HTTP?

이번 페이지에서는 HTTP에 대해서 좀 정리해 보겠습니다.

※ 아래에 기술되는 내용의 출처 : http://ko.wikipedia.org/wiki/HTTP

HTTP(HyperText Transfer Protocol)는 WWW 상에서 정보를 주고 받을 수 있는 프로토콜이다. 주로 HTML 문서를 주고 받는 데에 쓰인다. TCP와 UDP를 사용하며, 80번 포트를 사용한다. 1996년 버전 1.0, 그리고 1999년 1.1이 각각 발표되었으며, 현재 가장 널리 쓰이는 버전이 1.1이다. HTTP는 클라이언트와 서버 사이에 이루어지는 요청/응답(request/response) 프로토콜이다. 예를 들면, 클라이언트인 웹 브라우저가 HTTP를 통하여 서버로부터 웹페이지나 그림 정보를 요청하면, 서버는 이 요청에 응답하여 필요한 정보를 해당 사용자에게 전달하게 된다. 이 정보가 모니터와 같은 출력 장치를 통해 사용자에게 보여지는 것이다. HTTP를 통해 전달되는 자료는 http:로 시작하는 URL(인터넷 주소)로 조회할 수 있다.

※ 아래에 기술되는 내용의 출처 : http://moogi.tistory.com/16

1. HTTP 프로토콜 정의

CERN(유럽입자물리학연구소)에서 하이퍼텍스트 문서를 연결해서, 한 문서에서 다른 문서로의 이동을 쉽게할 수 있도록 하기 위해 만들어진, TCP/IP 애플리케이션 계층 프로토콜이다. HTTP 프로토콜은 클라이언트가 서버에게 문서를 요청하는 방식에 대해 정의되어 있다.


2. HTTP 프로토콜의 종류

  가. HTTP 0.9

HTTP의 최초 버전이며, 하이퍼텍스트 문서의 전송만을 위해 간단하게 설계되어 있다.

초기 HTTP는 HTTP의 클라이언트가 TCP(Transmission Control Protocol)을 사용해서 HTTP서버와 연결을 맺고, 클라이언트는 서버에 자원에 대한 요청(Request)을 한다. 요청을 받은 서버는 텍스트 바이트의 스트림으로 요청에 대한 응답(Response)을 하고 연결을 종료한다.

HTTP 0.9는 하이퍼텍스트 이외의 다른 타입의 데이터를 전송하지는 못했다.

  나. HTTP 1.0

HTTP의 공식적인 첫번째 표준이다. HTTP 1.0은 RFC1945 로 발표되었다. HTTP 1.0은 HTTP 0.9에 대한 하위호환성을 가지고 있다.

HTTP 1.0은 HTTP에 대한 메시지 형태와, 클라이언트의 요청과 서버의 응답을 어떻게 사용하는지 정의해 놓았다.

또한 HTTP 1.0은 하이퍼텍스트 문서뿐만 MIME(Multipurpose Internet Mail Extension)을 받아들여 다양한 형태의 자원(문서, 미디어)을 다룰 수 있도록 HTTP를 확장하였다.

그러나 HTTP 1.0은 각 HTTP 세션이 하나의 클라이언트 요처만을 처리하도록 한 것이나, 클라이언트의 요청을 서버에서 효율적으로 처리할 수 있는 캐싱이나, 프록싱 같은 기능지원이 부족했고, 서버의 호스트명을 지정할 수 없었기 때문에 좀더 효율적인 프로토콜에 대한 필요가 생기게 되었다.

  다. HTTP 1.1

HTTP 1.1은 RFC 2068 로 발표되었다. HTTP 1.1은 현시점에서 가장 많이 사용되는 HTTP 프로토콜이다.  HTTP 1.1은 HTTP 0.9와 HTTP 1.0에 대한 하위호환성을 가지고 있고, 후에 보안과 인증 문제를 다루는 RFC 2617이 추가되었다. 

