网络：当你键入网址之后，发生了什么

怼烎@ 2022-12-17 08:47 193阅读 0赞

### 文章目录 ###

*  URI解析
 *   *  一般过程
     *  补充信息
 *  DNS查询：将域名翻译成IP地址
 *  TCP/UDP传输层：传输数据包到目的IP
 *   *  TCP-- 可靠的数据传输
     *   *  TCP包头格式
         *  TCP 三次握手
         *  TCP 分割数据
         *  TCP 报文生成
         *  TCP连接终止（四次挥手）
         *  TCP状态机
     *  IP--远程定位
     *   *  IP包头格式
     *  MAC--两点传输
     *   *  MAC 包头格式
         *  怎么生成报文
     *  交换机-- 送别者
     *  路由器--出境大门
     *   *  工作原理
         *  路由器和交换机的区别
     *  服务器 与 客户端--相互扒皮

# URI解析 #

## 一般过程 ##

当你在浏览器中输入信息时，浏览器就已经开始进行工作了。首先它会监听我们输入的信息并尝试匹配出你想要访问的网址或关键词，以 chrome 为例，它会猜我们想要什么，给出下面的建议项：

*  使用默认搜索引擎搜索关键字
 *  书签，历史记录和最近下载中存储的其他链接
 *  使用默认搜索引擎的相关关键字搜索选项

当我们在地址栏输入xxxx.com后**回车**，命令浏览器搜索信息。浏览器就会对输入的信息进行以下判断：

*  输入的是不是一个合法的URI
    
     *  如果不是，就将输入的内容作为搜索的条件，生成一个**HTTP数据包**
     *  如果是，判断输入是否完整。浏览器可能会对域猜测，也就是说尝试通过在输入的内容中添加前缀、后缀或两者来 “补全” URL。比如输入 xxx.com 则可能会在前面添加 www。等有了一个URI之后，就**解析URI**。  
        ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center]
        
         *  待URI解析完毕之后，就可以的到**服务器域名**等，然后就可以根据这些消息**生成一个HTTP数据包**了
            
             *  浏览器先从URI中取出协议，比如http协议，然后根据不同的协议进行不同的解析。
             *  然后从URI中提取出主机名(host)信息。它可能是一个 IP 地址(比如192.168.0.1），也可以可能是一个域名地址(www.xxx.com)。如果是域名地址就需要访问DNS服务器获取到对应的IP地址，如果是IP地址就不需要进行这一步了

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 1]

现在已经生成了一个**HTTP数据包**了。

## 补充信息 ##

浏览器还会进行一些额外的操作，比如安全检查、访问限制（之前国产浏览器限制 996.icu）等。

实际上，浏览器会先查看缓存来决定下一步是什么操作：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 2]

# DNS查询：将域名翻译成IP地址 #

**如果在代码或者数据包中就指定的是IP地址而不是域名，那么这一步可以省略**

> 在互联网上有多达到上亿的设备，而这些设备之间互相联通网络，每一台主机都需要一个唯一的标识符（就像是我们每个人都有一张身份证），而这个标识符就是IP地址，由于IP地址是数字，不利于人来使用，人们为了方便记忆，发明了**点分十进制**，但是还是不方便，又发明了**域名**，日常生活中使用的是域名。为了将域名和IP地址对应起来，又发明了DNS服务器。

> DNS 是互联网上重要的基础应用程序，它作为一个**分布式数据库**，**储存着域名与 IP 地址的映射关系**。通过DSN服务器可以查询到域名对应的IP  
> ![在这里插入图片描述][20201023100357869.png_pic_center]

当然，我们并不是直接就去访问DNS服务器，而是先去缓存中查询：  
![在这里插入图片描述][20201023143259357.png_pic_center]

*  **浏览器缓存**：浏览器会先检查是否在缓存中，没有则调用系统库函数进行查询。
 *  **操作系统缓存**：操作系统也有自己的 DNS缓存，但在这之前，会向检查域名是否存在本地的 Hosts 文件里，没有则向 DNS 服务器发送查询请求。
 *  **路由器缓存**
 *  **ISP DNS 缓存**：ISP DNS 就是在客户端电脑上设置的首选 DNS 服务器，它们在大多数情况下都会有缓存。
 *  **根域名服务器查询**：在前面所有步骤没有缓存的情况下，本地 DNS 服务器会将请求转发到互联网上的根域

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 3]

到目前为止，数据包有了，目的IP有了，接下来要做的就是将数据包发出去了

[IP知识总结][IP]  
[抓包分析dns的原理][dns]

# TCP/UDP传输层：传输数据包到目的IP #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 4]  
通过`DNS`获取到目的`IP`之后，就可以将HTTP的传输工作交给操作系统中的协议栈了。  
应用程序（浏览器）通过调用`socket`库，来委托协议栈工作。协议栈的上半部分有两块，

