프록시

드디어 프록시를 배운다.
프록시는 중재자다.

이 장에서는 프락시 기능에 대한 특별한 지원, 그리고 프락시 서버를 사용할 때 보게 될 몇 가지 교묘한 동작을 포함하여
HTTP 프락시 서버의 모든 것에 대해 이야기 한다고 한다.

다음과 같은 것을 학습한다고 한다.

 - HTTP 프락시와 웹 게이트웨이를 비교하고 HTTP 프락시가 어떻게 배치되는지 그림으로 보여주면서 설명한다.
 - 몇 가지 유용한 활용방법을 보여준다.
 - 프락시가 실제 네트워크에 어떻게 배치되어 있는지 그리고 트래픽이 어떻게 프락시 서버에 가게 되는지 설명한다.
 - 브라우저에서 프락시를 사용하려면 어떻게 설정해야 하는지 보여준다.
 - HTTP 프락시 요청이 서버 요청과 어떻게 다른지, 그리고 프락시가 어떻게 브라우저의 동작을 미묘하게 바꾸는지 보여준다.
 - 일련의 프락시 서버들을 통과하는 메시지의 경로 Via 헤더와 TRACE 메서드를 이용해 기록하는 방법을 설명한다.
 - 프락시에 기반한 HTTP 접근 제어를 설명한다.
 - 어떻게 프락시가 클라이언트와 서버 사이에서 각각의 다른 기능과 버전 들을 지원하면서 상호작용 할 수 있는지 설명한다.

웹 중재자

웹 프락시 서버는 클라이언트 입장에서 트랜잭션을 수행하는 중개인이다.
만약, 프락시 서버가 없다면 클라이언트는 직접 HTTP 서버와 직접 대화를 해야한다.
고귀하신 클라이언트는 HTTP 서버와 직접 대화하는 것을 원치 않아하신다.
그래서 대신 대화 해줄 신하를 뒀는데 그것이 웹 프락시 서버다.
그러니까 서버에 대한 이야기를 잘 정리해서 클라이언트에게 전달하는 것이 프락시의 역할이다.

개인 프락시와 공유 프락시

프락시를 공동으로 사용하면 공유  프락시 
혼자 쓰면 개인 프락시라고 부른다.

공용 프락시

마치 공유 오피스와 같은 느낌이다.

캐시 프락시 서버와 같은 몇몇 프락시 애플리케이션은 프락시를
이용하는 사용자가 많을수록 유리하다.
공통된 요청에서 이득을 취할 수 있으니까.
다만, 중앙 집중형 프락시를 관리하다면, 비용효율이 높다고 한다.

개인 프락시

혼자쓰면 개인 프락시
흔하지는 않지만 꾸준히 사용되고 있다고 한다.
특히 클라이언트 컴퓨터에서 직접 실행되는 형태로...

프락시 대 게이트웨이

생각해보면 게이트웨이도 프락시와 비슷한 역할을 합니다.
그러니까 서버와 브라우저의 소통을 도와주는 역할을 한다는 뜻이죠.
그럼 뭐가 다를까?

다른 점은 게이트웨이 같은경우 프로토콜을 변환해주는 역할을 한다고 한다.
HTTP을 요청받았는데 그것을 게이트웨이가 받아서 POP로 변환시켜줘서 메일 서버로 보낸다.

사실 프록시와 게이트웨이의 경계는 굉장히 모호하다고 한다.
프락시도 때때로 프로토콜을 변환하기도 한다고 한다.
뭔지는 잘 모르겠지만...
게이트웨이도 추후에 학습하니 두고보자.

 왜 프락시를 사용하는가?

프락시 서버는 보안을 개선하고, 성능을 높여주며, 비용을 절약한다.
프락시 서버는 모든 HTTP 트래픽을 들여다보고 건드릴 수 있기 때문에, 
프락시는 부가적인 가치를 주는 여러 유용한 웹 서비스를 구현하기 위해 트래픽을 감시하고 수정 할 수 있다.

그러니까 프락시를 사용하는 이유는
추가적인 기능을 추가하기 위함이라 생각이 든다.

다음은 프락시가 가지고 있는 추가적인 기능들에 대해 살펴보자.
아마 커스텀한 기능도 만들 수도 있을 것 같다.(아마도.. 가능하지 않을까...)

