우아한테크코스 4기/프로젝트

HTTP1.0 과 HTTP1.1 과 HTTP2 그리고 QUIC

giron 2022. 9. 8. 09:51
728x90

HTTP 1.0

기존의 HTTP 1.0은 TCP Connection당 하나의 URL만 fetch하며, 매번 request/response가 끝나면 연결이 끊기므로 필요할 때마다 다시 연결해야하는 단점이 있어 속도가 현저히 느리다.

  • 매번 새로운 연결로 성능 저하
  • 서버 부하 비용 증가
  • GET, HEAD, POST의 method가 사용된다.
    • HEAD는 Header의 정보만 전송된다.

HTTP 1.1

  • persistent Connection(keep-alive)
    • 지정한 timeout 동안 커넥션을 닫지 않는다.
    • 기본적으로 keep-alive이고 사용하지 않을 때만 헤더에 ~을추가하여 사용하지 않는다.
  • 캐시를 두어 성능을 향상시켰고 데이터를 압축해서 보낸다.
  • OPTION, PUT, DELETE, TRACE의 method를 사용한다.
  • multiple request에 대한 처리가 가능하고 request/response가 파이프라인 방식으로 진행이 가능하다.
  • 호스트 헤더를 통해서 Virtual Hosting 이 가능해졌다.
    • 한 ip로 여러 도메인을 운영할 수 있다.

keep-alive

keep-alive

파이프라이닝

+ 하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답하여 지연 시간을 줄인다.

파이프라이닝

-하지만 Head of Line Blocking 처럼 1, 2, 3번 순서로 올 때, 1번에서 문제가 발생해 blocking이 생기면 3 요청이 모두 안 가게 되는 문제가 생긴다.

- Header 구조의 중복 request의 헤더에 중복된 값이 들어갈 수 있다.

호스트 헤더

HTTP 1.0 환경에서는 하나의 IP에 여러 개의 도메인을 운영할 수 없었지만 HTTP 1.1 부터 가능하게 된다.

+ HTTP 1.1 에서 Host 헤더의 추가를 통해 비로소 Virtual Hosting이 가능해졌다.

HTTP 2.0

HTTP 2.0

HTTP 1.X는 평문을 사용했지만 2.0부터는 바이너리 포맷으로 인코딩된 Message, Frame 으로 구성된다. 즉, 바이너리로 전달한다!!

메시지 전송 방식의 변화

  • 바이너리 프레이밍 계층 사용 - 파싱, 전송 속도 증가 (바이너리로 전달하므로)
  • Multiplexed Streams: 요청과 응답에 멀티플렉싱이 가능하다. - 바이너리 프레임으로 나누고 잔송받은 쪽에서 다시 조립한다.( 받는 쪽에서 다시 조립하므로 요청과 응답의 순서가 중요하지 않으므로 HOLB해결)
  • Stream Prioritization - 리소스간 우선순위 설정 가능
  • Server push - 클라이언트가 요청하지 않는 리소스도 push 가능하다.
  • Header Compression - 헤더의 크기를 줄인다.(중복 제거) 약 85%
  • HTTP1.X가 결국 지연시켜서 한 번에 요청/응답을 처리하는 방식에서 2.0부터는 각 응답을 멀티플렉싱 즉, frame으로 나누어서 병렬로 처리할 수 있다.

HOLB(HeadOfLineBlocking)

HTTP에서 HOLB 은 처리가 가능했다. 바이너리 프레임으로 전달하므로 병렬적으로 응답받는다.

TCP에서 HOLB 가 HTTP2에서도 문제이다. 패킷이 순서에 맞춰서 가야하기 때문에 앞에가 에러나면 뒤에 페킷도 기다려야한다. 따라서 때에따라 HTTP1.1보다 느릴수있다. 예를 들어, HTTP/2로 다중화된 요청은 TCP에서는 단순한 패킷이므로 패킷이 막히면 전체가 지연되는 문제는 피할 수 없다.

TCP통신의 문제 HOLB

HTTP/2는 TCP를 사용하며 이전 HTTP 버전을 사용할 때 보다 더 적은 TCP 연결을 사용한다. TCP는 신뢰할 수 있는 전송 프로토콜이고 기본적으로 두 머신 간의 가상 체인으로 생각해도 된다. 네트워크의 한쪽 끝에 넣은 것이 최종적으로 다른 쪽 끝에 같은 순서로 나올 것이다.

stream

QUIC & HTTP3 - UDP로 만들어짐(구글이 만듦) - 전송프로토콜

TCP header
UDP header

빠르기도 중요하지만 신뢰성도 중요할 것 같은데 왜 UDP로 전송할까?

  1. tcp는 신뢰성을 확보하지만 지연을 줄이기 힘든 구조 - 패킷 구조상 넣을 게 많다.
    1. 반면에 UDP는 패킷 구조가 작다.
  2. 핸드쉐이크 없이 바로 데이터 주고받고 연결 성공시 설정을 캐싱한다.
    1. connection UUID를 식별자로하여 통신하므로 커넥션 재수립 필요 X없으므로 가능하다
  3. TLS 기본적으로 사용한다. IP SPoofing, 재연공격 방어
  4. 독립된 스트림으로 하나가 끊겨도 다른 하나가 작동하여 병렬 처리한다.
  5. HTTP3

정리

HTTP 1.0

  1. connection하나당 하나의 요청/응답만 받는다.

HTTP 1.1

장점

  1. keep-alive와 파이프라이닝을 통해 해당 문제를 해결한다.
  2. 캐시를 두어 성능을 향상시킨다. 
  3. OPTION, PUT, DELETE 등 다양한 메서드도 지원한다.
  4. host header를 통해 virtual hosting이 가능해졌다.

단점

  1. HOLB로 앞의 패킷이 안가면 뒤의 패킷들도 전송이 지연된다.
  2. 파이프라이닝을 통해 사용하지만 헤더의 중복이 발생한다.

HTTP 2.0

장점

  1. 바이너리 포맷으로 인코딩된 Message, Frame 으로 구성된다.
  2. 패킷을 쪼개어 보내므로 HOLB가 해결이 된다.
  3. 헤더의 중복을 해결했다.

단점

  1. 여전히 TCP기반 통신이라서 데이터 프레임이 도착하지 않으면 지연이 된다.

QUIC

장점

  1. UDP로 통신해서 빠르다. - 패킷의 구조가 작으므로
  2. TLS를 기본적으로 사용한다.
  3. 핸드쉐이크 없이 통신한다.

Nginx에서 http2 적용하기

기존의 http1.1인 상태

server {
    # ssl설정을 해주고, http2를 적어주면 쉽게 설정할 수 있다.
    listen 443 ssl http2;
	...
}

적용 끝이다. 이후, sudo service nginx reload를 하면 아래처럼 http2가 적용되는 것을 확인할 수 있다.

적용후 http2.0

 

Reference

https://tecoble.techcourse.co.kr/post/2021-09-20-http2/

728x90
저작자표시