ネットワークの重要な特徴の一つは、データをパケットに束ねることです。パケットは建物内や世界中を巡回し、ネットワーク上の別のノードによって分離されます。ネットワークのトラブルシューティングや分析を行う管理者やエンジニアは、プロトコルアナライザーを使ってこれらのパケットを解読し、その内容を詳しく調べることで、ネットワーク上で何が起こっているかを把握しなければならない場合があります。
本日は、ほとんどの電線（光ファイバーケーブルの場合はガラス）を流れる最も一般的な3種類のTCP/IPパケットの構造を解説します。また、よくあるパケットエラーとその典型的な原因についても説明します。
OSI参照モデルを用いたネットワークの理解
次の 2 つの記事は、OSI 参照モデルをガイドとして使用して、ネットワーク用語と概念をより深く理解するのに役立ちます。
「OSIモデルを恐れる必要はない」
「OSI参照モデルを使用してトポロジの決定を支援する」
ユーザー データグラム プロトコル (UDP)
ネットワークのトランスポート層 (OSI レイヤー 4) では、通常、次の 2 つの主要なプロトコルを使用して情報を移動します。
- UDP（ユーザーデータグラムプロトコル）はRFC 768で文書化されています。
- RFC 793に記載されているTCP（伝送制御プロトコル）
UDP や TCP/IP などのネットワーク プロトコルでは、パケットの範囲は 64 ～ 1,500 文字 (バイト)になります。
UDPは、信頼性、フロー制御、エラー回復機能を持たないコネクションレス型プロトコルです。UDPはシンプルなため、TCPよりもヘッダーバイト数が少なく、ネットワークオーバーヘッドも少なくて済みます。UDPは、上位層プロトコルがエラー制御やフロー制御を提供する場合など、TCPの信頼性メカニズムが不要な状況で役立ちます。UDPはユーザーにTCPのようなサービスを提供します。TCPとは異なり、UDPパケットは宛先に到達する前に破棄できます。UDPは、TCPが複雑すぎる、遅すぎる、あるいは単に不要な場合に役立ちます。
UDP は、ネットワーク ファイル システム (NFS - UDP ポート 1021/1022)、簡易ネットワーク管理プロトコル (SNMP - UDP ポート 161/162)、ドメイン ネーム システム (DNS - UDP ポート 53)、および簡易ファイル転送プロトコル (TFTP - UDP ポート 69) など、いくつかのよく知られたアプリケーション層プロトコルのトランスポート プロトコルです。
図 A はUDP パケット形式を示しています。
| 図A |
 |
| UDPパケット |
UDP パケット形式には 4 つのフィールドがあります。
- 送信元ポート フィールドと宛先ポート フィールド(それぞれ 16 ビット) は、接続のエンドポイントを識別します。
- 長さフィールド(16 ビット) は、ヘッダーとデータの長さを指定します。
- チェックサム フィールド(16 ビット) により、パケットの整合性チェックが可能になります (オプション)。
UDPパケット
UDPは、OSI参照モデルの上位層から受信したメッセージを受け取り、UDPパケットに変換します。送信側アプリケーションは、受信側ホスト上のピアアプリケーションにパケットを送信します。UDPは受信通知を必要とせず、3ウェイハンドシェイク（SYN-ACK-ACK。これについては後ほど詳しく説明します）も使用しません。繰り返しますが、UDPはTCPよりもはるかにシンプルなプロトコルであり、TCPのような信頼性メカニズムが不要な状況で役立ちます。
伝送制御プロトコル（TCP）
TCPは、上位層プロトコルに全二重、確認応答、フロー制御サービスを提供するコネクション指向の第4層プロトコルです。TCPは、連続した非構造化バイトストリームでデータを転送します。シーケンス番号は、ストリーム内のバイトを識別します。また、TCPは多数の同時上位層通信をサポートできます。
図 B はパケット形式を示しています。
| 図B |
 |
