하루에 한 문제
HTTP1.1 vs HTTP2.0 본문
우선 둘을 비교해보기 전에 HTTP 1.1에 도입된 Persistent Connection과 Pipelining 기법을 알아보자!
1. Persistent Connection
HTTP 통신을 통해 여러 오브젝트를 요청 및 응답해야 하는 경우, HTTP1.0 초기에는 요청때마다 TCP연결을 3-Way handshake 방식으로 맺어야 했다.
즉 5개의 오브젝트를 가진 하나의 웹 사이트가 있다면 클라이언트와 서버 사이에는 5번의 3-Way handshake과정을 통해 TCP 연결을 맺고 끊는 반복적인 작업이 필요했다.
웹의 초창기때는 콘텐츠의 수가 많지 않았기 때문에 부담이 크지 않았지만, 웹 사이트의 콘텐츠가 늘어나면서 TCP 연결의 재사용이 필요하게 되었따. 이때 나온 기술이 바로 Persistent Connection 기술이다. (keep-alive 라고도 한다)
Persistent Connection의 사용을 원하고 이를 지원하는 클라이언트는 다음과 같이 서버에 HTTP메세지를 전달할 때 다음헤더를 추가한다.
Connection : keep-alive
이를 지원하는 서버는 클라이언트의 요청을 받고 TCP연결을 HTTP응답이후에 끊지않고 계속 사용하겠다는 약속으로 동일한 헤더를 HTTP응답에 포함한다.
하지만 HTTP1.1에서는 굳이 Connection 헤더를 사용하지 않아도 모든 요청과 응답은 기본적으로 Persistent Connection을 지원한다. 그래서 필요없을 경우에만 다음과 같은 Connection헤더를 사용한다.
Connection : close
Persistent Connection을 사용하지 말아야 할 경우가 있는데 서버에 연결된 클라이언트의 TCP연결이 계속해서 늘어나면 서버의 자원이 고갈되어 다른 클라이언트들의 접속에 대처할 수 없는 상황이 발생할 수 있다.
따라서 클라이언트의 접속이 제일 잦은 메인페이지와 같은 URL에서는 서버의 가용성을 고려해 Persistent Connection을 사용할지 말지를 고민해봐야 한다.
반대로 장점은 서버의 단일 시간내 TCP연결의 수를 적게해서 자원을 절약할 수 있고 네트워크 혼잡이나, 지연의 경우의 수를 줄일 수 있다. 또한 속도가 빨라진다.
2. Pipelining
HTTP1.1에서 클라이언트와 서버간 요청과 응답의 효율성을 개선하기 위해 만들어진 개념이다.
HTTP Request 들은 연속적으로 발생하며, 순차적으로 동작한다
HTTP/1.1 에서 클라이언트는 각 요청에 대한 응답을 기다리지 않고, 여러개의 HTTP Request 를 하나의 TCP/IP Packet 으로 연속적으로 Packing 해서 요청을 보낸다.
파이프라이닝이 적용되면, 하나의 Connection 으로 다수의 Request 와 Response 를 처리할 수 있게끔 Network Latency 를 줄일 수 있다.
이제 HTTP/1.1의 문제점에 대해 한번 살펴보자.
1. HOL ( Head Of Line ) Blocking - 특정 응답의 지연
예를 들어 Pipelining기능을 통해 (a.png, b.png, c.png)를 받으려고 하는 경우 HTTP의 요청 순서는 아래처럼 된다.
순서대로 첫번째 이미지의 요청을 응답하고 두번째의 요청에 대해 응답을 하는데 만약 a.png에 대한 요청이 지연된다면 b.png, c.png의 요청은 a.png에 대한 응답이 완료될때까지 계속 대기해야한다
2. RTT (Round Trip Time) 증가
HTTP/1.1의 경우 일반적으로 Connection 하나에 요청 한 개를 처리한다. 이렇다보니 매번 요청 별로 Connection을 만들게 되고 TCP 상에서 동작하는 HTTP의 특성상 3-way Handshake가 반복적으로 일어나며, 불필요한 RTT증가와 네트워크 지연을 초래하여 성능을 지연시킨다.
3. 무거운 Header 구조
HTTP/1.1의 헤더에는 많은 메타 정보들이 저장되어 있다. 클라이언트가 서버로 보내는 HTTP 요청은 매 요청 때마다 중복된 헤더 값을 전송하게 되며 서버 도메인에 관련된 쿠키 정보도 헤더에 함께 포함되어 전송된다. 이러한 반복적인 헤더 전송, 쿠키 정보로 인한 헤더 크기 증가가 HTTP/1.1의 단점이다.
개선방법
1. Image Spriting
웹 페이지를 구성하는 다양한 아이콘 이미지 파일의 요청 횟수를 줄이기 위해 아이콘을 하나의 큰 이미지로 만든 다음 CSS에서 해당 이미지의 좌표 값을 지정하여 표시한다.
2. Domain Sharding
요즘 브라우저들은 HTTP/1.1의 단점을 극복하기 위해 여러 개의 Connection을 생성해서 병렬로 요청을 보내기도 한다. 하지만 브라우저 별로 도메인당 Connection 개수 제한이 존재하기 때문에 근본적인 해결책은 아니다.
3.Load Faster
이 방법은 브라우저에서 문서를 어떻게 빠리 로드하는가에 대한 정보다. 아래 글에 자세하게 설명되어 있다.
https://dkwjdi.tistory.com/188
async VS defer
우선 async, defer에 대한 예를 보기 전에 아래의 예를 먼저보자 1. haed 안에 스크립트 포함 Document HTML Parser가 HTML을 파싱하다가 script 태그를 만나면 main.js를 fetching, executing하..
dkwjdi.tistory.com
HTTP/2.0
HTTP/2는 HTTP/1.1을 완전하게 재작성한 것이 아니라 프로토콜의 성능에 초점을 맞추어 수정한 버전이라 생각하면 된다.
Multiplexed Streams
HTTP/2는 Multiplexed Streams를 이용해 Connection한 개로 동시에 여러 개의 메시지를 주고 받을 수 있으며 응답은 순서에 상관없이 Stream으로 주고 받는다. HTTP/1.1의 Persistent Connection, PipeLining의 개선버전이라 할 수있다.
Stream Prioritization
문서 내에 CSS 파일 1개와 이미지 파일 2개가 존재하고 이를 클라이언트가 요청하는 상황에서, 이미지 파일보다 CSS 파일의 수신이 늦어진다면 브라우저 렌더링에 문제가 생기게 된다. HTTP/2에서는 이러한 상황을 고려하여 리소스 간의 의존관계에 따른 우선순위를 설정하여 리소스 로드 문제를 해결한다.
Server Push
서버는 클라이언트가 요청하지 않은 리소스를 사전에 푸쉬를 통해 전송할 수 있다. 이렇게 리소스 푸쉬가 가능해지면 클라이언트가 추후에 HTML 문서를 요청할 때 해당 문서 내의 리소스를 사전에 클라이언트에서 다운로드할 수 있도록 하여 클라이언트의 요청을 최소화할 수 있다.
Header Compression
HTTP/2는 헤더 정보를 압축하기 위해 Header Table과 Huffman Encoding기법을 사용해 처리하는데 이를 HPACK 압축방식이라 부르며 별도의명세서로 관리하고 있다.
참고
https://www.popit.kr/%EB%82%98%EB%A7%8C-%EB%AA%A8%EB%A5%B4%EA%B3%A0-%EC%9E%88%EB%8D%98-http2/
https://seokbeomkim.github.io/posts/http1-http2/