HTTP 완벽가이드 - 4. 콘텐츠 및 인코딩

19 분 소요

4부 콘텐츠/인코딩

15장 엔터티와 인코딩

HTTP 메시지와 엔터티

: 메세지는 운송 컨테이너고 엔터티가 실질적인 화물

엔터티 헤더
- HTTP 메세지의 내용물을 기술
- 주요 헤더: Content-Type, Content-Length, Last-Modified, Allow, ETag 등
엔터티 본문
- 미가공된 데이터를 내포
- 헤더 필드의 끝 의미하는 빈 CRLF 줄 다음부터 시작 (콘텐츠 종류/언어 무관)

Content-Length 헤더

특성
- 엔터티 본문 길이 바이트 단위로 표시
- 인코딩/압축 여부와 무관하게 크기 표현 가능 => 인코딩/압축 후의 본문 길이값 표시
- 청크 인코딩으로 전송하지 않는 한 필수값
기능
- 서버 충돌로 인한 메세지 잘림 검출
  - 길이값 모를 경우 커넥션이 정상적으로 닫혔는지 알 수 없음
  - 캐싱 프록시 서버는 오류 방지 위해 Content-Length 값 있어야 캐시함
  - Content-Length 값 잘못된 경우 버그 발생 가능
    => HTTP/1.1의 사용자 에이전트는 길이값 오류 시 사용자에게 안내
- 지속커넥션의 공유메세지 분할
  - 커넥션 지속 시 커넥션 닫힌 위치로 메세지 끝 인식 불가
    => Content-Length 값 필수
    but) 청크 인코딩 사용 시 데이터가 일정 크기로 분할되므로 전체 길이값 몰라도 됨
길이값 판별 규칙 (순서대로 적용) 1) 본문이 없는 특정 타입 HTTP 메세지에서는 Content-Length 헤더 무시됨
ex) HEAD 응답 2) 메세지에 Transfer-Encoding 헤더 포함 시 ‘0 Byte 청크’ 패턴으로 끝나야
cf) 커넥션 닫혀서 먼저 끝나지 않는 한 3) Content-Length 값 허용된 메세지에
- Transfer-Encoding 헤더 없는 경우 => Content-Length 값에 본문 길이값을 저장
- Transfer-Encoding 헤더 있는 경우 => Content-Length 값 무시 4) 메세지가 multipart/byteranges 타입이고 Content-Length 값 미정의 시
- 메세지의 각 부분은 각자 스스로 크기를 정의
- 수신자가 해당 미디어 타입 해석할 수 있을 때만 송신해야 5) 위 규칙에 미해당 시 엔티티는 커넥션이 닫힐 때 종료
- 서버만 메세지 끝났음 알리기 위해 커넥션 닫을 수 있음 6) HTTP/1.0 어플리케이션과 호환 시 유효한 Content-Length 값 필수
- 길이값 판별 불가능 시 400(Bad Request) 응답 전송 권고
- 유효한 content-Length 값 요구 시 411(Length Required) 응답 전송 권고

엔터티 요약

특성
- 불완전한 전송 및 변형 감지 위해 최초 엔터티 생성 시 체크썸 생성 가능
  => 중간의 프록시나 캐시는 체크썸 헤더 변경/추가 말아야
- 수신자는 비의도적인 엔터티 변경 감지 위해 체크썸으로 기본적인 검사 가능
- 체크썸은 인코딩/압축 처리 후의 계산값임
요약 헤더
- Content-MD5
  - 엔터티 본문의 MD5 알고리즘 계산값
  - 활용가치 있으나 자주 이용되지는 않음
- Want-Digest
  - 2002년에 새로 승인된 헤더 (RFC3230)
  - 품질값(quality value) 이용해 여러 요약 알고리즘 제안 및 선호도 지정 가능

미디어 타입

특성
- Content-Type 헤더는
  - 엔터티 본문의 MIME 타입을 기술
  - 인코딩 전의 엔터티 본문 유형을 명시
  - MIME 타입 외에 추가적인 매개변수 지원
    ex) Content-Type: text/html; charset=EUC-KR
- MIME 타입은
  - 데이터 매체의 기저 형식 표준 명칭임
  - IANA(Internet Assigned Numbers Authority)에서 등록
  - 형식: 주_미디어타입/부_타입

대표적 타입

명칭	엔터티 본문
text/html	HTML 문서
text/plain	플레인 텍스트 문서
image/gif	GIF 이미지
image/jpeg	JPEG 이미지
audio/x-wav	WAV 음향데이터
model/vrml	삼차원 VRML 모델
application/vnd.ms-powerpoint	MS 파워포인트 프레젠테이션
multipart/byteranges	전체 문서의 특정 범위(Byte 단위) 담은 여러 부분으로 나뉨
message/http	완전한 HTTP 메세지 (6장의 TRACE 메소드 참고)

멀티파트
- 멀티파트 미디어 타입
  - 서로 연결된 여러 메세지를 하나의 복합메세지로 전송
  - 각 구성요소는 자족적인 자기 기술 헤더를 포함
  - 각 구성요소는 문자열 하나로 서로의 경계를 식별
