데이터 패킷 손실

네트워크 혼잡은 데이터 패킷 손실의 가장 흔한 원인 중 하나이다. 이는 특정 네트워크 경로나 장치(예: 라우터, 스위치)에 처리 능력 이상의 트래픽이 집중될 때 발생한다. 혼잡이 발생하면 장치의 버퍼가 가득 차게 되고, 이후 도착하는 새로운 패킷은 버려진다. 이 과정을 패킷 드롭이라고 한다.

혼잡은 여러 상황에서 나타난다. 예를 들어, 많은 사용자가 동시에 대용량 파일을 다운로드하거나, 고화질 스트리밍 서비스를 이용할 때 특정 링크의 대역폭을 초과할 수 있다. 네트워크 토폴로지상 병목 현상이 발생하는 지점에서도 혼잡이 집중적으로 일어난다.

이러한 혼잡을 관리하기 위해 TCP 혼잡 제어와 같은 프로토콜 수준의 메커니즘이 사용된다. 또한, 네트워크 운영자는 트래픽 엔지니어링이나 품질 서비스 정책을 적용하여 중요한 트래픽의 우선순위를 지정하고 혼잡으로 인한 손실 영향을 완화한다.

버퍼 오버플로우는 네트워크 장비의 버퍼가 수용 가능한 양보다 많은 데이터 패킷이 도달하여 넘쳐흐를 때 발생하는 현상이다. 네트워크의 라우터나 스위치와 같은 장비는 처리 속도보다 빠르게 도착하는 패킷들을 임시로 보관하기 위해 버퍼를 사용한다. 그러나 버퍼의 저장 용량을 초과하는 트래픽이 지속적으로 유입되면, 새로운 패킷을 저장할 공간이 없어져 추가로 도착하는 패킷들은 버려지게 된다. 이것이 패킷 손실의 주요 원인 중 하나이다.

버퍼 오버플로우는 주로 네트워크의 특정 지점에서 순간적인 트래픽 폭주나 링크 간 처리 속도 불일치로 인해 발생한다. 예를 들어, 빠른 속도의 링크(예: 1Gbps)에서 느린 속도의 링크(예: 100Mbps)로 트래픽이 집중될 때, 느린 링크로 전송되지 못한 패킷들이 라우터의 버퍼에 쌓이게 된다. 버퍼가 가득 차면 이후의 패킷은 손실된다. 이 현상은 네트워크 혼잡의 직접적인 결과이기도 하다.

버퍼 오버플로우로 인한 패킷 손실의 특성은 다음과 같은 표로 정리할 수 있다.

버퍼 오버플로우를 완화하기 위한 일반적인 방법은 버퍼 관리 알고리즘을 적용하는 것이다. 능동적 큐 관리 기술은 버퍼가 완전히 채워지기 전에 미리 패킷을 폐기하거나 표시하여 송신 측에 혼잡을 알림으로써 트래픽 흐름을 조절한다. 또한, 네트워크 설계 단계에서 충분한 버퍼 용량을 확보하거나, 트래픽 셰이핑을 통해 트래픽 흐름을 평탄화하는 방법도 사용된다.

물리적 결함은 네트워크 케이블의 손상, 커넥터의 불량, 네트워크 인터페이스 카드(NIC)의 고장 등 하드웨어의 물리적 문제에서 발생한다. 케이블이 꼬이거나 휘어지거나, 외부 압력에 의해 내부 도선이 손상되면 신호의 무결성이 깨져 패킷 손실로 이어진다. 또한, 장비의 포트나 커넥터에 먼지가 쌓이거나 산화 현상이 발생하면 연결 불안정성을 초래한다.

전자기 간섭(EMI)과 무선 간섭은 중요한 손실 원인이다. 전자기 간섭은 고전력 장비, 모터, 형광등, 또는 다른 네트워크 케이블과의 병행 배치로 인해 발생할 수 있다. 이는 신호에 잡음을 더해 수신 측에서 패킷을 올바르게 해석하지 못하게 만든다. 무선 네트워크(Wi-Fi)의 경우, 다른 Wi-Fi 네트워크, 블루투스 장치, 마이크로파 오븐, 두꺼운 벽과 같은 물리적 장애물이 신호를 약화시키거나 간섭을 일으킨다.

