知識マップ: OSI参照モデルをはっきりイメージする ── HTTPリクエスト1個を7層に解剖する

記事「OSI参照モデルをはっきりイメージする ── HTTPリクエスト1個を7層に解剖する」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

OSI参照モデルは7層それぞれに対応するOSIプロトコル群を伴う標準として構想されたが、普及競争でTCP/IPプロトコルスイートに敗れ、現実のインターネットはリンク層・IP層・トランスポート層・アプリケーション層の実質4層で動いている。HTTPリクエストを運ぶEthernetフレームは、Ethernet(L2、MACアドレス宛)・IPv4(L3、ルーターを越えても変わらない宛先IP)・TCP(L4、ポート番号での振り分けと信頼性のあるバイトストリーム)・HTTP(L7)という入れ子構造(カプセル化)を持ち、Wiresharkのパケット詳細ペインとバイト列ペインの対応で確認できる。.NETのSocketはL7のバイト列だけを渡しOSがTCP/IPヘッダーを付け、SslStreamはTCPストリームをTLSでラップし、HttpClientはL7の組み立てまで引き受ける。実務でOSI参照モデルが役立つのは、下の層から1段ずつ生存確認する障害切り分けとチーム間の共通言語としての場面である。

flowchart LR
    accTitle: OSI参照モデルとTCP/IPパケット構造の知識マップ
    accDescr: HTTPリクエストを運ぶEthernetフレームがEthernet・IPv4・TCP・HTTPの入れ子構造(カプセル化)になっていること、OSI参照モデルが実装ではなく障害切り分けの語彙として使われること、.NETのSocket・SslStream・HttpClientが各層のどこを担うかを示す図
    osi_model["OSI参照モデル"]
    tcp_ip_protocol_suite["TCP/IPプロトコルスイート"]
    osi_protocol_suite["OSIプロトコル群"]
    ethernet["Ethernet(L2)"]
    mac_address["MACアドレス"]
    arp["ARP"]
    ipv4["IPv4(L3)"]
    ttl["TTL(Time To Live)"]
    tracert["tracert"]
    tcp["TCP(L4)"]
    port_number["ポート番号"]
    http["HTTP"]
    tls["TLS"]
    dotnet_sslstream["SslStream(.NET)"]
    dotnet_socket["Socket(.NET)"]
    dotnet_httpclient["HttpClient(.NET)"]
    encapsulation["カプセル化(層のペイロード構造)"]
    wireshark["Wireshark"]
    network_layer_troubleshooting["層ごとの障害切り分け"]
    tcp_ip_protocol_suite -->|"の後継"| osi_protocol_suite
    ethernet -->|"利用する"| mac_address
    ethernet -.->|"前提とする"| arp
    ipv4 -->|"利用する"| ttl
    tracert -->|"利用する"| ttl
    tcp -->|"利用する"| port_number
    tcp -.->|"前提とする"| ipv4
    ipv4 -.->|"利用する"| ethernet
    http -.->|"利用する"| tcp
    tls -->|"利用する"| tcp
    dotnet_sslstream -->|"実装を担う"| tls
    dotnet_socket -.->|"利用する"| tcp
    dotnet_httpclient -->|"実装を担う"| http
    tcp_ip_protocol_suite -->|"利用する"| encapsulation
    encapsulation -->|"で確認できる"| wireshark
    mac_address -->|"で確認できる"| arp
    osi_model -->|"推奨される対応"| network_layer_troubleshooting
    network_layer_troubleshooting -->|"利用する"| tcp
    network_layer_troubleshooting -->|"利用する"| ipv4
    network_layer_troubleshooting -->|"利用する"| http

