10.1 HTTP/2.0의 등장 배경
HTTP/1.1
- 구현의 단순성과 접근성에 주안점, 성능은 어느정도 희생
- 커넥션 하나로 요청 하나를 보내고 그에 대한 응답 하나만을 받는다은 점에서 단순하다.
- 응답을 받아야만 그 다음 요청을 보낼 수 있기 때문에 회전 지연이 심각하다.
- 이 문제를 완화하기 위해 병렬 커넥션이나 파이프라인 커넥션이 도입되었지만 성능 개선에 대한 근본적인 해결책은 되지 못했다.(4장)
성능 개선을 위한 노력
-
WAKA 프로토콜
-
S+M 프로토콜
-
SPDY(스피디) 프로토콜 : made by Google
- 헤더 압축 -> 대역폭 절약
- 하나의 TCP 커넥션에 여러 요청을 동시에 보냄
- 클라이언트가 요청을 보내지 않아도 서버가 능동적으로 리소스를 푸시
=> 이 모든 것이회전지연을 줄이기 위함.
=> 스피디 프로토콜을 기반으로 HTTP/2.0을 설계하게 됨.
10.2 개요
HTTP/2.0
- TCP 커넥션 위에서 동작
- TCP 커넥션 초기화 by 클라이언트
- 요청과 응답은 길이가 정의된 한 개 이상의 프레임에 담긴다.
- 헤더는 압축되어 담긴다.
- 프레임에 담긴 요청과 응답은 스트림을 통해 보내진다.
- 한 개의 스트림이 한쌍의 요청과 응답을 처리한다.
- 여러 개의 요청과 응답을 동시에 처리할 수 있다.
- 스트림에 대한 흐름 제어와 우선순위 부여가 가능하다.
- 서버가 능동적으로 클라이언트에게 리소스를 보낼 수 있다.
10.3 HTTP/1.1과의 차이점
10.3.1 프레임
모든 메시지가 프레임에 담겨 전송된다.
10.3.2 스트림과 멀티플렉싱
- 스트림 : HTTP/2.0 커넥션을 통해 클라이언트와 서버 사이에 교환되는 프레임들의 독립된 양방향 시퀀스.
- 한쌍의 HTTP 요청과 응답이 하나의 스트림을 통해 이루어진다.
- 클라이언트가 새 스트림을 만들어서 HTTP 요청을 보낸다. 요청을 받은 서버는 같은 스트림으로 응답을 보내고, 그러고 나면 스트림이 닫힌다.
- HTTP/2.0은 하나의 커넥션에서 여러 개의 스트림이 동시에 열릴 수 있다. 즉, 하나의 HTTP/2.0 커넥션에서 여러 개의 요청이 동시에 보내질 수 있다.
cf) HTTP/1.1은 한 TCP 커넥션을 통해 요청을 보냈을 때 그에 대한 응답이 도착하고 나서야 같은 TCP 커넥션으로 다시 요청을 보낼 수 있다. 동시에 여러 개의 요청을 보내려면 여러 개의 TCP 커넥션을 만들어야 한다. (파이프라인 커넥션을 사용할 수도 있지만 널리 사용x) - 스트림은 우선순위를 가질 수 있다.
예) 프레임 전송이 느리다면 웹브라우저가 보다 중요한 리소스(이미지 보다는 HTML 페이지)를 요청하는 스트림에게 더 높은 우선순위를 부여할 수 있다. - 서버와 클라이언트는 스트림을 일방적으로 만들기 때문에 스트림을 만들기 위해 서로 협상을 위해 TCP 패킷을 주고 받으며 시간을 낭비할 필요가 없다.
10.3.3 헤더 압축
- HTTP/1.1 : 헤더를 아무런 압축 없이 그대로 전송.
- HTTP/2.0 : 요즘에는 웹페이지 하나에서도 많은 요청이 발생하기 때문에 헤더의 크기가 회전 지연과 대역폭에 실질적인 영향을 미치게 되었다. 따라서 HTTP2.0은 메시지의 헤덜르 압축해서 전달한다.
10.3.4 서버 푸시
서버가 하나의 요청에 대해 응답으로 여러 개의 리소스를 보낼 수 있다. HTML 문서를 요청 받은 서버가 그 문서가 링크하고 있는 이미지, css 파일, 자바스크립트 파일 등의 리소스를 클라이언트에게 푸시하는 상황과 같이 서버가 클라이언트에서 어떤 리소스를 요구할 것인지 미리 알 수 있는 상황에서 유용하다.
10.4 알려진 보안 이슈
10.4.1 중개자 캡슐화 공격
HTTP2.0 메시지를 중간의 프락시(중개자)가 HTTP1.1 메시지로 변환할 때 메시지의 의미가 변질될 가능성이 있다.
10.4.2 긴 커넥션 유지로 인한 개인정보 누출 우려
회전지연을 줄이기 위한 긴 커넥션 유지는 개인 정보의 유출에 악용될 가능성이 있다. ex) 이전에 브라우저를 사용했던 사용자가 무엇을 했는지 알아낼 가능성이 있다.
현재 HTTP가 갖고 있는 문제이기도 하지만 짧게 유지되는 커넥션에서는 위험이 적다.
