Khi nào thì thích hợp sử dụng UDP thay vì TCP? [đóng cửa]

Vì TCP đảm bảo phân phối gói và do đó có thể được coi là "đáng tin cậy", trong khi UDP không đảm bảo bất cứ điều gì và các gói có thể bị mất. Điều gì sẽ là lợi thế của việc truyền dữ liệu bằng UDP trong một ứng dụng thay vì qua luồng TCP? Trong những tình huống nào UDP sẽ là sự lựa chọn tốt hơn, và tại sao?

Tôi cho rằng UDP nhanh hơn vì nó không có chi phí tạo và duy trì luồng, nhưng sẽ không liên quan nếu một số dữ liệu không bao giờ đến đích?

Đây là một trong những câu hỏi yêu thích của tôi. UDP bị hiểu lầm như vậy.

Trong trường hợp bạn thực sự muốn nhanh chóng nhận được câu trả lời cho máy chủ khác, UDP hoạt động tốt nhất. Nói chung, bạn muốn câu trả lời nằm trong một gói phản hồi và bạn đã sẵn sàng thực hiện giao thức của riêng mình để đảm bảo độ tin cậy hoặc gửi lại. DNS là mô tả hoàn hảo của trường hợp sử dụng này. Chi phí thiết lập kết nối quá cao (tuy nhiên, DNS cũng hỗ trợ chế độ TCP).

Một trường hợp khác là khi bạn đang cung cấp dữ liệu có thể bị mất vì dữ liệu mới hơn sẽ thay thế dữ liệu / trạng thái trước đó. Dữ liệu thời tiết, truyền phát video, dịch vụ báo giá chứng khoán (không được sử dụng cho giao dịch thực tế) hoặc dữ liệu trò chơi xuất hiện trong tâm trí.

Một trường hợp khác là khi bạn đang quản lý một lượng lớn trạng thái và bạn muốn tránh sử dụng TCP vì HĐH không thể xử lý nhiều phiên đó. Đây là một trường hợp hiếm hoi ngày nay. Trên thực tế, hiện nay có các ngăn xếp TCP trên đất liền có thể được sử dụng để người viết ứng dụng có thể kiểm soát chi tiết hơn đối với các tài nguyên cần thiết cho trạng thái TCP đó. Trước năm 2003, UDP thực sự là trò chơi duy nhất trong thị trấn.

Một trường hợp khác là cho lưu lượng phát đa hướng. UDP có thể được phát đa hướng tới nhiều máy chủ trong khi TCP hoàn toàn không thể làm điều này.

Nếu một gói TCP bị mất, nó sẽ bị bực bội. Điều đó không hữu ích cho các ứng dụng dựa trên dữ liệu được xử lý theo một thứ tự cụ thể trong thời gian thực.

Ví dụ bao gồm truyền phát video và đặc biệt là VoIP (ví dụ Skype ). Tuy nhiên, trong những trường hợp đó, một gói bị rơi không phải là vấn đề lớn: các giác quan của chúng ta không hoàn hảo, vì vậy chúng ta thậm chí có thể không nhận thấy. Đó là lý do tại sao các loại ứng dụng này sử dụng UDP thay vì TCP.

"Không đáng tin cậy" của UDP là một chủ nghĩa hình thức. Truyền tải không được đảm bảo tuyệt đối. Là một vấn đề thực tế, họ hầu như luôn luôn vượt qua. Họ chỉ không thừa nhận và thử lại sau một thời gian chờ.

Chi phí đàm phán cho một ổ cắm TCP và bắt tay các gói TCP là rất lớn. Thực sự rất lớn. Không có chi phí UDP đáng giá.

Quan trọng nhất, bạn có thể dễ dàng bổ sung UDP bằng một số bắt tay giao hàng đáng tin cậy mà ít chi phí hơn TCP. Đọc cái này: http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP là hữu ích để phát thông tin trong một loại ứng dụng đăng ký xuất bản. IIRC, TIBCO sử dụng UDP rất nhiều để thông báo về sự thay đổi trạng thái.