어린이 필터

말 그대로 어린이 필터다.

우리 주변에서 볼 수 있는 최고의 예시는
바로 위 사진이라 생각한다.
부모는 어린 자식이 성인물이나 게임에 노출되지 않기 위해 위와 같은 기능을 설정해 둔다.
아니면 학교에서 웹툰같은 것을 보지 않게 한다던지...

잘못하면 이렇게 될 수 도 있다. 

알고 보니 위 기능이 프락시에서 하는 기능이라고 한다.
아무튼 이것을 사용하게 되면 특정 사이트의 접근을 강제로 거부할 수 있다.
몇몇 회사들에서는 악성 콘텐츠를 식별하는 필터링을 제공하고 블랙리스트를 관리한다고 한다.

문서 접근 제어자

프락시 서버는 많은 웹 서버들과 웹 리소스에 대한 단일한 접근 제어 전략을 구현하고 감사 추적하기 위해 사용할 수 있다.
대기업 환경이나 분산된...
이것도 이름그대로 이해하는 것이 제일 편한데..
대기업이라면 조직이 굉장히 많을 거라 예상한다.
따라서 각각의 조직에는 문서들이 굉장히 많을 거다.
그렇다는 소리는 그 문서가 다른 부서가 보면 안 되는 문서일 수도 있다.
그러면 그 문서를 보기 위해서는 특정한 비밀번호를 입력한다던지, 아니면 네트워크상에서 막는 여러 행위들을 해야 할 것이다.

책에서는 다음과 같이 이야기한다.
각기 다른 조직에서 관리되는 다양한 종류의 수많은 웹 서버들에 대한 접근제어를 수시로 갱신할 필요없이,
중앙 프락시 서버에서 접근 제어를 설정할 수 있다.

중앙화된 접근 제어 프락시는 다음과 같은 일을 한다.
- 클라이언트1에게 제약 없이 서버의 뉴스 페이지를 접근할 수 있도록 허락해준다.
- 클라이언트2에게 제약 없이 인터넷 콘텐츠에 접근할 수 있는 권한을 준다.
- 클라리언트3에게 서버 B에 접근하기 전에 먼저 비밀번호를 요구한다.

이렇게 하는 이유는 감사 추적때문이라고 한다.
위에서 내가 설명한것은 3번째에 해당되는 이야기인것 같구
어떻게 보면 어린이 필터의 강화버전 같은 느낌이 든다.  

보안 방화벽

프락시 서버는 조직안에 들어오거나 나가는 응용 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제한다.
참고로 응용 레벨은 OSI 7 Layer의 마지막으로 대표적으로 HTTP가 포함되어있다.

방화벽이라 바이러스도 제거하구...
후크? 트랙픽을 세심이 살펴보는? 

후킹 - 위키백과, 우리 모두의 백과사전

후킹(영어: hooking)은 소프트웨어 공학 용어로, 운영 체제나 응용 소프트웨어 등의 각종 컴퓨터 프로그램에서 소프트웨어 구성 요소 간에 발생하는 함수 호출, 메시지, 이벤트 등을 중간에서 바꾸거나 가로채는 명령, 방법, 기술이나 행위를 말한다. 

이런것으로 봤을때 위해 중간에서 트래픽을 확인하는 느낌으로 이해된다. 

웹 캐시

프락시 캐시는 인기 있는 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오면 빠르게 제공하여, 느리고 비싼 인터넷 커뮤니케이션을 
줄인다.

그러니까 중앙에서 보다 빠르게 접근하게 도와주는 역할을 한다.

그림을 보면 클라이언트와 웹 서버의 거리만 봤을때는 오른쪽에 존재하는 클라이언트의 길이가 더 길지만,
중간에 웹 캐싱 프락시가 존재하기 때문에 보다 빠르게 접근이 가능해졌다.

대리 프락시

프락시 자체도 대리자(중재자)라는 말인데
그러면 대리 대리자인가...
리버스 프락시라고도 말한다고 한다.
느린 웹 서버를 개선하기 위해 서버 가속기라는 말을 사용기도 한다.
진짜 웹 서버 요청을 받지만, 웹 서버와 달리 요청 받은 콘텐츠의 위치를 찾아내기 위해 다른 서버와 커뮤니케이션을 한다.
라고 했을 때,
대리 프락시는 직접 소통을 하는 굉장히 적극적인 프락시라 생각한다.

