신뢰성있는 UDP (응용 프로그램 계층에서 구현)가 TCP를 대체하지 않는 이유는 무엇입니까?


25

TCP는 전송 계층에서 안정성을 제공하지만 UDP는 그렇지 않습니다. 따라서 UDP는 빠릅니다. 그러나 응용 프로그램 계층의 프로토콜은 UDP를 사용하는 동안 안정적인 메커니즘을 구현할 수 있습니다.

이런 점에서 신뢰성이 필요한 UDP가 TCP보다 빠르고 신뢰성이 필요한 경우 신뢰성이있는 UDP (응용 프로그램 계층에서 구현)가 TCP를 대체하지 않는 이유는 무엇입니까?


6
TCP와 같은 널리 사용 가능한 다른 프로토콜에 의존 할 때 모든 응용 프로그램이 자체 안정성 메커니즘을 제공하는 이유는 무엇입니까?
Nakrule

14
그리고 스택 속도를 늦추지 않고 응용 프로그램 계층에서 안정성을 구현하도록 어떻게 제안합니까?
JFL

6
" UDP 헤더는 TCP보다 작기 때문에, 우리는 데이터 크기를 활용할 수 있습니다. "그 사고의 문제는 아마에서 사용할 수있는 데이터를 감소 응용 프로그램 계층 프로토콜 헤더와 UDP 페이로드의 많은 먹을 것입니다 UDP 페이로드 TCP와 UDP 헤더 크기의 차이는 12 바이트입니다. 또한 UDP는 실제로 작은 페이로드 (예 : 576 바이트)를 위해 설계되었습니다. UDP는 단순히 데이터 그램을 잃게되며 데이터 그램에 더 많은 데이터가있을수록 데이터 그램이 손실 될 때 더 많은 데이터가 손실됩니다.
Ron Maupin

21
스택 오버플로 는 프로그래머가 UDP를 사용하여 TCP와 유사한 프로토콜을 만들려고 시도하고 실패하는 경우에 발생합니다. 보다 숙련 된 프로그래머는이를 포기하고 TCP 만 사용하도록 지시합니다. 그들은 모두 더 나은 일을 할 수 있다고 생각하지만 그럴 가능성은 적습니다.
Ron Maupin

11
이것이 귀하의 질문의 일부가 아니라는 것을 알고 있지만 UDP가 더 나은 이유 중 하나는 필요한 신뢰성 부분 만 구현할 수 있기 때문입니다. TCP를 사용하면 주문 및 배송에 대한 신뢰성을 얻을 수 있습니다. 이것은 TCP가 이전 메시지가 재전송되기를 기다리는 동안 딸꾹질을 가질 수 있음을 의미합니다. UDP를 사용하면 원하는 것이 배달이라고 결정할 수 있지만, 메시지가 잘못 도착하면 누락 된 메시지를 기다리지 않고 그냥 버립니다. 사람들이 겪고있는 함정은 TCP 100 %를 복제하려고합니다. 이 경우 TCP 만 사용하십시오.
윌리엄 마리아 거

답변:


47

TCP는 안정성 속성으로 무언가를 만들 수있는 것만 큼 빠릅니다. 예를 들어 시퀀싱 및 오류 감지 만 필요한 경우 UDP를 완벽하게 제공 할 수 있습니다. 이는 음성, 비디오 스트리밍 등과 같은 대부분의 실시간 프로토콜의 기초이며 "절대"오류 수정보다 지연 및 지터가 더 중요합니다.

