TCPをパケットで確認すると何が分かるのか

TCPは、Web、SSH、メール、ファイル転送、データベース通信など、 多くのアプリケーション通信の土台として使われます。

TCPでは、いきなりアプリケーションデータを送るのではなく、 基本的に最初に通信相手との接続状態を作ります。

たとえば、クライアントからサーバーのTCP/443へアクセスできない場合、 パケットを見ることで次のように切り分けられます。

今回の検証構成

今回は、PCからWebサーバーのTCP/443へ接続する通信を例にします。 実際に利用するIPアドレスは自分の環境へ読み替えてください。

ブラウザはHTTP/3などTCP以外の通信方式を使用する場合があるため、 TCP通信を確実に発生させたい検証では、curlなどでHTTP/1.1を明示すると確認しやすくなります。

curl.exe --http1.1 https://example.com/ -o NUL

WiresharkでTCP通信を取得する

1. 通信に使用しているインターフェースを確認する EthernetまたはWi-Fiなど、実際の通信が流れるインターフェースを選択します。
2. Wiresharkでキャプチャーを開始する 対象インターフェースをダブルクリックして取得を開始します。
3. TCP通信を発生させる ブラウザ、curl、SSHなどを使ってTCP通信を発生させます。
4. 表示フィルターへtcpを入力する 最初はTCPだけに絞り、対象通信を探します。
5. 対象ポートやIPアドレスでさらに絞り込む TCP/443なら tcp.port == 443 などを利用します。
6. 対象セッションだけを表示する 対象パケットを選び、TCP Stream単位で絞り込みます。

最初に使う表示フィルター

tcp

TCP/443だけを表示する場合は次のようにします。

tcp.port == 443

特定のIPアドレスとのTCP通信だけを表示する場合は、次のようにできます。

ip.addr == 203.0.113.20 && tcp

3ウェイハンドシェイクを確認する

TCP通信で最初に確認したいのが、3ウェイハンドシェイクです。

正常なTCP接続では、基本的に次の3パケットが確認できます。

1．クライアント → サーバー：SYN

クライアントは、TCP接続を開始するためにSYNフラグを設定したセグメントを送信します。

Transmission Control Protocol
    Source Port: 53124
    Destination Port: 443
    Sequence Number: 0    (relative sequence number)
    Acknowledgment Number: 0
    Flags: 0x002 (SYN)
        Syn: Set
        Acknowledgment: Not set

ここで確認するポイントは次のとおりです。

• 送信元ポートはクライアント側の一時ポート
• 宛先ポートはサーバー側の待ち受けポート
• SYNフラグが設定されている
• 最初のシーケンス番号を相手へ通知する

2．サーバー → クライアント：SYN / ACK

サーバーが接続要求を受け付けると、 SYNとACKの両方を設定したセグメントを返します。

Transmission Control Protocol
    Source Port: 443
    Destination Port: 53124
    Sequence Number: 0    (relative sequence number)
    Acknowledgment Number: 1
    Flags: 0x012 (SYN, ACK)
        Acknowledgment: Set
        Syn: Set

Ack=1は、クライアントが送信したSYNを受け取り、 次のシーケンス番号を待っていることを表します。

3．クライアント → サーバー：ACK

最後にクライアントがACKを返します。

Transmission Control Protocol
    Source Port: 53124
    Destination Port: 443
    Sequence Number: 1
    Acknowledgment Number: 1
    Flags: 0x010 (ACK)

ここまで完了すると、TCP接続は確立状態になります。

TCPヘッダーの重要項目

TCPヘッダーには多くのフィールドがありますが、 中級編ではまず次の項目を読めるようにしましょう。

よく見るTCPフラグ

SYN ACK FIN RST PSH

Sequence NumberとAck Numberを理解する

TCPパケット解析で最も混乱しやすいのが、 Sequence NumberとAcknowledgment Numberです。

500バイトのデータを送る例

クライアントがSequence Number 1から500バイトのTCPデータを送ったとします。

受信側は、Sequence Number 1から500バイト分を受信したため、 次に期待する番号は501です。

送信：
Seq = 1
Len = 500

受信側からのACK：
Ack = 501

SYNとFINもシーケンス番号を1つ消費する

