HTTP 완벽 가이드 2부 - HTTP 아키텍처(1/2)

HTTP 완벽 가이드 시리즈를 정리한 내용입니다.

5장 웹 서버

5.1 다채로운 웹 서버

• 웹 서버라는 용어는 웹 서버 소프트웨어와 웹페이지 제공에 특화된 장비 모두를 가리킨다.
• 모든 웹 서버는 리소스에 대한 HTTP 요청을 받아서 콘텐츠를 클라이언트에게 돌려준다.

5.1.1 웹 서버 구현

• 웹 서버는 HTTP 및 그와 관련된 TCP 처리를 구현한 것이다.
• 웹 서버의 여러가지 형태
  • 다목적 소프트웨어 웹 서버를 표준 컴퓨터 시스템에 설치, 실행
  • 전자기기 안에 몇 개의 칩으로 구현된 웹 서버를 내정, 완전한 관리 콘솔로 제공(임베디드)

5.1.2 다목적 소프트웨어 웹 서버

• 수 많은 웹 서버 소프트웨어가 존재하지만 Apache, Microsoft, nginx 등 몇가지만이 널리 사용된다.

5.1.3 임베디드 웹 서버

• 일반 소비자용 제품에 내장될 목적으로 만들어진 작은 웹 서버(프린터 등)

5.3 진짜 웹 서버가 하는 일

1. 커넥션을 맺는다
   • 클라이언트의 접속을 받아들이거나, 원치 않는 클라이언트라면 닫는다.
2. 요청을 받는다.
   • HTTP 요청 메시지를 네트워크로부터 읽어 들인다.
3. 요청을 처리한다.
   • 요청 메시지를 해석하고 행동을 취한다.
4. 리소스에 접근한다.
   • 메세지에서 지정한 리소스에 접근한다.
5. 응답을 만든다.
   • 올바른 헤더를 포함한 HTTP 응답 메시지를 생성한다.
6. 응답을 보낸다.
   • 응답을 클라이언트에게 돌려준다.
7. 트랜잭션을 로그로 남긴다.
   • 로그파일에 트랜잭션 완료에 대한 기록을 남긴다.

5.4 단계 1: 클라이언트 커넥션 수락

5.4.1 새 커넥션 다루기

• 클라이언트가 TCP 커넥션을 요청하면, 웹 서버는 그 커넥션을 맺고 TCP 커넥션에서 IP 주소를 추출하여 커넥션 맞은편에 어떤 클라이언트가 있는지 확인한다.
• 웹 서버는 어떤 커넥션이든 마음대로 거절하거나 즉시 닫을 수 있다.

5.4.2 클라이언트 호스트 명 식별

• 대부분의 웹 서버는 역방향 DNS를 사용해서 클라이언트의 IP 주소를 클라이언트의 호스트 명으로 변환하도록 설정되어 있다.
  • 구체적인 접근 제어와 로깅을 위해 사용한다.

5.5 단계 2: 요청 메시지 수신

• 커넥션에 데이터가 도착하면, 웹 서버는 네트워크 커넥션에서 그 데이터를 읽어 들이고 파싱하여 요청 메세지를 구성한다.

5.5.2 커넥션 입력/출력 처리 아키텍처

• 웹 서버는 커넥션들로부터 요청에 언제 어떻게 들어올지 모르므로 항상 주시하고 있다.
• 웹 서버 아키텍처의 차이에 따라 요청을 처리하는 방식도 달라진다.

1. 단일 스레드 웹 서버
   • 한번에 하나씩 요청을 처리한다.
   • 처리 도중 다른 모든 커넥션은 무시된다.
2. 멀티프로세스와 멀티스레드 웹 서버
   • 동시에 여러 요청을 처리하기 위해 여러 개의 프로세스 혹은 고효율 스레드를 할당한다.
   • 필요할 때마다 만들 수도 있고, 이미 만들어져있을 수도 있다.
   • 너무 많으면 메모리, 시스템 리소스의 소비가 크므로 최대 개수에 제한을 건다.
