티스토리 뷰

이번 포스팅에서는 HTTP 완벽가이드 책을 활용하였습니다.

 

5장 web server는 github의 구현코드를 확인 바랍니다. 추가적으로 Connection 관리 학습을 하며 TCP 밑단 프로토콜 학습을 위한 코드도 작성하였으니 테스트 코드를 돌려보시거나, 직접 코드 수정 후 wireshark로 확인하실 수 있습니다.

6장 Proxy

1. Proxy란?

 

같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결하는 용도로 사용된다. (HTTP version 변환은 가능하며, 상용 Proxy Server는 SSL, 방화벽, FTP 접근 등 웹 기반 애플리케이션을 지원하기 위해 Gateway 기능이 구현되어 있다.)

 

* 서로 다른 프로토콜을 사용하는 둘 이상을 연결하기 위해서는 Gateway를 사용한다.

 

 

2. Proxy Server가 사용되는 예

 

성인컨텐츠 등을 차단하는 어린이 필터, 보안등급이 있는 문서에 대한 접근 제어, 보안 방화벽, 웹 캐시, Reverse Proxy, Contents Router, TransCoder, Anonymizer 등으로  사용된다. 이 중 Contents Router란 인터넷 트래픽 조건과 컨텐츠 종류에 따라 요청을 특정 웹 서버로 유도하는 역할을 한다. Anycast와 비교해서 확인해보는 것도 좋겠다. Transcoder란, 컨텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정(GIF -> JPG, image resize, 압축, 언어 변환)하는 것을 말한다. apache의 mod_deflate, mod_ssl 등의 모듈 등을 활용하여 같은 효과를 낼 수 있다. 그리고 Anonymizer는 개인 식별 정보를 제거하여 익명성 보장에 기여한다. 구체적으로, User-Agent 헤더에서 사용자의 컴퓨터와 OS 종류 제거, 어떤 사이트를 거쳐서 방문했는지 알기 어렵게 하기 위해 Referer 헤더 제거, 프로필과 신원 정보를 없애기 위해 Cookie 헤더 제거 등이 있다. 

 

3. Proxy Server의 종류

 

1) Egress Proxy: LAN 구간과 Internet 구간에서 방화벽, 인터넷 트래픽 성능 개선 등의 역할을 한다. (어린이 필터 등이 여기에 위치한다.)

 

2) Ingress Proxy: LoadBalancer 역할을 한다. Kubernetes의 ingress의 기능을 같이 확인해보는 것도 좋겠다. [Nginx Ingress에서 Proxy Protocol을 통해 Client Source IP를 가져오는 방법]

 

3) Reverse Proxy: 웹서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청할 수 있다. 또한 웹 서버에 보안 기능을 추가하거나 빠른 웹 서버 캐시를 느린 웹 서버의 앞에 놓음으로서 성능을 개선할 수도 있다. Reverse Proxy는 일반적으로 웹서버의 이름과 IP 주소를 자신으로 가징하기 때문에, 모든 요청은 서버가 아닌 이 Proxy로 가게 된다.

 

4. Proxy Server의 요청 처리방식

 

Proxy Server들은 origin server에 가까운 Proxy Server를 parent로 둔다. 일반적으로 자신의 parent proxy 혹은 origin server에게 라우팅하는데, contents router, reverse proxy 등의 경우처럼 동적으로 parent를 선정하는 경우가 있다. 이 경우 현재 부모들의 작업량 수준에 근거하여 선택(Load Balancing), 지리적 인접성에 근거하여 선택, 특정 URI의 요청을 처리하는 프락시 서버를 선택, 유료 서비스 가입자를 위한 라우팅 등의 방법이 있다.

 

그렇다면 Proxy Server는 트래픽을 어떻게 처리할까? 

 

웹 브라우저에서 Proxy를 사용하도록 설정하여 의도적으로 origin server가 아닌 Proxy로 보낼 수 있다. 그리고 트래픽을 가로채어 Proxy로 리다이렉트하는 방식(Transparent Proxy)과 웹 서버에서 HTTP Redirect 명령을 클라이언트에게 돌려줌으로써 클라이언트의 요청을 Proxy로 리다이렉트할 수있다. 그 외에 Reverse Proxy는 웹서버의 이름과 IP주소를 자신이 직접 사용하여 모든 요청을 서버 대신 자신이 받는다.

 

5. Proxy 요청의 미묘한 특징들

 

