HTTP - (5) HTTP/2.0

HTTP/1.1은 simplicity와 접근성에 중점을 두고 포맷화되었기 때문에, 성능에 대한 아쉬움이 남아있었다.

커넥션 하나로 응답 하나만 받게 되는 HTTP 메시지 교환방식에 대해 개선에 대한 필요성이 제기되었고,

구글은 SPDY(더 빠른 웹을 위한 실험적인 프로토콜)을 제안하였고, 현재의 HTTP/2.0은 대부분 SPDY의 특징을 유지하고 있다.

​

HTTP/2.0의 길이가 정의된(~16,383byte) 프레임은 request / response를 담는다.

스트림을 통해 전달된 요청/응답은 각각의 스트림이 한쌍의 요청/응답을 담당하게 됨으로써 처리된다.

하나의 커넥션 위에 여러 스트림이 만들어지기 때문에 여러 요청과 응답을 동시에 처리하게 되는 것이다.

우선순위를 부여할 수 있고, 스트림들을 제어할 수도 있다.

​

HTTP/2.0의 메시지는 모두 프레임에 담겨 전송되는데, 프레임은 8byte 헤더로 시작된다. 아래는 헤더의 구성요소이다.

- R : reserved, 2비트 필드, 받는 쪽에서는 값을 무시

- 길이 : payload의 길이를 나타내는 정수

- 종류 : 프레임의 종류

- 플래그 : 8비트, 프레임 종류에 따라 플래그가 다르다

- R : reserved, 1비트, 받는쪽에서 무시

- 스트림 식별자 : 31비트, 0은 커넥션 전체와 연관된 프레임이라는 의미. 클라이언트에서 초기화되었을 경우 홀수, 서버는 짝수.

이전에 만들어진 스트림은, 그 이후에 만들어진 스트림의 식별자 값보다 작아야함

​

HTTP/1.1은 하나의 TCP커넥션에 하나의 응답/요청만 처리할 수 있지만, HTTP/2.0은 하나의 커넥션에 여러 스트림이 열릴 수 있다.

커넥션 내 스트림 식별자는 다시 사용할 수 없기 때문에, 식별자가 고갈되었을 경우 새롭게 커넥션을 맺게 된다.

​

HTTP/1.1은 헤더가 압축없이 그대로 전송되었기 때문에, 헤더의 크기가 지연과 대역폭 모두에 영향을 미치는 변수가 되었다.

HTTP/2.0은 헤더를 압축하게 되는데, 헤더 블록 조각들로 쪼개져 전송한다.

​

HTTP/2.0은 서버가 하나의 응답에 여러 리소스를 전송할 수 있는데, 클라이언트가 어떤 요청을 해올지 미리 알 수 있는 경우 효율적이다.

예를 들어 클라이언트가 HTML 문서를 요청한다면, 그에 담긴 이미지, 자바스크립트 등에 대한 파일들을 요구해올 수 있기 때문에 푸시한다.

이런 경우 클라이언트는 다시 서버로 필요한 리소스를 신청하지 않아도 될 것이다.

​

서버는 클라이언트에게 리소스를 푸시할 것이라는 'PUSH_PROMISE' 프레임을 보내게 되는데, 클라이언트는 이 프레임을 받으면 스트림의 상태를 '예약됨' 상태로 변경한다. 이 상태로 변환되면 클라이언트는 'RST_STREAM'프레임을 보내어 푸시를 거절할 수 있다.

스트림이 닫히게 되면 클라이언트는 서버가 푸시하려고 하는 리소스를 요청할 수 있다.

미리 닫는 이유는 클라이언트가 다시 요청하지 않도록 푸시 자원을 받을 수 있게 준비하는 것이다.

​

​

---

참고도서

https://book.naver.com/bookdb/book_detail.nhn?bid=8509980