3. 다중 I/O 서버
   • 여러 커넥션을 감시하며 커넥션의 상태가 바뀌는 경우에만 처리가 수행된다.
   • 처리가 완료되면 다시 열린 커넥션 목록으로 돌아간다.
   • 유휴 상태의 커넥션에 매여 기나리느라 리소스를 낭비할 필요가 없다.
4. 다중 멀티스레드 웹 서버
   • 장점을 합쳐, 여러 개의 스레드는 각각 열려있는 커넥션을 감시하고 각 커넥션에 대해 조금씩 작업을 수행한다.

5.6 단계 3: 요청 처리

• 요청으로부터 메서드, 리소스, 헤더, 본문을 얻어내어 처리한다.

5.7 단계 4: 리소스의 매핑과 접근

5.7.1 Docroot

• 리소스 매핑의 가장 단순한 형태는 요청 URI를 웹 서버의 파일 시스템 안에 있는 파일 이름으로 사용하는 것이다.
• 웹 서버 파일 시스템의 특별한 폴더를 웹 콘텐츠를 위해 예약해 두는데, 이 폴더를 문서 루트 혹은 docroot라 부른다.
• 요청 메시지에서 URI를 가져와 문서 루트 뒤에 붙인다.
• 서버는 상대적인 url이 docroot를 벗어나서 파일 시스템의 docroot 이외 부분이 노출되는 일이 생기지 않도록 주의해야 한다.

가상 호스팅된 docroot

• 각 사이트에 그들만의 분리된 문서 루트를 주는 방법으로 한 웹 서버에서 여러 개의 웹 사이트를 호스팅 한다.
• 하나의 웹 서버 위에서 두 개의 사이트가 완전히 분리된 콘텐츠를 갖고 호스팅 되도록 할 수 있다.

사용자 홈 디렉터리 docroot

• 사용자들이 한 대의 웹 서버에서 각자의 개인 웹 사이트를 만들 수 있도록 할 수 있다.
• 빗금(/)과 물결표(~) 다음에 사용자 이름이 오는 것으로 시작하는 URI는 그 사용자의 개인 문서 루트를 가리킨다.

5.7.2 디렉터리 목록

• 웹 서버는 경로가 파일이 아닌 디렉터리를 가리키는 디렉터리 URL에 대한 요청을 받을 수 있다.
• 그럴 때 다음 몇 가지 행동을 취하도록 설정할 수 있다.
  • 에러를 반환한다.
  • 디렉터리 대신 특별한 색인 파일을 반환한다.
  • 디렉터리를 탐색해서 그 내용을 담은 HTML 페이지를 반환한다.

5.7.3 동적 콘텐츠 리소스 매핑

• 웹 서버는 URI를 동적 리소스에 매핑할 수도 있다.

5.7.4 서버사이드 인클루드

• 리소스가 서버사이드 인클루드를 포함하고 있는 것으로 설정되어 있다면, 서버는 그 리소스의 콘텐츠를 클라이언트에게 보내기 전에 처리한다.
• 콘텐츠에 변수 이름이나 내장된 스크립트가 될 수 잇는 어떤 특별한 패턴이 있는지 검사하고, 이는 변수 값이나 실행 가능한 스크립트의 출력 값으로 치환된다.

5.7.5 접근 제어

• 각각의 리소스에 접근 제어를 할당할 수 있다.
  • 클라이언트의 IP주소에 근거하여 접근을 제허할 수 있고 혹은 리소스에 접근하기 위한 비밀번호를 물어볼 수 있다.

5.8 단계 5: 응답 만들기

• 서버가 리소스를 식별하면, 서버는 요청 메서드로 서술되는 동작을 수행한 뒤 응답 메시지를 반환한다.

5.8.1 응답 엔티티

• 응답 메시지는 본문이 있다면 주로 다음을 포함한다.
  • 응답 본문의 MIME 타입을 서술하는 Content-Type 헤더
  • 응답 본문의 길이를 서술하는 Content-Length 헤더
  • 실제 응답 본문의 내용

5.8.2 MIME 타입 결정하기

• mime.types
  • MIME 타입을 나타내기 위해 파일 이름의 확장자를 사용할 수 있다.
  • 각 리소스의 MIME 타입을 계산하기 위해 확장자별 MIME 타입이 담겨 있는 파일을 탐색한다.
  • 가장 흔하게 사용된다.