HTTP 1.1 다중호스트네임을 지원하여, 하나의 웹 서버가 여러개의 가상 호스트에 대한 요청을 다룰 수 있도록 했고, HTTP 세션이 여러개의 연결을 처리할 수 있게 했다. 또한 자원 전체에 대한 요청이외에 일부의 자원에 대한 요청도 가능해졌으면, HTTP 1.0보다 향상된 캐싱과 프록싱 및 보안 기능을 제공했다.

3. HTTP1.0, HTT1.1 비교표(http://coffeenix.net/doc/network/http_1_0_vs_1_1.html 표)

분 류	Massages	Header	설    명	지 원 버 전		생략여부
				HTTP1.0	HTTP1.1
상용Header	General-Header	Date	현재시간 ex)Date: Tue, 15 Nov 1994 08:12:31 GMT	○	○
		Pragma	케시제어 ex)Pragma: no-cache	○	×
		Cache-Control	케시 여부·업데이트시간·내용·지움등	×	○
		Connection	연결끊기-http1.1은 연결을 지속 ex)Connection: close	×	○
		Transfer-Encoding	[entity-body]의 압축방식	×	○
		Upgrade	프로토콜 변경시 ex)Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11	×	○
		Via	중계서버(프록시,게이트웨이등)의 지원프로토이름·버전·호스트명	×	○
	Entity-Header	Allow	사용이 허용되는 메소드열거 ex)Allow: GET ,HEAD ,OPTIONS ,TRACE	○	○
		Content-Encoding	[entity-body]의 리소스 압축방식(gzip, compress, deflate..) ex)Content-Encoding: gzip	○	○
		Content-Length	[entity-body]의 리소스 크기(바이트 단위) ex)Content-Length: 3495	○	○	×※2
		Content-Type	[entity-body]의 미디어 타입 ex)Content-Type: text/html	○	○
		expires	자원의 만기 날짜(케시데이터 업데이트요구) ex)Expires: Thu, 01 Dec 1994 16:00:00 GMT	○	○
		Last-Modified	가장 최근에 수정된 날짜 ex)Last-Modified: Thu, 01 Dec 1994 16:00:00 GMT	○	○
		Content-Base	[entity-body]리소스 base-URL ex)Content-Base: http://www.isoft.co.kr/	×	○
		Content-Language	[entity-body]언어정보 ex)Content-Language: da	×	○
		Content-Location	[entity-body]의 URL	×	○	×※3
		Content-MD5	전송시 [entity-body]의 오류발생검사-[entity-body]일부를 요약※1(MD5 RFC1864)	×	○
		Content-Range	[entity-body]일부분 전송시의 해당부분(이어받기등에 사용) ex)Content-Range: bytes 4150-5140/5140	×	○
		ETag	케시 업데이트 정보를 위한 임의의 식별숫자※4 ex)ETag: "0-556-343b9e36"	×	○

※1(MD5 RFC1864)-vase64로 인코딩된 내용이 헤더값으로 존재한다.

※2 requst-line 의 method가 post 인 경우 생략 불가

※3Content-Base가 없는 경우 생략이 불가.

※4Entity-Tag 라고 불리며, If-Match·If-None-Match·If-Range에서 사용

분 류	Massages	Header	설    명	지 원 버 전		생략여부
				HTTP1.0	HTTP1.1