기본적으로 TCP는 스트림을 결국 신뢰할 수 있다고 말합니다.. 얼마나 빠른가는 다양한 타이머, 속도 등에 따라 달라집니다. 오류를 해결하는 데 걸리는 시간은 예측할 수 없지만 오류가없는 경우 기본 작업은 가능한 한 빠릅니다. 시스템이 발생할 수있는 오류 종류에 대해 알고 있으면 TCP로는 불가능한 작업을 수행 할 수 있습니다. 예를 들어, 단일 비트 오류가 특히 발생하는 경우 해당 비트 오류에 대해 오류 수정 코딩을 사용할 수 있습니다. 그러나 이는 링크 계층에서 훨씬 더 잘 구현됩니다. 또 다른 예로, 전체 패킷 손실의 짧은 버스트가 일반적인 경우 손실을 기다리지 않고 여러 전송으로이 문제를 해결할 수 있지만 분명히 대역폭이 비쌉니다. 또는 오류 확률이 무시할 수있을 때까지 속도를 늦 춥니 다. 또한 대역폭이 비쌉니다. 결국

구현 측면에서 볼 때 TCP에 투자 한 프로그래머 세기는 일반적인 경우보다 더 빠를뿐만 아니라 모호한 경우에 더 안정적 일 것입니다.

TCP는 다음을 제공합니다. 임의의 거리 다중 홉 네트워크에 대한 혼잡 제어를 통해 신뢰할 수 있고 순서가 지정된 (및 중복 제거 된) 양방향의 창 바이트 스트림을 제공하는 유비쿼터스 연결 방법 (통신 시스템에 공통 제어가없는 경우).

응용 프로그램에 편재성이 필요하지 않거나 (소프트웨어가 양쪽에서 실행 됨) 모든 TCP 기능이 필요하지 않은 경우, 많은 사람들이 종종 UDP 외에 다른 프로토콜을 사용하는 것이 유리합니다. 예를 들어 TFTP (실제로 비효율적 인 오류 처리 기능이있는 최소한의 오류 처리, 오버 헤드를 줄 이도록 설계된 QUIC (여전히 실험으로 표시)) 및 lidgren과 같은 라이브러리는 정확히 어떤 신뢰성 기능이 필요한지 정밀하게 제어 할 수 있습니다. ]


7
맞춤형 "신뢰성을 갖춘 UDP"프로토콜도 비디오 게임에서 매우 일반적입니다. 다양한 구현을 가진 수많은 네트워킹 라이브러리가 있습니다. 그들은 일반적으로 손실 된 패킷의 재전송 (및 모든 미래 패킷의 지연 수신)을 원하지 않고 패킷을 주문하고 오류를 수정하기를 원합니다.
BlueRaja-대니 Pflughoeft

"TCP는 최적의 일반 솔루션이므로 기본적으로 지원합니다"라고 말하는 것처럼 들립니다. +1
이케 가미

1
@ BlueRaja-DannyPflughoeft 때로는 신뢰할 수있는 정렬되지 않은 패킷 (예 : 근처 플레이어에 적용되는 시각 효과)이 필요합니다.
user253751

@ BlueRaja-DannyPflughoeft 만약 당신이 전형적인 예제 프로토콜 라이브러리를 가지고 있다면 정답에 기꺼이 통합 할 것입니다
jonathanjo

1
@jonathanjo 내가 사용한 것 중 하나는 lidgren 이며, 5 가지 배달 방법 을 지원 합니다 (아래로 스크롤) . UnityUnreal Engine 에는 UDP 위에 구축 된 자체 네트워킹 API가 있습니다.
BlueRaja-대니 Pflughoeft

10

신뢰성있는 UDP는 실제로 TCP를 대체 할 수 있습니다. 우리는 이미 그 예를 가지고 있습니다 : QUIC .

Wikipedia에서 :

다른 응용 프로그램 중에서 QUIC는 현재 TCP를 사용하는 연결 지향 웹 응용 프로그램의 성능을 향상시킵니다. UDP (User Datagram Protocol)를 통해 두 엔드 포인트간에 여러 개의 다중 연결을 설정하여이를 수행합니다.

UDP를 사용하여 새로운 전송 계층 프로토콜을 만드는 것의 장점은 라우터와 다른 네트워크 장치가 이미 이해하고 있다는 것입니다.


