[CN] HTTP의 버전

2023학년도 2학기 충남대학교 이영석 교수님의 컴퓨터네트워크 수업 정리자료입니다.

 

 

 

 

📁 HTTP의 발전

현재는 HTTP/1.1 이상 버전만 사용중이다.
 
 
 
 

📁 HTTP/1.0

HTTP/1.0 버전은 객체를 하나 전송할때마다 GET 메소드 한번, TCP 연결 한번으로 1:1 연결 방식을 사용했다.
 
 
객체는 웹페이지를 이루는 요소들이므로, 위와 같이 연결하게되면 웹페이지 하나에 여러개의 TCP 연결이 사용된다. 이때 TCP 연결을 만드는데 왕복지연시간 문제가 발생하며, non-persistent HTTP라고 부른다.
 
TCP는 서버와 클라이언트를 연결해야하는데, 만약 서버가 바다 건너 있다면 객체 하나를 불러오는데 바다를 한번씩 건너야 해서 전파지연시간이 오래 걸릴 수 있는 것이다.
 
 
 
 
 

📁 HTTP/1.1

위 1.0 버전의 왕복지연시간 문제를 개선하고 성능을 향상시키기 위해, HTTP GET 메소드 처리에 이전 TCP 연결을 재사용하는 방식을 도입하였다. persistent HTTP라고 불린다.

 

 

🌱 지연시간과 Page Load Time(PLT) 관계

 

위 그래프는 대역폭, 아래 그래프는 지연시간을 기준으로 페이지 로드 타임과 어떤 관계가 있는지 나타낸다.
 
대역폭이 길어질수록, 지연시간이 줄어들수록 페이지 로드 시간이 줄어드는건 동일하지만, 대역폭은 5, 6 Mbps 정도가 넘어가면 페이지 로드 속도 개선에 영향도가 떨어진다.
 
즉, 대역폭이 늘어나면 PLT가 줄어든다 는 말은 일부 맞지만, 일정 대역폭 이상에서 PLT를 효과적으로 줄이기 위해서는 지연시간을 감소시키는 것이 핵심이다. 때문에 HTTP/1.1의 개선사항처럼 지연시간을 감소시키는 것이 중요하다.
 
이때 지연시간을 감소시키는 핵심 기술에는 압축과 같은 방식이 존재한다.

 

 
또한 응답을 순차적으로 받지 않고, 객체 요청을 한꺼번에 받는 Pipelining 방식으로 요청도 병렬 전송이 가능하고, 응답도 병렬 처리가 가능하다. 

 

예를 들면 위 그림과 같이 GET 메세지로 HTML과 CSS를 함께 요청하고, HTML과 CSS를 함께 응답받는 식이다.

 

 

 

 

🌱 Keep-Alive 

 

# Response Header

 

HTTP/1.1 200 OK
Connection: Keep-Alive
Keep-Alive: timeout=5, max=1000
...

 

HTTP는 TCP 위에서 동작한다. TCP가 전송이 끝나고 연결이 끊어지면 HTTP도 끊어진다. 이렇게 매번 전송이 끝날때마다 다시 연결을 해야한다면 리소스가 낭비된다.

 

때문에 HTTP/1.0+에서는 위 헤더에서처럼 Keep-Alive 옵션을 사용하여 persistent connection을 맺을 수 있었다.

 

 

HTTP/1.1부터는 기본적으로 keep-alive 방식으로 동작한다.

 
 

 

 

📁 HTTP/2

HTTP/1.1에서는 객체가 1개의 TCP 연결 내에서 순차적으로 전송된다. 이때 동영상이나 폰트와 같은 객체는 용량이 커서 받는 시간이 오래 걸려 병목현상(Head-of-Line, HoL)이 발생할 수 있다.
 
이러한 병목 현상을 해결하고, 웹페이지 로딩시간을 50% 단축하여 웹페이지 성능을 향상시키기 위함을 목표로 개선되었다.
 
 

 

HTTP/2는 TCP 연결 1개 내에서 멀티플렉싱과 우선순위 방식을 도입하여 객체를 섞어서 전달한다. 

 

 

1. Binary Frame

HTTP/1.1까지는 정보를 일반 text 형태 그대로 전달했다면, HTTP/2에서는 데이터를 HEADERS frame과 DATA frame으로 각각 따로 프레임화하여 binary로 인코딩한 후 전달한다. 이렇게 Binary Framing으로 데이터가 바이너리화 되어 전달되면 파싱 및 전송속도가 높고, 오류 발생 가능성이 줄어든다.

 

 

2. Multiplexing

