과거에는 HTTP의 데이터를 Entity라고 정의 해둠.
HTTP 헤더에는 Entity 바디의 정보를 가지고 있엇음
HTTP 바디의 메시지 본문은 엔티티 본문을 전달하는데 사용
엔티티 본문은 요청이나 응답에서 전달하는 실제 데이터를 뜻함
엔티티 헤더에는 엔티티 본문을 해석할 수 있는 정보를 제공해줫음

그러나 HTTP 표준이 바뀜

바뀐 HTTP 표준에서는 엔티티라는 개념이 사라짐
엔티티라는 개념이 사라지고 대신 표현이라는 개념으로 데이터를 말함
표현이라는 개념은 요청이나 응답에서 전달할 실제 데이터를 뜻함
표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공해줌

예를들어 어떤 GET요청이 들어왔을때 응답 HTTP의 바디부분에 데이터를 넣어서 응답을 보낸다고 생각했을때, 그 바디메시지 부분에 들어가있는 데이터는 HTML형식 일수도 있고 데이터만 전달하는 JSON일수도 있음.

즉 실제 데이터를 HTML이든 JSON이든 바디메시지 본문에 들어가있는 어떠한 형태로 표현해서 응답을 함

어떤 리소스를 이렇게 이러이러한 방식으로 표현할 것이다(표현 메타데이터)를 HTTP헤더 부분에 정의 해놓고 실제로 표현한 데이터를 HTTP바디 부분에(표현 데이터) 리소스를 표현한다.

헤더의 정보를 조금더 살펴보자

HTTP 헤더 정보

표현

HTTP헤더에는 표현 메타데이터를 정의 한다고 했다.

• Content-Type : 표현 데이터의 형식을 정의한다.
• Content-Encoding : 표현 데이터의 압축 방식을 정의한다.
• Content-Language : 표현 데이터의 자연 언어(한국어, 영어)를 정의한다.
• Content-Length : 표현 데이터의 길이

HTTP헤더는 요청, 응답 둘다 사용 가능하다.

Content-Type

표현 데이터의 형식을 설명한다.

예를 들어 Content-Type : text/html이면 본문의 표현 데이터는 HTML형식으로 표현한것이다.

협상 (콘텐트 네고시에이션)

네고시에이션이란 클라이언트가 선호하는 표현 요청을 정의하는 것이다.
즉, 클라이언트가 원하는 표현방식을 서버에 요청 하는것이다.

• Accept : 클라이언트가 선호하는 미디어 타입을 전달 요청
• Accept-Charset : 클라이언트가 선호하는 문자 인코딩 요청
• Accept-Encoding : 클라이언트가 선호하는 압축 방식을 요청

네고시에이션은 클라이언트 측에서 요청(Request)시에만 헤더에 포함에서 요청을 보낸다.

협상에는 우선순위가 있다. Quality Values(q)

• Quality Values(q) 값을 사용해서 협상 우선순위를 정할 수 있다.
• 0~1값을 가지고, 클수록 높은 우선순위
• 생략하면 default는 1이다.
• 구체적인 것이 우선 순위를 가진다.
  • 추상적인것 보다 구체적으로 명시 해준것을 우선시한다.

일반 정보

• Referer : 이전 웹 페이지의 주소 정보

  • Referer를 사용해서 유입 경로 분석 가능
  • HTTP요청에서 사용

• User-Agent : 유저 애플리케이션 정보

  • 클라이언트의 애플리케이션 정보를 나타탬(웹 브라우저 정보, OS정보 등)
  • HTTP요청에서 사용

• Server : 요청을 처리하는 ORIGIN 서버의 소프르웨서 정보
  * ex) Server : Apach, Server : Nginx 등

특별 정보

• Host : 요청한 호스트 정보( 도메인 )

  • Host는 필수 정보다.
  • 요청HTTP에서 사용한다.
  • 예를들어 TCP/IP 통신을 할땐 IP로만 통신을 한다. 그런데 HTTP프로토콜을 이용해서 통신을 한다면, HTTP헤더에 서버IP에 실제 내가 요청을 보낼 도메인 주소를 Host에 정보를 표시해서 요청을 보낸다. 그러면 HTTP 요청을 받은 하나의 서버 IP에 여러개의 도메인 주소가 있어도 요청헤더에 있는 Host정보를 보고 해당 도메인으로 연결 시켜준다(가상 호스팅)

• Location : 페이지 리다이렉션

  • 웹 브라우저는 3xx응답 결과에 Location헤더가 있으면, Location위치로 자동 이동한다.

