HTTP/2의 특징 HTTP/1.1과의 차이에 대해서

고속화 수단의 하나로 주목받고 있는 HTTP/2에 대해서 주요 특징과 HTTP/1.1과의 차이에 대해서 소개하겠습니다. HTTP/2는 HTTP/1.1에 비해 여러가지 최적화가 되어 있습니다.

 

HTTP/2란

---

SPDY라는 프로토콜은 2009년 Google에 의한 웹 고속화 대처의 일환으로 탄생했습니다. SPDY는 종래부터 이용되고 있는 HTTP와 호환성을 유지하면서 세션층을 효율화하는 프로토콜로, 이미 트위터나 페이스북, 일부 대기업 사이트 등이 도입하게 되었습니다.

 

HTTP/2는 이 SPDY의 진화판이라는 위치에서 2015년 5월 IETF(Internet Engineering Task Force)에 의해 사양 책정이 진행되어 RFC화를 완수했습니다. 그 때문에 HTTP/2는 종래의 HTTP와 호환성을 유지하면서 내부적인 효율화가 되고 있습니다.

 

SPDY는 2009년 이후 종종 버전 업을 반복하며 노력해 왔지만 HTTP/2의 사양이 확정되며 SPDY는 향후 모두 HTTP/2로 대체될 것으로 예상됩니다. 구글 Chrome도 이러한 이유로 2016년까지 SPDY 지원을 종료하겠다고 발표했습니다.

 

HTTP/2가 탄생한 이유

SPDY나 HTTP/2는 왜 등장했을까요? 기존 웹 사이트는 지금처럼 콘텐츠가 많지 않았습니다. 그러나 현재는 여러가지 콘텐츠가 전달되고 용량도 많아지고 있어 한번의 액세스로 대량의 리퀘스트를 던지는 것이 당연해졌습니다. 이러한 배경에서 HTTP/1.1에서는 프로토콜 수준에서는 제약이 많아 한계를 맞이했다는 것이 탄생한 큰 이유입니다. 

 

HTTP의 역사

• 1991년 – HTTP/0.9
  GET 메서드만 사용. 헤더도 리스폰스 코드의 규정도 존재하지 않는 간소한 사양
• 1996년 - HTTP/1.0
  RFC1945 공개. 상태 코드를 포함한 리스폰스 헤더가 부가되게 됨. GET 이외에 POST 메서드 등의 새로운 메서드도 추가
• 1999년 - HTTP/1.1
  RFC 2068 공개. Keep-Alive 및 파이프라인화 지원. 1.0부터 대폭 기능 추가
  
• 2015년 – HTTP/2
  RFC7540 공개. HTTP/1.1과의 호환성을 유지하면서 웹 효율화를 위한 다양한 기능 지원

 

 

HTTP/1.1의 결점이란

---

HTTP/1.1의 경우 1개의 요청이 완료될 때 까지 원칙적으로 다음 요청을 보낼 수 없습니다. 웹 사이트에 이미지가 2개 있는 경우, 첫번째의 이미지를 읽은 후 두번째의 이미지를 읽는 비효율적인 통신이 처리됩니다. 이러한 제약을 피하기 위해서 대부분의 모던 브라우저는 1도메인=복수동시접속을 하는 것으로 어느 정도 통신의 다중화를 도모하고 있습니다.

Chrome 등은 동시에 송신하는 리퀘스트는 6개까지로 제한되어 있습니다. 다운로드에 시간이 걸리는 파일은 표준으로는 6개 이상 동시 다운로드를 할 수 없습니다. 

 

HTTP 파이프라인

이처럼 동시 다운로드의 제약이 있는 HTTP/1.1은 HTTP파이프라인 이라는 구조를 이용하여 이전요청의 완료를 기다리지 않고 다음 요청을 전송할 수 있습니다.

 

그러나 파이프라인은 서버 측에서 제대로 대응하지 않으면 브라우저 측의 요청을 제대로 처리할 수 없어 구현에도 문제가 있었습니다. 게다가 HTTP 파이프라인에는 "서버는 요청 순서대로 리스폰스를 반환해야 한다" 라는 제한이 있습니다.

