HTTP 1.1, 2, 3

cloudflare 문서를 옮긴 글입니다.

[[HTTP]] 는 하이퍼텍스트 전송 프로토콜을 의미하며 거의 모든 웹 애플리케이션의 기초이다. 보다 구체적으로, HTTP는 컴퓨터와 서버가 정보를 요청하고 보내는 데 사용하는 방법이다. 예를 들어 누군가가 노트북에서 cloudflare.com 탐색하면 웹 브라우저에서 페이지에 표시되는 콘텐츠에 대해 Cloudflare 서버에 HTTP 요청을 보낸다. 그런 다음 Cloudflare 서버에서는 브라우저에서 사용자에게 표시하는 텍스트, 이미지, 서식과 함께 HTTP 응답을 보낸다.

HTTP/1.1

HTTP의 첫 번째 사용 가능한 버전은 1997년에 만들어졌다. 여러 단계의 개발을 거쳤으므로 이 첫 번째 버전의 HTTP는 HTTP/1.1이라고 불렸다. 이 버전은 웹에서 아직도 사용되고 있다.

HTTP/2

2015년에는 HTTP/2라는 새로운 버전의 HTTP가 만들어졌다. HTTP/2는 HTTP/1.1 제작자가 예상하지 못한 몇 가지 문제를 해결한다. 특히 HTTP/2는 HTTP/1.1보다 훨씬 빠르고 효율적이다. HTTP/2가 더 빠른 방법 중 하나는 로드 프로세스 중에 콘텐츠의 우선순위를 지정하는 방법이다.

HTTP/2의 우선 순위 지정

🧑‍💻

우선 순위 지정

웹 성능의 맥락에서 우선순위는 콘텐츠가 로드되는 순서를 나타냅니다.사용자가 뉴스 웹 사이트를 방문하여 기사로 이동한다고 가정해 보겠습니다.기사 상단의 사진이 먼저 로드되어야 할까요?기사의 텍스트가 먼저 로드되어야 할까요?배너 광고가 먼저 로드되어야 할까요?

우선순위는 웹 페이지의 로드 시간에 영향을 줍니다. 예를 들어 큰 JavaScript 파일과 같은 특정 리소스는 먼저 로드해야 하는 경우 페이지의 나머지 부분이 로드되지 않도록 차단될 수 있습니다. 이러한 렌더링 차단 리소스가 마지막으로 로드되는 경우, 더 많은 페이지를 한 번에 로드할 수 있습니다.

또한 이러한 페이지 리소스가 로드되는 순서는 사용자가 페이지 로드 시간을 인식하는 방법에 영향을 미칩니다. 배후의 콘텐츠(예: CSS 파일) 또는 사용자가 즉시 볼 수 없는 콘텐츠(예: 페이지 하단의 배너 광고)만 먼저 로드되면 사용자는 페이지가 전혀 로드되지 않는다고 생각할 것입니다. 페이지 상단의 이미지와 같이 사용자에게 가장 중요한 콘텐츠가 먼저 로드되는 경우 사용자는 페이지가 더 빨리 로드되는 것으로 인식합니다.

HTTP/2에서는 가중치 우선순위 지정이라는 기능이 제공된다. 이를 통해 개발자는 매번 먼저 로드할 페이지 리소스를 결정할 수 있다. HTTP/2에서 클라이언트가 웹 페이지를 요청하면 서버는 여러 데이터 스트림을 클라이언트에 차례로 보내는 대신 한 번에 보낸다. 이 데이터 전달 방법을 멀티플렉싱이라고 한다. 개발자는 이러한 각 데이터 스트림에 서로 다른 가중치 값을 할당할 수 있으며, 이 값은 클라이언트에 먼저 렌더링할 데이터 스트림을 알려준다.

🖋️

예시)

Alice가 친구 Bob이 쓴 소설을 읽고 싶어하지만, Alice와 Bob은 일반 메일을 통해서만 의사소통한다고 상상해 보세요. Alice는 Bob에게 편지를 보내 소설을 보내달라고 부탁합니다. Bob은 HTTP/1.1 스타일이라는 소설을 보내기로 결정합니다. Bob은 한 번에 한 장씩 우편으로 보내고, Alice로부터 이전 장을 받았다는 답장을 받은 후에만 다음 장을 우편으로 보냅니다. 이 콘텐츠 전달 방법을 사용하면 Alice가 Bob의 소설을 읽는 데는 몇 주가 걸립니다.