• Allow : 허용 가능한 HTTP 메서드

인증

• Authorization : 클라이언트 인증정보를 서버에 전달하는 정보다.

쿠키 !!!

• Set-Cookie : 서버에서 클라이언트로 쿠키 전달(응답)
• Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP요청시 서버로 전달

HTTP는 기본적으로 Stateless 무상태다. 클라이언트가 요청을하면 서버는 응답을 하고 연결을 끊는다.

만약 클라이언트가 어떤 도메인에서 회원가입을 하고 로그인을 했다.그런데 HTTP프로토콜은 Stateless니까 서버는 클라이언트가 최초 로그인을 했을때만 로그인을 했다고 응답을 보내고 그 뒤에 클라이언트가 로그인을 한 상태에서 서버로 요청을 보내도 서버는 클라이언트가 로그인을 한 상태인지 안한 상태인지 알 방법이 없다.

완전히 방법이 없는건 아니다. 단순무식하게 클라이언트가 요청을 보낼때 마다 쿼리파라미터에 클라이언트의 로그인 정보를 담아서 서버로 요청을 보내면된다.. 그럼 서버는 요청의 쿼리파라미터를 해석해서 아 이 요청은 어떤 클라이언트가 보낸 요청이군, 하면서 응답을 줄 수 있다.

그런데 이렇게 개발을하면 당연히 보안상의 문제도 존재하고 개발하는데 엄청난 불편함이 있을것이다.

그럴때 사용하는것이 쿠키다.

예를들어 클라이언트가 로그인 요청을 보냈다. 서버에서는 로그인이 성공적으로 됐다면 응답 헤더에 Set-Cookie 정보에 쿠키를 세팅해서 클라이언트로 응답을 보낸다.

클라이언트는 해당 응답을 받아서 클라이언트의 웹브라우저의 쿠키저장소 라는 곳에 해당 쿠키 정보를 저장 해놓는다. 그리고 해당 클라이언트에서 다음 요청을 보낼때 마다 웹 브라우저는 무조건 쿠키저장소를 뒤져서 해당 쿠키 정보를 HTTP요청 헤더에 Cookie정보에 담아서 서버로 전송한다.
그럼 서버는 요청헤더에 있는 쿠키를 보고 클라이언트의 정보를 알 수 있다.

이러한 쿠키는 보통 사용자 로그인 관리에 많이 사용된다.

쿠키 정보는 항상 서버로 전송 되기때문에 서버의 트래픽에 추가 유발이 된다. 예를 들어 쿠키가 몇백개가 되면 그 몇백개가 되는 쿠키 정보를 항상 서버로 전송한다. 이러면 아무래도 서버에서 받는 부하가 많을것이다.

그래서 쿠키는 최소한의 정보만 사용하는 것을 권장한다.
로그인을 할때 서버측에서 세션Id라는것을 만들어서 유저 정보 전부를 쿠키로 보내는게 아니라 해당 세션Id만 쿠키로 보내는 식으로 이용하는게 좋다.

캐시

캐시가 만약 없다면 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드를 받아야 한다. 인터넷 네트워크는 하드웨어 메모리나 하드 디스크보다 매우 느리다. 그럼 결과적으로 사용자는 느린 사용자 경험을 유발한다.

이런 캐시도 서버측의 응답 HTTP헤더 정보에 포함해서 클라이언트에 전송할 수 있다.
응답 HTTP헤더에 캐시정보를 포함시켜(캐시 유효시간 등) 응답을 보내면 클라이언트는 응답 바디부의 캐시데이터를 웹브라우저의 캐시저장소에 저장 해놓고 다음에 똑같은 요청을 하면 서버에서 데이터를 받아오는게 아니라 캐시 저장소에서 데이터를 꺼내서 쓴다.
물론 해당 캐시데이터는 캐시 유효시간 동안만 유지된다.

캐시 제어 헤더

• Cache-Control : 캐시 제어
  • max-age : 캐시 유쵸시간, 초 단위
  • no-cache : 데이터는 캐시해도 되지만, 항상 origin서버에 검증하고 사용
  • no-store : 데이터에 중요 정보가 있으므로 저장하면 안됨

캐시 검증 헤더와 조건부 요청 헤더

• 검증 헤더 (Validator)
  • ETag : "[캐싱할 데이터의 별칭(?)]"
  • Last-Modified : [캐싱할 데이터의 최종 수정날짜]
• 조건부 요청 헤더
  • If-Match, If-None-Match : ETag값을 사용해서 요청시 사용
  • If-Modified_since : Last-Modified 값을 사용해서 요청시 사용