OSI参照モデル入門 ── パケット1個の解剖で7層をイメージする

OSI参照モデルは、ネットワークの入門書なら必ず最初に出てくるのに、「7層の名前は言えるけれど、正直イメージが湧かない」という声をよく聞きます。物理層・データリンク層・ネットワーク層……と暗記はしたものの、自分が書いているC#のコードや、目の前で起きている通信障害と、あの7段の図がどう結びつくのかが分からないままになりがちです。

当ブログではこれまで、TCPでSendした単位ごとにReceiveできるという誤解やTCP再送で産業用カメラ通信が止まる原因と切り分けなど、L4(トランスポート層)のふるまいを扱った記事を書いてきましたが、その土台になる「層」という考え方そのものをまとめた記事がありませんでした。

この記事のアプローチはシンプルです。HTTP GETリクエスト1個を運ぶEthernetフレームを実際に1個作って、外側から順に解剖します。 7層は概念図の中だけの話ではなく、ネットワークを流れる171バイトの中に物理的に入れ子になって存在します。それをヘックスダンプとWiresharkで自分の目で見てしまえば、OSI参照モデルは暗記の対象ではなくなります。

この記事に登場するコードは、ビルド・実行できるサンプル一式(フレームの組み立て・解剖ライブラリ、Wiresharkで開けるpcapの書き出し、ユニットテスト)としてGitHubで公開しています。

osi-model-packet-anatomy - komurasoft-blog-samples (GitHub)

1. まず結論

OSI参照モデルは「実装」ではなく「語彙」です。 現実のインターネットで動いているのはTCP/IPプロトコルスイート(実質4層)であり、OSIの7層プロトコルそのものは普及競争に敗れて使われていません。生き残ったのは「L2で切り分ける」「L7の問題だ」という共通言語としてのモデルです。¹²
7層はバイト列として物理的に入れ子になっています。 HTTP GETを運ぶフレームなら、先頭14バイトがEthernetヘッダー(L2)、次の20バイトがIPv4ヘッダー(L3)、次の20バイトがTCPヘッダー(L4)、残りがHTTPのテキスト(L7)です。各層のヘッダーが前の層の直後から始まる様子は、本文のヘックスダンプとWiresharkでそのまま確認できます。
あなたのC#コードが直接書いているのはL7のバイト列だけです。 Socket.Send に渡すのはアプリケーションデータのみで、TCP・IPヘッダーはOSのプロトコルスタックが、Ethernetヘッダーと電気信号はNIC側が付けます。だからこそHttpClient / SslStream / Socketのどれを使うかは「どの層から下をOSに任せるか」の選択になります。³
L5(セッション層)・L6(プレゼンテーション層)は、現実のスタックには独立した層として存在しません。 TLSや文字エンコーディングがその役割の一部を担っていますが、TCP/IPモデルではまとめてアプリケーション層です。「L6が何のことか分からない」のはあなたのせいではなく、モデルと現実がズレている場所だからです。²
OSIモデルが実務で本当に役立つのは、障害の切り分けと会話のときです。「pingは通るのにHTTPが失敗する」ならL3までは生きているのでL4以上を疑う、という層の語彙での絞り込みは、ネットワーク・インフラ・アプリ開発者の間で通じる共通言語になります。

2. なぜOSI参照モデルは暗記で終わるのか

多くの解説がこういう表から始まります。

層	名前	説明
L7	アプリケーション層	アプリケーションに通信サービスを提供する
L6	プレゼンテーション層	データの表現形式を変換する
L5	セッション層	通信の開始・終了を管理する
L4	トランスポート層	信頼性のあるデータ転送を提供する
L3	ネットワーク層	経路選択とアドレッシングを行う
L2	データリンク層	隣接ノード間のデータ転送を行う
L1	物理層	ビットを電気信号に変換する

この表は正しいのですが、すべての行が抽象的な言葉で書かれているため、読んでも像を結びません。「データの表現形式を変換する」と言われて、自分のコードのどの行のことなのか分かる人はいないでしょう。

