한동안 네트워크 문제가 있어서 문제의 원인을 추적하려고 합니다.
어제 저는 Wi-Fi 연결을 통해 SCP를 사용하여 노트북에서 데스크톱으로 파일을 전송하고 있었습니다. 다운로드가 시작되었을 때 두 컴퓨터 모두 로컬 라우터(192.168.1.1, 둘 다 약 10ms-50ms)에 대한 핑이 낮았고 다운로드는 2-3MB/s로 실행되었습니다.
1분 정도 후에 192.168.1.1에 대한 데스크톱의 대기 시간이 급격히 증가하고(> 1,000ms) 전송 속도가 크롤링 속도(~200KB/s)로 느려지는 것을 발견했습니다. 그러나 192.168.1.1에 대한 노트북의 대기 시간은 동일하게 유지되었습니다(10-50ms). 전송이 완료되면 데스크톱의 대기 시간이 다시 정상 범위로 떨어졌습니다.
연결이 포화되면 분명히 문제가 발생합니다. 뭐가 될수 있었는지? 이는 라우터에 문제가 있음을 의미합니까, 아니면 내 데스크탑에 문제가 있음을 의미합니까? 찾기 시작하기에 적합한 장소는 어디입니까?
답변1
"버퍼 팽창"에 대한 Google.
RAM이 저렴해지면서 네트워킹 장비는 프레임 버퍼를 추가하여 프레임을 삭제할 필요가 없습니다.
불행하게도 프레임 드롭은 TCP가 정체를 발견하고 언제 물러날지 아는 방법이었습니다. 프레임 손실이 없으면 기존 TCP 구현은 정체를 인지하지 못하고 결코 물러서지 않으므로 계속해서 높은 속도로 전송하고 상황을 악화시킵니다.
모든 네트워킹 장비가 정체 중에 점점 더 많은 프레임을 버퍼링하고 대기열 길이를 제한 없이 늘리면 대기열을 비우는 데 시간이 점점 더 오래 걸리므로 대기 시간이 계속해서 늘어납니다.
AQM(Active Queue Management) 기술과 ECN(명시적 정체 알림)과 같은 메커니즘으로 이를 완화할 수 있지만 문제가 잘 알려져 있지 않기 때문에 어떤 제품이 버퍼 팽창을 피하고 어떤 제품이 그렇지 않은지 알기가 어렵습니다. "버퍼 팽창 없음!"을 찾을 수 있는 것과는 다릅니다. 상자 측면에 로고가 있으면 좋은 장비를 구입했다는 것을 알 수 있습니다.
그러나 버퍼 팽창 방지를 전문으로 하는 Wi-Fi 라우터 애프터마켓 펌웨어 배포판이 있습니다. 문제를 처음 인식한 TCP 연구원이 적어도 하나의 배포판을 특별히 개발했으며 솔루션을 찾을 때 연구 개발 플랫폼으로 사용했습니다.
답변2
매우 바쁜 링크를 통해 전송되기 위해 패킷이 대기열에 들어갈 때 높은 대기 시간이 발생합니다. 대기열에서 그 앞에 있는 모든 패킷이 먼저 전송되어야 합니다. 링크에 대한 수요가 많고 큐 버퍼가 크면 왕복 시간이 길어집니다.