LinuxでC/Sを使用してネットワークアプリケーションを開発していますが、最近、帯域を介して大量のUDPおよびTCPデータが伝送されると、開いている接続されたソケットの書き込み/読み取りが失敗する可能性があることがわかりました。ソケットはなんらかの理由で閉鎖されました。
ここに質問があります。TCPが自動的にソケットを閉じるかどうかを教えてください。
送信者と受信者がいるとすると、送信者はTCP非ブロッキングソケットを介して受信者に大量のデータを送信します。また、アプリケーション自体や他のアプリケーションによる帯域内のトラフィックが多いとします。送信者がデータを送信する機会がない帯域幅が完全に展開されている場合、TCPはしばらくしてから自動的にソケットを閉じますか？はいの場合、時間の値はいくらですか？
問題の1のバンドウィズが完全に展開されておらず、送信者が受信者にデータを正常に配信できるとします。しかし、受信者がデータを読み取らず、しばらくしてバッファがいっぱいになった場合、TCPは数時間でソケットを自動的に閉じますか？
どんな助けでも大歓迎です!!
TCPソケットが自動的に閉じるという話は聞いたことがないので、そうは思わない。送信者がデータを送信できない場合は、待機して再試行します。ソケットが閉じる唯一の理由は、送信者がデータを数回送信しようとして、送信できず、明示的にソケットを閉じる場合です。送信者がデータを送信するのに十分な帯域幅を持っているが、受信者がデータを受信するための帯域幅を欠いている場合、プロトコル自体がデータを再送信し、データが正しく到着したことを確認します（Wikipediaを参照）。
＃2に関しては、ウィキペディアからも（ottが述べたように）：
受信者がウィンドウサイズ0をアドバタイズすると、送信者はデータの送信を停止し、永続タイマーを開始します。永続タイマーは、受信側からの後続のウィンドウサイズの更新が失われた場合に発生する可能性のあるデッドロック状況からTCPを保護するために使用され、送信側は受信側から新しいウィンドウサイズの更新を受信するまでそれ以上のデータを送信できません。永続タイマーが期限切れになると、TCP送信側は小さなパケットを送信して回復を試み、受信側が新しいウィンドウサイズを含む別の確認応答を送信して応答するようにします。
TCPには、送信するデータ量を決定するためのこのシステムが用意されているため、TCP接続は常に1つの更新パケットを受け入れることができると思います。バッファがまだいっぱいの状況では、受信者はウィンドウサイズ0をブロードキャストし続けます。Xが「0ウィンドウサイズ」を繰り返した後、ソフトウェアが明示的にソケットを閉じない限り、ソケットが閉じる理由はありません。 。
ホストのTCP実装は、長期間アクティビティがない場合でも接続をタイムアウトしない可能性がありますが（RFC 5482：TCPユーザータイムアウトオプションなど、その動作を処理および制御するためのTCPオプションが存在することに注意してください）、ほとんどのネットワーク機器（ルーター、NATボックス、ファイアウォールなど）には、アイドル接続が終了するタイムアウトポリシーがあります。一部のデバイスには、5分という短いタイムアウト値があります。
そのため、ネットワーク接続をUDPでフラッディングしている場合、同時TCP接続で単一のパケットを取得できず、ルーターが接続を終了する可能性があります。
TCPは正常に動作し、ネットワークリンクのフラッディングを防止しようとしますが、UDPはまったく気にしません。したがって、UDPトラフィックの動作を（アプリケーションまたは私のネットワーク品質管理ツールのいずれかで）制御できる場合、それはTCPトラフィックに大いに役立ちます。
私の場合（C Linux、非ブロッキングソケットのカーネル3.2）、recv関数でゼロバイトを受信したとき、および送信でエラーが発生したとき、および送信->errno=ピアによって接続がリセットされたときにソケットが自動的に閉じられます。他の場合もあると思います（プログラムがrecvおよびsend関数で特定のタイプのエラーを受信した場合）。お役に立てば幸いです。