- URL入力→アクセス先のプロトコル判断（http:, ftp: maito:）→サーバー名・ファイル名解読
- （HTTPの場合）リクエスト・メッセージ作成
- リクエスト・ライン（リクエスト内容を簡潔に示したもの）
- メッセージヘッダー
- メッセージ・ボディー
- IPアドレス宛にHTTPメッセージを送る（←まずIPアドレスを調べる必要がある）
- IPアドレスの調査
- Socketライブラリのリゾルバを利用して、DNSサーバーに問い合わせ、IPアドレスを調査する
- IPアドレス＝ネットワーク上の住所
- ネットワーク番号（丁目）・ホスト番号（番地）で構成されている
- IPアドレス＝ネットワーク上の住所
- Socketライブラリの内部にあるリゾルバが動く
- OS内部のプロトコル・スタックを呼び出して、LANアダプター経由でメッセージが送信される
- 応答メッセージはプロトコル・スタック経由して、リゾルバに渡され、リゾルバがメッセージを解読してIPを取り出す
- Socketライブラリのリゾルバを利用して、DNSサーバーに問い合わせ、IPアドレスを調査する
- IPアドレスの調査
- プロトコル・スタック
- TCP
- ソケット作成
- ディスクリプタ作成
- 接続：「通信相手との間で制御情報（IPアドレス・ポート番号）をやり取りして、ソケットに必要情報を記録して、データ通信可能な情報にすること」
- クライアント側からサーバー側に制御情報を伝える
- バッファ・メモリー（データ送受信するために必要なメモリー領域）の確保
- 送受信
- データはパケットで送信
- データが大きいときは分割して送る
- シーケンス番号・ACK番号でパケットが受信したことを確認する
- 切断
- サーバー側のプロトコル・スタックがTCPヘッダを作ってそこに切断情報を渡す（コントロール・ビットのFINビットに1をセット）。サーバー側のソケットに切断動作に入ったことを記録。
- クライアント側にFINに1をセットしたTCPヘッダが届いたら、プロトコル・スタックに記録。クライアント側からFINを1ににしたバケットを届いたことを知らせるために、ACK番号をサーバー側に送り返す
- クライアントのプロトコル・スタックもTCPヘッダを作ってそこに切断情報を渡す（コントロール・ビットのFINビットに1をセット）。IP担当部分に依頼してサーバーに送信してもらう。
- サーバーからACK番号が返ってくれば、サーバーとのやり取りは終了
- ソケット抹消
- ソケットはすぐに抹消しない
- 理由：クライアントから切断動作が始まり、最後にクライアントからACK番号が送信されなかったときにソケット消えていたら、サーバーはFINを再送信する。このときに新しいソケットが作成されていて同じポート番号に割り当てられたら、新しいソケットの切断動作に入ってしまうかもしれないから。
- ソケットはすぐに抹消しない
- ソケット作成
- IP
- パケット：ヘッダー＋データで構成されている
- ヘッダー：宛先などを表す制御情報が入っている
- TCP/IPパケット
- ヘッダー：MACヘッダー（宛先が次のルーター）＋IPヘッダー（宛先が目的地のサーバー）
- IP担当部分はIPヘッダーをつけたら、その前にMACヘッダーをつける
- TCPヘッダー・データの中身はバイナリデータとみなす（中身の情報は識別できない）
- MACヘッダー：宛先MAC＋送信元MAC＋イーサー・タイプ
-
MACアドレス
-
ARP（Adress Resolusion Protcol）を使って宛先MACを調べる
-
- パケット：ヘッダー＋データで構成されている
- LANドライバ
- ROMに全世界で重複しないよう一元管理されたMACアドレスが製造時に書き込まれている
- LANドライバーがMACアドレスをMAC回路にセットする
- TCP
- サブネット（小さなネットワークの単位）
- パケットはファイアウォールを通過してから、Webサーバーに辿り着く
- パケット・フィルタリング型ファイアウォール
- 宛先IPアドレス・送信元IPアドレス・宛先ポート番号・送信元ポート番号・コントロールビットでパケットを通すか棄てるか判断している
- パケット・フィルタリング型ファイアウォール
- サーバーへのアクセスが増えた時には、複数サーバーで負荷分散をする
- ロードバランサー
- WebサーバーからCPU・メモリ使用率などを収集して負荷状態を判断
- やり取りが複数ページに渡る時は同じWebサーバーを使用。前後関係を判断するための情報をHTTPのヘッダー・フィールドに付け加える。
- キャッシュ・サーバー
- プロキシという仕組みを使用して、データをキャッシュするサーバー。
- キャッシュ・サーバーにデータがある場合、Webサーバーからはコンテンツに変更なしという情報のみが返信され、クライアントにはキャッシュ・サーバーのデータが送られる。
- フォワードプロキシ：クライアント側に置くプロキシサーバー
- サーバーの運営者がコントロールできない
- ネットワークのトラフィックを抑えることができる
- リバースプロキシ：サーバー側に置くプロキシサーバー
- Webサーバーの負荷を抑えることができる
- キャッシュサーバーの管理ができる
- コンテンツ配信サービス
- コンテンツ配信サービス運営者がプロバイダと契約して、クライアント側に置いたキャッシュサーバーをWebサーバー運営者に貸し出すことで、サーバー運営者はキャッシュサーバーを管理できる。さらにインターネットのトラフィックを減らすことも可能。
- 接続を待つ部分とクライアントとやりとりする部分に分かれている（マルチスレッド）
- ソケット作成のステップ
- ソケット作成
- ソケットを接続待ち状態にする（サーバー特有）
- 接続を受け付ける（サーバー特有）
- データを送受信する
- パイプを外してソケットを抹消する
- LANドライバ：MACヘッダーからプロトコルを判断して、プロトコル・スタックに渡す
- IP担当部分：
- TCP担当部分：