HTTP Protocol 구조

Request Header

GET(요청방식*1) /test.html(경로*2) HTTP/1.1(프로토콜버전*3)
Accept: */* (응답하여 해석할 파일의 종류*4)
Referer: (호출전경로*5)
User-Agent: (브라우저의 Agent값*7)
Accept-Encoding: gzip, deflate (수신가능한 body 인코딩 종류*8)
Host: (호출할 호스트*9)

1. 요청방식 (메소드) [GET/POST]

GET

GET 메쏘드는 request URI(Request-URI)에서 지정한 어떤 정보이든간에 가리지 않고 바디(entity body)로 전달해 달라고 요청할 수 있다. request URI에서 어떤 실행 프로그램을 명시할 경우 실행 프로그램 자체가 전달되는 것이 아니라 실행 결과가 response 메시지의 entity body로 전달된다. 요구 메시지에 If-Modified-Since 헤더 필드가 포함돼 있다면 GET은 조건부 GET으로도 동작할 수 있다. 이 경우 GET이 가지는 의미는 If-Modified-Since에 의해서 지정된 일자 이후에 수정되었을 때만 전송한다. 이 조건을 이용하면 불필요한 데이타 전송을 막을 수 있을 뿐만 아니라 이미 캐시돼 있는 데이터를 사용자에게 전달해줌으로써 네트웍의 활용을 십분 높일 수 있다.

HEAD

HEAD 메쏘드는 응답 메시지의 메시지 바디 부분에 내용을 실어 보낼 수 없다는 점을 빼고는 GET 메쏘드와 같다. 말 그대로 헤더 정보만 서버에 요구하는 명령이다. 즉 클라이언트에서는 서버 자원의 여러 정보(존재여부, 권한, 최근 수정 정보)를 미리 받아 검사할 수 있다.

POST

POST 메쏘드는 request 메시지중 body에 포함돼 있는 자원을 request 메시지에 있는  URI로 넘겨주게 된다. 이 메쏘드를 사용하면 대부분 CGI 프로그램에서 도맡아 처리하므로 Content-Length만 빠뜨리지 않으면 된다. 서버가 이에 대한 정보를 확보하지 못할시에는 400(bad request) 메시지를 클라이언트에 보내게 된다. 그리고 서버가 매번 request 메시지에 대해 똑같은 응답을 할 것인지 알 수가 없으므로 클라이언트에서는 굳이 POST 메쏘드에 대한 응답을 캐싱할 필요가 없다.


HTTP 1.1에 추가된 메쏘드

OPTIONS

클라이언트가 OPTIONS로 요구 URI에서 지정한 자원을 요구하면 서버는 요구와 응답의 관계를 선택할 수 있는 권한을 클라이언트에게 부여함고 동시에 자원과 관련된 필요 사항도 결정할 수 있는 권한을 준다. 또한 서버 기능도 알아볼 수 있다. 자원을 접근할 수 있는 통신 선택 사항은 Allow 헤더 필드에 나열돼 있다. 다음은 OPTIONS 메쏘드의 예이다.

 

OPTIONS 메쏘드 요구 메시지:

OPTIONS / HTTP/1.1

Host: test.test.co.kr

 

응답 메시지 :

HTTP/1.1 200 OK

Date: Wed, 08 Oct 1997 05:32:29 GMT

Server: Apache/1.3a1

Content-Length: 0

Allow: GET, HEAD, OPTIONS, TRACE       
 

PUT

메시지 바디 부분의 데이터를 지정한 요구 URI에 저장한다. 만약 URI 자리에 이미 자원이 존재한다면 메시지의 데이터를 가장 최근 자원이라 인식하고 저장한다. 또 클라이언트는 이 URI를 통해 저장된 자원에 접근할 수 있다. FTP의 PUT 명령의 HTTP판이라고 생각하면 쉬울 것이다.

 

DELETE

서버에서 요구 URI에 지정된 자원을 지울 수 있다.

 

TRACE

요구 메시지가 최종 수신처에 도달 경로를 기록하는 루프백(loop back) 검사용으로 쓰인다. 유닉스의 'traceroute'나 윈도우 95의 'tracetr' 명령의 기능을 생각하면 된다. 즉 클라이언트의 요구 메시지가 거쳐가는 프록시나 게이트웨이의 중간 경로부터 최종 수신 서버까지의 경로를 알아낼 때 사용된다. 이와 함께 사용되는 Max-Forwards 헤드 필드에는 중간에 거쳐갈 프록시나 게이트웨이 경로의 최대수를 지정할 수 있다.

2. 경로 (URI)
URI(Uniform Resource Identifier)는 웹자원에 대한 유일무이한 이름으로 절대 URI(Absolute URI) 또는 절대 경로(Absolute PATH)로 지정할 수 있다. 절대 URI는 http://www.testsitexxx.com/test.html과 같이 프로토콜명, 호스트명 또는 IP 번호,  파일명이 모두 나온 경우이며, 절대 경로는 /test.html 과 같이 디렉토리와 파일명만 있는 경우이다. 프록시 서버에 요구 메시지를 보내는 경우는 꼭 서버명이 포함된 절대 URI를 보내야 한다.

3. 프로토콜 버전
HTTP 프로토콜의 버전은 0.9, 1.0, 1.1 등이 사용되는데 주로 1.1 이 사용된다 각 프로토콜의 버전별로 요청되는 헤더의 규약이 달라진다. 여기서 설명은 1.1 기준이다.

4.Accept
클라이언트에서 사용할 수 있는 미디어 타입을 적어준다 .

5. Referer
요구 URI로 얻은 문서의 정보가 들어가게 된다. 서버에서는 이 정보를 통해 잘못된 Back-Link나 링크를 판단할 수 있고, 상업 사이트에서는 링크된 서버를 찾아 방문자를 찾아낼 수도 있다.(->자신의 사이트가 링크된 서버를 찾을 수 있다.)

6. User-Agent
사용자 브라우저의 버전명 및 OS명등 브라우저가 기본적으로 서버에 보내는 브라우저의 정보 이다. 

8.Accept-Encoding
클라이언트에서 제공되는 인코딩 방법을 적어준다. 서버에서 인코딩이 가능하다면 메시지 바디에서 명시한 방식으로 인코딩된다. 이 헤더 정보가 없다면 HTTP에 지정된 모든 인코딩 방식을 지원하는 것으로 인식한다.

9.Host
요구하는 서버의 이름주소를 적는다. 이는 하나의 IP주소에 여러개의 이름을 가진 멀티 서버를 지원 하기 위한 헤더 필드이다. HTTP/1.1의 요구 메시지에서는 반드시 포함되야 하는 헤더이다.




Response Header

HTTP/1.1 200 OK
Server: Apache
Content-Length: xx
Transfer-Encoding: 데이터 인코딩의 타입
Content-Type: text/html; charset=utf-8

 이부분은 서버가 HTTP/1.1방식으로 응답을 했다는 내용이다. 그리고 오류코드는 200 즉 정상으로 응답을 했다는 표시이고
전송하는 컨텐츠의 길이는 XXByte이다고 알려준다. Contents-Type 은 text/html 이고 그 데이터의 캐릭터셋은 utf-8이라는것을 브라우저에게 알려준다. 

인증(Authorization)

상용자 인증에 대한 정보가 들어가는 헤더 필드로 사용자 ID와 암호가 함께 Base64로 인코딩돼  넘어오게 된다. 가령 사용자 ID아이디가 'Aladdin'이고 암호가 'open sesame'일 경우면 'Aladin:open sesame'을 Base64로 인코딩한 코드는 "QWxhZGRpbjpvcGVuIHNlc2FtZQ=="이다. 이때 주의할 점은 Base64 자체가 공개된 인코딩이므로 스나이핑 등의 해킹에는 보안상 문제가 많다는 것을 염두해 두기 바란다.

예) Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

폼(From)

자원의 생성자나 웹마스터의 전자우편 주소를 넣는 요구 헤더 필드이다.

예) From: psycho@isoft.co.kr

 

If-Modified-Since

GET 메쏘드와 같이 쓰이면 헤더 필드에 지정된 날짜보다 나중 자원만 전달한다. 그러므로 캐시된 자원을 받아올 때 제작일자를 검사 할 수 있다.

예) If-Modified-Since: Tue, 15 Nov 1994 12:45:26 GMT

 

참조(Referer)

요구 URI로 얻은 문서의 정보가 들어가게 된다. 서버에서는 이 정보를 통해 잘못된 Back-Link나 링크를 판단할 수 있고, 상업 사이트에서는 링크된 서버를 찾아 방문자를 찾아낼 수도 있다.(->자신의 사이트가 링크된 서버를 찾을 수 있다.)

예) Referer: http://www.w3.org/hypertext/DataSources/Overview.html

 

사용자 에이전트(User-Agent)

클라이언트 프로그램의 이름과 버전 정보가 들어간다.

예) User-Agent: MyWebBroswer/0.5

 

HTTP 1.1에 추가된 요구 헤더

Accept

클라이언트에서 사용할 수 있는 미디어 타입을 적어준다 .

예) Accept: text/*, text/html, text/html;level=1, */*

 

