데이터가 많은 실시간 게임에서 UDP가 여전히 TCP보다 낫습니까?

데이터 사용량이 많은 실시간 멀티 플레이어 게임에는 일반적으로 UDP가 권장된다는 것을 알고 있습니다.

대부분의 기사는 오래되어 왔으며 인터넷에서 전송되는 모든 데이터의 ~ 80 %가 TCP이므로 TCP에 대한 많은 최적화가 이루어져야합니다.

UDP가 여전히 속도와 대기 시간 측면에서 우수합니까? 최근의 TCP 최적화로 인해 TCP보다 TCP 성능이 향상 될 수 있습니까?

아니요, UDP는 여전히 성능 대기 시간 측면에서 우수하며 통신 데이터가 UDP 또는 기타 손실 통신을 염두에두고 설계되었다고 가정 할 때 두 프로토콜의 철학 때문에 항상 더 빠릅니다.

TCP는 모든 네트워크 패킷이 도착하고 패킷이 전송 된 순서대로 도착하는 추상화를 생성합니다. 손실이 많은 채널에서 이러한 추상화를 구현하려면 시간이 걸리는 재전송 및 시간 초과를 구현해야합니다. TCP에서 2 개의 업데이트를 보내고 첫 번째 업데이트의 패킷이 손실되면 다음과 같은 때까지 두 번째 업데이트가 표시되지 않습니다.

1. 첫 번째 업데이트 손실이 감지되었습니다.
2. 첫 번째 업데이트의 재전송이 요청됩니다.
3. 재전송이 도착하여 처리되었습니다.

UDP를 사용하면 첫 번째 업데이트를 버리고 두 번째 최신 업데이트를 사용하기 때문에 TCP에서 얼마나 빨리 수행되는지는 중요하지 않습니다. TCP와 달리 UDP는 모든 패킷 도착을 보장하지 않으며 순서대로 도착한다고 보장하지 않습니다.

이를 위해서는 올바른 종류의 데이터를 전송하고 데이터 손실이 허용되는 방식으로 통신을 설계해야합니다.

모든 패킷이 도착해야하는 데이터가 있고 게임에서 패킷을 전송 된 순서대로 처리해야하는 경우 UDP가 더 빠르지 않습니다. 실제로이 경우 UDP를 사용하면 TCP를 재구성하고 UDP를 사용하여 TCP를 구현할 수 있기 때문에 속도가 느려질 수 있습니다.

편집-일부 의견을 통합 / 주소 지정하기 위해 추가 정보 추가 :

일반적으로 이더넷의 패킷 손실률은 매우 낮지 만 WiFi가 연결되거나 사용자가 업로드 / 다운로드를 진행중인 경우 훨씬 높아집니다. 0.01 %의 완전 균일 패킷 손실이 있다고 가정 해 봅시다 (왕복이 아닌 편도). 일인칭 슈팅 게임에서 클라이언트는 마우스 커서가 플레이어를 돌릴 때와 같이 초당 약 20 회 발생하는 등의 상황이 발생할 때마다 업데이트를 보내야합니다. 또한 프레임 당 또는 고정 간격 (초당 60-120 회 업데이트)으로 업데이트를 보낼 수 있습니다. 이러한 업데이트는 서로 다른 시간에 전송되므로 업데이트 당 하나의 패킷으로 전송됩니다. 16 인 게임에서는 16 명의 모든 플레이어가 초당 20-120 개의 패킷을 서버로 전송하여 초당 총 320-1920 개의 패킷을 생성합니다. 패킷 손실률이 0.01 %이면 5.2-31.25 초마다 패킷이 손실됩니다.

손실 된 패킷 이후에 수신되는 모든 패킷에 대해 DupAck를 보내며 3 번째 DupAck 이후에 보낸 사람은 손실 된 패킷을 재전송합니다 . 따라서 TCP가 재전송을 시작하는 데 필요한 시간은 3 개의 패킷과 마지막 DupAck가 보낸 사람에게 도달하는 데 걸리는 시간입니다. 그런 다음 재전송이 도착할 때까지 기다려야하므로 총 3 개의 패킷 + 1 개의 왕복 지연 시간을 기다립니다. 왕복 대기 시간은 일반적으로 로컬 네트워크에서 0-1ms, 인터넷에서 50-200ms입니다. 초당 120 개의 패킷을 보내면 3 개의 패킷이 일반적으로 25ms에, 초당 20 개의 패킷을 보내면 150ms에 도착합니다.

