Bạn sử dụng gì khi cần UDP đáng tin cậy?

92

Nếu bạn gặp trường hợp kết nối TCP có khả năng quá chậm và 'kết nối' UDP có khả năng quá không đáng tin cậy, bạn sử dụng cách nào? Có nhiều giao thức UDP tiêu chuẩn đáng tin cậy khác nhau, bạn có kinh nghiệm gì với chúng?

Vui lòng thảo luận về một giao thức cho mỗi câu trả lời và nếu ai đó đã đề cập đến giao thức bạn sử dụng thì hãy cân nhắc bỏ phiếu cho họ và sử dụng nhận xét để giải thích nếu cần.

Tôi quan tâm đến các tùy chọn khác nhau ở đây, trong đó TCP ở một đầu của quy mô và UDP ở đầu kia. Có nhiều tùy chọn UDP đáng tin cậy khác nhau và mỗi tùy chọn đưa một số yếu tố của TCP sang UDP.

Tôi biết rằng thường TCP là lựa chọn chính xác nhưng có một danh sách các lựa chọn thay thế thường hữu ích trong việc giúp người ta đi đến kết luận đó. Những thứ như Enet, RUDP, v.v. được xây dựng trên UDP có nhiều ưu và nhược điểm khác nhau, bạn đã sử dụng chúng chưa, kinh nghiệm của bạn là gì?

Để tránh nghi ngờ, không có thêm thông tin nào nữa, đây là một câu hỏi giả định và một câu hỏi mà tôi hy vọng sẽ đưa ra một danh sách các câu trả lời nêu chi tiết các phương án và lựa chọn thay thế khác nhau có sẵn cho người cần đưa ra quyết định.

— Len Holgate
nguồn

1

Câu hỏi này có vẻ lạc đề vì nó đang thăm dò ý kiến về công nghệ

— Dave Hillier

Những ai nghĩ rằng TCP là tốt nhất trong mọi trường hợp, vui lòng đọc: en.wikipedia.org/wiki/Bandwidth-delay_product

— nullptr

Wikipedia có một bảng đẹp so sánh các khía cạnh khác nhau của UDP, UDP Lite, TCP, Multipath TCP, SCTP, DCCP và RUDP . SCTP hỗ trợ hầu hết các tính năng trong danh sách đó.

— Evgeniy Berezovsky

@EugeneBeresovsky Tôi đã thực hiện một nghiên cứu nhỏ về SCTP, hầu hết thông tin, bao gồm từ câu trả lời SO, từ năm 2013 trở về trước. Hầu hết mọi người hồi đó đã viết rằng việc áp dụng SCTP rất thấp. stackoverflow.com/questions/1171555/…

— Michael IV,

@MichaelIvanov Tỷ lệ chấp nhận thực sự thấp. Nhưng nếu bạn có ý định sử dụng nó bên trong trung tâm dữ liệu của mình, bạn không cần quan tâm đến việc chấp nhận bên ngoài, miễn là các bộ chuyển mạch và bộ định tuyến không gây ra sự cố (trong trung tâm dữ liệu thì không) và bạn có hệ điều hành. và hỗ trợ thư viện, có thể là một vấn đề, như được mô tả trong một trong những câu trả lời trong câu hỏi bạn đã liên kết đến.

— Evgeniy Berezovsky

25

Thật khó để trả lời câu hỏi này nếu không có một số thông tin bổ sung về miền của vấn đề. Ví dụ, bạn đang sử dụng khối lượng dữ liệu nào? Bao lâu? Bản chất của dữ liệu là gì? (ví dụ: nó có phải là duy nhất, một dữ liệu không? Hay đó là một luồng dữ liệu mẫu? v.v.) Bạn đang phát triển nền tảng nào? (ví dụ: máy tính để bàn / máy chủ / được nhúng) Để xác định ý bạn là "quá chậm", bạn đang sử dụng phương tiện mạng nào?

Nhưng nói chung (rất!), Tôi nghĩ bạn sẽ phải cố gắng thực sự để đánh bại tcp về tốc độ, trừ khi bạn có thể đưa ra một số giả định khó về dữ liệu mà bạn đang cố gắng gửi.

Ví dụ: nếu dữ liệu bạn đang cố gắng gửi đến mức bạn có thể chịu được việc mất một gói (ví dụ: dữ liệu được lấy mẫu thường xuyên trong đó tốc độ lấy mẫu cao hơn nhiều lần so với băng thông của tín hiệu) thì bạn có thể hy sinh một số độ tin cậy của việc truyền tải bằng cách đảm bảo rằng bạn có thể phát hiện ra lỗi dữ liệu (ví dụ: thông qua việc sử dụng một crc tốt)

