Tại sao UDP không có độ tin cậy (được triển khai ở lớp Ứng dụng) thay thế cho TCP?

TCP cung cấp độ tin cậy ở lớp vận chuyển trong khi UDP thì không. Vì vậy, UDP là nhanh chóng. Nhưng, một giao thức ở lớp ứng dụng có thể thực hiện cơ chế đáng tin cậy trong khi sử dụng UDP.

Theo nghĩa này, tại sao UDP không có độ tin cậy (được triển khai trên lớp Ứng dụng) thay thế TCP trong trường hợp UDP nhanh hơn TCP trong khi chúng ta cần độ tin cậy?

TCP là nhanh như bạn có thể làm một cái gì đó với các thuộc tính độ tin cậy của nó. Nếu bạn chỉ cần, nói, giải trình tự và phát hiện lỗi, UDP có thể được thực hiện để phục vụ hoàn hảo. Đây là cơ sở cho hầu hết các giao thức thời gian thực như giọng nói, truyền phát video, v.v., trong đó độ trễ và jitter quan trọng hơn sửa lỗi "tuyệt đối".

Về cơ bản, TCP nói rằng các luồng của nó có thể được dựa vào cuối cùng. Tốc độ đó phụ thuộc vào các bộ hẹn giờ, tốc độ khác nhau nhanh như thế nào. Thời gian để khắc phục lỗi có thể không dự đoán được, nhưng các thao tác cơ bản càng nhanh càng tốt khi không có lỗi. Nếu một hệ thống biết điều gì đó về các loại lỗi có thể xảy ra, thì nó có thể có thể làm điều gì đó không thể xảy ra với TCP. Ví dụ, nếu các lỗi đơn bit đặc biệt có khả năng, bạn có thể sử dụng mã hóa sửa lỗi cho các lỗi bit đó: tuy nhiên, điều này được triển khai tốt hơn nhiều trong lớp liên kết. Một ví dụ khác, nếu các đợt mất toàn bộ gói ngắn là phổ biến, bạn có thể giải quyết vấn đề này bằng nhiều lần truyền mà không phải chờ mất, nhưng rõ ràng điều này rất tốn kém về băng thông. Hoặc cách khác, làm chậm tốc độ xuống cho đến khi xác suất lỗi không đáng kể: cũng tốn kém về băng thông. Đến cuối cùng,

Về mặt triển khai, bạn sẽ thấy rằng các thế kỷ lập trình viên được đầu tư vào TCP sẽ làm cho nó nhanh hơn bất kỳ thứ gì chung mà bạn có thể đủ khả năng để thực hiện, cũng như đáng tin cậy hơn trong các trường hợp cạnh tối nghĩa.

TCP cung cấp: một phương thức kết nối phổ biến (thiết yếu trong đó các hệ thống giao tiếp không có kiểm soát chung) tạo ra một luồng đáng tin cậy, có trật tự, (và bị trùng lặp), hai chiều, cửa sổ, luồng byte với điều khiển tắc nghẽn trên các mạng đa hop khoảng cách tùy ý.

Nếu một ứng dụng không yêu cầu sự phổ biến (phần mềm của bạn chạy ở cả hai bên) hoặc không cần tất cả các tính năng của TCP, nhiều người sẽ sử dụng các giao thức khác một cách có lợi, thường là trên UDP. Các ví dụ bao gồm TFTP (tối giản, xử lý lỗi thực sự không hiệu quả, QUIC được thiết kế để giảm chi phí (vẫn được đánh dấu là thử nghiệm) và các thư viện như lidgren, có kiểm soát chi tiết chính xác các tính năng đáng tin cậy được yêu cầu. ]

UDP với độ tin cậy thực sự có thể thay thế cho TCP. Chúng tôi đã có một ví dụ về nó: nó được gọi là QUIC .

Từ Wikipedia:

Trong số các ứng dụng khác, QUIC cải thiện hiệu suất của các ứng dụng web hướng kết nối hiện đang sử dụng TCP. Nó thực hiện điều này bằng cách thiết lập một số kết nối đa kênh giữa hai điểm cuối trên Giao thức gói dữ liệu người dùng (UDP).

Ưu điểm của việc sử dụng UDP so với việc tạo ra một giao thức tầng vận chuyển hoàn toàn mới là các bộ định tuyến và các thiết bị mạng khác đã hiểu nó.

Bạn có thể sử dụng UDP để thực hiện chức năng TCP ở lớp ứng dụng (độ tin cậy, khả năng thích ứng). Bạn cũng có thể sử dụng TCP ngay từ đầu trừ khi ứng dụng của bạn thực sự cần không thể thực hiện được với TCP. Nếu bạn tự thực hiện các chức năng đó, rất có thể bạn sẽ kết thúc tồi tệ hơn nhiều so với TCP. Chi phí bổ sung cũng làm giảm hiệu quả tổng thể.

TCP không chậm - nó chỉ cần bắt tay trước khi truyền và cửa sổ truyền để thích ứng với kênh. Nó có thể định hình rất tốt thông lượng của nó tới kênh truyền trong tay và thích ứng với các thay đổi trong luồng, tất cả những gì UDP không thể làm được (bằng chính nó).