| TCPパケット |
TCP パケット形式は次のフィールドで構成されます。
- 送信元ポート フィールドと宛先ポート フィールド(それぞれ 16 ビット) は、接続のエンドポイントを識別します。
- シーケンス番号フィールド（32ビット）は、現在のメッセージのデータの最初のバイトに割り当てられた番号を指定します。特定の状況下では、このフィールドは、次の送信で使用される初期シーケンス番号を識別するためにも使用されます。
- 確認応答 番号フィールド（32ビット）には、ACK制御ビットがセットされている場合、セグメントの送信者が次に受信することを期待するシーケンス番号の値が含まれます。シーケンス番号はセグメントと同じ方向に流れるストリームを参照し、確認応答番号はセグメントと反対方向に流れるストリームを参照することに注意してください。
- データオフセット （別名ヘッダー長）フィールド（可変長）は、TCPヘッダーに含まれる32ビットワードの数を示します。オプションフィールドは可変長であるため、ヘッダー長も可変長であるため、この情報が必要になります。
- 予約フィールド（6ビット）は0である必要があります。これは将来使用するためのものです。
- フラグ フィールド(6 ビット) には、さまざまなフラグが含まれます。URG
- 緊急データが配置されたことを示します。ACK
- 確認応答番号が有効であることを示します。PSH
- データをできるだけ早くアプリケーションに渡す必要があることを示します。RST
- 接続をリセットします。SYN
- シーケンス番号を同期して接続を開始します。FIN
- フラグの送信者がデータの送信を完了したことを意味します。 - ウィンドウ フィールド(16 ビット) は、送信側の受信ウィンドウ (つまり、受信データに使用できるバッファ スペース) のサイズを指定します。
- チェックサム フィールド(16 ビット) は、ヘッダーが転送中に破損したかどうかを示します。
- 緊急ポインタ フィールド(16 ビット) は、パケット内の最初の緊急データ バイトを指します。
- オプション フィールド(可変長) は、さまざまな TCP オプションを指定します。
- データフィールド（可変長）には上位層の情報が含まれます。
TCPは、信頼性の高いストリーム指向の接続を提供することで、IPの欠点を補います。このプロトコルスイートの名前の由来は、ほとんどのTCP/IPプロトコルがTCPをベースとしており、TCPはIPをベースとしていることです。TCPとIPはTCP/IPの双璧を成しています。TCPはIPサービスに多くの機能を追加します。
TCPパケット：
TCPはほぼ常に全二重モード（2つの独立したバイトストリームが反対方向に流れる）で動作します。接続の開始時と終了時のみ、データは片方向に転送され、反対方向には転送されません。TCPはセグメントを使用して、受信側ホストがデータを受信する準備ができているかどうかを判断します。
送信側TCPホストが接続を確立しようとする場合、受信側ホストで動作しているピアTCPプロトコルにSYNと呼ばれるセグメントを送信します。受信側TCPは、セグメントの受信に成功したことを示すACKと呼ばれるセグメントを返します。送信側TCPは別のACKセグメントを送信し、その後データの送信を続行します。この制御情報の交換は、3ウェイハンドシェイクと呼ばれます。
TCP パケットは非常に複雑で、データ パケットの接続状態、信頼性、フロー制御を確保するためのいくつかのメカニズムが組み込まれています。
- ストリーム: TCP データは、ファイルと同様にバイトのストリームとして編成されます。
- 信頼性の高い配信：シーケンス番号は、送受信されたデータを調整するために使用されます。TCPは、データが失われたと判断した場合、再送信を手配します。
- ネットワーク適応: TCP はネットワークの遅延特性を動的に学習し、ネットワークに過負荷をかけずにスループットを最大化するように動作を調整します。
- フロー制御： TCPはデータバッファを管理し、トラフィックを調整することでバッファオーバーフローを防止します。高速な送信側は、低速な受信側に対応するために定期的に停止されます。
- 往復時間の推定: TCP はデータ パケットの交換を継続的に監視し、確認応答を受信するまでにかかる時間を推定し、この時間を超過した場合には自動的に再送信します。
インターネットプロトコル（IP）
IPは、データグラムの断片化と再構成、そしてエラー報告を提供するレイヤー3プロトコルです。TCPと並んで、IPはインターネットプロトコルスイートの中核を担っています。図CはIPパケットのフォーマットを示しています。
| 図C |
 |
