HTTP완벽가이드 스터디 5, 6장

5장

웹 서버

진짜 웹 서버가 하는 일

• 커넥션 맺기(원치 않는 클라이언트라면 거절)
• request 받기
• request 처리(메세지 해석, 그게 맞는 행동 취하기)
• 리소스에 접근
• response 생성
• return response
• 트랙잭션을 로그로 남기기

클라이언트 호스트 명 식벼ㅑㄹ

• 역방향 DNS를 사용해서 클라이언트의 ip주소를 클라이언트의 호스트명을 변환하도록 설정되어있다.

 

https://kscodebase.tistory.com/300

요청 메시지 수신

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

 

요청 줄을 파싱하여 오청 메서드, 지정된 리소스의 식별자(URI), 버전 번호를 찾는다. 각 값은 스페이스 한 개로 구분되어 있으며, 요청 줄은 캐리지 리턴 줄바꿈으로 끝난다.

메시지 헤더들을 읽는다. 각 헤더는 캐리지 리턴으로 끝난다.

헤더의 끝을 의미하는 캐리지 리턴으로 끝나는 빈 줄을 찾아낸다.

요청 본문이 있다면 읽어들인다. 길이는 Content-Length 헤더로 정의된다.

웹 서버는 메시지가 파싱이 가능한 수준이 될 때까지 메모리에 저장해둔다.

 

5.5.1 메시지 내부 표현

몇몇 웹 서버는 요청 메시지를 쉽게 다루기 위해 내부의 자료구조에 저장한다. (이것은 Express도 해당하는 것으로 보인다. 다양한 메서드와 프로퍼티로 접근이 가능하다.)

 

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

고성능 웹 서버는 수천 개의 커넥션을 동시에 열 수 있도록 지원한다. 이 커넥션은 웹 서버가 전 세계 클라이언트들과 각각 한 개 이상의 커넥션을 통해 통신할 수 있게 해준다.

 

어떤 커넥션들로부터는 요청이 느리게 혹은, 드물게 흘러 들어오고 어떤 것들은 나중에 일어날 활동을 위해 기다리고 있는 데 비해 일부 커넥션은 급속히 요청을 보내고 있을 것이다.

 

(설명이 좀 중구난방한데, 간단히 설명하자면, 차례대로 줄 세우면 맨 앞에 무거운 트랜잭션을 모두가 기다려야 하니, 다른 방법이 필요하다는 것을 말하는 중이다.)

 

아래는 웹 서버들을 처리 방식에 따라 구분한 것이다.

 

단일 스레드 웹 서버 : 한 번에 하나의 요청을 처리한다. 순서가 밀리면 모두 대기해야 하기 때문에 간단한 진단 도구에서만 사용한다.

멀티 프로세스와 멀티 스레드 웹 서버 : 미리 만들거나, 필요할 때마다 만든 여러 개의 프로세스, 혹은 고효율 스레드를 할당한다. 많은 메모리와 시스템 리소스가 필요하다. (개수 제한을 걸기도 한다.)

다중 I/O 서버 : 다중 커넥션을 지원한다. 커넥션의 상태가 바뀌면 (데이터를 사용할 수 있게 되거나 에러가 발생하면) 작은 양의 처리를 실행한다.

다중 멀티 스레드 웹 서버 : CPU가 여러 개인 서버. (하드웨드 레벨에서 서버인 경우)

5.6 단계 3: 요청 처리

웹 서버는 요청을 받으면 응답을 만든다. 이 과정을 요청 처리라고 하는데, 여기서는 설명하지 않는다. 왜냐하면 요청 처리가, 이 책의 나머지 전부이기 때문이다. (앞으로 계속 설명될 것이다.)

 

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

웹 서버는 요청에 맞는 리소스를 찾아서 클라이언트에게 주어야 한다.

 

5.7.1 Docroot

웹 서버는 여러 종류의 리소스를 매핑한다. 가장 단순한 형태는 요청 URL를 웹 서버의 파일 시스템 안에 있는 파일 이름으로 사용하는 것이다.

 

일반적으로 웹 서버 파일 시스템의 특별한 폴더를 웹 콘텐츠를 위해 예약해둔다. 이 폴더는 문서 루트 (Docroot)라고 부른다. 웹 서버는 요청 메시지에서 URI를 가져와서 문서루트 뒤에 붙인다.

 

(Express에서는 public에 해당하는 부분, static, 즉 정적 폴더를 의미하는 것 같다.)

 

