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
68
Webブラウザでページが表示されるまで
mikiken
May 11, 2023
Tweet
Share
More Decks by mikiken
See All by mikiken
ライフゲームの製作
mikiken
0
200
簡単な4bitCPUの作成
mikiken
0
1.1k
Cコンパイラ自作はじめてみた
mikiken
0
240
seccamp2022 成果発表
mikiken
0
36
Other Decks in Technology
See All in Technology
OCI Network Firewall 概要
oracle4engineer
PRO
1
7.8k
Trust as Infrastructure
bcantrill
1
370
カンファレンスに託児サポートがあるということ / Having Childcare Support at Conferences
nobu09
1
430
SREとソフトウェア開発者の合同チームはどのようにS3のコストを削減したか?
muziyoshiz
1
110
ACA でMAGI システムを社内で展開しようとした話
mappie_kochi
1
300
AIAgentの限界を超え、 現場を動かすWorkflowAgentの設計と実践
miyatakoji
1
160
LLM時代にデータエンジニアの役割はどう変わるか?
ikkimiyazaki
6
1.1k
関係性が駆動するアジャイル──GPTに人格を与えたら、対話を通してふりかえりを習慣化できた話
mhlyc
0
130
プロポーザルのコツ ~ Kaigi on Rails 2025 初参加で3名の登壇を実現 ~
naro143
1
160
AI時代こそ求められる設計力- AWSクラウドデザインパターン3選で信頼性と拡張性を高める-
kenichirokimura
3
160
成長自己責任時代のあるきかた/How to navigate the era of personal responsibility for growth
kwappa
4
300
SoccerNet GSRの紹介と技術応用:選手視点映像を提供するサッカー作戦盤ツール
mixi_engineers
PRO
1
190
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6.1k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
9
580
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
It's Worth the Effort
3n
187
28k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
Git: the NoSQL Database
bkeepers
PRO
431
66k
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アドレスをクライアントに通知する