콘텐츠 라우터

프락시 서버는 인터넷 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도하는 콘텐츠 라우터로 동작 할 수 있다.
콘텐츠 라우터는 사용자들에게 제공할 여러 서비스를 구현하는데 사용할 수 있다.
예를 들면, 돈을 지불하면 웹 캐시 프락시를 이용해서 조금더 빠르게 이용할 수 있다는등 여러가지를 할 수 있다.

트랜스코더

코더 바꾼다?
프락시 서버는 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정할 수 있다.
그러니까 한글로된 문서인데 이걸 이용하면 영어로 바꿔준다 뭐 그런것 같다.
표현 방식을 자연스럽게 변환하는 것을 트랜스코딩이라고 부른다.

익명화 프락시

익명화 프락시는 HTTP메시지에서 신원을 식별할 수 있는 특성들을 과감히 제거함으로써 개인 정보와 익명성 보장에 기여한다.
예를 들면,
 - User-Agent 헤더에서 사용자의 컴퓨터와 OS종류를 제거한다.
 - 사용자의 이메일 주소를 보호하기 위해 From 헤더는 제거한다.
 - 어떤 사이트를 거쳐서 방문했는지 알기 어렵게 하기 위해 Refer 헤더는 제거된다.
 - 프로필과 신원 정보를 없애기 위해 Cookie 헤더는 제거된다.

생각보다 프락시는 다양한 역할을 하는 것같다.

프락시는 어디에 있는가?

프락시가 뭔지는 알겠는데...
문제는 프락시가 어디에 있고 언제 아키텍처상에 배치될까?
다음 내용을 학습한다고 한다.
 - 어떻게 프락시가 네트워크에 배치되는가?
 - 어떻게 프락시의 연쇄가 계층을 이루는가?
 - 어떻게 트래픽이 올바르게 프락시를 찾아가는가?

프락시 서버 배치

어떻게 사용할지에 따라서 프락시는 어디에든 배치가 가능하다.
프락시 서버가 배치 될 수 있는 몇 가지 방법을 알아 보자.

출구(Egress) 프락시

출구? 약간 느낌이 마지막에 등장하는 듯한 느낌을 준다.
근데 여기서 입구와 출구는 무엇을 뜻할까?
바로 로컬 네트워크를 기준으로 입구와 출구가 결정이 된다.
어찌되었든 
로컬 네트워크가 기준이 된다는 느낌이 든다.

그림에 보는거와 같이 로컬 네트워크의 출구에 프락시에 놓을 수 있는데
이것은 로컬 네트워크에서 처리한 결과들을 인터넷으로 넘어갈때 막거나 변형시키는 것이 가능하다.
예를 들어,
1. 회사 밖의 악의적인 해커들을 막는 방화벽을 제공할 수 있다.
2. 인터넷 트래픽의 성능을 개선하기 위해 회사에서 출구 프락시를 사용할 수 있다.
3. 부적절한 콘텐츠를 브라우징하는 것을 막기 위해 사용한다.

그럼 여기서 의문인게 그러면 로컬 네트워크에서 처리하면 되지 왜 프락시를 사용하냐고 물어볼수 있다.
위에 작성되었있지만, 다시 한번더 설명하면,
로컬 네트워크쪽에 설정할 수 도 있겠지만, 그렇게 되면 로컬 네트워크는 또 다른 일들을 하게 될것이다.
더욱이 기능이 또 추가된다면, 로컬 네트워크쪽을 지속적으로 수정해야 된다.
그러면 의도치 않는 문제가 발생할지도 모른다.
위와 같은 이유들 때문에, 프락시를 만드는것이 유리하다.
만약, 해당 기능이 필요없으면 프락시를 없애면 된다.

접근(입구) 프락시

고객으로부터의 모든 요청을 종합적으로 처리하기 위해 프락시는 ISP 접근 지점에 위치하기도 한다.
ISP ?

인터넷 서비스 제공자 - 위키백과, 우리 모두의 백과사전

