[HTTP] HTTP/2.0

 

#1. HTTP/2.0의 등장 배경

HTTP/1.1의 메시지 포맷은 구현의 단순성과 접근성에 주안점을 두고 최적화되었다. 그러다 보니 성능은 어느 정도 희생시키지 않을 수 없었다. 

커넥션 하나를 통해 요청 하나를 보내고 그에 대한 응답 하나만을 받는 HTTP의 메시지 교환 방식은 단순함 면에서는 더할 나위 없었지만 응답을 받아야만 그다음 요청을 보낼 수 있기 때문에 심각한 회전 지연(latency)를 피할 수 없었다. 이 문제를 회피하기 위해 병렬 커넥션이나 파이프라인 커넥션이 도입되었지만 성능 개선에 대한 근본적인 해결책이 되지 못했다.

2009년, 구글은 웹을 더 빠르게 하겠다는 목표 아래 SPDY(스피디) 프로토콜을 내놓았고 이것은 회전 지연을 줄이기 위한 것이었다. 2012년, HTTP 작업 그룹은 SPDY를 기반으로 HTTP/2.0 프로토콜을 설계하기로 결정하고 SPDY의 초안을 그대로 가져와서 HTTP/2.0 초안을 만들기 시작했다.

---

#2. 개요

• HTTP/2.0은 서버와 클라이언트 사이의 TCP 커넥션 위에서 동작한다. 이때 TCP커넥션을 초기화하는 것은 클라이언트이다.
• HTTP/2.0 요청과 응답은 길이가 정의된(최대 16383바이트) 한 개 이상의 프레임에 담긴다. 이때 HTTP헤더는 압축되어 담긴다.
• 프레임들에 담긴 요청과 응답은 스트림을 통해 보내진다. 한 개의 스트림이 한 쌍의 요청과 응답을 처리한다.
• HTTP/2.0은 기존의 요청-응답과는 약간 다른 새로운 상호작용 모델인 서버 푸시를 도입했다. 서버는 클라이언트에게 필요하다고 생각하는 리소스라면 요청을 명시적으로 받지 않더라도 능동적으로 클라이언트에게 보낸다.
• HTTP/2.0은 요청과 응답 메시지의 의미를 HTTP/1.1과 같도록 유지하고 있다. (호환성 유지)
• Content-Length 헤더의 이름은 '.content-length', 404 Not Found는 404 값을 갖고 있는 '.status' 헤더로 문법이 변경되었다.

---

#3. HTTP/1.1과의 차이점

프레임

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

---

스트림과 멀티플레싱

HTTP/1.1에서는 한 TCP 커넥션을 통해 요청을 보냈을 때 그에 대한 응답이 도착하고 나서야 같은 TCP 커넥션으로 다시 요청을 보낼 수 있다. (회전 지연)

HTTP/2.0에서는 하나의 커넥션에 여러 개의 스트림이 동시에 열릴 수 있다. 따라서 하나의 HTTP/2.0 커넥션을 통해 여러 개의 요청이 동시에 보내질 수 있다.

---

헤더 압축

HTTP/1.1에서 헤더는 아무런 압축 없이 그대로 전송되었다. 

HTTP/2.0에서는 메시지의 헤더를 압축하여 전송한다. 

---

서버 푸시

HTTP/2.0은 서버가 하나의 요청에 대해 응답으로 여러 개의 리소스를 보낼 수 있도록 해준다. 예를 들어 HTML 문서를 요청 받은 서버는 그 HTML 문서가 링크하고 있는 이미지, CSS파일, 자바스크립트 파일 등의 리소스를 클라이언트에게 푸시할 수 있을 것이다.

리소스를 푸시하려는 서버는 먼저 클라이언트에게 자원을 푸시할 것임을 PUSH_PROMISE 프레임을 보내 미리 알려주어야 한다. 이 상태에서 클라이언트는 RST_STREAM 프레임을 보내 푸시를 거절할 수도 있다.

서버 푸시를 사용할 때 주의할 점

• 서버는 오직 안전하고, 캐시 가능하고, 본물을 포함하지 않은 요청에 대해서만 푸시할 수 있다.
• 푸시할 리소스는 클라이언트가 명시적으로 보낸 요청과 연관된 것이어야 한다.
• 클라이언트는 반드시 서버가 푸시한 리소스를 동일 출처 정책에 따라 검사해야 한다.
• 서버 푸시를 끄고 싶다면 SETTINGS_ENABLE_PUSH을 0으로 설정하면 된다.

---

#4. 알려진 보안 이슈

중개자 캡슐화 공격(Intermediary Encapsulation Attacks)

HTTP/2.0 메시지를 중간의 프락시가 HTTP/1.1 메시지로 변환할 때 메시지의 의미가 변질될 가능성이 있다. HTTP/1.1과는 달리 HTTP/2.0은 헤더 필드의 이름과 값을 바이너리로 인코딩한다. 이는 HTTP/2.0이 헤더 필드로 어떤 문자열이든 사용할 수 있게 해준다. 이는 정상적인  HTTP/2.0 요청이나 응답이 불법적이거나 위조된 HTTP/1.1 메시지로 변역되는 것을 유발할 수 있다.

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

HTTP/2.0은 사용자가 요청을 보낼 떄의 회전 지연을 줄이기 위해 클라이언트와 서버 사이의 커넥션을 오래 유지하는 것을 염두에 두고 있다. 이것은 개인 정보의 유출에 악용될 가능성이 있다.

---

 

참고 자료

• HTTP완벽가이드, 인사이트