김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 듣고 정리한 내용입니다.
https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC
HTTP 헤더1 - 일반 헤더
HTTP 헤더 개요
용도
HTTP의 헤더에 HTTP 전송에 필요한 모든 부가정보를 담는다. (eg. 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등)
정말 많은 표준 헤더가 존재하고, 필요 시 임의의 헤더를 추가할 수도 있다.
RFC2616(과거)
과거에는 HTTP 헤더를 크게 4가지로 분류했다.
- General 헤더: 메시지 전체에 적용되는 정보. 예) Connection: close
- Request 헤더: 요청 정보. 예) User-Agent: Mozilla/5.0
- Response 헤더: 응답 정보. 예) Server: Apache
- Entity 헤더: 엔티티 바디 정보. 예) Content-Type: text/html, Content-Length: 3423
메시지 본문(message body)은 엔티티 본문(entity body)을 전달하는 데 사용하고, 엔티티 본문은 요청이나 응답에서 전달할 실제 데이터를 의미한다. -> 쉽게 말해 메시지 본문 안에 엔티티 본문을 담아 전송한다고 생각하면 된다.
엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보를 제공한다(데이터 유형, 데이터 길이, 압축 정보 등).
그런데 1999년에 RFC2616이 폐지되고 RFC7230~7235가 등장하면서 엔티티 바디라는 용어가 사라지게 되고, 엔티티 대신 표현(Representation)이 추가되었다.
표현(Representation) = 표현 메타데이터(Representation Metadata) + 표현 데이터(Representation Data)
RFC7230(최신)
메시지 본문(=페이로드)을 통해 표현 데이터를 전달한다.
표현은 요청이나 응답에서 전달할 실제 데이터이고, 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다.
표현
- Content-Type: 표현 데이터의 형식
- Content-Encoding: 표현 데이터의 압축 방식
- Content-Language: 표현 데이터의 자연 언어
- Content-Length: 표현 데이터의 길이
표현 헤더는 전송, 응답 둘 다 사용할 수 있다.
Content-Type
미디어 타입, 문자 인코딩 등 표현 데이터의 형식을 설명한다.
예) text/html; charset=utf-8, application/json(참고로 application/json의 기본이 utf8이다.), image/png
Content-Encoding
표현 데이터 인코딩. 표현 데이터를 압축하기 위해 사용한다.
데이터를 전달하는 곳에서 압축 후 인코딩 헤더를 추가해주면 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축을 해제한다.
예) gzip, deflate, identity(압축을 안한다는 의미)
Content-Language
표현 데이터의 자연 언어를 표현한다.
예) ko, en, en-US
Content-Length
바이트 단위로 표현 데이터의 길이를 나타낸다.
Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안된다. -> 전송 코딩 안에 해당 정보들이 이미 들어가있기 때문.
콘텐츠 협상
협상은 클라이언트가 서버에게 선호하는 표현을 요청하는 것이다.
- Accept: 클라이언트가 선호하는 미디어 타입 전달
- Accept-Charset: 클라이언트가 선호하는 문자 인코딩
- Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
- Accept-Language: 클라이언트가 선호하는 자연 언어
협상 헤더는 요청 시에만 사용한다.
Accept-Language
적용 전
다중 언어를 지원하는(기본 언어가 영어이고 한국어도 지원) 서버가 있다.
클라이언트가 서버로 요청을 보낼 때 클라이언트가 한국인지 아닌지 아무런 정보가 없으면 기본값인 영어로 응답을 해준다.
적용 후
클라이언트에서 요청을 보낼 때 Accept-Language: ko를 보내면 서버에서는 기본 언어는 영어지만 한국어도 기원하기 때문에 한국어로 응답을 보내준다.
복잡한 예시
기본 언어로 독일어를 지원하고 영어도 지원하는 서버에 Accept-Language: ko를 보내면 한국어가 없기 때문에 해당 서버의 기본 언어인 독일어로 응답이 오게 될 것이다.
한국어를 지원하지 않는 서버에서 독일어보다 영어로 응답을 받고 싶을 때 필요한 것이 바로 우선순위이다.
협상과 우선 순위 1
우선 순위는 0부터 1까지 지정할 수 있고, 숫자가 클 수록 높은 우선순위를 가진다(1이 가장 우선순위가 높고, 0이 우선순위가 가장 낮다.).
우선순위가 1일 경우 생략할 수도 있다.
- ko-KR <- 우선순위 1
- ko;q=0.9
- en-US;q=0.8
- en;q=0.7
이렇게 우선순위를 지정해주면 한국어를 지원하지 않을 때에는 영어로 응답을 받을 수 있도록 서버에 요청할 수 있다.
협상과 우선순위 2
구체적인 것이 우선한다.
Accept: text/*, text/plain, text/plain;format=flowed, */*
위 처럼 보내게 되면 구체적인 것이 우선이기 때문에 아래와 같은 우선순위를 가진다.
- text/plain;format=flowed
- text/plain
- text/*
- */*
협상과 우선순위 3
구체적인 것을 기준으로 미디어 타입을 맞춘다.
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5
위 처럼 보내게 되면 구체적인 것을 기준으로 미디어 타입을 맞추기 때문에 아래와 같은 우선순위를 가진다.
Media Type | Quality | |
text/html;level=1 | 1 | text/html;level=1(우선순위 생략 시 1) |
text/html | 0.7 | text/html;q=0.7 |
text/plain | 0.3 | text/*;q=0.3 |
image/jpeg | 0.5 | */*;q=0.5 |
text/html;level=2 | 0.4 | text/html;level=2;q=0.4 |
text/html;level=3 | 0.7 | text/html;q=0.7 |
전송 방식
단순 전송
요청을 하면 미리 컨텐츠의 길이를 알고 응답 메시지에 Content-Length를 지정해 보낸다. content의 길이를 알 수 있을 때 사용한다.
압축 전송
서버에서 메시지 바디의 내용을 압축을 해서 보낸다(실제로 절반 이상 줄어드는 경우가 많음).
이 경우 Content-Encoding을 추가로 보내 클라이언트가 내용이 어떤 방식으로 압축된 것인지 알 수 있도록 해야 한다.
분할 전송
chunk란 덩어리를 뜻하는데, chunked는 덩어리로 쪼개서 보낼 것이라는 걸 의미한다.
메시지를 쪼개서 메시지는 5Byte이고 그 내용은 Hello라는 것을 보낸다. 끝났으면 0 \r\n을 보내 전송이 끝났음을 표현한다.
용량의 큰 데이터의 경우 한 번에 모두 보내려면 더 긴 시간을 기다려야 한다. 분할해서 전송하면 응답이 오는대로 바로 내용을 표시할 수 있게 된다.
분할 전송을 할 때는 쪼개서 오는 정보에 바이트 정보가 있기 때문에 Content-Length를 넣으면 안된다.
범위 전송
만약 이미지를 절반까지 받다가 서버와의 연결이 끊겼을 경우, 처음부터 다시 전송하게 되면 그 전에 보냈던 것이 아까워진다.
그래서 클라이언트는 범위를 지정해서 다시 보내달라는 요청을 보낸다.
서버에서 해당 범위의 데이터만 다시 보내면서, 응답 메시지의 헤더에 Content-Range로 해당 범위 / 끝길이를 넣어 보내준다.
'TIL' 카테고리의 다른 글
[TIL] 22.12.21 HTTP 헤더 - 캐시와 조건부 요청(1) (0) | 2022.12.22 |
---|---|
[TIL] 22.12.18 HTTP 헤더 - 일반 헤더(2) (0) | 2022.12.19 |
[TIL] 22.12.15 HTTP 메서드 활용, 상태코드 (0) | 2022.12.16 |
[TIL] 22.12.12 HTTP 메서드 (0) | 2022.12.13 |
[TIL] 22.12.04 HTTP vs HTTPS (0) | 2022.12.04 |