- 멀티파트 폼 제출
  - 가변 길이 텍스트 필드와 업로드 객체는 각각 멀티파트 본문 구성하는 하나의 파트로 전송됨
  - 멀티파트 본문은 여러 다른 종류와 길이값으로 채워진 폼을 허용
  - ex) Content-Type: multipart/form-data; boundary=[abcdefghijklmnopqrstuvxyz]
  - ex) Content-Type: multipart/mixed; boundary=BbC04y
- 멀티파트 범위 응답
  - 범위요청에 대한 응답 또한 멀티파트가 될 수 있음
    => Content-Type: multipart/byteranges 헤더와 각각 다른 범위 담은 멀티파트 본문이 함께 전송됨

콘텐츠 인코딩

과정 1) 서버가 Content-Type과 Content-Length 헤더 포함된 응답메세지를 생성 2) 콘텐츠 인코딩 서버(원 서버나 프록시)가 인코딩된 메세지를 생성
- Content-encoding 헤더를 추가
- Content-Length 헤더를 수정 3) 수신자가 인코딩된 메세지 수신 및 디코딩 처리 통해 원본 취득

유형

HTTP 몇 개의 표준 콘텐츠 인코딩 유형 및 확장 인코딩을 허용
IANA는 각 콘테츠 인코딩 알고리즘에 고유한 토큰 할당해 인코딩을 표준화

대표적 인코딩 토큰

명칭	무손실 압축	상세
gzip	o	GNU zip 인코딩 적용됨 (효율적이고 널리 사용되는 압축 알고리즘)
compress	o	compress가 실행됨 (유닉스의 파일압축 프로그램)
deflate	o	zlib 포맷으로 압축됨
identity	x	- 어떤 인코딩도 적용 안 됨 - Content-Encoding 없는 경우 이 값으로 간주

Accept Encoding 헤더
- 클라이언트가 지원하는 인코딩 목록을 전달
- 값 없거나 값이 *인 경우 어떤 인코딩도 수용하는 것으로 간주
- 각 인코딩에 Q(quality)값 설정해 선호도 표시 가능
  - 선호도 범위: 0.0 (비선호) ~ 1.0 (선호)
  - 토큰이 *인 경우 ‘나머지 모든 인코딩’을 의미
    ex) Accept-Encoding: gzip;q=1.0, identity;q=0.5, *;q=0

전송 인코딩

특성
- 전송 인코딩 또한 엔터티 본문에 적용되는 가역적 변환
- 구조적인 이유로 적용되며 콘텐츠 포맷과는 무관
- 메세지 데이터가 네트워크 통해 전송되는 방법 바꾸기 위해 전송 인코딩 적용 가능
- 콘텐츠 인코딩과 동시에 사용 가능
문제점
- 알 수 없는 크기
  - 콘텐츠를 생성해야만 본문의 최종 크기 알 수 있는 경우 길이값 모른 채로 전송 시작
  - 데이터 끝을 알리는 종결 꼬리말 포함해 전송 인코딩으로 전송 시도
    => 이를 ‘저렴한’ 메세지 종결 신호로 간주하고 커넥션 종료 시 지속 커넥션 망가질 수도
- 보안
  
  전송 전에 본문을 뒤섞어 암호화 할 수 있으나 SSL과 같은 전송계층 보안 방식을 사용하는 것이 일반적
헤더
- Transfer-Encoding
  
  안전한 전송 위해 어떤 인코딩이 메세지에 적용됐는지 수신자에게 안내
  ex) Transfer-Encoding: chunked
- TE
  - 어떤 확장 전송 인코딩 사용 가능한지 서버에게 안내
  - Q값으로 선호도 표시 가능
  - HTTP/1.1은 청크인코딩 선호도에 0.0 설정 금지
    ex) TE: trailers, chunked
규칙 (적용 필수)
- 전송 인코딩 집합은 반드시 chunked 포함해야 (메세지가 커넥션 종료로 끝나는 경우 제외)
- 청크 송 인코딩 사용 시 메세지 본문에 적용된 마지막 전송 인코딩 있어야
- 청크 전송 인크딩은 반드시 메세지 본문에 한 번 이상 적용돼야 => 수신자가 메세지 길이값 인식 가능
- 비 HTTP/1.1 어플리케이션에 전송하지 않아야
- 서버는 이해할 수 없는 전송 인코딩 수신 시 501(Unimplemented)로 응답해야

청크 인코딩(Chunked Encoding)

특성
- 메세지를 일정 크기의 청크로 쪼개고 순차적으로 전송
- 메세지 보내기 전에 전체 길이값 알 필요 없어짐
- 본문이 동적으로 생성 => 본문 일부를 청크에 담고 청크의 길이값과 함께 전송 => 전체 보낼 때까지 반복
- 전송 인코딩의 한 형태로 본문이 아닌 메세지의 속성임 <-> 멀티파트 인코딩은 본문의 속성
- 청크 길이값
  - 16진수 형식
  - Byte 단위로 표시
  - CRLF로 청크의 데이터와 구분
지속커넥션
- 서버는 크기가 0인 청크 전송해 본문 끝났음을 안내
  => 커넥션 끝나지 않아도 본문 끝났음 알 수 있음
