From 2cbd9cf37636cb3e476a1ffd61f4828f6f1c557c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E4=B8=8A=E5=AE=98=E6=B0=B8=E7=9F=B3?= <841842619@qq.com>
Date: Wed, 29 Jun 2022 23:19:36 +0800
Subject: [PATCH] =?UTF-8?q?=E4=BF=AE=E6=94=B9=20ch04=20=E9=94=99=E5=AD=97?=
 =?UTF-8?q?=20&=20=E4=BF=AE=E6=94=B9=E9=83=A8=E5=88=86=E8=A1=A8=E8=BF=B0?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ch04/README.md | 31 +++++++++++++++++++------------
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/ch04/README.md b/ch04/README.md
index da4b54a..0f1a096 100644
--- a/ch04/README.md
+++ b/ch04/README.md
@@ -20,13 +20,13 @@ TCP/IP 协议栈共分为 4 层，可以理解为数据收发分成了 4 个层
 
 #### 4.1.3 IP 层
 
-转备好物理连接候就要传输数据。为了再复杂网络中传输数据，首先要考虑路径的选择。向目标传输数据需要经过哪条路径？解决此问题的就是IP层，该层使用的协议就是IP。
+准备好物理连接后就要传输数据。为了在复杂网络中传输数据，首先要考虑路径的选择。向目标传输数据需要经过哪条路径？解决此问题的就是IP层，该层使用的协议就是IP。
 
 IP 是面向消息的、不可靠的协议。每次传输数据时会帮我们选择路径，但并不一致。如果传输过程中发生错误，则选择其他路径，但是如果发生数据丢失或错误，则无法解决。换言之，IP协议无法应对数据错误。
 
 #### 4.1.4 TCP/UDP 层
 
-IP 层解决数据传输中的路径选择问题，秩序照此路径传输数据即可。TCP 和 UDP 层以 IP 层提供的路径信息为基础完成实际的数据传输，故该层又称为传输层。UDP 比 TCP 简单，现在我们只解释 TCP 。 TCP 可以保证数据的可靠传输，但是它发送数据时以 IP 层为基础（这也是协议栈层次化的原因）
+IP 层解决数据传输中的路径选择问题，只需照此路径传输数据即可。TCP 和 UDP 层以 IP 层提供的路径信息为基础完成实际的数据传输，故该层又称为传输层。UDP 比 TCP 简单，现在我们只解释 TCP 。 TCP 可以保证数据的可靠传输，但是它发送数据时以 IP 层为基础（这也是协议栈层次化的原因）。
 
 IP 层只关注一个数据包（数据传输基本单位）的传输过程。因此，即使传输多个数据包，每个数据包也是由 IP 层实际传输的，也就是说传输顺序及传输本身是不可靠的。若只利用IP层传输数据，则可能导致后传输的数据包B比先传输的数据包A提早到达。另外，传输的数据包A、B、C中可能只收到A和C，甚至收到的C可能已经损毁 。反之，若添加 TCP 协议则按照如下对话方式进行数据交换。
 
@@ -56,7 +56,7 @@ IP 层只关注一个数据包（数据传输基本单位）的传输过程。
 
 #### 4.2.2 进入等待连接请求状态
 
-已经调用了 bind 函数给他要借资分配地址，接下来就是要通过调用 listen 函数进入等待链接请求状态。只有调用了 listen 函数，客户端才能进入可发出连接请求的状态。换言之，这时客户端才能调用 connect 函数
+已经调用了 bind 函数给套接字分配地址，接下来就是要通过调用 listen 函数进入等待链接请求状态。只有调用了 listen 函数，客户端才能进入可发出连接请求的状态。客户端可以调用 connect 函数，向服务端请求连接，对于客户端发来的请求，先进入连接请求等待队列，等待服务端受理请求。
 
 ```c
 #include <sys/socket.h>
@@ -67,7 +67,7 @@ int listen(int sockfd, int backlog);
 ```
 #### 4.2.3 受理客户端连接请求
 