HTTP/1.1의 경우 요청 하나를 보내고 응답을 기다린 후 응답을 받으면 다음 요청을 하는 방식으로 동작한다. 즉 응답이 올 때까지 대기해야하기 때문에, 앞서 요청한 리소스의 응답이 오래 걸리면 대기시간이 오래 걸린다. 그래서 HTTP/1.1은 대기시간을 줄이기 위해 요청한 리소스가 많은 경우 TCP를 여러개 만드는 방식으로 해결하였다.

 

binary framing을 사용하면 리소스를 프레임 단위로 나눌수 있다. 이를 활용하여 HTTP/2는 하나의 TCP 연결 내에 리소스를 쪼개서 요청하고 응답도 쪼개서 받는 Multiplexing(멀티플렉싱)을 도입하였다. 

 

 

3. 우선순위(Stream Prioritization)

리소스 간의 우선순위를 설정하여 수신 순서를 결정한다. 예를 들어 home.html 안에 css 파일 한개와 image 파일 2개가 존재한다고 하자. 클라이언트가 파일을 각각 요청하는데 image파일보다 css파일의 수신이 늦어지는 경우 브라우저의 렌더링이 늦어진다. 이런 문제를 객체에 우선순위를 부여하여 해결한다.

 

4. 흐름제어(Flow Control)

혼잡제어와 대응되는 개념으로, 송신측의 전송량이 수신측의 처리량보다 많은 경우 혼잡 상태를 해결하기 위해 송신측에서 패킷 전송량을 조절하는 기능을 말한다. 원래 TCP 프로토콜 내에 흐름제어 기능이 들어있지만, HTTP/2는 하나의 TCP 연결을 멀티플렉싱해서 사용하기 때문에 TCP의 흐름제어 기능만으로는 충분하지 않다.

 

 

5. Server Push

서버에서 클라이언트가 요청하지 않는 데이터를 미리 보내주는 Server push 기능이 추가되었다. 예를 들어 home.html에 대한 요청이 들어왔을때, 이와 관련된 js및 css파일에 대한 요청이 들어오지 않았어도 함께 보내준다.

 

 

6. 헤더압축

HTTP 헤더를 압축하는 기능을 말한다. Huffman 코드를 사용한 인코딩과 같이 실질적으로 값 자체를 압축하거나, 헤더 전송량을 줄인다. 예를 들어 같은 서버로 요청을 여러번 하게 되면 헤더의 내용이 겹치는 경우가 많다. HTTP/2에서 서버와 클라이언트는 요청에 대한 헤더값과 인덱스를 기억하여, 새로운 요청을 할 때 겹치는 부분은 인덱스만 전송하고, 겹치지 않는 부분의 값만 함께 보내 헤더 전송량을 줄일 수 있다.


 

현재 Apache web server, Nginx, MS IIS, Nodejs, Jetty, Netty 등 많은 웹사이트가 HTTP/2를 사용하고 있으며, 크롬 개발자 도구에서 이를 확인할 수 있다. Protocol 컬럼에서 보이는 h2가 HTTP/2를 사용하고 있음을 나타낸다.
 
HTTP/2는 구글에서 개발하였다.
 

 
 
 

📁 HTTP/3

HTTP/2는 이전 버전의 병목현상(HoL) 해결을 목표로 했지만, 아직 개선될 여지가 남아있었다. TCP의 세그먼트 손실은 HTTP에서 보이지 않기 때문에, HTTP/2의 문제점은 TCP와 연결한다는 것 자체가 문제점이었다.
 
HTTP/3은 위 문제를 해결하기 위해 HTTP 하위 계층에 TCP가 아닌 UDP를 사용한다.
 
 

TLS 1.2+는 암호화 기능을 수행하는 어쩌구로, TCP socket 위에서 작동한다.
 
HTTP/3은 TCP 대신 UDP를 사용하므로 TLS 1.3을 TCP 위에서 작동하는 것 처럼 수행할 수 있는 QUIC과 함께 사용한다. QUIC은 TCP에서는 default 기능이었던 손실 복구 기능 등을 UDP에 구현하는 프로토콜이다.

 

 

 

 

참고

https://velog.io/@18k7102dy/HTTP2-HTTP2%EC%97%90-%EA%B4%80%ED%95%98%EC%97%AC

[HTTP/2] HTTP2에 관하여

https://study-ihl.tistory.com/171

HTTP/1.1, HTTP/2, QUIC

https://ibocon.tistory.com/257

[FE] HTTP/2 - HyperText Transfer Protocol (Version 2) 을 자세히 알아보자