기본구조
- HTTP 응답 헤더 블록
- 청크 스트림
- 마지막 청크: 길이가 0
- 트레일러
  - 메세지 헤더에 Trailer 헤더가 있을 때만 존재
  - TE 헤더가 트레일러 수용 가능 표시하거나 클라이언트가 무시 가능한 선택적 메타데이터인 경우 추가 가능
  - 메세지 헤더는 청크 인코딩 메세지 다음에 오게 될 헤더들을 Trailer 헤더에 나열
    but) Transfer-Encoding, Trailer, Content-Length 헤더는 나열 불가

인스턴스

인스턴스
- 동적인 객체의 시간에 따른 스냅숏
인스턴스 조작
- HTTP에서 정한 특정한 종류의 요청이나 응답 다루는 방법
- 클라이언트가 소지한 리소스 사본과 서버의 원본 비교해 상황에 따라 새 인스턴스 요청하는 메커니즘
- ex) 범위요청, 델타 인코딩

검사기와 신선도

조건부 요청

리소스가 변경된 경우에만 사본 요청하는 HTTP 요청 메세지
조건을 충족할 때만 수행됨 <-> 충족 못하면 HTTP 에러코드 반환
If- 로 시작하는 조건부 헤더에 의해 구현
특정 검사기 위에서 동작

검사기

문서의 테스트된 특정 속성
ex) 일련번호, 버전번호, 문서 최종변경일 등

종류

명칭	상세	예시
약한 검사기 (Weak Validator)	약간의 변경점은 같은 것으로 취급	Byte 크기 최종변경시각
강한 검사기 (Strong Validator)	언제나 고유하게 식별하며 모든 변경점을 변경값으로 취급	암호체크썸 ETag (태그 앞에 `W/` 붙이는 경우 약한 엔터티 태그)

유형

요청유형	검사기	상세
If-Modified-Since	Last-Modified	지난 `Last-Modified`헤더에 기술된 시각 이후 변경점 존재하는 경우 리소스 사본 전송하라
If-Unmodified-Since	Last-Modified	지난 `Last-Modified` 헤더에 기술된 시각 이후 변경점 존재하는 경우 리소스 사본 전송하라
If-Match	ETag	지난 `ETag` 헤더에 기술된 값과 엔터티 태그가 일치하는 경우 리소스 사본 전송하라
If-None-Match	ETag	지난 `ETag` 헤더에 기술된 값과 엔터티 태그가 불일치하는 경우 리소스 사본 전송하라

신선도
- 콘텐츠가 유효하다고 가정할 수 있는 캐시 가능 기간 정보
- 서버가 Expires(절대시간)나 Cache-Control(상대시간) 헤더 통해 안내 가능

Cache-Control 헤더

서버에서 떠난 후로부터의 총시간 초단위로 계산
시계 동기화에 비의존적이므로 더 정확

지시자

메세지타입	지시자	상세
요청	no-cache	서버와의 최초 재검사 없이 캐시된 사본 반환 금지
요청	no-store	캐시된 사본 반환 및 캐시에 응답 저장 금지
요청	max-age = `n`	n초보다 오래되지 않은 캐시문서만 요청
요청	max-stale = `n`	만료시각이 n만큼 지난 문서도 제공 허용
요청	min-fresh = `n`	지금으로부터 n초 전까지의 문서만 허용
요청	no-transform	문서 보내기 전 변형 금지
요청	only-if-cached	캐시에 있는 사본만 요청
응답	public	응답은 어떤 캐시로도 캐시 가능
응답	private	응답은 하나의 클라이언트만 접근 가능한 형태로 캐시됨
응답	no-cache	- 지시자가 헤더필드 목록 동반 시 콘텐츠는 캐시되어 클라이언트에게 제공 가능하며, 그 전에 헤더 필드들은 반드시 제거되어야 - 헤더필드 미 지정 시 캐시된 사본은 서버의 재검사 없이 제공 불가
응답	no-store	응답은 절대로 캐시되면 안 됨
응답	no-transform	응답은 제공 전에 어떤 식으로도 수정 불가
응답	must-revalidate	응답은 제공 전에 반드시 서버 통해 재검사 해야
응답	proxy-revalidate	공유된 캐시는 반드시 응답을 원 서버 통해 재검사 해야 (개인 캐시는 무시 가능)
응답	max-age = `n`	문서는 캐시 가능하고 n초보다 오래되지 않은 경우 신선함
응답	s-max-age = `n`	공유된 캐시에 적용 가능한 문서의 최대 수명을 정의 `max-age` 지시자 덮어씀 (개인 캐시는 무시 가능)

stale: 신선하지 않은

범위 요청

특성
- 문서의 일부분이나 특정 범위만 요청하는 HTTP 요청 메세지
- 받다가 실패한 엔터티를 다운로드 중단 시점부터 요청 재개 가능
- 모든 서버가 지원하지는 않으나 많은 경우 지원

Accept-Range 헤더

서버가 클라이언트에게 범위 요청 가능한지 안내 가능

ex)

HTTP/1.1 200 OK
Date: Fri, 22 Jan 2021 16:00:15 GMT
Server: Apache/2.1.2
Accept-Ranges: bytes