ISP는 인터넷 서비스 제공자라는 뜻이라고 한다.
결국 이것의 목적은 고객의 편리성을 제공하기 위해 사용이 되어진다.

이것은 다음과 같은 곳에서 사용된다고 한다.
1. 사용자들의 다운로드 속도를 개선한다.
2. 인터넷 대역폭 비용을 줄이기 위해 캐시 프락시를 사용해 많이 찾는 문서들을 사본으로 저장한다.

대리 프락시

한글로 하면 대리 대리자. 그래서 리버스 프락시로 부르기로 했어요.
근데 이거 위해서 한것 같은데 기분 탓인가...
이곳에서 리버스 프락시는 어디에 설치되는 관점에 대해 고민해보자. 
리버스 프락시는 네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치하여 웹 서버로 향하는
모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청 할 수 있다.

그림으로 보면
클라이언트가 바로 인터넷이 연결 되있고 그 다음에 프락시가 있는 것으로 봐서
클라이언트의 동작이 인터넷에 영향을 주고
그것을 프락시가 처리하는 것 같다. 

이것은 다음과 같은 곳에서 사용된다고 한다.
1. 웹 서버에 보안 기능을 추가하거나 빠른 웹 서버 캐시를 느린 웹 서버의 앞에 놓음으로써 성능 개선

네트워크 교환 프락시

캐시를 이용해 인터넷 교차로의 혼잡을 완화하고 트래픽 흐름을 감시하기 위해 사용되어진다.
책이 2002년도에 만들어졌다.

프락시 계층

프락시는 연쇄적으로 구성할 수 있다.
프락시 계층에서, 메시지는 최종적으로 원 서버에 도착할 때까지 프락시와 프락시를 거쳐 이동한다.
인 바운드 프락시 : 서버와 가까운 쪽 => 부모라 부르고
아웃 바운드 프락시 : 클라이언트와 가까운 쪽 => 자식이라 부른다.

내가 기억하기로는
인 바운드는 클 -> 서버이구
아웃 바운드는 서버 -> 클로 알고 있다.

프락시 계층 콘텐츠 라우팅

프락시 서버는 여러 가지 판단 근거에 의해 메시지를 다양하고 유동적인 프락시 서버와 원 서버들의 집합에게 보낼 수 있다.
접근 프락시는 상황에 맞게 부모 프락시나 원 서버에게 라우팅한다.

 - 요청된 객체가 콘텐츠 분산을 위해 돈을 지불한 웹 서버에 속한 경우, 프락시는 요청을 가까운 캐시 서버에게
보내 캐시된 객체를 반환하거나 그럴 수 없을 때는 서버에서 가져온다.
 - 요청이 특정 종류의 이미지에 대한 것인 경우, 접근 프락시는 그 요청을 특화된 압축 프락시에게 보내어
그 프락시가 이미지를 가져와 압축하게 하여 느린 모델으로 접속했더라도 빠르게 클라이언트가 다운로드할 수  있게 한다.

그러니까 2개이상 중에 하나를 선택한다는 거지..

동적 부모 선택의 몇 가지 예는 다음과 같다.

부하 균형
- 부모의 작업량에 따라 부모를 선택한다.

지리적 인접성에 근거한 라우팅
  - 원 서버의 지역을 담당하는 부모를 선택할 수도 있다.

프로토콜/타입 라우팅
  - URL에 근거하여 결정한다.

이 밖에도 유로 서비스 가입자를 위한 라우팅같은 경우도 존재한다.  

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

클라이언트는 보통 웹 서버와 직접 대화하기 때문에, 우리는 먼저 HTTP 트래픽이 프락시로 향하는 길을
찾아내는지 설명할 필요가 있다.
트래픽?

1. 통신망을 통과하는 정보의 흐름. 통신망과 통신 기기를 점유하는 시간으로 그 양을 나타냄.

그러니까 트래픽은 정보의 흐름을 뜻하는데...
보통 클라이언트에서 서버쪽으로 흐르는것이 정상적인 방향이다.
물론, 반대로 될 수 도 있겠지만 그거는 일반적인 경우가 아니라고 생각이 든다.
왜냐하면, 고객이 버튼을 누르던지 아니면, 검색을 하던지 등 여러 행위들은
클라이언트에서 발생한다. 그리고 나서 그 정보들을 서버쪽으로 보낸다. 
결국 서버가 처리가 되는 구조다.
그러면 프락시는?
보통은 클라이언트에서 나온 데이터들을 처리? 조작? 한다.