이러한 문제를 진단하기 위해 케이블 테스터, TDR(시간 영역 반사계), 스펙트럼 분석기 등의 도구를 사용한다. 해결책으로는 차폐 케이블(STP 또는 동축 케이블) 사용, 장비 접지 개선, 케이블 경로를 간섭원으로부터 분리하거나, 무선 네트워크의 경우 채널을 변경하거나 듀얼 밴드 라우터를 활용하는 방법이 있다.

소프트웨어 또는 하드웨어 구성 요소의 결함은 데이터 패킷 손실의 주요 원인 중 하나이다. 네트워크 장비의 펌웨어나 운영 체제에 존재하는 버그는 패킷을 잘못 처리하거나 폐기하게 만들 수 있다. 예를 들어, 라우터나 스위치의 소프트웨어 결함은 버퍼 관리 오류를 일으켜 정상적인 패킷을 손실시킬 수 있다. 또한, 장비의 과부하로 인해 소프트웨어 프로세스가 중단되거나 재시작되는 경우, 처리 중이던 패킷이 유실될 수 있다.

하드웨어 오류는 물리적 구성 요소의 고장을 의미한다. 네트워크 인터페이스 카드(NIC)의 결함, 라우터의 메모리 모듈 손상, 또는 스위치의 포트 고장 등이 직접적인 패킷 손실을 유발한다. 이러한 하드웨어 문제는 종종 비트 오류를 동반하며, 이는 체크섬 검증 실패로 이어져 패킷이 폐기되는 결과를 낳는다. 열악한 환경에서의 과열이나 전원 공급 장치의 불안정성도 하드웨어 오류를 유발하는 일반적인 요인이다.

소프트웨어와 하드웨어 오류는 종종 상호 연관되어 발생한다. 하드웨어 성능 저하가 소프트웨어의 비정상적인 동작을 유발하거나, 반대로 소프트웨어 버그가 하드웨어 리소스를 과도하게 소모하여 물리적 고장을 가속화할 수 있다. 이러한 오류는 간헐적으로 발생하거나 특정 조건에서만 나타나는 경우가 많아, 진단이 어려울 수 있다.

이러한 오류를 해결하기 위해서는 정기적인 펌웨어 업데이트, 하드웨어 상태 모니터링, 그리고 장비의 로그 분석이 필수적이다.

핑은 ICMP 에코 요청 패킷을 대상 호스트로 보내고, 해당 호스트로부터의 에코 응답을 받는 데 걸리는 시간(지연 시간)과 응답 성공 여부를 측정하는 기본적인 네트워크 진단 도구이다. 패킷 손실을 확인하기 위해 핑 명령어는 일반적으로 연속적으로 여러 개의 패킷을 전송한다. 이때 일부 패킷에 대한 응답을 전혀 받지 못하면, 그 패킷이 네트워크 경로상에서 손실되었음을 나타낸다.

패킷 손실률은 특정 시간 동안 전송된 총 패킷 수 대비 손실된 패킷 수의 비율로 계산된다. 일반적으로 백분율(%)로 표시된다. 예를 들어, 100개의 핑 패킷을 전송했을 때 4개의 응답을 받지 못했다면 패킷 손실률은 4%이다. 이 수치는 네트워크의 안정성과 품질을 평가하는 핵심 지표 중 하나이다.

핑을 통한 패킷 손실 측정은 네트워크 문제를 빠르게 파악하는 데 유용하지만 몇 가지 한계가 있다. 많은 네트워크 장비나 호스트는 ICMP 트래픽을 낮은 우선순위로 처리하거나 차단할 수 있어, 실제 애플리케이션 트래픽의 손실률과 차이가 날 수 있다. 또한, 핑은 단일 경로와 대상에 대한 점검 도구이므로, 네트워크 전체의 정확한 손실 분포를 분석하기 위해서는 더 포괄적인 네트워크 모니터링 도구가 필요하다.

트레이스라우트(traceroute)는 데이터 패킷이 출발지에서 목적지까지 이동하는 경로를 추적하고, 그 과정에서 발생하는 지연 시간과 패킷 손실을 감지하는 진단 도구이다. 이 도구는 일반적으로 TTL(Time To Live) 값을 점차 증가시키는 일련의 ICMP 또는 UDP 패킷을 보내어 경로상의 각 라우터로부터 응답을 받는 방식으로 작동한다. 각 홉(hop)에서의 응답 시간과 응답 유무를 분석함으로써 네트워크 병목 지점이나 손실이 발생하는 구간을 식별할 수 있다.

