reference: https://kotlinworld.com/75
HTTP 프로토콜 통신도 결국 소켓 통신을 기반으로 한다. TCP 프로토콜 계층 위에 존재하는(응용 계층) HTTP 또한 소켓 통신을 기반으로 하고, IP와 Port 번호 등이 존재하는 TCP/IP 헤더들이 붙여져 메시지가 송수신된다.
다만 둘을 구분하는 이유는 HTTP 프로토콜 통신의 경우 한쪽에서만 요청에 대한 응답을 하는 웹 통신에 특화되어있기에, 또는 이러한 통신을 위해 일반적인 소켓 통신 매커니즘과 다르기 때문에 구분하는 것이다.
HTTP 프로토콜 통신과 소켓 통신
HTTP 프로토콜 통신
기존에는 HTML 파일을 전송하는 프로토콜의 의미를 가졌다(Hyper Text Transfer Protocol). 웹 브라우저에서의 통신은 초기 대부분 HTML 파일을 전송하는 목적이였기 때문이다.
현재는 JSON, Image 등 다양한 형식의 파일들을 전송할 수 있다.
HTTP 통신은 클라이언트에서 서버로 요청을 보내고, 서버가 이에 응답하는 방식으로 통신이 이루어진다. 여기서 응답은 클라이언트의 요청에 따른 결과를 반환한 것이다.
"클라이언트의 요청이 있을 때 서버가 응답하는 방식, 단방향 통신"
서버의 응답에는 응답 코드(202, 404 ..)가 같이 전송되며, 사용자는 응답 코드와 메시지 응답으로부터 오는 메시지 바디를 통해 요청 값을 전달받는다.
초기, 서버는 응답한 후 클라이언트와 연결이 바로 끊어졌으나(HTTP 프로토콜의 '무연결성'), 최근에는 성능상 이유로 'Keep Alive' 옵션을 통해 일정 기간동안 클라이언트와 연결을 유지하는 방식이 도입되기도 한다.
Socket 통신
소켓 통신에서는 서버와 클라이언트가 양방향 연결이 이루어진다. 클라이언트만이 서버로 요청을 보내는 것이 아니라, 서버도 클라이언트로 요청을 보낼 수 있다.
"클라이언트와 서버 양쪽에서 서로에게 데이터 전달을 하는 방식의 양방향 통신"
보통 스트리밍이나 실시간 채팅 등 실시간으로 데이터를 주고 받아야 하는 경우 연결을 자주 맺고 끊는 HTTP 통신보다 소켓 통신을 직접적으로 사용하는 것이 적합. 소켓 통신은 계속해서 연결을 유지하고 있기에 HTTP 통신보다 연결/해제의 반복적 오버헤드가 줄어든다. 반면 리소스가 많이 소모되는 단점도 있다.
정리
- 자주 데이터를 주고 받는 환경이 아닌 경우: HTTP 프로토콜 통신이 유리
- 자주 데이터를 주고 받아야 하는 환경인 경우: 직접적인 소켓 통신이 유리
- HTTP 통신은 사용자가 서버에 요청을 보내는 단방향 통신, 소켓 통신은 양방향 통신
reference: https://ws-pace.tistory.com/104
HTTP에서 실시간 통신을 하려면?
- Polling
- Long Polling
- Streaming
1. Polling
브라우저가 일정한 주기마다 서버에 HTTP 요청을 보내는 방식이다. 서버 쪽 데이터 업데이트 주기는 클라이언트 쪽에선 예측 불가능하므로 불필요한 요청이 있을 수 있고 이는 서버 및 네트워크 부하를 늘리는 악영향이 될 수 있다.
ex) 실시간 야구 문자 중계는 10초 주기로 업데이트
주기(interval)가 짧을 수록 실시간성은 높아지지만 서버 및 네트워크 부하가 높아지는 trade-off가 발생한다.
실시간성이 조금 떨어지더래도 주기를 늘려 여러 대의 클라이언트와 통신할 때 사용하는 방식이다.
ex) 페북 친구 리스트의 온라인 상태 확인, 약 1분 주기
2. Long Polling
polling 방식의 단점인 서버 부하를 줄이면서 실시간성을 높이기 위한 방식이다. HTTP 요청이 서버로 들어올 때 Polling 방식과 달리 요청에 대한 응답을 보내고 연결을 바로 끊는 것(stateless 방식)이 아닌 일정시간 대기한다. 이 대기 시간 중 데이터 업데이트(변경)이 일어났으면 바로 클라이언트에 응답을 보낸다. 응답을 받은 클라이언트는 바로 서버에 다시 요청을 보낸다.
수 많은 클라이언트와 연결된 채팅방을 가정해보면, 한 명이 채팅을 쓰면 데이터가 변경되고, 서버는 변경된 데이터를 연결된 모든 클라이언트에 동시다발적으로 응답을 보내게 될 것이다. 그리고 수 많은 클라이언트들은 응답을 받은 후 다시 요청을 동시다발적으로 서버에 보낼 것이다.
이러한 과정에서는 트래픽이 일시적으로 몰리는 경우가 발생하고, 서버 쪽의 요청 Queue가 쌓여 부담이 될 수 있다.
Long Polling 방식은 서버의 부하를 줄이면서 실시간성을 높여주는 장점이 있지만 (1)비교적 많은 클라이언트와의 연결, (2)데이터 변경 빈번한 경우 오히려 서버에 부담을 줄 수 있다.
따라서 실시간성이 필요한 적은 수의 클라이언트와 연결되어있는 경우 사용하는 것이 좋다.
ex) 웹 1:1 채팅, 10명 이하의 단체 채팅
3. Streaming 방식
(Long)Polling 방식에서는 서버로부터 응답을 받으면 클라이언트가 곧바로 재차 요청을 보내는 방식을 사용함으로써 실시간성을 유지한다. 이 방식에서는 HTTP의 Stateless 특성에 의해 재연결 오버헤드가 커지게 된다.
스트리밍 방식에서는 서버는 요청을 받으면 요청에 대한 응답을 완료하지 않은 상태에서 데이터를 계속 보내도록 한다. 따라서 클라이언트는 응답을 받더라도 연결을 끊고 다시 요청을 보내는 과정없이 계속 응답을 받아 처리한다.
서버는 무한정 혹은 일정 시간동안 요청을 대기시키고, chuncked 메시지를 이용하여 연결을 계속 유지하는 방식이다.
이 문제의 단점은 클라이언트에서 서버로 데이터를 보내는 것이 힘들다는 점이다. 실시간 양방향 통신이 아닌 실시간 단방향 통신과 가깝다.
정리
- Polling
- 일정주기마다 서버에 요청
- 이벤트가 없어도(데이터 변경이 없어도) 요청이 이루어지기에 서버, 클라이언트 둘다 부담
- Long Polling
- 서버가 요청을 받으면 바로 응답을 보내는 것이 아니라 이벤트가 발생하면 응답을 보낸다.
- 전체적인 요청/응답량이 줄어들지만 수 많은 클라이언트와 연결되어 있고, 이벤트 발생(데이터 변경)이 빈번하다면 오히려 서버 쪽에서 부담이 될 수 있다.
- Streaming
- 서버가 요청을 받으면, 요청에 대한 응답을 완료하지 않은 상태에서 계속해서 데이터를 클라이언트 쪽으로 보낸다.
- 클라이언트 쪽에서 서버에 데이터를 보내기 힘들다는 단점이 있다.
reference: https://theheydaze.tistory.com/565
Websocket
응용 계층의 관점에서 웹 서비스는 HTTP 프로토콜 기반으로 동작한다. 비연결성이라는 특징에 의해 '실시간성'이 떨어지는 단점이 있다. 이러한 단점을 Websocket이라는 '실시간으로 상호작용하는 웹 서비스 표준 기술'이 도입된다.
source: https://learn.microsoft.com/ko-kr/azure/application-gateway/application-gateway-websocket
배경
- HTTP 프로토콜 기반으로 실시간 웹을 구현하기 위해선 Polling, Streaming 방식의 Ajax 코드를 통행 이루어졌다.
- 이러한 방식은 각 브라우저마다 구현 방법이 달라 개발이 어렵다는 문제가 있다. 또한 Polling, Streaming 기법 또한 trade-off가 존재한다.
- 이를 위해 HTML5 표준의 일부로 Websocket이 만들어지게 되었다.
특징
- TCP 소켓과 달리 응용 계층에서 핸드셰이킹(Handshaking)이 일어난다. HTTP 요청을 통해 핸드셰이킹이 시작되고, 최초 접속이 이루어진다.
- 웹 개발 과정 중 직접적으로 바이트스트림을 기반으로 TCP 소켓 통신을 활용할 수 있지만, 원시 바이트가 아닌 응용 계층의 메시지를 통해 소켓 통신을 할 수 있다.
- TCP 소켓의 추상화된 형태라 할 수 있다.
- 일반적인 HTTP 요청과 마찬가지로 80번 포트를 통해 웹서버와 연결된다.
- HTTP 요청을 그대로 사용하기에 기존의 80(http), 433(https) 포트로 접속하므로 추가로 방화벽을 열지 않고도 양방향 통신이 가능하다.
- HTTP 규격인 CORS 적용이나 인증 등의 과정을 기존과 동일하게 사용할 수 있다.
http://대신ws"//로 시작한다.- 클라이언트인 브라우저와 마찬가지로 웹 서버도 Websocket 기능을 지원해야 한다.
- Websocket을 지원하는 서버 구현체: Jetty, GlassFish, Node.js, Netty 등 ..
추가 참고자료
reference: (Microsoft Windows 블로그)https://kotlinworld.com/75
"When to use a HTTP call instead of a WebSocket (or HTTP 2.0)"
HTTP를 사용해야 하는 경우
source: https://blogs.windows.com/windowsdeveloper/2016/03/14/when-to-use-a-http-call-instead-of-a-websocket-or-http-2-0/
