[WEB기초] HTTP, AJAX, Web Socket

• HTTP는 통신 제약이 있는 약속입니다.
• AJAX로 HTTP의 통신 제약으로부터 조금 벗어날 수 있었습니다.
• Websocket은 HTTP의 통신 제약을 해결한 새로운 약속입니다.

1. HTTP(Hyper Text Transfer Protocol)

HTTP의 앞 두글자 Hyper Text는 HTTP가 등장하기 이전 세대에서 통신한다 함은, 터미널 창에서 딱딱한 텍스트를 주고 받는 것이였다. 

HTTP의 뒤 두 글자 Transfer Protocol. HTTP의 대전제는 “URL 및 부가정보를 통해 사용자가 원하는 페이지를 서버에 요청한다, 그리고 서버는 해당 요청에 응답한다” 이다. -> 사용자가 URL을 요청할 때만 서버에서 해당 페이지를 꺼내준다.

 

즉, 브라우저가 웹서버에 무엇인가를 요청하려면, 페이지를 이동하지 않고서는 요청할 방법이 없다. 초기 웹의 목적은 문서 전달과 하이퍼링크를 통한 문서 연결이었다. 웹을 위한 HTTP 프로토콜은 이러한 목적에 매우 부합하는 모델이다. 그러나 시대가 변하고 환경이 발전할수록 동적인 표현과 뛰어난 상호작용이 요구되었고 이로 인해서 새로운 기술이 탄생했다.

ex. 엑티브엑스, 플래시, 자바애플릿, 실버라이트 등이 있다. 문제는 순수 웹 환경이 아니라 별도의 런타임을 플러그인 형태로 브라우저에 설치해야 한다는 점이다.

플래시를 집어넣어 몽땅 플래시 기반으로 사이트를 만들기도 하고 특히 한국에서는 ActiveX를 얻어서 웹도 아니고 애플리케이션도 아닌 어정쩡한 결과물들이 넘쳤다.

 

이에 구글이 AJAX라는 방안을 제시했다.

AJAX는 HTTP를 효과적으로 이용하는 기술이다. AJAX는 약속은 아니다.(HTTP는 약속) 효과적으로 서버와 소통하기 위한 기술이다.

 

2. AJAX(Asynchronous Javascript And Xml)

오늘날 Ruby, JQuery 등을 이용한 대중적인 웹 개발의 기반에도 페이지 이동 없는 통신의 근간을 이루는 기술이 되었다.

Ajax가 쓰이기 시작하면서 웹 페이지들은 페이지 이동 없이도 서버와 통신을 했고 페이지에 구멍을 뚫지 않아도 특정 영역만 업데이트하거나 조작할 수 있게 됐다.

웹 브라우저에 쓰이던 자바 스크립트는 XMLHttpRequest라는 API가 있었다.(IE 기준 5.0부터 지원)

 AJAX 기술이 들어가지 않은 HTTP에 따른 통신(출처. 이미지 클릭)

위는 AJAX 기술이 들어가지 않은 HTTP의 통신 방식이다. 요청 페이지에서 확인을 누르면, 확인을 눌렀다는 정보를 서버에 전달한다. 웹서버는 요청을 받고, 처리한 후에 HTML 페이지를 생성하고, 유저에게 해당 HTML페이지를 전송한다. 이 방식을 선택한다면, HTML(즉 웹 페이지)을 하나 새롭게 브라우저에 뿌리게 되고, 결국 새로운 페이지로 이동하는 결과를 마주하게 된다.

아래는 이제 다뤄볼 AJAX 기술이 들어간 통신 방식이다.

 

AJAX 기술이 들어간 HTTP에 따른 통신. (출처: 이미지 클릭)

AJAX를 쓰면, 유저는 새로운 HTML을 서버로부터 받는 것이 아니다. 즉, 유저는 (유저가 정말 새로운 웹페이지로 이동하기를 원하는 것이 아닌 한)새로운 웹페이지로 이동하는 것이 아닌, 동일한 웹페이지 내에서 DOM을 변경하게 된다.

 

요청 페이지에서 이름 칸에 ‘촉새’를 쓰고, 내용에 ‘안녕하세요. 촉새입니다’라고 썼다고 해보자.

사용자의 이벤트로부터 Javascript는 해당 이름과 내용이 쓰여진 DOM을 읽는다. 그리고는 XMLHttpRequest 객체를 통해 웹서버에 해당 이름과 내용을 전송한다. 웹서버는 요청을 처리하고 XML, Text 혹은 JSON을 XMLHttpRequest 객체에 전송한다. 그러면, Javascript가 해당 응답 정보를 DOM에 쓴다. 그렇게 결과페이지가 만들어 진다.