Accept-Charset

클라이언트에서 사용할 수 있는 문자 집합을 적어준다. 이 헤더가 없다면 어떤 문자라도 인식할 수 있다.

예) Accepr: iso-8859-1, unicode-1-1

 

Accept-Encoding

클라이언트에서 제공되는 인코딩 방법을 적어준다. 서버에서 인코딩이 가능하다면 메시지 바디에서 명시한 방식으로 인코딩된다. 이 헤더 정보가 없다면 HTTP에 지정된 모든 인코딩 방식을 지원하는 것으로 인식한다.

예) Accept-Encoding: compress, gzip

 

Accept-Language

클라이언트가 인식할 수 있는 언어를 적어주는데, 이때 언어의 선호를 함께 적어줄 수 있다. 다음 예는 독일어, 영국영어, 영어 순으로 언어를 받아들일 수 있다.

예) Accept-Language: da, en-gb;q=0.8, en;q=0.7

 

 

Accept 나 Accept-Charset, Accept-Encoding,Accept-Language등의 헤더 필드는 다음에 자세히 설명될 Content Neogotation에서 쓰이게 될 헤더 들이다.

 

Host : 요구하는 서버의 이름주소를 적는다. 이는 하나의 IP주소에 여러개의 이름을 가진 멀티 서버를 지원 하기 위한 헤더 필드이다. HTTP/1.1의 요구 메시지에서는 반드시 포함되야 하는 헤더이다.

