21장 로깅과 사용 추적

로깅을 알아보고, 어떤 HTTP 트랜잭션 정보를 기록하고, 로그 포맷에는 어떤것들이 있는지 알아본다.

1. 로그란 무엇인가?

• 대체적으로 로깅을 하는 이유?
  • 서버나 프락시의 문제를 찾기 위해서
  • 웹 사이트 접근 통계를 내기위해서
• 별 연관성이 없고 다시 볼 일도 없는 데이터만 로깅한다.
• 보통은 트랜잭션의 기본적인 항목들만 로깅한다.
  • HTTP 메서드
  • 클라이언트와 서버의 HTTP 버전
  • 요청받은 리소스의 URL
  • 응답의 HTTP 상태 코드
  • 요청과 응답 메시지의 크기
  • 트랜잭션이 일어난 시간
  • Referer와 User-Agent 헤더 값

2. 로그 포맷

• 상용 혹은 오픈 소스 HTTP 애플리케이션은 대부분, 표준 로그 포맷을 한 개 이상 지원한다.
• 애플리케이션이 더 많은 표준 포맷을 지원하고 관리자가 사용할 수록 얻을 수 있는 이점이 많다.

2.1 일반 로그 포맷(Common Log Format)

• 가장 일반적인 포맷이며, 많은 서버들이 기본으로 사용한다.

일반 로그 포맷 엔트리의 몇가지 예

209.1.32.44 - - [03/Feb/2020:14:15:00 -0400] "GET / HTTP/1.0" 200 1024
bebiangel.github.io - dg [03/Feb/2020:14:15:00 -0400] "GET / HTTP/1.0" 200 477
bebiangel.github.io - dg [03/Feb/2020:14:15:00 -0400] "GET /foo HTTP/1.0" 404 0

3. 적중 계량하기

• 캐시는 수많은 HTTP요청을 처리하므로, 요청이 원 서버 까지 오지 않더라도 정상적으로 처리될 수 있어서, 클라이언트가 콘텐츠에 접근했다는 기록이 남지 않아 로그 파일에 누락이 발생하게 된다.
• 캐시를 파기 시킨다면, 문제 없이 로깅을 하지만, 요청에 대한 응답속도가 느려지고 원서버와 네트워크의 부하가 가중되는 문제를 야기한다.
• 적중 계량 규약은 HTTP의 확장으로, 캐시가 정기적으로 캐시 접근 통계를 원 서버에 보고하도록 한다.
• 완벽하진 않지만, 서버가 원하는 통계 정보를 받아볼 수 있는 방법을 제공한다.

20장 리다이렉션과 부하 균형

리다이렉션 기법들과 그것들이 어떻게 동작하며 어떤 부하 균형 능력을 갖고 있는지 알아본다

1. 왜 리다이렉트인가?

HTTP 애플리케이션이 원하는것

• 신뢰할 수 있는 HTTP 트랜잭션의 수행
• 지연 최소화
• 네트워크 대역폭 절약

리다이렉션

• 최적의분산된 콘텐츠를 찾는 것을 도와주는 기법의 집합

2. 리다이렉트 할 곳

• 서버, 프락시, 캐시, 게이트웨이는 클라이언트에게 있어서 HTTP 요청을 보내고 그것을 처리하므로 서버라고 할 수 있다.
• 서버로의 리다이렉트는 휘발유를 찾는 운전 기사를 가장 가까운 주유소로 보내는 것이다.
• 프락시로의 리다이렉트는 진입로의 트래픽을 근처에 있는 지름길로 빨아들이는 것과 같다.

3. 리다이렉션 프로토콜의 개요

• HTTP 메시지를 웹 서버로 가급적 빨리 보내는 것이 리다이렉션의 목표다.
• HTTP 메시지는 HTTP 애플리케이션과 라우팅 장치에 영향을 받는다.
• 메시지를 서버로 리다이렉트하기 위한 여러 방법들이 존재한다.

4. 일반적인 리다이렉션 방법

4.1 HTTP 리다이렉션

• 요청을 처리하는 서버는 가용한 것들 중 부하가 가장 적은 콘텐츠 서버를 찾아서 브라우저의 요청을 그 서버로 리다이렉트 한다.
• 리다이렉트를 하느 서버가 클라이언트의 아이피 주소를 아는 것은 좀 더 정보에 근거해 선택하므로 장점이다.

단점

• 어떤 서버로 리다이렉트할지 경정하려면 원 서버는 상당히 많은 처리를 해야 한다.
• 페이지에 접근할 때마다 두 번의 왕복이 필요하므로 사용자가 더 오래 기다리게 된다.
• 리다이렉트 서버가 고장나면, 사이트도 고장난다.

4.2 DNS 리다이렉션

• 클라이언트가 웹사이트에 접근하려고 시도할 때마다, 도메인 이름은 반드시 아이피 주소로 분석되어야 한다.
• DNS는 하나의 도메인에 여러 아이피 주소가 결부되는 것을 허용한다.
• DNS 분석자는 여러 아이피 주소를 반환하도록 결정하는 방법은 다양하다.
• DNS 결정 알고리즘은 라운드 로빈이 가장 쉽다.

DNS 라운드 로빈

• 웹 서버 팜 전체에 대한 부하의 균형을 유지하기 위해 DNS 호스트명 분석 기능을 사용한다.
• DNS 클라이언트는 다중 주소 집합의 첫 번째 주소를 사용한다.
• DNS 서버는 룩업이 끝났을 때마다 주소를 순환시킨다.

DNS 캐싱의 효과

• DNS 룩업은 애플리케이션, 운영체제 등 DNS 서버에 의해 재사용 되어 비용을 줄이게 된다.
• 클라이언트의 수가 어느정도 이상만 된다면, 부하는 모든 서버에 잘 분산된다.

4.3 임의 캐스팅 어드레싱

• 여러개의 흩어진 웹 서버들은 정확히 같은 아이피 주소를 갖고 클라이언트의 요청을 클라이언트에서 가장 가까운 서버로 보내주기 위해 백본 라우터의 최단거리 라우팅 능력에 의지한다.
• 백본 라우터가 임의 캐스트 주소를 목적지로 하는 패킷을 받았을때, 그 아이피 주소를 받아들일 수 잇는 가장 가까운 라우터를 찾는다.
• 서버는 반드시 라우터의 언어로 말해야하고 라우터는 일어날 수 있 는 주소 충돌을 반드시 다룰수 있어야 한다.

4.4 아이피 맥 포워딩

• HTTP 메시지는 주소가 붙은 데이터 패킷의 형태로 보내진다.
• 각 패킷은 출발지와 목적지의 아이피 주소와 TCP 포트 번호로 이루어진 레이어4 주소를 갖는다.
• 레이어2의 역할은 들어오는 특정 맥(MAC) 주소의 패킷을 받아서 나가는 특정 맥 주소로 포워딩한다.