서버는 상대적인 URI가 Docroot를 벗어나서 파일 시스템의 Docroot 이외 부분이 노출되지 않도록 해야 한다. 예컨대 이런 경우를 거부해야 한다. www.naver.com/../여기는_뭐가_있을까.jpg

 

가상 호스팅된 Docroot

웹 서버는 각 사이트마다 그들만의 분리된 문서 루트를 줌으로써 웹 서버에 여러 개의 웹 사이트를 호스팅한다. 이 방법으로 두 사이트 이상이 완전히 분리된 콘텐츠를 가지게 할 수 있다.

 

사용자 홈 디렉터리 Docroots

빗금(/)과 물결표(~) 다음에 사용자 이름이 오는 것으로 시작하는 URI는 보통 그 사용자의 개인 문서 루트를 가리킨다.

 

5.7.2 디렉터리 목록

웹 서버는 경로가 파일이 아닌 디렉터리를 가리키는, 디렉터리 URL에 대한 요청을 받을 수 있다. 웹 서버는 이런 요청에 대해 아래처럼 대응할 수 있다.

 

에러를 반환한다.

디렉터리 대신 특별한 '색인 파일'을 반환한다.

디렉터리를 탐색하여 그 내용을 담은 HTML 페이지를 반환한다.

대부분의 웹 서버는 요청한 URL에 대응되는 디렉터리 안에서 index.html 혹은 index.htm으로 이름 붙은 파일을 찾는다.

 

5.7.3 동적 콘텐츠 리소스 매핑

웹 서버는 URI를 동적 리소스에 매핑할 수도 있다. 즉 요청에 맞게 콘텐츠를 생성하는 프로그램에 URI를 매핑하는 것이다. 웹 서버 중 애플리케이션 서버들은 웹 서버를 백엔드 애플리케이션과 연결한다.

 

만약 어떤 리소스가 동적 리소스라면 애플리케이션 서버는 그에 대한 동적 콘텐츠 생성 프로그램이 어디에 있는지, 어떻게 그 프로그램을 실행할 수 있는지 알려주어야 한다.

 

5.7.4 서버사이드 인클루드 (Server-Side Includes, SSI)

많은 웹 서버가 서버사이트 인클루드도 지원한다. 이는, 서버가 리소스의 콘텐츠를 클라이언트에게 보내기 전에 처리하는 것을 의미한다.

 

서버는 콘텐츠에 변수 이름이나 내장된 스크립트가 될 수 있는 어떤 특별한 패턴이 있는지 검사를 받는다. 이것은 동적 콘텐츠를 만드는 쉬운 방법이다.

 

5.7.5 접근 제어

접근 제어되는 리소스에 대한 요청이 도착됐을 때, 웹 서버는 클라이언트의 IP 주소에 근거하여 접근을 제어하거나 혹은 리소스에 접근하기 위한 비밀번호를 물어볼 수도 있다.

 

5.8 단계 5: 응답 만들기

한 번 서버가 리소스를 식별하면, 서버는 응답 메시지를 반환한다. 응답 메시지는 응답 상태코드, 응답 헤더, 응답 본문을 포함한다고 이야기한 바 있다.

 

5.8.1 응답 엔터티

만약 트랜잭션이 응답 본문을 생성한다면, 본문은 아래를 포함한다.

 

응답 본문의 MIME (Muti purpose Internet Mail Extensions) 타입을 서술하는 Content-Type 헤더

응답 본문의 길이를 서술하는 Content-Length 헤더

실제 응답 본문의 내용

5.8.2 MIME 타입 결정하기

웹 서버에게는 응답 본문의 MIME 타입을 결정해야 하는 책임이 있다.

 

mime.types

웹 서버는 MIME 타입을 나타내기 위해서 파일 이름의 확장자를 사용할 수 있다. 웹 서버는 확장자별 MIME 타입이 담겨있는 파일을 탐색한다.

 

매직 타이핑 (Magic typing)

파일의 내용을 검사하여 알려진 패턴에 대한 테이블에 해당하는 패턴이 있는지를 찾는다. 느리지만 표준 확장자가 없는 경우에 유용하다.

 

유형 명시 (Explicit typing)

특정 파일이나 디렉터리 안의 파일들이 파일 확장자나 내용에 관계 없이 어떤 MIME 타입을 갖도록 웹 서버를 설정할 수 있다.

 

