HTTP 버전

HTTP 1.0

한 연결당 하나의 요청을 처리한다.

RTT(Round Tip Time, 패킷이 목적지에 도착하고 나서부터 출발지로 돌아오기 전 까지 걸리는 시간 = 패킷 왕복시간)의 증가

TCP - 3 way handshake를 서버로부터 파일을 가져올 때마다 하기 때문에 RTT시간이 증가한다. 

 

RTT 증가를 해결하기 위한 방법 

이를 이미지 스플리팅, 코드 압축, 이미지 BASE 64인코딩을 활용해 해결한다.

 

이미지 스플리팅

많은 이미지를 다운로드받으면 과부하가 걸려 이미지가 합쳐진 하나의 이미지를 다운받고

이를 기반으로 Background 이미지의 Position을 이용해 이미지를 표기한다.

 

코드 압축

코드를 압축해 개행 문자, 빈칸을 없애 크기를 최소화한다.

 

이미지 BASE 64 인코딩

이미지 파일을 64 진법으로 이루어진 문자열로 인코딩한다.

서버와의 연결을 열고 이미지에 대해 서버에 HTTP 요청을 할 필요가 없다.하지만 크기가 더 커지는 문제가 발생한다.

 

인코딩 : 정보의 형태나 형식을 표준화 , 보안, 처리 속도 향상, 저장 공간 절약을 위해 다른 형태나 형식으로 변환하는 처리 방식

 

HTTP 1.1

매번 TCP 연결을 하는 것이 아닌 한 번 TCP 초기화하고 keep-alive라는 옵션으로 여러 개의 파일을 송수신한다.

즉, 한번의 handshake만 일어나고 이후에는 handshake가 다시 일어나지는 않는다. 

1.0에서도 이 기능이 있었지만 표준화가 되지 않았다.

 

단점

문서 안에 다양한 리소스(이미지, css, script)를 처리하려면 요청할 리소스 개수에 비례해 대기시간이 길어진다.

무거운 헤더 구조 : 헤더에 많은 메타데이터가 들어잇다.(쿠키) 그리고 압축이 되어있지 않아 무겁다.

지속  커넥션을 제공함에도 불구하고 데이터를 정기적으로만 가져올 수 있다.

응답 실패시 클라이언트가 모든 리소스에 대한 요청을 처음부터 다시 보내야 한다.

서버에서 평렬 처리 시 응답을 메모리에 적재하고 있어야 한다.(메모리 낭비)

 

HOL Blocking (Head of line blocking)

네트워크에서 같은 큐에 있는 패킷이 그 첫번째 패킷에 의해 지연되는 현상을 의미한다. HOL Blocking은 TCP 환경과 HTTP에서 발생한다. 이 문제때문에 여러개의 TCP 커넥션을 생성해 사용하기도 하였다. 

 

HTTP에서의 HOL Blocking

TCP 연결 상에서 3개의 이미지를 받는 경우 HTTP 요청은 다음과 같다.

|---a.png---|
            |---b.png---|
                        |---c.png---|

 

하나의 요청이 처리되고 응답을 받은 후 다음 요청을 보낸다. 이전의 요청이 처리되지 않았다면 그 다음 요청은 보낼 수 없다. a.png의 요청이 막히면 bc가 빨리 처리될 수 있다 하더라도 a가 끝난 이후에 동작해야 하므로 작업이 지연된다.

|------------a.png------------|
                              |-b.png-|
                                      |---c.png---|

 

HTTP 2.0

SPDY(speedy) 프로토콜에서 파생된 HTTP1.x 보다 지연시간을 줄이고 응답시간을 더 빠르게 한다.

멀티플렉싱 ,헤더 압축, 서버 푸시, 요청의 우선순위 처리를 지원한다.

 

멀티플렉싱

요청과 순서의 응답에 구애받지 않고 병렬적으로 처리할 수 있도록 여러개의 스트림을 사용하여 송수신한다.

특정 스트림의 패킷이 손실되더라도 스트림에는 고유한 식별자가 붙어있어 해당 스트림 외에는 영향을 받지 않는다. 

스트림 내의 데이터는 쪼개져 있고 어플리케이션에서 받아온 메시지를 독립된 프레임으로 조각내어 서로 송수신한 이후 다시 조립해 데이터를 주고받는다. 병렬로 여러 요청을 받을 수 있고 응답을을 줄 수 있다.

 

헤더 압축

HTTP2.0에서는 헤더 압축을 써서 해결한다.

 

서버 푸시

1.1에서는 서버에 요청을 해야 파일을 다운로드 할 수 있었다면, 2는 클라이언트 요청 없이 서버가 바로 푸시한다. 

예시) html파일을 요청하면 html과 css 파일 모두 제공한다. 

 

문제

TCP에서의 HOL Blocking

HTTP의 요청과 응답 방식을 TCP패킷 레벨에서 그대로 생각하면 된다.

TCP는 패킷을 전송할 때 전달을 보장하기 때문에 패킷이 손실되면 재전송 해야한다. 재전송 시에도 패킷의 순서각 역전되지 않도록 후속 패킷이 대기한다. 이 순서에 따라 HOL Blocking이 발생하게 되는 것이다. 

|----packet1----|xxx lost xxx|----packet1----|
                                             |-packet2-|
                                                       |--packet3--|

 

HTTP 3

QUIC (범용 목적의 전송 계층 통신 프로토콜)

순서가 중요한 TCP와 달리 UDP 기반으로 돌아도록한다. UDP는 기본적으로 신뢰성이 없지만, 신뢰성을 가지는 로직을 어플리케이션 계층에 다시 구현을 한다. 

 

독립 스트림 (HOL Blocking문제 해결)

 

HTTP/2

TCP를 이용한 HTTP/2스트림은 하나의 TCP 체인에서 데이터들이 엮여있는 상태로 전송이 이루어진다.

 

두 컴퓨터 사이 두가지 QUIC 스트림

QUIC의 경우 하나의 연결 안에서 데이터 스트림이 각자 다른 Chain을 가진다. 그래서 하나의 Chain에 문제가 생겨도 다른 스트림에는 영향을 주지 않는다.

 

초기 연결 설정시 지연 시간 감소

UDP로 사용하기 때문에 Handshake를 하지 않는다. 클라이언트가 서버에게 어떤 신호를 한 번 주고 서버도 거기에 응답하기만 하면 바로 본 통신을 시작한다.

QUIC는 순방향 오류 수정 메커니즘에 적용된다. 전송한 패킷이 손실되었다면 수신 측에서 에러를 검출하고 수정하는 방식이며 네트워크 환경에서도 낮은 패킷 손실률을 자랑한다. 

 

 

 

출처 :

우테코, CS 전공지식 노트

https://http3-explained.haxx.se/ko/why-quic/why-tcphol

 https://velog.io/@dnr6054/HOL-Blocking