4.5 아이피 주소 포워딩

• 스위치나 레이어4를 이해하는 장비는 들어오는 패킷에 대해 TCP/IP 어드레싱을 검증하고 패킷을 목적지 맥 주소가 아니라 목적지 아이피 주소의 변경에 따라 라우팅한다.
• 목적지 서버가 한 홉 거리에 있을 필요가 없다.
• 스위치는 반드시 그 커넥션을 통해 클라이언트에게 응답을 돌려줘야 한다.

5. 프락시 리다이렉션 방법

5.1 명시적 브라우저 설정

• 대부분의 브라우저에는 프락시 서버에 접촉하기 위한 프락시 이름, 아이피 주소, 포트번호를 설정하는 메뉴가 존재한다.
• 사용자의 설정에 따라 모든 요청에 대해 프락시와 접촉한다.

단점

• 만약 프락시가 다운되었거나 브라우저가 잘못 설정되었다면, 사용자는 접속 문제에 마주하게 된다.
• 네트워크 아키텍처를 변경했을 때 그 변경사항을 모든 최종사용자에게 전파하는것이 어렵다.

5.2 프락시 자동 설정(Proxy Auto-configuration, PAC)

• 브라우저가 동적으로 자신을 설정할 수 있게 하는 것이다.

• PAC는 브라우저들이 URL별로 접촉해야 할 프락시를 지정한 PAC 파일이라 불리는 특별한 파일을 찾도록 하는것이다.

• 브라우저는 반드시 PAC파일을 얻기 위해 지정된 서버에 접촉하도록 설정되어 있다.

• 브라우저는 재시작 할 때마다 PAC 파일을 가져온다.

• PAC 파일은 다음의 함수를 반드시 정의해야하는 자바스크립트 파일이다.

  function FindProxyForURL(url, host)

5.3 웹 프락시 자동발견 프로토콜(Web Proxy Autodiscovery Protocol)

• 웹브라우저가 근처의 프락시를 찾아내어 사용할 수 있게 해주는 방법을 제공해 준다.

6. 캐시 리다이렉션 방법

• 신뢰성이 높고, 고성능, 콘텐츠 지각 디스패칭이 가능하게 하여 복잡한 방법이다.

6.1 WCCP 리다이렉션

• 캐시 조직 프로토콜(WCCP)는 라우터들과 캐시들 사이의 대화를 관리하여 라우터가 캐시를 검사하고, 특정 종류의 트래픽을 특정 캐시로 보낼 수 있게 해준다.
• WCCP 서비스 그룹을 구성하고, 어떤 트래픽이 어디로 어떻게 보내지는지, 서비스 그룹에서 부하가 캐시들 사이에서 어떻게 분산되어야 하는지 명시한다.
• HTTP 요청이 서비스 그룹의 라우터에 도착한다면, 라우터는 그 요청을 처리하기 위해 서비스 그룹의 캐시 중 하나를 선택한다.

7. 캐시 배열 라우팅 프로토콜

• 부하를 분산하기 위해 사용하는 프락시 서버를 여러대로 늘리는 것이다.
• CARP는 프락시 서버의 배열이 클라이언트의 시점에서는 마치 하나의 논리적인 캐시처럼 보이도록 관리해주는 표준이다.
• 각 구성요소 서버가 전체 캐시된 문서의 일부만 갖고 있는 하나의 큰 서버처럼 동작한다.
• 하나의 웹 객체는 하나의 프락시 서버에만 속하기 때문에, 프락시 서버 각각을 폴링하지 않고도 한 번의 검색으로 그 객체의 위치를 결정할 수 있다.

8. 하이퍼텍스트 캐싱 프로토콜

• HTCP는 형제들이 URL과 모든 요청 및 응답 헤더를 사용하여 서로에게 문서의 존재 여부에 대한 질의를 할수 있도록 해줌으로써 적중이 아님에도 적중으로 잘못 처리될 확률을 줄인다.
• 캐시들이 서로의 캐시 안에 있는 선택된 문서의 추가 및 삭제를 모니터링하고 요청할 수 있게 해준다.
• 근처 캐시가 문서를 갖고 있다면, 요청 캐시는 그 캐시에 HTTP 커넥션은 열고 그 문서를 가져 온다.

19장 배포 시스템

1. WebDav

• 웹 분산 저작과 버저닝(Web Distributed Authoring and Versioning)
• 공동 저작에 적합한 플랫폼을 제공하려고 HTTP를 확장하는데 집중한다.

2. WebDav와 공동저작

2.1 WebDav와 XML

• WebDav의 메서드는 요청과 응답 관련 정보를 모두 잘 다루어야함
• WebDav는 여러개의 리소스나 계층 관계에 있는 리소스들에 대해 정보를 선택적으로 헤더에 기술하기 위해서 XML포맷을 지원한다.

2.2 WebDav헤더

• WebDav는 새로운 메서드들의 기능을 넓혀주는 여러 HTTP메서드를 도입했다
• 모든 리소스는 OPTIONS 요청에 대한 응답에 이 헤더를 포함해야한다.
• Depth는 계층 구조로 분류된 리소스 사용에 용이하다.
• Destination은 COPY나 MOVE 메서드가 목적지 URI를 식별하는데 사용한다.

2.3 WebDav 잠금과 덮어쓰기 방지

• WebDav는 잠금이라는 개념을 지원한다
• 잠금은 완벽하지 않으므로 버저닝과 메시징을 지원해야한다
• 잠금을 수행하기 위해서는 다이제스트 인증을 요구한다

2.4 속성과 META 데이터

• 속성에는 저작자의 이름, 수정한 날자, 내용 등급 등 리소스의 정보를 기술한다.
• 속성의 발견과 수정을 지원하기 위해, WebDav는 PROFIND와 PROPPATCH라는 새로운 메소드를 추가한다.

2.5 콜렉션과 이름공간 관리

• 콜렉션은 리소들의 논리적 혹은 물리적 그룹이다.
• 파일시스템의 디렉터리 같이 다른 리소스들의 컨테이너처럼 동작한다.
• WebDav는 XML 이름 공간 메커니즘을 사용한다.
• 이름공간 파티션들은 충돌이 생기지 않고 명확한 구조적 제어기능을 제공한다.

2.6 MKCOL 메서드

• 클라이언트가 지정된 URL에 해당하는 콜렉션을 서버에 생성하게 한다.
• WebDav 프로토콜은 새로운 메서드를 정의하는 방식을 사용한다.

2.7 DELETE 메서드

• 디렉터리를 지우기 위해서는 Depth 헤더를 필요로한다.
• Depth가 없다면, DELETE 메서드는 Depth 헤더가 무한으로 설정되어 있다고 가정한다.
• 디렉터리와 그 하위에 있는 모든 디렉터리가 지워진다.

2.8 COPY와 MOVE 메서드

