mirror of
https://github.com/riba2534/TCP-IP-NetworkNote.git
synced 2026-05-07 05:51:47 +08:00
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>
This commit is contained in:
riba2534
@@ -2,7 +2,7 @@
|
||||
|
||||
本章代码，在[TCP-IP-NetworkNote](https://github.com/riba2534/TCP-IP-NetworkNote)中可以找到。
|
||||
|
||||
上一章仅仅是从编程角度学习实现方法，并未详细讨论 TCP 的工作原理。因此，本章将想次讲解 TCP 中必要的理论知识，还将给出第 4 章客户端问题的解决方案。
|
||||
上一章仅仅是从编程角度学习实现方法，并未详细讨论 TCP 的工作原理。因此，本章将详细讲解 TCP 中必要的理论知识，还将给出第 4 章客户端问题的解决方案。
|
||||
|
||||
### 5.1 回声客户端的完美实现
|
||||
|
||||
@@ -15,14 +15,14 @@ while ((str_len = read(clnt_sock, message, BUF_SIZE)) != 0)
|
||||
write(clnt_sock, message, str_len);
|
||||
```
|
||||
|
||||
接着是客户端代码:
|
||||
接着是客户端代码：
|
||||
|
||||
```c
|
||||
write(sock, message, strlen(message));
|
||||
str_len = read(sock, message, BUF_SIZE - 1);
|
||||
```
|
||||
|
||||
二者都在循环调用 read 和 write 函数。实际上之前的回声客户端将 100% 接受字节传输的数据，只不过接收数据时的单位有些问题。扩展客户端代码回顾范围，下面是，客户端的代码:
|
||||
二者都在循环调用 read 和 write 函数。实际上之前的回声客户端将 100% 接收字节传输的数据，只不过接收数据时的单位有些问题。扩展客户端代码回顾范围，下面是客户端的代码：
|
||||
|
||||
```c
|
||||
while (1)
|
||||
@@ -40,11 +40,11 @@ while (1)
|
||||
}
|
||||
```
|
||||
|
||||
现在应该理解了问题，回声客户端传输的是字符串，而且是通过调用 write 函数一次性发送的。之后还调用一次 read 函数，期待着接受自己传输的字符串，这就是问题所在。
|
||||
现在应该理解了问题，回声客户端传输的是字符串，而且是通过调用 write 函数一次性发送的。之后还调用一次 read 函数，期待着接收自己传输的字符串，这就是问题所在。
|
||||
|
||||
#### 5.1.2 回声客户端问题的解决办法
|
||||
|
||||
这个问题其实很容易解决，因为可以提前接受数据的大小。若之前传输了20字节长的字符串，则再接收时循环调用 read 函数读取 20 个字节即可。既然有了解决办法，那么代码如下：
|
||||
这个问题其实很容易解决，因为可以提前接收数据的大小。若之前传输了 20 字节长的字符串，则在接收时循环调用 read 函数读取 20 个字节即可。既然有了解决办法，那么代码如下：
|
||||
|
||||
- [echo_client2.c](https://github.com/riba2534/TCP-IP-NetworkNote/blob/master/ch05/echo_client2.c)
|
||||
|
||||
@@ -57,15 +57,15 @@ while (1)
|
||||
现在写一个小程序来体验应用层协议的定义过程。要求：
|
||||
|
||||
1. 服务器从客户端获得多个数组和运算符信息。
|
||||
2. 服务器接收到数字候对齐进行加减乘运算，然后把结果传回客户端。
|
||||
2. 服务器接收到数字后对齐进行加减乘运算，然后把结果传回客户端。
|
||||
|
||||
例：
|
||||
|
||||
1. 向服务器传递3,5,9的同事请求加法运算，服务器返回3+5+9的结果
|
||||
1. 向服务器传递 3, 5, 9 的同时请求加法运算，服务器返回 3+5+9 的结果
|
||||
2. 请求做乘法运算，客户端会收到`3*5*9`的结果
|
||||
3. 如果向服务器传递4,3,2的同时要求做减法，则返回4-3-2的运算结果。
|
||||
3. 如果向服务器传递 4, 3, 2 的同时要求做减法，则返回 4-3-2 的运算结果。
|
||||
|
||||
请自己实现一个程序来实现功能。
|
||||
请自己实现一个程序来实现以上功能。
|
||||
|
||||
我自己的实现：
|
||||
|
||||
@@ -99,7 +99,7 @@ gcc op_client.c -o opclient
|
||||
gcc op_server.c -o opserver
|
||||
```
|
||||
|
||||
运行:
|
||||
运行：
|
||||
|
||||
```shell
|
||||
./opserver 9190
|
||||
@@ -114,9 +114,9 @@ gcc op_server.c -o opserver
|
||||
|
||||
#### 5.2.1 TCP 套接字中的 I/O 缓冲
|
||||
|
||||
TCP 套接字的数据收发无边界。服务器即使调用 1 次 write 函数传输 40 字节的数据，客户端也有可能通过 4 次 read 函数调用每次读取 10 字节。但此处也有一些疑问，服务器一次性传输了 40 字节，而客户端竟然可以缓慢的分批接受。客户端接受 10 字节后，剩下的 30 字节在何处等候呢？
|
||||
TCP 套接字的数据收发无边界。服务器即使调用 1 次 write 函数传输 40 字节的数据，客户端也有可能通过 4 次 read 函数调用每次读取 10 字节。但此处也有一些疑问，服务器一次性传输了 40 字节，而客户端竟然可以缓慢的分批接收。客户端接收 10 字节后，剩下的 30 字节在何处等候呢？
|
||||
|
||||
实际上，write 函数调用后并非立即传输数据， read 函数调用后也并非马上接收数据。如图所示，write 函数调用瞬间，数据将移至输出缓冲；read 函数调用瞬间，从输入缓冲读取数据。
|
||||
实际上，write 函数调用后并非立即传输数据，read 函数调用后也并非马上接收数据。如图所示，write 函数调用瞬间，数据将移至输出缓冲；read 函数调用瞬间，从输入缓冲读取数据。
|
||||
|
||||
|
||||
|
||||
@@ -135,7 +135,7 @@ I/O 缓冲特性可以整理如下：
|
||||
|
||||
> - A：你好，最多可以向我传递 50 字节
|
||||
> - B：好的
|
||||
> - A：我腾出了 20 字节的空间，最多可以接受 70 字节
|
||||
> - A：我腾出了 20 字节的空间，最多可以接收 70 字节
|
||||
> - B：好的
|
||||
|
||||
数据收发也是如此，因此 TCP 中不会因为缓冲溢出而丢失数据。
|
||||
@@ -164,7 +164,7 @@ TCP 在实际通信中也会经过三次对话过程，因此，该过程又被
|
||||
|
||||
> [SYN] SEQ : 1000 , ACK:-
|
||||
|
||||
该消息中的 SEQ 为 1000 ，ACK 为空，而 SEQ 为1000 的含义如下：
|
||||
该消息中的 SEQ 为 1000，ACK 为空，而 SEQ 为 1000 的含义如下：
|
||||
|
||||
> 现在传递的数据包的序号为 1000，如果接收无误，请通知我向您传递 1001 号数据包。
|
||||
|
||||
@@ -174,11 +174,11 @@ TCP 在实际通信中也会经过三次对话过程，因此，该过程又被
|
||||
|
||||
此时 SEQ 为 2000，ACK 为 1001，而 SEQ 为 2000 的含义如下：
|
||||
|
||||
> 现传递的数据包号为 2000 ，如果接受无误，请通知我向您传递 2001 号数据包。
|
||||
> 现在传递的数据包号为 2000，如果接收无误，请通知我向您传递 2001 号数据包。
|
||||
|
||||
而 ACK 1001 的含义如下：
|
||||
|
||||
> 刚才传输的 SEQ 为 1000 的数据包接受无误，现在请传递 SEQ 为 1001 的数据包。
|
||||
> 刚才传输的 SEQ 为 1000 的数据包接收无误，现在请传递 SEQ 为 1001 的数据包。
|
||||
|
||||
对于主机 A 首次传输的数据包的确认消息（ACK 1001）和为主机 B 传输数据做准备的同步消息（SEQ 2000）捆绑发送。因此，此种类消息又称为 SYN+ACK。
|
||||
|
||||
@@ -192,7 +192,7 @@ TCP 在实际通信中也会经过三次对话过程，因此，该过程又被
|
||||
|
||||
|
||||
|
||||
图上给出了主机 A 分成 2 个数据包向主机 B 传输 200 字节的过程。首先，主机 A 通过 1 个数据包发送 100 个字节的数据，数据包的 SEQ 为 1200 。主机 B 为了确认这一点，向主机 A 发送 ACK 1301 消息。
|
||||
图上给出了主机 A 分成 2 个数据包向主机 B 传输 200 字节的过程。首先，主机 A 通过 1 个数据包发送 100 个字节的数据，数据包的 SEQ 为 1200。主机 B 为了确认这一点，向主机 A 发送 ACK 1301 消息。
|
||||
|
||||
此时的 ACK 号为 1301 而不是 1201，原因在于 ACK 号的增量为传输的数据字节数。假设每次 ACK 号不加传输的字节数，这样虽然可以确认数据包的传输，但无法明确 100 个字节全都正确传递还是丢失了一部分，比如只传递了 80 字节。因此按照如下公式传递 ACK 信息：
|
||||
|
||||
@@ -217,7 +217,7 @@ TCP 套接字的结束过程也非常优雅。如果对方还有数据需要传
|
||||
|
||||
|
||||
|
||||
图中数据包内的 FIN 表示断开连接。也就是说，双方各发送 1 次 FIN 消息后断开连接。此过过程经历 4 个阶段，因此又称四次握手（Four-way handshaking）。SEQ 和 ACK 的含义与之前讲解的内容一致，省略。图中，主机 A 传递了两次 ACK 5001，也许这里会有困惑。其实，第二次 FIN 数据包中的 ACK 5001 只是因为接收了 ACK 消息后未接收到的数据重传的。
|
||||
图中数据包内的 FIN 表示断开连接。也就是说，双方各发送 1 次 FIN 消息后断开连接。此过程经历 4 个阶段，因此又称四次握手（Four-way handshaking）。SEQ 和 ACK 的含义与之前讲解的内容一致，省略。图中，主机 A 传递了两次 ACK 5001，也许这里会有困惑。其实，第二次 FIN 数据包中的 ACK 5001 只是因为接收了 ACK 消息后未接收到的数据重传的。
|
||||
|
||||
### 5.3 基于 Windows 的实现
|
||||
|
||||
@@ -229,13 +229,13 @@ TCP 套接字的结束过程也非常优雅。如果对方还有数据需要传
|
||||
|
||||
1. **请说明 TCP 套接字连接设置的三次握手过程。尤其是 3 次数据交换过程每次收发的数据内容。**
|
||||
|
||||
答：TCP套接字的生命周期主要可分为3个部分: ①与对方套接字建立连接 ②与对方套接字进行数据交换 ③断开与对方套接字的连接。
|
||||
答：TCP 套接字的生命周期主要可分为 3 个部分：①与对方套接字建立连接 ②与对方套接字进行数据交换 ③断开与对方套接字的连接。
|
||||
|
||||
其中,在第一步建立连接的阶段,又可细分为3个步骤(即`三次握手`)：①由主机1给主机2发送初始的SEQ，首次连接请求是关键字是SYN，表示收发数据前同步传输的消息,此时报文的ACK一般为空。②主机2收到报文以后，给主机 1 传递信息，用一个新的SEQ表示自己的序号，然后ACK代表已经接受到主机1的消息，希望接受下一个消息③主机1收到主机2的确认以后，还需要给主机2给出确认，此时再发送一次SEQ和ACK。
|
||||
其中，在第一步建立连接的阶段，又可细分为 3 个步骤（即`三次握手`）：①由主机 1 给主机 2 发送初始的 SEQ，首次连接请求的关键字是 SYN，表示收发数据前同步传输的消息，此时报文的 ACK 一般为空。②主机 2 收到报文以后，给主机 1 传递信息，用一个新的 SEQ 表示自己的序号，然后 ACK 代表已经接收到主机 1 的消息，希望接收下一个消息。③主机 1 收到主机 2 的确认以后，还需要给主机 2 给出确认，此时再发送一次 SEQ 和 ACK。
|
||||
|
||||
2. **TCP 是可靠的数据传输协议，但在通过网络通信的过程中可能丢失数据。请通过 ACK 和 SEQ 说明 TCP 通过和何种机制保证丢失数据的可靠传输。**
|
||||
2. **TCP 是可靠的数据传输协议，但在通过网络通信的过程中可能丢失数据。请通过 ACK 和 SEQ 说明 TCP 通过何种机制保证丢失数据的可靠传输。**
|
||||
|
||||
答：通过超时重传机制来保证，如果报文发出去的特定时间内，发送消息的主机没有收到另一个主机的回复，那么就继续发送这条消息，直到收到回复为止。
|
||||
答：TCP 通过超时重传机制和确认应答（ACK）机制来保证可靠传输。具体过程如下：发送方每次发送数据时都会带上一个序列号（SEQ），接收方收到数据后会返回一个确认号（ACK），ACK 号的值等于 SEQ 号加上接收到的字节数再加 1，表示期待接收的下一个序列号。如果发送方在规定时间内没有收到对应的 ACK 确认，TCP 套接字的计时器会发生超时，发送方会重传该数据包。通过这种 SEQ/ACK 机制配合超时重传，TCP 可以确保数据包的可靠传输。
|
||||
|
||||
3. **TCP 套接字中调用 write 和 read 函数时数据如何移动？结合 I/O 缓冲进行说明。**
|
||||
|
||||
@@ -243,4 +243,4 @@ TCP 套接字的结束过程也非常优雅。如果对方还有数据需要传
|
||||
|
||||
4. **对方主机的输入缓冲剩余 50 字节空间时，若本主机通过 write 函数请求传输 70 字节，请问 TCP 如何处理这种情况？**
|
||||
|
||||
答：TCP 中有滑动窗口控制协议，所以传输的时候会保证传输的字节数小于等于自己能接受的字节数。
|
||||
答：TCP 中有滑动窗口控制协议，所以传输的时候会保证传输的字节数小于等于对方能接收的字节数。在这种情况下，TCP 只会发送 50 字节的数据（或者更少），剩余的 20 字节会保留在发送方的输出缓冲中，等待对方腾出更多空间后再发送。write 函数可能会阻塞等待，或者返回实际发送的字节数（部分写入）。
|
||||
|
||||
Reference in New Issue
Block a user