* 클라이언트가 Proxy 대신 서버로 요청할 경우 완전한 URI를 갖는다. Proxy는 목적지 서버와 커넥션을 맺어야 하기 때문에, 그 서버의 이름, URI 스킴을 알 필요가 있다.

VirtualHost는 부분 URI로 인해 발생하는 문제를 호스트와 포트에 대한 정보가 담겨있는 Host 헤더를 통해 해결한다. Proxy도 부분 URI이고 Host 헤더가 있다면 이를 통해 정보를 알아내야 한다. 만약, Transparent Proxy와 같은 방식으로 동작할 경우엔 Client는 Proxy가 있음을 알지 못함으로 부분 URI를 보낼 수 있고, 브라우저에서 Host 헤더를 지원하지 않을 경우라면 어떻게 해야할까?

   - Reverse proxy라면 Proxy에 실제 서버의 주소와 포트번호가 설정되어 있을 수 있다
   - 이전에 어떤 Proxy가 가로챘던 트래픽을 받았고, 그  Proxy가 원 IP주소와 포트번호를 사용할 수 있도록 해두었다면 그 정보를 사용할 수 있다.
   - 모두 실패했다면 에러 메시지를 반환해야 한다. (보통은 Host 헤더를 지원하는 브라우저로  업그레이드하라고 보낸다.)

1
GET http://www.brainbackdoor.com/index.html HTTP/1.1

 

* Proxy가 없는 경우엔 기본스킴으로 'http://' 기본포트로 80 기본 경로를 '/'로 간주한다. 실패할 경우, DNS resolve 를 활용하여 도메인을 검색한다.  웹 브라우저는 Proxy에 요청할 경우 부분 호스트명을 자동확장하지 않는다.

만약 Transparent Proxy가 있을 경우, 브라우저는 Proxy가 있는지 알 수 없으므로 자동확장하고, DNS resolve를 활용하여 요청한다. 만약 DNS에 등록된 서버가 죽은 서버일 경우(DNS는 서버의 health를 보장해주지 않는다. DNS 다중화의 문제점에 대해 링크에서 확인할 수 있다.) Proxy Server가 다른 IP 주소로 인계하여야 한다.

 

6. 메시지 추적

 

* 보안과 비용 절감을 위해 인터넷 접속시 Cache Proxy Server를 사용하며, 많은 대형 ISP들이 성능 개선과 기능 구현을 위해 Proxy Cache를 사용한다. 동시에 성능상의 이유로 세계 곳곳에 흩어져 있는 대리 Cache 저장고에 Contents를 복제해두는 방식이 점점 더 흔해지고 있다.

* Proxy가 점점 더 흔해지면서, 서로 다른 스위치나 라우터를 넘나드는 IP 패킷의 흐름을 추적하는 것 못지 않게 Proxy를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것도 필요한 일이 되었다. Via 헤더 필드는 메시지가 지나는 각 중간 노드(Proxy나 Gateway)의 정보를 나열한다. (Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com)

 Via 헤더 필드는 메시지의 전달을 추적하고, 메시지 루프를 진단하고, 요청을 보내고 그에 대한 응답을 돌려주는 과정에 관여하는 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용된다.

* Proxy는 이해할 수 없는 헤더 필드는 반드시 그대로 전달해야 하며, 같은 이름의 헤더 필드가 여러 개 있는 경우에는 그들의 상대적인 순서도 반드시 유지해야 한다.

 

 

 

7. 그 외 Proxy 관련 주제들..

 

1) Ngrok 패킷 분석

 

* 로컬(192.168.7.144)에서 서버를 띄우고 브라우저로 확인해서 헷갈릴수도 있겠다.

1. ngrok을 실행하니, 우선 3.15.53.92의 원격 서버의 주소를 알아온 후 SSL Tunneling을 맺는다.

2. 자동으로 생성한 주소(b2612480.ngrok.io를 DNS Server의 CNAME으로 매핑하는 듯 하다. 매번 주소가 바뀐다. (AWS EC2일 때도 있고, akamai 장비일 때도 있다.)

3. b2612480.ngrok.io의 IP를 알아온 후 해당 브라우저로 요청 시 서버에서 SSL 터널링으로 데이터를 보내는 것을 확인할 수 있다. 이것으로 18.188.14.65 proxy 서버와 3.15.53.92 서버간에 Port forwarding 되어 있을거라 추측해본다.


2) GSLB

 

* 잘 정리된 포스팅이 있어서 링크를 남겨둔다. 

 

3) Ingress with Kubenetes

댓글
링크
최근에 달린 댓글
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
Total
Today
Yesterday