*  TCP和UDP协议，负责接收应用层的委托执行**数据收发**工作。
 *  IP协议负责将数据块发送到目的IP。IP协议中还包括
    
     *  `ICMP`：用于追踪数据的发送过程，告知网络包传送过程中产生的数据以及各种控制信息
     *  `ARP`：根据IP地址查询相应的以太网MAC地址  
        IP下面的网卡驱动程序负责**控制网卡硬件**，而最下面的网卡负责完成实际的收发操作（收发网线中的信号）

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 5]

因为从浏览器输入的"`http`: //xxxxx" 可以知道当前包是采用http协议的，而HTTP是基于TCP协议传输的，因此我们先来学习下TCP协议

## TCP-- 可靠的数据传输 ##

### TCP包头格式 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 6]

*  首先，**源端口号**和**目标端口号**是不可少的，如果没有这两个端口号，数据就不知道应该发给哪个应用。
 *  接下来有包的**序号Seq**，这个是为了解决**包乱序**的问题。
    
     *  TCP连接中传送的数据流中的每一个字节都有一个序号。
     *  序号字段的值指的是本报文所发送的第一个字节的序号。
 *  **确认号Ack**，目的是确认发出去对方是否有收到。如果没有收到就应该重新发送，直到送达，这个是为了**解决不丢包**的问题。
    
     *  ACK是期望收到对方下一个报文段的数据的第一个字节的序号。
     *  只有ACK标志位为1时，确认序号字段才有效，ACK=SEQ+1
 *  接下来还有一些**状态位**：也就是包的类型，主要用于**操控TCP状态机**。TCP 是面向连接的，因而双方要维护连接的状态，这些带状态位的包的发送，会引起双方  
    的状态变更。
    
     *  `URG`
        
         *  设置为1时，首部中的紧急指针有效；它告诉系统此报文段中有紧急数据，应该尽快传送
         *  设置为为0时，紧急指针没有意义。
     *  `ACK`
        
         *  设置为1时，确认字段号才有效
         *  设置为0时，确认字段号才无效
     *  `PSH`：当设置为1时，要求把数据尽快的交给应用层，而不要等到这个缓存都填满了后再向上交付
     *  `RST`是重新连接：当RST=1时，表明TCP连接中出现了严重错误(比如主机崩溃)，必须释放连接，然后再重新建立传输连接
     *  `SYN`是同步比特：当SYN=1时，表明这时一个链接请求或者连接接受报文
     *  `FIN` 是结束连接：当FIN=1时，表明此报文段的发送端已发送完毕，并要求释放运输连接。
 *  **首部长度**，也叫做数据偏移。它指出TCP报文段的数据起始处距离TCP报文段的起始处由多远
 *  还有一个重要的就是**窗口大小**。也就是著名的滑动窗口（Sliding Window），用于解决**流控**的。TCP 要做**流量控制**，通信双方各声明一个窗口（缓存大小），标识自己当前能够的处理能力，别发送的太快，撑死我，也别发的太慢，饿死我。

> 除了做流量控制以外，TCP还会做拥塞控制，对于真正的通路堵车不堵车，它无能为力，唯一能做的就是控制自己，也即控制发送的速度。不能改变世界，就改变自己嘛。

*  **校验和**：它校验的范围包括首部和数据这两部分。在计算校验和时，要在TCP报文段的前面加上12字节的伪首部
 *  **紧急指针**：指出本报文段中的紧急数据的最后一个字节的序号
 *  **选项字段**：长度可变，TCP只规定了一种选项，即最大报文段长度MSS。MSS告诉对方TCP：“我的缓存所能接收的报文段的数据字段的最长长度是MSS个字节”
 *  保留字段：占6位，保留为今后使用，当目前应该置0

### TCP 三次握手 ###

> 在 HTTP 传输数据之前，首先需要 TCP 建立连接，TCP 连接的建立，通常称为**三次握手**

这个所谓的「连接」，只是双方计算机里维护一个**状态机**，在连接建立的过程中，双方的状态变化时序图就像这样  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 7]

*  一开始，客户端和服务端都处于 `CLOSED`状态。
 *  服务器必须准备好接受外来的连接， 主动监听某个端口。这通常通过socket、bind、listen这3个函数来完成，我们称之为**被动打开**， 此时服务端处`LISTEN`状态。
 *  然后客户端主动调用connect应该连接请求(**主动打开**)
    
     *  这个时候客户端TCP会发送一个SYN分节(标志位SYN=1, 发送序号SEX=x) ，它告诉服务器客户将在（待建立）的连接中发送的数据的初始序列号。
     *  通常SYN分节不携带数据，其所在IP数据报只含有一个IP首部，一个TCP首部和可能有的TCP选项。
     *  客户端发送完SYN之后，将处于 `SYN-SENT` 状态，等待服务端确认。
 *  服务端收到数据报后由标志位SYN=1知道客户端请求建立连接，
    
     *  它**必须 ACK(确认)客户端的SYN**(将标志位SYN和ACK都位于1，确认序号ACK=x+1)，同时随机产生一个发送序号SEQ=y(表示服务器将在同一连接中发送的数据的初始序列号)，并将该数据包发送给客户端以确认连接请求。
     *  服务器收到客户端的`SYN`之后处于 `SYN-RCVD`状态。
 *  客户端收到确认后：
    
     *  检测确认序号ACK是否为x+1，标志位ACK是否为1，如果正确，则将ACK置为1，确认序号ACK=y+1，并将该数据包发送给服务端。
     *  客户端随后进入`ESTABLISHED`状态（表示TCP链接成功），因为它一发一收成功了。
 *  服务端收到数据报之后：
    
     *  检测确认序号ACK是否为y+1，标志位ACK是否为1
     *  如果是表明建立成功，并进入 `ESTABLISHED` 状态，因为它也一发一收成功了了。  
        ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]

