패킷 손실

Packet loss

패킷 손실은 컴퓨터 네트워크를 통과하는 1개 이상의 데이터 패킷이 수신처에 도달하지 못할 때 발생합니다.패킷 손실은 일반적으로 무선 네트워크를 통한 데이터 전송 오류 [1][2]또는 네트워크 [3]: 36 폭주로 인해 발생합니다.패킷 손실은, 송신된 패킷에 대해서 손실된 패킷의 퍼센티지로 측정됩니다.

Transmission Control Protocol(TCP)은 패킷 손실을 검출하고 재전송을 실행하여 신뢰할 수 있는 메시지를 보장합니다.TCP 접속에서의 패킷 손실도 congestion를 회피하기 위해서 사용되며, 따라서 접속의 throughput이 의도적으로 저하됩니다.

스트리밍 미디어나 온라인 게임과 같은 실시간 애플리케이션에서는 패킷 손실이 사용자의 Quality of Experience(QoE)에 영향을 줄 수 있습니다.

원인들

인터넷 프로토콜(IP)은 엔드 투 엔드 원칙에 따라 논리 라우터가 구현해야 하는 것을 가능한 한 단순하게 유지하기 위해 베스트 에포트 전송 서비스로서 설계됩니다.네트워크가 자체적으로 신뢰성 높은 전달 보증을 하고 있는 경우, 각 라우터가 다음 노드가 패킷을 올바르게 수신하고 있는지 확인하기 위해 대기하는 동안 패킷에 상당한 양의 저장 공간을 할당하는 저장 및 전송 인프라스트럭처가 필요합니다.신뢰할 수 있는 네트워크에서는, 라우터에 장해가 발생했을 경우에서도, 전달 보증을 유지할 수 없습니다.또, 모든 애플리케이션에 신뢰성이 필요한 것은 아닙니다.예를 들어 라이브 스트리밍 미디어에서는 오래된 패킷이 최종적으로 전송되는 것보다 최신 패킷을 신속하게 전송하는 것이 중요합니다.또, 애플리케이션 또는 유저는, 시간이 걸리는 조작을 재시도 할 수도 있습니다.이 경우, 원래의 세트를 전달해야 하는 부담이 다른 패킷세트가 추가됩니다.이러한 네트워크에는 congestion 관리를 위한 명령 및 제어 프로토콜도 필요할 수 있으므로 복잡성이 더욱 가중됩니다.

이러한 모든 문제를 피하기 위해 인터넷 프로토콜은 라우터 또는 네트워크 세그먼트가 너무 비지 상태여서 데이터를 시기적절하게 전달할 수 없는 경우 라우터가 단순히 패킷을 드롭할 수 있도록 합니다.이는 데이터의 신속하고 효율적인 전송에는 적합하지 않으며,[4] 통신량이 많은 네트워크에서는 발생하지 않을 것으로 예상됩니다.패킷의 폐기는 네트워크가 폭주하고 있음을 암시하는 신호로서 기능해, 송신측이 소비하는 대역폭의 양을 줄이거나 다른 패스를 찾으려고 하는 경우가 있습니다.예를 들어, 인식된 패킷 손실을 congestion를 검출하기 위한 피드백으로서 사용하는 것으로, Transmission Control Protocol(TCP)은, 과도한 패킷 손실이 송신측의 속도를 억제해,[3]: 282–283 보틀 넥 포인트의 데이터 플래딩을 정지하도록 설계되어 있습니다.

IPv4 헤더체크섬 또는 이더넷프레임 체크시퀀스가 패킷이 파손되었음을 나타내는 경우에도 패킷은 폐기될 수 있습니다.패킷 손실은 패킷 폐기 공격에 의해서도 발생할 수 있습니다.

무선 네트워크

무선 네트워크에는 Radio Frequency Interference(RFI;[1] 무선 주파수 간섭), 거리 또는 멀티 패스의 페이딩으로 인해 너무 약한 무선 신호, 네트워크하드웨어의 장애, 네트워크 드라이버의 장애 등, 전송중의 패킷이 파손되거나 손실될 가능성이 있습니다.