유형 협상 (Type negotiation)

어떤 웹 서버는 한 리소스가 여러 종류의 문서 형식에 속하도록 설정할 수 있다. 이 때 웹 서버가 사용자와의 협상 과정을 통해 파일 형식을 직접 결정할 수 있게 설정할 수도 있다.

 

5.8.3 리다이렉션

웹 서버는 종종 성공 메시지 대신에 리다이렉션 응답을 반환하기도 한다. 웹 서버는 요청을 수행하기 위해 브라우저가 다른 곳에 가도록 리다이렉트할 수 있다.

 

Location 응답 헤더에서는 콘텐츠의 새로운 혹은 선호하는 위치에 대한 URI를 포함한다.

 

영구히 리소스가 옮겨진 경우

리소스는 새 URL이 부여되어 새로운 위치로 옮겨졌거나 이름이 바뀌었을 수 있다. 이 때 웹 서버는 클라이언트에게 리소스의 이름이 바뀌었으므로, 북마크를 갱신하라고 말해줄 수 있다.

 

301 Moved Permanently 상태 코드는 이런 종류의 리다이렉트를 위해 사용된다.

 

임시로 리소스가 옮겨진 경우

만약 리소스가 임시로 옮겨지거나 이름이 변경된 경우, 서버는 클라이언트를 새 위치로 리다이렉트하길 원할 것이다. 하지만 다시 원래 URL로 바꿀 것이기 때문에 북마크를 갱신하질 원하지는 않는다.

 

이 경우에는 303 See Other와 307 Temporary Redirect 상태 코드를 쓴다.

 

URL 증강

서버는 종종 문맥 정보를 포함시키기 위해 재 작성된 URL로 리다이렉트한다. 요청이 도착했을 때, 서버는 상태 정보를 내포한 새 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장

프락시

• 클라이언트와 서버 사이에 위치하여 그들 사이의 http 메시지를 정리하는 중개인처럼 동작

 

https://kscodebase.tistory.com/304?category=1154654

6.1 웹 중개자

프락시는 클라이언트 사이에서 서버와의 트랜잭션을 중개하는 역할을 한다. 프락시가 없으면 클라이언트는 서버와 직접 소통해야 한다.

 

트랜잭션을 완료하는 것이 클라이언트라는 점은 변하지 않지만, 프락시 서버가 제공하는 서비스를 이용하게 된다.

 

HTTP 프락시 서버는 서버이자 클라이언트다. 따라서 두 역할을 모두 수행할 수 있어야 한다.

 

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

공용 프락시

대부분의 프락시는 공유 프락시이다. 이는 여러 클라이언트가 쓸 수 있다는 뜻이다.

 

개인 프락시

흔하지 않지만, 하나의 클라이언트를 위해 사용되는 프락시이다.

 

6.1.2 프락시 대 게이트웨이

엄밀하게 말하면 프락시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결하고, 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다. 게이트웨이는 클라이언트와 서버 사이에서 프로토콜 변환기로 동작하는 셈이다.

 

6.2 왜 프락시를 사용하는가

프락시 서버는 보안을 개선하고 성능을 높여주며 비용을 절약하는 등 여러 목적을 수행한다. 프락시 서버는 모든 HTTP 트래픽을 들여다보고 건드릴 수 있기 때문에 감시 및 수정의 용도로도 사용한다.

 

어린이 필터 : 성인 콘텐츠를 차단하는 것도 필터링 목적의 프락시로 해결한다.

문서 접근 제어자 : 서버와 리소스에 대한 단일한 접근 제어 전략을 구현하고 감사 추적을 하기 위해 사용될 수 있다.

보안 방화벽 : 보안을 목적으로 만든 프락시이다.

웹 캐시 : 인기 있는 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청을 빠르게 처리해준다. 원 서버의 캐시를 가진 프락시가, 요청을 도중에 처리해주는 역할을 한다.

대리 프락시 : 이전에, 어떤 프락시들은 웹 서버인 것처럼 위장한다고 했는데, 이는 대리 프락시를 의미한다. 대리 프락시는 요청을 받으면 그 요청이 가리키는 대상을 찾기 위해서, 다른 서버들과 커뮤니케이션을 시작한다. 대리 프락시는 웹 서버의 성능을 개선하기 위해 사용될 수 있다. 따라서 서버 가속기라고도 한다.

콘텐츠 라우터 : 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹서버로 유도한다.

