소켓 통신에서 path가 사라진다고?!

FE를 향한 배려가 삽질의 구렁텅이로 빠진 건에 대하여,,,

#socket.io #host_파싱 #default_path

P2P 통신을 위한 시그널링 서버를 구축하는 과정에서 웹소켓 요청이 시그널링 서버로 전달되지 않는 문제가 발생했다.

아이너리 한 것은 WAS와 시그널링 서버 모두 웹소켓을 사용하고 있는데 오직 시그널링 서버로의 소켓 요청만 동작하지 않았다. 😇

결론부터 말하자면 이는 상대적으로 업무가 많은 FE분들의 라우팅 부담을 덜어고자 하는 노력에서 시작되었다. nginx의 경로 기반 라우팅으로 URL의 마지막에 /signal을 붙이면 시그널링 서버로 전달해주겠다고 했는데, 경로를 붙이면서 소켓 요청을 이상한 곳으로 보내게 되었다. (우주먼지가 되어버린 소켓 요청)

개발자 도구를 열면 상상도 못한 URL이 있다. io는 서버와 통신하기 위해 사용하는 객체인데, /signal이라는 path가 사라지고 /socket.io가 그 자리를 대체한 것을 볼 수 있다.

io 객체는 파라미터로 URL을 전달할 수 있는데, 놀랍게도 socket.io가 파라미터로 넣어준 URL을 자동으로 파싱하여 호스트 주소만 남겨버린다 😇 즉, 라우팅을 위해 붙여준 /signal이 사라진 상태로 웹소켓 연결을 시도한다.

그렇다면 내가 붙여준 적도 없는 /socket.io는 뭘까? 바로 socket.io의 기본 path다. io의 파라미터에는 url도 있지만 옵션도 파라미터로 넘길 수 있다.

호스트만 남은 URL에 path를 붙여주기 위해서는 바로 옵션을 활용해야 한다. 다음과 같이 path를 작성하면 /socket.io 대신 /signal이 붙어서 간다.

io("https://was.tarotmilktea.com", { path: "/signal" });

위와 같이 클라이언트, 서버 측 path 처리를 해주면 소켓이 연결된다.

WAS 요청은 동작하고, 시그널링 서버는 동작하지 않았던 이유를 표로 정리해봤다.

아래 그림은 이해를 돕고자 만들어본 io 요청 동작 과정이다.

Authored by @kimyu0218