HTTP/1.0과 HTTP/1.1의 가장 큰 차이는 지속 가능한 연결(keep-alive)을 명시적으로 선언해야 하는가에 있다.
이에 대한 내용을 차근차근히 살펴보자!
웹 초창기에는 다수의 TCP 연결에 대한 고려가 필요 없었다. 사이트에 콘텐츠 수가 그리 많지 않았기 때문이다.
하지만 기술력이 발전하면서 사이트에 콘텐츠 수가 증가하게 되었고 클라이언트와 서버 간의 요청과 응답이 어떻게 하면 빠르게 이루어질 수 있을까에 대한 연구가 진행되었다.
HTTP/1.0과 HTTP/1.1 사이의 Keep-Alive
HTTP/1.0 이후에 클라이언트와 서버 간의 요청과 응답을 어떻게 하면 빠르게 할 수 있을까에 대한 연구가 진행되었다.
대표적으로 아래의 두 가지 기법이 존재한다.
- keep-Alive
- Pipelining
HTTP/1.0 초기에는 클라이언트와 서버 간의 요청의 3-way handshake로 이루어졌다.
3-way handshake는 syn, syn-ack, ack로 이루어진다.
예를 들어 10개의 오브젝트를 가진 웹 페이지가 존재한다면
클라이언트와 서버 사이에 10번의 3-way handshake 과정을 통해 TCP 연결을 맺고 끊는 과정을 반복해야 한다.
HTTP/1.0 기반에서 Persistence Connection을 원하고 이를 지원하는 클라이언트는 서버에게 HTTP 요청 시 아래와 같은 메시지를 헤더에 추가하면 Keep-Alive가 생성된다.
connection:keep-alive
Persistence 커넥션을 지원하는 서버는 클라이언트의 요청을 수용하고 응답 이전까지 TCP 연결을 끊지 않는다.
이때 응답 헤더에도 동일한 헤더를 응답 메시지에 포함시킨다.
HTTP1.1에서도 Keep-Alive를 헤더에 포함시켜야 하는가?
답은 그럴 수도 있고 아닐 수도 있다 이다.
이것의 의미는 HTTP/1.1은 기본적으로 Persistence 커넥션을 지원한다.
만약 응답이후에 TCP 연결을 끊어야 하는 경우에만 해당 헤더를 선언한다.
유의사항
모든 페이지에 Persistence 커넥션을 사용하면 서버 자원을 고갈시키기 때문에 사용할지 말지를 고려해 보아야 한다.
Keep-Alive를 사용하면서 얻을 수 있는 장점은 단일 시간 내의 TCP 연결을 최소화 함으로써 CPU와 메모리 자원을 절약할 수 있고 네트워크 혼잡이나 Latency에 대한 경우의 수를 줄일 수 있다는 점이다.
또한 Keep-Alive는 복수개의 HTTP 요청과 응답을 병렬적으로 동시에 처리하기 위한 HTTP 파이프라이닝 기술을 사용하기 위해서는 꼭 지원되어야 한다.
HTTP/1.0과 HTTP/1.1 사이의 파이프라이닝
HTTP 파이프라이닝은 HTTP/1.1 으로 스펙이 업그레이드 되면서
클라이언트와 서버간 요청과 응답의 효율성을 개선하기 위해 만들어진 개념
HTTP/1.0
HTTP/1.0 에서 HTTP Request 는 소켓에 write 한뒤, 서버의 Response 를 받아 다음 Request 를 보내는 방식으로 웹이 동작한다.
여러 요청에 대해 여러 응답을 받고, 각 처리가 대기되는 것은 Network Latency 에 있어서 큰 비용을 요구한다.
게다게 HTTP/1.0 에서 HTTP 요청들은 연결의 맺고 끊음을 반복하기 때문에 서버 리소스 적으로도 비용을 요구한다.
HTTP/1.1
HTTP/1.1 에서는 다수의 HTTP Request 들이 각각의 서버 소켓에 Write 된 후, Browser 는 각 Request 들에 대한 Response 들을 순차적으로 기다리는 문제를 해결하기 위해 여러 요청들에 대한 응답 처리를 뒤로 미루는 방법을 사용한다.
즉, HTTP/1.1 에서 클라이언트는 각 요청에 대한 응답을 기다리지 않고, 여러개의 HTTP Request 를 하나의 TCP/IP Packet 으로 연속적으로 Packing 해서 요청을 보낸다.
파이프라이닝이 적용되면,
하나의 Connection 으로 다수의 Request 와 Response 를 처리할 수 있게끔 Network Latency 를 줄일 수 있다.
하지만 위의 기법 설명에서 언급하듯이, 결국 완전한 멀티플렉싱이 아닌 응답처리를 미루는 방식이므로 각 응답의 처리는 순차적으로 처리되며, 결국 후순위의 응답은 지연될 수 밖에 없다.
이는 HTTP의 Head Of Line Blocking 이라 부르며 Pipelining 의 큰 문제점이다.
https://jwdeveloper.tistory.com/218
References
https://podo1017.tistory.com/245#recentEntries
https://brunch.co.kr/@sangjinkang/4
'CS > Network' 카테고리의 다른 글
(Network) TCP vs UDP (0) | 2020.05.10 |
---|---|
(Network) SSL 인증서 (0) | 2020.04.28 |
(Network) HTTPS와 SSL 인증서(2) - 공개키 (0) | 2020.04.28 |
(Network) HTTPS와 SSL 인증서(1) - 대칭키 (0) | 2020.04.28 |
(Network) HTTP/1.1 VS HTTP/2 (1) | 2020.04.12 |