# Header Compression and Binary Encoding
+ 헤더의 쿠키 크기가 클 경우에 대한 대비책..
+ HTTP/1.1에서는 헤더 정보가 평문으로 전송된다.
+ HTTP/2 에서는 새로운 HPACK 표준에 따라 Single, Multiplexed Connection 헤더는 압축된다.
+ HPACK은 Huffman coding(허프만 부호화)를 사용한다.
+ HEADER는 binary 포맷으로 보내지며, 그로인해 파일 사이즈를 줄여준다.
+ HEADER 압축은 항상 효율적이지는 않다. 헤더의 압축은 CPU오버헤드를 야기한다.
+ 한개의 TCP 패킷에는 압축되지 않은 Header가 적합하다.
+ Response의 경우에는 데이터보다 헤더가 훨씬 더 작아서 헤더 압축의 효과가 더 적다.
+ 압축과 Binary화는 평문의 헤더와 비교해서 디버깅에 어려움을 준다.
+ 더이상 텔넷으로 디버깅할 수 없다. 그러나 WireShark는 HTTP/2를 지원한다.
+ HPACK 압축은, 헤더필드들과 보통의 value들로 알려진 Static Table을 갖고있다.
+ 각각의 값은 index 번호를 갖는다.
+ 헤더 전송이 시작될때, Static Table 에 포함된 value 들은 Text String으로 치환된다.
# Prioritization
+ Single Multiplexed Connection을 가진다는 것은 응답을 받는 순서가 성능에 큰 차이를 만든다는 것이다.
+ HTTP/2 Stream은 숫자 1 ( lowest ) ~ 256 ( highest ) 의 가중치를 가진다,
+ Stream 마다 독립적인 가중치를 가진다.
+ 우선순위 규칙은 서버가 요청받은 파일을 반환하는 순서를 결정하는데 사용된다.
+ 예를들면 가장 효율적인 구현은 CSS Javascript는 이미지 파일보다 더 높은 우선순위를 가지는 것이다.
+ 이와같이 하면 코드파일이 빠르게 다운로드 되어 지연을 방지한다.
+ 독립성과 가중치의 조합은 “prioritization tree로 표현될 수 있다.
+ 서버는 사용자의 우선순위를 지원하기 위해 CPU, 메모리 대역폭을 할당할 수 있다.
+ 마지막 그림이 가장 복잡하다, 먼저 D는 모든 자원을 사용할 수 있다.
+ E, C는 동일하게 자원들을 공유할 수 있다.
+ A, B는 도 공유가 가능하지만 A는 4배더 사용 가능하다
+ 가중치는 Client에 의해 바뀔수 있다.
+ Multiplexing 과 Prioritization 은 다중요청을 병렬적으로 수행할 때 가장 효과적으로 동작한다.
+ 성능을 측정해보면 HTTP/2 장점이 적다는것을 찾을것 같다.
+ 성능 SSL 때문에 더 낮아진다.
+ 수용할 만한 성능이 필요해서 SSL없는 HTTP/1.x 을 사용하는 경우가 많다 .
# SSL Encryption
+ HTTP/2 그 자체로는 SSL이 필요하지 않는다
+ 그러나 최근 브라우저들은 SSL을 사용가능한 HTTP/2를 지원하는 서버의 HTTP/2 만을 지원한다.
+ HTTP/2가 SSL지원이 필요할것같다는 것을 미래 브라우저는 지원한다??? (뭔말이지..)
+ 25%의 인기있는 웹사이트들인 SSL 을 구현했다.
+ SSL과 새로운 Connection들은 비용이 많이 든다.
+ 각각의 연결은 계산집중적인 키의 교환이 일어난다. RSA 2k 공개/비공개 키 쌍이 그 예이다.
+ 그러나 HTTP/2에서는 Initial Connection 에서만 키교환이 필요하다.
+ HTTP/1.x에서는 6~8번의 키교환이 일어난다.
+ 만약 이미 SSL을 사용한다면 Single, Persistent Connection을 지원하는 HTTP/2로 갈아타라
+ HTTP/2가 SSL 오버해드를 감소시켜줄 것이다.
+ 이미 SSL을 사용하고 있지 않는다면 HTTP/2로 옮겨서 SSL을 추가하라
