[CS] 응용 계층 - HTTP의 기초

눈치없어·2025년 3월 25일

HTTP를 이해하기 위한 배경지식과 HTTP 전반에 대한 내용

DNS와 URI/URL

도메인 네임과 DNS

네트워크 상의 호스트를 식별하기 위해 기본적으로 IP 주소를 사용하지만
오로지 IP 주소만을 사용하는 것은 다소 번거로움 일

숫자로만 이루어져 있어 기억하기 어려움
특정 호스트의 특징을 나타내기 어려움
호스트의 IP 주소는 언제든 변경할 수 있음

그래서 도메인 네임을 사용함

📌 도메인 네임 (Domain Name)

특정 호스트를 식별하는 문자열 형태의 주소

www.example.com, developers.naver.com, git.kernel.org
기억하기 쉬움, IP 주소가 바뀌더라도 도메인 네임만 다시 대응하면 됨, 호스트를 특징을 쉽게 나타냄

네임 서버: 도메인 네임과 그에 대응되는 IP 주소를 관리하는 특별한 서버
DNS 서버: 도메인 네임을 관리하는 네임 서버

호스트는 네임 서버에 특정 도메인 네임을 가진 호스트의 IP 주소가 무엇인지 질의함으로써 패킷을 주고받고자 하는 호스트의 IP 주소를 얻어낼 수 있음

DNS 리졸빙(Resolving): 풀이(resolve)한다 or 리졸빙(resolve+ing)한다
- IP 주소를 모르는 상태에서 도메인 네임에 대응되는 IP 주소를 알아내는 과정
- www.example.com을 입력하면 DNS 서버가 해당 도메인의 IP 주소를 찾아서 반환하는 과정을 의미

📌 도메인 네임 계층적 구조

⏹️ 루트 도메인

도메인 네임의 최상단
실제로 도메인 네임의 마지막에 존재하지만 일반적으로 표기에서 생략됨
점(.)으로 표시됨 (www.example.com. ← 마지막 점이 루트 도메인)

⏹️ 최상위 도메인

루트 도메인 아래 위치하는 첫 번째 계층
일반 최상위 도메인: .com, .net, .org
국가 코드 최상위 도메인: .kr, .jp, .us

www.example.com의 최상위 도메인은 .com
하지만 "최상위 도메인"이라는 이름과는 달리 실제로 도메인 네임의 최상단은 아님
최상단에는 루트 도메인(.)이 존재하기 때문
보통 표기에서 루트 도메인(.)을 생략하기 때문에 최상위 도메인을 마지막 부분으로 간주

⏹️ 하위 도메인 (Subdomain)

2단계 도메인 (SLD, Second-Level Domain)
- 최상위 도메인(TLD)의 하위 도메인
- example.com에서 example이 2단계 도메인
3단계 도메인
- 2단계 도메인의 하위 도메인
- www.example.com에서 www가 3단계 도메인

도메인의 단계는 더 늘어날 수 있지만, 일반적으로 3~5단계로 구분

서브 도메인(Subdomain): 다른 도메인을 포함하는 도메인

mail.example.com

www.example.com

developer.example.com

모두 example.com의 서브 도메인