这种交换至少需要三个分组，因此被称为TCP的三次握手。建立链接后，客户端和服务器就可以相互通信了

注意：

*  **关于连接时SYN超时**。
    
     *  试想一下，如果server端接到了clien发的SYN后回了SYN-ACK后client掉线了，server端没有收到client回来的ACK，那么，这个连接处于一个中间状态，即没成功，也没失败。
     *  于是，server端如果在一定时间内没有收到的TCP会重发SYN-ACK。在Linux下，默认重试次数为5次，重试的间隔时间从1s开始每次都翻售，5次的重试时间间隔为1s, 2s, 4s, 8s, 16s，总共31s，第5次发出后还要等32s都知道第5次也超时了，所以，总共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 2^6 -1 = 63s，TCP才会把断开这个连接。
 *  **关于SYN Flood攻击**： 一些恶意的人就为此制造了SYN Flood攻击—给一个服务器发了一个SYN之后，就下线了，于是服务器就需要默认等待63s才断开连接，这样，攻击者就可以把服务器的syn连接的队列耗尽，让正常的连接请求不能处理。于是，linux下给了一个叫做**tcp\_syncookies**的参数来应对这个事----当SYN队列满了之后，TCP会通过源地址端口、目标地址端口和时间长打造出一个特别的`Sequence Numbe`发回去（又叫cookie）, 如果是攻击者就不会有响应，如果是正常连接，则会把这个SYN Cookie发回来，然后服务器就医通过cookie建立连接（即使你不在SYNC队列中）。请注意，请先千万别用tcp\_syncookies来处理正常的大负载的连接的情况。因为，synccookies是妥协版的TCP协议，并不严谨。对于正常的请求，你应该调整三个TCP参数可供你选择，第一个是：tcp\_synack\_retries 可以用他来减少重试次数；第二个是：tcp\_max\_syn\_backlog，可以增大SYN连接数；第三个是：tcp\_abort\_on\_overflow 处理不过来干脆就直接拒绝连接了。
 *  **关于ISN（初始序列号）的初始化**。ISN是不能hard code的，不然会出问题的。 RFC793中规定：ISN会和一个假的始终绑定在一起，这个时钟没4us会对ISN做加一操作，直到超过2^32，又从0开始，这样，一个ISN的周期大概是4.55小时。因此，我们规定TCP Segment在网络上的存活时间不会超过MSL（RFC793定义了MSL为2分钟，Linux设置成了30s），所以，只要MSL的值小于4.55小时，我们就不会重用到ISN  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 2]

> 如何查看 TCP 的连接状态？

TCP 的连接状态查看，在 Linux 可以通过 `netstat -napt` 命令查看

![在这里插入图片描述][20201030174956852.png_pic_center]

### TCP 分割数据 ###

如果 HTTP 请求消息比较长，超过了`MSS` 的长度，这时 TCP 就需要把 HTTP 的数据拆解成一块块的数据发送，而不是一次性发送所有数据。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 8]

*  `MTU` ：一个网络包的最大长度，以太网中一般为 1500 字节。
 *  `MSS` ：除去`IP` 和 `TCP`头部之后，一个网络包所能容纳的 TCP 数据的最大长度。

数据会被以 `MSS`的长度为单位进行拆分，拆分出来的每一块数据都会被放进单独的网络包中。也就  
是在每个被拆分的数据加上`TCP` 头信息，然后交给 IP 模块来发送数据。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 9]

### TCP 报文生成 ###

TCP协议中会有两个端口，一个是浏览器监听的端口（通常是随机生成的），一个是web服务器监听的端口（HTTP 默认端口号是`80` ， HTTPS 默认端口号是`443`）

在双方建立了链接之后，TCP报文中的数据部分就是存放HTTP头部+数据，组装好TCP报文之后，就需要交给下面的网络层处理。

### TCP连接终止（四次挥手） ###

TCP建立一个连接需要3个分节，终止一个连接需要4个分节。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 3]

