HTTP 완벽 가이드 (15)

https://drive.google.com/file/d/1GvTXg8eHt-pFyTplUl_8yyWU0fPL6dCM/view?usp=sharing

 

엔티티 길이 - Content-Length

엔티티 요약

미디어 타입과 Charset

• 텍스트 매체를 위한 문자 인코딩
• 멀티파트 미디어 타입
• 멀티파트 폼 제출
• 멀티파트 범위 응답

콘텐츠 인코딩

• 과정
• 유형
• Accept-Encoding 헤더

전송 인코딩과 청크 인코딩

• 안전한 전송
• Transfer-Encoding 헤더
• 청크 인코딩
• 콘텐츠와 전송 인코딩의 조합
• 전송 인코딩 규칙

시간에 따라 바뀌는 인스턴스

검사기와 신선도

• 신선도
• 조건부 요청과 검사기

범위 요청

델타 인코딩

• 인스턴스 조작, 델타 생성기 그리고 델타 적용기

1115

HTTP는 다음을 보장한다.

• 객체는 올바르게 식별됨 → Content-Type 미디어 포맷, Content-Language 헤더
  • 브라우저나 다른 클라이언트는 콘텐츠를 바르게 처리할 수 있다.
• 객체는 올바르게 압축이 풀림 → Content-Length, Content-Encoding
• 객체는 항상 최신임 → 엔티티 검사기, 캐시 만료 제어
• 사용자의 요구 만족 → 내용 협상용 Accept 헤더 기반
• 네트워크 사이를 빠르고 효율적으로 이동 → 범위 요청, 델타 인코딩, 그외 데이터 압축
• 조작되지 않고 온전히 도착 → 전송 인코딩 헤더, MD5 체크섬

메시지 = 컨테이너, 엔티티 = 화물

HTTP/1.0 200 OK
Server: Netscape-Enterprise/3.6
Date: Sun, 17 Sep 2000 00:01:05 GMT
Content-type: text/plain
Content-length: 18

Hi! I'm a message!

• Content-Type : 엔티티에 의해 전달된 객체의 종류
• Content-Length : 전달되는 메시지의 길이나 크기
• Content-Language : 전달되는 객체와 가장 잘 대응되는 자연어
• Content-Encoding : 객체 데이터에 대해 행해진 변형 - 압축 등
• Content-Location : 요청 시점 기준, 객체의 또 다른 위치
• Content-Range : 부분 엔티티일 경우, 이 헤더는 이 엔티티가 전체에서 어느 부분에 해당하는지 정의함.
• Content-MD5 : 엔티티 본문의 콘텐츠에 대한 체크섬
• Last-Modified : 서버에서 이 콘텐츠가 생성 혹은 수정된 날
• Expires : 이 엔티티 데이터가 더 이상 신선하지 않은 것으로 간주되기 시작하는 날짜와 시각
• Allow : 이 리소스에 대해 허용되는 요청 메서드
• ETag : 인스턴스에 대한 고유한 검사기
• Cache-Control : 어떻게 이 문서가 캐시될 수 있는지에 대한 지시자.

Content-Length

메시지의 엔티티 본문의 크기를 바이트 단위로 나타냄.

옛날 HTTP → 커넥션이 닫힌 걸 보고 메시지가 끝났음을 인지함.

• 커넥션이 정상적으로 닫힌 것인지 서버 충돌 발생인지 구분하지 못함. → 메시지 잘림 검출용도
• 캐싱 프락시 서버 - 잘린 메시지 인식 못하면 결함 있는 콘텐츠를 저장하고 계속 제공하게 됨.
  • 명시적으로 Content-Length 헤더를 갖고 있지 않은 HTTP 본문은 보통 캐시하지 않음

잘못된 값을 담고 있는 Content-Length →

• HTTP/1.1 사용자 에이전트는 잘못된 길이를 받고 그 사실을 인지했을 때 사용자에게 알려주게 되어있음

지속 커넥션

커넥션이 닫힌 위치를 근거로 메시지 끝 인식 불가능.

• 청크 인코딩 사용 시 Content-Length 헤더 없는 지속 커넥션을 만날 수 있음.
• 서버가 헤더 생성 시점에 엔티티 전체의 크기를 알 수 없다 하더라도, 서버는 청크 인코딩을 이용해 엔티티를 잘 정의된 크기의 조각들로 전송할 수 있음.

