패킷 손실이 빠른 홈 서버 연결을 느리게 하는 이유는 무엇인가요?

패킷 손실은 링크 속도가 비트를 얼마나 빨리 전송할 수 있는지를 측정하는 반면, 유용 처리량은 애플리케이션 데이터가 얼마나 정확히 도착하는지와 패킷이 사라질 때 전송 프로토콜이 어떻게 반응하는지에 따라 달라지므로, 빠른 홈 서버 링크를 느리게 만듭니다.

신뢰할 수 있는 전송은 누락된 데이터를 반복 전송하며, 손실이 혼잡을 신호할 수 있기 때문에 보통 전송 속도를 줄입니다. 따라서 1GbE 또는 10GbE 인터페이스는 완전히 협상된 상태를 유지할 수 있지만, 파일 복사, 원격 백업, 웹 세션 또는 미디어 스트림은 예상 유용 성능의 일부만 전달할 수 있습니다.

왜 링크 속도는 높게 유지되면서 유용 처리량은 떨어질 수 있나요?

대역폭은 경로의 명목상 전송 용량인 반면, 유효 처리량은 성공적으로 전달된 유용한 애플리케이션 페이로드만 계산합니다. 한 제어된 경로 품질 실험에서 작은 손실률도 반복적으로 전송 흐름을 방해하여 유용 처리량이 링크 속도 변화 전에 붕괴할 수 있습니다.

재전송된 바이트, 중복 데이터, 헤더 및 복구 간극은 완료된 파일이나 애플리케이션 응답을 진행시키지 않으면서 시간을 소비합니다. 인터페이스 카운터는 수신자가 유용한 데이터를 천천히 얻을 때도 상당한 트래픽을 표시할 수 있습니다.

속도 테스트는 여러 병렬 흐름, 인근 서버 또는 짧은 테스트 간격을 사용하여 문제를 숨길 수도 있습니다. 먼 엔드포인트로의 단일 장기 전송은 반복 손실과 왕복 복구에 더 취약합니다.

손실 후 신뢰할 수 있는 전송이 반복하는 작업은 무엇인가요?

TCP와 신뢰할 수 있는 QUIC 스트림은 어떤 데이터가 수신자에게 도달했는지 추적합니다. 간극이 감지되면 손실된 데이터를 다시 전송해야 하며, 추가 대역폭을 소비하고 완료를 지연시킵니다.

발신자는 중복 확인 응답, 선택적 확인 응답, QUIC 손실 타이머 또는 재전송 타임아웃을 통해 손실을 감지할 수 있습니다. 빠른 감지는 일시 중지를 제한하지만, 타임아웃은 발신자가 재시도하기 전에 훨씬 더 긴 지연을 추가할 수 있습니다.

재전송은 단순히 하나의 누락된 패킷을 대체하는 것이 아닙니다. 원래 패킷은 이미 링크 용량을 사용했으며, 대체 패킷도 다시 용량을 사용하고, 발신자가 손실을 정확히 식별하지 못할 경우 인근 패킷도 재전송될 수 있습니다.

패킷 손실 후 TCP가 전송 속도를 줄이는 이유는 무엇인가요?

고전적인 TCP는 손실을 경로에 너무 많은 데이터가 들어가고 있다는 증거로 간주합니다. 손실 기반 혼잡 제어는 전송 속도를 줄입니다 그래서 송신자는 이전 속도로 가능한 병목 현상에 데이터를 계속 공급하는 것을 멈춥니다.

혼잡 윈도우는 확인되지 않은 데이터가 비행 중에 남아 있을 수 있는 양을 제어합니다. 그 윈도우를 줄이면 실제로 손실된 패킷 비율보다 훨씬 더 처리량이 감소할 수 있는데, 이는 송신자가 이후 확인 라운드에서 윈도우를 다시 키워야 하기 때문입니다.

다양한 알고리즘은 다르게 반응합니다: Reno, CUBIC, BBR 변형 및 QUIC 구현은 동일한 신호나 감소를 사용하지 않습니다. 일반적인 경계는 빠른 물리적 링크가 전송이 비행 중인 데이터를 의도적으로 제한할 때 용량을 전달할 수 없다는 점입니다.

왕복 시간이 손실 복구를 어떻게 확대시키나요?

송신자는 수신자에게 전달되어 다시 돌아오는 피드백을 통해 전달 상태를 알게 됩니다. 높은 RTT는 모든 복구 주기를 연장합니다 왜냐하면 각 윈도우 조정과 재전송 확인이 RTT의 또 다른 부분을 소비하기 때문입니다.

