HTTP/1.1

1999년에 발표된 프로토콜로 텍스트 위주 전송 관리.

사진,동영상등 고용량 멀티미디어 데이터 전송할 일이 많아졌고, 모바일 시장이 엄청 성장함.

→ 새 버전의 http 필요

HTTP/2 개발 과정

구글이 자체적으로 개발한 SPDY이라는 프로토콜을 뼈대로 http/2 개발착수

2012년 IETF에서 http/2 프로토콜의 초안으로 spdy구조를 채택하면서 spdy구조와 유사

spdy는 http를 대체하는 게 아니고 , http전송을 재정의하는 식으로 구현

전송 계층의 구현만 변경하면 http서버프로그램을 spdy에서 그대로 사용가능

차이점

1. Head of line blocking (HOLB)

http/1.1까지는 한 번에 한 파일 보냄. 특정 파일 로딩 늦어지면 병목 생김

→ 병목현상을 head of line blocking이라고 부름 (대충 줄의 선두 작업이 막힌다. 라는 뜻인듯)

http/2에서는 여러 파일을 병렬 전송으로 로딩 시간 줄임.
http/1.1 에 비해 15~50퍼 향상 효과

2. Binary Framing Layer

http메시지가 http/1.1에서는 text로 전송, 2.0에서는 binary frame으로 인코딩되어 전송

http 헤더에서는 헤더와 바디를 /r /n과 같은 개행 문자로 구분

http/2.0 부터는 헤더와 바디를 다른 layer로 처리

• Stream과 Frame 단위

http/1.1에서는 http 요청과 응답은 텍스트 message 단위로 구성

http/2.0에서는 frame, stream단위 추가

• frame - http/2.0에서 통신의 최소 단위. header혹은 data 들어있다.
• message - http/1.1 과 마찬가지로 요청 혹은 응답의 단위이며 다수의 frame으로 이뤄진 배열
• stream - 연결된 connection 내에서 양방향으로 message를 주고받는 하나의 흐름

http/2는 http요청을 여러 개의 frame으로 나누고,
이 frame들이 모여 요청/ 응답 message가 되고,
message는 특정 stream에 속함.
여러 stream이 connection에 속하는 구조

“프레임“ 단위로 이뤄진 “요청과 응답 메시지”는 하나의 “스트림”을 통해 이뤄짐.

이 “스트림”들은 하나의 “커넥션” 내에서 병렬적으로 처리. 커넥션에서 여러 스트림이 병렬 처리되어 빠르다.

스트림은 31비트 unsinged 정수로 된 식별자 가짐 - 클라이언트에 의해 초기화되었다면 식별자는 반드시 홀수, 서버는 짝수로 초기화

→ 식별자로 요청 스트림인지 응답스트림인지 확인

3. multiplexing

http 헤더와 메시지를 바이너리 형태 프레임으로 나누고, 하나의 커넥션으로 동시에 여러개의 메시지 스트림을 응답 순서에 상관없이 주고받는것을 Multiplexing이라고 부른다.

• http/1.1 통신과정

  • 한 tcp커넥션을 통해 요청 보내면, 그에 대한 응답이 도착하고,
    같은 tcp커넥션으로 다시 요청보냄.
    따라서 웹브라우저는 여러개의 tcp커넥션을 만들어 동시 처리하는 방법을 사용한다.
    
  • but, 한 페이지에서 보낼 요청이 수백개에 달하는 요즘 시대에서는 한계 존재

• http/2 통신과정

  • 한 tcp 커넥션에서 여러개의 스트림이 동시에 요청/응답함

  • stream을 통해 요청과 응답이 묶여서 다수 개의 요청을 병렬 처리가능.
    → 응답순서 상관없이 작업 완료되는대로 바로 전달

    https://blog.kakaocdn.net/dn/b7nEZv/btrRo3kn075/YfKfNG45pJl7k9DwXlBrKK/img.gif

3. 중복 헤더 제거

같은 내용의 헤더 보내면, 생략해버리는 식으로 최적화

4. Header compression

