☰

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

대답은 '아니요'인 것 같아요.

문제의 소프트웨어를 교체하여 문제가 해결되었지만 여전히 아이디어를 환영합니다.

관련 정보