Giao thức TCP có đủ tốt cho các trò chơi nhiều người chơi trong thời gian thực không?


57

Trước đây, các kết nối TCP qua dialup / ISDN / băng thông rộng chậm dẫn đến các trò chơi bị giật, lag vì một gói bị rơi dẫn đến đồng bộ hóa lại. Điều đó có nghĩa là rất nhiều nhà phát triển trò chơi phải triển khai lớp tin cậy của riêng họ trên UDP hoặc họ đã sử dụng UDP cho các tin nhắn có thể bị mất hoặc nhận không theo thứ tự và sử dụng kết nối TCP song song cho thông tin phải đáng tin cậy.

Với người dùng trung bình có kết nối mạng nhanh hơn bây giờ, một trò chơi thời gian thực như FPS có thể cho hiệu suất tốt hơn kết nối TCP không?


Câu trả lời:


36

Tôi sẽ nói không. Thông tin không gian của các đối tượng trò chơi cần phải nhanh nhất có thể và để sử dụng UDP tốt hơn, vì độ tin cậy không phải là 100%. Ngay cả trên các kết nối hiện đại, UDP vẫn đủ chậm để bạn phải thực hiện một số cân nhắc đặc biệt cho nội suy và như vậy. Ngay cả về lượng dữ liệu được truyền, TCP sẽ thêm chi phí đáng kể vào việc này.

Tuy nhiên, TCP hoàn toàn chấp nhận được đối với những thứ không phải thời gian thực, chẳng hạn như đàm phán nhiều người chơi, tin nhắn trò chuyện, cập nhật điểm số, v.v.


7
Sean là khá nhiều về tiền. Nếu, tình cờ, bạn đang phát triển một trò chơi trong C # /. NET (bạn biết là bạn muốn!), Tôi đã tìm thấy Thư viện mạng Lidgren ( code.google.com/p/lidgren-l Library-network ) khá hay sự lựa chọn tốt. Nó thậm chí còn cung cấp tin nhắn có trật tự, đáng tin cậy qua UDP, nếu bạn cần.
Mike Strobel

2
Thật không khôn ngoan khi trộn cả TCP và UDP; là kết quả của cách TCP thực hiện kiểm soát luồng, nó có thể gây ra mất gói. (nguồn: isoc.org/INET97/proceedings/F3/F3_1.HTM )
Jason Kozak

4
Cũng cần lưu ý rằng trong một số trường hợp, người dùng cuối của bạn sẽ ngồi sau các ISP chặn lưu lượng UDP, có các thiết lập bộ định tuyến ngăn chặn lưu lượng UDP hoặc trong trường hợp sử dụng UDP không lý tưởng. Trong những trường hợp đó, nếu trò chơi của bạn có thể hỗ trợ nó, việc có thể quay trở lại giao tiếp TCP là khá tiện lợi.
Charles Ellis

Một điểm nữa cho UD là gói tự nhiên của nó được định hướng, bạn phải mô phỏng điều này trong TCP nếu cần (boilderplatecode), đáng buồn là các giao thức hiện đại hơn không được hỗ trợ bởi các cửa sổ (điều này thật tệ)
Quonux

11

Vì Flash không hỗ trợ UDP, bằng cách xem các trò chơi Flash nhiều người chơi, bạn có thể biết được những gì có thể xảy ra với TCP / IP và những gì không. Về cơ bản, bạn có thể tạo các trò chơi thời gian thực, miễn là chúng không phụ thuộc vào thời gian phản hồi nhanh như chớp. Một vài ví dụ:

http://www.xgenstudios.com/play/stickarena

http://everybodyedits.com/

Nếu bạn có tùy chọn sử dụng UDP, bạn thực sự nên, nhưng với Flash, thật đáng buồn là bạn không có tùy chọn đó.


8

Nó phụ thuộc.