이는 5개 요청 중 첫 번째 요청 처리가 느린 경우, 두 번째 요청은 대기 상태(헤드오브라인 블로킹)가 되어 결과 전체의 속도가 느려지는 과제가 있습니다. 상황이 이렇다 보니 파이프라인은 오페라 브라우저를 제외하고 대부분의 모던 브라우저가 기본으로 OFF 되어 있어 안타깝게도 거의 이용되고 있지 않은 실정입니다.

 

HTTP/1.1로 고속화 하려면

이러한 점에서 HTTP/1.1에서의 고속화는 요청할 수 있는 수를 늘리거나 요청하는 수를 줄이는 것이 중요합니다.

 

리퀘스트를 줄이는 방법

• CSS 스프라이트 (요청 수를 줄일 수 있지만 스프라이트 처리 시간이 걸림)
• 이미지의 인라인화 (이미지 요청 수를 0으로 할 수 있지만 DATA 사이즈가 증가함)
• 웹 글꼴( 요청 수를 줄일 수 있음)

도메인 샤딩

복수의 도메인에 분산하면 도메인 수x6 요청분의 동시 연결 수를 늘릴 수 있습니다. 그러나 비용과 노력이 드는 것이 단점이 될 수 있습니다.

 

 

HTTP/2의 주요 기능

---

스트림의 다중화

HTTP/1.1에서는 리퀘스트와 리스폰스의 세트를 동시에 1개씩 밖에 송수신 할 수 없어서 프로토콜 레벨로 병목현상을 일으키는 보틀넥이 됩니다. HTTP/2에서는 하나의 접속상에 스트림으로 불리는 가상적인 쌍방향 시퀀스를 만드는 것(스트림의 다중화)으로 문제를 극복하고 있습니다.

 

이와 같이 HTTP/2에서는 하나의 커넥션 상에서 병렬로 송수신할 수 있습니다. 따라서 HTTP/1.1 시대에 문제가 되었던 HTTP 파이프라인(HoL 블로킹) 문제를 해결합니다.

스트림에는 아이디가 매겨져 클라이언트 쪽은 홀수, 서버 쪽은 짝수 번호를 할당해 중복을 막고 있습니다.

 

HTTP/2 프레임의 종류

타입	프레임 종류	역할
0	DATA	특정 스트림의 핵심 내용을 전송
1	HEADERS	HTTP 헤더를 포함. 우선순위 포함 가능
2	PRIORITY	스트림 우선순위오 의존성 표시 또는 변경 가능
3	RST_STREAM	엔드포인트가 스트림을 닫도록 허용 (보통 오류가 발생한 경우)
4	SETTINGS	연결 매개변수를 주고받음
5	PUSH_PROMISE	서버가 클라이언트에 무언가를 보내려 한단느 사실을 알려줌
6	PING	연결을 시험하고 RTT를 측정해줌
7	GOAWAY	상대방이 새로운 스트림을 수신했음을 엔드포인트에 알려줌
8	WINDOW_UPDATE	엔드포인트가 얼마나 많은 바이트를 수신할 수 있는지 주고받는다. 흐름제어에 사용
9	CONTINUATION	HEADER 블록을 확장

 

스트림의 우선도

HTTP/2에서는 스트림의 다중화에 의해 차단되는 일은 없어졌지만 마찬가지로 렌더링과 관계없는 리소스는 뒤로 미루기(우선도를 낮추기) 를 할 필요가 있습니다. HTTP/2의 세계에서 말하면 중요한 스트림이 반환을 기다리게 될 가능성이 있다는 것입니다. 이를 해결하기 위해 HTTP/2에서는 클라이언트가 PRIORITY 프레임을 이용해 스트림에 우선순위를 부여하는 것이 가능해졌습니다.