Wi-Fi는 본질적으로 신뢰할 수 없으며 동일한 Wi-Fi 수신기가 서로 근접하게 배치되어 있어도 예상과 [1]같은 패킷 손실 패턴을 보이지 않습니다.

셀룰러 네트워크에서는, 「High Bit Error Rate(BER; 고비트 에러 레이트), 불안정한 채널 특성, 및 유저의 [5]모빌리티」에 의해서 패킷 손실이 발생하는 일이 있습니다.TCP 의 의도적인 슬롯링 동작에 의해, 무선 네트워크가 이론상의 잠재적인 전송 레이트에 가까운 퍼포먼스를 발휘하지 않게 됩니다.변경되지 않은TCP 는 폐기된 모든 패킷을 네트워크의 congestion에 의한 것처럼 취급하기 때문입니다.따라서 실제로 [5]congestion가 발생하지 않은 경우에도 무선 네트워크가 억제될 가능성이 있기 때문입니다.

네트워크 폭주

네트워크의 congestion는, 모든 종류의 네트워크에 영향을 줄 가능성이 있는 패킷 손실의 원인입니다.소정의 라우터 또는 네트워크 세그먼트에, 송신 가능한 레이트보다 큰 레이트로 컨텐츠가 일정 기간 착신했을 경우,[3]: 36 패킷을 드롭 하는 것 외에 다른 옵션은 없습니다.단일 라우터 또는 링크가 전체 이동 경로 또는 네트워크 이동의 용량을 제한하고 있는 경우 이를 병목 현상이라고 합니다.경우에 따라서는, 패킷이 라우팅 루틴에 의해서,[6][7] 또는 운용 관리를 위해서 네트워크 만류 기술에 의해서 의도적으로 드롭 되는 일이 있습니다.

영향들

패킷 손실은, 송신된 데이터가 수신되지 않고, 스루풋으로 카운트 할 수 없기 때문에, 특정의 송신측의 스루풋을 직접 감소시킵니다.패킷 손실은 일부 전송 계층 프로토콜이 손실을 폭주의 표시로 해석하고 폭주 붕괴를 피하기 위해 전송 속도를 조정하기 때문에 간접적으로 처리량을 감소시킵니다.

신뢰할 수 있는 전달이 필요한 경우 패킷 손실은 [a]재전송에 필요한 추가 시간으로 인해 지연을 증가시킵니다.재발송신이 없는 경우, 최악의 지연이 발생하고 있는 패킷은 우선적으로 폐기될 수 있습니다(사용하는 큐잉의 종류에 따라 다름).그 결과, 전체적으로 지연이 짧아집니다.

측정.

패킷 손실은 프레임 손실률로 측정할 수 있습니다.이것은 네트워크에 의해 전송될 필요가 있었지만 전송되지 [8]않은 프레임의 퍼센티지로 정의됩니다.

허용 가능한 패킷 손실

패킷 손실은 Quality of Service 고려사항과 밀접하게 관련되어 있습니다.허용 가능한 패킷 손실량은 전송되는 데이터의 유형에 따라 달라집니다.예를 들어 Voice over IP 트래픽의 경우, 한 코멘테이터는 [m]1개 또는 2개의 패킷을 발행해도 컨버세이션의 품질에는 영향을 주지 않는다고 간주했습니다.전체 패킷 스트림의 5%에서 10% 사이의 손실이 품질에 [9]큰 영향을 미칩니다."또 다른 조사에서는 1% 미만의 패킷 손실이 오디오 또는 비디오 스트리밍에 대해 '양호함'으로, 1~2.5%가 '허용 가능'[10]으로 설명했습니다.

진단.

