iOS 게임용 서버를 작성 중입니다. 게임은 턴 기반이며 서버가 정보를 클라이언트에 푸시해야하는 유일한 시간은 상대방의 움직임을 알리는 것입니다.
누구든지 웹 소켓 사용과 긴 폴링 간의 성능 및 구현 용이성에 대해 언급 할 수 있는지 궁금합니다. 또한 웹 소켓을 사용한 경우 정보를 수신하고 다른 모든 것에 대한 POST 요청을 보내는 데만 사용해야합니까, 아니면 모든 통신이 웹 소켓을 통해 이루어져야합니까?
또한 웹 클라이언트를 만드는 데 관심이 있다면 웹 소켓과 긴 폴링 사이에 고려할 추가 사항이 있습니까?
답변
롱 폴링이란 무엇입니까?
기존 폴링 기술의 변형이며 서버에서 클라이언트로 푸시되는 정보를 에뮬레이션 할 수 있습니다. 긴 폴링을 사용하면 클라이언트는 일반 폴링과 유사한 방식으로 서버에서 정보를 요청합니다.
- 서버에 클라이언트에 사용할 수있는 정보가없는 경우 빈 응답을 보내는 대신 서버는 요청을 보류하고 일부 정보를 사용할 수있을 때까지 기다립니다.
-
정보를 사용할 수있게되면 (또는 적절한 시간 초과 후) 완전한 응답이 클라이언트로 전송됩니다. 그런 다음 클라이언트는 일반적으로 서버로부터 정보를 즉시 다시 요청하므로 서버는 거의 항상 이벤트에 대한 응답으로 데이터를 전달하는 데 사용할 수있는 사용 가능한 대기 요청을 갖게됩니다.
웹 / AJAX 컨텍스트에서 긴 폴링은 Comet 프로그래밍 이라고도 합니다.
Websocket은 어떻습니까?
WebSocket은 클라이언트와 서버간에 영구적 인 연결을 제공하여 양 당사자가 언제든지 데이터 전송을 시작할 수 있습니다.
- 클라이언트는 WebSocket 핸드 셰이크라는 프로세스를 통해 WebSocket 연결을 설정합니다. 이 프로세스는 클라이언트가 서버에 일반 HTTP 요청을 보내는 것으로 시작됩니다.
- 클라이언트가 WebSocket 연결을 설정하고자 함을 서버에 알리는 Upgrade 헤더가이 요청에 포함됩니다.
결론 :
실시간 통신이 필요한 경우 웹 소켓을 선택할 수 있습니다.
그러나 긴 폴링에서는 :
웹 클라이언트와 웹 서버 사이에 연결이 열려 있으므로 서버에 새 정보가있을 때이를 클라이언트로 푸시 할 수 있습니다. 그러면 해당 요청이 완료됩니다. 그런 다음 클라이언트와 서버간에 새 요청이 작성되고 서버에서 다른 업데이트를 기다립니다. 동일한 TCP 연결은 일반적으로 HTTP / 1.1 연결 유지로 인해 여러 요청에서 지속적으로 열립니다.
참조 및 기타 고려 사항 :
Long-Polling, Websockets, SSE (Server-Sent Events) 및 Comet은 무엇입니까?
