3. HTTP란 무엇이며 어떻게 진화되었는가? - 3

원문 : kamranahmed.info/blog/2016/08/13/http-in-depth/

Journey to HTTP/2 – Kamran Ahmed

 

SPDY - 2009

구글은 웹페이지의 지연 시간을 줄이면서 웹을 더 빠르게 만들고 보안을 향상하기 위해 대체 프로토콜 실험을 시작해서 2009년에 SPDY를 발표했습니다.

 

SPDY는 구글의 상표로 약어가 아닙니다.

 

대역폭을 계속 늘리면 초기에는 네트워크 성능이 올라가지만, 성능은 크게 오르지 않을 때 point가 오는 것으로 파악됐습니다. 그러나 지연 시간으로 같은 작업을 수행하면(즉, 지연 시간을 계속 줄이면 지속적인 성능 향상 효과를 얻을 수 있습니다.) 이는 SPDY 뒤에 숨겨진 성능 향상, 네트워크 성능을 높이기 위한 지연 시간 단축에 대한 핵심 아이디어였습니다.

차이를 모르는 사람들에게 latency는 delay입니다. 데이터가 시작점과 도착점 사이를 이동하는 데 
걸리는 시간(밀리 초 단위)과 대역폭은 초당 전송되는 데이터의 양(초당 비트 수)입니다.

 

다중화, 압축, 우선순위 지정, 보안 등 포함된 SPDY의 기능들은 HTTP/2가 대부분 SPDY에서 영감을 받은 것이라고 말했듯이 다음 섹션에서 HTTP/2의 nitty gritty에 들어가면 알 수 있습니다.

 

SPDY는 실제로 HTTP를 대체하려고 하지 않았습니다. SPDY는 HTTP를 통한 변환 계층이었는데, 그것은 응용 계층에 존재했고, 그것을 전선으로 보내기 전에 요청을 수정했습니다. 그것은 defacto 표준이 되기 시작했고 대다수 브라우저가 이를 구현하기 시작했습니다.

 

2015년 구글에서는 두 가지 경쟁 표준을 원하지 않아 HTTP/2를 만들고 HTTP로 병합하기로 했습니다.

---

HTTP/2 - 2015

여기까지 읽었으면 왜 HTTP 프로토콜의 또 다른 개정이 필요했는지 확신할 수 있을 것입니다. HTTP/2는 콘텐츠의 짧은 지연 시간 전송을 위해 설계되었습니다. HTTP/1.1의 이전 버전과의 주요 특징 또는 차이점은 다음과 같습니다.

 

• 텍스트 대신 이진수
• 다중화 - 단일 연결을 통한 여러 비동기 HTTP 요청
• HPACK를 사용한 헤더 압축
• Server push - 단일 요청에 대한 여러 응답
• Request Prioritization
• 보안

 

 

1. Binary Protocol

HTTP/2는 Binary Protocol로 만들어 HTTP/1.x에 존재했던 지연 시간 증가 문제를 해결하는 경향이 있습니다. Binary Protocol이기 때문에 구문 분석하기가 더 쉽지만, HTTP/1.x와 달리 더 사람의 눈으로 읽을 수 없습니다. HTTP/2의 주요 구성 요소는 프레임과 스트림입니다.

 

프레임 및 스트림

HTTP 메시지는 하나 이상의 프레임으로 구성되어 있습니다. payload에 대한 메타 데이터 및 데이터 프레임에 대한 헤더 프레임이 있으며 HTTP/2 사양을 통해 확인할 수 있는 여러 가지 프레임 유형(헤더, 데이터, RST_STREAM, SETURITY, PRITRIENT 등)이 있습니다.

 

모든 HTTP/2 요청 및 응답에는 고유한 스트림 ID가 부여되며 프레임으로 나뉩니다. 프레임은 이항 데이터 조각에 불과합니다. 프레임 컬렉션은 스트림이라고 불린다. 각 프레임에는 자신이 속한 스트림을 식별하는 스트림 ID가 있으며 각 프레임에는 공통 헤더가 있습니다. 또한, 스트림 ID가 고유하다는 것 외에도, 클라이언트가 시작한 요청은 홀수를 사용하고 서버의 응답은 짝수 스트림 ID를 가지고 있습니다.

 

헤더와 DATA를 제외하고 여기서 주목할만한 다른 프레임 유형은 RST_STREAM으로, 일부 스트림을 중단하는 데 사용되는 특수 프레임 유형입니다. 즉, 클라이언트가 이 프레임을 보내서 내가 더 스트림이 필요하지 않음을 서버에게 알릴 수 있습니다. HTTP/1.1에서 서버가 클라이언트에 대한 응답 전송을 중지하도록 하는 유일한 방법은 연결을 닫는 것이었습니다. 연결은 연속적인 요청에 대해 새로운 연결을 열어야 했기 때문에 지연 시간을 증가시키게 되었습니다. HTTP/2에 있는 동안, 클라이언트는 RST_STREAM을 사용할 수 있고, 연결이 여전히 열려 있고 다른 스트림이 여전히 작동 중일 때 특정 스트림 수신을 중지할 수 있습니다.

 