Bất kỳ loại hoạt động "sự kiện quan trọng" hoặc "ghi nhật ký" một chiều nào khác đều có thể được xử lý độc đáo với các gói UDP. Bạn muốn gửi thông báo mà không cần xây dựng toàn bộ ổ cắm. Bạn không mong đợi bất kỳ phản hồi từ những người nghe khác nhau.

Hệ thống tin nhắn "heartbeat" hoặc "Tôi còn sống" cũng là một lựa chọn tốt. Thiếu một người không phải là một cuộc khủng hoảng. Thiếu nửa tá (liên tiếp) là.

Tôi làm việc trên một sản phẩm hỗ trợ cả giao tiếp UDP (IP) và TCP / IP giữa máy khách và máy chủ. Nó bắt đầu với IPX hơn 15 năm trước với sự hỗ trợ IP được thêm vào 13 năm trước. Chúng tôi đã thêm hỗ trợ TCP / IP 3 hoặc 4 năm trước. Dự đoán hoang dã sắp tới: Tỷ lệ mã UDP và TCP có thể là khoảng 80/20. Sản phẩm này là một máy chủ cơ sở dữ liệu, vì vậy độ tin cậy là rất quan trọng. Chúng tôi phải xử lý tất cả các vấn đề do UDP áp đặt (mất gói, nhân đôi gói, thứ tự gói, v.v.) đã được đề cập trong các câu trả lời khác. Hiếm khi có bất kỳ vấn đề, nhưng đôi khi chúng xảy ra và do đó phải được xử lý. Lợi ích của việc hỗ trợ UDP là chúng tôi có thể tùy chỉnh nó một chút theo cách sử dụng của riêng chúng tôi và điều chỉnh hiệu suất cao hơn một chút so với nó.

Mỗi mạng sẽ khác nhau, nhưng giao thức truyền thông UDP thường nhanh hơn một chút đối với chúng tôi. Người đọc hoài nghi sẽ hỏi đúng liệu chúng tôi có thực hiện đúng mọi thứ không. Thêm vào đó, bạn có thể mong đợi gì từ một anh chàng có đại diện 2 chữ số? Tuy nhiên, bây giờ tôi mới chạy thử vì tò mò. Bài kiểm tra đọc 1 triệu bản ghi (chọn * từ đôi khi). Tôi đặt số lượng hồ sơ trả về với mỗi yêu cầu khách hàng cá nhân là 1, 10 và sau đó là 100 (ba lần chạy thử với mỗi giao thức). Máy chủ chỉ cách hai bước nhảy trên mạng LAN 100Mbit. Các con số dường như đồng ý với những gì người khác đã tìm thấy trong quá khứ (UDP nhanh hơn khoảng 5% trong hầu hết các tình huống). Tổng số lần tính bằng mili giây như sau đối với thử nghiệm cụ thể này:

1. 1 kỷ lục
   • IP: 390,760 ms
   • TCP: 416,903 ms
2. 10 hồ sơ
   • IP: 91.7707 ms
   • TCP: 95.662 ms
3. 100 hồ sơ
   • IP: 29.664 ms
   • TCP: 30.968 ms

Tổng lượng dữ liệu được truyền là tương đương nhau cho cả IP và TCP. Chúng tôi có thêm chi phí với truyền thông UDP vì chúng tôi có một số nội dung tương tự mà bạn nhận được "miễn phí" với TCP / IP (tổng kiểm, số thứ tự, v.v.). Ví dụ, Wireshark đã chỉ ra rằng một yêu cầu cho bộ bản ghi tiếp theo là 80 byte với UDP và 84 byte với TCP.

