TCP 대신 UDP를 사용하는 것이 언제 적절한가요? [닫은]

TCP는 패킷 전달을 보장하므로 "신뢰할 수있는"것으로 간주 될 수 있지만 UDP는 아무것도 보장하지 않으며 패킷이 손실 될 수 있습니다. TCP 스트림이 아닌 응용 프로그램에서 UDP를 사용하여 데이터를 전송하면 어떤 이점이 있습니까? 어떤 상황에서 UDP가 더 나은 선택이며 왜 그럴까요?

UDP는 스트림을 만들고 유지 관리하는 오버 헤드가 없으므로 UDP가 더 빠르다고 가정하지만 일부 데이터가 대상에 도달하지 않으면 관련이 없습니까?

이것은 내가 가장 좋아하는 질문 중 하나입니다. UDP가 너무 잘못 이해되었습니다.

다른 서버에 대한 간단한 답변을 빨리 얻고 싶은 경우 UDP가 가장 효과적입니다. 일반적으로 응답이 하나의 응답 패킷에 포함되기를 원하며 신뢰성을 위해 자체 프로토콜을 구현하거나 다시 보낼 준비가되었습니다. DNS는이 사용 사례에 대한 완벽한 설명입니다. 연결 설정 비용이 너무 높습니다 (아직 DNS는 TCP 모드도 지원합니다).

또 다른 경우는 새로운 데이터가 이전 데이터 / 상태를 대체하기 때문에 손실 될 수있는 데이터를 제공 할 때입니다. 날씨 데이터, 비디오 스트리밍, 주식 시세 서비스 (실제 거래에는 사용되지 않음) 또는 게임 데이터가 떠 오릅니다.

또 다른 경우는 엄청난 양의 상태를 관리하고 OS가 많은 세션을 처리 할 수 ​​없기 때문에 TCP를 사용하지 않는 경우입니다. 이것은 오늘날 드문 경우입니다. 실제로, 응용 프로그램 작성기가 해당 TCP 상태에 필요한 리소스를보다 세밀하게 제어 할 수 있도록 사용할 수있는 사용자 영역 TCP 스택이 있습니다. 2003 년 이전에는 UDP가 실제로 유일한 게임이었습니다.

다른 경우는 멀티 캐스트 트래픽입니다. UDP는 여러 호스트로 멀티 캐스트 될 수 있지만 TCP는이 작업을 전혀 수행 할 수 없습니다.

경우 TCP의 패킷이 손실되는, 그것은 다시 보내야합니다. 특정 순서로 실시간으로 처리되는 데이터에 의존하는 응용 프로그램에는 유용하지 않습니다.

예를 들어 비디오 스트리밍, 특히 VoIP (예 : Skype )가 있습니다. 그러나 그러한 경우에, 손실 된 패킷은 그다지 중요하지 않습니다 : 우리의 감각이 완벽하지 않으므로, 우리는 눈치 채지 못할 수도 있습니다. 이러한 유형의 응용 프로그램이 사용되는 이유 이 TCP 대신 UDP 를 입니다.

UDP의 "신뢰할 수 없음"은 형식입니다. 전송이 절대적으로 보장되는 것은 아닙니다. 실질적인 문제로, 그들은 거의 항상 통과합니다. 시간 초과 후에는 승인되지 않고 재 시도되지 않습니다.

TCP 소켓 협상 및 TCP 패킷 핸드 셰이 킹의 오버 헤드는 엄청납니다. 정말 큰. 인식 가능한 UDP 오버 헤드가 없습니다.

가장 중요한 것은 TCP보다 오버 헤드가 적은 안정적인 전달 핸드 셰이 킹으로 UDP를 쉽게 보완 할 수 있습니다. 이것을 읽으십시오 : http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP는 게시-구독 종류의 응용 프로그램에서 정보를 브로드 캐스트하는 데 유용합니다. IIRC, TIBCO는 상태 변경 알림을 위해 UDP를 많이 사용합니다.

다른 종류의 단방향 "중요한 이벤트"또는 "로깅"활동은 UDP 패킷으로 처리 할 수 ​​있습니다. 전체 소켓을 구성하지 않고 알림을 보내려고합니다. 다양한 청취자의 응답을 기대하지 않습니다.

시스템 "하트 비트"또는 "살아 있습니다"메시지도 좋은 선택입니다. 빠진 것은 위기가 아닙니다. 열 여섯 개가 누락되었습니다.

