소켓 아이고 😇 (Feat. socket.io는 파싱을 해)

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

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

#socket.io #host_파싱 #default_path

시그널링 서버만 안 되는 이야기 🎧

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

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

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

이게 무슨 URL이야 🎶

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

그건 아마 내 잘못은 아닐거야 🎼 (호스트 파싱한 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 요청은 동작하고, 시그널링 서버는 동작하지 않았던 이유를 표로 정리해봤다.

-	WAS	wrong 시그널링	correct 시그널링
URL	https://was.tarotmilkteam.com	https://was.tarotmilktea.com/signal	https://was.tarotmilktea.com
option 설정	x	x	{ path: "/signal" }
path 결과	/socket.io	/socket.io	/path
실제 URL	wss://was.tarotmilktea.com/socket.io	wss://was.tarotmilktea.com/socket.io	wss://was.tarotmilktea.com/signal

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

---

Authored by @kimyu0218