---

Chapter 4. Connection Management

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

---

❤️ 원문 번역 ❤️

TCP Connection Handshake Delays

When you set up a new TCP connection, even before you send any data, the TCP software exchanges a series of IP packets to negotiate the terms of the connection (see Figure 4-8). These exchanges can significantly degrade HTTP performance if the connections are used for small data transfers.

• 데이터를 전송하기 전 TCP 연결을 설정하면서 TCP 소프트웨어는 연결의 조건을 협상하기 위해 일련의 IP 패킷을 주고받습니다. (Figure 4-8)

• 그러나 작은 데이터를 전송할 때 TCP 연결을 사용하면 패킷 교환으로 인해 HTTP의 성능이 저하될 수 있습니다.

Here are the steps in the TCP connection handshake:

1. To request a new TCP connection, the client sends a small TCP packet (usually 40–60 bytes) to the server. The packet has a special “SYN” flag set, which means it’s a connection request. This is shown in Figure 4-8a.

2. If the server accepts the connection, it computes some connection parameters and sends a TCP packet back to the client, with both the “SYN” and “ACK” flags set, indicating that the connection request is accepted (see Figure 4-8b).

3. Finally, the client sends an acknowledgment back to the server, letting it know that the connection was established successfully (see Figure 4-8c). Modern TCP stacks let the client send data in this acknowledgment packet.

• TCP 연결 핸드쉐이크 과정은 다음과 같습니다.
  (TCP 연결 설정을 위해 패킷을 주고받는 것을 "handshake"라고 한다)

• 1. 새로운 TCP 연결을 요청하기 위해 클라이언트는 일반적으로 40-60 바이트의 작은 TCP 패킷을 서버에게 전달합니다. 이 패킷에는 연결 요청을 의미하는 특별한 플래그인 "SYN"가 포함되어 있습니다. Figure 4-8a에 이 과정이 나타납니다.

• 2. 서버가 연결을 승인하면 몇 가지 연결 파라미터를 계산하여 클라이언트에게 TCP 패킷을 돌려 보냅니다. 이때 연결 요청이 승인되었음을 나타내는 "SYN"과 "ACK" 플래그 집합이 함께 전달됩니다. (Figure 4-8b)

• 3. 마지막으로 클라이언트는 서버에게 연결이 성공적으로 이루어졌음을 알리는 Acknowledgment(확인 응답)을 전송합니다. (Figure 4-8c) 오늘날의 TCP 스택은 클라이언트가 이와 같은 Acknowledgment 패킷을 전송하게 합니다.

The HTTP programmer never sees these packets—they are managed invisibly by the TCP/IP software. All the HTTP programmer sees is a delay when creating a new TCP connection.

• HTTP 개발자는 이러한 패킷들을 전혀 볼 수 없습니다. 패킷 교환은 TCP/IP 소프트웨어에 의해 보이지 않는 곳에서 관리됩니다.

• HTTP 개발자가 보는 것은 새로운 TCP 연결을 생성했을 때 발생하는 지연뿐입니다.

The SYN/SYN+ACK handshake (Figure 4-8a and b) creates a measurable delay when HTTP transactions do not exchange much data, as is commonly the case. The TCP connect ACK packet (Figure 4-8c) often is large enough to carry the entire HTTP request message,* and many HTTP server response messages fit into a single IP packet (e.g., when the response is a small HTML file of a decorative graphic, or a 304 Not Modified response to a browser cache request).

• SYN/SYN+ACK 핸드쉐이크(Figure 4-8a와 b)는 HTTP 트랜잭션이 통상 많은 데이터를 주고받지 않을 때 눈에 띄는 지연을 만들어냅니다.

• TCP 연결 ACK 패킷은 주로 HTTP 요청 메시지 전체를 실어나르기 충분한 크기입니다. 그리고 많은 HTTP 서버의 응답 메시지는 하나의 IP 패킷에 딱 맞게 들어맞습니다. (e.g. 그래픽을 포함한 작은 HTML 파일, 브라우저 캐시 요청에 대한 304 Not Modified)

The end result is that small HTTP transactions may spend 50% or more of their time doing TCP setup. Later sections will discuss how HTTP allows reuse of existing connections to eliminate the impact of this TCP setup delay.

• 결과적으로 작은 HTTP 트랜잭션에서 50% 이상의 시간은 TCP 설정을 수행하는 데 소요됩니다.

• 이후 섹션에서는 TCP 연결 지연의 악영향을 제거하기 위해 HTTP가 존재하는 연결을 재사용하는 방법에 대해 논의할 것입니다.

---

Delayed Acknowledgments

Because the Internet itself does not guarantee reliable packet delivery (Internet routers are free to destroy packets at will if they are overloaded), TCP implements its own acknowledgment scheme to guarantee successful data delivery.

• 인터넷은 그 자체로 안전한 패킷 송수신을 보장하지 않습니다(인터넷 라우터가 과부하에 걸리는 경우 마음대로 패킷을 손상시킬 수도 있음).

