예전에는 전화 접속 / ISDN / 느린 광대역을 통한 TCP 연결로 인해 단일 드롭 패킷이 재 동기화 되었기 때문에 게임이 고르지 않고 지연되었습니다. 이는 많은 게임 개발자들이 UDP 위에 자체 신뢰성 계층을 구현해야하거나, 삭제되거나 순서가 잘못된 메시지에 대해 UDP를 사용하고 신뢰할 수있는 정보를 위해 병렬 TCP 연결을 사용했음을 의미했습니다.
일반 사용자의 네트워크 연결 속도가 더 빨라지면 FPS와 같은 실시간 게임이 TCP 연결보다 우수한 성능을 제공 할 수 있습니까?
답변:
나는 아니오라고 말할 것입니다. 게임 오브젝트의 공간 정보는 가능한 한 빨라야하며, 신뢰성이 100 % 중요하지 않기 때문에 UDP를 사용하는 것이 좋습니다. 최신 연결에서도 UDP는 여전히 느리므로 보간 등에 대해 특별히 고려해야 할 사항이 있습니다. 전송되는 데이터의 양에 있어서도 TCP는 이것에 상당한 오버 헤드를 추가합니다.
그러나 TCP는 멀티 플레이어 협상, 채팅 메시지, 점수 업데이트 등과 같은 비 실시간 항목에는 완벽하게 허용됩니다.
Flash는 UDP를 지원하지 않기 때문에 멀티 플레이어 Flash 게임을 살펴보면 TCP / IP로 무엇이 가능하고 무엇이 불가능한지 잘 알 수 있습니다. 기본적으로 매우 빠른 응답 시간에 의존하지 않는 한 실시간 게임을 만들 수 있습니다. 몇 가지 예 :
http://www.xgenstudios.com/play/stickarena
UDP를 사용할 수있는 옵션이 있다면 실제로해야하지만 Flash에서는 슬프게도이 옵션을 얻지 못합니다.
따라 다릅니다.
World of Warcraft와 같은 게임은 통신을 위해 TCP를 사용합니다. TCP를 사용하면 많은 문제를 피할 수 있기 때문입니다. 결과적으로 핑이 더 높을 수 있지만 많은 게임의 경우 이는 허용됩니다. UDP를 프로토콜로 사용하는 경우에도 공간 보간을 수행해야합니다.
클라이언트 / 서버 아키텍처가 깨끗하면 전송 계층 (거의)은 중요하지 않습니다.
TCP에는 몇 가지 단점이 있지만 쉽게 구할 수 있습니다.
그렇습니다. TCP와 두뇌 만 있으면됩니다.
오늘날 일반적인 네트워크 설정 (프록시, 방화벽 등)으로 UDP는 로컬 (읽기 : LAN) 게임을 제외하고는 거의 쓸모가 없습니다.
Nagle 알고리즘을 끈 경우 UDP 대신 TCP를 사용하는 것이 좋습니다 .
Nagle을 끄면 UDP 속도가 가장 빠르며 트 위치 반응 게임을 완벽하게 만들 수 있습니다 . 실제로, 나는 플래시에서 TCP를 사용하여 그러한 게임을 만들었습니다.
http://2dspacemmo.wildbunny.co.uk
희망이 도움이됩니다!
게임의 종류에 따라 다릅니다.
RTS와 같은 일부 게임은 TCP보다 훨씬 더 잘 플레이하며 일반적으로 항상 TCP를 사용합니다.
TCP의 실제 문제는 소량이라도 패킷 손실이 발생하면 재전송이 발생할 때까지 연결이 "중지"된다는 것입니다. OS는 비 순차적 데이터를 애플리케이션에 전달할 수 없습니다 (이로 인해 TCP가 보장되지는 않지만 TCP는 애플리케이션 프레임 경계를 표시하지 않습니다). 연결 중단은 늦은 데이터가 나중에 도착한다는 것을 의미합니다. 그러나 (예를 들어) FPS 게임에서 오래된 데이터는 쓸모가 없습니다.
UDP를 사용하면 응용 프로그램에서 지연되거나 잘못된 데이터로 수행 할 작업을 선택할 수 있습니다. FPS와 같은 게임의 경우 오래된 데이터를 무시하고 최신 데이터를 가져올 수 있습니다. 때때로 손실 된 패킷은 후속 패킷을 전혀 지연시키지 않습니다. 지연된 패킷이 도착하면 게임에서이를 무시할 수 있습니다.
당신이 실제로 직면 할 필요가없는 UDP와 관련된 많은 문제들과 싸워야 할 수도 있기 때문에 "그렇거나 말도 안된다"라는 대답을 여기에 받아들이지 마십시오.
여기에 다른 답변은 이것을 증명하는 확실한 방법이 없습니다.
몇 가지 간단한 사실을
따라서 1 바이트 아래로 메시지를 보낼 때마다 IP 헤더가 필요하다고 가정하면 실제로 프로토콜에 따라 25 또는 41 바이트를 보냈습니다.
출처 :
내 조언
클라이언트 서버 상호 작용이 필요한 상황을 파악하고 클라이언트 수를 추정 한 다음 실제로 2 사이에 보내는 데이터를 기반으로 수학을 수행하십시오.
예
내 게임에서 업데이트 당 1 바이트 인 10 개의 메시지를 보내고 약 60fps로 업데이트 중이므로 초당 실제 메시지 데이터 + 관련 헤더 + 60 * 10 = 600 바이트를 보내야한다고 가정 해 보겠습니다.
이제 게임에 따라 모든 것을 단일 메시지로 보낼 수 있으므로 TCP 레이어에서 내 오버 헤드는 40 바이트 (실제로 초당 20 바이트의 UDP 이상의 비용)이며 오버 헤드가없는 것은 600 바이트의 잠재적 비용입니다 ( 전체 메시지 스트림을 다시 보내야 할 수도 있습니다).
그러나 모든 메시지를 보낼 준비가 된 순간에 자체적으로 보내는 것이 매우 중요한 경우 600 메시지 (또한 600 바이트) + 40 * 600 = 24k의 TCP 오버 헤드 또는 초당 ~ 14k의 UDP 오버 헤드가 있습니다. 600 바이트의 메시지 데이터
다시 한 번 질문을하고, 그 메시지가 얼마나 중요한지, 얼마나 자주 메시지를 보내고, 오버 헤드를 줄이기 위해 어떤 방식으로 배치 할 수 있습니까?
그것은 단일 바이트 메시지 묶음을 기반으로합니다. 일반적으로 매우 다른 작업을 수행하지만 TCP가 UDP보다 상황에 더 잘 맞는지 원시 데이터가 전송되는 것을 알지 못합니다.
그래서 작동합니까?
글쎄, 당신이 전형적인 fps를 가지고 있고 (속임수 또는 부정확 한 결정을 피하기 위해) 위치가 중요하다면, 당신의 네트워크 스트림이 실현 가능하다는 것을 알아야합니다. s + messages) ... 서버를 통해 각 클라이언트에서 다른 모든 클라이언트로 프레임 당 최소 1 개의 메시지를 전송하는 것을 기반으로 개별 헤더에 대한 약 10mb / s 광대역 회선입니다.
분명히 서버와 클라이언트가 그렇게 작동하도록 코딩하지 않으며 메시지 크기는 대부분의 상황에서 프레임 당 1 바이트보다 훨씬 크고 아마도 덜 빈번 할 수 있으므로 실제 세계를 보지 않고는 말하기가 어렵습니다. "이것은 내가 보내야 할 데이터"예입니다.
내 경우
필자의 경우 합리적인 오버 헤드가 필요하지만 메시지 스트림을 작성하는 방법을 기반으로하므로 일부 디자인과 비교하여 큰 오버 헤드가 없습니다.
TCP는 잘 작동하고 확장 가능한 MMO 서버 및 클라이언트 프레임 워크가 있지만 호출을 일괄 처리 할 수 있기 때문에 많은 데이터를 프레임이나 작은 패킷으로 스트리밍 할 필요가 없습니다.
다른 사람들을 위해 : TCP는하지 않으며 UDP 만 사용할 수 있지만 그들이 얻는 것에 대해 보증하지는 않는다는 것을 수용해야합니다 (주문 / 도착 보증).
다른 고려 사항
잘못 코딩 된 많은 게임 엔진은 CPU의 메인 스레드에서 모든 것을 처리하므로 CPU는 종종 네트워킹 코드를 처리하는 데 아주 적은 시간이 주어집니다. 메시지를 일괄 적으로 가져옵니다.
좋은 네트워킹 라이브러리가 있지만 여기에서 볼 수 있듯이 많은 사람들이 UDP가 "더 좋을 것"이라는 의견을 갖고있는 것 같습니다. 자신의 필요를 먼저 고려하고 그렇지 않을 수도 있습니다. 그렇지 않은 라이브러리를 찾으십시오. 동일한 lib의 UDP 변형과 비교할 때 제대로 코딩되지 않은 TCP 설정이 발생할 수 있습니다 (이것을 보았으며로드 테스트에서 입증했습니다).
먼저 보내려는 데이터의 기술 기반을 구축하고 테스트하여 데이터를 확장하고, 최악의 경우 클라우드에 배포하여로드 테스트하고, 50 대의 컴퓨터가 테스트 클라이언트를 실행하여 처리 할 수 있는지 확인하십시오. 게임당 32 명의 플레이어 제한