트랜스 코더 : 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정한다. 이를 트랜스 코딩이라고 한다. 예컨대 자신을 거쳐 가는 GIF 이미지를 JPG 이미지로 변환하는 것 등을 말한다. 또는 기기 (Ex. 컴퓨터에서 모바일로) 간에 적합한 형태로 파일을 변환하기도 한다.

익명화 프락시 : 개인정보와 익명성 보장을 위해 신원을 특별할 수 있는 특성을 제거한다.

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

어떻게 프락시가 네트워크에 배치되는가?

어떻게 프락시의 연쇄가 계층을 이루는가?

6.3.1 프락시 서버 배치

어떻게 사용할지에 따라서 프락시는 어디에든 배치될 수 있다.

 

출구 프락시 : (출구라 하여 오해가 생길 수 있으나) 로컬 네트워크의 출구에서, 요청을 통제한다.

접근(입구) 프락시 : 인터넷 대역폭 비용을 줄이기 위해 캐시 프락시를 사용해 많이 찾는 문서들의 사본을 저장한다.

대리 프락시

네트워크 교환 프락시 : 트래픽 흐름을 감시하기 위해 네트워크 사이의 인터넷 피어링 교환지점에 놓이는 프락시.

출구와 입구라는 말 때문에 많이 헷갈릴 수 있는데, 사실 프락시의 위치가 클라이언트와 서버 사이에 있음을 감안한다면, 결국 출구 입구 모두 위치가 엇비슷한 자리일 것이다.

 

그럼에도 출구와 입구라는 표현으로 나눈 이유는, 프락시를 기준으로 하여 클라이언트와 서버 사이의 요청을 나눌 수 있기 때문이다.

 

클라이언트에서 프락시로 가는 것, 즉 출구 쪽에서 요청을 통제한다. 많은 비용이 나오지 않게 통제한다는 예시를 생각하면 이해가 빠를 것이다.

 

이번에는 프락시에서 서버로 가는 것, 이 역시도 결국 출구 프락시와 위치는 같겠지만, 이 경우를 입구 프락시라고 하며 캐시 프락시를 생각하면 된다.

 

6.3.2 프락시 계층

여러 프락시들이 연쇄적으로 있는 계층. 프락시 서버들이 부모와 자식의 관계를 지닌다. 인바운드 프락시를 부모, 아웃바운드 프락시를 자식이라고 한다.

 

프락시 계층 콘텐츠 라우팅

동적 부모 선택 : 프락시 계층의 프락시들은 반드시 정적인 것이 아니다. 필요에 따라 자유롭게 이동하며, 서버나 클라이언트로 바로 접근할 수도 있다.

부하 균형

지리적 인접성에 근거한 라우팅

프로토콜/타입 라우팅

유료 서비스 가입자를 위한 라우팅

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

HTTP 트래픽이 프락시로 향하는 길을 찾아내는지 설명할 필요가 있다. 클라이언트 트래픽이 프락시로 가도록 만드는 방법은 4가지가 있다.

 

클라이언트를 수정한다.

브라우저를 포함한 많은 웹 클라이언트들은 수동 및 자동 프락시 설정을 지원한다.

HTTP 요청을 의도적으로 원 서버가 아닌 프락시로 가게 한다.

네트워크를 수정한다.

클라이언트가 인지하지 못하는 상태에서, 네트워크 인프라를 가로채서 조정한다.

인터셉트 프락시라고 부른다.

DNS 이름공간을 수정한다.

웹 서버를 수정한다.

클라이언트를 수정하는 것은, 클라이언트로부터 프락시로 가게끔, 에이전트가 이미 설정되어 있는 경우를 의미한다. 다이렉트 연결인 셈이다. (내 임의의 표현이다.)

 

또는 라우터를 통해 가로채거나, 대리 프락시를 거치거나, 서버에 도착한 다음에 프락시로 가는 등 여러 가지 방법이 있다.

 

6.4 클라이언트 프락시 설정

수동 설정 : 프락시를 사용하겠다고 명시적으로 설정한다.

브라우저 기본 설정 : 배포자는 브라우저를 소비자에게 전달하기 전에 프락시를 미리 설정할 수 있다.

프락시 자동 설정 : 자바스크립트 프락시 자동설정 (PAC) 파일에 대한 URI를 제공할 수 있다. 클라이언트는 프락시의 필요성과, 어떤 프락시를 선택할지에 대해 판단하기 위해 해당 자바스크립트 파일을 실행한다.

