ネットワーク
INPUT · スライド
01 / 12
ブラウザにアドレスを打つと、ページが返ってくる。あの一瞬のあいだに、2人の役者が決まった仕事をしているよ。
頼む側が クライアント、応える側が サーバ。この2つに役割を分けた組み方を クライアントサーバシステム と呼ぶ。ブラウザがクライアントで、ページを持っている機械が Web サーバだね。
大事なのは、役割が入れかわらないこと。話を始めるのはいつもクライアントの側で、サーバのほうから勝手にページを送りつけてくることはないよ。
もうひとつ、サーバは機械の名前ではなく役割の名前だということ。1台の中に Web サーバと DB サーバが同居していることもあるし、逆に1つの役割を何台にも分けることもある。
02 / 12
クライアントとサーバのやり取りは、いつも2つで1組だよ。クライアントが送るのが リクエスト（要求）、サーバが返すのが レスポンス（応答）。Web ではこの往復の書き方を HTTP が決めている。
リクエストに書くのは、どれが欲しいか（URL）と、何をしたいか（メソッド）だよ。取ってくるだけなら GET、入力した内容を送りつけるなら POST だね。
レスポンスの先頭には、うまくいったかどうかを表す番号が付く。200 は成功、404 は見つからない、500 はサーバ側で失敗、という具合。
「ページが出ない」と言われたとき、何番が返っているかを見るだけで、探す場所がぐっと狭くなるよ。
クライアント │ リクエスト │ GET /index.html ↓サーバ │ レスポンス │ 200 OK と中身 ↓クライアント03 / 12
1回の往復で運ばれてくるのは、たいてい HTML の文章だけだよ。見た目を決める CSS も、写真も、動きをつける JavaScript も、まだ手元に無い。
ブラウザは受け取った HTML を読みながら、足りないものを見つけるたびにもう一度リクエストを出す。画像が10枚あれば、それだけで10往復。つまり1ページの表示は、何十回もの往復の集まりなんだ。
ページが遅いとき、犯人が「1回の通信が遅い」ではなく「往復の回数が多すぎる」であることは珍しくない。
この先に出てくる工夫は、ほとんどが往復の回数を減らすか、1回で運ぶ量を減らすかの話だと思って読んでほしい。
04 / 12
HTTP には、意外に思える性質がある。1往復が終わると、サーバは相手のことを忘れるんだ。これを ステートレス と言うよ。
それでは困る場面がある。買い物かごに入れた品物や、ログインした状態は、次のリクエストでも覚えていてほしいよね。
そこで使うのが Cookie だよ。サーバはレスポンスに小さな覚え書きを付けて返し、ブラウザは次のリクエストからそれを一緒に送る。渡すのは「あなたは何番の人か」という セッション ID だけで、中身のデータはサーバ側に置いておくのがふつうだね。
忘れる仕組みの上に、覚えているように見せる仕組みを乗せている。この二階建てが Web の作りだよ。
05 / 12
サーバが返すものには2種類ある。
動的にするには、Web サーバが外部のプログラムを呼び出す必要がある。その受け渡しの決めごとが CGI だよ。呼ばれたプログラムが HTML を組み立て、Web サーバはそれをレスポンスに載せて返す。
2つはかかる手間がまるで違う。ファイルを読むだけの静的に対して、動的はプログラムを動かし、たいていデータベースまで見に行く。だから重いほうを別の機械に任せよう、という発想が出てくるよ。
06 / 12
プログラムが動く場所も2つある。サーバの中で動くのか、クライアントに送られてから動くのかだよ。
アプレットは、コンパイル済みの小さなプログラムがサーバに置いてあって、要求されたときにクライアントへ転送されてから実行されるもの。名前の似たサーブレットはサーバの中で動くほうだよ。
見分け方は名前のとおりで、サーブ（serve）が付くほうがサーバ側。試験ではこの2つを入れかえた選択肢が並ぶよ。
サーブレット サーバの中で動く → 結果だけ返るアプレット クライアントへ送られ → 手元で動く07 / 12
動的なページを返すサーバの中では、仕事がさらに分かれている。よくあるのが3段だよ。
この並びを、1回のリクエストがどう流れるかで追ってみよう。受け取った中身を読み解いたら、DB につなぎ、SQL を組み立て、データを取り、それを HTML に組み立て、ブラウザへ送り、最後に DB を切る。
つまずきやすいのは2か所。SQL を組み立てるのはアクセスより前、そして HTML を組み立てるのはデータを取った後だよ。中身が無いのに HTML は作れないよね。
③ DB へつなぐ⑤ SQL を組み立てる② DB にアクセスする④ HTML を組み立てる⑥ ブラウザへ送る① DB を切る08 / 12
3段に分ける利点は、種類の違う仕事を、向いた機械に振り分けられることだよ。
置いてあるファイルを返すだけの軽いリクエストは Web サーバが自分で片づけ、プログラムを動かしてデータベースまで見に行く重いリクエストは AP サーバへ回す。リクエストの種類で担当を分けられるのが、機械を分けるいちばんの効きどころだね。
もうひとつは、業務処理がサーバ側に集まること。クライアントに残るのは画面の表示だけになるので、処理を直したいときはサーバを直せば全員に効く。端末に配って回る必要が無いよ。
逆に言えば、クライアント側で業務処理をすると書いてある選択肢は、分ける前の形の説明だよ。
09 / 12
往復が重いなら、まとめてしまえばいい。データベース相手でよく使われるのが ストアドプロシージャ だよ。
よく使う SQL のまとまりをあらかじめサーバ側の DBMS に登録しておき、クライアントは「あれを実行して」と名前で呼ぶ。SQL 文を何十行も送らずに済むので、クライアントとサーバの間の通信量が減る。
気をつけたいのは、減るのは通信量だけだということ。サーバがデータベースのファイルを読む量も、メモリの使用量も、置き場所の大きさも変わらない。仕事の場所を移しただけで、仕事そのものは消えていないからね。
「大量の SQL 文で通信の負荷が高い」と書いてあったら、答えはこれだよ。
10 / 12
昔の Web は、ボタンを押すたびにページ全体が描き直されていた。変わるのは一部分だけなのに、毎回まるごと運び直していたんだね。
それを変えたのが Ajax だよ。JavaScript が裏側でサーバとやり取りし、返ってきたデータで画面の一部だけを描き直す。地図をドラッグしてもページが真っ白にならないのは、これのおかげ。
鍵になる言葉は 非同期。応答を待っているあいだも画面は固まらず、操作を続けられる。「頼んだら、返事が来るまで何もできない」をやめた、ということだよ。
運ぶのが一部だけになるので、1往復あたりの量も小さくなる。回数と量の両方に効いているね。
11 / 12
クライアントとサーバのあいだに、もう1台はさまることがある。代表が プロキシサーバ だよ。
ブラウザはプロキシに頼み、プロキシが代わりに本物のサーバへ頼みに行く。往復が2本に分かれるので、宛先のポート番号も分かれるよ。ブラウザからプロキシへの要求はプロキシの番号（たとえば 8080）宛て、プロキシから Web サーバへの要求は 80 宛てになる。
応答は行きと逆向きに流れるので、宛先はそのつど頼んできた側になる。「常に 8080 宛てになるのはどれか」と聞かれたら、プロキシに向けて出す要求だけが答えだね。
この 80 は Web の窓口として世界中で決まっている番号。ファイアウォールでもまず開けてあるので、そこを通り道に選ぶ悪いプログラムもいるよ。
A → B 宛先 8080B → C 宛先 80C → B 宛先 B の番号B → A 宛先 A の番号12 / 12
ここまでは、人がブラウザで頼む話だった。同じ往復を、プログラムどうしでやることもできる。それが Web サービス だよ。
このとき困るのが、相手のプログラムが自分と違う言葉で書かれていること。そこで、どちらでも読める形に直してから運ぶ。長く使われてきたのが XML だね。
XML の特徴は、タグを自分で決められること。HTML は使えるタグが決まっているけれど、XML は <price> でも <author> でも定義してよい。だからシステムどうしのデータ交換に向いているんだ。
その XML のメッセージを送受信するプログラムの間で受け渡す決めごとが SOAP。そして、複数の Web サービスをつないで新しいサービスにすることを マッシュアップ と呼ぶよ。