패킷 손실은 TCP와 같은 신뢰할 수 있는 프로토콜에 의해 감지됩니다.신뢰할 수 있는 프로토콜은 패킷 손실에 자동으로 반응하기 때문에 네트워크 관리자 등의 담당자가 패킷 손실을 감지하고 진단해야 할 경우 일반적으로 네트워크 장비 또는 특수 제작된 도구의 상태 정보를 사용합니다.

Internet Control Message Protocol은 에코 기능을 제공합니다.이 기능에서는, 항상 응답을 생성하는 특수한 패킷이 송신됩니다.ping, traceroute, MTR 등의 도구는 이 프로토콜을 사용하여 패킷이 통과하는 경로를 시각적으로 표현하고 각 [b]홉에서 패킷 손실을 측정합니다.

대부분의 라우터에는 상태 페이지 또는 로그가 있어 소유자는 특정 기간 동안 드롭된 패킷의 수 또는 비율을 확인할 수 있습니다.

신뢰성 높은 전달을 위한 패킷 복구

엔드 투 엔드의 원칙에 따르면, 인터넷 프로토콜은 엔드포인트(데이터를 송수신하는 컴퓨터)에 손실된 패킷을 재전송함으로써 패킷 복구에 대한 책임을 떠맡습니다.데이터를 송신하는 애플리케이션은 메시지의 전체 또는 일부가 최선의 재발송신인지, 메시지를 송신할 필요가 있는지 여부, 폭주를 고려하기 위해 소비되는 대역폭의 양을 제어하는 방법을 알아야 하기 때문에 재전송이 필요한지 여부를 결정하는 데 최적의 위치에 있습니다.

TCP와 같은 네트워크 전송 프로토콜은 개별 애플리케이션이 이 로직을 직접 구현할 필요가 없도록 패킷의 안정적인 전달을 보장하는 쉬운 방법을 엔드포인트에 제공합니다.패킷이 손실되었을 경우, 수신측은 재전송을 요구하거나,[3]: 242 송신측은 자동적으로 확인 응답을 받지 않은 세그먼트를 재발송합니다.TCP 는 패킷 손실로부터 회복할 수 있습니다만, 누락된 패킷을 재발송하면, 리시버가 재발송신을 대기해, 리시버에 의해서 추가의 대역폭이 소비되기 때문에, 접속의 throughput이 저하됩니다.TCP 의 특정 종류에서는, 송신 패킷이 없어지면, 그 후에 이미 송신된 모든 패킷과 함께 재발송신됩니다.

UDP(User Datagram Protocol) 등의 프로토콜은 손실된 패킷에 대한 복구를 제공하지 않습니다.UDP를 사용하는 애플리케이션은 필요에 따라 패킷 손실을 처리하기 위한 자체 메커니즘을 구현해야 합니다.

큐잉 규율의 영향

폐기할 패킷을 결정하기 위해 사용되는 큐잉 규칙이 많이 있습니다.대부분의 기본적인 네트워킹기기는 보틀 넥 통과를 대기하는 패킷에 FIFO 큐잉을 사용합니다.패킷이 수신되었을 때 큐가 가득 차면 패킷을 드롭합니다.이런 유형의 패킷 폐기를 테일 드롭이라고 합니다.기타 풀 큐메커니즘에는 랜덤 조기 드롭 또는 가중치 랜덤 조기 드롭이 있습니다.패킷의 드롭은 패킷이 손실되거나 재발송신이 필요하기 때문에 바람직하지 않습니다.이는 실시간스루풋에 영향을 줄 수 있습니다.다만, 버퍼 사이즈를 늘리면, 버퍼 블러트가 발생해, congestion시의 지연이나 지터에 영향을 줄 가능성이 있습니다.

예를 들어 누출 버킷알고리즘을 사용하는 등 서비스 품질로 접속이 레이트 제한되는 경우 패킷은 특정 서비스의 속도를 늦추고 중요도가 높은 다른 서비스에 사용 가능한 대역폭을 확보하기 위해 의도적으로 폐기될 수 있습니다.따라서 패킷 손실이 반드시 연결 신뢰성의 저하 또는 대역폭 보틀 넥의 징후를 나타내는 것은 아닙니다.