이제 Bob이 Alice에게 자신의 소설 HTTP/2 스타일을 보내기로 결정했다고 상상해 보세요. 이 경우 Bob은 소설의 각 장을 개별적으로 보내지만(우편 서비스의 크기 제한 내에서 유지하기 위해), 동시에 보냅니다. Bob은 또한 각 장에 1장, 2장 등의 번호를 매깁니다. 이제 Alice는 소설을 한꺼번에 받고 적당한 시간에 올바른 순서로 조립할 수 있습니다. 챕터가 누락된 경우 특정 챕터를 요청하는 빠른 답장을 보낼 수 있지만, 그렇지 않으면 프로세스가 완료되고, Alice는 단 며칠 만에 소설을 읽을 수 있습니다.

HTTP/2에서는 Bob이 Alice에게 한 번에 여러 장을 보내는 것처럼 데이터가 한 번에 전송됩니다. Bob과 마찬가지로 개발자는 HTTP/2에서 각 장에 번호를 매길 수 있습니다. 개발자는 웹 페이지의 텍스트, CSS 파일, JavaScript, 사용자 경험에 가장 중요하다고 생각되는 것 중 어느 것을 먼저 보낼지 결정할 수 있습니다.

HTTP/2 와 HTTP/1.1의 차이점

멀티플렉싱

HTTP/1.1은 리소스를 차례로 로드하므로 한 리소스를 로드할 수 없는 경우 그 뒤에 있는 다른 모든 리소스가 차단된다.이와는 대조적으로, HTP/2는 단일 [[TCP]] 연결을 사용하여 한 번에 여러 데이터 스트림을 보낼 수 있으므로 한 리소스 때문에 다른 리소스가 차단되지 않는다.HTTP/2는 데이터를 이진 코드 메시지로 분할하고 클라이언트가 각 이진 메시지가 속한 스트림을 알 수 있도록 이러한 메시지에 번호를 매겨 이를 수행합니다.

서버 푸시

일반적으로 서버는 클라이언트가 요청하는 경우에만 클라이언트 장치에 콘텐츠를 제공한다.그러나 이 접근 방식은 클라이언트가 요청해야 하는 수십 개의 개별 리소스를 포함하는 최신 웹 페이지에서는 항상 실용적인 것은 아니다.HTTP/2는 클라이언트가 요청하기 전에 서버가 클라이언트에 콘텐츠를 “푸시”할 수 있도록 하여 이 문제를 해결한다.서버는 또한 Bob이 모든 것을 보내기 전에 Alice에게 소설의 목차를 보낸 경우와 같이, 예상되는 콘텐츠를 푸시한 내용을 클라이언트에게 알려주는 메시지를 보낸다.

헤더 압축

작은 파일은 큰 파일보다 더 빨리 로드된다. 웹 성능 속도를 높이기 위해 HTTP/1.1 및 HTTP/2는 모두 HTTP 메시지를 압축하여 더 작게 만든다.그러나 HTTP/2는 HTTP 헤더 패킷에서 중복 정보를 제거하는 HPACK이라는 고급 압축 방법을 사용한다.이렇게 하면 모든 HTTP 패킷에서 몇 바이트가 제거된다. 단일 웹 페이지를 로드하는 데 관련되는 HTTP 패킷의 양을 고려할 때, 이러한 바이트는 빠르게 합산되어 로드 속도가 빨라진다.

HTTP/3

HTTP/3은 새로운 개발 표준으로, 웹 브라우저와 서버가 통신하는 방식에 영향을 미치며, 성능, 안정성, 보안 등 사용자 경험을 크게 업그레이드한다.

HTTP/3는 2015년에 HTTP/2 승인된 이후 하이퍼텍스트 전송 프로토콜의 첫 번째 주요 업그레이드가 될 것이다.

HTTP/3의 중요한 차이점은 새로운 전송 프로토콜인 QUIC에서 실행된다는 것이다. QUIC은 사람들이 하루 종일 이동하면서 끊임없이 하나의 네트워크에서 다른 네트워크로 전환하는 스마트폰을 휴대하는 모바일 중심의 인터넷 사용을 위해 설계되었다. 최초의 인터넷 프로토콜이 개발될 당시에는 기기의 휴대성이 떨어지고 네트워크를 자주 전환하지 않았다.

🧑‍💻

QUIC

