[TIL] HTTP : The Definitive Guide "p97 ~ p99"

시윤·2024년 3월 21일
0

[TIL] Two Pages Per Day

목록 보기
43/108
post-thumbnail

Chapter 4. Connection Management

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


❤️ 원문 번역 ❤️

HTTP/1.1 Persistent Connections

HTTP/1.1 phased out support for keep-alive connections, replacing them with an improved design called persistent connections. The goals of persistent connections are the same as those of keep-alive connections, but the mechanisms behave better.

  • HTTP/1.1은 keep-alive 연결에 대한 지원을 단계적으로 중단하여 persistent 연결이라고 불리는 개선된 설계로 대체했습니다.

  • persistent 연결의 목표는 keep-alive 연결과 동일하지만 매커니즘을 개선하는 것입니다.

Unlike HTTP/1.0+ keep-alive connections, HTTP/1.1 persistent connections are active by default. HTTP/1.1 assumes all connections are persistent unless otherwise indicated. HTTP/1.1 applications have to explicitly add a Connection: close header to a message to indicate that a connection should close after the transaction is com- plete. This is a significant difference from previous versions of the HTTP protocol, where keep-alive connections were either optional or completely unsupported.

  • HTTP/1.0+ keep-alive 연결과 달리 HTTP/1.1의 persistent 연결은 디폴트로 활성화됩니다.

  • HTTP/1.1은 특별한 표시가 없는 한 모든 연결이 영구적이라고 가정합니다.

  • 트랜잭션이 완료된 후 연결을 종료해야 함을 나타내기 위해서는 HTTP/1.1 응용 프로그램이 명시적으로 Connection: close 헤더를 메시지에 추가해야 합니다.

  • 이것이 이전 HTTP 프로토콜에서 선택적으로 지원하거나 완전히 지원되지 않았던 keep-alive 연결과의 큰 차이점입니다.

An HTTP/1.1 client assumes an HTTP/1.1 connection will remain open after a response, unless the response contains a Connection: close header. However, clients and servers still can close idle connections at any time. Not sending Connection: close does not mean that the server promises to keep the connection open forever.

  • HTTP/1.1 클라이언트는 Connection: close 헤더를 포함한 응답을 받지 않는다면 응답 직후 HTTP/1.1 연결이 유지될 것이라고 가정합니다.

  • 그러나, 클라이언트와 서버는 여전히 아무때나 사용되지 않는 연결을 종료할 수 있습니다.

  • Connection: close를 전송하지 않는다고 하여 서버가 영구적으로 연결을 지속하는 것은 아닙니다.


Persistent Connection Restrictions and Rules

Here are the restrictions and clarifications regarding the use of persistent connections:

  • Persistent 연결의 사용에 관한 몇 가지 제한과 설명이 있습니다.
  • After sending a Connection: close request header, the client can’t send more requests on that connection.
  • Connection: Close 요청 헤더를 전송한 후에는 클라이언트가 이 연결에 더 이상 요청을 전송하지 않습니다.
  • If a client does not want to send another request on the connection, it should send a Connection: close request header in the final request.
  • 클라이언트가 주어진 연결에 더 이상 전송할 것이 없다면 마지막 요청에 Connection: close 요청 헤더를 포함한 후 전송해야 합니다.
  • The connection can be kept persistent only if all messages on the connection have a correct, self-defined message length—i.e., the entity bodies must have correct Content-Lengths or be encoded with the chunked transfer encoding.
  • 연결의 모든 메시지가 정확한 self-defined 메시지 길이를 가질 때에만 연결을 지속할 수 있습니다. (엔티티 본문은 정확한 Content-Lengths를 가지거나 묶음 전송 인코딩으로 인코딩되어야 합니다.)
  • HTTP/1.1 proxies must manage persistent connections separately with clients and servers—each persistent connection applies to a single transport hop.
  • HTTP/1.1 프록시는 클라이언트와 서버를 Persistent 연결을 별도로 관리해야 합니다/

  • 각각의 Persistent 연결은 단일한 전송 hop에 적용합니다.

  • HTTP/1.1 proxy servers should not establish persistent connections with an HTTP/1.0 client (because of the problems of older proxies forwarding Connection headers) unless they know something about the capabilities of the client. This is, in practice, difficult, and many vendors bend this rule.
  • HTTP/1.1 프록시 서버는 클라이언트의 능력에 대해 알고 있지 않다면 HTTP/1.0 클라이언트와 Persistent 연결을 설정해서는 안 됩니다(구형 프록시가 Connection 헤더를 포워딩하는 문제가 있기 때문).

  • 실제로 이것은 어렵고 많은 공급 업체가 이 규칙을 고수하지 않습니다.

  • Regardless of the values of Connection headers, HTTP/1.1 devices may close the connection at any time, though servers should try not to close in the middle of transmitting a message and should always respond to at least one request before closing.
  • HTTP/1.1 장치는 Connection 헤더의 값에 관계없이 언제든 연결을 종료할 수 있습니다.

  • 하지만 서버는 메시지 전송 중에 연결을 종료하지 않도록 해야 하며 항상 연결을 종료하기 전 하나 이상의 요청에 응답해야 합니다.

  • HTTP/1.1 applications must be able to recover from asynchronous closes. Clients should retry the requests as long as they don’t have side effects that could accumulate.
  • HTTP/1.1 응용 프로그램은 비동기 종료로부터 복구할 수 있어야 합니다.

  • 클라이언트는 누적될 수 있는 부작용이 없다면 요청을 재시도해야 합니다.

  • 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.
  • 클라이언트는 요청을 반복하는 것이 부작용을 야기하지 않는 한 전체 응답을 받기 전 연결이 종료될 경우 재요청을 준비해야 합니다.
  • A single user client should maintain at most two persistent connections to any server or proxy, to prevent the server from being overloaded. Because proxies may need more connections to a server to support concurrent users, a proxy should maintain at most 2N connections to any server or parent proxy, if there are N users trying to access the servers.
  • 임의의 서버나 프록시에 대하여 한 유저 클라이언트의 최대 persistent 연결 개수는 최대 2개여야 합니다. 서버에 과부하가 걸리는 것을 방지하기 위함입니다.

  • 프록시는 동시에 여러 유저들을 지원하기 위해 더 많은 연결을 필요로 할 수 있습니다.

  • 프록시는 서버에 접근을 시도하는 N명의 유저가 있다면 최대 2N 개의 연결을 임의의 서버나 부모 프록시에 유지해야 합니다.