• 매직 타이핑
  • 아파치 웹 서버는 각 파일의 MIME 타입을 알아내기 위해 파일의 내용을 검사해서 알려진 패턴에 대한 테이블에 해당하는 패턴이 있는지 찾아본다.
  • 느리긴 하지만 표준 확장자 없이 이름 지어진 경우에 편리하다.
• 유형 명시
  • 특정 파일이나 디렉터리 안의 파일들이 파일 확장자나 내용에 상관없이 어떤 MIME타입을 갖도록 웹 서버를 설정할 수 있다.
• 유형 협상
  • 한 리소스가 여러 종류의 문서 형식에 속하도록 설정할 수 있다.

5.8.3 리다이렉션

• 웹 서버는 요청을 수행하기 위해 브라우저가 다른 곳으로 가도록 리다이렉트 할 수 있다.

• 리다이렉션은 3XX상태코드로 지칭된다.

• 영구히 리소스가 옮겨진 경우
  • 리소스는 새 URL이 부여되어 새로운 위치로 옮겨졌거나 이름이 바뀌었을 수 있다.
  • 클라이언트에게 리소스의 이름이 바뀌었으므로, 북마크를 갱신하거나 할 수 있다고 말해줄 수 있다.
  • 301 Moved Permanently
• 임시로 리소스가 옮겨진 경우
  • 리소스가 임시로 옮겨지거나 이름이 변경된 경우, 임시적이므로 서버는 클라이언트가 나중에는 원래 URL로 찾아오길 원한다.
  • 303 See Other, 307 Temporary Redirect
• URL 증강
  • 요청이 도착했을 때, 상태 정보를 내포한 새 URL을 생성하고 사용자를 리다이렉트한다.
  • 클라이언트는 리다이렉트를 따라가서, 상태정보가 추가된 완전한 URL을 포함한 요청을 다시보낸다.
  • 트랜잭션 간 상태를 유지하는 유용한 방법이다.
  • 303 See Other, 307 Temporary Redirect
• 부하 균형
  • 과부하된 서버가 요청을 받으면, 덜 부하가 걸린 서버로 리다이렉트시킨다.
  • 303 See other, 307 Temporary Redirect
• 친밀한 다른 서버가 있을 때
  • 서버는 클라이언트를 그 클라이언트에 대한 정보를 갖고 있는 다른 서버로 리다이렉트할 수 있다.
  • 303 See Other, 307 Temporary Redirect
• 디렉터리 이름 정규화
  • 디렉터리 이름에 대한 URI를 요청하는데 빗금을 빠뜨렸다면, 상대경로가 정상적으로 동작하도록 슬래시를 추가한 URI로 리다이렉트시킨다.

5.9 단계 6: 응답 보내기

• 서버는 커넥션 상태를 추적해야 하며 지속적인 커넥션은 특히 주의해서 다루어야 한다.

5.10 단계 7: 로깅

• 트랜잭션이 완료되었을 때 웹 서버는 트랜잭션이 어떻게 수행되었는지에 대한 로그를 로그파일로 기록한다.

6장 프록시(Proxy)

6.1 웹 중개자

• 웹 프록시 서버는 클라이언트의 입장에서 트랜잭션을 수행하는 중개인이다.
• 클라이언트는 자신의 입장에서 서버와 대화해주는 프록시와 대화하게 된다.
• 프록시 서버는 웹 서버이기도 하고 웹 클라이언트이기도 하다.

6.1.1 개인 프록시와 공유 프록시

• 공용 프록시
  • 대부분의 프록시는 공유된 프록시이다.
  • 몇몇 프록시는 사용자가 많을수록 공통된 요청에서 이득을 취할 수 있어 유리하다.
• 개인 프록시
  • 브라우저의 기능을 확장하거나 성능을 개선하는 등 사용자의 컴퓨터에서 직접 실행한다.

6.1.2 프록시 대 게이트웨이

• 프록시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결하고, 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다.

  브라우저 <-HTTP-> 웹 프록시 <-HTTP-> 웹 서버
  브라우저 <-HTTP-> 웹/이메일 게이트웨이 <-POP-> 이메일 서버