Nhưng nếu bạn không thể chịu đựng được việc mất một gói tin, thì bạn sẽ phải bắt đầu giới thiệu các loại kỹ thuật về độ tin cậy mà tcp đã có. Và, nếu không thực hiện một số lượng công việc hợp lý, bạn có thể thấy rằng bạn đang bắt đầu xây dựng các yếu tố đó thành một giải pháp không gian người dùng với tất cả các vấn đề về tốc độ vốn có đi kèm với nó.

— Andrew Edgecombe
nguồn

4

Ok, tôi sẽ điều chỉnh câu hỏi. Tôi quan tâm nhiều hơn trong những ưu và nhược điểm của các giao thức UDP đáng tin cậy khác nhau ngoài kia chứ không phải là phản ứng một 'sử dụng TCP';)

— Len Holgate

9

@Andrew - rất DỄ DÀNG để đánh bại TCP trong hai trường hợp: (1) ứng dụng của bạn có các yêu cầu về độ tin cậy nhẹ hơn "tất cả dữ liệu, luôn theo thứ tự, không trùng lặp, không xếp hàng quá nhiều". Hoặc (2) bạn đang sử dụng multicast. UDP đáng tin cậy rất phổ biến đối với môi trường phát đa hướng.

— Tom

4

Ngoài ra, TCP gặp vấn đề khủng khiếp khi được sử dụng trên kết nối WAN (các vấn đề về đường dài). Tại sao, đơn giản. TCP sử dụng các cửa sổ trong đó các gói trong cửa sổ phải được tải. Các giao thức ACK bị ảnh hưởng vì độ trễ do khoảng cách đường truyền. Google: WAN TCP "tốc độ ánh sáng"

— Ajaxx

3

@Ajaxx, bạn nói rất đúng về điều này, tuy nhiên, TCP / IP thực hiện điều này có chủ đích vì sự cố internet vừa qua. Nếu bạn đang thực hiện giao thức tốc độ bit cao mà không có bất kỳ sự kiểm soát tắc nghẽn nào, về cơ bản bạn sẽ rất xấu hổ. Nếu bạn sở hữu mạng, sau đó đi hoang dã.

— Kevin Nisbet,

2

"nơi mà tốc độ lấy mẫu cao hơn đáng kể so với tốc độ nyquist" - theo định nghĩa, tốc độ lấy mẫu luôn gấp đôi tốc độ nyquist.

— Steve

27

Còn về SCTP . Đó là một giao thức tiêu chuẩn của IETF (RFC 4960)

Nó có khả năng phân khúc có thể giúp tăng tốc độ.

Cập nhật: so sánh giữa TCP và SCTP cho thấy rằng các hiệu suất có thể so sánh được trừ khi có thể sử dụng hai giao diện.

Cập nhật: một bài báo giới thiệu hay .

— từ thiện
nguồn

Điều đó tốt, tôi quan tâm đến những thứ có thể được xây dựng trên UDP hơn là được xây dựng trên IP nhưng chắc chắn đó là thứ phù hợp với không gian giải pháp.

— Len Holgate 20/09/08

SCTP có nhiều tính năng tuyệt vời (chẳng hạn như multihoming) và với phần mở rộng độ tin cậy một phần (RFC 3758), nó là một tùy chọn cực kỳ linh hoạt. Nó có trong các phiên bản nhân linux mới nhất, nhưng đối với windows, bạn sẽ phải cài đặt ngăn xếp SCTP của riêng mình.

— Andrew Johnson

6

SCTP có thể được đào hầm qua UDP. tools.ietf.org/id/draft-ietf-sigtran-sctptunnel-00.txt

— Miles

Cảm ơn Miles, đó là một liên kết hữu ích!

— Len Holgate

1

Có ... Nhưng cái gì đó được xây dựng trên đầu trang của UDP chứ không phải ở mức tương tự như UDP có thể sẽ dễ dàng hơn để thực hiện trong không gian sử dụng, ít nhất là trên Windows ...

— Len Holgate

21

ENET - http://enet.bespin.org/

Tôi đã làm việc với ENET như một giao thức UDP đáng tin cậy và đã viết một phiên bản thân thiện với ổ cắm không đồng bộ cho một khách hàng của tôi đang sử dụng nó trong máy chủ của họ. Nó hoạt động khá tốt nhưng tôi không thích chi phí mà ping ngang hàng thêm vào các kết nối nhàn rỗi; khi bạn có nhiều kết nối ping tất cả chúng thường xuyên là rất nhiều công việc bận rộn.