*  某个应用程序首先调用`close`，我们称该端执行**主动关闭**(active close)， 该TCP socket就会发送一段TCP报文：
    
     *  发送一个`FIN`分节，表示“请求释放连接”。
     *  序号Seq=U
     *  随后该TCP连接就会进入`FIN-WAIT-1`阶段，即半关闭阶段，并且停止向另一端发送数据（这里的不发送指的是不发送应用数据，而且还是发送ACK等报文）。但是当前应用还是能够接受到另一端发送过来的数据
 *  另一端接受到`FIN`之后，就会结束`established`阶段，进入`CLOSE_WAIT`（半关闭状态-- 表示服务器不再接受应用数据，但是本端还是可以向另一端发送数据的）并返回一段TCP报文：
    
     *  标记位为ACK，表示“接收到客户端发送的释放连接的请求”；
     *  序号为Seq=V；
     *  确认号为Ack=U+1，表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值；
     *  随后服务器端开始准备**释放**服务器端到客户端方向上的连接。

客户端收到从服务器端发出的TCP报文之后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入`FIN-WAIT-2`阶段

> 前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了

*  服务器自从发出`ACK`确认报文之后，开始准备**释放**服务器端到客户端方向上的连接。等做好准备之后，就会再次向客户端发出一段TCP报文：
 *  标记位为FIN，ACK，表示“已经准备好释放连接了”。注意：这里的ACK并不是确认收到服务器端报文的确认报文。
 *  序号为Seq=W；
 *  确认号为Ack=U+1；表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值。

发出报文之后，服务器端将结束`CLOSE_WAIT`状态，进入`LAST_ACK`状态，并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。

*  客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文，服务的收到这个报文之后就里面进入`close`状态

随后客户端开始在TIME-WAIT阶段等待2MSL。客户端等待完2MSL之后，结束TIME-WAIT阶段，进入CLOSED阶段，由此完成“四次挥手”。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 4]

[参考][Link 1]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 5]  
从上面我们可以看出，当套接字关闭时，其所在的TCP就会调用`close`发送一个FIN，那么程序异常终止会不会发送一个FIN？

### TCP状态机 ###

其实，网络上是没有连接的，包括TCP也是一样的。而TCP所谓的连接，其实只不过是在通信的双方维护一个”连接状态“，让他看上去好像有链接一样。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 6]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 7]  
执行主动关闭的那一端将进入`TIME_WAIT`状态。该断点停留在这个状态的持续时间是\*\*最长分节生命期(MLS)\*\*的两倍，有时候称之为2MSL。 那为什么要由这个`TIME_WAIT`呢？两个目的  
（1）可靠的实现TCP全双工连接的终止

*  假设终止连接的主动方最后回复的`ACK`丢失了，这会造成被动方重发FIN。这个时候主动的那方必须维护TCP状态机，以便能够重新ACK，要是主动方不维护状态信息，它将响应一个RST，该分节将被服务器解释成一个错误。这也是为什么是主动方进入`TIME_WAIT`：因为可能重传最终的`ACK`  
    （2）允许老的重复分节在网络中消逝
 *  任何TCP分段都要在IP网络上传输，中间的路由器可能会随意的缓存任何的IP数据报，它并不管这个IP数据报上被承载的是什么数据，一个IP数据报最多存活MSL
 *  假设终止连接的主动方最后回复的`ACK`丢失了，这会造成被动方重发FIN，这个FIN可能会在互联网上存活MSL。
 *  如果没有TIME\_WAIT的话，假设连接1已经断开，然而其被动方最后重发的那个FIN(或者FIN之前发送的任何TCP分段)还在网络上，然而连接2重用了连接1的所有的5元素(源IP，目的IP，TCP，源端口，目的端口)，刚刚将建立好连接，连接1迟到的FIN到达了，这个FIN将以比较低但是确实可能的概率终止掉连接2.
 *  为什么说是概率比较低呢？这涉及到一个匹配问题，迟到的FIN分段的序列号必须在连接2的一方的期望序列号范围之内。这种巧合很少发生，但确实会发生。因此终止连接的主动方必须在接受了被动方回复了ACK之后等待2\*MSL时间才能进入CLOSE状态，之所以乘以2是因为这是保守的算法，最坏情况下，针对被动方的ACK在以最长路线(经历一个MSL)经过互联网马上到达被动方时丢失。
 *  为了应对这个问题，RFC793对初始序列号的生成有个建议，那就是设定一个基准，在这个基准之上搞随机，这个基准就是时间，我们知道时间是单调递增的。然而这仍然有问题，那就是回绕问题，如果发生回绕，那么新的序列号将会落到一个很低的值。 因此最好的办法就是避开“重叠”，其含义就是基准之上的随机要设定一个范围。

> 分组在网络中“迷途”通常是路由异常的结果：某个路由器崩溃或者某两个路由器之间的某个链路端口时，路由协议需要花费数秒到数分钟的时间才能稳定并找到另一条通路。这段时间可能发生路由循环（路由器A–>路由器B–>路由器A）。