If-Match : Entity Tag값을 비교해서 같다면 Method를 수행하고 다르다면 수행하지 않고 412 Precondition Failed 가 응답 메시지에 뜬다. 또 Method가 PUT인 경우 이 헤더는 무시된다.

예) If-Match: "0-556-343b9e36"

If-None-Match :Entity Tag값을 비교해서 다르다면 Method를 수행한다. If-Match 헤더와 반대 기능이다.

예) If-None-Match: "0-556-343b9e36","0-1e4-34367116"

If-Range : 클라이언트 캐시 정보를 업데이트 하기 위해 Entity Tag와 날자를 비교하는 두가지 방법 모두 쓸수 있는 헤더이다. 이 헤더의 뒤에는 Entity Tag와 날자 모두 올 수 있다.

If-Unmodified-Since : URI에 지정된 리소스가 헤더값에 지정된 날자로부터 지금까지 수정되지 안되었다면 Method를 수행하는 헤더이다.

예) If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Max-Forwards : 이 메시지가 거쳐 갈수 있는 최대 Proxy의 개수를 지정한다.

예) Max-Forwards: 7

Proxy-Authorization : 프록시 서버가 비공개인 경우 유저인증을 위한 코드가 헤더값으로 들어 간다.

Range : 지정된 URI의 자원의 일부분만 받고자 할 때 사용되는 헤더이다. 통신 프로그램들의 이어 받기 기능을 프로토콜 상에서 지원해준다고 생각 하면 된다. 성공하면 206 Partial Content 상태코드가 응답 메시지에 담겨오게 된다.

예)

Range: bytes=0-499            <- 0~499byte를 얻고자 할 때.

 

서버의 응답 메시지(Response Message)

<그림 5> 서버의 응답 메시지 구조도 

서버의 응답 메시지에는 HTTP 버전, 상태 코드, 응답 구문으로 이루어진 상태 라인(Status-Line)과 일반 헤더, 응답 헤더, 엔터티 헤더중 하나가 온 후 메시지 바디가 놓인다(일반 헤더, 응답 헤더, 엔터티 헤더가 안 올수도 있다).

 

예)

HTTP/1.1 200 OK                           <-상태 라인

Date: Wed, 08 Oct 1997 11:40:24 GMT           <-일반 헤더

Server: Apache/1.3a1                         <-응답 헤더

Last-Modified: Wed, 08 Oct 1997 11:40:06 GMT  <-엔터티 헤더

ETag: "0-1e4-343b7116"                         <-엔터티 헤더

Content-Length: 484                             <-엔터티 헤더

Accept-Ranges: bytes                           <-엔터티 헤더

Content-Type: text/html                         <-엔터티 헤더

<HTML>

<HEAD>

 

상태 코드는 응답 상태를 나타내는 3자리수로 코드의 첫자리 수에 따라 다른 의미를 갖는다.

이외에도 서버 제작자가 추가하거나 서버 애드온 프로그램이 새로운 상태코드나 응답구문을 추가한다 하더라도 첫번째 자리수는 그 역할에 맞아야 한다. 그러나 서버나 클라이언트에서 <표 3>의 모든 상태 코드를 지원할 필요는 없다.

Response Body 
응답헤더가 출력되고 CRLF가 2번 나온 후 HTTP Body(html body 아님) 가 출력이 되는데 이 것은 응답헤더의 인코딩 타입에 따라 달라지게 된다. 보통 gzip, chunked 인코딩이 사용된다. 

• GZIP 인코딩
  서버에서 HTTP BODY를 전송할때 gzip 압축방식으로 압축을 해서 전송을 한다. 주로 텍스트를 전송하는 HTTP프로토콜로서 전체적 트레픽 낭비와 전송 시간을 줄이기 위해 gzip으로 압축을 해서 전송하는 방식이다.

 

• CHUNKED 인코딩
  서버에서 데이터를 전송할때 CRLF가 나온 후 데이터의 길이를 알려준다 이때 적당한 길이만큼 8진수(HEX)로 길이를 알려준다 그만큼 데이터를 이동한 후에 또 8진수 형태의 데이터를 알려준다 이런것이 반복이 되고 마지막 0을 만날때까지 데이터를 반복한다. 데이터의 형태는 [길이]CRLF[데이터]CRLF[길이] 의 형태로 브라우저에게 데이터를 전송한다.