공유기, 통신사 사이 연결 구간, 데이터센터 회선처럼 가장 좁은 곳의 대기열이 가득 차면 새로 오는 패킷을 버립니다.
왜 영상·다운로드·다른 사용자 트래픽으로 병목 구간이 꽉 참 → 그러면 대기열이 찬 동안 새로 도착하는 패킷이 연달아 버려짐(tail drop). 버려지지 않은 패킷도 꽉 찬 대기열 끝에서 기다림 → 화면에서는 여러 패킷이 한꺼번에 사라져 긴 멈춤 뒤 몰아치기, 저녁 시간에 잦음
손실이 몰리거나 핑이 급등하면 화면에 네트워크 상태 표시(같은 회선의 대용량 전송 가능성 안내).
인프라팀 할 일
데이터센터 회선 여유 확보, 우리 회선·스위치 포트의 대기열 폐기(output drops) 카운터 확인, 통신사 구간이 막히면 다른 회선·피어링으로 우회.
외부 할 일
유저에게 공유기 SQM(fq_codel, CAKE)과 ECN 사용 안내(대기열이 넘치기 전에 속도를 줄이게 함), 통신사에 병목 구간 증설 요청.
수치 감각
대기열이 넘치는 순간에는 수십 ms 동안 들어오는 패킷의 상당수가 한꺼번에 사라집니다. 연달아 잃고 다시 보낸 것까지 잃기 쉬워 RTO까지 가는 경우가 많습니다.
그래프에서는
특정 시간대에만 높음 · 재전송률, RTT(핑)
확인할 곳
서버 재전송률(nstat을 1분 간격으로 실행한 TcpRetransSegs ÷ TcpOutSegs 증가분)과 연결별 RTT를 지역·통신사·시간대별로 나눠 보고, 우리 회선·스위치 포트의 출력 폐기(ifOutDiscards)를 함께 봄. 문제 지역으로 피크 시간과 한가한 시간에 mtr을 떠서 비교함
이러면 맞음
저녁 피크에만 재전송률이 오르고 손실 직전에 RTT가 먼저 오름(대기열이 차는 모습). mtr에서 피크 시간에만 어느 구간부터 끝까지 손실과 지연이 함께 늘어남
이러면 아님
손실 직전에 RTT가 오르지 않으면 “폴리서의 초과분 폐기”. 시간대와 상관없이 늘 비슷하게 잃으면 “물리 오류”나 “경로 변경·ECMP 불량 경로”