Range 헤더
- 여러 범위로 요청 가능 (각 범위는 순서 없고 겹칠 수 있음)
- 하나의 요청으로 여러 범위 요청 시 응답은 하나의 멀티파트 본문으로 반환
  => Content-Type: multipart/byteranges 헤더 포함
- 주의! 인스턴스 조작의 일종임 => 클라이언트와 서버가 동일 버전 문서 소지해야 의미 있음
- ex)
```
GET /bigfile.do HTTP/1.1
HOST: www.test.kr
Range: bytes=5000-
User-Agent: Mozilla/7.62 [ko] (WinNT; I)
```

델타 인코딩

특성
- 페이지 전체 대신 클라이언트가 소지한 사본에 대해 변경된 부분만 통신하는 HTTP프로토콜 확장 (FRC3329)
- 일종의 인스턴스 조작 (특정 객체의 인스턴스에 대한 클라이언트-서버 정보교환에 의존)
- 전송시간 절감할 수 있으나 구현 까다로울 수도
- 서버는 변경된 사본 유지 필요 ???
과정
- 클라이언트가 델타 요청 메세지를 서버에 전송
  - 캐시된 사본의 버전 정보 포함
  - 델타 적용하기 위한 차이점 계산 알고리즘 정보 포함
- 서버가 델타 생성 및 클라이언트에게 전송
  - 델타 보내고 있음을 명시
  - 최신 버전에 대한 새 식별자 명시
- 클라이언트가 수신된 델타를 사본에 적용해 최신버전 생성
  - ETag에 최신 버전정보 갱신

헤더

명칭	상세
Etag	문서의 각 인스턴스의 유일한 식별자 서버가 응답에 담아 전송 클라이언트가 다음번 요청 시 `If-Match`, `If-None-Match` 헤더에 사용
If-None-Match	클라이언트가 보내는 요청 헤더 서버와 클라이언트의 문서 버전이 불일치하는 경우에만 요청
A-IM	수용 가능한 인스턴스 조작의 종류 명시하는 클라이언트 요청 헤더
IM	적용된 인스턴스 조작 종류 명시하는 서버 응답 헤더 응답 코드가 `226(IM Used)`일 경우 전송
Delta-Base	델타 생성 위해 사용된 기저 문서의 Etag 명시하는 서버 응답 헤더 (클라이언트 요청의 `If-None-Match` 헤더의 `ETag`와 동일해야)

인스턴스 조작

반환 전 압축률 높이기 위해 복수의 인스턴스 조작 가능

명칭	상세
vcdiff	vcdiff 알고리즘 이용한 델타 diff 알고리즘보다 강력해서 텍스트 파일 외에도 적용 가능 일반적으로 diff -e 보다 더 작은 델타 생성
diffe	유닉스의 `diff -e` 명령 사용한 델타 유닉스 ed 편집기 사용해 델타 적용 가능 파일에 대한 줄 단위 비교 수행 => 바이너리 파일에 이용 불가
gdiff	gdiff 알고리즘 이용한 델타
gzip	gzip 알고리즘 이용한 압축
deflate	deflate 알고리즘 이용한 압축
range	현재 응답이 범위선택에 대한 결과(partial 콘텐츠)임을 안내하기 위한 서버 응답
identity	클라이언트가 identity 인스턴스 조작 수용의사 있음 안내하기 위한 클라이언트 요청 `A-IM` 헤더에서 사용

16장 국제화

16.1 국제적인 콘텐츠 지원

서버
- 클라이언트에게 각 문서의 문자/언어 알려야
- HTTP Content-Type charset 매개변수 통해 어떻게 콘텐츠를 올바른 출력 글자로 바꿀지 안내
- Content-Language 헤더 통해 콘텐츠 텍스트의 언어 서술
클라이언트
- Accept-Charset 통해 서버에 수용가능/선호하는 캐릭터셋 인코딩 알고리즘 안내
- Accept-Language 통해 서버에 수용가능/선호하는 언어 안내
HTTP Accept 관련 헤더
- q: 품질인자 (quality factor)로 선호도 표현, 기본값 =1.0
- ex)
```
Accept-Language: fr, en;q=0.8
Accept-Charset: iso-8859-1, utf-8
```

16.2 문자집합

HTTP 캐릭터셋 (Charset)
- 엔터티 콘텐츠의 비트를 특정 문자체계 글자로 변환하는 알고리즘 명명
- 캐릭터셋 태그는 등록된 MIME 문자집합에 표준화되어 있음
- IANA에서 관리 (참조: IANA Charster Sets)
- 문자체계에 따라 글자 당 비트 수 다를 수 있음
  - ex) 중국어, 일본어 등 글자 많은 문자체계
Content-Type 헤더
- 수신자에게 콘텐츠의 파일형식 안내
- 수신자에게 콘텐츠 비트를 글자로 매핑할 디코딩 기법 안내
- ex)
```
Content-Type: text-html; chrset=iso-8859-6
```
문자집합
- 번호가 매겨진 특정 문자의 집합
  - 디코딩 시 해당 문자코드의 번호로 매핑
  - charset 잘못 설정 시 다른 문자집합의 글자로 매핑됨
