Chapter 4. Connection Management
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
❤️ 원문 번역 ❤️
Keep-Alive Operation
Keep-alive is deprecated and no longer documented in the current HTTP/1.1 specification. However, keep-alive handshaking is still in relatively common use by browsers and servers, so HTTP implementors should be prepared to interoperate with it. We’ll take a quick look at keep-alive operation now. Refer to older versions of the HTTP/1.1 specification (such as RFC 2068) for a more complete explanation of keep-alive handshaking.
-
Keep-alive는 권장되지 않으며 현재 HTTP/1.1의 명세에 더 이상 기록되지 않습니다.
-
그러나 Keep-alive 핸드쉐이킹은 브라우저와 서버 사이에서 여전히 흔하게 사용되고 있습니다. 따라서 HTTP를 구현하는 사람들은 이들과의 상호운용에 대비해야 합니다.
-
우리는 Keep-alive 연산에 대해 빠르게 살펴볼 것입니다.
-
Keep-alive 핸드쉐이킹에 대해 보다 완전한 설명을 원한다면 RFC 2068과 같은 구버전의 HTTP/1.1 명세를 참고하기 바랍니다.
Clients implementing HTTP/1.0 keep-alive connections can request that a connection be kept open by including the Connection: Keep-Alive request header.
- HTTP/1.0의 keep-alive 연결을 구현한 클라이언트는 Connection: Keep-Alive 요청 헤더를 포함하여 개방된 연결을 유지하도록 요청할 수 있습니다.
If the server is willing to keep the connection open for the next request, it will respond with the same header in the response (see Figure 4-14). If there is no Connection: keep-alive header in the response, the client assumes that the server does not support keep-alive and that the server will close the connection when the response message is sent back.
-
다음 요청에도 연결을 유지하기를 원하는 서버는 동일한 헤더를 담아 응답할 것입니다. (Figure 4-14)
-
만약 Connection: keep-alive 헤더가 응답에 없다면, 클라이언트는 서버가 keep-alive를 지원하지 않고 응답 메시지를 전송한 뒤 연결을 닫을 것이라고 추정합니다.
Keep-Alive Options
Note that the keep-alive headers are just requests to keep the connection alive. Clients and servers do not need to agree to a keep-alive session if it is requested. They can close idle keep-alive connections at any time and are free to limit the number of transactions processed on a keep-alive connection.
-
keep-alive 헤더는 그저 연결이 유지되도록 요구하는 것입니다.
-
클라이언트와 서버가 keep-alive 세션을 요청 받을 때 이것에 반드시 동의할 필요는 없습니다.
-
사용되지 않는 keep-alive 연결을 아무때나 종료할 수 있고, keep-alive 연결에서 처리되는 트랜잭션 수를 자유롭게 제한할 수 있습니다.
The keep-alive behavior can be tuned by comma-separated options specified in the Keep-Alive general header:
• The timeout parameter is sent in a Keep-Alive response header. It estimates how long the server is likely to keep the connection alive for. This is not a guarantee.
• The max parameter is sent in a Keep-Alive response header. It estimates how many more HTTP transactions the server is likely to keep the connection alive for. This is not a guarantee.
• The Keep-Alive header also supports arbitrary unprocessed attributes, primarily for diagnostic and debugging purposes. The syntax is name [= value].
-
keep-alive 동작은 쉼표로 구분되는 옵션에 의해 튜닝됩니다. 옵션은 Keep-Alive 일반 헤더에 의해 지정됩니다.
-
Keep-Alive 응답 헤더로 전달되는 것에는 timeout 파라미터가 있습니다. 이것은 서버가 연결을 얼마나 지속할 가능성이 있는지 추정합니다. 단 이것이 보장되는 것은 아닙니다.
-
max 파라미터 또한 Keep-Alive 응답 헤더로 전달됩니다. 이것은 서버가 얼마나 더 많은 HTTP 트랜잭션을 위해 연결을 유지할 가능성이 있는지 추정합니다. 이러한 추정 역시 보장되지 않습니다.
-
Keep-Alive 헤더는 진단과 디버깅 목적으로 종종 처리되지 않은 임의의 애트리뷰트를 지원하기도 합니다. 문법은 name [=value]입니다.
The Keep-Alive header is completely optional but is permitted only when Connection: Keep-Alive also is present. Here’s an example of a Keep-Alive response header indicating that the server intends to keep the connection open for at most five more transactions, or until it has sat idle for two minutes:
Connection: Keep-Alive Keep-Alive: max=5, timeout=120
-
Keep-Alive 헤더는 완전히 선택사항이지만 Connection: Keep-Alive가 존재할 때만 유효합니다.
-
아래는 서버가 앞으로 최대 5번의 트랜잭션을 주고받는 동안 혹은 2분 동안 사용되지 않을 때까지 연결을 개방할 의사를 나타내는 Keep-Alive 응답 헤더의 예시입니다.
Connection: Keep-Alive Keep-Alive: max=5, timeout=120
Keep-Alive Connection Restrictions and Rules
Here are some restrictions and clarifications regarding the use of keep-alive connections:
- keep-alive 연결을 사용하는 것에 대한 몇 가지 제한 사항과 설명이 있습니다.
• Keep-alive does not happen by default in HTTP/1.0. The client must send a Connection: Keep-Alive request header to activate keep-alive connections.
-
keep-alive는 HTTP/1.0에서 디폴트로 발생하지 않습니다.
-
클라이언트는 반드시 Connection: Keep-Alive 요청 헤더를 전송하여 keep-alive 연결을 활성화해야 합니다.
• The Connection: Keep-Alive header must be sent with all messages that want to continue the persistence. If the client does not send a Connection: Keep-Alive header, the server will close the connection after that request.
-
Connection: Keep-Alive 헤더는 지속성을 유지하려는 모든 메시지와 함께 전달되어야 합니다.
-
만약 클라이언트가 Connection: Keep-Alive 헤더를 전송하지 않았다면, 서버는 해당 요청 이후 연결을 종료할 것입니다.
• Clients can tell if the server will close the connection after the response by detecting the absence of the Connection: Keep-Alive response header.
- 클라이언트는 Connection: Keep-Alive 응답 헤더의 존재 여부를 확인하여 응답 직후 연결이 종료될 것인지 여부를 알 수 있습니다.
• The connection can be kept open only if the length of the message’s entity body can be determined without sensing a connection close—this means that the entity body must have a correct Content-Length, have a multipart media type, or be encoded with the chunked transfer encoding. Sending the wrong Content-Length back on a keep-alive channel is bad, because the other end of the transaction will not be able to accurately detect the end of one message and the start of another.
-
연결은 메시지의 엔티티 본문 길이가 결정될 때만 연결의 종료를 감지하지 않고 유지될 수 있습니다.
-
이것은 엔티티 본문이 올바른 Content-Length나 미디어 타입을 가지고 있거나, 묶음 전송 인코딩 방식으로 인코딩 되어야 함을 의미합니다.
-
잘못된 Content-Length를 keep-alive 채널로 돌려보내는 것은 좋지 않습니다. 트랜잭션의 다른 엔드포인트가 한 메시지의 끝과 다음 메시지의 시작을 정확하게 확인할 수 없기 때문입니다.
• Proxies and gateways must enforce the rules of the Connection header; the proxy or gateway must remove any header fields named in the Connection header, and the Connection header itself, before forwarding or caching the message.
- 프록시와 게이트웨이는 Connection 헤더의 규칙을 적용해야 합니다. 프록시나 게이트웨이는 메시지를 포워딩 혹은 캐싱하기 전에 Connection 헤더에 적힌 모든 헤더 필드와 Connection 헤더 자체를 삭제해야 합니다.
• Formally, keep-alive connections should not be established with a proxy server that isn’t guaranteed to support the Connection header, to prevent the problem with dumb proxies described below. This is not always possible in practice.
-
공식적으로 keep-alive 연결은 Connection 헤더의 지원이 보장되지 않는 프록시 서버와 양립해서는 안 됩니다. 하단에 설명되는 dumb 프록시 문제를 예방하기 위함입니다.
-
그러나 실전에서 항상 이것이 가능한 것은 아닙니다.
** dumb 프록시 문제는 다음 포스팅에 등장합니다.
• Technically, any Connection header fields (including Connection: Keep-Alive) received from an HTTP/1.0 device should be ignored, because they may have been forwarded mistakenly by an older proxy server. In practice, some clients and servers bend this rule, although they run the risk of hanging on older proxies.
-
기술적으로 HTTP/1.0 장치로부터 받은 모든 Connection 헤더 필드(Connection: Keep-Alive 포함)는 무시되어야 합니다.
-
오래된 프록시 서버에 의해 우발적으로 포워딩될 가능성이 있기 때문입니다.
-
그러나 일부 클라이언트와 서버는 오래된 프록시에 시달릴 위험을 안고 있더라도 이러한 규칙을 우회합니다.
• Clients must be prepared to retry requests if the connection closes before they receive the entire response, unless the request could have side effects if repeated.
- 클라이언트는 전체 응답을 받기 전에 연결이 종료되는 경우, 반복 요청이 부작용을 일으킬 가능성이 없는 한 요청을 재전송할 준비가 되어있어야 합니다.
🧡 요약 정리 🧡
HTTP/1.0+ Keep-Alive Connections
- 지속 연결의 실험적인 초기 형태
- HTTP/1.1과의 상호운용 문제로 어려움을 겪었으나 여전히 많이 사용
- 연결 설정과 종료에 의한 오버헤드 감소 -> 타임라인 압축
[1] Response Headers for Keep-Alive
Connection: Keep-Alive
Keep-Alive: max=5, timeout=120- Keep-Alive : 서버가 연결 유지를 희망함을 의미
- max : 연결이 지속되는 동안 전송할 것으로 추정되는 최대 트랜잭션 수
- timeout : 연결을 유지하기 위해 추정되는 최대 유휴 시간
[2] Restrictions and Rules
- 클라이언트가 Connection: Keep-Alive를 보내야 지속 연결 활성화
- 클라이언트는 Connection: Keep-Alive 응답을 통해 지속 여부 확인
- 올바른 Content-Length를 알 수 있어야 연결 유지 가능
- 프록시나 게이트웨이는 Connetion 헤더를 처리한 후 삭제
- HTTP/1.0 장치로부터 받은 모든 Connection 헤더 필드는 무시하는 것이 원칙
- 전체 응답을 받기 전에 연결이 종료되는 경우, 반복 요청이 부작용을 일으키지 않는 한 요청 재전송 준비
💛 감상 💛
-
Keep-Alive 연결에 대해서는 지금껏 자세히 배운 적이 없습니다. Connection 헤더를 주고받으면서 연결을 유지할 수 있다는 사실을 오늘 처음 알게 되었습니다. 오늘날의 HTTP/1.1 Persistent Connection은 Keep-Alive와 과연 어떤 차이점이 있을지 궁금해집니다.
-
주말 동안 게시글을 안 올렸더니 되게 오랜만에 쓰는 기분입니다. 사정이 있어서 고작 3일 안 썼을 뿐인데 매일 두 페이지씩 글을 읽던 습관이 와르르 무너진 것 같습니다. 얼마나 집중이 안 되는지.... 오늘부터 다시 마음을 다잡아 보겠습니다.