WPAD 프락시 발견 : 대부분 브라우저는 자동설정 파일을 다운받을 수 있는, 프락시 자동발견 프로토콜을 제공한다.

6.4.1 클라이언트 프락시 설정 : 수동

생략한다.

 

6.4.2 클라이언트 프락시 설정 : PAC 파일

수동 프락시 설정은 유연하지 못하다. PAC 파일은 자바스크립트를 이용한 동적 설정이기 때문에 더 자유롭다.

 

6.4.3 클라이언트 프락시 설정 : WPAD

WPAD는 여러 발견 메커니즘들의 상승 전략으로 브라우저에게 알맞는 PAC를 찾아준다.

 

PAC URI를 찾기 위해 WPAD를 사용한다.

주어진 URI에서 PAC 파일을 가져온다.

프락시 서버를 알아내기 위해 PAC 파일을 실행한다.

알아낸 프락시 서버를 이용해서 요청을 처리한다.

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

프락시 요청의 URI는 서버 요청과 어떻게 다른가

인터셉트 프락시와 리버스 프락시는 어떻게 서버 호스트 정보를 알아내기 어렵게 만드는가.

URI 수정 규칙

프락시는 브라우저의 URI 자동완성이나 호스트 명 확장 기능에 어떤 영향을 주는가?

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

서버는 부분 URI이 아니라, 프락시를 위해 전체 URI을 다룰 필요가 있다는 내용.

 

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

명시적인 프락시는 요청 메시지가 완전한 URI 를 갖도록 함으로써 문제를 해결. 가상으로 호스팅 되는 웹 서버는 호스트와 포트에 대한 정보가 담겨 있는 Host 헤더를 요구한다.

 

6.5.3인터셉트 프락시는 부분 URL을 받는다

클라이언트는 자신이 프락시와 대화하고 있음을 항상 알고있는 것은 아니다.

 

몇몇 프락시는 클라이언트에게 보이지 않기 때문에 클라이언트가 프락시를 사용한다고 설정되어 있지 않더라도 여전히 대리 혹은 인터셉트 프락시를 지날 수 있다.

 

클라이언트는 자신이 웹 서버와 대화하고 있다고 생각하고 완전한 URI를 보내지 않을 수도 있다.

 

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

트래픽이 프락시 서버로 리다이렉트 될 수 있는 여러 가지 방법이 존재하기 때문에, 다목적 프락시 서버는 요청 메시지의 완전한 URI 와 부분 URI을 모두 지원해야 합니다

 

6.5.5 전송 중 URI 변경

요청 URI의 변경에 매우 신경을 써야한다. 사소한 URI 변경이라도 다운스트림 서버와 상호운용성 문제를 일으킬 수 있다.

 

프락시들은 절대로, 경찰처럼 행동해서는 안 된다. 있는 그대로 받아서 그대로 돌려주는 것을 원칙으로 한다. 중간에 수정을 해서는 안 된다.

 

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

브라우저는 프락시의 존재 여부 에 따라 요청 URI를 다르게 분석한다. 프락시가 없다면 사용자가 타이핑한 URI를 가지고 그에 대응하는 IP 주소를 찾는다.

 

6.5.7 프락시 없는 URI 분석 (URI Resolution)

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

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

6.6. 메세지 추적

오늘 날에는 웹 요청이 둘 이상의 프락시를 지나서 도착하는 경우가 드물지 않다. 예를 들어 많은 회사들이 보안과 비용 절감을 위해 캐시 프락시를 사용한다.

 

캐시 프락시는, 요청의 결과 값에 관한 것을 미리 캐시해두어, 해당하는 정보가 있을 경우 서버에 요청을 보내지 않고 프락시가 임의로 처리하는 것이다.

 

그런데 이런 캐시 프락시, 각자 다른 벤더(재화와 용역을 제공하는 회사)들에 의해 개발되고 점점 흔해지면서 서로 다른 스위치, 라우터를 넘나드는 것도 흔한 일이 되었다.

 

따라서 프락시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것도 필요한 일이 되었다.

 

6.6.1 Via 헤더

가장 간단한 방법은 메세지의 헤더에 계속해서 경로를 저장하는 것이다. Via 헤더는 자신이 거친 노드를 항상 목록 끝에 추가한다. Via 헤더에 값이 2개면 2개를 거쳤다는 뜻이다.

 