> 假设迷途的分组时一个TCP分节，在它“迷途”期间，发送端TCP超时并重传该分组，而重传的分组却通过某条候选路径到达最终目的地。然而不久后（自迷途的分组开始其旅程起最多MSL秒内）路由循环修复，迷途分组最终也到达目的地，这个原来的分组就叫做**迷途/漫游的重复分组**。TCP必须正确处理这些重复的分组

[TCP协议疑难杂症全景解析----待研究][TCP_----]

[TCP 的那些事儿][TCP]

## IP–远程定位 ##

**TCP模块在进行连接、收发、断开等各阶段的操作时，都需要委托IP模块将数据封装成网络包发送给通信对象**

### IP包头格式 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 11]  
在 IP 协议里面需要有**源地址 IP** 和 **目标地址 IP**：

*  源地址IP，即是客户端输出的 IP 地址；
 *  目标地址，即通过 DNS 域名解析得到的 Web 服务器 IP

因为 HTTP 是经过 TCP 传输的，所以在 IP 包头的**协议号**，要填写为`06` （十六进制），表示协议为TCP。

**TTL生存时间字段**设置了数据报可以经过的最多路由数。它指定了数据报的生存时间。TTL的初始值由源主机设置（通常为32或64），一旦经过一个处理它的路由器就减1。当该字段值为0时，数据报就被丢弃，并发送ICMP报文通知源主机。

对于**校验和**，如果首部在传输过程中没有发送任何错误，那么接收方计算的结构应该全为1。如果结果不是全1（即检验和错误），那么IP就丢弃收到的数据报，但是**不生成差错报文**，由上层去发现丢失的数据报并进行重传。

> IP路由选择

从概念上来说，IP路由选择是简单的，特别是对于主机来说。如果目的主机和源主机直接相连（如点对点链路）或者在一个共享网络上（以太网或令牌环网），那么IP数据报就直接发送到目的主机上。否则，主机把数据报发往一默认路由器上，由路由器来转发该数据报。大多数的主机都是采用这种简单机制。

在一般的体制中，IP可以从TCP、UDP、ICMP和IGMP接收数据报(即本地生成的数据报)并进行发送，或者从一个网络接口中接收数据报(待转发的数据报)并进行发送。IP层在内存中有一个路由表。当收到一份数据报并进行发送时，它都要对该表进行搜索一次。当数据报来自某个网络接口时，IP首先检测目的IP地址是否是本机的IP地址之一或者IP广播地址。

*  如果是，那么数据报就被发送到由IP首部协议指定的协议模块进行处理。
 *  如果不是，那么：
    
     *  如果IP地址被设置为路由器功能，那么就对路由器进行转发
     *  否则就丢弃数据报

路由表中的每一项包含如下信息：

*  目的IP地址。它既可以是一个完整的主机地址
 *  下一站（或下一跳）路由器的IP地址，或者有直接连接的网络IP地址。下一跳路由器是指一个在直接相连网络上的路由器，通过它可以转发数据报。下一跳路由器不是最终的目的，但是它可以把传送给它的数据报转发到最终目的。
 *  标志。其中一个标志指明目的 I P地址是网络地址还是主机地址，另一个标志指明下一站路由器是否为真正的下一站路由器，还是一个直接相连的接口
 *  为数据报的传输指定一个网络接口

IP路由选择是逐跳的进行的。从上面路由表信息可以看出，IP并不知道到达任何目的的完整路径。所有IP路由选择只为数据报传输提供下一站的IP地址。它假定下一站路由器比发送数据报的主机更接近目的，而且下一站路由器与该主机是直接相连的。

IP路由选择主要完成如下功能：

*  搜索路由表，寻找能与目的IP地址完全匹配的数据（网络号和主机号都要匹配）。如果找到，就把报文发送给该表目指定的下一站路由器或者直接连接的网络接口（取决于标志字段的值）
 *  搜索路由表，寻找能与目的网络号相匹配的表目。如果找到，则把报文发送给该表目指定的下一站路由器或直接连接的网络接口（取决于标志字段的值）。
 *  搜索路由表，寻找标为“默认”的表目。如果找到，则把报文发送给该表目指定的下一站路由器。

如果上面这些步骤都没有成功，那么该数据报就不能被传送。如果不能传送的数据报来自本机，那么一般会向生成数据报的应用程序返回一个“主机不可达”或“网络不可达”的错误。

为一个网络指定一个路由器，而不必为每个主机指定一个路由器，这是 I P路由选择机制的另一个基本特性。这样做可以极大地缩小路由表的规模，比如 Internet上的路由器有只有几千个表目，而不会是超过1 0 0万个表目。

> 假设客户端有多个网卡，就会有多个 IP 地址，那 IP 头部的源地址应该选择哪个 IP 呢？

当存在多个网卡时，在填写源地址IP时，就需要判断到底应该填写哪个地址，这个判断相当于在多块网卡中判断应该使用那一块网卡来发送包

这个时候就需要根据**路由表**规则，来判断哪一个网卡作为源地址IP

