私のクローラの実行中に奇妙なソケットの問題が発生しました。プロトコル設計により、多数のTCPソケットをすばやく開閉できます。これは私が生きなければならないことです。私はコードでソケットを正しく閉じたと確信しています（strace印刷で確認してデバッグします）。しかし、どういうわけかまだシステムのオープンソケット制限に達しました。 Netdatのようなツールでも、開いているソケットの数が増えていることがわかりました。追加検査の際。私はそこに多数のソケットファイル記述子があることを発見しました/proc/<pid>/fd/。私が実行したサンプルの結果は次のとおりです。
すべてのコマンドは次のように実行されます。root
# ls /proc/248298/fd/ -l | grep socket | wc -l
522
netstatただし、ソケットが接続されているリモートを見つけるために実行すると、システム全体のTIME_WAITとCLOSE_WAITソケットの両方が考慮されます（netstatがもはや私のプロセスに関連付けられていないため）。この数字ははるかに低いです。
# netstat -tulnap | egrep '(TIME_WAIT|CLOSE_WAIT|248298)' | wc -l
109
私はそれを緩和net.ipv4.tcp_tw_reuseに設定しようとしましたが、成功しませんでした。1
その理由は何ですか？さらに一歩進んで、閉じたソケットがまだアクティブと見なされるのはなぜですか？それともこの問題を解決する方法はありますか？
オペレーティングシステム：Linux
展開：Ubuntu 22.04
カーネル：5.15
CPU：x64
ベストアンサー1
これは一時的なポート圧力と呼ばれ、正当ではないネットワークトラフィックを含むさまざまな他のサービスへの多くの接続を作成するトラフィックが多いシステムに影響を与える可能性があります。オペレーティングシステムは、ポート範囲のRFC推奨事項と同様に、この目的のために予約されているポートが異なります（RFC 6056、RFC 6335と比較）。
Linuxで最も簡単なハンドルはこれですnet.ipv4.ip_local_port_range
。接続の多いシステムでは、できるだけ大きく設定する必要があります。
sysctl -w net.ipv4.ip_local_port_range=1024\ 65535
これにより、1024〜65535の範囲のポートを使用する他のネットワークサービス（おそらくNFS用RPC？）に問題が発生する可能性があります。あるいは、他の方法の効率をテストするために値を意図的に小さく設定することで、問題のある状態をより簡単に再現できます。
sysctl -w net.ipv4.ip_local_port_range=30000\ 30100
もちろん、これらの低い範囲は任意のサービスを中断する可能性があります。テスト仮想マシンを使用するか、テストシステムへのコンソールアクセスを提供することをお勧めします。
そうしないと、接続がさまざまな状態で費やす時間を減らすことができるさまざまなノブがあります（
FIN_WAIT*カウントがオフになる可能性がある状況を質問に記載していません）、低すぎるとリスクが高まる可能性があります。遅延または冗長パケットが発生するなど、さまざまな問題に対するリモートシステムがレート制限のためにパケットをドロップする場合、これは発生する可能性はありません。