docs: 全面校对全部章节文档与示例代码

通过多智能体工作流对 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
跳过，已人工复核）。

ch04/README.md

@@ -16,7 +16,7 @@ TCP/IP 协议栈共分为 4 层，可以理解为数据收发分成了 4 个层
 
 #### 4.1.2 链路层
 
-链路层是物理链接领域标准化的结果，也是最基本的领域，专门定义LAN、WAN、MAN等网络标准。若两台主机通过网络进行数据交换，则需要物理连接，链路层就负责这些标准。
+链路层是物理连接领域标准化的结果，也是最基本的领域，专门定义LAN、WAN、MAN等网络标准。若两台主机通过网络进行数据交换，则需要物理连接，链路层就负责这些标准。
 
 #### 4.1.3 IP 层
 
@@ -28,11 +28,11 @@ IP 是面向消息的、不可靠的协议。每次传输数据时会帮我们
 
 IP 层解决数据传输中的路径选择问题，只需照此路径传输数据即可。TCP 和 UDP 层以 IP 层提供的路径信息为基础完成实际的数据传输，故该层又称为传输层。UDP 比 TCP 简单，现在我们只解释 TCP 。 TCP 可以保证数据的可靠传输，但是它发送数据时以 IP 层为基础（这也是协议栈层次化的原因）。
 
-IP 层只关注一个数据包（数据传输基本单位）的传输过程。因此，即使传输多个数据包，每个数据包也是由 IP 层实际传输的，也就是说传输顺序及传输本身是不可靠的。若只利用IP层传输数据，则可能导致后传输的数据包B比先传输的数据包A提早到达。另外，传输的数据包A、B、C中可能只收到A和C，甚至收到的C可能已经损毁 。反之，若添加 TCP 协议则按照如下对话方式进行数据交换。
+IP 层只关注一个数据包（数据传输基本单位）的传输过程。因此，即使传输多个数据包，每个数据包也是由 IP 层实际传输的，也就是说传输顺序及传输本身是不可靠的。若只利用IP层传输数据，则可能导致后传输的数据包B比先传输的数据包A提早到达。另外，传输的数据包A、B、C中可能只收到A和C，甚至收到的C可能已经损毁。反之，若添加 TCP 协议则按照如下对话方式进行数据交换。
 
 > 主机A：正确接收第二个数据包
 >
-> 主机B：恩，知道了
+> 主机B：嗯，知道了
 >
 > 主机A：正确收到第三个数据包
 >
@@ -48,7 +48,7 @@ IP 层只关注一个数据包（数据传输基本单位）的传输过程。
 
 ### 4.2 实现基于 TCP 的服务器/客户端
 
-#### 4.2.1 TCP 服务端的默认函数的调用程序
+#### 4.2.1 TCP 服务端的默认函数调用顺序
 
 ![](images/5c3c2782a7810.png)
 
@@ -86,13 +86,13 @@ accept 函数受理连接请求队列中待处理的客户端连接请求。函
 
 #### 4.2.4 回顾 Hello World 服务端
 