在 Linux 操作系统，我们可以使用 `route -n` 命令查看当前系统的路由表  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 12]  
举个例子，根据上面的**路由表**，我们假设 Web 服务器的目标地址是 `192.168.10.200` 。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 13]

1.  首先先和第一条目的子网掩码（ `Genmask`）进行 与运算，得到结果为 `192.168.10.0` ，但是第一  
    个条目的`Destination` 是 `192.168.3.0` ，两者不一致所以匹配失败。
2.  再与第二条目的子网掩码进行 **与运算**，得到的结果为`192.168.10.0`，与第二条目的 `Destination 192.168.10.0` 匹配成功，所以将使用 `eth1`网卡的 IP 地址作为 IP 包头的源地址。

那么假设 Web 服务器的目标地址是 `10.100.20.100`，那么依然依照上面的路由表规则判断，判断后的  
结果是和·**第三条目**匹配。

第三条目比较特殊，它的目标地址和子网掩码都是`0.0.0.0`，这表示**默认网关**，如果其他所有条目都无法匹配，就会自动匹配这一行。并且后续就把包发给**路由器， `Gateway`即是路由器的 IP 地址**。

至此，网络包的报文如下图。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 14]  
加上IP头部之后，数据包就有了**远程定位**的能力，但是目标主机一般比较远，我们还需要`arp`协议来决定下一步跳到哪个主机(`mac`)上。

## MAC–两点传输 ##

生成了 IP 头部之后，接下来网络包还需要在 IP 头部的前面加上 **MAC 头部**

### MAC 包头格式 ###

MAC头是以太网使用的头部，它包含了接收方和发送发的MAC地址等信息  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 15]  
在MAC包头里需要**发送发MAC地址**和**接收方MAC地址**，用于**两点之间的传输**

### 怎么生成报文 ###

> 协议类型

一般在TCP/IP通信里面，MAC包头的**协议类型**只使用

*  `0800`: IP协议
 *  `0806`： ARP协议

> 怎么填写发送方的MAC地址

发送方也就是自己的MAC地址。直接从本机的网卡中的ROM中读取出来就可以，MAC地址是在网卡生产时写入到ROM中的。

> 怎么填写接收方的MAC地址

*  先查询路由表，得到下一步要发送的IP：在路由表中找到相匹配的条目，然后把包发给`Gateway`列中的\*\* IP 地址\*\*就可以了。
 *  现在我们已经知道了要发送的IP地址，那么怎么知道这个IP地址是那块\*\*网卡（Mac地址）\*\*呢？
    
    1.  ARP 协议会在以太网中以**广播**的形式，对以太网所有的设备喊出：“这个 IP 地址是谁的？请把你的MAC 地址告诉我”。
    2.  然后就会有人回答：“这个 IP 地址是我的，我的 MAC 地址是 XXXX”。  
        ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 16]  
        如果对方和自己处于同一个子网中，那么通过上面的操作就可以得到对方的 MAC 地址。然后，我们将这个 MAC 地址写入 MAC 头部，MAC 头部就完成了。

> 好像每次都要广播获取，这不是很麻烦吗？

在后续操作系统会把本次查询结果放到一块叫做**ARP缓存**的内存空间留着以后用，不过缓存的时间就几分钟。

也就是说，在发包时：

*  先查询 ARP 缓存，如果其中已经保存了对方的 MAC 地址，就不需要发送 ARP 查询，直接使用ARP 缓存中的地址。
 *  而当 ARP 缓存中不存在对方 MAC 地址时，则发送 ARP 广播查询。

> 查看 ARP 缓存内容

![在这里插入图片描述][20201104170239506.png_pic_center]

arp获取mac地址只能获取内网机器的mac地址

## 交换机-- 送别者 ##

交换机的设计是将网络包原样转发到目的地。交换机工作在MAC 层，也称为二层网络设备。

> 交换机的包接收操作

1、首先，电信号到达网线接口，交换机里的模块进行接收

2、接下来交换机里的模块将电信号转换为数字信号

3、然后通过包末尾的 FCS 校验错误，如果没问题则放到缓冲区。  
这部分操作基本和计算机的网卡相同，但交换机的工作方式和网卡不同：

*  计算机的网卡本身具有 MAC 地址，并通过核对收到的包的接收方 MAC 地址判断是不是发给自己的，如果不是发给自己的则丢弃；
 *  交换机本身不具有MAC地址（但是它有很多端口，每个端口都可以和不同的MAC地址绑定），会直接接收所有（通过包末尾的FCS校验错误的）数据包并放到缓存区中  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 17]

4、将包存入缓冲区后，接下来在交换机的**MAC地址表**中查询一下这个包的接收方 MAC 地址是否已经在 MAC 地址表中有记录了。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 18]  
举个例子，如果收到的包的接收方 MAC 地址为 00-02-B3-1C-9C-F9 ，则与图中表中的第 3 行匹配，根据端口列的信息，可知这个地址位于 3 号交换机端口上，然后就可以通过交换电路将包发送到相应的**交换机端口**了。

