1.2OSI・TCP/IPモデルとTCP/UDP

層モデルは暗記の対象ではなく障害切り分けの地図です。「Webが遅い」という現象でも、ケーブル不良（L1）・スイッチのMACテーブル異常（L2）・ルーティング誤り（L3）・ポート遮断（L4）・DNS失敗（L7）と原因の層が異なれば対処もまったく異なります。この節では層の対応とカプセル化を押さえ、さらにTCPとUDPのどちらを使うべきかをアプリの要件から判断できるようにします。

1.2.1OSIとTCP/IPの対応

• OSI参照モデルは通信を7層に分ける：下位から物理(L1)/データリンク(L2)/ネットワーク(L3)/トランスポート(L4)/セッション(L5)/プレゼンテーション(L6)/アプリケーション(L7)。各層は直下のサービスだけを使い直上へサービスを提供するため、下位を替えても上位に影響しない（層の独立性）——これが層をまたいで障害を切り分けられる根拠になる。
• TCP/IPモデルは実務の4階層：ネットワークアクセス層(L1+L2相当)/インターネット層(L3相当)/トランスポート層(L4相当)/アプリケーション層(L5〜L7相当)。OSIの上位3層を1つにまとめるのが最大の違い。カタログの「L2スイッチ」「L3スイッチ」はこの対応で読み替える。

1.2.2カプセル化とPDU

• カプセル化＝送信側で各層が自層のヘッダ（L2はトレーラも）を付けて下位層へ渡す処理。受信側は逆に各層でヘッダを外す非カプセル化を行う。各層のデータ単位をPDUと呼び名称が異なる＝データ(L7)→セグメント(L4/TCP)/データグラム(UDP)→パケット(L3)→フレーム(L2)→ビット(L1)。
• 障害報告の言葉遣いはヒントになる：「フレームのFCSエラー」ならL2/L1、「パケットが届かない」ならL3、「特定ポートだけ繋がらない」ならL4、「名前が引けない」ならL7。症状からどの層・どのPDUの話かを即断できると切り分けが速い。

1.2.3TCPとUDPの使い分け

• TCP＝コネクション型。3ウェイハンドシェイク（SYN→SYN/ACK→ACK）で接続を確立し、順序制御・再送・フロー制御・輻輳制御で信頼性を担保する。取りこぼしが許されないWeb(HTTP/HTTPS)・メール・ファイル転送に使う。オーバーヘッドは大きい。
• UDP＝コネクションレス。ハンドシェイクや再送を行わず低遅延・低オーバーヘッド。多少の欠落より即時性が重要なDNSの問い合わせ・音声/映像(VoIP・ストリーミング)・DHCPに向く。信頼性が要るならアプリ側で補う。

あなたは社内の新しい音声通話(VoIP)システムの通信設計を任され、通話品質のクレームを調査しています。開発者は当初「取りこぼしが怖いから全部TCPで送ろう」と提案しましたが、これは要件を取り違えた判断です。VoIPはリアルタイム性が命で、パケットが1つ欠けても古い音声を再送して遅れて届けるより、欠落を捨てて次を優先したほうが会話が自然になります。TCPは順序保証と再送のために、失われたセグメントを待って後続をバッファし、再送遅延（ヘッドオブラインブロッキング）が音声の途切れや遅延を悪化させます。したがって音声メディア自体はUDP（RTP上）で送り、多少の欠落は許容するのが妥当な判断です。一方、同じシステムでも通話相手の名簿をサーバから取得する処理や設定ファイルの転送は、1バイトの欠落も許されないのでTCPが適切です。つまり「アプリ全体でTCPかUDPか」ではなく、トラフィックの性質ごとに——即時性重視のメディアはUDP、完全性重視の制御/データはTCP——と使い分けるのが正しい設計です。障害切り分けでも、VoIPが切れる症状で真っ先に疑うのは、経路上のジッタ/パケットロス（L3の品質）や、UDPの特定ポート（例：RTPのレンジ）がファイアウォールで遮断されていないか（L4）であり、闇雲にTCP化することではありません。

1.2.4この節のまとめ

• OSI7層はTCP/IP4層で上位3層(L5〜L7)がアプリケーション層に統合される。層の独立性が障害切り分けの土台
• カプセル化は各層がヘッダを付け下位へ渡す処理。PDUはデータ/セグメント/パケット/フレーム/ビットと層で異なる
• TCPは信頼性重視（Web・ファイル転送）、UDPは低遅延重視（DNS・VoIP・DHCP）。トラフィックの性質ごとに使い分ける