[tip] Socket.IO 의 이슈 공유

[tip] Socket.IO 의 이슈 공유합니다.

말이 길어지면 재미없고, 제가 글을 잘 쓰지 못하기 때문에 ㅋㅋ. point 마다 떨어뜨렸습니다.

• WebSocket에 부하 전혀 없다고 볼 수 있음.
  • 다수의 클라이언트를 접속시킨 후, 약 7일동안 서로 메세지 패킷 20000 바이트를 쉴세없이 주고받은 테스트를 한적이 있어요.
  • 저를 믿어주시고요 :)
  • 한번 Connection 되면 이는 영구적인 접속으로 변합니다.
  • packet 을 확인하세요.
  • 이후로는 패킷만 보내죠.
  • 패킷의 내용은 https://github.com/LearnBoost/socket.io-spec 이곳을 꼭 참조하세요.
• Socket.IO 입장에서 Client의 접속유지를 확인하는 방법
  • Heartbeat 입니다.
  • 하지만, 여러 메세지가 쉴세없이 오고갈때, 중간에 heartbeat 패킷 (2::)도 오고가는데, 이때 클라이언트가 heartbeat timeout 동안 2:: 패킷을 못쳐내면 해당 클라이언트를 끊어버립니다.
  • 2:: 페킷은 별도로 클라이언트에게 보내는 것이 아닌 message queue 에 의해서 순서대로 보내지고 받습니다.
  • 이런 현상이 왜 이러나냐면
  • 네트워크 데이타 처리는 수신되는대로 처리되는데,
  • 단일쓰레드에서 패킷을 보내고
  • 단일쓰레드에서 패킷을 처리하기 때문입니다.
  • netstat 으로 dump 떠서 겨우 찾아냈었죠. 이유도 없이 몇몇 클라이언트가 떨어져 나가는 ;;

Socket.IO 서버스케일링

• 굉장히 중요한 문제입니다.
• Socket.IO 는 내부적으로 해쉬오브젝트를 사용하여 사용자와 Room, Namespace 관리를 합니다. 이외 여러가지가 있구요.
• 접속자가 늘어날 수록 1000명 붙였을시 top에서 100m 정도로 늘어나는 것을 확인할 수 있습니다.
• redis 사용
  • cluster module 이나 여러 프로세스를 띄우면 메세지 통신이 단절됩니다.
  • ;; 클라이언트 소켓을 하나의 socket.io 프로세스가 잡고 있기때문이죠.
  • 이는 어쩔 수 없는 문제이기 때문에, client id 와 메세지를 만들어 redis 에 pub 하고
  • 각각의 socket.io 에 붙어있는 프로세스가 socket.id 를 관리하여, 해당 메세지가 sub 될 수 있도록 체크하면 됩니다.
  • 큰 서비스를 할 경우에는 이것은 필수입니다.
  • 예전부터 redis 기반한 pub/sub channel을 지원하고 있는데요, 아직 문서화가 안되어 있어요. 이거 왜 안해주는지 궁금하더군요.
  • 그래서 제가 할려고요. 기다려주세요.

자 모든 정보는 공유할것을 약속합니다.

KIN 플~