기본적으로 HTTP는 애플리케이션 계층으로서 웹서비스 통신에 사용됩니다. HTTP/1.0 부터 발전해서 현재는 HTTP/3입니다.
HTTP/1.0
한 연결당 하나의 요청을 처리하도록 설계되었습니다. 하지만 한 연결당 하나의 요청을 처리하게되면 RTT 증가를 불러오게 됩니다.
여기서 RTT 란 패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간입니다.(패킷 왕복 시간)
매번 연결 할 때 마다 RTT 가 증가하기 때문에 서버에 부담이 많이가고 사용자 응답시간이 길어졌기 때문에 해결 방법으로 이미지 스플리팅, 코드압축, 이미지 Base64 인코딩을 사용했습니다.
HTTP/1.1
HTTP/1.0 에서 발전한 것으로 매번 TCP 연결을 하는 것 이 아니라 한 번 TCP 초기화를 한 후에 Keep-alive 라는 옵션으로 여러 개의 파일을 송수신 할 수 있게 바뀌었습니다. HTTP/1.0 에도 Keep-alive가 있었지만 표준화 되어있지 않았고 HTTP/1.1부터 표준화가 되어 기본 옵션으로 설정되었습니다.
- 한 번 TCP 3 - way handshake 가 발생하면 그 다음 부터 발생하지 않는 것을 볼 수 있습니다.
HOL Blocking
앞에서 요청한 리소스 개수에 비례해 대기시간이 길어지는데 지현될 때 발생하는 성능 저하 현상을 말합니다.
또한 HTTP/1.1의 헤더에는 쿠키 등 많은 메타데이터가 들어 있고 압축되지 않아 무거웠습니다.
HTTP/2
SPDY 프로토콜에서 파생된 HTTP/1.x 보다
- 지연 시간을 줄이고
- 응답 시간을 더 빠르게 할 수 있으며
- 멀티플렉싱, 헤더압축, 서버푸시, 요청의 우선순위 처리
를 지원하는 프로토콜 입니다.
멀티플렉싱
여러 개의 스트림을 이용하여 송수신합니다.
1. 여러 개의 스트림을 사용하기 때문에 특정 스트림의 패킷이 손실되더라도 나머지 스트림은 정상적으로 동작합니다.
2. 병렬적인 스트림을 통해 데이터를 서빙하고 애플리케이션에서 받아온 메시지를 독립된 프레임으로 조각내어 서로 송수신한 이후 다시 조립하여 데이터를 주고받습니다.
- HTTP/1.1에서 발생하던 HOL Blocking 을 해결할 수 있다.
해더압축
HTTP/1.1 에서 크기가 크던 헤더를 압축. 허프만 코딩 압축 알고리즘을 사용하여 HPACK 압축 형식을 가집니다.
서버푸시
HTTP/1.1 에서는 클라이언트가 서버에 요청해야 파일을 받을 수 있었지만 HTTP/2는 클라이언트 요청 없이 서버가 바로 리소스를 푸시할 수 있습니다.
HTTPS
HTTP/2는 HTTPS 위에서 동작합니다. HTTPs 는 애플리케이션 꼐층과 전송 꼐층 사이에 신뢰 계층인 SSL/TLS 계층을 넣은 신뢰 할 수 있는 HTTP 요청을 의미합니다. 이를통해 통신을 암호화 합니다.
구축방법은
1. CA 에서 구매한 인증키 방식으로 서비스를 구축
2. 서버 앞단의 HTTPS 를 제공하는 로드밸런서를 두거나 서버 앞단에 HTTPS를 제공하는 CDN을 둬서 구축합니다.
HTTP/3
TCP 위에서 돌아가는 HTTP/2 와는 달리 HTTP/3은 QUIC 이라는 계층에서 돌라가며 UDP 기반으로 돌아갑니다. 멀티플렉싱을 가지고 있으며 초기 연결시 기연시간 감소라는 장점이있습니다.
초기 연결시 기연시간 감소하는 이유는 UCP 를 사용하기 때문에 번거로는 3 - way handshake 과정을 거치지 않아도 되기때문입니다.
출처 : 면접을 위한 CS 전공지식 노트 - 지은이 : 주홍철
을 읽고 정리한 내용입니다.