🧡 요약 정리 🧡

HTTP/1.1 Persistent Connections

  • keep-alive와 동일한 목적으로 사용 (지속 연결)
  • HTTP/1.1의 연결은 디폴트로 Persistent
  • 클라이언트와 서버는 원하는 때에 언제든 지속 연결 종료 가능

[1] Response Header for Closing Connection

Connection: close

[2] Persistent Connection Restrictions and Rules

    1. close 헤더를 전송한 후에는 클라이언트가 더 이상 요청 전송 X
    1. 클라이언트가 더 이상 전송할 것이 없으면 close 전송
    1. 올바른 Content-Length를 알 수 있어야 연결 유지 가능
    1. HTTP/1.1 프록시는 클라이언트와 서버의 persistent 연결 별도 관리
    1. HTTP/1.1 프록시는 HTTP/1.0과 persistent 연결을 설정하지 않는 것이 원칙
    1. HTTP/1.1 장치는 Connection 헤더의 값에 관계없이 언제든 연결을 종료할 수 있지만 서버는 메시지 전송 중에 연결을 종료하지 않아야 하며 항상 연결을 종료하기 전 하나 이상의 요청에 응답해야 함
    1. HTTP/1.1 응용 프로그램은 비동기 종료로부터 복구 가능해야 함
    1. 전체 응답을 받기 전에 연결이 종료되는 경우, 반복 요청이 부작용을 일으키지 않는 한 요청 재전송 준비
    1. 서버 과부하 방지를 위해 클라이언트의 persistent 연결 개수는 최대 2개

💛 감상 💛

  • keep-alive 연결과 달리 persistent 연결은 디폴트로 설정되며 종료시에 Connection: close 헤더를 전송한다는 사실을 알게 되었습니다. 글을 읽다 보니 HTTP/1.0 장치과 HTTP/1.1 장치가 지속 연결로 통신하기 위해서는 마땅한 방법이 없는 건가 하는 생각이 들었습니다. 어쩌면 성능을 올리기 위해서는 그냥 낡아빠진 장치를 바꾸는 게 제일 빠를 수도 있을 것 같아요. 근데 요즘에도 HTTP/1.0 장치가 많이 있을지는 잘 모르겠습니다.

  • 뒷부분 분량을 미리 살펴봤는데 다음 포스팅은 진짜 짧을 것 같습니다. 다음 포스팅 포함해서 앞으로 3편이면 Chapter 4가 마무리됩니다. Chapter 4가 마무리되면 Part도 바뀝니다. (지금까지는 'Part 1. HTTP: The Web's Foundation'이었습니다.) 내일이면 페이지 수로도 100페이지를 찍을 것 같고요...! 하루에 두 페이지씩 읽기를 시작한 지 이제 두 달 정도 됐는데, 글을 안 쓴 날이 며칠 정도 있다 보니 이제서야 100페이지를 읽습니다. 새로 시작하는 마음으로 더 분발해 보겠습니다.

profile
맑은 눈의 다람쥐

0개의 댓글

관련 채용 정보