2. 다중화

HTTP/2는 이제 Binary Protocol이고 위에서 말했듯이 요청과 응답에 프레임과 스트림을 사용하므로 일단 TCP 연결이 열리면 모든 스트림은 추가 연결을 열지 않고 같은 연결을 통해 비동기적으로 전송됩니다. 그리고 차례로 서버는 같은 비동기 방식으로 응답합니다. 즉, 응답은 순서가 없고 클라이언트는 할당된 스트림 ID를 사용하여 특정 패킷이 속하는 스트림을 식별합니다. 이것은 또한 HTTP/1.x에 존재했던 회선 차단 문제를 해결할 수 있습니다. 즉, 클라이언트는 시간이 걸리는 요청을 기다리지 않고 다른 요청을 처리할 것입니다.

 

3. HPACK 헤더 압축

전송된 헤더를 최적화하기 위한 별도의 RFC 일부였습니다. 그것의 본질은 우리가 같은 클라이언트에서 서버에 지속해서 접속할 때 헤더에 계속해서 보내는 중복 데이터가 많고, 때로는 대역폭 사용과 지연 시간을 증가시키는 헤더 크기를 증가시키는 쿠키가 있을 수 있다는 것입니다. 이를 극복하기 위해 HTTP/2는 헤더 압축을 도입했습니다.

 

요청이나 응답과는 달리 헤더는 gzip이나 압축 등의 형식으로 압축되지 않지만, 헤더 압축을 위한 다른 메커니즘이 있는데, 헤더 압축에는 리터럴 값이 Huffman 코드를 사용하여 인코딩되고 헤더 테이블은 클라이언트와 서버에 의해 유지되며 클라이언트와 서버 모두 반복 헤더를 생략합니다(예: 사용자 에이전트 등). 다음 요청에서 두 개 모두로 유지 관리하는 헤더 테이블을 사용하여 해당 요청을 참조합니다.

 

4. Server push

Server push는 HTTP/2의 또 다른 엄청난 기능으로, 클라이언트가 특정 자원을 요구하리라는 것을 알고, 클라이언트조차 요구하지 않고 클라이언트에 밀어 넣을 수 있습니다. 예를 들어, 브라우저가 웹 페이지를 로드한다고 가정해 보자. 페이지 전체를 구문 분석하여 서버에서 로드해야 하는 원격 콘텐츠를 찾아낸 다음, 그 콘텐츠를 얻기 위해 서버에 결과적인 요청을 보냅니다.

 

Server push는 서버가 클라이언트가 요구할 것을 알고 있는 데이터를 밀어줌으로써 라운드 트립을 줄일 수 있도록 합니다. 어떻게 하느냐 하면, 서버는 클라이언트에게 PUSH_PROMISE라는 특별한 프레임을 보내 "이봐, 내가 이 자원을 당신에게 보내려고 해! 나한테 부탁하지 마." PUSH_PROMISE 프레임은 푸시를 발생시킨 스트림과 연결되며, 서버가 푸시할 리소스를 보내는 스트림, 즉 약속된 스트림 ID를 포함하고 있습니다.

 

5. Request Prioritization

클라이언트는 스트림이 열리는 헤더 프레임에 우선순위 정보를 포함해 스트림에 우선순위를 할당할 수 있습니다. 언제든지 클라이언트는 우선순위 프레임을 보내 스트림의 우선순위를 변경할 수 있습니다.

 

서버는 우선순위 정보 없이 비동기적으로 요청을 처리합니다. 스트림에 우선순위가 지정된 경우, 서버는 이 우선순위 정보에 기초하여 요청 처리에 필요한 리소스 양을 결정합니다.

 

6. 보안

HTTP/2에 대해 보안(TLS를 통한)을 의무화해야 하는지에 대해 폭넓은 의견이 있었습니다. 그리고 결국 의무화하지 않기로 했습니다. 그러나 대부분의 vendors는 HTTP/2가 TLS에서 사용될 때만 지원할 것이라고 말했습니다. 그래서 HTTP/2는 specs에 의한 암호화가 필요 없지만 어쨌든 그것은 일종의 기본으로 의무화되었습니다. TLS를 통해 구현될 때 HTTP/2는 일부 요구 사항을 요청합니다. TLS 버전 1.2 이상을 사용해야 하며, 일정 수준의 최소 키 크기, 사용 후 키 필요 등이 있어야 합니다.

 

 

HTTP/2는 이미 SPDY를 넘어섰습니다. HTTP/2는 성능 향상 측면에서 제공할 것이 많으며 이제 우리가 그것을 사용하기 시작해야 할 때입니다.