TIL

효준·2024년 10월 29일

10월 29일 화요일
AM 알고리즘 문제 풀이
PM 1주차 강의 수강

💡 Today Issue

HTTP

🤔 나의 생각 + 배운 것

HTTP/1.0

버전 정보가 명시되고 각 요청 응답 사이에서 전송되었다.

요청 메서드가 GET, HEAD, POST 세 가지로 확장되었다.

상태 코드가 추가되어 클라이언트 측에서 요청 결과에 따라 동작할 수 있게 되었다.

요청과 응답에 대한 부가적인 메타데이터를 담는 헤더 필드가 추가되었다.

HTTP 헤더의 도움으로 HTML 이외의 파일도 전송할 수 있게되었다.

HTTP/1.1

제안한 이유 :

HTTP/1.0이 설계에서 불완전하고 미처 고려되지 못한 부분이 있어서 보완해야한다.

HTTP/1.0으로 통신한다고 선언해 놓고 사양을 지키지 않은 서버와 클라이언트가 많아 불편하다.

추가된 기능

연결 상태 유지 : 한번 수립한 연결을 재사용하도록 설정되었으며 연결을 맺고 끊는 과정이 줄어 지연이 개선될 수 있다. 연결을 유지하는 시간이 길어지면 서버에 부하가 생겨 연결 유지 시간을 제한하며 Keep-Alive라고 부른다.

파이프라이닝 : 클라이언트가 여러 요청을 연달아 보내야 할 때, 각 응답을 기다리는 것이 아니라 발생한 요청은 일단 전송하고 보는 방식이다. 이전에는 한번에 하나씩 요청과 응답을 처리 했는데 이는 지연을 발생시킬 수 있다.

HTTPS : 암호화 되지 않은 텍스트로 통신을 하는 HTTP는 신뢰성과 무결성을 추가할 필요에 따라 대화 상대가 서로 신뢰할 수 있음을 증명하는 인증서를 사용하고 통신 내용은 SSL or TLS라는 프로토콜로 암호화하는 방식으로 해결했다.
HTTPS 통신에서 상대방을 확인하기 위해 인증서를 이용한 비대칭 키 암호화 방식을 사용한다.
비대칭 키 암호화 방식은 비대칭 키 암호화를 이용해 대칭 키를 교환하는 방식이다.

RESTful : 이전에는 클라이언트 측 요청으로 서버가 HTML 파일을 제공하였는데 서버와 서버 간의 통신의 경우 데이터만 주고받을 수 있는 API가 필요해 당시 HTTP가 표준 프로토콜이었기에 HTTP 기반으로 웹의 장점을 최대한 활용할 수 있는 아키텍처로 REST가 제안되었습니다. REST는 HTTP의 메서드를 활용해 CRUD를 구현하고 URI를 통해 자원을 명시, HTTP 통신의 특성을 최대한 활용하는 아키텍처입니다.

HTTP/1.1의 한계점

헤더의 중복 : HTTP/1.1에 많은 기능이 추가되며 헤더에도 많은 메타 데이터가 담기게 되었고 매 요청시 헤더를 중복 요청하게 되어 낭비로 이어지게 되며 전송하려는 값보다 헤더의 크기가 더 큰 경우도 발생했다.

HOLB : 항상 요청받은 순서대로 응답해야하는 특성에서 발생했는 문제였다. HTTP/1.1에서 하나의 연결내에서 응답 다중화를 할 수 없었기 때문에 서버가 응답 작성 중간에 문제가 생기면 후속 요청들을 전송 못하고 지연되는 문제가 발생했다.
이로 인해 HTTP/1.1에서는 물리적인 TCP연결을 여러개 두는 방식으로 병렬 연결을 구현하게 되었습니다. 하지만 이는 HOLB를 해결할 수 있는 해결책이 아니었습니다.

HTTP/2

SPDY :
HTTP/2에서 SPDY라는 프로토콜을 기반으로 동작하는데 SPDY는 HTTP/1.1의 잘 알려진 성능 제한 사항을 해결하여 웹 페이지의 로드 대기 시간을 줄이는 것으로 목표로 구글에서 개발하고 2009년 중반에 발표한 프로토콜입니다. 때문에 HTTP/2는 HTTP over SPDY라는 이름으로도 불립니다.

