---

Chapter 4. Connection Management

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

---

❤️ 원문 번역 ❤️

Graceful Connection Close

TCP connections are bidirectional, as shown in Figure 4-19. Each side of a TCP connection has an input queue and an output queue, for data being read or written. Data placed in the output of one side will eventually show up on the input of the other side.

• TCP 연결은 Figure 4-19와 같이 양방향으로 이루어집니다.

• TCP 연결의 양측에는 데이터를 읽거나 쓰기 위한 입력 큐와 출력 큐가 있습니다.

• 한쪽의 출력부에 위치한 데이터는 결과적으로 다른 쪽의 입력부에 표시됩니다.

---

[1] Full and Half Closes

An application can close either or both of the TCP input and output channels. A close( ) sockets call closes both the input and output channels of a TCP connection. This is called a “full close” and is depicted in Figure 4-20a. You can use the shutdown( ) sockets call to close either the input or output channel individually. This is called a “half close” and is depicted in Figure 4-20b.

• 응용 프로그램은 TCP의 입력 채널이나 출력 채널, 혹은 양 채널 모두 종료할 수 있습니다.

• close() 소켓 호출은 TCP 연결의 입출력 채널 모두 종료시킵니다.

• 이것을 "full close"라고 하며 Figure 4-20a에 나타납니다.

• shutdown() 소켓 호출은 입력 채널이나 출력 채널을 개별적으로 종료하기 위해 사용할 수 있습니다.

• 이것은 "half close"라고 하며 Figure 4-20b에 나타납니다.

---

[2] TCP Close and Reset Errors

Simple HTTP applications can use only full closes. But when applications start talking to many other types of HTTP clients, servers, and proxies, and when they start using pipelined persistent connections, it becomes important for them to use half closes to prevent peers from getting unexpected write errors.

• 간단한 HTTP 응용 프로그램은 오직 full close만을 사용할 수 있습니다.

• 그러나 응용 프로그램이 많은 유형의 HTTP 클라이언트, 서버, 프록시와 통신하며 파이프라이닝된 지속 연결을 사용하기 시작할 때, 응용 프로그램이 예상치못한 write 오류가 발생하지 않도록 half close를 사용하는 것이 중요해집니다.

In general, closing the output channel of your connection is always safe. The peer on the other side of the connection will be notified that you closed the connection by getting an end-of-stream notification once all the data has been read from its buffer.

• 일반적으로, 여러분의 연결의 출력 채널을 닫는 것은 항상 안전합니다.

• 연결의 반대편 peer에 위치한 컴퓨터는 버퍼로부터 모든 데이터를 읽었을 때 end-of-stream 표시를 얻어 여러분이 연결을 종료했다는 사실을 알아차릴 것입니다.

Closing the input channel of your connection is riskier, unless you know the other side doesn’t plan to send any more data. If the other side sends data to your closed input channel, the operating system will issue a TCP “connection reset by peer” mes- sage back to the other side’s machine, as shown in Figure 4-21. Most operating sys- tems treat this as a serious error and erase any buffered data the other side has not read yet. This is very bad for pipelined connections.

• 연결의 반대편이 더이상 데이터를 보내지 않을 거라는 것을 알지 못한다면 입력 채널을 종료하는 것은 상대적으로 위험합니다.

• 반대편에서 종료된 입력 채널로 데이터를 전송하는 경우, 운영체제는 Figure 4-21처럼 TCP "connection reset by peer" 메시지를 발생시켜 반대편의 장치로 전달할 것입니다.

Say you have sent 10 pipelined requests on a persistent connection, and the responses already have arrived and are sitting in your operating system’s buffer (but the application hasn’t read them yet). Now say you send request #11, but the server decides you’ve used this connection long enough, and closes it. Your request #11 will arrive at a closed connection and will reflect a reset back to you. This reset will erase your input buffers.

• 여러분이 10개의 파이프라이닝된 요청을 Persistent 연결에 전송했고, 응답이 이미 도착해 여러분의 운영체제의 버퍼에 안착했다고 가정해봅시다. (단 응용 프로그램은 아직 응답을 읽지 않았습니다.)

• 이제 여러분이 #11 요청을 보냅니다. 하지만 서버는 이 연결을 충분히 길게 사용했다고 판단하여 연결을 종료시킵니다.

• 여러분의 #11 요청은 종료된 연결에 도착하여 재설정을 반영할 것입니다.

• 이러한 재설정은 여러분의 입력 버퍼를 지울 것입니다.

When you finally get to reading data, you will get a connection reset by peer error, and the buffered, unread response data will be lost, even though much of it successfully arrived at your machine.

• 마침내 데이터를 읽을 때, 여러분은 peer 오류에 의해 연결 재설정을 할 것입니다.

