---

Chapter 4. Connection Management

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

---

❤️ 원문 번역 ❤️

Keep-Alive and Dumb Proxies

Let’s take a closer look at the subtle problem with keep-alive and dumb proxies. A web client’s Connection: Keep-Alive header is intended to affect just the single TCP link leaving the client. This is why it is named the “connection” header. If the client is talking to a web server, the client sends a Connection: Keep-Alive header to tell the server it wants keep-alive. The server sends a Connection: Keep-Alive header back if it supports keep-alive and doesn’t send it if it doesn’t.

• keep-alive와 dumb 프록시의 미묘한 문제에 대해 더 면밀히 살펴보겠습니다.

• 웹 클라이언트의 Connection: Keep-Alive 헤더는 클라이언트를 떠난 하나의 TCP 링크에만 영향을 미칩니다.

• 이것의 이름이 "연결" 헤더인 이유입니다.

• 클라이언트가 웹 서버와 통신하는 중이라면 클라이언트는 Connection: Keep-Alive 헤더를 전달하여 연결을 지속할 의사를 표출합니다.

• 만약 서버가 지속 연결을 지원할 의사가 있다면 서버는 Connection: Keep-Alive 헤더를 반환하고, 그렇지 않다면 반환하지 않습니다.

---

The Connection header and blind relays

The problem comes with proxies—in particular, proxies that don’t understand the Connection header and don’t know that they need to remove the header before proxy- ing it down the chain. Many older or simple proxies act as blind relays, tunneling bytes from one connection to another, without specially processing the Connection header.

• 문제는 프록시와 함께 발생합니다. 특히 Connection 헤더를 이해하지 못하고 다음 체인으로 내려가기 전에 헤더를 삭제해야 함을 알지 못하는 프록시라면 더욱 그렇습니다.

• 오래되거나 단순한 프록시들은 대개 Connection 헤더를 특수하게 처리하지 않고 한 연결에서 다른 연결로 바이트를 터널링하는 블라인드 릴레이를 수행합니다.

Imagine a web client talking to a web server through a dumb proxy that is acting as a blind relay. This situation is depicted in Figure 4-15.

• 블라인드 릴레이로 동작하는 dumb 프록시를 통해 웹 서버와 통신하는 웹 클라이언트를 생각해봅시다.

• 이 상황은 Figure 4-15에 나타나고 있습니다.

Here’s what’s going on in this figure:

1. In Figure 4-15a, a web client sends a message to the proxy, including the Connec- tion: Keep-Alive header, requesting a keep-alive connection if possible. The client waits for a response to learn if its request for a keep-alive channel was granted.

• 다음은 진행 과정입니다.

• 1. Figure 4-15a에서 웹 클라이언트가 Connection: Keep-Alive 헤더를 포함하여 가능하다면 지속 연결을 요청하는 메시지를 프록시에 전달합니다. 클라이언트는 지속 연결 채널에 대한 요청이 승인되었는지 확인하기 위해 응답을 기다립니다.

2. The dumb proxy gets the HTTP request, but it doesn’t understand the Connec- tion header (it just treats it as an extension header). The proxy has no idea what keep-alive is, so it passes the message verbatim down the chain to the server (Figure 4-15b). But the Connection header is a hop-by-hop header; it applies to only a single transport link and shouldn’t be passed down the chain. Bad things are about to happen.

• 2. dumb 프록시는 HTTP 요청을 받았지만 Connection 헤더를 이해하지 못합니다(확장 헤더처럼 취급합니다). 프록시는 keep-alive가 무엇인지 모르기 때문에 체인에 따라 서버로 메시지를 전달합니다. (Figure 4-15b) 하지만 Connection 헤더는 hop-by-hop 헤더입니다. 이 헤더는 오직 하나의 전송 링크에만 적용되며 체인을 따라 전송되어서는 안 됩니다. 좋지 않은 상황이 발생하기도 합니다.

