Liệu nó có ý nghĩa để sử dụng cả TCP và UDP cùng một lúc?

Sau khi đọc UDP có còn tốt hơn TCP cho các trò chơi thời gian thực nặng dữ liệu không? , Tôi tự hỏi liệu có hợp lý khi sử dụng cả TCP và UDP cùng một lúc không, nhưng đối với những thứ khác nhau:

• TCP để gửi thông tin được gửi không thường xuyên, nhưng nên được đảm bảo đến nơi đáng tin cậy.
  Chẳng hạn như cập nhật điểm số, tên người chơi hoặc thậm chí trạng thái bật / tắt của ánh sáng trong thế giới trò chơi.

• UDP để truyền thông tin được cập nhật liên tục và đôi khi có thể bị mất, vì thông tin mới hơn luôn luôn xuất hiện.
  Chẳng hạn như vị trí, luân chuyển, vv

Đây có phải là một ý tưởng hợp lý? Những hạn chế có thể là gì?
Có cách nào tốt hơn để xử lý việc này?

Nó dẫn đến mất gói cho UDP do sự tranh chấp giữa hai giao thức - hãy nhớ rằng UDP không được đảm bảo phân phối, trong khi TCP là. Nhiều gói TCP sẽ vượt qua trong khi UDP bị ảnh hưởng - TCP gây ra mất gói UDP . Cũng có ý tưởng (lịch sử) rằng cơ sở hạ tầng bộ định tuyến ủng hộ TCP hơn UDP, mặc dù tôi nghi ngờ điều đó vẫn đúng trong giai đoạn cuối này.

Tôi nghĩ rằng bạn nên tìm một trong các giao thức UDP hướng kết nối được sử dụng trong các trò chơi và tương tự, cung cấp cho bạn một số lợi ích của TCP mà không có nhược điểm nào. Có một vài như vậy, thường là với một whitepaper chi tiết từng khái niệm.

Một ví dụ trong số đó là thư viện Enet mã nguồn mở , tính năng chính của nó là tùy chọn đáng tin cậy, phân phối các gói theo thứ tự qua UDP.

Đây là một trích dẫn của Sam Jansen từ một bình luận trên gafferongames.com :

Nói như một nhà nghiên cứu mạng và không phải là nhà phát triển trò chơi, kết luận không bao giờ sử dụng TCP và UDP cùng nhau có vẻ hơi mạnh mẽ. TCP sẽ chỉ bị mất gói nếu nó đang gửi quá nhiều dữ liệu; theo một số cách giống như dữ liệu UDP bạn đang gửi. Sự khác biệt là bạn không có quyền kiểm soát trực tiếp về tốc độ TCP gửi, điều này được ẩn cho bạn.

Nếu bạn chỉ cần gửi một số dữ liệu đáng tin cậy và không muốn lo lắng về việc truyền lại và thực hiện một giao thức đáng tin cậy, và bạn biết rằng tốc độ sẽ thấp, thì sẽ không có vấn đề gì khi sử dụng cả TCP và UDP.

Mối quan hệ không quá phức tạp giữa hai người thực sự: TCP chỉ tăng tốc độ gửi của nó (nếu có dữ liệu để gửi) cho đến khi bị mất gói, trong trường hợp đó, nó quay lại tốc độ của nó, sau đó bắt đầu tăng lại tốc độ (điều này thời gian chậm hơn). Khi tốc độ tăng của nó gây ra mất gói, nó cũng có khả năng tấn công bất kỳ luồng dữ liệu nào khác, bao gồm cả các gói UDP của bạn.

Đặc điểm giấy của Mất gói UDP: Hiệu ứng của lưu lượng TCP có kết quả bằng cách mở nhiều kết nối TCP cùng một lúc và làm ngập dữ liệu mạng. Điều này dẫn đến tắc nghẽn sau đó là đồng bộ hóa toàn cầu , cả hai đều gây ra các gói bị rơi. Rõ ràng, một khách hàng trò chơi sẽ không mở hàng tá kết nối cùng một lúc và tràn ngập mạng với dữ liệu, và do đó kết quả của bạn sẽ khác.

Để trả lời câu hỏi của bạn:

Tôi tự hỏi liệu có hợp lý khi sử dụng cả TCP và UDP cùng một lúc không, nhưng đối với những thứ khác nhau [...]

Có, đây là một điều có thể chấp nhận được khi giả sử bạn ở trong giới hạn băng thông của mình.

• TCP để gửi thông tin được gửi không thường xuyên, nhưng nên được đảm bảo đến nơi đáng tin cậy. Chẳng hạn như cập nhật điểm số, tên người chơi hoặc thậm chí trạng thái bật / tắt của ánh sáng trong thế giới trò chơi.

Khi sử dụng cả TCP và UDP, bạn luôn muốn gửi càng nhiều càng tốt qua UDP và càng ít càng tốt qua TCP.

Bây giờ, tôi hỏi bạn điều này: Có thực sự cần thiết phải gửi điểm số, tên người chơi và trạng thái của ánh sáng qua TCP không? Mặc dù đúng là bạn cần nhận dữ liệu này sau cùng, nhưng có đúng là bạn cần nhận dữ liệu này theo đúng thứ tự và chính xác một lần không?

Chắc là không.

UDP hoạt động tốt trong những trường hợp này và Quake 3 là một ví dụ điển hình về cách thức.

Vì vậy, một ví dụ tốt về TCP cùng với UDP là gì? Chà, nghĩ về chatbox của một trò chơi. Các bản cập nhật cho hộp trò chuyện này (nghĩa là các dòng văn bản mới) cần phải được gửi một cách đáng tin cậy và theo thứ tự nghiêm ngặt. Do đó, TCP là một sự phù hợp tốt.

Đây có phải là một ý tưởng hợp lý?

• Đúng

Những hạn chế có thể là gì?

• Mất gói, độ phức tạp mã nhiều hơn, một kết nối khác để quản lý == nhiều cơ hội hơn cho việc ngắt kết nối, hết thời gian, ngoại lệ, bất cứ điều gì ...

Có cách nào tốt hơn để xử lý việc này?

• Sử dụng Thư viện UDP đáng tin cậy hiện có. Hai trong số phổ biến nhất là: Mạng lưới Lidgren (C #), RakNet (C ++). Từ kinh nghiệm tôi có thể nói Lidgren siêu dễ sử dụng, nhanh chóng và đáng tin cậy.

Có một hạn chế tài nguyên bổ sung để xem xét. Hầu hết các triển khai (Tôi tin tất cả, nhưng không có tài liệu tham khảo) về TCP trên máy chủ có giới hạn về số lượng Kết nối TCP đồng thời mà máy chủ có thể mở cùng một lúc. Điều này sẽ giới hạn số lượng người chơi bạn có thể mở cùng một lúc nếu mỗi người chơi cần kết nối riêng.

Các giới hạn được xác định bởi các cài đặt trong hệ thống mạng. Ngoài ra, mọi kết nối đều sử dụng một số bộ nhớ phải đến từ một nơi nào đó trên máy chủ.

Một giải pháp là chỉ mở Kết nối TCP tạm thời trong khi dữ liệu được truyền và Đóng ngay lập tức. Điều này sẽ làm cho các giao dịch chậm hơn, mở Kết nối tcp là một quá trình khá "tốn kém". Như mọi khi, tất cả là về việc thiết kế một hệ thống mạnh mẽ ngay từ đầu để cho phép tăng trưởng lớn.