저번 게시글에서는 HTTP Method에 대해서 알아보았다.
여기부터는 HTTP의 Header에 대해 다뤄보자.

HTTP Header

기본적으로, HTTP 전송에 필요한 모든 부가정보를 담는다.
매우매우 많은 표준 헤더가 있으며, 필요 시 커스텀도 가능하다.

표현

표현 Header은 Request, Response 둘 다 사용되며,
Body에 어떤 Data가 포함되는 지에 대해 설명해준다.

  • Content-Type: 표현 Data(Response Body)의 형식
    • text/html; charset=utf-8
    • application/json
    • image/png
  • Content-Encoding: 표현 Data의 압축 방식
    • Data를 읽는 쪽에서 Encoding 정보로 압축을 해제한다.
    • gzip
    • deflate
    • identity
  • Content-Language: 표현 Data의 자연 언어
    • ko
    • en-US.. 등등
  • Content-Length: 표현 Data의 길이
    • 전송 코딩(Transfer Coding)을 사용할 땐 쓸 수 없다.

협상(Contents Negotiation)

Client가 선호하는 표현을 요청할 수 있다.
우선순위를 직접 설정할 수 있으며, 구체적인 협상 정보를 우선시 한다.

  • Accept: Client가 선호하는 Media Type 전달.
  • Accept-Charset:
  • Accept-Encoding:
  • Accept-Language: Client가 선호하는 언어를 전달한다.
    • Accept-Language: ko-KR, ko;q=0.9, en-US;q=0.8
    • 위와 같이 협상의 우선순위를 정할 수 있다.
    • 생략 시에는 1(최고 우선순위)로 설정 된다.

전송 방식

Data를 전송하는 여러가지 방식을 정할 수 있다.

  • 단순 전송 : Content의 길이를 알 때 그냥 모두 전송하는 것이다.
    • Content-Length: Header가 존재할 때 사용.
  • 압축 전송 : Content를 압축을 시켜서 전송한다.
    • Content-Encoding: gzip Header가 필요하다.
  • 분할 전송 : 보낼 Data를 덩어리 덩어리로 잘라서 보낸다.
    • Transfer-Encoding: chunked Header가 반드시 필요하다.
  • 범위 전송 : Data를 전송하다 끊겼을 때, 끊긴 부분부터 다시 요청한다.
    • Content-Range: bytes 1001-2000 Header가 반드시 필요하다.

일반 정보

  • From : User-Agent의 이메일 정보를 담는다.
    • 일반적으로 잘 사용되지 않는다.
    • 검색 엔진 같은 곳에서 주로 사용한다.
    • 요청에서 사용한다.
  • Referer : 이전 Web page의 주소를 담는다.
    • 현재 요청된 페이지의 이전 페이지의 주소이다.
    • Referer는 유입 경로 분석에 매우 많이 쓰인다.
    • 요청에서 사용한다.
  • User-Agent
    • 유저의 Application 정보를 담는다.
    • Web browser의 정보 등등..
    • 어떤 종류의 브라우저에서 장애가 발생하는 지 파악이 가능하다.
    • 요청에서 사용한다.
  • Server
    • 요청을 처리하는 Origin 서버의 소프트웨어 정보이다.
    • ex) Server: Apache/2.2.22(Debian)
    • ex) server: nginx
    • 응답에 쓰인다.
  • Date
    • 메시지가 발생한 날짜와 시간을 담는다.
    • 응답에서 사용한다.

특별한 정보

  • Host : 요청한 호스트의 정보(Domain)
    • 필수 조건이다!
      • 하나의 IP에서 여러개의 Domain을 쓰는 경우도 존재하기 때문이다.
      • 그래서 같은 IP라도 Host Header로 구분을 하기 위해서 필수 조건이 되었다.
    • 요청에 사용된다.
  • Location : 리다이렉션 위치를 지정하는 헤더.
    • 3XX의 응답 결과가 발생했을 때, 여기로 리다이렉트한다.
    • 201 Created에서도 새로 등록된 리소스의 URI로 쓰인다.
  • Allow : 허용 가능한 Method의 종류를 명시한다.
    • 405 Method Not Allowed 에서 응답에 반드시 포함해야 한다.
  • Retry-After : User-Agent가 다음 요청까지 기다려야 하는 시간이다.
    • 503 Service Unavailable 응답에 포함될 수 있다.
    • ex) Retry-After: Fri, 31 Dec 1999 23:59:59 GMT (날짜식)
    • ex) Retry-After: 120 (초단위 표기)