3. In Figure 4-15b, the relayed HTTP request arrives at the web server. When the web server receives the proxied Connection: Keep-Alive header, it mistakenly concludes that the proxy (which looks like any other client to the server) wants to speak keep-alive! That’s fine with the web server—it agrees to speak keep- alive and sends a Connection: Keep-Alive response header back in Figure 4-15c. So, at this point, the web server thinks it is speaking keep-alive with the proxy and will adhere to rules of keep-alive. But the proxy doesn’t know the first thing about keep-alive. Uh-oh.

• 3. Figure 4-15b에서 전달된 HTTP 요청이 웹 서버에 도착합니다. 웹 서버가 프록시된 Connection: Keep-Alive 헤더를 받으면, 프록시가 지속 연결을 원하는 것으로 잘못 판단하게 됩니다. 웹 서버 입장에서는 괜찮습니다. Figure 4-15c에서 지속 연결을 승인하고 Connection: Keep-Alive 응답 헤더를 돌려 보냅니다. 따라서 이 시점에서 웹 서버는 프록시와 keep-alive로 통신하고 있고 keep-alive의 규칙을 따를 것입니다. 그러나 프록시는 keep-alive에 대해 전혀 알지 못합니다.

4. In Figure 4-15d, the dumb proxy relays the web server’s response message back to the client, passing along the Connection: Keep-Alive header from the web server. The client sees this header and assumes the proxy has agreed to speak keep-alive. So at this point, both the client and server believe they are speaking keep-alive, but the proxy they are talking to doesn’t know anything about keep-alive.

• 4. Figure 4-15에서 dumb 프록시는 서버로부터 Connection: Keep-Alive 헤더를 전달하며 웹 서버의 응답 메시지를 클라이언트에게 반환합니다. 클라이언트는 이 헤더를 읽고 프록시가 keep-alive를 승인했다고 추정합니다. 따라서 이때 클라이언트와 서버는 그들이 지속 연결로 통신하고 있다고 믿지만, 정작 그들이 통신하고 있는 프록시는 keep-alive에 대해 전혀 알지 못합니다.

5. Because the proxy doesn’t know anything about keep-alive, it reflects all the data it receives back to the client and then waits for the origin server to close the connection. But the origin server will not close the connection, because it believes the proxy explicitly asked the server to keep the connection open. So the proxy will hang waiting for the connection to close.

• 5. 프록시가 keep-alive에 대해 아무것도 모르기 때문에, 수신한 모든 데이터를 클라이언트에 반영하고 origin 서버가 연결을 닫기를 기다립니다. 그러나 origin 서버는 연결을 닫지 않을 것입니다. 프록시가 명시적으로 서버에게 연결을 개방된 상태로 유지할 것을 요청했다고 생각하기 때문입니다. 따라서 프록시는 연결이 끝나기를 기다리면서 멈출 것입니다.

6. When the client gets the response message back in Figure 4-15d, it moves right along to the next request, sending another request to the proxy on the keep-alive connection (see Figure 4-15e). Because the proxy never expects another request on the same connection, the request is ignored and the browser just spins, making no progress.

• 6. 클라이언트가 Figure 4-15d에서 응답 메시지를 받으면, 다음 요청으로 바로 이동하여 keep-alive 연결을 통해 프록시에게 또다른 요청을 전송합니다. (Figure 4-15e) 프록시는 동일한 연결에 다른 요청이 들어올 거라고 전혀 예측하지 못하기 때문에 요청이 무시되고 브라우저가 진전 없이 회전합니다.

7. This miscommunication causes the browser to hang until the client or server times out the connection and closes it.*

• 7. 이와 같은 소통의 오류는 브라우저가 클라이언트나 서버가 타임아웃으로 연결을 종료할 때까지 중단되게 합니다.

---

Proxies and Hop-by-Hop Headers