QUIC는 TCP와 약간 다른 특성을 가지고 있습니다. 일부 시나리오 (신뢰할 수있는 네트워크 또는 암호화가 필요하지 않은 경우) quora.com/…
괴물

sctp를 통해 UDP를 사용하는 목록에 WebRTC 데이터 채널을 추가 할 수도 있습니다. 실제로 피어간에 UDP 연결이 불가능한 경우 WebRTC는 TCP로 페일 오버하여 성능이 눈에 띄게 떨어집니다.
JSON

이 경우 @freakish slower는 일반화입니다. 예를 들어 QUIC는 패킷에 추가 데이터를 추가하여 재전송을 줄여 처리량에 영향을 주지만 대기 시간에는 영향을 미치지 않습니다.
JSON

4

UDP를 사용하여 응용 프로그램 계층에서 TCP 기능을 구현할 수 있습니다 (신뢰성, 적응성). 응용 프로그램에서 실제로 필요한 것을 TCP로 수행 할 수 없다면 TCP를 처음부터 사용할 수 있습니다. 이러한 기능을 직접 구현하면 TCP보다 훨씬 나빠질 수 있습니다. 추가 된 오버 헤드는 전체 효율성도 감소시킵니다.

TCP는 느리지 않습니다. 전송하기 전에 핸드 셰이크 만 있으면되고 전송 창은 채널에 맞게 조정됩니다. 전송 채널에 대한 처리량을 매우 잘 형성하고 흐름 중에 변경 사항에 적응할 수 있으며 UDP는 자체적으로 수행 할 수 없습니다.

그러나 전송 계층 위의 프로토콜은 여기서 주제가 맞지 않습니다.


3
"UDP를 사용하여 응용 프로그램 계층에서 TCP 기능을 구현할 수 있습니다 (신뢰성, 적응성). 실제로 QUIC, µTP 및 SCTP가 이미 구현 된 방식이라고 생각합니다. (UDP는 아래쪽에 앉아있는 동안 그럼에도 불구하고, 나는 보통, 전송 계층의 상반부에있는 것으로를 고려한다.)
grawity

1
@grawity POV에 따라 다릅니다. 응용 프로그램 관점에서 중간 계층은 전송 계층의 확장입니다. 공식적으로 그리고 네트워크 (장치) 관점에서 볼 때, 그것은 모두 응용 계층의 일부입니다.
Zac67

4

깨끗한 네트워크에서 그들은 상당히 동등합니다. TCP가 일정 기간 동안 중단되는 경우가 있습니다 (누구든지 HTTP 화면이 정지되는 것을 보았습니까?). 가비지를 전달하지 않거나 패킷을 혼합하여 거의 포기하지 않습니다.

UDP는 많은 작업 비용으로 애플리케이션 계층에 트래픽을보다 효과적으로 제어 할 수 있습니다.

귀하의 질문에 대한 답변은 때로는 그렇게하는 것입니다. 짧은 대기 시간이 필요한 게임은 종종 정확히 그렇게합니다. 더 많은 작업이 필요하지만 얼마나 많은 미해결 패킷을 가질 수 있는지와 얼마나 자주 재 시도 할 것인지를 제어하는 ​​능력은 종종 가치가 있습니다.

따라서 전체적인 차이점은 TCP가 일반적인 범용 구현이라는 점이지만 UDP가 TCP의 성능을 저하 시키거나 전혀 수행하지 않는 특별한 목적이 있습니다.

  • 절대 포기하지 마십시오 (TCP를 사용하면 연결이 끊어지고 연결을 끊고 다시 시작해야 함)
  • 답글을 요구하지 않는 빠른 패킷 스트림을 전송하고 때로는 최신 패킷 만 중요하고 다른 패킷을 버릴 수있는 경우가 있습니다. 게임 위치 업데이트를 생각하면 각 단계가 아니라 "점프"하지만 동일한 결과를보다 빠르고 안정적으로 얻을 수 있습니다.
  • 패킷 손실을 분석하고 재시도 빈도와 재시도 속도를 동적으로 변경하여 iffy 네트워크를 처리하는 것은 최대 패킷 크기 일 수도 있습니다.