클라이언트와 서버 간의 UDP (IP) 및 TCP / IP 통신을 모두 지원하는 제품에서 작업하고 있습니다. 15 년 전에 IPX로 시작하여 13 년 전에 IP 지원이 추가되었습니다. 3 년 또는 4 년 전에 TCP / IP 지원을 추가했습니다. 사나운 추측 : UDP 대 TCP 코드 비율은 아마도 약 80/20입니다. 제품은 데이터베이스 서버이므로 안정성이 중요합니다. 우리는 다른 답변에서 이미 언급 한 UDP (패킷 손실, 패킷 배가, 패킷 순서 등)로 부과 된 모든 문제를 처리해야합니다. 거의 문제가 없지만 때때로 발생하기 때문에 처리해야합니다. UDP 지원의 이점은 자체 용도에 맞게 약간 사용자 정의하고 약간 더 성능을 조정할 수 있다는 것입니다.

모든 네트워크는 다를 수 있지만 UDP 통신 프로토콜은 일반적으로 조금 더 빠릅니다. 회의론자는 우리가 모든 것을 올바르게 이행했는지에 대해 의문을 가질 것입니다. 또한 2 자리 담당자가있는 사람에게서 무엇을 기대할 수 있습니까? 그럼에도 불구하고, 나는 방금 호기심에서 테스트를 실행했습니다. 이 테스트는 백만 개의 레코드를 읽습니다 (일부 테이블에서 * 선택). 각 개별 클라이언트 요청과 함께 리턴 할 레코드 수를 1, 10 및 100 (각 프로토콜에 대해 세 번의 테스트 실행)으로 설정했습니다. 서버는 100Mbit LAN을 통해 두 번 홉 떨어져있었습니다. 이 수치는 다른 사람들이 과거에 찾은 것과 일치하는 것으로 보입니다 (UDP는 대부분의 상황에서 약 5 % 빠릅니다). 이 특정 테스트의 총 시간 (밀리 초)은 다음과 같습니다.

1. 1 기록
   • IP : 390,760ms
   • TCP : 416,903ms
2. 10 기록
   • IP : 91,707ms
   • TCP : 95,662ms
3. 100 레코드
   • IP : 29,664ms
   • TCP : 30,968ms

전송 된 총 데이터 양은 IP와 TCP 모두에서 거의 동일했습니다. TCP / IP (체크섬, 시퀀스 번호 등)에서 "무료"로 얻을 수있는 것과 동일한 것들이 있기 때문에 UDP 통신에 추가 오버 헤드가 있습니다. 예를 들어, Wireshark는 다음 레코드 세트에 대한 요청이 UDP의 경우 80 바이트, TCP의 경우 84 바이트임을 보여주었습니다.

이 이미 많은 좋은 답변은 여기에 있습니다,하지만 난 하나 개를 추가 할 매우 잘 요약만큼 중요한 요소. UDP는 정체 제어를 사용하지 않기 때문에 올바른 조정으로 훨씬 높은 처리량을 달성 할 수 있습니다 . TCP의 혼잡 제어는 매우중대한. 연결의 현재 용량을 추정하여 네트워크 정체를 최소화하기 위해 연결 속도와 처리량을 제어합니다. 코어 네트워크와 같이 매우 안정적인 링크를 통해 패킷이 전송 되더라도 라우터의 크기는 제한적입니다. 이러한 버퍼는 용량을 채우고 패킷은 삭제되고 수신 된 승인이 없으면 TCP가이 삭제를 확인하여 용량 추정에 대한 연결 속도를 제한합니다. TCP는 slow start 이지만 처리량 (실제로는 정체 창))는 패킷이 삭제 될 때까지 천천히 증가한 다음, 패킷이 떨어질 때까지 감소하고 천천히 다시 증가합니다. 이로 인해 TCP 처리량이 변동됩니다. 큰 파일을 다운로드하면이를 명확하게 볼 수 있습니다.

UDP는 혼잡 제어를 사용하지 않기 때문에 드롭 포인트까지 버퍼를 최대화하려고하지 않기 때문에 더 빠르며 지연이 적습니다. UDP는 혼잡 제어를 사용하지 않지만 TCP는 사용하기 때문에 TCP에서 용량을 빼앗아 UDP 흐름을 생성 할 수 있습니다.

UDP는 여전히 혼잡 및 패킷 삭제에 취약하므로 재전송 또는 오류 수정 코드를 사용하여 이러한 합병증을 처리 할 수 ​​있도록 응용 프로그램을 준비해야합니다.

