docs: 全面审查并修正所有章节文档内容

- 修正各章节中的错别字和术语错误（如 IPv4 大写规范、接收/接受区分等）
- 补充和完善部分习题答案
- 优化技术描述的准确性和专业性
- 合并所有章节内容到根 README.md

新增文件：
- CLAUDE.md: 项目开发指南
- .claude/agents/content-reviewer.md: 内容审查 subagent
- .claude/agents/merger.md: 文档合并 subagent

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

ch09/README.md

@@ -52,11 +52,11 @@ sock: 用于查看选项套接字文件描述符
 level: 要查看的可选项协议层
 optname: 要查看的可选项名
 optval: 保存查看结果的缓冲地址值
-optlen: 向第四个参数传递的缓冲大小。调用函数候，该变量中保存通过第四个参数返回的可选项信息的字节数。
+optlen: 向第四个参数传递的缓冲大小。调用函数后，该变量中保存通过第四个参数返回的可选项信息的字节数。
 */
 ```
 
-上述函数可以用来读取套接字可选项，下面的函数可以更改可选项：d
+上述函数可以用来读取套接字可选项，下面的函数可以更改可选项：
 
 ```c
 #include <sys/socket.h>
@@ -68,7 +68,7 @@ sock: 用于更改选项套接字文件描述符
 level: 要更改的可选项协议层
 optname: 要更改的可选项名
 optval: 保存更改结果的缓冲地址值
-optlen: 向第四个参数传递的缓冲大小。调用函数后，该变量中保存通过第四个参数返回的可选项信息的字节数。
+optlen: 向第四个参数传递的缓冲大小值（选项值的长度）。
 */
 ```
 
@@ -127,7 +127,7 @@ Output buffer size: 16384
 编译运行：
 
 ```shell
-gcc get_buf.c -o setbuf
+gcc set_buf.c -o setbuf
 ./setbuf
 ```
 
@@ -170,7 +170,7 @@ Output buffer size: 6144
 
 #### 9.2.3 地址再分配
 
-Time-wait 状态看似重要，但是不一定讨人喜欢。如果系统发生故障紧急停止，这时需要尽快重启服务起以提供服务，但因处于 Time-wait 状态而必须等待几分钟。因此，Time-wait 并非只有优点，这些情况下容易引发大问题。下图中展示了四次握手时不得不延长 Time-wait 过程的情况。
+Time-wait 状态看似重要，但是不一定讨人喜欢。如果系统发生故障紧急停止，这时需要尽快重启服务器以提供服务，但因处于 Time-wait 状态而必须等待几分钟。因此，Time-wait 并非只有优点，这些情况下容易引发大问题。下图中展示了四次握手时不得不延长 Time-wait 过程的情况。
 
 ![](https://i.loli.net/2019/01/19/5c42dec2ba42b.png)
 
@@ -200,7 +200,7 @@ setsockopt(serv_sock, SOL_SOCKET, SO_REUSEADDR, (void *)&option, optlen);
 
 TCP 套接字默认使用 `Nagle` 算法交换数据，因此最大限度的进行缓冲，直到收到 ACK 。左图也就是说一共传递 4 个数据包以传输一个字符串。从右图可以看出，发送数据包一共使用了 10 个数据包。由此可知，不使用 `Nagle` 算法将对网络流量产生负面影响。即使只传输一个字节的数据，其头信息都可能是几十个字节。因此，为了提高网络传输效率，必须使用 `Nagle` 算法。
 
- `Nagle` 算法并不是什么情况下都适用，网络流量未受太大影响时，不使用 `Nagle` 算法要比使用它时传输速度快。最典型的就是「传输大文数据」。将文件数据传入输出缓冲不会花太多时间，因此，不使用 `Nagle` 算法，也会在装满输出缓冲时传输数据包。这不仅不会增加数据包的数量，反而在无需等待 ACK 的前提下连续传输，因此可以大大提高传输速度。
+ `Nagle` 算法并不是什么情况下都适用，网络流量未受太大影响时，不使用 `Nagle` 算法要比使用它时传输速度快。最典型的就是「传输大文件数据」。将文件数据传入输出缓冲不会花太多时间，因此，不使用 `Nagle` 算法，也会在装满输出缓冲时传输数据包。这不仅不会增加数据包的数量，反而在无需等待 ACK 的前提下连续传输，因此可以大大提高传输速度。
 
 所以，未准确判断数据性质时不应禁用 `Nagle` 算法。
 
@@ -234,12 +234,12 @@ getsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (void *)&opt_val, &opt_len);
 
 1. **下列关于 Time-wait 状态的说法错误的是？**
 
-   答：以下字体加粗的代表正确。
+   答：错误的说法是第 1、3、4 项。正确的说法是第 2 项（加粗显示）。
 
-   1. Time-wait 状态只在服务器的套接字中发生
-   2. **断开连接的四次握手过程中，先传输 FIN 消息的套接字将进入 Time-wait 状态。**
-   3. Time-wait 状态与断开连接的过程无关，而与请求连接过程中 SYN 消息的传输顺序有关
-   4. Time-wait 状态通常并非必要，应尽可能通过更改套接字可选项来防止其发生
+   1. ~~Time-wait 状态只在服务器的套接字中发生~~（错误：客户端先断开连接时也会进入 Time-wait 状态）
+   2. **断开连接的四次握手过程中，先传输 FIN 消息的套接字将进入 Time-wait 状态。**（正确）
+   3. ~~Time-wait 状态与断开连接的过程无关，而与请求连接过程中 SYN 消息的传输顺序有关~~（错误：Time-wait 状态与断开连接的四次握手过程直接相关）
+   4. ~~Time-wait 状态通常并非必要，应尽可能通过更改套接字可选项来防止其发生~~（错误：Time-wait 状态对于保证 TCP 连接可靠关闭是必要的，但在某些紧急重启场景下可通过 SO_REUSEADDR 重用端口）
 
 2. **TCP_NODELAY 可选项与 Nagle 算法有关，可通过它禁用 Nagle 算法。请问何时应考虑禁用 Nagle 算法？结合收发数据的特性给出说明。**