もうひとつ、率直に書いておくべき歴史的事実があります。OSI参照モデルはISO(国際標準化機構)とITU-Tが定めた標準(ISO/IEC 7498-1、ITU-T X.200)で、本来は7層それぞれに対応するOSIプロトコル群とセットの壮大な構想でした。¹ しかし1990年代の普及競争で、先に動くものがあったTCP/IPが事実上の標準になり、OSIプロトコル自体はほぼ使われないまま終わりました。インターネットの基礎を定めたRFC 1122は、リンク層・インターネット層(IP)・トランスポート層・アプリケーション層という実質4層で世界を説明しており、L5・L6に相当する独立した層はありません。²

つまり、いま私たちがOSI参照モデルを学ぶ意味は「この通りに実装されているから」ではなく、「層で考える」という道具と、障害切り分けの共通語彙を手に入れるためです。この前提に立つと、「L5とL6の実物が見つからない」ことに悩む必要がなくなり、一気に見通しがよくなります。

3. 本題:HTTPリクエスト1個を解剖する

前置きはここまでにして、実物を見ます。次のヘックスダンプは、GET /index.html HTTP/1.1 というHTTPリクエスト1個を運ぶEthernetフレーム(全171バイト)です。冒頭で紹介したサンプルコードが組み立てたもので、IPv4ヘッダーチェックサムもTCPチェックサムも正しく計算してあるため、Wiresharkに読ませても正常なパケットとして表示されます。

02 00 00 00 00 01 02 00  00 00 00 02 08 00 45 00  ..............E.
00 9d 12 34 40 00 40 06  3b 99 c0 00 02 0a c6 33  ...4@.@.;......3
64 50 cb 84 00 50 00 00  03 e8 00 00 07 d0 50 18  dP...P........P.
ff ff a3 05 00 00 47 45  54 20 2f 69 6e 64 65 78  ......GET /index
2e 68 74 6d 6c 20 48 54  54 50 2f 31 2e 31 0d 0a  .html HTTP/1.1..
48 6f 73 74 3a 20 65 78  61 6d 70 6c 65 2e 63 6f  Host: example.co
6d 0d 0a 55 73 65 72 2d  41 67 65 6e 74 3a 20 4b  m..User-Agent: K
6f 6d 75 72 61 53 6f 66  74 44 65 6d 6f 2f 31 2e  omuraSoftDemo/1.
30 0d 0a 41 63 63 65 70  74 3a 20 74 65 78 74 2f  0..Accept: text/
68 74 6d 6c 0d 0a 43 6f  6e 6e 65 63 74 69 6f 6e  html..Connection
00a0  3a 20 63 6c 6f 73 65 0d  0a 0d 0a                 : close....

右側のASCII表示を見ると、途中(offset 0x36)から GET /index.html HTTP/1.1 という人間が読めるテキストが始まっているのが分かります。では、その手前の54バイトは何なのか。サンプルの解剖器に食わせると、こう報告されます。

