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

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

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

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

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

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

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

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

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

Wikipedia에서 :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

정답은 "의존적"이며 "네트워크 전체를 손상시킬 수 있기 때문"입니다. 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가 증가함에 따라 가장 효과적인 혼잡 제어 기능을 보여줍니다.

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

TCP! = UDP + 신뢰성

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

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

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

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

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

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

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