⏹️ 전체 주소 도메인 네임(FQDN (Fully Qualified Domain Name)

특정 호스트를 완전히 식별할 수 있는 도메인 네임 전체 주소를 의미

📌 네임 서버 계층적 구조

네임 서버는 여러 개가 존재하며, 전 세계 여러 곳에 위치함
다시 말해, 네임 서버는 분산되어 관리됨

⏹️ 도메인 네임 시스템(DNS): 계층적으로 분산되어 있는 도메인 네임에 대한 관리 체계
DNS는 호스트가 이러한 DNS를 이용할 수 있도록 하는 애플리케이션 계층 프로토콜을 의미하기도함

⏹️ DNS 리졸빙 과정

로컬 네임 서버에 질의
- 클라이언트는 가장 먼저 로컬 네임 서버에 질의
- 로컬 네임 서버가 FQDN에 대응하느 IP 주소를 알고 있다면 클라이언트에게 즉시 해당 IP 주소 반환
- 대부분의 경우 ISP가 자동으로 로컬 네임 서버 주소를 할당 해줌
- 또는 사용자가 공개 DNS 서버를 설정

대표적인 공개 DNS 서버
Google: 8.8.8.8, 8.8.8.4
Cloudflare: 1.1.1.1

로컬 네임 서버가 IP 주소를 모르는 경우
- 계층적 네임 서버에 순차적으로 질의함

로컬 네임 서버 → 루트 네임 서버 → TLD 네임 서버 → 네임 서버, ... 등에 걸쳐 최종적으로 IP 주소 반환

⏹️ DNS 캐시(DNS Cache)

DNS 질의가 너무 많아지면
- 트래픽 증가
- 응답 시간 증가

→ 그래서 DNS 서버는 기존 응답 결과를 임시 저장해놓고 같은 요청이 들어오면 캐시에서 반환

TTL (Time To Live)
- DNS 캐시는 영구적 않음
- 각 DNS 응답에는 TTL 값이 포함되어 있음
- TTL이 만료되면, 새로 질의해야 함

DNS 레코드 타입(DNS Record Type)

서버를 운영할 때, 클라이언트가 도메인 네임을 통해 서버에 접근하게 하려면
도메인 네임이 서버의 IP 주소에 대응되도록 설정해야 함

📌 도메인 네임을 서버에 연결하는 과정

1️⃣ 도메인 네임 구매

DNS 서비스 업체(가비아, 카페24, AWS Route 53 등)에서 도메인 구입
이들 업체는 보통 네임 서버를 운영 중

2️⃣ DNS 레코드 등록

도메인 네임을 구매한 것만으로는 끝이 아님
해당 도메인 네임을 어느 IP 주소와 연결할지 네임 서버에 알려줘야 함

이떄 사용하는 것이 DNS 레코드 (DNS Resource Record)

📌 DNS 레코드

도메인 네임에 대한 각종 정보를 저장한 데이터 항목

모든 DNS 레코드는 기본적으로

이름(Record Name)
값(Value)
레코드 타입(Record Type)
을 포함

레코드 타입에 따라, 해당 레코드가 의미하는 바가 달라짐
또한 각 레코드에는 TTL도 설정할 수 있음
- 캐시 유지 시간 (ex: 60, 3600, 86400, 172800 초 등)

대표적인 DNS 레코드 타입

레코드 타입	설명
A	도메인 네임을 IPv4 주소에 대응시킴
AAAA	도메인 네임을 IPv6 주소에 대응시킴
CNAME	도메인에 별칭(Alias)을 설정함
NS	해당 도메인을 관리하는 네임 서버의 주소를 지정
MX	메일 서버를 지정할 때 사용

레코드 설정 예시

레코드 타입	이름	값	TTL	설명
A	`example.com.`	`1.2.3.4`	300	`example.com` → IP 주소 매핑
CNAME	`www.example.com.`	`example.com.`	300	`www.example.com` → `example.com` 별칭

사용자가 www.example.com에 접속하면
자동으로 example.com으로 리다이렉트
결과적으로 1.2.3.4라는 IP 주소로 연결됨

자원과 URI/URL

자원: 네트워크 상의 메시지를 통해 주고받는 최종 대상을 의미

HTML 파일, 이미지, 동영상, 텍스트 파일이 될 수도 있음
즉, 두 호스트가 네트워크를 통해 서로 정보를 주고받을 때 송수신하는 대상이 바로 자원

📌 URI

자원을 식별하는 통일된 방식

구분	설명
URL	위치 기반 식별자 (Uniform Resource Locator)
URN	이름 기반 식별자 (Uniform Resource Name)

현대 대부분의 인터넷 환경에서는 URL이 훨씬 많이 사용됨

📌 URL 구조 분석

구성 요소	설명
scheme	`https` : 자원에 접근하는 방법/프로토콜 (예: `http`, `https`, `ftp`, ...)
authority	`www.example.com:8042` : 도메인/IP 주소 + 포트번호
path	`/over/there` : 자원이 위치한 경로
query	`?name=ferret` : 자원을 요청할 때 필요한 추가 정보 (매개변수)
fragment	`#nose` : 자원의 일부분을 가리키는 조각 정보 (예: HTML 내부 위치)

query 예시

부동산 검색
http://example.com/search?location=seoul&rooms=2&size=100&min_price=200000
지역: seoul
방 개수: 2
면적: 100
최소 가격: 200000

상품 필터링
http://example.com/search?category=books&brand=hanbit&discounted=true&sorted=price_desc
카테고리: books
브랜드: hanbit
할인 여부: true
정렬: price_desc

fragment 사용 예시

(a) 전체 문서 링크
https://datatracker.ietf.org/doc/html/rfc3986
문서 전체(처음부터)를 표시함

(b) 특정 섹션 링크
https://datatracker.ietf.org/doc/html/rfc3986#section-1.1.2
문서의 특정 부분(섹션 1.1.2)으로 이동

📌 URN

이름 기반(네임 기반)의 자원 식별자

URL이 자원의 위치(location)를 기준으로 식별한다면,
URN은 자원의 이름(name)을 기준으로 식별해

자원의 위치가 바뀌더라도 여전히 식별 가능하다는 점이 URN의 장점

다만 URN은 아직 URL만큼 널리 채택된 방식이 아니므로 자원을 식별할 URI로는 URL이 많이 사용됨

urn:isbn:0451450523

HTTP의 특징과 메시지 구조

HTTP의 목적은 애플리케이션의 다양한 자원을 네트워크를 통해 송수신하는 것
다소 일반적이고 범용적인 목적이지만, 그것이 바로 HTTP의 핵심. 데이터의 형식에 구애받지 않고 다양한 애플리케이션 데이터의 송수신을 가능하게 하는 것이 HTTP의 주된 목적

HTTP의 특징

주요한 특징 4가지가 있으며, 이는 프로그래밍에 큰 영향을 끼치기 때문에 모든 특징을 기억해 두는 것이 좋음
1. HTTP는 요청과 응답을 기반으로 동작(요청 응답 기반 프로토콜)
2. HTTP는 미디어 독립적(미디어 독립적 프로토콜)
3. HTTP는 상태를 유지하지 않음(스테이트리스 프로토콜)
4. HTTP는 지속 연결을 지원(지속 연결 프로토콜)

1️⃣ 요청 응답 기반 프로토콜

HTTP는 클라이언트가 요청(Request)을 보내고 서버가 응답(Response)을 반환하는 구조
요청과 응답은 각각의 HTTP 메시지 형태로 구성되며, 내용과 구조가 다름

2️⃣ 미디어 독립적 프로토콜

HTTP는 전송하는 데이터의 종류에 상관없이 자원을 전달할 수 있음
HTML, PNG, JPEG, JSON, XML, PDF 등 어떤 형식이든 모두 가능
HTTP는 자원의 형식이 아닌 자원을 전송하는 수단(인터페이스) 역할만 수행

이때 자원의 형식을 명시하는 것이 미디어 타입

미디어 타입은 MIME 타입 이라고도 부름

미디어 타입 형식표

미디어 타입의 추가 표기 방법
미디어 타입에 별표 문자()가 사용되는 경우도 있음. 별표는 여러 미디어 타입을 통칭하기 위해 사용
`text/는 text 타입의 모든 서브타입을 나타냄./는 모든 미디어 타입을 나타냄 또한 미디어 타입에는 부가 설명을 위해 선택적으로 매개변수를 포함할 수도 있음 매개변수는 타입/서브타입:매개변수=값의 형식으로 표현 type/html:charset=UTF-8`은 미디어 타입이 HTML 문서 타입이며, HTML 문서 내에서 사용된 문자가 UTF-8로 인코딩되었음을 의미

3️⃣ 스테이트리스 프로토콜

HTTP는 상태를 유지하지 않는(stateless) 특성을 가짐
클라이언트가 어떤 요청을 보내도, 서버는 이전 상태를 기억하지 않음
모든 요청은 독립적으로 처리됨

HTTP가 상태를 유지하지 않는 이유

HTTP 서버는 수많은 클라이언트 요청을 동시에 처리해야 함
각 클라이언트의 상태를 모두 기억하면 서버 부하 증가 + 구조 복잡도 증가
스테이트리스 덕분에:
- 서버 간 부하 분산, 서버 추가/교체가 쉬움
- 확장성과 견고성 향상

클라이언트 상태가 필요한 경우에는 세션, 쿠키, 토큰 등을 사용해서 해결

4️⃣ 지속 연결 프로토콜

HTTP 1.1 이상에서는 지속 연결을 기본으로 제공

비지속 연결 (HTTP/1.0 이전)
- 요청 1건 → 응답 1건 → 연결 종료
- 매 요청마다 새로운 TCP 연결 수립 → 비효율적
지속 연결 (HTTP/1.1 이상)
- 하나의 TCP 연결로 여러 요청/응답 처리 가능
- 다른 표현으로 Keep-Alive 라고도 부름

지속 연결을 통해 비지속 연결보다 빠른 속도로 여러 HTTP의 요청과 응답을 처리할 수 있음

HTTP의 특징 정리

특징	설명
요청-응답 기반	클라이언트 요청 → 서버 응답 구조
미디어 독립적	어떤 형식의 자원이든 전송 가능
스테이트리스	상태를 저장하지 않음, 확장성↑
지속 연결	하나의 TCP 연결로 여러 요청 처리

📌 HTTP 버전별 정리

HTTP 1.1

항목	설명
사용 비중	여전히 널리 사용되는 버전
연결 방식	지속 연결(Persistent Connection) 지원 (1.1부터 공식 지원)
메시지 형식	평문(Text) 기반 메시지 송수신
기능	콘텐츠 협상(Content Negotiation), 호스트 헤더 사용 등 다양한 편의 기능
문제점	HOL Blocking 문제 존재 (요청이 순차적으로 처리되어 지연 발생 가능)

HTTP 2.0

항목	설명
등장 목적	HTTP/1.1의 한계 보완 및 성능 개선
메시지 형식	바이너리(Binary) 기반 메시지 송수신
헤더 처리	헤더 압축 지원으로 네트워크 효율 ↑
멀티플렉싱	Multiplexing: 여러 요청/응답을 하나의 연결에서 병렬 처리 가능
서버 푸시	Server Push: 클라이언트가 요청하지 않은 리소스도 미리 전송 가능
HOL 완화	HTTP/1.1의 Head-of-Line Blocking 문제를 해결함

HTTP 3.0

항목	설명
최신 버전	가장 최근 등장, 사용 비중 점차 증가 중
기반 프로토콜	TCP → X / UDP → O (정확히는 QUIC 프로토콜 사용)
속도 향상	TCP 대비 빠른 송수신 속도
개선 효과	연결 수립 시간 단축, 지연 감소, 안정성 향상 등

요약 비교

버전	메시지 형식	기반 프로토콜	지속 연결	멀티플렉싱	헤더 압축	서버 푸시	특징 요약
HTTP/1.1	평문(Text)	TCP	✅	❌	❌	❌	전통적 구조, 여전히 많이 사용됨
HTTP/2	바이너리	TCP	✅	✅	✅	✅	성능 대폭 향상, 병렬 처리 가능
HTTP/3	바이너리	UDP (QUIC)	✅	✅	✅	✅	빠른 속도, 연결 성능 향상

HTTP 메시지 구조

HTTP 메시지는 시작라인, 필드라인(헤더), 메시지 본문으로 구성

시작라인(줄바꿈)
필드라인(줄바꿈) (0개 이상)
(줄바꿈)  
메시지 본문 (선택적)

📌 요청 메시지 / 응답 메시지

HTTP는 요청/응답 기반 프로토콜이기 때문에 두 종류의 메시지가 존재
- 요청 메시지: 클라이언트 → 서버
- 응답 메시지: 서버 → 클라이언트

시작라인을 통해 요청/응답을 구분할 수 있음

📌 시작라인 구성

요청라인 형식: 메서드 (공백) 요청대상 (공백) HTTP 버전 (줄바꿈)
상태라인 형식: HTTP버전 (공백) 상태코드 (공백) 이유구문(선택적) (줄바꿈)

요청라인

메서드(method): 클라이언트가 서버의 자원에 대해 수행할 작업의 종류
요청 대상(request-target): 요청을 보낼 서버의 자원을 명시. 일반적으로 쿼리 문자열이 포함된 URL의 path가 명시
- 예시1: http://example.com/hello?q=network → /hello?q=network
- 예시2: http://example.com/ → /
HTTP 버전: 사용된 HTTP 버전 HTTP/<버전> 형식 → HTTP/1.1

상태라인

HTTP 버전: 사용된 HTTP 버전 HTTP/<버전> 형식 → HTTP/1.1
상태 코드(status code): 요청에 대한 결과를 나타내는 3자리 정수
이유 구문(reason phrase): 상태 코드에 대한 문자열 형태의 설명

HTTP/1.1 200 OK
HTTP/1.1 404 Not Found

📌 필드라인 (헤더)

HTTP 헤더: HTTP 메시지 전송과 관련한 부가 정보이자 제어 정보
일반적으로 하나의 HTTP 메시지에는 여러 헤더가 포함되어 있음

형식: 헤더이름: 헤더값
Content-Type: text/html
Content-Length: 648

HTTP 메서드와 상태 코드

HTTP 메시지에서 가장 중요한 부분은 요청 라인과 상태 라인이 명시되는 시작 라인, 그리고 헤더가 명시되는 필드 라인

HTTP 메서드

1️⃣ GET
자원을 조회할 때 사용

가장 많이 사용되는 메서드
브라우저에서 웹페이지를 띄울 때 사용하는 메서드
요청 메시지에 메시지 본문 없음
응답 메시지에는 요청한 자원(HTML 등)이 포함

GET /example-page HTTP/1.1  
Host: www.example.com  
Accept: */*

HTTP/1.1 200 OK  
Content-Type: text/html  
Content-Length: 648  

<!DOCTYPE html>
<html>
  <head><title>Example Page</title></head>
  <body><h1>Hello, World</h1></body>
</html>

2️⃣ HEAD
자원에 대한 메타 정보만 확인할 때 사용

GET과 거의 동일하지만 응답 본문이 없음
자원의 존재 여부나 크기, 타입 확인 등에 활용

HEAD /example-page HTTP/1.1  
Host: www.example.com  
Accept: */*

HTTP/1.1 200 OK  
Content-Type: text/html  
Content-Length: 648

3️⃣ POST
서버에 새로운 자원을 생성하거나, 작업을 요청할 때 사용

메시지 본문에 데이터를 담아서 서버로 전송
자원 생성 시 응답 코드로 보통 201 Created를 반환
Location 헤더를 통해 생성된 자원의 위치를 전달

POST /posting HTTP/1.1  
Host: example.com  
Content-Type: application/json  

{
  "Id": 1,
  "Title": "제목 제목",
  "Contents": "내용 내용 내용"
}

HTTP/1.1 201 Created  
Content-Type: application/json  
Location: /posting/1  

{
  "Id": 1,
  "Title": "제목 제목",
  "Contents": "내용 내용 내용"
}

4️⃣ PUT
서버의 자원을 전체 덮어쓰기할 때 사용

요청 본문 전체를 기존 자원에 대체
기존 필드가 사라질 수 있음 → 주의 필요

기존 자원

{
  "Id": 1,
  "Title": "오늘도 즐거운 날입니다",
  "Contents": "재미있는 글 보고 가세요~"
}

PUT 요청

PUT /posting HTTP/1.1  
Host: example.com  

{
  "Id": 1,
  "Title": "수정된 제목입니다"
}

결과

{
  "Id": 1,
  "Title": "수정된 제목입니다"
}

→ "Contents"는 사라짐 (전체 덮어쓰기)

5️⃣ PATCH
자원을 부분 수정할 때 사용

변경하고자 하는 필드만 포함하여 보냄
수정 대상만 업데이트되므로 PUT보다 안전하고 효율적

PATCH /posting HTTP/1.1  
Host: example.com  

{
  "Title": "수정된 제목입니다"
}

결과

{
  "Id": 1,
  "Title": "수정된 제목입니다",
  "Contents": "재미있는 글 보고 가세요~"
}

6️⃣ DELETE
자원을 삭제할 때 사용

삭제할 자원의 경로를 명시하여 요청
응답 본문이 없는 경우도 많음

DELETE /texts/a.txt HTTP/1.1  
Host: example.com

HTTP 메서드에 대한 동작 정의는 서버 개발자의 몫
같은 URL이어도 메서드별로 전혀 다르게 동작 가능함
예: /list에 대해 GET은 목록 조회, POST는 새 항목 추가 등
PATCH를 지원하지 않도록 설계할 수도 있음

HTTP 상태 코드

상태 코드는 요청의 결과를 나타내는 3자리의 정수

1️⃣ 200번대: 성공 상태 코드
200번대 상태 코드는 요청이 성공했음을 의미

2️⃣ 300번대: 리다이렉션 상태 코드
300번대 상태 코드는 리다이렉션과 관련된 상태 코드
리다이렉션: 클라이언트가 요청한 자원이 다른 곳에 있을 때 다른 곳으로 요청을 이동시키는 것을 의미

클라이언트가 요청한 자원이 다른 URL에 있을 경우, 서버는 리다이렉션 관련 상태 코드와 함께 응답 메시지의 Location 헤더를 통해 요청한 자원이 위치한 URL을 안내해줄 수 있음

영구적 리다이렉션: 자원이 완전히 새로운 곳으로 이동하여 경로가 영구적으로 재지정되는 것을 의미
- 어떤 URL에 요청을 보낸 결과로 영구적인 리다이렉션 관련 상태 코드를 응답받았다면 요청을 보낸 기존의 URL은 기억할 필요가 없음
일시적 리다이렉션: 자원의 위치가 임시로 변경되었거나 임시로 사용할 URL이 필요한 경우에 주로 사용
- 어떤 URL에 대해 일시적인 리다이렉션 관련 상태 코드를 응답받았다면 요청을 보낸 기존의 URL을 기억해야함

3️⃣ 400번대: 클라이언트 에러 상태 코드
400번대 상태 코드는 클라이언트에게 잘못이 있음을 나타내는 상태 코드

401은 인증을 요구하는 상태 코드이고, 403은 권한을 요구하는 상태 코드

인증: 자신이 누구인지를 증명하는 작업
권한: 인증된 주체에게 허용된 작업

4️⃣ 500번대 상태 코드
500번대 상태 코드는 서버에게 잘못이 있음을 나타내는 상태 코드

사실 500번대 상태 코드의 대부분은 요청을 처리할 수 없음을 나타냄
서버에 어떤 문제가 발생했을 때, 익명의 다수 사용자에게 로그를 비롯한 문제의 발생 원인을 상세히 공개하는 것은 보안상 좋지 않기 때문에 보통 서버 문제를 가리키는 상태 코드는 500으로 통칭하는 경우가 많음
다만, 서버와 클라이언트 사이에 위치한 중간 서버가 잘못된 응답을 받았을 경우는 502 응답

HTTP 주요 헤더

HTTP 헤더 종류는 모두 나열하기 어려울 정도로 다양함

요청 메시지에서 주로 활용되는 HTTP 헤더

1️⃣ Host
요청을 보낼 호스트가 명시되는 헤더
도메인 네임이나 IP 주소로 표현되며, 포트 번호가 포함될 수도 있음

GET /hypertext/WWW/TheProject.html HTTP/1.1
Host: info.cern.ch
...

2️⃣ User-Agent
요청 메시지를 보낸 클라이언트의 프로그램과 관련한 정보가 명시

User-Agent 헤더를 통해 HTTP 요청 메시지를 보낸 클라이언트의 접속 수단(대표적으로 웹 브라우저)을 유추할 수 있음

3️⃣ Referer
클라이언트가 요청을 보낼 때 머무르던 URL이 명시
이를 통해 클라이언트의 유입 경로를 파악할 수 있음

Referer: https://daum.net

응답 메시지에서 주로 활용되는 HTTP 헤더

1️⃣ Server
HTTP 응답 메시지를 보내는 서버 호스트와 관련된 정보가 명시

Server: Apache/2.4.1 (Unix)

유닉스 운영체제에서 동작하는 아파치 HTTP 서버에서 응답 메시지를 보냈음을 알 수 있음

2️⃣ Allow
처리 가능한 HTTP 헤더 목록을 알리기 위해 사용
Allow 헤더는 상태 코드 405를 응답할 때 함께 사용할 수 있음

3️⃣ Location
클라이언트에게 자원의 위치를 알려 주기 위해 사용
주로 리다이렉션이 발생했을 때나 새로운 자원이 생성되었을 때 사용됨

요청과 응답 메시지 모두에서 활용되는 HTTP 헤더

1️⃣ Date
메시지가 생성된 날짜와 시각에 관련된 정보를 담은 헤더

Date: Tue, 15 Nov 1994 08:12:31 GMT

2️⃣ Content-Length
메시지 본문의 바이트 단위 크기(길이)를 표현하기 위해 사용

Content-Length: 123

3️⃣ Content-Type, Content-Language, Content-Encoding
이 3개의 헤더는 메시지 본문이 어떻게 표현되었는지와 관련된 헤더라서 표현 헤더라고도 부름

Content-Type: 메시지 본문에서 사용된 미디어 타입

Content-Language: 메시지 본문에 어떤 자연어가 사용되었는지를 나타냄
- 언어 태그로 명시되며, 언어 태그는 하이폰으로 여러 서브 태그가 구분된 구조를 따름
- 첫 번째 서브 태그에는 특정 언어를 나타내는 언어 코드가 명시
- 두 번째 서브 태그에는 특정 국가를 나타내는 국가 코드가 명시
- en-US 은 미국에서 사용하는 영어를 의미

<첫 번째 서브 태그>
<첫 번째 서브 태그> - <두 번째 서브 태그>
<첫 번째 서브 태그> - <두 번째 서브 태그> - <세 번째 서브 태그>

Content-Encoding: 메시지 본문을 압축하거나 변환한 방식이 명시
- 효율적인 송신을 위해 메시지 본문이 압축/변환 될 수 있음
- 메시지 본문은 여러 번 압축/변환될 수 있으며, 이 경우 압축/변환된 순서대로 명시됨

Content-Encoding: gzip
Content-Encoding: br

// 여러 인코딩이 사용된 경우
Content-Encoding: deflate, gzip

4️⃣ Connection
HTTP 메시지를 송신하는 호스트가 어떠한 방식의 연결을 원하는지 명시

keep-alive: 지속 연결을 희망함을 의미
close: 연결 종료를 희망함을 의미

Connection: keep-alive
Connection: close

참고: 북스터디 - 이것이 취업을 위한 컴퓨터 과학이다 (Chapter 5-5)

눈치없어

dock 사이즈 다르잖아

이전 포스트

[CS] 전송 계층 - TCP / UDP

다음 포스트