[HTTP 프로토콜 강좌]#12 HTTP 요청 헤더 II - Authorization, Cookie, Expect, From, Host

지난 포스팅에 이어 오늘도 HTTP 요청헤더 2탄을 시작해 본다.
회사일, 그리고 집에 손이 필요한 아이들이 있다 보니, 한번에 많은 양을 진행하기가 벅차다.. ㅠㅠ
가급적 남는 시간을 활용하여 짬짬히 적고 있는데, 혹여.. 그럴리는 거의 없겠지만(ㅠㅠ) HTTP 프로토콜 강좌 연재를 기다리는 분이 있다면 이해를 구한다.

오늘은 다음 5가지 헤더에 대해 정리해 보려한다.

1. Authorization
2. Cookie
3. Expect
4. From
5. Host

그럼 오늘 내용 시작~!!!


1. Authorization

HTTP 프로토콜은 보안기능을 자체적으로 제공한다.
물론 HTTP에서 제공하는 보안기능이 웹어플리케이션에서 구현해서 제공하는 형태보다는 보안 수준에서 보면 상대적으로 낮다.

하지만, 그럼에도 불구하고 HTTP 에서 제공하는 수준으로도 보안성을 크게 높일수 있는것은 사실이다.

Authorization 헤더는 이때 사용되는 헤더이며, 사전적 의미와 같이 사용자를 서버에게 확인시켜줄 필요가 있을때 클라이언트가 웹서버로 전달한다.

우리는 아래와 같이 웹사이트에 접속했을때 조그마한 창으로 사용자의 계정과 비밀번호를 요구하는 것을 본적이 있을것이다.

사용자의 계정정보를 올바르게 입력해야만 정상적으로 접속이 가능할텐데, 이것이 HTTP 프로토콜 자체에서 제공하는 보안기능이다.

실제 데이터 흐름을 보면 다음과 같다.

1. 웹사이트 접속
2. 인증 정보 요구 (www-authenticate 헤더를 이용)
3. 인증정보 전송 (autorization 헤더 이용)
4. 클라이어트 요청 데이터 전송

데이터 흐름도를 실제 패킷상으로 확인한 내용이다.

패킷내용의 메시지를 좀 들여다 보면 아래와 같다.
먼저, 최초 클라이언트의 접속에 대해 서버가 "401 Unauthorized" 라는 응답과 함께 "www-authenticate" 헤더를 사용하고 있음을 아래에서 확인 해보자.

그리고 나서, 클라이언트에서 정상적으로 사용자 계정정보를 입력했을때 서버로 전달되는 요청을 보자.
바로 이때, "Authorization" 헤더가 사용됨을 볼수 있다.

Authorization 헤더에 대해 좀 정리해 보면, 

HTTP 프로토콜에서 제공하는 보안기능을 이용할 때 사용자가 계정정보를 전달하여 서버에게 확인 시켜줄 필요가 있는데, 바로 이때 Authorization 헤더가 사용된다. 

HTTP가 제공하는 Web Security에 대해서는 HTTP 헤더에 대한 포스팅이 끝나면 상세하게 다뤄보기로 하겠다. 

2. Cookie

이전 포스팅에서 다뤘듯이 웹사이트 접속에 있어 사용자의 로그인 정보를 지속적으로 유지할 필요가 있는경우 우리는 쿠키(Cookie)와 세션(Session)을 이용한다고 이야기 했었다. 

[HTTP 프로토콜 강좌]#9 HTTP 상태 유지 - 쿠키 (Cookie)와 세션(Session) -> 쿠키와 세션의 내용이 궁금하다면 클릭

Cookie 헤더는 서버에서 발급 받은 쿠키를 다시 전송하고자 할때 사용하는 헤더이다. 

아래는 실제 서비스에서의 Cookie 내용이다. 

쿠키는 이전 포스팅에서도 논했듯이, 보안성이 중요하다보니, 위와 같이 Cookie 헤더에 담긴 정보들이 암호화 되어 있음을 알수 있다. 

Cookie 의 값으로는 '쿠키변수명=쿠키값' 형식으로 표현되며, 다수의 쿠키 변수가 있을 경우는 ';(세미콜론)' 로 쿠키변수들을 구분한다.

3. Expect 

우리는 이전 포스팅에서 POST, PUT의 HTTP 요청 방식(Method)이 클라이언트가 웹서버에게 어떤 데이터를 전달하고자 할때 사용된다고 배웠다.

Expect 헤더는 이렇게 클라이언트가 웹서버에게 어떤 데이터를 전달하고자 할때, 사용되는 헤더인데, 딱 다음의 속담을 보면 이해가 쉬울것 같다

" 돌다리도 두들고 보고 건너라 "

흔히 클라이언트가 웹서버에 데이터를 전달할때, TCP 3-way handshake를 통해 세션이 맺어지면 HTTP 통신할 준비가 되었다고 보고 바로 전달하려는 데이터를 보낼것이다.