그러나 일반적으로 가치가 없습니다 .TCP는 매우 최적이므로 왜 모든 추가 작업을 수행하고 버그와 보안 결함을 추가 할 수있는 (큰) 기회를 추가합니까?


3

UDP는 UDP이므로 빠르지 않습니다. TCP는 TCP이므로 느리지 않습니다.

두 프로토콜 모두 특정 보증으로 설계되었으며 원시 TCP는 원시 UDP보다 더 많은 보증을 제공합니다.

경험의 원칙은 보증 가격이 성능 입니다.

UDP를 통한 TCP 보증 구현을 금지하는 것은 없습니다. 그러나 더 많은 보증을 받으므로 가격을 지불해야합니다. 따라서 UDP 오버 헤드로 인해 성능이 TCP 이상으로 저하됩니다. 더 나은 TCP 구현을 알지 못하는 경우는 거의 없습니다. 그리고 만약 당신이 그렇게한다면 (희망) 당신은 그것을 공개하고 표준 TCP를 더 빨리 만듭니다. 그리고 우리는 시작한 곳으로 돌아 왔습니다. :)

당신은 또한 그 보증을 가지고 놀 수 있습니다. 약간 수정하고 약간 수정하십시오. 그런 다음 UDP를 통한 QUIC 와 같은 프로토콜 로 끝나고 TCP + TLS와 매우 유사합니다. 대부분의 경우 TCP보다 빠릅니다 ( 이 기사 에 따르면 최대 5 %, 최대 15 %의 버퍼링으로 IMO가 큰 문제는 아니지만). 그러나 일부 시나리오 (예 : 안정적인 네트워크 또는 암호화가 필요하지 않음)에서는 실제로 느리게 ( 여기에 대한 설명 참조 ).

당신은 또한 그 보증을 약화시킬 수 있고 더 이해가됩니다. 예를 들어 스트리밍 중이고 오래된 패킷은 흥미롭지 않다고 가정하십시오. 가장 최근에만. 그러나 정체는 여전히 중요합니다. 따라서 TCP를 보장하지만 전부는 아닙니다. 그렇습니다. 사람들은 실제로 그렇게합니다 (예 : 실시간 게임). 이는 일부 보증 비용으로 더 나은 성능을 제공합니다.


1

당신의 아이디어는 깊은 우주에서 좋을 것입니다.

정답은 "의존적"이며 "네트워크 전체를 손상시킬 수 있기 때문"입니다. TCP / IP는 네트워크에 매우 친절하며 빠른 속도로 적절한 속도로 자동 조정되지만 많은 톤의 ICMP 리턴 패킷을 생성하지 않습니다.

RAM이 충분하지 않은 라우터가 갑자기 쓰나미, 비트 토렌트 또는 FDT와 같은 많은 종류의 패킷을 받으면이를 삭제하고 발신자에게 작은 실패의 비 확인 패킷을 보냅니다. 이제 UDP 서버는 해당 부분을 수동으로 추적하고 다시 전송해야합니다. 일부 ISP 라우터는 Bittorrent를 너무 많이 형성하여 쓰나미를 해칠까요?

Tsunami 프로토콜은 TCP에서 제어 채널과 함께 UDP를 사용합니다. http://tsunami-udp.sourceforge.net/ FDT라는 것보다 느리다는 연구 결과가 있습니다.

CERN의 전설적인 FDT (Fast Data Transfer) 프로토콜은 여러 TCP 스트림을 사용하여 모든 네트워크를 포화시킬 수 있습니다. 아마도 많은 양의 UDP로 네트워크에 쇄도하는 쓰나미가 재전송을 적게하기 때문에 더 빠를 것입니다. 일부 네트워크는 완전히 통과하지 못합니다.

