RFC 2616(HTTP) : 1장 정리

1.1 목적

HTTP

분산 정보 시스템, 종합 정보 시스템 및 하이퍼미디어 정보시스템에서 사용하는 응용계층의 규약

 

HTTP/0.9

HTTP의 첫 버전. 인터넷 상에서 저장되어 있는 원래 데이터를 전송하기 위한 단순한 규약.

 

HTTP/1.0

메시지를 전송하는 문서 데이터에 대한 메타 정보 및 요구/응답 용어의 변경자를 포함하는 MIME(다용도 인터넷 메일 확장)과 유사한 메시지의 형식으로 사용할 수 있도록 함으로써 규약을 향상시킴.

 

HTTP/1.1

HTTP/1.0의 문제(계층적 프락시, 캐시, 지속적인 연결의 필요성, 가상 호스트)을 해결한 버전.

상호 협상할 수 있는 응용 프로그램이 상대방의 진정한 성능을 파악할 수 있도록 규약 버전을 갱신함.

하이퍼텍스트 전송 규약을 정의.

요구의 목적을 표시하는 일련의 개방된 method를 허용.

자원 식별자(URI), 자원 위치(URL), 자원이름(URN)이 제공하는 참고 방법에 따라 method를 적용할 자원을 지칭하는데 사용.

다른 인터넷 시스템 사이의 통신을 위한 범용 규약으로서 사용.

 

1.3 용어

connection : 통신을 목적으로 두 프로그래밍 간에 설정된 전송 계층의 가상적 회로

message : HTTP 통신의 기본 전송 단위. 구조적인 데이터 표현 형태. 8비트로 구성되어 있고 연결을 통하여 전송

request : 요구. 5장에 규정된 HTTP 요구 메시지.

response : 응답. 5장에 규정된 HTTP 응답 메시지.

resource : 자원. 3.2장에 규정되어 있는 URI에 의하여 식별되는 네트워크 데이터 객체 또는 서비스. 자원은 다양한 표현 형태를 지닐 수 있으면 다양한 방법으로 변형될 수 있다.

entity : 요구나 응답 메세지의 payload로서 전송되는 정보. entity-header 필드 형태의 메타 정보 및 entity-body 형태의 내용으로 구성되어 있음.

representation : 내용 협상의 통제를 따르는 응답에 포함된 엔터티. 특정한 응답 상태와 연관된 다수의 표현 방법이 있을 수 있음.

content negotiation : 내용 협상. 요구를 처리할 때 적절한 표현 방법을 선택하는 메커니즘. 어떠한 응답에서는 엔터니의 표현은 협상할 수 있다. (에러 응답 포함)

variant : 변형자. 자원은 특정한 경우에 자원과 관련된 하나 이상의 표현 방식을 가질 수 있다.

client : 요구 메시지를 전송할 목적으로 연결을 설정하는 프로그램.

user agent : 요구 메시지를 시작하는 클라이언트. 브라우저, 편집기, 스파이더 또는 다른 사용자 툴

server : 서버. 요구 메시지를 처리하기 위해 접속을 수신하는 애플리케이션으로서 응답 메시지를 전송함. 어떤 프로그램이든 도시에 클라이언트와 서버가 될 수 있음.

origin server : 해당 자원이 보관되어 있거나 자원을 생성할 수 있는 서버.

proxy : 프락시. 다른 클라이언트를 대신하여 요구를 작성할 목적으로 서버와 클라이언트의 역할을 모두 수행하는 중간 프로그램. 요구는 내부적으로 처리되어 가능하면 해석되어 다른 서버로 전달된다. 프락시는 이 규격의 클라이언트와 서버의 필요 조건을 모두 구현해야만 한다.

gateway : 다른 서버를 위해 중간 역할을 하는 서버. 프락시와는 달리 게이트웨이는 요구 메시지를, 요청받은 자원을 서비스하는 최종적인 원서버처럼 수신한다.

