バックエンドサービス TCP 通信異常トラブルシューティング

ビジネスモデル:バックエンドサービスがTCPを通じてグループの行情ゲートウェイと接続します。接続ごとに、最初に権限リクエストを送信し、その後継続的にハニーポットパケットを送信して接続状態を維持します。

しかし、ある日、サービス切断警告の情報を受け取りました。詳細なログ調査の結果、バックエンドサービスは継続的にハニーポットパケットを送信していたにもかかわらず、相手からの応答が一切なく、接続自体が断続的に切断されていました。

現場要約

当初、社内プロジェクトの進捗をオフィスで作業中に、グループチャットに警報情報がポップアップした。一 glance で見ると、以前からの恒常的な問題だと思い、おそらくネットワークタイムアウトによって心拍送信が失敗し、その結果サービスが切断されたと推測した。しかし、ログの詳細な調査の結果、実際にはそうではなかったことが判明した。バックエンドで権限認証メッセージを送信したが、応答を受信せず、同時に心拍パケットは継続的に送信され続け、相手からは心拍データに対する応答が一切なかった。ログの徹底的な分析により、以下の重要な問題点が明らかになった:

  1. 権限認証メッセージへの応答なし:おそらく相手側のシステムが再起動しており、その結果権限認証メッセージがタイムリーに処理されなかった可能性がある。
  2. 権限認証失敗中に心拍パケット送信:調査の結果、これはプログラムロジック上の脆弱性であることが判明した。心拍送信関数の判断ロジックに欠陥があり、接続状態のみを検証し、権限状態の検証を省略していた。
  3. サービスが切断されなかったこと:もしサービスが切断可能であれば、再接続メカニズムをトリガーして権限認証メッセージを再送信することができた。 現在、解決すべき最後の課題は、なぜサービスが切断されなかったのかである。この問題の解決には、より詳細で精緻な調査が必要となる。

ネットワークパケットの分析

tcpdump は非常に強力なネットワークパケットキャプチャツールであり、ネットワークパケットを捕捉するために使用できます。ネットワークパケットを分析することで、通信の詳細をより直感的に理解することができます。ここでは、tcpdump を使用してネットワークパケットをキャプチャし、さらに分析します。 tcpdump 分析図のデータから、心拍が正常に送信され続けていること、相手側のサーバーが応答していないこと、そして ACK が送られていることがわかります。これにより接続は積極的に切断されません。

共通フラグの説明

TCP プロトコルにおいて、PSH (Push) と ACK (Acknowledgment) は重要なフラグであり、それぞれデータ転送の制御とフロー制御に使用されます。その機能は以下のとおりです。

1. PSH (Push Flag)

  • 機能: PSH フラグは、受信側がバッファ内のデータを上位のアプリケーションに即時送信するように要求する 役割を持ちます(バッファが満杯で待つのではなく)。 つまり、PSH フラグが付いたデータ段を受信すると、受信側はできるだけ早くそのデータをアプリケーションに処理して送信し、オペレーティングシステムのバッファに一時的に保存することはありません。
  • 典型的なシナリオ:
    • HTTP/HTTPS リクエスト: クライアントがリクエストを送信する際(例: GET /index.html)には PSH が設定され、サーバーから即時の応答を希望します。
    • SSH プロトコル: 毎回キーボード入力が発生すると PSH がトリガーされ、入力された文字をリアルタイムで転送します。
    • リアルタイム通信: ビデオストリームやオンラインゲームなど、低遅延のシナリオでは PSH を使用して遅延を減らすことがあります。
  • 注意:
    • PSH は必須ではありません。受信側はフラグを無視することもできます(ただし、データを正常に処理する必要があります)。
    • 送信側が PSH を設定しない場合、受信側は自身のバッファリング戦略に基づいてデータ送信のタイミングを決定します。

2. ACK(Acknowledgment Flag)

  • 機能ACK フラグは、前段のデータが正しく受信されたことを示す。各 ACK には確認番号(Acknowledgment Number)が含まれており、これは期待される次のバイトのシーケンス番号を表す。TCP の信頼性のある転送の中核メカニズムである。
  • 動作原理
    • 送信側がデータ段を送信すると、期待する受信側の ACK 値(例えば ACK = シーケンス番号 + データ長)を付加する。
    • 受信側がデータを受信すると、受信したデータのシーケンス番号を確認するための ACK 報文段を生成する。
    • 送信側は、対応する ACK を受信するまで再送を行わない。
    • 送信側がシリアル番号 100~199 のデータ段を送信した場合、期待される受信側の ACK200 になる。
    • 受信側が 100~199 内の特定のデータを受信しない場合、ACK=150 を通じて送信側に再送を通知する。

3. PSH と ACK の組み合わせ

TCP 報文において、PSH (Push) と ACK (確認応答) は同時に出現することがあり、以下のようなシナリオでよく見られます。

  • HTTP リクエスト応答
    クライアントが POST リクエスト(データを含む)を送信する際、PSHACK を設定し、前の応答の確認を行います。
  • SSH ハンドシェイク後のコマンド転送
    クライアントがコマンドを入力した後、PSHACK が付いたデータ段を送信することで、コマンドが即座にサーバーで処理されるようにします。

4. その他の関連を示すフラグ

フラグ 名前 概要
SYN シーケンス 接続の初期化 (3ウェイハンドシェイク)

4. その他の重要な関連

標識 名称 概要
FIN 終了 エレガントな接続のクローズ

4. その他の関連を示すフラグ

フラグ 名前 概要
RST リセット 接続の強制終了 (異常状況)

4. その他の重要な関連

標識 名称 概要
URG 緊急 緊急ポインタのマーク (ほとんど使用されない)

4. その他の関連要素

まとめ

  • PSH は、データのアプリケーション層への迅速な到達 と遅延の低減に焦点を当てています。
  • ACK は、データの信頼性の高い伝送 とパケットロスや乱数(順不同)を防ぐことに焦点を当てています。 両者は連携して、TCP プロトコルの効率性と信頼性をバランスしています。
金融ITプログラマーのいじくり回しと日常のつぶやき
Hugo で構築されています。
テーマ StackJimmy によって設計されています。