[HTTP 완벽가이드] 10장 HTTP/2.0

등장배경

http/1.1은 구현의 단순성과 접근성에 기조를 두고 최적화 되었기 때문에 성능의 희생은 불가피 했다. 

커넥션 하나를 통해서 하나의 요청, 하나의 응답을 받는 메시지 교환 방식은 단순하지만, 회전지연을 피할 수 없었다.

문제를 해결하기 위해서 병렬커넥션, 파이프라인 커넥션이 도입되었지만 근본적 해결책은 아니였다.

 

여러 곳에서 다양한 프로토콜을 제안해왔다. ( 로이필딩의 WAKA, 마이크로소프트의 S+M, 구글의 SPDY 등)

2012년에 SPDY를 기반으로 한 HTTP/2.0을 설계하기로 결정했다.

 

HTTP/2.0

서버와 클라이언트 사이의 TCP커넥션 위에서 동작하고, 커넥션 초기화는 클라이언트이다. 

요청과 응답은 길이가 정의된 한개 이상의 프레임에 담기고, 헤더는 압축되어 담긴다.

서버는 클라이언트에게 필요하다고 생각하는 리소스라면 요청을 명시적으로 받지 않더라도, 능동적으로 클라이언트에게 보낼 수 있다.

요청과 응답 메세지의 의미는 HTTP/1.1과 같도록 유지하고있다. 

 

프레임

HTTP/2.0에서는 모든 메세지는 프레임에 담겨 전송된다.

 

스트림과 멀티플렉싱

스트림은 클라이언트와 서버사이에서 교환되는 프레임들의 독립된 양방향 시퀀스이다. 

한쌍의 HTTP요청과 응답은 하나의 스트림을 통해 이루어진다.

기존에는 하나의 커넥션을 통해 요청을 보내면, 그에대한 응답이 도착하고 나서야 같은 커넥션을 통해서 요청을 보낼 수 있었다.

2.0에서는 하나의 커넥션에 여러개의 스트림이 동시에 열릴 수 있다.

 

우선순위로 메길수 있어,
사용자가 어떤 브라우저를 볼때, 프레임의 전송이 느리다면 웹브라우저는 중요한 리소스를 요청하는 스트림에게 높은 우선순위를 부여할 수있다. 하지만 우선순위는 의무는 아니기 때문에 처리되는 보장은 없다.

 

스트림은 31빝츠의 무부호 정수로 된 고유한 식별자를 갖는다.

클라이언트에 의해 초기화 되었다면 식별자는 반드시 홀수이며, 서버는 짝수여야 한다.

또한 새로 만는 스트림은 기존 스트림 보다 커야하며 이를 어기면 커넥션 에러로 응답 해야한다. 

 

서버와 클라이언트는 스트림은 일방적으로 생성되는데, 협상을 위해 TCP 패킷을 주고받는 시간낭비를 줄여준다.

한번 사용한 스크림 식별자는 다시 사용할 수 없고, 오래된 커넥션은 스트림에 할당할 식별자가 고갈되기도 하지만, 다시 커넥션을 맺으면 된다.

 

동시에 여러개의 스트림을 사용하면 스트림이 블록될 우려가 있지만, window-update 프레임을 이용한 흐름 제어를 통해 망가지는 것을 막아준다.

 

헤더 압축

기존에는 헤더 압축 없이 전송되었다 ( 웹 페이지가 크지 않아서)

최근에는 웹페이지 하나를 보기 위해 많은 요청을 보내기 때문에 영향을 미치게 되었다. 

 

2.0에서 헤더는 HPACK명세에 정의된 압축 방법으로 압축해서 헤더 블록 조각들로 쪼개져서 전송된다.

헤더를 압축하고 해제할 때 압축콘텍스트를 사용하는데, 오동작하지 않으려면 올바른 압축콘텍스트를 유지해야 한다.

 

서버 푸시

서버가 하나의 요청에 대해 응답에 여러개의 리소스를 보낼 수 있도록 한다. 서버가 클라이언트에서 어떤 리소스를 요구할 것인지 미리 알 수 있는 상황에 유용하다

 

알려진 보안 이슈

중개자 캡슐화 공격

2.0메시지를 중간의 프락시가 1.1 메세지로 변환할 때 의미가 변질될 가능성이 있다.

2.0 헤더 필드의 이름과 값을 바이너리로 인코딩 하는데, 이는 헤더필드로 어떤 문자열이든 사용 할 수 있게 되고, 정상적인 요청이나 응답이 위조된 메시지로 번역되는 것을 유발할 수 있다. 

 

긴 커넥션 유지로 인한 개인정보 누출 우려