참고한 자료들
What is HTTP 2.0? How its better than HTTP 1.1?
[10분 테코톡] 🙆♂️아이크의 HTTP 2.0
HTTP 1.0 과 1.1의 차이에 대해 설명해주세요
🌐 HTTP 2.0 소개 & 통신 기술 알아보기
HTTP 2.0 이전까지의 역사
여태까지 배운 내용들은 모두 HTTP 0.9 , HTTP 1.0 , HTTP1.1 에 해당하는 내용들이였다.
여태 배운 내용들을 간략하게 정리해보자
HTTP 0.9
HTTP 0.9 는 1991 년 단순한 텍스트 기반의 프로토콜이였으며
GET 요청만이 가능했고 응답은 HTML 문서의 형태로만 반환되었다.
HTTP 1.0 과 HTTP 1.1 의 차이
GET , POST , HEAD 등 다양한 메소드들이 도입되었고 헤더들과 상태 코드들이 추가되었다.
TCP Connection
HTTP 1.0 은 서버와 클라이언트가 통신을 주고 받을 때 마다 TCP connection 을 맺고 통신을 주고 받으면 커넥션을 끊었어야 했다.
그렇기 때문에 주고 받을 데이터가 많을 수록 맺고 끊는 TCP connection 의 수가 많아지며 오버헤드가 존재했다.
이를 보안하기 위해 나온 HTTP 1.1 에서는 Keep-Alive 라는 헤더와 함께 TCP connection 을 유지시키는 Persistent Connection (지속적 연결) 을 이용하여
한 번 커넥션을 맺은 이후부터 어느 기간 동안엔 커넥션이 유지되도록 하였다.
이에 불필요한 커넥션을 맺고 끊는 오버헤드를 줄일 수 있었다.
Pipe Line
HTTP 는 Stateless 프로토콜로 주고 받는 정보의 문맥과 상관 없이 발신자의 요청을 수신자 처리 하면 된다.
기존 HTTP 1.0 에서는 이런 요청들에 대해 모두 직렬적으로 이뤄졌다.
만약 요청 발신자가 10개의 요청을 보낼 때 첫 번째 요청에 대한 응답을 받아야 두 번째 요청을 받을 수 있었다.
이전 요청에 대한 응답을 받아야 다음 요청을 보낼 수 있었다는 말이다.
하지만 HTTP 1.1 에서는 Pipe Line 이란 기술을 이용해
요청자는 이전 요청의 응답과 상관없이 필요한 요청들을 보낼 수 있다.
이에 응답자 는 우수수 받은 요청들에 대해 순서에 맞춰 응답을 생성하고 응답을 순차적으로 발신한다.
가상 호스팅와 HOST Header
HTTP 1.0 에서는 하나의 서버는 하나의 도메인에 대한 처리만 가능했다.
그 이유는 HTTP 1.0 에는 Host Header 가 존재하지 않았기 때문에 서버는 받는 요청들을 특정 할 수 없어
한 서버가 하나의 도메인만 담당 해야만 했다.
하지만 HTTP 1.1 에서는 Host Header 가 도입되면서 서버는 받는 요청이 어떤 웹 페이지에서 온 것인지에 대해 구별 할 수 있었다.
그렇기에 한 서버가 여러 도메인을 관리하는 가상호스팅이 가능해졌다.
이를 통해 서버 자원을 효율적으로 사용 할 수 있으며 비용 절감에 도움이 되었다.
발달된 캐싱 기술
HTTP 1.0 에서도 캐싱 기술이 가능했지만 HTTP 1.0 에서는 Expires , Last-Modified , Cache-Control , ETag, If-None-Match 헤더가 존재하지 않았기 때문에
캐싱하는 정보의 무결성을 확인하기도 힘들었다.
이에 HTTP 1.0 에선 매우 제한적인 캐싱 활용만이 가능했지만
HTTP 1.1 에서는 다양한 헤더들이 추가되면서 캐싱을 더 효과적으로 활용 할 수 있게 되었다.
청크 전송
청크란 데이터를 나눈 데이터 조각과 나뉜 조각에 대한 정보를 의미한다.
그러니 대용량 데이터를 청크로 나눠 나눠짐에 대한 정보와 나눠진 정보를 전달 하는 방식이다.
HTTP 1.0 에서는 Content-length 헤더를 이용해 보내고자 하는 엔터티 의 사이즈를 나누고 해당 엔터티를 보내주는 방식이였다.
그럼 만약 보내고자 하는 사이즈를 특정 할 수 없는 실시간 스트리밍 이라거나 한 번에 보낼 수 없는 대용량 엔터티라고 하면 어떨까 ?
HTTP 1.0도 여러번 나눠 보낼 수는 있었지만 성능이 매우 저하되었다. 그 이유는 한 번 보내면 TCP Connection 을 또 해줘야 하기 때문에 오버헤드가 심했기 때문이다.
하지만 HTTP 1.1 에서는 한 번에 커넥션으로 여러 개의 응답을 보낼 수 있었기 때문에 대용량 정보들을 나눠서 전송하는 것에 대해 제약이 없었다.
그래서 HTTP 1.1 은 대용량 정보를 나눠서 보낼 수 있도록 Transfer-Encoding: chunked 라는 헤더로 현재 보내는 데이터들은 청크 데이터임을 이야기 하고
보내는 엔터티에는 청크 크기 와 청크 데이터 를 담아 보낸다.
POST /example HTTP/1.1
Host: www.example.com
Transfer-Encoding: chunked
7
Chunked
8
Transfer
6
-Encoding
0예를 들어 위의 경우 Chunked Transfer-Encoding 라는 문자를 나눠 보내는 것이다.
마지막에 청크 사이즈가 0이고 받은 엔터티가 없기 때문에 해당 부분이 청크 데이터의 마지막 부분임을 수신자는 알 수 있다.
HTTP 2.0
HTTP 1.1 은 나온지 30년이 다 되어감에도 불구하고 현재까지도 많이 쓰이는 프로토콜이다.
하지만 몇 가지 단점이 존재했다. 해당 단점을 보완하기 위해 HTTP 2.0 이 2015년 나타났다.
TEXT 에서 Binary frame 으로의 인코딩
HTTP 1.1 에서 요청에 대한 응답들은 헤더와 데이터 본문들이 하나의 TEXT 인 상태로 전송되었다.
그렇기 때문에 HTTP 1.1 에서는 헤더와 바디를 \r , \n 과 같은 개행 문자로 구분했다.
하지만 HTTP 2.0 에서는 우선적으로 헤더와 데이터 부분을 frame 이란 단위로 나눠 전송했으며
통짜 TEXT 에서 binary frame 으로 인코딩하여 헤더와 데이터 압축 된 상태로 응답을 전송한다.
frame 이라는 단위는 아래에서 후술한다.
Stream , Frame 단위
HTTP 2.0 은 TEXT 형식의 기존 요청과 응답을 새로운 단위로 나눠 저장하고 전송한다.
Frame
Frame은HTTP 2.0의 최소 통신 단위이다.Header와Data등을 나누는 단위이다.Message
Message는 다수의Frame들로 이뤄진 배열 라인이다. 그러니HTTP 1.1에서는Header 와 Data부분이 하나의TEXT로 이뤄졌다면HTTP 2.0에서는 여러 개의Frame으로 구성된Message로 나눈다.Stream
HTTP 2.0은 한 요청당 하나의Message를 보내는 것이 아니라 여러 개의Message를 모아 한 번에 보낸다. 그렇게 모인Message의 집합을Stream이라고 한다.
아직 설명하지 않았지만 HTTP 2.0 은 요청과 응답 1회당 여러 개의 Message 가 담긴 Stream 을 보내기 때문에 요청과 응답의 횟수가 줄어든다는 장점이 존재한다.
응답의 병렬 전송 (멀티플렉싱)
HTTP 1.1 의 파이프라인 기술은 요청에 대한 응답 여부와 상관 없이 요청을 보낼 수 있다는 장점이 존재했지만
응답이 요청이 온 순서에 따라 처리 된다는 단점이 여전히 존재했다.
만약 첫 번쨰 온 요청이 시간이 매우 오래 걸리는 요청일 경우에는 시간이 오~래 걸린 후 다음 요청을 처리하게 될 것이다.
하지만 HTTP 2.0 에서는 요청들 순서와 상관없이 응답을 병렬적으로 보낸다.
심지어 병렬적으로 보내는 응답은 하나 하나의 데이터가 아닌, 여러 데이터의 묶음인 Stream 이기 때문에 더 적은 응답 횟수로 더 빠르게 응답을 보내는 것이 가능하다.
이는 HTTP 1.1 에 비해 매우 빠른 응답을 가능하게 했다.
실제 HTTP 1.1 에 비해 HTTP 2.0 의 처리 속도를 빠르면 현저하게 차이나는 모습을 볼 수 있다.
HTTP 1.1 과 HTTP 2.0 의 통신을 비교해보자
HTTP 1.1
HTTP 2.0
이렇게 보니 차이가 더 명확하다.
서버 푸쉬
서버 푸쉬는 응답을 전송하는 입장에서 요청자가 요청하지 않은 정보까지 같이 묶어서 보내는 행위를 말한다.
응답자는 요청자가 특정 데이터를 요구 했을 때, 해당 데이터와 연관되어 있는
예를 들어
index.html을 요청 했을 때index.html과 연동 되어 있는style.css , script.js등
데이터들을 묶어서 보낸다.
츄라이 츄라이
이렇게 되면 요청자 입장에선 파싱 후 어차피 또 보냈어야 하는 데이터들을 미리 받을 수 있기 때문에 데이터 전송이 효율적이다.
Stream Prioritization
HTTP 2.0 에선 여러 데이터를 하나의 Stream 으로 묶어 병렬적으로 보낸다고 하였기 때문에
전송되는 데이터들이 뒤죽 박죽 섞여서 간다거나
요청자가 당장 보기를 원하는 Stream 보다 다른 우선순위가 낮은 Stream 을 먼저 받을 수도 있다.
또 어떤 리소스는 다른 리소스와 강한 의존성을 보이는데 리소스가 도착하는 순서가 뒤죽 박죽이라 패킷이 버려지거나 오류가 발생 할 수도 있다.
이를 해결하기 위해 HTTP 2.0 에서는 병렬적으로 보내되 보내는 Stream 의 우선순위를 지정하고 우선순위가 높은 Stream 부터 전송하는 Stream Prioritization 이 존재한다.
HTTP 2.0 에서는 리소스 별 스트림에 대한 우선순위와 의존성을 고려하는 우선순위 지정 트리 를 사용하여 Stream 별 식별자를 설정해주어 해당 문제를 해결한다 .
우선 순위 지정 트리를 결정하는 것은 요청자이다. (클라이언트) 요청자는 서버에게 필요한 스트림을 보낼 떄 우선순위 지정 트리를 고려하여 스트림을 구성하고 요청을 보낸다.
그럼 응답자 (호스트)는 해당 요청 스트림과 우선순위에 맞춰 전송하면 된다.
이 때 병렬적으로 처리되는 데이터들은 스트림 간 의존성과 우선순위에 맞춰 서로 끼어놓는 식으로 조립된다.
우선순위는 의존성뿐이 아니라 브라우저 사용 양상을 고려하기도 한다.
Header Data Compression
여러 응답을 주고 받다보면 항상 사용되는 헤더들이 존재한다.
이에 HTTP 2.0 은 이전에 보냈던 헤더들과 중복되는 헤더가 존재한다면 동일한 헤더를 보내지 않는다 .
보낸 헤더들은 해쉬테이블과 같은 자료구조에서 관리되며 , 보낸 헤더가 존재하는지 확인한다.
또한 중복되지 않은 헤더 (새로 보내지는 헤더) 또한 호프만 인코딩 기법을 이용해 압축해주었다.
HTTP 2.0 의 단점
Head of Line Blocking
HTTP 2.0 은 TCP 통신을 사용한다.
TCP 통신은 데이터의 무결성을 유지하기 위해서 요청한 packet 들이 모두 문제 없이 잘 도착했는지를 확인하고
만약 중간에 leakage 가 있다면 새로 패킷을 구성하여 재전송한다.
그렇기 때문에 중간에 어떤 packet 이 leakage 된다면 무결성이 해결 될 때 까지 이후의 packet 들은 애플리케이션 레이어로 올라가지 못하고
기다렸다가 애플리케이션 레이어로 올라간다.
이러한 성질은 데이터의 무결성을 유지한다는 장점이 존재하기도 하지만 성능이 저하 될 수 있다 .
이를 해결하기 위해서 HTTP 3.0 이 나왔는데 HTTP 3.0 은 UDP 통신을 이용한다고 하더라
이 책에선 HTTP 2.0 까지만 다루고 있기 때문에 빠르게 진도를 나간 후 HTTP 3.0 까지 확인해보자 :)
공부하면서 궁금한 마음에 유튜브의 네트워크를 확인해 보니 유튜브도
HTTP 3.0프로토콜이더라 !
중간자 캡슐화 공격
만약 HTTP 2.0 을 사용하는 클라이언트와 HTTP 1.1 을 사용하는 호스트가 존재한다고 해보자
HTTP 2.0 은 헤더필드의 이름과 값을 바이너리 인코딩 하기 때문에 헤더 필드에 어떤 문자열이든 사용 할 수 있게 해준다는 것이다.
그렇기 때문에 악의적인 의도를 가지고 보낸 헤더를
HTTP2.0 / HTTP 1.1 사이를 잇는 게이트웨이가 변환 후 보낼 때
문제를 캐치하지 못한다면 문제가 발생 할 수 있다.
HTTP 1.1을HTTP 2.0으로 변환 할 땐 문제가 생기지 않는다.
애초에HTTP 1.1에서는 악의적인 헤더를 담기가 어려우니까 !
긴 커넥션 유지로 인한 개인정보 누출 우려
긴 커넥션 유지로 인해 개인 정보 유출에 악용될 가능성이 존재한다고 한다.
흠 그렇다고 커넥션 유지 시간을 낮추면 UX 가 떨어지지 않나싶다
