Chapter 4. Connection Management
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
❤️ 원문 번역 ❤️
Pipelined Connections
HTTP/1.1 permits optional request pipelining over persistent connections. This is a further performance optimization over keep-alive connections. Multiple requests can be enqueued before the responses arrive. While the first request is streaming across the network to a server on the other side of the globe, the second and third requests can get underway. This can improve performance in high-latency network conditions, by reducing network round trips.
-
HTTP/1.1은 Persistent 연결을 통한 선택적인 요청 파이프라이닝을 허용합니다.
-
이것은 keep-alive 연결 이상의 성능 최적화입니다.
-
응답이 도착하기 전 여러 개의 요청을 대기열에 넣을 수 있습니다.
-
첫 번째 요청이 네트워크를 따라 지구 반대편의 서버로 흘러 들어가는 동안 두 번째와 세 번째 요청이 진행될 수 있습니다.
-
이것은 네트워크의 왕복을 줄여 지연 시간이 긴 네트워크 환경에서 성능을 향상시킬 수 있습니다.
Figure 4-18a-c shows how persistent connections can eliminate TCP connection delays and how pipelined requests (Figure 4-18c) can eliminate transfer latencies.
- Figure 4-18a-c는 Persistent 연결이 TCP 연결 지연을 제거하고, 파이프라이닝된 요청이 전송 지연을 감소시키는 방법(Figure 4-18c)을 보여줍니다.
There are several restrictions for pipelining:
- 파이프라이닝에는 몇 가지 제한 사항이 있습니다.
- HTTP clients should not pipeline until they are sure the connection is persistent.
- HTTP 클라이언트는 연결이 지속적인지 확인할 때까지 파이프라인을 생성하지 않아야 합니다.
- HTTP responses must be returned in the same order as the requests. HTTP messages are not tagged with sequence numbers, so there is no way to match responses with requests if the responses are received out of order.
-
HTTP 응답은 요청과 동일한 순서로 반환되어야 합니다.
-
HTTP 메시지가 Sequence 번호로 태그되어 있지 않기 때문에, 응답이 순서에 맞게 수신되지 않으면 응답과 요청을 매칭할 수 없습니다.
- HTTP clients must be prepared for the connection to close at any time and be prepared to redo any pipelined requests that did not finish. If the client opens a persistent connection and immediately issues 10 requests, the server is free to close the connection after processing only, say, 5 requests. The remaining 5 requests will fail, and the client must be willing to handle these premature closes and reissue the requests.
-
HTTP 클라이언트는 언제든 연결이 종료될 수 있도록 준비하고 아직 완료되지 않은 모든 파이프라이닝 된 요청들을 다시 실행할 수 있게 해야 합니다.
-
만약 클라이언트가 Persistent 연결을 열고 즉시 10개의 요청을 발생시킨다면, 서버는 예를 들어 오직 5개의 요청만 처리한 후 자유롭게 연결을 닫을 수 있습니다.
-
나머지 5개의 요청은 실패할 것이고 클라이언트는 이러한 조기 종료를 제어하고 요청을 재발행할 수 있어야 합니다.
- HTTP clients should not pipeline requests that have side effects (such as POSTs). In general, on error, pipelining prevents clients from knowing which of a series of pipelined requests were executed by the server. Because nonidempotent requests such as POSTs cannot safely be retried, you run the risk of some methods never being executed in error conditions.
-
HTTP 클라이언트는 POST와 같이 부작용을 가진 요청을 파이프라이닝 해서는 안 됩니다.
-
일반적으로 오류 상황에서는 파이프라이닝을 사용하면 클라이언트가 일련의 파이프라이닝 된 요청 중 어떤 요청이 서버에 의해 실행되는지 알지 못합니다.
-
POST와 같은 비멱등적인 요청은 안전하게 재전송되지 않기 때문에 오류 상황에서는 몇몇 메소드가 영영 실행되지 않는 위험을 지게 됩니다.
(** 멱등성 : 한 번 적용되고 나면 그 이후에는 적용되지 않는 성질)
🧡 요약 정리 🧡
Pipelined Connections
- 여러 개의 요청을 여러 개의 Persistent 연결을 통해 전송하는 방법
- 전송 지연 감소 : 네트워크 왕복을 줄여 지연 시간이 긴 네트워크에서 성능 향상
Restrictions
- 클라이언트는 Persistent 연결인지 확인하기 전까지 파이프라인 생성 불가
- HTTP 응답은 요청과 같은 순서로 반환
- 클라이언트는 언제든 요청을 종료할 수 있도록 준비해야 하고, 완료되지 않은 모든 파이프라이닝 된 요청을 재발송 할 수 있어야 한다
- 부작용을 가진 요청(POST 등)을 파이프라이닝 해서는 안 된다
💛 감상 💛
-
Pipelining이 Persistent 연결이 아닐 때도 될 수 있을 거라고 생각했는데, 제한이 걸려 있다는 사실을 알게 되었습니다.
-
HTTP/1.1이 연결 지연과 전송 지연을 줄이기 위해 Persistent 연결과 Pipelining을 적극적으로 활용하고 있음을 알게 되었습니다. 그리고 이것이 Serial 연결에 비해 얼마나 빠른 시간 내로 요청을 처리할 수 있는지 Table 4-18을 통해 확인할 수 있었습니다.
