10. HTTP/2.0

이 책은 8번째 초안을 기반으로 작성되었음

등장 배경

http/1.1 : 구현의 단순성과 접근성 위주

문제 : 회전 지연

응답을 받아야만 요청을 보낼 수 있음

(우회적인) 해결 방법

• 병렬 커넥션

• 파이프라인 커넥션

대안 : 새로운 프로토콜

WAKA

Microsoft S+M (Speed + Mobility)

SPDY (2.0의 기반)

SPDY의 특징

• 헤더 압축 → 대역폭 절약

• 1 TCP 다중 커넥션 (회전지연 줄임)

• 서버 푸시

SPDY에 기반한 HTTP 2.0

프레임

모든 메시지를 담는 수단.

요청 또는 응답이 담겨 있음.

프레임의 종류

• 데이터 (DATA)

• 헤더 (HEADERS)

• 우선순위 (PRIORITY)

• 스트림 리셋 (RST_STREAM)

• SETTINGS, PUSH_PROMISE, ... 등 총 10가지

스트림

한 쌍의 HTTP 요청과 응답을 처리하는 단위.

• 프레임들의 독립된 양방향 시퀸스.

• 하나의 커넥션에 여러 개의 스트림이 있을 수 있으므로 여러 개의 TCP 커넥션을 만드는 효과.

• 여러 요청이 동시에 보내질 수 있고 우선순위도 가질 수 있다.

• 여러 스트림을 사용함으로써 블록되는 것을 방지하기 위해 흐름제어 기법을 사용.

스트림 식별자

한 TCP 커넥션에서 스트림을 식별하는 31비트 필드

• 클라이언트가 만들면 : 홀수

• 서버가 만들면 : 짝수

• 스트림 식별자는 점점 증가해야만 한다.

  • 규칙을 어기면 PROTOCOL_ERROR (커넥션 에러)

• 식별자는 서버와 클라가 협상 없이 독립적으로 만듦

• 한 번 사용한 식별자 재사용 불가

• 식별자가 고갈되면 다시 커넥션 맺음

헤더 압축

HPACK 명세에 따라 압축한 뒤 청크로 전송

받는 쪽에서는 항상 압축을 풀어야만 한다.

압축 콘텍스트

HPACK은 압축을 하고, 해제할 때 압축 콘텍스트라는 것이 변경 됨.

• 각 피어에서 압축을 해제한다고 기대하고 있음.

• 그러므로 헤더를 쓰지 않고 버린다고 하더라도 무조건 압축을 해제해야 함.

• 그럴 수 없다면 COMPRESSION_ERROR (커넥션 에러, 종료)

서버 푸시

어떤 HTML 파일을 요청할 때 서버에서 이 파일이 링크하고 있는 CSS, JS, 이미지 등을 클라이언트에서 요청하기 전에 같이 반환 해줄 수 있음.

PUSH_PROMISE

서버 푸시를 원하고자 할 때 클라의 원 요청을 위해 만들어진 스트림에 전송하는 프레임

• 클라이언트가 서버 푸시하고자 하는 리소스를 요청하기 전에 미리 보내야 함

• 이 프레임을 받으면 클라이언트는 해당 스트림을 예약됨 상태로 만듦.

• 해당 스트림이 닫히기 전까지 서버푸시 대상인 리소스를 요청하면 안 됨.

RST_STREAM

PUSH_PROMISE 프레임을 받은 클라이언트가 서버 푸시를 원치 않을 때 보내는 프레임

• 바로 PUSH_PROMISE 프레임으로 부터 예약된 스트림이 닫히게 됨.

주의점

• 중간의 프록시가 서버 푸시의 의도와는 별개로 원치 않는 전송 / 원치 않는 미전송이 이루어질 수 있음

• 안전하고 캐시 가능하고 본문을 포함하지 않는 요청에 대해서만 푸시 가능

• 푸시할 리소스는 클라이언트가 명시적으로 보낸 것과 연관이 있어야만 함

• 클라는 서버가 푸시한 리소스를 CORS에 따라 검사해야 함. = 다른 origin 에서 온 리소스는 거부해야 함.

• 서버 푸시를 끄고 싶다면 SETTING_ENABLE_PUSH = 0 으로 설정

알려진 보안 이슈

중개자 캡슐화 공격

Intermediary Encapsulation Attacks

2.0 메시지를 프록시가 1.1 메시지로 변환할 때 의미 변질 가능성이 있다.

• 2.0 메시지는 헤더 필드의 이름과 값을 바이너리로 인코딩

  • 이로써 어떤 문자열이든 헤더 필드로 작성할 수 있다

  • 정상적인 2.0 요청/응답을 불법적인 1.1 메시지로 번역되게 할 수 있음

  • 그러나 반대로 1.1메시지는 이를 허용하지 않으므로 불가능

긴 커넥션 유지 = 개인정보 누출 우려

일반적으로, 한 커넥션이 스트림 식별자가 고갈되거나 한 쪽에서 강제로 끊기 전에는 계속 유지됨.

RTT 가 줄어드는 대신 짧은 커넥션이 아닌 경우 (길게 계속 유지되는 경우) 보안 문제가 발생할 수 있음

• 같은 브라우저 내에서, 이전 사용자가 무엇을 했는지 알아낼 수도 있음.