Các trò chơi như World of Warcraft sử dụng TCP cho giao tiếp của họ, vì bạn tránh được nhiều vấn đề bằng cách sử dụng nó. Kết quả có thể có ping cao hơn, nhưng đối với nhiều trò chơi, điều này có thể chấp nhận được. Bạn cần thực hiện phép nội suy không gian ngay cả khi bạn sử dụng UDP làm giao thức.


1
Đó không chỉ là ping. Có một lý do tại sao không có va chạm giữa người chơi và người chơi trong WoW. Nó sẽ là quá khó để làm tốt. WoW có thể sử dụng TCP vì bạn đang đứng không quan trọng lắm. Nhắm mục tiêu và tấn công không phụ thuộc vào vị trí thực sự của quái vật hoặc người chơi kẻ thù. Nếu bạn quan tâm đến những điều này, thì TCP sẽ làm tổn thương trải nghiệm chơi.
Nuoji

6

Nếu kiến ​​trúc máy khách / máy chủ của bạn sạch sẽ, lớp vận chuyển (gần như) không thành vấn đề.

TCP có một số nhược điểm, nhưng những điều này dễ dàng được xác nhận.

Vì vậy, có, TCP và bộ não là tất cả những gì bạn cần.

Với các thiết lập mạng phổ biến (proxy, tường lửa, v.v.) ngày nay, UDP khá vô dụng đối với tất cả các trò chơi ngoại trừ (đọc: LAN) cục bộ.


7
Nếu bạn downvote, xin vui lòng để lại nhận xét tại sao. Chúng tôi sử dụng TCP và không bao giờ có một vấn đề nào với nó.
Andreas

3
Tôi không thấy sự liên quan của các thiết lập mạng phổ biến trong việc này. Tường lửa thường chỉ can thiệp vào máy chủ lưu trữ, nhưng ngay cả khi đó không phụ thuộc vào giao thức, trong khi các proxy thực sự làm tăng nguy cơ bị chậm hoặc bỏ gói, làm cho UDP trở nên hữu ích hơn nhiều so với mạng cục bộ. Hạn chế của UDP phần lớn có thể được khắc phục bằng cách tự kiểm tra tính toàn vẹn, nhưng bạn không thể lấy các tính năng ra khỏi TCP để làm cho nó nhanh hơn.
Marcks Thomas

1
Bạn cần đề cập đến Nagles . Tôi luôn quên rằng đó là nguyên nhân sâu xa khiến TCP trở nên xấu xa (bộ đệm của Nagle tại máy khách / máy chủ, về cơ bản là "giữ lại" chúng khỏi trò chơi của bạn và đưa ra độ trễ bổ sung).
bobobobo

Có một số lý do tại sao bạn nên sử dụng UDP thay vì TCP nếu độ trễ là mối quan tâm. Nếu bạn không quan tâm đến độ trễ và / hoặc bạn có thể thực hiện đủ dự đoán phía máy khách, thì TCP có thể là đủ. Trong trường hợp trò chơi thời gian thực. Quên TCP.
Nuoji

6

Hoàn toàn chấp nhận được khi sử dụng TCP thay vì UDP - nếu bạn tắt thuật toán của Nagle .

Khi bạn tắt Nagle, bạn có hầu hết tốc độ của UDP và sẽ hoàn toàn có thể tạo ra một trò chơi phản ứng co giật . Thật vậy, tôi đã tạo ra một trò chơi như vậy bằng TCP trong Flash:

http://2dspacemmo.wildbunny.co.uk

Mong rằng sẽ giúp!


Ứng dụng không hoạt động tại liên kết của bạn, thưa ông.
Kỹ sư

Liên kết hoàn toàn bị quay, thưa ông. Tôi nhận được một bài kiểm tra máy chủ Apache.
Gustavo Maciel

4

Đối với các trò chơi FPS, chúng tôi luôn sử dụng UDP. Đặc biệt là nếu bạn đang làm một game bắn súng co giật, nơi ping quan trọng.


4

Nó phụ thuộc vào loại trò chơi.

