OSI モデル、層ごとに、無駄な説明なし
OSI モデルの7層を実践的に解説し、各層に対応する実例のプロトコルとトラブルシューティングの観点を示します。
ネットワークの説明の多くは OSI モデルを認定試験のために暗記して忘れるチャートとして扱っています。それは間違いです。実際の問題をトラブルシューティングし始めると、7層はメンタルチェックリストになります。ケーブルの問題か、ルーティングの問題か、アプリケーションのバグか。どの層を扱っているのか知ることで、デバッグ時間は劇的に短縮されます。
Layer 1: physical
実際の媒体です。銅線、光ファイバー、電波。電圧レベル、ピン配置、コネクタタイプ(RJ45、SFP+)、信号変調がここにあります。スイッチポートが「link down」を表示するか、ケーブルの近くで誰かが掃除機をかけたときに相関する間欠的なパケット損失が発生する場合、Layer 1 の範囲です。ケーブルテスターや Linux での ethtool eth0 のようなツールは、上位でデバッグに時間を無駄にする前に、リンク状態、速度、デュプレックス設定を表示します。
Layer 2: data link
ここでは MAC アドレス、スイッチ、フレームがあります。Ethernet はこの層で動作し、ARP も動作します(技術的には L2 と L3 の間のブリッジです)。VLAN も Layer 2 の構造です。ホストが独自のサブネット上の何にも到達できないが、直接接続されている他のマシンへの ping は正常に機能する場合、arp -a または ip neigh で古いエントリをチェックし、VLAN の不一致についてスイッチポート設定を確認してください。古典的な落とし穴は、同じ VLAN 上にある 2 つのホストが異なる MTU 設定を持ち、奇妙なフラグメンテーション関連の症状を引き起こしています。
Layer 3: network
IP アドレス、ルーティング、ICMP がここにあります。ここは traceroute と ping が動作する場所であり、パケットがローカルネットワークから外に出ているかどうかを診断する場所です。ルーターはこの層で宛先 IP に基づいて転送決定を行います。ping 8.8.8.8 は機能するが ping google.com は機能しない場合、これは Layer 3 の問題ではなく、DNS である Layer 7 です。これは、障害を絞り込むときに層の規律がなぜ重要かを示す良い例です。
Layer 4: transport
TCP と UDP。ポート、シーケンシング、信頼性(または欠如)が入ってくるのはここです。TCP の 3 ウェイハンドシェイク、再送信タイマー、ウィンドウスケーリングはすべてここにあります。curl が接続試行で hang する場合、tcpdump -i eth0 port 443 は SYN パケットが SYN-ACK を取得しているかどうかを示します。応答がない場合は通常、ファイアウォールがトラフィックを明示的に拒否するのではなく、静かに破棄していることを意味します。これは、インシデントレポートを作成するときに重要な区別です。
Layer 5: session
この層は実装では薄いため悪い評判を得ています。多くの実世界のスタックはセッション管理をトランスポート層またはアプリケーション層のいずれかに折りたたみます。TLS セッション再開と NetBIOS セッションのようなものが教科書の例です。最新のアーキテクチャでは、他のどの層よりもここで時間を費やす可能性がありますが、完全な再交渉なしにドロップされた接続が再開可能な理由を説明する場合、概念的には依然として有用です。
Layer 6: presentation
エンコーディング、圧縮、暗号化フォーマットは技術的にはここに属します。文字セット、SSL/TLS 暗号化フォーマット(セッション確立自体ではなく)、データシリアライゼーションを考えてください。実際には、ほとんどのエンジニアはこれについて話すとき、層の境界があいまいであるため、これを Layer 5 または Layer 7 のいずれかに折りたたみます。ペイロード内の文字化けされた文字と破損したハンドシェイクをデバッグする場合、それが L6/L7 の分割です。
Layer 7: application
HTTP、DNS、SMTP、SSH。実際にコードを記述するプロトコル。開発者としての日常的なデバッグのほとんどはここで発生し、ステータスコード、ヘッダー、ペイロードをチェックします。ブラウザー開発ツール、Postman、curl -v はすべてこの層で動作します。API 呼び出しが失敗するとき、ネットワークを最初に責めるのは魅力的ですが、500 レスポンスは要求がすべての下位層を正常に通過したことを意味します。問題は完全にアプリケーションロジックにあります。
誰も完全に実装しないモデルにこだわる理由
実世界のネットワーキング、特に TCP/IP は、OSI の 7 層に完全にはマップされません。TCP/IP は独自の参照モデルで 4 層を持っています。この不一致は問題ありません。OSI の価値は実装仕様としてではなく、共有語彙としてあります。同僚が「これは Layer 2 の問題に見える」と言うとき、DNS レコードについて議論するのではなく、スイッチと VLAN をチェックすることをお互いにすぐに知ります。これが学習の全てです。試験のために暗記するのではなく。
この層ごとの分解があなたにクリックした場合、Korra Studio のネットワーキングセグメントはパケットキャプチャ、サブネッティングドリル、およびこの基盤の上に直接構築されるファイアウォールルールのトラブルシューティングにさらに進みます。
この記事は AI の支援を受けて執筆し、Korra Studio の Michal Pilch(CISSP)が確認のうえ公開しました。
これは Korra Studio ナレッジベースの 1 つのノートです。プラットフォームはすべてのトピックと 1 対 1 メンタリングをペアで提供します。
無料で始めるarrow_forward