Update 计算机网络.md

notes/计算机网络.md

@@ -398,10 +398,15 @@ TCP 虽然是面向字节流的，但其传输的基本数据单元则是报文
 各字段的含义如下：
 
 1. **源端口和目的端口**：各占 2 个字节。
+
 2. **序号**：占 4 字节，序号范围为 [ 0 , 2<sup>32</sup> - 1 ] ，序号增加到 2<sup>32</sup> - 1 后又会回到 0 。在一个 TCP 连接中，传送的字节流中的每一个字节都要按顺序进行编号。
+
 3. **确认号**：占 4 字节，表示期望收到对方下一个报文段的第一个数据字节的序号。例如 B 收到 A 的报文，序号值为 501 ，数据长度为 200 字节（序号 501 ~ 700），此时表明 B 正确收到了序号 700 及其之前的所有数据，因此 B 在发送给 A 的确认报文段中确认号的值为 701。
+
 4. **数据偏移**：占 4 位，其所能表达的最大数字是 15 。数据偏移表示该数据报中数据的起始位置，由于数据报是由 首部+数据 组成，所以实际上就是指报文段的首部长度。数据偏移的单位是 32 位字（即以 4 字节长为单位），所以数据偏移的最大长度是 60 （15*4）字节，即 TCP 报文段的首部长度不能超过 60 字节，对应的选项长度不能超过 40 字节。
+
 5. **保留**：占 6 位，保留为今后使用，目前应置为 0 。
+
 6. **六个控制位**：其作用分别如下：
    + **紧急 URG (URGent)**：当值为 1 时，表明紧急指针字段有效，代表此报文中有紧急数据，应尽快传送，而无需按原来的排队顺序传送。
    + **确认 ACK (ACKnowledgment)**：当值为 1 时，确认号有效；值为 0 时，确认号无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置为 1。
@@ -409,9 +414,13 @@ TCP 虽然是面向字节流的，但其传输的基本数据单元则是报文
    + **复位 RST (Reset)**：当值为 1 时，表明 TCP 连接出现严重差错，必须立即释放，然后再重新建立连接；也可以用来拒绝一个非法的报文段或拒绝打开一个连接。
    + **同步 SYN (SYNchronization)**：在连接建立时用来同步序号。当 SYN = 1 而 ACK = 0 时，表明这是一个连接请求报文段；对方若同意建立连接，则应在响应的报文段中使 SYN = 1 和 ACK = 1 。
    + **终止 FIN (FINis)**：当值为 1 时，表明此报文段发送方的数据已发送完毕，并要求释放连接。
+   
 7. **窗口**：占 2 字节，取值范围为 [ 0 , 2<sup>16</sup> - 1 ] 之间的整数。窗口字段保持动态变化，用于指明接收方允许发送方发送的数据量。
+
 8. **校验和**：占 2 字节，校验的字段范围包括首部和数据。
+
 9. **紧急指针**：占 2 字节，仅在 URG = 1 时才有意义，用于指明紧急数据的结束位置，位于结束位置之后的就是普通数据。
+
 10. **选项**：长度可变，最长可达 40 字节。可用的选项有：最大报文段长度 ，窗口扩大选项、时间戳选项等。
 
 ### 5.4 三次握手
@@ -422,9 +431,13 @@ TCP 建立连接的过程叫做握手，握手需要在客户和服务器之间
 
 
 1. 服务器进程 B 首先创建传输控制模块 TCB，然后进入 LISTEN（收听）状态，准备接受客户端的连接请求；
+
 2. 客户端进程 A 首先创建传输控制模块 TCB，然后发出连接请求报文段，此时同步位 `SYN = 1` ，同时选择一个初始序号 `seq = x` ，之后进入 SYN-SENT（同步已发送）状态；
+
 3. B 收到连接请求报文段后，如果同意建立连接，则发送确认报文段，此时 SYN 和 ACK 都置为 1，确认号 `ack = x + 1` ，并为自己选择一个初始序号 `seq =y` ，之后进入 SYN-RCVD（同步收到）状态；
+
 4. A 收到来自 B 的确认后，发出最后的确认，确认报文段的 ACK 为 1，确认号 `ack = y + 1`，序号 `seq = x + 1`。TCP 标准规定，ACK 报文段可以携带数据也可以不携带，如果不携带则该序号不被消耗，下一个数据报文段的序号仍然是 `seq = x + 1`。之后 A 进入 ESTABLISHED（已连接）状态；
+
 5. 当 B 收到 A 的确认后，也进入 ESTABLISHED 状态。 
 
 ### 5.5 四次挥手
@@ -435,11 +448,17 @@ TCP 建立连接的过程叫做握手，握手需要在客户和服务器之间
 
 
 1. 假设应用进程 A 先主动关闭连接，此时需要发送连接释放报文段：首部终止控制位 FIN 为 1，序号 `seq = u`，其中 u 等于前面传送过的数据的最后一个字节的序号加 1 。之后 A 进入 FIN-WAIT-1（终止等待 1）状态；
+
 2. 应用进程 B 收到连接释放报文段后立即发出确认，确认号 `ack = u + 1`，序号 `seq = v` ，其中 v 等于前面传送过的数据的最后一个字节的序号加 1 。之后 B 进入 CLOSE-WAIT（关闭等待）状态，并通知高层应用进程。此时 TCP 连接处于半关闭状态，即 A 已经没有数据需要发送，但如果 B 发送数据，A 仍要接收；
+
 3. A 收到来自 B 的确认后就进入 FIN-WAIT-2（终止等待 2）状态，等待 B 发出连接释放报文段；
+
 4. 若高层应用进程已经没有数据要发送，则通知 B 释放 TCP 连接。此时 B 发出释放连接报文段：首部终止控制位 FIN 为 1，序号 `seq = w`（在半关闭状态下 B 可能又发送了一些数据），另外还需要重复上次已经发送过的确认号 `ack = u + 1`。之后 B 进入 LAST-ACK（最后确认）状态；
+
 5. A 收到 B 的连接释放报文段后，发出最后确认：ACK 为 1，确认号 `ack = w + 1`，序号 `seq = u + 1`，然后进入 TIME-WAIT（有时间限制的等待）状态；
+
 6. B 收到来自 A 的最后确认后进入 CLOSED（关闭）状态；
+
 7. A 经过 2 倍的 MSL（Maximum Segment Lifetime，最长报文段寿命）后，才进入 CLOSED 状态。
 
 RFC 793 建议 MSL 设置为 2 分钟，现在的网络环境已经有了质的提升，该值可以按需缩短。A 之所以要等待两倍的 MSL 时间后才进入 CLOSED 状态，主要基于以下两个原因：