오역, 오탈자는 알아서 필터링 하시길..
# HTTP2 started from SPDY
+ SPDY 는 구글이 진두지휘하여 만들어진 프로토콜이다.
+ HTTPbis 그룹이 http2 작업을 시작할 때라고 결정할 때, SPDY http2의 운용 컨셉을 이미 증명해오고 있었다.
+ http2는 http2 draft-00의 기본토대인 SPDY/3 draft를 약간 수정하여 작업이 시작되었다.
# http2 concepts
+ http2 는 여전히 TCP를 통해 서버로 요청들을 보내고 있는 프로토콜인 HTTP의 패러다임을 유지해야한다.
+ http:// 과 https:// URL은 변경되어져서는 안된다.
+ HTTP1 서버와 사용자는 수십년동안 지속될것이다. http2서버들로 proxy 할수 있어야 한다.
+ 프로토콜의 선택적 옵션을 줄이거나 없앤다.
+ minor 버전은 없다. client들과 서버들의 호환성에 의해 결정된다. 만약 프로토콜의 확장이나 수정이 필요하다면 http3를 발표한다. http2의 마너 버전은 없다.
# http2 for existing URI schemes
+ 앞에서도 언급된 것처럼 URI 스키마는 변경될수없다. 그래서 http2에서는 기존의 스키마를 반드시 사용해야한다.
# Binary
+ http2는 binary 프로토콜이다.
+ http2 binary 는 framing 을 훨씬 쉽게 만든다. frame의 시작과 끝을 찾는것은 text 기반인 http1.1에서 굉장히 복잡했다.
+ framing 으로부터 실제 프로토콜의 부분을 구분하는데 훨씬 쉽게 만든다. http1.1에서는 혼란스럽게 석여있었다.
# The Binary format
+ http2는 binary frame을 보낸다. 동일한 구성을 다른 유형의 프레임 타입들을 사용해 전송할 수 있다.
+ http2에서는 10가지 종류의 프레임 타입이 정의 되어 있다.
# Multiplexed strems
+ 스트림은 http2 connection 내에서 client와 server간에 독립적이고 양방향 통신을 하는 것이다.
+ http2 connection은 동시생성한 다수의 stream을 포함할 수 있고 multiple stream으로부터 하나의 종단점을 분할 할 수 있다.
+ Stream 들은 연결이 수립되고 일방적으로 사용되거나 client와 server에 공유되거나 종단으로 부터 종료될 수 있다.
+ Stream에서 보내지는 순서는 중요하다.
+ 수신처에서 수신한 순서대로 프레임을 처리한다.
+ Stream의 multiplexing은 많은 스트림들이 섞여 동일한 Connection으로 전달된 패키지들을 의미한다
# Priorities and dependencies
+ 각각의 스트림은 가중치를 갖고있다.
+ 가중치는 peer에게 어떤 스트림이 더 중요한지 알리는 역할을 한다.
+ resource의 제한이 있는 경우 서버는 먼저 보내져야 하는 스트림을 선택하여 강제로 보낸다.
+ PRIORITY 프레임을 사용하는것은 client 가 server에게 특정 stream에 의존하는 stream을 알릴 수 있다. 이로인해 client는 parent stream에 완전 의존하는 child stream을 가지는 가중치 tree를 만들 수 있다.
+ 가중치는 실행시간동안 동적으로 변할 수 있다. ( 웹 화면에 뿌려야 하는 이미지 순서가 달라질 수 있음 )
# Header compression
+ HTTP 상태가 없는 프로토콜이다. 짧게 말해서 모든 요청은 서버가 적절한 응답을 하기 위한 자세한 정보를 포함해야 한다. 서버는 이전 요청들에 대한 메티정보나 수많은 정보들을 저장하지 않기 때문이다.
+ http2 이후에도 이러한 구조는 변합이 없다. 기존과 동일하게 동작해야 한다.
+ 이러한 구조는 HTTP 반복을 만든다.
+ 동일한 서버로부터 웹페이지의 이미지와 같은 많은 자원을 client 가 요청할 때, 거의 동일하게 보이는 많은 일련의 요청들이 전송된다.
+ 웹 페이지당 요소들의 숫자가 증가하는 동안, 쿠키의 사용과 request 크기 또한 시간이 지남에 따라 성장하고 있다.
+ 쿠키들은 모든 request에 포함되어 있다. 종종 동일한 쿠키가 다양한 request들에 포함되곤 한다.
+ http1.1의 request 사이즈는 굉장히 커져왔고 초기 TCP 윈도우 보다 커졌다. 그 결과 서버로 부터 ACK 를 돌려받는데 굉장히 시간이 지연되는 현상이 발생했다.
# Compression is a tricky subject
+ HTTPS 와 SPDY 압축은 BREACH, CRIME 공격에 취약점이 드러났다.
+ 알려진 text를 스트림에 주입하고 output이 어떻게 변하는지 알아냄으로 공격자는 암호화된 데이터가 무엇인지 알아낸다.
+ 이러한 취약점으로부터 안전한 프로토콜을 통해 동적인 내용을 압축하는 것은 고려해봐야할 필요가 있다.
+ 다음은 HTTPbis 팀이 권고하는 사항이다
+ HPACK, HTTP/2의 헤더 압축은 http2 헤더들의 압축을 위해서 고안된 압축 포맷이다.
+ internet draft와는 구별되는 특징이 있다.
+ HPACK은 약접이 드러나기 어렵고, 빠르게 decodeing encoding이 가능하고, 수신자가 compression 내용의 사이즈를 조정할 수 있으며, proxy를 통해 re-index이 가능하다.