하지만, 웹서버가 클라이언트에게 전달받아서 처리할 수 있는 데이터의 사이즈가 정해져 있다고 할 경우 클라이언트는 이를 확인하고 보내야 보다 안전하고 정확하게 전달이 가능하지 않을까?

이런걸 가능케 해주는 헤더라고 이해하면 좋다.
아래 클라이언트와 웹서버간 통신하는 방식을 그려보았다.

1. 클라이언트가 전달할 데이터가 있는데, 처리 가능한지를 묻는다. (Expect 헤더 사용)
2. 서버는 가능한 경우 이를 클라이언트에게 알린다 (100 Continue)
3. 클라이언트가 데이터를 전달한다.
4. 서버는 정상적으로 처리되었음을 알린다.

Expect 헤더를 사용하면, 서버가 처리불가능한 데이터(payload)는 보내지 않게 되므로, 불필요한 네트워크 대역폭 사용의 낭비를 줄일수 있다.

다음은 webdav 서버에서 Expect 헤더를 테스트 해본 내용이다. 

webdav 서버의 upload 파일용량을 1024 byte로 제한을 해 놓은 상태에서 테스트 했으니 참고하면 좋겠다. 

클라이언트가 WEBDAV 서버에 I love you 라는 텍스트가 담긴 파일을 업로드 했다.
페이로드 사이즈가 1024 보다 작기 때문에 정상적으로 서버에 생성되었음을 응답코드(201 Created)를 통해 확인할 수 있다.

다음은 데이터 사이즈를 웹서버의 제한용량보다 크게 설정한 경우이다.

컨텐츠 사이즈를 1029 로 설정한 예이다. (웹서버에서 설정된 1024보다 높게 한 경우)
웹서버에서 100 continue 가 아닌 "413 Request Entity Too Large"라는 에러코드를 보내고 세션을 끊었다.

이렇듯, 웹서버에서 처리할 수 있는 용량을 초과할 경우 불필요한 데이터 전송이 이루어 지지 않음을 알수 있다.

4. From

From 헤더는 실제 사용자의 정보를 웹서버에게 알리기 위한 목적으로 사용되는 헤더이며, 다음과 같이 email 주소로 표시된다.

From: anoldkim@test.com

이메일 주소 자체가 개인정보라서 그런지 대부분의 HTTP 클라이언트는 더이상 이 필드를 사용하지 않는다.

From 헤더는 나도 문서상의 내용에서만 봤다. 실제 서비스에서 From 헤더가 HTTP 요청헤더로 사용된것을 본적이 없다. 일단, From 이란 헤더가 존재하고, 이메일주소가 값으로 사용된다는 정도만 알고 있자.

5. Host

이전 포스팅에서 살짝 언급한 적이 있는데.. HTTP 1.1 버젼에서 새로 소개된 헤더이다.
다시 간단히 정리를 한다면 Host 헤더가 없었을 시절 그러니까 HTTP 1.0 이 사용되던 때는 10개의 고객사 홈페이지를 운영하기 위해서는 1대의 물리적인 서버에서 운영하기 위해서는 여간 어려운 정도가 아니었다. (거의 불가능)

다음을 보자.

GET / HTTP/1.1
Accept: */*
User-Agent: Mozilla/5.0

Host 헤더가 없는 경우 위와 같은 요청이 서버로 전달 될것이다. 웹서버는 위 정보만으로 어느 회사 홈페이지로 접속했는지 알수 있는 방법이 없다.
HTTP 헤더 내용으로는 구분이 불가능하기 때문에 IP 주소로 구분할 수 밖에 없다.

한대의 물리적인 서버에 2개 이상의 NIC 포트가 있는 경우에는 포트 개수만큼의 웹어플리케이션 운영이 가능한데, 이 역시도 많은 IP 개수의 사용, 제한적인 포트 개수 때문에 효과가 있다고 볼수는 없다.

하지만, HTTP 1.1 이 등장하고, 이와 함께 Host 헤더가 HTTP 요청에 추가되면서 부터, 지금 우리가 흔히 알고 있는 가상 호스팅(Virtual Hosting) 이 가능하게 된 것이다.
즉, IP가 같아도 고객사 도메인을 모두 구분하여 처리할 수 있게 되었다.

위 HTTP 헤더에 다음과 같이 Host 정도가 포함되게 되는데....

GET / HTTP/1.1
Accept: */*
User-Agent: Mozilla/5.0
Host: www.Acompany.com

Host 헤더에는 클라이언트가 접속을 시도한 웹사이트 도메인 네임의 정보가 표시된다.
이때부터 IP 주소가 아닌 Host 헤더의 값을 가지고 고객사를 구분할 수 있게 된것이다.

IP 주소의 의미가 없어지면서 물리적인 한대의 웹서버에 여러개의 웹어플리케이션을 운영할 수 있게 되었는데, 이것이 지금의 가상 호스팅(Virtual Hosting)을 가능하게 하여 HTTP 서비스 환경 측면에서 매우 큰 변화를 가져오게 된 것이다.



끝!