---

Chapter 4. Connection Management

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

---

❤️ 원문 번역 ❤️

Persistent Connections

Web clients often open connections to the same site. For example, most of the embedded images in a web page often come from the same web site, and a significant number of hyperlinks to other objects often point to the same site. Thus, an application that initiates an HTTP request to a server likely will make more requests to that server in the near future (to fetch the inline images, for example). This property is called site locality.

• 웹 클라이언트는 종종 동일한 사이트에 대한 연결을 엽니다.

• 웹 페이지에 있는 대부분의 임베디드 이미지는 동일한 웹 사이트에서 비롯됩니다. 다른 객체를 가리키는 상당수의 하이퍼링크는 동일한 웹 사이트를 가리킵니다.

• 따라서 서버에 HTTP 요청을 시작하는 응용 프로그램은 가까운 시간 내에 서버에게 더 많은 요청을 발생시킬 가능성이 있습니다. (예를 들어 인라인 이미지를 불러오는 것)

• 이러한 특성을 site locality라고 이야기합니다.

For this reason, HTTP/1.1 (and enhanced versions of HTTP/1.0) allows HTTP devices to keep TCP connections open after transactions complete and to reuse the preexisting connections for future HTTP requests. TCP connections that are kept open after transactions complete are called persistent connections. Nonpersistent connections are closed after each transaction. Persistent connections stay open across transactions, until either the client or the server decides to close them.

• HTTP/1.1(HTTP/1.0의 발전된 버전)은 HTTP 장치가 트랜잭션이 완료된 후 TCP 연결을 열린 상태로 유지하고 기존에 존재하는 연결을 미래의 HTTP 요청에 재사용할 수 있게 합니다.

• 트랜잭션이 끝난 후에도 TCP 연결을 계속해서 유지하는 것을 지속 연결이라고 합니다.

• 지속적이지 않은 연결은 트랜잭션이 끝날 때마다 종료됩니다.

• 반면 지속적인 연결은 클라이언트나 서버가 연결을 종료하기로 결정할 때까지 트랜잭션 전반에 걸쳐 열린 상태를 유지합니다.

By reusing an idle, persistent connection that is already open to the target server, you can avoid the slow connection setup. In addition, the already open connection can avoid the slow-start congestion adaptation phase, allowing faster data transfers.

• 타켓 서버에 이미 열려 있지만 사용되지 않는 지속 연결을 재사용하여 연결 설정으로 인한 속도 저하를 피할 수 있습니다.

• 또한 Slow-start의 혼잡 적응 단계를 회피해 더 빠른 데이터 전송이 가능합니다.

---

Persistent Versus Parallel Connections

As we’ve seen, parallel connections can speed up the transfer of composite pages. But parallel connections have some disadvantages:

• Each transaction opens/closes a new connection, costing time and bandwidth.
• Each new connection has reduced performance because of TCP slow start.
• There is a practical limit on the number of open parallel connections.

• 앞서 살펴본 것처럼 병렬 연결은 복합 페이지의 전송 속도를 올릴 수 있습니다.

• 그러나 병렬 연결은 몇 가지 제약을 가지고 있습니다.
  - 각 연결을 열고 닫을 때 시간과 대역폭이 소모된다
  - 새로운 연결은 TCP Slow Start로 인해 성능이 감소된다
  - 열 수 있는 실질적인 병렬 연결의 수가 제한된다

Persistent connections offer some advantages over parallel connections. They reduce the delay and overhead of connection establishment, keep the connections in a tuned state, and reduce the potential number of open connections. However, persistent connections need to be managed with care, or you may end up accumulating a large number of idle connections, consuming local resources and resources on remote clients and servers.

• 지속 연결은 병렬 연결 이상의 몇 가지 장점을 제공합니다.

• 연결 설정의 지연과 오버헤드를 감소시키고, 연결을 이미 튜닝된 상태로 유지하며, 개방된 연결의 잠재적 수를 줄입니다.
  (* 오버헤드 : 무언가를 처리할 때 소요되는 시간과 메모리 등의 비용)

• 그러나 지속 연결은 신중하게 관리되어야 합니다. 그렇지 않으면 사용되지 않는 연결의 수가 축적되어 결국 로컬 리소스와 원격 클라이언트와 서버의 리소스를 소비하게 됩니다.

Persistent connections can be most effective when used in conjunction with parallel connections. Today, many web applications open a small number of parallel connections, each persistent. There are two types of persistent connections: the older HTTP/1.0+ “keep-alive” connections and the modern HTTP/1.1 “persistent” connections. We’ll look at both flavors in the next few sections.

• 지속 연결은 병렬 연결과 함께 사용될 때 가장 효과적입니다.