Một số trò chơi như RTS, chơi tốt hơn nhiều so với TCP và thường sử dụng TCP mọi lúc.

Vấn đề thực sự với TCP là nếu bạn bị mất gói - thậm chí là một lượng nhỏ - thì kết nối sẽ "dừng lại" cho đến khi truyền lại xảy ra. HĐH không thể cung cấp dữ liệu không theo thứ tự cho ứng dụng (điều này phá vỡ sự bảo đảm của TCP, nhưng đồng thời, TCP không hiển thị ranh giới khung ứng dụng). Gian hàng kết nối có nghĩa là dữ liệu muộn sau đó đến. Nhưng trong một trò chơi FPS (ví dụ), dữ liệu lỗi thời là vô ích.

Với UDP, ứng dụng sẽ chọn những gì nó làm với dữ liệu trễ hoặc không theo thứ tự. Nó có thể (và đối với một trò chơi như FPS, thường không) bỏ qua dữ liệu cũ và chỉ lấy những dữ liệu mới nhất. Một gói bị mất thỉnh thoảng không trì hoãn các gói tiếp theo. Nếu một gói bị trì hoãn cuối cùng sẽ đến, nó có thể bị bỏ qua bởi trò chơi.


Lưu ý rằng việc triển khai của bạn sẽ cần xử lý khía cạnh loại bỏ các gói bị trì hoãn, vì UDP sẽ coi nó như một datagram nhận được.
Guvante

3

Đừng chỉ chấp nhận một câu trả lời thẳng thắn "có hoặc không vì tôi đã nói như vậy" vì bạn có thể tự mở ra để phải chiến đấu với hàng loạt vấn đề với UDP mà thực sự bạn không cần phải đối mặt.

Không có câu trả lời nào khác ở đây nêu cách rõ ràng để chứng minh điều này.

Lấy một số sự thật đơn giản

  • Một tiêu đề IP là 20 byte cho dù bạn sử dụng giao thức nào.
  • Các tiêu đề UDP là 4 byte
  • Tiêu đề TCP là 20 byte

Vì vậy, mỗi lần bạn gửi tin nhắn 1 byte xuống dòng bạn thực sự đã gửi 25 hoặc 41 byte tùy thuộc vào giao thức giả sử tiêu đề IP cũng cần thiết.

nguồn:

Lời khuyên của tôi

Hãy xem tình huống của bạn khi bạn cần tương tác máy chủ của khách hàng, ước tính số lượng khách hàng sau đó thực hiện phép toán dựa trên dữ liệu bạn thực sự gửi giữa 2 người.

Một ví dụ

Hãy nói rằng tôi gửi 10 tin nhắn mỗi byte 1 bản cập nhật trong trò chơi của mình và tôi đang cập nhật khoảng 60 khung hình / giây vì vậy tôi cần gửi 60 * 10 = 600 byte mỗi giây dữ liệu tin nhắn thực tế + các tiêu đề có liên quan.

Bây giờ tùy thuộc vào trò chơi, tôi có thể gửi tất cả dưới dạng một tin nhắn để chi phí của tôi từ lớp TCP chỉ là 40 byte (chi phí hiệu quả trên UDP là 20 byte mỗi giây), không có chi phí đó là chi phí tiềm năng là 600 byte ( bởi vì tôi có thể phải gửi lại toàn bộ dòng tin nhắn).

Tuy nhiên, điều cực kỳ quan trọng là mọi tin nhắn đều được gửi ngay lập tức, ngay lập tức nó sẵn sàng được gửi, tôi có 600 tin nhắn (cũng là 600 byte) + 40 * 600 = 24k tổng phí TCP hoặc ~ 14k chi phí UDP mỗi giây + 600 byte dữ liệu tin nhắn.

Một lần nữa, chúng tôi đặt câu hỏi, những thông điệp đó quan trọng như thế nào, mức độ thường xuyên của chúng và chúng có thể được xử lý theo cách nào đó để giảm chi phí không?

