TCP 처리량이 UDP 처리량보다 훨씬 큰 이유는 무엇입니까?

하드웨어 또는 커널 구성 (모든 기본 설정, 새로 운 OS 설치, Linux 커널 3.11 TCP / IP 스택)에 특이한 작업을 수행하지 않았으며 평균 0.75에 불과한 동안 TCP를 통해 초당 평균 약 383 만 메시지를 처리하고 있습니다. UDP를 통한 초당 백만 개의 메시지 이것은 두 프로토콜에 대해 내가 기대하는 것을 완전히 무시하는 것 같습니다.

급격한 차이의 가장 큰 원인은 무엇이며 Ubuntu 13.10에서 어떻게 진단 할 수 있습니까?

#TCP RESULTS
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

87380  65536     64    10.00      1963.43   32.96    17.09    5.500   2.852

#UDP RESULTS
Socket  Message  Elapsed      Messages                   CPU      Service
Size    Size     Time         Okay Errors   Throughput   Util     Demand
bytes   bytes    secs            #      #   10^6bits/sec % SS     us/KB

4194304      64   10.00     7491010      0      383.5     28.97    24.751
212992            10.00     1404941              71.9     25.03    21.381

이 테스트에는 10G 크로스 오버 케이블을 통해 동일하고 직접 연결된 두 개의 테스트 서버가 있습니다. 이 경우에 사용되는 NIC는 기본 구성이 적용된 Intel X520이며 마더 보드의 PCIe 3.0 x8 슬롯에 연결되며 NUMA 컨트롤러를 통해 CPU와 통신합니다.

테스트 설정에 대한 자세한 정보를 얻지 못하는 것 외에도 주요 문제는 64 바이트의 메시지 크기를 사용하는 것 같습니다. 이는 일반적인 MTU 1500 바이트와는 거리가 멀고 UDP를 비효율적으로 만듭니다. TCP는 링크를 효율적으로 사용하기 위해 여러 전송을 유선상의 단일 패킷 (TCP_NODELAY가 설정된 경우 제외)으로 병합하지만 각 UDP 메시지는 별도의 패킷. 숫자 : 64 바이트 크기의 약 23 개의 메시지가 MTU 크기의 단일 TCP 패킷으로 결합되는 반면 동일한 양의 데이터에 대해 UDP의 경우 23 개의 단일 패킷이 필요합니다. 이들 패킷 각각은 호스트로부터의 송신, 유선으로의 송신 및 피어에 의한 수신으로 인한 오버 헤드를 의미한다. 그리고 귀하의 경우에서 볼 수 있듯이 하드웨어가 이러한 모든 패킷을 송수신 할만큼 빠르지 않기 때문에 UDP 패킷의 약 80 %가 손실됩니다.

따라서이 벤치 마크에서 배울 수있는 것은 다음과 같습니다.

• UDP를 신뢰할 수 없음 (80 % 패킷 손실)
• MTU보다 훨씬 작은 패킷 크기와 함께 사용하면 UDP가 비효율적입니다.
• TCP는 링크를 최대한 활용하도록 고도로 최적화되었습니다

당신의 기대에 관해서는, UDP가 더 좋을 것입니다 : 왜 모든 주요 파일 전송 (ftp, http, ...)이 TCP 기반 프로토콜로 수행되는지 궁금한 적이 있습니까? 벤치 마크는 그 이유를 보여줍니다.

그렇다면 사람들은 왜 UDP를 사용합니까?

• 실시간 데이터 (예 : VoIP)는 오래된 메시지에 신경 쓰지 않으므로 보낸 사람이 링크를 효과적으로 사용하기 위해 메시지를 더 큰 패킷으로 결합하는 것을 원하지 않습니다. 그리고 패킷이 너무 늦게 도착하는 것보다 패킷이 손실된다는 것을 받아들입니다.
• 대기 시간이 긴 링크 (위성 등)에서는 TCP의 기본 동작이 링크를 효과적으로 사용하기에 최적이 아닙니다. 따라서이 경우 UDP로 전환하여 TCP의 신뢰도 계층을 다시 구현하고 대기 시간이 긴 링크에 맞게 최적화하는 한편 다른 사람들은 기존 TCP 스택을 조정하여 링크를 더 잘 사용합니다.
• "먼저 버리기"데이터 : 때때로 로그 메시지 (syslog)와 같이 데이터를 멀리 보내고 패킷 손실에 신경 쓰지 않는 것이 더 중요합니다.
• 짧은 상호 작용 : TCP를 사용하면 클라이언트와 서버에서 시간과 리소스를 소비하는 상태를 유지하는 연결을 설정해야합니다. 짧은 요청 및 회신과 같은 짧은 상호 작용의 경우 너무 많은 오버 헤드가 발생할 수 있습니다. 이 DNS로 인해 일반적으로 UDP를 사용하지만 UDP를 기반으로 재 시도를 구축했습니다.