반면 UDP를 사용하면 다음 패킷을 얻는 즉시 손실 된 패킷을 복구하므로 초당 120 개의 패킷을 보내면 8.3ms, 초당 20 개의 패킷을 보내면 50ms가 손실됩니다.

TCP를 사용하면 Nagle (개발자가 전송 병합을 끄는 것을 잊거나 지연된 ACK를 비활성화 할 수없는 경우 ), 네트워크 혼잡 방지 또는 여러 가지를 고려해야 할만큼 패킷 손실이 나쁜 경우 고려해야합니다. 패킷 손실 (손실 된 Ack 및 DupAck 포함). UDP를 사용하면 TCP처럼 좋은 네트워크 시민이되는 것에 신경 쓰지 않기 때문에 더 빠른 코드를 쉽게 작성할 수 있습니다.

우리는 TCP와 UDP가 모두 IP 위에 구축 된 프로토콜이라는 것에 동의합니다 . IP는 인터넷을 통해 메시지가 전달되는 방법을 지정하지만 메시지 구조, 형식에 관한 것은 없습니다. 여기에 TCP 및 UDP 프로토콜이 있습니다. IP 속성을 사용하지만 프로그래머는 하위 계층의 순 통신에 대해 걱정하지 않고 메시지 교환에 집중할 수 있습니다. 전선에서 아날로그 신호를 직접 처리하는 것은 일종의 고통 스러울 수 있기 때문에 훌륭합니다.

• TCP는 메시지를 보내고받는 일련의 기능을 제공합니다. 데이터를 작은 패킷으로 나눠서 네트워크를 통해 보냅니다. 우리가 요구하는 것은 넷 소켓에 사용할 포트 와 보내려는 실제 메시지입니다. 또한 신뢰할 수 있습니다. 즉, 네트워크를 따라 일부 패킷이 손실 된 경우 패킷이 감지되면 도착 순서와 동일한 순서로 패킷을 전송하여 다시 전송합니다.

• 반면, UDP는 사용자 제어를위한 프로토콜입니다. UDP를 사용하여 데이터 그램 을 보낼 때 데이터 그램이 대상에 도착하는지 여부를 확신 할 수 없습니다 (수학적 확실성을 의미합니다. 패킷을 보낼 때 도착할 가능성이 있지만 확실하지는 않습니다) 100 %). 또한 패킷이 손실되면 감지되거나 다시 전송되지 않습니다.

이 시점에서 TCP는 모든 문제에 대한 이상적인 솔루션처럼 보입니다. 신뢰할 수 있고 빠르며, 어떤 패킷이 도착했는지와 여전히 어떤 패킷을 보내야하는지 추적하여 연결 대기 시간을 해결합니다.

그러나 , 저쪽을 보라. UDP가 우리에게 제공하는 유일한 장점은 속도라는 것입니다. 이것이 바로 우리가 정말로 원하는 것입니다. UDP 패킷은 UDP 프로토콜이 작동하는 방식이기 때문에 특정 컨트롤없이 방금 제작, 합계 검사 및 전송됩니다. TCP 패킷은 제작, 레이블 지정, 합계 검사를 거쳐야하며 ACK 가 도착 하면 발신자에게 "패킷 x는 여기에 계속 이동합니다" 라고 알리기 위해이 패킷을 보내야합니다.이 신호를 보내지 않으면 해당 패킷 x 를 보내야합니다. 다시.

데이터 사용량이 많은 실시간 멀티 플레이어 게임에는 일반적으로 UDP가 권장된다는 것을 알고 있습니다.

그렇습니다. UDP는 주로 고속 보다 높은 데이터 전송 및 관리를 처리 하기 때문에 TCP보다 선호 됩니다. 이러한 비디오 게임이 결정 론적 잠금 단계에서 실행된다고 가정하면 (서버에서 발생하는 상황은 네트워크 대기 시간과 독립적으로 모든 클라이언트에서 동일하게 복제 됨) 업데이트 패킷이 손실되고 대상에 도달하지 않습니다. TCP는 이러한 패킷을 다시 보내고, 다음 패킷은 순서대로 도착하지 않아 삭제 된 후 손실 된 패킷 이후에 다시 전송됩니다. UDP는이 시나리오에서 훨씬 더 관대합니다. 최신 업데이트가 제공되므로이 패킷에 신경 쓰지 않습니다. 손실 된 업데이트는 렌더링되지 않고 대신 사용 된 통합 방법 과 최신 업데이트가 수신 되면 게임 물리가 보간됩니다 .

