HTTP Header

이태곤·2024년 1월 16일

CS

목록 보기

12/23

1. HTTP Header

클라이언트와 서버간 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 돕는다.
HTTP Header 종류
1. General header: 요청과 응답 모두에 적용되지만 바디와 관련이 없는 헤더
2. Request header: 페치될 리소스나 클라이언트 자체에 대한 정보를 포함하는 헤더
3. Response header: 서버 자체에 대한 정보 등 응답에 대한 부가적인 정보를 갖는 헤더
4. Entity header: 컨텐츠 길이, MIME 타입과 같이 바디에 대한 자세한 정보를 포함하는 헤더

2. HTTP request

GET /docs/index.html HTTP/1.1
Host: www.nowhere123.com
Accept: image/gif, image/jpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
(blank line)

Request line
- Method, Request-URI, HTTP version
Request Headers
- Host: 요청받을 서버의 도메인 정보
- Accept: 클라이언트가 수신 처리 가능한 MIME 타입
- Accept-Language: 클라이언트가 수신 처리 가능한 언어
- Accept-Encoding: 클라이언트가 수신 처리 가능한 Encoding 방식
- User-Agent: 클라이언트의 브라우저 또는 애플리케이션 정보

3. HTTP response

HTTP/1.1 200 OK
Date: Sun, 18 Oct 2009 08:56:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Sat, 20 Nov 2004 07:16:26 GMT
ETag: "10000000565a5-2c-3e94b66c2e680"
Accept-Ranges: bytes
Content-Length: 44
Connection: close
Content-Type: text/html
X-Pad: avoid browser bug
  
<html><body><h1>It works!</h1></body></html>

Status line
- HTTP version, status code
Response Headers
- Date: 응답 메세지 생성 날짜
- Server: 서버 정보
- Last-Modified: 마지막으로 수정된 날짜
  - Conditional GET 추가 학습은 클릭!

4. HTTP version

1. HTTP 1.0 & HTTP 1.1

HTTP 1.0
- Non-persistent: 데이터를 주고받을 때마다 TCP 연결을 새로 수립해야 한다.
- Non-pipelining: 하나의 요청을 보내고 해당 요청에 대한 응답을 받아야지만 다음 요청을 진행할 수 있다.
HTTP 1.1
- Persistent: 데이터를 주고 받는동안 TCP 세션이 유지된다.
  → 기존 연결을 재사용하여 오버헤드를 줄이고 response time 단축
- Pipelining : 응답을 기다리지 않고 여러 요청을 병렬로 보낼 수 있다.
  → Throughput↑
한계
1. HOL 발생: 브라우저에서 허용되는 병렬 요청 수가 모두 사용되어, 후속 요청이 이전 요청이 완료될 때까지 대기해야 하는 상황이 발생할 수 있다.
  - 같은 큐에 있는 패킷이 첫번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상
  - 사용자가 여러 요청을 연속으로 보낸 경우, 브라우저에서 병렬로 처리 가능한 요청 수가 제한되어 있다.
  - 첫 번째 요청이 완료되기 전에 다른 요청들은 대기해야 한다.
  - 나머지 요청들은 비교적 빠르게 응답이 가능한 상태에도 불구하고 첫 번째 요청의 응답을 기다려야 하며, 이로 인해 웹 페이지 로딩 성능이 저하될 수 있다.
2. HTTP 1.0의 경우 요청마다 connection 해야하므로 RTT 증가
3. 무거운 헤더: 사용자가 웹 페이지를 방문할 때 많은 HTTP 요청이 발생하며, 이로 인해 중복된 헤더 값과 각 도메인에 설정된 쿠키 정보가 매 요청마다 헤더에 다시 전송된다.
  이로 인해 불필요한 중복 데이터 값이 전송되며, 경우에 따라 데이터 양보다 헤더의 크기가 더 큰 경우가 발생할 수 있다.
  → 웹 페이지에서 여러 이미지, 스타일시트, 스크립트 파일 등을 로딩하는 경우, 각 요청마다 중복된 헤더 데이터(Accept-Encoding, Cookie)가 함께 전송된다.

2. HTTP 2.0

HTTP 1.0 / HTTP 1.1 버전에서 해결되지 못한 HOL(Head of Line Blocking) 문제를 해결했다.

해결방법
1. 오브젝트들을 프레임 단위로 쪼개어(Framing) 번갈아가며 수행 함으로써 해결
2. Binary 인코딩: HTTP/2는 텍스트 형태로 전달되는 HTTP 메시지가 아닌 binary 형태로 인코딩되어 전송된다.
  이로써 송수신 데이터량이 감소하고 효율적으로 통신이 가능해졌다.
  → 10바이트만 있으면 1024개의 정보를 표현할 수 있다.
  → 헤더도 이진 표현을 통해 압축
3. 우선순위 지정: HTTP/2는 요청하는 객체의 우선순위를 지정할 수 있다.
4. Push 기능: HTTP/2에서는 서버가 클라이언트의 요청 없이 연관된 객체를 함께 클라이언트에게 전송할 수 있는 기능을 제공한다.
  → Pull방식에서 Push 방식으로 변경
  → 클라이언트가 HTML 문서를 받고 나서 필요한 리소스를 다시 요청하는 번거로움을 줄여주며, 웹 페이지 로딩을 빠르게 만드는 기술이다.
한계
1. 여전히 TCP 연결을 사용하므로, 연결 수립 및 해제를 위한 handshaking 과정에서 Response time이 증가 할 수 있다.
2. TCP는 신뢰성 있는 프로토콜로 알려져 있지만, 패킷이 유실되거나 오류가 발생할 경우 재전송 기법을 사용한다.
  이로 인해 패킷 지연이 발생할 수 있으며, 이러한 지연은 HOL을 유발할 수 있다.

3. HTTP 3.0

HTTP 3.0에서는 UDP 위에서 동작하는 QUIC 프로토콜을 사용한다.
1. 흐름제어 및 혼잡제어: UDP는 흐름제어와 혼잡제어를 지원하지 않아 데이터 전송에 제한이 없으며 이로 인해 네트워크 혼잡 상황에서 데이터 손실이 발생할 수 있다.
  QUIC는 흐름제어 및 혼잡제어 기능을 통해 데이터의 안정적인 전송을 보장하며 네트워크 혼잡을 최소화한다.
2. 보안 및 제어 개선: QUIC은 보안 측면에서도 개선되어 있으며, TLS(Transport Layer Security) 프로토콜과 함께 사용된다.
3. Zero Round-Trip Time (0-RTT): 이전 연결에서 이미 확인한 정보를 재사용하여 연결을 빠르게 설정할 수 있다.