NetDiag+
회선이 바쁠 때 핑이 튀는 이유
양상은 언제나 같습니다. 아무것도 내려받지 않는 동안 지연은 정상인데, 전송이 시작되면 몇백 밀리초씩 튀어 오르고 이삼 초 뒤 다시 가라앉습니다. 통화는 끊기고 게임은 되돌아가는데, 속도 측정은 회선이 건강하다고 우깁니다. 이것이 버퍼블로트입니다 — 경로 어딘가의 대기열이 큰 전송을 비우는 동안 당신의 패킷을 붙잡고 있는 것입니다.
범인을 지목하는 세 단계
- 먼저 유휴 상태의 지연을 재십시오. 다른 무엇도 네트워크를 쓰지 않는 상태에서 안정적인 주소로 몇 초간 핑을 보내고 중앙값을 적어 둡니다. 이것이 기준선입니다 — 이것이 없으면 두 번째 숫자는 아무 의미가 없습니다.
- 부하를 걸고 다시 재십시오. 내려받기로, 이어서 올리기로 회선을 포화시키고 그 내내 핑을 계속 보냅니다. 기준선 위로 올라간 값이 바로 버퍼블로트입니다. 30 ms 아래는 건강하고, 200 ms를 넘으면 통화가 깨집니다.
- 방향을 읽으십시오. 올릴 때 지연이 폭발하면 범인은 집에 있는 공유기나 모뎀의 버퍼입니다. 내려받을 때 폭발하면 대기열은 통신사 장비에 있습니다. 해법은 완전히 다릅니다.
무료 · 25가지 도구 · 한 번 구매로 광고 제거 · 구독 없음
사람들이 실제로 묻는 것
속도 측정은 500 Mbps인데 왜 여전히 튀나요?
속도 측정은 빈 관으로 데이터가 얼마나 지나가는지를 재지, 관이 꽉 찼을 때 한 패킷이 얼마나 기다리는지를 재지 않습니다. 대역폭과 부하 상태 지연은 다른 측정이며, 영상 통화가 버틸지를 예측하는 것은 후자뿐입니다.
공유기 잘못인가요, 통신사 잘못인가요?
방향이 알려 줍니다. 올리기 쪽 팽창은 거의 언제나 내 공유기나 모뎀의 버퍼입니다. 다음에 무엇을 보낼지 결정하는 장치가 그것이기 때문입니다. 내려받기 쪽 팽창은 통신사 장비에 있습니다. 무엇을 보낼지 그쪽에서 정하기 때문입니다.
통신사는 왜 아무 문제 없다고 하나요?
그들의 시험은 회선을 봅니다. 신호 세기, 오류 카운터, 처리량입니다. 대기열이 300 ms의 지연을 더하는 동안에도 그 모두가 완벽할 수 있습니다. 떠넘기는 것이 아니라, 다른 것을 재고 있는 것입니다.
직접 고칠 수 있나요?
팽창이 올리기 쪽이라면 보통 가능합니다. 공유기에서 SQM, QoS 또는 fq_codel을 켜고 업로드를 회선 속도의 90 % 정도로 제한하십시오. 짧은 대기열을 얻기 위해 약간의 대역폭을 내주는 의도적인 거래입니다. 내려받기 쪽 팽창은 회선 속도보다 낮게 조절해 완화하는 것만 가능합니다.
휴대폰은 깨끗한데 PC는 계속 튑니다. 이제 무엇을 하죠?
그렇다면 네트워크는 무죄이고 결함은 그 기계 안에 있습니다. 첫 용의자는 네트워크 어댑터 드라이버입니다. 운영체제에 딸려 오는 범용 드라이버는 과도하게 큰 전송 버퍼를 가지고 대기열 관리가 없어, 바로 이런 급등을 만들어 냅니다. VPN 클라이언트나 보안 제품도 같은 일을 할 수 있습니다.
겉으로 건강해 보이는 연결을 조용히 망치는 것이 버퍼블로트만은 아닙니다. 다음: 실제 Path MTU를 찾는 방법 →