Đã có nhiều câu trả lời hay ở đây, nhưng tôi muốn thêm một yếu tố rất quan trọng cũng như tóm tắt. UDP có thể đạt được thông lượng cao hơn nhiều với điều chỉnh chính xác vì nó không sử dụng điều khiển tắc nghẽn . Kiểm soát tắc nghẽn trong TCP là rất rấtquan trọng. Nó kiểm soát tốc độ và thông lượng của kết nối để giảm thiểu tắc nghẽn mạng bằng cách cố gắng ước tính dung lượng hiện tại của kết nối. Ngay cả khi các gói được gửi qua các liên kết rất đáng tin cậy, chẳng hạn như trong mạng lõi, bộ định tuyến có bộ đệm kích thước giới hạn. Các bộ đệm này chứa đầy dung lượng và các gói sau đó bị loại bỏ và TCP thông báo điều này giảm do không có xác nhận đã nhận, do đó điều chỉnh tốc độ kết nối để ước tính dung lượng. TCP cũng sử dụng một thứ gọi là khởi động chậm , nhưng thông lượng (thực ra là cửa sổ tắc nghẽn) được tăng chậm cho đến khi các gói được loại bỏ, và sau đó được hạ xuống và từ từ tăng trở lại cho đến khi các gói bị giảm, v.v ... Điều này làm cho thông lượng TCP dao động. Bạn có thể thấy rõ điều này khi bạn tải xuống một tệp lớn.

Bởi vì UDP không sử dụng điều khiển tắc nghẽn, nó có thể nhanh hơn và trải nghiệm độ trễ ít hơn vì nó sẽ không tìm cách tối đa hóa bộ đệm cho đến điểm rơi, tức là các gói UDP đang sử dụng ít thời gian hơn trong bộ đệm và đến đó nhanh hơn với độ trễ thấp hơn. Bởi vì UDP không sử dụng điều khiển tắc nghẽn, nhưng TCP thì có, nó có thể lấy đi dung lượng từ TCP mang lại luồng UDP.

Mặc dù vậy, UDP vẫn dễ bị tắc nghẽn và giảm gói tin, vì vậy ứng dụng của bạn phải được chuẩn bị để xử lý các biến chứng này bằng cách nào đó, có thể sử dụng truyền lại hoặc sửa mã lỗi.

Kết quả là UDP có thể:

• Đạt được thông lượng cao hơn TCP miễn là tốc độ rớt mạng nằm trong giới hạn mà ứng dụng có thể xử lý.
• Cung cấp các gói nhanh hơn TCP với độ trễ ít hơn.
• Thiết lập kết nối nhanh hơn vì không có bắt tay ban đầu để thiết lập kết nối
• Truyền các gói phát đa hướng, trong khi TCP phải sử dụng nhiều kết nối.
• Truyền các gói kích thước cố định, trong khi TCP truyền dữ liệu theo phân đoạn. Nếu bạn chuyển gói UDP 300 Byte, bạn sẽ nhận được 300 Byte ở đầu kia. Với TCP, bạn có thể cung cấp ổ cắm gửi 300 Byte, nhưng người nhận chỉ đọc 100 Byte và bạn phải tìm ra bằng cách nào đó có thêm 200 byte trên đường đi. Điều này rất quan trọng nếu ứng dụng của bạn truyền các thông điệp có kích thước cố định, thay vì một luồng byte.

Tóm lại, UDP có thể được sử dụng cho mọi loại ứng dụng mà TCP có thể, miễn là bạn cũng thực hiện cơ chế truyền lại phù hợp. UDP có thể rất nhanh, ít trễ hơn, không bị ảnh hưởng bởi tắc nghẽn trên cơ sở kết nối, truyền các datagram có kích thước cố định và có thể được sử dụng để phát đa hướng.

UDP có ít chi phí hoạt động hơn và rất tốt để thực hiện những việc như truyền dữ liệu thời gian thực như âm thanh hoặc video, hoặc trong mọi trường hợp đều ổn nếu mất dữ liệu.

UDP là một giao thức không có kết nối và được sử dụng trong các giao thức như SNMP và DNS trong đó các gói dữ liệu không theo thứ tự được chấp nhận và việc truyền ngay các gói dữ liệu trở nên có thể chấp nhận được.

Nó được sử dụng trong SNMP vì việc quản lý mạng thường phải được thực hiện khi mạng bị căng thẳng, tức là khi việc truyền dữ liệu được kiểm soát tắc nghẽn khó tin cậy.

Nó được sử dụng trong DNS vì nó không liên quan đến thiết lập kết nối, do đó tránh sự chậm trễ của thiết lập kết nối.

chúc mừng

Một trong những câu trả lời hay nhất mà tôi biết cho câu hỏi này đến từ người dùng zAy0LfpBZLC8mAC tại Hacker News . Câu trả lời này rất hay, tôi sẽ trích dẫn nó như hiện tại.