UDP는 신뢰할 수없는 응용 프로그램에서 사용됩니다. 스트리밍 오디오, 게임 입력 / 업데이트 IO, "ping"은 실제로는 ICMP이지만 보장되지는 않습니다. 이상한 누락 패킷을 신경 쓰지 않고 즉시 "캐치"할 수있는 모든 것.

TCP / IP는 실제로 앱 개발자가 설정하고 잊어 버릴 수있는 킬러 발명이었습니다. 소켓은 한 쌍의 IP 주소와 포트이며, 다시 연결하지 않고도 몇 시간, 며칠, 몇 주 동안 설정 및 유지 될 수 있도록 설계되었습니다. 이메일, 웹, IRC 및 문자 그대로 모든 킬러 앱은 TCP를 사용합니다. 그러나 다운로드 속도가 갑자기 빨라지는 이상한 일이 생길 수 있습니다. 깊은 공간에서 연결하면 시간이 지남에 따라 쓰나미 스타일 전송이 가장 효과적 일 수 있습니다.

그 증거는이 과학 연구 추출물의 마지막 말에 있습니다. 여기에는 제가 계속 진행할 거리가 멀다는 것을 언급합니다 : 딥 스페이스 From : https://uscholar.univie.ac.at/get/o:300623.pdf

혼잡이 없으면 TCP를 통한 FDT 및 GridFTP의 성능은 쓰나미 및 UDT보다 높습니다. FDT의 최고 처리량은 1ms RTT에서 2.34Gb / s이지만 GridFTP에 비해 100ms 후에 급격히 감소합니다. 이는 링크 RTT가 100ms보다 길면 FDT보다 성능이 뛰어납니다. 흥미롭게도 쓰나미의 처리량은 RTT가 증가해도 감소하지 않았으며 RTT가 증가함에 따라 가장 효과적인 혼잡 제어 기능을 보여줍니다.

그리고 다시 ... 우주에는 더 나은 전자 메일과 유사한 우주 프로토콜이 있습니다. 앱은 영원히와 같은 시간 제한 값을 신경 쓰지 않아도됩니다.


0

TCP! = UDP + 신뢰성

TCP는 안정성이 추가 된 단순한 UDP가 아닙니다. TCP는 단순한 안정성보다 더 많은 기능을 제공합니다. 많은 RFC에서 이에 대해 읽을 수 있습니다.

이러한 기능은 응용 프로그램 계층에서 "구현"될 수 있습니다. 결국 바퀴를 다시 발명하기 시작하는 지점이됩니다.

TCP의 몇 가지 기능을 말하면 ...

  • 연결 생성 및 종료 : 핸드 셰이크 및 연결 종료 수행

  • 흐름 제어 : 발신자와 수신자 모두 데이터 속도를 처리 할 수있는 속도로 전송합니다.

  • 엔드 투 엔드 혼잡 제어 : 엔드 노드가 손실에 따라 처리량을 조절할 수 있습니다. 느린 시작, 정체 방지 및 빠른 복구에 대해 읽으십시오.

내 경험상 UDP가 속도가 안정성에 대한 우려가 될 때 사용됩니다. 응용 프로그램 수준에서 TCP만큼 100 % 신뢰할 수없는 수준의 안정성을 추가 할 수 있습니다. 예를 들어 여전히 빠른 성능을 원한다면 데이터를 두 번 이상 전송하는 FEC (Forward Error Correction)를 구현할 수 있습니다. 패킷을 잃어 버릴 수있는 앞뒤의 모든 채팅 대화없이 우수한 성능과 일정한 수준의 안정성 (꽤 TCP 안정성에 유의하십시오)을 얻습니다. 네트워크 사용률은 증가하지만 게임이나 스트리밍과 같은 실시간 애플리케이션에 적합 할 수 있다는 장점이 있습니다.


이러한 추가 기능에서 궁극적으로 안정성에 대해 설명 할 수 있습니다.
user207421
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.