To avoid this kind of proxy miscommunication, modern proxies must never proxy the Connection header or any headers whose names appear inside the Connection values. So if a proxy receives a Connection: Keep-Alive header, it shouldn’t proxy either the Connection header or any headers named Keep-Alive.

• 이러한 프록시 소통의 오류를 피하기 위해 모던 프록시는 Connection 헤더나 Connection 값에 나타나는 모든 헤더들을 절대 프록시해서는 안 됩니다.

• 즉, 프록시가 Connection: Keep-Alive 헤더를 받는다면 Connection 헤더나 Keep-Alive로 명명된 임의의 헤더가 프록시 되어서는 안 됩니다.

In addition, there are a few hop-by-hop headers that might not be listed as values of a Connection header, but must not be proxied or served as a cache response either. These include Proxy-Authenticate, Proxy-Connection, Transfer-Encoding, and Upgrade. For more information, refer back to “The Oft-Misunderstood Connection Header.”

• 추가로 Connection 헤더의 값으로 나열되지 않을 수도 있는 몇 가지 hop-by-hop 헤더가 존재합니다. 하지만 이것이 프록시되거나 캐시 응답으로 제공되어서는 안 됩니다.

• 이러한 헤더에는 Proxy-Authenticate, Proxy-Connection, Transfer-Encoding, Upgrade가 포함됩니다.

• 자세한 정보는 "The Oft-Misunderstood Connection Header"를 참고하기 바랍니다.
  ** https://velog.io/@dvlp-sy/TIL-HTTP-The-Definitive-Guide-p86-p88

---

🧡 요약 정리 🧡

Keep-Alive and Dumb Proxies

• Dumb Proxies : Connection 헤더 이해 X -> Connection 헤더 처리 X, Connection 헤더 삭제 X

[1] Blind Relays

• 1. 클라이언트 -> 프록시 : Connection: Keep-Alive 전달 (클라이언트와 keep-alive 연결 시도)
• 2. 프록시 -> 서버 : Connection 헤더를 처리하지 않고 서버에 전달, 서버는 프록시가 keep-alive 연결을 시도한다고 착각
• 3. 서버 -> 프록시 : keep-alive 연결을 승인한다는 뜻으로 Connection 헤더 전달 (프록시와 keep-alive 연결 승인)
• 4. 프록시 -> 클라이언트 : Connection 헤더를 처리하지 않고 클라이언트에 전달, 클라이언트는 프록시가 keep-alive 연결을 승인했다고 착각
• 5. 프록시는 서버가 연결을 종료할 것을 기대하지만 클라이언트는 프록시에게 또다른 요청 전송 -> 요청 무시
• 6. 클라이언트나 서버가 타임아웃으로 연결을 종료할 때까지 소통의 오류 발생

[2] Proxies and Hop-by-Hop Headers

• Modern Proxy는 Connection 헤더나 Connection 헤더의 값 전달 X
• Proxy-Authenticate, Proxy-Connection, Transfer-Encoding, Upgrade 등도 전달 X

---

💛 감상 💛

• 오늘도... 고봉밥 텍스트를 소화하기 힘들었습니다. 화요일은 특히 바쁜 날이라, 목표한 분량을 끝까지 읽어낸 것에 의의를 두겠습니다.

• Dumb 프록시가 고유명사인지 일종의 비유 표현인지는 잘 모르겠습니다. 한국말로 직역하면 '멍청한 프록시'인데 그건 좀 아닌 것 같아서 그냥 영어 표현을 그대로 사용했습니다 ㅎ... 실제로 멍청한 프록시를 지칭하는 게 맞습니다만 이게 고유명사가 되는 건 느낌이 좀 다릅니다. 사대주읜가

• 어쨌든 Connection 헤더를 사용하는 Keep-alive 연결이 일부 프록시에서 문제를 일으킬 수 있다는 사실을 알게 되었습니다. 만약 Keep-alive 연결을 사용해야 할 일이 있다면 이 점에 유의하는 것이 좋겠습니다.