결과적으로 UDP는 다음을 수행 할 수 있습니다.

• 네트워크 드롭률이 애플리케이션이 처리 할 수있는 한계 내에있는 한 TCP보다 높은 처리량을 달성하십시오.
• 적은 지연으로 TCP보다 빠른 패킷을 제공합니다.
• 연결을 설정하기위한 초기 핸드 셰이크가 없으므로 연결을 더 빠르게 설정
• TCP는 다중 연결을 사용해야하는 반면 멀티 캐스트 패킷을 전송합니다.
• 고정 크기 패킷을 전송하는 반면 TCP는 세그먼트로 데이터를 전송합니다. 300 바이트의 UDP 패킷을 전송하면 다른 쪽 끝에 300 바이트가 수신됩니다. TCP를 사용하면 송신 소켓에 300 바이트를 공급할 수 있지만 수신자는 100 바이트 만 읽으므로 도중에 200 바이트가 더 있는지 확인해야합니다. 응용 프로그램이 바이트 스트림이 아닌 고정 크기 메시지를 전송하는 경우 중요합니다.

요약하면, 적절한 재전송 메커니즘을 구현하는 한 TCP는 TCP가 할 수있는 모든 유형의 응용 프로그램에 UDP를 사용할 수 있습니다. UDP는 매우 빠를 수 있으며 지연이 적으며 연결 기반의 정체의 영향을받지 않으며 고정 된 크기의 데이터 그램을 전송하며 멀티 캐스팅에 사용될 수 있습니다.

UDP는 오버 헤드가 적고 오디오 또는 비디오와 같은 실시간 데이터 스트리밍과 같은 작업을 수행하거나 데이터가 손실 된 경우 괜찮은 경우에 좋습니다.

UDP는 비 연결 프로토콜이며 SNMP 및 DNS 와 같은 프로토콜에 사용됩니다. 순서에 따라 도착하지 않은 데이터 패킷이 수용 가능하고 데이터 패킷을 즉시 전송할 수 있습니다.

네트워크가 스트레스 상태에있을 때, 즉 정체가 통제 된 안정적인 데이터 전송을 달성하기 어려운 경우 네트워크 관리를 수행해야하기 때문에 SNMP에서 사용됩니다.

연결 설정을 포함하지 않으므로 연결 설정 지연을 피하기 때문에 DNS에 사용됩니다.

건배

내가이 질문에 대해 알고있는 가장 좋은 답변 중 하나는 Hacker News 사용자 zAy0LfpBZLC8mAC에서 온 것 입니다. 이 답변은 너무 좋기 때문에 그대로 인용하려고합니다.

TCP는 전체 및 순서대로 배달을 보장하기 때문에 큐 오브 헤드 차단 기능을 제공합니다. 따라서 전송 중에 패킷이 손실되면 누락 된 패킷의 재전송을 기다려야하지만 UDP는 패킷이 도착하면 애플리케이션에 전달합니다. 중복을 포함하여 패킷이 도착했거나 도착한 순서에 대한 보장없이 (실제로는 포트 번호와 (선택적) 페이로드 체크섬이 추가 된 IP 임), 전화 통신에 적합합니다. 몇 밀리 초의 오디오가 누락 된 경우에는 문제가되지 않지만 지연은 매우 성가 시므로 재전송을 방해하지 않고 복제본을 삭제하고 재정렬 된 패킷을 올바른 순서로 정렬하여 수백 밀리 초의 지터 버퍼 패킷이 제 시간에 표시되지 않거나 전혀 표시되지 않으면 간단히 건너 뜁니다.코덱이 지원하는 경우 보간 가능

또한 TCP의 주요 부분은 흐름 제어입니다. 가능한 많은 처리량을 얻을 수 있지만 네트워크에 과부하가 걸리지 않습니다 (과중한 네트워크는 과부하 된 네트워크가 패킷을 삭제하므로 중복되어야 함). UDP는 그 어떤 것도 가지고 있지 않습니다. UDP는 그 어떤 것도 가지고 있지 않습니다.-주어진 코덱을 가진 전화가 특정 양의 대역폭을 필요로하기 때문에 "느려질"수 없으며 추가 대역폭도 전화 통신과 같은 응용 프로그램에 적합합니다. 통화가 더 빨라지지는 않습니다.

