Khi nói về "cái gì nhanh hơn" - có ít nhất hai khía cạnh rất khác nhau: thông lượng và độ trễ.
Nếu nói về thông lượng - Kiểm soát luồng của TCP (như đã đề cập trong các câu trả lời khác), là cực kỳ quan trọng và làm bất cứ điều gì có thể so sánh với UDP, trong khi chắc chắn có thể, sẽ là một Nhức đầu lớn (tm). Kết quả là - sử dụng UDP khi bạn cần thông lượng , hiếm khi đủ điều kiện là một ý tưởng hay (trừ khi bạn muốn có được lợi thế không công bằng so với TCP).
Tuy nhiên, nếu nói về độ trễ - toàn bộ điều này hoàn toàn khác. Mặc dù không có mất gói, TCP và UDP hoạt động rất giống nhau (bất kỳ sự khác biệt nào, nếu có, là cận biên) - sau khi gói bị mất, toàn bộ mô hình thay đổi mạnh mẽ.
Sau khi mất gói, TCP sẽ chờ truyền lại ít nhất 200ms (1 giây cho mỗi đoạn 2.4 của RFC6298, nhưng các triển khai hiện đại thực tế có xu hướng giảm xuống còn 200ms). Ngoài ra, với TCP, ngay cả những gói đã đến máy chủ đích - sẽ không được gửi đến ứng dụng của bạn cho đến khi nhận được gói bị thiếu (nghĩa là toàn bộ giao tiếp bị trì hoãn ~ 200ms) - BTW, hiệu ứng này, được gọi là Head-of -Line Blocking, vốn có cho tất cả các luồng được đặt hàng đáng tin cậy, cho dù TCP hoặc UDP đáng tin cậy + được đặt hàng. Để làm cho mọi thứ trở nên tồi tệ hơn - nếu gói truyền lại cũng bị mất, thì chúng ta sẽ nói về độ trễ ~ 600ms (do cái gọi là backoffential theo cấp số nhân, lần truyền lại thứ nhất là 200ms và lần thứ hai là 200 * 2 = 400ms). Nếu kênh của chúng tôi bị mất gói 1% (không tệ theo tiêu chuẩn ngày nay), và chúng tôi có một trò chơi với 20 cập nhật mỗi giây - sự chậm trễ 600ms như vậy sẽ xảy ra trung bình cứ sau 8 phút. Và vì 600ms là quá đủ để khiến bạn bị giết trong một trò chơi có nhịp độ nhanh - tốt, nó khá tệ cho trò chơi. Những hiệu ứng này chính xác là lý do tại sao các gamedev thường thích UDP hơn TCP.
Tuy nhiên, khi sử dụng UDP để giảm độ trễ - điều quan trọng là phải nhận ra rằng chỉ "sử dụng UDP" là không đủ để cải thiện độ trễ đáng kể, tất cả là về CÁCH BẠN đang sử dụng UDP. Đặc biệt, trong khi các thư viện RUDP thường tránh "backoffential mũ" đó và sử dụng thời gian truyền lại ngắn hơn - nếu chúng được sử dụng như một luồng "có thứ tự đáng tin cậy", thì chúng vẫn phải chịu Chặn đầu dòng (vì vậy trong trường hợp gấp đôi mất gói, thay vì 600ms, chúng tôi sẽ nhận được khoảng 1,5 * 2 * RTT - hoặc với RTT 80ms khá tốt, đó là độ trễ ~ 250ms, đây là một cải tiến, nhưng vẫn có thể làm tốt hơn). Mặt khác, nếu sử dụng các kỹ thuật được thảo luận trong http://gafferongames.com/networked-physics/snapshot-compression/ và / hoặc http: // ithare. , có thể loại bỏ hoàn toàn việc chặn Head-of-Line (vì vậy, đối với việc mất gói kép cho trò chơi với 20 lần cập nhật / giây, độ trễ sẽ là 100ms bất kể RTT).
Và như một lưu ý phụ - nếu bạn chỉ có quyền truy cập vào TCP nhưng không có UDP (chẳng hạn như trong trình duyệt hoặc nếu khách hàng của bạn đứng sau một trong 6-9% tường lửa xấu xí chặn UDP) - dường như có một cách để triển khai UDP-over-TCP mà không phát sinh quá nhiều độ trễ, xem tại đây: http://ithare.com/al ultra -zo-additable -latency-udp-over-tcp / (đảm bảo cũng đọc các bình luận (!)).