트레이스라우트를 실행하면 중간 라우터 중 하나로부터 응답이 돌아오지 않거나 "*"(별표)로 표시되는 경우가 있다. 이는 해당 라우터가 ICMP "시간 초과" 메시지를 반환하지 않도록 설정되었거나, 패킷이 해당 구간에서 손실되었음을 의미한다. 결과는 일반적으로 다음과 같은 표 형태로 출력된다.

위 표에서 2번 홉의 두 번째 응답 시간이 "*"로 표시된 것은 해당 패킷이 손실되었거나 응답이 차단되었음을 시사한다. 지속적으로 특정 구간에서 패킷 손실이 관찰된다면, 해당 네트워크 구간의 혼잡이나 물리적 문제를 의심해 볼 수 있다.

트레이스라우트는 단일 경로의 문제를 진단하는 데 유용하지만, 인터넷의 동적 라우팅 특성상 매번 실행 시 경로가 달라질 수 있다는 한계가 있다. 또한, 일부 네트워크 장비는 보안상의 이유로 ICMP 패킷을 필터링하기 때문에 실제 패킷 손실을 과소평가할 가능성도 있다. 따라서 네트워크 문제의 근본 원인을 파악하기 위해서는 핑(ping) 테스트나 종단 간 네트워크 모니터링 도구와 함께 종합적으로 사용하는 것이 일반적이다.

네트워크 모니터링 도구는 패킷 손실을 포함한 다양한 네트워크 문제를 지속적으로 감지, 측정, 분석하는 소프트웨어 또는 하드웨어 솔루션이다. 이 도구들은 네트워크 트래픽을 실시간으로 분석하거나 과거 데이터를 수집하여 패킷 손실의 원인, 위치, 패턴을 파악하는 데 핵심적인 역할을 한다. 단순한 진단 도구를 넘어 네트워크의 전반적인 상태와 성능을 관리하는 네트워크 관리 시스템의 일부로 작동한다.

주요 도구 유형과 기능은 다음과 같다.

이러한 도구들은 패킷 손실 문제를 해결하는 데 있어 단순히 손실률을 보여주는 것을 넘어, 손실이 네트워크의 어느 구간(예: WAN 링크, 특정 스위치 포트)에서 발생하는지, 어떤 애플리케이션이 가장 큰 영향을 받는지, 손실이 시간대별로 어떻게 변하는지에 대한 통찰을 제공한다. 이를 통해 네트워크 관리자는 네트워크 혼잡이나 버퍼 오버플로우 같은 근본 원인을 식별하고, 품질 서비스(QoS) 정책 조정이나 네트워크 용량 증설과 같은 사전 예방적 또는 사후 대응적 조치를 취할 수 있다.

데이터 패킷 손실은 응용 프로그램의 전반적인 성능과 사용자 경험에 직접적인 영향을 미친다. 특히 실시간 상호작용이 요구되거나 대량의 데이터 전송이 필요한 애플리케이션에서 그 영향이 두드러진다.

웹 브라우징의 경우, 페이지를 구성하는 HTML, CSS, JavaScript 파일, 이미지 등이 패킷 손실로 인해 지연되거나 누락되면 페이지 로딩 시간이 현저히 증가한다. 사용자는 페이지가 불완전하게 표시되거나, 스크립트 오류가 발생하거나, 상호작용 요소가 느리게 반응하는 현상을 경험하게 된다. 파일 전송 프로토콜이나 클라우드 저장소 동기화 애플리케이션에서는 데이터 무결성을 보장하기 위해 손실된 패킷을 반드시 재전송해야 하므로, 전송 완료까지 걸리는 시간이 예상보다 훨씬 길어질 수 있다.

온라인 게임이나 원격 데스크톱 프로토콜과 같은 저지연 애플리케이션에서는 더욱 심각한 문제를 일으킨다. 게임에서의 패킷 손실은 플레이어의 입력 명령이 서버에 늦게 전달되거나 다른 플레이어의 위치 정보가 갑자기 점프하는 "워프" 현상으로 나타난다. 이는 게임 플레이를 거의 불가능하게 만들 수 있다. 원격 회의나 VoIP 통화에서는 음성과 영상이 끊기거나, 지연이 발생하며, 심할 경우 통화 자체가 끊길 수 있다.

