웹소켓(WebSocket) 관련 정보

발생일: 2013.05.28

문제:
웹소켓으로 채팅을 구현하는 것과 관련해 정리해뒀던 메모


해결책:

예전에 구글 톡은 어떻게 사용하고 있었나?

     https://developers.google.com/talk/

     XMPP 프로토콜을 사용하고 있었는데, 이번에 행아웃으로 통합하면서 XMPP를 제공하지 않음.

구글톡이나 행아웃은 websocket을 쓰고 있나?

     https://plus.google.com/104401121686781166984/posts/Wc4vKDmmqEZ

     구글 챗에서는 쓰고 있지 않다. 대신, 채널이란 개념을 쓰고 있다. 

WebSocket

     http://www.websocket.org/quantum.html

     여기에 오버뷰가 잘 정리되어 있다.

     이전에는 폴링, 롱폴링, 스트리밍이 있었다.

     - 폴링:

          클라이언트에서 정기적으로 서버에서 요청해서 가져온다.

          메시지가 갱신되는 기간을 알 수 있는 경우엔 적합하지만, 채팅처럼 임의로 생성된다면 대기 시간이 발생한다.

     - 롱폴링:

          클라이언트가 요청을 보내고, 서버에서는 요청을 보관하고 있다가 메시지가 발생하면 바로 응답한다.

          일정 시간동안 메시지가 발생하지 않으면, 응답을 보내고 다시 요청받는다.

          메시지가 바로 응답이 오는 경우 반복해서 룹이 발생할 수 있고, 메시지가 큰 경우 폴링에 비해 큰 성능 향상을 기대하기 어렵다.

     - 스트리밍:

          응답에는 기본적으로 버퍼를 사용하기 때문에, 메시지가 바로 전달되지 않는다.

          버퍼 프록시를 사용하지 않도록 설정해야 한다.

     먼저 핸드쉐이킹으로 접속을 시도한다.

     아래 헤더를 포함해서 요청을 보내고, 응답에도 같은 헤더가 포함된다.

          Upgarde: WebSocket

          Connection: Upgrade

     (트렐로의 것을 보니, 시큐리티 목적을 위한 값을 전달한다.)

     텍스트와 바이너리 모두 양방향으로 통신할 수 있으며,

     텍스트의 경우 시작 바이트가 0x00 끝 바이트가 0xFF 로 끝나며, UTF-8 데이터를 포함할 수 있다.

     텍스트는 종료 문자(0xFF)를 사용하며, 바이너리는 length 속성을 이용한다.

     노트: 자바스크립트는 바이트 타입을 지원하지 않기 때문에, 

          

     웹소켓은 최초 접속을 제외하고는 헤더 정보를 보내지 않기 때문에, 네트워크 비용 측면에서 훨씬 이득이다.

     또한, 양방향 통신을 하기 때문에 빠르게 구현할 수 있다.

 

WebSocket에서는 바이너리를 전송할 수 없다?

     http://msdn.microsoft.com/ko-kr/library/ie/hh673567(v=vs.85).aspx

     MSDN API에서는 바이너리를 전송할 수 있다고 하는데…?

     JavaScript에 TypeArray에 추가돼서 가능하다.

카징 웹소켓 게이트웨이

     http://blog.daum.net/himond/159

          서비스 구조에 대한 한글 설명

     

     http://www.zdnet.co.kr/news/news_view.asp?artice_id=20120222100805 

          카징 서비스에 대한 zdnet 기사

     http://community.igniterealtime.org/thread/46521

          비용이 비싸서 바꿨다. (1mm/year) 

Building a streaming quote server using node.js and websockest

     http://weblog.plexobject.com/?p=1695

     노드 JS를 활용한 웹서버

 

Comparing server side web sockets using atmosphere, betty, nodejs and vertex.io

     http://weblog.plexobject.com/?p=1698

     각 서버별 차이점에 대해 잘 정리한 글

     글쓴이는 최종적으로, 자바 7 기반의 vertex.io를 선택했다. (확장성과 안정성이 뛰어나다는 판단)

     그렇지만, 노드 JS도 최종 경쟁자로 아주 나쁜 결과는 아니었다.

The Definitive Guide to HTML5 WebSocket Book 발췌본

     http://www.adobe.com/devnet/html5/articles/book-excerpt-the-definitive-guide-to-html5-websocket.html

웹소켓 보안에 대한 고려사항

http://tools.ietf.org/html/rfc6455#section-10

1. 브라우저가 아닌 클라이언트

     웹소켓 프로토콜은 동일 근원 정책 내에서 사용 가능하며, Origin 헤더로 이를 검증할 수 있다.

     하지만 브라우저가 아닌 클라이언트에서 Origin을 조작할 수 있기 때문에,

     서버는 Origin 헤더의 값이나 클라이언트에서 보내는 인풋을 신뢰하면 안된다.

2. Origin에 대한 고려

     서버는 Origin 헤더로 체크를 해야 하고, 올바르지 않을 경우 403 코드로 응답해야 한다.

     Origin 헤더는 브라우저가 아닌 클라이언트가 보내는 커넥션을 방어하기 위한 것이 아니라,

     신뢰할 만한 브라우저에서 악성 자바스크립트 코드의 공격을 방어하기 위한 의도로 설계한 것이다.

3. 네트워크 단의 공격(마스킹)

     프록시 같은 서버도 공격의 대상이 될 수 있다.

     (중간에 프록시 서버에 대한 이야기는 이해가 안되고…)

     클라이언트는 매 프레임마다 새로운 마스킹 키를 생성해야 하고, 키를 예측할 수 없어야 한다.

     또한, 클라이언트가 데이터를 전송할 때에, 애플리케이션 데이터를 취해 수정할 수 없도록 해야 한다.

     같은 값이라도, 매번 전송될 때마다 다른 값으로 마스킹되어 있어야 한다.