HTTP 프로토콜 집중탐구[1]
2016.07.18 10:55
HTTP 프로토콜 집중탐구[1]
신고합니다! HTTP 1.1(1)
프로토콜 집중탐구의 첫 순서로 얼마전 신고식을 마친 웹프로토콜의 대명사 HTTP 1.1을 초대했다. HTTP 1.0를 보안(완?)하며 HTTP 1.1은 새로운 모습, 강력한 파워로 인터넷 프로그래머를 휘어잡고 있다고 하니 2회에 걸쳐 탐방하는 시간을 가져 보겠다. 이번호에서는 변모된 모습을 살펴보겠다. 그럼 프로토콜을 향해 돗(닻?돛?)을 올려보자.
□ 이경만(아이소프트)
http://kmh.ync.ac.kr/java2/nulpulum/servlet/http11_1.html
W3C 가 97년 7월에 HTTP 1.1의 8번째 권고안을 발표하며, HTTP가 성숙한 모습으로 거듭 태어났다. HTTP 1.1은 기존의 1.0보다 빠르면서도 더 효율적으로 변모하며 웹개발자들의 마음을 설레이게 했다. 이로써 HTTP는 일정하지 않지만 2배에서 8배정도로 전송속도가 향상되며 네트웍 트래픽을 감소시켜 인터넷 환경에서 더욱 강력한 우위를 확보하게 되었다. 이에 발맞춰 HTTP 1.1을 지원하지 않는 웹브라우저가 전무할 정도로 인기가 하늘을 찌를 지경이다(넷스케이프 4.0,익스플로러 4.0 심지어 핫자바 1.1도 지원하고 있다). 서버 시장에서도 현재 나오는 새버전의 웹서버들은 HTTP 1.1을 일부 또는 전체를 지원 하며 빠르게 시장에 수용되고 있는 실정이다.
이런 상황에서 이번 2회에 걸친 연재는 HTTP 1.1의 기능과 구조를 알아보고, 간단한 서버 애플리케이션을 구현해 보도록 하겠다. 전초전으로 이번호에서는 다소 지루한 감이 있지만 ~~~~진다고 HTTP의 기반인 요구 응답 메시지를 자세히 살펴보고, 다음호에는 메시지를 기반으로 구현되는 여러 가지 기능들과 실제 구현과 연관지어 설명하겠다.
HTTP 1.1의 속도 향상 노하우
전 송속도는 사용자에게 밀접한 영향을 미치는 요소로 왜 빨라 졌을까라고 생각해 보기전에 왜 느려지는가를 프로토콜 구조적 입장에서 생각해 본다면 답은 의외로 간단하다. HTTP는 문서의 참고를 위해 고안된 단순한 프로토콜이어서 한 번의 요구와 한 번의 응답 후에는 연결을 끊어 버린다. 가령 그림이 20개정도 포함된 문서라면 20번의 요구와 응답을 반복해가며 그림을 받아온다. 시간이 돈을 통하는 세상에 얼마나 시간 낭비인가. 20번의 연결과 연결해제를 위해 자원을 허비하는 것이다. 웹개발자라면 자주들르는 넷스케이프나 마이크로소프트 사이트는 한 페이지당 그림 수가 20∼30개인 것을 보았을 때 이는 돈 낭비가 아닐수 없다. 'HTTP가 인터넷을 망하게 한다.', '깡패프로토콜이다' 라는 말도 이쯤되면 농담만이 아니라는 것을 체감할 수 있을 것이다. 이 해결하기 위해 '홈페이지에서 그림을 줄이자', '텍스트로만 만들자.' 라는 캠페인도 한때 벌여 졌지만, 인터넷 트래픽을 해결하는 좋은 해결책은 아니다. 그렇다면 프로토콜 차원에서는 어떤 방법이 있을까. 바로 이것이 HTTP 1.1의 숨은 비결이다.
① 연결을 유지한다.
② 전송되는 데이터를 압축한다.
③ 프록시 서버나 캐시 등을 적극 활용한다.
연결유지(persistent connection)는 HTTP 1.0에는 일부 웹서버에서만 제한된 기능이었지만 1.1에서는 기본 사항이다. **즉 1.0에서는 연결을 유지하기 위해 헤더 부분에 다른 정보를 적어줄 필요는 없게 되었다.(그것도 일부 웹서버와 일부 브라우저만이 지원하는 **이부분을 삭제 했으면 합니다. 자칫하면 오해의 소지가 많아서요 ) 따라서 연결과 해제를 위한 동작들이 줄게 되었고, 연결유지와 덧불어 파이프라이닝(Pipelining)이라는 개념도 추가되었다. 이 개념은 연결이 유지된 상태에서 요구를 보내후 응답이 오기 전에 다른 요구를 보낼 수 있는 것으로 파이프라이닝을 사용하기 전에는 요구에 대한 응답이 올 때까지 기다렸던 옛시절을 생각해 보면 괄목상대한 변화라고 할 수 있다. 파이프라이닝에서 서버는 반드시 요구 받은 순서대로 응답을 해야 하기 때문에 시간을 줄여주며, 그 수행 결과는 같게 된다. 다음은 파이프라이닝의 모식도 이다(<그림 1>).
<그림 1> 파이프라이닝 개념도
또 주시해야 할 변화가 전송데이터를 압축 방법이다. HTTP 1.0부터 나온 개념이지만 문서인 경우에는 최고 10%정도까지의 압축(률)을 허락(보장?)했 고, 이미 압축돼 있는 멀티미디어 데이터의 경우는 효과는 더욱 미미했다. 하지만 HTTP 1.1에서는 요구 메시지에서 Accept-Encoding 헤더에 사용할 수 있는 압축 방식을 적어주면 응답 메시지의 데이터는 Content-Encoding 헤더에 압축된 데이터의 압축 방식과 함께 데이터를 넘겨 주게 되므로써 여러 가지 압축 방식을 지원하게 되었다.
그 리고 프록시나 캐시를 적극 사용하기 위해서 HTTP 1.1에서는 여러 가지 헤더가 추가되었고(프록시에서의 인증, 계층적인 프록시 서버를 위한 헤더 등), 다양한 조건으로 캐시 자료와 서버 자료를 비교할 수 있게 하였다. 자 그럼 본격적으로 HTTP 1.1의 메시지에 대해 알아 보자.
메시지를 알면 HTTP가 보인다
HTTP 의 기본 구조는 클라이언트의 요구 메시지와 서버의 응답 메시지가 주축이 된다(<그림 2>). 따라서 메시지는 HTTP의 핵심이라 할 수 있다. <그림 3>은 HTTP의 일반적인 메시지 구조이다. 스타트 라인(Start Line)에는 HTTP 메시지의 기본적인 기능이 한 줄로 들어가게 되는데, 요구 메시지인 경우 요구 사항에 대한 정보(Request-Line)가, 응답 메시지인 경우 응답할 내용의 상태(Status-Line)가 들어간다(스타트 라인만으로 구성된 HTTP 메시지도 있다). 메시지 헤더는 HTTP 메시지의 부가적인 정보를 담고있는 부분으로 날짜, 프로그램 이름과 버전 정보, 쿠키와 캐시에 대한 정보 등이 들어있다. 헤더에는 '헤더이름'+':'+'헤더정보'+'CRLF'의 형태로 구성돼 있으며, 하나의 HTTP 메시지에는 아무 정보도 없어도 된다.(-> 하나의 HTTP 메시지에는 헤더정보가 하나도 없어도 된다)
그 리고 요구, 응답 메시지에서 모두 쓰이는 일반 헤더(General Header), 요구 헤더(Request Header), 응답 해더(Response Header) 그리고 메시지 바디(Message Body) 부분의 정보와 연관돼있는 엔터티 헤더(Entity Header)로 나뉜다. 메시지 바디는 요구나 응답에 필요한 내용이 들어가는 곳으로 예를 들자면 요구 메시지의 CGI-From 데이터, 응답 메시지의 HTML 문서 등을 말한다.
HTTP 는 Telnet 명령으로 간단히 테스트 할 수 있다. 'Telnet 호스트명 포트명(80번 포트가 기본 HTTP의 포트이다.)'로 HTTP의 요구 메시지를 보내면 그에 대한 응답 메시지를 화면에 뿌려준다(<화면 1>).
<화면 1> 텔넷의 응답 메시지
|
telnet www.test.co.kr 80 ?? GET /test.html HTTP/1.1 ?? Host: www.test.co.kr ?? ?? HTTP/1.1 200 OK Date: Sun, 12 Oct 1997 01:10:36 GMT Server: Apache/1.3a1 Last-Modified: Thu, 02 Oct 1997 00:39:45 GMT ETag: "58299-848-3432ed51" Content-Length: 2120 Accept-Ranges: bytes Content-Type: text/html
<html><body bgcolor=white> TEST PAGE ................................... |
<그림 2> 클라이언트의 요구 메시지와 서버의 응답 메시지
<그림 3> 일반적인 HTTP 메시지
일반 헤더 (General Header)
일반 헤더는 요구와 응답 메시지에 모두 적용되며, 메시지 바디의 내용에 영향을 주지않는 메시지 전송 관련 헤더이다.다음은 HTTP 1.0에 있는 일반 헤더이다.
Date : 서버나 클라이언트의 현재 시간을 알려준다.
예) Date: Tue, 15 Nov 1994 08:12:31 GMT
Pragma : HTTP 1.0에서는 캐시 등을 제어하기 위해 사용됐으나 1.1에서는 사용되지 않는다.
다음은 HTTP 1.1에 새롭게 선보인 기능으로 캐시 제어, 프로토콜 버전 관리 및 연결 상태를 끊기위한 헤더 등이 추가됐다.
캐시 컨트롤(Cache-Control) : 캐시에 관련된 여러 가지 사항을 제어하는 헤더로 프록시 서버와 연계돼(하여?) 많이 쓰인다. 캐시를 할 수 있는가, 무엇을 캐시 할것인가, 캐싱된 자료는 언제 업데이트 되고 지워질 것인가 등을 제어하도록 설계됐다.
연결(Connection) : HTTP 1.1은 기본적인 연결을 유지하므로 클라이언트쪽이나 서버쪽에서 연결을 끊어 버릴 필요가 있을 때 다음과 같이 Connection 헤더를 선언해주면 된다.
예) Connection: close
트랜스퍼 인코딩(Transfer-Encoding) : 메시지 바디를 압축하는 방식에 대해 적혀있다.
업 그레이드(Upgrade) : 사용하는 프로토콜을 바꾸고자할 때 사용하는 헤더 필드이다. 현재 클라이언트가 지원할 수 있는 프로토콜을 헤더값으로 해 요구 메시지에 담아 서버에 보내면 서버에서는 지원 가능한 프로토콜을 업그레이드 헤더에 담아 보내면 클라이언트가 프로토콜을 선택할 수 있다.
예) Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
경유(Via) : HTTP 메시지가 프록시나 게이트웨이 등을 통과할 때 반드시 포함해야 하는 헤더로 중개 서버(프록시,게이트웨이)의 지원 프로토콜 이름, 버전, 호스트명이 경유 헤더에 포함돼 있다.
전송되는 데이터에 대한 정보가 있는 엔터티 헤더
메시지 바디에 있는 리소스에 대한 정보가 담겨진 헤더로 요구, 응답 메시지 둘다 올 수 있는 헤더이다. HTTP 1.0에 있던 엔터티 헤더는 다음과 같다.
허락(Allow) : 메시지 바디에서 허용되하는 요구 메쏘드를 적어주는 헤더로 리소스에서 허용하지 않는 메쏘드를 요구 메시지로 보내면 '405 Method Not Allowed'로 응답 메시지를 첨가해 클라이언트에 보낸다.
예) Allow: GET ,HEAD ,OPTIONS ,TRACE
컨텐트 인코딩(Content-Encoding) : 메시지 바디의 리소스 압축방식에 대한 정보를 적어준다. 압축방식에는 gzip, compress, deflate 등이 있다.
예) Content-Encoding: gzip
컨텐트 길이(Content-Length) : 메시지 바디의 리소스 크기에 대한 정보가 바이트 단위로 들어간다.
예) Content-Length: 3495
컨텐트 타입(Content-Type) : 메시지 바디의 미디어 타입을 적어준다.
예) Content-Type: text/html
익스파이어(Expires) : 메시지 바디에 있는 자원의 만기 날짜를 적어준다. 캐시 데이터가 업데이트된 시기를 알 수 있다.예) Expires: Thu, 01 Dec 1994 16:00:00 GMT
라스트 모디파이(Last-Modified) : 가장 최근에 수정된 날짜를 적어준다.
예) Last-Modified: Thu, 01 Dec 1994 16:00:00 GMT
다음은 1.1에서 추가된 엔터티 헤더들로 멀티 서버를 위해 Content-Base를, 다국어 지원을 위해 Content-Language를, 그리고 캐시를 위해 헤더 지원이 달라지며 HTTP 사용자의 편의를 도모했다.
Content-Base : 메시지 바디에 있는 리소스의 Base URI를 적어준다.
예) Content-Base: http://www.isoft.co.kr/
Content-Language : 메시지 바디에 쓰여진 언어의 정보가 담겨져 있다.
예) Content-Language: da
Content-Location : 메시지 바디의 URI 정보가 들어간다. 캐시 정보 등을 구성할 때 필요하며 Content-Base가 생략돼 있다면 꼭 URI은 들어간다.
Content-MD5 : 전송시 발생할 수 있는 메시지 바디의 우연한 변경을 검사하기 위해 메시지 바디의 일부분을 요약한 값이다. MD5(RFC 1864) 알고리즘으로 요약한 다음 base64로 인코딩한 내용이 헤더값으로 존재한다.
Content-Range : 메시지 바디의 일부분만을 전송할 때, 즉 이어받기 기능을 이용할때 존재하는 헤더이다. 가령 5140 바이트짜리 파일중 4150번째 바이트부터 끝까지 전송한다면 다음과 같은 헤더 응답이 들어간다.
예) Content-Range: bytes 4150-5140/5140
ETag : 엔터티 태그(Entity-Tag)는 서버 자원마다 임의로 식별 태그를 만들어 붙인다. 이 태그는 해당 자원이 업데이트되기 전에는 결코 변하지 않는 값으로 캐시 정보 등을 관리할 때 더 많은 조건으로 메시지를 교환할 수 있다.
예) ETag: "0-556-343b9e36"
클아(라?)이언트 요구 메시지 (Request Message)
<그림 4> 요구 메시지의 구조도
일 반적으로 HTTP 1.0에서는 먼저 메쏘드가 온 후 URI, HTTP 버전이 놓인다. 그리고 일반 헤더(General Header)나 요구 헤더(Request Header) 또는 엔터티 헤더(Entity Header)가 순서에 관계없이 올 수도 있고, 오지 않을 수도 있다(<그림 4>). 하지만 HTTP1.1에서는 Host라는 요구 헤더(Request Header)가 반드시 따라와야 한다. 그 다음에야 메시지 바디가 필요하면 올 수 있다.
예 ) GET http://www.isoft.co.kr/helloworld.html HTTP/1.1 <-Request Line
Host: www.isoft.co.kr <-Request Header
User-Agent: MyWebBroswer/0.5 <-Request Header
이 예는 helloworld.html을 얻어오기 위해 클라이언트가 서버에 보내는 요구 메시지이다. GET은 문서를 가져오기 위한 명령이며 /helloworld.html은 가져올 문서의 URI, 그리고 HTTP 1.1은 HTTP 프로토콜의 버전이다. <Method> <URI> <HTTP Version>을 합쳐 '요구 라인(Request-Line)'이라고 부른다. 여기서 호스트(Host)는 프로토콜에서 멀티서버를 지원하기 위해 HTTP 1.1의 요구 메시지에 반드시 포함돼야한다. 즉 하나의 IP 어드레스로 여러 개의 DNS 서버에 등록돼 있는 웹서버인 경우 요구 헤더(Request Header)의 호스트부분에 다른 이름을 써주면, 여러 개의 이름으로 서비스할 수 있는 것이다. 이렇게 일거다득의 효과를 볼 수 있을 뿐만 아니라 프로그램 차원에서 구현했던 것을 프로토콜 차원에서 지원함으로써 한 단계 높은 서비스를 할 수 있게 됐다. 또 사용자 에이전트(User-Agent)에는 요구을 보낸 프로그램의 이름과 버전명이 들어있어 ~~~~~~~~~~~~~~~~. 그럼 요구 메시지를 자세히 살펴 보기로 하자.
메쏘드
요 구 메시지가 '무엇을 어떻게 해달라'고 요구하는 것이라면 '어떻게'에 해당하는 것이 메쏘드이고 '무었을'에 해당하는 것이 URI이다. 다시 말하면 메쏘드는 뒤에나오는 URI를 쓰는 방법을 기술한 것으로 프로토콜이 버전업할 때마다 새롭게 추가 되고 있다. HTTP 1.0에서 쓰던 메쏘드와 함께 1.1에서 새롭게 고개를 내민 메쏘드를 살펴보자.
HTTP 1.0부터 애용되고 있는 메쏘드
GET
GET 메쏘드는 요구 URI(Request-URI)에서 지정한 어떤 정보이든간에 가리지 않고 엔터티 바디(entity body)로 전달해 달라고 요청할 수 있다. 요구 URI에서 어떤 실행 프로그램을 명시할 경우 실행 프로그램 자체가 전달되는 것이 아니라 실행 결과가 응답 메시지의 엔터티 바디로 전달된다. 요구 메시지에 If-Modified-Since 헤더 필드가 포함돼 있다면 GET은 조건부 GET으로도 동작할 수 있다. 이 경우 GET이 가지는 의미는 If-Modified-Since에 의해서 지정된 일자 이후에 수정되었을 때만 전송한다. 이 조건을 이용하면 불필요한 데이타 전송을 막을 수 있을 뿐만 아니라 이미 캐시돼 있는 데이터를 사용자에게 전달해줌으로써 네트웍의 활용을 십분 높일 수 있다.
HEAD
HEAD 메쏘드는 응답 메시지의 메시지 바디 부분에 내용을 실어 보낼 수 없다는 점을 빼고는 GET 메쏘드와 같다. 말 그대로 헤더 정보만 서버에 요구하는 명령이다. 즉 클라이언트에서는 서버 자원의 여러 정보(존재여부, 권한, 최근 수정 정보)를 미리 받아 검사할 수 있다.
POST
POST 메쏘드는 요구 메시지중 메시지 바디에 포함돼 있는 자원을 요구 라인에 있는 요구 URI로 넘겨주게 된다. 이 메쏘드를 사용하면 대부분 CGI 프로그램에서 도맡아 처리하므로 컨 텐트 길이(Content-Length)만 빠뜨리지 않으면 된다. 서버가 이에 대한 정보를 확보하지 못할시에는 400(bad request) 메시지를 클라이언트에 보내게 된다. 그리고 서버가 매번 요구 메시지에 대해 똑같은 응답을 할 것인지 알 수가 없으므로 클라이언트에서는 굳이 POST 메쏘드에 대한 응답을 캐싱할 필요가 없다.
HTTP 1.1에 추가된 메쏘드
OPTIONS
클 라이언트가 OPTIONS로 요구 URI에서 지정한 자원을 요구하면 서버는 요구와 응답의 관계를 선택할 수 있는 권한을 클라이언트에게 부여함고 동시에 자원과 관련된 필요 사항도 결정할 수 있는 권한을 준다. 또한 서버 기능도 알아볼 수 있다. 자원을 접근할 수 있는 통신 선택 사항은 Allow 헤더 필드에 나열돼 있다. 다음은 OPTIONS 메쏘드의 예이다(<화면 2>).
<화면 2> 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 헤드 필드에는 중간에 거쳐갈 프록시나 게이트웨이 경로의 최대수를 지정할 수 있다.
요구 URI(Request URI)
URI(Uniform Resource Identifier)는 웹자원에 대한 유일무이한 이름으로 절대 URI(Absolute URI) 또는 절대 경로(Absolute PATH)로 지정할 수 있다. 절대 URI는 http://www.isoft.co.kt/index.html과 같이 프로토콜명, 호스트명 또는 IP 번호, 파일명이 모두 나온 경우이며, 절대 경로는 /test/helloworld.html과 같이 디렉토리와 파일명만 있는 경우이다. 프록시 서버에 요구 메시지를 보내는 경우는 꼭 서버명이 포함된 절대 URI를 보내야 한다.
요구 헤더 (Request Header)
<표 1>과 <표 2>를 살펴보기 바란다.
<표 1> HTTP 1.0의 요구 헤더
인증(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
<표 2> 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>의 모든 상태 코드를 지원할 필요는 없다.
상태 코드와 응답 구문(Status Code and Reason Phrase)
1xx: Informational - 요구 메시지를 받은 후 연결을 지속시키며 작업할 때.
2xx: Success - 요구 메시지를 제대로 받았을 때.
3xx: Redirection - 요구 메시지를 수행하기 위해 다른 작업이 필요할 때.
4xx: Client Error - 요구 메시지의 형식이 틀리거나 빠진 부분이 있을 때.
5xx: Server Error - 서버에 문제가 있을 때.
<표 3> 표준 상태 코드와 응답 구문
|
상태 코드 |
응답구문 |
상태코드 |
응답구문 |
|
100 |
Continue |
404 |
Not Found |
|
101 |
Switching Protocols |
405 |
Method Not Allowed |
|
200 |
OK |
406 |
Not Acceptable |
|
201 |
Created |
407 |
Proxy Authentication Required |
|
202 |
Accepted |
408 |
Request Time-out |
|
203 |
Non-Authoritative Information |
409 |
Conflict |
|
204 |
No Content |
410 |
Gone |
|
205 |
Reser Content |
411 |
Length Required |
|
206 |
Partial Content |
412 |
Precondition Failed |
|
300 |
Multiple Choices |
413 |
Request Entity Too Large |
|
301 |
Moved Permanently |
414 |
Request-URI Too Large |
|
302 |
Moved Temporarily |
415 |
Unsupported Media Type |
|
303 |
See Other |
500 |
Internal Server Error |
|
304 |
Not Modified |
501 |
Not Implemented |
|
305 |
Use Proxy |
502 |
Bad Gateway |
|
400 |
Bad Request |
503 |
Service Unavailable |
|
401 |
Unauthorized |
504 |
Gateway Time-out |
|
402 |
Payment Require |
505 |
HTTP Version not supported |
|
403 |
Forbidden |
|
|
<표 4> 응답 헤더
Location : 요구한 리소스의 URI가 변경 되었을 때 변경된 URI를 Location 헤더에 넣어 주게 된다. 넷스케입이나 인터넷 익스플로어등의 많이 쓰이는 브라우저에는 Location 정보를 얻어 자동으로 다시 요구메시지를 보내주는 기능이 있다.
예) Location: http://새로 바뀐 URI
Server : 서버 프로그램의 이름과 버전 정보가 들어 간다.
예) Server: Apache/1.3a1
WWW-Authenticate : 유저 인증이 필요한 자원을 요구했을 때 인증 메시지에 필요한 데이터와 서버가 제공하는 인증 방식을 이 헤더값으로 넘겨 주게 된다.
예) WWW-Authenticate: Basic realm="아이 소프트"
HTTP/1.1에서는 다음과 같은 응답 헤더가 추가 되었다.
Age : 클라이언트에서 요구메시지를 보낸 후 원 서버(origin Server)에서 응답 메시지를 생성하지까지의 시간이 Age이다. 이 헤더를 이용하여 지능적인 Server나 User Agent를 만들 수 있다. Age는 초단위이다.
Proxy-Authenticate : 서버가 프록시 서버일 경우 유저 인증을 요구하기 위한 헤더이다.
Public : 서버에서 지원 가능한 Method의 리스트를 헤더값으로 넘겨 준다. Allow헤더는 메시지 바디의 자원이 사용가능한 Method의 리스트라는 점이 다른 점이다.
예) Public: OPTIONS, MGET, MHEAD, GET, HEAD
Retry-After : 서버가 여러 가지 이유로 서비스가 불가능할 때 서버는 503 Service Unavailable 상태 코드를 넘겨 준다. 이때 몇초 후에 다시 요구 메시지를 보내라는 정보가 이 헤더에 담겨 진다. 또는 절대 시간으로도 시간정보가 들어 갈 수 있다.
예) Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
예) Retry-After: 120
Warning : 상태코드와 응답 구문에 추가적인 경고를 넣고 싶을 때 사용 하는 헤더.
이외에 Content-Neotation에 쓰이는 Vary헤더도 있다.
결론
이 번호에는 HTTP 1.1의 메시지에 중점적으로 살펴보았다. 메시지를 아는 것만으로는 HTTP의 실체를 파악한다고 할 수 없다(언어를 배우고 프로그램을 한 번도 짜보지 않는 것과 마찬가지이다). 하지만 언어를 알아야 버젓한 프로그램으로 만들 수 있듯 메시지가 어떻게 동작해서 서비스를 구성하는지를 알아야만 HTTP를 활용할 수 있는 것이다. 다음호에서는 Content-Neotation등 몇가지 개념적인 부분과 실제 이런 헤더와 메시지들이 어떻게 같이 쓰여 동작을 하는가를 살펴 보고 간단한 서버 프로그램를 만들어 보겠다.
참고 사이트
① http://pec.etri.re.kr/~qkim/guides.html, 김용운씨의 HTTP RFC 한글번역 문서
② http://www.w3.org/Talks/9608HTTP/
③ http://www.w3.org/Protocols/
박스기사
*******************************************
HTTP에서 염두해둬야할 기본 용어
연결 (Connection)
데이터 송수신을 위해 두 개의 응용 프로그램 사이(TCP 데이터 전송 계층)에 만들어진 가상 연결선
메시지 (Message)
HTTP 데이터 송수신의 기본 단위
요구 (Request)
HTTP 클라이언트가 서버에게 데이터를 요구하기위해 보내는 HTTP 메시지
응답 (Response)
HTTP 서버가 클라이언트의 요구에 대해 처리 결과를 알려주는 HTTP 메시지
자원 (Resource)
URI에 의해 지정되는 통신 데이터
클라이언트(Client)
HTTP 프로토콜에서는 규약에 맞춰 요구를 보내고, 서버가 보낸 응답을 수신해 처리하는 응용 프로그램
사용자 에이전트(User agent)
요구 메시지를 발생시키는 클라이언트 프로그램으로 브라우저, 로봇 등이 대표적인 사용자 에이전트의 예이다.
서버(server)
HTTP 프로토콜에서는 요구받은 HTTP 서비스를 제공해주기 위해 연결을 허용하는 응용 프로그램
원서버(origin server)
프록시 서버와 같이 중계해주는 것이 아니라 최종 데이터를 저장해두고 수신한 요구에 대해 서비스를 제공하거나, 저장 장소를 제공하는 서버
프록시(Proxy) 클 라이언트 사이에서 서버 또는 클라이언트로 동작하는 중계 프로그램. 보통 클라이언트 요구는 내부적인 동작에 의해 처리되거나, 변환을 통해 다른 서버로 전달되는데, 프록시는 중계해주기에 앞서 요구 메시지를 해석해 보고, 필요하다면 적절히 다시 만들어야 한다. 프록시는 방화벽을 통과하는 클라이언트측 통로로써, 혹은 느린 속도의 네트웍 사용자를 위한 캐시 서버로 많이 사용된다.
게이트웨이(Gate Way)
프록시와 비슷한 클라이언트와 서버 간의 중계 프로그램. 하지만 프록시와 다른 점은 클라이언트쪽에서는 게이트웨이를 거친다는 사실을 모른다
[출처] http://blog.daum.net/sadest/15771677?srchid=BR1http://blog.daum.net/sadest/15771677
광고 클릭에서 발생하는 수익금은 모두 웹사이트 서버의 유지 및 관리, 그리고 기술 콘텐츠 향상을 위해 쓰여집니다.