> 当 MAC 地址表找不到指定的 MAC 地址会怎么样？

地址表中找不到指定的 MAC 地址。这可能是因为具有该地址的设备还没有向交换机发送过包，或者这个设备一段时间没有工作导致地址被从地址表中删除了。

这种情况下，交换机无法判断应该把包转发到哪个端口，只能将包转发到除了源端口之外的所有端口上，无论该设备连接在哪个端口上都能收到这个包。

这样做不会产生什么问题，因为以太网的设计本来就是将包发送到整个网络的，然后**只有相应的接收者才接收包，而其他设备则会忽略这个包。** 发送了包之后目标设备会作出响应，只要返回了响应包，交换机就可以将它的地址写入 MAC 地址表，下次也就不需要把包发到所有端口了。

此外，如果接收方的MAC地址是一个**广播地址**，那么交换机会将包发送到除了源端口之外的所有端口。

以下两个属于广播地址：

*  MAC 地址中的 **FF:FF:FF:FF:FF:FF**
 *  IP 地址中的 **255.255.255.255**

交换机发送包有两种可能：

*  目标MAC是子网内主机，发送给子网主机，子网主机就会接收这个包
 *  目标MAC是路由器，路由器接收包之后就可以转发到外网了。

## 路由器–出境大门 ##

网络包经过交换机之后，现在到达了路由器，并在此被转发到下一个路由器或目标设备。

这一步转发的工作原理和交换机类似，也是通过查表判断包转发的目标。

### 工作原理 ###

> 路由器的包接送操作

首先，电信号到达网线接口部分，路由器中的模块会将电信号转换成数字信号，然后通过包末尾的`FCS`进行错误校验

如果没有问题则检测MAC头部中的**接收方的MAC地址**，看看是不是发给自己的包，如果是就放到接收换粗去中，负责就丢弃这个包。

总的来说，路由器的端口都具有MAC地址，只接收与自身MAC地址匹配的包，遇到不匹配的包则直接丢弃

> 查询路由表确定输出端口

完成包接收操作之后，路由器就会**去掉**包开头的MAC头部

**MAC头部的作用就是将包送达路由器**，其中的接收方MAC地址就是路由器端口的MAC地址。因此，当包到达路由器之后，MAC头部的任务就完成了，于是MAC头部就会**被丢弃**

接下来，路由器会根据MAC头部后面的`IP头部`中的内容进行包的转发操作。

首先要查询**路由表**判断转发目标

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 19]  
具体的工作流程根据上图，举个例子。

*  假设地址为`10.10.1.101`的计算机要向地址为 `192.168.1.100` 的服务器发送一个包，这个包先到达图中的路由器。
 *  判断转发目标的第一步，就是根据包的\*\*接收方 IP \*\*地址查询路由表中的目标地址栏，以找到相匹配的记  
    录。
 *  路由匹配和前面讲的一样，每个条目的子网掩码和 `192.168.1.100`IP 做 **& 与运算**后，得到的结果与对应条目的目标地址进行匹配，如果匹配就会作为候选转发目标，如果不匹配就继续与下个条目进行路由匹配。
 *  如第二条目的子网掩码`255.255.255.0`与 `192.168.1.100` IP 做 & 与运算后，得到结果是  
    `192.168.1.0` ，这与第二条目的目标地址 192.168.1.0 匹配，该第二条目记录就会被作为转发目标。
 *  实在找不到匹配路由时，就会选择**默认路由**，路由表中子网掩码为 `0.0.0.0` 的记录表示「默认路由」。

> 路由器的发送操作

接下来就会进入包的发送操作。

首先，我们需要根据**路由表的网关列**判断对方的地址

*  如果网关是一个IP弟子，那么这个IP地址就是我们要转发的目标地址，**还未到达终点**，还需要继续**路由器**转发
 *  如果网关未空，则IP头部中的接收方IP地址就是要转发到的目标地址，也是就终于找到 IP 包头里的目标地址了，说明**已抵达终点**。

知道对方的IP地址之后，需要寻找IP地址对应的Mac地址（接收方的MAC地址）

*  先查询路由器中的`ARP缓存`，如果找不到就进行下一步
 *  通过`ARP`协议根据IP地址查询MAC地址，并将查询的结果作为接收方的MAC地址

接下来填写发送方MAC地址： 就是输出端口的MAC地址

还有一个以太类型字段：填写`0080`（十六进制）表示IP协议

网络包完成之后，接下来会将其转换成电信号并通过端口发送出去。

发送出去的网络包会通过**交换机**到达下一个路由器。由于接收方MAC地址就是下一个路由器的地址，所以交换机会根据这一地址将这一地址将包传输到下一个路由器。

接下来，下一个路由器就会将包转发给再下一个路由器，经过层层转发之后，网络包就到达了最终的目的。

**在网络包传输的过程中，源IP和目的IP始终是不会变的，一直编号的是MAC地址，因为需要MAC地址在以太网内进行两个设备之间的包传输**