대기 시간이 충분히 높으면 UDP가 지 터링을 유발하지만 UDP는 그렇지 않습니다.

<video style="min-width: 100% height: auto" autoplay="" preload="auto" loop="true"><source src="https://gafferongames.com/videos/deterministic_lockstep_tcp_250ms_5pc.mp4" type="video/mp4"><source src="http://173.255.195.190/cubes_deterministic_lockstep_tcp_250ms_5pc.webm" type="video/webm">Your browser does not support the video tag.</video>

이것은 UDP가 여전히 속도와 대기 시간 측면에서 우수한지 궁금합니다.

음, 그래, 그것은이며 A에 대한 것이다 긴 시간입니다. TCP vs UDP에 대한 자세한 내용은 여기를 참조하십시오 .

TCP <-전송 제어 프로토콜. 전송 을 제어 하기 위해 만들어졌습니다 .

TCP는 좋은 외교 네트워크 시민이되기 위해 만들어졌습니다. 네트워킹은 모든 사람에게 좋은 경험을 제공하는 데 중점을두고 있으며이를 달성하기 위해 처리량을 기꺼이 줄입니다. 그것은 조정 하여 환경에 대기 시간을 추가 . 이유는 다음과 같습니다.

• 수신자가 누락 된 패킷을 감지하면 발신자에게 속도를 늦추도록 지시합니다 (한 시간 동안 속도의 절반).
• 수신자는 잘못된 패킷 순서를 감지하고 (네트워크 경로가 다를 수 있음) 발신자에게 속도를 늦추도록 지시합니다. btw의 경우 수신자는 누락 된 패킷이 들어올 때까지 추가 패킷을받지 않습니다.
• 발신자는 네트워크 혼잡 (예 : 느린 왕복 시간)을 감지하고 대기 시간을 추가합니다.
• 수신자가 속도를 유지할 수없는 경우 (입력 버퍼가 가득 참) 발신자에게 대기 시간 추가 (흐름 제어)를 요청합니다.
• 수신기 사이에 단일 느린 수신기 (높은 핑 자식, 울음 소리, 소위 말하는 것)이 있으며 가정에서 대기 시간이 추가 될 수 있습니다.

또한

• Nagle의 알고리즘은 데이터 프레임을보다 효율적으로 활용하기 위해 더 많은 데이터를 전송할 때까지 보낸 사람 데이터를 보류 상태로 유지할 수 있습니다. 시간이 중요한 데이터가 지연됩니다.
• wlan을 사용하는 일반 홈 라우터는 여러 클라이언트 간의 TCP 처리량을 부드럽게하기 위해 현명한 작업 (느려짐)을 수행 할 수 있다고 생각합니다 (게임이 그것을 사용하지 않더라도 wlan 인터페이스는 병목 현상입니다). 방송 / 멀티 캐스팅과 관련이 있습니다. "기타"데이터는 TCP 처리량을 감소시킬 수 있습니다.
• TCP ACK 는 게임 환경에 필요하지 않은 모든 것을 알고 있습니다. 모든 단일 물리 업데이트를 ACK하는 것은 중요하지 않습니다. 예를 들어 초당 1 회 또는 이와 유사한 지식을 충분히 알고 있습니다. 클라이언트 (또는 서버)가 더 오랜 시간 동안 침묵하는 경우에는 대응할 시간입니다.

그럼에도 불구하고 TCP는 (전체 전송 데이터) / (전체 소비 시간) 에서 가장 높은 수치를 제공합니다 . 당신이 그것을 원할 때 정확하게 일어나지 않는다고 단지.

UDP는이 중 어느 것도 수행하지 않습니다. 당신의 의지에 따라 발사 될 때 마다 매번 맞을 수는 없습니다. 대상은 "오랫동안 총을 쏘지 않은 이유는 무엇입니까?"라고 공표해야합니다. 하나는 여전히 고유의 사용자 지정 ACK 패킷을 만들고 여러 레코드를 단일 패킷에 넣을 수 있습니다. 또한 NAT 통과를 제어 할 수도 있습니다. UDP는 지연 시간이 적은 게임에 가장 적합합니다.