• 프록시도 때로는 프로토콜 변환을 하기도 하고, 게이트웨이 기능을 구현하기도 한다.

6.2 왜 프록시를 사용하는가?

어린이 필터

• 초등학교는 성인 콘텐츠를 차단하고자 필터링 프록시를 사용할 수 있다.
• 부적절한 사이트의 접근을 강제로 거절한다.

문서 접근 제어자

• 많은 웹 서버와 웹 리소스들에 대한 단일한 접근 제어 전략을 구현한다.
• 각각의 서버, 리소스들에 대한 접근 제어를 수시로 갱신할 필요 없이, 중앙 프록시 서버를 통해 접근 제어를 설정한다.

보안 방화벽

• 조직 안에 들어오거나 나가는 응용 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제한다.

웹 캐시

• 인기 있는 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오며녀 빠르게 제공한다.

대리 프록시

• 웹 서버로 위장아여 진짜 웹 서버 요청을 받지만 웹 서버와 달리 요청 받은 컨텐츠의 위치를 찾기 위해 다른 서버와 커뮤니케이션을 시작한다.
• 공용 콘텐츠에 대한 느린 웹 서버의 성능을 개선하기 위해 사용될 수 있다.
• 서버 가속기라고도 부른다.

콘텐츠 라우터

• 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도한다.
• 사용자들을 위한 서비스를 구현하는데 사용 될 수 있다. (유료 서비스, 필터링 서비스 등 맞춤형 콘텐츠)

트랜스코더

• 클라이언트에게 전달되는 본문 내용을 수정할 수 있다.(트랜스코딩)
• GIF이미지를 JPG이미지로 변환하거나, 텍스트를 압축하는 등

익명화 프록시

• HTTP 메시지에서 신원을 식별할 수 있는 특성들을 제거하여 개인 정보 보호와 익명성 보장에 기여한다.
• User-Agent헤더 제거, Cookie 헤더 제거 등

6.3 프록시는 어디에 있는가?

6.3.1 프록시 서버 배치

• 출구 프록시
  • 로컬 네트워크의 출구에 높을 수 있다.
  • 악의적인 해커들을 막는 방화벽을 제공하거나, 인터넷 트래픽의 성능을 개선하거나, 콘텐츠를 필터링하는 등
• 접근(입구) 프록시
  • 고객으로부터의 모든 요청을 종합적으로 처리하기 위해 ISP 접근 지점에 위치할 수 있다.
  • 다운로드 속도를 개선하고, 캐시 프록시를 사용해 많이 찾는 문서의 사본을 저장한다.
• 대리 프록시
  • 웹 서버들의 바로 앞에 위치하여 웹서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청한다.
  • 보안 기능을 추가하거나 빠른 웹 서버 캐시를 두어 성능을 개선한다.
  • 일반적으로 웹 서버의 이름과 IP주소로 스스로를 가장하기 떄문에, 모든 요청은 서버가 아닌 이 프록시로 가게 된다.
• 네트워크 교환 프록시
  • 캐시를 이용해 인터넷 교차로의 혼잡을 완화하고 트래픽의 흐름을 감시한다.

6.3.2 프록시 계층

• 프록시 계층에서, 메시지는 최종적으로 원 서버에 도착할 때까지 프록시와 프록시를 거쳐 이동한다.
• 프록시 계층에서 프록시 서버들은 부모와 자식의 관계를 갖는다.
  • 서버에 가까울 수록 부모, 클라이언트에 가까울 수록 자식
• 계층이 항상 정적인 것은 아니다. 여러 판단 근거에 따라 유동적인 프록시 서버와 원 서버들의 집합에게 보낼 수 있다.
  • 부하 균형: 부하를 분산하기 위해 현재 부모들의 작업량 수준에 근거하여 부모 프록시를 고른다.
  • 지리적 인접성에 근거한 라우팅: 원 서버의 지역을 담당하는 부모를 선택할 수 있다.
  • 프로토콜/타입 라우팅: 어떤 자식 프로기슨ㄴ URI에 근거하여 다른 부모나 원 서버로 라우팅할 수 있다.
  • 유료 서비스 가입자를 위한 라우팅: 웹 서비스 운영자가 빠른 서비스를 위해 추가금을 지불했다면, 그들의 URI는 대형 캐시나 성능 개선을 위한 압축 엔진으로 라우팅 될 수 있다.