UDP는 실시간 / 낮은 대기 시간 응용 프로그램 외에도 지연 시간 및 대역폭 사용 측면에서 TCP 연결 설정 및 해제 오버 헤드가 없기 때문에 DNS 조회와 같은 매우 작은 트랜잭션에 적합합니다. 귀하의 요청이 일반적인 MTU보다 작고 응답도 역시 같은 경우, 서버에서 상태를 유지할 필요없이 흐름 제어를 주문할 수 있으며, 특히 유용하지 않은 모든 것은 한 번의 왕복으로 수행 할 수 있습니다. 그러한 용도로도 사용됩니다.

그리고 UDP를 사용하여 자신 만의 TCP 대체물을 구축 할 수는 있지만 네트워크 역학에 대한 깊은 이해가 없으면 좋은 아이디어가 아닐 수 있습니다. 최신 TCP 알고리즘은 매우 정교합니다.

또한 SCTP 및 DCCP와 같은 UDP 및 TCP 이상이 있음을 언급해야한다고 생각합니다. 현재 유일한 문제는 (IPv4) 인터넷에 NAT 게이트웨이가 가득하여 최종 사용자 응용 프로그램에서 UDP 및 TCP 이외의 프로토콜을 사용할 수 없다는 것입니다.

비디오 스트리밍은 UDP를 사용하는 완벽한 예입니다.

UDP는 오버 헤드가 적습니다. 이미 언급했듯이 비디오 및 오디오와 같은 것을 스트리밍하는 데 좋습니다.

TCP 전달에 대한 보장은 없습니다. 소켓 연결이 끊어 졌는지 또는 기본적으로 데이터가 도착하지 않을 경우 알 수 있습니다. 그렇지 않으면 도착할 때 도착합니다.

사람들이 잊어 버린 큰 점은 udp는 패킷 기반이며 tcp는 바이트 스트림 기반이라는 것입니다. 보낸 "tcp 패킷"이 다른 쪽 끝에 나타나는 패킷이라는 보장은 없습니다. 많은 패킷으로 분리 될 수 있습니다 라우터와 스택이 원하는대로. 따라서 소프트웨어는 바이트를 사용 가능한 데이터 덩어리로 다시 파싱하는 추가 오버 헤드를 가지므로 상당한 오버 헤드가 발생할 수 있습니다. UDP는 순서가 잘못되어 패킷 번호를 매기거나 다른 메커니즘을 사용하여 다시 정렬해야합니다. 그러나 해당 udp 패킷을 가져 오면 왼쪽과 동일한 순서로 모든 동일한 바이트로 도착하며 변경되지 않습니다. 따라서 udp 패킷이라는 용어는 의미가 있지만 tcp 패킷은 반드시 필요한 것은 아닙니다. TCP에는 응용 프로그램에서 숨겨진 자체 재시도 및 순서 메커니즘이 있습니다.

UDP는 기본적으로 지점 간 연결을 만들고 유지 관리 할 필요가 없기 때문에 양쪽 끝에 코드를 작성하는 것이 훨씬 쉽습니다. 내 질문은 일반적으로 TCP 오버 헤드를 원하는 상황은 어디에 있습니까? 그리고 수신 된 tcp "packet"이 전송 된 완전한 패킷이라고 가정하는 등의 지름길을 택하면 더 나을까요? (길이 / 내용을 확인하려는 경우 두 개의 패킷을 버릴 수 있습니다)

비디오 게임을위한 네트워크 통신은 거의 항상 UDP를 통해 이루어집니다.

속도는 가장 중요하며 각 업데이트에 플레이어가 볼 수있는 현재 상태가 모두 포함되어 있으므로 업데이트를 놓치더라도 중요하지 않습니다.

주요 질문은 "TCP보다 UDP가 더 나은 선택이 될 수있는 상황"과 관련이있었습니다.

위의 많은 큰 답변이 있지만 부족한 것은 TCP 불확실성이 TCP 성능에 미치는 영향에 대한 공식적이고 객관적인 평가입니다.

모바일 응용 프로그램의 급격한 증가와 함께 "때로 연결됨"또는 "가끔 연결이 끊어짐"패러다임으로 인해 연결이 잘 이루어지지 않을 때 TCP가 연결을 유지하려고 시도하는 오버 헤드가 확실히 발생하는 상황이 있습니다. UDP 및 "메시지 지향"특성의 경우

이제 수학 / 연구 / 숫자가 없지만 연결이 일반적으로 열악하고 오래된 TCP 일 때 TCP로 얻을 수있는 것보다 UDP를 통해 ACK / NAK 및 메시지 번호 지정을보다 안정적으로 사용하는 앱을 만들었습니다. 그냥 시간과 내 고객의 돈을 연결하려고 보냈습니다. 많은 서구 국가의 지역 및 농촌 지역에서이 정보를 얻습니다.