RFC 768 (UDP) 의 첫 번째 다이어그램을 15 페이지 의 RFCP 793 (TCP) 의 첫 번째 다이어그램과 비교할 수 있습니다 .

둘 다 "소스 포트"에 16 비트를 표시하고 "대상 포트"에 16 비트를 표시합니다. 둘 다 "체크섬"에 대해 16 비트를 보여줍니다. RFC 768에 따르면 UDP의 "체크섬 절차는 TCP에서 사용 된 것과 동일합니다."

UDP 길이는 UDP 다이어그램의 세부 사항을 마무리하는 반면 TCP 길이는 15 및 16 페이지에 설명 된“96 비트 의사 헤더”의 일부입니다.

TCP가 UDP보다 성능이 뛰어나다 고 기대하지 마십시오. 여러 가지 이유로 간단하게 발생하지는 않습니다. 하나는 TCP가 단순히 더 많은 비트를 가지고 있다는 것입니다. 따라서 장비가 초당 특정 수의 비트를 효과적으로 처리 할 수 ​​있으면 TCP 패킷보다 더 많은 UDP 패킷이 허용됩니다.

다른 이유는 TCP의 "3 방향 핸드 셰이크"는 발신자가 응답을 기다려야한다는 것을 의미합니다. 이 요구 사항은 UDP가 처리하지 않는 추가 오버 헤드를 발생시킵니다. 대부분의 인터넷 통신이 일부 UDP 통신으로 시작하는 이유가 있습니다. 기본 DNS는 UDP를 사용하므로 TCP의 "3 방향 핸드 셰이크"프로세스보다 적은 단계로 요청 및 응답을 완료 할 수 있습니다. 손실 된 패킷을 추적하는 TCP의 기능은 다소 흥미롭지 않습니다. 컴퓨터는 완료되지 않은 이전 요청이 있음을 원격 시스템에 알리려고 시도하지 않고 단순히 새로운 요청을 할 수 있기 때문입니다.

잠시 동안 무슨 일이 일어나고 있는지 고려하십시오. 시나리오를 단순화하기 위해 상태 변경을 보내려고 할 때 두 가지 선택이 있습니다 (플레이어가 방금 방향을 바꾸거나 총을 쏘거나 다른 플레이어가 방금 폭탄을 발사 한 것과 같이).

1. TCP 세션을 열어두고 폭탄이 터질 때 모든 플레이어에게 TCP 메시지를 보냅니다 (가능한 경우 아래 참조).
2. UDP 포트를 계속 청취하고 폭탄이 터질 때 연결 상태에 관계없이 모든 플레이어에게 UDP 메시지를 보냅니다.

바로 전에 업데이트가 필요하지 않다고 가정 할 때 해당 단일 업데이트가 1 대 2로 도착하는 시간은 크게 다르지 않습니다. 서버에서 클라이언트로 한 번만 이동합니다. 그러나 폭탄이 터지는 대신 미로를 가로 질러 달리는 사람의 활동을 지속적으로 전달하려고합니다. 직조, 더킹, 사격 등 UDP의 경우 모든 작업이 발생하자마자 데이터 그램으로 전송됩니다. TCP의 경우 모든 작업은 서버가 전송이 허용 된 경우에만 패킷으로 전송됩니다. 보낼 수있는 것은 무엇입니까? 메시지가 전선에 놓일 수 있도록 TCP 창에 여유 공간이 있어야합니다 (지연된 ack이 활성화되었다고 가정). 그렇지 않은 경우, 보내기 전에 클라이언트로부터 ack이 도착할 때까지 기다려야합니다.

너무 길어요? 멀티 플레이어 1 인칭 슈팅 게임 개발이 90 년대 후반과 2000 년대 초반에 크게 뒤떨어졌지만 낮은 대기 시간 연결은 일반적이지 않았습니다. 전화 접속 모뎀의 일반적인 단방향 대기 시간은 180ms입니다. 다른 업데이트를 보내기 전에 공격을 기다리면서 그 시간을 360ms로 두 배로 늘리는 것은 고통 스러웠습니다. 초보 사용자들조차도 분명히 차이를 느낄 수있었습니다. 광대역 연결이 끊어지면 대기 시간이 크게 줄어 들었지만 대역폭이 부족한 경우에도 여전히 지속됩니다 (일부 지역에서는 매우 흔함). 따라서 가능한 가장 낮은 대기 시간에 대한 선호가 지속되었습니다.

