HTTP (HyperText Transfer Protocol)

Hee Suh·2024년 4월 27일
computer sciencehttp네트워크
0

[CS] Network

목록 보기
4/8
post-thumbnail

Overview of HTTP

HyperText Transfer Protocol

  • 웹의 애플리케이션 계층 프로토콜
  • client/server model client/server model
  • stateless HTTP 서버는 클라이언트에 대한 정보를 유지하지 않으므로, HTTP를 무상태 프로토콜이라고 한다.

Evolution of HTTP

HTTP 1.0

Non-persistent HTTP 비지속 연결

Non-persistent HTTP

Non-persistent HTTP response time =  2RTT + file transmission time

* RTT (Round Trip Time): 작은 패킷이 클라이언트에서 서버로 갔다 오는 왕복 시간

❗ issues

  • 각 요청 객체에 대해 새로운 TCP 연결이 설정되고 유지되어야 한다.
    TCP 버퍼가 할당되어야 하고 TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야 하므로, 수많은 클라이언트들의 요청을 동시에 서비스하는 웹 서버에게 심각한 부담을 줄 수 있다.
  • 각 객체는 2 RTT를 필요로 한다. (TCP 연결 설정에 1 RTT, 객체를 요청하고 받는 데 1 RTT)

HTTP 1.1

Persistent HTTP 지속 연결

서버는 응답을 보낸 후에 TCP 연결을 그대로 유지한다. 같은 클라이언트와 서버 간의 이후 요청과 응답은 같은 연결을 통해 보내진다. (default Connection: keep-alive header)

HTTP/1.1에서 도입된 pipelining을 통해 단일 TCP 연결을 통해 대응되는 응답을 기다리지 않고 여러 HTTP 요청을 보냄으로써, 웹 페이지 로딩 시간 성능을 개선했다.

출처: https://engineering.cred.club/head-of-line-hol-blocking-in-http-1-and-http-2-50b24e9e3372

ℹ️ HTTP 파이프라이닝은 모던 브라우저에서 기본적으로 활성화되어있지 않다.

  • 버그가 있는 프록시들이 여전히 많은데, 이들은 웹 개발자들이 쉽게 예상하거나 분석하기 힘든 이상하고 오류가 있는 동작을 야기한다.
  • 파이프라이닝은 정확히 구현해내기 복잡하다.
    전송 중인 리소스의 크기, 사용될 효과적인 RTT, 그리고 효과적인 대역폭은 파이프라인이 제공하는 성능 향상에 직접적으로 영향을 미친다. 이런 내용을 모른다면, 중요한 메시지가 덜 중요한 메시지에 밀려 지연될 수 있다. 중요성에 대한 생각은 페이지 레이아웃 중에도 진전된다. 그러므로 파이프라이닝은 대부분의 경우 미미한 수준의 향상만을 가져다 준다.
  • 파이프라이닝은 HOL 문제에 영향을 받는다.

❗ HOL (head-of-line) blocking issue
하나의 (느린) 오브젝트가 다른/따라오는 오브젝트의 진행을 방해해서 웹 성능이 저하되는 문제

  • HTTP HOL Blocking (Application Layer)
                        |------------a.png------------|
            |-b.png-|
|---c.png---|
  • TCP HOL Blocking (Transport Layer)
                          |----packet1----|xxx lost xxx|----packet1----|
            |-packet2-|
|--packet3--|

💡 Domain Sharding
여러 개의 병렬 TCP 연결을 동시에 생성해, 여러 subdomain을 이용하여 여러 리소스를 한 번에 다운로드하는 기술이다.
HTTP/1.1에서 domain sharding을 이용하여 HOLB를 해결해왔으나, 도메인의 주소를 찾기 위해 DNS Lookup 과정에서 시간을 잡아먹을수도 있으며, 브라우저별로 Domain당 Connection 개수의 제한(Chrome은 max 6개)이 존재하여 근본적인 해결책은 아니었다.

HTTP 2.0

