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
190
簡単な4bitCPUの作成
mikiken
0
1k
Cコンパイラ自作はじめてみた
mikiken
0
240
seccamp2022 成果発表
mikiken
0
35
Other Decks in Technology
See All in Technology
生まれ変わった AWS Security Hub (Preview) を紹介 #reInforce_osaka / reInforce New Security Hub
masahirokawahara
0
480
SmartNewsにおける 1000+ノード規模 K8s基盤 でのコスト最適化 – Spot・Gravitonの大規模導入への挑戦
vsanna2
0
140
タイミーのデータモデリング事例と今後のチャレンジ
ttccddtoki
6
2.4k
Delta airlines Customer®️ USA Contact Numbers: Complete 2025 Support Guide
deltahelp
0
710
怖くない!はじめてのClaude Code
shinya337
0
400
LangChain Interrupt & LangChain Ambassadors meetingレポート
os1ma
2
320
Reach American Airlines®️ Instantly: 19 Calling Methods for Fast Support in the USA
flyamerican
1
170
関数型プログラミングで 「脳がバグる」を乗り越える
manabeai
1
190
生成AI活用の組織格差を解消する 〜ビジネス職のCursor導入が開発効率に与えた好循環〜 / Closing the Organizational Gap in AI Adoption
upamune
7
5.3k
OPENLOGI Company Profile
hr01
0
67k
第4回Snowflake 金融ユーザー会 Snowflake summit recap
tamaoki
1
290
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
27k
Featured
See All Featured
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
54k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.4k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Raft: Consensus for Rubyists
vanstee
140
7k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
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アドレスをクライアントに通知する