일부 패킷 손실을 허용 할 수있는 일반적인 프로토콜 메시지 교환. TCP를 통한 UDP는 얼마나 더 효율적입니까?
답변
UDP는 TCP보다 빠르며 간단한 이유는 TCP 창 크기와 왕복 시간을 사용하여 계산 된 패킷 집합을 확인하는 TCP 대신 연속 패킷 스트림을 허용하는 존재하지 않는 확인 패킷 (ACK)이기 때문입니다. (RTT).
자세한 내용은 간단하지만 이해하기 쉬운 Skullbox 설명 (TCP vs. UDP)을 권장합니다.
답변
사람들은 TCP가 제공하는 가장 중요한 것은 안정성이라고 말합니다. 그러나 그것은 사실이 아닙니다. TCP가 제공하는 가장 중요한 것은 혼잡 제어입니다. DSL 링크를 통해 100 개의 TCP 연결을 모두 최대 속도로 실행할 수 있으며, 100 개의 연결은 모두 사용 가능한 대역폭을 “감지”하기 때문에 생산적입니다. 100 개의 서로 다른 UDP 응용 프로그램을 사용하여 가능한 빨리 패킷을 푸시하고 일이 얼마나 잘 수행되는지 확인하십시오.
더 큰 규모로,이 TCP 동작은 인터넷이 “혼잡 축소”에 잠기는 것을 막는 것입니다.
응용 프로그램을 UDP로 푸시하는 경향이있는 것 :
-
그룹 전달 시맨틱 : TCP의 지점 간 인식보다 훨씬 효율적으로 그룹의 사람들에게 안정적인 전달을 수행 할 수 있습니다.
-
비 순차적 전달 : 많은 응용 프로그램에서 모든 데이터를 얻는 한 어떤 순서로 전달되는지 상관하지 않습니다. 비 순차적 블록을 수락하여 앱 수준 대기 시간을 줄일 수 있습니다.
-
친숙하지 않음 : LAN 파티에서는 가능한 한 빨리 네트워크 업데이트를 블리 팅하는 한 웹 브라우저가 제대로 작동하는지 신경 쓰지 않을 수 있습니다.
그러나 성능에 관심이 있어도 UDP를 사용하고 싶지 않을 것입니다.
-
지금은 안정성을 추구하고 있으며 안정성을 구현하기 위해 할 수있는 많은 것들이 TCP보다 이미 느려질 수 있습니다.
-
이제 네트워크에 친숙하지 않아 공유 환경에서 문제가 발생할 수 있습니다.
-
가장 중요한 것은 방화벽이 사용자를 차단한다는 것입니다.
여러 TCP 연결을 “트렁킹”하여 일부 TCP 성능 및 대기 시간 문제를 잠재적으로 극복 할 수 있습니다. iSCSI는 로컬 영역 네트워크에서 혼잡 제어를 피하기 위해이를 수행하지만 대기 시간이 짧은 “긴급”메시지 채널을 생성하기 위해이를 수행 할 수도 있습니다 (TCP의 “URGENT”동작이 완전히 중단됨).
답변
일부 응용 프로그램에서 TCP는 UDP보다 처리 속도가 빠릅니다.
이것은 MTU 크기에 비해 많은 수의 작은 쓰기를 수행하는 경우입니다. 예를 들어, 300 바이트 패킷 스트림이 이더넷을 통해 전송되고 (1500 바이트 MTU) TCP가 UDP보다 50 % 더 빠른 실험을 읽었습니다 .
TCP가 데이터를 버퍼링하고 전체 네트워크 세그먼트를 채우므로 사용 가능한 대역폭을보다 효율적으로 사용하기 때문입니다.
반면에 UDP는 패킷을 유선으로 연결하여 많은 작은 패킷으로 네트워크를 정체시킵니다.
특별한 이유가 없다면 UDP를 사용해서는 안됩니다. 특히 Nagle 알고리즘 을 비활성화하여 TCP에 UDP와 동일한 대기 시간을 제공 할 수 있기 때문에 (예를 들어 실시간 센서 데이터를 전송하고 많은 작은 패킷으로 네트워크를 혼잡하게 할 염려가없는 경우).
답변
손실 허용
“손실 허용 오차 포함”을 의미합니까?
기본적으로 UDP는 “손실 허용”이 아닙니다. 누군가에게 100 개의 패킷을 보낼 수 있으며, 그 패킷 중 95 개만 가져올 수 있으며 일부는 잘못된 순서 일 수 있습니다.
비디오 스트리밍 및 멀티 플레이어 게임과 같은 다른 모든 패킷을 지연시키는 것보다 패킷을 놓치는 것이 더 나은 경우에는 이것이 명백한 선택입니다.
그러나 대부분의 경우 누락되거나 ‘재배치 된’패킷이 중요합니다. 누락 된 경우 다시 시도하고 올바른 순서를 적용하려면 UDP 위에서 실행할 추가 코드를 작성해야합니다. 특정 장소에서는 약간의 오버 헤드가 발생합니다.
고맙게도 매우 똑똑한 사람들이이 작업을 수행했으며이를 TCP라고했습니다.
패킷이 누락 된 경우 가능한 빨리 다음 패킷을 가져 와서 계속 (UDP 사용) 또는 누락 된 데이터가 실제로 필요합니까 (TCP 사용)? 실제 시나리오가 아니라면 오버 헤드는 중요하지 않습니다.
답변
UDP 또는 TCP 중 어떤 프로토콜이 더 나은 성능 (처리량 측면에서)인지는 실제로 네트워크 특성과 네트워크 트래픽에 따라 다릅니다. 예를 들어 Robert S. Barnes는 TCP의 성능이 향상되는 시나리오 (작은 쓰기)를 지적합니다. 이제 네트워크가 정체되고 TCP 및 UDP 트래픽이 모두있는 시나리오를 고려하십시오. TCP를 사용하는 네트워크의 발신자는 ‘정체’를 감지하고 전송 속도를 줄입니다. 그러나 UDP에는 혼잡 방지 또는 혼잡 제어 메커니즘이 없으며 UDP를 사용하는 발신자는 계속 동일한 속도로 데이터를 펌핑합니다. 점차적으로 TCP 발신자는 전송 속도를 최소 수준으로 낮추고 UDP 발신자가 네트워크를 통해 전송하기에 충분한 데이터를 가지고 있다면 가용 대역폭의 대부분을 차지하게됩니다. 이런 경우에는 UDP 발신자는 네트워크 대역폭의 파이가 커질수록 처리량이 더 커집니다. 실제로 이것은 활발한 연구 주제입니다-UDP 트래픽이있을 때 TCP 처리량을 개선하는 방법입니다. 처리량을 향상시킬 수있는 TCP 응용 프로그램을 사용하는 한 가지 방법은 여러 TCP 연결을 여는 것입니다. 이렇게하면 각 TCP 연결의 처리량이 제한 될 수 있지만 모든 TCP 연결의 처리량의 총계는 UDP를 사용하는 응용 프로그램의 처리량보다 클 수 있습니다.
답변
“더 빠른 것”에 대해 말하면 처리량과 대기 시간이라는 두 가지 측면이 있습니다.
처리량 에 대해 말하면 -TCP의 흐름 제어 (다른 답변에서 언급했듯이)는 매우 중요하며 UDP와 비교할 수있는 모든 작업은 가능하지만 Big Headache ™입니다. 결과적으로 처리량 이 필요할 때 UDP를 사용하면 TCP보다 불공정 한 이점을 얻지 않는 한 좋은 아이디어로 간주되지 않습니다.
그러나 대기 시간 에 대해 말하면 모든 것이 완전히 다릅니다. 패킷 손실이없는 경우 TCP와 UDP는 매우 유사하게 작동하지만 (만약 있다면 차이가 거의 없음) 패킷이 손실 된 후 전체 패턴이 크게 변경됩니다.
패킷 손실 후 TCP는 최소 200ms 동안 재전송을 기다립니다 (RFC6298의 2.4 항당 1 초이지만 실제적인 최신 구현에서는이를 200ms로 줄이는 경향이 있습니다). 또한 TCP를 사용하면 대상 호스트에 도달 한 패킷조차도 누락 된 패킷이 수신 될 때까지 앱에 전달되지 않습니다 (즉, 전체 통신이 ~ 200ms 지연됨)-BTW,이 효과는 Head-of -회선 차단은 TCP 또는 신뢰할 수있는 + 순서화 된 UDP에 관계없이 모든 신뢰할 수있는 순서화 된 스트림에 내재되어 있습니다. 재전송 된 패킷도 손실되면 ~ 600ms 지연 (소위 지수 백 오프, 첫 번째 재전송은 200ms, 두 번째는 200 * 2 = 400ms)에 대해 이야기합니다. 채널에 1 %의 패킷 손실이있는 경우 (오늘날의 표준으로는 나쁘지 않습니다), 초당 20 번의 업데이트가있는 게임이 있습니다. 이러한 600ms 지연은 평균 8 분마다 발생합니다. 그리고 600ms는 빠르게 진행되는 게임에서 당신을 죽일 수있을만큼 충분하기 때문에 게임 플레이에는 좋지 않습니다. 이러한 효과는 gamedevs가 종종 TCP보다 UDP를 선호하는 이유입니다.
그러나 지연 시간을 줄이기 위해 UDP를 사용하는 경우 “UDP를 사용하는 것”만으로도 상당한 대기 시간을 개선하기에 충분하지 않다는 사실을 알아야합니다. 특히, RUDP 라이브러리는 일반적으로 “지수 백 오프”를 피하고 더 짧은 재전송 시간을 사용합니다. “신뢰할 수있는 정렬 된”스트림으로 사용되는 경우 여전히 라인 헤드 블로킹으로 인해 어려움을 겪습니다 (더블 인 경우). 패킷 손실은 600ms 대신 약 1.5 * 2 * RTT를 얻습니다. 또는 80ms RTT는 ~ 250ms 지연으로 개선되었지만 여전히 더 잘 수행 할 수 있습니다). 한편, http://gafferongames.com/networked-physics/snapshot-compression/ 및 / 또는 http : // ithare 에서 논의 된 기술을 사용하는 경우 . Head-of-Line 차단을 완전히 제거 할 수 있습니다 (초당 20 번 업데이트하는 게임의 더블 패킷 손실의 경우 RTT에 관계없이 지연 시간은 100ms입니다).
당신은 단지 TCP하지만 UDP에 액세스 할 수있는 일이있는 경우 (예 : 브라우저 등을 클라이언트가 UDP를 차단 추한 방화벽 6 ~ 9 %를 한 뒤에있는 경우, 또는) – – 그리고 보조 노트로이 보인다 에 방법이 대기 시간이 너무 길지 않고 UDP-over-TCP를 구현하려면 여기를 참조하십시오 : http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (주석도 읽어보십시오 (!)).
답변
각 TCP 연결에는 데이터가 전송되기 전에 초기 핸드 셰이크가 필요합니다. 또한 TCP 헤더에는 다른 신호 및 메시지 전달 감지를위한 많은 오버 헤드가 포함되어 있습니다. 메시지 교환의 경우, 약간의 실패 가능성이 허용되면 UDP로 충분합니다. 영수증을 확인해야하는 경우 TCP가 최선의 선택입니다.