Tuy nhiên, các giao thức trên lớp vận chuyển không có chủ đề ở đây.

Trên một mạng sạch chúng tương đương nhau. Có những trường hợp TCP sẽ bị treo trong thời gian (Bất kỳ ai từng thấy màn hình HTTP bị đóng băng khi tải?) Nhưng nó sẽ không phân phát rác hoặc trộn các gói và hiếm khi từ bỏ hoàn toàn.

UDP có thể cung cấp cho lớp ứng dụng quyền kiểm soát nhiều hơn đối với lưu lượng truy cập với chi phí rất nhiều công việc.

Câu trả lời cho câu hỏi của bạn là, đôi khi nó được thực hiện theo cách đó. Các trò chơi đòi hỏi độ trễ thấp thường làm chính xác điều đó. Đó là một công việc tốt hơn, nhưng khả năng kiểm soát chính xác có bao nhiêu gói tin nổi bật mà bạn có thể có và tần suất chúng được thử lại thường đáng giá.

Vì vậy, nhìn chung sự khác biệt là TCP là một triển khai mục đích chung rất tốt, nhưng có những mục đích cụ thể mà UDP có thể thực hiện mà TCP thực hiện rất kém hoặc hoàn toàn không - chẳng hạn:

• KHÔNG BAO GIỜ bỏ cuộc (với TCP đôi khi kết nối bị treo và bạn phải ngắt kết nối và khởi động lại)
• Gửi một luồng nhanh các gói không yêu cầu trả lời và thỉnh thoảng bạn không nhớ một số gói (trong đó chỉ có gói gần đây nhất là quan trọng, bất kỳ gói nào khác có thể bị loại bỏ) - nghĩ rằng cập nhật vị trí trò chơi - bạn có thể nhận được một chút "Nhảy" thay vì từng bước, nhưng bạn nhận được cùng một kết quả nhanh hơn và đáng tin cậy hơn.
• Xử lý các mạng iffy bằng cách phân tích các gói tin và thay đổi linh hoạt tần suất và thời gian bạn thử lại - thậm chí có thể kích thước gói tối đa.

Nhưng nói chung là không đáng, TCP khá tối ưu, vậy tại sao bạn phải đi làm tất cả các công việc phụ và thêm cơ hội (lớn) để thêm lỗi và lỗi bảo mật?

UDP không nhanh vì đó là UDP. TCP không chậm vì đó là TCP.

Cả hai giao thức được thiết kế với một số đảm bảo nhất định và TCP thô có nhiều bảo đảm hơn UDP thô.

Và quy tắc của là: giá cho bảo lãnh là hiệu suất .

Không có gì cấm bạn thực hiện các đảm bảo TCP trên UDP. Nhưng sau đó bạn nhận được nhiều đảm bảo hơn và vì vậy bạn phải trả giá. Do đó, bạn giảm hiệu suất xuống TCP hoặc tệ hơn (do chi phí UDP). Trừ khi bạn biết triển khai TCP tốt hơn, điều này là không thể. Và nếu bạn làm như vậy (hy vọng) bạn tiết lộ nó và chúng tôi làm cho TCP chuẩn nhanh hơn. Và chúng tôi trở lại nơi chúng tôi bắt đầu. :)

Bạn có thể chơi với những đảm bảo là tốt. Hơi sửa đổi cái này, hơi sửa cái kia. Và sau đó, bạn kết thúc với một giao thức như QUIC vượt qua UDP và nó rất giống với TCP + TLS. Trong nhiều trường hợp, nó nhanh hơn TCP (mặc dù theo bài viết này độ trễ lên tới 5% và đệm tới 15% mà IMO không phải là vấn đề lớn) nhưng trong một số trường hợp (ví dụ: mạng đáng tin cậy hoặc không cần mã hóa) thì thực tế là vậy chậm hơn (xem một lời giải thích ở đây ).

Bạn cũng có thể làm suy yếu những đảm bảo đó và sau đó nó có ý nghĩa hơn. Ví dụ: bạn đang phát trực tuyến và vì vậy các gói cũ không thú vị. Chỉ gần đây nhất. Nhưng tắc nghẽn vẫn quan trọng. Vì vậy, bạn có một số đảm bảo từ TCP, nhưng không phải tất cả. Và vâng, mọi người thực sự làm điều đó (ví dụ như các trò chơi thời gian thực). Điều này cung cấp cho bạn hiệu suất tốt hơn với chi phí của một số đảm bảo.

Ý tưởng của bạn sẽ tốt trong không gian sâu.

Câu trả lời đúng là "nó phụ thuộc" và "bởi vì điều đó sẽ làm hỏng toàn bộ mạng". TCP / IP rất tốt đối với các mạng và tự động điều chỉnh về tốc độ phù hợp để nhanh nhưng không tạo ra hàng tấn gói trả về ICMP.

