HTTP 2.0

타미·2020년 10월 27일
0

Hello CS

목록 보기
1/8
post-thumbnail

HTTP 1.0


요청을 할때마다 connection 연결 (3way), 연결 해지 (4way)

HTTP 1.1

Persistent Connection


연결을 지속한다. 지정된 시간동안 계속 Connection을 맺을 필요없다.
HTTP Keep-alive 속성!

  • TCP에도 Keep-alive 속성이 있다.
    • HTTP : 주어진 시간 안에 요청이 안오면 요청 끝남
    • TCP : 주어진 시간 간격으로 연결 여부를 확인한다. (지속적인 연결)

파이프라인


Queue에 요청을 받아놓는다.
응답이 올때까지 기다리지 않고 바로 요청을 보낼 수 있다.

Head Of Line Blocking


파이프라인에서 파생되는 문제
첫번째 처리가 오래걸리면 그 이후 처리까지 오래걸린다.

HTTP 2.0

  • HTTP 2.0은 기존 HTTP를 대체하는 것이 아니라 확장한다.

    • HTTP의 애플리케이션 의미 체계는 동일하게 유지되며, 제공되는 기능이나 핵심 개념(예: HTTP 메서드, 상태 코드, URI 및 헤더 필드)은 변경되지 않습니다
  • 성능 개선에 초점을 맞추었다.

    1. connection 줄이기 (다중화)
    2. 네트워크 리소스 줄이기 (헤더압축)

Frame, Message, Stream

  • 프레임
    • HTTP 2.0에서의 최소 단위
    • HTTP 1.1 (문자열) -> HTTP 2.0 (binary)
    • header 하나가 프레임 하나, body 하나가 프레임 하나

  • 메세지
    • 요청,응답의 단위
  • 스트림
    • 데이터의 앙뱡향 흐름

프레임이 모여 메세지, 메세지가 모여 스트림

멀티플렉싱

스트림 -> 멀티플렉싱(다중화)
다중화: 하나의 전송로에서 여러 데이터를 요청,응답하는 것

요청과 응답의 병렬처리가 가능하다.

  • head of line blocking 문제 해결
  • 대신 TCP layer상에서는 head of line blocking 여전히 존재한다.
    • 예를 들어 하나의 stream 요청이 느리면 그 뒤에도 막혀버린다.


하나의 Connection에서 데이터 요청과 응답이 가능하다.
대부분의 HTTP 전송은 수명이 짧고 폭주하는 반면 TCP는 수명이 긴 대량 데이터 전송에 최적화되어 있습니다. -> TCP를 잘~사용하게 되었다!


출처: 구글
TLS(SSL) handshake 반복할 필요없다.
그동안 SSL handshake를 계속하고 있었던거군아...

구글 say : HTTP 메시지를 독립된 프레임으로 세분화하고 이 프레임을 인터리빙한 다음, 다른 쪽에서 다시 조립하는 기능은 HTTP/2에서 가장 중요한 기능 향상입니다. 실제로, 이 기능은 모든 웹 기술에 걸쳐 수많은 성능 향상에 파급 효과를 주고 있으며, 다음과 같은 작업이 가능합니다.
프레임으로 나눈 것이 곧 Client 쪽에서 조립할 수 있는 이유이자 다중화할 수 있는 이유라고 하는데, 왜 그런걸까.. 그냥 head+body 같이 보낸다고 다중화가 안되는 이유가 있나?

헤더 압축

기존 (HTTP 1, 1.1) : 중복되는 Header
HTTP 2.0 중복되는 Header 문제 해결

HPACK 압축 방식

  1. 헤더 인덱싱

    중복되는 헤더: 헤더 테이블에 있는 index 값만 내려준다. -> 성능 개선
  2. 인코딩
    중복되지 않는 헤더는 허프만 인코딩한다.

구글 say : 아직까지 나타나지 않은 값에 대해 정적 Huffman 코딩을 사용하고 또한 정적 테이블이나 동적 테이블에 이미 있는 값을 인덱스로 대체하여 각 요청의 크기를 줄일 수 있습니다.
indexing한 걸 인코딩한다는 말이 있는데 아니다!

서버 푸시


기존에는 html 파일에 필요한 자원을 다시 요청했다.
HTTP 2.0에서는 html 파일에 필요한 자원을 서버가 push해준다.

HTTP 3

HTTP 3.0은 QUIC + HTTP 2.0이라고 할 수 있다.

TLS 는 SSL과 똑같다.
그렇다면 QUIC은 HTTPS와 같은 보안을 무조건 지원한다는 건가??!

QUIC

HTTP 3.0을 알기 위해 QUIC을 먼저 알아보자.

UDP

HTTP 1,2에서 사용한 TCP와 달리 비연결형 프로토콜 UDP를 사용한다.


이렇게 미리 connection을 맺지 않고
connection + data를 함께 보내버린다.


출처
대신 UDP의 특성인 신뢰성이 없다는 한계를 QUIC에서 보완하고 있다.

Connection은 식별자로


위에서 한번 연결이 되면 uuid 식별자로 식별한다.
wifi가 바뀌어도 다시 연결할 필요없다?

TLS 기본 설정

TLS가 기본적으로 적용되어서 보안성 향상
HTTPS보면 handshake하는 거 있던데 UDP에서는 어떻게 하는 걸까,, + CA 기관 설정 안한데랑은 통신이 안되나?

독립 스트림

HTTP 2.0에서 TCP layer에서의 head of blocking 해결

참고 자료

아이크 테코톡 쿨라임 테코톡

profile
IT's 호기심 천국

0개의 댓글