Chapter 4. Connection Management
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
❤️ 원문 번역 ❤️
HTTP Connection Handling
The first two sections of this chapter provided a firehose tour of TCP connections and their performance implications. If you’d like to learn more about TCP network- ing, check out the resources listed at the end of the chapter.
-
이 챕터의 처음 두 섹션은 TCP 연결과 성능의 의미에 관해 이야기했다.
-
TCP 네트워킹에 대해 더 자세히 공부하고 싶다면 챕터 마지막에 열거된 리소스를 참고하기 바랍니다.
We’re going to switch gears now and get squarely back to HTTP. The rest of this chapter explains the HTTP technology for manipulating and optimizing connections. We’ll start with the HTTP Connection header, an often misunderstood but important part of HTTP connection management. Then we’ll talk about HTTP’s connection optimization techniques.
-
우리는 이제 기어를 바꾸어 HTTP로 다시 돌아갑니다.
-
이번 챕터의 남은 부분은 연결을 관리하고 최적화하기 위한 HTTP 기술들을 설명합니다.
-
가장 먼저 HTTP Connection 헤더부터 시작합니다. 이것은 종종 잘못 이해되지만 HTTP 연결 관리에서 중요한 요소입니다.
-
그럼 HTTP의 연결 최적화 기술에 대해 이야기해봅시다.
The Oft-Misunderstood Connection Header
HTTP allows a chain of HTTP intermediaries between the client and the ultimate origin server (proxies, caches, etc.). HTTP messages are forwarded hop by hop from the client, through intermediary devices, to the origin server (or the reverse).
-
HTTP는 클라이언트와 최종 origin 서버(프록시, 캐시 등) 사이의 HTTP 매개 체인을 허용합니다.
-
HTTP 메시지는 매개 장치를 통해 클라이언트로부터 최종 서버로 (혹은 반대 방향으로) hop 단위로 전송됩니다.
In some cases, two adjacent HTTP applications may want to apply a set of options to their shared connection. The HTTP Connection header field has a comma-separated list of connection tokens that specify options for the connection that aren’t propagated to other connections. For example, a connection that must be closed after sending the next message can be indicated by Connection: close.
-
경우에 따라 인접한 두 HTTP 응용 프로그램은 공유된 연결에 몇 가지 옵션을 적용하려 할 수 있습니다.
-
HTTP Connection 헤더 필드는 다른 연결로 전파되지 않는 연결에 대해 연결 토큰 리스트를 갖고 있습니다. 이것은 옵션을 특정화하며 각각의 연결 토큰을 쉼표로 구분합니다.
-
예를 들어 다음 메시지를 전송 후 종료되어야 하는 연결은 Connection에 의해 close로 표현될 수 있습니다.
The Connection header sometimes is confusing, because it can carry three different types of tokens:
• HTTP header field names, listing headers relevant for only this connection
• Arbitrary token values, describing nonstandard options for this connection
• The value close, indicating the persistent connection will be closed when done
-
Connection 헤더는 종종 혼란을 야기합니다. 서로 다른 세 가지 유형의 토큰을 전송할 수 있기 때문입니다.
-
오직 해당 연결에만 관련된 HTTP 헤더 필드 이름
-
연결에 대한 비표준 옵션을 나타내는 임의의 토큰 값
-
영구적인 연결이 닫힐 것임을 나타내는 종료 값
If a connection token contains the name of an HTTP header field, that header field contains connection-specific information and must not be forwarded. Any header fields listed in the Connection header must be deleted before the message is forwarded. Placing a hop-by-hop header name in a Connection header is known as “protecting the header,” because the Connection header protects against accidental forwarding of the local header. An example is shown in Figure 4-9.
-
만약 연결 토큰이 HTTP 헤더 필드의 이름을 포함하고 있다면, 그 헤더필드는 구체적인 연결 정보를 포함하고 있으므로 전달되지 않아야 합니다.
-
Connection 헤더에 나열된 모든 헤더 필드는 메시지가 전송되기 전 반드시 삭제되어야 합니다.
-
Connection 헤더에 홉 단위로 헤더 이름을 적는 것은 "헤더를 보호하는 행위"로 알려져 있습니다. Connection 헤더가 로컬 헤더의 우발적인 전송을 방지하기 때문입니다.
-
이에 관한 예시가 Figure 4-9에 나타납니다.
When an HTTP application receives a message with a Connection header, the receiver parses and applies all options requested by the sender. It then deletes the Connection header and all headers listed in the Connection header before forwarding the message to the next hop. 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. These include Proxy-Authenticate, Proxy-Connection, Transfer-Encoding, and Upgrade. For more about the Connection header, see Appendix C.
-
HTTP 응용 프로그램이 Connection 헤더를 가진 메시지를 받을 때, 수신단은 송신단에게 요청받은 모든 옵션들을 파싱하여 적용합니다.
-
그리고 메시지를 다음 홉으로 전달하기 전 Connection 헤더와 Connection 헤더에 나열된 모든 헤더들을 삭제합니다.
-
Connection 헤더 값에 나열되지 않은 홉 단위의 헤더가 존재할 수도 있지만 그것들이 프록시 서버를 통과해서는 안 됩니다.
-
이러한 헤더에는 Proxy-Authenticate, Proxy-Connection, Transfer-Encoding, Upgrade가 있습니다.
-
Connection 헤더에 대해 자세히 알고 싶다면 Appendix C를 참조하기 바랍니다.
Serial Transaction Delays
TCP performance delays can add up if the connections are managed naively. For example, suppose you have a web page with three embedded images. Your browser needs to issue four HTTP transactions to display this page: one for the top-level HTML and three for the embedded images. If each transaction requires a new connection, the connection and slow-start delays can add up (see Figure 4-10).
-
연결이 단순하게 관리될 때 TCP의 성능 지연이 누적됩니다.
-
예를 들어 여러분이 세 개의 임베디드 이미지를 포함한 웹 페이지를 가지고 있다고 가정해봅시다.
-
브라우저는 이 페이지를 화면에 표시하기 위해 4개의 HTTP 트랜잭션을 발생시켜야 합니다. 하나는 최상단의 HTML 문서, 나머지 3개는 임베디드 이미지에 대한 트랜잭션일 것입니다.
-
각각의 트랜잭션이 새 연결을 필요로 한다면 연결 설정 및 Slow-start 지연이 누적될 수 있습니다. (Figure 4-10)
In addition to the real delay imposed by serial loading, there is also a psychological perception of slowness when a single image is loading and nothing is happening on the rest of the page. Users prefer multiple images to load at the same time.
-
직렬 로딩에 의해 적재된 지연과 더불어, 한 이미지가 로딩되고 나머지 페이지에서는 아무런 일도 발생하지 않으면 심리적으로 더 느리다고 인식하기도 합니다.
-
사용자는 여러 개의 이미지를 동시에 로딩하는 것을 더 선호합니다.
Another disadvantage of serial loading is that some browsers are unable to display anything onscreen until enough objects are loaded, because they don’t know the sizes of the objects until they are loaded, and they may need the size information to decide where to position the objects on the screen. In this situation, the browser may be making good progress loading objects serially, but the user may be faced with a blank white screen, unaware that any progress is being made at all.
-
직렬 로딩은 일부 브라우저가 충분한 객체가 로딩될 때까지 화면에 아무것도 표시할 수 없게 한다는 점에서 또다른 한계점을 가집니다. 객체가 로딩될 때까지 객체의 크기를 알지 못하는 한편 객체를 어디에 배치할지 결정하기 위해서는 크기 정보가 필요할지도 모르기 때문입니다.
-
이런 상황에서는 브라우저가 객체 직렬 로딩을 잘 수행하고 있다고 하더라도, 사용자가 그 사실을 전혀 알지 못한 채 텅 빈 흰 화면을 마주하게 됩니다.
Several current and emerging techniques are available to improve HTTP connection performance. The next several sections discuss four such techniques:
Parallel connections
Concurrent HTTP requests across multiple TCP connectionsPersistent connections
Reusing TCP connections to eliminate connect/close delaysPipelined connections
Concurrent HTTP requests across a shared TCP connectionMultiplexed connections
Interleaving chunks of requests and responses (experimental)
-
현재는 새롭게 부상한 몇 가지 HTTP 연결 성능 개선 기술들을 사용할 수 있습니다. 다음의 섹션은 4가지 신기술에 대해 이야기합니다.
-
Parallel Connections
- HTTP 요청을 여러 개의 TCP 연결에서 병렬적으로 처리 -
Persistent Connections
- 연결/종료 지연을 제거하기 위한 TCP 연결 재사용 -
Pipelined Connections
- 공유된 하나의 TCP 연결을 통해 HTTP 요청을 동시적으로 처리 -
Multiplexed Connections
- 요청 응답 덩어리를 인접하지 않게 다중화하여 처리 (experimental)
🧡 요약 정리 🧡
HTTP Connection Handling
[1] Connection Header
: 로컬 헤더의 우발적인 전송을 방지하여 헤더 보호
Connection: { HTTP header field }, { Arbitrary Token }, close- HTTP header field : 해당 연결에 대한 구체적인 정보를 포함한 값 -> 다음 홉으로 전달하기 전 삭제 (여러 개일 수도 있다)
- Arbitrary Token : 연결에 대한 비표준 옵션 -> 다음 홉으로 전달하기 전 파싱하여 적용 (여러 개일 수도 있다)
- close : 메시지 전송 후 종료
- Proxy-Authenticate, Proxy-Connection, Transfer-Encoding, Upgrade 등의 헤더는 프록시 서버 통과 금지
[2] Emerging Techniques for HTTP Performance
: TCP 연결 설정 및 Slow-start로 인한 직렬 로딩 지연 문제를 해결하는 기술
(** 책에 나오지 않는 내용을 일부 포함하였습니다)
-
Parallel Connection : 요청을 여러 개의 TCP 연결에서 처리하는 것
-
Persistent Connection : TCP 연결을 재사용하는 것
-
Pipelined Connection : 하나의 TCP 연결을 통해 요청을 동시에 전송하는 것 -> 요청에 대한 응답이 오지 않아도 다음 요청 전송 가능, 대신 요청을 받은 순서대로 응답 전송
-
Multiplexed Connection : 하나의 TCP 연결을 통해 요청과 응답을 다중화하여 전송하는 것 -> 요청에 대한 응답이 오지 않아도 다음 요청 전송 가능, 요청을 받은 순서와 무관하게 준비된 응답부터 먼저 전송 가능 (오늘날 HTTP/2의 주요 기술)
💛 감상 💛
-
지금까지 Conenction 헤더가 뭔지 잘 몰랐는데 책을 읽으니 잘 이해가 됐다. 옵션, 즉 Token에 어떤 것이 들어갈 수 있는지는 잘 모르겠지만 이 부분은 추후에 Appendix C 부분을 다시 읽어보려고 한다.
-
Pipelined Connection과 Multiplexed Connection의 차이를 정확히 짚고 넘어가기 위해 예전에 수강했던 네트워크 관련 강의 자료를 참고했다. 희미하게 기억이 남았던 것을 이번 기회에 되짚어 볼 수 있어 좋았다.