우선순위는 '무게부여'와 '의존관계' 두 가지가 있는데 스트림 A를 다른 스트림보다 우선시 하거나 B와 C의 스트림을 각각 2:5의 가중치를 붙이는 것이 가능합니다.

HTTP/2에서는 페이지 코딩 시에 리소스의 배치장소를 열심히 생각해야 하는데 HTTP/2로 하면 배치는 그대로 하고 우선도만 붙이면 나머지는 프로토콜이 어떻게든 해주는 세계가 될지도 모릅니다.

 

헤더 압축

HTTP/1.1에서 압축이라고 하면 GZIP화해서 CSS나 JS, JSON 등의 텍스트 형식 파일을 줄이는 것을 이미지하기 쉽지만 HTTP/2에서는 여기에 더해 헤더 부분의 압축이 가능합니다. 현재의 웹은 다양한 내용이 헤더에 부여되어 헤더 용량 자체가 방대해진 것에 주목하여 콘텐츠 바디 이외의 헤더도 압축할 필요가 생겼습니다.

HTTP/2 이전의 SPDY 시절에는 헤더도 GZIP으로 압축하였으나 중대한 CRIME이라는 취약성이 발견되었기 때문에 HPACK 이라는 압축 방식으로 변경되었습니다. 

 

플로어 제어

HTTP/2는 새로운 흐름 제어 구조를 실장하고 있습니다. 플로우 제어는 하나의 스트림이 자원을 점유해 버림으로써 다른 스트림이 차단되어 버리는 것을 방지합니다. 플로우 제어구조는 TCP에서도 구현되어 있지만 HTTP/2에서는 스트림 별로 플로우 제어가 가능합니다. 예를들어 대용량 파일 다운로드가 대역을 잠식하고 다른 통신을 방해하는 것을 통제합니다.

 

 

HTTP/2의 대응 상황

---

HTTP/2는 서버측과 클라이언트측이 쌍방 모두 HTTP/2에 대응하고 있지 않으면 효과가 없습니다. 그러나 만일 클라이언트측이 HTTP/2에 대응하지 않았다고 해도 통신을 할 수 없게 되는 것은 아니고, 종래의 HTTP/1.1을 이용한 통신이 가능합니다.

 

웹 사이트측의 확인

웹 사이트가 HTTP/2에 대응하고 있는지 어떤지는 브라우저의 플러그인을 이용하는 것으로써 간단하게 확인할 수 있습니다.

HTTP/2 and SPDY indicator플러그인
(Chrome판 Firefox판)

 

플러그인을 도입하여 사이트에 접속하면 주소창 오른쪽에 번개마크가 표시됩니다.

 

클라이언트측의 대응

 

 

HTTP/2의 혜택을 받을 수 없는 사이트

---

HTTP/2는 1.1에 비해 다양한 효율화가 이루어지고 있지만, 도입한다고 해서 효율이 올라가지 않는 사이트도 있습니다.

• 이미 여러 도메인으로 분산되어 있는 사이트
• 리퀘스트 수나 리소스가 원래 적은 사이트
• 애초에 HTTP 밖에 이용하지 않는 사이트
• 패킷 손실이 많은 사이트

따라서 HTTPS로 많은 콘텐츠를 전달하는 쇼핑사이트나 동시 액세스가 집중되는 사이트는 특히 HTTP/2의 혜택을 받을 수 있습니다.

 

HTTP/2 과제

HTTP/2는 커넥션의 수명이 길어지므로 로드 밸런싱이나 페일오버를 실시할 때의 고려가 필요하게 됩니다. 또한 다중화에 의해 동시 리퀘스트가 가능해졌지만 TCP 레벨에서의 블로킹이 해소된 건 아닙니다. 패킷 손실이 많은 환경에서는 1 개로 한 TCP 커넥션이 반대로 영향을 받아 버리기 때문입니다.

더욱이 HTTP/2에서의 가중치 부여는 현시점에서 각 브라우저에 의해 정의가 통일되어 있지 않기 때문에 아직 검토해야 할 점은 많은 것 같습니다.