Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Webブラウザでページが表示されるまで
Search
mikiken
May 11, 2023
Technology
0
61
Webブラウザでページが表示されるまで
mikiken
May 11, 2023
Tweet
Share
More Decks by mikiken
See All by mikiken
ライフゲームの製作
mikiken
0
180
簡単な4bitCPUの作成
mikiken
0
1k
Cコンパイラ自作はじめてみた
mikiken
0
240
seccamp2022 成果発表
mikiken
0
35
Other Decks in Technology
See All in Technology
Liquid Glass革新とSwiftUI/UIKit進化
fumiyasac0921
0
190
地図も、未来も、オープンに。 〜OSGeo.JPとFOSS4Gのご紹介〜
wata909
0
110
How Community Opened Global Doors
hiroramos4
PRO
1
110
Amazon S3標準/ S3 Tables/S3 Express One Zoneを使ったログ分析
shigeruoda
3
460
登壇ネタの見つけ方 / How to find talk topics
pinkumohikan
3
350
UIテスト自動化サポート- Testbed for XCUIAutomation practice
notoroid
0
130
エンジニア向け技術スタック情報
kauche
1
250
AWS アーキテクチャ作図入門/aws-architecture-diagram-101
ma2shita
29
10k
Snowflake Summit 2025 データエンジニアリング関連新機能紹介 / Snowflake Summit 2025 What's New about Data Engineering
tiltmax3
0
310
解析の定理証明実践@Lean 4
dec9ue
0
170
急成長を支える基盤作り〜地道な改善からコツコツと〜 #cre_meetup
stefafafan
0
120
Oracle Audit Vault and Database Firewall 20 概要
oracle4engineer
PRO
3
1.7k
Featured
See All Featured
Agile that works and the tools we love
rasmusluckow
329
21k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.3k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
KATA
mclloyd
29
14k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.3k
Designing for Performance
lara
609
69k
Designing Experiences People Love
moore
142
24k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Six Lessons from altMBA
skipperchong
28
3.8k
Transcript
Webブラウザでページが表示されるまで 2023/05/11 三木 健太郎 (@mikikeen)
TCP/IP プロトコルスタックの全体像 • 離れた場所にあるコンピュータ同士を通信させたい • 通信経路の決定から物理的な信号の伝送まで、行うべき処理は多岐にわたる • そこで一連の処理をアプリケーションレベルでの処理~物理的なレベルまで、複数の階層に分離 • 各階層ごとに複数のプロトコルが規定されている
• 各階層のプロトコルが互いに協調して、通信を実現する アプリケーション層 トランスポート層 インターネット層 ネットワーク インターフェース層 Ethernet IPv4 ARP TCP UDP HTTP FTP DNS … IPv6 無線LAN PPP … 信号の物理的な伝送方法を規定 宛先までデータを実際に届ける役割を担う アプリケーションごとに通信を振り分ける 確実なデータ伝送を実現 アプリケーションで扱うデータのフォー マットや処理手順を規定
TCP/IP プロトコルスタックの全体像 • 各階層のプロトコルは、上の階層からのデータを単にバイナリの列とみなす • 上の階層からのデータにヘッダをつけて、下の階層のプロトコルに渡す • 受信時は逆に、ヘッダを除去して上の階層のプロトコルに渡す アプリケーション層 トランスポート層
インターネット層 ネットワーク インターフェース層 アプリケーション層 トランスポート層 インターネット層 ネットワーク インターフェース層
行われる処理 (アプリケーションのレベルで見た場合) 1. ブラウザがURLを解釈 2. DNSサーバにIPアドレスを問い合わせる 3. HTTPリクエストを作成し、プロトコルスタックに送信を依頼する 4. HTTPのレスポンスが返ってくるので、それをもとにブラウザの画面を描画する
ブラウザがURLを解釈する http://www.example.com
ブラウザがURLを解釈する http://www.example.com/ プロトコルの種類 ホスト名 (≒サーバー名) ドメイン名 サーバーのルートディレクトリ (ブラウザが付加) • ドメイン名の後には、本来ファイルパスが続く
• ファイル名が明示されていない場合、サーバー側で返すべきファイルを判断 (.htaccessの内容に基づき判断) • ここではディレクトリも指定されていないが、ブラウザが文脈を判断し、サーバー のルートディレクトリへのアクセスだと判断
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レコードのイメージ
DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … …
クライアント
DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … …
クライアント
DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … …
クライアント
DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … …
クライアント
DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … …
クライアント
DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … …
クライアント
DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … …
クライアント
DNSによる名前解決の様子 / (root) com jp 最寄りの DNSサーバ example … …
クライアント
実際のDNSサーバからの応答
HTTPリクエストメッセージを作成 https://www.infraexpert.com/study/tcpip16.html より引用
HTTPリクエストメッセージを作成
HTTPのレスポンスをもとにブラウザの画面を描画 https://www.infraexpert.com/study/tcpip16.html より引用
None
行われる処理 (トランスポート層のレベルで見た場合) 1. プロトコルスタックがソケットを作成する 2. サーバーに接続する 3. データを送受信する 4. 接続を切断し、ソケットを抹消する
プロトコルスタックがソケットを作成する • プロトコルスタックは、通信に必要な制御情報 (宛先IPアドレス、ポート番号、通信の進行状態 )をソケットと いう単位で管理している • クライアント側とサーバー側のソケットを (仮想的に)接続することで、通信を行う •
通常サーバー側は、クライアント側がソケットを繋ぎに来るのを待ち受けている • アプリケーション側でSocket APIを呼び出し、プロトコルスタックにソケット作成を依頼
サーバーに接続する (3Way Hand Shake方式) • クライアントが接続開始を通知するパケットを送信 • そのパケットのTCPヘッダのSYN(synchronize)フラグを1にして、接続開始をサーバー側に通知 • サーバー側は、同様にTCPヘッダのSYNフラグとACK(acknowledge)フラグを1にしたパケットを作成
• 更にシーケンス番号(このパケットの先頭位置のデータが元データの何バイト目かを表す )の初期値と、 ACK番号(これまで何バイト目まで受信したかを表す )、ウィンドウ(受信バッファの大きさ)を通知 • 最後にクライアント側がACK番号を通知 クライアント側 サーバー側
データを送受信する • データの送信側は、シーケンス番号 (このパケットの先頭位置のデータが元データの何バイト目かを表す ) とデータを送信 • 受信側は、ACK番号(これまで何バイト目まで受信したかを表す )、ウィンドウ(受信バッファの大きさ)を送り 返す
• これを相互に繰り返す
接続を切断し、ソケットを抹消する • Webではサーバーがデータを送り終えたら、サーバー側から接続を切断することになっている • サーバー側がTCPヘッダのFINフラグを1にしたパケットを送信 • クライアント側がACK番号を送信し、さらにTCPヘッダのFINフラグを1にしたパケットを送信 • 最後にサーバー側からACK番号が送信されてきて、接続は切断される
行われる処理 (インターネット層のレベルで見た場合) 1. ARPプロトコルを用いて、次にパケットを中継すべきルーターの MACアドレスを通知してもらう 2. IPパケットにMACヘッダを付加し、ネットワークアダプタに実際の送信を依頼
ARPプロトコルで次にパケットを送るべきルーターを探す • ARPプロトコルで、IPのブロードキャストという仕組みを用いて、同じサブネットのホスト全体に宛先の IPア ドレスを通知して、パケットを中継してくれるルーターを見つける • パケットを中継できるルーターは自分の MACアドレスをクライアントに通知する