[HTTP] HTTP 1.0 과 1.1 의 차이 (HTTP/1.0 VS HTTP/1.1)

---

 출처

 : http://jaweb.tistory.com/547

 : https://bluestarblogkr.blogspot.kr/2011/10/http10-11.html

---

참고 출처 : http://coffeenix.net/doc/network/http_1_0_vs_1_1.html

             http://msdn.microsoft.com/ko-kr/library/aa287673(v=vs.71).aspx

뭔가 들어가고 빠진건 많은데;

Cache-control 이나 Content- , Accept- 관련이 많은듯..

HTTP1.0-1.1 Protocol Massage & Header 구성요소

분 류	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 QWxhZGRpbjpvcGVuIHNlc2FtZQ==	○	○
		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  Neogotation)	Accept-Charset	클라이언트에서 사용할 수 있는 문자 집합(생략시 모두인식) ex)Accepr: iso-8859-1, unicode-1-1	×	○
	(Content  Neogotation)	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	상태코드와 응답 구문에 추가적인 경고	×	○

Vary

×

○

  

 

<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 요청과 HTTP 응답은 헤더를 사용하여 HTTP 메시지 정보를 보냅니다. 헤더는 이름 뒤에 콜론, 공백, 값이 순서대로 나오는 일련의 줄입니다. 

필드는 순서에 상관 없이 정렬할 수 있습니다. 일부 헤더 필드는 요청 헤더와 응답 헤더 모두에 사용되지만 그 외의 헤더 필드는 요청이나 응답 헤더 중
한 헤더에만 사용할 수 있습니다.

대부분 요청 헤더 필드를 사용하여 클라이언트는 허용되는 여러 옵션을 값 부분에 지정할 수 있으며 각 옵션의 기본 설정 순위를 정할 수도 있습니다.
여러 항목은 쉼표로 구분됩니다. 예를 들어, 클라이언트는 다음 압축 형식이 적용됨을 나타내는 "Content-Encoding: gzip, compress"가 포함된
요청 헤더를 보낼 수 있습니다. 서버에서 응답 본문에 gzip 인코딩을 사용하면 해당 응답 헤더에 "Content-Encoding: gzip"가 포함됩니다.

일부 필드는 단일 헤더에 두 번 이상 발생할 수 있습니다. 예를 들어, 헤더에 "Warning" 필드가 있을 수 있습니다.

다음은 HTTP 1.1 헤더 필드를 나열한 표입니다. 일부 헤더 필드는 MIME 필드입니다.
MIME 필드는 IETF(Internet Engineering Task Force) 문서 RFC 2045에서 정의되지만 HTTP 1.1 프로토콜에도 사용됩니다.
MIME 및 HTTP 1.1 사양에 대한 자세한 내용은 IETF 페이지를 참조하십시오.

일반 헤더 필드

일반 헤더 필드는 요청 메시지와 응답 메시지에 사용할 수 있습니다.

이름	예제 값
Cache-Control	"max-age=10"
Connection	"close"
Date	"Tue, 11 Jul 2000 18:23:51 GMT"
Pragma	"no-cache"
Trailer	"Date"
Transfer-Encoding	"chunked"
Upgrade	"SHTTP/1.3"
Via	"HTTP/1.1 Proxy1, HTTP/1.1 Proxy2"
Warning	"112 Disconnected Operation"

요청 헤더 필드

요청 헤더 필드는 요청 메시지에만 사용됩니다.

이름	예제 값
Accept	"text/html, image/*"
Accept-Charset	"iso8859-5"
Accept-Encoding	"gzip, compress"
Accept-Language	"en, fr"
Authorization	[credentials]
Content-Encoding	"gzip"
Expect	"100-continue"
From	"user@microsoft.com"
Host	"www.microsoft.com"
If-Match	"entity_tag001"
If-Modified-Since	"Tue, 11 Jul 2000 18:23:51 GMT"
If-None-Match	"entity_tag001"
If-Range	"entity_tag001" or "Tue, 11 Jul 2000 18:23:51 GMT"
If-Unmodified-Since	"Tue, 11 Jul 2000 18:23:51 GMT"
Max-Forwards	"3"
Proxy-Authorization	[credentials]
Range	"bytes=100-599"
Referer	"http://www.microsoft.com/resources.asp"
TE	"trailers"
User-Agent	"Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"

응답 헤더 필드

응답 헤더 필드는 응답 메시지에만 사용됩니다.

이름	예제 값
Accept-Ranges	"none"
Age	"2147483648(2^31)"
ETag	"b38b9-17dd-367c5dcd"
Last-Modified	"Tue, 11 Jul 2000 18:23:51 GMT"
Location	"http://localhost/redirecttarget.asp"
Proxy-Authenticate	[challenge]
Retry-After	"Tue, 11 Jul 2000 18:23:51 GMT" or "60"
Server	"Microsoft-IIS/5.0"
Vary	"Date"
WWW-Authenticate	[challenge]

엔터티 헤더 필드

엔터티 헤더 필드는 요청 메시지나 응답 메시지에 사용할 수 있습니다. 엔터티 헤더 필드에는 사용된 인코딩 형식 등의 메시지의 엔터티 본문에 대한 정보가 있습니다.