• COPY 메서드는 리소스에 GET 요청을 보내고, 리소스를 다운 받은 다음, PUT 요청과 함께 서버에 리소스를 다시 올리는 것이다.
• MOVE는 DELETE메소드를 포함한 COPY와 비슷하게 동작한다.
• MOVE 메서드는 원본지 URL을 목적지에 복사하고, 새로 생성된 URI의 무결성을 검사하고, 원본을 지운다.

18장 웹 호스팅

웹 호스팅의 가장 중요한 속성들과 그것들이 어떻게 HTTP 애플리케이션과 상호작용하는지 알아본다.

1. 호스팅 서비스

• 전문적으로 서버실을 짓고 도메인을 등록하고 네트워크 대역폭을 구매하는 기술과 시간을 가진 업체들이 있다.
• 물리적인 장비 관리에서 고객이 직접 콘텐츠를 제공할 수 있는 총체적인 웹 호스팅까지 다양한 종류의 서비스들이 있다.

2. 가상 호스팅

• 웹 호스팅 업자는 컴퓨터 한 대를 여러 고객이 공유하게 해서 저렴한 웹 호스팅 서비스를 제공하는데, 이를 공유 호스팅 또는 가상 호스팅이라 부른다.
• 가상 호스팅은 비용, 공간, 관리에 이점이 있다.
• 호스팅 업자는 복제 서버 더미(서버 팜)를 만들고 서버 팜에 부하를 분산할 수 있다.
• 수많은 가상 웹사이트를 호스팅 하므로 관리자는 훨씬 편해진다.

2.1 호스트 정보가 없는 가상 서버 요청

• HTTP/1.0 명세는 공용 웹 서버가 호스팅하고 있는 가상 웹 사이트에 누가 접근하고 있는지 식별하는 기능을 제공하지 않는다.
• 여러 개의 요청이 완전히 다른 문서를 요청을 하더라도, 요청 자체가 똑같이 생겼다.
• HTTP 대리 서버(리버스 프락시)와 인터셉트 프락시는 어떤 사이트를 요청하는지에 관한 정보가 필요하다.

2.2 가상 호스팅 동작하게 하기

URL 경로를 통한 가상 호스팅

• 서버가 어떤 사이트를 요청하는 것인지 알 수 있게 URL에 특별한 경로 컴포넌트를 추가한다.
  • 경로에 있는 정보를 통해 해당 URL을 분석한다.
  • GET joes/index.html
  • GET mary/index.html
• 일반적으로, URL 기반의 가상 호스팅은 좋지 않은 방법이다.

포트 번호를 통한 가상 호스팅

• 각 사이트에 다른 포트번호를 할당하여, 분리된 웹 서버의 인스턴스 요청 처리를 한다.
• 사용자는 URL에 비표준 포트를 쓰지 않고서도 리소스를 찾길 원하는 문제가 생긴다.

IP 주소를 통한 가상 호스팅

• 각 가상 웹 사이트에 유일한 IP 주소를 한 개 이상 부여한다.

• 모든 가상 서버의 IP 주소는 같은 공용 서버에 연결되어 있다.

  문제점들

  • 컴퓨터 시스템이 연결할 수 있는 장비의 IP의 개수에 제한이 있다.
  • 가상 사이트를 많이 가지고 있는 호스팅 업자는 호스팅 하는 모든 웹 사이트에 할당할 가상 IP 주소를 충분히 얻지 못할 수 있다.
  • 부하 균형의 구조상, 용량을 늘리기 위해 서버를 복제하면서, 각 복제된 서버에 IP 주소를 부여해야 하므로 IP 주소는 복제 서버의 개수만큼 더 필요하게 된다.

Host 헤더를 통한 가상 호스팅

• 모든 요청에 호스트명을 Host 확장 헤더에 기술해서 전달한다.

2.3 HTTP/1.1 Host 헤더

• 가상 서버는 매우 흔하기 때문에 대부분의 HTTP 클라이언트가 HTTP/1.1과 호환되지 않더라도, Host헤더는 구현한다.
• Host = "Host" ":" 호스트[ ":" 포트 ]

3. 안정적인 웹 사이트 만들기

3.1 미러링 된 서버 팜

• 서버 팜은 서로 대신할 수 있고 식별할 수 있게 설정된 웹 서버들의 집합이다.
• 서버팜의 서버에 있는 콘텐츠들은 한 곳에 문제가 생기면 다른 한 곳에서 대신 전달할 수 있게 미러링 할 수 있다.

HTTP 리다이렉션

• 콘텐츠에 대한 URL은 마스터 서버의 IP를 가리키고, 마스터 서버는 요청을 받는 즉시 복제 서버로 리다이렉트시킨다.

DNS 리다이렉션

• 콘텐츠의 URL은 여러 개의 IP 주소를 가리킬 수 있고, DNS 서버는 클라이언트에게 전송할 IP 주소를 선택할 수 있다.

3.2 콘텐츠 분산 네트워크

• 콘텐츠 분산 네트워크(CDN)는 특정 콘텐츠의 분산을 목적으로 하는 단순한 네트워크이다.

3.3 CDN의 대리 캐시

• 대리 서버는 콘텐츠에 대한 요청을 받는다.
• 원 서버 집합을 대신해 요청을 받는다.

미러링 된 서버와의 차이점

• 수요에 따라서 동작한다.
• 원 서버의 전체 콘텐츠를 복사하지 않는다.
• 클라이언트가 요청하는 콘텐츠만 저장한다.

3.4 CDN의 프락시 캐시

• 대리 서버를 사용하면, 프락시 캐시의 콘텐츠는 요청이 있을 때만 저장되고 원본 서버 콘텐츠를 정확히 복제한다는 보장이 없다.
• 요청이 있을 때만 저장하는 프락시 캐시는 스위치 혹은 라우터가 중간에서 웹 트래픽을 가로채 처리한다.

4. 웹 사이트 빠르게 만들기

• 콘텐츠를 분산시키면, 그 콘텐츠를 사용자에게 더 가깝게 만들어 주므로 콘텐츠를 서버에서 클라이언트로 전송하는 시간이 단축된다.
• 콘텐츠를 인코딩하는것

5. WebDav

• 웹 분산 저작과 버저닝(Web Distributed Authoring and Versioning)
• 공동 저작에 적합한 플랫폼을 제공하려고 HTTP를 확장하는데 집중한다.

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

1. 내용 협상 기법

• 서버에 있는 페이지들 중 어떤 것이 클라이언트에게 맞는지 판단하는 세 가지 다른 방법이 있다.
• 클라이언트 주도 협상, 서버 주도 협상, 투명한 협상에 대해서 알아본다.

2. 클라이언트 주도 협상