이진(binary)프로토콜 :
HTTP/1.1은 텍스트 기반 프로토콜이기 때문에 아스키코드로 작성되었고 사람이 읽기에는 편하지만 데이터가 불필요하게 커지는 문제가 있었다.
HTTP/2에서는 보내는 데이터를 바이너리로 변환하는 계층이 있어 단순 텍스트 전송보다 훨씬 더 효율적으로 데이터를 전송할 수 있습니다.

응답 다중화 지원 :

위에서 설명했던것처럼 하나의 요청과 응답을 하며 순서를 지켰던 것과 달리 하나의 TCP 연결에서 여러 요청을 동시에 처리할 수 있는데 이것은 TCP연결을 스트림(stream), 메세지(message), 프레임(frame)이라는 단위로 더욱 세분화 했기 때문입니다.

스트림 : 요청과 응답이 양방향을 오가는 논리적 연결 단위, TCP 연결에서 여러 개의 스트림이 동시에 존재할 수 있음
메세지 : 하나의 요청과 응답을 구성하는 단위
프레임 : 메세지를 구성하는 최소 단위, 잘게 쪼게어 전송되기 때문에 수신 측에서 다시 조립하여 사용

헤더 필드 압축 :

HPACK이라 부르는데, 달라진 부분만 다시 전송하는 허프만 코딩 기법을 사용한다. 달라지지 않은 부분은 전송하지 않아 불필요하게 발생하는 오버헤드를 최소화 할 수 있다.

이외에도 많은 기능이 있다.

HTTP/2의 한계점

HTTP/2가 여전히 TCP 위에서 동작하기에 TCP로 인해 발생하는 문제를 해결할 수 없었기 때문이다.
TCP는 신뢰성을 지향하기에 데이터 손실이 발생하면 재전송을 수행한다. TCP는 재전송을 정확한 순서대로 수행해야하는 특성상 재전송 수행 후 대기과정에서 병목 현상이 발생했습니다. TCP는 프로토콜 자체의 HOLB 문제를 해결할 수 없었습니다.

HTTP/3

이를 해결하기 위해 HTTP/3는 QUIC이라는 프로토콜 위에서 동작합니다. QUIC은 TCP의 신뢰성 보장을 위해 제공되는 기능들을 UDP 기반으로 직접 구현하여 성능을 개선하여 구글이 공개한 프로토콜입니다.

QUIC은 TCP가 아닌 UDP기반의 프로토콜입니다. UDP는 TCP와 달리 기본적인 신뢰성을 제공하지 않는데 UDP 프로토콜 자체의 구조가 간단하기 때문에 QUIC은 신뢰성을 위해 패킷 재전송, 혼잡 제어, 흐름 제어 기능 등을 직접 구현했습니다. 즉 QUIC은 신뢰성 기능이 제공되는 UDP 기반의 프로토콜입니다.

HTTP/3는 연결 정보를 캐싱하여 재사용할 수 있는 0-RTT 기능을 제공합니다. TCP의 경우 최초 연결 수립 시 3-way 핸드세이크 과정이 필요하지만 HTTP/3는 최초 연결 설정에서 연결에 필요한 정보들과 데이터를 함께 전송하여 1-RTT로 시간을 절약한다. 또 한 번 성공한 연결은 캐싱해 놓았다가 다음 연결 때에는 캐싱된 정보를 바탕으로 바로 연결을 수립할 수 있기 때문에 0-RTT가 가능합니다.

독립 스트림 :
또한 HTTP/3는 연결 다중화를 지원하며, 각 스트림이 독립적으로 동작합니다. 위 사진을 보면 각 스트림이 독립적으로 동작한다는 것이 어떤 의미인지 쉽게 알 수 있을 것입니다. HTTP/2에서는 연결 다중화가 지원되어 여러 스트림을 동시에 지원할 수 있지만, TCP 특성상 데이터 손실이 발생하면 데이터 복구를 우선 처리하면서 HOLB가 발생합니다. 하지만 QUIC 기반의 HTTP/3는 연결 내 스트림이 완전히 독립적으로 동작하기 때문에 데이터 손실이 발생해도 다른 스트림에 영향을 주지 않죠.