tunnel : 두 연결 사이를 무조건 중계하는 역할을 하는 중간 프로그램. 활성화되면 비록 HTTP 요구에 의하여 시작되지만 터널은 HTTP 통신의 참여자로 간주되지 않음. 터널은 중계하고 있는 양 쪽의 연결이 종결되면 사라짐.

cache : 캐시. 프로그램이 응답 메시지를 저정하는 로컬 저장소. 클라이언트, 서버 모두 캐시를 포함할 수 있지만 터널 역할을 하는 서버는 캐시를 사용할 수 없다.

cachable : 캐시할 수 있는. 응답 메시지의 사본을 저장하여 계속적인 요구 응답에 사용할 수 있으며 응답을 캐시할 수 있다.

first-hand : 응답이 직접적으로 오며 원서버로부터 하나 또는 그 이상의 프락시를 거쳐옴으로써 발생하는 불필요한 지연이 없을 경우 응답이 직접 온다고 말함.

explicit expiration time : 명백한 유효 시간. 원서버가 추가적인 검증 없이는 캐시에 의해 엔터티를 더 이상 되돌려 주지 않기로 한 시간. 즉 원서버가 캐시된 데이터의 유효성을 보장할 수 있는 시간.

heuristic expiration time : 자동으로 설정되는 캐시 유효 시간.

age : 경과 시간. 응답 메시지의 경과 시간은 원서버로부터 전송된 후, 또는 성공적으로 검증된 후의 시간.

freshness lifetime : 응답의 생성 시점과 유효 시간 만기 시점 사이의 시간 길이

fresh : 응답의 경과 시간이 신선한 기간을 넘어서지 않았을 떄 응답이 신선하다고 말함.

stale : 낡음. 응답의 경과 시간이 신선한 기간을 넘어섰다면 응답이 낡았다고 말함.

semantically transparent : 의미상으로 분명한. 성능을 향상시키고자 하는 목적을 제외하고 캐시의 사용이 요구하는 클라이언트나 원서버에 영향을 미치지 않을 때 특정한 요구에 대하여 캐시가 의미상으로 분명하게 작동한다고 말함.

validator : 검증자. 캐시 엔트리가 엔터티의 복사본과 동일한 지 알아내는데 사용하는 규약 요소.

1.4 Overall Operation(전체 작업)

HTTP 규약은 요구/응답 규약.

클라이언트는 요구 method, URI, 규약 버전의 형태로 서버에 요구 메시지를 전송.

서버는 메시지의 규약 버전 및 성공 또는 실패 코드를 포함하는 상태 정보 응답

<세 가지의 중간 매개 형태>

• 프락시 : 전송 에이전트로 절대 표현 형태의 URI 요구를 수신하여 메시지의 전체 혹은 부분을 재작성 한 후 URI가 표시하는 서버로 재구성된 요구 메시지를 전달
• 게이트웨이 : 수신 에이전트로 다른 서버 위의 계층 역할을 수행하며 필요하다면 원서버의 규약에 맞도록 요구를 해석하기도 함
• 터널 : 메시지를 변경하지 않고 두 지점을 연결하는 중계역할을 수행 ex. 방화벽

터널이 아닌 통신에 참여하는 무엇이든 요구를 처리할 때 내부 캐시를 사용할 수 있음.

캐시의 효과는 연결 고리를 따라 참가자 중 하나가 해당되는 요구에 적용 할 수 있는 캐시된 응답을 갖고 있다면 Request/Response chain이 짧아짐.

HTTP/1.1의 목적 : 고도의 신뢰성과 신뢰성을 확보할 수 없다면 신뢰할 수 있는 실패의 표시 기능을 지닌 웹 응용프로그램을 개발하는 개발자의 요구를 충족하는 규약 구조물을 새로 소개하면서도 이미 배포된 다양한 환경을 지원하는 것

HTTP/1.0에서 대부분의 구현 방식은 각각의 요구/응답 교환에 새로운 접속을 사용했음.

HTTP/1.1에서는 하나의 접속을 하나 또는 그 이상의 요구/응답 교환에 사용가능.(연결이 여러 가지 이유로 단절될 수 있음.)