HTTP 1.1의 동작방식
HTTP는 웹 상에서 클라이언트와 웹 서버간 통신을 위한 프로토콜 중 하나이다. HTTP1.1은 기본적으로 연결 당 하나의 요청과 응답을 처리하기 때문에 동시 전송이 불가능하고 요청과 응답이 순차적으로 이루어지게 된다. 이렇다 보니 HTTP 문서 안에 포함된 다수의 리소스(Image, CSS, Script)를 처리하려면 요청할 리소스 개수에 비례해서 Latency(대기시간)가 길어진다. 이처럼 HTTP 1.1은다수의 리소스를 처리하기에 속도와 성능 이슈를 가지고 있다.
HTTP 1.1의 단점
HOL(Head Of Line) Blocking - 특정응답지연
Web 환경에서 HOLB는 두 종류가 존재한다.
우리의 관심은 HTTP이고 HOLB에 대해 알아보자
HTTP/1.1의 connection당 하나의 요청처리를 개선할 수 있는 기법 중 pipelining이 존재한다. 이것은 하나의 Connection을 통해서 다수 개의 파일을 요청/응답 받을 수 있는 기법이다. pipelining을 통해서 어느정도의 성능 향상을 꾀할 수 있으나 문제점은 여전히 존재한다.
RTT(Round Trip Time) 증가
네트워크 시작 지점에서 대상 지점으로 이동하고 시작 지점으로 다시 이동하는 데 걸리는 시간
앞서 말한 것처럼 http/1.1의 경우 일반적으로 하나의 connection에 하나의 요청을 처리한다. 이렇다 보니 매 요청 별로 connection을 만들게 되고 TCP상에서 동작하는 HTTP의 특성상 3-way Handshake가 반복적으로 일나고 또한 불필요한 RTT의 증가와 네트워크 지연을 초래하여 성능을 저하시킨다.
무거운 Header 구조 ( 특히 Cookie )
http/1.1의 헤더에는 많은 메타정보들이 저장되어있다. 사용자가 방문한 웹페이지는 다수의 http 요청이 발생하는데 이 경우 매 요청시 마다 중복된 헤더 값을 전송하게 되며 또한 해당 domain에 설정된 cookie 정보도 매 요청시 마다 헤더에 포함되어 전송되며 어쩔땐 요청을 통해서 전송하려는 값보다 헤더 값이 더 큰 경우도 비일비재하다.
이러한 문제점들을 해결 하기위한 (퍼포먼스를 향상시키기 위해) HTTP/2가 등장하였다. HTTP/2는 성능 뿐만 아니라 속도면에서도 월등하다. Multiplexed Streams(한 커넥션에 여러 개의 메세지를 동시에 주고 받을 수 있음), Stream Prioritization(요청 리소스 간 의존관계를 설정), Server Push(HTML 문서상에서 필요한 리소스를 클라이언트 요청없이 보내줄 수 있음), Header Compression(Header 정보를 HPACK 압축방식을 이용하여 압축전송)을 사용하여 성능을 획기적으로 향상 시켰다.
"HTTP/2 is a replacement for how HTTP is expressed “on the wire.” It is not a ground-up rewrite of the protocol; HTTP methods, status codes and semantics are the same, and it should be possible to use the same APIs as HTTP/1.x (possibly with some small additions) to represent the protocol. The focus of the protocol is on performance; specifically, end-user perceived latency, network and server resource usage. One major goal is to allow the use of a single connection from browsers to a Web site." - http2 공식 github
즉, 목적은 성능 향상