ネットワークの一般的な動作として、LAMP環境のwebサイトにWindowsマシンからhttps通信でアクセスする場合、OSI基本参照モデルにおいてどのような通信経路を辿りますか？: ひっくり返った犬小屋に逃げろ

<< ブルキナファソの歴史 | TOP | IISはwebサーバですか？APサーバですか？ >>

2025年09月15日

ネットワークの一般的な動作として、LAMP環境のwebサイトにWindowsマシンからhttps通信でアクセスする場合、OSI基本参照モデルにおいてどのような通信経路を辿りますか？

質問

ネットワークの一般的な動作として、LAMP環境のwebサイトにWindowsマシンからhttps通信でアクセスする場合、OSI基本参照モデルにおいてどのような通信経路を辿りますか？
ユーザがブラウザを開いたところから順を追って詳細にまとめてください。

解答

# 概要ユーザがWindowsでブラウザを開き、LAMP（Linux + Apache + MySQL + PHP）上の Web サイトに HTTPS（= HTTP over TLS）でアクセスする際には、アプリケーション層から物理層まで順に多くのプロトコルと処理が連鎖します。

以下は「ユーザがブラウザを開いてクリックしてからページが表示されるまで」を時系列に追い、各段階で実際に何が起きるかを OSI 基本参照モデルの層と照らし合わせて詳細に説明したものです。

# ステップごとの詳細（時系列）

0) ユーザ操作（起点）

* 何をするか：ブラウザに URL（例 `https://www.example.com/path`）を入力して Enter、またはリンククリック。
* OSI層：アプリケーション層（第7層）

* 備考：ブラウザは URL を解析（スキーム `https`・ホスト名・パス）して接続準備を始める。

1) キャッシュ／hosts の確認

* 動作：ブラウザ→OS の DNS キャッシュ、ブラウザ内キャッシュ、`hosts` ファイル、OS レベルのキャッシュをまず確認。

* OSI層：アプリケーション層（DNS はアプリ層のプロトコル）

* 結果：IP アドレスが既に分かれば DNS 問い合わせは不要。
無ければ次へ。

2) DNS 名前解決（[www.example.com](http://www.example.com) → IP）

* 動作：

* ブラウザ/OS がローカルキャッシュにないと、DNS リゾルバ（通常はISPや社内DNS）へ問い合わせ。
* 通常 UDP/53 でクエリ送信（大きい応答や DNSSEC では TCP/53）。

* OSI層：アプリケーション（DNS） → トランスポート層（UDP/TCP） → ネットワーク層（IP） → データリンク（Ethernet/Wi-Fi） → 物理層

* 注意点：DoH/DoT を使う場合は DNS も TLS/HTTPS による暗号化通信となる（ブラウザ設定次第）。

3) DNS 応答受信 → IP 確定

* 動作：IP（例 `203.0.113.10`）を取得。
TTL により次のキャッシュ期間が決まる。

* OSI層：アプリケーション層（DNS）

4) ルーティングと ARP（次ホップの MAC 解決）

* 動作：

* クライアントの OS は宛先 IP がローカルサブネットかどうか判断。
別サブネットならデフォルトゲートウェイ（ルータ）へ送る。
* 次ホップの MAC アドレスが不明なら ARP Request → ARP Reply（IPv4 の場合）。（IPv6 は Neighbor Discovery）

* OSI層：ネットワーク層（IP）とデータリンク層（ARP / Ethernet）

5) NAT / ファイアウォールの存在確認

* 動作：

* クライアントがルータの背後にいる場合、送信時にルータで NAT（ソース IP をグローバル IP に書き換え）される。
* 企業やホストのファイアウォールがポリシーをチェック（443/tcp を許可するか）。

* OSI層：境界でのネットワーク層／トランスポート層の処理（NAT はネットワーク層に跨る機能）

6) TCP コネクション確立（3-way handshake）

* 動作：

1. クライアント → サーバへ `SYN`（初期シーケンス番号、MSS、SACK、Window Scale 等のオプションを含む）

2. サーバ → クライアント `SYN/ACK`

3. クライアント → サーバ `ACK`（接続確立）

* ポート：宛先ポートは 443/tcp（HTTPS）

* OSI層：トランスポート層（TCP）→ ネットワーク（IP）→ データリンク（Ethernet）

* TCP の追加要素：CWND（輻輳制御）、スロースタート、再送タイムアウトなど

7) TLS ハンドシェイク（暗号化チャネル構築）

* 動作（TLS 1.2 の場合の代表）：

