私は以下のクエリを持っています：TCP経由でアプリケーションレベルの再送信と確認応答が必要ですか？
1）TCPは、パケットの配送を保証します。したがって、使用されるトランスポートプロトコルがTCPの場合は、アプリケーションレベルの再送信が必要です。私はクライアントとサーバーの間にTCP接続を確立し、サーバーはクライアントにメッセージを送信します。しかし、クライアントはオフラインになり、10時間後に復帰するので、TCPスタックはクライアントに再送信とメッセージの配信を処理するか、サーバー上で実行されているアプリケーションはそれを処理する必要がありますか？
2）上記の質問に関連して、トランスポートプロトコルがTCPの場合、アプリケーションレベルのACKが必要です。アプリケーションACKの1つの理由は、アプリケーションなしでは、リモートエンドがいつメッセージを受信したかをアプリケーションが認識しないためです。それ以外の理由はありますか？意味は、メッセージ自体の配信ですか？
パケットのTCP保証配信を行い、このように使用されるトランスポートプロトコルがTCP
他端のTCPレイヤにメッセージストリームバイトのTCP保証配信であれば、これまで必要従って、アプリケーション・レベルの再送信でありますTCP接続のしたがって、アプリケーションは再送信のニュアンスを気にする必要はありません。しかし、それを絶対的なものとする前に、私の答えの残りを読んでください。
クライアントはオフラインになり、10時間後に戻ってくるので、TCPスタックはクライアントに再送信とメッセージの配信を処理するか、サーバー上で実行されるアプリケーションはそれを処理する必要がありますか？
いいえ、実際はありません。 TCPには個々のTCPパケットに対してある程度の再試行ロジックがありますが、リモートエンドポイントが切断されていると再接続を実行できません。言い換えれば、遠隔側からTCP ACKを取得し、数回再試行することを最終的に「タイムアウト」することになります。しかし、最終的にはあきらめて、リモートエンドポイント接続がデッドまたはクローズ状態になっていることをソケットインターフェイス経由でアプリケーションに通知します。典型的なパターンは、クライアントアプリケーションがサーバーへのソケット接続を失ったことを検出すると、アプリケーションのユーザーインターフェイスにエラーを報告するか、接続を再試行することです。いずれにしても、TCP接続に失敗した場合の対処方法に関するアプリケーションレベルの決定です。
は、トランスポートプロトコルは、絶対に、TCP
はいであれば、アプリケーションレベルのACKが必要です。ほとんどのクライアント - サーバープロトコルには、メッセージの要求/応答のペアという概念があります。 TCPソケットは、アプリケーションによって「送信された」データがカーネルのネットワークスタックに正常にキューイングされたかどうかをアプリケーションに示すことしかできません。これは、リモートエンドのソケットの上にあるアプリケーションが実際に "持っている"か "処理した"という保証はありません。 TCPの上にあるあなたのプロトコルは、メッセージが処理されるときにある種の応答指示を提供するはずです。ここではHTTPを例として使用します。アプリケーションがHTTP POSTメッセージをサーバーに送信するが、サーバーからの確認応答（たとえば200 OK）がなかった場合を想像してください。クライアントはサーバーが処理したことをどのように知っていますか？
ネットワークアドレス変換（NAT）とプロキシサーバーの世界では、アイドル状態（相互間のデータなし）のTCP接続は、NATまたはプロキシが実際のエンドポイントの代わりに接続を閉じるときに失敗する可能性があります。データが欠落しています。解決策は、送信するデータがない場合にアプリケーションがTCP接続を生き続けることができる、何らかの種類の定期的な「ping」および「pong」プロトコルを持つことです。