HTTP 웹 기본 지식 - HTTP 헤더1 일반 헤더

728x90

표현

표현은 요청이나 응답에서 전달할 실제 데이터를 말한다.

표현은 표현 헤더와 표현 데이터를 합친 말로

표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다.

표현 헤더에는 type, encoding, language, length의 정보가 들어갈 수 있다.

type은 이게 json인지 이미지인지 구별할 수 있는 정보를 제공한다.

encoding은 표현 데이털르 어떤 식으로 압축했는지에 대한 정보를 제공한다.

옵션 중 하나인 identity는 압축을 하지 않는다.

language는 데이터의 언어를 표현한다.

length는 데이터의 길이, 바이트 단위를 표현한다.

협상

협상 헤더는 클라이언트가 선호하는 표현을 요청하는 것으로, 요청시에만 사용한다.

Accept, Accept-Charset, Accept-Encoding, Accept-Language가 있다.

Accept-Language는 클라이언트가 원하는 언어로 요청하는 것이다.

요청하는 서버에서 지원하는 언어가 클라이언트가 원하는 언어와 일치하면 좋겠지만,

일치하지 않는 경우, 즉, 클라이언트가 원하는 언어를 지원하지 않을 수 있다.

그렇다면 클라이언트 입장에서는 제일 좋은게 한국어, 만약 한국어가 없다면 영어로 보고 싶다

이런 식으로 우선순위를 매겨 요청할 수 있다.

q라는 키워드를 사용하고, 우선순위는 0~1로 표현하게 된다. 1이 제일 우선순위가 높은 것이다.

ex) Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

위의 예를 보면 ko-KR은 q가 생략되있다. 이는 q=1이 생략된 것으로 가장 우선순위가 높은 것을 의미한다.

0.9 -> 0.8 -> 0.7 순으로 우선순위를 정한다.

숫자로 표현할 뿐 아니라, 구체적인 것을 우선으로 한다.

ex) Accept: text/*, text/plain, text/plain;format=flowed, */*

위의 경우

text/plain;format~ -> text/plain -> text/* -> */* 순으로 우선순위가 정해진다.

전송 방식

전송 방식에는 단순 전송, 압축 전송, 분할 전송, 범위 전송이 있다.

단순 전송

단순 전송은 컨텐츠의 길이를 알 수 있을 때 사용한다.

Content-Length를 사용해서 말이다.

압축 전송

압축 전송(gzip)하게 되면 단순 전송 때보다 용량이 확 줄어들게 된다.

Content-Encoding을 추가 정보로 넣는다.

분할 전송

위 사진을 보면 5 hello 5 world 0 \r\n이 있다.

5는 5바이트를 말하고 5바이트인 hello를 보낸 뒤, 5바이트인 world를 보내고

끝났다면 마지막에 0이라 표시하고 \r\n을 보낸다.

Transfer-Encoding을 추가 정보로 넣는다.

분할 전송은 용량이 매우 큰 것을 분할 전송한다. 보내면서 5바이트가 채워지면 보내고, 또 5바이트가 채워지면 보내고

이런식으로 전송을 하게 된다.

이 때는 content-length를 넣으면 안된다. 왜? 길이가 예상이 안되기 때문이다.

범위 전송

예를 들어 이미지를 받는다고 생각해보자.

이미지를 받는 중에 절반까지 받다가 끊겼다. 다시 요청하는데 처음부터 요청하면 용량이 아깝기 때문에

절반 부터 끝까지 범위를 지정해서 요청할 수 있게 해준다.

절반 받았으니 이어서 받고 싶다 이렇게 말이다.

일반 정보

일반 정보에는 From, Referer, User-Agent, Server, Date가 있다.

Referer는 이전 웹 페이지 주소를 나타낸다.

내가 어느 페이지에 들어가서 보면 아래의 사진과 같이 나타난다.

User-Agent는 애플리케이션 정보를 나타낸다.

어떤 종류의 브라우저에서 장애가 발생하는지 파악이 가능하다고 한다.

Server는 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보를 나타낸다.

Date는 메시지가 발생한 날짜와 시간을 나타낸다.

특별한 정보

Host

호스트는 정말 중요하다고 했다.

하나의 서버가 여러 도메인을 처리하는데 매우 필수적인 요소이다.

만약 호스트가 없을 때를 생각해보자.

하나의 서버가 있는데, 여러 개의 애플리케이션 a b c가 있다고 하자.

클라이언트가 /hello요청을 보내는데 이 /hello가 a, b, c 중 누구와 관련이 있는지 알 수가 없다.

왜?

IP로만 통신하기 때문에

그래서 호스트를 a라고 알려주면 a에 가서 /hello를 요청하게 된다.

Location

앞에서 배운 3xx의 Location이 지금 말하는 Location이다.

그 때와 똑같이 웹 브라우저가 응답 결과가 3xx이고, Location 헤더가 존재하면

Location위치로 자동 이동한다. --> 리다이렉션

물론 201 Created도 있다.

Retry-After

유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간이다.

503 Service Unavailable로 서비스가 언제까지 불능인지 알려줄 수 있다.

ex)

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT

Retry-After: 120 (초단위 표기)

쿠키

Set-Cookie는 서버에서 클라이언트로 쿠키 전달을 하는 것이고,

Cookie는 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달한다.

/welcome으로 요청했을 때, 안녕하세요 손님이라고 응답이 오고,

로그인을 한 뒤 /welcome으로 요청해도 똑같이 안녕하세요 손님이라는 응답이 오게 된다.

쿠키가 없다면 위와 같은 상황에서 서버는 로그인한 사용자인지 아닌지 구분할 수 없다.

http는 무상태 프로토콜이므로 요청과 응답을 주고받으면 연결이 끊어져서 기억을 못한다.

위를 해결하려면 요청할 때 사용자 정보를 다 포함해서 요청 메시지를 보내야하는데, 이는 매우 심각한 문제를 초래할 수 있다.

그래서 쿠키가 만들어졌다.

로그인을 하면 서버에서 Set-Cookie를 이용하여 쿠키를 전달하고, 클라이언트에서 쿠키를 쿠키 저장소에 저장한다.

그리고 요청을 보낼 때마다 Cookie: user OOO을 요청하게 된다.

모든 요청에 쿠키 정보가 자동 포함된다.

하지만 쿠키 정보는 항상 서버에 전송되기 때문에 모든 쿠키를 다 저장하고 그럴 때마다 쿠키를 보내게 되면

트래픽을 유발할 수 있다.

방법은 여러가지가 있지만 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지라는 것이 있다.

또한, 쿠키에게 생명주기를 설정하여 삭제를 하는 것이다.

만료일을 주거나, 시간을 할당하여 해당 만료일이 되거나 시간이 0이나 음수를 지정하면 쿠키가 삭제된다.

여기서 세션 쿠키와 영속 쿠키로 나눌 수 있다.

세션 쿠키는 만료 날짜를 생략하면 브라우저 종료시 까지만 유지되고,

영속 쿠키는 만료 날짜를 입력하면 해당 날짜까지 유지가 된다.

쿠키에 도메인을 domain=example.org와 같이 명시하면,

example.org와 dev.example.org도 쿠키 접근이 가능하게 된다.

그러나 생략하게 되면 example.org에서 쿠키를 생성할 시,

example.org에서만 쿠키 접근 가능하고, dev.example.org는 쿠키 미접근이다.

출처 : 인프런 모든 개발자를 위한 HTTP 웹 기본 지식 (김영한 강사님)