-- 代码：[hello_server.c](https://github.com/riba2534/TCP-IP-NetworkNote/blob/master/ch04/hello_server.c)
+- 代码：[hello_server.c](hello_server.c)
 
 重新整理一下代码的思路
 
 1. 服务端实现过程中首先要创建套接字，此时的套接字并非是真正的服务端套接字
 2. 为了完成套接字地址的分配，初始化结构体变量并调用 bind 函数。
-3. 调用 listen 函数进入等待连接请求状态。连接请求状态队列的长度设置为5.此时的套接字才是服务端套接字。
+3. 调用 listen 函数进入等待连接请求状态。连接请求等待队列的长度设置为 5。此时的套接字才是服务端套接字。
 4. 调用 accept 函数从队头取 1 个连接请求与客户端建立连接，并返回创建的套接字文件描述符。另外，调用 accept 函数时若等待队列为空，则 accept 函数不会返回，直到队列中出现新的客户端连接。
 5. 调用 write 函数向客户端传送数据，调用 close 关闭连接
 
@@ -118,13 +118,13 @@ addrlen: 第二个结构体参数 servaddr 变量的字节长度
 - 服务端接受连接请求
 - 发生断网等异常状况而中断连接请求
 
-注意：**接受连接**不代表服务端调用 accept 函数，其实只是服务器端把连接请求信息记录到等待队列。因此 connect 函数返回后并不应该立即进行数据交换。
+注意：**接受连接**不代表服务端调用了 accept 函数，其实只是服务器端把连接请求信息记录到等待队列。connect 函数返回时 TCP 三次握手已完成、连接已建立，客户端可以发送数据（数据会暂存在内核缓冲区，待服务端调用 accept 后读取），但服务端应用层可能尚未调用 accept 处理该连接。
 
-客户端在调用 connect 函数时自动分配主机的 IP，随机分配端口。无需调用显式的 bind 函数进行分配。
+客户端在调用 connect 函数时自动分配主机的 IP，随机分配端口。无需显式调用 bind 函数进行分配。
 
 #### 4.2.6 回顾 Hello World 客户端
 
-- 代码：[hello_client.c](https://github.com/riba2534/TCP-IP-NetworkNote/blob/master/ch04/hello_client.c)
+- 代码：[hello_client.c](hello_client.c)
 
 重新理解这个程序：
 
@@ -132,7 +132,7 @@ addrlen: 第二个结构体参数 servaddr 变量的字节长度
 2. 结构体变量 serv_addr 中初始化IP和端口信息。初始化值为目标服务器端套接字的IP和端口信息。
 3. 调用 connect 函数向服务端发起连接请求
 4. 完成连接后，接收服务端传输的数据
-5. 接收数据后调用 close 函数关闭套接字，结束与服务器端的连接。(对套接字调用close函数，对应于向建立连接的对应套接字发送EOF。即，如果客户端的套接字调用了close函数，服务端read时候会返回0。)
+5. 接收数据后调用 close 函数关闭套接字，结束与服务器端的连接。(对套接字调用 close 函数，相当于向建立连接的对端套接字发送 EOF。即，如果客户端的套接字调用了 close 函数，服务端 read 时会返回 0。)
 
 #### 4.2.7 基于 TCP 的服务端/客户端函数调用关系
 
@@ -167,8 +167,8 @@ addrlen: 第二个结构体参数 servaddr 变量的字节长度
 
 以下是服务端与客户端的代码：
 
-- [echo_server.c](https://github.com/riba2534/TCP-IP-NetworkNote/blob/master/ch04/echo_server.c)
-- [echo_client.c](https://github.com/riba2534/TCP-IP-NetworkNote/blob/master/ch04/echo_client.c)
+- [echo_server.c](echo_server.c)
+- [echo_client.c](echo_client.c)
 
 编译:
 
@@ -234,7 +234,7 @@ Windows 平台下的 Socket 编程（Winsock）与 Linux 平台基本类似，
 
 2. **请说出 TCP/IP 协议栈中链路层和IP层的作用，并给出二者关系**
 
-   答：链路层是物理链接领域标准化的结果，专门定义网络标准。若两台主机通过网络进行数据交换，则首先要做到的就是进行物理链接。IP层：为了在复杂的网络中传输数据，首先需要考虑路径的选择。关系：链路层负责进行一系列物理连接，而IP层负责选择正确可行的物理路径。
+   答：链路层是物理连接领域标准化的结果，专门定义网络标准。若两台主机通过网络进行数据交换，则首先要做到的就是进行物理连接。IP层：为了在复杂的网络中传输数据，首先需要考虑路径的选择。关系：链路层负责进行一系列物理连接，而IP层负责选择正确可行的物理路径。
 
 3. **为何需要把 TCP/IP 协议栈分成 4 层（或7层）？开放式回答。**
 
@@ -242,7 +242,7 @@ Windows 平台下的 Socket 编程（Winsock）与 Linux 平台基本类似，
 
 4. **客户端调用 connect 函数向服务器端发送请求。服务器端调用哪个函数后，客户端可以调用 connect 函数？**
 
-   答：服务端调用 listen 函数后，客户端可以调用 connect 函数。因为，服务端调用 listen 函数后，服务端套接字才有能力接受请求连接的信号。
+   答：服务端调用 listen 函数后，客户端可以调用 connect 函数。因为服务端调用 listen 函数后，服务端套接字才具备接收连接请求的能力。
 
 5. **什么时候创建连接请求等待队列？它有何种作用？与 accept 有什么关系？**
 

ch04/echo_client.c

@@ -45,6 +45,8 @@ int main(int argc, char *argv[])
 
         write(sock, message, strlen(message));
         str_len = read(sock, message, BUF_SIZE - 1);
+        if (str_len == -1)
+            error_handling("read() error!");
         message[str_len] = 0;
         printf("Message from server: %s", message);
     }