Chapter 6. Proxies
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
❤️ 원문 번역 ❤️
Tricky Things about Proxy Requests
This section explains some of the tricky and much misunderstood aspects of proxy server requests, including:
• How the URIs in proxy requests differ from server requests
• How intercepting and reverse proxies can obscure server host information
• The rules for URI modification
• How proxies impact a browser’s clever URI auto-completion or hostname- expansion features
- 이번 섹션에서는 까다로우면서 오해를 일으킬 수 있는 프록시 서버 요청의 몇 가지 측면을 설명하고자 합니다.
- 프록시 요청의 URI가 서버 요청과 다른 점
- 간섭 및 리버스 프록시가 서버 호스트 정보를 숨기는 방법
- URI 수정 규칙
- 프록시가 브라우저의 영리한 URI 자동완성이나 호스트명 확장 특성에 미치는 영향
Proxy URIs Differ from Server URIs
Web server and web proxy messages have the same syntax, with one exception. The URI in an HTTP request message differs when a client sends the request to a server instead of a proxy.
-
웹 서버와 웹 프록시 메시지는 동일한 문법을 가지고 있지만 한 가지 예외가 있습니다.
-
클라이언트가 프록시 대신 서버로 요청을 보낼 때는 HTTP 요청 메시지의 URI가 다릅니다.
When a client sends a request to a web server, the request line contains only a par- tial URI (without a scheme, host, or port), as shown in the following example:
GET /index.html HTTP/1.0 User-Agent: SuperBrowserv1.3
- 클라이언트가 웹 서버로 요청을 전송할 때, 다음의 예시처럼 요청 라인은 URI의 일부분만을 포함합니다(schene, host, port 없이).
GET /index.html HTTP/1.0 User-Agent: SuperBrowserv1.3
When a client sends a request to a proxy, however, the request line contains the full URI. For example:
GET http://www.marys-antiques.com/index.html HTTP/1.0 User-Agent: SuperBrowser v1.3
- 반면 클라이언트가 프록시로 요청을 전송할 때는 요청 라인에 전체 URI를 포함합니다.
GET http://www.marys-antiques.com/index.html HTTP/1.0 User-Agent: SuperBrowser v1.3
Why have two different request formats, one for proxies and one for servers? In the original HTTP design, clients talked directly to a single server. Virtual hosting did not exist, and no provision was made for proxies. Because a single server knows its own hostname and port, to avoid sending redundant information, clients sent just the partial URI, without the scheme and host (and port).
-
왜 프록시의 요청 포맷과 서버의 요청 URI 포맷은 서로 다를까요?
-
처음 HTTP를 설계할 때는 클라이언트가 단일 서버와 직접 소통하였습니다.
-
가상 호스팅의 개념이 존재하지 않았고, 프록시에 대한 프로비저닝이 이루어지지 않았습니다.
-
단일 서버는 고유한 호스트명과 포트 번호를 알고 있습니다. 따라서 정보를 중복으로 전송하지 않기 위해 클라이언트는 Scheme과 host, (port)를 제외한 URI의 일부분만 전송합니다.
When proxies emerged, the partial URIs became a problem. Proxies needed to know the name of the destination server, so they could establish their own connections to the server. And proxy-based gateways needed the scheme of the URI to connect to FTP resources and other schemes. HTTP/1.0 solved the problem by requiring the full URI for proxy requests, but it retained partial URIs for server requests (there were too many servers already deployed to change all of them to support full URIs).*
-
부분 URI가 문제가 되기 시작한 것은 프록시가 출현한 이후입니다.
-
프록시는 destination 서버의 이름을 알아야만 서버에 고유한 연결을 설정할 수 있습니다.
-
뿐만 아니라 프록시 기반 게이트웨이는 FTP 리소스 및 다른 scheme에 접근하기 위한 URI scheme을 필요로 합니다.
-
HTTP/1.0은 프록시 요청에 대해 전체 URI를 요청하여 해당 문제를 해결했습니다. 그러나 서버 요청에 대한 부분 URI의 사용은 그대로 유지되었습니다. (이미 수많은 서버가 배포되어 그 많은 서버가 전부 전체 URI를 지원하도록 수정할 수 없습니다.)
So we need to send partial URIs to servers, and full URIs to proxies. In the case of explicitly configured client proxy settings, the client knows what type of request to issue:
• When the client is not set to use a proxy, it sends the partial URI (Figure 6-15a).
• When the client is set to use a proxy, it sends the full URI (Figure 6-15b).
-
그러므로 우리는 서버에게는 부분 URI를, 프록시에게는 전체 URI를 전송해야 합니다.
-
클라이언트 프록시 설정이 명시적으로 구성되어 있는 경우에는 클라이언트가 어떤 유형의 요청을 발행해야 할지 알고 있습니다.
- 클라이언트가 프록시를 사용하도록 설정되지 않으면 부분 URI를 전송한다. (Figure 6-15a)
- 클라이언트가 프록시를 사용하도록 설정되면 전체 URI를 전송한다. (Figure 6-15b)
The Same Problem with Virtual Hosting
The proxy “missing scheme/host/port” problem is the same problem faced by virtually hosted web servers. Virtually hosted web servers share the same physical web server among many web sites. When a request comes in for the partial URI /index.html, the virtually hosted web server needs to know the hostname of the intended web site (see “Virtually hosted docroots” in Chapter 5 and “Virtual Hosting” in Chapter 18 for more information).
-
프록시의 "missing scheme/host/port" 문제는 가상 호스팅 된 웹 서버에 의해 직면된 문제와 동일합니다.
-
가상 호스팅 된 웹 서버는 동일한 물리적 웹 서버를 여러 웹 사이트 사이에서 공유합니다.
-
부분 URI인 /index.html에 대한 요청이 들어오면, 가상 호스팅 된 웹 서버는 의도한 웹 사이트의 호스트명을 알아야 합니다. (자세한 내용은 Chapter 5의 "Virtually hosted docroots"와 Chapter 18의 "Virtual Hosting"을 참고하시기 바랍니다.)
In spite of the problems being similar, they were solved in different ways:
• Explicit proxies solve the problem by requiring a full URI in the request message.
• Virtually hosted web servers require a Host header to carry the host and port information.
- 문제 상황은 비슷하지만 두 상황은 서로 다른 방식으로 해결되었습니다.
- 명시적인 프록시가 요청 메시지 안에 전체 URI를 요구하여 문제를 해결합니다.
- 가상 호스팅 웹 서버는 호스트와 포트 정보를 운반하기 위해 Host 헤더를 요구합니다.
Intercepting Proxies Get Partial URIs
As long as the clients properly implement HTTP, they will send full URIs in requests to explicitly configured proxies. That solves part of the problem, but there’s a catch: a client will not always know it’s talking to a proxy, because some proxies may be invisible to the client. Even if the client is not configured to use a proxy, the client’s traffic still may go through a surrogate or intercepting proxy. In both of these cases, the client will think it’s talking to a web server and won’t send the full URI:
-
클라이언트는 HTTP를 적절하게 구현한다는 가정하에 명시적으로 구성된 프록시에 전체 URI를 담은 요청을 전송할 것입니다.
-
이 방식은 문제의 일부분을 해결하지만 한 가지 문제가 더 있습니다. 일부 프록시는 클라이언트에게 보이지 않을지도 모릅니다. 따라서 클라이언트는 자신이 프록시와 통신 중인지를 장담할 수 없습니다.
-
클라이언트가 프록시를 사용하도록 구성되지 않더라도 클라이언트의 트래픽이 여전히 Surrogate나 간섭 프록시를 통과할지도 모릅니다.
-
두 가지 경우 모두 클라이언트는 웹 서버와 통신 중이라고 생각하여 전체 URI를 전송하지 않을 것입니다.
• A surrogate, as described earlier, is a proxy server taking the place of the origin server, usually by assuming its hostname or IP address. It receives the web server request and may serve cached responses or proxy requests to the real server. A client cannot distinguish a surrogate from a web server, so it sends partial URIs (Figure 6-15c).
-
앞서 설명했던 Surrogate는 일반적으로 origin 서버의 호스트명이나 IP 주소를 가정하여 그 자리를 대신하는 프록시 서버입니다.
-
Surrgate는 웹 서버 요청을 받고 캐싱된 응답을 제공하거나 실제 서버로 프록시 요청을 전달할 것입니다.
-
클라이언트는 Surrogate와 웹 서버를 구별할 수 없기 때문에 partial URI를 전송합니다. (Figure 6-15c)
• An intercepting proxy is a proxy server in the network flow that hijacks traffic from the client to the server and either serves a cached response or proxies it. Because the intercepting proxy hijacks client-to-server traffic, it will receive partial URIs that are sent to web servers (Figure 6-15d).*
-
간섭 프록시는 네트워크 흐름에서 클라이언트로부터 서버로 향하는 트래픽을 하이재킹하여(가로채어) 캐싱된 응답을 전송하거나 중개하는 프록시 서버입니다.
-
간섭 프록시는 클라이언트에서 서버로 향하는 트래픽을 가로채기 때문에 웹 서버로 향하는 부분 URI를 받게 될 것입니다. (Figure 6-15d)
Proxies Can Handle Both Proxy and Server Requests
Because of the different ways that traffic can be redirected into proxy servers, general-purpose proxy servers should support both full URIs and partial URIs in request messages. The proxy should use the full URI if it is an explicit proxy request or use the partial URI and the virtual Host header if it is a web server request.
-
트래픽이 프록시 서버로 리디렉션되는 방법은 다양합니다. 따라서 일반적인 목적의 프록시 서버는 요청 메시지의 전체 URI와 부분 URI를 모두 지원해야 합니다.
-
프록시는 명시적인 프록시 요청인 경우 전체 URI를 사용해야 하고, 웹 서버 요청이라면 부분 URI와 가상의 Host 헤더를 사용해야 합니다.
The rules for using full and partial URIs are:
• If a full URI is provided, the proxy should use it.
• If a partial URI is provided, and a Host header is present, the Host header should be used to determine the origin server name and port number.
• If a partial URI is provided, and there is no Host header, the origin server needs to be determined in some other way:— If the proxy is a surrogate, standing in for an origin server, the proxy can be configured with the real server’s address and port number. — If the traffic was intercepted, and the interceptor makes the original IP address and port available, the proxy can use the IP address and port number from the interception technology (see Chapter 20). — If all else fails, the proxy doesn’t have enough information to determine the origin server and must return an error message (often suggesting that the user upgrade to a modern browser that supports Host headers).*
-
전체 URI 및 부분 URI를 사용하는 규칙은 다음과 같습니다.
-
전체 URI가 제공되면, 프록시는 그것을 사용해야 합니다.
-
부분 URI가 제공되고 Host 헤더가 존재하면, Host 헤더는 origin 서버의 이름과 포트 변호를 결정하는 데 사용되어야 합니다.
-
부분 URI가 제공되고 Host 헤더가 존재하지 않는다면, origin 서버는 별도의 방법으로 결정되어야 합니다.
- Surrogate : 프록시가 origin 서버를 대신하는 Surrogate라면 origin 서버의 주소와 포트 번호로 프록시를 구성할 수 있습니다.
- Intercept Proxy : 트래픽을 가로챈 주체가 원본 IP 주소와 포트 번호를 사용할 수 있게 하면, 프록시는 간섭 기술로부터 IP 주소와 포트 번호를 사용할 수 있습니다. (Chapter 20 참고)
- Fail : 모든 종류의 fail이 발생하면 프록시는 origin 서버를 결정할 만한 정보가 충분하지 않습니다. 따라서 에러 메시지를 반환해야 합니다. (보통 유저에게 Host 헤더를 지원하는 최신 브라우저로 업데이트 할 것을 권장합니다)
In-Flight URI Modification
Proxy servers need to be very careful about changing the request URI as they forward messages. Slight changes in the URI, even if they seem benign, may create interoperability problems with downstream servers.
-
프록시 서버는 메시지를 포워딩할 때 요청 URI를 수정하는 것에 매우 신중해야 합니다.
-
URI의 사소한 변화가 정상적으로 보일지라도 다운스트림 서버와 상호운용성 문제가 발생할 수 있습니다.
In particular, some proxies have been known to “canonicalize” URIs into a standard form before forwarding them to the next hop. Seemingly benign transformations, such as replacing default HTTP ports with an explicit “:80”, or correcting URIs by replacing illegal reserved characters with their properly escaped substitutions, can cause interoperation problems.
-
특히 일부 프록시는 다음 홉으로 URI를 포워딩하기 전에 표준 형태로 표준화하는 것으로 알려져 있습니다.
-
디폴트 HTTP 포트를 명시적인 ":80"으로 대체하거나 허용되지 않는 예약어를 적절한 escape 표기로 대체하는 것처럼 정상적으로 보이는 변화도 상호운용 문제를 야기할 수 있습니다.
In general, proxy servers should strive to be as tolerant as possible. They should not aim to be “protocol policemen” looking to enforce strict protocol compliance, because this could involve significant disruption of previously functional services.
-
일반적으로 프록시 서버는 가능한 한 관용을 베풀기 위해 노력합니다.
-
프록시가 엄격하게 프로토콜 규정을 준수하는 "프로토콜 경찰관"이 되어서는 안 됩니다. 이전에 정상적으로 작동하던 서비스의 심각한 장애를 초래할 수 있기 때문입니다.
In particular, the HTTP specifications forbid general intercepting proxies from rewriting the absolute path parts of URIs when forwarding them. The only exception is that they can replace an empty path with “/”.
-
특히 HTTP 명세에서는 일반적인 간섭 프록시가 URI를 포워딩할 때 URI의 절대 경로 부분을 재작성하는 것을 금지하고 있습니다.
-
예외적으로 빈 경로를 "/"로 대체하는 것은 가능합니다.
🧡 요약 정리 🧡
Proxy URIs
- Server Request(not using proxy) : Partial URI
- Explicit Proxy Request : Full URI
클라이언트가 프록시를 사용하도록 구성되지 않더라도 클라이언트 트래픽이 여전히 아래 프록시들을 통과할 가능성이 있다 - Surrogates : 웹 서버와 구별이 되지 않으므로 Partial URI 도착 -> origin 서버의 주소와 포트 번호로 프록시 구성
- Intercept Proxy : 클라이언트에서 서버로 향하는 트래픽을 가로채므로 Partial URI 도착 -> 트래픽을 가로챈 주체가 원본 IP 주소와 포트 번호를 사용 가능하게 하면 해당 정보를 활용해 프록시 구성
- Fail : origin 서버 결정 불가 -> 에러 메시지 반환
** 프록시 서버는 메시지를 포워딩할 때 요청 URI를 신중하게 수정해야 한다. 보이는 변화도 상호운용 문제를 야기할 수 있다.
💛 감상 💛
-
낮에 산뜻한 정신으로 글을 쓰니 기분이 좋습니다. 맨날 피로에 쩔어가지고 반쯤 넋 나간 상태로 글을 썼는데 말이죵... 오늘 분량도 텍스트 고봉밥이었지만 강의 하나가 휴강을 한 덕에 시간적 여유가 있어서 다행입니다.
-
클라이언트가 프록시로 요청을 보낼 때와 서버로 요청을 보낼 때의 URI가 서로 다르다는 사실을 오늘 처음 알게 되었습니다. 물론 클라이언트가 프록시의 존재 여부를 아는 상황은 제한적이라 Surrogate나 Intercept Proxy에는 Partial URI가 전송되지만 말입니다. 이런 상황 때문에 프록시는 두 가지 URI를 모두 처리할 수 있어야 한다는 정보도 새롭게 얻었습니다.