| IPパケット |
IP パケット形式は次のフィールドで構成されます。
- バージョン フィールド(4 ビット) は、現在使用されている IP のバージョンを示します。
- IP ヘッダー長 (IHL) フィールド(4 ビット) は、IP ヘッダーに含まれる 32 ビット ワードの数を示します。
- サービスタイプフィールド（8ビット）は、特定の上位層プロトコルが現在のデータグラムをどのように処理するかを指定します。このフィールドを通じて、データグラムに様々な重要度レベルを割り当てることができます。
- 合計長フィールド(16 ビット) は、データとヘッダーを含む IP パケット全体の長さをバイト単位で指定します。
- 識別フィールド（16ビット）には、現在のデータグラムを識別する整数が格納されます。このフィールドは、データグラムフラグメントの再構築に役立ちます。
- フラグ フィールド(4 ビット、1 つは未使用) は、ルータがパケットを断片化できるかどうかを制御し、パケットの各部分を受信者に示します。
- TTLフィールド（8ビット）は、徐々に減少してゼロになるカウンタを保持し、ゼロに達した時点でデータグラムは破棄されます。これにより、パケットが無限ループするのを防ぎます。
- プロトコル フィールド(8 ビット) は、IP 処理が完了した後にどの上位層プロトコルが着信パケットを受信するかを示します。
- ヘッダー チェックサム フィールド(16 ビット) は、IP ヘッダーの整合性を保証するのに役立ちます。
- 送信元アドレス フィールド(32 ビット) は送信ノードを指定します。
- 宛先アドレス フィールド (32 ビット)は受信ノードを指定します。
- オプション フィールド(32 ビット) により、IP はセキュリティなどのさまざまなオプションをサポートできます。
- データフィールド（32ビット）には上位層の情報が含まれます。
IPパケット（データグラム）
IPは、 TCPまたはUDPによって追加される情報に加えて、セグメントまたはパケットのヘッダーにIPヘッダーを付加します。IPヘッダーの情報には、送信ホストと受信ホストのIPアドレス、データグラムの長さ、データグラムのシーケンス順序が含まれます。これは、データグラムがネットワークパケットの許容バイトサイズを超え、フラグメント化が必要な場合に備えて提供されます。
異なるパケット、同じ問題
ネットワークパフォーマンスの問題の追跡は、時間がかかり、非常に複雑になる場合があります。これらのパケットはすべて、フレームに変換されてネットワークを介して送信される際に、さまざまな問題が発生する可能性があります。情報が届かない最も一般的な理由をいくつか見ていきましょう。
ウィンドウ外 (遅延) 衝突
ウィンドウ外衝突は、送信開始後 51.2 マイクロ秒 (イーサネットの最大伝播遅延) を超えて、ステーションがまだ送信中に衝突信号を受信した場合に発生します。
原因:このタイプのエラーが発生する原因は2つあります。ネットワークセグメントの物理的な長さがIEEE 802.3仕様（100メートル）を超えているか、ネットワーク上のノードがキャリアセンスをリッスンせずに送信を行っている（最初のステーションが送信を開始してから51.2マイクロ秒以上経過してから不正な送信を開始している）かのいずれかです。
ジャイアンツ
ジャイアンツは、イーサネットの最大サイズである 1,518 バイト (プリアンブルを除く) よりも長いパケットです。
原因：ジャイアントパケットは通常、ネットワーク上にジャバリングノードが存在する場合に発生します。これはネットワークカードの不良を示しています。ジャバリングノードとは、NICの送信機の不良が原因で、継続的に送信したり、短時間だけ不適切に送信したりするノードのことです。ジャイアントパケットは、不要な信号の追加やフレームサイズを示すビットの破損など、送信中にパケットが破損することで発生することもあります。
不整合
不整合パケットとは、1 バイト未満のビット単位を含むパケットのことです。
原因：アライメント不良のパケットは、MAC層のパケット形成の問題、または伝送媒体（ケーブル配線）の問題によるデータの破損や損失が原因で発生することがあります。また、パケットが2台以上のカスケード接続されたマルチポートトランシーバーを通過する場合（イーサネット仕様を満たさないネットワーク設計）にも発生することがあります。アライメントパケットエラーには通常、CRCエラーも発生します。
CRC
巡回冗長検査（CRC）エラーは、パケットが伝送中に何らかの理由で破損した場合に発生します。各パケットが送信される際、送信デバイスのMAC層はパケットの内容に基づいてフレームチェックシーケンス（FCS）値を計算します。受信ステーションも同様の計算を行います。FCS値が一致しない場合、パケットは破損しているとみなされ、CRCエラーとしてカウントされます。
原因: CRC エラーは、MAC 層のハードウェアの問題によって FCS 値が不正確に計算されたり、別の伝送の問題によって元のデータが文字化けしたりすることによって発生することがあります。
ラントパケットとは、
イーサネットフレームの最小サイズである64バイト（プリアンブルを除く）よりも小さいパケットのことです。この最小サイズは、イーサネットネットワークセグメントの最大伝播時間（51.2マイクロ秒）に関係しており、64バイトのデータを送信するのに約51.2マイクロ秒かかります。そのため、セグメント上のすべてのノードは、送信が完了する前に他のノードが送信中であることを認識する必要があるため、より正確な衝突検出が可能になります。
原因：ラントは衝突によって発生する場合があり、混雑したイーサネットセグメントの自然な副産物である可能性があります。ただし、ハードウェア（パケット構成）、伝送（データ破損）、またはネットワーク設計（4台以上のリピータのカスケード接続）に問題があることを示している場合もあります。
結論
ネットワークのパフォーマンスに問題があり、解決策を見つけようとして行き詰まっている場合は、プロトコルアナライザー（パケットスニファーとも呼ばれます）を開いて、ネットワーク上のトラフィックを調べてみてください。ここで得た洞察をもとに、問題の原因についていくつかのアイデアをまとめることができるはずです。
パケットスニファーをどのくらいの頻度で使用しますか?
パケット解析のヒントをお持ちですか？このトピックに関するご意見やご経験談をお待ちしております。以下のディスカッションにご参加いただくか、編集者までメールでご連絡ください。
