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

신뢰할 수있는 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- 신뢰할 수있는 사용자 데이터 그램 프로토콜

다음을 제공합니다.

• 수신 된 패킷의 승인
• 윈도 잉 및 혼잡 제어
• 손실 된 패킷 재전송
• 오버 버퍼링 (실시간 스트리밍보다 빠름)

It seems slightly more configurable with regards to keep alives then ENet but it doesn't give you as many options (i.e. all data is reliable and sequenced not just the bits that you decide should be). It looks fairly straight forward to implement.

---

As others have pointed out, your question is very general, and whether or not something is 'faster' than TCP depends a lot on the type of application.

TCP is generally as fast as it gets for reliable streaming of data from one host to another. However, if your application does a lot of small bursts of traffic and waiting for responses, UDP may be more appropriate to minimize latency.

There is an easy middle ground. Nagle's algorithm is the part of TCP that helps ensure that the sender doesn't overwhelm the receiver of a large stream of data, resulting in congestion and packet loss.

If you need the reliable, in-order delivery of TCP, and also the fast response of UDP, and don't need to worry about congestion from sending large streams of data, you can disable Nagle's algorithm:

int opt = -1;
if (setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, (char *)&opt, sizeof(opt)))
  printf("Error disabling Nagle's algorithm.\n");

---

Anyone who decides that the list above isn't enough and that they want to develop their OWN reliable UDP should definitely take a look at the Google QUIC spec as this covers lots of complicated corner cases and potential denial of service attacks. I haven't played with an implementation of this yet, and you may not want or need everything that it provides, but the document is well worth reading before embarking on a new "reliable" UDP design.

A good jumping off point for QUIC is here, over at the Chromium Blog.

The current QUIC design document can be found here.

---

If you have a situation where a TCP connection is potentially too slow and a UDP 'connection' is potentially too unreliable what do you use? There are various standard reliable UDP protocols out there, what experiences do you have with them?

The key word in your sentence is 'potentially'. I think you really need to prove to yourself that TCP is, in fact, too slow for your needs if you need reliability in your protocol.

If you want to get reliability out of UDP then you're basically going to be re-implementing some of TCP's features on top of UDP which will probably make things slower than just using TCP in the first place.

---

Protocol DCCP, standardized in RFC 4340, "Datagram Congestion Control Protocol" may be what you are looking for.

It seems implemented in Linux.

---

May be RFC 5405, "Unicast UDP Usage Guidelines for Application Designers" will be useful for you.

---

Did you consider compressing your data ?

As stated above, we lack information about the exact nature of your problem, but compressing the data to transport them could help.

---

RUDP. Many socket servers for games implement something similar.

---

The best way to achieve reliability using UDP is to build the reliability in the application program itself( for example, by adding acknowledgment and retransmission mechanisms)

참고URL : https://stackoverflow.com/questions/107668/what-do-you-use-when-you-need-reliable-udp