Request	Requst- Line	Method※5	GET,POST,HEAD	○	○
			OPTIONS,PUT,DELETE,TRACE	×	○
		Request-URI	요청 데이터의 절대 주소나  상대주소. ex)http://www.isoft.co.kt/ index.html or /test/helloworld.html	○	○
		HTTP-Version	HTTP" + 0.9∼1.1 (해당 프로토콜)	○	○
	Request-Header	Authorization	사용자 인증정보 - 사용자 ID와 암호가 함께 Base64로 인코딩※6 ex)Authorization: Basic QWxhZGRpbjpvcGVuIHN lc2FtZQ==	○	○
		From	자원의 생성자나 웹마스터의 전자우편 주소 ex)From: psycho@isoft.co.kr	○	○
		If-Modified-Since	GET 사용시-헤더 필드에 지정된 날짜보다 나중 자원만 전달(케시일자검색) ex)If-Modified-Since: Tue, 15 Nov 1994 12:45:26 GMT	○	○
		Refer	한페이지에서 다른페이지를 요청할 때 (링크시) 이전 페이지 주소제공 ex)Referer: http://www.w3.org/ hypertext/ DataSources/ Overview.html	○	○
		User Agenter	browser 정보 ex)User-Agent: MyWebBroswer/0.5	○	○
		Accept	클라이언트의 사용가능 미디어타입 ex)Accept: text/*, text/html, text/html;level=1, */*	×	○
	(Content  Neogo tation)	Accept-Charset	클라이언트에서 사용할 수 있는 문자 집합 (생략시 모두인식) ex)Accepr: iso-8859-1, unicode-1-1	×	○
	(Content  Neogot ation)	Accept-Encoding	클라이언트에서 제공되는 인코딩 방법(압축) ex)Accept-Encoding: compress, gzip	×	○
		Accept-Language	클라이언트가 인식할 수 있는 언어 (우선순위가능) ex)Accept-Language: da, en-gb; q=0.8, en;q=0.7(독일어, 영국영어, 영어)	×	○
		Host	서버의 기본URL (하나의 IP주소에 여러개의 이름을 가진 멀티 서버를 지원) ex)www.w3.org	×	○	×
		If-Match	ETag값 비교-Method수행 -(PUT 메소드:해당header 무시),다르면 402에러발생 ex)If-Match: "0-556-343b9e36"	×	○
		If-None-Match	ETag값 비교, 다를때 -Method수행- (If-Match와 반대), 같을 때 에러 ex)If-None-Match: "0-556-343b9e36", "0-1e4-34367116"	×	○
		If-Range	클라이언트 캐시 정보를 업데이트 정보 (ETag or Date 비교)	×	○
		If-Unmodified-Since	헤더값에 지정된 날자로부터 수정이 없는경우 Method를 수행 ex) If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT	×	○
		Max-Forwards	이 메시지가 거쳐 갈수 있는 최대 Proxy의 개수를 지정 ex)Max-Forwards: 7	×	○
		Proxy-Authorization	비공개 프록시 서버 유저인증을 위한 코드	×	○
		Range	자원의 일부분만 받을때 (이어받기기능) 받을범위 지정 ex)bytes=0-499            : <- 0~499byte를 얻고자 할 때.	×	○

※5 : GET     - 요청한 URL 자료를 전송 (실행화일일 경우 실행 결과를 전송)

      POST    - [Entity-body]를 해당 서버에 수송(CGI활용. 단, Entity-body가
                없거나, Content-Length가 없으면 에러..(400에러))

      Head    - 응답메시지는 [Entity-body]없이 전송됨

      OPTIONS - 자원과 관련된 필요 사항 결정 및 서버 기능검색

      PUT     - 메시지 바디 부분의 데이터를 지정한 요구 URI이름으로 저장한다.
                (ftp의 PUT과 동일)

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

      TRACE  - 요구 메시지가 최종 수신처에 도달 경로를 기록하는 루프백(loop back)
               검사용 (클라이언트 의 요구 메시지가 거쳐가는 프록시나 게이트웨이의
               중간 경로부터 최종 수신 서버까지의 경로를 알아낼 때 사용, 
               Max-Forwards 헤드 필드에는 중간에 거쳐갈 프록시나 게이트웨이 경로의
               최대수를 지정)

※6 ID :'Aladdin', PW : 'open sesame'일 경우 'Aladin:open sesame'을 Base64로 인코딩
    한 코드는 "QWxhZGRpbjpvcGVuIHNlc2FtZQ=="

    주의 : Base64 자체가 공개된 인코딩이므로 보안상 문제가 많다.