이러한 성능 저하는 궁극적으로 사용자 생산성 저하와 불만족으로 이어진다. 애플리케이션 개발자는 네트워크 상태가 불안정할 때를 대비한 재연결 로직이나 상태 관리 메커니즘을 구현해야 하며, 네트워크 관리자는 지속적인 모니터링을 통해 패킷 손실의 근본 원인을 찾고 해결해야 한다.

패킷 손실이 발생하면, TCP와 같은 신뢰성 있는 전송 프로토콜은 손실된 데이터를 복구하기 위해 재전송 메커니즘을 작동시킵니다. 이 재전송 과정은 필연적으로 추가적인 지연을 발생시킵니다. 송신 측은 ACK 신호를 기다리거나, RTO가 만료될 때까지 대기해야 하며, 이후 패킷을 다시 보내고 수신 확인을 받아야 합니다. 이로 인해 전체 RTT가 증가하게 되어 사용자에게는 통신이 느려지는 것으로 인지됩니다.

재전송은 혼잡 제어 알고리즘과 밀접하게 연관되어 있습니다. 패킷 손실을 혼잡의 신호로 간주하는 TCP는 슬로우 스타트 단계로 돌아가거나 cwnd 크기를 급격히 줄입니다. 이는 네트워크의 과부하를 완화시키는 긍정적인 역할을 하지만, 동시에 데이터 전송 속도를 크게 낮추어 추가적인 처리 지연을 유발합니다.

지속적인 패킷 손실과 재전송은 응용 프로그램의 성능에 치명적인 영향을 미칠 수 있습니다. 특히 실시간 애플리케이션에서는 재전송으로 복구된 데이터가 이미 시점이 지나버려 무용지물이 되는 경우가 많습니다. 다음 표는 패킷 손실이 지연에 미치는 주요 영향 요인을 정리한 것입니다.

따라서 네트워크 성능 최적화에서는 단순히 패킷 손실률을 낮추는 것뿐만 아니라, 손실이 발생했을 때의 지연을 최소화하는 재전송 및 복구 전략도 함께 고려해야 합니다.

데이터 패킷 손실은 실시간 스트리밍 서비스와 인터넷 전화(VoIP), 화상 회의 등 멀티미디어 애플리케이션의 사용자 경험에 직접적이고 가시적인 영향을 미친다. 이러한 애플리케이션들은 일반적으로 UDP와 같은 비연결형 프로토콜을 사용하거나, 실시간 전송 프로토콜(RTP)을 통해 낮은 지연 시간을 보장하는 데 중점을 둔다. 패킷 손실이 발생하면 손실된 데이터를 재전송하기 위한 시간이 없어, 애플리케이션은 손실을 그대로 수용하거나 근사치로 보정해야 한다.

오디오 스트림에서 패킷 손실은 소리의 끊김, 왜곡 또는 완전한 무음 구간으로 나타난다. 인터넷 전화의 경우, 상대방의 목소리가 끊겨 들리거나 특정 단어가 들리지 않아 대화의 자연스러운 흐름이 방해받는다. 비디오 스트리밍에서는 손실된 패킷이 화면 정지, 블록 현상(화면이 네모난 블록으로 깨져 보이는 현상), 색상 왜곡 또는 전체 프레임의 손실로 이어진다. 특히 고화질(HD) 또는 초고화질(4K/UHD) 콘텐츠는 데이터량이 많아 동일한 손실률이라도 저화질 콘텐츠보다 더 뚜렷한 품질 저하를 초래할 수 있다.

애플리케이션들은 이러한 손실을 완화하기 위해 다양한 기술을 적용한다. 일반적인 방법은 다음과 같다.

그러나 이러한 기술들도 극심한 패킷 손실이나 지속적인 네트워크 정체 앞에서는 효과가 제한적이다. 결국, 멀티미디어 품질을 보장하는 근본적인 방법은 품질 서비스(QoS) 정책을 통해 멀티미디어 트래픽에 우선순위를 부여하거나, 네트워크 인프라를 개선하여 패킷 손실 자체를 줄이는 것이다.

