mirror of
https://github.com/riba2534/TCP-IP-NetworkNote.git
synced 2026-06-30 01:46:15 +08:00
5625eea472
通过多智能体工作流对 19 章笔记（README.md）与 96 个 .c 示例代码做深度 审查与对抗性验证，修复 317 处确认问题，涵盖： 技术正确性： - 修复缓冲区溢出：echo_mpserv.c / echo_storeserv.c 等的 read(buf, BUFSIZ) 改为 BUF_SIZE（buf 仅 30 字节，BUFSIZ 远大于此） - 修复 open() 缺少 mode 参数：low_open.c / fd_seri.c / desto.c 等 O_CREAT 调用补 0644（原导致 low_read 链路失败） - 修复 feof 循环 off-by-one：news_sender.c / echo_stdserv.c 改用 fgets 返回值判断 - 修复线程竞态：chat_server.c / webserv_linux.c 的 &clnt_sock 栈地址 传子线程改为 malloc 分配 + free - 修复索引混淆：char_EPLTserv.c 错用 clnt_sock 查找改为 ep_events[i].data.fd - 修复格式化符：thread4.c 的 sizeof 用 %d 改为 %zu - 修正习题答案：ch01 fd 序号、ch13 MSG_OOB 加粗项、ch09 Nagle 等 文档规范： - 统一术语：IPv4/IPv6、接收(receive)/连接(connection) - 修正错别字：occured→occurred、cooffee→coffee、Usgae→Usage、 eerror→error、proess→process 等 - 修复病句、补全习题答案解释 - GitHub 绝对 URL 改为相对路径，统一项目引用规范 - 同步根 README.md（前言 + 19 章合并） 另：重命名 ch10/remove_zomebie.c → remove_zombie.c（修正拼写） 所有 .c 文件经 gcc 编译验证通过（ch17 epoll 文件因 macOS 无 sys/epoll.h 跳过，已人工复核）。
138 lines
7.8 KiB
Markdown
138 lines
7.8 KiB
Markdown
## 第 7 章 优雅地断开套接字的连接
|
||
|
||
本章代码，在[TCP-IP-NetworkNote](https://github.com/riba2534/TCP-IP-NetworkNote)中可以找到。
|
||
|
||
本章讨论如何优雅地断开套接字的连接，之前用的方法不够优雅是因为，我们是调用 close 函数或 closesocket 函数单方面断开连接的。
|
||
|
||
### 7.1 基于 TCP 的半关闭
|
||
|
||
TCP 的断开连接过程比建立连接更重要，因为连接过程中一般不会出现大问题，但是断开过程可能发生预想不到的情况。因此应该准确掌控。所以要**掌握半关闭（Half-close）**，才能明确断开过程。
|
||
|
||
#### 7.1.1 单方面断开连接带来的问题
|
||
|
||
Linux 的 close 函数和 Windows 的 closesocket 函数意味着完全断开连接。完全断开不仅指无法传输数据，而且也不能接收数据。因此在某些情况下，通信一方单方面的断开套接字连接，显得不太优雅。如图所示：
|
||
|
||
|
||
|
||
图中描述的是 2 台主机正在进行双向通信，主机 A 发送完最后的数据后，调用 close 函数断开了最后的连接，之后主机 A 无法再接收主机 B 传输的数据。实际上，是完全无法调用与接收数据相关的函数。最终，由主机 B 传输的、主机 A 必须要接收的数据也销毁了。
|
||
|
||
为了解决这类问题，「只关闭一部分数据交换中使用的流」的方法应运而生。断开一部分连接是指，可以传输数据但是无法接收，或可以接收数据但无法传输。顾名思义就是只关闭流的一半。
|
||
|
||
#### 7.1.2 套接字和流（Stream）
|
||
|
||
两台主机通过套接字建立连接后进入可交换数据的状态，又称「流形成的状态」。也就是把建立套接字后可交换数据的状态看作一种流。
|
||
|
||
此处的流可以比作水流。水朝着一个方向流动，同样，在套接字的流中，数据也只能向一个方向流动。因此，为了进行双向通信，需要如图所示的两个流：
|
||
|
||
|
||
|
||
一旦两台主机之间建立了套接字连接，每个主机就会拥有单独的输入流和输出流。当然，其中一个主机的输入流与另一个主机的输出流相连，而输出流则与另一个主机的输入流相连。另外，本章讨论的「优雅的断开连接方式」只断开其中 1 个流，而非同时断开两个流。Linux 的 close 函数和 Windows 的 closesocket 函数将同时断开这两个流，因此与「优雅」二字还有一段距离。
|
||
|
||
#### 7.1.3 针对优雅断开的 shutdown 函数
|
||
|
||
shutdown 用来关闭其中一个流：
|
||
|
||
```c
|
||
#include <sys/socket.h>
|
||
int shutdown(int sock, int howto);
|
||
/*
|
||
成功时返回 0 ，失败时返回 -1
|
||
sock: 需要断开的套接字文件描述符
|
||
howto: 传递断开方式信息
|
||
*/
|
||
```
|
||
|
||
调用上述函数时，第二个参数决定断开连接的方式，其值如下所示：
|
||
|
||
- `SHUT_RD` : 断开输入流
|
||
- `SHUT_WR` : 断开输出流
|
||
- `SHUT_RDWR` : 同时断开 I/O 流
|
||
|
||
若向 shutdown 的第二个参数传递`SHUT_RD`，则断开输入流，套接字无法接收数据。即使输入缓冲收到数据也会抹去，而且无法调用相关函数。如果向 shutdown 的第二个参数传递`SHUT_WR`，则中断输出流，也就无法传输数据。如果输出缓冲中还有未传输的数据，则将传递给目标主机。最后，若传递关键字`SHUT_RDWR`，则同时中断 I/O 流。这相当于分 2 次调用 shutdown ，其中一次以`SHUT_RD`为参数，另一次以`SHUT_WR`为参数。
|
||
|
||
#### 7.1.4 为何要半关闭
|
||
|
||
考虑以下情况：
|
||
|
||
> 一旦客户端连接到服务器，服务器将约定的文件传输给客户端，客户端收到后发送字符串「Thank you」给服务器端。
|
||
|
||
此处「Thank you」的传递是多余的，这只是用来模拟客户端断开连接前还有数据要传输的情况。此时程序的编写难度并不小，因为传输文件的服务器端只需连续传输文件数据即可，而客户端无法知道需要接收数据到何时。客户端也没办法无休止地调用输入函数，因为这有可能导致程序**阻塞**。
|
||
|
||
> 是否可以让服务器和客户端约定一个代表文件尾的字符？
|
||
|
||
这种方式也有问题，因为这意味着文件中不能有与约定字符相同的内容。为了解决该问题，服务端应最后向客户端传递 EOF 表示文件传输结束。客户端通过函数返回值接收 EOF ，这样可以避免与文件内容冲突。那么问题来了，服务端如何传递 EOF ？
|
||
|
||
> 断开输出流时向主机传输 EOF。
|
||
|
||
当然，调用 close 函数的同时关闭 I/O 流，这样也会向对方发送 EOF 。但此时无法再接收对方传输的数据。换言之，若调用 close 函数关闭流，就无法接收客户端最后发送的字符串「Thank you」。这时需要调用 shutdown 函数，只关闭服务器的输出流。这样既可以发送 EOF ，同时又保留了输入流。下面实现收发文件的服务器端/客户端。
|
||
|
||
#### 7.1.5 基于半关闭的文件传输程序
|
||
|
||
上述文件传输服务器端和客户端的数据流可以整理如图：
|
||
|
||
|
||
|
||
下面的代码为编程简便，省略了大量错误处理代码。
|
||
|
||
- [file_client.c](file_client.c)
|
||
- [file_server.c](file_server.c)
|
||
|
||
编译运行：
|
||
|
||
```shell
|
||
gcc file_client.c -o fclient
|
||
gcc file_server.c -o fserver
|
||
./fserver 9190
|
||
./fclient 127.0.0.1 9190
|
||
```
|
||
|
||
结果：
|
||
|
||
|
||
|
||
客户端接收完成后，服务器会接收到来自客户端的感谢信息。
|
||
|
||
### 7.2 基于 Windows 的实现
|
||
|
||
Windows 平台下的半关闭实现与 Linux 类似，同样使用 shutdown 函数。函数原型如下：
|
||
|
||
```c
|
||
#include <winsock2.h>
|
||
int shutdown(SOCKET s, int how);
|
||
/*
|
||
成功时返回 0，失败时返回 SOCKET_ERROR
|
||
s: 需要断开的套接字句柄
|
||
how: 传递断开方式信息
|
||
*/
|
||
```
|
||
|
||
Windows 下的 how 参数取值与 Linux 略有不同：
|
||
|
||
- `SD_RECEIVE` : 断开输入流（相当于 Linux 的 SHUT_RD）
|
||
- `SD_SEND` : 断开输出流（相当于 Linux 的 SHUT_WR）
|
||
- `SD_BOTH` : 同时断开 I/O 流（相当于 Linux 的 SHUT_RDWR）
|
||
|
||
使用方法与 Linux 版本基本一致，只需注意参数名称的差异即可。
|
||
|
||
### 7.3 习题
|
||
|
||
> 以下答案仅代表本人个人观点，可能不是正确答案
|
||
|
||
1. **解释 TCP 中「流」的概念。UDP 中能否形成流？请说明原因。**
|
||
|
||
答：两台主机中通过套接字建立连接后进入可交换数据的状态，又称「流形成的状态」。也就是把建立套接字后可交换数据的状态看做一种流。UDP 没有建立连接的过程，所以不能形成流。
|
||
|
||
2. **Linux 中的 close 函数或 Windows 中的 closesocket 函数属于单方面断开连接的方法，有可能带来一些问题。什么是单方面断开连接？什么情形下会出现问题？**
|
||
|
||
答：单方面断开连接是指通信的一方调用 close（Linux）或 closesocket（Windows）函数，同时关闭输入流和输出流。这会导致该主机既不能发送数据也不能接收数据。
|
||
|
||
问题出现的典型情形是：服务器向客户端传输文件，传输完成后需要接收客户端的确认信息（如「Thank you」）。如果服务器调用 close 函数发送 EOF，虽然客户端能知道文件传输完毕，但服务器也无法再接收客户端发送的确认信息了。解决方法是使用 shutdown 函数进行半关闭，只关闭输出流，保留输入流。
|
||
|
||
3. **什么是半关闭？针对输出流执行半关闭的主机处于何种状态？半关闭会导致对方主机接收什么消息？**
|
||
|
||
答：半关闭是指只关闭套接字的输入流或输出流中的一种，而不是同时关闭两者。
|
||
|
||
针对输出流执行半关闭（即调用 `shutdown(sock, SHUT_WR)`）的主机处于：可以接收数据，但无法发送数据的状态。
|
||
|
||
半关闭会导致对方主机的接收函数返回 EOF（文件结束符），对方主机由此得知数据已传输完毕。
|