TCP 연결이 잠재적으로 너무 느리고 UDP ‘연결’이 잠재적으로 너무 불안정한 상황이있는 경우 무엇을 사용합니까? 신뢰할 수있는 다양한 표준 UDP 프로토콜이 있습니다. 어떤 경험이 있습니까?
회 신당 하나의 프로토콜에 대해 논의하고 다른 사람이 이미 사용중인 프로토콜을 언급 한 경우 투표하고 필요한 경우 설명을 사용하여 설명하는 것을 고려하십시오.
여기서는 TCP가 스케일의 한쪽 끝에 있고 UDP가 다른쪽에있는 다양한 옵션에 관심이 있습니다. 신뢰할 수있는 다양한 UDP 옵션을 사용할 수 있으며 각각 TCP의 일부 요소를 UDP로 가져옵니다.
나는 종종 TCP가 올바른 선택이라는 것을 알고 있지만 대안 목록이 있으면 그 결론에 도달하는 데 도움이되는 경우가 많습니다. UDP를 기반으로 구축 된 Enet, RUDP 등과 같은 것에는 다양한 장단점이 있습니다. 사용해 본 적이 있습니까? 경험은 무엇입니까?
의심을 피하기 위해 더 이상 정보가 없습니다. 이것은 가설적인 질문이며 결정을 내려야하는 사람이 사용할 수있는 다양한 옵션과 대안을 자세히 설명하는 응답 목록을 도출하기를 바랐습니다.
답변
문제의 영역에 대한 추가 정보 없이는이 질문에 답하기가 어렵습니다. 예를 들어, 어떤 양의 데이터를 사용하고 있습니까? 얼마나 자주? 데이터의 특성은 무엇입니까? (예 : 고유 한 일회성 데이터입니까? 아니면 샘플 데이터 스트림입니까? 등) 어떤 플랫폼을 위해 개발하고 있습니까? (예 : 데스크탑 / 서버 / 임베디드) “너무 느림”이 의미하는 바를 파악하기 위해 어떤 네트워크 매체를 사용하고 있습니까?
그러나 (매우!) 일반적인 용어로는 전송하려는 데이터에 대해 어려운 가정을 할 수 없다면 속도면에서 tcp를 이기기 위해 정말 열심히 노력해야한다고 생각합니다.
예를 들어 전송하려는 데이터가 단일 패킷의 손실을 허용 할 수있는 수준이면 (예 : 샘플링 속도가 신호 대역폭보다 몇 배 높은 정기적으로 샘플링 된 데이터) 다음 작업을 수행 할 수 있습니다. 데이터 손상을 감지 할 수 있는지 확인하여 전송의 신뢰성을 희생합니다 (예 : 좋은 crc 사용을 통해).
그러나 단일 패킷 손실을 용인 할 수 없다면 tcp가 이미 가지고있는 안정성을위한 기술 유형을 도입해야합니다. 그리고 합리적인 양의 작업을하지 않고도 이러한 요소를 모든 고유 한 속도 문제와 함께 사용자 공간 솔루션으로 구축하기 시작할 수 있습니다.
답변
답변
ENET- http://enet.bespin.org/
저는 ENET을 신뢰할 수있는 UDP 프로토콜로 사용하고 서버에서 사용하는 클라이언트를 위해 비동기 소켓 친화적 버전을 작성했습니다. 꽤 잘 작동하지만 P2P 핑이 유휴 연결에 추가하는 오버 헤드가 마음에 들지 않습니다. 많은 연결이있을 때 모든 연결을 정기적으로 핑하는 것은 많은 바쁜 작업입니다.
ENET은 데이터의 여러 ‘채널’을 전송하고 전송 된 데이터가 신뢰할 수 없거나 신뢰할 수 있거나 순서가 지정되도록하는 옵션을 제공합니다. 또한 연결 유지 역할을하는 앞서 언급 한 피어 투 피어 핑도 포함됩니다.
답변
UDT (UDP 기반 데이터 전송) ( http://udt.sourceforge.net/ 참조)를 사용하는 일부 방위 산업 고객이 있으며 매우 만족합니다. 친근한 BSD 라이센스도 있습니다.
답변
RUDP- 신뢰할 수있는 사용자 데이터 그램 프로토콜
다음을 제공합니다.
- 수신 된 패킷의 승인
- 윈도 잉 및 혼잡 제어
- 손실 된 패킷 재전송
- 오버 버퍼링 (실시간 스트리밍보다 빠름)
ENet보다 생존 유지와 관련하여 약간 더 구성 가능해 보이지만 많은 옵션을 제공하지 않습니다 (즉, 모든 데이터가 신뢰할 수 있고 결정해야하는 비트뿐만 아니라 순서가 지정됨). 구현하는 것은 매우 간단합니다.
답변
다른 사람들이 지적했듯이 귀하의 질문은 매우 일반적이며 TCP보다 ‘빠른지’여부는 응용 프로그램 유형에 따라 크게 달라집니다.
TCP는 일반적으로 한 호스트에서 다른 호스트로 데이터를 안정적으로 스트리밍하는 속도만큼 빠릅니다. 그러나 애플리케이션이 작은 트래픽 버스트를 많이 수행하고 응답을 기다리는 경우 지연 시간을 최소화하는 데 UDP가 더 적합 할 수 있습니다.
쉬운 중간 지대가 있습니다. Nagle의 알고리즘 은 송신자가 대량의 데이터 스트림을받는 사람을 압도하여 혼잡과 패킷 손실을 초래하지 않도록하는 TCP의 일부입니다.
TCP의 안정적인 순차 전달과 UDP의 빠른 응답이 필요하고 대용량 데이터 스트림 전송으로 인한 혼잡에 대해 걱정할 필요가없는 경우 Nagle 알고리즘을 비활성화 할 수 있습니다.
int opt = -1;
if (setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, (char *)&opt, sizeof(opt)))
printf("Error disabling Nagle's algorithm.\n");
답변
위의 목록이 충분하지 않다고 판단하고 자신의 신뢰할 수있는 UDP를 개발하기를 원하는 사람은 많은 복잡한 코너 케이스와 잠재적 인 서비스 거부 공격을 다루기 때문에 Google QUIC 사양을 확인해야합니다. 나는 아직 이것의 구현을 가지고 놀지 않았고, 당신은 그것이 제공하는 모든 것을 원하거나 필요로하지 않을 수도 있지만,이 문서는 새로운 “신뢰할 수있는”UDP 디자인을 시작하기 전에 읽을 가치가 있습니다.
QUIC의 좋은 출발점이 여기 있습니다. 크롬 블로그에서 이상.