- HTTP 문자집합(=MIME charset 태그)은 문자 인코딩 구조와 코딩된 문자집합을 결합한 것
- 동작 과정
  - 데이터 비트를 인코딩 구조(charset) 사용해 디코딩
  - 코딩된 문자집합 사용해 문자코드에 매핑된 글자 검색
  - 검색된 글자를 폰트/형식 소프트웨어 이용해 표현
  국제화 문자 시스템의 핵심 목표는 표현(=화면출력)과 의미(=글자)를 분리하는 것
Charset 추측
- 문자집합 명시적으로 나열되지 않은 경우 수신자는 문서의 콘텐츠에서 문자집합을 추측
- HTML 콘텐츠는 meta 태그에서 문자집합을 서술
  - ex)
    <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta lang="en"> </head> ...
- HTML 콘텐츠 아니거나 meta 태그 없는 경우 텍스트 스캐닝해 문자 인코딩을 추측
- 추측 실패 시 iso-8859-1 (서유럽 언어 지원하는 ASCII의 8비트 확장)로 가정

16.3 다중언어 문자 인코딩

전자 문자체계 용어

명칭	상세
문자	- 알파벳 글자, 숫자, 구두점, 표의문자, 기호 등 글쓰기의 최소 단위 - 글꼴/스타일에 독립적 - Unicode라고 불리는 국제문자세트(UCS) 계획에 따라 여러 언어/글자에 유일한 이름 부여하는 표준화된 이름집합 개발되어 옴
글리프(glyph)	- 하나의 글자를 표한하기 위한 획 패턴이나 유일한 시각적 형태 - 글자 당 복수의 글리프 존재하기도 ex) 단어 상 위치나 연자(ligatures) 따라 모양 다른 경우
코딩된 문자 (coded character)	각 글자에 할당된 유일한 숫자
코드 공간	문자코드 값으로 사용하기 위해 계획된 정수의 범위
코드 너비	각 문자 코드의 비트 개수
사용 가능한 문자집합 (character repertoire)	글자들에 대한 특정한 작업집합 (세상 모든 글자의 부분집합)
코딩된 문자집합 (coded character set)	각 글자에 코드공간의 코드 할당하는 코딩된 문자들의 집합 = 실제 글자에 숫자로 된 문자코드 대응시킨 것
문자 인코딩 구조	- 숫자로 된 문자코드를 콘텐츠 비트의 연속으로 인코딩/디코딩 하는 알고리즘 - 데이터압축/전송제약 회피에 사용 가능 - 중복되는 코딩된 문자집합 통합에 사용 가능

단어 상의 위치: 단독 사용, 단어의 처음/중간/마지막에 위치
연자(ligatures): 인접글자와 부드럽게 이어지기 위한 필기/활자체 표현 형태

주요 코딩된 문자집합

: RFC2277, RFC2130에서 정의되는 코딩된 문자집합은 정수를 글자로 매핑한다
=> 보통 코드 번호로 인덱싱된 배열로 구현
=> 다차원 배열의 경우 코드 번호 이루는 비트의 덩어리가 각각의 축에 대한 색인임

US-ASCII
- 모든 문자집합의 어머니
- 1968년 ANSI 표준 X3.4 ‘정보교환을 위한 미국 표준 코드’로 표준화된 가장 유명한 코딩된 문자집합
- HTTP 메세지는 US-ASCII 사용함 (헤더/URI 등)
- 값 범위: 0-127 (총 7비트)

iso-8859

국제적 글쓰기 지원 위해 필요 글자를 하이 비트로 추가한 US-ASCII의 8비트 확대집합

추가 비트는 모든 유럽글자 담기에 부족 => 지역에 따라 커스텀된 문자집합 제공

명칭	상세
iso-8859-1	서유럽어 (영어, 프랑스어 등) `Latin1`로도 불림
iso-8859-2	중앙 및 동유럽어 (체코어, 폴란드어 등)
iso-8859-3	남유럽어
iso-8859-4	북유럽어
iso-8859-5	키릴 (러이아어, 세르비아어 등)
iso-8859-6	아랍어
iso-8859-7	그리스어
iso-8859-8	히브리어
iso-8859-9	터키어
iso-8859-10	노르딕어 (아이슬랜드어, 이뉴잇어 등)
iso-8859-15	새 유로통화 기호 포함하는 `iso-8859-1`의 변형 (`iso-8859-1`에 비해 잘 쓰이지 않음)

JIS X 0201
- 아스키에 일본어 가타가나 반각문자 더해 확장한 작은 문자집합
- JIS Roman으로 불림 (JIS: Japanese Industrial Standard)
- 63개의 표음 가타가나 문자 사용
JIS X 0208
- 최초의 멀티바이트 일본어 문자집합
- 일본식 한자 포함된 6879개 문자 정의
JIS X 0212
- 6607개의 문자를 추가
Shift_JIS
- 원래 MS에서 개발
- SJIS, MS Kanji 라고 부름
- 역사적인 호환성 문제 있으며 모든 문자 대응하지 않으나 널리 사용됨
UCS (Universal Character Set)
- 국제문자세트(UCS)는 전 세계의 모든 글자를 하나의 코딩된 문자집합으로 통합하려는 세계적인 표준
- ISO 10646으로 정의 됨
- 유니코드는 UCS 표준을 따르는 상업적인 컨소시엄
- 기본집합은 50000 글자로 이루어져 있으나 수백만 개의 글자 위한 코드 공간 갖춤