어떤 경우에는 다른 사람들이 강조한 것처럼 패킷의 도착을 보장하는 것이 중요하지 않으므로 UDP를 사용하는 것이 좋습니다. TCP보다 UDP가 선호되는 다른 경우가 있습니다.

TCP 대신 UDP를 사용하려는 고유 한 경우는 다른 프로토콜 (예 : 터널, 가상 네트워크 등)을 통해 TCP를 터널링하는 경우입니다. TCP over TCP를 터널링하면 각각의 혼잡 제어가 서로 간섭합니다. 따라서 일반적으로 TCP over UDP (또는 다른 상태 비 저장 프로토콜)를 터널링하는 것을 선호합니다. TechRepublic 기사 : TCP over TCP 이해 : TCP 터널링이 엔드 투 엔드 처리량 및 지연 시간에 미치는 영향을 참조하십시오 .

앱이 정확한 데이터 복제 대신 "실시간"데이터에 더 관심이있는 경우 UDP를 사용할 수 있습니다. 예를 들어, VOIP는 UDP를 사용할 수 있으며 앱은 패킷 순서를 바꿀 염려가 있지만 결국 VOIP는 모든 단일 패킷을 필요로하지 않지만 더 중요한 것은 많은 패킷의 지속적인 흐름을 필요로합니다. 어쩌면 여기에 음성 품질의 "고장"이있을 수 있지만 주된 목적은 다른 쪽에서 완벽하게 재생성되지 않고 메시지를받는 것입니다. UDP는 연결을 생성하고 TCP와 동기화하는 비용이 페이로드보다 많은 경우에도 사용됩니다. DNS 쿼리는 완벽한 예입니다. 쿼리 당 하나의 패킷 출력, 하나의 패킷 백. TCP를 사용하면 훨씬 더 집중적입니다. DNS 응답을받지 못하면 다시 시도하십시오.

속도가 필요한 경우 UDP, 패킷이 아닌 경우 정확도, 정확성이 필요한 경우 TCP

UDP는 종종 패킷의 정확성에 의존하지 않는 방식으로 프로그램을 작성해야한다는 점에서 더 어렵습니다.

항상 명확한 것은 아닙니다. 그러나 손실없이 올바른 순서로 패킷을 확실하게 전달해야하는 경우 TCP가 원하는 것일 수 있습니다.

반면에 UDP는 정보의 순서가 덜 중요하거나 데이터가 단일 패킷에 들어갈 수있는 짧은 정보 패킷을 전송하는 데 적합합니다.

동일한 정보를 많은 사용자에게 브로드 캐스트하려는 경우에도 적합합니다.

다른 경우에는 시퀀스 된 데이터를 보낼 때 적합하지만 일부 데이터가 누락 된 경우 너무 걱정하지 않아도됩니다 (예 : VOIP 응용 프로그램).

필요한 프로토콜은 TCP의 기능 중 일부 (모두는 아님)이지만 UDP가 제공하는 것보다 더 많기 때문에 일부 프로토콜은 더 복잡합니다. 애플리케이션 계층은 추가 기능을 구현해야합니다. 이 경우 UDP도 적절합니다 (예 : 인터넷 라디오, 순서는 중요하지만 모든 패킷이 통과 할 필요는 없습니다).

사용 장소 / 사용 장소의 예 1) LAN상의 여러 머신에 정확한 시간을 알리는 타임 서버. 2) VOIP 프로토콜 3) DNS 조회 4) LAN 서비스 요청 예를 들어 어디입니까? 5) 인터넷 라디오 6) 다른 많은 것들 ...

유닉스에서는 grep udp / etc / services를 입력하여 오늘날 구현 된 UDP 프로토콜 목록을 얻을 수 있습니다. 수백 가지가 있습니다.

Steven의 Unix 네트워크 프로그래밍 , "TCP 대신 UDP를 사용하는시기" 섹션 22.4 를 참조하십시오.

또한이 다른 SO 답변을 참조하십시오. UDP가 항상 TCP보다 빠르다는 오해 .

Steven의 말은 다음과 같이 요약 될 수 있습니다.

• 브로드 캐스트 및 멀티 캐스트에 UDP를 사용하는 것이 유일한 옵션이므로 새 앱에는 멀티 캐스트를 사용하십시오.
• 간단한 요청 / 응답 앱에 UDP를 사용할 수 있지만, 고유 한 방식으로 타임 아웃 및 재전송을 구축해야합니다.
• 대량 데이터 전송에는 UDP를 사용하지 마십시오.

