netstat -o
출력에 일부 타이머 정보가 포함되어 있지만 열의 어느 곳에서도 출력에 대한 설명을 찾지 못했습니다 Timer
.
누구든지 이것을 설명하거나 설명을 지적할 수 있습니까?
이것은 netstat -o의 출력과 다릅니다(Ubuntu 8.04에서).
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State Timer
tcp 0 0 192.168.22.1:443 111.111.11.210:5804 ESTABLISHEDkeepalive (6176.47/0/0)
tcp 0 0 192.168.22.1:443 192.168.22.253:48379 TIME_WAIT timewait (36.57/0/0)
tcp 0 924 192.168.22.1:47763 10.9.169.60:443 ESTABLISHEDon (0.34/0/0)
tcp 0 0 192.168.22.1:443 192.168.111.99:4059 ESTABLISHEDkeepalive (6963.60/0/0)
tcp 0 0 192.168.22.1:443 192.168.111.74:1729 ESTABLISHEDkeepalive (1393.60/0/0)
tcp 0 0 192.168.56.1:42204 10.9.169.60:443 ESTABLISHEDoff (0.00/0/0)
tcp 0 0 192.168.56.1:42207 10.9.169.60:443 ESTABLISHEDoff (0.00/0/0)
tcp 0 940 192.168.22.1:42186 10.9.169.60:443 ESTABLISHEDon (0.28/0/0)
tcp 0 0 192.168.22.1:443 192.168.22.253:48367 TIME_WAIT timewait (31.57/0/0)
tcp 0 0 192.168.22.1:42234 10.9.169.60:443 ESTABLISHEDoff (0.00/0/0)
tcp 0 0 192.168.22.1:42209 10.9.169.60:443 ESTABLISHEDoff (0.00/0/0)
답변1
첫 번째 숫자는 분명히 카운트다운 타이머입니다. 상태 유형에 따라 타이머 시간이 초과되면 다시 시도하고 다른 FIN이나 필요한 패킷을 보내 다시 시도합니다. 따라서 두 번째 숫자는 재시도 횟수를 추적합니다. TCP에는 트래픽 상황이 있을 경우를 대비한 백오프 타이머가 있으므로 타이머가 증가합니다. 백오프 타이머는 지나치게 빈번한 재시도를 방지합니다. 실패할 때마다 백오프가 점점 더 커집니다. 백오프는 TCP 스택에 따라 기하급수적으로 증가하거나 선형적으로 증가할 수 있습니다. 3개의 숫자가 무엇인지는 알 수 없습니다. 내 디스플레이에서는 항상 0입니다.
답변2
타이머 열에는 위의 o/p에 있는 두 개의 필드가 있습니다.
keepalive (6176.47/0/0)
<1st field> <2nd field>
값 1st field
은 다음과 같습니다.
keepalive
- 소켓에 대해 Keepalive 타이머가 ON일 때
on
- 소켓에 대해 재전송 타이머가 ON일 때
off
- 위의 어느 것도 ON이 아닙니다.
에는 2nd field
세 가지 하위 필드가 있습니다.
(6176.47/0/0) -> (a/b/c)
a
= 타이머 값(a=keepalive 타이머, 첫 번째 필드="keepalive"일 때; a=재전송 타이머, 첫 번째 필드="on"일 때)
b
= 발생한 재전송 횟수
c
= 전송된 keepalive 프로브 수
예를 들어, 클라이언트와 서버 사이에 두 개의 소켓이 열려 있었습니다(루프백 아님). 연결 유지 설정은 다음과 같습니다.
KEEPALIVE_IDLETIME 30
KEEPALIVE_NUMPROBES 4
KEEPALIVE_INTVL 10
그리고 클라이언트 시스템을 종료했기 때문에 서버 측에서 netstat를 실행했고 결과는 다음과 같았습니다.
포트1:
netstat -c --timer | grep "192.0.0.1:43245 192.0.68.1:49742"
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (1.92/0/0)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (0.71/0/0)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (9.46/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (8.30/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (7.14/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (5.98/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (4.82/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (3.66/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (2.50/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (1.33/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (0.17/0/1)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (9.01/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (7.75/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (6.47/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (5.29/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (4.08/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (2.89/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (1.73/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (0.54/0/2)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (9.38/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (8.23/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (7.08/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (5.93/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (4.76/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (3.62/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (2.48/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (1.32/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (0.13/0/3)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (8.98/0/4)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (7.78/0/4)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (6.62/0/4)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (5.45/0/4)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (4.29/0/4)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (3.14/0/4)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (1.99/0/4)
tcp 0 0 192.0.0.1:43245 192.0.68.1:49742 ESTABLISHED keepalive (0.85/0/4)
위에서는 서버가 각각 10초 후에 4개의 keepalive 프로브를 보냈고 응답을 받지 못하기 때문에 전송된 프로브 수가 증가하고 4 이후에는 클라이언트와의 연결이 끊어지는 것을 볼 수 있습니다.
포트 2:
두 번째 연결의 경우 소켓은 동일했습니다. 단, 서버 측 애플리케이션이 클라이언트가 다운된 후 & keepalive가 만료되기 전에 일부 메시지를 보내려고 시도했다는 점을 제외하면 다음과 같습니다.
netstat -c --timer | grep "192.0.0.1:36483 192.0.68.1:43881"
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (8.18/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (7.00/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (5.86/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (4.71/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (3.55/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (2.40/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (1.21/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (0.05/0/1)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (8.91/0/2)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (7.75/0/2)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (6.56/0/2)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (5.39/0/2)
tcp 0 0 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED keepalive (4.14/0/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.21/2/2) // <---- retransmission timer kicks in
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.68/3/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.74/4/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.59/4/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.43/4/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.28/5/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.11/5/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.95/6/2)
. . . . .
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.65/249/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.58/250/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.48/250/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.36/250/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.26/251/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.15/251/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (3.01/252/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.92/252/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.84/252/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.72/253/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.64/253/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.55/253/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.47/254/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.39/254/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (0.31/254/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (2.19/255/2)
tcp 0 210 192.0.0.1:36483 192.0.68.1:43881 ESTABLISHED on (1.12/255/2)
보시다시피, 이 경우에는 상황이 약간 다릅니다. 클라이언트가 다운되었을 때 내 서버는 연결 유지 메시지를 보내기 시작했지만 계속 연결 유지 메시지를 보내는 동안 내 서버는 클라이언트에 메시지를 보내려고 했습니다. 클라이언트가 다운되었기 때문에 서버는 클라이언트로부터 어떠한 ACK도 받을 수 없었기 때문에 TCP 재전송이 시작되었고 서버는 데이터를 다시 보내려고 시도했으며, 매번 재전송 타이머(1번째)가 되었을 때 재전송 횟수(2번째 필드)를 증가시켰습니다. 필드)이 만료되었습니다.
이것이 netstat --timer
옵션을 잘 설명하기를 바랍니다.
답변3
첫 번째 필드:timewait/keepalive
마지막 데이터가 전송된 시점부터 다음 TCP Keepalive 프로브가 전송될 때까지의 시간(초)입니다.
기본적으로 이는 7200초에 시작되며 더 많은 데이터가 전송될 때마다 다시 재설정됩니다. 예를 들어 값이 낮은 경우 4000초는 연결 유지 연결 중 일부가 오랫동안 중단되었거나 아무 작업도 수행하지 않음을 의미합니다.
내부 프록시 또는 기타 내부 프로세스에 대한 연결이 더 오래 중단될 수 있지만 웹 기반 연결에서는 이런 일이 발생해서는 안 됩니다.