트래픽을 제어하는 방법은 총 4가지가 존재하는데,

• 클라이언트를 수정한다.
  • 이 방법이 가장 간단하다고 생각한다.
  • 왜냐하면 단순히 클라이언트를 수정해서 트래픽을 제어하면 되기 때문이다.
  • 책을 읽어보니 클라이언트 => 서버가 아니라 
  • 도중에 클라이언트 => 프락시
  • 로 변경시키는 것을 말한다. 아마 트래픽이 많아지면 이런식으로 제어한다는 거겠지.!
• 네트워크를 수정한다.
  • 이 방법은 클라이언트가 몰라야 할때 사용한다고 한다.
  • 중간에 네트워크 인프라를 가로채서 트래픽을 프락시로 가도록 조정한다고 한다.
  • 이것을 인터셉터 프락시라고 부른다.
  • 또 투명 프락시라고도 불린다.
• DNS 이름공간을 수정한다.
  • 리버스 프락시는 웹 서버 앞에 위치한다.
  • 리버스 프락시가 웹 서버의 이름과 IP주소를 자신이 직접 사용한다.
  • 모든 요청을 서버 대신 리버스 프락시로 가게 된다.
  • DNS 이름 공간을 수정하는 것만으로도 가능하다니.!
• 웹 서버를 수정한다.
  • 몇 몇 웹서버는 HTTP 리다이렉션(305) 명령을 클라이언트에게 
  • 돌려줌으로써 클라이언트 요청을 프락시로 리다이렉트 하도록 설정할 수 있다.
  • 결국은 리다이렉션이 발생이 될때 프락시로 가게 되는거라 생각이든다.

클라이언트 프락시 설정

브라우저가 프락시를 설정 하는 방법
하나만 지원 된다. 왜냐하면 직접 입력하니까.

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

프락시를 사용하겠다고 명시적으로 설정

클라이언트 프락시 설정 : 브라우저 기본 설정(Default)

우리가 사용하기 전에 미리 세팅되어 있다.

클라이언트 프락시 설정 : (Proxy auto-configuration, PAC) 파일

- 자바 스크립트 프락시 자동 설정 파일에 대한 URI를 제공할 수 있다.
- 어떤 프락시를 사용해야 한다면 자바스크립트 파일을 가져와서 실행시킨다.

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

- 자동설정 파일을 다운받을 수  있는 '설정 서버'를 자동으로 찾아주는,
- 웹 프락시 자동발견 프로토콜(Web Proxy Autodiscovery Protocol)을 제공한다.

현재의 WPAD 명세는 다음의 기법 순서대로 정의한다.

• 동적 호스트 발견 규약(DHCP)
• 서비스 위치 규약(SLP)
• DNS 잘 알려진 호스트 명
• DNS SRV 레코드
• DNS TXT 레코드 안의 서비스 URI

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

다음과 같은 것들이 존재한다고 한다.

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

?? : 아니 클라이언트에서 URL를 입력해서 그 정보가 프락시 서버로 들어가는데 어째서 다른거죠?

사실 한가지 예외가 존재한다고 한다.
그것은 클라이언트가 프락시 대신 서버로 요청을 보내면 요청 URL이 달라진다.
클라이언트 =>웹 서버로 요청을 보낼때는

GET /index.html HTTP/1.0
User-Agent: SuperBrowserv1.3

이런식으로 어떤 데이터인지 확인 정도만 하지만
클라이언트가 프락시로 요청을 보낼때는 달라진다고 한다.

GET www.mattttttt.com/index.html HTTP/1.0
User-Agent: SuperBrowserv1.3

이렇게 완전한 URL로 요청을 보낸다고 한다.
아직 책을 보지는 않았지만 유추해보면, 웹 서버는 웹이랑 관련이 있기 때문에 URL전문을 보내지 않아도 알 수 있는데,
프록시는 전혀 모르는 상태이기 때문에 URL을 입력해주는거라 예상해본다.