Khi một bộ định tuyến không đủ RAM đột nhiên nhận được rất nhiều loại gói tin - nói từ Tsunami, Bittorrent hoặc FDT - nó sẽ thả nó và gửi lại cho người gửi một gói xác nhận thất bại nhỏ. Bây giờ máy chủ UDP của bạn phải theo dõi và truyền lại phần đó theo cách thủ công. Một số bộ định tuyến ISP định hình Bittorrent rất nhiều điều này làm tổn thương sóng thần?

Giao thức Tsunami sử dụng UDP với kênh điều khiển trong TCP. http://tsunami-udp.sourceforge.net/ Tôi tìm thấy một nghiên cứu cho thấy nó chậm hơn một thứ gọi là FDT.

Giao thức truyền dữ liệu nhanh (FDT) huyền thoại từ CERN có khả năng bão hòa bất kỳ mạng nào sử dụng nhiều luồng TCP. Có lẽ nó nhanh hơn, bởi vì nó gây ra ít sóng truyền lại mà Tsunami, làm ngập mạng với rất nhiều UDP, một số trong đó không thể thực hiện được.

UDP được sử dụng bởi các ứng dụng không đáng tin cậy: truyền phát âm thanh, nhập / cập nhật trò chơi IO, "ping" thực sự là ICMP nhưng không được bảo đảm, Bittorrent, mosh ssh phản ứng nhanh, điện thoại VOIP, phát đa hướng, DNS được gửi qua UDP AFAIK. Bất cứ điều gì không bận tâm đến gói bị thiếu lẻ và có thể "bắt kịp" ngay lập tức.

TCP / IP thực sự là phát minh giết người cho phép các nhà phát triển ứng dụng nên chỉ cần đặt và quên. Ổ cắm là một cặp địa chỉ IP và cổng và được thiết kế để có thể được thiết lập và duy trì trong nhiều giờ, nhiều ngày, thậm chí vài tuần mà không cần kết nối lại. Email, web, IRC và tất cả các ứng dụng sát thủ sử dụng TCP. Nhưng bạn có thể nhận được các lần tạm dừng lạ trong quá trình tải xuống đột ngột nhanh hơn ... và trong không gian sâu, các kết nối có thể hết thời gian để chuyển kiểu Tsunami tốt nhất cho chuyển tập tin giữa các vì sao - bạn có thể vào một cái gì đó ở đó !!

Bằng chứng là trong những nhận xét cuối cùng của trích xuất nghiên cứu khoa học này, trong đó đề cập đến khoảng cách ngày càng tăng mà tôi đang diễn ra về re: không gian sâu Từ: https://uscholar.univie.ac.at/get/o:300623.pdf

Không có tắc nghẽn, hiệu suất của FDT và GridFTP với TCP cao hơn Tsunami và UDT. Tốc độ cao nhất của FDT là 2,34 Gb / s với RTT 1 ms nhưng nó giảm nhanh sau 100 ms so với GridFTP, hoạt động tốt hơn FDT khi RTT liên kết dài hơn 100 ms. Điều thú vị là, thông lượng của Tsunami không giảm khi tăng RTT, cho thấy nó có kiểm soát tắc nghẽn hiệu quả nhất với tăng RTT.

Sau đó, một lần nữa ... thực sự có một giao thức không gian rất giống với email sẽ tốt hơn cho không gian. Các ứng dụng không phải bận tâm đến các giá trị hết thời gian như mãi mãi.

TCP! = UDP + Độ tin cậy

TCP không chỉ đơn giản là UDP với độ tin cậy cao hơn. TCP cung cấp nhiều tính năng hơn là độ tin cậy. Bạn có thể đọc về chúng trong nhiều RFC.

Bất kỳ tính năng nào trong số này "có thể" được triển khai ở lớp ứng dụng. Cuối cùng, sẽ trở thành một điểm mà bạn bắt đầu phát minh lại bánh xe.

Để đặt tên cho một vài tính năng TCP có ...

• Tạo kết nối và kết thúc: thực hiện bắt tay và đóng kết nối

• Kiểm soát luồng: đảm bảo rằng người gửi và người nhận truyền phát ở tốc độ mà cả hai có thể xử lý tốc độ dữ liệu.

• Kiểm soát tắc nghẽn từ đầu đến cuối: cho phép các nút cuối điều tiết lưu lượng của chúng dựa trên tổn thất. Đọc về khởi đầu chậm, tránh tắc nghẽn và phục hồi nhanh.

Theo kinh nghiệm của tôi, UDP được sử dụng khi tốc độ là mối quan tâm về độ tin cậy. Bạn có thể thêm một số mức độ tin cậy ở cấp ứng dụng không đáng tin cậy 100% như TCP. Ví dụ: nếu bạn vẫn muốn hiệu suất nhanh, bạn có thể thực hiện sửa lỗi chuyển tiếp (FEC) nơi bạn truyền dữ liệu nhiều lần. Bạn vẫn có được hiệu suất tốt và một số mức độ tin cậy (lưu ý độ tin cậy khá TCP) mà không cần tất cả các cuộc trò chuyện qua lại để nhận các gói bị mất. Giao dịch là nó làm tăng việc sử dụng mạng nhưng có thể phù hợp với các ứng dụng thời gian thực như chơi game hoặc phát trực tuyến.