[그림 1] TCP/IP Protocol Stack
이러한 가능성은 그만큼 사용자의 복잡 다양한 요구를 수용할 수 있어야 한다는 뜻을 함축하고 있으며, 인터넷에 존재하는 각종 서비스들을 하나로 통합하여 서비스할 수 있다는 뜻도 갖고 있다. 이에 따라 HTTP 프로토콜은 현재 HTTP/1.0의 제한적 서비스 영역을 넘어 보다 확장되고 다양한 사용자의 요구를 충족시킬 수 있도록 개발되고 있다.
HTTP Next Generation에서는 프로토콜의 개발 동향을 살펴보고자 하며, 이를 통해 앞으로 가능하게 될 인터넷의 종합적 서비스 도구로서의 WWW을 전망해보고자 한다.
HTTP는 World Wide Web에서 사용하고 있는 데이타 전송 프로토콜이며 MIME으로 지정할 수 있는 모든 데이타 형식에 대해 바이나리 모드로 전송할 수 있다. 이것은 FTP의 경우에서와 같이 데이타 송수신이 가능함을 뜻하며, 다만 WWW용의 추가적인 정보가 HTTP 프로토콜에서 활용되고 있을 뿐이다. 따라서 HTTP 프로토콜은 TCP/IP 프로토콜 체계 가운데 응용 프로토콜로서 한 자리를 차지한다.
다음의 그림 1과 같이 HTTP는 FTP처럼 TCP 연결을 통해 데이타를 송수신한다.
따라서 HTTP는 TCP/IP 기반 위에서 데이타 송수신이 이루어지고, FTP에서 get, put, dir 등의 응용 프로토콜 기능이 있는 것처럼 HTTP에서도 get, put, post, head 등과 같은 응용 프로토콜 기능이 있다.
이렇게 TCP/IP 프로토콜을 기반으로 동작하기 때문에 사용하는 TCP 포트가 있으며 80번으로 지정되어 있다. 다른 포트를 이용할 수도 있으나 기본적으로 정의되어 있는 번호는 80번이다. 그렇다고 해서 HTTP 프로토콜은 TCP/IP에서만 동작할 수 있는 것은 아니다. OSI 참조모델을 이용한 프로토콜 체계에서도 HTTP 프로토콜은 응용 프로토콜로서 활용될 수 있는 것이다. 다만 다른 프로토콜 체계에서 사용하고자 할 때는 그에 맞게끔 적절한 수정을 해야만 가능할 것이다.
실제적인 정보시스템에서는 검색, 정보 갱신, 및 주석 등과 같은 간단한 작업보다는 보다 다양한 기능을 필요로 하고 있다. 또한 분산 환경, 공동작업 환경, 하이퍼미디어 정보시스템 등의 상황에서 필요로 하는 속도와 간편성을 제공하기 위한 프로토콜이 필요하게 되었고 이를 목적으로 HTTP 프로토콜이 설계되었다.
HTTP 프로토콜은 요구/응답 (Request/Response) 방식을 이용하여 동작하고 있다. 즉, 원하는 프로토콜 기능(예: GET, DELETE, POST, HEAD, etc.)에 대해 서비스 요구를 하면 데이타 통신을 위한 TCP 연결이 만들어지고 서버가 응답을 보내어 데이타 전송을 끝내면 자동적으로 연결이 끊어지게 되는 것이다.
FTP 프로토콜의 경우 하나의 화일을 송신 또는 수신하고 난 다음에도 그 연결은 끊어지지 않아 또 다른 요구를 할 수 있지만, HTTP 프로토콜의 경우에는 다시 연결을 만들어 요구해야 하는 방식이다.[Simon5]
HTTP의 Request 형식은 아주 간단하다. 첫 번째 줄 처음에 어떤 기능을 이용하려는지 지정을 한다. 가장 일반적으로 쓰이고 있는 것이 GET 이다. 이것은 브라우저가 서버에게 문서를 보내달라고 요청하는 것이다. 그 다음에는 화일 이름처럼 대상이 되는 것을 지정하고 현재 쓰이고 있는 HTTP 프로토콜의 버전을 지정한다. 이 다음에는 일련의 지정 사항들을 덧붙일 수가 있은데, 예를 들어 브라우저의 종류나 브라우저가 다룰 수 있는 데이타 형식 등이다. 아래와 같은 예를 볼 수 있다.
GET /index.html HTTP/1.0 Accept: text/plain Accept: text/html Accept: */* User-Agent: Netscape 1.2
HTTP에서의 응답 형식도 아주 간단하게 구성되어 있다. 서버에서 쓰이고 있는 프로토콜 버전, Request에 대한 실행 결과, 전달해줄 데이타의 형식, 데이타 길이 등과 같은 추가적인 정보가 전달되고, 이러한 헤더 정보의 끝을 나타내는 빈줄이 들어가고, 뒤이어 실제 데이타가 전달된다. 데이타 전달이 끝나면 서버는 연결을 끊는다. 아래와 같은 예를 볼 수 있다.
HTTP/1.0 200 OK Server: MDMA/0.1 MIME-version: 1.0 Content-type: text/html Last-Modified: Thu Jul 7 00:25:33 1994 Content-Length: 2003 Right here waiting for you...
이러한 요구/응답 방식은 나름대로 장단점을 갖고 있다. URL (Uniform Resource Locator)을 이용한 하이퍼링크로 구성되어 있는 HTML 문서에서는 각종 프로토콜과 호스트 이름을 지정하여 문서 요청을 위한 연결을 만들어 데이타를 갖고 올 수 있다. FTP의 경우에서처럼 하나의 호스트에 오래 연결을 맺고서 여러 가지 문서들을 갖고 오는 것이 아니라 하이퍼텍스트 문서에 있는 하이퍼링크를 통해 전혀 다른 호스트에 접속하여 문서를 요청할 수 있기 때문에 연결이 지속적으로 유지되는 방식보다는 요구/응답의 방식으로 동작하는 것이 보다 효율적이게 된다.
하지만 많은 경우에 갖고 오는 데이타는 같은 장소에 있는 것이다. 따라서 같은 호스트에서 여러가지 문서를 갖고 올려고 한다면 각각의 문서마다 별도의 TCP 연결을 만들고 이 과정에서 추가적인 부담이 생기게 된다. FTP의 경우에는 한 번 맺어진 연결을 통해서 여러 번 문서 요청을 하면 되지만 HTTP 프로토콜에서는 문서마다 각각의 연결을 만들어야 하는 추가적인 부담이 발생하는 것이다. 따라서 같은 장소에서 많은 문서를 갖고 올려고 할 때 HTTP 프로토콜은 성능상의 저하를 발생시키고 있는 것이다.
이러한 문제점을 해결하고, On-Line 쇼핑과 같은 상업적인 응용들을 염두에 둔 기능들을 보완하여 새로운 프로토콜을 설계하고자 하고 있다. 이것은 두 가지 방식으로 진행되고 있는데 현재의 프로토콜을 보완하는 방법이 하나이고 아예 새로운 프로토콜을 설계해서 기존의 HTTP 프로토콜을 대체하는 방법이 나머지 한 가지이다. HTTP-NG란 명칭은 기존의 HTTP 프로토콜을 대체하는 새로운 프로토콜을 설계하고자 하는 것이다.[Simon1][Simon2]
HTTP는 인터넷에서 가장 빠르게 성장하고 있는 프로토콜이다. 구현하기도 손쉬우며 지금 이 순간에도 엄청난 양의 데이타가 이 프로토콜에 의해 전송되고 있다. 이렇게 잘 동작하고 있음에도 HTTP를 대체하는 새로운 프로토콜을 설계하고자 하는 것은 앞서 말한 성능상의 문제와 사용자 확인 및 사용료 징수 등과 같은 수단으로 상업적 응용의 목적을 달성하기 위해서이다.[Simon1]
기존의 프로토콜에다 각종 기능들을 추가하고 개선하여 활용하는 방법도 있으나 필요한 요건들이 프로토콜 동작의 기본 모델과 관련한 것이기 때문에 이를 바꾸지 않고서는 문제를 더 복잡하고 어렵게 만든다. 이에 따라 다른 동작 모델을 사용하여 새로운 프로토콜을 설계하고자 하는 것이다.[Simon2]
새로운 프로토콜을 개발하고자 할 때 검토할 수 있는 요구사항들은 세 가지 대상에 대한 것으로 나누어볼 수 있다. 즉, 다음과 같다.
HTTP 프로토콜이 동작하는 방식은 아래 그림 2와 같이, 브라우저의 각 요구들마다 매번 새로운 연결을 만들어서 데이타를 가져오고 있다. 따라서 다섯 가지의 문서 화일을 가져오기 위해서는 다섯 개의 연결을 만들어서 갖고 오게 된다.[Simon2]
이에 비해, HTTP-NG 프로토콜 구조에서는 다른 모델을 사용하고 있다. 다음 그림 3과 같이 각 문서 요구에 대해 별도의 연결을 만들기 보다는 여러 개의 문서 요구에 대해 하나의 연결만 만들도록 한다. 이 하나의 TCP 연결 속에서 '세션(session)'이라고 불리우는 여러 개의 가상적 연결을 만들도록 한다. 이 가운데 하나는 세션 연결에서 제어 정보를 주고 받기 위해 쓰인다. 나머지 세션 연결선에 실제 데이타가 전달된다.
HTTP-NG에서의 요구/응답은 '메시지' 단위로 처리되며, GET 요구를 통해 문서를 요구하는 경우에 원하는 문서 목록을 지정하여 요구하고, 각각의 문서들은 세션 연결을 통해 동시에 전달된다. 데이타를 수신하고 있는 동안에도 기다릴 필요없이 문서 요청을 할 수 있으며, 하나의 데이타 스트림 속에 여러 개의 문서가 사이사이에 끼어 있을 수 있다. 따라서 중간 게이트웨이 역할을 할 때도 서로 다른 브라우저가 같은 서버에 대해 요구를 할 때 효율적으로 동작할 수 있는 수단이 된다.
HTTP 프로토콜을 통해 송수신되는 데이타는 텍스트 정보 그대로여서 사람들이 이해하기 쉬운 형태이나 다양한 데이타 형식이 복합적으로 쓰일 때는 복잡한 구조로 표현되어야 하고 다루기가 어려워진다.
이에 따라 HTTP-NG에서는 전달되는 문서 정보들을 ASN.1 (Abstract Syntax Notation)과 PER (Packed Encoding Rules) 형식으로 인코딩하여 전달되도록 한다. 이미 이 방식으로 동작하는 효율적인 도구가 있기 때문이다.
HTTP-NG 메시지는 동작 레벨에 대한 협상 결과에 따라 교환된다.[Simon4]
TCP 연결이 일단 설립되고 나면 세션 연결을 위해 일단 먼저 초기화를 시켜야 한다. 브라우저는 허용 가능한 methods(1)와 동작 레벨을 지정하는 초기화 요구를 보내고, 서버는 허용 가능한 methods와 사용할 동작 레벨을 지정하는 초기화 응답을 한다. 이때 브라우저는 이 응답을 받지 않고서도 서버에게 요구를 보낼 수 있다. 만약 서버가 처리할 수 없는 요구 사항이라면 서버는 오류 응답을 보낸다.
이러한 초기화 요구와 응답은 반드시 연결이 설립되고 최초로 전달되어야 한다. 만약 협상이 가능하다면 초기화 요구를 보내고 나서 즉시 협상 요구를 보낼 수 있다. [Simon4]
초기화 동작이 끝나고 난 다음에는 실제적인 데이타 송수신을 위한 요구와 응답을 주고 받을 수 있다. 서버는 브라우저가 허용 가능하다고 지정한 것 이외에 다른 어떤 메시지도 보내어서는 안 된다.
데이타를 주고 받는 가운데 브라우저는 언제든지 동작 레벨과 method를 바꾸기 위해 초기화 요구를 다시 할 수 있다. 서버는 새롭게 수신한 초기화 요구에 대해, 이전에 수신한 모든 요구 사항들을 처리하고 난 다음에 초기화 응답을 해야 한다. [Simon4]
오류가 발생하게 되면 오류를 알리는 응답이 전달된다. 오류가 발생한 이유에 대해 미리 지정되어 있는 숫자 번호로 알려주고, 추가적으로 알려줄 수 있는 오류 메시지나 정보도 포함될 수 있다. [Simon4]
이미 보냈던 요구 사항은 언제든지 취소가 가능하다. 아직 완료되지 않는 동작에 대한 '취소요구'를 서버가 수신하면 수행하고 있던 작업을 중단한다.
만약 브라우저가 원하지 않았던 데이타를 포함하거나 원하지 않았던 응답 메시지가 도착하면 -- 이미 했던 요구 사항을 취소했지만 응답이 도착했을 경우도 포함하여 -- 수신하게 된다면, 취소요구를 서버에게 보내도록 한다. 이를 통해 보다 나은 예측 알고리즘이 동작할 수 있게끔 한다.
'취소요구'(Cancel Request)와 함께 '대기요구'(Suspend Request)도 가능하다. 이것은 서버가 전송 재개를 요청하거나 브라우저가 대기요구를 취소하기 전까지 데이타 전송을 일시적으로 중단시키고 대기 상태로 두게끔 하는 것이다. [Simon4]
브라우저는 연결을 언제든지 끊을 수 있으며 서버도 언제든지 연결을 끊을 수 있다. 적절하게 '해제요구'(Shutdown Request)를 보내어 해제할 수 있다.[Simon4]
브라우저가 서버에게 여러 가지 문서 전송을 요구하는 것이 일반적인 경우이지만, 반대로 여러 브라우저에게 경고 메시지를 전달할 때와 같은 경우도 있다. 또는 비용 지불을 누가 담당할 것인지 서버는 여러 상대에 대해 협상을 해야할 경우도 있다. 이와 함께, HTTP-NG는 문서의 종류에 제한을 두고 있지 않고 보안 및 지불 방식의 제한도 두고 있지 않으므로 브라우저와 서버 사이에 어떤 방식을 사용할 것인지 협상이 있어야 한다.
HTTP의 경우에는 브라우저가 허용 가능한 것들을 주루룩 나열하여 서버가 선택하는 방식으로 이루어진다. 이같은 방식에서는 전달하는 요구 데이타 크기가 커지고 그만큼 송수신에 시간이 걸리고 처리 시간을 증가시키는 성능상의 문제점을 일으킨다. 이러한 정보가 브라우저 요구 패킷의 95% 부분을 차지한다.
HTTP-NG에서는 일반적으로 가장 많이 쓰이는 데이타 형식들을 목록으로 만들어 짤막한 비트맵 형식으로 인코딩을 한다. 서버와 브라우저는 이 정보와 함께 자신이 허용 가능한 것들을 지정하는 방식으로 협상의 과정을 거친다. 이를 위해 추가적인 숫자 형식의 파라미터가 추가되어야 한다. security schemes, authentication information, payment mechanisms 등에 대한 협상도 같은 방식으로 이루어진다.[Simon2][Simon4]
지금까지 제안되어 있는 보안 방식들은 부지기수로 존재하기 때문에 HTTP-NG에서는 적용할 수 있는 여러 가지 보안 요소들을 결합하여 general security framework을 만들고 있다. 여기서 체계적인 선택 사안들을 제시하고 이를 선택함으로써 이용하고자 하는 보안 방식을 손쉽게 선택하게끔 하고 있다. 이를 통해 각 HTTP-NG 메시지마다 다른 보안 방식을 사용할 수도 있다. HTTP-NG에서는 중간 게이트웨이 역할을 하는 서버에서도 이런 보안 방식을 지원하므로 데이타 내용에 대해 손대지 않고 암호화 되어 있는 데이타를 그대로 중계해 줄 수 있도록 하고 있다.[Simon2]
HTTP-NG는 브라우저의 요구에 대한 응답으로 서버가 대금 지불 요청을 할 수 있게끔 하고 있다. 이를 위해 적절한 지불 방식과 사용자 인증 방식 등에 대한 상호간 협상을 하여야 한다. 또한 서버는 가격 정보도 함께 제공하여야 한다.[Simon2]
브라우저가 요구한 정보에 대해 사용자에게 보여줄 때 저작권 사항과 같이 자동적으로 보여주게끔 하기 위해 추가적인 기능을 이용할 수도 있다.[Simon2]
HTTP 1.0 프로토콜에서 HTTP-NG 프로토콜로 옮겨가기 위한 방법으로 두 가지를 활용할 수 있다. 한 가지 방법은 HTTP 1.0과 HTTP-NG를 함께 구현하여 각각의 브라우저 요구에 따라 응하는 Dual Stack approach이다. 다른 한 가지 방법은 Proxy Server로서 활용하는 방법이다.[Simon2]
두 가지를 함께 구현하는 Dual Stack 방식에서는 HTTP-NG만 사용하는 만큼의 성능 향상을 기대할 수 없다. 그러나 Proxy Server 방식에서는 캐시되는 정보가 항상 HTTP-NG 프로토콜을 이용하므로 상당한 정도의 성능 향상을 기대할 수 있다. 또한 Proxy Server는 같은 연결 속에서 여러 개의 HTTP 1.0 연결을 동시에 처리할 수 있다.
FTP, GOPHER, HTTP 등과 같이 인터넷에서 폭넓게 사용되고 있는 응용들은 문서를 요청할 때마다 매번 새로운 연결을 만들어서 가져온다. 통상 브라우저는 몇 개의 문서를 같은 서버에서 가져오므로 이러한 문서 송수신 방식은 비효율적인 것임에 틀림없다. 그래서 하나의 TCP 연결에다 여러 개의 conversations, 즉 session 연결을 두어 보다 효율적으로 데이타 송수신 처리를 하고자 한다.[Simon3]
SCP에서 사용하는 헤더의 구성 형식을 보면 다음 그림과 같다.
이미 앞서 열거했던 HTTP 프로토콜의 문제점들이 파악되어 있기 때문에 현재 프로토콜을 개선하고자 하는 논의가 이루어지고 있으며, 다양한 응용들과 사용자들의 요구사항을 반영하고자 하는 논의가 이루어지고 있다. 여기에서는 현재 HTTP 프로토콜 개발 작업에서 논의되고 있는 주요한 사항들에 대해 살펴보고자 한다. 이러한 사항들은 아직 논의 단계에 있기 때문에 향후의 HTTP 상위 버전에 반영될지는 알 수가 없다.[Archive]
KeepAlive on | off
KeepAliveTimeout N
MaxKeepAliveRequests N