문자 인코딩 구조

: 숫자로 된 문자코드를 콘텐츠 비트로 변환/환원하는 알고리즘

종류

명칭	상세
고정폭	각 코딩된 문자를 고정된 길이의 비트로 표현 처리속도 빠르나 공간낭비 발생
가변폭(비모달)	각 문자코드번호에 다른 길이의 비트를 사용 자주 사용되는 글자 비트길이 축소 가능 국제문자에 대해 여러 바이트 사용 => 종전의 8비트 문자집합과 호환성 유지 가능
가변폭(모달)	다른 모드로 전환하기 위한 escape 패턴 사용 => 중첩된 여러 문자집합 간의 전환 위해 사용 가능 => 복잡한 표기체계 효과적 지원 가능

대표적 인코딩 구조

8비트 고정폭 아이덴티티 인코딩
- 각 문자코드를 그에 대응되는 8비트 값으로 인코딩
- 256개 문자의 코드 범위에 대한 문자집합만 지원
UTF-8
- UTF는 UCS를 위해 설계됨 (UTF: UCS Transformation Format)
- 문자코드 값을 위해 비모달 가변길이 인코딩을 사용
- 첫 바이트의 선두 비트들은 인코딩된 문자의 길이를 바이트 단위로 표현
- 나머지 바이트들은 각각 6비트의 코드 값을 저장
- 첫 번째 인코딩된 바이트의 하이비트가 0이면 길이는 단 1바이트
  => 남은 7비트에 문자코드를 저장하므로 ASCII와 호환됨 (iso-8859는 호환불가)

iso-2022-jp

일본어 인터넷 문서에 널리 사용됨
128보다 작은 값(33-126)으로만 이루어진 가변길이 모달 인코딩
=> 8비트 문자 지원하지 않는 S/W와의 문제점 방지

인코딩 콘텍스트는 4가지의 선정의된 문자집합 중 하나로 설정
=> US-ASCII, JIS X 0201-1976 등
=> 처음에는 US-ASCII 문자집합 사용하며 이스케이프 문자열 사용해 전환 가능

이스케이프 문자열	문자집합	코드당 바이트 수
ESC(B	US-ASCII	1
ESC(J	JIS X 0201-1976	1
ESC $ @	JIS X 0208-1978	2
ESC $ B	JIS X 0208-1983	2

euc-jp

인기 있는 일본어 인코딩
여러 표준 일본어 문자집합 사용하게 하는 가변길이 인코딩
유닉스 운영체제에서 아시아 문자들 지원하기 위해 개발 (EUC: Extended Unix Code)
iso-2020-jp와 달리 비모달 (이스케이프 문자 없음)
공간 다소 낭비되나 처리가 단순

4가지 코딩된 문자집합 지원

바이트	인코딩 값
JISX 0201 첫 번째 바이트	33-126
반각 가타가나 첫 번째 바이트 두 번째 바이트	161-254 161-254
JISX 0208 첫 번째 바이트 두 번째 바이트	142 161-223
JISX 0212 첫 번째 바이트 두 번째 바이트 세 번째 바이트	143 161-254 161-254

euc-kr

널리 사용되는 한글 가변길이 인코딩
2가지 문자집합 지원
KS X 1003
- 1바이트 인코딩
- US-ASCII에서 역슬래시를 원화기호로 치환만 한 문자집합 (부호화 문자 94개)

KS X 1001

2바이트 인코딩
한글/한자/특수문자로 이루어진 한국어 문자집합 (부호화 문자 8836개)
채움문자(fill code) 이용해 한글 표현 (ex 꿈 = 채움문자 + ㄲ + ㅜ + ㅁ )

바이트	인코딩 값
KS X 1003 첫 번째 바이트	0-127
KS X 1001 첫 번째 바이트 두 번째 바이트	161-254 161-254

16.4 언어 태그

특성
- 짧고 표준화된 언어 이름 문자열
- RFC3066으로 문법 표준화
- 일반 언어, 특정 국가어, 방언, 지방어, 그 외 표준/비표준어 표현 가능
- 대소문자 비구별
  - 관용적으로 언어-소문자, 국가-대문자 사용 (ISO 3166 권고사항)
Content-Language 헤더
- 엔터티가 어떤 언어 사용자 대상으로 하는지 서술
- 미디어 종류에 상관없이 헤더 기술 가능
- ex) Content-Language: en, ko
Accept-Language 헤더
- 서버에 언어 제약/선호도 전달 => 자원의 선호 언어로 된 버전 제공 가능
- ex) Accept-Language: en

서브태그

첫 번째 서브태그

표준화된 값 (IANA가 RFC3066 표준 따라 관리)
2글자: ISO 639, ISO 639-1 표준의 언어코드
3글자: ISO 639-2 표준과 확장에 열거된 언어코드
i: IANA에 등록된 언어태그
x: 특정 개인/집단 전용의 비표준 확장 서브태그

구성: a-z

