✋🏻 들어가며,
부트캠프에서 알게 된 지인들과
사이드프로젝트로 '유니버스'라는 웹 사이트를 제작하고 있다.
코드를 짜면서도 늘 부족함을 느끼는 부분은 네트워크에 대한 이해였다.
서버와 클라이언트가 서로 통신하며 일어나는 일들에 대해 설명해보라고 하면,
머릿속에 뭉게구름처럼 지식이 존재할 뿐.
구체적으로 어떻게 웹사이트가 돌아가는지 늘 궁금증을 느꼈고,
웹의대표적인 통신 방법인 HTTP 와 이번에 구현하게 된 Web Socket 에 대해 공부하고,
각각의 특징과 차이점에 대해 정리 해 보았다.
👉🏻유니버스 프로젝트에 대한 자세한 내용이 궁금하시다면 이곳을 클릭해주세요 :)
🧾 HTTP 통신이란?
HTTP가 등장하기 이전 세대에서 통신한다 함은,
터미널 창에서 딱딱한 텍스트를 주고받는 것이었다.
그런데 HTTP의 등장 이후,
시각적으로나 정보량 차원에서 엄청나게 멋진 문서를 주고 받을 수 있게 되었다.
HTTP는 HyperText Transfer Protocol 의 약자인데,
HyperText 란, 아주 멋진(super보다 더 멋진 hyper)텍스트 문서를 의미한다.
Transfer Protocol 이란, 통신 약속을 의미한다.
즉 HTTP는 HTML 파일을 전송하기 위한 약속이다.
"URL 및 부가정보를 통해 사용자가 원하는 페이지를 서버에 요청하면, 서버는 해당요청에 응답한다." 와 같은 대전제가 있는 통신규약인 것이다.
웹 브라우저 초기에는 HTML 파일을 전송하려는 목적으로 만들어졌으나,
현재는 JSON, Image 파일 또한 전송한다.
☝🏻 HTTP 통신의 통신 방식 - 특징 3가지
단방향 통신
클라이언트에서 서버로 요청을 보내야만,
서버가 응답하는 방식으로 통신이 이루어진다.
즉 단방향 통신이며, 사용자는 응답 코드와 메세지 바디를 통해 요청 값을 전달받는다.
재밌는 비유가 있었는데,
마치 답장은 주지만 선톡은 절대 오지않는 소개팅남(녀)라고 표현한 게 익살스러워 기억에 남았었다.무상태 프로토콜(Stateless) 지향
서버가 클라이언트의 연결/상태를 보존하지 않는다.
즉 이전 요청과 같은 데이터를 원하더라도 다시 서버에 동일한 요청을 해야한다.
하지만 로그인 같은 상태 정보는 서버에 유지시켜야 하기에
브라우저 쿠키나 세션 등을 이용해 상태를 유지한다.비연결성
클라이언트가 서버에 요청을 하고 응답을 받으면
바로 TCP/IP 연결을 끊어 연결을 유지하지 않는 것이다.
이를 통해 서버는 자원을 효율적으로 관리할 수 있게 되고,
수많은 클라이언트의 요청에도 대응할 수 있게 된다.
수 천명이 서비스를 사용해도 실제 서버에서 0.0000001초까지
동일한 시간에 동시에 요청을 하지는 않기 때문이다.
🧐 HTTP의 한계와 AJAX 기술의 등장
최근 HTTP의 성능상의 이유(Connection을 맺고 끊는 비용이 비싸다)로 Keep Alive 옵션을 통해
일정 기간 동안 클라이언트와 Connection 을 유지하는 방식으로 통신이 가능해졌다.
왼쪽의 경우는 데이터를 주고 받을 때 열고 닫고를 반복,
오른쪽은 keep alive를 설정해 데이터를 계속 주고 받는다. 지정한 시간 내에서 말이다.
하지만 이것도 무조건 좋은 기능은 아닌 것이,
사용자가 많다면 연결이 늘어나면서 새로운 사용자를 받아들이지 못하는 경우가 있다.
사용자가 많고 유동이 많은 서비스에서는 사용이 권장되지 않는다.
또한 HTTP는 UX적인 면에서도 통신제약이 작용했는데,
바로 사용자가 새로운 URL을 요청할 때에만 서버에서 해당 페이지를 꺼내주는 식이라는 것이다.
클라이언트가 요청을 한 후, 서버에서 응답값으로 HTML 문서가 새로 오면
사용자는 페이지도 새롭게 이동해야 했고, 이는 굉장히 번거롭고 또 깔끔하지 않은 통신 방법이었다.
이를 해결하기 위해 AJAX가 나타났다.
AJAX는 HTTP를 효과적으로 이용하기 위한 기술이며, 2002년에 구글이 개발한 웹을 통해 세상에 빛을 발하게 되었다.
1989년 팀 버너스리의 HTTP 통신규약 탄생 이후 15년만의 등장이었다.
(1) HTML 전체를 서버로부터 응답받던 기존의 나이브한 HTTP 통신방식
(2) AJAX 기술이 들어간, 새로운 통신 방식
AJAX는 html 페이지 전체가 아닌 일부분만 갱신할수 있도록 XMLHttpRequest객체를 통해 서버에 요청을 보낸다. 그동안 XMLHttpRequest는 서버와의 연결을 잡아둔다.
Json이나 XML형태로 필요한 데이터만 주고 받으며 DOM을 갱신하기 때문에 그만큼의 자원과 시간을 아낄 수 있다.
즉, ‘비동기적 방식’을 이용해 동기적 방식과는 반대로 서버의 응답이 올 때까지 대기하지 않고,
서버의 데이터가 준비되는 동안에도 사용자가 웹페이지에서 다른 작업을 수행할 수 있는 방식을 의미한다. 아래 그림처럼 동적으로 웹사이트 이용이 가능해 진 것이다.
하지만 AJAX 도 HTTP의 한계를 완전히 벗어나지 못했는데, 데이터 수신을 위해 서버가 클라이언트에게 전송해 주는 푸시(push)방식이 아니라 여전히 클라이언트가 서버에게 요청하는 폴링(polling) 방식이었다는 것이다.
이와 같은 애로사항은 HTML5 개발 과정에 녹아들었고, 결국 순수 웹 환경에서 실시간 양방향 통신이 가능해지게 만들어졌다. 그 스펙의 명칭이 바로 웹 소켓(Web Socket)이다.
🔉 드디어, 웹소켓의 등장!
웹소켓(Web Socket)은 클라이언트와 서버(브라우저와 서버)를 연결하고 실시간으로 통신이 가능하도록 하는 첨단 통신 프로토콜이다.
웹소켓은 하나의 TCP접속에 전이중(duplex) 통신 채널을 제공한다.
쉽게 말해, Socket Connenction을 유지한 채로 실시간으로 양방향 통신 혹은 데이터 전송이 가능한 프로토콜이다.
한번 연결이 이루어지면 클라이언트가 요청하지 않아도 데이터가 저절로 서버로부터 올 수 있다. 예를 들어, 실시간 채팅이 가능하거나 주가변동이 실시간으로 화면에 렌더링이 된다. 이는 WebSocket을 이용한 기술이다.
HTTP 와 다르게 상태(Statefule) 프로토콜이기 때문에, 한번 클라이언트와 연결되면 같은 연결을 이용해 통신하므로 TCP 커넥션 비용을 아낄 수 있다.
웹소켓은 TCP연결 처럼 핸드셰이크를 이용해 연결을 맺는다.
이때 HTTP 업그레이드 헤더를 사용하여 HTTP 프로토콜에서 웹소켓 프로토콜로 변경한다.
즉, 최초 접속시에는 HTTP 프로토콜을 이용해 핸드셰이킹을 한다.
이후 연결이 맺어지면 어느 한쪽이 연결을 끊지 않는 이상
영구적인(persistent) 동일한 채널이 맺어지고, HTTP 프로토콜이 웹소켓 프로토콜로 변경된다.
📚참고
서버와의 연결을 계속? keep alive! 👉🏻 https://kamang-it.tistory.com/m/599
HTTP 통신과 Socket 통신의 차이점 👉🏻 https://kotlinworld.com/75
🌐-웹-소켓-Socket-역사부터-정리[Inpa Dev 👨💻:티스토리] 👉🏻https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-%EC%9B%B9-%EC%86%8C%EC%BC%93-Socket-%EC%97%AD%EC%82%AC%EB%B6%80%ED%84%B0-%EC%A0%95%EB%A6%AC
HTTP에서부터 WEBSOCKET까지 👉🏻
https://medium.com/@chullino/http%EC%97%90%EC%84%9C%EB%B6%80%ED%84%B0-websocket%EA%B9%8C%EC%A7%80-94df91988788Ajax란, 활력 있는 웹페이지를 만들기 위한 필수 기능 👉🏻
웹소켓이란? HTTP와 웹소켓의 차이 👉🏻
https://code-lab1.tistory.com/300