UDP 대 TCP, 얼마나 빠릅니까? [닫은]

일부 패킷 손실을 허용 할 수있는 일반적인 프로토콜 메시지 교환. 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 (tm)입니다. 결과적으로 처리량 이 필요할 때 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가 최선의 선택입니다.

@Andrew , 나는달라고 간청한다. 성능 요구 사항 때문에 일부 응용 프로그램에서는 UDP가 선택됩니다. 전형적인 예는 화상 회의입니다. 이러한 종류의 응용 프로그램은 TCP 제어에 제대로 응답하지 않습니다.

고려해야 할 다른 측면은 멀티 캐스트가 필요한 경우입니다. 그렇다면 UDP를 사용하십시오.

아직까지 말하지 않은 두 IP 사이에 그물을 통해 메시지를 빠르게 보내야하는 경우 UDP는 최소 3 배, 보통 5 배 더 빨리 도착합니다.

나는 단지 일을 명확히 할 것입니다. TCP / UDP 는 도로에서 운전되는 두 대의 차량입니다. 교통 표지 및 장애물이 오류라고 가정하십시오. TCP 는 교통 표지를 관리하고 주변의 모든 것을 존중합니다. 차에 무슨 일이 일어날 수 있기 때문에 천천히 운전하십시오. UDP가 막 떨어져 나가는 동안 도로 표지판과 관련이없는 최고 속도. 아무것도, 미친 운전사. UDP 에는 오류 복구가 없습니다. 장애물이 있으면 충돌하여 계속 진행합니다. TCP 는 모든 패킷이 완벽하게 전송 및 수신되도록 보장 하지만 오류 없음이므로 자동차는 충돌하지 않고 장애물을 통과합니다. 나는 이것이 게임에서 UDP 가 선호되는 이유를 이해하기위한 좋은 예라고 희망합니다 . 게임에는 속도가 필요합니다. 다운로드에 TCP 가 있거나 다운로드 한 파일이 손상되었을 수 있습니다.

UDP는 내 경험에서 약간 빠르지 만 별로는 아닙니다. 성능이 아니라 메시지 내용 및 압축 기술을 선택해야합니다.

그것이 메시지 교환을 가진 프로토콜이라면 , TCP로 인한 약간의 성능 저하가 그만한 가치가 있다고 제안합니다. 필요한 모든 것을 제공하는 두 개의 엔드 포인트 사이에 연결되어 있습니다. 실제로 자신이 맡고있는 일에 대해 확신이 없으면 UDP를 기반으로 신뢰할 수있는 양방향 프로토콜을 시도하거나 제조하지 마십시오.

TCP는 일반적으로 여러 메시지를 유선으로 유지합니다. UDP로 이것을 구현하려면 안정적으로 수행하려면 많은 작업이 필요합니다. 귀하의 솔루션은 안정성이 떨어지거나 빠르거나 엄청난 양의 작업이 될 것입니다. UDP의 유효한 응용 프로그램이 있지만이 질문을하면 아마 그렇지 않을 것입니다.

프로그래머가 두 세계의 혜택을 누릴 수 있도록 몇 가지 작업이 수행되었습니다.

SCTP

독립적 인 전송 계층 프로토 롤이지만 UDP를 통해 추가 계층을 제공하는 라이브러리로 사용할 수 있습니다. 기본 통신 단위는 메시지입니다 (하나 이상의 UDP 패킷에 매핑 됨). 혼잡 제어 기능이 내장되어 있습니다. 프로토콜에는 스위치를 켤 수있는 노브와 트위들이 있습니다.

• 메시지 배달
• 사용자 정의 매개 변수를 사용하여 손실 된 메시지 자동 재전송

이 중 하나가 특정 응용 프로그램에 필요한 경우.

이것의 한 가지 문제는 연결 설정이 복잡하므로 프로세스가 느리다는 것입니다

다른 유사한 것들

• https://ko.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

하나 더 유사한 독점적 실험적인 것

• https://ko.wikipedia.org/wiki/QUIC

또한 TCP의 3 중 핸드 셰이크를 개선하고 혼잡 제어를 변경하여 빠른 회선을보다 잘 처리하려고합니다.

네트워크 상태를 고려하지 않고 TCP 또는 UDP에 대해 이야기하는 것은 의미가 없습니다. 두 지점 사이의 네트워크 품질이 매우 높은 경우 UDP는 TCP보다 절대적으로 빠르지 만 GPRS 네트워크와 같은 다른 경우에는 TCP가 UDP보다 빠르고 신뢰성이 높을 수 있습니다.

네트워크 설정은 모든 측정에 중요합니다. 로컬 컴퓨터의 소켓을 통해 또는 다른 쪽 끝과 통신하는 경우 큰 차이가 있습니다.

토론에 추가하고 싶은 세 가지 :

1. 여기에서 찾을 수 있습니다 게임 개발의 맥락에서 TCP 대 UDP에 대한 아주 좋은 기사를.
2. 또한, iperf ( jperf 는 GUI로 iperf를 향상시킵니다)는 측정하여 질문에 스스로 대답 할 수있는 매우 유용한 도구입니다.
3. 파이썬에서 벤치 마크를 구현했습니다 ( 이 SO 질문 참조 ). 평균 10 ^ 6 반복의 경우 8 바이트 전송의 차이는 UDP의 경우 약 1-2 마이크로 초입니다.