SYNとFINはアプリケーションデータを持たない場合でも、 TCPのシーケンス空間上ではそれぞれ1つ分を使用します。

そのため、最初のSYNがWireshark上で相対的に Seq=0 と表示されている場合、 SYN/ACK側のAcknowledgment Numberは通常 1 になります。

データ転送とACKを確認する

3ウェイハンドシェイクが終わると、 アプリケーションデータの送受信が始まります。

この例では、クライアントが Seq=1から517バイト送っています。

サーバーは次に受け取りたい番号として Ack=518を返しています。

ACKは必ず1パケットごととは限らない

TCPでは、受信したすべてのデータセグメントに対して 必ず即座に個別ACKを返すとは限りません。

複数のデータ受信をまとめて確認応答するDelayed ACKなどの動作もあるため、 「データ1個にACK1個が存在しないから異常」と判断しないようにしてください。

FIN・ACKによるTCP切断を確認する

TCP通信が終了するときは、FINを使って接続を閉じます。

典型的には次のような流れが確認できます。

ただし、実際にはACKとFINがまとめて送信されることもあり、 必ず4パケットになるとは限りません。

FINとRSTの違い

実務で使えるWiresharkフィルター

TCP通信を調査するときに使用頻度の高い表示フィルターを整理します。

1つのTCPセッションだけを見る

Webサイトへアクセスすると複数のTCPセッションが同時に発生することがあります。 その場合は対象パケットを右クリックし、 Follow → TCP Streamを利用すると対象セッションを追いやすくなります。

Wiresharkが対象ストリームへフィルターを設定すると、 次のような形式で表示できます。

tcp.stream eq 3

TCP障害をパケットで切り分ける

TCP障害では、エラーメッセージだけを見るのではなく、 「どのパケットまで確認できたか」を整理します。

Client → Server  [SYN]


Client → Server  [TCP Retransmission] [SYN]
Client → Server  [TCP Retransmission] [SYN]

Client → Server  [SYN]


Server → Client  [RST, ACK]

Client → Server  [SYN]


Server → Client  [SYN, ACK]
Client → Server  [ACK]
Client → Server  Application Data
Server → Client  [RST, ACK]

障害調査の基本手順

1. SYNが送信されているか確認する そもそもTCP接続要求が出ているかを確認します。
2. SYN/ACKまたはRSTが返るか確認する 宛先側から何らかの応答があるかを確認します。
3. 3ウェイハンドシェイクが完了しているか確認する TCP接続確立前と確立後で調査範囲を分けます。
4. データとACKの流れを確認する Seq、Ack、Lenを見て、どこまで受信されているか確認します。
5. 再送・Duplicate ACK・Zero Window・RSTを確認する TCP解析情報から異常の特徴を探します。
6. キャプチャー位置と機器ログを照合する パケットだけで断定せず、FWログ、サーバーログ、IFカウンターなどと組み合わせます。

調査結果の報告例

【事象】
PC-AからWebサーバーのTCP/443へ接続できない。

【パケット確認結果】
PC-A（192.168.10.10）からWebサーバー宛てのSYN送信を確認。
同一SYNが再送されているが、SYN/ACKおよびRSTの応答は確認できない。

【判断】
クライアントからTCP接続要求は送信されている。
一方、TCP接続確立前の段階で応答を受信できていない。

【次の確認】
・途中FWのTCP/443許可状況
・サーバーまでのルーティング
・サーバー側の受信有無
・サーバーからクライアントへの戻り経路
・キャプチャーポイント以降のパケットロス

HTTPS通信では何が見えるのか

HTTPSでは、HTTPの内容はTLSによって暗号化されます。

しかし、TCPそのものまで見えなくなるわけではありません。

HTTPSをTCPで利用している場合でも、 Wiresharkでは次のようなTCP情報を確認できます。

• 送信元・宛先IPアドレス
• 送信元・宛先TCPポート
• SYN・ACK・FIN・RST
• Sequence Number
• Acknowledgment Number
• Window Size
• 再送などのTCP解析情報
• TCP上で交換されるTLSレコード

したがってHTTPS障害でも、 「TCP接続自体が成立しない」のか、 「TCP接続後のTLSやHTTP処理で失敗している」のかを切り分けられます。

TCPパケット解析でよくある勘違い

自分の言葉で説明する課題