TCP có chức năng chặn hàng đợi, vì nó đảm bảo phân phối đầy đủ và theo thứ tự, do đó, khi một gói bị mất trong quá trình vận chuyển, nó phải chờ truyền lại gói bị thiếu, trong khi UDP gửi gói đến ứng dụng khi chúng đến , bao gồm các bản sao và không có bất kỳ đảm bảo nào rằng một gói đến tất cả hoặc thứ tự chúng đến (thực chất là IP với số cổng và tổng kiểm tra tải trọng (tùy chọn) được thêm vào), ví dụ như vậy là tốt cho điện thoại Đơn giản là không có vấn đề gì khi thiếu vài mili giây âm thanh, nhưng độ trễ rất khó chịu, vì vậy bạn không bận tâm đến việc truyền lại, bạn chỉ cần bỏ bất kỳ bản sao nào, sắp xếp các gói được sắp xếp lại theo đúng thứ tự trong vài trăm mili giây của bộ đệm jitter và nếu các gói không hiển thị kịp thời hoặc hoàn toàn, chúng chỉ bị bỏ qua,có thể nội suy nơi được hỗ trợ bởi codec.

Ngoài ra, một phần chính của TCP là kiểm soát luồng, để đảm bảo bạn nhận được càng nhiều thông tin càng tốt, nhưng không làm quá tải mạng (điều này hơi dư thừa, vì mạng quá tải sẽ làm mất các gói của bạn, điều đó có nghĩa là bạn phải làm truyền lại, làm tổn thương thông lượng), UDP không có bất kỳ điều gì - điều này có ý nghĩa đối với các ứng dụng như điện thoại, vì điện thoại với một codec nhất định cần một lượng băng thông nhất định, bạn không thể "làm chậm" và băng thông bổ sung cũng không làm cho cuộc gọi đi nhanh hơn.

Ngoài các ứng dụng thời gian thực / độ trễ thấp, UDP có ý nghĩa đối với các giao dịch thực sự nhỏ, chẳng hạn như tra cứu DNS, đơn giản vì nó không có thiết lập kết nối TCP và chi phí phá vỡ, cả về độ trễ và về sử dụng băng thông. Nếu yêu cầu của bạn nhỏ hơn MTU thông thường và cũng có thể lặp lại, bạn có thể thực hiện trong một vòng, không cần giữ bất kỳ trạng thái nào tại máy chủ và điều khiển luồng theo thứ tự và tất cả những điều đó có thể không đặc biệt hữu ích cho sử dụng như vậy hoặc.

Và sau đó, bạn có thể sử dụng UDP để xây dựng các thay thế TCP của riêng mình, nhưng có lẽ không phải là ý tưởng hay nếu không hiểu sâu về động lực học mạng, thuật toán TCP hiện đại khá phức tạp.

Ngoài ra, tôi đoán nên đề cập rằng có nhiều hơn UDP và TCP, chẳng hạn như SCTP và DCCP. Vấn đề duy nhất hiện nay là internet (IPv4) có đầy đủ các cổng NAT khiến cho không thể sử dụng các giao thức khác ngoài UDP và TCP trong các ứng dụng của người dùng cuối.

Truyền phát video là một ví dụ hoàn hảo về việc sử dụng UDP.

UDP có chi phí thấp hơn, như đã nêu là tốt cho việc truyền phát những thứ như video và âm thanh, tốt hơn hết là chỉ mất một gói sau đó cố gắng gửi lại và bắt kịp.

Không có đảm bảo nào về việc phân phối TCP, bạn chỉ cần được thông báo nếu ổ cắm bị ngắt kết nối hoặc về cơ bản nếu dữ liệu sẽ không đến. Nếu không thì nó đến đó khi nó đến đó.