분 류	Massages	Header	설    명	지 원 버 전		생략여부
				HTTP1.0	HTTP1.1
Response	Status-Line	HTTP-Version	HTTP" + 0.9∼1.1(해당 프로토콜)	○	○
		Status-Code	수신상태코드-(4Page의 표참조.)	○	○
		Respon-Phrase	수신 상태코드에 대한 간략한 설명-(4Page의 표참조.)	○	○
	Response-Header	Location	요구한 정보 실제 위치. 옮겨지거나 다를경우-정보주소가 실제 위치 정보. (redirection,forwording 단, 절대주소만 가능.)	○	○
		Server	서버 프로그램의 이름과 버전 정보 ex)Server: Apache/1.3a1	×	○
		WWW-Authenticate	사용자 인증이 필요한 자원을 요구시, 필요데이터와 서버가 제공하는 인증 방식 ex)WWW-Authenticate: Basic realm="아이 소프트"	×	○
		Age	요구후 원 서버(origin Server)에서 응답생성하지까지의 시간(초단위)	×	○
		Proxy-Authenticate	서버가 프록시 서버일 경우 유저 인증을 요구하기 위한 헤더이다.	×	○
		Public	서버에서 지원 가능한 Method의 리스트(제한의 의미는없음) ex)Public: OPTIONS, MGET, MHEAD, GET, HEAD	×	○
		Retry-After	503 에러시 -몇초(시간)후에 다시 요구 메시지를 보내라는 정보 ex)Retry-After: Fri, 31 Dec 1999 23:59:59 GMT(Time)    Retry-After: 120   (Second)	×	○
		Warning	상태코드와 응답 구문에 추가적인 경고	×	○

4. HTTP Status-Code Header

1xx: Informational -  요구메시지를 받은 후  연결 중 작업할 때.	2xx: Success -  요구메시지를 제대로 받았을 때.	3xx: Redirection -  요구메시지를 수행하기 위해  다른 작업이 필요할 때.	4xx: Client Error -  요구 메시지의 형식이 틀리거나  빠진 부분이 있을 때.	5xx: Server Error - 서버에 문제가 있을 때.
100 Continue	200 OK  성공처리	300 Multiple Choices  (실제 발생하지 않음)	400 Bad Request  요구가 올바르지 않음	500 Internal Server Error  예기치 못한 서버처리오류
101 Switching Protocols	201 Created  요구에따라 새로운자원생성(PUT)	301 Moved Permanently  URL이 확정적으로 옮겨짐	401 Unauthorized  사용자 인증이 필요	501 Not Implemented  요구에 대한 지원불가  (transfer-Encoding)
	202 Accepted  요구를 이해하였으며 진행중	302 Moved Temporarily  URL이 임시적으로 옮겨짐	402 Payment Require	502 Bad Gateway  게이트웨이·프락시의 응답오류
	203 Non-Authoritative Information	303 See Other	403 Forbidden  요구는 이해하나 수행거절(PUT)	503 Service Unavailable  서버부하로 응답불가
	204 No Content  요구자료에 정보가 없음(empty)	304 Not Modified(If-Modified-Since)  수정날짜에 수정되지 않음	404 Not Found  요구한 파일이 없음	504 Gateway Time-out
	205 Reser Content	305 Use Proxy	405 Method Not Allowed  허락된 메소드가 아님	505 HTTP Version not supported  (요구를 무시할 수 있음..??)
	206 Partial Content		406 Not Acceptable
			407 Proxy Authentication Required
			408 Request Time-out
			409 Conflict
			410 Gone
			411 Length Required
			412 Precondition Failed
			413 Request Entity Too Large
			414 Request-URI Too Large
			415 Unsupported Media Type

※ 아래에 기술되는 내용의 출처 : http://darkmirr.egloos.com/1237288