• 그리고 버퍼된 읽지 않은 응답 데이터는 유실됩니다. 많은 수의 데이터가 성공적으로 여러분의 컴퓨터에 도착했더라도 말입니다.

---

[3] Graceful Close

The HTTP specification counsels that when clients or servers want to close a connec- tion unexpectedly, they should “issue a graceful close on the transport connection,” but it doesn’t describe how to do that.

• HTTP 명세는 클라이언트나 서버가 연결을 불가피하게 종료하려고 할 때 "전송 연결을 graceful close 해야 함"을 명시하고 있습니다.

• 하지만 그것을 어떻게 하는지에 대해서는 설명하지 않고 있습니다.

In general, applications implementing graceful closes will first close their output channels and then wait for the peer on the other side of the connection to close its output channels. When both sides are done telling each other they won’t be sending any more data (i.e., closing output channels), the connection can be closed fully, with no risk of reset.

• 일반적으로 graceful close를 구현하는 응용 프로그램은 가장 먼저 그들의 출력 채널을 종료할 것이고, 연결의 반대편에 위치한 peer가 출력 채널을 종료하기를 기다릴 것입니다.

• 연결의 양측이 서로 통신을 완료하면 더 이상 데이터를 전송하지 않을 것입니다. 그러면 연결은 완전하게(fully) 종료될 수 있고 재설정의 위험을 감수하지 않아도 됩니다.

Unfortunately, there is no guarantee that the peer implements or checks for half closes. For this reason, applications wanting to close gracefully should half close their output channels and periodically check the status of their input channels (looking for data or for the end of the stream). If the input channel isn’t closed by the peer within some timeout period, the application may force connection close to save resources.

• 단 peer가 half close를 구현하거나 확인하고 있는지는 보장할 수 없습니다.

• 이런 이유로 정상적으로 종료를 희망하는 응용 프로그램은 그들의 출력 채널을 half close하고 주기적으로 입력 채널 상태를 확인(stream의 마지막 부분이나 데이터를 찾는 것)해야 합니다.

• 만약 입력 채널이 타임아웃 기간 내로 peer에 의해 종료되지 않는다면 응용 프로그램은 리소스를 절약하기 위해 연결을 강제로 종료할 수 있습니다.

---

🧡 요약 정리 🧡

Full & Half Close

• Full Close : TCP 연결의 입출력 채널이 동시에 종료되는 것 (close())
• Half Close : TCP 연결의 입력 채널이나 출력 채널이 개별적으로 종료되는 것 (shutdown())

Graceful Close

: 응용 프로그램이 파이프라이닝된 지속 연결을 사용할 때 예상치못한 write 오류(이미 종료된 연결에 데이터를 쓰려고 하는 것)가 발생하지 않도록 half close해야 한다

• 1. 출력 채널 종료 (half close)
• 2. 반대편의 출력 채널 종료 대기
• 3. 주기적으로 입력 채널 상태 확인
• 4. 타임아웃 기간 내로 반대편에 의해 종료되지 않으면 리소스 절약을 위해 입력 채널 강제 종료 (half close)

---

💛 감상 💛

• 예전에 TCP를 배웠을 때 Half Close라는 단어를 본 적이 있는 것 같아서 당시에 했던 필기를 살펴봤습니다. 한동안 기억에서 지워졌었는데 지금 보니 꽤 자세하게 배웠던 것 같습니다. 정리한 내용에 따르면 Half Close는 한 컴퓨터가 연결의 종료를 알리는 FIN=1 세그먼트를 보내고, 이것을 받은 컴퓨터가 ACK=1인 세그먼트로 응답을 보낼 때 이루어질 수 있습니다. 만약 FIN=1 세그먼트를 받은 컴퓨터가 ACK=1과 함께 FIN=1을 담아서 전송한다면 그것은 Full Close가 될 겁니다.

• 막연하게 Half Close가 뭐고 Full Close가 뭐다 정도만 알고 있었는데, 왜 안전한 종료를 위해서는 Half Close를 사용해야 하는지를 이제 이해할 수 있게 되었습니다.

• 어제 동아리 면접을 준비하느라 포스팅을 올리지 못했습니다. 오늘 낮에 서버 파트 기술 면접을 보고 왔는데, 제대로 답변을 할 수 있었던 게 하나도 없었어서 제가 여전히 부족하다는 사실을 뼈저리게 느끼게 되었습니다. 확실히 기술 면접에 나오는 질문들은 학교에서 배우는 내용과 괴리감이 큰 것 같습니다. 학교에서 배우는 것 외에 스스로 공부한 것이 있는지를 확인하려는 거겠죠. 그래도 면접에서 한 번 시원하게 털리고 나니 앞으로 제가 어떻게 공부를 해야 할지에 대한 방향성이 잡히는 듯합니다. 자극 받은 김에 어제 못 올린 포스팅까지 오늘은 2개를 업로드하도록 하겠습니다.