혼잡 제어 알고트름은 네트워크의 혼잡을 감지하고 데이터 전송 속도를 조절하여 패킷 손실과 버퍼 오버플로우를 방지하는 핵심 메커니즘이다. 이 알고리즘은 주로 전송 제어 프로토콜 계층에서 구현되며, 네트워크의 처리 능력을 초과하는 트래픽이 유입되는 것을 방지하는 것을 목표로 한다. 기본 원리는 송신자가 네트워크 상태에 따라 윈도우 크기나 전송률을 동적으로 조정하는 것이다.

대표적인 알고리즘으로는 TCP Tahoe, TCP Reno, TCP Cubic 등이 있다. 초기 TCP는 슬로우 스타트와 혼잡 회피 단계를 통해 선형적으로 윈도우를 증가시키다가 패킷 손실을 감지하면 크게 윈도우를 줄이는 방식을 사용했다. 이후 개발된 TCP Reno는 빠른 재전송과 빠른 회복 메커니즘을 도입하여 단일 패킷 손실 시 연결을 완전히 슬로우 스타트 상태로 되돌리지 않고 더 효율적으로 대응할 수 있게 했다. TCP Cubic은 고대역폭·고지연 네트워크 환경에 최적화되어, 손실 후 윈도우 크기를 3차 함수 곡선을 따라 증가시킨다.

이러한 알고리즘의 발전은 단순히 손실을 줄이는 것을 넘어, 네트워크 자원의 공정한 분배와 전체적인 처리량 최대화를 추구한다. 최근에는 BBR과 같은 모델 기반 알고리즘이 등장하여, 패킷 손실을 혼잡의 지표로 삼기보다 실제 대역폭과 지연 시간을 측정하여 최적의 전송 속도를 직접 추정하는 방식을 채택하기도 한다.

오류 정정 및 재전송은 데이터 패킷 손실을 복구하기 위한 두 가지 핵심적인 접근법이다. 오류 정정은 수신 측에서 손실되거나 손상된 데이터를 추가 정보를 바탕으로 복원하는 방식이며, 재전송은 송신 측이 손실된 패킷을 다시 보내는 방식이다. 각 방식은 사용되는 프로토콜과 애플리케이션의 요구 사항에 따라 선택된다.

오류 정정 방식은 주로 순방향 오류 수정(FEC) 기법을 사용한다. 송신 측은 원본 데이터에 오류 정정 코드(예: 리드-솔로몬 코드, 해밍 코드)를 추가하여 전송한다. 수신 측은 패킷이 손실되더라도 남아 있는 데이터와 오류 정정 코드를 조합하여 원본 데이터를 재구성할 수 있다. 이 방식은 재전송에 따른 지연이 발생하지 않아 실시간 통신이나 스트리밍 서비스에 유리하지만, 대역폭 오버헤드가 증가한다는 단점이 있다.

재전송 방식은 신뢰성 있는 전송이 필수적인 TCP와 같은 프로토콜에서 주로 사용된다. 기본 메커니즘은 다음과 같다.

두 방식은 상호 배타적이지 않으며, 상황에 따라 혼합되어 사용되기도 한다. 예를 들어, 일부 화상 회의 시스템은 지연을 최소화하기 위해 FEC를 기본으로 사용하되, 중요한 데이터 구간에 대해 재전송을 병행하는 하이브리드 방식을 채택하기도 한다.

품질 서비스(QoS)는 네트워크에서 데이터 패킷 손실을 관리하고 완화하기 위한 핵심적인 접근 방식이다. 이는 네트워크 자원을 제한된 대역폭 내에서 효율적으로 할당하여, 중요한 트래픽의 전달을 보장하고 혼잡으로 인한 손실을 사전에 방지하는 것을 목표로 한다. QoS는 패킷이 네트워크를 통과할 때 특정 기준에 따라 우선순위를 부여하고, 대역폭을 예약하며, 트래픽 흐름을 조절하는 일련의 기술을 포괄한다.

QoS 설정의 주요 메커니즘은 다음과 같다.

