☰

소유자 PID 없이 TCP 연결을 설정하는 이유는 무엇입니까?

tag-icon • tag-icon tcp netstat
소유자 PID 없이 TCP 연결을 설정하는 이유는 무엇입니까?

ss --processes그리고 (sudo를 사용하여) 둘 다 0이 아닌 값과 소유자 프로세스가 없는 로컬 포트 ​​6514에 대한 netstat --program다수의 TCP 연결을 나열합니다 (netstat 출력은 PID/명령이 있어야 하는 위치를 보여줍니다).ESTABLISHEDRecv-Q-

동일한 로컬 포트에 대해 내가 모두 소유하고 싶은 Java 기반(logstash) 애플리케이션의 소유자 PID를 표시하는 다른 설정된 TCP 연결이 있습니다(LISTENing 소켓을 소유함). 이러한 연결에는 빈 수신 대기열이 있습니다.

또한 lsof -i:6514"소유되지 않은" 설정된 TCP 연결은 전혀 나열되지 않습니다.

ss"소유되지 않은" 연결 중 하나의 원격 측에서 실행하는 것은 연결이 설정되었으며 빈 보내기 및 받기 대기열이 있다고 믿고 있음을 나타냅니다. 원격 측에서는 연결이 몇 주 동안 설정되었음을 보여줍니다. 원격 끝은 NAT 뒤에 있습니다.

이러한 "소유되지 않은" TCP 연결이 어떻게 존재하는지, 그리고 어떻게 정리되는지(있는 경우) 알고 싶습니다.

로컬 포트 ​​6514의 ss --listening소켓 에는 LISTENSend-Q가 50이고 Recv-Q가 51인 것을 볼 수 있습니다. 이것이 수신 중인 Java 프로세스가 동시 연결 제한에 도달했으며 "소유자 없음" 연결이 설정되는 원인이라고 가정할 수 있습니까?

# lsb_release -d
Description:    Ubuntu 14.04.1 LTS
# uname -irs
Linux 3.13.0-36-generic x86_64

고쳐 쓰다

netstat --program --numeric-hosts --numeric-ports --extend"소유되지 않음"을 표시하는 연결을 실행하는 사용자는 rootJava 프로세스 사용자가 아니며 Inode는 입니다 0.

Java 프로세스를 다시 시작한 지 한두 시간 후에 문제가 다시 나타났습니다. 이번에는 LISTEN 소켓 Recv-Q만 9Send-Q와 비교되며 50로컬 포트 ​​6514에 대한 총 TCP 연결 수는 21개이며 그 중 "소유되지 않은" 연결은 8개입니다.

업데이트 2

이제 LISTEN 소켓의 Recv-Q 번호가 "소유되지 않은" ESTABLISHED 연결 수와 일치한다는 것을 깨달았습니다. 이는 커널이 들어오는 연결에서 TCP SYN/SYN+ACK/ACK 핸드셰이크를 완료했지만 Java 프로세스가 아직 이를 호출하지 않았음을 의미한다고 생각합니다 accept().

제가 이해한 것이 맞다면 애플리케이션이 새로운 연결을 허용하지 않는 이유를 조사해야 합니다.

답변1

logstash문제의 범위를 JRuby의 SSL 구현 사용, 두 개의 서로 다른 Logstash 플러그인, 두 개의 서로 다른 Java 버전, 서로 다른 시스템, 서로 다른 클라이언트 사용, 중간 TCP 작동 유무에 따라 좁혔습니다 .

모든 경우에 Ruby 코드를 SSLServer으로 바꾸고 TCPServerLogstash 전에 TLS 오프로드를 수행하면 문제가 해결되었습니다.

JRuby의 SSL 구현과 관련된 근본적인 문제나 Logstash 컨텍스트에서 SSL이 사용되는 방식은 아직 해결되지 않았습니다.

영향을 받는 각 Logstash 플러그인의 문제:

관련 정보