☰

Linux では、カーネルとユーザー空間の間に構成可能なソケット タイムアウトがありますか?

tag-icon • tag-icon linux socket
Linux では、カーネルとユーザー空間の間に構成可能なソケット タイムアウトがありますか?

私は現在、接続を適切に受け入れない、ひどい (カスタム) サーバー ソフトウェアと格闘しています (スレッドどころかソケットに触れたことのない PHP プログラマーが Java で作成しました)。私の推測では、ソケットがクライアント スレッドで適切に受け入れられる前にスレッドが終了しているのではないかと思います。確信はありませんし、ソフトウェアは現在再実装されているため、実際にはあまり問題ではありません。古いバージョンは、新しいバージョンがオンラインになるまで実行し続けなければなりません。できるだけ信頼性が高く、古いコードベースのデバッグに時間とお金を費やす必要はありません。

このバグは、次の netstat 出力に現れます。一部の接続は、スペースを使用するためにカーネルから転送されません (これは私の解釈ですが、より適切な解釈があれば歓迎します)。

Proto Recv-Q Send-Q Local Address         Foreign Address         State       PID/Program name
tcp6     228      0 192.0.2.105:1988      46.23.248.10:7925       ESTABLISHED -               
tcp6       0      0 192.0.2.105:1988      221.130.33.37:9826      ESTABLISHED 14741/java      
tcp6       0      0 192.0.2.105:1988      46.23.248.2:5867        ESTABLISHED 14741/java      
tcp6    2677      0 192.0.2.105:1988      221.130.33.37:15688     ESTABLISHED -               
tcp6    3375      0 192.0.2.105:1988      221.130.33.36:3045      ESTABLISHED -               
tcp6   14742      0 192.0.2.105:1988      46.23.248.17:4679       ESTABLISHED -               
tcp6     774      0 192.0.2.105:1988      212.9.19.73:36064       ESTABLISHED -               
tcp6      92      0 192.0.2.105:1988      46.23.248.19:7164       ESTABLISHED -               
tcp6       0      0 192.0.2.105:1988      46.23.248.21:6322       ESTABLISHED 14741/java      
tcp6       0      0 192.0.2.105:1988      221.130.39.216:13937    ESTABLISHED 14741/java      
tcp6    3051      0 192.0.2.105:1988      211.139.145.104:31239   ESTABLISHED -               
tcp6     246      0 192.0.2.105:1988      46.23.248.10:5458       ESTABLISHED -               
tcp6     618      0 192.0.2.105:1988      212.9.19.73:20209       ESTABLISHED -               
tcp6    1041      0 192.0.2.105:1988      46.23.248.18:7424       ESTABLISHED -               
tcp6       0      0 192.0.2.105:1988      46.23.248.10:5065       ESTABLISHED 14741/java

この状況が発生してクライアントが再接続すると、クライアントは正常に動作する傾向があります。ただし、かなり長いタイムアウトが発生するまで、クライアントは自動的に再接続しません。現在のカスタム全二重プロトコルはクライアントから送信されたデータを一切確認せず、クライアントはサーバーからの定期的な受信要求を期待していないため、クライアントがデータを問題なく送信してからカーネルの受信キューがいっぱいになるまで、数日かかることがあります。サーバー (カーネル) 側では、クライアントがデータを定期的に送信するため、古いソケットを検出できるはずです。

したがって、この問題に関する私の解釈が正しいと仮定すると、私が疑問に思ったのは、ユーザー空間によってタイムリーに読み取られない場合にカーネルが RST を使用して TCP 接続をドロップ/クローズするように調整できるカーネル パラメータがあるかどうかでした。

ここで何が起こっているのかについてのより良い説明も歓迎します。

答え1

チューニングを試してみることができますTCP キープアライブはるかに短い値に変更します。デフォルトでは、キープアライブが起動するまで接続は 2 時間アイドル状態になることがあります。

実際にどの値を使用するかは、アプリケーションの機能、ユーザーの期待、またはアプリケーションとのやり取り方法によって異なります。

答え2

答えはノーだと思います。

問題のソフトウェアを交換することで問題は解決しましたが、引き続きアイデアをお待ちしています。

関連情報