• 오늘날 많은 웹 애플리케이션은 소수의 병렬 연결을 지속적으로 엽니다.

• 지속 연결에는 두 가지의 유형이 있습니다.
  - HTTP/1.0+ "keep-alive" connections
  - moedern HTTP/1.1 "persistent" connections

• 이 두 가지 형태에 대해서는 다음 몇 가지 섹션에서 살펴볼 것입니다.

---

HTTP/1.0+ Keep-Alive Connections

Many HTTP/1.0 browsers and servers were extended (starting around 1996) to support an early, experimental type of persistent connections called keep-alive connec- tions. These early persistent connections suffered from some interoperability design problems that were rectified in later revisions of HTTP/1.1, but many clients and servers still use these earlier keep-alive connections.

• 많은 HTTP/1.0 브라우저와 서버는 "keep-alive"라고 불리는 지속 연결의 실험적인 초기 형태를 지원하도록 확장되었습니다. (1996년 무렵부터)

• 초기의 지속 연결은 최신 리비전(* 개정판)인 HTTP/1.1과의 상호운용 설계 문제로 어려움을 겪었습니다. 하지만 다수의 클라이언트와 서버는 여전히 초기의 keep-alive 연결을 사용하고 있습니다.

Some of the performance advantages of keep-alive connections are visible in Figure 4-13, which compares the timeline for four HTTP transactions over serial con- nections against the same transactions over a single persistent connection. The timeline is compressed because the connect and close overheads are removed.

• keep-alive 연결의 일부 성능적 이점이 Figure 4-13에 나타납니다. Figure 4-13은 직렬 연결 위에 4개의 HTTP 트랜잭션을 전송하는 것과 하나의 지속 연결 위에 동일한 트랜잭션을 전송하는 것의 타임라인을 비교합니다.

• 연결과 종료로 인한 오버헤드가 감소하기 때문에 타임라인이 압축됩니다.

---

🧡 요약 정리 🧡

Persistent Connections

: 트랜잭션을 완료한 후 TCP 연결을 열린 상태로 유지, 추후 재사용하는 것

• Site Locality : 가까운 시간 내에 같은 서버에게 더 많은 요청을 발생시키는 것
  -> HTTP 요청을 사용하는 응용 프로그램은 Site Locality가 높다
  -> Site Locality가 높으면 지속 연결의 효율이 높다
• 연결 설정과 Slow Start에 의한 지연 해소
• 병렬 연결과 함께 효과적으로 사용 가능

[1] HTTP/1.0+ Keep-Alive Connections

• 지속 연결의 실험적인 초기 형태
• HTTP/1.1과의 상호운용 문제로 어려움을 겪었으나 여전히 많이 사용
• 연결 설정과 종료에 의한 오버헤드 감소 -> 타임라인 압축

---

💛 감상 💛

• 자고 일어났더니 자정이 훌쩍 넘어버렸습니다. 잘 생각은 있었지만 이렇게 오래 잘 생각은 아니었는데 많이 피곤했나봐요 ㅠㅠ 날짜 밀린 게 살짝 짜증이 나지만 푹 자서 개운하긴 합니다.... 업로드하고 운영체제 공부까지 하다가 자려고요.

• 글을 읽으면서 HTTP 연결이 되게 수학문제 푸는 것처럼 발전했다는 생각을 했습니다. 수학을 공부할 때 처음에는 일단 문제를 많이 풀어보고 양으로 막 밀어붙이다가, 그것만으로 한계에 다다르면 더 정교하고 심화된 문제를 풀기 시작합니다. 이 방식이 HTTP에도 똑같이 적용되는 것 같습니다. 병렬 연결로 밀어붙이다가 한계가 있으니까 연결을 재사용해서 연결의 질(속도)를 올렸으니까요. 지속 연결로도 한계를 느낀다면 이제는 연결의 내부를 들여다 보지 않을까요? 심화 문제를 푸는 것만으로 한계에 부딪히면 아예 문제 유형을 분석하기 시작하는 것처럼요. 사실 수학 공부나 HTTP 연결뿐만이 아니라 모든 게 다 그런 것 같습니다. 모든 것은 분명 한계가 있습니다. 하지만 한계가 있다는 것을 직접 느껴야 그것을 하나씩 극복하면서 더욱 발전할 수 있는 거겠죠! 그래서 스스로 한계를 느낄 때까지 끊임없이 질문하고 도전하는 자세가 중요한 것 같습니다.

• 이제는 감상란이 아니라 그냥 일기장이네요. 뭔들 어떤가요. 매일매일 읽고 요약만 잘하면 됐지 싶은 생각입니다.

** 개인적인 사정으로 일요일까지 업로드가 없습니다.