HTTP/1.1
HTTP/1.1은 HTTP의 첫 번째 공식 표준 버전으로 GET, POST 외에도 PUT과 DELETE가 생겼다.
또한, 하나의 TCP 연결을 재사용해 많은 콘텐츠를 전달할 수 있는 지속적 연결 기술(keep alive)이 추가 되었다.
HTTP/1.1의 또 다른 특징 중 하나는 파이프라이닝 기술이다.
파이프라이닝은 브라우저가 웹 서버에 여러 개의 콘텐츠를 요청했을 때, 이전 요청에 대한 응답을 완전하게 받지 않더라도 지속적 연결로 확보한 하나의 TCP 연결 내에서 미리 다음 요청에 대한 처리를 시작하면서 전체적인 전달 시간을 줄이는 방식이다.
Persistent Connection(Keep alive connection)(영속적인 커넥션)
영속적인 커넥션은 얼마간 연결을 열어놓고 여러 요청에 재사용함으로써, 새로운 TCP 핸드셰이크를 하는 비용을 아끼고, 성능 향상에 기여할 수 있다.
커넥션이 영원히 열려있는 것은 아니며, 특정한 시간이 지나면 닫히게 된다.
(서버는 Keep-alive 헤더를 사용해서 연결이 최소한 얼마나 열려있어야 할 지를 설정할 수 있다.)
물론, 영속적인 커넥션도 단점을 가질 수 있다.
실제로 데이터를 보내지 않는 상황에서도 통신을 열어서 유지해야 하기 때문에 서버 리소스를 소비하게 된다.
HTTP/1.0 커넥션은 기본적으로는 영속적이지 않지만, Connection을 close가 아닌 다른 것으로, 일반적으로 retry-after로 설정하면 영속적으로 동작한다.
반면, HTTP/1.1은 기본적으로 영속적이다.
HTTP 파이프라이닝
HTTP 파이프라이닝이란 HTTP1.1 로 스펙이 업그레이드 되면서 클라이언트와 서버간 요청과 응답의 효율성을 개선하기 위해 만들어진 개념이다.
HTTP Request 들은 연속적으로 발생하며, 순차적으로 동작한다.
HTTP/1.0 에서 HTTP Request 는 소켓에 write 한뒤, 서버의 Response 를 받아 다음 Request 를 보내는 방식으로 웹이 동작한다.
여러 요청에 대해 여러 응답을 받고, 각 처리가 대기되는 것은 Network Latency 에 있어서 큰 비용을 요구한다.
게다게 HTTP/1.0 에서 HTTP 요청들은 연결의 맺고 끊음을 반복하기 때문에 서버 리소스 적으로도 비용을 요구한다.
HTTP/1.1 에서는 다수의 HTTP Request 들이 각각의 서버 소켓에 Write 된 후, Browser 는 각 Request 들에 대한 Response 들을 순차적으로 기다리는 문제를 해결하기 위해 여러 요청들에 대한 응답 처리를 뒤로 미루는 방법을 사용한다.
즉, HTTP/1.1 에서 클라이언트는 각 요청에 대한 응답을 기다리지 않고, 여러개의 HTTP Request 를 하나의 TCP/IP Packet 으로 연속적으로 Packing 해서 요청을 보낸다.
파이프라이닝이 적용되면, 하나의 Connection 으로 다수의 Request 와 Response 를 처리할 수 있게끔 Network Latency 를 줄일 수 있다.
하지만 위의 기법 설명에서 언급하듯이, 결국 완전한 멀티플렉싱이 아닌 응답처리를 미루는 방식이므로 각 응답의 처리는 순차적으로 처리되며, 결국 후순위의 응답은 지연될 수 밖에 없다.
HTTP 파이프라이닝은 모던 브라우저에서 기본적으로 활성화 되어 있지 않다.
HTTP/2.0의 등장
HTTP/1.1의 메시지 포맷은 구현의 단순성과 접근성에 주안점을 두고 최적화되었다.
그러다 보니 성능은 어느 정도 희생시키지 않을 수 없었다.
커넥션 하나를 통해 요청 하나를 보내고 그에 대해 응답 하나만을 받는 HTTP의 메시지 교환 방식은 단순했지만, 응답을 받아야만 그다음 요청을 보낼 수 있기 때문에 심각한 회전 지연(latency)을 피할 수 없었다.
때문에 더 효율적이고 빠른 HTTP가 필요했고 이러한 요구에 만들어진 것이 구글의 SPDY 프로토콜이다.
텍스트 방식의 프로토콜 메시지를 과감히 버리고 이진 포맷을 사용하면서 프로토콜 자체를 경량화하고자 했던 첫 시도이다.
이후 HTTP working group은 SPDY 프로토콜에 몇 가지 보안성을 보완해 새로운 정식 HTTP 버전을 제안했고, 이것이 HTTP/2이다.
HTTP/2.0은 서버와 클라이언트 사이의 TCP 커넥션 위에서 동작한다.
이때 TCP 커넥션을 초기화하는 것은 클라이언트이다.
HTTP/2.0 요청과 응답은 길이가 정의된 (최대 16383 (2^14 - 1) 바이트) 한 개 이상의 프레임에 담긴다. 프레임들에 담긴 요청과 응답은 스트림을 통해 보내진다. 한 개의 스트림이 한 쌍의 요청과 응답을 처리한다. 하나의 커넥션 위에 여러 개의 스트림이 동시에 만들어질 수 있으므로, 여러 개의 요청과 응답을 처리하는 것 역시 가능하다.
HTTP/2.0은 이들 스트림에 대한 흐름 제어와 우선순위 부여 기능도 제공한다.
HTTP/2.0은 기존의 요청-응답과는 약간 다른 새로운 상호작용 모델인 서버 푸시를 도입했다. 이를 통해 서버는 클라이언트에게 필요하다고 생각하는 리소스라면 그에 대한 요청을 명시적으로 받지 않더라도 능동적으로 클라이언트에게 보내줄 수 있다.
HTTP/1.1과의 차이점
1. 프레임
HTTP/2.0에서 모든 메시지는 프레임에 담겨 전송된다. 모든 프레임은 8바이트 크기의 헤더로 시작하여, 뒤이어 최대 16383 바이트 크기의 페이로드가 온다.
2. 스트림과 멀티플렉싱
한 쌍의 HTTP 요청과 응답은 하나의 스트림을 통해 이루어진다. 클라이언트는 새 스트림을 만들어 그를 통해 HTTP 요청을 보낸다. 요청을 받은 서버는 그 요청과 같은 스트림으로 응답을 보낸다. 그러고 나면 스트림이 닫히게 된다.
HTTP/1.1에서는 한 TCP 커넥션을 통해 요청을 보냈을 때, 그에 대한 응답이 도착하고 나서야 같은 TCP 커넥션으로 다시 요청을 보낼 수 있다. 따라서 웹브라우저들은 회전 지연을 줄이기 위해 여러 개의 TCP 커넥션을 만들어 동시에 여러 개의 요청을 보내는 방법을 사용한다. 그러나 그렇다고 TCP 커넥션을 무한정 만들 수는 없기에 한 페이지에 보내야 할 요청이 수십개에서 수백개에 달하는 오늘날에는 회전 지연이 늘어나는 것을 피하기 어렵다.
HTTP/2.0에서는 하나의 커넥션에 여러 개의 스트림이 동시에 열릴 수 있다. 따라서 하나의 HTTP/2.0 커넥션을 통해 여러 개의 요청이 동시에 보내질 수 있기 때문에 HTTP/1.1에서의 문제는 쉽게 해결 될 수 있다. 뿐만 아니라 스트림은 우선순위를 가질 수 있다. (그러나 이 우선순위에 따르는 것은 의무사항이 아니기 때문에, 요청에 우선순위대로 처리된다는 보장은 없다.)
3. 헤더 압축
HTTP/1.1에서 헤더는 아무런 압축 없이 그대로 전송되었다. 과거에는 웹페이지 하나를 방문할 때의 요청이 많지 않았기 때문에 헤더의 크기가 큰 문제가 되지는 않았다. 하지만, 요즘 웹페이지 하나를 보기 위해서는 수십, 수백 번의 요청을 보내기 때문에 헤더의 크기가 회전 지연과 대역폭 양쪽 모두에 실질적인 영향을 끼치게 된다.
이를 개선하기 위해 HTTP/2.0에서는 HTTP 메시지의 헤더를 압축하여 전송한다.
HTTP/2는 클라이언트와 서버 사이에 가상 테이블을 만들어서 동일하고 중복되는 헤더 값들을 테이블에 저장하고 참고하는 방식으로 중복 전달을 제거한다.
가상 테이블은 정적 테이블과 동적 테이블로 나눌 수 있는데, 정적 테이블에는 미리 정의된 자주 사용되는 헤더 필드를 저장한다. 동적 테이블에는 클라이언트와 서버가 주고 받은 값들을 업데이트한다.
또한, 헤더 압축 알고리즘인 HPACK을 사용해 허프만 알고리즘 방식으로 헤더를 압축한다.
4. 서버 푸시
HTTP/2.0은 서버가 하나의 요청에 대해 응답으로 여러 개의 리소스를 보낼 수 있도록 해준다. 이 기능은 서버가 클라이언트에서 어떤 리소스를 요구할 것인지 미리 알 수 있는 상황에서 유용하다.
예를 들어, HTML 문서를 요청 받은 서버는 그 HTML 문서가 링크하고 있는 이미지, CSS 파일, 자바스크립트 파일 등의 리소스를 클라이언트에게 푸시할 수 있을 것이다. 이는 클라이언트가 HTML 문서를 파싱해서 필요한 리소스를 다시 요청하여 발생하게 되는 트래픽과 회전 지연을 줄여준다.
HTTP를 공부하는데 정말 미지의 세계인 것 같다.
용어가 어려워서 계속 찾아본다고 시간을 많이 소비한 것 같다.
네트워크 계층의 중요성을 다시금 깨닫게 되는 공부였다...