이러한 설정은 일반적으로 라우터, 스위치, 방화벽 같은 네트워크 장치에서 구성된다. 예를 들어, VoIP 통화나 화상 회의 트래픽에 최고 우선순위를 부여하면, 버퍼 오버플로우 상황에서도 이 패킷들이 먼저 처리되어 음성 끊김이나 영상 깨짐 현상을 최소화할 수 있다. 반면, 이메일이나 파일 백업 같은 비실시간 트래픽은 낮은 우선순위를 받아 네트워크가 혼잡할 때 일시적으로 지연될 수 있다.

효과적인 QoS 구현을 위해서는 네트워크의 트래픽 패턴을 분석하고, 애플리케이션의 요구사항을 정확히 정의하는 정책 수립이 선행되어야 한다. 또한, 엔드투엔드 경로상의 모든 주요 장치에서 일관된 QoS 정책이 적용되어야 그 효과가 발휘된다.

네트워크 용량 최적화는 사용 가능한 대역폭을 효율적으로 활용하여 패킷 손실의 근본 원인 중 하나인 네트워크 혼잡을 사전에 방지하거나 완화하는 접근법이다. 이는 단순히 물리적 대역폭을 증설하는 것을 넘어, 트래픽 흐름을 분석하고 병목 현상을 제거하며 네트워크 자원의 사용률을 극대화하는 일련의 과정을 포함한다.

주요 최적화 기법으로는 트래픽 샤이핑, 로드 밸런싱, 그리고 대역폭 예약이 있다. 트래픽 샤이핑은 특정 애플리케이션이 과도한 대역폭을 점유하지 않도록 트래픽 흐름의 속도를 제한하거나 지연시키는 기술이다. 로드 밸런싱은 다수의 네트워크 경로나 링크에 트래픽을 분산시켜 단일 경로의 포화 상태를 방지한다. 또한, 품질 서비스 정책을 통해 실시간 통신이나 중요한 비즈니스 애플리케이션의 트래픽에 우선적으로 대역폭을 할당할 수 있다.

정기적인 네트워크 모니터링을 통해 용량 계획을 수립하는 것도 필수적이다. 트래픽 증가 추세를 분석하여 병목 지점을 예측하고, 네트워크 장비의 업그레이드나 구성 변경(예: 링크 애그리게이션)을 통해 용량을 확장할 수 있다. 궁극적으로 네트워크 용량 최적화는 혼잡으로 인한 패킷 손실을 사전에 줄여 전송 제어 프로토콜의 재전송 및 지연을 최소화하고, 전체적인 네트워크 처리량과 사용자 경험을 향상시킨다.

TCP는 신뢰성 있는 데이터 전송을 보장하기 위해 패킷 손실을 감지하고 복구하는 여러 메커니즘을 구현한다. 핵심은 시퀀스 번호와 확인 응답을 사용한 재전송 방식이다. 송신 측은 전송한 각 데이터 세그먼트에 고유한 시퀀스 번호를 부여하고, 수신 측은 성공적으로 수신한 데이터의 시퀀스 번호 범위를 ACK 패킷으로 응답한다. 송신 측은 일정 시간 내에 ACK를 받지 못하면 해당 데이터를 손실된 것으로 판단하고 재전송한다.

재전송을 유발하는 주요 타이머는 재전송 타이머이다. 이 타이머의 만료 시간인 RTT는 네트워크 상태에 따라 동적으로 계산되어 조정된다[4]. 또한, 빠른 재전송 메커니즘은 재전송 타이머의 만료를 기다리지 않고 손실을 추정한다. 수신 측이 동일한 시퀀스 번호에 대한 중복 ACK를 세 번 이상 보내면, 송신 측은 해당 세그먼트가 손실되었다고 간주하고 즉시 재전송한다.

TCP의 혼잡 제어 알고리즘은 패킷 손실을 네트워크 혼잡의 주요 신호로 간주한다. 손실이 발생하면 TCP 혼잡 제어는 전송 속도를 급격히 낮춰 네트워크의 부하를 줄인다. 예를 들어, TCP Reno나 TCP Cubic과 같은 알고리즘은 손실에 반응하여 혼잡 창 크기를 절반으로 줄이거나 특정 수준으로 감소시킨다. 이는 재전송으로 인한 추가 트래픽으로 인해 혼잡이 더 악화되는 것을 방지하는 데 목적이 있다.