• 서버에게 가장 쉬운 방법은 서버가 클라이언트의 요청을 받았을 때 가능한 페이지의 목록을 응답을 돌려주어 클라이언트가 보고 싶은 것을 선택하게 하는 것이다.

  단점

  • 각 페이지에 두 번의 요청이 필요하다.(목록 & 사본)
  • 느리고 지루하다.

• 서버는 클라이언트에게 여러가지 버전에 대한 링크와 설명이 담긴 HTML 페이지를 돌려준다.

• 300Multiple Choices 응답 코드로 HTTP/1.1응답을 돌려준다.

  단점

  • 대기시간이 증가되고, 페이지당 여러 번의 요청이 필요하다.

3. 서버 주도 협상

• 클라이언트가 서버가 결정을 하도록 요청 헤더에 정보를 삽입한다.
  • 내용 협상 헤더 → 서버는 클라이언트의 Accept 관련 헤더들을 보고 그에 알맞은 응답을 돌려 준다.
  • 이외의 다른 헤더 → ex) 서버는 클라이언트의 User-Agent헤더에 기반하여 응답을 돌려준다.

3.1 내용 협상 헤더

• HTTP 헤더들을 이용해서 자신의 선호 정보를 보낸다.
  • Accept: 서버가 어떤 미디어 타입으로 보내도 되는지 알려준다.
  • Accept-Language: 서버가 어떤 언어로 보내도 되는지 알려준다.
  • Accept-Charset: 서버가 어떤 차셋으로 보내도 되는지 알려준다.
  • Accept-Encoding: 서버가 어떤 인코딩으로 보내도 되는지 알려준다.
• HTTP는 상태가 없는 프로토콜이기 때문에 클라이언트는 자신의 선호 정보를 매 요청마다 보내야한다.

3.2 내용 협상 헤더의 품질값

• HTTP 프로토콜은 클라이언트가 각 선호의 카테고리마다 여러 선택 가능한 항목을 선호도와 함께 나열할 수 있도록 품질값을 정의하였다.
• q값은 0.0부터 1.0까지의 값을 가진다.(커질수록 높은 선호도)

3.3 그 외의 헤더들에 의해 결정

• 서버는 User-Agent와 같은 헤더들을 이용해 알맞은 요청을 만들어내려고 시도할 수 있다.
• 서버가 웹브라우저에서 자바스크립트를 지원하지 않는다는 것을 알고 있다면, 자바스크립트를 포함하지 않은 페이지를 돌려줄 수 있다.

4. 투명협상

• 클라이언트 입장에서 협상하는 중개자 프락시를 둔다.
• 메시지 교환을 최소화 하며 서버 주도 협상으로 인한 부하를 서버에서 제거한다.

4.1 캐시와 얼터네이트(alternate)

• 캐시는 클라이언트에게 올바르게 응답을 돌려주기 위해, 서버가 응답을 돌려줄 때 사용했던 로직을 상당부분 사용한다.
• 캐시는 반드시 모든 요청을 서버에게 전달하고 모든 응답을 저장해야 한다.
• 캐시는 같은 URL에 대해 두 개의 다른 문서를 갖게 된다.
• 이 다른 번전은 배리언트(variant)나 얼터네이트(alternate)라고 불린다.

4.2 Vary 헤더

• HTTP Vary 응답 헤더는 클라이언트 요청 헤더 모두를 나열한다.
• 캐시가 문서를 클라이언트에게 제공해 주기 전에, 캐시는 반드시 캐시된 응답 안에 서버가 보낸 Vary 헤더가 있는지 확인한다.
• Vary 헤더가 존재한다면, Vary 헤더가 명시하고 있는 헤더들은 새 요청과 오래되고 캐시된 요청의 값이 맞아야 한다.

5. 트랜스코딩

• 서버가 클라이언트의 요구에 맞는 문서를 가지고 있지 않다면, 서버는 기존의 문서를 클라이언트가 사용할 수 있는 무언가로 변환 할 수 있다. 이 옵션을 트랜스코딩이라 한다.

5.1 포맷 변환

• 데이터를 클라이언트가 볼 수 있도록 한 포맷에서 다른 포맷으로 변환하는 것이다.
• 포맷 변환은 내용 협상 헤더에 의해 주도된다.
• 콘텐츠를 특정 접근 장치에서 볼 수 있도록 하는 것이다.

5.2 정보 합성(information synthesis)

• 각 절의 제목에 기반한 문서의 개요 생성이나 페이지에서 광고 및 로고 제거와 같은 예가 있다.
• 웹페이지 디렉토리와 같은 자동화된 웹페이지 분류 시스템에 의해 종종 사용된다.

5.3 콘텐츠 주입

• 자동 광고 생성, 사용자 추적 시스템과 같은 예가 있다.
• 특정 사용자를 대상으로 자동으로 광고를 삽입한다.
• 어떻게 페이지가 보여지고 사용자가 웹을 서핑하는 거에 따라 동적으로 콘텐츠를 삽입한다.

5.4 트랜스코딩 vs 정적으로 미리 생성

• 트랜스코딩의 대안으로는 웹 서버에서 웹페이지의 여러 사본을 만드는 것이다.
  • 페이지의 작은 변화에 따라 페이지의 수정이 필요하다.
  • 모든 버전을 저장하기 위해 더 많은 공간이 필요하다.
  • 페이지를 관리하고 올바른 페이지를 노출 시키도록 웹 서버를 프로그래밍하기 어려워진다.
• 광고 삽입과 같은 트랜스코딩은 요청한 사용자에게 달려있기 때문에 정적인 방법으로는 수행될 수 없다.
• 루트 페이지를 필요할 때마다 변환하는 것이 좋다.

16장 국제화

주요 국제화 이슈인 문자집합 인코딩과 언어 태그를 알아본다.

1. 국제적인 콘텐츠을 다루기 위해 필요한 HTTP 지원

• HTTP에서 엔터티 본문이란 비트들로 가득 찬 상자에 불과하다.
• 국제 콘텐츠를 지원하기 위해, 서버는 클라이언트에게 각 문서의 문자와 언어를 알려줘서, 클라이언트가 문서를 이루고 있는 비트들을 올바르게 문자들로 풀어내고, 처리해서 사용자들에게 제공한다.
• 서버는 클라이언트에게 문서의 문자와 언어를 HTTP Content-Type charset 매개변수와 Content-Language 헤더를 통해 알려준다.
• 클라이언트는 서버에게 자신이 어떤 차셋 인코딩 알고리즘들과 언어들을 이해하며 무엇을 선호하는지 말해주기 위해 Accept-Charset과 Accept-Language 헤더를 보낸다.

2. 문자집합과 HTTP

2.1 Charset은 글자를 비트로 변환하는 인코딩이다

• HTTP Charset 값은 어떻게 엔터티 콘텐츠 비트들을 특정 문자 체계의 글자들로 바꾸는지 말해준다.
• Content-Type: text/html; charset=iso-8859-6
  • Content-Type 헤더는 수신자에게 콘텐츠가 HTML 파일임을 말해준다.
  • charset 매개변수는 수신자에게 콘텐츠 비트들을 글자들로 디코딩하기 위해 iso-8859-6 아랍 문자집합 디코딩 기법을 사용하라고 말해준다.

