nginx 프록시 소켓.io 서비스의 함정을 해결하는 방법

nginx는 두 개의 소켓.io 서버에 대한 프록시 역할을 합니다. Socket.io의 작업 모드는 폴링 및 websocket으로 업그레이드 중입니다

Phenomenon

nginx를 통해 서비스를 요청하면 400 오류가 대량으로 나타나는 경우도 있습니다. 때로는 websocket으로 업그레이드할 수도 있고, 계속 오류를 보고하는 경우도 있습니다. 하지만 ip+端口를 통해 직접 접속하면 100% 성공합니다.

Analytics

sid

sid가 우리 문제의 핵심입니다. 처음 연결을 생성할 때(폴링 모드는 긴 연결을 시뮬레이션함) 클라이언트는 다음과 같은 요청을 시작합니다.

https://***/?eio=3&transport=polling&t=1540820717277-0

서버에서 수신 An 개체가 생성되어 연결에 바인딩되며 세션을 표시하기 위해 sid(세션 ID)가 반환됩니다. 세션은 무엇을 의미합니까? 세션은 일련의 상호 작용이며 이러한 상호 작용은 서로 관련되어 있습니다. 우리 시나리오에서는 다음 http 요청이 오면 이전에 이론에 바인딩된 긴 연결을 찾아야 합니다(아직 여기에 없음). 이론적으로는 websocket입니다). 우리는 http 요청이 상태 비저장(stateless)이고 각 요청이 독립적이라는 것을 알고 있습니다. 그래서 소켓.io는 이를 위해 sid를 도입했습니다. 요청을 받은 후 서버는 sid를 생성합니다. 응답을 살펴보세요.

코드 복사 코드는 다음과 같습니다:

{"sid":"eogal3frqlptoalp5est","upgrades":["websocket"], "pinginterval":8000," pingtimeout":10000}

모든 후속 요청은 이 SID를 가져와야 하며 웹소켓 요청에 대한 연결 설정도 예외는 아닙니다. 따라서 sid는 폴링을 웹소켓으로 업그레이드하고 폴링하는 데 핵심이 됩니다. 이후의 요청은

https://***/?eio=3&transport=polling&t=1540820717314-1&sid=eogal3frqlptoalp5est

or

wss://***/?eio=3&transport=websocket&t=1540820717314-1&sid=eogal3frqlptoalp5est

와 유사합니다. 그러면 질문은 요청의 sid가 서버에서 생성되지 않으면 어떻게 됩니까? 서버는 이를 인식하지 못하고 400을 반환하고

invalid sid

라고 알려줍니다. 이것이 우리가 직면한 문제입니다. nginx의 기본 로드 밸런싱 전략은 폴링이므로 요청이 SID를 생성하지 않은 시스템에 도달할 수 있습니다. 올라가면 이때 400을 받게 됩니다. 운이 좋으면 웹소켓 연결이 설정될 때까지 지속될 수도 있습니다.

솔루션

다음에 두 가지 솔루션이 제안됩니다

1. nginx의 로드 밸런싱은 ip_hash를 사용하여 모든 클라이언트 요청이 하나의 서버로 이동하도록 보장합니다.

2. 폴링 모드를 사용하지 말고 websocket만 사용하세요

두 옵션 모두 장단점이 있습니다. 두 번째로 확실한 점은 웹소켓을 지원하지 않는 오래된 브라우저와 클라이언트는 작동하지 않는다는 것입니다. 첫 번째 유형의 문제는 더 깊이 숨겨져 있습니다. 이때, ip_hash 정책의 모드가 변경되고, 마이크로서비스의 경우 확장 및 축소가 매우 불가능해집니다. 빈번한 작업(특히 제품이 개발 단계에 있는 경우)에서 이러한 종류의 손실이 있는 팽창 및 수축은 용납될 수 없습니다.

위 내용은 nginx 프록시 소켓.io 서비스의 함정을 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!