• 따라서 TCP는 성공적인 데이터 전송을 보장하기 위해 고유의 확인 응답 기법을 구현합니다.

Each TCP segment gets a sequence number and a data-integrity checksum. The receiver of each segment returns small acknowledgment packets back to the sender when segments have been received intact. If a sender does not receive an acknowledgment within a specified window of time, the sender concludes the packet was destroyed or corrupted and resends the data.

• 각각의 TCP 세그먼트는 Sequence Number와 데이터 통합 Checksum을 가지고 있습니다.

• 세그먼트의 수신단은 손상되지 않은 세그먼트가 도착하면 작은 크기의 확인 응답 패킷을 송신단에 돌려 보냅니다.

• 만약 송신단이 일정 시간 이내에 확인 응답을 받지 못했다면 송신단은 패킷이 파괴되거나 손상되었다고 판단하여 데이터를 재전송합니다.

Because acknowledgments are small, TCP allows them to “piggyback” on outgoing data packets heading in the same direction. By combining returning acknowledgments with outgoing data packets, TCP can make more efficient use of the network. To increase the chances that an acknowledgment will find a data packet headed in the same direction, many TCP stacks implement a “delayed acknowledgment” algorithm. Delayed acknowledgments hold outgoing acknowledgments in a buffer for a certain window of time (usually 100–200 milliseconds), looking for an outgoing data packet on which to piggyback. If no outgoing data packet arrives in that time, the acknowledgment is sent in its own packet.

• 확인 응답의 크기가 작기 때문에 TCP는 같은 곳으로 향하는 발신 데이터 패킷에 "piggyback" 하는 것을 허용했습니다.

• cf) piggybacking : 데이터 패킷과 확인 응답 패킷을 따로 전송하지 않고, 다음에 수신해야 하는 데이터 패킷에 확인 응답을 포함하여 함께 전송하는 것
  

• 반환할 확인 응답을 발신 데이터 패킷과 결합함으로써 TCP는 네트워크를 보다 효율적으로 사용할 수 있습니다.

• 확인 응답이 같은 곳으로 향하는 데이터 패킷을 더 잘 찾게 하기 위해 많은 TCP 스택은 "Delayed Acknowledgment(지연 확인 응답)" 알고리즘을 구현합니다.

• 지연 확인 응답 알고리즘은 특정 시간(통상 100-200 밀리초) 동안 버퍼에 발신 확인 응답을 보유한 채로 Piggyback을 할 발신 데이터 패킷을 탐색합니다.

• 만약 제한시간 내에 도착하는 발신 패킷이 없다면 확인 응답은 새로운 패킷으로 전송됩니다.

Unfortunately, the bimodal request-reply behavior of HTTP reduces the chances that piggybacking can occur. There just aren’t many packets heading in the reverse direction when you want them. Frequently, the disabled acknowledgment algorithms introduce significant delays. Depending on your operating system, you may be able to adjust or disable the delayed acknowledgment algorithm.

• 그러나 안타깝게도, 두 가지 모드의 HTTP 요청-응답 동작은 Piggybacking의 발생 가능성을 낮춥니다.

• 적절한 시기에 반대 방향으로 향하는 패킷이 그리 많지 않기 때문입니다.

• 종종 지연 확인 응답 알고리즘이 막대한 지연을 발생시키기도 합니다.

• 운영체제에 따라 지연 응답 알고리즘을 조절하거나 비활성화할 수 있습니다.

** Bimodal에 관한 부분을 정확히 해석하지 못했습니다. HTTP는 양방향으로의 요청-응답이 이루어지지 않아서 Piggybacking이 잘 일어나지 않는다 정도로 이해했는데... 이게 맞는 건지는 잘 모르겠습니다. 혹시 이해하신 분 있다면 저에게 꼭 좀 알려주세요 ㅠㅠ

Before you modify any parameters of your TCP stack, be sure you know what you are doing. Algorithms inside TCP were introduced to protect the Internet from poorly designed applications. If you modify any TCP configurations, be absolutely sure your application will not create the problems the algorithms were designed to avoid.

• TCP 스택의 임의의 파라미터들을 수정하기 전에 여러분이 무엇을 하고 있는지를 잘 알아야 합니다.

• TCP 내부의 알고리즘은 잘못 설계된 응용 프로그램으로부터 인터넷을 보호하기 위해 도입되었습니다.

• 만약 TCP 구성을 임의로 수정하고자 한다면, 여러분의 응용 프로그램이 알고리즘이 피하기 위해 설계된 여러 문제들을 발생시키지 않도록 보장해야 합니다.

---

TCP Slow Start

The performance of TCP data transfer also depends on the age of the TCP connection. TCP connections “tune” themselves over time, initially limiting the maximum speed of the connection and increasing the speed over time as data is transmitted successfully. This tuning is called TCP slow start, and it is used to prevent sudden overloading and congestion of the Internet.