3. 언어 태그와 HTTP

• 언어 태그는 언어에 이름을 붙이기 위한 짧고 표준화된 문자열이다.

3.1 Content-Language 헤더

• 엔터티가 어떤 언어 사용자를 대상으로 하고 있는지 서술한다.
• 텍스트 문서 이외의 오디오 클립, 동영상, 애플리케이션도 특정 언어 사용자를 대상으로 할 수 있다.
• 콘텐츠가 여러 언어를 대상으로 한다면, 언어들을 나열할 수 있다.
  • Content-Language: mi, en

3.2 Accept-Language 헤더

• 웹 서버가 자원에 대해 여러 언어로 된 버전을 갖고 있다면, 사용자에게 선호하는 언어로 된 컨텐츠를 제공한다.
• 클라이언트는 자신이 이해 할 수 있는 콘텐츠를 요청하기 위해 Accept-Language와 Accept-Charset을 사용한다.

3.3 대소문자 구분 및 표현

• 모든 태그는 대소문자가 구분되지 않는다.
• 관용적으로 언어를 나타날때 소문자, 국가를 나타낼 때는 대문자를 사용한다.

4. 국제화된 URI

• 오늘날 URI는 국제화를 지원하지 않는다.
• 오늘날의 URI는 US-ASCII의 부분집합으로 구성되어 있다.

4.1 국제적 가독성 vs 의미 있는 문자들

• 문자집합에는 제한이 있기 때문에, URI는 비영어권 사람들도 쉽게 사용하고 기억할 수 있도록 설계되지는 못했다.
• URI 저자들은 리소스 식별자의 가독성과 고유 가능성의 보장이 중요하다고 여겼다.
• ASCII 문자들의 제한된 집합으로 이루어진 URI를 갖게 되었다.

4.2 URI에서 사용될 수 있는 문자들

• US-ASCII 문자들의 부분집합은 예약된 문자들, 예약되지 않은 문자들, 이스케이프 문자들로 나뉜다.
• 예약되지 않음: [A-Za-z0-9] |”-“|”_”|”.”|”!”|”~”|”*”|”‘“|”(“|”)”
• 예약됨: “;”|”/“|”?”|”:”|”@”|”&”|”=”|”+”|”$”|”,”
• 이스케이프: “%”

4.3 이스케이핑과 역이스케이핑(unescaping)

• 이스케이프는 예약된 문자난 다른 지원하지 않는 글자들을 안전하게 URI에 삽입할 수 있는 방법을 제공한다.
• 이스케이프는 퍼센트 글자 하나와 뒤이은 16진수 그자 둘로 이루어진 세 글자 문자열이다.
• 애플리케이션은 어떤 URI도 두 번 언이스케이핑 되지 않도록 해야 한다.
  • 이스케이핑된 퍼센트 기호를 포함한 URI를 언이스케이핑하면 퍼센트 기호가 포함된 URI가 만들어진다.
  • 잘못하여 한 번 더 언이스케이핑을 하게 되면 이스케이프의 일부처럼 처리되어 데이터의 손실을 유발한다.

5. 기타 고려사항

5.1 헤더와 명세에 맞이 않는 데이터

• HTTP 헤더는 반드시 US-ASCII 문자집합의 글자들로만 이루어져야 한다.
• HTTP 애플리케이션은 글자들을 처리하기 위해 운영체제와 리아브러리 루틴을 사용한다.

5.2 날짜

• HTTP 명세는 올바른 GMT 날짜를 명확히 정의하지만, 모든 웹 서버와 클라이언트가 규칙을 따르지 않는다.
• 명세에 맞지 않는 날짜를 관대하게 받아들이고, 받아들이면서 충돌을 일으키지 말아야한다.

5.3 도메인 이름

• 국제화 문자를 포함하는 도메인 이름을 국제화 도메인 이름(Internationalizing Domain Name)이라 한다.
• 웹브라우저는 퓨니코드를 사용해 사용자가 입력한 다국어로 된 도메인 이름을 알파벳과 숫자 등으로 된 도메인 이름으로 변환한다.

15장 엔터티와 인코딩

목표: 엔터티 및 그와 연관된 엔터티 헤더들이 콘텐츠를 나르기 위해 하는 일들을 알아본다.

1. 메시지는 컨테이너🗄, 엔터티는 화물📦

• HTTP 메시지를 인터넷 운송 시스템의 컨테이너라고 생각한다면,

• HTTP 엔터티는 메시지의 실질적인 화물이다.

• 엔터티 헤더는 18자(Content-Length:18)의 플레인 텍스트 문서를 의미한다.

  

**`메시지 엔터티는 엔터티 헤더와 엔터티 본문으로 이루어진다!`**

엔터티 본문

• 가공되지 않은 데이터만을 담고 있다.
• 헤더 필드의 끝을 의미하는 빈 CRLF 줄 바로 다음부터 시작한다.

2. Content-Length: 엔터티의 길이

• 메시지의 엔터티 본문의 크기를 바이트 단위로 나타낸다.
• 엔터티 본문을 포함한 메시지에서는 필수적으로 존재해야 한다.
• 서버 충돌로 인해 메시지가 잘렸는지 감지하고자 할 때와 지속 커넥션을 공유하는 메시지를 올바르게 분할하고자 할 때 필요하다.

2.1 잘림 검출

• Content-Length가 없다면 클라이언트는 커넥션이 정상적으로 닫힌 것인지 메시지 전송 중에 서버에 충돌이 발생한 것인지 구분하지 못한다.
• 메시지 잘림을 검출하기 위해 Content-Length가 필요하다.

2.2 Content-Length와 지속 커넥션(Persistent Connection)

• Content-Length는 지속 커넥션을 위해 필수이다.
• 응답이 지속 커넥션을 통해서 온 것이라면, 또 다른 HTTP 응답이 즉시 그 뒤를 이어서 온다.
• HTTP 애플리케이션은 Content-Length 헤더 없이는 어디까지가 본문이고 다음 메시지인지 알지 못한다.

2.3 콘텐츠 인코딩

• HTTP는 보안을 강화하거나 압축을 통해 공간을 절약하도록, 엔터티 본문을 인코딩할 수 있게 해준다.
• 본문의 콘텐츠가 인코딩되어 있다면, Content-Length 헤더는 인코딩된 본문의 길이를 바이트 단위로 정의한다.

3. 엔터티 요약

