HTTP

Jinmin Kim·2025년 7월 25일

HTTP

(2025.07.25 팀회고)
네트워크에 대해서 조금 알아보다가, http의 내용에 대해서 조금더 알고싶어졌다.
알던 내용들을 다시 정리하는시간 + 회사에서 사용하는 네트워크는 이것인데 이런것 까지있구나 하는 생각이 들었다.

HTTP란?

HTTP는 하이퍼텍스트 전송 프로토콜 (Hypertext Transfer Protocol)의 약자로, 웹 브라우저와 웹 서버 간에 데이터를 주고받기 위한 통신 규약입니다. 클라이언트(주로 웹 브라우저)가 서버에 요청을 보내면, 서버는 그 요청에 대한 응답을 클라이언트에 보냅니다. 이러한 요청-응답 방식을 통해 웹 페이지, 이미지, 동영상 등 다양한 웹 콘텐츠를 주고받을 수 있습니다.

네트워크 7계층중 Applicatoin Layer에 속해있으며,
보통 Transport Layer에 속해있는 TCP, UDP를 통해서 소통하게된다.

3-way Handshaking

HTTP 0.9 초기상태 [TCP]

가능한 메서드는 하이퍼텍스트 문서(html)를 가져오기만 하는 GET 동작이 유일했으며, 헤더(header)도 없어 요청과 응답이 극히 단순 명료 하였다. 또한 상태 코드(status code)도 없었기 때문에 문제가 발생한 경우 특정 html 파일을 오류에 대한 설명과 함께 보내졌다.

GET /mypage.html

<HTML>
A very simple HTML page
</HTML>

HTTP 1.0 초기상태 [TCP]

Short-lived Connection
HTTP 1.0의 문제점은 비연결성(connectionless)로 인한 단기 커넥션(Short-lived connenction) 특징이다.
즉, 커넥션 하나당 하나의 요청 하나의 응답 처리가 가능한 것을 말하는데, 서버에 자원을 요청할때마다 매번 새로운 연결을 해주어야 했다.

HTTP 1.1 초기상태 [TCP]

1.0에서의 Short-lived Connection 문제로 인해 6개월만에
다시 http가 출시되었다. 해당 문제를 개선하기위해 아래의 내용이 나왔다.

지속 연결(Persistent connection) - keep alive : 지정한 timeout 동안 연속적인 요청 사이에 커넥션을 닫지 않음. 기존 연결에 대해서 handshake 생략 가능

현재 우리가 사용하고있는 형태의 HTTP 요청.

기본적인 HTTP 메서드와 요청/응답 헤더 추가 HTTP 버전 정보가 각 요청 사이내로 전송되기 시작 (HTTP/1.0 이 GET 라인에 붙은 형태로)
상태 코드(status code)가 응답의 시작 부분에 붙어 전송되어, 브라우저가 요청에 대한 성공과 실패를 알 수 있고 그 결과에 대한 동작을 할 수 있게 되었다.

Pipelining

파이프 라이닝은 여러개의 요청을 보낼때 처음 요청이 응답될 때까지 기다리지 않고 바로 요청을 한꺼번에 보내는 것을 의미한다. 즉, 여러개의 요청을 한꺼번에 보내서 응답을 받음으로서 대기시간을 줄이는 기술이다.

문제점

1️⃣ 서버는 요청이 들어온 순서대로(FIFO) 응답을 반환한다.

응답 순서를 지키기 위해 응답 처리를 미루기 때문에 Head Of Line Blocking 문제가 발생하여, 그래서 모던 브라우저들은 대부분 파이프라이닝을 사용하지 못하도록 막아 놓았다.

Head Of Line Blocking이란?
순서를 지키려면 앞에 요청온것을 먼저 보내줘야하는데, 만약 먼저 요청한 내용이 오래걸리게 된다면, 이후의 내용들이 계속 지연되는 현상

2️⃣ 중복 헤더