⭐️ HTTP/2 주요 목표: 하나의 TCP 연결상에서 멀티플렉싱 요청/응답 지연 시간을 줄이는 데 있다.

  • Binary protocol
    텍스트로 작성된 메시지로 구성된 HTTP/1.1과 달리, HTTP/2는 binary protocol을 사용한다. 파싱을 단순화하고 에러를 줄이면서 클라이언트와 서버 간 통신을 더 효율적이게 만들었다.
    출처: https://hpbn.co/http2/
    HTTP/2는 각 메시지를 독립적인 프레임으로 쪼개고, 다른 쪽 끝에서 다시 조립할 수 있도록 한다. 또한 프레임을 바이너리 인코딩한다.
    Frame < Message < Stream

    • Frame: HTTP/2에서 최소 통신 단위이며, Header 혹은 Data 둘 중 하나다.

    • Message: HTTP/1.1과 마찬가지로 요청 혹은 응답의 단위이며, 다수의 Frame으로 이루어져있다.

    • Stream: 클라이언트와 서버 사이에 설정된 연결을 통해 양방향으로 주고받는 하나 이상의 메시지다.

      출처: https://hpbn.co/http2/

  • Multiplexing, 다중화
    HTTP/2의 새로운 바이너리 프레이밍 레이어를 이용하여, 하나의 TCP 연결로 동시에 여러 개의 스트림을 응답 순서에 상관 없이 주고 받는 것을 의미한다.
    Cf. HTTP/1.1 은 하나의 TCP 연결 상에서 여러 파이프라인 구조의 GET을 보내며, HOLB 문제를 야기했으나, HTTP/2로 전환하면 네트워크 지연 시간이 줄어들 뿐만 아니라 처리량이 개선되고 운영 비용이 절감된다.
  • Server Push
    HTTP/2는 클라이언트가 요청하기 전에 서버가 클라이언트에 콘텐츠를 "push"할 수 있다.
    ❗️HTTP/2 서버 푸시는 Chrome에서 더 이상 지원되지 않는다. 서버 푸시의 대안으로는 103 Early Hints과 Preloading이 있다.
  • Stream Prioritization
    HTTP/2는 각 스트림, 즉 요청과 응답에 우선순위를 매겨서, 서버는 가장 높은 우선순위의 요청을 위한 프레임을 제일 먼저 보낼 수 있다. 이는 HTML이나 주요 스크립트와 같은 중요 자원들이 높은 우선순위를 받아서, 먼저 도착하는 것을 보장하고 사용자 경험을 향상시킬 수 있다는 것을 의미한다.
  • Header Compression
    작은 파일은 큰 파일보다 더 빨리 로드된다. 웹 성능 속도를 높이기 위해 HTTP/1.1 및 HTTP/2는 모두 HTTP 메시지를 압축하여 더 작게 만든다. 그러나 HTTP/2는 HTTP 헤더 패킷에서 중복 정보를 제거하는 HPACK이라는 고급 압축 방법을 사용한다. 이렇게 하면 모든 HTTP 패킷에서 몇 바이트가 제거된다. 단일 웹 페이지를 로드하는 데 관련되는 HTTP 패킷의 양을 고려할 때, 이러한 바이트는 빠르게 합산되어 로드 속도가 빨라진다.

❗ issues

  • TCP HOC(Head of line) blocking
  • no security over vanilla TCP connection

HTTP 3.0 (QUIC)

QUIC(Quick UDP Internet Connections, 빠른 인터넷 연결)

QUIC은 UDP 프로토콜 위에 구현한 트랜스포트 계층 프로토콜이다.

출처: https://web.eecs.umich.edu/~xumiao/docs/imc23-quic-poster.pdf

  • HTTP over TCP + TLS

    • TCP (reliability, congestion control state) + TLS (authentication, crypto state)
    • 2 serial handshakes
  • HTTP over QUIC
    • QUIC: reliability, congestion control, authentication, crypto state
    • 1 handshake
http over TCP + TLS

QUIC 주요 기능

  • 연결지향적 & 보안
    TCP와 마찬가지로 QUIC은 두 종단 간의 연결지향 프로토콜이다. 대신 QUIC은 연결 상태를 설정하는 데 필요한 핸드셰이크와 인증 및 암호화에 필요한 핸드셰이크를 결합하여, 더 빠른 설정(1RTT)을 제공한다.
  • Stream Multiplexing
    QUIC을 사용하면 단일 QUIC 연결을 통해 여러 애플리케이션 레벨의 스트림들을 다중화하고, 이를 통해 동시에 여러 스트림이 독립적으로 전송된다.
  • 신뢰적이고 TCP 친화적인 혼잡 제어 데이터 전송
    QUIC은 스트림별로 데이터를 신뢰적이고 순서대로 전달하기 때문에 손실된 UDP 세그먼트는 해당 세그먼트에서 데이터가 전달된 스트림에만 영향을 준다. 다른 스트림의 HTTP 메시지는 계속 수신되어 애플리케이션에 전달될 수 있으므로, TCP HOL Blocking을 해결한다.

❗ Limitations

  • QUIC은 패킷별로 암호화하기 때문에 패킷을 묶어서 암호화하는 TLS-TCP보다 리소스 소모가 더 클 수 있다.
  • CPU 사용량이 많다.
  • UDP를 사용하기 때문에 UDP Flood DDoS 공격에 취약하다.

HTTP 1.0 ➡︎ HTTP 1.1 ➡︎ HTTP 2.0 ➡︎ HTTP 3.0 (QUIC)

출처: https://blog.bytebytego.com/p/http-10-http-11-http-20-http-30-quic

Additional Resources

References

profile
Hee Suh
원리를 파헤치는 것을 좋아하는 프론트엔드 개발자입니다 🏃🏻‍♀️
이전 포스트

TCP/UDP

다음 포스트

Cookie, Session

0개의 댓글