콘텐츠 인코딩

보안 강화, 압축을 통한 공간 절약 → 엔티티 본문을 인코딩함.

• Content-Length 인코딩된 본문의 길이를 바이트 단위로 정의함.
• HTTP/1.1 명세의 어떤 헤더도 원 본문의 길이를 보내기 위해 사용x → 클라이언트 디코딩 과정 검증을 어렵게 만듦.
  • MD5헤더도 인코딩된 문서를 해시한 결과.

엔티티 본문 길이 판별 규칙

1. 본문이 없는 메시지에서는 content-length 헤더가 무시됨.

• 실제 본문 길이를 서술하지 않음. 부가정보에 불과함.
• ex) HEAD 응답, 1XX, 204, 304 응답 = 본문을 갖지 않음. 정보성 content-length 헤더를 갖긴함.
• 엔티티 본문을 금하는 메시지는 어떤 엔티티 헤더 필드가 존재하느냐와 상관없이 반드시 헤더 이후의 첫 번째 빈 줄에서 끝나야 함.

1. Transfer-Encoding 헤더 포함 메시지(기본 HTTP ‘identity’ 인코딩과는 다른)

• 커넥션이 닫혀서 먼저 끝나지 않는 이상 ‘0바이트 청크’ 라고 불리는 특별한 패턴으로 끝나야 함.

1. content-length 헤더, transfer-encoding 헤더 포함 메시지 → 전자 무시해야 함. 전송 인코딩은 엔티티 본문을 표현하고 전송하는 방식을 바꿈.
2. multipart/byteranges 미디어 타입 사용, 엔티티 길이가 별도로 정의 x라면, 멀티파트 유형은 자신의크기를 스스로 결정함. → self-defining 이 미디어 타입은 수신자가 이것을 해석할 수 있다는 사실을 송신자가 알기 전까지는 절대로 보내지 말아야 함. *RFC 7230에서 삭제됨.
3. 위의 어떤 규칙에도 해당되지 않는다면, 엔티티는 커넥션이 닫힐 때 끝남. *오직 서버만이 메시지가 끝났음을 알리기 위해서 커넥션을 닫을 수 있음. 클라이언트가 커넥션을 닫아버리면 서버가 응답을 돌려줄 방법이 없음.

엔티티 요약

Content-MD5 : 콘텐츠 인코딩만 적용된 엔티티 본문에 대한 MD5.

메시지의 무결성을 검증하려는 클라이언트는 먼저 전송 인코딩을 디코딩한 뒤 그 디코딩 된 엔티티 본문에 대해 MD5를 계산해야 함.

ex) 어떤 문서를 gzip 알고리즘으로 압축하여 청크 인코딩으로 보냈다면, MD5 알고리즘은 압축된 본문 전체에 대해 수행

• 문서 위치 알아내기, 중복 저장 방지 등 → 해시 테이블의 키

Want-Digest

헤더에 품질값을 이용해 여러 요약 알고리즘을 제안하고 각각에 대한 선호도 지정

미디어 타입과 차셋(Charset)

Content-Type 헤더 필드 → 엔티티 본문의 MIME 타입 기술

• 전달되는 데이터 매체의 기저 형식의 표준화된 이름.
• 주 미디어 타입 / 부 타입(subtype)

text/html 엔티티 본문은 HTML 문서

text/plain	엔티티 본문은 플레인 텍스트 문서
image/gif	GIF 이미지
image/jpeg	JPEG 이미지
audio/x-wav	WAV 음향 데이터 포함
model/vml	삼차원 VRML 모델
application/vnd.ms-powerpoint	마이크로소프트 ppt
multipart/byteranges	각 부분은 전체 문서의 특정 범위(바이트 단위)를 담고 있음
message/http	완전한 HTTP 메시지

멀티파트 미디어 타입

서로 붙어 있는 여러 개의 메시지 포함. 하나의 복합 메시지로 보내짐.

• 두 종류의 데이터가 하나의 http Request Body에 들어가야 함.

HTTP 멀티파트 본문도 지원함.

• 폼을 채워서 제출
• 범위 응답

---

텍스트 필드 + 업로드 될 객체

• Content-Type: multipart/form-data
• Content-Type: multipart/mixed