http/1.1의 헤더에는 많은 메타정보들이 저장되어져 있다.
또한 해당 도메인에 설정된 cookie정보도 매 요청시 마다 헤더에 포함되어 전송되기 때문에 오히려 전송하려는 값보다 헤더 값이 더 큰 경우가 비일비재 하였다.
그리고 지속 커넥션 속에서 주고 받는 연속된 요청 데이터가 중복된 헤더값를 가지고 있는 경우가 많아 쓸데없는 메모리 자원도 낭비하게 되는 꼴이 되었다.

HTTP 2.0 [TCP]

HTTP 2.0에서는 헤더 압축(HPACK)과 헤더의 중복 제거(Multiplexing과 함께)가 도입되었습니다. 이를 통해 같은 커넥션 상에서 중복되는 헤더를 줄이고 성능을 개선할 수 있었다.

HTTP 1.1과 HTTP 2.0의 주요한 차이점은 HTTP 메세지가 1.1에서는 text로 전송되었던 것과 달리, 2.0에서는 binary frame로 인코딩되어 전송된다는 점이다.

구분	HTTP/1.1	HTTP/2
기본 단위	Message (텍스트 기반)	Frame (바이너리 기반)
Message 구성	헤더 + 바디 (통짜 텍스트)	여러 개의 Frame으로 분할
추가 개념	없음	Frame, Stream, Multiplexing
멀티플렉싱	불가능 (순차적 요청)	가능 (동시 다중 전송)

HTTP/2 주요 개념 정리

1️⃣ Frame (프레임)

HTTP/2의 통신 최소 단위 (바이너리 기반)
종류: Header Frame, Data Frame 등
하나의 메시지는 여러 Frame으로 나뉘어 전송됨

2️⃣ Message (메시지)

요청(Request) 또는 응답(Response)을 의미
하나의 Message = 여러 Frame의 조합
HTTP/1.1의 메시지와 역할은 같지만 내부 구조가 분할됨

3️⃣ Stream (스트림)

하나의 커넥션(Connection) 위에서 흐르는 양방향 데이터 흐름 단위
각 Stream은 고유 ID를 가짐
여러 Stream이 동시에 존재 가능 (Multiplexing)

멀티플렉싱(multiplexing) -> Head Of Line Blocking 해결 방법

바로 위에서 frame - message - stream - connection 그림에서 봤듯이, HTTP 헤더 메세지를 바이너리 형태의 프레임으로 나누고 하나의 커넥션으로 동시에 여러개의 메세지 스트림을 응답 순서에 상관없이 주고 받는 것을 멀티플렉싱(multiplexing)이라고 한다.

🚨질의응답🚨

TCP에서 왔다갔다를 하면서, Pipelining를 만들게되는데,
Pipelining에서 한번에 모아서 보내는것들에 대해서 취소가되거나,
잘못이 일어나면, 서버가 해당 내용을 알수가있는걸까? 로그가 찍히는걸까?
HTTP 2.0에서 Header 중첩을 해결하기위해서 비교해서 같은것들은
보내지않고, 중첩되지 않는 Header만 보낸다고했는데, 해당 비교는 어디에서 하는것이고, 보내지 않은 데이터에 대해서는 어디서 해당 내용을 알고있는가??
HTTP에서 요청을 보내면서, 특정 헤더를 안보내고 싶다면, 어떻게 처리해줘야하는가? 옵션이 있는건가??? header 자체를 조작하고싶은건가?
HTTP 1.1에서 Pipelining을 구성하고있는곳에서 우리가 사용하는 서비스는 사실 앞에 API가 pending이 걸린다고 이후의 다른 API가 멈추거나 하지않더라,
HTTP 1.1의 Pipelining은 앞에 내용중 하나의 내용이 막혔을때 뒤의 요청들이 함께 멈춘다고 되어잇는데 왜 우리 서비스에서는 해당 현상을 못본걸까?
아니면 내가 그냥 못본건가?
HTTP의 통신에서 만약 Pipelining 이후에 Block이 생겼을때 status는 몇번으로 나타나는가? 또는 Client가 해당 내용을 알수있는가?