Điều đó chỉ dựa trên một loạt các thông điệp byte đơn, thông thường bạn sẽ làm một cái gì đó rất khác nhưng không biết dữ liệu thô được gửi đi khó chứng minh bằng cách nào nếu TCP phù hợp hơn với tình huống của bạn so với UDP.

Vì vậy, nó sẽ làm việc?

Chà, nếu bạn có một khung hình / giây điển hình và vị trí rất quan trọng (để tránh các quyết định gian lận hoặc không chính xác), bạn cần biết rằng luồng mạng của bạn là có thể thực hiện được, nhưng 32 người chơi mỗi luồng phát trực tiếp 24k + byte tin nhắn (vì vậy 768KB / s + tin nhắn) ... đó là khoảng 10mb / s băng thông rộng chỉ dành cho các tiêu đề riêng lẻ dựa trên việc gửi ít nhất 1 tin nhắn trên mỗi khung hình từ mỗi máy khách đến tất cả các máy khách khác thông qua máy chủ.

Bạn rõ ràng sẽ không mã hóa máy chủ và máy khách của mình để hoạt động theo cách đó và kích thước thư rất có thể lớn hơn rất nhiều và có thể ít hơn 1 byte mỗi khung hình trong hầu hết các tình huống nên khó có thể nói rằng không nhìn thấy thế giới thực "Đây là dữ liệu tôi cần gửi" ví dụ.

Trường hợp của tôi

Tôi đã thực hiện cuộc gọi trong trường hợp của mình rằng đó là một chi phí hợp lý nhưng điều đó dựa trên cách tôi xây dựng các luồng thông điệp của mình để tôi không có chi phí quá lớn so với một số thiết kế.

TCP hoạt động tốt và tôi có khung máy chủ và máy khách MMO có thể mở rộng nhưng tôi không cần truyền nhiều dữ liệu từng khung hoặc nhiều gói nhỏ vì tôi có thể thực hiện các cuộc gọi của mình.

đối với những người khác: TCP sẽ không làm và họ chỉ có thể sử dụng UDP nhưng phải chấp nhận rằng họ sẽ không đảm bảo cho họ về những gì họ nhận được (đảm bảo đặt hàng / đến).

Những ý kiến ​​khác

Nhiều công cụ trò chơi được mã hóa kém xử lý mọi thứ trên luồng chính trên cpu, vì vậy cpu thường chỉ dành một lượng thời gian rất nhỏ để xử lý mã mạng, việc triển khai tốt cả phục vụ và máy khách sẽ hoàn toàn không đồng bộ và có thể đẩy và kéo tin nhắn theo đợt.

Có một số thư viện mạng tốt ngoài kia nhưng như đã thấy ở đây, nhiều người dường như có ý kiến ​​rằng UDP "tốt hơn", yếu tố chính trong nhu cầu của bạn trước tiên và đó có thể không phải là trường hợp đó, và tìm một thư viện không yếu tố trong cách bạn làm có thể dẫn đến thiết lập TCP được mã hóa kém so với biến thể UDP trong cùng một lib (tôi chỉ nói rằng tôi đã thấy điều này và các thử nghiệm tải đã chứng minh điều đó).

Xây dựng một cái gì đó trước tiên là một cơ sở kỹ thuật của dữ liệu bạn muốn gửi và kiểm tra nó sau đó thực hiện phép toán để mở rộng nó, trường hợp tải nặng nhất kiểm tra nó bằng cách triển khai lên một đám mây và có 50 máy tính chạy máy khách thử nghiệm để xem liệu nó có thể xử lý không giới hạn của bạn là 32 người chơi mỗi trò chơi (hoặc bất kỳ giới hạn nào bạn có thể có).


2

Tôi không nghĩ vậy ... Các trò chơi mà việc truyền dữ liệu rất thường xuyên (khi di chuyển chuột hoặc phím xuống), nên sử dụng UDP. Nó sẽ bị trễ ngay cả trên mạng LAN nếu TCP được sử dụng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.