Chapter 6. Proxies
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
❤️ 원문 번역 ❤️
URL Resolution with Explicit Proxy
When you use an explicit proxy the browser no longer performs any of these convenience expansions, because the user’s URI is passed directly to the proxy.
- 명시적인 프록시를 사용하면 브라우저가 더 이상 이와 같은 편의 확장 기능을 수행하지 않습니다. 사용자의 URI가 프록시에 직접 전달되기 때문입니다.
As shown in Figure 6-17, the browser does not auto-expand the partial hostname when there is an explicit proxy. As a result, when the user types “oreilly” into the browser’s location window, the proxy is sent “http://oreilly/” (the browser adds the default scheme and path but leaves the hostname as entered).
-
Figure 6-17처럼, 브라우저는 명시적인 프록시가 존재할 때 호스트명의 일부분을 자동으로 확장하지 않습니다.
-
그 결과 사용자가 브라우저의 URI 창에 "oreilly"를 입력했을 때 프록시는 "http://oreilly/"로 전송됩니다. (브라우저는 디폴트 scheme과 path를 추가하지만 호스트명은 입력한 대로 유지됩니다.)
For this reason, some proxies attempt to mimic as much as possible of the browser’s convenience services as they can, including “www...com” auto-expansion and addition of local domain suffixes.*
- 이런 이유로 일부 프록시는 "www...com" 자동 확장과 로컬 도메인 접미사를 추가하는 것과 같은 브라우저의 편의 서비스를 최대한 모방하고자 노력합니다.
URI Resolution with Intercepting Proxy
Hostname resolution is a little different with an invisible intercepting proxy, because as far as the client is concerned, there is no proxy! The behavior proceeds much like the server case, with the browser auto-expanding hostnames until DNS success. But a significant difference occurs when the connection to the server is made, as Figure 6-18 illustrates.
-
보이지 않는 Intercepting Proxy에서 호스트명을 확인하는 방법은 조금 다릅니다. 클라이언트 입장에서는 프록시가 없다고 생각하기 때문입니다.
-
동작은 서버와 매우 유사하게 진행되며, 브라우저는 DNS 작업을 성공할 때까지 호스트명을 자동으로 확장합니다.
-
한 가지 큰 차이점은 Figure 6-18이 나타내는 것처럼 서버와의 연결이 만들어질 때 발생합니다.
Figure 6-18 demonstrates the following transaction:
• In Step 1, the user types “oreilly” into the browser’s URI location window.
-
Figure 6-18은 다음의 트랜잭션을 묘사하고 있습니다.
-
Step 1에서 사용자가 브라우저의 URI 위치 창에 "oreilly"를 입력합니다.
• In Step 2a, the browser looks up the host “oreilly” via DNS, but the DNS server fails and responds that the host is unknown, as shown in Step 2b.
- Step 2a에서 브라우저는 DNS를 통해 "oreilly"라는 호스트를 검색하지만 DNS 서버가 호스트를 찾는 데 실패하여 Step 2b와 같이 호스트를 알 수 없다는 응답을 전송합니다.
• In Step 3a, the browser does auto-expansion, converting “oreilly” into “www.oreilly.com.” In Step 3b, the browser looks up the host “www.oreilly.com” via DNS. This time, as shown in Step 3c, the DNS server is successful and returns IP addresses back to the browser.
-
Step 3a에서 브라우저는 자동 확장을 통해 "oreilly"를 "www.oreilly.com"으로 변환합니다.
-
Step 3b에서는 브라우저가 DNS를 통해 "www.oreilly.com" 호스트를 탐색합니다.
-
이때 Step 3c에 나타난 것처럼 DNS 서버가 호스트를 찾는 데 성공하고 브라우저로 IP 주소를 반환합니다.
• In Step 4a, the client already has successfully resolved the hostname and has a list of IP addresses. Normally, the client tries to connect to each IP address until it succeeds, because some of the IP addresses may be dead. But with an intercepting proxy, the first connection attempt is terminated by the proxy server, not the origin server. The client believes it is successfully talking to the web server, but the web server might not even be alive.
-
Step 4a에서 클라이언트는 이미 호스트의 이름을 성공적으로 확인한 상태로, 호스트의 IP 주소 목록을 가지고 있습니다.
-
일반적으로 클라이언트는 성공할 때까지 각각의 IP 주소로 연결을 시도합니다. 일부 IP 주소는 사용이 불가(dead)할지도 모르기 때문입니다.
-
그러나 Intercepting Proxy를 사용하여 origin 서버가 아닌 프록시 서버에 의해 첫 번째 연결 시도가 종료됩니다.
-
클라이언트는 웹 서버와 성공적으로 통신하고 있다고 생각하지만, 웹 서버는 사용 가능한 상태가 아닐지도 모릅니다.
• When the proxy finally is ready to interact with the real origin server (Step 5b), the proxy may find that the IP address actually points to a down server. To provide the same level of fault tolerance provided by the browser, the proxy needs to try other IP addresses, either by reresolving the hostname in the Host header or by doing a reverse DNS lookup on the IP address. It is important that both intercepting and explicit proxy implementations support fault tolerance on DNS resolution to dead servers, because when browsers are configured to use an explicit proxy, they rely on the proxy for fault tolerance.
-
결국 프록시는 실제 origin 서버와 상호작용할 준비가 되었을 때(Step 5b), IP 주소가 다운된 서버를 가리키고 있다는 사실을 발견할 수 있습니다.
-
브라우저가 제공하는 것과 동일한 수준의 내결함성을 제공하기 위해 프록시는 Host 헤더에서 호스트명을 확인하거나 IP 주소에 대해 리버스 DNS 탐색을 수행함으로써 다른 IP 주소를 시도해야 합니다.
(* 내결함성 : 시스템이 하드웨어나 소프트웨어의 오류에도 정상적으로 동작하는 능력)
🧡 요약 정리 🧡
URI Resolution with Explicit Proxy
- 클라이언트가 프록시가 있다는 사실을 안다 -> 브라우저가 URI 자동 확장을 시도하지 않는다
- 클라이언트가 입력한 호스트 이름이 잘못되면 제대로 연결이 되지 않는다
- [해결] 프록시가 "www...com" 자동 확장과 로컬 도메인 접미사를 추가하는 것과 같은 브라우저의 편의 서비스를 최대한 모방하고자 노력한다
URI Resolution with Intercepting Proxy
- 클라이언트가 프록시가 있다는 사실을 모른다 -> 브라우저가 URI 자동 확장을 시도하여 호스트의 IP 주소 목록을 가져온다
- 첫 번째 IP 주소로 연결 시도 -> 클라이언트는 웹 서버가 아닌 Intercepting Proxy에 연결, 그러나 클라이언트는 웹 서버와 잘 연결이 되었다고 생각하여 요청을 전송
- 이 경우 origin 서버와 상호작용할 준비가 되어서야 서버의 다운 여부를 알 수 있다
- [해결] Host 헤더를 통한 호스트 확인, Reverse DNS 사용
(cf) Why Use Reverse DNS
- 클라이언트가 접속하려는 origin 서버의 상태를 확인하기 위해 Intercepting Proxy가 origin 서버에 Reverse DNS 요청 전송
- Intercepting Proxy는 origin 서버의 IP 주소에 대조되는 호스트 이름을 돌려받음
- 만약 응답이 돌아오지 않으면 origin 서버가 다운된 것
💛 감상 💛
-
프록시가 사용될 때 URI를 확인하는 방법이 다르다는 사실을 알게 되었습니다. 비단 URI 확인에 대한 것만은 아니고, 클라이언트가 프록시의 존재 여부를 아는지 모르는지에 따라서 이런저런 처리 방식이 상당히 달라진다는 것을 체감하게 됩니다.
-
DNS가 있고 Reverse DNS도 있다는 사실을 알게 되었습니다. Reverse DNS를 구체적으로 왜 사용하는지는 검색을 해봐도 잘 모르겠지만... 아무튼 Intercepting Proxy에서 사용되는 이유는 대충 알 것 같습니다.
