통신 프로토콜이 각각의 통신계층에 어디에 위치하고 해당 데이터들이 어떻게 조립되는지 이해가 점점 명확해면서 나는 굉장히 이 내용을 잘 설명할 줄 알았는데, 제한 된 시간내에 핵심을 아직 추려내는게 쉽지 않았다. 글을 통해서 http, websocket에 대해서 다시한번 더 명확하게 정리하고자 한다.
해당 내용을 REST API와 더불어 설명을 해야했던 기억이 있는데, 생각보다 조리있게 내가 잘 이야기를 못한 듯하다.
일단 세가지 개념의 역사에 대해서는 링크의 블로그가 매우 잘 정리를 하고 있다. ( Chullin님 블로그 )
HTTP란?
웹 상에서 웹 서버 및 웹브라우저 상호 간의 데이터 전송을 위한 응용계층 프로토콜이다. 요청 및 응답 메시지로 대응되는 구조를 띄고있다. (클라이언트 서버 모델)
데이터은 위의 도식과 같다. 이 통신 프로토콜은 트랜잭션 중심의 비연결성 프로토콜이다. 각각의 통신을 하는 주체(노드) 간 연결이 없고, stateless 특성을 지닌다.
HTTP 프로토콜의 표준은 아래와 같다.
RFC 1945 ( http 1.0 )
RFC 2616 ( http 1.1 )
RFC 7230 - 7235기회가 되면 요청 메시지와 응답 메지를 한번 파싱 해보도록 하겠다. 지금은 간단하게 구조만 파악한다.
[ Request Message ]
HTTP 프로토콜에서 Request Method는 GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT가 있다. 주로 GET, POST를 중심으로 쓰게 되는 듯하다.
Request Header에는 Host(도메인 이름), Accept(클라이언트가 다룰 수 있는 MINE 타입), Accpt-Language, Accpet-Charset, Accept-Encoding 등 이 포함된다.
이에 대해서 응답은 아래와 같다.
[ Reponse Message ]
Request의 상태코드가 상세 내용은 링크를 참고하고 요약한다. ( 링크에 표로 잘 정리되어 있음 )
- 1XX(Informational) — 서버의 상태정보
- 2XX(Success) — 수신하였고 이를 처리했다는 의미
- 3XX(Redirection) — 요청을 처리하기 위해 다른 액션이 필요함을 의미한다.
- 4XX(Client Error) — Request에 오류가 있거나 해당 내용을 해석하지 못함. 보통 400 문법 오류, 403 서버에서 리소스 제공을 거부, 404 요청 리소스를 서버에서 찾지 못하는 경우, 405 클라이언트 요청을 서버에서 허용하지 않음을 자주 볼 수 있다.
- 5XX(Server Error) — 서버에서 Request를 처리하지 못함. 500 서버 내부 프로그램의 오류, 501 요청메서드가 잘못됨, 503 과부하 등으로 서버 응답 불가 등이 있다.
Response Header에는 Location, Server, WWW-Authnticate, Allow, Content-Encoding, Content-Type, Expires, Last-Modified, Accept-Ranges, Etag, Content-Language, Content-Location, Content-MDS, Transfer-Encoding 등이 있다.
세부적인 내용들은 파싱을 하면서 한번 보고자 한다.
다시 위의 이야기중 통신 특성으로 잠시 회귀한다.
- 양방향 노드간 통신을 유지하지 않는다.
이 특성은 http 통신 프로토콜의 성능 이슈가 발생한다. 연결당 하나의 요청과 응답을 처리하도록 되어있기 때문에 동시 전송 문제와 다수의 리소스를 처리하기에 성능이 떨어진다는 것이다. 이를 개선하기 위해서 아래의 2가지 개념이 나온듯하다. 이 외에도 웹소켓이 등장하기 전까지 실시간 처리를 위한 HTTP Comet(Long Polling, Streaming) 개념도 있다.
- http/2.0 — 기존 방식에서 개선을 하는 방법(데이터를 압축하거나, 한번에 여러개의 메시지를 처리)
- websocket — TCP socket 연결을 직접하는 방식
두가지 방식 모두 장단점이 있기 절대적으로 더 좋다는 없다.
HTTP/2.0
해당 내용은 링크의 블로그가 정말 일목요연하게 잘 정리를 하고 있다. 링크의 블로는 Factory.hr의 블로그를 번역한 내용이다. 일부 발췌한다.
HTTP/2.0 설명 (web.dev)HTTP/2.0은 2015년 IETF에서 출시 된 HTTP/1.0의 성능 개선 버전이다. 개선의 주요 골자는 아래와 같다.
- 멀티플렉싱 요청 : 연결 하나당 하나의 요청과 응답이 있던 것을 여러 데이터를 보낼 수 있도록 개선
- 헤더 압축 : 데이터를 압축하여 처리 효율을 가져온다.
- 이진 프로토콜 : 기존 텍스트 프로토콜에서 바이너리 프로토콜로 변경하여 처리량을 증가시키고 데이터 분석 시 오버헤드를 줄여 성능 개선.
WebSocket
하나의 TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜이다. 아래는 표준 번호이다.
RFC 6455
HTTP방식으로 HandShaking을 완료하고 양 노드간 통신을 연결한 채로 데이터를 주고 받는다. 해당 프로토콜의 데이터 프레임 설명은 아래와 같다.
hand-shaking에 대한 기본적인 개념으로 접근하고 보다 세부적인 내용은 표준을 참고하는것이 좋겠다. (내용이 넘으 많다.)
기본적인 웹소켓 API는 6가지로만 모든 동작을 한다.
- 이벤트 핸들러 : onopen, onmessage, onerror, onclose
- 함수 : send, close
아주 간단한 기능들만을 제공하기 때문에 SockJs나 Socket.IO와 같은 오픈소스 라이브러리를 많이 사용한다고 한다. 웹 소켓은 실시간 반응형 웹에 많이 사용된다고 한다. 가령 지도 서비스나 주식 차트 제공 등 이런 부분은 웹 소켓을 사용하는 것이 좋다고 한다.
하지만 단점도 명확하다. 프로그램 구현이 보다 복잡해진다. 서버가 소켓이 연결되어 있다고 성능이 개선되는 것이 아니다. 보여줘야 하는 순서 등 고려사항이 증가할 수록 캐시나 메시지 큐를 함께 사용해야 되는데, 개발의 복잡성이 그만큼 증가하게 된다.
그리고 소켓 연결을 유지하는 것 자체가 비용이 든다. CPU 사용량이 증가하고 통신 상태를 체크하거나, 통신 단절 시 예외처리 로직 추가는 개발 비용도 증가시킨다.
그럼에도 불구하고 webSocket의 수요가 증가하는 것은 그만큼 사용자 경험 수준이 높아지면서 데이터 처리량이 증가하고 있다는 반증인듯하다.
함께보면 좋은 블로그
HTTP 정리
WebSocket 정리
네이버 D2 - WebSocket과 Socket.io세상에는 정말 정리를 잘 하시는 분이 많다. 지금은 FA 신분이라 내게 필요한 것들 위주로 빠르게 정리하지만, 좀 더 정리를 잘 하고 싶다.