 
타 업체와 서비스 연ᇼ1; 1473; 요청 실패가 많다lj16; 문1032;를 0155;아 tcpdump Ȣ16;여 해NJ17; IP만 /196;ƾ13;Ȣ16;였lj16;데 첨ǥ12; 파1068;1012; 보시면 Retransmission 너무 많1060; 0156;견.104;Ǻ12; 문1032; 글 올리,172; .104;었습니다.
타 업체/196;ǥ12;터 2초 1060;상 1025;NJ13;1060; 없1012; ᅆ1;우 1200;7148; 1901; 요청1012; 1473;단Ȣ16;였고 그 실패율1060; 60%1221;도 라고 Ȣ16;여 Retransmission 만 필터링 해서 보니 대략 수량1060; 맞lj16; ,163; 같습니다.
대ǥ12;ǥ16; SYN 시 tcp 포트를 1116;사용 Ȣ16;였고 1060;후  RTO 1초가 1648;나면 요청 패ᓟ1;1008; 버/140;1648;lj16; ,163;1064;가요 새/196;운 seq 번호/196; 1116;요청1060; .104;나요? (TCP Retransmission 1032; seq_raw 다1020; 번호(+1)/196; ,160;색했1012; ᅆ1;우 나오1648; 않았습니다.)
아래lj16; sysctl 구성1077;니다.
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_rmem = 8192 87380 8388608
net.ipv4.tcp_wmem = 8192 87380 8388608
net.ipv4.tcp_timestamps = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
fs.file-max = 360000
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5
netstat -nao | grep "TIME_WAIT" | wc -l => 1500 ~ 2000 
ss -t | wc -l => 10000 ~ 12000
Retransmission 1012; 1460;1068; 수 1080;lj16; 0169;법1060; 1080;1012;까요?
1312;Ǻ16; ǥ12;ᓠ1;드립니다.
감사합니다.
패킷 로스가 나면 하드웨어 불량이 대부분이라고 생각합니다..
패킷 로스가 나는 구간의 장비 모델 /케이블 연결방법 /거리 /셋팅 상태 등은 어떠한가요??
그리고 장비는 대략 몇 년 된 것들인가요??
아마 IDC 나 AWS 같을 걸 쓰고 있을텐데 이 경우 하드웨어 불량이라고 보긴 어렵습니다..
+1 했을 때 seq 값이 나오지 않는 건 클라이언트 쪽에서 active close 해서 그런 걸로 추정됩니다. 그러니까 계속 새로운 seq가 재요청되고 있는 상태인거죠.
계속 새로운 세션을 만드니까 핸드쉐이크에서 1초 넘기도 하고 안 넘기도 하는데 그러면 로스율이 60퍼나 되는게 설명됩니다.
연동한 서비스가 어떤 어플리케이션인지는 모르겠지만 타 업체로부터 2초 이상 응답이 없을 경우 저희 쪽 요청을 중단하였다라는 말로 보았을 때 제가 보기엔 업체 쪽도 튜닝이 필요할 것 같습니다.
대상이 웹 서비스가 아니라 타 업체의 서비스인 경우 양쪽에서 튜닝을 잘 해줘야 합니다.
TIME_WAIT 수가 많긴 한데 Listen만 하는 서버가 저 정도 개수로 패킷로스율이 60퍼나 될 정도로 성능에 지장을 주진 않습니다.
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_tw_reuse = 1 에다
net.ipv4.tcp_tw_recycle = 1 을 추가하면 TIME_WAIT 소켓 수는 줄겠지만 패킷로스는 여전할 겁니다.
일단 RTO를 2초로 늘리면 해결은 될 겁니다. 근데 업체 쪽 서버도 TIME_WAIT 이 상당 할 텐데 잘 말해서 양쪽에서 튜닝하는게 제일 손실을 줄이고 효율적입니다.
상대 쪽에 말해보고 그게 잘 안 된다면 net.ipv4.tcp_tw_recycle = 2 InitRTO 2초로 맞춰주심 됩니다..
버려지는 세션이 가능한 없는 게 좋긴합니다..
sysctl -a | grep rto
net.ipv4.tcp_frto = 2
net.ipv4.tcp_frto_response = 0
rto 관련 변수는 2개 밖에 보이질 않네요..
박문형님 답글과 같이 양 끝단 서버 사이의 어딘가에서 패킷 손실이 발생하고 있습니다.
스위치, 방화벽, 라우터, 랜케이블 등 패킷 유실을 발생시킬 수 있는 장비는 너무 다양합니다.
진단하는 가장 쉬운 방법은 traceroute 명령을 사용하는 것입니다. 라우터 기준 구간별로 어느 구간에서 문제가 생기는지를 알려줍니다. 문제 구간이 식별되면 그 구간 담당자에게 조치 요청하세요.
구글 검색하면 자료가 많이 있으니 사용해보세요.