하드웨어 또는 커널 구성 (모든 기본 설정, 새로 운 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를 기반으로 재 시도를 구축했습니다.