ENET cung cấp cho bạn tùy chọn để gửi nhiều 'kênh' dữ liệu và dữ liệu được gửi là không đáng tin cậy, đáng tin cậy hoặc theo trình tự. Nó cũng bao gồm ping ngang hàng đã nói ở trên, hoạt động như một biện pháp duy trì sự sống.

— Len Holgate
nguồn

14

Chúng tôi có một số khách hàng trong ngành công nghiệp quốc phòng sử dụng UDT (Truyền dữ liệu dựa trên UDP) (xem http://udt.sourceforge.net/ ) và rất hài lòng với nó. Tôi thấy đó là một giấy phép BSD thân thiện.

— Chris Markle
nguồn

2

Bạn có thể nói rõ hơn về khách hàng của mình và các trường hợp sử dụng của họ, đặc biệt là trong lĩnh vực quốc phòng? Có lẽ là không, nhưng nó đáng để thử. Tôi đã thực sự đưa ra ý tưởng với cấp trên của mình về UDT trong một ứng dụng chuyển tệp, nhưng nó vẫn chưa thực sự đi đến đâu.

— Thomas Owens

10

RUDP - Giao thức dữ liệu người dùng đáng tin cậy

Điều này cung cấp:

Xác nhận các gói đã nhận
Gió và kiểm soát tắc nghẽn
Truyền lại các gói bị mất
Overbuffering (Nhanh hơn phát trực tuyến thời gian thực)

Nó có vẻ dễ cấu hình hơn một chút liên quan đến việc giữ bí danh sau đó ENet nhưng nó không cung cấp cho bạn nhiều tùy chọn (tức là tất cả dữ liệu đều đáng tin cậy và được sắp xếp theo trình tự chứ không chỉ các bit mà bạn quyết định nên có). Nó có vẻ khá dễ dàng để thực hiện.

— Len Holgate
nguồn

Tôi đã xem xét điều này nhưng dường như không có nhiều triển khai. Có một đề xuất?

— Nicholas,

Không xin lỗi. Cuối cùng tôi đã không sử dụng nó và luôn luôn thực hiện triển khai từ đầu.

— Len Holgate vào

9

Như những người khác đã chỉ ra, câu hỏi của bạn rất chung chung và việc cái gì đó có 'nhanh hơn' TCP hay không phụ thuộc rất nhiều vào loại ứng dụng.

TCP nói chung là nhanh như nó giúp truyền dữ liệu đáng tin cậy từ máy chủ này sang máy chủ khác. Tuy nhiên, nếu ứng dụng của bạn thực hiện nhiều nhóm lưu lượng nhỏ và chờ phản hồi, UDP có thể thích hợp hơn để giảm thiểu độ trễ.

Có một trung gian dễ dàng. Thuật toán của Nagle là một phần của TCP giúp đảm bảo rằng người gửi không lấn át người nhận một luồng dữ liệu lớn, dẫn đến tắc nghẽn và mất gói.

Nếu bạn cần sự phân phối đáng tin cậy, theo thứ tự của TCP, cũng như phản hồi nhanh của UDP và không cần lo lắng về tắc nghẽn khi gửi các luồng dữ liệu lớn, bạn có thể tắt thuật toán của Nagle:

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

— sương khói
nguồn

Như tôi đã nói, giả sử TCP ở một đầu của thang đo và UDP ở đầu kia, thì còn gì nữa.

— Len Holgate 21/09/08

Nếu bạn muốn trở nên phức tạp, hầu hết các giao thức được thảo luận đều được xây dựng trên UDP.

— sương khói 22/09/08

Giả định rằng TCP ở một đầu và UDP ở đầu kia là sai. Ví dụ: UDP không có kiểm soát luồng, bạn có thể dễ dàng gửi các gói quá nhanh, khiến một bộ định tuyến ở giữa làm rơi tất cả chúng. Sau đó, bạn sẽ làm gì ? Bỏ qua các gói bị mất hoặc gửi lại chúng? Gửi lại chúng và bạn sẽ ít nhiều hoàn thành lại TCP. Một lựa chọn khác để liên lạc đáng tin cậy là SCTP.

— không

1

Một phản hồi nhanh không nhất thiết phải bằng một thông lượng cao.

— Matt

1

Tôi không đồng ý. Khi nagle được sử dụng trên các giao thức dựa trên TCP với nhiều gói nhỏ hơn, nó sẽ hợp nhất chúng lại với nhau và tạo ra nhiều gói lớn hơn. Nó gây ra một số chậm trễ trong việc gửi, do đó độ trễ có thể tăng lên rất ít. Tuy nhiên, thông lượng có thể thấp hơn nếu không hiểu vì nhiều gói hơn = nhiều tiêu đề gói hơn = tổng chi phí lớn hơn. Các gói bị rơi trong mạng LAN thường liên quan nhiều hơn đến việc lấp đầy bộ đệm đầu vào. Nếu bạn có nhiều khách hàng gửi dữ liệu đến cùng một máy chủ, nó có thể không có sự khác biệt. Tôi không tin rằng tắt và mè nheo sẽ có tác dụng trong thực tế.

— Matt

8

Bất kỳ ai quyết định rằng danh sách trên là không đủ và họ muốn phát triển UDP đáng tin cậy của RIÊNG mình chắc chắn nên xem xét thông số Google QUIC vì điều này bao gồm nhiều trường hợp góc phức tạp và các cuộc tấn công từ chối dịch vụ tiềm ẩn. Tôi chưa chơi với việc triển khai điều này và bạn có thể không muốn hoặc cần mọi thứ mà nó cung cấp, nhưng tài liệu rất đáng đọc trước khi bắt tay vào thiết kế UDP mới "đáng tin cậy".

Một điểm khởi đầu tốt cho QUIC là ở đây , tại Blog Chromium.

Tài liệu thiết kế QUIC hiện tại có thể được tìm thấy ở đây .

— Len Holgate
nguồn

4

Nếu bạn gặp trường hợp kết nối TCP có khả năng quá chậm và 'kết nối' UDP có khả năng quá không đáng tin cậy, bạn sử dụng cách nào? Có nhiều giao thức UDP tiêu chuẩn đáng tin cậy khác nhau, bạn có kinh nghiệm gì với chúng?

Từ khóa trong câu của bạn là 'có khả năng'. Tôi nghĩ rằng bạn thực sự cần phải chứng minh với bản thân rằng trên thực tế, TCP quá chậm so với nhu cầu của bạn nếu bạn cần độ tin cậy trong giao thức của mình.

Nếu bạn muốn có được độ tin cậy từ UDP thì về cơ bản bạn sẽ triển khai lại một số tính năng của TCP trên UDP, điều này có thể sẽ khiến mọi thứ chậm hơn so với chỉ sử dụng TCP ngay từ đầu.

— 17 của 26
nguồn

Vâng, Andrew Edgecombe đã nói nhiều như vậy, nhưng, như tôi đã nói, tôi quan tâm đến ưu và nhược điểm của những lựa chọn thay thế GÌ. Nếu không có danh sách các lựa chọn thay thế và ưu nhược điểm của chúng thì thật khó để quyết định điều gì tốt nhất.

— Len Holgate 21/09/08

Với một chức năng đáng tin cậy đã biết, đôi khi một luồng UDP có thể được điều chỉnh thủ công để vượt xa luồng TCP trong hte OS. Tuy nhiên, hiếm.

— Joshua

1

@ 17/26, tôi đồng ý với Len Holgate, TCP sẽ chậm hơn UDP đáng tin cậy trong một số trường hợp. Giống như mạng BDP cao, giả sử bạn có kết nối internet 1 Gbps từ Trung Quốc đến NewYork, tôi chắc chắn TCP sẽ rất tệ khi sử dụng gần như toàn bộ tốc độ 1 Gbps. TCP tốt hơn cho hầu hết các kết nối trên trái đất, nhưng không tốt hơn cho mạng có Sản phẩm có độ trễ băng thông cao.

— nullptr

4

Giao thức DCCP, được tiêu chuẩn hóa trong RFC 4340 , "Giao thức kiểm soát tắc nghẽn Datagram" có thể là những gì bạn đang tìm kiếm.

Nó có vẻ được triển khai trong Linux .

— bortzmeyer
nguồn

3

Có thể là RFC 5405 , "Hướng dẫn sử dụng Unicast UDP dành cho nhà thiết kế ứng dụng" sẽ hữu ích cho bạn.

— bortzmeyer
nguồn

2

Bạn đã xem xét việc nén dữ liệu của mình chưa?

Như đã nêu ở trên, chúng tôi thiếu thông tin về bản chất chính xác của vấn đề của bạn, nhưng việc nén dữ liệu để vận chuyển chúng có thể hữu ích.

— từ thiện
nguồn

1

Đặc biệt là với các thư viện nén hiện đại. Một số nhanh như một bản ghi nhớ. ví dụ: lz4.

— Matt

2

RUDP . Nhiều máy chủ ổ cắm cho trò chơi triển khai một cái gì đó tương tự.

— Kỹ sư
nguồn

-3

Cách tốt nhất để đạt được độ tin cậy khi sử dụng UDP là xây dựng độ tin cậy trong chính chương trình ứng dụng (ví dụ: bằng cách thêm cơ chế xác nhận và truyền lại)

— kushan singh
nguồn