언어	ISO 639	ISO 639-2
중국어	zh	chi/zho
영어	en	eng
프랑스어	fr	fra/fre
독일어	de	deu/ger
일본어	ja	jpn
한국어	ko	kor
러시아어	ru	rus
스페인어	es	esl/spa

두 번째 서브태그

선택적인 값
자신만의 이름 표준 따름 (IANA가 RFC3066 표준 따라 관리)
보통 ISO 3166의 국가코드와 지역표준집합에서 선택된 표준 국가토큰
1글자: 뭔가 잘못됨
2글자: ISO 3166에 정의된 국가/지역
3~8글자: IANA에 등록된 것

구성: a-z, 0-9 (최대 8자)

국가	코드
바티칸시국	VA
중국	CN
미국	US
영국	GB
독일	DE
일본	JP
러시아	RU
홍콩	HK

금지된 국가코드: AA, QM-QZ, XA-XZ, ZZ (ISO 3166에서 사용자 할당코드로 예약됨)

나머지 서브태그
- 세 번째 서브태그부터 미등록
- 구성: a-z, 0-9 (최대 8자)

16.5 국제화된 URI

: 기존에는 US-ASCII 부분집합으로 구성되었으나 RFC 3986에서 URI에 UTF-8 사용하는 법 제시

국제적 가독성 vs 의미 있는 문자
- 제한된 공통 문자집합 사용하므로 세계 대부분의 S/W와 키보드가 지원
- 비영어권 사용자들의 인식률/기억률 낮지만
- => 리소스 식별자의 가독성/공유가능성 보장에 더 중시

URI 문자 분류

문자분류	사용 가능 문자집합
미예약	`A-Za-z0-9`, `-` , `_` , `.` , `!` , `~` , `*` , `'` , `(` , `)`
예약됨	`;`, `/`, `?`, `:`, `@`, `&`, `=`, `+`, `$`, `,`
이스케이프	`% <HEX> <HEX>`

URI 이스케이프 (<-> 언이스케이프)
- 예약문자나 기타 미지원 글자를 안전하게 URI에 삽입할 수 있는 방법 제공
- 형태: 3글자
  - 문자열퍼센트문자(%) + US-ASCII 문자코드 나타내는 16진수 글자 2개
  - ex) + -> %2B, = -> %3D, / -> %2F
- 주의
  - 두 번 언이스케이프 시 데이터 손실 유발
  - 이스케이프 값들은 US-ASCII 코드 범위에 있어야(0-127) 오류 방지 가능
모달 체인징
- 몇몇 URI는 다른 문자집합 글자 표현하기 위해 ASCII 문자열을 사용
- 오늘날에는 ASCII 범위 밖 문자를 인코딩하는 일도 흔함

16.6 기타 고려사항

헤더/명세에 안 맞는 데이터
- HTTP 헤더는 반드시 US-ASCII 문자집합의 글자로만 이루어져야
- 많은 HTTP 어플리케이션이 글자 처리에 OS와 라이브러리 루틴 사용하며 ASCII 미지원 하기도 => 오류 발생 가능
날짜
- HTTP 명세는 올바른 GMT 날짜 형식 정의하지만 모든 서버/클라이언트가 규칙 따르지는 않음
  => 명세에 안 맞는 날짜도 관대히 수용하고 충돌 방지해야
  => 날짜 파싱 불가능한 경우 서버는 보수적으로 다뤄야
국제화 도메인 이름(Internationalizing Domain Name)
- 국제화 문자 포함된 도메인 이름
- 대부분의 웹브라우저가 퓨니코드(punycode) 이용해 국제화 도메인 이름을 지원
  - 퓨니코드: 유니코드 문자열을 호스트 명에서 사용 가능한 문자열로 변환하는 방법 (RFC 3492에 정의)
  - ex) 한글.com -> xn--bj0bj06e.com

17장 내용 협상과 트랜스코딩

17.1 내용 협상 기법 (Content-negotiation)

내용 협상 기법 (Content-negotiation)
- 하나의 URL이 여러 리소스에 대응할 필요가 있는 경우 (예: 다국어 리소스 등)
- 클라이언트-서버가 적합한 것 판단하도록 HTTP가 제공하는 협상방법
배리언트 (variant)

특정 리소스의 서로 다른 버전

종류

협상기법	상세	장점	단점
클라이언트 주도	클라이언트가 요청 시 서버가 선택지 제시	- 서버 구현 용이 - 클라이언트가 최선의 선택 가능	대기 시간 증가 (최소 2번 요청 필요)
서버 주도	- 서버가 요청 헤더 검증해 제공 버전 선택 - 클라이언트는 선호도(q값) 제공 - 서버는 `Vary` 헤더로 검증 헤더 안내	클라이언트 주도보다 빠름	헤더에 맞는 것 없으면 서버가 추측해야
투명	투명한 중간장치가 서버 대신 협상 (주로 프록시 캐시)	- 서버의 협상부담 절감 -클라이언트 주도보다 빠름	정형화된 명세 부재

17.2 클라이언트 주도 협상

2회의 서버 응답 1) 선택 목록 제공
- 여러 버전에 대한 링크 & 설명 담긴 HTML 페이지 제공하거나
- 300(Multiple Choices) 응답 제공 가능(HTTP/1.1) 2) 선택한 사본 제공
여러 URL 필요
- 주 URL과 조건별 하부 URL 필요
- URL 공유/저장 시 불명확함 초래