Content-Type: multipart/form-data; boundary=[abcdefghikjlmnopqrstuvwxyz]

• boudary : 본문의 서로 다른 부분 구분자

---

Spring MVC - MultipartResolver

<form method="post" action="upload" enctype="multipart/form-data">

• 이미지 파일도 문자 → 이미지를 문자(binary)로 생성해 HTTP request body에 담아 전송함.

Content-Type: multipart/form-data; boundary=AaB03x
--AaB03x
Content-Disposition: form-data; name="submit-name"
Sally
--AaB03x
Content-Disposition: form-data; name="files"
Content-Type: multipart/mixed; boundary=BbC04y
--BbC04y
Content-Disposition: form-data; name="imagefile.gif"
Content-Type: image/gif
--BbC04y
Content-Disposition: form-data; name="imagefile.gif"
Content-Type: image/gif
Content-Transfer-Encoding: binary
...contents of imagefile.gif...
--BbC04y--
--AaB03x--

콘텐츠 인코딩

유형

• gzip
• compress
• deflate
• identity

Accept-Encoding 헤더

클라이언트가 지원하는 인코딩의 목록을 전달하는 요청 헤더

• 포함하지 않으면 서버는 클라이언트가 어떤 인코딩이든 받아들일 수 있는 것으로 간주함.
• Q(quality) 값 → 선호도 0.0 ~1.0 의미

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip; q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

• identity 인코딩 토큰은 이 헤더에만 존재할 수 있음.
  • 클라이언트에 의해 다른 콘텐츠 인코딩 알고리즘에 대한 상대적 선호도를 정의하는 데 이용할 수 있음.

전송 인코딩과 청크 인코딩

안전한 전송

• 몇몇 게이트웨이 애플리케이션과 콘텐츠 인코더는 콘텐츠를 먼저 생성하지 않고서는 메시지 본문의 최종 크기를 판단할 수 없음.
• HTTP는 데이터에 앞서 Content-Length 헤더를 요구하기 때문에, 몇몇 서버는 데이터의 끝을 알리는 특별한 종결 꼬리말을 포함시켜 전송 인코딩으로 데이터를 보내려 시도함.
• 보안 → 전송 인코딩으로 알아보기 어렵게 섞어버림. 이미 SSL과 같은 방식이 있음.

Transfer-Encoding

전송 인코딩에서 사용하는 두 가지 헤더

• Transfer-Encoding : 어떤 인코딩이 적용되었는지 수신자에게 알려줌
• TE(Accept-Transfer-Encoding) : 어떤 확장된 전송 인코딩을 사용할 수 있는지
  • Q값(선호도 표현)을 가질 수 있음.
  • HTTP/1.1 명세는 청크 인코딩에 대해 Q값이 0.0을 갖는 것을 금지함.

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

7\\r\\n
Mozilla\\r\\n
9\\r\\n
Developer\\r\\n
7\\r\\n
Network\\r\\n
0\\r\\n
\\r\\n

청크 인코딩

A server MUST NOT send a Transfer-Encoding header field in any response with a status code of 1xx (Informational) or 204 (No Content). A server MUST NOT send a Transfer-Encoding header field in any 2xx (Successful) response to a CONNECT request (Section 9.3.6 of [HTTP]).

• 정보성 상태코드, 204코드와 함께 응답을 보낼 때 Transfer-Encoding 헤더 전송 금지
• CONNECT 요청에 대한 2xx 응답에도 전송 x
• 이해 불가능한 transfer coding 요청 메시지를 받으면 501(Not Implemented)로 응답해야 함.

지속 커넥션

콘텐츠가 서버에서 동적으로 생성되는 경우엔 본문의 길이를 알 수 없음.

→ 본문을 여러 청크로 쪼개 보냄

• 크기가 0인 청크로 본문이 끝났음을 알림

청크 요청은 411 Length Required 응답으로 거절당할 수 있음.

트레일러 추가 요건

• 클라이언트의 TE 헤더가 트레일러를 받아들일 수 있음을 나타내고 있는 경우
• 트레일러가 응답을 만든 서버에 의해 추가되었으며, 그 트레일러의 콘텐츠는 클라이언트가 이해하고 사용할 필요가 없는 선택적인 메타데이터이므로 클라이언트가 무시하고 버려도 되는 경우
  • HTTP/1.1에 Trailer가 추가된 것은 청크 인코딩의 초기 버전 추가보다 나중. 호환 x 가능성 있음.