현대의 가정 연결 및 상호 연결은 혼잡 한 시간대에도 지역 대기 시간이 15ms 이하인 지점으로 변경되었습니다. 지연 시간이 "충분히 낮기"때문에 UDP 대신 TCP를 선택하는 것은 보이지 않습니다. 그러나, 지연 시간이 짧은 프로토콜로서 히스토리를 고려할 때 UDP보다 TCP보다 우선 순위가 높은 경향이 여전히 있습니다. 따라서 현재 (그리고 아마도 미래에는) UDP가 실시간 통신에 선호 될 것입니다.

데이터 사용량
이 많은 실시간 멀티 플레이어 게임에는 일반적으로 UDP가 권장된다는 것을 알고 있습니다. UDP는 여전히 속도와 대기 시간 측면에서 우수합니까? 최근 TCP 최적화로 인해 TCP보다 TCP 성능이 향상 될 수 있습니까?

당신의 가정이 잘못되었습니다. TCP와 UDP는 주로 그들이 나타내는 모델이 다릅니다 (신뢰할 수없는 데이터 그램과 순서가 안정적인 가상 스트림).

볼륨 ( "높은 데이터 사용량") 또는 처리량과 관련하여 다르지 않습니다. TCP는 UDP만큼 많은 데이터를 통과 시키며 물리적 케이블을 쉽게 포화시킵니다.

패킷 손실 이있을 경우 대기 시간 은 다르지만 해당 조건에서만 다릅니다 . 그렇지 않으면 TCP는 UDP만큼 지연 시간이 낮습니다 (네트워크 스택에 약간 더 많은 논리가 있기 때문에 수십 나노 초가 걸리거나 걸릴 수는 있지만 무시할 수는 없습니다).
헤더 크기에는 약간의 차이가 있으므로 기술적으로 더 많은 바이트가 직렬 회선의 와이어를 통해 더 많은 바이트를 작성해야하지만 그보다 덜 중요합니다. 대량 전송에만 중요하며 약 0.5 % 차이가 있습니다. 홈 DSL 인터넷 액세스를 사용하는 대부분의 사람들은 ATM을 통해 모든 트래픽을 라우팅하여 10 % 이상의 프로토콜 오버 헤드 (48 바이트의 페이로드에 5 개의 제어 바이트 및 부분 프레임)를 추가하며 아무도 통지하지 않습니다.

어떤 사람들은 UDP를 기반으로 신뢰성을 구축합니다. 신뢰성이 어느 정도가 요구되지만 엄격한가에 차 구원이 필요하지 않은 경우, 그 수도 적은 장점을 제공합니다. 그러나 접근 방식이 의미가 있는지 여부는 여전히 논란의 여지가 있으며 그 작은 이점을 위해 막대한 가격을 지불해야합니다.
호텔 WiFi 또는 다른 "이상한"장소에서 연결하는 클라이언트가있는 경우 TCP에 대한 전반적인 지원이 UDP보다 훨씬 더 낫다는 것을 알 수 있습니다.

게임은 일반적으로 UDP가 앞서 언급 한 방식 중 하나가 우수하지 않기 때문에-그렇지 않거나-순서없이 신뢰성을 구현하여 지터를 밀리 초 단위로 줄일 수 있기 때문에 게임 (IP 텔레포니와 매우 유사) 때문에 UDP를 사용합니다. 예를 들어 위치 업데이트와 같이 매우 휘발성이 높은 데이터가 많이 포함됩니다.
이 휘발성 데이터는 시간이 지남에 따라 그리고 다음 데이터 그램에 의해 정기적으로 신속하게 폐기됩니다. 이는 실제로 100 % 신뢰할 수있는 (또는 순서대로) 신경 쓰지 않는 것 이상을 의미합니다.

네트워크 패킷이 빈번한 업데이트 (슈터 게임, 전화, 비디오 채팅)로 꾸준한 속도로 실행되는 서비스에 빠졌다고 가정하면 승인 시간이 초과되어 패킷을 재전송하는 것은 의미가 없습니다. 재전송 된 패킷이 도착할 때까지 반대쪽에있는 모든 것을 고정시킵니다. 그것은 너무 혼란스럽고 좋지 않습니다.

