네트워크 비용이 말도 안되게 비싸던 시절 만들어진 규약이 그렇다.
그 넷 비용을 획기적으로 낮추는 것이 웹이 활성화되는 결정적인 역할 중 하나다.
Http에서는 뭔가 할 수 있는 것이 없었으나
2000년 초반 XmlHttpRequest라는 것이 ActiveX 형식으로 IE에서 지원되면서
Dynamic HTML에서 통신요소가 깔끔하게 정리되어 정말 유용했었다.
그런데 브라우저들은 보안에 매우 취약하여 웬만한 자원접근은 막아두었다.
심지어 프린터까지...
부정적 활용에 대해 제약을 걸었으나 제약은 제약인지라
모든 긍정적 쓰임도 차단된다.
Http가 tcp/ip에 기반한 Socket 위에서 구현된 규약이라 없으나
보안이란 명목으로 접속중이라도 서버와 클라이언트가 대화하기 곤란하다.
XMLHttpRequest는 HttpClient의 일종이다.
그래서 웹소켓websocket이 대두 되었으나 여러모로 아랫단 소켓과 자잘한 문제들이
다시 대두되는 번거로움이 있다.
짧은 데이터야 ajax든 iframe으로 돌아도 문제될 것이 없다.
그러나 긴..형태의 데이터라면..
그런데 생각해보면 매우 간단한 방법이 있다.
1. Ajax api에 대화만 허용하면 된다.
즉 여러번 메시지를 주고받으면 된다는 것이다.
다른 보안 제약은 그대로 유지해도 좋다.(파일시스템접근제약 등...)
2. response를 streaming해주면 된다.
현재는 responseText는 streaming가 아니다. 물론 ResponseXML도 streaming일 수 없다.
오로지 한꺼번에 다 읽어야 한다.
둘다 socket에 있는 기능이다.
이 두가지면 번거롭게 websocket운운하지 않아도 간단히 해결된다.
서버측에는 엄청난 라이브러리들이 있어서 streaming 기반 통신 API가 널렸다.
HttpClient류에서는 InputStream OutputStream을 바로 참조할 수 있다.
그러나 클라이언트측(브라우저들)에는 너무 심한 제약으로 구현의 제약 뿐만 아니라
streaming으로 처리해야하는 다양한 데이터처리에 bottle neck역할만 한다.
Http는 한번 보내고 한번 받는 것이 기본룰이라 될 수가 없다.
그래서 그 복잡한 websocket이야기가 나오는 것인지..
그렇게되면 Http에서 처리하는 것들(도메인,계정,쿠키,보안..기타등등...)
그렇다면, 왜 이름이 웹소켓이면서 http서버로 바로 접속하면 안되는지..
이또한 http서버들의 구현문제
이문제는 protocol... 규약이 제약.
socket하나 얻자고 클라이언트에 java applet 환경을 강요하는 것은 말도 안된다.
(자바가 브라우저에서 실패한 요소 중 하나이다.)
flash는 상대적으로 가볍다고 해도, 모바일이 대세인시대에
flash도 java와 동일한 문제가 발생한다.
오로지 브라우저에서 지원해야 한다.
WebSocket은 정말 궁여지책으로 나온 것이다.
client 브라우저들은 거짐 준비가 된 것 같다.
다만 서버사이드가 표준이라하기엔 다양한 구현이 나와버렸다.
http://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations
개인적인 생각이지만 위의 두가지 기능만 제공된다면
어떤 작업이 안되는지 궁금할 정도다.
만일 별개의 서버로 간다면..
jWebSocket 이 보여주듯, 수많은 중복구현이 불가피할 것이다.
HTTP2.0도 나올때가 되지 않았나?
window8 의 경우 StreamWebsocket 이란 걸 제공한다는데..
cross browsing-html5 의 이야기를 하는데
오로지 자기지향으로 달리는 것 같아 답답하다..
어쨌던 당장 XMLHTTPRequest에서 stream을 읽을 수 있다면
복잡한 것이 없다.
도중에 통신을 끊지 않고, 메시지를 보낼 수 있다면 더할 나위 없다.
통신되는데, 뭐가 문제야.. 데이터는 문제없다.
------------
문제가 되는 지점은 chatting 형..... 즉 다자간 동기대화형 application이다.
구지 socket이어야 하는 이유지... 주된 영역이 아니라 할말이 없다.
여튼 5개 브라우저와 톰캣으로 간단한 chatting 예제를 돌려보았으나..
Safari는 되지도 않았고(tomcat7과 safari는 맞지 않단다. nio와 맞지 않는다는데..)
같은 IP라서 그런지.. 브라우저에 상관없이
커넥션을 몇개를 생성하건 한놈만 응답을 받는다.
subprotocol 관련된 것인지.. 싶기도 하고.
server에서 IP단위로만 구분하는지..... 참 어렵다.
추가적인 다른 작업이 필요한건지...
서버사이드도 짧지 않은 이야기가 진행중이다.
올해(2013)에 모두 선보이게 될 것 같은데
annotation 기반 POJO Bean 경향으로 다가오게 될 것 같다.
지금 당장 어찌해야 한다면, atmosphere를 이용해야 할 듯.
atmosphere..... 이건 또 오로지 maven이군.
2013-01-31.
-------
atmosphere 로 간단한 채팅예제를 해 보았다.
Window7에서 safari를 제외한 Chrome,IE10,Opera,FireFox는 잘 되었다.
safari만의 문제가 아니라 mac의 전체가 아직 websocket을 지원하지 않는다.
예를 들어 vmware에 osx를 설치후 chrome으로 접속해도 마찬가지고
아이패드3에서 safari,chrome 접속도 마찬가지.
톰캣용 예제의 문제점은 없었다.
다만 문자열에 " "로 감싸져서 왔다. 왜 그런지는 모르겠다.
Websocket 2013년 어느 시점부터 java WAS들에 모두 장착되어 배포될 것으로 보이는데
양방향(full-duplex) 통신이다보니 활용영역이 ajax와는 비교할 수 없을 정도로
다양할 것이다.
용도에 따른 적절한 패턴으로 활용되어야 할 것이다.
2013-02-03
--------
HTTP2.0이 2014년에 표준이 개발될 것이라고 한다.
Google의 SPDY가 수용될 것이라고 한다.
spdy는 밑단에서 브라우저와 웹서버만 되는 것인지..
websocket와 같은 클라이언트의 쉬운 api는 없다.. 있을 것 같은데..
Websocket 은 java was가 지원하더라도
웹서버는 그런 기능이 마련되지 않아서 proxy를 세워 해결한다고 하는데...
kaazing 상용으로 잘 나가는 듯 하다.
2013-02-06
----------------------
댓글 없음:
댓글 쓰기