1. クライアント→サーバ：`ClientHello`（サポートする TLS バージョン、暗号スイート、SNI（Server Name Indication：仮想ホスト名を通知）、ランダム値、ALPN（HTTP/1.1 or HTTP/2 希望））

2. サーバ→クライアント：`ServerHello`（選択された暗号、ランダム値）、`Certificate`（証明書チェーン）、（必要なら `ServerKeyExchange`）、`ServerHelloDone`

3. クライアント：証明書検証（ルートCAまで検証、OCSP/CRL/OCSP Stapling を確認する場合あり）、`ClientKeyExchange`（鍵交換情報：RSA/（E）DHE）、`ChangeCipherSpec`、`Finished`

4. サーバ：`ChangeCipherSpec`、`Finished` → 双方で対称鍵が確立され、アプリケーションデータは暗号化される

* TLS 1.3：ハンドシェイクが短縮され、鍵合意が早く行われる（0-RTT オプトも可）。
* OSI層：プレゼンテーション層（第6層）／セッション層（第5層）の機能を担うが、実装上はトランスポート（TCP）上で動くアプリケーション層プロトコル

8) ブラウザ側の証明書検証とポリシーチェック

* 検証内容： * 証明書の署名（CA のルートまで）

* 有効期限、失効（OCSP/CRL）

* サブジェクト名とアクセス中のホスト名の一致（CN/SAN）

* 信頼ストアに基づくチェーンの合否

* 追加チェック：HSTS（事前に強制 HTTPS の指示がある場合）、ピンニング等

* 失敗時：ユーザに警告（例：不正な証明書）を表示

9) HTTP リクエスト送信（暗号化されたアプリケーションデータ）

* 動作：

* ブラウザが HTTP リクエスト（例 `GET /path HTTP/1.1`、ヘッダに `Host: www.example.com`、`User-Agent`、Cookie 等）を生成 * HTTP が TLS レコードに格納され、TLS により暗号化され、TCP セグメントとして送出される

* HTTP バージョン：

* ALPN によって HTTP/2 が選ばれれば単一の TLS 接続で複数リクエストを多重化（ストリーム番号）できる

* OSI層：アプリケーション層（HTTP）→ プレゼンテーション/セッション（TLS）→ トランスポート（TCP）→ ...

10) サーバ側での受信処理（Linux + Apache）

* NIC → カーネル：Ethernet フレームを NIC が受け取り、カーネルのネットワークスタックへ。
ドライバ→カーネル→ソケットバッファ。
* TCP/TLS 復号：

* カーネルからプロセス（Apache）へデータが渡る。
* Apache（mod_ssl / OpenSSL など）が TLS レコードを復号して HTTP を得る。
* バーチャルホスト判定：

* SNI と Host ヘッダを使ってどの仮想ホスト／証明書で処理するか決定。

11) Web アプリケーション処理（Apache → PHP → MySQL）

* PHP の呼び出し方式：

* `mod_php`（Apache 内で直接 PHP 実行）か、`PHP-FPM`（FastCGI 経由）かにより仕組みは異なるが目的は同じ：リクエストに応じて PHP スクリプトを実行。
* DB アクセス：

* PHP がデータを取得するため MySQL に接続（通常は TCP 3306 か unix ドメインソケット）。
* MySQL がクエリ処理 → 結果を返す。
* テンプレート作成：

* PHP は DB の結果を HTML に組み込み、必要なら JSON を作る。
* 出力： * 生成した応答（HTML、ヘッダ：Content-Type、Set-Cookie、Content-Encoding gzip 等）を Apache が受け取り、TLS 層へ渡す。

12) サーバ側 TLS 暗号化と送信

* 動作：

* Apache/OpenSSL がレスポンスを TLS レコード化して暗号化。
* TCP はデータをセグメント化し、IP パケットに封入して送出。
Ethernet フレーム化され NIC から物理的に送信。
* 性能最適化：gzip 圧縮、TCP セグメンテーションオフロード（LSO）、NIC のハードウェア暗号化支援などが動作する場合あり。

13) インターネット経路（ルータ・ISP・BGP）

* 動作：

* パケットは複数のルータを経由（各ルータは IP ヘッダの TTL を減らす）。
* AS 間は BGP によって経路が選ばれる（OSI の外側、運用層だがネットワーク層の上位概念）。
* パケット損失や遅延があれば TCP の再送機構や輻輳制御が働く。
* OSI層：ネットワーク層中心、リンク層/物理層に渡る

14) クライアント側受信・復号