「 」를 참조해 주세요.

메모들

  1. ^ 일반적인 네트워크의 congestion중에, 스트림내의 모든 패킷이 드롭 되는 것은 아닙니다.즉, 루핑되지 않은 패킷은, 레이텐시가 높은 재발송신 패킷에 비해, 레이텐시가 짧은 패킷으로 착신합니다.재발송신된 패킷은, 그 도중에 2 회 전송 할 필요가 있을 뿐만 아니라, 송신자는, 패킷이 드롭 된 것을 깨닫지 못하고, 지연이 아니고, 패킷이 드롭 된 것을 상정해, 예상의 순서로 수신 확인 응답을 수신할 수 없거나, 충분한 시간 동안 수신 확인 응답을 수신할 수 없는 경우, 패킷이 드롭 된 것을 깨닫지 못합니다.
  2. ^ 경우에 따라서는, 이러한 툴은, 행선지에 도달하는 패킷이 아니고, 소수의 홉으로 종단하는 패킷의 폐기를 나타내고 있는 경우가 있습니다.예를 들어 라우터는 ICMP 패킷의 에코를 낮은 priority로 하여 실제 데이터에 자원을 소비하기 위해 우선 폐기할 수 있습니다.이는 일반적으로 테스트의 아티팩트로 간주되며 엔드 투 엔드 결과를 [11]위해 무시할 수 있습니다.

레퍼런스

  1. ^ a b c Salyers, David C.; Striegel, Aaron; Poellabauer, Christian. "Wireless Reliability: Rethinking 802.11 Packet Loss" (PDF). Archived from the original (PDF) on 2019-07-12. Retrieved 2018-02-19.
  2. ^ Tian, Ye; Xu, Kai; Ansari, Nirwan (March 2005). "TCP in Wireless Environments: Problems and Solutions" (PDF). IEEE Radio Communications. 43 (3): S27–S32. doi:10.1109/MCOM.2005.1404595. S2CID 735922. Archived from the original (PDF) on 2017-08-09. Retrieved 2018-02-19.
  3. ^ a b c d 쿠로세, J.F. & Ross, K.W. (2010년)컴퓨터 네트워킹: 하향식 접근법.뉴욕: 애디슨 웨슬리
  4. ^ Kurose, J.F.; Ross, K.W. (2010). Computer Networking: A Top-Down Approach. New York: Addison-Wesley. pp. 42–43. The fraction of lost packets increases as the traffic intensity increases. Therefore, performance at a node is often measured not only in terms of delay but also in terms of the probability of packet loss…a lost packet may be retransmitted on an end-to-end basis in order to ensure that all data are eventually transferred from source to destination.
  5. ^ a b Ye Tian; Kai Xu; Nirwan Ansari (March 2005). "TCP in Wireless Environments: Problems and Solutions" (PDF). IEEE Radio Communications. IEEE. Archived from the original (PDF) on 2017-08-09. Retrieved 2018-02-19.
  6. ^ 퍼킨스, C.E. (2001)애드혹 네트워킹보스턴:애디슨-웨슬리 페이지 147
  7. ^ "네트워크 특성에 의한 애플리케이션 제어" Vahab Pournaghshband, Leonard Kleinrock, Peter Reiher 및 Alexander Apanasyev ICC 2012
  8. ^ RFC 1242
  9. ^ 맨스필드, K.C. & 안토나코스, J.L. (2010)LAN에서 WAN으로의 컴퓨터 네트워킹: 하드웨어, 소프트웨어 및 보안.보스턴:기술 코스, Cenge Learning 페이지 501
  10. ^ "Archived copy". Archived from the original on 2013-10-10. Retrieved 2013-05-16.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  11. ^ "Packet loss or latency at intermediate hops". Retrieved 2007-02-25.

외부 링크

  • 패킷 손실 테스트 - 인터넷 연결을 테스트하여 패킷 손실을 확인합니다.