우리는 UDP가 비 연결 프로토콜이라는 것을 알고 있습니다.

1. 간단한 요청-응답 통신이 필요한 프로세스에 적합합니다.
2. 내부 흐름, 오류 제어 기능이있는 프로세스에 적합
3. 광범위한 캐스팅 및 멀티 캐스팅에 적합

구체적인 예 :

• SNMP에서 사용
• RIP와 같은 일부 경로 업데이트 프로토콜에 사용

UDP와 TCP를 비교하고 UDP와 같은 비 연결 프로토콜은 속도를 보장하지만 패킷 전송의 신뢰성은 보장하지 않습니다. 예를 들어 비디오 게임에서는 일반적으로 안정적인 네트워크가 필요하지 않지만 속도가 가장 중요하며 게임에 UDP를 사용하면 네트워크 지연을 줄일 수 있다는 이점이 있습니다.

도중에 일부 데이터가 손실되어 전송중인 데이터가 완전히 망가지지 않는 경우 TCP를 통한 UDP를 사용하려고합니다. 많은 용도가 게임과 같은 실시간 응용 프로그램에서 사용됩니다 (예 : FPS). 항상 모든 플레이어의 위치를 ​​항상 알 필요가없고, 도중에 패킷이 몇 개 손실 될 경우 새로운 기능 데이터는 플레이어가 어디에 있는지 정확하게 알려주고 실시간 비디오 스트리밍 (하나의 손상된 프레임은 시청 경험을 망치지 않을 것입니다).

많은 PC에 수천 개의 winforms 클라이언트가있는 웹 서비스가 있습니다. PC는 DB 백엔드와 연결되어 있지 않으며 모든 액세스는 웹 서비스를 통해 이루어집니다. 따라서 UDP 포트에서 수신 대기하는 중앙 로깅 서버를 개발하기로 결정했으며 모든 클라이언트는 수신시 DB 테이블에 덤프되는 xml 오류 로그 패킷 (log4net UDP 어 펜더 사용)을 보냅니다. 우리는 몇 가지 오류 로그가 누락 되어도 수천 클라이언트와 관련하여 실제로 신경 쓰지 않기 때문에 기본 웹 서비스를로드하지 않는 전용 로깅 서비스를 사용하면 빠릅니다.

TCP가 작동 할 수있을 때 UDP를 제안하는 것을 꺼려합니다. 문제는 TCP가 어떤 이유로 든 작동하지 않는 경우 연결이 너무 느리거나 혼잡하여 UDP를 사용하도록 응용 프로그램을 변경해도 도움이 될 수 없다는 것입니다. UDP에 대한 연결이 잘못되었습니다. TCP는 이미 혼잡을 최소화하는 데 매우 효과적입니다.

UDP가 필요한 곳을 생각할 수있는 유일한 경우는 브로드 캐스트 프로토콜입니다. 응용 프로그램에 알려진 두 개의 호스트가 포함 된 경우 UDP는 코드 복잡성 비용을 크게 증가 시켜도 성능에 한계가 있습니다.

실제로 수행중인 작업을 알고있는 경우에만 UDP를 사용하십시오. UDP는 오늘날 극히 드문 경우이지만, 모든 곳에서 사용하려고 시도하는 (아주 경험이 많은) 전문가의 수는 비례하지 않는 것 같습니다. 아마도 오류 처리 및 연결 유지 관리 코드 자체를 구현하는 것을 좋아할 것입니다.

체크섬 임프린트 로 알려진 최신 네트워크 인터페이스 카드의 경우 TCP가 훨씬 빨라질 것으로 예상됩니다 . 놀랍게도, 빠른 연결 속도 (예 : 1Gbps)에서 체크섬 계산은 CPU에 큰 부하가되므로 인쇄물에 대한 TCP 패킷을 인식 하는 NIC 하드웨어 로 오프로드 되므로 동일한 서비스를 제공하지 않습니다.

UDP는 데이터 패킷을 전송해야하는 경우 VoIP의 안정성이 떨어집니다. 비디오 채팅은 UDP의 예입니다 (비디오 채팅 중에 wireshark 네트워크 캡처로 확인할 수 있음). 또한 TCP는 작동하지 않습니다. DNS 및 SNMP 프로토콜. TCP에는 오버 헤드가 많지만 UDP에는 오버 헤드가 없습니다.