대신, 패킷 손실을 고려하고 다음 패킷에서 데이터를 가져 와서 최대한의 능력을 발휘하기 위해 패킷이 사용자에게서 손실되었다는 사실을 숨 깁니다. 보간, 데드 레커닝, 당신은 이름을 짓습니다.

패킷 손실은 정상적인 조건입니다. IP는 일반적으로 "매우 신뢰할 수있는"반면, 패킷이 가끔 일어날 수있는 낙하, 그리고 일어날 것입니다 . 손실되는 패킷은 일반적으로 드문 편이지만 (<1 % 미만) 특별하거나 이론적 인 것이거나 무언가가 손상되었다는 표시는 아닙니다. 완벽하게 정상입니다.
모든 TCP 벌크 전송에는 반드시 손실 된 패킷이 포함됩니다 (예 : 혼잡 제어 작동 방식).

고 대역폭 MPG에서는 몬스터 # 425의 위치와 상태를 알려주는 패킷을 놓치더라도 신경 쓰지 않아도됩니다. 몇 초 안에 다른 업데이트를받을 수 있기 때문입니다. 이것은 UDP가 TCP를 바보처럼 보이게하여 즉시 사용되지 않는 데이터를 기다릴 수있는 예입니다.

같은 게임에서 패치가 디자인 된대로 정확하게 나타나기를 원합니다. TCP에는 이미 "실패한 경우 알려주기"기능이 내장되어있어 자동 재시도 및 확인 된 실패를 촉진합니다. UDP로 할 수 있지만 기술을 다시 만드는 이유는 무엇입니까?

다음은 진행 상황에 대한 간단한 설명입니다.

UDP-청크 O'data를 분리합니다.
패킷을 만드십시오.
IP로 캡슐화합니다.
배송하십시오.

TCP-스트림 O '데이터 분리
스트림 앞에서 패킷을 만듭니다.
IP로 캡슐화합니다.
TCP 창에서 공간을 기다리십시오.
배송하십시오.
영수증을 받거나 시간이 초과 될 때까지 계속 재배송하십시오.
영수증을 받거나 시간이 초과 될 때까지 TCP 창을 유지하십시오.

배송은 단지 로컬 NIC를 통해서만 이루어 졌다는 의미입니다.

TCP 수신 수신은 데이터 수신을 보장하고 다음 패킷의 창에서 공간을 비 웁니다.

재전송하면 (약간) 최종 수신 가능성이 높아집니다.

TCP 패킷은 다른 쪽에서 순서가 지정된 데이터 스트림으로 재 조립됩니다. UPD 패킷은 별개의 패킷으로 수신됩니다. 프로토콜은 순서를 유지하지 않습니다.

TCP는 필요한 데이터와 대량의 데이터를 푸시하는 데 좋습니다. TCP는 지속적인 실패에 대한 알림을 제공합니다. k 파이프를 통한 TCP 자체 조절 (참조 : 창). TCP에는 초기화 속도를 늦추기위한 핸드 셰이크가 있습니다. TCP는 전송하기 전에 "연결"이 필요합니다.

UDP는 데이터를 유선으로 저장하기 때문에 창과 재전송을 기다리지 않고 진행할 수 있습니다. UDP는 손실 된 데이터 양에 관계없이 최고 속도로 데이터를 초크 파이프로 분사합니다.

상용 상용 UDP 멀티 캐스트 파일 전송 유틸리티를 설계하고 작성했습니다. 나는 IP 스택에서 일했다. 이것들은 단지 기본입니다, sans minutia. "소켓, MTU 및 기타 재미있는 장난감"을 설명하는 것은이 질문에 유용한 것 이상을 조금 설명했습니다.

추신 (댓글에 답글을 달 수 없습니다) UDP는 바람직하지만 필수는 아닌 데이터에 좋습니다. 순방향 오류 수정은 불필요하지만 바람직한 많은 패킷의 예입니다.

모든 TCP 최적화 라우터가 UDP보다 TCP 성능을 향상 시켰습니까?

또 다른 질문은 "데이터가 무겁다"는 장면을 자주로드한다는 의미입니까?

그렇다면, 특히 서버 쪽에서 NIC가 동일한 주기로 여러 가지 오프로드를 제공하기 때문에 TCP가 훨씬 더 효율적일 수있는 큰 데이터 조각 (> 1k)을 집중적으로 보내야 할 수도 있습니다. UDP에서 MTU- 헤더 크기 바이트보다 많은 바이트를 보내려고하면 IP 조각화 및 기타 오버 헤드가 발생하여 성능이 저하 될 수있는 반면 사용자 공간 응용 프로그램은 TCP로 대량 쓰기를 실행할 수 있습니다.