• HTTP는 불완전한 트랜스코딩 프락시나 버그 많은 중개자 프락시를 비롯한 여러가지 이유로 메시지의 일부분이 전송 중에 변형되는 이리 나타난다.
• 엔터티 본문 데이터에 대한 의도하지 않은 변경을 감지하기 위해, 최초 엔터티가 생성될 때 송신자는 데이터에 대한 체크섬을 생서할 수 있고, 수신자는 모든 의도하지 않은 엔터티의 변경을 잡아내기 위해 체크섬으로 기본적인 검사를 할 수 있다.
• Content-MD5 헤더는 서버가 엔터티 본문에 MD5 알고리즘을 적용한 결과를 보내기 위해 사용된다.

4. 미디어 타입과 차셋(Charset)

• Content-Type 헤더 필드는 엔터티 본문의 MIME 타입을 기술한다.

  MIME?

  • 전달되는 테이터 매체의 기저형식의 표준화된 이름이다.
  • ex) HTML파일, 워드 문서, MPEG 비디오 등

• 주 미디어타입 / 부 타입 으로 구성된다.

• text/html, text/plain, image/gif, image/jpeg 등

4.1 텍스트 매체를 위한 문자 인코딩

• 엔터티 비트 집합을 텍스트 파일의 글자들로 변환하기 위한 charset 매개변수가 대표적인 예이다.
• Content-Type: text/html; charset=iso-8859-4

4.2 멀티파트 폼 제출

• HTTP 폼을 채워서 제출하면, 가변 길이 텍스트 필드와 업로드 될 객체는 각각 멀티파트 본문을 구성하는 하나의 파트가 되어 보내진다.
• Content-Type: multipart/form-data; boundary=[abcdefghijklmnopqrstuvwxyz]

5. 콘텐츠 인코딩

• HTTP 애플리케이션은 때때로 콘텐츠를 보내기 전에 인코딩을 한다.

5.1 콘텐츠 인코딩 과정

1. 웹 서버가 원본 Content-Type과 Content-Length 헤더를 수반한 원본 응답 메시지를 생성한다.
2. 콘텐츠 인코딩 서버가 인코딩된 메시지를 생성한다. 콘텐츠 인코딩 서버는 Content-Encoding헤더를 인코딩된 메시지에 추가하여, 수신 측 애플리케이션이 그것을 디코딩할 수 있도록 한다.
3. 수신 측 애플리케이션은 인코딩된 메시지를 받아서 디코딩하고 원본을 얻는다.

5.2 콘텐츠 인코딩 유형

• 인코딩은 각 콘텐츠 인코딩 알고리즘에 고유한 토큰을 할당하는 IANA를 통해 표준화된다.
  • gzip → 가장 효율적이고 널리 쓰이는 압축 알고리즘
  • compress
  • deflate
  • identity

5.3 Accept-Encoding 헤더

• 클라이언트는 자신이 지원하는 인코딩의 목록을 Accept-Encoding 요청 헤더를 통해 전달한다.

  예)..

  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

• 클라이언트는 각 인코딩에 Q(quality)값을 매개변수로 더해 선호도를 나타낸다.

6. 전송 인코딩과 청크 인코딩

• 콘텐츠 인코딩은 콘텐츠 포맷과 긴밀하게 연관되어 있다.
• 전송 인코딩 또한 본문에 적용되는 가역적 변환이지만, 구조적인 이유 때문에 적용되는 것이며 콘텐츠의 포맷과는 독립적이다.

콘텐츠 인코딩 & 전송 인코딩

• 콘텐츠 인코딩된 메시지는 단지 메시지의 엔터티 부분만 인코딩한다.

6.1 청크 인코딩

• 청크 인코딩은 메시지를 일정 크기의 청크 여럿으로 쪼갠다.
• 청크 인코딩을 이용하면 메시지를 보내기 전에 전체 크기를 알 필요가 없다.
• 청크 인코딩이 전송 인코딩의 한 형태이며 따라서 본문이 아닌 메시지의 속성이다.

청크 인코딩된 메시지의 구조

6.2 전송 인코딩 규칙

1. 전송 인코딩의 집합은 반드시 chunked를 포함해야 한다.
2. 청크 전송 인코딩이 사용되었다면, 메시지 본문에 적용된 마지막 전송 인코딩이 존재해야 한다.
3. 청크 전송 인코딩은 반드시 메시지 본문에 한 번 이상 적용되어야 한다.

7. 검사기와 신선도

• 클라이언트는 처음에 리소스를 서버에게 달라고 요청보낸다.
• 클라이언트는 사본 리소스를 받아서 캐시한다.
• 클라이언트는 반드시 서버에게 최신 사본을 요청한다.
• 서버에서 문서가 변경되지 않았다면 클라이언트는 다시 받을 필요가 없다.

조건부 요청

• 클라이언트가 서버에게 자신이 갖고 잇는 버전을 말해주고 검사기를 사용해 자신의 사본 버전이 더 이상 유효하지 않을 때만 사본을 보내달라고 요청하는 것이다.

8. 범위 요청

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

  

14장 보안 HTTP

목표: HTTP 트랜잭션을 안전하게 보호하는 더 복잡한 기술들을 알아본다.

1. HTTP를 안전하게 만들기

• 사용자들이 온라인 쇼핑이나 인터넷뱅킹을 안심하고 사용하기 위해서는 강력한 보안이 필요하다.
• HTTP의 보안 버전은 효율적이고, 이식성이 좋으며, 관리가 쉽고, 현실 세계의 변화에 대한 적응력이 좋아야 한다.

1.1 HTTPS

• 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화 된다.
• HTTP의 하부의 보안 계층에서 안전 소켓 계층(Secure Sockets Lyaer, SSL) 또는 전송 계층 보안(Transport Layer Security, TLS)에서 동작한다.
• 어려운 인코딩 및 디코딩 작업은 SSL 라이브러리 안에서 동작하므로 클라이언트와 서버가 크게 변경할 필요는 없다.

2. 디지털 암호학

2.1 암호학 용어들

• 암호: 테스트를 아무나
• 키: 암호의 동작을 변경하는 숫자로 된 매개변수
• 대칭키 암호 체계: 인코딩과 디코딩에 같은 키를 사용하는 알고리즘
• 비대칭키 암호 체계: 인코딩과 디코딩에 다른 키를 사용하는 알고리즘
• 공개키 암호법: 비밀 메시지를 전달하는 수백만 대의 컴퓨터를 쉽게 만들 수 있는 시스템
• 디지털 서명: 메시지가 위조 혹은 변조되지 않았음을 인증하는 체크섬
• 디지털 인증서: 신뢰할 만한 조직에 의해 서명되고 검증된 신원 확인 정보

2.2 암호(cipher)

• 암호란 메시지를 인코딩하는 어떤 특정한 방법과 그 비밀 메시지를 디코딩하는 방법이다.
• 암호가 적용되어 있는 메시지를 텍스트 혹은 평문이라고 한다.
• 암호는 상대적으로 간단한 알고리즘으로 시작해 기술의 진보에 따라 복잡한 암호를 빠르고 정확하게 인코딩&디코딩 하는 기계를 만들었다.