Một điều lớn mà mọi người quên là udp là dựa trên gói và tcp là dựa trên bytestream, không có gì đảm bảo rằng "gói tcp" bạn đã gửi là gói hiển thị ở đầu bên kia, nó có thể được chia thành nhiều gói như các bộ định tuyến và ngăn xếp mong muốn. Vì vậy, phần mềm của bạn có thêm chi phí phân tích cú pháp trở lại thành các khối dữ liệu có thể sử dụng được, có thể mất một lượng chi phí khá lớn. UDP có thể bị lỗi do đó bạn phải đánh số các gói của mình hoặc sử dụng một số cơ chế khác để sắp xếp lại chúng nếu bạn quan tâm. Nhưng nếu bạn nhận được gói udp đó, nó sẽ đến với tất cả các byte theo cùng thứ tự như nó để lại, không có thay đổi. Vì vậy, thuật ngữ gói udp có ý nghĩa nhưng gói tcp không nhất thiết phải có. TCP có cơ chế thử lại và đặt hàng riêng được ẩn khỏi ứng dụng của bạn,

UDP dễ dàng hơn nhiều để viết mã cho cả hai đầu, về cơ bản vì bạn không phải thực hiện và duy trì các kết nối điểm tới điểm. Câu hỏi của tôi thường là các tình huống mà bạn muốn có chi phí TCP ở đâu? Và nếu bạn sử dụng các phím tắt như giả sử "gói" tcp nhận được là gói hoàn chỉnh đã được gửi, bạn có tốt hơn không? (bạn có thể vứt bỏ hai gói nếu bạn muốn kiểm tra độ dài / nội dung)

Giao tiếp mạng cho các trò chơi video hầu như luôn được thực hiện qua UDP.

Tốc độ là vô cùng quan trọng và nó không thực sự quan trọng nếu các bản cập nhật bị bỏ lỡ vì mỗi bản cập nhật chứa trạng thái hiện tại hoàn chỉnh của những gì người chơi có thể thấy.

Câu hỏi chính liên quan đến "loại tình huống nào UDP sẽ là lựa chọn tốt hơn [trên tcp]"

Có nhiều câu trả lời tuyệt vời ở trên nhưng điều còn thiếu là bất kỳ đánh giá chính thức, khách quan nào về tác động của sự không chắc chắn về vận chuyển đối với hiệu suất TCP.

Với sự phát triển mạnh mẽ của các ứng dụng di động và các mô hình "thỉnh thoảng được kết nối" hoặc "đôi khi bị ngắt kết nối" đi kèm với chúng, chắc chắn có những tình huống mà các nỗ lực của TCP cố gắng duy trì kết nối khi các kết nối khó có thể dẫn đến sự mạnh mẽ trường hợp cho UDP và bản chất "hướng thông điệp" của nó.

Bây giờ tôi không có toán / nghiên cứu / số về điều này, nhưng tôi đã tạo ra các ứng dụng hoạt động đáng tin cậy hơn bằng cách sử dụng và ACK / NAK và đánh số tin nhắn qua UDP so với TCP khi kết nối thường kém và TCP cũ kém chỉ mất thời gian và tiền của khách hàng của tôi chỉ cố gắng kết nối. Bạn nhận được điều này trong khu vực và nông thôn của nhiều nước phương Tây ....

Trong một số trường hợp, điều mà những người khác đã nhấn mạnh, việc đảm bảo các gói đến không quan trọng và do đó sử dụng UDP là ổn. Có những trường hợp khác mà UDP thích hợp hơn TCP.

Một trường hợp duy nhất mà bạn muốn sử dụng UDP thay vì TCP là nơi bạn đang tạo đường hầm TCP qua giao thức khác (ví dụ: đường hầm, mạng ảo, v.v.). Nếu bạn tạo đường hầm TCP qua TCP, các điều khiển tắc nghẽn của mỗi cái sẽ can thiệp lẫn nhau. Do đó, người ta thường thích đường hầm TCP hơn UDP (hoặc một số giao thức không trạng thái khác). Xem bài viết của TechRepublic: Tìm hiểu về TCP qua TCP: Ảnh hưởng của đường hầm TCP đến thông lượng và độ trễ từ đầu đến cuối .