짧은 로컬 이더넷 경로에서는 빠른 재전송이 거의 눈에 띄지 않을 정도로 빠르게 완료될 수 있습니다. VPN, 원격 백업, 클라우드 마운트 또는 국가 간 연결에서 같은 손실은 수십 또는 수백 밀리초 동안 진행을 지연시킬 수 있습니다.

고대역폭은 각 왕복 동안 더 많은 데이터가 전송 중일 수 있기 때문에 페널티가 더 놀랍습니다. 손실은 그 파이프라인을 비우거나 축소시키며, 더 긴 경로는 이를 다시 채우는 데 더 많은 시간이 필요합니다.

왜 하나의 누락된 패킷이 이미 도착한 데이터를 지연시킬 수 있나요?

TCP는 애플리케이션에 순서가 지정된 바이트 스트림을 제공합니다. 하나의 누락된 세그먼트가 나중 데이터를 차단할 수 있습니다 심지어 나중 패킷이 이미 수신자에게 도달했을 때도 그렇습니다.

나중의 바이트들은 간극이 복구될 때까지 수신 버퍼에서 대기할 수 있습니다. HTTP/2의 경우 여러 논리적 요청이 하나의 TCP 연결을 공유하므로, 하나의 전송 수준 손실이 누락된 바이트 뒤에 있는 독립적인 응답 스트림을 지연시킬 수 있습니다.

QUIC는 스트림이 독립적으로 복구할 수 있기 때문에 스트림 간 전송 헤드 오브 라인 차단을 피하지만, 손실은 여전히 재전송 용량과 혼잡 제어 예산을 소모합니다. 하나의 정체 메커니즘을 제거한다고 해서 손실된 패킷이 무료가 되는 것은 아닙니다.

파일 전송, 스트림 및 UDP 앱이 다르게 실패하는 이유는 무엇인가요?

TCP와 UDP는 손실을 다르게 노출합니다. 파일 전송은 정확한 바이트를 기다리지만, 라이브 통화는 이미 재생하기에 너무 늦은 데이터를 기다리기보다 손상되거나 건너뛴 프레임을 선호할 수 있습니다.

TCP 손실은 낮은 처리량, 버퍼링 또는 페이지 및 파일 완료 지연으로 나타납니다. UDP 손실은 전방 오류 수정 및 복구 설계에 따라 오디오 끊김, 블록 아티팩트, 제어 지터, 텔레메트리 누락 또는 애플리케이션 수준 재시도로 나타날 수 있습니다.

로컬과 인터넷 트래픽이 하나의 병목을 공유할 수 있습니다. 이 때문에 패킷 손실은 경로와 작업 부하에 따라 해석해야 합니다: 깨끗한 LAN 복사본이 원격 경로가 깨끗하다는 증거가 아니며, 빠른 인터페이스가 신뢰할 수 있는 애플리케이션 전달을 보장하지 않습니다.

자주 묻는 질문

1% 패킷 손실이 정말로 훨씬 큰 처리량 감소를 초래할 수 있나요?

특히 의미 있는 RTT를 가진 단일 TCP 흐름의 경우 일부 조건에서는 그렇습니다. 정확한 영향은 혼잡 제어 알고리즘, 손실 패턴, RTT, 윈도우 크기, 병렬 흐름 및 복구 기능에 따라 다릅니다.

패킷 손실이 항상 네트워크 혼잡을 의미하나요?

아니요. 혼잡은 흔하지만 손실은 Wi-Fi 간섭, 손상된 케이블, 불량 광학 장치, 과부하 호스트, 결함 있는 NIC, MTU 문제 또는 소프트웨어 및 드라이버 제한에서도 발생할 수 있습니다.

왜 병렬 속도 테스트는 정상처럼 보일 수 있나요?

여러 흐름이 독립적으로 복구하며 각 흐름이 성능이 좋지 않아도 함께 링크를 채울 수 있습니다. 단일 애플리케이션 연결은 같은 이점을 받지 못할 수 있습니다.

UDP가 패킷 손실의 성능 비용을 피할 수 있나요?

UDP는 내장된 재전송과 순서 전달을 피하지만, 애플리케이션은 데이터를 잃거나 자체 복구, 은폐, 중복성 또는 재시도 메커니즘을 추가해야 합니다.

최종 요약

패킷 손실은 전송 용량을 낭비하고 신뢰할 수 있는 복구를 강제하며 혼잡 윈도우를 줄이고 순서대로 전달을 지연시켜 빠른 링크를 느린 애플리케이션 경로로 만듭니다. 물리적 인터페이스는 최대 속도를 유지할 수 있지만 유용한 데이터는 느리게 도착할 수 있습니다. RTT, 전송 프로토콜, 손실 패턴, 작업 부하에 따라 결과가 낮은 처리량, 버퍼링, 긴 꼬리 지연 또는 실시간 미디어 누락처럼 보일 수 있습니다.