2.3 키가 있는 암호

• 디코딩 과정을 바르게 동작시키려면 올바른 키를 암호 기계에 입력할 필요가 있다.
• 암호키는 하나의 암호 기계를 여러 가상 암호 기계의 집합처럼 만든다.
• 서로 다른 키 값을 가지고 있으므로 제각기 다르게 동작한다.

2.4 디지털 암호

• 속도 및 기능에 대한 기계 장치의 한계에서 벗어나, 복잡한 인코딩과 디코딩 알고리즘이 가능하다.
• 단일 암호 알고리즘으로 키의 값마다 다른 수조 개의 가상 암호 알고리즘을 만들어낼 수 있다.

3. 대칭키 암호법

• 디지털 알고리즘은 인코딩 할 때와 디코딩 할 때 똑같은 키를 사용하므로 대칭키 암호라 불린다.
• 발송자와 수신자 모두 통신을 위해 비밀 키를 똑같이 공유 할 필요가 있다.
• 발송자는 메시지를 암호화 하고 그 결과인 암호문을 수신자에게 발송하기 위해 비밀키를 사용한다.
• 수신자는 암호문을 받은 뒤 공유키를 사용하여 원래대로 복원하기 위해 해독 함수를 적용한다.

4. 공개키 암호법

• 두 개의 비대칭 키로 하나는 인코딩시에 다른 하나는 디코딩시에 사용한다.
• 호스트만이 개인 디코딩 키를 알고 있다.

4.1 RSA

• 공개키

• 가로채서 얻은 암호문의 일부(네트워크 스누핑해서 획득)

• 메시지와 그것을 암호화한 암호문

  → 공개키 비대칭 암호는 위 항목들을 알아도 계산할 수 없다는 것을 확신시켜 줘야한다.

• 그 중 RSA는 공개키 암호 체계중 유명하며, 가장 상용화된 알고리즘이다.

4.2 혼성 암호 체계와 세션 키

• 공개키 암호 방식의 알고리즘은 계산이 느린 경향이 있다.
• 실제로는 대칭과 비대칭 방식을 섞은 것이 쓰인다.

5. 디지털 서명

• 메시지가 위조되지 않았음을 증명하기 위해 메시지에 서명을 하도록 한다.
• 보안 인증서에 중요하다.

5.1 서명은 암호 체크섬

• 서명은 메시지를 작성한 저자가 누군지 알려준다.
• 서명은 메시지 위조를 방지한다.
• 디지털 서명은 보통 비대칭 공개키에 의해 생성된다.
• 저자의 개인키는 지문처럼 사용된다.

6. 디지털 인증서

신뢰할 수 있는 기관으로부터 보증 받은 사용자나 회사에 대한 정보를 담는다.

6.1 인증서의 내부

• 대상의 이름, 유효기간, 인증서 발급자, 디지털 서명과 같이 기본적인 것들을 담고 있다.
• 누구나 디지털 인증서를 만들 수 있지만, 인증서의 정보를 보증하고 인증서를 개인 키로 서명할 수 있는 널리 인정받는 서명 권한을 얻을 수 있는 것은 아니다.

13장 다이제스트 인증

목표: 기본 인증과 호환되는 더 안전한 대체재로서의 다이제스트 인증을 알아본다.

1. 다이제스트 인증의 개선점

특징

• 비밀번호를 절대로 네트워크를 통해 평문으로 전송하지 않는다.
• 인증 체결을 가로채서 재현하려는 악의적인 사람들을 처단한다.
• 구현하기에 따라서, 메시지 내용 위조를 막는것이 가능하다.
• 그 외의 잘 알려진 형태의 공격을 막는다.

1.1 비밀번호를 안전하게 지키기 위해 요약 사용하기

• 다이제스트 인증을 요약하면 “절대로 비밀번호를 네트워크를 통해 보내지 않는다” 이다.
• 클라이언트는 비밀번호를 비가역적으로 뒤섞은 지문(fingerprint) 혹은 요약(digest)를 보낸다.

1.2 단방향 요약

• 요약은 ‘정보 본문의 압축’이다.
• 요약은 단방향 함수로 동작하고, 무한 가지의 모든 입력 값들을 유한한 범위의 압축으로 변환한다.
• 만약 비밀번호를 모른다면 서버에게 보내줄 알맞은 요약을 추측하기 위해 많은 시간을 소모하게 된다.
• 요약은 비밀번호를 그대로 전송해야 할 필요성에서 해방시켜준다.

1.3 재전송 방지를 위한 난스(nonce) 사용

• 요약은 비밀번호 자체와 다름 없으므로 요약을 가로챈다면 요약을 서버로 재전송할 수 있다.
• 재전송을 막기 위해서 서버는 클라이언트에게 난스라고 불리는 특별한 증표를 넘겨준다.
• 난스는 약 1밀리초마다, 인증할때마다 바뀌게 된다.

1.4 다이제스트 인증 핸드 셰이크

1. 서버는 난스 값을 계산한다.
2. 서버는 난스를 WWW-Authenticate 인증요구 메시지에 담아, 알고리즘 목록과 함께 클라이언트에 보낸다.
3. 클라이언트는 알고리즘을 선택하고 비밀번호와 그 외 데이터에 대한 요약을 계산한다.
4. 클라이언트는 Authorization 메시지에 요약을 담아 서버에게 돌려준다.
5. 서버는 요약, 선택한 알고리즘, 그 외 보조 데이터들을 받고, 클라이언트가 했던 그대로 요약을 계산한다. 서버는 자신이 계산한 요약과 네트워크로 전송되어 온 요약이 서로 같은지 확인한다.

2. 보호 수준(Quality of Protection) 향상

• qop 필드는 클라이언트와 서버가 어떤 보호 기법을 어느 정도 수준으로 사용할 것인지 협상할 수 있게 해준다.

2.1 메시지 무결성 보호

• 무결성 보호가 적용되었을 때 계산되는 엔터티 본문은, 메시지 본문의 해시가 아닌 엔터티 본문의 해시이다.
• 송신자에 의해 어떠한 전송 인코딩이 적용되기도 전에 먼저 계산되고 그 후 수신자에 의해 제거된다.

2.2 다이제스트 인증 헤더

• 기본, 다이제스트 인증은 WWW-Authentication 헤더에 담겨 전달되는 인증요구와, Authentication 헤더에 담겨 전달되는 인기 응답을 포함한다.
• 다이제스트는 Authentication-Info 헤더를 추가했다.
• 3단계 핸드셰이크를 완성하고 다음번 사용할 난스를 전달하기 위해 인증 성공 후에 전송된다.

• 3. 다이제스트 인증 작업시 고려할것들

3.1 다중 인증요구