원래 HTTP 설계에서, 클라이언트는 단일한 웹 서버와 통신을 했다고 한다.
가상 호스팅에 대한 개념도, 프락시도 없었다고 한다.
그래서 단일 서버는 자신의 호스트명과 포트 번호를 알고 있어야 했다.
하지만 도중에 프락시라는 녀석이 들어왔다.
물론, 프락시에도 같은 효과를 부여할수 도 있겠지만, 프락시가 0개일수도 있지만
2개 이상일 수 도 있다. 이 많은 프락시에 전부 단일 서버와 같이 할 수 없다 생각한다.

결국 프락시는 URL전문을 받기로 했다

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

프락시에서 스킴/호스트/포트 번호가 누락되는 문제는 가상으로 호스팅되는 웹 서버가 직면한 문제와 같다고 한다.
가상으로 호스팅되는 웹 서버는 여러 웹 사이트가 같은 물리적 웹 서버를 공유한다.

가상으로 호스팅된다는 것은 다시 말해서 실제 웹 서버가 아니라는 뜻이다.
그러니까 프록시처럼 URL을 미리 아는 능력이 없다는 이야기다.

프록시 같은 경우는 URL을 전문으로 받는 것으로 수정했지만,
가상 호스팅 같은 경우는 호스트와 포트에 대한 정보가 담겨 있는 Host 헤더를 요구한다.

인터셉트 프락시는 부분 URL를 받는다.

이건 또 뭔소리냐..
아까 프락시는 URL전체를 받는다고 하지 않았는가.
그래서
인터셉트 프락시와 리버스 프락시는 어떻게 서버 호스트 정보를 알아내기 더 어렵게 만드는 것 같다.

이는 인터셉트 프락시의 특수한 성질때문인데,
이들은 보이지 않는 프락시로 투명 프락시라고도 불린다. 보이지 않기 때문에 클라이언트 입장에서는 URL전문을 보낼 수 는 없다.
또한, 인터센트 프락시는 도중에 트랙픽을 가로채 캐시되는 응답을 돌려주는 프락시 서버다.
이건 내 생각인데 어차피 돌려주기 때문에 URL전문을 전부 받을 필요는 없다고 생각한다.

이와 더불어 리버스 프락시도 부분URL만 받는다고 한다.
왜냐하면 이들은 웹 서버를 대신하기 때문이다. 

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

트래픽이 프락시 서버로 리다이렉트 될 수 있는 여러 가지 방법이 존재하기 때문에 다목적 프락시 서버는 완전 URL과 부분 URL을
모두 지원해야 한다. 
완전 URL과 부분 URL를 사용하는 규칙은 다음과 같다고 한다.

•  완전 URL이 주어지면 프락시는 그것을 사용해야 한다.
•  부분 URL이 주어졌고, HOST헤더가 있다면, Host헤더를 이용해 원 서버의 이름과 포트 번호를 알아야 한다,
•  부분 URL이 주어졌으나, HOST헤더가 없다면, 다음의 방법으로 알아야한다.
  • 프락시가 원 서버 대신하는 리버스 프락시라면, 프락시에 실제 서버의 주소와 포트번호가 설정되어 있을 수 있다.
  • 이전에 어떤 인터센트 프락시가 가로챘던 트래픽을 받았고, 그 인터센터가 프락시가 원 IP주소와 포트 번호를 사용할 수 있도록 해두었다면, 그 IP주소와 포트번호를 사용할 수 있다.
  • 모두 실패 했다면, 프락시는 원서버를 알아낼 능력이 부족하므로 예외를 던진다. 

작성하면서 느낀건데 이거 다 위에서 본 듯한 내용들 이었다.

전송중 URI 변경

프락시 서버는 요청 URI 변경에 매우 신경써야 한다.
무해해 보이는 사소한 URI 변경이라도 다운스트림 서버와 상호운용성 문제를 일으킬 수 있다.
따라서 사용자가 겉보기에 별 문제가 되지 않는 것 같은 URI일지라도 올바르게 변경시키는 것이 좋다.
HTTP 명세는 일반적인 인터셉트 프락시가 URI가 전달할 때 절대 경로를 고쳐 쓰는 것을 금지한다.
유일한 예외는 빈 경로를 '/'로 교체하는 것 뿐이라고 한다.

메시지 추적

성능상의 이유로 세계 곳곳에 흩어져 있는 대리 캐시 저장소에 콘텐츠를 복제해두는 방식이 점점 더 흔해지고 있다.
프락시는 여러 벤더에 의해 개발된다.
공급사슬에서 벤더(vendor) 또는 셀러(seller)는 재화나 용역을 제공하는 기업이다

그러면 프락시 벤더는 어떤것이 있는지 조사해보자.
다음과 같은 곳들이 존재한다고 한다.
솔직히 다 처음보는 것들이다.

The Best Proxy Server Providers - July 2021 | 99firms

 보니까 조사한지 얼마 지나지 않은 것 같다.

Via 헤더

HTTP 헤더와 같은 위치에 작성이 되어진다.
저번에 여러 HTTP헤더들을 학습했었는데, 이거는 조금더 자세하게 하는 느낌이든다.

 - 메시지가 지나는 각 중간 노드의 정보를 나열한다.
 - 메시지가 또 다른 노드를 지날때 마다, 중간 노드는 Via 목록의 끝에 반드시 추가되어야 한다.
 - 메시지의 전달을 추적하고, 메시지 루프를 진단하고, 요청을 보내고 그에 대한 응답을 돌려주는 과정에 관여하는 모든
    메시지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용된다.

TRACE 메서드

이거는 진단에 관련된 내용인건가...?
저번에 학습했을때 TRACE메서드는 메서드를 진단할때 사용한다고 하는것 같았는데..
요청 메세지를 프락시 연쇄를 따라가면서 어떤 프락시를 지나가고 어떻게 각 프락시가 요청 메시지를
수정하는지 관찰/추적할 수 있도록 해준다.
전에 내가 이렇게 기록했었다.

클라이언트가 어떤 요청을 할 때, 그 요청은 방화벽, 프락시, 게이트 웨이 등의 애플리케이션을 통과할 수 있다.
- 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 보여준다.
- 목적지 서버에서 루프백(loopback) 진단을 시작한다.
TRACE 응답의 엔티티 본문에서는 서버가 받은 요청이 그대로 들어 있다고 합니다.
감히 잡히지 않아서 스프링 부트를 이용해서 돌려봤다.

프락시 상호운용성

클라이언트, 서버, 프락시는 HTTP명세의 여러 버전에 대해 여러 벤더에 의해 만들어진다.
그러면 결국 벤더가 서로 다른 프락시끼리 통신이 되어진다는 이야기인데,
프락시끼리 서로 다른 프로토콜을 구현했을 수 도 있을 뿐더러 다른 벤더에서 만든 프락시가 어떻게 동작하는지 
아는 방법이 없다.

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

그러면 프락시보다 HTTP헤더가 새로운 것일수 도 있다.
그렇다는 이야기는 프락시가 HTTP헤더를 지원을 안한다는 이야기가 된다.
근데 또 통신을 해야 한다.
근데 또 그 HTTP헤더는 지원하지 않는다.

마치 쳇바퀴를 도는듯한 기분이 든다.
어떻게 하면 좋을까?
프락시는 이해할 수 없는 헤더 필드는 반드시 그대로 전달해야 하며, 같은 이름의 헤더 필드가 여러 개 있는 경우에는 그들의 상대적인
순서도 반드시 유지해야 한다고 한다.
만약, 지원하지 않는 메서드들을 통과시킬 수 없는 프락시는 네트워크 환경에서 살아남지 못한다고 한다.
그러면 새로운 HTTP메서드를 만들면 되지 않냐고 할 수 있다.
아쉽게도 HTTP /1.1에서는 메서드를 확장하는 것을 허용하고 있다.
실제로 WebDav라는 프로토콜같이 메서드를 확장하여 사용하는 일이 적지 않게 발생하고 있다고 한다.

Allow 헤더

엔티티 헤더 필드는, 요청 URL에 의해 식별되는 자원에 대해 지원되는 메서드들이나 서버가 지원하는 모든 메서드를 열거한다.
만약, 프락시가 지정된 모든 메서드를 이해할 수 없다고 해도, 프락시는 Allow헤더 필드를 수정할 수 있다고 한다.
왜냐하면 클라이언트는 원 서버와 대화하는 다른 경로를 갖고 있을 수 도 있기 때문이다.