UDP có thể được sử dụng khi một ứng dụng quan tâm nhiều hơn đến dữ liệu "thời gian thực" thay vì sao chép dữ liệu chính xác. Ví dụ, VOIP có thể sử dụng UDP và ứng dụng sẽ lo lắng về việc sắp xếp lại các gói, nhưng cuối cùng VOIP không cần mỗi gói duy nhất, nhưng quan trọng hơn là cần một luồng liên tục của nhiều gói. Có thể bạn ở đây "trục trặc" về chất lượng giọng nói, nhưng mục đích chính là bạn nhận được tin nhắn và không phải nó được tái tạo hoàn hảo ở phía bên kia. UDP cũng được sử dụng trong các tình huống trong đó chi phí tạo kết nối và đồng bộ hóa với TCP lớn hơn tải trọng. Các truy vấn DNS là một ví dụ hoàn hảo. Một gói ra, một gói trở lại, mỗi truy vấn. Nếu sử dụng TCP, điều này sẽ chuyên sâu hơn nhiều. Nếu bạn không nhận được phản hồi DNS, bạn chỉ cần thử lại.

UDP khi tốc độ là cần thiết và độ chính xác nếu các gói không và TCP khi bạn cần độ chính xác.

UDP thường khó hơn ở chỗ bạn phải viết chương trình của mình theo cách không phụ thuộc vào độ chính xác của các gói.

Nó không phải lúc nào cũng rõ ràng. Tuy nhiên, nếu bạn cần phân phối đảm bảo các gói không bị mất và theo đúng trình tự thì TCP có thể là thứ bạn muốn.

Mặt khác, UDP thích hợp để truyền các gói thông tin ngắn trong đó chuỗi thông tin ít quan trọng hơn hoặc nơi dữ liệu có thể vừa với một gói.

Nó cũng thích hợp khi bạn muốn phát cùng một thông tin cho nhiều người dùng.

Những lần khác, nó phù hợp khi bạn gửi dữ liệu tuần tự nhưng nếu một số dữ liệu bị mất thì bạn không quá lo lắng (ví dụ: ứng dụng VOIP).

Một số giao thức phức tạp hơn vì những gì cần thiết là một số (nhưng không phải tất cả) các tính năng của TCP, nhưng nhiều hơn những gì UDP cung cấp. Đó là nơi lớp ứng dụng phải thực hiện các chức năng bổ sung. Trong những trường hợp đó, UDP cũng phù hợp (ví dụ: Internet radio, thứ tự rất quan trọng nhưng không phải gói nào cũng cần phải vượt qua).

Ví dụ về nơi sử dụng / có thể được sử dụng 1) Máy chủ thời gian phát sóng đúng thời gian tới một loạt các máy trên mạng LAN. 2) Giao thức VOIP 3) Tra cứu DNS 4) Yêu cầu dịch vụ LAN, ví dụ bạn đang ở đâu? 5) Internet radio 6) và nhiều người khác ...

Trên unix, bạn có thể nhập grep udp / etc / services để nhận danh sách các giao thức UDP được triển khai ngày hôm nay ... có hàng trăm.

Xem phần 22.4 của Lập trình mạng Unix của Steven , "Khi nào nên sử dụng UDP thay vì TCP".

Ngoài ra, hãy xem câu trả lời SO khác về quan niệm sai lầm rằng UDP luôn nhanh hơn TCP .

Những gì Steven nói có thể được tóm tắt như sau:

• Sử dụng UDP để phát và phát đa hướng vì đó là tùy chọn duy nhất của bạn (sử dụng phát đa hướng cho bất kỳ ứng dụng mới nào)
• Bạn có thể sử dụng UDP cho các ứng dụng yêu cầu / trả lời đơn giản, nhưng bạn sẽ cần xây dựng các mục, thời gian chờ và truyền lại của riêng bạn
• Không sử dụng UDP để truyền dữ liệu số lượng lớn.

Chúng tôi biết rằng UDP là giao thức không có kết nối, vì vậy nó là

1. thích hợp cho quá trình yêu cầu giao tiếp đáp ứng yêu cầu đơn giản.
2. phù hợp với quy trình có lưu lượng nội bộ, kiểm soát lỗi
3. thích hợp cho đúc rộng và đa hướng

Ví dụ cụ thể:

• được sử dụng trong SNMP
• được sử dụng cho một số giao thức cập nhật tuyến đường như RIP