17.3 서버 주도 협상

내용 협상 헤더

HTTP는 stateless하므로 매 요청마다 헤더로 안내 해야 (선호도 저장X)
선호도 q값: 0.0 ~ 1.0

종류

명칭	상세	대응 엔터티 헤더
Accept	수신 가능한 미디어타입 안내	Content-Type
Accept-Language	수신 가능한 언어 안내	Content-Language
Accept-Charset	수신 가능한 차셋 안내	Content-Type
Accept-Encoding	수신 가능한 인코딩 안내	Content-Encoding

내용 협상 헤더는 수신 가능한 리소스 버전을 안내하고 엔터티 헤더는 콘텐츠의 속성을 안내

ex)

Accept-Language: en;q=0.7, fr;q=0.0, ko;q=1.0

추가 헤더
- User-Agent 헤더
  
  클라이언트의 호화성에 따라 페이지 제공 가능 (예: 스크립트 제거 버전 등)
- Vary 헤더
  
  캐시나 다운스트림 장치에게 버전 결정에 어떤 요청헤더 참고하는지를 안내
서버 측 확장
- MS의 ASP의 경우 내용협상 기능을 서버가 확장
- 참조: MS 공식문서

아파치 서버의 내용협상

개괄
- 색인 페이지를 여러 버전으로 제공하려는 경우
- 우선 각 버전의 파일을 적절한 디렉토리에 모두 저장하고
- type-map 파일이나 MultiViews 지시어 사용해 내용협상 설정 가능

type-map 파일 사용

서버 설정 파일에 type-map 파일 접미사를 명시한 핸들러를 추가
ex) AddHandler type-map .var
type-map 파일을 추가

ex)

URI: main.html
  
URI: main.en.html
Content-Type: text/html
Content-Language: en
    
URI: main.ko.jp.html
Content-Type: text/html;charset=utf-8
Content-Language: ko, jp

ex)

URI: foo
    
URI: foo.jpeg
Content-type: image/jpeg; qs=0.8
    
URI: foo.gif
Content-type: image/gif; qs=0.5
    
URI: foo.txt
Content-type: text/plain; qs=0.01  

MultiViews 지시어 사용
- access.conf 파일의 적절한 절에 Options 지시어 사용해 해당 디렉터리의 MultiViews를 켜야
- MultiViews가 설정된 경우 요청된 리소스 명에 따라 서버가 type-map 파일을 자동으로 생성
- 서버는 이름에 근거해 적절한 협상 헤더를 추측
- ex) index 요청 시 => index.en.html 등 검색해 제공
참조
- 아파치 공식문서

17.4 투명 협상 (transparent negotiation)

: 클라이언트 입장에서 협상하는 중개자 프록시를 이용해 협상

특성
- 클라이언트와의 메세지 교환 최소화
- 서버 주도 협상의 부하 절감
- 캐시 내부에 설치된 범용 트랜스코더로 트랜스코딩 가능
- 캐시는 올바른 배리언트(=alternate) 반환 위해 내용협상 헤더 사용
Vary 헤더
- Vary 응답헤더는 서버가 문서선택/커스텀 콘텐츠 생성에 고려한 요청 헤더를 나열
- 캐시는 반드시 내용협상 헤더와 서버가 고려하는 요청 헤더를 모두 확인해야
- ex) Vary: User-Agent, Cookie
  => User-Agent와 Cookie 값 따라 배리어트 생성됨

17.5 트랜스코딩

: 클라이언트에게 맞춰 커스터마이징 된 페이지를 서버가 자동으로 생성

종류
- 포맷변환
  - 데이터를 클라이언트가 볼 수 있는 포맷으로 변환 => 효율적/안전한 전송
  - ex) 고해상도->저해상도, 칼라->흑백
- 정보합성 (info synthesis)
  - 문서에서 정보의 요점 추출
  - ex) 개요 생성, 광고/로고 제거, 웹페이지 자동분류
- 콘텐츠 주입 (Content-Injection)
  - 페이지에 동적으로 콘텐츠를 추가
  - ex)사용자 대상 광고, 사용자 추적/통계 시스템
대안
- 정적 사본 미리 생성
  - 페이지 수정 시 모든 사본 수정 필요 => 저장/관리 비용 증대
  - 타깃 광고 삽입 어려워짐
- 루트 페이지를 필요에 따라 변환
  - 대기시간 증가 등 비용 초래
  - 계산/변환을 프록시나 캐시의 외부 에이전트에 넘길 경우 서버 부담 감소

17.6 다음 단계

HTTP 내용협상은 성능 제약을 초래
- variant 탐색 및 추측 비용 간소화 위해 RFC2295 RFC2296 등을 논의
콘텐츠 협상 작업 그룹
- HTTP는 내용협상이 필요한 유일한 프로토콜 아님 (예: 미디어 스트리밍과 팩스 등)
- 일반적인 내용협상 프로토콜을 TCP/IP에서 구현하기 위해 논의 (현재는 그룹 닫힘)

Twitter Facebook LinkedIn

Sooyeun Kim