여기서 이 2개는, 클라이언트와 서버를 제하고 중간에 거친 프락시들을 의미한다. 이렇게 관측된 결과는 메시지 발송자들의 프로토콜 능력을 알아보기 위해 사용된다.

 

서버 : 클라이언트에게 정보를 주려면 프로토콜을 낮은 버전으로 써야 겠군.

 

또한 프락시는 네트워크 라우팅 루프를 탐지하기 위해 Via 헤더를 사용할 수 있다. 라우팅 루프란 동일한 경로를 반복적으로 순회하는 것을 말한다.

 

Via 문법

Via 헤더 필드는 쉼표로 구분된 경유지(waypoint)의 목록이다. 경유지는 프락시 서버나 게이트웨이 홉을 나타내며, 프로토콜과 주소의 정보를 가진다.

 

Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com Via는 "Via" ":" (waypoint) [", " (waypoint) ...]의 형태이며, waypoint는 다시 ( received-protocol received-by [ comment ] )의 형태를 지닌다. received-protocol = [ protoco-name "/"] protocol-version received-by = ( host [ ":" port ] ) | pseudonym

 

각 Via waypoint는 프로토콜 이름 (선택, 기본 값은 HTTP), 프로토콜 버전 (필수), 노드 이름(필수), 코멘트(선택)의 최대 4개의 구성 요소를 담을 수 있다.

 

프로토콜 이름

만약 프로토콜이 HTTP 라면 생략할 수 있다. 프로토콜 이름은 버전 앞에 "/"로 구분되어 붙는다. 비 HTTP 프로토콜은 게이트웨이가 다른 프로토콜을 위해 HTTP 요청에 접속할 때 발생할 수도 있다.

 

프로토콜 버전

수신한 메시지의 버전. 버전의 포맷은 프로토콜에 달려 있다. 버전은 Via 필드에 포함되므로 애플리케이션들은 자신 이전의 모든 중개자들이 어떤 버전을 다룰 수 있는지 알 수 있다.

 

노드 이름

중개자의 호스트와 포트 번호. 만약 포트 번호가 포함되지 않는다면 프로토콜의 기본 포트라고 간주할 수 있다.

 

몇몇 조직은 정보 보호를 이유로 진짜 호스트 명을 밝히고 싶지 않을 수도 있는데, 그러한 경우에 가명으로 대체할 수 있다.

 

노드 코멘트

중개자 노드를 서술하는 선택적인 코멘트. 벤더나 버전 정보를 여기에 포함시키는 것은 흔한 일이며, 몇몇 프락시는 장치에서 일어난 이벤트의 진단 정보를 포함시키기도 한다.

 

Via 요청과 응답 경로

요청 메시지와 응답 메시지 모두 프락시를 지나므로 둘 모두 Via 헤더를 가진다. 요청과 응답은 보통 같은 TCP 커넥션을 오가는데, 응답 메시지는 요청과 같은 경로로 돌아간다.

 

만약 요청 메시지가 A,B,C의 프락시를 거쳤다면 응답은 그 반대로, C,B,A의 경로를 지난다. 응답의 Via 헤더는 즉, 항상 요청의 반대라고 할 수 있다.

 

Via와 게이트웨이

몇몇 프락시는 서버에게 비 HTTP 프로토콜을 사용할 수 있도록 하는 게이트웨이 기능을 제공한다. Via 헤더는 이러한 프로토콜 변환을 기록한다.

 

따라서 HTTP 애플리케이션은 프락시 연쇄에서 프로토콜 능력과 변환이 있는지 알 수 있다.

 

Server 헤더와 Via 헤더

Server 응답 헤더 필드는 원 서버에 의해 사용되는 소프트웨어를 알려준다. 예를 들면 다음과 같다.

 

Server: Apache/1.3.14 (Unix) PHP/4.0.4 Server: Netscape-Enterprise/4.1 Server: Microsoft-IIS/5.0

 

Via가 개인정보 보호와 보안에 미치는 영향

Via 문자열 안에 정확한 호스트 명이 들어가지를 원하지 않는 경우가 있다. 명시적으로 Via를 실행하지 않는 경우에는, 절대 동작해서는 안된다.

 

프락시 서버가 네트워크 방화벽의 일부인 경우에, 프락시는 방화벽 뒤에 있는 호스트의 이름과 포트를 전달할 수도 있다. 이는 악의적인 이용을 허용한다.

 