QUIC 프로토콜은 2012년에 Google에서 개발했으며, 벤더 중립적인 표준 단체인 인터넷 엔지니어링 태스크포스(IETF)에서 새로운 HTTP/3 표준을 만들기 시작하면서 채택되었다. 전 세계 전문가들의 자문을 거쳐 IETF는 여러 가지 변경 사항을 적용하여 자체 버전의 QUIC을 개발했다.

HTTPS 프로토콜은 TCP/IP와 TLS레이어가 나누어져 있어서 불필요한 라운드 트립 딜레이(RTT)가 발생했는데, QUIC은 이 과정을 UDP 위에서 한 번의 라운드-트립으로 구현해서 효율성을 높였다.

# QUIC 프로토콜 | 구글 또 너야?

QUIC을 사용한다는 것은 HTTP/3가 전송 제어 프로토콜([[TCP]])이 아닌 사용자 데이터그램 프로토콜([[UDP]])에 의존한다는 의미다. UDP로 전환하면 온라인 검색 시 연결 속도가 빨라지고 사용자 경험이 향상된다.

HTTP/3이 필요한 이유

QUIC는 HTTP/2의 가장 큰 단점 몇 가지를 해결하는 데 도움이 될 것이다.

• 스마트폰이 WiFi에서 셀룰러 데이터로 전환될 때(예: 집이나 사무실을 떠날 때) 성능이 저하되는 문제 해결 방법 개발
• 패킷 손실의 영향 감소 - 하나의 정보 패킷이 목적지에 도달하지 못하면 더 이상 모든 정보 스트림을 차단하지 않는다.(“헤드 오브 라인 차단”이라고 알려진 문제).

🧑‍💻

HOL(Head-of-Line Blocking)

컴퓨터 네트워킹에서 HOL 차단(Head-of-Line Blocking)은 패킷 대기열이 대기열의 첫 번째 패킷에 의해 지연될 때 발생하는 성능 제한 현상입니다. 예를 들어 입력 버퍼링 네트워크 스위치, 순서 외 전송 및 HTTP 파이프라이닝의 여러 요청에서 발생합니다.

wikipedia - Head-of-line_blocking

기타 혜택은 다음과 같습니다.

• 더 빠른 연결 설정: QUIC를 사용하면 TLS 버전 협상이 암호화 및 전송 핸드셰이크와 동시에 이루어진다.
• 제로 왕복 시간(0-RTT): 이미 연결된 서버의 경우 클라이언트는 핸드셰이크 요구 사항(통신 방법을 결정하기 위해 서로를 인정하고 확인하는 과정)을 건너뛸 수 있다.
• 보다 포괄적인 암호화: QUIC의 새로운 핸드셰이크 접근 방식은 HTTP/2에서 대폭 업그레이드된 암호화를 기본으로 제공하며 공격 위험을 완화하는 데 도움이 된다.

기본적 암호화란?

애플리케이션 계층이 아닌 전송 계층 내에서 암호화를 요구하는 것은 보안에 중요한 의미를 갖는다. 이는 연결이 항상 암호화된다는 것을 의미한다. 이전에 HTTPS에서는 암호화와 전송 계층 연결이 별도로 이루어졌다. TCP 연결은 암호화되거나 암호화되지 않은 데이터를 전송할 수 있었으며, TCP 핸드셰이크와 TLS 핸드셰이크는 서로 다른 이벤트였다. 그러나 QUIC는 기본적으로 전송 계층에서 암호화된 연결을 설정하므로 애플리케이션 계층 데이터가 항상 암호화된다.

QUIC는 두 번의 핸드셰이크를 하나의 작업으로 결합하여 이를 수행하므로 애플리케이션이 데이터를 전송하기 전에 한 번의 핸드셰이크만 완료될 때까지 기다려야 해서 대기 시간이 줄어든다. 또한 패킷 번호와 헤더의 일부 다른 부분을 포함하여 각 연결에 대한 메타데이터를 암호화하여 사용자 행동에 대한 정보를 공격자가 의 입수하지 못하도록 보호한다. 이 기능은 HTTP/2에는 포함되지 않았다. 이 데이터를 암호화하면 공격자가 사용자 행동에 대한 실행 가능한 정보를 손에 넣지 못하도록 보호할 수 있다.

HTTP는 요청과 응답에 일반 텍스트를 사용하는데, 이는 통신을 모니터링하는 모든 사람이 이를 읽을 수 있으므로 보안에 부정적인 영향을 미친다. 기본적으로 암호화하면 모두를 안전하게 보호하고 중요한 데이터를 보호하는 데 도움이 된다.