---

Chapter 6. Proxies

(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)

---

❤️ 원문 번역 ❤️

Tracing Messages

Today, it’s not uncommon for web requests to go through a chain of two or more proxies on their way from the client to the server (Figure 6-19). For example, many corporations use caching proxy servers to access the Internet, for security and cost savings, and many large ISPs use proxy caches to improve performance and implement features. A significant percentage of web requests today go through proxies. At the same time, it’s becoming increasingly popular to replicate content on banks of surrogate caches scattered around the globe, for performance reasons.

• 오늘날 웹 요청이 클라이언트로부터 서버로 전달될 때까지 두 개 이상의 프록시 체인을 통과하는 것은 흔한 일입니다. (Figure 6-19)

• 예를 들어 많은 기업이 보안과 비용 절감을 위해 캐싱 프록시 서버를 사용하여 인터넷에 액세스하고, 수많은 대규모 ISP가 성능을 향상하고 기능을 구현하기 위해 프록시 캐시를 활용하고 있습니다.

• 오늘날 웹 요청의 상당 비율은 프록시를 통과합니다.

• 동시에 성능적인 이유로 전세계 여러 곳에 흩어져 있는 Surrogate 캐시에 콘텐츠를 복제하는 것이 대중화 되고 있습니다.

Proxies are developed by different vendors. They have different features and bugs and are administrated by various organizations.

• 프록시는 서로 다른 vendor(공급자)에 의해 개발됩니다.

• 따라서 서로 다른 기능과 버그가 존재하고 다양한 기관에 의해 관리됩니다.

As proxies become more prevalent, you need to be able to trace the flow of messages across proxies and to detect any problems, just as it is important to trace the flow of IP packets across different switches and routers.

• 프록시의 사용이 만연해짐에 따라 프록시를 통과하는 메시지의 흐름을 추적하고 문제를 탐지해야 할 필요성이 대두되었습니다. 서로 다른 스위치와 라우터를 통과하는 IP 패킷의 흐름을 추적하는 것이 중요하기 때문입니다.

---

The Via Header

The Via header field lists information about each intermediate node (proxy or gateway) through which a message passes. Each time a message goes through another node, the intermediate node must be added to the end of the Via list.

• Via 헤더 필드는 메시지가 통과하는 중간 노드(프록시나 게이트웨이)에 대한 정보를 나열합니다.

• 메시지가 다른 노드를 통과할 때마다 Via 리스트의 끝에 중간 노드가 추가되어야 합니다.

The following Via string tells us that the message traveled through two proxies. It indicates that the first proxy implemented the HTTP/1.1 protocol and was called proxy-62.irenes-isp.net, and that the second proxy implemented HTTP/1.0 and was called cache.joes-hardware.com:

Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com

• 다음의 Via 문자열은 메시지가 두 개의 프록시로부터 전해졌음을 시사합니다.

• 이것은 proxy-62.irenes-isp.net이라고 불리는 첫 번째 프록시가 HTTP/1.1 프로토콜을 구현했고, cache.joes-hardware.com이라고 불리는 두번째 프록시가 HTTP/1.0을 구현했음을 나타냅니다.

The Via header field is used to track the forwarding of messages, diagnose message loops, and identify the protocol capabilities of all senders along the request/response chain (Figure 6-20).

• Via 헤더 필드는 포워딩된 메시지를 추적하고, 메시지 루프를 진단하며, 요청/응답 체인에 속한 모든 송신단의 프로토콜 능력을 식별하기 위해 사용됩니다. (Figure 6-20)

Proxies also can use Via headers to detect routing loops in the network. A proxy should insert a unique string associated with itself in the Via header before sending out a request and should check for the presence of this string in incoming requests to detect routing loops in the network.

• 프록시는 네트워크에서 라우팅 루프를 감지하기 위해 Via 헤더를 사용할 수도 있습니다.

• 프록시는 요청을 내보내기 전 Via 헤더에 자기 자신과 관련된 고유한 문자열을 삽입해야 합니다. 또한 네트워크에서 라우팅 루프를 감지하기 위해 들어오는 요청에 대해 이 문자열의 존재 여부를 확인해야 합니다.

Via Syntax

The Via header field contains a comma-separated list of waypoints. Each waypoint represents an individual proxy server or gateway hop and contains information about the protocol and address of that intermediate node. Here is an example of a Via header with two waypoints:

Via = 1.1 cache.joes-hardware.com, 1.1 proxy.irenes-isp.net

• Via 헤더 필드는 콤마로 구분되는 경유지(중간 노드)의 목록을 포함합니다.

• 각각의 경유지는 각각의 프록시 서버나 게이트웨이 홉을 의미하고 프로토콜과 중간 노드의 주소에 대한 정보를 포함합니다.

• 아래는 두 개의 경유지를 포함한 Via 헤더의 예시입니다.

  Via = 1.1 cache.joes-hardware.com, 1.1 proxy.irenes-isp.net

The formal syntax for a Via header is shown here:

Via               = "Via" ":" 1#( waypoint )
waypoint          = ( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
received-by       = ( host [ ":" port ] ) | pseudonym

• Via 헤더의 공식적인 문법은 다음과 같습니다.

  Via               = "Via" ":" 1#( waypoint )
  waypoint          = ( received-protocol received-by [ comment ] )
  received-protocol = [ protocol-name "/" ] protocol-version
  received-by       = ( host [ ":" port ] ) | pseudonym

Note that each Via waypoint contains up to four components: an optional protocol name (defaults to HTTP), a required protocol version, a required node name, and an optional descriptive comment:

• 각각의 Via 경유지는 선택적인 프로토콜 이름(디폴트는 HTTP), 필수적인 프로토콜 버전, 필수적인 노드의 이름, 선택적인 설명 코멘트, 최대 4개의 컴포넌트를 포함할 수 있음에 유의합니다.

Protocol name

The protocol received by an intermediary. The protocol name is optional if the protocol is HTTP. Otherwise, the protocol name is prepended to the version, separated by a “/”. Non-HTTP protocols can occur when gateways connect HTTP requests for other protocols (HTTPS, FTP, etc.).

Protocol name

• 중개자가 수신한 프로토콜입니다.

• 만약 HTTP 프로토콜이라면 프로토콜의 이름은 선택 사항입니다.

• HTTP가 아니라면 버전 앞에 프로토콜의 이름이 위치해야 하며 두 요소를 "/"로 구분합니다.

• Non-HTTP 프로토콜은 게이트웨이가 다른 프로토콜(HTTPS, FTP 등)에 대한 HTTP 요청을 연결할 때 발생할 수 있습니다.

Protocol version

The version of the message received. The format of the version depends on the protocol. For HTTP, the standard version numbers are used (“1.0”, “1.1”, etc.). The version is included in the Via field, so later applications will know the protocol capabilities of all previous intermediaries.

Protocol version

• 수신된 메시지의 버전입니다.

• 버전의 형태는 프로토콜에 따라 상이합니다.

• HTTP의 경우 표준 버전 번호("1.0", "1.1" 등)가 사용됩니다.

• Via 필드에 포함된 버전은 추후 응용 프로그램이 이전의 모든 중간 노도의 프로토콜 능력을 알 수 있게 합니다.

Node name

The host and optional port number of the intermediary (if the port isn’t included, you can assume the default port for the protocol). In some cases an organization might not want to give out the real hostname, for privacy reasons, in which case it may be replaced by a pseudonym.

Node name

• 중간 노드의 호스트와 선택적인 포트 번호입니다. 만약 포트 번호가 포함되지 않는다면 주어진 프로토콜의 디폴트 포트 번호라고 가정합니다.

• 특정 경우에서는 조직이 보안상의 이유로 실제 호스트명을 전달하지 않기를 희망하여 pseudonym으로 대체될 수 있습니다.

Node comment

An optional comment that further describes the intermediary node. It’s common to include vendor and version information here, and some proxy servers also use the comment field to include diagnostic information about the events that occurred on that device.*

Node comment

• 중간 노드를 추가로 설명하는 선택적인 comment입니다.

• vendor와 버전 정보를 포함하는 것이 일반적이며, 일부 프록시 서버는 장치에서 발생한 이벤트의 진단 정보를 포함하는 데 comment 필드를 사용하기도 합니다.

---

🧡 요약 정리 🧡

Via Header

Via               = "Via" ":" 1#( waypoint )
waypoint          = ( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
received-by       = ( host [ ":" port ] ) | pseudonym

• 서로 다른 프록시, 스위치, 라우터를 통과하는 요청 메시지의 흐름 추적
• 라우팅 루프 진단 : 내보내는 요청에 고유한 문자열 삽입 / 들어오는 요청에 문자열 존재 여부 확인
  (* 라우팅 루프 : 네트워크에서 패킷이 목적지로 이동하지 못하고 끊임없이 순환하는 현상)
• 요청/응답 체인에 속한 모든 송신단의 프로토콜 능력 식별

---

💛 감상 💛

• Via 헤더의 존재 이유에 대해 알게 되었습니다. HTTP 헤더가 워낙 많고 당장 급하게 공부해야 할 다른 것들이 너무 많아서, 그냥 막연하게 이런 헤더가 있는가보다 정도로만 생각했었습니다. 그런데 막상 책을 읽으면서 여러 헤더들을 만나다 보니 신기하다는 생각이 듭니다. 기존의 네트워크 문제점을 해결하기 위해, 혹은 성능을 개선하기 위해, 다양한 헤더를 구상하고 실제로 사용하는 사람들이 대단하게 느껴집니다. 정말 네트워크는 파면 팔수록 흥미로운 분야입니다. 어떻게 사람들이 이렇게까지 똑똑할까요?

• 150페이지째 번역을 하다 보니 이제 파파고 켜기도 귀찮아서 크롬에 DeepL 확장 프로그램을 다운받아 버렸습니다...ㅋㅋ 번역기 성능도 좋고 드래그하면 자동으로 번역해주니까 너무 편리합니다. 네트워크 공부하면서 영어 읽는 연습도 같이 하려고 원서 읽기를 시작했는데, 번역기 돌리는 게 너무 맛있습니다. 이러면 안 되는데 자꾸만 손이 가네요. 그래도 제가 한 번 해석한 다음 어색한 부분만 번역기로 고치고 있으니, 해석이 이상하다면 언제든 말씀 주시기 바랍니다.