이전 http 헤더는 평문이지만, http/2에서는 헤더를 압축해 용량 대비 처리 효율성 증가

5. Server push

특정 파일을 서버에 지정해, http전송시 같이 밀어넣음

javascript, css, 글꼴, 이미지 파일등을 지정함

클라이언트로부터 html 문서 요청하는 하나의 http 메시지 받은 서버는

그 htmll 문서가 링크해 사용하는 이미지, css, js파일등 리소스들을 전부 클라이언트에게 미리 push해 브라우저 캐시에 저장함

https://blog.kakaocdn.net/dn/cmio9u/btrRnElzChU/3y5zSZgQm9xrgkCrnopsd1/img.gif

5. prioritization

• http/1.1

  pipeline기술을 통해 요청 순서대로 처리하는 혁신적인 기술은 결국 HOLB문제에 의해 사장됨.

• http2

  • 웹 페이지 구성하는 파일의 우선순위를 둘 수 있다.

  • 로딩이 빨리되어야하는 파일과 다른 파일 구분 가능 및 중요도 배분
    따라서 리소스간 의존관계(우선순위) 설정해 문제 해결 !

• 부가설명

  • http/2.0에서 메시지가 개별 바이너리 프레임으로 변경되고,
    멀티플렉싱이 가능해지면서 패킷 순서가 엉망이 됨.

  • 따라서 스트림 식별자에 우선순위 지정 트리를 사용해 해결

  • 각 스트림은 1~256까지 가중치 가지고, 하나의 스트림은 다른 스트림에게 명확한 의존성 가짐

HTTP 2.0 문제점- tcp 자체의 문제점들

1. RTT

http는 여전히 tcp사용하므로 tcp 자체의 handshake 지연 발생

2. TCP자체의 HOLB

HTTP2.0 자체는 HOLB문제를 멀티플렉싱을 통해 해결

하지만 tcp는 패킷 신뢰성을 위해 패킷 유실이나 지연시 재전송을 하게되고, 병목이 생기며

결국 tcp프로토콜 자체의 HOLB가 생김

→ application 계층의 HOLB는 multiplexing을 통해 해결햇지만 tcp자체의 HOLB는 어쩔 수 없다

3. 중개자 캡슐화 공격- 바이너리 파일로 인코딩해서 전송하는 문제들

http 2.0은 헤더필드의 이름과 값을 바이너리로 인코딩, http2.0이 헤더필드로 어떤 문자열이든 사용 가능

중간의 proxy 서버가 http2.0 메시지를 http 1.1 메시지로 변환시 메시지를 불법 위조가 가능하다.

• 메시지 위조 과정
  • HTTP/2는 기존 HTTP/1.x와 달리 헤더 필드 값에 대한 엄격한 문자 제한이 없고, 바이너리로 인코딩하기 때문에 공격자가 임의의 데이터를 숨기거나 삽입하기 용이합니다.
  • 특히, 헤더 필드 값에 특수문자나 제어 문자를 포함하는 것도 가능해져서, 이것이 프로토콜을 우회하거나 중간 장비가 해석하기 어렵도록 만들 수도 있습니다.
  • 이런 자유도 높은 데이터 삽입이 가능하면, 공격자가 중간에서 메시지를 캡슐화(encapsulate)해 자신에게 유리하게 바꾸거나 새로운 악의적 메시지를 만들어서 정상 메시지로 위장할 수 있습니다.
• 어떤 문제가 발생하는가?
  • 중간 공격자가 정상 메시지 일부를 숨기고, 나머지 바이너리 데이터를 덧붙이거나 변조해 세션키 협상, 인증서 교환 등 중요한 과정에서 메시지 위조 가능
  • 인코딩 과정에서 해석 차이나 취약점을 이용해 데이터 내용을 바꿔치기할 수 있음
  • 정상적인 검증 과정을 우회하고, 악성 데이터를 삽입하거나 변조된 패킷을 서버나 클라이언트가 수용하게 만들 수 있음

4. 긴 커넥션 유지로 개인정보 유출 - tcp사용하니까 커넥션유지로 인해