概念間の関係(全20件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• TCP/IPプロトコルスイートはOSIプロトコル群の後継に当たります。1990年代の普及競争で先に動くものがあったTCP/IPが事実上の標準になり、OSIプロトコル自体はほぼ使われないまま終わった / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Ethernet(L2)はMACアドレスを利用します。Ethernetヘッダーは宛先・送信元にMACアドレスを使い、同じセグメント内の隣接ノードまでフレームを届ける / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Ethernet(L2)はARPを前提とします。IPv4アドレス宛にEthernetフレームを送出する場合、宛先MACアドレスが未知であればそれを解決する手段が必要で、IPアドレスから隣接ノードのMACアドレスを引くのがARPである。IPv6ではARPの代わりにNDPが使われ、MACが既知の場合やIP以外の積み荷ではARPは介さない / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• IPv4(L3)はTTL(Time To Live)を利用します。IPv4ヘッダーはTTLフィールドを持ち、ルーターを1つ越えるたびに1ずつ減って0になると破棄される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• tracertはTTL(Time To Live)を利用します。tracertはTTLを1、2、3…とわざと増やしながら送ることで、途中のルーターを1つずつあぶり出す / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• TCP(L4)はポート番号を利用します。TCPはポート番号を使って、届いたホスト内のどのプロセス(のソケット)にデータを渡すかを振り分ける / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• TCP(L4)はIPv4(L3)を前提とします。IPv4上でTCPを使う場合、TCPのチェックサムはTCPセグメント単体ではなく送信元・宛先IPアドレスを並べた擬似ヘッダーを先頭に付けて計算すると定義されている。IPv6上のTCPではIPv6用の擬似ヘッダーが使われ、ipv4への依存ではない / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• IPv4(L3)はEthernet(L2)を利用します。IPv4はPPPやWi-Fiなど他のリンク層でも運ばれるが、本記事が例示するEthernetのリンクでは、IPv4パケットはEthernetフレームの積み荷(ペイロード)として運ばれ、EthernetはIPv4の中身を関知しない / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• HTTPはTCP(L4)を利用します。HTTP/1.1やHTTP/2の場合、HTTPリクエストはTCPセグメントの積み荷として運ばれる。本記事のパケット解剖もHTTP/1.1 over TCPの例である。HTTP/3はUDP上のQUICを使うためTCPを介さない / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• TLSはTCP(L4)を利用します。TLSはTCPの上に確立されるプロトコルで、TCPが提供する信頼性のあるバイトストリームの上でハンドシェイクと暗号化を行う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• SslStream(.NET)はTLSの実装を担います。SslStreamは既存のストリーム(通常はTCPのNetworkStream)をラップし、TLSによる暗号化・認証の実装を担う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Socket(.NET)はTCP(L4)を利用します。SocketクラスはUDPなど他のプロトコルでも使えるが、TCPソケットとして構築した場合、アプリケーションが渡すのはL7のバイト列のみで、TCP/IPヘッダーの生成はOSのプロトコルスタックが行う / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• HttpClient(.NET)はHTTPの実装を担います。HttpClientを使えばHTTPリクエストの組み立てまで含めてライブラリに任せられる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• TCP/IPプロトコルスイートはカプセル化(層のペイロード構造)を利用します。TCP/IPスタックの各層は自分のヘッダーだけを読み、内側の層の中身には関知せずそのまま上位へ渡すカプセル化の構造で動く / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• カプセル化(層のペイロード構造)はWiresharkで確認できます。各層がバイト範囲として物理的に入れ子になっていることは、Wiresharkのパケット詳細ペインとバイト列ペインの対応表示で確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• MACアドレスはARPで確認できます。IPアドレスと隣接ノードのMACアドレスの対応は、Windowsの`arp -a`コマンドで確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• OSI参照モデルは層ごとの障害切り分けに対する本記事の推奨です。OSI参照モデルが実務で本当に役立つのは、下の層から1段ずつ生存確認していく障害の切り分けと、責任分界点を短く伝えるチーム間の会話である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 層ごとの障害切り分けはTCP(L4)を利用します。L4が生きているかの確認には、相手ポートへのTCP接続を試す(Test-NetConnectionなど)手順を使う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 層ごとの障害切り分けはIPv4(L3)を利用します。L3が生きているかの確認には、ゲートウェイや相手ホストへのpingを使う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 層ごとの障害切り分けはHTTPを利用します。L7が生きているかの確認には、curlやアプリ本体からのHTTPリクエスト送信を使う / 確度: 確立した関係 / 確認日: 2026-08-01 出典

主要概念の定義

OSI参照モデル

ISOとITU-Tが定めた、通信機能を7層に分けて整理する参照モデルで、現実には実装の設計図としてではなく障害切り分けと会話のための語彙として使われている。

TCP/IPプロトコルスイート

現実のインターネットで動いている、リンク層・IP層・トランスポート層・アプリケーション層の実質4層でホストの要件を説明するプロトコル群。

Ethernet(L2)

同じネットワークセグメント内の隣接ノードまでMACアドレス宛にフレームを届ける、OSIのL2に相当する規格。

IPv4(L3)

ルーターを何段越えても最終目的地のホストまで届ける、通信の最初から最後まで変わらない宛先アドレスを持つ、OSIのL3に相当するプロトコル。

tracert

TTLを1、2、3…と増やしながらパケットを送ることで、経路上のルーターを1つずつあぶり出すWindowsの経路調査コマンド。

TCP(L4)

ポート番号でプロセスに振り分け、シーケンス番号・確認応答・再送・フロー制御によって信頼性のあるバイトストリームを提供する、OSIのL4に相当するプロトコル。

HTTP

TCPの上を流れる、OSIのL7(アプリケーション層)に相当するテキストベースのプロトコル。

TLS

TCPの上でセッションの確立・管理と暗号化を担い、OSIのL5・L6に相当する役割の多くを現実に吸収しているプロトコル。

SslStream(.NET)

既存のストリーム(通常はTCPのNetworkStream)をラップしてTLSによる暗号化・認証を提供する.NETのクラス。

Socket(.NET)

TCP/UDPのL4バイトストリームを直接扱う.NETのAPIで、渡すのはL7のペイロードのみでヘッダーの生成はOSのプロトコルスタックが担う。

HttpClient(.NET)

L7(HTTP)のリクエスト組み立てまで含めて任せられる.NETの高水準HTTPクライアントAPI。

カプセル化(層のペイロード構造)

各層が自分のヘッダーだけを読み、内側の層の中身には関知せずそのまま上位・下位へ渡す、層構造の中心的な性質。

MACアドレス

NICに割り当てられた識別子で、ルーターを越えるたびに宛先が貼り替えられる「次の1区間の相手」を指す宛名。

層ごとの障害切り分け

リンクランプの目視からping・TCP接続確認・HTTPリクエストまで、下の層から1段ずつ生存確認して原因の層を絞り込む手法。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。