6.3.3 어떻게 프록시가 트래픽을 처리하는가

• 클라이언트 트래픽이 프록시로 가도록 만드는 방법에는 네가지가 있다.
  • 클라이언트 수정: 브라우저를 포함한 많은 웹 클라이언트들은 수동 혹은 자동 프록시 설정을 지원한다.
  • 네트워크 수정: 클라이언트는 알지 못하는 상태에서, 네트워크 인프라를 가로채서 웹 트래픽을 프록시로 가도록 조정한다. 스위칭 장치와 라우팅 장치가 필요하다.
  • DNS 이름공간을 수정: 대리 프록시는 웹 서버의 이름과 IP주소를 사용하므로 모든 요청은 서버 대신 대리 프록시로 간다.
  • 웹 서버를 수정: HTTP 리다리엑션 명령(305)을 클라이언트에게 내려주고 요청을 프록시로 리다이렉트시킬 수 있다.

6.4 클라이언트 프록시 설정

6.5 프록시 요청의 미묘한 특징들

6.5.1 프록시 URI는 서버 URI와 다르다

• 프로시로 요청을 보낼 때, 요청줄은 완전한 URI를 갖는다.
• 애초에 HTTP는 단일한 클라이언트가 대화했다. 가상 호스팅이나 프록시는 고려되지 않았다.
• 프록시는 목적지 서버와 커넥션을 맺어야 하므로 그 이름을 알아야 한다.
• 클라이언트는 프록시를 사용하지 않도록 설정되어있다면 부분 URI를, 사용하도록 설정되어 있다면 완전한 URI를 내보낸다.

6.5.2 가상 호스트에서 일어나는 같은 문제

• 가상 호스팅도 프록시와 같은 문제를 겪는다.
• 가상 호스팅 웹 서버는 여러 웹사이트가 같은 물리적 웹 서버를 공유하므로 호스트명을 모르면 어떤 웹 서버에 접근하려하는지 알 수 없다.
• 이를 해결하기 위해 가상 호스팅되는 웹 서버는 호스트와 포트에 대한 정보가 담겨 있는 Host헤더를 요구한다.

6.5.3 인터셉트 프록시는 부분 URI를 받는다

• 클라이언트가 프록시를 지나지 않을 것이라 생각해 부분 URI를 내보냈는데, 대리 프록시나 인터셉트 프록시를 지난다면?
• 인터셉트 프록시는 클라이언트에서 서버로 가는 트래픽을 가로채 캐시된 응답을 돌려주는 등의 일을 한다.
  • 따라서 부분 URI을 얻게된다.

6.5.4 프록시는 프록시 요청과 서버 요청을 모두 다룰 수 있다

• 다목적 프록시 서버는 요청 메시지의 완전한 URI와 부분 URI를 모두 지원해야 한다.
• 명시적인 프록시 요청에 대해서는 완전한 URI, 그렇지 않다면 부분 URI, 웹 서버 요청의 경우에는 가상 Host 헤더를 사용해야 한다.
• 완전 URI와 부분 URI를 사용하는 규칙은 다음과 같다.
  1. 완전한 URI가 주어졌다면 그것을 사용한다.
  2. 부분 URI와 Host 헤더가 있다면 Host 헤더를 이용해 원 서버의 이름과 포트 번호를 알아내야 한다.
  3. 부분 URI가 주어졌으나 Host 헤더가 없다면 다음 방법으로 원 서버를 알아내야 한다.
  • 대리 프록시라면 원 서버의 주소와 포트 번호가 설정되어있을 수 있다.
  • 이전에 어떤 인터셉트 프록시가 가로챘던 트래픽을 받았고 그 프록시가 원 IP 주소와 포트번호를 사용할 수 있도록 해두었다면 그 IP주소와 포트번호를 사용할 수 있다.
  • 모두 실패했다면 충분한 정보가 없으므로 에러 메시지를 반환해야 한다.

6.5.5 전송 중 URI 변경