이름	예제 값
Allow	"GET, HEAD"
Content-Encoding	"gzip"
Content-Language	"en"
Content-Length	"8445"
Content-Location	"http://localhost/page.asp"
Content-MD5	[md5-digest]
Content-Range	"bytes 2543-4532/7898"
Content-Type	"text/html"
Expires	"Tue, 11 Jul 2000 18:23:51 GMT"
Last-Modified	"Tue, 11 Jul 2000 18:23:51 GMT"

요청 헤더 예제

다음은 HTTP 요청의 기본 예제입니다.

GET /articles/news/today.asp HTTP/1.1

Accept: */*

Accept-Language: en-us

Connection: Keep-Alive

Host: localhost

Referer: http://localhost/links.asp

User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Accept-Encoding: gzip, deflate

이 요청에는 메서드(GET), 리소스 경로(/articles/news/today.asp) 및 HTTP 버전(HTTP/1.1)을 포함하는 요청 표시줄이 있습니다. 이 요청에는 본문이 없으므로 요청 표시줄 다음에 나오는 모든 것은 모두 헤더의 일부입니다. 헤더 다음에는 빈 줄이 오며 헤더의 끝을 표시합니다.

응답 헤더 예제

웹 서버는 여러 방법으로 이전 요청에 응답할 수 있습니다. 파일을 액세스할 수 있고 사용자가 해당 파일을 볼 수 있는 권한이 있으면 응답은 다음과 유사합니다.

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.0

Date: Thu, 13 Jul 2000 05:46:53 GMT

Content-Length: 2291

Content-Type: text/html

Set-Cookie: ASPSESSIONIDQQGGGNCG=LKLDFFKCINFLDMFHCBCBMFLJ; path=/

Cache-control: private

<HTML>

<BODY>

...

응답의 첫째 줄은 상태 표시줄입니다. 이 상태 표시줄에는 응답에 사용된 HTTP 버전, 상태 코드(200) 및 원인이 있습니다.
이 예제에는 다섯 개 필드로 이루어진 헤더가 있으며, 이 헤더 뒤에 빈 줄(캐리지 리턴 및 줄 바꿈)과 응답 본문의 첫 두 줄이 차례로 옵니다.

---

HTTP/1.0과 1.1 차이

차이점

HTTP/1.0과 1.1 Entity 차이

entity-hader의 헤더 필드가 다수 추가되었다. HTTP/1.0의 것이 다음과 같으며,

Allow
Content-Encoding
Content-Length
Content-Type
Expires
Last-Modified

HTTP/1.1에서는 위 필드에 더해 다음과 같은 것들이 추가되었다.

Content-Base
Content-Language
Content-Location
Content-MD5
Content-Range
ETag

HTTP version 1.1 에서 "host" 필드가 필요한 이유?

HTTP/1.0 vs. 1.1
HTTP는 사용자에게 보다 좋은 Internet을 서비스하기 위해 제정이 되었다.
특히 사용자나 서버 모두에게 성능의 향상과 요구되는 시간의 최소화에 중점을 두고 있다.
HTTP/1.0에서는 없거나 미약하여 HTTP/1.1에서 향상된 기능은 우선 지속적인 연결을 해 주는 persistent connection의 특징과
pipeline의 기능 및 전송하는 데이터의 양을 줄이는 데이터의 압축방식과 proxy server와 cache의 사용을 둘 수 있다.

HTTP의 기본구조와 1.0의 문제점과 이를 1.1에서 해결하는 방식에 대해서 살펴보자. HTTP는 기본적으로 MIME 형태로 이루어지며
request/response의 방식에 기반을 두고 있다. HTTP 1.0의 구조 및 문제점을 살펴보면, HTTP 1.0은 단순하게 open/operation/close의 방식을
취하고 있어서 단순하다. TCP connection당 하나의 URL만 fetch하며 매번의 request/response가 끝나면 연결이 끊기므로 매 번 필요할 때마다
다시 연결을 해야 하므로 속도가 떨어진다. 그리고 한번에 얻어서 가져올 수 있는 데이터의 양이 제한되어 있다. 나아가 URL의 크기도 작다.

HTTP/1.0에서는 connection은 TCP의 open/close을 위한 flow의 제한으로 인해서 bandwidth가 적게 할당되어 연결된다.
그래서 congestion information의 손실로 인해서 disconnect가 될 수 있다. 계속되는 disconnection현상으로 인해서 한 서버에 계속에서
접속을 시도하게 되어서 과부하가 걸리게 되고 결국에는 성능이 떨어지게 된다. 이러한 문제점을 해결하기 위해서 HTTP/1.1에서는
multiple request에 대한 처리를 가능하게 해준다. 즉, request가 많이 서버에 전달되면 서버에서는 serial하게 response을 해주어 해결을 하고 있다.
즉, request/response가 pipeline의 방식으로 진행이 가능하다.

HTTP/1.0에서는 client가 IP address와 서버가 1:1관계에 있다고 가정을 두고 있다. 그래서 request와 response는 직접 전달되고 있다고
인식한다. 하지만 HTTP/1.1에서는 하나의 IP address로 multiple web site를 지원이 가능하다. 즉 한 인터넷 주소로 여러 web site의 연결이
가능하다. 이때 client와 server는 Host request-header를 반드시 포함하고 있어야 하며 이 header를 주고 받아야 한다.

HTTP/1.1은 HTTP의 Internet에서의 impact를 줄이고 HTTP를 Internet Protocol에 잘 적용이 되도록 해주고 빨리 수행이 되도록 cache를 두어
성능을 향상하고 있다. 그리고 HTTP/1.0과 호환이 가능하다. 과거의 HTTP/1.0에서는 request와 response 메시지 모두에 적용되며 메시지의
body에는 영향을 주지 않는다. 기본적으로 HTTP/1.0에서는 Date와 Pragma를 사용하는데 이는 서버와 클라이언트의 현재시간을 알려주고
cache를 제어하기 위해 사용되는 method였으나 HTTP/1.1에서는 Pragma가 사용되지 않는다. 이 cache의 사용으로 인해 해결해야 할 부분이 있다.

즉 cache를 이용하여 어떻게 semantic하게 transparency를 제공하고 어느 적정한 수준이상의 cache가 사용되어 data가 저장되어 있는 경우
cache의 내용을 비워 주어야 한다. 이 과정은 reliable한 cache의 사용과 cache의 burst해지는 현상 등을 해결하기 위해 도입되었다.

그리고 HTTP/1.0에서는 주로 Last-Modified, 즉 Dates에만 의존해서 cache를 다루었지만 HTTP/1.1에서는 1.0에서 지원해 주는 기능 이외에
client에서 사용 가능한 미디어 타입을 명시하여 지원을 해 주고 있으며 또한 사용가능한 character set, 제공되는 encoding 방식과 인식 가능한 언어
등을 request header에 명시하여 메시지를 전달한다. 그리고 cache의 내용이 적절한지의 여부를 판단하기위해 If-Match, If-None-Match를
사용하고 있다.

또한 If-Range및 If-Unmodified-Since등을 비교하여 method를 수행할 수 있도록 하고 있다. 이 cache는 서버에 노출되어 있으므로
불필요한 자료를 막거나 주의를 요하는 자료 등은 저장하지 말아야 한다. 따라서 cache의 control에 주의를 요해야 한다.
특히 cache의 재사용을 하거나 하는 경우에는 proxy를 두어서 cache를 control하고 있다.

이때 물론 개인적인 data의 경우에는 이 proxy를 사용하지 말아야 한다. 이때 Max-Forwards를 두어서 거쳐 갈 수 있는
최대 proxy의 수를 제한할 수 있고, Proxy-Authentication을 두어 proxy server가 비공개인경우 사용자 인증을 위해 사용이 된다.
Resource의 일부만을 받고 이어받기의 기능을 지원하기 위해서 Range의 새로운 header가 추가 되었다.

이제 response의 header의 내용을 살펴보면, 우선 HTTP/1.0에서는 location과 server및 WWW-Authenticate을 이용하고 있다.
HTTP/1.1에서는 client에서 request를 보낸 이후 server에서 응답 메시지를 생성하기까지의 시간을 나타내는 age가 도입되었고,
만약 서버가 proxy server인 경우 사용자 인증을 요구하는 Proxy-Authenticate라는 헤더필드를 지원하고 있다.
그 이외에 Public, Retry-After, Warning 등의 정보가 추가되었다.

HTTP method는 우선 HTTP/1.0에서는 GET, HEAD, POST의 method가 사용되고 있는데 GET은 Request-URI에서 지정한 어떤 정보이든
Entity Body로 전달해 달라는 요청으로 이 Request-URI가 어떤 실행프로그램을 명시한 경우에는 이 프로그램의 실행결과를 전달하라는 의미이다.
HAED의 경우는 Header의 정보만 요구하는 method이고 POST는 Request 메시지의 body에 포함된 자원을 Request-URI로 넘겨주는 경우
사용한다.

HTTP/1.1에서는 통신과 관련된 선택사항들에 대한 정보를 요구하는 경우 OPTION의 method를 지원하고 있으며,
Request 메시에 포함되어 있는 data를 지정한 Request-URI로 저장하기 위한 PUT을 두고 있다. 또 특정한 resource를 지우기 위해
DELETE를 두고 있으며 최종 destination까지의 Loopback을 테스트하기 위한 TRACE method가 있다.

앞에서도 언급했지만 HTTP/1.0에서 매번 필요시에만 connection을 open하고 close하는 기능을 해결하기 위해서 HTTP/1.1에서는
multiple connection을 open할 수 있도록 하고 있다. 뿐만 아니라 몇몇 entity의 경우에는 그 길이를 모르므로 이를 해결하기 위해서
chunked encoding을 도입하여서 해결하고 있다. 그리고 전송한 data를 압축해서 전달이 가능하도록 하고 있어서 전달하고자 하는
data의 양을 줄인다.

이상에서 살펴보았듯 HTTP/1.0에서 HTTP/1.1로의 성능적인 면과 시간의 최소화에 중점을 두고 있다.