So sánh TCP với UDP, các giao thức không có kết nối như UDP đảm bảo tốc độ, nhưng không đáng tin cậy về việc truyền gói. Ví dụ: trong các trò chơi video thường không cần một mạng đáng tin cậy nhưng tốc độ là quan trọng nhất và sử dụng UDP cho các trò chơi có lợi thế là giảm độ trễ mạng.

Bạn muốn sử dụng UDP qua TCP trong trường hợp mất một số dữ liệu trên đường đi sẽ không làm hỏng hoàn toàn dữ liệu được truyền. Rất nhiều ứng dụng của nó là trong các ứng dụng thời gian thực, chẳng hạn như chơi game (ví dụ FPS, nơi bạn không phải luôn biết mọi người chơi đang ở đâu vào bất kỳ thời điểm nào và nếu bạn mất một vài gói trên đường đi, mới dữ liệu sẽ cho bạn biết chính xác vị trí của người chơi ở đâu) và truyền phát video theo thời gian thực (một khung bị hỏng sẽ không làm hỏng trải nghiệm xem).

Chúng tôi có dịch vụ web có hàng ngàn máy khách winforms trong nhiều PC. Các PC không có kết nối với phụ trợ DB, tất cả quyền truy cập đều thông qua dịch vụ web. Vì vậy, chúng tôi đã quyết định phát triển một máy chủ ghi nhật ký trung tâm lắng nghe trên cổng UDP và tất cả các máy khách gửi một gói nhật ký lỗi xml (sử dụng app4 UDP của log4net) được đưa vào bảng DB khi nhận được. Vì chúng tôi không thực sự quan tâm nếu một vài nhật ký lỗi bị bỏ qua và với hàng ngàn khách hàng, thật nhanh chóng với một dịch vụ ghi nhật ký chuyên dụng không tải dịch vụ web chính.

Tôi hơi miễn cưỡng khi đề xuất UDP khi TCP có thể hoạt động. Vấn đề là nếu TCP không hoạt động vì một số lý do, vì kết nối quá chậm hoặc bị nghẽn, việc thay đổi ứng dụng để sử dụng UDP dường như không có ích. Một kết nối xấu cũng có hại cho UDP. TCP đã làm rất tốt việc giảm thiểu tắc nghẽn.

Trường hợp duy nhất tôi có thể nghĩ về nơi UDP được yêu cầu là cho các giao thức phát sóng. Trong trường hợp một ứng dụng liên quan đến hai, các máy chủ đã biết, UDP có thể sẽ chỉ cung cấp các lợi ích hiệu suất cận biên cho chi phí tăng đáng kể về độ phức tạp của mã.

Chỉ sử dụng UDP nếu bạn thực sự biết những gì bạn đang làm. UDP là trong những trường hợp cực kỳ hiếm ngày hôm nay, nhưng số lượng chuyên gia (thậm chí rất có kinh nghiệm), những người sẽ cố gắng gắn bó ở mọi nơi dường như không cân xứng. Có lẽ họ thích tự thực hiện xử lý lỗi và bảo trì mã kết nối.

TCP nên được dự kiến ​​sẽ nhanh hơn nhiều với các thẻ giao diện mạng hiện đại do những gì được gọi là dấu ấn tổng kiểm tra . Đáng ngạc nhiên, ở tốc độ kết nối nhanh (chẳng hạn như 1Gbps) tính toán tổng kiểm tra sẽ là một tải trọng lớn cho CPU, do đó, nó được chuyển sang phần cứng NIC nhận ra các gói TCP để in dấu và nó sẽ không cung cấp cho bạn dịch vụ tương tự.

UDP hoàn hảo cho địa chỉ VoIP, nơi gói dữ liệu phải được gửi đi ít liên quan đến độ tin cậy của nó ... Trò chuyện video là một ví dụ về UDP (bạn có thể kiểm tra nó bằng cách chụp mạng wireshark trong bất kỳ cuộc trò chuyện video nào) .. Ngoài ra TCP không hoạt động với Giao thức DNS và SNMP. UDP không có bất kỳ chi phí nào trong khi TCP có nhiều chi phí