• 몇몇 프록시는 다음 홉으로 URI를 보내기 전에 표준 형식으로 정규화하고는 하는데, 이것이 상호운용성 문제를 일으킬 수 있다.
• 프록시 서버는 가능한 한 관대해야 하며, 프로토콜을 엄격하게 준수하도록 강제해서는 안된다.
• 특히 HTTP 명세는 일반적인 인터셉트 프록시가 URI를 전달할 때 절대 경로를 고쳐쓰는 것을 금지한다.

6.5.6 URI 클라이언트 자동확장과 호스트 명 분석

• 프록시가 없다면, 사용자가 타이핑한 URI를 가지고 그에 대응하는 IP주소를 찾는다.
• 호스트명이 발견되면 그에 대응하는 IP 주소들을 연결에 성공할 때까지 시도해본다.
• 호스트명이 발견되지 않는다면, 사용자가 약어를 사용한 것으로 보고 자동화된 호스트 명의 확장을 제공한다.
  • 웹 사이트 이름의 가운데만 입력했다면 www.접두사와 .com접미사를 붙인다.
  • 서드파티 사이트로 넘겨 오타 교정을 시도하고 사용자가 의도했을법한 URI를 제시한다.

6.5.7 프록시 없는 URI분석

1. 사용자가 ‘Oreilly’를 검색한다.
2. DNS를 통해 찾으나 실패한다.
3. 호스트명을 확장하여 DNS를 통해 ‘www.oreilly.com’을 찾아 IP주소를 반환받는다.
4. IP주소들에 대해 성공할 때까지 하나씩 접속을 시도한다.
5. 성공하여 커넥션을 맺는다.

6.5.8 명시적인 프록시를 사용할 때의 URI분석

• 브라우저의 URI가 프록시를 그냥 지나치므로 확장 기능이 수행되지 못한다.
• 사용자가 ‘oreilly’라고 타이핑한다면 프록시는 ‘http://oreilly/’라고 보낸다.
• 몇몇 프록시는 확장 기능을 흉내내려고 시도한다.

6.5.9 인터셉트 프록시를 이용한 URI분석

• 클라이언트는 프롤시가 존재하지 않는다고 생각하기 때문에 기본적인 내용은 프록시가 없을때와 같다.
• IP주소에 접속을 시도할 때, 죽은 IP주소일 수도 있지만 인터셉트 프록시는 이를 가로채고 접속 시도가 종료된다.
• 클라이언트는 성공적으로 웹 서버와 대화했다고 믿는다.
• 프록시가 최종적으로 진짜 원 서버와 상호작용할 준비가 되었을 때, IP주소가 다운된 주소를 가리키고 있다면 프록시는 호스트 헤더에 들어있는 호스트 명을 다시 분석하든 IP 주소에 대한 역방향 DNS 룩업을 해서든 다른 IP주소를 시도해야 한다.

6.6 메시지 추적

• 프록시가 흔해지면서, 서로 다른 스위치와 라우터를 넘나드는 IP 패킷의 흐름을 추적하는 것 못지않게 프록시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것도 필요한 일이 되었다.

6.6.1 Via 헤더

• 메시지가 지나는 각 중간 노드의 정보를 나열한다.

Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com

-> 첫번째 프록시는 HTTP/1.1 프로토콜을 구현했고 proxy-62.irenes-isp.net라 불리며 두번째 프록시는 HTTP/1.0을 구현했고 cache.joes-hardware.com로 불린다.

• 프록시는 네트워크의 라우팅 루프를 탐지하기 위해 Via 헤더를 사용할 수 있다.
  • 프록시는 요청을 보내기 전에 자신을 가리키는 유일한 문자열을 Via헤더에 삽입해야 하고, 루프가 있는지 탐지하기 위해 이 문자열이 들어온 요청에 있는지 검사해야 한다.
