Webブラウザでページが表示されるまで

Transcript

1. Webブラウザでページが表示されるまで 2023/05/11　三木 健太郎 (@mikikeen)
2. TCP/IP プロトコルスタックの全体像 • 離れた場所にあるコンピュータ同士を通信させたい • 通信経路の決定から物理的な信号の伝送まで、行うべき処理は多岐にわたる • そこで一連の処理をアプリケーションレベルでの処理～物理的なレベルまで、複数の階層に分離 • 各階層ごとに複数のプロトコルが規定されている • 各階層のプロトコルが互いに協調して、通信を実現する アプリケーション層 トランスポート層 インターネット層 ネットワーク インターフェース層 Ethernet IPv4 ARP TCP UDP HTTP FTP DNS … IPv6 無線LAN PPP … 信号の物理的な伝送方法を規定 宛先までデータを実際に届ける役割を担う アプリケーションごとに通信を振り分ける 確実なデータ伝送を実現 アプリケーションで扱うデータのフォー マットや処理手順を規定
3. TCP/IP プロトコルスタックの全体像 • 各階層のプロトコルは、上の階層からのデータを単にバイナリの列とみなす • 上の階層からのデータにヘッダをつけて、下の階層のプロトコルに渡す • 受信時は逆に、ヘッダを除去して上の階層のプロトコルに渡す アプリケーション層 トランスポート層 インターネット層 ネットワーク インターフェース層 アプリケーション層 トランスポート層 インターネット層 ネットワーク インターフェース層
4. 行われる処理 (アプリケーションのレベルで見た場合) 1. ブラウザがURLを解釈 2. DNSサーバにIPアドレスを問い合わせる 3. HTTPリクエストを作成し、プロトコルスタックに送信を依頼する 4. HTTPのレスポンスが返ってくるので、それをもとにブラウザの画面を描画する
5. ブラウザがURLを解釈する http://www.example.com
6. ブラウザがURLを解釈する http://www.example.com/ プロトコルの種類 ホスト名 (≒サーバー名) ドメイン名 サーバーのルートディレクトリ (ブラウザが付加) • ドメイン名の後には、本来ファイルパスが続く • ファイル名が明示されていない場合、サーバー側で返すべきファイルを判断 (.htaccessの内容に基づき判断) • ここではディレクトリも指定されていないが、ブラウザが文脈を判断し、サーバー のルートディレクトリへのアクセスだと判断
7. DNSサーバーにIPアドレスを問い合わせる • ホスト名+ドメイン名では、アクセスすべきサーバーが分からない • DNS(Domain Name System)を用いて、ホスト名+ドメイン名から、アクセスすべきサーバーの IPアドレス を取得する • DNSの問い合わせクエリはUDPで伝送される 名前 タイプ 返答内容 www.example.com A (IP アドレス) 93.184.216.34 hoge.example.com MX (メール配送先) 1 mail.example.com mail.example.com A 100.112.143.10 … … … DNSレコードのイメージ
8. DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … … クライアント
9. DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … … クライアント
10. DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … … クライアント
11. DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … … クライアント
12. DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … … クライアント
13. DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … … クライアント
14. DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … … クライアント
15. DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … … クライアント
16. 実際のDNSサーバからの応答
17. HTTPリクエストメッセージを作成 https://www.infraexpert.com/study/tcpip16.html より引用
18. HTTPリクエストメッセージを作成
19. HTTPのレスポンスをもとにブラウザの画面を描画 https://www.infraexpert.com/study/tcpip16.html より引用
21. 行われる処理 (トランスポート層のレベルで見た場合) 1. プロトコルスタックがソケットを作成する 2. サーバーに接続する 3. データを送受信する 4. 接続を切断し、ソケットを抹消する
22. プロトコルスタックがソケットを作成する • プロトコルスタックは、通信に必要な制御情報 (宛先IPアドレス、ポート番号、通信の進行状態 )をソケットと いう単位で管理している • クライアント側とサーバー側のソケットを (仮想的に)接続することで、通信を行う • 通常サーバー側は、クライアント側がソケットを繋ぎに来るのを待ち受けている • アプリケーション側でSocket APIを呼び出し、プロトコルスタックにソケット作成を依頼
23. サーバーに接続する (3Way Hand Shake方式) • クライアントが接続開始を通知するパケットを送信 • そのパケットのTCPヘッダのSYN(synchronize)フラグを1にして、接続開始をサーバー側に通知 • サーバー側は、同様にTCPヘッダのSYNフラグとACK(acknowledge)フラグを1にしたパケットを作成 • 更にシーケンス番号(このパケットの先頭位置のデータが元データの何バイト目かを表す )の初期値と、 ACK番号(これまで何バイト目まで受信したかを表す )、ウィンドウ(受信バッファの大きさ)を通知 • 最後にクライアント側がACK番号を通知 クライアント側 サーバー側
24. データを送受信する • データの送信側は、シーケンス番号 (このパケットの先頭位置のデータが元データの何バイト目かを表す ) とデータを送信 • 受信側は、ACK番号(これまで何バイト目まで受信したかを表す )、ウィンドウ(受信バッファの大きさ)を送り 返す • これを相互に繰り返す
25. 接続を切断し、ソケットを抹消する • Webではサーバーがデータを送り終えたら、サーバー側から接続を切断することになっている • サーバー側がTCPヘッダのFINフラグを1にしたパケットを送信 • クライアント側がACK番号を送信し、さらにTCPヘッダのFINフラグを1にしたパケットを送信 • 最後にサーバー側からACK番号が送信されてきて、接続は切断される
26. 行われる処理 (インターネット層のレベルで見た場合) 1. ARPプロトコルを用いて、次にパケットを中継すべきルーターの MACアドレスを通知してもらう 2. IPパケットにMACヘッダを付加し、ネットワークアダプタに実際の送信を依頼
27. ARPプロトコルで次にパケットを送るべきルーターを探す • ARPプロトコルで、IPのブロードキャストという仕組みを用いて、同じサブネットのホスト全体に宛先の IPア ドレスを通知して、パケットを中継してくれるルーターを見つける • パケットを中継できるルーターは自分の MACアドレスをクライアントに通知する