• TCP 데이터 전송의 성능은 TCP 연결이 얼마나 오래됐는지에 따라서도 달라집니다.

• TCP 연결은 시간이 지남에 따라 스스로를 튜닝합니다. 초기에는 연결의 최대 속도를 제한하고 데이터가 성공적으로 전달되면 서서히 속도를 올립니다.

• 이러한 튜닝 방식을 TCP Slow Start라고 합니다. Slow Start는 갑작스러운 과부하와 인터넷 혼잡을 예방하기 위해 사용됩니다.

TCP slow start throttles the number of packets a TCP endpoint can have in flight at any one time. Put simply, each time a packet is received successfully, the sender gets permission to send two more packets. If an HTTP transaction has a large amount of data to send, it cannot send all the packets at once. It must send one packet and wait for an acknowledgment; then it can send two packets, each of which must be acknowledged, which allows four packets, etc. This is called “opening the congestion window.”

• TCP Slow Start는 TCP 엔드포인트가 한 번에 전송할 수 있는 패킷의 개수를 제한합니다.

• 매번 패킷이 성공적으로 수신될 때마다 송신단은 두 배 더 많은 패킷을 전송할 권한이 생깁니다. (TCP Slow Start는 지수적으로 패킷 개수를 늘리는 것으로 압니다. 원서에 "two more"이라고 적혀 있기는 한데 의미상 "twice as more"이 아닐까 싶습니다.)

• HTTP 트랜잭션은 대량의 전송 데이터를 가지고 있고, 모든 패킷을 한 번에 전송할 수 없습니다.

• 송신단은 하나의 패킷을 전송하고 확인 응답을 기다려야 합니다. 확인 응답을 받았다면 두 개의 패킷을 전송하고, 이 두 개의 패킷들도 각각 확인 응답을 받았다면 네 개의 패킷을 전송하는 것이 허용됩니다.

• 이것을 "opening the congestion window"라고 부릅니다.

Because of this congestion-control feature, new connections are slower than “tuned” connections that already have exchanged a modest amount of data. Because tuned connections are faster, HTTP includes facilities that let you reuse existing connections. We’ll talk about these HTTP “persistent connections” later in this chapter.

• 이와 같은 혼잡 제어 특성은 새로운 연결이 이미 적당량의 데이터를 주고받으며 튜닝된 연결에 비해 더 느려지게 합니다.

• HTTP는 튜닝된 연결이 더 빠르다는 점을 감안하여 연결을 재사용할 수 있는 기능을 포함합니다.

• HTTP의 지속 연결에 대해서는 이번 챕터의 뒷부분에서 이야기하겠습니다.

---

🧡 요약 정리 🧡

Connection Handshake

• TCP 연결 설정을 위해 패킷을 주고받는 것
• SYN from Client to Server -> SYN+ACK from Server to Client -> ACK from Client to Server
• 작은 HTTP 트랜잭션에서는 50% 이상의 시간이 TCP 연결 설정에 수행되기도 함
• HTTP 연결을 재사용하여 문제를 해결하는 법을 추후 논의할 것

Delayed Acknowledgments

• Acknowledgment(확인 응답) : Sequence Number, Checksum 등을 통해 세그먼트의 손상 여부를 확인하여 세그먼트가 손상되지 않았을 때만 송신단에 전달하는 패킷
• Delayed Acknowledgment(지연 확인 응답) : 특정 시간 동안 버퍼에 존재하는 확인 응답을 Piggybacking 하기 위해 데이터 패킷을 탐색하는 알고리즘
• Piggybacking : 데이터 패킷과 확인 응답 패킷을 따로 전송하지 않고, 다음에 수신해야 하는 데이터 패킷에 확인 응답을 포함하여 함께 전송하는 것
• HTTP에서는 Piggybacking이 잘 일어나지 않아 지연 발생
• 혹은 지연 확인 응답 알고리즘이 운영체제 등에 의해 비활성화되면 지연 발생

Slow Start

• TCP 엔드포인트가 한 번에 전송할 수 있는 패킷 개수를 제한하는 것
• 초기에는 연결의 최대 속도를 제한하다가 서서히 속도 증가 -> 패킷이 송신단에 성공적으로 수신될 때마다 두 배 더 많은 패킷 전송
• 갑작스러운 과부하와 인터넷 혼잡 방지
• Persistent Connections(지속 연결) : 튜닝된 연결 재사용

---

💛 감상 💛

• 텍스트만 고봉밥으로 있으니까 진짜 어질어질하다. 원서는 고작 두 페이지 읽는 것도 참 쉽지가 않은 것 같다. 다음 분량은 진짜 그림 하나도 없고 텍스트만 있던데... 의지가 꺾인다 ㅎ

• TCP는 한 번 공부한 적이 있어서 그래도 쉽게 슥슥 넘어갈 줄 알았는데, 오만한 생각이었다. 페이지를 빼곡히 채운 텍스트 앞에 겸손해진다.