TCP送信バッファをフラッシュするための保証はありますか？冷凍庫サブシステムcgroup をフリーズしますか?
次のシナリオを考えてみましょう。cgroup で実行されているサーバー A が、TCP 経由でサーバー B にデータを送信します。TCP ソケットは Naggle のアルゴリズムを使用するように設定されています (オプションはTCP_NODELAY設定されていません)。したがって、sendソケット経由でのデータ送信はサーバー B の ACK をブロックせず、送信データが TCP 送信バッファにコピーされた後に戻ります。その後、データがサーバー B に送信されるまで、cgroup はフリーズされます。
TCP 送信バッファ内のデータはどうなるのでしょうか?
- フリーズ操作は、バッファ内のすべてのデータがサーバ B によって確認されるまで待機しますか? サーバ B の受信バッファがいっぱいの場合はどうなりますか? フリーズは、サーバ B の確認応答を無期限に待機しますか?
- フリーズは、cgroup が解凍された後も、サーバー B の ACK を待たずにデータを送信し続けますか? フリーズと解凍の間の遅延がサーバー B が TCP 接続を閉じるのに十分長い場合、バッファー内のデータは失われます。
その動作に関する仕様と保証へのリンクはありがたいです。しかし、保証がないので、どちらかの動作に依存するのは脆弱ではないでしょうか?
質問の背景にあるのは、AWS Lambda で TCP 経由でデータを送信するときにどの程度注意する必要があるのかということです (AWS Lambda は Lambda 呼び出しが処理される前/後に cgroup を使用してフリーズ/解凍を行うと想定しています)。アプリケーション バッファーを TCP ソケット/TCP 送信バッファーにフラッシュするだけで十分でしょうか。それとも、たとえば HTTP を使用してサーバーの HTTP 応答を待つなどして、サーバー B がアプリケーション層でデータを受信したことを確認する必要がありますか。