.
안녕하세요 개발자 Chullin입니다.
오늘의 주제는 HTML5의 꽃이자 이 시대 웹의 횃불, 웹소켓입니다.
.
.
예상 독자[웹소켓 모르는, HTTP 모르는, AJAX 모르는 분]
- 액티브엑스를 쓰는 것이 구린 이유를 논리적으로 제시하고 싶으신 분.
- 비웹개발자로서 웹의 30년 발전사(HTTP => AJAX => Web Socket)에 대한 정보를 15분 정도 들여서 알고 싶으신 분.
.
예상하지 않은 독자[웹소켓 아는, HTTP 아는, AJAX 아는 분]
- HTTP의 구체적인 전송 규약을 세밀하게 파악하고 싶은 분.
- Websocket의 구체적인 전송 규약을 세밀하게 파악하고 싶은 분.
- Websocket과 HTTP의 성능 차이를 파악하고 싶은 분.
아직 제 능력의 부족으로 위에 해당하는 분들의 니즈를 충족시킬 글을 쓰지 못했습니다. 오늘의 내용에 위에 언젠가 쌓을 수 있길 바랍니다.
.
.
글의 가독성을 높이기 위해, 글의 초두와 말미에 짧게 요약해보도록 하겠습니다.
.
.
TL; DR
- HTTP는 통신 제약이 있는 약속입니다.
- AJAX로 HTTP의 통신 제약으로부터 조금 벗어날 수 있었습니다.
- Websocket은 HTTP의 통신 제약을 해결한 새로운 약속입니다.
.
.
페라리의 속도감을 느껴보고 싶나요? 그러려면 걷기 먼저!
.
.
곁에 항상 있는 것은 없어져봐야 그 소중함을 알게됩니다. 웹소켓을 사용한 통신의 장점을 느껴보기 위해 웹소켓이 없었던 머나먼 30년 전으로 돌아가보도록 하겠습니다. 짠, 1989년.
1989년의 세계는 격동의 시기였죠. 아시아 대륙 중국에서는 6월에 텐안먼 사건이 일어나 중국인 수백명이 죽었고, 11월 유럽 대륙 독일은 통일을 일궈내 냉전의 장막이 차차 걷히고 있는 참이었습니다. 한편, 그 격동의 시기 와중에 유럽에서 영국 출신의 학자 한 분이 미래를 뒤흔들어버릴 기술을 발명해버립니다. 팀 버너스리의 HTTP 통신규약입니다.
HTTP는 약속입니다. 약속을 영어로 표현하면, 프로토콜이라고 합니다. 멋짐이라는 것이 폭발해버린, 텍스트 문서를, 교환하기 위하여 사용된, 약속. 즉 Hyper, Text, Transfer, Protocol 입니다.
HTTP의 앞 두 글자 Hyper Text. HTTP가 등장하기 이전 세대에서 통신한다 함은, 터미널 창에서 딱딱한 텍스트를 주고 받는 것이었어요. 그런데 HTTP가 등장하니, 시각적으로나 정보량 차원에서 엄청나게 멋진 문서를 주고 받을 수 있게 되었습니다.
HTTP의 뒤 두 글자 Transfer Protocol. HTTP의 대전제는 “URL 및 부가정보를 통해 사용자가 원하는 페이지를 서버에 요청한다, 그리고 서버는 해당 요청에 응답한다” 입니다.
예를 들어보겠습니다. 제가 과거에 썼던 포스트가 있는데, 이 주소는 링크와 같습니다. 이 링크를 누르면, 사용자가 사용하는 웹 브라우저(크롬, 웨일, 사파리, 파이어폭스, 인터넷 익스플로러 등등)가 HTTP 규약에 따라 미디엄 서버에 해당 URL에 해당하는 웹페이지를 요청합니다. 그러면, 서버가 해당 요청에 응답하며, 그 결과인 html 문서가 브라우저 창에 뿌려지는 식입니다.
그런데 HTTP의 뒤 두 글자 TP에는 무서운 대전제가 붙습니다. 사용자가 URL을 요청할 때에만! 서버에서 해당 페이지를 꺼내주는 식이라는 겁니다. 거꾸로 말하자면, 사용자는 서버로부터 새로운 정보를 받아보기 위해서, 반드시, 새로운 URL을 요청해야 한다는 말과 같습니다. 이 말이 얼마나 무섭냐 하면… 현재 이런 HTTP 규약 그대로 개발하는 웹개발자는 아마 월급을 못받을 수도 있을 거라서 그래요…
예를 들어보겠습니다. 공공기관 웹사이트의 회원가입 과정을 떠올려보세요.
즉, 브라우저가 웹서버에 무엇인가를 요청하려면, 페이지를 이동해야만 했습니다. 사실 그렇게 웹페이지를 이동하는 방식으로 만들어버리면 시각적으로 너무 뻣뻣하고 구렸기 때문에 많은 꼼수들이 등장합니다. 액티브엑스도 그 중 하나입니다.
하지만 전폭적 격변을 만들어내는 반골은 있는 법입니다. “이딴 더러운 꼼수 다 집어 치워! 우리는 더 멋진 디딤돌 위에서 새로운 세계를 만들어갈거야!”라고 말할 수 있는 너드 천재집단. 갓.구.글. 당시에 혜성처럼 등장하기 시작한 구글은 HTTP 규약을 뛰어넘는 방안을 제안합니다. 이름하여 AJAX입니다.
.
.
이제는 페라리를 타고 싶다구요? 아직 아닙니다!
.
.
소중함을 인식하는 최고의 방법은 그 역사를 이해하는 것입니다. 페라리의 진수를 느끼려면, 아장아장 걸어도 보고 마차도 타봐야지요. 걷기는 마쳤으니, 마차를 타봅시다. 그리고 나서 페라리를 타도 늦지 않습니다.
웹소켓의 탁월함을 체감하기 전, 구글의 AJAX를 알아보도록 하겠습니다. 이제 1989년에서 15년 정도 지나왔다고 생각하시면 됩니다. 2002년이야말로 AJAX가 구글이 개발한 웹을 타고서 태양처럼 솟아올랐기 때문입니다.
AJAX는 HTTP를 효과적으로 이용하는 기술입니다. 앞에서 HTTP는 약속이라고 말씀드렸지요? AJAX는 약속은 아닙니다. 효과적으로 서버와 소통하기 위한 기술이에요. 그림으로 비교해보도록 하겠습니다.
위는 앞에서 봤던 HTTP에 따른 나이브한 통신 방식입니다. 요청 페이지에서 확인을 누르면, 확인을 눌렀다는 정보를 서버에 전달합니다. 웹서버는 요청을 받고, 처리한 후에 HTML 페이지를 생성하고, 유저에게 해당 HTML페이지를 전송합니다. 이 방식을 선택한다면, HTML(즉 웹 페이지)을 하나 새롭게 브라우저에 뿌리게 되고, 결국 새로운 페이지로 이동하는 결과를 마주하게 됩니다.
아래는 이제 다뤄볼 AJAX 기술이 들어간, 진일보한 통신 방식입니다.
AJAX를 쓰면, 유저는 새로운 HTML을 서버로부터 받는 것이 아닙니다. 즉, 유저는 (유저가 정말 새로운 웹페이지로 이동하기를 원하는 것이 아닌 한)새로운 웹페이지로 이동하는 것이 아닙니다. 대신, 동일한 웹페이지 내에서 DOM을 변경하게 됩니다.
요청 페이지에서 이름 칸에 ‘촉새’를 쓰고, 내용에 ‘안녕하세요. 촉새입니다’라고 썼다고 해봅시다.
사용자의 이벤트로부터 Javascript는 해당 이름과 내용이 쓰여진 DOM을 읽습니다. 그리고는 XMLHttpRequest 객체를 통해 웹서버에 해당 이름과 내용을 전송합니다. 웹서버는 요청을 처리하고 XML, Text 혹은 JSON을 XMLHttpRequest 객체에 전송합니다. 그러면, Javascript가 해당 응답 정보를 DOM에 씁니다. 그렇게 결과페이지가 만들어집니다.
AJAX를 쓰면 새로운 HTML을 서버로부터 받아야 하는 것이 아닙니다. 동일한 페이지의 일부를 수정할 수도 있는 가능성이 생깁니다. 결과적으로 사용자 입장에서는 페이지 이동이 발생되지 않고 페이지 내부 변화만 일어나게 됩니다. HTML 페이지 전체를 다 바꿔야 하는 것이 아니라 부분만 바꿀 수 있게 되는 것입니다.
.
.
AJAX를 안썼을 때와 썼을 때를 비교하기 위한 3 가지 포인트.
.
.
[ 차이1 : 전체를 다 변경해야 하는가? vs 부분만 선별적으로 변경할 수 있는가?]
- 나이브 HTTP는 클라이언트쪽에서 Request를 보내고 Server쪽에서 Response를 받으면 이어졌던 연결이 끊기게 되어있습니다. 그래서 화면의 내용을 갱신하기 위해서는 다시 request를 하고 response를 하면서 페이지 전체를 갱신하게 됩니다.
- AJAX는 html 페이지 전체가 아닌 일부분만 갱신할수 있도록 XMLHttpRequest객체를 통해 서버에 request 합니다. XMLHttpRequest는 서버와의 연결을 잡아둡니다. Json이나 xml형태로 필요한 데이터만 주고 받으며 DOM을 갱신하기 때문에 그만큼의 자원과 시간을 아낄 수 있습니다.
.
[ 차이2 : 누가 서버에 유저의 니즈를 요청하는가?]
- 나이브한 HTTP는 웹브라우저가 서버에 요청합니다.
- AJAX는 XMLHttpRequest 객체가 서버에 요청합니다.
.
[차이3 : 페이지의 변경사항이 필요할때마다 페이지를 이동하는가?]
- 나이브한 HTTP는 항상 페이지를 이동합니다.
- AJAX는 조그마한 변경이 필요할 때, 해당 페이지 내에서 변경이 가능합니다.
.
앞서서 나이브한 HTTP로 회원가입했을 때 중복체크하는 과정과 비교해볼까요? AJAX를 쓴다면, 다음과 같은 방식으로 아이디 중복체크하는 것도 가능해집니다.
그 외에도 HTML5를 여행하는 비웹개발자를 위한 안내서 링크를 눌러보시면(그럼으로써 웹브라우저로 하여금 미디엄의 서버로부터 새로운 HTML페이지를 응답으로 받는다면), 더욱 많은 AJAX 사례들을 확인해보실 수 있습니다. 비밀번호 강도 확인, 검색어 실시간 추천, 마우스 커서나 스크롤바 위치에 반응하는 그림, 지도 표시 서비스 등등 다양합니다.
.
.
그러나 여전히 AJAX로 여전히 수행하지 못하는 것들이 있습니다.
.
.
왜냐하면, AJAX도 여전히 HTTP로 서버와 통신하기 때문입니다. 즉, AJAX도 HTTP의 한계를 완전히 벗어나지 못했습니다. HTTP는 “클라이언트의 요청이 있고 그 다음 서버로부터 응답을 받는 상황”인데, 이 틀로부터 벗어나지 못했습니다.
“클라이언트의 요청이 있고 그 다음 서버로부터 응답을 받는 상황”에서 벗어나는 예를 들어보겠습니다. “클라이언트의 요청이 없음에도, 서버로부터 응답을 받는 상황”을 들어보고자 합니다.
이러한 경우 외에도 웹 상에서는 갈수록 동적인 표현과 뛰어난 상호작용이 요구되었습니다. 이러한 문제에 대응하기 위해 Comet 이 등장했습니다. 하지만, 이 방법은 “클라이언트의 요청이 없음에도, 서버로부터 응답을 받는 상황”에 대한 미봉책[RFC6202]이었습니다. 즉, 데이터 수신을 위해 서버가 클라이언트에게 전송해 주는 푸시(push)방식이 아니라 여전히클라이언트가 서버에에게 요청하는 폴링(polling) 방식이었습니다.
이와 같은 애로사항은 HTML5 개발 과정에 녹아들었습니다. 결국, HTML5은 순수 웹 환경에서 실시간 양방향 통신이 가능해지게 만들어졌습니다. 그 스펙의 명칭이 바로 ‘웹 소켓(Web Socket)’ 입니다.
.
.
자, 여기 페라리입니다! 같이 웹소켓 한 번 타보자구요!
.
.
이제 동시대 즉 웹소켓의 시대로 넘어왔습니다. 2014년 10월 28일의 HTML5 버전이 나올 때 함께 등장했던 웹소켓은 2016년 11월 1일 HTML5.1 버전이 나오고 2017년 12월 14일 HTML5.2 버전이 나올 때까지 더더욱 발전했습니다.
웹소켓은 약속입니다. HTTP와 같이 약속입니다. 브라우저와 서버가 양방향 통신을 할 수 있도록 지원하는 프로토콜입니다.
웹소켓은 HTTP의 문제를 해결해주는 약속입니다. HTTP에서 원리적으로 해결할 수 없었던 문제는 “클라이언트의 요청이 없음에도, 그 다음 서버로부터 응답을 받는 상황”이었는데요. 웹소켓은 HTTP가 해결할 수 없었던 이 문제를 해결하는 새로운 약속이었습니다. 즉, 브라우저가 서버에 데이터를 요청하고 서버가 브라우저에 데이터를 보내기 위해 별다른 제약이 없습니다.
웹소켓에서는 서버와 브라우저 사이에 양방향 소통이 가능합니다. 브라우저는 서버가 직접 보내는 데이터를 받아들일 수 있고, 사용자가 다른 웹사이트로 이동하지 않아도 최신 데이터가 적용된 웹을 볼 수 있게 해줍니다. 웹페이지를 ‘새로고침’하거나 다른 주소로 이동할 때 덧붙인 부가 정보를 통해서만 새로운 데이터를 제공하는 웹서비스 환경의 빗장을 본질적으로 풀어준 셈입니다.
웹소켓 약속 하에서는 실시간 소통이 편안해지게 됩니다. 웹에서도 채팅이나 게임, 실시간 주식 차트와 같은 실시간이 요구되는 응용프로그램의 개발을 한층 효과적으로 구현할 수 있게 되었습니다. 가상화폐의 분산화 기술의 핵심도 web socket으로 구현할 수 있다는 점 언급해두고 싶습니다.
TL; DR
- HTTP는 통신 제약이 있는 약속입니다.
- AJAX로 HTTP의 통신 제약으로부터 조금 벗어날 수 있었습니다.
- Websocket은 HTTP의 통신 제약을 해결한 새로운 약속입니다.
그럼 이만 안녕히 계세요. 개발자 chullin이었습니다. 궁금하신 점들과 어려운 내용들은 댓글로 해결해주시면 좋겠습니다. 도움이 되신 분들로부터의 Clap은 큰 힘이 됩니다!
짧은 정보
AJAX는 이름이 왜 AJAX 인가요?
- Asynchronous Javascript And Xml의 약자입니다. (비동기적인) 자바스크립트로 DOM을 읽고 쓰며, XMLHttpRequest 객체를 통해 서버와 데이터를 주고받기 때문에 이러한 이름이 붙은 것으로 저는 이해했습니다.
HTTP와 HTTPS에는 무슨 차이가 있나요?
- 뒤에 붙은 S는 Secured의 S입니다. 웹페이지를 요청하는 사람이 무슨 페이지를 요청하는지, 서버가 유저에게 어떤 페이지를 주었는지가 암호화됩니다.
- 우리 정부가 야동 사이트, 불법 웹툰 사이트, 불법 도박 사이트 등을 전부 없애지 못하는 이유도 이 S 때문입니다. 이 기사를 보시면 다소간 도움이 되실 듯 싶네요.
.
.
이번 블로그 글을 쓸 수 있게 도와준 블로거들에 대한 감사의 말
.
.
이번 글은 HTML5를 여행하는 비웹개발자를 위한 안내서와 ZDnet 기사를 많이 참고하였습니다. 감사드립니다.
