신뢰할 수있는 UDP가 필요할 때 무엇을 사용합니까?

TCP 연결이 잠재적으로 너무 느리고 UDP '연결'이 잠재적으로 너무 불안정한 상황이있는 경우 무엇을 사용합니까? 신뢰할 수있는 다양한 표준 UDP 프로토콜이 있습니다. 어떤 경험이 있습니까?

회 신당 하나의 프로토콜에 대해 논의하고 다른 사람이 이미 사용중인 프로토콜을 언급 한 경우 투표하고 필요한 경우 설명을 사용하여 설명하는 것을 고려하십시오.

여기서는 TCP가 스케일의 한쪽 끝에 있고 UDP가 다른쪽에있는 다양한 옵션에 관심이 있습니다. 신뢰할 수있는 다양한 UDP 옵션을 사용할 수 있으며 각각 TCP의 일부 요소를 UDP로 가져옵니다.

나는 종종 TCP가 올바른 선택이라는 것을 알고 있지만 대안 목록이 있으면 그 결론에 도달하는 데 도움이되는 경우가 많습니다. UDP를 기반으로 구축 된 Enet, RUDP 등과 같은 것에는 다양한 장단점이 있습니다. 사용해 본 적이 있습니까? 경험은 무엇입니까?

의심을 피하기 위해 더 이상 정보가 없습니다. 이것은 가설적인 질문이며 결정을 내려야하는 사람이 사용할 수있는 다양한 옵션과 대안을 자세히 설명하는 응답 목록을 도출하기를 바랐습니다.

문제의 영역에 대한 추가 정보 없이는이 질문에 답하기가 어렵습니다. 예를 들어, 어떤 양의 데이터를 사용하고 있습니까? 얼마나 자주? 데이터의 특성은 무엇입니까? (예 : 고유 한 일회성 데이터입니까? 아니면 샘플 데이터 스트림입니까? 등) 어떤 플랫폼을 위해 개발하고 있습니까? (예 : 데스크탑 / 서버 / 임베디드) "너무 느림"이 의미하는 바를 파악하기 위해 어떤 네트워크 매체를 사용하고 있습니까?

그러나 (매우!) 일반적인 용어로는 전송하려는 데이터에 대해 어려운 가정을 할 수 없다면 속도면에서 tcp를 이기기 위해 정말 열심히 노력해야한다고 생각합니다.

예를 들어 전송하려는 데이터가 단일 패킷의 손실을 허용 할 수있는 수준이면 (예 : 샘플링 속도가 신호 대역폭보다 몇 배 높은 정기적으로 샘플링 된 데이터) 다음 작업을 수행 할 수 있습니다. 데이터 손상을 감지 할 수 있는지 확인하여 전송의 신뢰성을 희생합니다 (예 : 좋은 crc 사용을 통해).

그러나 단일 패킷 손실을 용인 할 수 없다면 tcp가 이미 가지고있는 안정성을위한 기술 유형을 도입해야합니다. 그리고 합리적인 양의 작업을하지 않고도 이러한 요소를 모든 고유 한 속도 문제와 함께 사용자 공간 솔루션으로 구축하기 시작할 수 있습니다.

무엇에 대해 SCTP . IETF (RFC 4960)의 표준 프로토콜입니다.

속도에 도움이 될 수있는 청크 기능이 있습니다.

업데이트 : TCP와 SCTP 를 비교하면 두 인터페이스를 사용할 수없는 경우 성능이 비슷 함을 알 수 있습니다.

업데이트 : 멋진 소개 기사 .

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의 좋은 출발점이 여기 있습니다. 크롬 블로그에서 이상.

현재 QUIC 디자인 문서는 여기 에서 찾을 수 있습니다 .

TCP 연결이 잠재적으로 너무 느리고 UDP '연결'이 잠재적으로 너무 불안정한 상황이있는 경우 무엇을 사용합니까? 신뢰할 수있는 다양한 표준 UDP 프로토콜이 있습니다. 어떤 경험이 있습니까?

문장의 핵심 단어는 '잠재적'입니다. 프로토콜의 안정성이 필요한 경우 TCP가 실제로 필요에 비해 너무 느리다는 것을 스스로 증명해야한다고 생각합니다.

UDP에서 안정성을 얻으려면 기본적으로 UDP 위에 TCP의 일부 기능을 다시 구현하여 처음에 TCP를 사용하는 것보다 속도가 느려질 것입니다.

RFC 4340 , "Datagram Congestion Control Protocol" 에서 표준화 된 프로토콜 DCCP 는 귀하가 찾고있는 것일 수 있습니다.

그것은 리눅스에서 구현 된 것 같습니다 .

RFC 5405 일 수 있습니다. "애플리케이션 설계자를위한 유니 캐스트 UDP 사용 지침"이 유용 할 것입니다.

데이터 압축을 고려하셨습니까?

위에서 언급했듯이 문제의 정확한 특성에 대한 정보가 부족하지만 데이터를 압축하여 전송하면 도움이 될 수 있습니다.

RUDP . 많은 게임용 소켓 서버는 비슷한 것을 구현합니다.

UDP를 사용하여 안정성을 달성하는 가장 좋은 방법은 응용 프로그램 자체에 안정성을 구축하는 것입니다 (예 : 승인 및 재전송 메커니즘 추가).