HTTP 프로토콜의 특성상 데이터를 요청하고 그리고 데이터를 받고 나면 바로 소켓 Connection을 해제하게 됩니다.
지속적인 연결을 하고 있으면서 데이터를 주고 받는 것이 아니라 필요할 때마다 소켓을 연결하고 데이터를 받자마자 바로 Connection을 끊어버리는 방식이 바로 HTTP 프로토콜의 연결 메커니즘입니다.
HTTP 1.0에서는 하나의 문서내에 이미지가 존재한다면 문서를 받기위해서 연결설정을 하고 이미지를 받을 때 다시 연결설정을 하게 됩니다. 이러한 원리를 그림으로 나타내면 다음과 같습니다.

 

하지만 HTTP 1.1에서는 만약 연결설정을 한 후 하나의 문서내에 포함 되어진 다른 이미지나 Object가 존재한다면 연결설정을 다시 하지않고 연결되어진 소켓을 통해서 데이터를 이어서 받게 됩니다.
이렇게 함으로써 HTTP 프로토콜의 수행성능을 향상하게 되는 것입니다.

HTTP 1.1의 Connection 메카니즘을 그림으로 나타내면 다음과 같습니다.

 

HTTP 1.0에서는 하나의 문서내에 이미지가 포함되어 있을 때 2번의 연결을 하여 전체 8 Step으로
모든 작업을 완료했지만 HTTP 1.1에서는 6번의 Step으로 모든 작업을 마치게 됩니다.
만약 포함되어진 Image나 Object가 많이 존재한다면 HTTP 1.1의 수행성능은 더욱 향상될 것입니다.
HTTP 1.1 프로토콜은 처음 연결할 때 Delay가 심하지만 점점 더 속도가 빨라지는 이유가 이러한 데에서 나타납니다.

 
하지만 작업을 마치면 연결 자체가 해제되어 버리기 때문에 지속성 있는 작업을 계속 유지할 수 없습니다.
연결을 완전 해제해 버리기 때문에 방금 전에 접속한 클라이언트인지, 이제 처음으로 접속한 클라이언트인지 구분할 수 없습니다. 이러한 단점을 극복하기 위해 몇가지의 방법론을 다음 절에서 소개하도록 하겠습니다.

HTTP 프로토콜은 연결을 계속 유지하는 것이 아니라 작업을 마치면 바로 연결을 해제하는 방식으로 동작합니다.
이러한 Connection의 지속성이 없기 때문에 각각의 클라이언트를 구분할 수 없다는 것은 HTTP 프로토콜의 가장 큰 단점입니다. 그리고 이것이 가장 큰 장점이기도 합니다.
보다 많은 사용자에게 보다 많은 서비스를 할 수 있다는 것입니다.
TCP 프로토콜의 지속성 측면에서 프로토콜을 나누어 보면 다음과 같습니다.

 

TCP 프로토콜의 응용

n        지속적인 연결성을 기지고 있는(stateful) 프로토콜 à FTP, Telnet

n        지속적인 연결성을 유지하지 못하는(statelessful) 프로토콜 à HTTP

 

FTP, Telnet은 한번 연결되면 계속적으로 다음 작업을 서비스 받을 수 있습니다.
하지만 HTTP는 한번의 연결로 필요한 작업만을 하고 바로 Connection을 해제 해버립니다.
이러한 HTTP의 단점을 극복하기 위해서 몇가지의 방법이 제공되어집니다.

 

상태를 유지하기 위한 방법들

n        URL Rewriting

n        Hidden Form Field

n        Cookie

n        Session

 
URL Rewriting과 Hidden Form 양식을 이용하는 것은 프로그램적인 응용부분으로 생각해 볼 수 있으며 일반적으로 Cookie와 Session을 이용하는 것을 주로 합니다.

※ 아래에 기술되는 내용의 출처 : http://www.lovelgw.com/Blog/74

HTTP 프로토콜 호출 구조