Websocket Java spec에 대한 단상

WebSocket 프로토콜은 하나의 tcp (실제로는 http 확장 형태) 소켓으로 여러 개의 논리적 연결인 세션 개념을 지원한다.

그런데 tcp 레벨에서 같은 연결을 사용하기 때문에 논리 세션은 각 특성에 따라 효율적이기 어렵다. 적당한 크기의 프레임이란 메시지 단위로 잘라서 여러 세션 메시지를 섞어 보내다보니 원래는 하나의 양방향 큐를 구성하는 tcp 연결을 다시 에뮬레이트해야해서 오버헤드가 있다.

자바 웹소켓 스펙을 보면 메시지 유형이 스트림이면 큰 메시지라고 간주하여 매 프레임별로 별도의 쓰레드로 보내고 그렇지 않으면 하나의 쓰레드로 보내게 되어있는데 나는 이 스펙은 지나친 쓰레드 모델과 메시지 유형의 커플링이라고 본다.

오히려 큰 파일일수록 순서대로 하나의 쓰레드에 큐로 보내고 작은 프레임들이면 알아서 처리하라고 worker로 보내거나 했어야 정상적인 (효율적인) 처리 구조일 것 같고 아니면 그냥 열어뒀어야 할것 같은데 Java EE 스펙에서 과도한 개입을 해서 망친 듯.

그런데 websocket과 같이 여러 개의 논리 연결을 위해 하나의 물리 연결을 사용하는 것 자체가 효율적인 발상은 아니다. tcp의내부 최적화를 깨는 형태가 되는 셈이니...

그저 브라우저가 http 연결하면서 서버로부터  push 메시지 받는 용도로만 제한적으로 쓸 일이지...

생각해보니 일전에 본 용례는 http로 passive connection을 못 만들어서 이런 복잡한 websocket을 쓰려고 하고 있었다 ㅠㅠ

tcp로 하는 것과 다른 게 없을텐데 ㅠㅠ