在发送数据包时，如果目标主机不是本地局域网，填入的MAC地址是路由器，也就是把数据包转发给路由器，路由器一直转发下一个路由器，直到转发到目标主机的路由器，发现IP地址是自己局域网内的主机，就会arp请求获取目标主机的MAC地址，从而转发到这个服务器的主机。

### 路由器和交换机的区别 ###

*  因为路由器是基于 IP 设计的，俗称**三层**网络设备，路由器的各个端口都具有 MAC 地址和 IP 地址；
 *  而交换机是基于**以太网**设计的，俗称二层网络设备，交换机的端口不具有 MAC 地址。

感觉：路由器就像一个很小很小的主机，数据包通过交换机这个跳板在“主机”之间流动

## 服务器 与 客户端–相互扒皮 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 20]

*  数据包到达服务器之后，服务器会先扒开数据包的MAC头部，查看是否和服务器自己的MAC地址符合，符合就将包收起来
 *  接着扒开数据包的IP头，发现IP符合，根据IP头中的协议项，知道自己上层是TCP协议。
 *  于是，扒开TCP头，里面有序列号，需要看一看这个序列包是不是我想要的，如果是就放入缓存中然后返回一个ACK，如果不是就丢弃。TCP头部里面还有端口号，http服务器正在监听这个端口号
 *  于是，服务器自然就知道HTTP进程想要这个包，于是就将包发给HTTP进程。
 *  服务器的 HTTP 进程看到，原来这个请求是要访问一个页面，于是就把这个网页封装在 HTTP 响应报文里。
 *  然后又将这个包发送回去

[https://zhuanlan.zhihu.com/p/95904514][https_zhuanlan.zhihu.com_p_95904514]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center]: /images/20221122/7d49a1d3dab9491d8733dc8efba16f8b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221122/d075ff1d0b214d88998b2f05c8aa524e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221122/0bbdbd0117934a878e1a5253e5ea899e.png
[20201023100357869.png_pic_center]: /images/20221122/f8e59f9f43f24a2f94f8c05de4a755bd.png
[20201023143259357.png_pic_center]: /images/20221122/a9f75d47b3bd4ae9968a09d2f7af8081.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221122/1086e747ec03471cbe108169790c68bb.png
[IP]: https://blog.csdn.net/zhizhengguan/article/details/109078998
[dns]: https://blog.csdn.net/zhizhengguan/article/details/109239665
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221122/05ac2df240974d87b3e2c3454c8343c2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221122/7b9d3f927615494fbab1f5d8d1145a7a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221122/27b0a92f5e7644e88acbf11699acef8f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221122/11c27dc174d84d4eb7ccd95ebfe6b925.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]: /images/20221122/00f03e52938b451bb7baea41aa7680fe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]: /images/20221122/0a1ac516c9fe44da8d36743525796713.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 2]: /images/20221122/5d68fcae8a574ab9b69fbf2cda46d509.png
[20201030174956852.png_pic_center]: /images/20221122/1658efd52c5c421db53a79ca5352c2db.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 8]: /images/20221122/950b797e94d648279879be3c4435ba03.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 9]: /images/20221122/3062b244ae454b32b9f259ad1a5f351e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 10]: /images/20221122/ba9e8b4fc89943808574b4280fd47832.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 3]: /images/20221122/3cf124f6464f44b1b4fb18359788e36f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 4]: /images/20221122/9e0bdd4207b449adaf4d387fc2282bf5.png
[Link 1]: https://baijiahao.baidu.com/s?id=1654225744653405133
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 5]: /images/20221122/4dd38cb3730d4d59b765347a6b9d4080.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 6]: /images/20221122/81702543e8dd435dbb7b3ab311f042ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 7]: /images/20221122/5dc9d8bcc3124fa6ba8f85826ce60ae6.png
[TCP_----]: https://blog.csdn.net/dog250/article/details/6612496
[TCP]: https://coolshell.cn/articles/11564.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 11]: /images/20221122/25f65d6d8e2d4062a917d27c6b96af31.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 12]: /images/20221122/83302b60bd004220b595f314d48ad94b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 13]: /images/20221122/af26000f4b3e4cf58ac230222ed62a4c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 14]: /images/20221122/047fb749101b464ba80c7df7796eefcf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 15]: /images/20221122/c1aeeb4309f846f5bb3f2eb270f959d8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 16]: /images/20221122/4b5cedd892144843bcca8b7bae18c5bb.png
[20201104170239506.png_pic_center]: /images/20221122/a887cba6f22342d3b05805cff0d3527b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 17]: /images/20221122/a18449f8e80245658ec9a259619d07f4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 18]: /images/20221122/608609e812cc4366944d821f98d52fa6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 19]: /images/20221122/f7212d5ff1c6446e81ba5b1b66893f22.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 20]: /images/20221122/7b6d3c8351f54ac692d1fe41f0a47753.png
[https_zhuanlan.zhihu.com_p_95904514]: https://zhuanlan.zhihu.com/p/95904514