[ L2 Ethernet II | offset   0 |  14 bytes | dst=02:00:00:00:00:01 src=02:00:00:00:00:02 type=0x0800 (IPv4)
  [ L3 IPv4        | offset  14 |  20 bytes | 192.0.2.10 -> 198.51.100.80 TTL=64 proto=6 (TCP) checksum=OK
    [ L4 TCP         | offset  34 |  20 bytes | 52100 -> 80 [Psh, Ack] seq=1000 win=65535
      [ L7 HTTP        | offset  54 | 117 bytes | GET /index.html HTTP/1.1

これがこの記事で一番見てほしい図です。ポイントは3つあります。

各層は「前の層の直後」から始まっています。 Ethernetヘッダーが0〜13バイト目、IPv4ヘッダーが14〜33バイト目、TCPヘッダーが34〜53バイト目、HTTPが54バイト目から。層は概念上の分類ではなく、フレーム先頭からのバイト範囲として指させます。
内側の層は外側の層の「ペイロード(積み荷)」です。 Ethernetから見ればIPv4以降はただの積み荷で、中身がTCPかどうかは関知しません。IPから見ればTCP以降が積み荷、TCPから見ればHTTPが積み荷です。各層は自分のヘッダーだけを読み、積み荷には手を付けずに上へ渡します。この「関知しない」構造こそがカプセル化です。
L1(物理層)とL5・L6はこの図に登場しません。 L1はこのバイト列を電気信号・光・電波に変換する仕事なのでダンプには写りませんし、L5・L6は前章の通り、平文のHTTP/1.1では独立した実体がありません。「7層のうちダンプに写るのは4層」──これが現実の姿です。

繰り返しますが、これはHTTPが特別なのではありません。データベース接続でも、gRPCでも、産業用カメラのGigE Visionでも、Ethernet上のTCP/IP通信ならすべてのパケットがこの同じ入れ子構造をしています。変わるのはL7の積み荷の中身だけです。

4. L2 データリンク層 ── 「隣」まで届ける

解剖結果を外側から順に見ていきます。先頭14バイトがEthernet II ヘッダーです。

00 00 00 00 01   宛先MACアドレス(6バイト)
00 00 00 00 02   送信元MACアドレス(6バイト)
00               EtherType = 0x0800(積み荷はIPv4)

L2の仕事は「同じネットワークセグメント内の隣のノードまで届ける」ことです。宛先の指定にはMACアドレスを使います。MACアドレスはNICに割り当てられた識別子で、原則としてルーターを越えて相手に届くことはありません。オフィスのPCからWebサーバーへ送るフレームの宛先MACは、Webサーバーではなくデフォルトゲートウェイ(ルーター)のMACになります。

ここで多くの人が一度は疑問に思うのが「IPアドレスがあるのになぜMACアドレスが要るのか」です。答えは層の役割分担にあります。IPアドレスは「最終目的地」を指す住所で、MACアドレスは「次の1区間を運ぶ相手」を指す宛名です。宅配便に例えるなら、IPアドレスが送り状の届け先住所、MACアドレスは「次の中継センター」の名前です。送り状(L3)は最後まで変わりませんが、宛名(L2)は区間ごとに貼り替えられます。IPアドレスから隣接ノードのMACアドレスを調べるのがARPで、arp -a コマンドでPCが覚えている対応表を確認できます。

機器で言えば、L2を見て転送するのがスイッチ(スイッチングハブ)です。スイッチは宛先MACアドレスだけを見てポートを選び、積み荷のIPアドレスは見ません。

5. L3 ネットワーク層 ── 世界の果てまで届ける

次の20バイトがIPv4ヘッダーです。主なフィールドを抜き出します。

45          バージョン=4、ヘッダー長=5ワード(20バイト)
00 9d       全長 157バイト(IPヘッダー+TCP+HTTP。Ethernetの14バイトは含まない)
40 06       TTL=64、プロトコル=6(積み荷はTCP)
3b 99       ヘッダーチェックサム
c0 00 02 0a 送信元IP   192.0.2.10
c6 33 64 50 宛先IP     198.51.100.80

L3の仕事は「ルーターを何段越えてでも、最終目的地のホストまで届ける」ことです。L2が1区間(1ホップ)しか運ばないのに対し、L3の宛先IPアドレスは通信の最初から最後まで変わりません。ルーターは受け取ったパケットの宛先IPを見て「次はどのルーターに渡すか」を判断し、L2のヘッダーを貼り替えて送り出します。

TTL(Time To Live)は、この「ルーターを越える」動きを目に見せてくれるフィールドです。ルーターを1つ越えるたびに1ずつ減り、0になったパケットは破棄されて送信元にエラーが返ります。tracert(Windowsの経路調査コマンド)は、TTLをわざと1、2、3……と増やしながら送ることで、途中のルーターを1つずつあぶり出しています。つまり tracert の出力に並ぶ1行1行が「L3のホップ」の実物です。

6. L4 トランスポート層 ── どのプロセスに届けるか

次の20バイトがTCPヘッダーです。

cb 84       送信元ポート 52100
00 50       宛先ポート 80
00 00 03 e8 シーケンス番号
00 00 07 d0 確認応答番号
50 18       ヘッダー長=5ワード、フラグ [PSH, ACK]
ff ff       ウィンドウサイズ
a3 05       チェックサム

L3まででパケットは目的地の「ホスト(マシン)」に届きました。しかしそのマシンでは、Webサーバーもデータベースも、その他多数のプロセスも同時に通信しています。L4の仕事のひとつは、ポート番号を使って「どのプロセス(のソケット)に渡すか」を振り分けることです。宛先ポート80は「HTTPサーバーが待ち受けている番号」という慣習で、OSはこの番号を見て該当プロセスの受信バッファーにデータを積みます。

TCPのもうひとつの大仕事が、シーケンス番号・確認応答・再送・フロー制御による「信頼性のあるバイトストリーム」の提供です。⁴ このあたりのふるまいと付き合い方は、それぞれ1本の記事になる深さなので、TCPのメッセージ境界の話とTCP再送の話に譲ります。ここでは「L4から上は、もうネットワークの形をしておらず、プロセスとプロセスをつなぐパイプに見える」という感覚をつかんでください。

ひとつ、モデルの理想と現実のズレを示す面白い事実があります。TCPのチェックサムは、TCPセグメント単体ではなく、L3の情報(送信元・宛先IPアドレス)を並べた「擬似ヘッダー」を先頭に付けて計算すると定義されています。⁴ 層がきれいに独立しているなら、L4の計算にL3のアドレスが混ざるはずはありません。OSI参照モデルはあくまで整理のための地図であって、現実のプロトコルは必要に応じて層をまたぐ、という好例です。

7. L5・L6 ── モデルと現実がズレる場所

さて、解剖図にはL5(セッション層)・L6(プレゼンテーション層)がありませんでした。ここが「OSIが分からない」と感じる最大の原因なので、はっきり書きます。

L5・L6は、現実のTCP/IPスタックには独立した層として存在しません。 RFC 1122のインターネットモデルでは、TCPより上はすべて「アプリケーション層」です。² OSIモデルが想定した役割は、現実には次のように散らばって吸収されています。

OSIの想定	現実に吸収した場所の例
L5: 対話(セッション)の確立・管理	TLSのセッション・ハンドシェイク、HTTPのCookie/トークン、アプリ自身のログイン管理
L6: データ表現の変換・暗号化	TLSによる暗号化、文字エンコーディング(UTF-8)、JSONなどのシリアライズ形式

たとえばHTTPSの場合、TCP(L4)の上にTLSが挟まり、HTTPはその中を流れます。「TLSは何層か?」は試験問題にしたくなるところですが、正解を1つに決めることに実務上の意味はありません。L4の上でL7の下、セッション管理(L5的役割)と暗号化(L6的役割)を併せ持つ ── そう説明できることのほうが、「L6です」と即答できることより重要です。

.NETのコードでは、この関係がそのままクラスの重ね方に現れます。TcpClient.GetStream() で得たL4のストリームを SslStream でラップすると、Write した平文はTLSレコードに暗号化されてからTCPに渡ります。⁵

using var client = new TcpClient("example.com", 443);
// L4のバイトストリームを、TLS(L5/L6相当)でラップする
using var ssl = new SslStream(client.GetStream());
await ssl.AuthenticateAsClientAsync("example.com");
// ここに書くのはL7(HTTP)の平文。暗号化はSslStreamの仕事
await ssl.WriteAsync(Encoding.ASCII.GetBytes("GET / HTTP/1.1\r\n..."));

ストリームをストリームでラップするこの構図は、カプセル化のコード版です。Wiresharkで443番ポートの通信を見ると、TCPペイロードが Application Data という不透明な塊にしか見えなくなっており、「L7がL6相当の包みに入った」ことを逆方向から確認できます。

8. あなたのC#コードはどの層を触っているのか

ここまでを、Windowsアプリ開発者の道具に対応付けます。

層	実物の例	.NET APIの例	誰がヘッダーを付けるか
L7 アプリケーション	HTTP、gRPC、独自プロトコル	`HttpClient`、`Grpc.Net.Client`、自作の電文組み立て	あなたのコード / ライブラリ
(L5/L6相当)	TLS、シリアライズ、文字コード	`SslStream`、`JsonSerializer`、`Encoding`	ライブラリ
L4 トランスポート	TCP、UDP	`Socket`、`TcpClient`、`UdpClient`(ヘッダー生成はOS)	OSのプロトコルスタック
L3 ネットワーク	IP、ルーティング、ICMP	`Ping`、`NetworkInterface`(参照のみ)	OSのプロトコルスタック
L2 データリンク	Ethernet、Wi-Fi、ARP	(通常のアプリからは直接触れない)	NICドライバー / NIC
L1 物理	電気信号、光、電波	──	NIC / ケーブル / 空間

この表から2つのことが読み取れます。

第一に、APIの選択は「どの層から下を任せるか」の選択です。 HttpClient を使えばL7の組み立てまで任せられ、Socket を使うならL7は全部自分で書くことになります。逆に、通常のWindowsアプリからL3以下を直接操作することはほぼありません(rawソケットは管理者権限や強い制約が付きます)。

第二に、Socket.Send に渡しているのはL7のバイト列「だけ」です。 サンプルのPart 2はループバックで実際にHTTPリクエストを送るデモですが、アプリケーションが用意するのは60バイトのHTTPテキストのみで、第3章で見た54バイト分のヘッダー群はOSとNICが付けています。あなたのアプリのネットワークコードは、実は7層のうち一番内側の積み荷を作る仕事しかしていない ── これがOSIモデルとあなたのコードの正確な位置関係です。

using var socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
await socket.ConnectAsync(IPAddress.Loopback, port);

byte[] request = Encoding.ASCII.GetBytes(
    $"GET / HTTP/1.1\r\nHost: localhost:{port}\r\nConnection: close\r\n\r\n");

// 渡すのはL7のバイト列だけ。TCP/IP/Ethernetのヘッダーは
// この呼び出しの向こう側(OSとNIC)で付けられる
int sent = await socket.SendAsync(request);

9. 手を動かす ── フレームを組み立てて、Wiresharkで開く

「読んで分かった」を「見て分かった」にするために、サンプルコードの動かし方を紹介します。

サンプルの中心は、第3章のフレームをL7からL2へ包んでいく順序どおりに組み立てる SampleFrameBuilder です。送信時に各層で何が起きるかが、そのままメソッドの並びになっています。

public static byte[] BuildHttpGetFrame()
{
    // L7: アプリケーションが Send に渡すのはこのバイト列「だけ」
    byte[] http = Encoding.ASCII.GetBytes(HttpRequest);

    // L4: OS のプロトコルスタックが TCP ヘッダーを前置する
    byte[] tcp = WrapInTcp(http);

    // L3: さらに IPv4 ヘッダーを前置する
    byte[] ip = WrapInIpv4(tcp);

    // L2: NIC ドライバーの手前で Ethernet ヘッダーを前置する
    return WrapInEthernet(ip);
}

デモを実行すると、ヘックスダンプと入れ子ビューの表示に加えて、このフレームをpcapファイルとして書き出します。

dotnet run --project samples/Demo

生成された sample-http-get.pcap をWiresharkで開いてみてください。⁶ 中央のペインに Ethernet II / Internet Protocol Version 4 / Transmission Control Protocol / Hypertext Transfer Protocol の4行が縦に並び、どれかをクリックすると下のヘックスダンプの該当バイト範囲だけがハイライトされます。第3章の入れ子ビューと同じものを、業界標準のツールが表示してくれるわけです。ここまで確認できたら、次は実トラフィックです。Wiresharkでキャプチャを開始し、フィルターに tcp.port == 443 あたりを入れてブラウザーでどこかのサイトを開けば、本物の通信が全部この入れ子でできていることを確認できます。

なお、解剖器側(PacketDissector)の実装にも実務的な学びどころを仕込んであります。たとえばIPv4の積み荷を切り出すとき、受信バッファーの残り全部ではなくヘッダーのTotalLengthフィールドを信頼して切り出す必要があります。Ethernetには最小フレーム長(60バイト)があり、短いパケットには意味のないパディングが末尾に付くためです。「外側の層の都合(パディング)を、内側の層の長さ情報で取り除く」── これも層の役割分担が実装に現れる一例で、ユニットテストで検証しています。

10. 実務でOSIモデルを使う ── 層の語彙で切り分ける

冒頭で「OSIは語彙として生き残った」と書きました。その語彙が実際に役立つ場面を2つ挙げます。

障害の切り分け。「サーバーにつながらない」という報告は、層の語彙に翻訳すると系統的に絞り込めます。下から順に確認するのが定石です。

確認	使うもの	生きていると分かる層
リンクランプ・Wi-Fi接続表示	目視	L1〜L2
同一セグメントのゲートウェイにping	`ping 192.168.x.1`	自分の周辺のL3
相手ホストにping	`ping <相手>`	経路全体のL3
相手のポートにTCP接続	`Test-NetConnection <相手> -Port 443`	L4(+途中のファイアウォール)
HTTPリクエストを送る	`curl -v` やアプリ本体	L7(+TLS)

たとえば「pingは通るのに Test-NetConnection が失敗する」なら、L3までは健全で、L4のポートを塞ぐ何か(サービス停止、ファイアウォール、ポート番号の設定ミス)に容疑が絞られます。「TCP接続はできるのにHTTPが400を返す」なら、ネットワークではなくL7(リクエストの中身)の問題です。闇雲にケーブルを抜き差しする代わりに、どの層まで生きているかを1段ずつ確定させる ── これがOSIモデルの実務での使い方です。

会話の共通言語。「L2の問題っぽいのでスイッチのポートを見てほしい」「それはL7の話だからアプリチームに」という会話は、ネットワーク担当・インフラ担当・アプリ開発者の間で正確に通じます。層の番号は、責任分界点を短く言うための業界共通の座標です。

11. よくある誤解を訂正する

最後に、OSI参照モデルまわりでよく見かける誤解をまとめて訂正します。

「インターネットはOSIの7層で動いている」 ── 動いていません。実装されているのはTCP/IP(実質4層)で、OSIは説明と会話のための参照モデルです。²
「TCP/IPの4層とOSIの7層はきれいに対応する」 ── L5〜L7の対応は本質的に曖昧です。「TCP/IPのアプリケーション層 = OSIのL5+L6+L7」という表をよく見ますが、第7章の通り、L5・L6の役割は現実にはTLSやシリアライズ形式に散らばっています。
「TLSは第6層(または第5層)のプロトコルだ」 ── 1つの層に確定させる意味はありません。L4の上、L7の下で、L5・L6相当の役割を併せ持つ、が正確な説明です。
「ポート番号を見ればプロトコルが分かる」 ── ポート80だからHTTPとは限りません。ポート番号は慣習であり、実際に何が流れているかはペイロードを見るまで分かりません。サンプルの解剖器がHTTP判定をポート番号ではなく中身の先頭文字列で行っているのはこのためです。
「スイッチはL2、ルーターはL3の機器だ」 ── 出発点としては正しいのですが、現実にはL3スイッチ、L4で振り分けるロードバランサー、L7を検査するWAFなど、複数層にまたがる機器が普通に存在します。「この機器はどの層まで読むか」で捉えるのが正確です。

12. まとめ

OSI参照モデルは実装ではなく、層で考えるための語彙。現実に動いているのはTCP/IP(実質4層)
7層は概念図ではなく、フレーム1個のバイト列の中に物理的に入れ子になっている(L2: 0〜13、L3: 14〜33、L4: 34〜53、L7: 54〜)
各層は自分のヘッダーだけを読み、積み荷(内側の層)には関知しない ── これがカプセル化
L5・L6は現実のスタックには独立して存在せず、TLSやエンコーディングが役割を吸収している
あなたのC#コードが書くのはL7のバイト列だけ。TCP/IPヘッダーはOS、EthernetはNICが付ける
実務での使い道は、下の層から1段ずつ生存確認していく障害切り分けと、チーム間の共通言語
サンプルコードでフレームを組み立ててWiresharkで開けば、この記事の内容はすべて自分の目で確認できる

参考リンク

ITU-T, X.200 : Information technology - Open Systems Interconnection - Basic Reference Model: The basic model. OSI基本参照モデルの原典(ISO/IEC 7498-1と同内容)。7層それぞれの定義について。 ↩ ↩²
IETF, RFC 1122 - Requirements for Internet Hosts – Communication Layers. インターネットのホストが実装すべき要件を定めたRFC。リンク層・IP層・トランスポート層・アプリケーション層の4層でプロトコルスイートを整理していることについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Socket Class (System.Net.Sockets). .NETにおけるソケットAPI。アプリケーションはペイロードを渡し、プロトコルヘッダーの生成はOSのプロトコルスタックが担うことについて。 ↩
IETF, RFC 9293 - Transmission Control Protocol (TCP). TCPの現行仕様。シーケンス番号・確認応答による信頼性の提供と、チェックサム計算にIPアドレスを含む擬似ヘッダーを用いることについて。 ↩ ↩²
Microsoft Learn, SslStream Class (System.Net.Security). 既存のストリーム(通常はTCPのNetworkStream)をラップしてTLSによる暗号化・認証を提供するクラスについて。 ↩
Wireshark Foundation, Wireshark User’s Guide. キャプチャファイルの開き方、パケット詳細ペインとバイト列ペインの対応表示、表示フィルターの使い方について。 ↩

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

Windowsアプリ開発

業務アプリ、装置連携、通信ツールなどの Windows ソフト開発を支援します。

サービスを見るお問い合わせ

技術相談・設計レビュー

改修方針、設計レビュー、既存資産の扱いを整理するための技術相談です。

サービスを見るお問い合わせ

著者プロフィール

記事の著者プロフィールページです。

小村豪

合同会社小村ソフト代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

プロフィールを見るお問い合わせ

公開リンク

GitHub LinkedIn X COM_BLAS COM_BigDecimal

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

1. まず結論

2. なぜOSI参照モデルは暗記で終わるのか

3. 本題:HTTPリクエスト1個を解剖する

4. L2 データリンク層 ── 「隣」まで届ける

5. L3 ネットワーク層 ── 世界の果てまで届ける

6. L4 トランスポート層 ── どのプロセスに届けるか

7. L5・L6 ── モデルと現実がズレる場所

8. あなたのC#コードはどの層を触っているのか

9. 手を動かす ── フレームを組み立てて、Wiresharkで開く

10. 実務でOSIモデルを使う ── 層の語彙で切り分ける

11. よくある誤解を訂正する

12. まとめ

関連記事

関連する相談領域

参考リンク

Windowsのセッション分離をどう理解するか ── Session 0・RDP・複数ユーザー同時実行

Windowsアプリの多重起動防止 ── 名前付きMutexと二重起動時のアクティブ化

C#からWin32 APIを安全に呼ぶ ── P/Invoke実務ガイド(DllImport / LibraryImport / CsWin32)

WinForms/WPFアプリにEntra ID認証を組み込む ── MSAL.NETとWAMブローカーの実務構成

業務アプリの日時とタイムゾーン ── DateTimeの罠からUTC保存の原則、テスト設計まで

関連トピック

Windows技術トピック

不具合調査 / 長期稼働テーマ

このテーマがつながるサービス

Windowsアプリ開発

技術相談・設計レビュー

著者プロフィール

小村豪

1. まず結論

2. なぜOSI参照モデルは暗記で終わるのか

3. 本題:HTTPリクエスト1個を解剖する

4. L2 データリンク層 ── 「隣」まで届ける

5. L3 ネットワーク層 ── 世界の果てまで届ける

6. L4 トランスポート層 ── どのプロセスに届けるか

7. L5・L6 ── モデルと現実がズレる場所

8. あなたのC#コードはどの層を触っているのか

9. 手を動かす ── フレームを組み立てて、Wiresharkで開く

10. 実務でOSIモデルを使う ── 層の語彙で切り分ける

11. よくある誤解を訂正する

12. まとめ

関連記事

関連する相談領域

参考リンク

関連する記事

関連トピック

このテーマがつながるサービス

著者プロフィール

小村 豪

小村豪