Tại sao nhà phát triển trò chơi tránh TCP và khiến UDP đáng tin cậy ở cấp ứng dụng?

Question

Nhiều nhà phát triển trò chơi chọn thực hiện UDPđáng tin cậy ở mức ứng dụng . Đó không phải là những gì TCP được tạo ra? Tôi đã tạo một API cho phép giao tiếp Client-Server bằng các gói UDP và TCP. Tôi có nên thêm UDP đáng tin cậy vào danh sách không? Và tại sao? Có vấn đề gì nếu tôi sử dụng TCP?

Tôi chỉ muốn biết nếu RUDP có bất kỳ lợi ích nào trên TCP, để tôi có thể chọn có thêm hỗ trợ RUDP hay không.

Answer 1

Trả lời ngắn: TCP không được tối ưu hóa cho độ trễ (ở tất cả); kết quả là - nó có một số thuộc tính là kẻ giết người tiềm ẩn cho các trò chơi (mặc dù chúng chỉ được phát khi gói bị mất). Đặc biệt, việc chặn đầu dòng và trả về theo hàm mũ có xu hướng gây phiền toái cho các trò chơi có nhịp độ nhanh.

Độ trễ lớn nhất là chặn đầu dòng (còn gọi là chặn HOL): nếu một gói bị mất, tất cả các gói tiếp theo trong cùng một luồng, ngay cả khi chúng đến được phía bên kia của giao tiếp, không được phép tiếp cận cấp ứng dụng (ouch!), cho đến khi gói bị mất được truyền lại (và điều này sẽ mất khoảng 2 * RTT, thậm chí cho một máy chủ trên mỗi châu lục, khoảng 100 ms (= "trong một game bắn súng, bạn đã bị giết))

Long trả lời:.

Đó là một chủ đề phức tạp, và chúng ta cần phải phân biệt một số kịch bản khác nhau:

1. chúng tôi cần luồng tin nhắn được đặt hàng đáng tin cậy (hoặc byte). Trong trường hợp này, lợi ích của RUDP trên TCP, trong khi hiện tại, rất nhỏ (chúng ta có thể chơi một chút với việc giảm thời gian truyền lại - và loại bỏ trở lại theo hàm mũ, nhưng đó là khá nhiều). Đặc biệt, việc chặn đầu dòng vẫn không thể tránh khỏi với bất kỳ loại luồng được đặt hàng đáng tin cậy nào (cho dù TCP, RUDP hay bất kỳ thứ gì khác).

2. chúng tôi KHÔNG cần phân phối tin nhắn đáng tin cậy nhưng có khả năng không có thứ tự. Điều này có thể cho phép để ngăn chặn HOL chặn, nhưng yêu cầu xử lý cấp ứng dụng khá phức tạp.

3. chúng tôi KHÔNG cần độ tin cậy (= "lửa và quên"). Một ví dụ điển hình của thông tin đó là khi chúng ta cần hiển thị dấu đầu dòng - nếu chúng tôi không hiển thị nó ngay lập tức, không cần phải hiển thị nó nửa giây sau, vì vậy nếu gói tin không làm cho nó - tốt, tốt hơn là chỉ cần bỏ qua nó và không chi tiêu tài nguyên khi gửi lại gói.

4. chúng tôi cần trạng thái đồng bộ hóa cuối cùng (nhưng chúng tôi KHÔNG quan tâm đến việc đi qua tất cả các trạng thái trung gian); đây là một kịch bản cực kỳ phổ biến cho các mô phỏng. IS này có thể thực hiện trên UDP (và không có hình phạt chặn HOL). Tuy nhiên - cho phép nén trên các kết nối không đáng tin cậy là không nhỏ, và nén là PHẢI cho hầu hết các trò chơi trên mạng. May mắn thay - việc nén IS có thể thực hiện được (xem http://gafferongames.com/networked-physics/snapshot-compression/ và/hoặc http://ithare.com/udp-from-mog-perspective/#low-latency-compression để thảo luận). Nếu cách tiếp cận này được thực hiện (có thể được thực hiện trên các gói tin không đáng tin cậy) - nó sẽ cung cấp cải thiện đáng kể so với TCP (nó loại bỏ chặn HOL, vì vậy chúng ta đang nói về sự chậm trễ của thứ tự của các ve mạng - và điều này có thể thấp nhất là 1/120 giây ~ = 8ms - qua sự chậm trễ-xung quanh-RTT, và đây là ít nhất 100ms cho một gói bị mất).

Side bình luận:

Trên thực tế, nó có thể để mô phỏng UDP qua TCP (loại bỏ độ trễ TCP) - xem http://ithare.com/almost-zero-additional-latency-udp-over-tcp/. Lưu ý rằng mặc dù để sử dụng nó, tất cả những thứ trên vẫn nên được thực hiện bằng tay. Vẫn không có viên đạn ma thuật nào cho phép tránh việc chặn HOL cho luồng được đặt hàng đáng tin cậy; thay vào đó - kỹ thuật này cho phép thực hiện một số kết nối TCP để hoạt động "gần như là" nó là UDP không đáng tin cậy nhưng không chặn.

Answer 2

Tôi không hiểu quá nhiều về các giao thức này, nhưng theo kiến ​​thức hiện tại của tôi, TCP là giao thức hướng kết nối và UDP là giao thức ít kết nối. UDP chủ yếu được sử dụng trong các trò chơi trực tuyến nhiều người chơi do thực tế là UDP nhanh hơn vì không phục hồi được lỗi. Trong những trò chơi đó, UDP được sử dụng vì độ tin cậy không thực sự quan trọng. TCP thực hiện các bước để đảm bảo tất cả các gói được gửi bởi máy khách, trong khi UDP chỉ gửi chúng mà không kiểm tra xem chúng có được nhận hay không. Hãy sửa tôi nếu tôi sai!

tham khảo: http://www.diffen.com/difference/TCP_vs_UDP

Answer 3

Nếu tôi muốn trực tiếp nói rằng UDP là nhanh hơn, tương đối so với TCP mà nó được sử dụng cho các ứng dụng đó; bạn sẽ không tin và chấp nhận. Các nhà phát triển, thực hiện điều này, do đó phát triển một số độ tin cậy trên UDP (được gọi là RUDP) để làm cho nó phần nào bắt chước TCP. Tuy nhiên, nó không thực hiện hoàn toàn chức năng TCP (tính tổng thể).

Đó là lý do tôi muốn trả lời câu hỏi của bạn có sự tham khảo một bài báo Reliable UDP (RUDP): The Next Big Streaming Protocol?:

TCP có một bộ các hướng dẫn đảm bảo rằng mỗi gói dữ liệu được cho người nhận nó. Nó có thể so sánh với phân phối được ghi lại ở dạng cơ bản nhất của nó. Tuy nhiên, trong khi nó có vẻ hiển nhiên lúc đầu rằng "làm cho chắc chắn thông điệp được có" là tối thượng khi gửi một cái gì đó để người khác, có một vài cân nhắc thêm phải được lưu ý. Nếu liên kết mạng sử dụng TCP/IP thông báo rằng gói đã xuất hiện của chuỗi, sau đó TCP dừng truyền, hủy mọi thứ từ gói ngoài chuỗi, gửi "quay lại nơi nó bị lỗi "tin nhắn, và bắt đầu truyền lại.

Nếu bạn có tất cả thời gian trên thế giới, điều này là tốt. Vì vậy, để chuyển thông tin tiền lương của tôi từ công ty của tôi cho tôi, tôi thẳng thắn không quan tâm nếu điều này mất một micro giây hoặc một giờ, tôi muốn nó thực hiện đúng. TCP là tuyệt vời cho điều đó.

Trong một mô hình dịch vụ video-trung tâm, tuy nhiên, có chỉ đơn giản là quá nhiều dữ liệu mà nếu một vài gói tin không làm cho nó qua liên kết có tình huống mà tôi thà bỏ những gói dữ liệu và tiếp tục với dòng chảy tổng thể của video hơn là lấy mọi chi tiết của nguồn gốc gốc. Não của chúng ta có thể tưởng tượng các bit bị bỏ qua của video cho chúng tôi là miễn là nó không bị phân tâm bởi âm thanh và video dừng chuyển động. Trong các trường hợp này, có tùy chọn chỉ gửi nhiều dữ liệu từ một đầu của liên kết đến liên kết khác một cách kịp thời, bất kể mức độ chính xác bao nhiêu, rõ ràng là mong muốn. Ứng dụng này dành cho loại ứng dụng này là UDP tối ưu. Nếu một gói dường như không có đến, thì người nhận sẽ đợi một lát để xem liệu nó có đến - có khả năng đến thời điểm người xem cần xem khối video đó - và nếu bộ đệm nhận được đến mức gói bị thiếu, sau đó nó đơn giản tiếp tục, và ứng dụng bỏ qua điểm mà dữ liệu bị thiếu, chuyển sang gói tiếp theo và duy trì thời gian của video. Bạn có thể thấy nhấp nháy hoặc một số tạo tác, nhưng thời điểm trôi qua gần như ngay lập tức và nhiều khả năng não của bạn sẽ lấp đầy khoảng trống.

Nếu lỗi này xảy ra dưới TCP thì có thể mất TCP upward of 3 seconds để thương lượng lại chuỗi khởi động lại từ điểm thiếu , loại bỏ tất cả dữ liệu tiếp theo, phải được gửi lại . Chỉ một gói bị mất có thể khiến toàn bộ "cửa sổ" của dữ liệu TCP được gửi lại.

---

Nhiều nhà phát triển trò chơi chọn một làm cho UDP đáng tin cậy trong việc áp dụng mức . Đó không phải là những gì TCP được tạo ra?

Nếu bạn có thể chịu đựng được tốc độ dữ liệu đang được xử lý ở cả hai đầu thì OK.

Nhưng, trong trò chơi, điều này không ổn. Bạn phải vượt qua các khung hình video (và âm thanh, vv.) Nhiều lần trong một giây mà quá nhiều người chơi (nếu nhiều người chơi). Tất cả đều cần tốc độ nhanh hơn và khả năng xử lý dữ liệu nhanh hơn; thay vì sử dụng TCP tương đối chậm hơn. Ngay cả khi một số gói dữ liệu bị ngắt giữa chừng, thì ứng dụng cũng có thể di chuyển ON, vì bộ não cũng sẽ chuyển sang phần tiếp theo thay vì nghĩ về những jitters đó.

Tôi đã tạo API cho phép giao tiếp Client-Server bằng UDP và gói TCP. Tôi có nên thêm UDP đáng tin cậy vào danh sách không? Và tại sao? Có sự cố nếu tôi sử dụng TCP không?

Điều đó phụ thuộc vào cách bạn muốn ứng dụng phản hồi tốt hơn. Tôi muốn đề nghị bạn thêm UDP đáng tin cậy vào danh sách của bạn.

Tôi đã đề cập vấn đề với TCP.

Tôi chỉ muốn biết nếu RUDP có bất kỳ lợi ích nào trên TCP, để tôi có thể chọn có thêm hỗ trợ RUDP hay không.

Với chi phí thấp và tốc độ cao hơn, tôi đặt cược cho UDP đáng tin cậy, so với TCP cồng kềnh - để phát triển các ứng dụng như vậy (chơi game).

Answer 4

Sự cố xảy ra với gói không theo yêu cầu.

Sau khi tìm hiểu về vấn đề này, TCP sẽ hog tất cả các gói đã nhận cho đến khi chúng được nhận theo thứ tự ứng dụng mong đợi. Điều này có thể gây bất lợi cho hiệu suất cho trò chơi nhiều người chơi có kích thước hợp lý, nơi bạn chỉ quan tâm đến các vị trí mới nhất người chơi mới nhất và không phải nơi chúng xảy ra cách đây vài phần nghìn giây.

RUDP thay đổi tất cả những gì và chỉ cung cấp "nhất gói gần đây" như Erik từ Unity khẳng định:

Erik-Juhl @Unity Technologies

Người dân Lý do chính sẽ chọn UDP/RUDP trên TCP là vì cách TCP xử lý các gói tin theo thứ tự. Bạn chỉ có thể quan tâm đến gói nhận được gần đây nhất và muốn nó ngay sau khi nó đến. Trong TCP, nếu gói được nhận gần đây nhất của bạn không phải là gói tiếp theo theo thứ tự, TCP sẽ không gửi nó cho bạn cho đến khi mọi thứ khác được nhận.

Nếu bạn cần chuỗi bảo hành và giao hàng thì chỉ cần sử dụng TCP. Nếu bạn cần đảm bảo chuỗi và phân phối cộng với nhận các gói gần đây nhất ngay sau khi chúng đến, hãy sử dụng RUDP. Tell me more...