* 動作：

* Windows マシンの NIC がフレームを受ける → カーネルが TCP バッファに格納 → アプリ（ブラウザ）へデータ渡す。
* TLS レコードが復号されて HTTP レスポンスを得る。
* ブラウザの処理：ステータスコードのチェック（200, 301/302 → リダイレクト処理など）、ヘッダ（Set-Cookie, Cache-Control など）を処理。

15) ブラウザによるパースとリソース取得

* HTML パース：DOM ツリー構築、CSSOM 構築、レンダーツリー作成。
* 外部リソース：CSS・JS・画像・フォント等を検出して追加リクエスト（同一ホストなら既存 TLS 接続の再利用；異なるドメインなら別に DNS→TLS→HTTP の流れ）。
* HTTP/2 の場合：同じ TLS 接続で複数リソースを同時に多重化して取得可能（効率向上）。
* レンダリング：CSS レイアウト → ペイント → JavaScript 実行（DOM 書き換えで再レイアウトあり）。

16) 接続維持 or 終了

* Keep-Alive / Persistent Connection：

* HTTP（/1.1 ではデフォルト）で接続を保持し複数リクエストを同一 TCP/TLS 接続で処理。
* TLS 終了： * セッションを終了するときは TLS の `close_notify` を交換し、TCP の `FIN`/`ACK` で接続 teardown。
* セッション再利用：TLS セッションチケットやセッション ID を用いた再接続の高速化（再ハンドシェイクを抑制）。
# OSI 層別の主要な関与要素（要約表）

OSI 層	具体的に関わるもの（このシナリオ）
7 アプリケーション	ブラウザ（HTTP リクエスト生成、HTML パース）、Apache、PHP、MySQL、DNS（アプリ層プロトコル）
6 プレゼンテーション	TLS（暗号化／復号、Record layer、証明書交換）
5 セッション	TLS セッション管理、HTTP/2 のストリーム管理（概念的）
4 トランスポート	TCP（3-way handshake、再送、輻輳制御、ポート443/3306/53 等）
3 ネットワーク	IP（ルーティング、TTL、フラグメンテーション）、ルータ間の経路選択（BGP）
2 データリンク	Ethernet フレーム、MAC アドレス、スイッチング、ARP
1 物理	光ファイバ / UTP ケーブル / 無線（物理的伝送媒体）

追加の重要ポイント（実務的・セキュリティ的観点）

* SNI（Server Name Indication）：1台のIPで複数仮想ホスト運用する場合、TLS ClientHello にホスト名を渡して適切な証明書を選ばせる。
* ALPN（Application-Layer Protocol Negotiation）：TLS 上で HTTP/2 を選択する交渉に使用。
HTTP/2 が選ばれるとパフォーマンスが変わる。
* 証明書検証の仕組み：OCSP Stapling（サーバが OCSP 応答を添付）でパフォーマンス向上／プライバシー改善。
* 圧縮とセキュリティ：TLS 圧縮は脆弱性（CRIME など）で非推奨。
代わりにアプリ層で gzip 圧縮する。

* CSP / HSTS / Secure Cookie：ブラウザとサーバでセキュリティポリシーを付与し、欺瞞的な挙動を緩和。

* ログと監査：サーバ側のアクセスログ、TLS ハンドシェイク失敗ログ、WAF（Web Application Firewall）が重要。
* 性能ボトルネック：DNS ラウンドトリップ、TLS ハンドシェイク (特に初回)、TCP スロースタート、バックエンド DB クエリが主因。
# トラブルシューティングの観点で確認すべき点（一覧） * DNS が返っているか（`nslookup` / `dig`）

* ARP/ゲートウェイ接続（`arp -a` / `ip route`）

* ポート到達性（`telnet host 443` / `nc -zv` / `curl -v`）

* TLS 証明書（`openssl s_client -connect host:443 -servername host`）

* サーバログ（Apache access/error、PHP-FPM、MySQL）

* ネットワークパケット確認（`tcpdump` / Wireshark）

# 最後に（短いまとめ）

* ユーザがブラウザを開いて HTTPS で LAMP にアクセスする流れは、DNS → TCP ハンドシェイク → TLS ハンドシェイク → HTTP リクエスト（暗号化） → サーバ側での PHP/MySQL 処理 → TLS 暗号化 → TCP/IP 経路 → ブラウザでの復号・レンダリング、という一連の連続処理です。

* 各段階は OSI の各層に対応し、性能や可用性・セキュリティはそれぞれの層で左右されます。