• Transfer-Encoding, Trailer, Content-Length 제외 어떤 HTTP 헤더도 트레일러로 보낼 수 있음.

콘텐츠 인코딩과 전송 인코딩은 동시에 사용될 수 있음.

검사기, 신선도

인스턴스는 시간에 따라 바뀜. 클라이언트에서 문서가 만료되면 반드시 서버에게 최신 사본을 요구해야 함.

• 조건부 요청 : 자신이 갖고 있는 버전을 서버에게 말해주고 검사기를 사용해 자신의 사본 버전이 더 이상 유효하지 않을 때만 사본을 보내달라고 말해주는 것

클라이언트가 같은 리소스에 한 번 이상 접근 → 현재사본 신선도 판별

• 신선 x → 서버로부터 최신 버전을 얻어와야 함.

범위 요청

클라이언트가 받다가 실패한 엔티티를 일부 혹은 범위로 요청 → 다운로드를 중단된 시점에서 재개할 수 있음.

GET /bigfile.html HTTP/1.1
Host: www.joes-hw.com
Range: bytes=4000-  #처음 4,000 바이트 이후 부분 요청
...

• Range → 여러 범위로 요청을 하기 위해 사용될 수 있음.
• 예) 어떤 문서에 대한 다운로드 시간을 줄이기 위해 동시에 여러 서버에 접속해서 같은 문서에 대해 서로 다른 범위를 요청하는 클라이언트.
• 하나의 요청으로 여러 범위 요청 → 응답 엔티티 = 멀티파트 본문 + Content-Type: multipart/byteranges 헤더
• Accept-Range: <측정 단위> 헤더를 포함시켜서 서버가 범위를 받아들일 수 있는지 알려주는 방법
  • 단위는 주로 바이트

HTTP/1.1 200 OK
Date: Fri, 05 Nov 1999 22:35:15 GMT
Server: Apache/1.2.4
Accept-Ranges: bytes

• 클라이언트의 범위 요청은 클, 서가 같은 버전의 문서를 갖고 있을 때만 의미 있음.

델타 인코딩

클라이언트의 사본에 대해 변경된 부분만을 서버가 전송

• 객체 전체가 아닌 변경된 부분에 대해서만 통신하여 전송량을 최적화하는 HTTP 프로토콜의 확장

1. 클이 갖고 있는 버전(ETag), 델타 적용 알고리즘을 서버에게 알려줘야 함.
2. 서버 - 버전 체크, 어떻게 최신과 클의 버전 사이 델타를 계산할 것인지 체크(알고리즘)
3. 델타를 보내주고, 보내고 있음을 알려주고, 최신 버전에 대한 새 식별자를 알려줘야 함
   1. 식별자=새로운 페이지의 버전

• A-IM : 받아들일 수 있는 인스턴스 조작의 종류를 가리키는 요청 헤더
• IM : 적용된 인스턴스 조작의 종류를 명시하는 서버의 응답 헤더
  • 코드 226 IM Used일 때 보냄
• Delta-Base : 델타를 생성하기 위해 사용된 기저 문서의 ETag를 명시하는 서버 응답 헤더
  • 클라이언트 요청의 ETag와 같아야 함

종류 설명

vcdiff	vcdiff 알고리즘을 이용한 델타
diffe	유닉스 diff-e 명령 이용 델타
gdiff	gdiff 알고리즘
gzip	gzip 압축
deflate	압축
range	범위선택에 대한 결과인 부분 콘텐츠 응답임을 말해주기 위해 서버 응답에서 사용됨.
identity	클라이언트가 identity 인스턴스 조작을 받아들일 의사가 있음을 말해주기 위해 A-IM 헤더에서 사용됨

유닉스 ed 편집기

diff -e <file1> <file2>

• <file1>을 <file2>로 변환해주는 ed 명령의 집합 생성

델타 인코딩은 전송 시간을 줄일 수 있지만 서버가 반드시 클라이언트가 갖고 있던 이전 버전의 사본들 모두를 유지해야만 함.

→ 제공 시간은 줄어들지만 디스크 공간 확장 필요