인증

  • Authorization : 클라이언트 인증 정보를 서버에 전달한다.
    • ex) Authorization: Basic (인증값)
  • WWW-Authentication : 리소스 접근 시 필요한 인증 방법을 정의한다.
    • 401 Unauthorized 응답과 함께 사용한다.

쿠키

HTTP는 무상태이고 비연결성을 갖기 때문에, 서버 단에서는 요청을 다시 받았을 때
내가 로그인을 했는지 알 수가 없다.
따라서 요청에 사용자의 정보를 계속 포함시켜서 요청을 해야만 하는데..
이는 보안 상의 문제도 발생하고 개발자의 입장에서는 매우 힘들어진다.

쿠키란, 위의 문제를 해결하기 위해서 등장했다.
최초에 로그인을 했을 때, Web browser의 쿠키 저장소에 서버가 응답으로 보낸 쿠키를 저장을 해놓는다.
그러면 Web browser은 매 요청마다 이 쿠키를 꺼내서 Header에 담아 서버에 전달한다!

  • Set-Cookie : 서버에서 Client로 쿠키를 전달한다.
    • 응답에 사용한다.
    • expires=Sat, 26-Dec-2020 04:39:21 GMT 로 생명주기를 정할 수 있다.
    • max-age = 3600으로 초단위로 정할 수도 있다.
    • 세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료 시 까지 유지된다.
    • 영속 쿠키 : 만료 날짜까지 쿠키가 유효하다.
  • Cookie : Client가 서버에서 받은 쿠키를 저장하고, 요청 시 서버로 보낸다.
    • 요청에 사용한다.

HTTP Cache

HTTP에서도 캐시를 사용해서 더 빠르게 리소스를 반환 받을 수 있다.
캐시가 없다면, Data가 바뀌지 않아도 요청을 받을 때 마다 매번 리소스를 계속 보내야 한다.
사용자 입장에선 매우 느리게 느껴진다!

  • Cache-control : 캐시가 유효한 시간을 정할 수 있다.
    • ex) max-age=60 60초간, 캐시 저장소에 응답 결과를 저장한다.
    • 다음 요청을 보내기 전에, 캐시 저장소에 같은 데이터가 있으면 요청을 보내지 않는다.
    • 캐시 유효 시간이 초과되면, 서버를 다시 조회하고 캐시를 갱신해야 한다.
      • 그런데 이 때도, 데이터가 변경되지 않았다면? 굳이 또 다운받을 필요가 없다.
      • 서버와 Client 둘의 데이터가 차이가 없음에 대한 검증이 필요하다!
      • Last-Modified: 2020.11.10 10:00:00으로 최종 수정일을 저장한다.
      • if-modified-since: 2020.11.10 10:00:00라고 서버에 요청을 보낸다.
      • 그럼 서버에서 Data 최종 수정일을 확인한 뒤 둘이 같으면 304 Not Modified 응답!
        • 이 응답을 받을 시, max-age를 갱신해서 캐시 재사용이 가능해진다.
      • 이 때, 서버는 Body를 제외하고 Header만 보낸다. 네트워크 부하가 매우 감소!
  • If-None-Match : if-modified-since의 단점을 보완하기 위해 등장했다.
    • 시간으로 검증하는 것은, 1초 미만의 단위로 캐시 조정이 불가능하다.
      • 그리고, 날짜 기반의 정해진 로직 밖에 쓸 수 없다.
      • 그리고 데이터를 수정해서 날짜가 다르지만, 결과는 같은 데이터라면?
    • 위 단점을 보완하기 위해 ETag라는 Hash 값을 사용한다.
      • 데이터가 변경이 될 때만, ETag 값을 새로 변경을 해준다.
    • 단순하게 ETag 값이 같으면 304 Not Modified를 보내며, Header만 응답에 보낸다.
    • 캐시 제어 로직을 서버에서 완전히 관리할 수 있다.
  • 사진 및 자료 출처 : [김영한의 HTTP 웹 기본 지식]https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard)