[2부 6장] 프락시

[im-gnar]

6장 프락시

6.1 웹 중개자

HTTP 프락시 서버는 웹 서버이면서 동시에 웹 클라이언트이다.

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

공용 프락시	개인 프락시
- 여러 클라이언트가 함께 사용하는 프락시(일반적) - 캐시 프락시 서버 등은 이용자가 많을 수록 공통된 요청에서 이득을 취할수 있기 때문에 유리	- 하나의 클라이언트만을 위한 프락시 - 사용자의 컴퓨터에서 직접 실행     - 브라우저 기능 확장/성능 개선     - ISP 서비스를 위한 광고 운영

ISP(Internet service provider)

인터넷 서비스 제공자(Internet service provider; ISP)는 인터넷에 접속하는 수단을 제공하는 주체를 가리키는 말이다.
그 주체는 영리를 목적으로 하는 사기업인 경우가 대다수이나 비영리 공동체가 주체인 경우도 있다.

ISP는 일반적으로 인터넷에서 이용 가능한 모든 것에 대한 접근권을 사용자에게 부여하는 액세스 포인트나 게이트웨이 역할을 한다.

• KT, SKT, LG유플러스

6.1.2 프락시 vs 게이트웨이

둘 다 클라이언트와 서버 사이에 대리자 역할을 수행한다.

• 프락시: 같은 프로토콜을 사용하는 애플리케이션 연결
• 게이트웨이: 서로 다른 프로토콜을 사용하는 애플리케이션도 연결 (프로토콜 변환기)

그러나 프락시 서버가 SSL 보안 프로토콜, SOCKS 방화벽, FTP 접근, 웹 어플리케이션 기능도 지원해주면서 게이트웨이 역할도 하게 되며 둘의 차이가 모호해졌다.

ref. API Gateway vs. Reverse Proxy
ref2. What is the difference between a proxy server and a gateway server?)
ref3. API Proxy vs. API Gateway

A gateway is about routing.
When a computer wants to communicate with another computer in a different network, it usually uses the gateway to get out of its own network. Gateways take care of routing data packets between separate networks.
A proxy is about representing another computer(s)/server(s) in a network.
Usually it is done for different purposes like load balancing, caching, access blocking, etc. The client is unaware that it talks to proxy instead of to the actual server (reverse proxy).

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

프락시 서버 : 실질적이고 유용한 것이라면 무슨 일이든 함

보안 개선, 성능 향상, 비용 절약

• 어린이 필터(유해 컨텐츠 필터링)

• 문서 접근 제어자

접근 제어 전략을 구현하고 감사 추적(audit trail)
특정 서버는 정해진 프록시 서버로부터만 요청을 받아들이도록 설정할 수 있다.
(클라이언트는 프록시 서버를 거치지 않으면 접속할 수 없다.)

• 보안 방화벽

조직 안에 들어오는 프로토콜의 흐름을 통제하여 바이러스 등을 차단한다.

• 웹캐시 (CDN 등)
  

인기 있는 문서의 로컬 사본을 관리하여 통신 비용 절감한다.

• 대리(리버스) 프락시
  

진짜 웹 서버 요청을 받지만 웹 서버와는 달리 요청 받은 콘텐츠의 위치를 찾아내기 위해 다른 서버와 커뮤니케이션을 한다.
웹서버 성능 개선, 콘텐츠 라우팅

• 콘텐츠 라우터
  

인터넷 트래픽 조건과 컨텐츠 종류에 따라 요청을 특정 웹서버로 유도(Route)한다.

• 트랜스코더
  

서버가 클라이언트에 전달하기 전에 본문 포맷을 프록시가 수정할 수 있다.
(파일 압축, 확장자 변환, 번역 등)

• 익명화 프락시
  

신원을 식별할 수 있는 IP 주소, From 헤더, Refer 헤더, 쿠키, URI 세션 아이디 등 을 제거, 수정 할 수 있다.

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

6.3.1 프락시 서버 배치

프락시	위치	기능
출구 프락시	로컬 네트워크의 출구	트래픽 제어, 방화벽, 필터링 등
입구 프락시	ISP 접근지점	트래픽 제어, 캐시 프락시
대리 프락시	웹서버 앞	필요할때만 서버로 자원을 요청 가능, 라우팅, 보안
네트워크 교환 프락시	인터넷 피어링 교환 지점	캐시를 이용해 혼잡도 완화, 트래픽 감시

6.3.2. 프락시 계층

프락시는 연쇄적으로 구성될 수 있고, 서버에 가까운 쪽을 부모, 클라이언트에 가까운 쪽을 자식 이라고 부른다.
프록시는 정적으로 라우팅 될 수도 있고, 아래와 같은 근거를 바탕으로 동적으로 될 수도 있다.

• 부하 균형
• 지리적 인접성에 근거
• 프로토콜 / 타입 라우팅
• 유료 서비스 가입자

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

클라이언트 수정	네트워크 수정	DNS 수정	웹서버 수정
수동.자동 설정	인터셉트 프락시	대리 프락시	리다이렉트

6.4 클라이언트 프락시 설정

6.4.1 수동

명시적 설정

Mac에서 설정하기
시스템환경설정 > 네트워크 > 고급 > 프록시

6.4.2 PAC (Proxy Auto Configuration)

javascript 문법으로 된 프락시 설정 파일

• 확장자 : *.pac
• MIME type : application/x-ns-proxy-autoconfig
• FindProxyForUrl(url, host) 필수 구현
• return : DIRECT , PROXY host:port, SOCKS host:port

수동 설정은 하나의 서버만을 지정할 수 있지만, PAC은 상황에 맞게 유연한 설정이 가능하다.

// proxy.pac
function FindProxyForURL(url, host) {

// If the hostname matches, send direct.
	if (dnsDomainIs(host, "intranet.domain.com") ||
		shExpMatch(host, "(*.abcdomain.com|abcdomain.com)"))
		return "DIRECT";

// If the protocol or URL matches, send direct.
	if (url.substring(0, 4)=="ftp:" ||
		shExpMatch(url, "http://abcdomain.com/folder/*"))
		return "DIRECT";

// If the IP address of the local machine is within a defined
// subnet, send to a specific proxy.
	if (isInNet(myIpAddress(), "10.10.5.0", "255.255.255.0"))
		return "PROXY 1.2.3.4:8080";

// DEFAULT RULE: All other traffic, use below proxies, in fail-over order.
	return "PROXY 4.5.6.7:8080; PROXY 7.8.9.10:8080";

}

ref. Proxy Auto-Configuration (PAC) file

6.4.3 WPAD(Web Proxy Auto Discovery)

PAC 파일을 다운받을 수 있는 설정 서버를 자동으로 찾는 기법
WPAD 는 성공할 때 까지 각 기법을 시도

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

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

부분 URI 와 전체 URI

• 서버로 바로 요청할 경우에는 부분 URI 가능 (유추 가능)
• 프록시를 쓰면 어디로 보내야할지 모름. 그래서 전체 URI 명시해야함.
• 근데 1.1부터는 host 헤더에서 뽑아쓰면 됨. 그래서 host 헤더 필수.
• host도 없다면 어떻게든 원서버를 알아냄
  • 대리프락시라면 원서버 주소와 호스트가 설정돼있을수 있다
  • 인터셉트 프록시를 사용한 전력이 있다면 해당 주소 사용가능
• 모두 실패했다면 Host 를 포함핳라는 400 Bad Request

전송 중 URI 변경이 일어날 수 있다

그러나 HTTP 프로토콜에 :80을 명시적으로 붙이는 등의 당연한 일도 치명적인 문제를 야기할 수 있으므로 빈 경로를 /으로 대체하는 것을 제외하고는 안 하는 것이 좋다.

URI 클라 자동확장 & 호스트네임 분석

URI 자동확장은 2장 참고

6.6 메시지 추적

6.6.1 Via 헤더

중간 노드 (프록시나 게이트웨이) 를 지날 때마다 Via 헤더에 중간 노드 정보가 추가된다.
그러므로 일반적으로 요청과 응답은 같은 (순서만 반대인) Via 헤더를 갖는다.

요소	비고
protocol 이름	HTTP 인 경우 생략 가능
protocol 버전	1.0, 1.1 ...
host 명	숨기고자 한다면 가명으로 대체할 수 있다. 가명을 그룹핑 할 수 있다. 같은 프로토콜, 같은 조직 통제하에 있고, 가명으로 교체되어 있는 경우에만 하나의 프록시 인 것처럼 대체할 수도 있다. 이는 네트워크 내부 설계 등이 노출됨으로써 보안이 깨지는 것을 방지한다. 웬만하면 모든 프록시는 via 헤더(경유지 목록)를 유지하고자 노력해야 한다.
노드 코멘트	벤더나 버전 정보, 이벤트 진단 정보 등을 사용

6.6.2 Trace 메서드

각 프록시를 지나면서 어떻게 메시지를 수정하는지 흐름을 확인(디버깅)할 수 있다.

• 널리 구현되지 않은 메서드 ㅜㅜ
• 네트워크를 통해 홉에서 홉으로 전달돨 때 메세지의 내용이 어떻게 �변하는 지 관찰
• TRACE 응답 Content-type : message/http
• MAX-Forwards 헤더 : 프록시는 자신이 메시지를 받을 때마다 MAX-Forwards 헤더를 1씩 감소시키고 0인 헤더를 받으면 자신이 원 서버가 아니더라도 클라이언트에게 곧장 답신해야 한다. 프락시 연쇄의 어떤 특정 홉의 요청을 보기 위해서 이용할 수도 있다.

6.7 프락시 인증

접근 통제 목적의 프록시는 Proxy-Authenticate 헤더를 통해 어떻게 접근해야 하는 지 알려준다.

• 제한된 콘텐츠에 대한 요청 도착
  • 407 Proxy Authorization Required 코드 + Proxy-Authenticate 헤더와 반환
• 클라이언트 407 응답 수신
  • 요구되는 자격 수집 후 Proxy-Authenticate 헤더에 담아 재요청

6.8 프락시 상호운용성

• 지원하지 않는 확장 헤더는 그대로 냅둔다. (몽총한 프락시의 keep-alive 처럼)
  • 같은 이름의 여러 헤더 필드의 순서도 유지해줘야 한다.
  • 확장 메서드 역시 그대로 넘긴다.
• OPTIONS
  • 서버는 Allow 헤더를 통해 가능한 기능을 응답한다.
  • 더 많은 헤더를 응답하고 이를 받을 수 있지만 표준은 Allow 하나 뿐.
  • 프록시는 Allow 헤더를 수정해선 안된다. (지원하지 않더라도 경로는 언제든지 바뀔 수 있기 때문)

[ruthetum]

[reverse proxy vs api gateway]

• 첨부해준 baeldung 자료 감사합니다.
• 결국 큰 차이는 다른 프로토콜에 대한 지원 여부라고 생각(아닐 경우 피드백주세요)
• 근데 자료를 읽다보니 포트스 말미에 reverse proxy와 api gateway를 비교한 테이블에서 reverse proxy에서 지원하지 않는 기능들에 대해 적혀져있는데 nginx 같은 경우 reverse proxy로 활용하면서 화이트리스트 및 logging 등의 기능을 지원하는 것으로 알고 있음
• 그렇다면 reverse proxy에서 observability한 기능이 optional한건지 혹은 다른 로깅을 의미하는건지 혹은 gateway에서 mandatory한건지 알려주시면 감사하겠습니다.

[ruthetum]

[pac 설정]

• pac 설정 코드의 경우 책에 나와있지 않은 자세한 부분까지 설명해주셔서 감사합니다.
• 그렇다면 이 설정을 정확히 어떻게 하는지 알 수 있을까요? (ex. 브라우저마다 각각 설정해줘야하는지, 아니면 통일되게 설정할 수 있는지)
• 제가 이해했을 때는 pac가 동작하는 시점이 os단에 http 요청을 하기 전에 브라우저 단에서 domain name, uri path, 내부 ip 등을 기준으로 미리 라우팅을 하는 것으로 이해했는데 맞을까요?

cf1. https://docs.microsoft.com/ko-kr/troubleshoot/developer/browsers/connectivity-navigation/optimize-pac-performance
cf2. https://runebook.dev/ko/docs/http/proxy_servers_and_tunneling/proxy_auto-configuration_(pac)_file

[ruthetum]

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

• 제가 구조가 약간 혼동이 되어서 그런데 그림 6-14의 나와있는 4가지 트래픽 처리 방법과 6.3.1 프락시 서버 배치에 나와 있는 다양한 프락시 서버 배치 방법들과 연관지어서 설명을 들을 수 있을까요?
• 6.3.3 어떻게 프락시가 트래픽을 처리하는가에 나와있는 여러 가지 처리 방법이 프락시 서버의 배치 방법과 연관이 있는건지, 연관이 있다면 어떤 배치 방법이 어떤 처리 방법으로 이어지는지 알고 싶습니다.

[im-gnar]

[pac 설정]

• pac 설정 코드의 경우 책에 나와있지 않은 자세한 부분까지 설명해주셔서 감사합니다.
• 그렇다면 이 설정을 정확히 어떻게 하는지 알 수 있을까요? (ex. 브라우저마다 각각 설정해줘야하는지, 아니면 통일되게 설정할 수 있는지)
• 제가 이해했을 때는 pac가 동작하는 시점이 os단에 http 요청을 하기 전에 브라우저 단에서 domain name, uri path, 내부 ip 등을 기준으로 미리 라우팅을 하는 것으로 이해했는데 맞을까요?

cf1. https://docs.microsoft.com/ko-kr/troubleshoot/developer/browsers/connectivity-navigation/optimize-pac-performance cf2. https://runebook.dev/ko/docs/http/proxy_servers_and_tunneling/proxy_auto-configuration_(pac)_file

일단 3번은 How is a PAC file consumed? 에서는 브라우저가 시작되는 시점에서 pac 파일을 색인하고 적용한다고 하네요.
저도 적용 방식을 정확하게 모르겠어서 추가로 리서치해보겟슴다