TCPアイドルタイムアウトを設定する場合、何を考慮する必要がありますか？
[低] TCPアイドルタイムアウト）の目的は何ですか？たとえば、ファイアウォールまたはロードバランサーで60秒のタイムアウトがあるのはなぜですか？それはメモリ管理か/パフォーマンスの最適化ですか？ありますか？タイムアウトの増加に伴うセキュリティリスク
どの最大設定が適切であるか、または許容できるかをどのように決定しますか？
アイドル状態の接続が長い場合、接続が切断されている（どちらかの側でアプリケーションがクラッシュしている、ネットワークケーブルが接続されていないなど）可能性がありますが、リソースは引き続き割り当てられます。
- パフォーマンスはわずかに影響を受けます。
- アプリケーションの同時接続数はXに制限される可能性があるため、実際には接続されていない新しいクライアントへのアクセスを拒否している可能性があります。
- 送信元と宛先の両方に固定ポートを使用している場合は、クライアントを再接続できません（少し珍しいですが、可能です）。
- 接続/ルーティングの制限に達したり、他のポートへの新しい接続を妨害したり、予期しない動作やサーバー自体のクラッシュを引き起こしたりする可能性があります。
- 多くのアプリケーションは、すべての接続が適切に閉じられるまで停止しないため、サービスのシャットダウンまたは再起動には時間がかかります
- しばらくTPCトラフィックを検査するか、アプリケーションログに依存しないと、切断された接続とアクティブな接続を区別することはできません
- ほとんどのクライアントアプリケーションは、接続が切断された場合の対応方法を認識していません。内部タイムアウトを待つものもあれば、永遠に待つものもあり、クライアントを再起動する必要がある場合はデータが失われる可能性があります。
最後の1つは、TCPアイドルタイムアウトを必要以上に低く設定した場合にも発生します。これは、一部のシステムがTCPテーブルから接続を単にドロップするため、 RSTパケットを他の部分に送信します。
管理するトラフィックの種類に応じてアイドルタイムアウトを使用します（たとえば、Apacheサーバーのデフォルトタイムアウトは5分なので、5分[および数秒]以上アイドル状態になる接続はありません）がneverstablishを低く（またはまったく同じ）TCPアイドルタイムアウトをアプリケーションのタイムアウトよりも長くします。長時間の接続でキープアライブを少なくとも毎回実装します接続が生きていることを確認するために数分（ソケットの作成で定義されたTCPキープアライブのタイムアウトは2時間です。これは高すぎると考えています）ユーザー対話型ソフトウェア（sshセッション、リモートデスクトップ、FTPなど）は、数秒間アイドル状態になりますユーザーが読んでいる間は数分なので、15分もかかりません。
注：TCPアイドルタイムアウトが数分未満の場合、数秒以上アイドル状態にならない非常に集中的な接続を除いて、お勧めしません。可能であれば、以下に応じて異なるアイドル接続を設定します。トラフィック（Webサーバーでは6分、sshセッションでは15分など）。
より高いタイムアウトが必要な場合（誰かが「eternal」TCP接続を要求する）の場合、代わりにアプリケーション層でキープアライブを使用してみてください。