• 서버는 한 리소스에 대해 여러 인증을 요구할 수 있다.
• 다양한 인증 옵션을 제공하는 경우, ‘가장 허약한 부분‘에 대한 보안우려가 있다는 것이 명확하다.

3.2 오류처리

• 지시자나 그 값이 적절하지 않거나 요구된 지시자가 빠져 있으면, 응답은 400 Bad Request이다.
• 인증 서버는 uri 지시자가 가리키는 리소스가 요청줄에 명시된 리소스와 같음을 확인해야 한다.
• 반복된 실패에 대해서는 따로 기록해 두는 것이 좋다.

3.3 보호 공간(Protection Space)

• 영역 값은 접근한 서버의 루트 URL과 결합되어 보호 공간을 정의한다.
• 영역 값은 원 서버에 의해 할당되는 문자열이며 인증 제도에 추가적인 의미를 더한다.
• 보호 공간은 어떤 자격이 자동으로 적용되는 영역을 정한다.

3.4 URI 다시 쓰기

• 프락시는 가리키는 리소스의 변경 없이 구문만 고쳐서 URI를 다시 쓰기도 한다.
  • 호스트 명은 정규화되거나 IP 주소로 대체된다.
  • 문자들은 % escape 형식으로 대체될 수 있다.
  • 서버로부터 가져오는 리소스에 영향을 주지 않는, 타입에 대한 추가 속성이 URI의 끝에 붙거나 중간에 삽입될 수 있다.

3.5 캐시

Authorization 헤더를 포함한 요청과 그에 대한 응답을 받은 경우, 두 Cache-Control 지시자 중 하나가 응답에 존재하지 않는 한 다른 요청에 대해 응답을 반환해서는 안된다.

4. 보안에 대한 고려사항

4.1 헤더 부당 변경

헤더 부당 변경에 대해 안전한 시스템을 제공하기 위해서, 양 종단 암호화나 헤더에 대한 디지털 서명이 필요하다.

4.2 재전송 공격

• 폼 데이터를 전송할 때 이전에 사용했던 자격을 재사용해도 문제없이 동작한다면, 큰 문제가 생기게 된다.
• 재전송 공격을 완전히 피하기 위해서는 매 트랜잭션마다 유일한 난스 값을 사용하는 것이다.
• 서버는 매 트랜잭션마다 난스와 함께 타임아웃 값을 발급한다.

4.3 다중 인증 메커니즘

• 클라이언트에게 항상 가장 강력한 인증제도를 선택하도록 한다.
• 가장 강력한 인증 제도만을 유지하는 프락시 서버를 사용한다.

4.4 사전 공격

• 전형적인 비밀번호 추측 공격이다.
• 비밀번호 만료 정책이 없고, 충분한 시간이 있고, 비밀번호를 크래킹할 비용을 치를 수 있다면, 비밀번호를 쉽게 수집할 수 있다.
• 크래킹하기 어렵도록 복잡한 비밀번호를 사용하고 괜찮은 비밀번호 만료 정책을 사용하는 것이 좋다.

4.5 악의적인 프락시와 중간자 공격

• 프락시중 하나가 악의적이거나 보안이 허술하다면 클라이언트는 중간자 공격에 취약한 상태가 될 수 있다.
• 프락시는 보통 정교한 프로그래밍 인터페이스를 제공하므로 그러한 프락시들을 이용하는 플러그인을 이용하여 트래픽을 가로채 수정하는 것이 가능하다.
• 이 문제를 해결하기에는 한계가 있으므로, 클라이언트가 가능한 가장 강력한 인증을 선택하도록 설정한다.

4.6 선택 평문 공격

• 보안이 허술하거나 악의적인 프락시가 트래픽 중간에 끼어든다면, 클라이언트가 응답 계산을 하기 위한 난스를 제공 할 수 있다.
• 응답을 계산하기 위해 알려진 키를 사용하는 것은 응답의 암호 해독을 쉽게 한다.
• 클라이언트가 서버에서 제공된 난스 대신 선택적인 c난스 지시자를 사용하여 응답을 생성할 수 있도록 설정하는 것이 좋다.

4.7 비밀번호 저장

• 다이제스트 인증 비밀번호 파일이 유출되면 영역의 모든 문서는 공격자에게 노출된다.
• 비밀번호 파일이 평문으로 된 비밀번호를 포함하고 있다고 생각하고 안전하게 보호한다.
• 영역 이름이 유일함을 보장한다.

12장 기본인증

목표 : HTTP 인증과 그것의 기본이 되는 기본 인증을 알아본다.

1. 인증

1.1 HTTP의 인증요구/응답 프레임워크

1.2 인증 프로토콜과 헤더

• HTTP에는 기본 인증과 다이제트스트 인증이 존재한다.

2. 기본 인증

• 기본 인증은 HTTP/1.0에 기술되어 있었지만, RFC 2617로 옮겨졌다.

2.1 기본 인증의 예

1. 사용자가 리소스를 요청한다.
2. 서버가 WWW-Authenticate 헤더와 함께 리소스를 접근하는데 필요한 비밀번호를 요구하는 401 Authorization Required 응답을 반환한다.
3. 브라우저에서 401 응답을 받고 사용자 이름과 비밀번호를 입력하는 화면을 띄운다. 브라우저는 정보들을 콜론으로 이어 붙이고, base-64방식으로 인코딩하고, Authorization 헤더에 그 값을 담아 서버로 다시 보낸다.
4. 서버는 사용자 이름과 비밀번호를 디코딩하고, 그 값이 정확한지 확인하고, 문제 없으면 HTTP 200 OK 메시지와 함께 요청받았던 문서를 보낸다.

2.2 Base-64 사용자 이름/비밀번호 인코딩

• HTTP 기본 인증은 사용자 이름과 비밀번호를 클론으로 이어서 합치고, base-64인 코딩 메서드를 사용해 인코딩 한다.
• base-64 인코딩은 8비트 바이트로 이루어져 있는 시퀀스를 6비트 덩어리의 시퀀스로 변환한다.
• base-64 인코딩은 국제 문제나 HTTP 헤더에서 사용할 수 없는 문자를 보내야 할 때 유용하다.

2.3 프락시 인증

• 중개 프락시 서버를 통해 인증 할 수 있다.
• 프락시 서버에서 접근 정책을 중앙 관리 할 수 있기 때문에, 회사 리소스 전체에 대해 통합적인 접근 제어를 하기 위해서 프락시 서버를 사용하면 좋다.

3. 기본 인증의 보안 결함

• 기본 인증은 사용자 이름과 비밀번호를 쉽게 디코딩 할 수 있는 형식이므로 노출되어서는 안된다.
• 메시지의 인증 헤더를 건드리지 않고, 그 외 다른 부분을 수정해서 트랜잭션의 본래 의도를 바꿔버리는 프락시나 중개자가 중간에 개입하는 경우, 기본 인증은 정상적인 동작을 보장하지 않는다.