UDP 대 TCP, 얼마나 빠릅니까?

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

---

일부 패킷 손실을 허용 할 수있는 일반적인 프로토콜 메시지 교환. TCP를 통한 UDP는 얼마나 더 효율적입니까?

---

UDP는 TCP보다 빠르며 간단한 이유는 TCP 창 크기 및 왕복 시간 (RTT)을 사용하여 계산 된 패킷 집합을 확인하는 TCP 대신 연속 패킷 스트림을 허용하는 존재하지 않는 확인 패킷 (ACK)이기 때문입니다. ).

자세한 내용은 간단하지만 이해하기 쉬운 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를 선호하는 이유입니다.

However, when using UDP to reduce latencies - it is important to realize that merely "using UDP" is not sufficient to get substantial latency improvement, it is all about HOW you're using UDP. In particular, while RUDP libraries usually avoid that "exponential backoff" and use shorter retransmit times - if they are used as a "reliable ordered" stream, they still have to suffer from Head-of-Line Blocking (so in case of a double packet loss, instead of that 600ms we'll get about 1.5*2*RTT - or for a pretty good 80ms RTT, it is a ~250ms delay, which is an improvement, but it is still possible to do better). On the other hand, if using techniques discussed in http://gafferongames.com/networked-physics/snapshot-compression/ and/or http://ithare.com/udp-from-mog-perspective/#low-latency-compression , it IS possible to eliminate Head-of-Line blocking entirely (so for a double-packet loss for a game with 20 updates/second, the delay will be 100ms regardless of RTT).

And as a side note - if you happen to have access only to TCP but no UDP (such as in browser, or if your client is behind one of 6-9% of ugly firewalls blocking UDP) - there seems to be a way to implement UDP-over-TCP without incurring too much latencies, see here: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (make sure to read comments too(!)).

---

Each TCP connection requires an initial handshake before data is transmitted. Also, the TCP header contains a lot of overhead intended for different signals and message delivery detection. For a message exchange, UDP will probably suffice if a small chance of failure is acceptable. If receipt must be verified, TCP is your best option.

---

@Andrew, I beg to differ. UDP is the choice in some kinds of application because of performance requirements. One classic example is video conferencing. This kind of application doesn't respond well to TCP control.

Other aspect to take in consideration is if you're going to need multicast. If so, use UDP.

---

If you need to quickly blast a message across the net between two IP's that haven't even talked yet, then a UDP is going to arrive at least 3 times faster, usually 5 times faster.

---

UDP is slightly quicker in my experience, but not by much. The choice shouldn't be made on performance but on the message content and compression techniques.

If it's a protocol with message exchange, I'd suggest that the very slight performance hit you take with TCP is more than worth it. You're given a connection between two end points that will give you everything you need. Don't try and manufacture your own reliable two-way protocol on top of UDP unless you're really, really confident in what you're undertaking.

---

I will just make things clear. TCP/UDP are two cars are that being driven on the road. suppose that traffic signs & obstacles are Errors TCP cares for traffic signs, respects everything around. Slow driving because something may happen to the car. While UDP just drives off, full speed no respect to street signs. Nothing, a mad driver. UDP doesn't have error recovery, If there's an obstacle, it will just collide with it then continue. While TCP makes sure that all packets are sent & received perfectly, No errors , so , the car just passes obstacles without colliding. I hope this is a good example for you to understand, Why UDP is preferred in gaming. Gaming needs speed. TCP is preffered in downloads, or downloaded files may be corrupted.

---

Keep in mind that TCP usually keeps multiple messages on wire. If you want to implement this in UDP you'll have quite a lot of work if you want to do it reliably. Your solution is either going to be less reliable, less fast or an incredible amount of work. There are valid applications of UDP, but if you're asking this question yours probably is not.

---

There has been some work done to allow the programmer to have the benefits of both worlds.

SCTP

It is an independent transport layer protolol, but it can be used as a library providing additional layer over UDP. The basic unit of communication is a message (mapped to one or more UDP packets). There is congestion control built in. The protocol has knobs and twiddles to switch on

• in order delivery of messages
• automatic retransmission of lost messages, with user defined parameters

if any of this is needed for your particular application.

One issue with this is that the connection establishment is a complicated (and therefore slow process)

Other similar stuff

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

One more similar proprietary experimental thing

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

This also tries to improve on the triple way handshake of TCP and change the congestion control to better deal with fast lines.

---

It is meaningless to talk about TCP or UDP without taking the network condition into account. If the network between the two point have a very high quality, UDP is absolutely faster than TCP, but in some other case such as the GPRS network, TCP may been faster and more reliability than UDP.

---

The network setup is crucial for any measurements. It makes a huge difference, if you are communicating via sockets on your local machine or with the other end of the world.

Three things I want to add to the discussion:

1. You can find here a very good article about TCP vs. UDP in the context of game development.
2. Additionally, iperf (jperf enhance iperf with a GUI) is a very nice tool for answering your question yourself by measuring.
3. I implemented a benchmark in Python (see this SO question). In average of 10^6 iterations the difference for sending 8 bytes is about 1-2 microseconds for UDP.

참고URL : https://stackoverflow.com/questions/47903/udp-vs-tcp-how-much-faster-is-it