• 각 Via waypoint는 프로토콜 이름(선택. 기본은 HTTP), 프로토콜 버전(필수), 노드이름(필수), 코멘트(선택)의 최대 4개의 구성요소를 담을 수 있다.
  • 프로토콜 이름: HTTP라면 없어도 된다. 버전 앞에 ‘/’로 구분되어 붙는다.
  • 프로토콜 버전: 애플리케이션들은 자신 이전의 모든 중개자들이 어떤 버전을 다룰 수 있는지 알 수 있다.
  • 노드 이름: 중개자의 호스트와 포트 번호. 정보 보호를 이유로 진짜 호스트명을 밝히고싶지 않을 경우 가명으로 대체할 수 있다.
  • 노드 코멘트: 중개자 노드를 서술하는 선택적인 코멘트. 벤터나 버전 정보등을 포함할 수도 있다.
• 응답 Via와 요청 Via는 대체로 반대이다.
• Server 헤더
  • 원 서버에 의해 사용되는 소프트웨어를 알려준다.
  • 응답 메시지가 프록시를 통과할 때, 프록시는 Server 헤더를 수정해서는 안된다.

6.6.2 TRACE 메서드

• 프록시는 메시지가 전달될 때 메시지를 바꿀 수 있다.
• 프록시 네트워크를 쉽게 진단하기 위해, 홉에서 홉으로 전달될 때마다 메시지의 내용이 어떻게 변하는지 관찰할 방법이 필요하다.
• TRACE 메서드는 요청 메시지를 프록시의 연쇄를 따라가면서 어떤 프록시를 지나가고 어떻게 각 프록시가 요청 메시지를 수정하는지 관찰/추적할 수 있도록 해준다.
• TRACE요청이 목적지 서버에 도착했을 때, 서버는 전체 요청 메시지를 HTTP응답 메시지의 본문에 포함시켜 송신자에게 그대로 돌려보낸다.
• Max-Forwards
  • 홉의 갯수를 제한하여 메시지가 무한 루프에 빠지지 않는지 테스트하거나 연쇄 중간의 특정 프록시 서버들의 효과를 체크한다.
  • 몇 번 더 다음 홉으로 전달될 수 있는가에 대한 정수를 담고있으며, 전달될 때 마다 1씩 감소되고 0이되면 무조건 더이상 전달하지 말고 클라이언트에게 돌려줘야 한다.

6.7 프록시 인증

• 접근 제어 장치로서 제공될 수 있다.
  1. 제한된 콘텐츠에 대한 요청이 오면 접근 자격을 요구하는 407 Proxy Authorization Required 상태 코드를 어떻게 자격을 제출할 수 있는지 설명하는 Proxy-Authenticate 헤더 필드와 함께 반환한다.
  2. 클라이언트는 응답을 받게 되면 요구되는 자격을 수집한다.
  3. 자격을 획득하면 요구되는 자격을 Proxy-Authorization헤더 필드에 담아서 요청을 다시 보낸다.
  4. 자격이 유효하다면 원 요청을 연쇄를 따라 통과시킨다.

6.8 프록시 상호운용성

• 프록시 서버는 서로 다른 프로토콜을 구현했을 수도 있고 골치 아프게 이상한 동작을 할 수도 있는 클라이언트와 서버 사이를 중계해야 한다.

6.8.1 지원하지 않는 헤더와 메서드 다루기

• 프록시 서버는 모든 헤더 필드들을 이해하지 못할 수도 있다.
• 프록시는 이해할 수 없는 헤더 필드는 반드시 그대로 전달해야 한다.
• 같은 이름의 헤더 필드가 여러개 있다면 상대적인 순서도 반드시 유지해야 한다.
• 프록시가 어떤 메서드와도 친숙하지 않다면, 가능한 한 그 메시지를 다음 홉으로 전달하려 시도해야 한다.

6.8.2 OPTIONS 메서드

• OPTIONS 메서드는 서버나 웹 서버의 특정 리소스가 어떤 기능을 지원하늦지 클라이언트가 알아볼 수 있게 한다.
• URI가 ‘*‘라면 요청은 서버 전체의 능력에 대해 묻는 것이 된다.
• URI가 실제 리소스라면, OPTIONS 요청은 특정 리소스에 대해 가능한 기능들을 묻는 것이다.

6.8.3 Aloow 헤더

• 요청 URI에 의해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하는 모든 메서드를 열거한다.

Allow: GET, HEAD, PUT

• 프록시는 지정된 모든 메서드를 이해할 수 없어도 Allow 헤더 필드를 수정할 수 없다.