만약 Via 노드의 이름 전달이 가능하지 않다면, 보안 경계선의 일부분인 프락시는, 호스트 명을 적절한 가명으로 교체해야 한다. 또한 실제 이름이 아니더라도 Via는 그걸 옮긴다.

 

6.6.2 TRACE 메서드

프락시 서버는 메시지가 전달될 때 메시지를 바꿀 수 있다. 헤더가 추가되거나 변경되거나 삭제될 수도 있으며 본문이 다른 형식으로 변환될 수도 있다.

 

프락시가 복잡해지고 더 많은 벤더가 프락시 제품을 배치하면서, 상호 운용성 문제가 증가한다. 프락시 네트워크를 더 쉽게 진단하기 위해 우리는 홉에서 홉으로 전달될 때마다 메시지의 내용이 어떻게 변하는지 더 쉽게 관찰할 방법이 필요하다.

 

HTTP/1.1의 TRACE 메서드는 요청 메시지를 프락시를 연쇄를 따라가면서 어떤 프락시를 지나가고 메시지가 어떻게 수정되는지를 추적할 수 있게 해준다.

 

TRACE 요청이 목적지 서버에 도착했을 때 서버는 전체 요청 메시지를 HTTP 응답 메시지의 본문에 포함시켜 송신자에게 그대로 돌려준다.

 

Max-Forwards

일반적으로 TRACE 메시지는 중간에 프락시들이 몇 개나 있든 상관하지 않고 목적지 서버로의 모든 경로를 여행한다. 이 때 경로의 수를 제한하는 것이 Max-Forwards 이다.

 

이는 프락시가 루프에 빠지는지를 테스트해보는 데에 용이하다. 만약 TRACE 메서드가 서버에 도착하기 전에 경로 수가 한계에 도달하면 원하는 지점이 아니라고 하더라도

 

HTTP 메시지는 클라이언트에게 돌아간다.

 

6.7 프락시 인증

프락시는 접근 제어 장치로도 사용될 수 있다. HTTP는 사용자가 유효한 접근 권한을 프락시에게 제출하지 않는 한 콘텐츠에 대한 요청을 차단하는 프락시 인증을 정의하고 있다.

 

제한된 콘텐츠에 대한 요청이 들어왔을 때 407 (Proxy Authorization Required) 상태코드와, 어떻게 권한을 제출할 수 있는지 설명하는 Proxy-Authenticate 헤더를 반환한다.

클라이언트는 407 응답을 받게 되면, 요구되는 자격을 수집해야 한다.

자격을 수집하면, 클라이언트는 해당 자격을 다시 Proxy-Authorization에 담아서 다시 요청을 보낸다.

자격이 유효하면 통과, 유효하지 않으면 다시 407 응답을 보낸다.

프락시 인증은, 인증에 참여하는 프락시가 프락시 연쇄 상에 여러 개 있을 때에는 잘 동작하지 않는다.

 

6.8 프락시 상호 운용성

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

 

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

프락시 서버는 넘어오는 헤더 필드들을 모두 이해하지 못할 수도 있다. 몇몇 헤더는 프락시 자신보다도 더 최신 버전일 수도 있다. 또 커스텀 헤더일 수도 있다.

 

프락시는 자신이 이해할 수 없다고 하더라도 모든 헤더를 그대로 전달해야 하며, 같은 이름의 헤더 필드가 여러 개인 경우, 상대적인 순서도 반드시 유지해야 한다.

 

6.8.2 OPTIONS: 어떤 기능을 지원하는지 알아보기

HTTP OPTIONS 메서드는 서버나 웹 서버의 특정 리소스가 어떤 기능을 지원하는지, 클라이언트가 알아볼 수 있게 해준다.

 

서로 다른 기능 수준의 서버와 프락시가 더 쉽게 상호작용할 수 있도록, 클라이언트는 OPTIONS를 이용해 서버의 능력을 먼저 알아낼 수 있다.

 

만약 OPTIONS 요청의 URI에 별표(*)이라면, 요청은 서버 전체의 능력에 대해 묻는 것이 된다.

 

만약 URI가 실제 리소스라면, OPTIONS는 특정 리소스에 대해 가능한 기능들을 묻는 것이 된다.

 

6.8.3 Allow 헤더

Allow 엔터티 헤더 필드는, 요청 URI에 의해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하는 모든 메서드를 열거한다.

 

allow : get, post, delete