Luavis' Dev Story

HTTP 1.1은 HTTP 1.0의 부족한 점을 보강하고자 정해진 표준으로 1999년에 RFC 2616으로 등록되어 있다. 1.0의 HTTP 버전 설명에 나와있듯, 몇 가지 용어에 대해서 정의가 변경되거나, 확장되었을 뿐 기본적인 프로토콜의 메세지 구조는 똑같다.(다른 그것을 보고 싶다면 HTTP/2를…)

따라서 이 장에서는 전체적인 해석보다는 부분적으로 달라진 점에 대해서 확인해 볼 것이다.

Missing Charset

몇몇 HTTP/1.0 소프트웨어들인 ISO-8859-1이 아닌 상태에서 Content-Type에 charset을 병기하지 않은 사례가 많다. 이런 경우 보통은 Client에서 charset에 대해서 추론을하는데, 몇몇 낡은 브라우저에서는 Content-Type의 charset보다 추론한 charset을 우선하는 경우가 많다. HTTP/1.1은 추론한 charset보다는 Content-Type에 써져있는 charset을 존중해주어야한다.

Content-Coding

HTTP/1.0에서 앞에 x-를 붙히는 prefix없이 gzip과 compress를 사용하고, 하지만 여전히 x-를 붙힌 x-compress와 x-gzip은 x- prefix를 제거하고 해석 해주어야한다. 그외에 두 가지 token이 표준으로 정의되었다:

deflate
    The "zlib" format defined in RFC 1950 [31] in combination with
    the "deflate" compression mechanism described in RFC 1951 [29].

identity
	The default (identity) encoding; the use of no transformation
	whatsoever. This content-coding is used only in the Accept-
	Encoding header, and SHOULD NOT be used in the Content-Encoding
	header.

identity같은 경우에는 Accept-Encoding 헤더에서만 사용할 수 있도록 정의되어 있고, Cotnent-Encoding 헤더에서는 사용하면 안된다. 의미상 변형 없이 달라는 의미이기 떄문이다.

Transfer Codings

큰 데이터를 전송함에 있어 전송의 안정성을 높히기 위해서 사용한다. 대용량의 데이터를 전송시 중간 손실의 위험이 있어 잘게 자른 데이터로 보내는 방식인데, 표준에 나와있는 ABNF는 아래와 같다:

transfer-coding         = "chunked" | transfer-extension
transfer-extension      = token *( ";" parameter )

Parameters are in  the form of attribute/value pairs.

parameter               = attribute "=" value
attribute               = token
value                   = token | quoted-string

Chunked-Body   = *chunk
                last-chunk
                trailer
                CRLF

chunk          = chunk-size [ chunk-extension ] CRLF
                chunk-data CRLF
chunk-size     = 1*HEX
last-chunk     = 1*("0") [ chunk-extension ] CRLF

chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val  = token | quoted-string
chunk-data     = chunk-size(OCTET)
trailer        = *(entity-header CRLF)

이를 실제 HTTP에서 사용할 경우 아래 사진과 같은 형태의 chunk 메세지들을 볼 수 있다.

chunk message

Quality Values

HTTP에서는 헤더에서 parameter를 이용하여 값에 중요성을 부동소숫점으로 나타낼 수 있는데,

qvalue         = ( "0" [ "." 0*3DIGIT ] )
              | ( "1" [ "." 0*3("0") ] )

이와 같은 형식으로 사용한다. 실제 사용 예를 보면:

Accept-Language:ko-KR,ko;q=0.8,en-US;q=0.6,en;q=0.4,ja;q=0.2

같은 형식으로 사용자가 어떤 언어를 선호하는지에 대하여 수치적으로 나타내어준다.

Entity Tags

Entity Tags(ETag)는 같은 URI에서 다수의 entity들의 동일성을 확인하기 위하여 사용한다. HTTP/1.1에서는 entity tag를 ETag를 If-Match나 If-None-Match If-Range같은 헤더에서 사용하고, 아래와 같은 형식으로 ETag를 발급한다.

entity-tag = [ weak ] opaque-tag
weak       = "W/"
opaque-tag = quoted-string

여기서 Strong ETag와 Weak ETag가 있는데 Strong은 하나의 ETag가 동일한 두 entity를 가르키고 있는 경우에 사용된다. weak ETag는 동일하거나, 의미상 큰 변화가 없어 대체 가능한 두 entity를 하나의 ETag가 가르키고 있음을 말하는걸로 “W/” prefix를 붙힌다.

Range Units

Range와 Content-Range 헤더를 이용하여, HTTP/1.1은 특정 부분만을 요청하는것이 가능하다. HTTP/1.1에서는 이를 bytes단위로 사용하는데 다른 단위를 사용할 경우 무시될 수 있다.

range-unit       = bytes-unit | other-range-unit
bytes-unit       = "bytes"
other-range-unit = token

Persistent Connections

각각의 URL마다 TCP connection을 따로 생성하는것은 HTTP server로부터 로딩 시간을 증가시킵니다. 이런 점을 보안하기 위해서 1.1버전에서는 지속적인 HTTP connection을 지원한다. 이를 통해 얻을 수 있는 장점은

TCP connection을 열고 닫는데에 발생하는 비용절감.
HTTP의 request와 response가 한 개의 connection에서 파이프라인이 가능하다.
통신에러 발생시 TCP close없이 바로 재요청이 가능하다.

HTTP 구현체는 persistent connection을 구현해야한다.

파이프라인

persistent connection을 지원하는 클라이언트는 pipeline을 지원할 수 있다. 이는 request를 response의 대기 없이 한번에 전송하는 것이다. client는 파이프라인을 시도해보고 첫 connection에서 fail될 경우 서버가 지원이 안된다고 생각하고 재전송한다.

이 외의

추가 METHOD와 Header, 캐시에 관한 설명은 이 글을 참조해주세요..