-调用 listen 函数后，则应该按序受理。受理请求意味着可接受数据的状态。进入这种状态所需的部件是**套接字**，但是此时使用的不是服务端套接字，此时需要另一个套接字，但是没必要亲自创建，下面的函数将自动创建套接字。
+调用 listen 函数后，套接字应该按序受理客户端发起的连接请求。受理请求就是服务端处理一个连接请求，进入可接受客户端数据的状态。进入这种状态所需的部件是**套接字**，但是此时使用的不是服务端套接字，此时需要另一个套接字，但是没必要亲自创建，下面的函数将自动创建套接字。
 
 ```c
 #include <sys/socket.h>
@@ -75,12 +75,14 @@ int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
 /*
 成功时返回文件描述符，失败时返回-1
 sock: 服务端套接字的文件描述符
-addr: 保存发起连接请求的客户端地址信息的变量地址值
-addrlen: 的第二个参数addr结构体的长度，但是存放有长度的变量地址。
+addr: 受理的请求中，客户端地址信息会保存到该指针指向的地址
+addrlen: 该指针指向的地址中保存第二个参数的结构体长度
 */
 ```
 
-sccept 函数受理连接请求队列中待处理的客户端连接请求。函数调用成功后，accept 内部将产生用于数据 I/O 的套接字，并返回其文件描述符。需要强调的是套接字是自动创建的，并自动与发起连接请求的客户端建立连接。
+accept 函数受理连接请求队列中待处理的客户端连接请求。函数调用成功后，accept 内部将产生用于数据 I/O 的套接字，并返回其文件描述符。需要强调的是套接字是自动创建的，并自动与发起连接请求的客户端建立连接。
+
+注意：accept 函数返回的套接字不等于服务端套接字，也需要通过 close 函数关闭。
 
 #### 4.2.4 回顾 Hello World 服务端
 
@@ -98,7 +100,7 @@ sccept 函数受理连接请求队列中待处理的客户端连接请求。函
 
 ![](https://i.loli.net/2019/01/14/5c3c31d77e86c.png)
 
-与服务端相比，区别就在于「请求连接」，他是创建客户端套接字后向服务端发起的连接请求。服务端调用 listen 函数后创建连接请求等待队列，之后客户端即可请求连接。
+与服务端相比，区别就在于「请求连接」，它是创建客户端套接字后向服务端发起的连接请求。服务端调用 listen 函数后创建连接请求等待队列，之后客户端即可请求连接。
 
 ```c
 #include <sys/socket.h>
@@ -107,17 +109,19 @@ int connect(int sock, struct sockaddr *servaddr, socklen_t addrlen);
 成功时返回0，失败返回-1
 sock:客户端套接字文件描述符
 servaddr: 保存目标服务器端地址信息的变量地址值
-addrlen: 以字节为单位传递给第二个结构体参数 servaddr 的变量地址长度
+addrlen: 第二个结构体参数 servaddr 变量的字节长度
 */
 ```
 
-客户端调用 connect 函数候，发生以下函数之一才会返回（完成函数调用）:
+客户端调用 connect 函数后，发生以下函数之一才会返回（完成函数调用）:
 
 - 服务端接受连接请求
 - 发生断网等一场状况而中断连接请求
 
 注意：**接受连接**不代表服务端调用 accept 函数，其实只是服务器端把连接请求信息记录到等待队列。因此 connect 函数返回后并不应该立即进行数据交换。
 
+客户端在调用connect函数时自动分配主机的IP，随机分配端口。无需调用标记的bind函数进行分配。
+
 #### 4.2.6 回顾 Hello World 客户端
 
 - 代码：[hello_client.c](https://github.com/riba2534/TCP-IP-NetworkNote/blob/master/ch04/hello_client.c)
@@ -132,9 +136,12 @@ addrlen: 以字节为单位传递给第二个结构体参数 servaddr 的变量
 
 #### 4.2.7 基于 TCP 的服务端/客户端函数调用关系
 
+关系图如下所示：
+
 ![](https://i.loli.net/2019/01/14/5c3c35a773b8c.png)
 
-关系如上图所示。
+- 客户端只能等到服务端调用 listen 函数后才才能调用 connect 函数
+- 服务器端可能会在客户端调用 connect 之前调用 accept 函数，这时服务器端进入阻塞（blocking）状态，直到客户端调用 connect 函数后接收到连接请求。
 
 ### 4.3 实现迭代服务端/客户端
 
@@ -189,7 +196,7 @@ client:
 
 #### 4.3.3 回声客户端存在的问题
 
-以上代码有一个假设「每次调用 read、write函数时都会以字符串为单位执行实际 I/O 操作」
+以上客户端代码有一个假设「每次调用 read、write函数时都会以字符串为单位执行实际 I/O 操作」
 
 但是「第二章」中说过「TCP 不存在数据边界」，上述客户端是基于 TCP 的，因此多次调用 write 函数传递的字符串有可能一次性传递到服务端。此时客户端有可能从服务端收到多个字符串，这不是我们想要的结果。还需要考虑服务器的如下情况：