> For the complete documentation index, see [llms.txt](https://hochan049.gitbook.io/cs-interview/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hochan049.gitbook.io/cs-interview/web/rfc-7320/6.-connection-management.md). # 6. Connection Management HTTP 메시징은 기반을 이루는 전송 또는 세션 계층 커넥션 프로토콜과 독립적이다. HTTP는 in-order 요청 전송과 그에 상응하는 in-order 응답 전송이 있는 신뢰할 수 있는 전송만 가정 한다. HTTP 구현은 현재 커넥션 상태 유지, 새 커넥션 설정 또는 기존 커넥션 재사용, 커넥션에서 수신된 메시지 처리, 커넥션 실패 탐지 및 각 커넥션을 닫는 것을 포함하는 커넥션 관리에 책임질 것으로 예상된다. 대부분의 클라이언트는 서버 엔드포인트당 두개 이상의 커넥션을 포함하여 여러 커넥션을 병렬로 유지한다. #### 6.1 Connection “Connection” 헤더 필드를 통해 발신자는 현재 커넥션에 대해 원하는 제어 옵션을 표시할 수 있다. * 메시지를 전달하기 전에, 프락시 또는 게이트웨이가 수신된 커넥션 옵션을 반드시 제거하거나 바꾸어야 한다. (MUST) [`Connection`](https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Connection) 와 [`Keep-Alive`](https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Keep-Alive) 같은 연결-지정(Connection-specific) 헤더 필드들은 [HTTP/2.에서 금지되었습니다](https://tools.ietf.org/html/rfc7540#section-8.1.2.2). 크롬과 파이어폭스는 HTTP/2 응답에서 그들을 무시하지만, 사파리는 HTTP/2 규격 요건에 따라 해당 필드가 포함된 응답은 처리하지 않습니다. - MDN - * 현재 커넥션에 대한 제어 정보를 제공하기 위해 Connection 이외의 헤더 필드를 사용할 경 우, 발신자는 Connection 헤더 필드에 해당 필드 이름을 반드시 나열해야 한다.(MUST) * 프락시 또는 게이트 웨이는 메시지를 전달하기 전에 수신된 Connection 헤더 필드를 분석해야 하며 (MUST) 이 필드의 각 connection-option에 대해 connection-option과 동일한 이름을 가진 메시지에서 헤더 필드를 제거한 다음 Connection 헤더 필드 자체를 제거한다.(또는 전송된 메시지를 위해 중개자의 자체 커넥션 옵션들과 함께 Connection 헤더 필드를 대체한다) 따라서, Connection 헤더 필드는 직접적인 수신자("hop-by-hop")만을 위한 헤더 필드를 체 인의 모든 수신자를 위한 필드("end-to-end")와 구분하여 메시지를 자체 설명할 수 있다. Connection option은 대소문자를 구분하지 않는다. * 발신자는 페이 로드의 모든 수신자를 위한 헤더 필드에 해당하는 커넥션 옵션을 보내면 안된다. (MUST NOT) * 영속적 커넥션을 지원하지 않는 클라이언트는 모든 요청 메시지에서 “close" 커넥션 옵션을 보내야 한다.(MUST) * 영속적 커넥션을 지원하지 않는 서버는 1xx (Informational) 상태 코드가 없는 모든 응답 메시지에서 “close" 커넥션 옵션을 보내야 한다.(MUST) #### 6.2 Establishment 다양한 전송 또는 세션 계층 프로토콜을 통해 커넥션을 설정하는 방법을 설명하는 것은 이 규격의 범위를 벗어난다. 각 커넥션은 하나의 전송 링크에만 적용된다. #### 6.3 Persistence HTTP/1.1은 기본적으로 “persistent connections” 을 사용하여 여러 요청과 응답을 단일 커넥션에서 수행할 수 있도록 한다. “close” 커넥션 옵션은 현재 요청/응답 후 커넥션이 지속되지 않음을 알리는 데 사용된다. * HTTP 구현은 영속적 커넥션을 지원해야 한다. (SHOULD) * 서버는 응답을 보낸 후 요청 메시지 본문 전체를 반드시 읽거나 또는 커넥션을 닫아야 한다.(MUST) * 후속 요청에 대해 동일한 커넥션을 재사용하려고 한다면 응답 메시지 본문 전체를 읽어야 한다.(MUST) * 프락시 서버는 HTTP/1.0 클라이언트와 영속적 커넥션을 유지해서는 안 된다.(MUST NOT) #### 6.3.1 Retrying Requests 커넥션은 의도가 있거나 없거나 언제든지 닫힐 수 있다. 비동기적으로 닫히는 상황으로부터 복구하기 위한 요구를 만족해야 한다. * 프록시는 비멱등 요청을 자동으로 재시도하면 안된다.(MUST NOT) #### 6.3.2 Pipelining ![](/files/-MT-nW29gb9g7JKQRFze) 영속적 커넥션을 지원하는 클라이언트를 “pipeline”으로 만들 수 있다.(MAY) (즉, 각 응답을 기다리지 않고 여러 요청을 보낼 수 있음). * 서버는 요청이 안전한 메서드(\[RFC7231]의 Section 4.2.1)인 경우 연속의 파이프 라인 요청을 병렬로 처리할 수 있지만, 다만 요청을 받은 순서대로 해당 응답을 전송해야 한다.(MUST) * 클라이언트는 커넥션 설립 직후 파이프라인을 처리해서는 안 된다.(MUST NOT) {% embed url="" %} {% embed url="" %} HTTP/2.x 이 나오면서 멀티플랙싱 알고리즘으로 대체됐다. #### 6.4 Concurrency 클라이언트는 주어진 서버로 유지하는 동시에 열려 있는 커넥션 수를 제한해야 한다. #### 6.5 Failures as Timeouts #### 6.6 Tear-down * “close” 커넥션 옵션을 보낸 클라이언트는 추가 요청을 보내지 않아야 하며(MUST NOT), * (“close” 가 포함된 경우) 이 요청에 해당하는 최종 응답 메시지를 읽은 후 커넥션을 반드시 닫아야 한다.(MUST) * “close” 커넥션 옵션을 수신한 서버는 “close”가 포함된 요청에 대한 최종 응답을 발송한 후 커넥션 종료를 시작해야 한다.(MUST) #### 6.7 Upgrade “Upgrade” 헤더 필드는 HTTP/1.1에서 동일한 커넥션의 다른 프로토콜로 전환하기 위한 간단한 메커니즘을 제공하기 위한 것이다. * 101 (Switching Protocols) 응답을 전송하는 서버는 반드시 커넥션 전환 대상의 새 프로토콜 을 나타내기 위해 Upgrade 헤더 필드를 전송해야 한다.(MUST) * 다중 프로토콜 계층이 전환되는 경우 발신자는 계층 구분 순서로 프로토콜을 나열해야 한다.(MUST) * 서버는 해당 요청의 Upgrade 헤더 필드에 클라이언트에 의해 표시하지 않은 프로토콜로 전환해서는 안 된다. (MUST NOT) * 426(Upgrade Required) 응답을 전송하는 서버는 내림차순 기본 설정 순서로 허용가능한 프로토콜을 나타내기 위해 Upgrade 헤더 필드를 전송해야 한다.(MUST) 101(Switching Protocols) 응답을 전송한 직후, 서버는 마치 새로운 프로토콜 내에서 그에 상응하는 것을 받은 것처럼 원래의 요청에 계속 대응할 것으로 예상된다(즉, 프로토콜 변경 후에도 서버가 충족해야 할 미결 요청을 여전히 가지고 있으며, 요구하지 않고 이를 수행할 것으로 예상된다). HTTP/1.1 101 Switching Protocols \ Connection: upgrade\ Upgrade: HTTP/2.0 \[... data stream switches to HTTP/2.0 with an appropriate response (as defined by new protocol) to the "GET /hello.txt" request ...] Upgrade 헤더 필드가 전송되면, 발신자는 나열된 프로토콜을 구현하지 않을 수도 있는 중개 자에 의해 Upgrade가 실수로 전달되는 것을 방지하기 위해 “upgrade” 커넥션 옵션이 포함된 Connection 헤더 필드(Section 6.1)도 전송해야 한다.(MUST) * 서버가 “100-continue” 예상과 Upgrade 및 Expect 헤더 필드(\[RFC7231]의 Section 5.1.1)를 모두 수신하는 경우, 서버는 101 (Switching Protocols) 응답을 보내기 전에 반드시 100 (Continue) 응답을 보내야 한다.(MUST) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://hochan049.gitbook.io/cs-interview/web/rfc-7320/6.-connection-management.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.