UDP / TCP (또는 다른 변형)는 속도 / 지연 시간 측면에서도 우수 하지 않습니다. 응용 프로그램의 요구 사항에 따라 선택해야합니다. 이를 위해서는 각 프로토콜이 제공하는 기능을 비교하여 더 많은 기능이 더 많은 오버 헤드를 의미한다는 것을 인식해야합니다. 따라서 대기 시간을 최소화하거나 속도를 최대화하는 것이 목표라면 가능한 적은 기능을 갖춘 프로토콜을 선택해야하지만 요구 사항을 충족하는 데 필요한 필수 기능을 유지해야합니다.

프로토콜의 비교

일반적으로 UDP (User Datagram Protocol)는 가장 적은 기능을 제공합니다. 모든 종류의 수신 / 확인없이 데이터를 보내는 것이 간단합니다.

반면 TCP (Transmission Control Protocol)는 안정적인 연결 통신에 필요한 가장 많은 기능을 제공합니다. TCP 통신은 중복 또는 하나 이상의 패킷을 전송하고 순서 정보로 태그를 지정합니다. 대상에서 수신하면 원래 발신자가 손실 된 패킷을 다시 보낼 수 있도록 ACK (확인)가 손실 된 패킷 정보와 함께 다시 전송되어야합니다. 올바르게 호출하면 ACK 패킷조차도 올바른 안정성을 위해 승인이 필요할 수 있습니다.

예 : Skype 전화 회의

Skype 전화 회의의 경우 모든 비디오 및 오디오 데이터를 안정적인 방식으로 전송 / 수신하는 것이 중요하지 않습니다. 요즘 UDP는 어쨌든 패킷 손실을 최소화하는 데 큰 역할을합니다. 알아야 할 중요한 점은 UDP의 전송 성공 여부에 대한 보장이 전혀 없다는 것입니다. 전화 회의의 오디오 / 비디오 데이터의 경우 실시간 데이터 (즉, 최신)를 얻는 데 더 관심이 있기 때문에 UDP가 올바른 선택입니다. 여기저기서 몇 개의 패킷이 손실되면 통신을 중단하지 않습니다.

그러나 전화 회의에서는 사람들이 IM (인스턴트 메시지)을 보내거나 파일을 보낼 수 있습니다. 이러한 경우 파일과 메시지가 손상되거나 손실되지 않도록하려면 안정성이 필요합니다. IM의 경우 TCP가 제공 하는 연결 상태 가 필요하지 않을 수 있습니다 . RUDP (Reliable UDP)와 같은 중개 프로토콜이 충분할 수 있습니다. 그러나 파일의 경우 TCP가 제공하는 연결 상태가 필요할 수 있습니다.

구현 선택

복잡한 응용 프로그램이 있거나 통신을 최적화해야하는 경우 UDP 통신으로 시작하는 것이 좋습니다. 나중에 필요한 모든 기능을 추가 할 수 있습니다. 이렇게하면 네트워크 통신을 최대한 제어 할 수 있습니다.

최적화가 필요없는 간단한 응용 프로그램이있는 경우 필요에 맞게 표준 (UDP 또는 TCP) 중 하나를 사용하는 것이 좋습니다. 그렇게하면 더 중요한 문제로 넘어갈 수 있습니다.

사람들이 TCP 패킷이 UDP 패킷보다 크다고 믿는 많은 의견을 발견했습니다. 나를 믿지 말고 설명서를 읽으십시오. 프로토콜은 다음과 같습니다. 이더넷 헤더의 경우 몇 바이트 (2 바이트 메시지 유형, 48 비트 MAC, 6 바이트) (Wi-Fi의 경우 헤더가 다를 수 있음) TCP의 경우 20 바이트, TCP의 경우 UDP 바이트, 데이터 x 범위의 경우 바이트 x 바이트 0에서 1500까지 (MTU 참조) 마지막으로, 해당 이더넷 패킷에서 손상이 발생하지 않았는지 확인하는 체크섬.

TCP는 약 64K의 더 큰 "스트림"패킷을 보낼 수 있습니다. 이 "큰"블록은 실제로 많은 작은 이더넷 패킷에서 잘립니다.