AJAX를 쓰면 새로운 HTML을 서버로부터 받아야 하는 것이 아닌, 동일한 페이지의 일부를 수정할 수도 있는 가능성이 생긴다. 결과적으로 사용자 입장에서는 페이지 이동이 발생되지 않고 페이지 내부 변화만 일어나게 된다. HTML 페이지 전체를 다 바꿔야 하는 것이 아니라 부분만 바꿀 수 있게 되는 것이다.

 

- AJAX의 주요 구성 요소

- XMLHttprequest : 웹서버와 통신을 담당함. 사용자의 요청을 웹서버에 전송 및 웹서버로부터 받은 결과를 웹브라우저에 전달함
- DOM : 문서의 구조를 나타냄, 폼 등의 정보나 화면 구성을 조작할때 사용함
- CSS : 글자색,배경색,위치,투명도 등 UI관련 부분을 담당
- 자바스크립트 : 사용자가 마우스를 드래그하거나 버튼을 클릭하면 XMLHttpRequest객체를 사용해 웹서버에 요청을 전송함.
XMLHttpRequest 객체로부터 응답이 오면 DOM, CSS등을 사용해 화면을 조작함.

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를 여행하는 비웹개발자를 위한 안내서)

그 외에도 HTML5를 여행하는 비웹개발자를 위한 안내서 링크를 눌러보면(그럼으로써 웹브라우저로 하여금 미디엄의 서버로부터 새로운 HTML페이지를 응답으로 받는다면), 더욱 많은 AJAX 사례들을 확인해보실 수 있다. 비밀번호 강도 확인, 검색어 실시간 추천, 마우스 커서나 스크롤바 위치에 반응하는 그림, 지도 표시 서비스 등등 다양하다.

 

그러나 여전히 AJAX로 여전히 수행하지 못하는 것들이 있습니다.

왜냐하면, AJAX도 여전히 HTTP로 서버와 통신하기 때문이다. 즉, AJAX도 HTTP의 한계를 완전히 벗어나지 못했다. HTTP는 “클라이언트의 요청이 있고 그 다음 서버로부터 응답을 받는 상황”인데, 이 틀로부터 벗어나지 못했다.

“클라이언트의 요청이 있고 그 다음 서버로부터 응답을 받는 상황”에서 벗어나는 예를 들어보면, “클라이언트의 요청이 없음에도, 서버로부터 응답을 받는 상황”을 들어보고자 한다.

요청이 있고 응답이 있는 경우는 문제가 없다. (출처: HTML5를 여행하는 비웹개발자를 위한 안내서)

요청이 없지만 응답은 있는 경우는 문제가 됩니다. 영희가 요청하지 않은 응답은 오지 않는다. (출처: HTML5를 여행하는 비웹개발자를 위한 안내서)

이러한 경우 외에도 웹 상에서는 갈수록 동적인 표현과 뛰어난 상호작용이 요구되었다. 이러한 문제에 대응하기 위해 Comet 이 등장했다. 하지만, 이 방법은 “클라이언트의 요청이 없음에도, 서버로부터 응답을 받는 상황”에 대한 미봉책[RFC6202]이었다. 즉, 데이터 수신을 위해 서버가 클라이언트에게 전송해 주는 푸시(push)방식이 아니라 여전히클라이언트가 서버에에게 요청하는 폴링(polling) 방식이다.

이와 같은 애로사항은 HTML5 개발 과정에 녹아들었다. 결국, HTML5은 순수 웹 환경에서 실시간 양방향 통신이 가능해지게 만들어졌다. 그 스펙의 명칭이 바로 ‘웹 소켓(Web Socket)’ 이다.

 

3. 웹 소켓(Web Socket)

HTML5 버전이 나올때 함께 등장했던 웹소켓은 2016년 11월 1일 HTML5.1버전이 나오고 2017년 12월 14일 HTML 5.2 버전이 나올  때까지 더더욱 발전했다.

웹 소켓은 브라우저와 서버가 지속적으로 연결된 TCP 소켓과 같이 양방향(연결지향) 통신을 할 수 있도록 지원하는 프로토콜이다.

웹소켓은 HTTP의 문제를 해결해주는 약속이다. HTTP에서 원리적으로 해결할 수 없었던 문제는 "클라이언트의 요청이 없음에도, 그 다음 서버로부터 응답을 받는 상황"이엇는데, 웹 소켓은 HTTP가 해결할 수 없었던 이 문제를 해결하는 새로운 약속이었다. 즉, 브라우저가 서버에 데이터를 요청하고 서버가 브라우저에 데이터를 보내기 위해 별 다른 제약이 없다.

 

웹소켓 특징 2가지

1) 양방향 통신(Full-Duplex)

