HTTP헤더에는 HTTP메시지에 대한 설명, 즉 메타 데이터(데이터를 설명하는 데이터)가 들어갑니다.

HTTP메시지의 바디 내용, 바디의 크기, 압축 정보, 인증, 요청 클라이언트, 서버정보, 캐시관리 등등..의 표준 헤더에는 이런 많은 정보들이 들어갈 수 있습니다.

HTTP 바디

• 메시지 본문(payload)은 표현 데이터를 전달하는데 사용
• 표현 데이터는 요청이나 응답에서 전달할 실제 데이터
• 표현 헤더는 표현 데이터의 데이터를 해석할 수 있는 정보 제공

HTTP 헤더

• General 헤더: 메시지 전체에 적용되는 정보 ex) Connection: close
• Request 헤더: 요청 정보 ex) User-Agent: Mozilla/5.0 (Macitosh; ..)
• Response 헤더: 응답 정보 ex) Server: Apache
• Entity 헤더: 엔티티 바디 정보 ex) Content-Type: text/html, Content-Length: 3423

Content-Type

표현 데이터의 형식을 설명해줍니다. 지금 HTML메시지 바디로 보내는 데이터가 어떤 형식으로 되어있는지에 대한 정보가 들어갑니다.

• text/html; charset=utf-8
• application/json
• image/png 미디어타입, 문자인코딩 등등..

Content-Encoding

표현 데이터의 압축 방식을 전달합니다. 어떻게 압축되어있는지 설명해줘야 데이터를 받는쪽에서 그에 맞게 압축을 풀 수 있습니다.

데이터를 전달하는 곳에서 압축 후 인코딩 헤더를 추가하고, 읽는 쪽에서 헤더의 정보로 압축 해제합니다.

• gzip
• deflate
• identity 등등...

Content-Language

표현 데이터의 자연 언어를 표현합니다. 가령 한글이 적용된 페이지를 원하면 이 헤더를 읽고 한글이 적용된 페이지를 줄것입니다.

• ko
• en
• en-US

Content-Length

표현 데이터의 길이를 바이트 단위로 넣어줍니다. 때문에 헤더를 읽고 옳바른 데이터를 받아왔는지 확인이 가능하겠습니다.

협상 - 클라이언트가 요청

헤더 이름	설명
Accept	클라이언트가 원하는 미디어 타입을 요청
Accept-Charset	클라이언트가 원하는 문자 인코딩
Accet-Encoding	클라이언트가 원하는 압축 인코딩
Accept-Language	클라이언트가 원하는 자연 언어

이 협상 헤더는 클라이언트가 서버에게 주문하는것 이기 때문에 서버는 있으면 주고, 없으면 안줍니다.

마치 우리가 css에서 글꼴을 적용할때처럼 해당 글꼴이 없으면 다른 글꼴이 적용되도록 여러 글꼴을 넣는것처럼 말이죠.

협상에서도 마찬가지로 서버에 원하는 타입이 없을 경우를 대비해서 여러개의 타입을 우선순위를 지정해서 넣어줄 수 있습니다.

Accept-Language: ko-KR, ko;q=0.9, en-US;q=0.8 ...

처럼 ko-KR처럼 q값(우선순위)이 없으면 default로 가장 높은 우선순위인 1로 설정되고 나머지는 q값에 따라 지정됩니다.

또한 협상헤더의 값이 구체적일수록 우선순위가 높다고 합니다.

전송 방식

전송 방식에는 4가지가 있습니다.

• 단순 정송
• 압축 전송
• 분할 전송
• 범위 전송

아무것도 하지 않고 평문으로 보내는 단순 전송, 압축을 해서 보내는 압축 전송, 서버에서 먼저 처리된 데이터들을 보내는 분할 전송, 큰 데이터를 쪼개서 보내는 범위 전송이 있습니다.

단순 전송과 압축 전송은 앞에서 봤으니 넘어가고 새로운 분할 전송부터 확인해봅시다.

분할 전송

분할 전송은 다른 전송들과 다르게 Content-Length헤더가 없습니다. 이는 클라이언트가 요청한 데이터를 서버에서 처리하면서 일정 크기만큼 먼저 만들어진 데이터를 조금씩 보내는 방법입니다. 때문에 응답으로 내려질 총 데이터의 크기를 모르기때문에 Content-Length를 넣어주지 못합니다.

분할 전송은 HTTP메시지 헤더 안에 Transfer-Encoidng: chunked(분할된)이 포함됩니다.

범위 전송

가령 클라이언트가 서버에 이미지 파일을 요청할 경우, 이미지를 한번에 전부 보내주기 보다는 조금씩이라도 먼저 보내주는 것이 UX이 좀 더 향상될것입니다.

또한 파일을 범위마다 보내다가 중간에 통신이 끊겼을 경우 처음부터 다시 요청하는것이 아니라 중간에 받지 못한 범위부터 받아올 수 있기때문에 네트워크 효율에도 좋습니다.

범위 전송은 헤더 안에 Content-Range: bytes 1001-2000/2000이라는 정보가 들어갑니다. 예시에서는 1001 번지부터 보내고 있게 되겠네요.

일반 정보

• From: 유저 에이전트의 이메일 정보(잘 사용x)
• Referer: 이전 웹 페이지의 주소(유입 경로 확인시 사용)
• User-Agent: 유저의 웹 브라우저 정보(로그를 기록해서 어떤 브라우저에서 생긴 버그인지 확인 가능)
• Server: 요청을 처리하는 Origin서버의 정보
• Date: 메시지가 생성된 날짜

특별한 정보

• Host: 요청한 호스트 정보(도메인)
• Location: 3xx 응답시 전달해서 재요청시에 사용됨
• Allow: 허용 가능한 HTTP 메서드
• Retry-After: 서비스가 언제까지 먹통인지 알려줌

HOST - 요청시 필수

GET /search?q=hello&hi=ko HTTP/1.1
**Host: www.google.com**

요청한 호스트 정보(도메인)을 헤더에 담습니다. 위의 예시에선 Google이 Host가 되겠습니다. 이 Host정보는 필수입니다.

왜나하면 하나의 성능 좋은 서버가 여러 도메인을 처리하고 있을때, 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 어떤 도메인이 최종 도착지인지 알려주기 위해 사용된다고 합니다.

우리는 URI에서 도메인명으로 검색을 하면 브라우저가 DNS서버로 가서 IP주소를 획득하고, 그 IP주소 기반으로 통신이 이뤄지는것을 배웠습니다. 하지만 IP주소만으로는 서버의 어떤 도메인인지 모르는 문제를 해결해주는 방식인것 같습니다.