SACK은 TCP의 선택적 확인응답 옵션으로, 표준적인 누적 ACK보다 향상된 정보를 제공한다. 수신 측이 연속되지 않은 데이터 블록을 성공적으로 수신했을 경우, SACK을 통해 이 블록들의 정확한 시퀀스 번호 범위를 송신 측에 알릴 수 있다. 이를 통해 송신 측은 정확히 어떤 세그먼트가 손실되었는지 파악하고, 불필요한 재전송을 줄이면서 효율적으로 손실된 데이터만 재전송할 수 있다.

UDP는 TCP와 달리 연결 설정, 신뢰성 있는 전송, 혼잡 제어, 순서 보장과 같은 기능을 제공하지 않는 무연결 프로토콜이다. 이로 인해 패킷이 손실되거나 순서가 바뀌어 도착하더라도 프로토콜 자체는 이를 복구하거나 재전송을 시도하지 않는다. 이러한 특성은 낮은 지연과 오버헤드가 요구되는 애플리케이션에 적합하게 만든다.

손실을 허용하는 애플리케이션은 주로 실시간 통신이나 스트리밍 서비스에 사용된다. 예를 들어, VoIP, 화상 회의, 실시간 온라인 게임, 라이브 비디오 스트리밍 등이 이에 해당한다. 이러한 애플리케이션에서는 지연이 치명적이기 때문에, 손실된 패킷을 기다리며 버퍼링하는 것보다 그냥 건너뛰고 최신 데이터를 계속 재생하는 것이 전체적인 사용자 경험에 더 유리하다. 애플리케이션 계층에서 일정 수준의 패킷 손실을 보정하기 위해 FEC나 인터리빙 같은 기술을 사용하기도 한다.

따라서 UDP를 기반으로 하는 애플리케이션은 본질적으로 일정량의 데이터 패킷 손실을 감수하고 설계된다. 개발자는 프로토콜의 신뢰성 부족을 애플리케이션 로직으로 보완하거나, 애플리케이션의 요구사항에 따라 손실이 미치는 영향을 최소화하는 방향으로 구현한다.

QUIC는 구글에서 처음 개발한 전송 계층 네트워크 프로토콜이다. 이 프로토콜은 TCP와 TLS를 결합하여 설계되었으며, 특히 데이터 패킷 손실 상황에서의 연결 설정 시간과 전반적인 성능을 개선하는 것을 목표로 한다. HTTP/3의 기본 전송 프로토콜로 채택되면서 널리 알려지게 되었다.

QUIC의 핵심 특징은 다중 스트림 지원과 향상된 손실 복구 메커니즘이다. 단일 QUIC 연결 내에서 여러 개의 독립적인 논리적 스트림을 병렬로 전송할 수 있다. 이는 Head-of-line blocking 문제를 해결하는 데 중요한 역할을 한다. 하나의 스트림에서 패킷 손실이 발생해도, 다른 스트림의 데이터 전송은 영향을 받지 않고 계속 진행될 수 있다. 또한, 연결 설정 과정에서 TCP의 3방향 핸드셰이크와 TLS 핸드셰이크를 결합하여 1-RTT 또는 0-RTT로 단축함으로써 초기 지연을 크게 줄인다.

패킷 손실에 대한 QUIC의 접근 방식은 더 빠른 복구와 향상된 혼잡 제어에 있다. TCP가 순차적인 패킷 번호를 사용하는 반면, QUIC는 패킷 번호를 암호화하고 각 패킷 번호 공간을 독립적으로 관리한다. 이 설계는 패킷 번호 변조를 방지하고, 손실된 패킷을 더 정확하게 식별하는 데 도움을 준다. 또한, 선택적 확인응답과 결합된 고유한 ACK 프레임 구조를 사용하여 네트워크 상태에 대한 더 풍부한 피드백을 제공한다. 이를 통해 송신 측은 손실을 더 빠르게 감지하고 재전송을 신속하게 시작할 수 있다.

QUIC는 특히 지연에 민감한 애플리케이션과 불안정한 무선 네트워크 환경에서 데이터 패킷 손실의 영향을 줄이는 데 효과적인 것으로 평가받는다. 그러나 네트워크 중간 장비(예: 방화벽, 로드 밸런서)에서의 가시성 문제와 같은 새로운 과제도 제기하고 있다.