데이터 송수신을 동시에 처리할 수 있는 통신방법이다. 웹 소켓은 클라이언트(client)와 서버(server)가 서로에게 원할때 데이터를 주고 받을 수 있으니 양방향이라고 말할 수 있다.

2) 실시간 네트워킹(Real Time-Networking)

웹 환경(ex. 웹 브라우저)에서 채팅(chatting), 주식(stock), 비디오(video) 데이터 등의 데이터들은 연속된 데이터를 화면에 빠르게 보여주어야 하거나, 여러 단말기(ex. PC, 스마트폰)에 빠르게 데이터를 교환하는 실시간처리가 필요한 부분들이 았다. 가상화폐들의 변하는 가격들을 웹 사이트에서 실시간으로 볼 수 있는데 이런 서비스를 구현할 때 사용될 수 있다.

※ 웹 소켓 특징 중 하나가 실시간 네트워킹인 이유는 웹 소켓이 아닌 다른 비슷한 기술로는 웹 브라우저 위에서 실시간으로 통신하기가 웹 소켓에 비해 상대적으로 어렵기 때문이다.

웹소켓 이전의 비슷한 기술

Polling, Long Polling, Streaming, XML Http Request, Ajax

웹소켓이 등장하기 이전에, 웹 소켓의 기능과 동일하게 만들 수 있는 기술들이 있었다. 웹소켓의 이해가 부족하거나 웹 소켓을 이용해서 개발하기가 부담스러운 환경이라면, 기존의 기술들인 위 목록에 나와있는 것들 중에서 하나를 골라서 개발해도 웹 소켓의 기능을 비슷하게 구현가능 할 것이다.

※ XML Http Request나 Ajax의 경우, 클라이언트가 서버에 원할 때 데이터를 보내서 요청하는 것이 목적이기 때문에, 그 반대가 어렵다. 서버가 클라이언트에게 원할 때 데이터를 보내는 것은 어렵다.

 

웹 소켓 동작 방법

웹 소켓 동작방법 (쿨처. 이미지 클릭)

1) Web Client는 handshake 요청 메시지를 Web Server에게 보낸다.

2) Web Server는 handshake 응답 메시지를 Web Client에게 보낸다.

3) Web Client는 data payload frames를 Web Server에게 보낸다.

4) Web Server는 data payload frames를 WEb Client에게 보낸다.

5) Web Client는 close frame을 Web Server에게 보낸다.

6) Web Server는 close frame을 Web Client에게 보낸다.

웹 소켓 프로토콜의 특징

• 최초 접속에서만 http 프로토콜 위에서 handshaking을 하기 때문에 http header를 사용한다.
• websocket을 위한 별도의 포트는 없으며, 기존 포트(http-80, http-443)를 사용한다.
• websocket 프로토콜의 ws는 http기반으로 운영되고, wss는 https기반으로 운영된다.
• 메시지 (Upgrade : Websocket, Connection : Upgrade)
• 메시지에 포함될 수 있는 교환 가능한 메시지는 텍스트(text)와 바이너리(binary)이다.

 

웹소켓에서는 서버와 브라우저 사이에 양방향 소통이 가능하다. 브라우저는 서버가 직접 보내는 데이터를 받아들일 수 있고, 사용자가 다른 웹사이트로 이동하지 않아도 최신 데이터가 적용된 웹을 볼 수 있게 해준다. 웹페이지를 ‘새로고침’하거나 다른 주소로 이동할 때 덧붙인 부가 정보를 통해서만 새로운 데이터를 제공하는 웹서비스 환경의 빗장을 본질적으로 풀어준 셈이다.

웹소켓 약속 하에서는 실시간 소통이 편안해지게 된다. 웹에서도 채팅이나 게임, 실시간 주식 차트와 같은 실시간이 요구되는 응용프로그램의 개발을 한층 효과적으로 구현할 수 있게 되었다. 가상화폐의 분산화 기술의 핵심도 web socket으로 구현할 수 있다.

 

HTTP와 HTTPS에는 무슨 차이가 있나요?

• 뒤에 붙은 S는 Secured의 S입니다. 웹페이지를 요청하는 사람이 무슨 페이지를 요청하는지, 서버가 유저에게 어떤 페이지를 주었는지가 암호화됩니다.
• 우리 정부가 야동 사이트, 불법 웹툰 사이트, 불법 도박 사이트 등을 전부 없애지 못하는 이유도 이 S 때문입니다. 이 기사를 보시면 다소간 도움이 되실 듯 싶네요.

 

 

출처 : medium.com/@chullino/http%EC%97%90%EC%84%9C%EB%B6%80%ED%84%B0-websocket%EA%B9%8C%EC%A7%80-94df91988788

HTTP에서부터 WEBSOCKET까지

caileb.tistory.com/185

웹 소켓 통신 (Web Socket)