计算机网络常见面试题汇总（建议收藏！！！）

淩亂°似流年 2022-09-08 03:44 677阅读 0赞

### 目录 ###

*   *  （1）说说HTTP常用的状态码及其含义？
     *  （2）HTTP 常用的请求方式，区别和用途？
     *  （3）请简单说一下你了解的端口及对应的服务？
     *  （4）说下计算机网络体系结构？
     *  （5）如何理解HTTP协议是无状态的
     *  （6）从浏览器地址栏输入url到显示主页的过程
     *  （7）说下HTTP/1.0、1.1、2.0的区别
     *  （8）POST和GET有哪些区别？
     *  （9）在交互过程中如果数据传送完了，还不想断开连接怎么办，怎么维持？
     *  （10）HTTP 如何实现长连接？在什么时候会超时？
     *  （11）HTTP 与 HTTPS 的区别
     *  （12）Https流程是怎样的？
     *  （13）说说HTTP的状态码，301和302的区别？
     *  （14）说说什么是数字签名？什么是数字证书？
     *  （15）对称加密与非对称加密有什么区别？
     *  （16）说说DNS的解析过程？
     *  （17）什么是CSRF攻击，如何避免
     *  （18）聊聊五层计算机网络体系结构中，每一层对应的网络协议有哪些？
     *  （19）说说 WebSocket与socket的区别
     *  （20）什么是DoS、DDoS、DRDoS攻击？
     *  （21）什么是XSS攻击，如何避免?
     *  （22）Http请求的过程与原理
     *  （23）forward和redirect的区别？
     *  （24）聊聊SQL注入？
     *  （25）Session和Cookie的区别？
     *  （26）IP地址有哪些分类？
     *  （27）说下ARP 协议的工作过程？
     *  （28）有了IP地址，为什么还要用MAC地址？
     *  （29）TCP 和 UDP 分别对应的常见应用层协议有哪些？
     *  （30）聊聊保活计时器的作用
     *  （31）如果服务器出现了大量CLOSE\_WAIT状态如何解决
     *  （32）URI和URL的区别
     *  （33）ICMP协议的功能
     *  （34）说下ping的原理
     *  （35）请详细介绍一下TCP 的三次握手机制
     *  （36）TCP握手为什么是三次，为什么不能是两次？不能是四次？
     *  （37）说说TCP四次挥手过程
     *  （38）TCP挥手为什么需要四次呢？
     *  （39）TCP四次挥手过程中，为什么需要等待2MSL,才进入CLOSED关闭状态
     *  （40）TCP的粘包和拆包
     *  （41）TCP和UDP区别
     *  （42）聊聊TCP的流量控制
     *  （43）说说半连接队列和 SYN Flood攻击的关系
     *  （44）聊聊TCP的滑动窗口
     *  （45）TCP的拥塞控制
     *   *  （45.1）慢启动算法
         *  （45.2）拥塞避免算法
         *  （45.3）拥塞发生算法
         *  （45.4）快速恢复算法
     *  （46）说说TCP是如何确保可靠性的呢？
     *  （47）说说TCP报文首部有哪些字段，其作用又分别是什么？
     *  （48）Nagle 算法与延迟确认
     *   *  （48.1）Nagle算法
         *  （48.2）延迟确认
     *  （49）说说TCP的重传机制
     *   *  （49.1）超时重传
         *  （49.2）快速重传
         *  （49.3）带选择确认的重传（SACK）
         *  （49.4）重复SACK（D-SACK）

## （1）说说HTTP常用的状态码及其含义？ ##

**思路:** 这道面试题主要考察候选人，是否掌握HTTP状态码这个基础知识点。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70]  
不管是不是面试需要，我们都要知道，日常开发中的这几个状态码的含义：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 1]

## （2）HTTP 常用的请求方式，区别和用途？ ##

**思路:** 这道题主要考察候选人，是否掌握**HTTP请求方式**这个基础知识点，我们用得比较多就是**GET和POST**。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 2]

*  **GET：对服务器资源获取的简单请求**
 *  **POST：用于发送包含用户提交数据的请求**

## （3）请简单说一下你了解的端口及对应的服务？ ##

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

## （4）说下计算机网络体系结构？ ##

**思路:** 这道题主要考察候选人，**计算机网络体系结构**这个基础知识点。  
计算机网路体系结构，有三层：

*  ISO七层模型
 *  TCP/IP四层模型
 *  五层协议体系结构

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 4]

**ISO七层模型**

> ISO七层模型是国际标准化组织（International Organization for  
> Standardization）制定的一个用于计算机或通信系统间互联的标准体系。

*  **应用层**：网络服务与最终用户的一个接口，常见的协议有：**HTTP FTP SMTP SNMP DNS**.
 *  **表示层**：数据的表示、安全、压缩。确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。
 *  **会话层**：建立、管理、终止会话,对应主机进程，指本地主机与远程主机正在进行的会话.
 *  **传输层**：定义传输数据的协议端口号，以及流控和差错校验,协议有**TCP UDP.**
 *  **网络层**：进行逻辑地址寻址，实现不同网络之间的路径选择,协议有**ICMP IGMP IP**等.
 *  **数据链路层**：在物理层提供比特流服务的基础上，建立相邻结点之间的数据链路。
 *  **物理层**：建立、维护、断开物理连接。

**TCP/IP 四层模型**

*  应用层：对应于OSI参考模型的（应用层、表示层、会话层）。
 *  传输层: 对应OSI的传输层，为应用层实体提供端到端的通信功能，保证了数据包的顺序传送及数据的完整性。
 *  网际层：对应于OSI参考模型的网络层，主要解决主机到主机的通信问题。
 *  网络接口层：与OSI参考模型的数据链路层、物理层对应。

**五层体系结构**

*  应用层：对应于OSI参考模型的（应用层、表示层、会话层）。
 *  传输层：对应OSI参考模型的的传输层
 *  网络层：对应OSI参考模型的的网络层
 *  数据链路层：对应OSI参考模型的的数据链路层
 *  物理层：对应OSI参考模型的的物理层。

## （5）如何理解HTTP协议是无状态的 ##

**思路**: 这道题主要考察候选人，是否理解Http协议，它为什么是无状态的呢？如何使它有状态呢？

如何理解无状态这个词呢？

> 当浏览器第一次发送请求给服务器时，服务器响应了；如果同个浏览器发起第二次请求给服务器时，它还是会响应，但是呢，服务器不知道你就是刚才的那个浏览器。简言之，服务器不会去记住你是谁，所以是无状态协议。

可以通过一个生活中的例子，来更好理解并记住它：

有状态场景：

*  小红：今天吃啥子？
 *  小明：罗非鱼~
 *  小红：味道怎么样呀？
 *  小明：还不错，好香

无状态的场景：

*  小红：今天吃啥子？
 *  小明：罗非鱼~
 *  小红：味道怎么样呀？
 *  小明：？啊？你说啥？什么鬼？什么味道怎么样？

Http加了Cookie的话：

*  小红：今天吃啥子？
 *  小明：罗非鱼~
 *  小红：你今天吃的罗非鱼，味道怎么样呀？
 *  小明：还不错，好香。

## （6）从浏览器地址栏输入url到显示主页的过程 ##

**思路**: 这道题主要考察的知识点是**HTTP的请求过程，DNS解析，TCP三次握手，四次挥手**这几个要点，我们都可以讲下。

1.  **DNS解析，查找域名对应的IP地址。**
2.  **与服务器通过三次握手，建立TCP连接**
3.  **向服务器发送HTTP请求**
4.  **服务器处理请求，返回网页内容**
5.  **浏览器解析并渲染页面**
6.  **TCP四次挥手，连接结束**

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

## （7）说下HTTP/1.0、1.1、2.0的区别 ##

**思路**: 这道题主要考察的知识点是HTTP几个版本的区别，我们记住**HTTP/1.0默认是短连接**，可以强制开启，**HTTP/1.1默认长连接**，**HTTP/2.0采用多路复用**就差不多。

**HTTP/1.0**

*  默认使用 **短连接**，每次请求都需要建立一个TCP连接。它可以设置Connection: keep-alive 这个字段，强制开启长连接。

**HTTP/1.1**

*  引入了持久连接，即TCP连接默认不关闭，可以被多个请求复用。
 *  分块传输编码，即服务端没产生一块数据，就发送一块，用”流模式”取代”缓存模式”。
 *  管道机制，即在同一个TCP连接里面，客户端可以同时发送多个请求。

**HTTP/2.0**

*  二进制协议，1.1版本的头信息是文本（ASCII编码），数据体可以是文本或者二进制；2.0中，头信息和数据体都是二进制。
 *  完全多路复用，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应。
 *  报头压缩，HTTP协议不带有状态，每次请求都必须附上所有信息。Http/2.0引入了头信息压缩机制，使用gzip或compress压缩后再发送。
 *  服务端推送，允许服务器未经请求，主动向客户端发送资源。

## （8）POST和GET有哪些区别？ ##

**思路**: 这道题主要考察的知识点是POST和GET的区别，可以从**数据包、编码方式、请求参数、收藏为书签、历史记录、安全性等**几方面去回答。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 6]

## （9）在交互过程中如果数据传送完了，还不想断开连接怎么办，怎么维持？ ##

这个问题记住**keep-alive**就好，也就是说，在HTTP中响应体的**Connection**字段指定为keep-alive即可

## （10）HTTP 如何实现长连接？在什么时候会超时？ ##

**思路**: 这道题实际上是考察**TCP长连接的知识点**，**HTTP的长连接实质是指TCP的长连接**。  
至于什么时候超时，我们记住这几个参数如`tcp_keepalive_time、tcp_keepalive_probes`就好

**什么是HTTP的长连接？**

*  HTTP分为长连接和短连接，**本质上说的是TCP的长短连接**。TCP连接是一个双向的通道，它是可以保持一段时间不关闭的，因此TCP连接才具有真正的长连接和短连接这一说法。
 *  TCP长连接可以复用一个TCP连接，来发起多次的HTTP请求，这样就可以减少资源消耗，比如一次请求HTML，如果是短连接的话，可能还需要请求后续的JS/CSS。

**如何设置长连接？**  
通过在头部（请求和响应头）设置`Connection`字段指定为`keep-alive`，HTTP/1.0协议支持，但是是默认关闭的，从HTTP/1.1以后，连接默认都是长连接。

**在什么时候会超时？**

*  HTTP一般会有httpd守护进程，里面可以设置`keep-alive timeout`，当tcp连接闲置超过这个时间就会关闭，也可以在HTTP的header里面设置超时时间
 *  TCP 的`keep-alive`包含三个参数，支持在系统内核的net.ipv4里面设置；当 TCP 连接之后，闲置了`tcp_keepalive_time`，则会发生侦测包，如果没有收到对方的ACK，那么会每隔 `tcp_keepalive_intvl`再发一次，直到发送了`tcp_keepalive_probes`，就会丢弃该连接。

1. tcp_keepalive_intvl = 15
    2. tcp_keepalive_probes = 5
    3. tcp_keepalive_time = 1800

## （11）HTTP 与 HTTPS 的区别 ##

**思路**: 这道题实际上考察的知识点是HTTP与HTTPS的区别，这个知识点非常重要，可以从**安全性、数据是否加密、默认端口等**这几个方面去回答。其实，当你理解HTTPS的整个流程，就可以很好回答这个问题

HTTP，即**超文本传输协议**，是一个基于TCP/IP通信协议来传递**明文数据**的协议。HTTP会存在这几个问题：

*  请求信息是明文传输，容易被窃听截取。
 *  没有验证对方身份，存在被冒充的风险
 *  数据的完整性未校验，容易被中间人篡改

为了解决Http存在的问题，Https出现

**Https是什么？**

**HTTPS= HTTP+SSL/TLS** ，可以理解Https是身披SSL(Secure Socket Layer，安全套接层)的HTTP。

**它们主要区别如下：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 7]

## （12）Https流程是怎样的？ ##

**思路**: 这道题实际上考察的知识点是HTTPS的工作流程，大家需要回答这几个要点，**公私钥、数字证书、加密、对称加密、非对称加密。**

*  HTTPS = HTTP + SSL/TLS，也就是用SSL/TLS对数据进行加密和解密，Http进行传输。
 *  SSL，即Secure Sockets Layer（安全套接层协议），是网络通信提供安全及数据完整性的一种安全协议。
 *  TLS，即Transport Layer Security(安全传输层协议)，它是SSL3.0的后续版本。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 8]

1.  客户端发起Https请求，连接到服务器的443端口。
2.  服务器必须要有一套数字证书（证书内容有公钥、证书颁发机构、失效日期等）。
3.  服务器将自己的数字证书发送给客户端（公钥在证书里面，私钥由服务器持有）。
4.  客户端收到数字证书之后，会验证证书的合法性。如果证书验证通过，就会生成一个随机的对称密钥，用证书的公钥加密。
5.  客户端将公钥加密后的密钥发送到服务器。
6.  服务器接收到客户端发来的密文密钥之后，用自己之前保留的私钥对其进行非对称解密，解密之后就得到客户端的密钥，然后用客户端密钥对返回数据进行对称加密，酱紫传输的数据都是密文。
7.  服务器将加密后的密文返回到客户端。
8.  客户端收到后，用自己的密钥对其进行对称解密，得到服务器返回的数据。

## （13）说说HTTP的状态码，301和302的区别？ ##

**思路**: 这道题考查的知识点，也是HTTP状态码，302和301都有重定向的含义，但是它们也是有区别的。

*  301：（永久性转移）请求的网页已被永久移动到新位置。服务器返回此响应时，会自动将请求者转到新位置。
 *  302：（暂时性转移）服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应GET和HEAD请求的301代码类似，会自动将请求者转到不同的位置。

网上有个很形象的例子比喻：

> 当一个网站或者网页24—48小时内临时移动到一个新的位置，这时候就要进行302跳转，打个比方说，我有一套房子，但是最近走亲戚去亲戚家住了，过两天我还回来的。而使用301跳转的场景就是之前的网站因为某种原因需要移除掉，然后要到新的地址访问，是永久性的，就比如你的那套房子其实是租的，现在租期到了，你又在另一个地方找到了房子，之前租的房子不住了。

## （14）说说什么是数字签名？什么是数字证书？ ##

**思路**: 这道题考查的知识点，不仅仅是数字签名，数字证书，很可能面试官也会问你https的原理的，因为https原理跟数字证书有关的，大家需要掌握https原理。

数字证书是指在互联网通讯中标志通讯各方身份信息的一个数字认证，人们可以在网上用它来识别对方的身份。它的出现，是为了避免身份被篡改冒充的。比如Https的数字证书，就是为了避免公钥被中间人冒充篡改：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 9]  
**数字证书构成**

*  公钥和个人等信息，经过Hash摘要算法加密，形成消息摘要；将消息摘要拿到拥有公信力的认证中心（CA），用它的私钥对消息摘要加密，形成**数字签名**。
 *  公钥和个人信息、数字签名共同构成**数字证书**。

## （15）对称加密与非对称加密有什么区别？ ##

**思路**: 这道题考察的知识点是对称加密与非对称加密算法，什么是对称加密，什么是非对称加密呢？

对称加密：指加密和解密使用同一密钥，优点是运算速度较快，缺点是如何安全将密钥传输给另一方。常见的对称加密算法有：DES、AES等。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 10]

非对称加密：指的是加密和解密使用不同的密钥（即公钥和私钥）。公钥与私钥是成对存在的，如果用公钥对数据进行加密，只有对应的私钥才能解密。常见的非对称加密算法有RSA。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 11]

## （16）说说DNS的解析过程？ ##

**思路**: 这道题考察的知识点是DNS域名解析，http请求的过程，是涉及到DNS域名解析的，这道面试题也挺经典的。

DNS，英文全称是`domain name system`，域名解析系统，是Internet上作为域名和IP相互映射的一个分布式数据库。它的作用很明确，**就是可以根据域名查出对应的IP地址**。在浏览器缓存、本地DNS服务器、根域名服务器都是怎么查找的。

DNS的解析过程如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 12]  
假设你要查询www.baidu.com的IP地址:

*  首先会查找浏览器的缓存，看看是否能找到www.baidu.com对应的IP地址，找到就直接返回；否则进行下一步。
 *  将请求发往给本地DNS服务器，如果查找到也直接返回，否则继续进行下一步；
 *  本地DNS服务器向**根域名服务器**发送请求，根域名服务器返回负责.com的顶级域名服务器的IP地址的列表。
 *  本地DNS服务器再向**其中一个负责.com的顶级域名服务器**发送一个请求，返回负责.baidu的权威域名服务器的IP地址列表。
 *  本地DNS服务器再向**其中一个权威域名服务器**发送一个请求，返回www.baidu.com所对应的IP地址。

## （17）什么是CSRF攻击，如何避免 ##

**思路**: 这道题考察的知识点是**CSRF攻击**，它是属于网络安全这块的知识点，还有**Xss攻击、SQL注入、DDoS**等这些常见的网络攻击，我们都需要知道攻击的流程。

**什么是CSRF 攻击？**

> CSRF，跨站请求伪造（英文全称是Cross-site request  
> forgery），是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。

**CSRF是如何攻击的呢？**  
来看一个来自百度百科的例子：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 13]

1.  Tom 登陆银行，没有退出，浏览器包含了Tom在银行的身份认证信息。
2.  黑客Jerry将伪造的转账请求，包含在在帖子
3.  Tom在银行网站保持登陆的情况下，浏览帖子
4.  将伪造的转账请求连同身份认证信息，发送到银行网站
5.  银行网站看到身份认证信息，以为就是Tom的合法操作，最后造成Tom资金损失。

**怎么解决CSRF攻击呢？**

*  检查Referer字段。
 *  添加校验token。

## （18）聊聊五层计算机网络体系结构中，每一层对应的网络协议有哪些？ ##

为了大家方便记忆，我还是画个思维导图吧，如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 14]

## （19）说说 WebSocket与socket的区别 ##

*  Socket其实就是等于**IP地址 + 端口 + 协议**。
 *  WebSocket是一个持久化的协议，它是伴随H5而出的协议，用来解决**http不支持持久化连接**的问题。
 *  Socket一个是**网编编程的标准接口**，而WebSocket则是应用层通信协议。

具体来说，Socket是一套标准，它完成了对TCP/IP的高度封装，屏蔽网络细节，以方便开发者更好地进行网络编程。

## （20）什么是DoS、DDoS、DRDoS攻击？ ##

*  **DOS**: (Denial of Service),翻译过来就是拒绝服务,一切能引起DOS行为的攻击都被称为DOS攻击。最常见的DoS攻击就有**计算机网络宽带攻击、连通性攻击。**
 *  **DDoS**: (Distributed Denial of Service),翻译过来是分布式拒绝服务。是指处于不同位置的多个攻击者同时向一个或几个目标发动攻击，或者一个攻击者控制了位于不同位置的多台机器并利用这些机器对受害者同时实施攻击。常见的DDos有**SYN Flood、Ping of Death、ACK Flood、UDP Flood等**。
 *  **DRDoS**: (Distributed Reflection Denial of Service)，中文是分布式反射拒绝服务，该方式靠的是发送大量带有被害者IP地址的数据包给攻击主机，然后攻击主机对IP地址源做出大量回应，从而形成拒绝服务攻击。

## （21）什么是XSS攻击，如何避免? ##

**思路**: XSS攻击也是比较常见，XSS，叫**跨站脚本攻击（Cross-Site Scripting）**，因为会与层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，因此有人将跨站脚本攻击缩写为XSS。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意攻击用户的特殊目的。

XSS攻击一般分三种类型：**存储型 、反射型 、DOM型XSS**

**XSS是如何攻击的呢？**

拿反射型举个例子吧，流程图如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 15]  
**如何解决XSS攻击问题？**

*  对输入进行过滤，过滤标签等，只允许合法值。
 *  HTML转义
 *  对于链接跳转，如<a href=“xxx” 等，要校验内容，禁止以script开头的非法链接。
 *  限制输入长度

## （22）Http请求的过程与原理 ##

**思路**: HTTP请求，一个非常非常基础的知识点，一定需要掌握的。其实觉得跟浏览器地址栏输入url到显示主页这道题有点类似。

HTTP是一个基于TCP/IP协议来传递数据的超文本传输协议，传输的数据类型有HTML,图片等。以访问百度有例子，看下一次Http的请求过程吧  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 16]

1.  客户端进行DNS域名解析，得到对应的IP地址
2.  根据这个IP，找到对应的服务器建立连接（三次握手）
3.  建立TCP连接后发起HTTP请求（一个完整的http请求报文）
4.  服务器响应HTTP请求，客户端得到html代码
5.  客户端解析html代码，用html代码中的资源(如js,css,图片等等)渲染页面。
6.  服务器关闭TCP连接（四次挥手）

## （23）forward和redirect的区别？ ##

*  **直接转发方式（Forward）** ：客户端和浏览器只发出一次请求，Servlet、HTML、JSP或其它信息资源，由第二个信息资源响应该请求，在请求对象request中，保存的对象对于每个信息资源是共享的。
 *  **间接转发方式（Redirect）** ：实际是两次HTTP请求，服务器端在响应第一次请求的时候，让浏览器再向另外一个URL发出请求，从而达到转发的目的。

举个通俗的例子：

*  直接转发就相当于：“A找B借钱，B说没有，B去找C借，借到借不到都会把消息传递给A”；
 *  间接转发就相当于：“A找B借钱，B说没有，让A去找C借”。

看下这两个图，可以更容易理解一些:  
Redirect 的工作原理：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 17]  
forward 的工作原理：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 18]

## （24）聊聊SQL注入？ ##

SQL注入是一种代码注入技术，一般被应用于攻击web应用程序。它通过在web应用接口传入一些特殊参数字符，来欺骗应用服务器，执行恶意的SQL命令，以达到非法获取系统信息的目的。它目前是黑客对数据库进行攻击的最常用手段之一。

**SQL注入是如何攻击的？**  
举个常见的业务场景：在web表单搜索框输入员工名字，然后后台查询出对应名字的员工。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 19]  
这种场景下，一般都是前端页面,把一个名字参数name传到后台，然后后台通过SQL把结果查询出来

name = "田螺"; //前端传过来的
    
    SQL= "select * from staff where name=" + name;  //根据前端传过来的name参数，查询数据库员工表staff

因为SQL是直接拼接的，如果我们完全信任前端传的参数的话。假如前端传这么一个参数时’’ or ‘1’=‘1’，SQL就变成这样：

select * from staff where name='' or '1'='1';

这个SQL会把所有的员工信息全都查出来了，这样请求用户已经越权了。请求者可以获取所有员工的信息，信息已经暴露了。

**如何预防SQL注入问题**

1.  使用\#\{\}而不是 $\{\}
2.  不要暴露一些不必要的日志或者安全信息，比如避免直接响应一些sql异常信息。
3.  不相信任何外部输入参数，过滤参数中含有的一些数据库关键词关键词
4.  适当的权限控制

## （25）Session和Cookie的区别？ ##

**我们先来看Session和Cookie的概念吧：**

*  Cookie是保存在客户端的一小块文本串的数据。客户端向服务器发起请求时，服务端会向客户端发送一个Cookie，客户端就把Cookie保存起来。在客户端下次向同一服务器再发起请求时，Cookie被携带发送到服务器。服务器就是根据这个Cookie来确认身份的。
 *  session指的就是服务器和客户端一次会话的过程。Session利用Cookie进行信息处理的，当用户首先进行了请求后，服务端就在用户浏览器上创建了一个Cookie，当这个Session结束时，其实就是意味着这个Cookie就过期了。Session对象存储着特定用户会话所需的属性及配置信息。

**Session 和Cookie的区别主要有这些：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 20]  
来看个图吧：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 21]

*  用户第一次请求服务器时，服务器根据用户提交的信息，创建对应的Session，请求返回时将此Session的唯一标识信息SessionID返回给浏览器，浏览器接收到服务器返回的SessionID信息后，会将此信息存入Cookie中，同时Cookie记录此SessionID是属于哪个域名。
 *  当用户第二次访问服务器时，请求会自动判断此域名下是否存在Cookie信息，如果存在，则自动将Cookie信息也发送给服务端，服务端会从Cookie中获取SessionID，再根据 SessionID查找对应的 Session信息，如果没有找到，说明用户没有登录或者登录失效，如果找到Session证明用户已经登录可执行后面操作。

## （26）IP地址有哪些分类？ ##

一般可以这么认为，IP地址=网络号+主机号。

*  网络号：它标志主机所连接的网络地址表示属于互联网的哪一个网络。
 *  主机号：它标志主机地址表示其属于该网络中的哪一台主机。

IP地址分为A，B，C，D，E五大类：

*  A类地址(1~126)：以0开头，网络号占前8位，主机号占后面24位。
 *  B类地址(128~191)：以10开头，网络号占前16位，主机号占后面16位。
 *  C类地址(192~223)：以110开头，网络号占前24位，主机号占后面8位。
 *  D类地址(224~239)：以1110开头，保留位多播地址。
 *  E类地址(240~255)：以11110开头，保留位为将来使用

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 22]

## （27）说下ARP 协议的工作过程？ ##

ARP 协议协议，Address Resolution Protocol，地址解析协议，它是用于实现IP地址到MAC地址的映射。

1.  首先，每台主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址的对应关系。
2.  当源主机需要将一个数据包要发送到目的主机时，会首先检查自己的ARP列表，是否存在该IP地址对应的MAC地址；如果有﹐就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。此ARP请求的数据包里，包括源主机的IP地址、硬件地址、以及目的主机的IP地址。
3.  网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。如果不相同，就会忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个 ARP响应数据包，告诉对方自己是它需要查找的MAC地址。
4.  源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。

## （28）有了IP地址，为什么还要用MAC地址？ ##

*  简而言之，标识网络中的一台计算机，比较常用的就是IP地址和MAC地址，但计算机的IP地址可由用户自行更改，管理起来就相对困难，而MAC地址不可更改，所以一般会把IP地址和MAC地址组合起来使用。
 *  那只使用MAC地址不用IP地址行不行呢？不行的！因为最早就是MAC地址先出现的，并且当时并不用IP地址，只用MAC地址，后来随着网络中的设备越来越多，整个路由过程越来越复杂，便出现了子网的概念。对于目的地址在其他子网的数据包，路由只需要将数据包送到那个子网即可。
 *  那为什么要用IP地址呢？是因为IP地址是和地域相关的，对于同一个子网上的设备，IP地址的前缀都是一样的，这样路由器通过IP地址的前缀就知道设备在在哪个子网上了，而只用MAC地址的话，路由器则需要记住每个MAC地址在哪个子网，这需要路由器有极大的存储空间，是无法实现的。
 *  IP地址可以比作为地址，MAC地址为收件人，在一次通信过程中，两者是缺一不可的。

## （29）TCP 和 UDP 分别对应的常见应用层协议有哪些？ ##

**基于TCP的应用层协议有：HTTP、FTP、SMTP、TELNET、SSH**

*  **HTTP**：HyperText Transfer Protocol（超文本传输协议），默认端口80
 *  **FTP**: File Transfer Protocol (文件传输协议), 默认端口(20用于传输数据，21用于传输控制信息)
 *  **SMTP**: Simple Mail Transfer Protocol (简单邮件传输协议) ,默认端口25
 *  **TELNET**: Teletype over the Network (网络电传), 默认端口23
 *  **SSH**：Secure Shell（安全外壳协议），默认端口 22

**基于UDP的应用层协议：DNS、TFTP、SNMP**

*  **DNS** : Domain Name Service (域名服务),默认端口 53
 *  **TFTP**: Trivial File Transfer Protocol (简单文件传输协议)，默认端口69
 *  **SNMP**：Simple Network Management Protocol（简单网络管理协议），通过UDP端口161接收，只有-Trap信息采用UDP端口162。

## （30）聊聊保活计时器的作用 ##

除时间等待计时器外，TCP 还有一个保活计时器（keepalive timer）。设想这样的场景：客户已主动与服务器建立了TCP连接。但后来客户端的主机突然发生故障。显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用保活计时器了。

服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两个小时。若两个小时都没有收到客户端的数据，服务端就发送一个探测报文段，以后则每隔 75秒钟发送一次。若连续发送10个探测报文段后仍然无客户端的响应，服务端就认为客户端出了故障，接着就关闭这个连接。

## （31）如果服务器出现了大量CLOSE\_WAIT状态如何解决 ##

我们先来复习下TCP的四次挥手  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 23]

*  服务器端收到客户端发送的FIN后，TCP协议栈就会自动发送ACK，接着进入`CLOSE_WAIT`状态。
 *  但是如果服务器端不执行socket的close()操作，那么就没法进入LAST\_ACK,导致大量连接处于CLOSE\_WAIT状态
 *  所以，如果服务器出现了大量`CLOSE_WAIT`状态，一般是程序Bug，或者关闭socket不及时。

## （32）URI和URL的区别 ##

*  URI，全称是Uniform Resource Identifier)，中文翻译是统一资源标志符，主要作用是唯一标识一个资源。
 *  URL，全称是Uniform Resource Location)，中文翻译是统一资源定位符，主要作用是提供资源的路径。打个经典比喻吧，URI像是身份证，可以唯一标识一个人，而URL更像一个住址，可以通过URL找到这个人。

## （33）ICMP协议的功能 ##

ICMP,Internet Control Message Protocol ,Internet控制消息协议。

*  ICMP协议是一种面向无连接的协议，用于传输出错报告控制信息。
 *  它是一个非常重要的协议，它对于网络安全具有极其重要的意义。它属于网络层协议，主要用于在主机与路由器之间传递控制信息，包括报告错误、交换受限控制和状态信息等。
 *  当遇到IP数据无法访问目标、IP路由器无法按当前的传输速率转发数据包等情况时，会自动发送ICMP消息。

比如我们日常使用得比较多的ping，就是基于ICMP的。

## （34）说下ping的原理 ##

ping，**Packet Internet Groper**，是一种因特网包探索器，用于测试网络连接量的程序。**Ping是工作在TCP/IP网络体系结构中应用层的一个服务命令**， 主要是向特定的目的主机发送ICMP（Internet Control Message Protocol 因特网报文控制协议） 请求报文，测试目的站是否可达及了解其有关状态

一般来说，ping可以用来检测网络通不通。它是基于ICMP协议工作的。**假设机器A ping机器B，工作过程如下：**

1.  ping通知系统，新建一个固定格式的ICMP请求数据包
2.  ICMP协议，将该数据包和目标机器B的IP地址打包，一起转交给IP协议层
3.  IP层协议将本机IP地址为源地址，机器B的IP地址为目标地址，加上一些其他的控制信息，构建一个IP数据包
4.  先获取目标机器B的MAC地址。
5.  数据链路层构建一个数据帧，目的地址是IP层传过来的MAC地址，源地址是本机的MAC地址
6.  机器B收到后，对比目标地址，和自己本机的MAC地址是否一致，符合就处理返回，不符合就丢弃。
7.  根据目的主机返回的ICMP回送回答报文中的时间戳，从而计算出往返时间
8.  最终显示结果有这几项：发送到目的主机的IP地址、发送 & 收到 & 丢失的分组数、往返时间的最小、最大& 平均值

## （35）请详细介绍一下TCP 的三次握手机制 ##

**思路**: TCP连接的三次握手机制，**最重要的知识点**，必须得会，通讯过程以及客户端、服务器的对应的状态都需要记住。

TCP提供可靠的连接服务，连接是通过三次握手进行初始化的。三次握手的**目的就是同步连接双方的序列号和确认号并交换TCP窗口大小信息**。我们一起来看下流程图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 24]

*  第一次握手(SYN=1, seq=x)，发送完毕后，客户端就进入SYN\_SEND状态
 *  第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1)， 发送完毕后，服务器端就进入SYN\_RCV状态。
 *  第三次握手(ACK=1，ACKnum=y+1)，发送完毕后，客户端进入ESTABLISHED状态，当服务器端接收到这个包时，也进入ESTABLISHED状态。

## （36）TCP握手为什么是三次，为什么不能是两次？不能是四次？ ##

**思路**: TCP握手为什么不能是两次，为什么不能是四次呢？为了方便理解，我们以男孩子和女孩子谈恋爱为例子：两个人能走到一起，最重要的事情就是相爱，就是我爱你，并且我知道，你也爱我，接下来我们以此来模拟三次握手的过程：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 25]  
**为什么握手不能是两次呢？**

*  如果只有两次握手，女孩子可能就不知道，她的那句我也爱你，男孩子是否收到，恋爱关系就不能愉快展开。

**为什么握手不能是四次呢？**

*  因为握手不能是四次呢？因为三次已经够了，三次已经能让双方都知道：你爱我，我也爱你。而四次就多余了。

## （37）说说TCP四次挥手过程 ##

**思路**: TCP的四次挥手，也是最重要的知识点，一般跟三次握手会一起考的，必须得记住。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 26]

1.  第一次挥手(FIN=1，seq=u)，发送完毕后，客户端进入**FIN\_WAIT\_1**状态。
2.  第二次挥手(ACK=1，ack=u+1,seq =v)，发送完毕后，服务器端进入**CLOSE\_WAIT**状态，客户端接收到这个确认包之后，进入**FIN\_WAIT\_2**状态。
3.  第三次挥手(FIN=1，ACK1,seq=w,ack=u+1)，发送完毕后，服务器端进入**LAST\_ACK**状态，等待来自客户端的最后一个ACK。
4.  第四次挥手(ACK=1，seq=u+1,ack=w+1)，客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入TIME\_WAIT状态，**等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后**，没有收到服务器端的ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入CLOSED状态。服务器端接收到这个确认包之后，关闭连接，进入CLOSED状态。

## （38）TCP挥手为什么需要四次呢？ ##

**思路**： TCP挥手为什么需要四次呢？为了方便大家理解，再举个生活的例子吧。

> 小明和小红打电话聊天，通话差不多要结束时，小红说，“我没啥要说的了”。小明回答，“我知道了”。但是小明可能还有要说的话，小红不能要求小明跟着她自己的节奏结束通话，于是小明可能又叽叽歪歪说了一通，最后小明说，“我说完了”，小红回答，“我知道了”，这样通话才算结束。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 27]

## （39）TCP四次挥手过程中，为什么需要等待2MSL,才进入CLOSED关闭状态 ##

思路： 这个问得频率特别高。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 28]  
2MSL，**two Maximum Segment Lifetime**，即两个最大段生命周期。假设主动发起挥手的是客户端，那么需要2MSL的原因是：

1.  **为了保证客户端发送的最后一个ACK报文段能够到达服务端**。 这个ACK报文段有可能丢失，因而使处在**LAST-ACK**状态的服务端就收不到对已发送的**FIN + ACK**报文段的确认。服务端会超时重传这个FIN+ACK 报文段，而客户端就能在 2MSL 时间内（**超时 + 1MSL 传输**）收到这个重传的 FIN+ACK 报文段。接着客户端重传一次确认，重新启动2MSL计时器。最后，客户端和服务器都正常进入到**CLOSED**状态。
2.  **防止已失效的连接请求报文段出现在本连接中**。客户端在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。

## （40）TCP的粘包和拆包 ##

TCP是面向流，没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，所以在业务上认为，**一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送**，这就是所谓的TCP粘包和拆包问题。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 29]  
**为什么会产生粘包和拆包呢?**

*  要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包；
 *  接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包；
 *  要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包；
 *  待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。即TCP报文长度-TCP头部长度>MSS。

**解决方案：**

*  发送端将每个数据包封装为固定长度
 *  在数据尾部增加特殊字符进行分割
 *  将数据分为两部分，一部分是头部，一部分是内容体；其中头部结构大小固定，且有一个字段声明内容体的大小。

## （41）TCP和UDP区别 ##

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>UDP</th> 
   <th>TCP</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>是否连接</td> 
   <td>无连接</td> 
   <td>面向连接</td> 
  </tr> 
  <tr> 
   <td>是否可靠</td> 
   <td>不可靠传输，不使用流量控制和拥塞控制</td> 
   <td>可靠传输，使用流量控制和拥塞控制</td> 
  </tr> 
  <tr> 
   <td>连接对象个数</td> 
   <td>支持一对一，一对多，多对一和多对多交互通信</td> 
   <td>只能是一对一通信</td> 
  </tr> 
  <tr> 
   <td>传输方式</td> 
   <td>面向报文</td> 
   <td>面向字节流</td> 
  </tr> 
  <tr> 
   <td>首部开销</td> 
   <td>首部开销小，仅8字节</td> 
   <td>首部最小20字节，最大60字节</td> 
  </tr> 
  <tr> 
   <td>适用场景</td> 
   <td>适用于实时应用（IP电话、视频会议、直播等）</td> 
   <td>适用于要求可靠传输的应用，例如文件传输</td> 
  </tr> 
 </tbody> 
</table>

## （42）聊聊TCP的流量控制 ##

TCP三次握手，发送端和接收端进入到ESTABLISHED状态，它们即可以传输数据。

但是发送端不能疯狂地向接收端发送数据，因为接收端接收不过来的话，接收方只能把处理不过来的数据存在缓存区里。如果缓存区都满了，发送方还在疯狂发送数据的话，接收方只能把收到的数据包丢掉，这就浪费了网络资源。

TCP 提供一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量，这就是**流量控制**。

TCP通过**滑动窗口**来控制流量，我们看下流量控制的简要流程吧：

首先双方三次握手，初始化各自的窗口大小，均为 400 个字节。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 30]

1.  假如当前发送方给接收方发送了200个字节，那么，发送方的SND.NXT会右移200个字节，也就是说当前的可用窗口减少了200 个字节。
2.  接受方收到后，放到缓冲队列里面，REV.WND =400-200=200字节，所以win=200字节返回给发送方。接收方会在 ACK 的报文首部带上缩小后的滑动窗口200字节
3.  发送方又发送200字节过来，200字节到达，继续放到缓冲队列。不过这时候，由于大量负载的原因，接受方处理不了这么多字节，只能处理100字节，剩余的100字节继续放到缓冲队列。这时候，REV.WND = 400-200-100=100字节，即win=100返回发送方。
4.  发送方继续干活，发送100字节过来，这时候，接受窗口win变为0。
5.  发送方停止发送，开启一个定时任务，每隔一段时间，就去询问接受方，直到win大于0，才继续开始发送。

## （43）说说半连接队列和 SYN Flood攻击的关系 ##

TCP进入三次握手前，服务端会从**CLOSED**状态变为**LISTEN**状态,同时在内部创建了两个队列：半连接队列（SYN队列）和全连接队列（ACCEPT队列）。

什么是**半连接队列（SYN队列）** 呢? 什么是**全连接队列（ACCEPT队列）** 呢？回忆下TCP三次握手的图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 31]

*  TCP三次握手时，客户端发送SYN到服务端，服务端收到之后，便回复**ACK和SYN**，状态由**LISTEN变为SYN\_RCVD**，此时这个连接就被推入了**SYN队列**，即半连接队列。
 *  当客户端回复ACK, 服务端接收后，三次握手就完成了。这时连接会等待被具体的应用取走，在被取走之前，它被推入ACCEPT队列，即全连接队列。

SYN Flood是一种典型的DDos攻击，它在短时间内，伪造不存在的IP地址,向服务器大量发起SYN报文。当服务器回复SYN+ACK报文后，不会收到ACK回应报文，导致服务器上建立大量的半连接半连接队列满了，这就无法处理正常的TCP请求。

那么有哪些方案应对呢？**主要有 syn cookie和SYN Proxy防火墙等。**

*  **syn cookie**：在收到SYN包后，服务器根据一定的方法，以数据包的源地址、端口等信息为参数计算出一个cookie值作为自己的SYNACK包的序列号，回复SYN+ACK后，服务器并不立即分配资源进行处理，等收到发送方的ACK包后，重新根据数据包的源地址、端口计算该包中的确认序列号是否正确，如果正确则建立连接，否则丢弃该包。
 *  **SYN Proxy防火墙**：服务器防火墙会对收到的每一个SYN报文进行代理和回应，并保持半连接。等发送方将ACK包返回后，再重新构造SYN包发到服务器，建立真正的TCP连接。

## （44）聊聊TCP的滑动窗口 ##

**思路讲解**： TCP滑动窗口是个高频考点，我们需要知道TCP报文首部有个字段**win**控制窗口大小的，同时也需要掌握，滑动窗口是怎么滑的。

TCP 发送一个数据，如果需要收到确认应答，才会发送下一个数据。这样的话就会有个缺点：**效率会比较低。**

这就好像我们面对面在聊天，你说完一句，我应答之后，你才能说下一句。那么，如果我在忙其他事情，没有能够及时回复你呢？你说完一句后，要等到我忙完回复你，你才说下句，这显然不现实，效率太低。

为了解决这个问题，TCP引入了**窗口**，它是操作系统开辟的一个缓存空间。窗口大小值表示无需等待确认应答，而可以继续发送数据的最大值。

TCP头部有个字段叫win，也即那个**16位的窗口大小**，它告诉对方本端的TCP接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度，从而达到**流量控制**的目的。

通俗点讲，就是接受方每次收到数据包，在发送确认报文的时候，同时告诉发送方，自己的缓存区还有多少空余空间，缓冲区的空余空间，我们就称之为接受窗口大小。这就是win。

TCP 滑动窗口分为两种: 发送窗口和接收窗口。**发送端的滑动窗口**包含四大部分，如下：

*  已发送且已收到ACK确认
 *  已发送但未收到ACK确认
 *  未发送但可以发送
 *  未发送也不可以发送

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 32]

*  虚线矩形框，就是发送窗口。
 *  SND.WND: 表示发送窗口的大小,上图虚线框的格子数是14个，即发送窗口大小是14。
 *  SND.NXT：下一个发送的位置，它指向未发送但可以发送的第一个字节的序列号。
 *  SND.UNA: 一个绝对指针，它指向的是已发送但未确认的第一个字节的序列号。

接收方的滑动窗口包含三大部分，如下：

*  已成功接收并确认
 *  未收到数据但可以接收
 *  未收到数据并不可以接收的数据  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 33]
 *  虚线矩形框，就是接收窗口。
 *  REV.WND: 表示接收窗口的大小,上图虚线框的格子就是9个。
 *  REV.NXT:下一个接收的位置，它指向未收到但可以接收的第一个字节的序列号。

## （45）TCP的拥塞控制 ##

**思路讲解**： TCP拥塞机制也是个高频考点，**需要掌握它跟流量控制的区别**，也需要掌握拥塞控制的这几种算法：**慢启动算法、拥塞避免、拥塞发生、快速恢复算法。**

拥塞控制是 **作用于网络的，防止过多的数据包注入到网络中，避免出现网络负载过大的情况。** 它的目标主要是最大化利用网络上瓶颈链路的带宽。它跟流量控制又有什么区别呢？流量控制是作用于接收者的，**根据接收端的实际接收能力控制发送速度**，防止分组丢失的。

我们可以把网络链路比喻成一根水管，如果我们想最大化利用网络来传输数据，那就是尽快让水管达到最佳充满状态。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 34]  
发送方维护一个**拥塞窗口cwnd（congestion window）** 的变量，用来估算在一段时间内这条链路（水管）可以承载和运输的数据（水）的数量。它大小代表着网络的拥塞程度，并且是动态变化的，但是为了达到最大的传输效率，我们该如何知道这条水管的运送效率是多少呢？

一个比较简单的方法就是不断增加传输的水量，直到水管快要爆裂为止（对应到网络上就是发生丢包），用 TCP的描述就是：

> 只要网络中没有出现拥塞，拥塞窗口的值就可以再增大一些，以便把更多的数据包发送出去，但只要网络出现拥塞，拥塞窗口的值就应该减小一些，以减少注入到网络中的数据包数。

实际上，拥塞控制主要有这几种常用算法

*  慢启动
 *  拥塞避免
 *  拥塞发生
 *  快速恢复

### （45.1）慢启动算法 ###

慢启动算法，表面意思就是，别急慢慢来。它表示TCP建立连接完成后，一开始不要发送大量的数据，而是先探测一下网络的拥塞程度。由小到大逐渐增加拥塞窗口的大小，如果没有出现丢包，**每收到一个ACK，就将拥塞窗口cwnd大小就加1（单位是MSS）**。每轮次发送窗口增加一倍，呈指数增长，如果出现丢包，拥塞窗口就减半，进入拥塞避免阶段。

*  TCP连接完成，初始化cwnd = 1，表明可以传一个MSS单位大小的数据。
 *  每当收到一个ACK，cwnd就加一;
 *  每当过了一个RTT，cwnd就增加一倍; 呈指数让升

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 35]  
为了防止cwnd增长过大引起网络拥塞，还需设置一个**慢启动阀值ssthresh**（slow start threshold）状态变量。当cwnd到达该阀值后，就好像水管被关小了水龙头一样，减少拥塞状态。即当**cwnd >ssthresh**时，进入了**拥塞避免**算法。

### （45.2）拥塞避免算法 ###

一般来说，慢启动阀值ssthresh是65535字节，cwnd到达**慢启动阀值**后

*  每收到一个ACK时，cwnd = cwnd + 1/cwnd
 *  当每过一个RTT时，cwnd = cwnd + 1

显然这是一个线性上升的算法，避免过快导致网络拥塞问题。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 36]

### （45.3）拥塞发生算法 ###

当网络拥塞发生丢包时，会有两种情况：

*  RTO超时重传
 *  快速重传

如果是发生了**RTO超时重传**，就会使用拥塞发生算法

*  慢启动阀值sshthresh = cwnd /2
 *  cwnd 重置为 1
 *  进入新的慢启动过程

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 37]  
这真的是辛辛苦苦几十年，一朝回到解放前。其实还有更好的处理方式，就是**快速重传**。发送方收到3个连续重复的ACK时，就会快速地重传，不必等待**RTO超时**再重传。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 38]  
慢启动阀值ssthresh 和 cwnd 变化如下：

*  拥塞窗口大小 cwnd = cwnd/2
 *  慢启动阀值 ssthresh = cwnd
 *  进入快速恢复算法

### （45.4）快速恢复算法 ###

快速重传和快速恢复算法一般同时使用。快速恢复算法认为，还有3个重复ACK收到，说明网络也没那么糟糕，所以没有必要像RTO超时那么强烈。

正如前面所说，进入快速恢复之前，cwnd 和 sshthresh已被更新：

- cwnd = cwnd /2
    - sshthresh = cwnd

然后，真正的快速算法如下：

*  cwnd = sshthresh + 3
 *  重传重复的那几个ACK（即丢失的那几个数据包）
 *  如果再收到重复的 ACK，那么 cwnd = cwnd +1
 *  如果收到新数据的 ACK 后, cwnd = sshthresh。因为收到新数据的 ACK，表明恢复过程已经结束，可以再次进入了拥塞避免的算法了。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 39]

## （46）说说TCP是如何确保可靠性的呢？ ##

思路： TCP是可靠的连接，为什么具有可靠性呢？记住这些点：连接和断开的可靠性（三次握手，四次挥手）、有状态（哪些数据发送了，哪些没发）、可控制（超时重传、流量控制、拥塞控制等）。

*  首先，TCP的连接是基于**三次握手**，而断开则是基于**四次挥手**。确保连接和断开的可靠性。
 *  其次，TCP的可靠性，还体现在**有状态**;TCP会记录哪些数据发送了，哪些数据被接收了，哪些没有被接受，并且保证数据包按序到达，保证数据传输不出差错。
 *  再次，TCP的可靠性，还体现在**可控制**。它有数据包校验、ACK应答、**超时重传(发送方)**、失序数据重传（接收方）、丢弃重复数据、流量控制（滑动窗口）和拥塞控制等机制。

## （47）说说TCP报文首部有哪些字段，其作用又分别是什么？ ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 40]

*  **16位端口号**：源端口号，主机该报文段是来自哪里；目标端口号，要传给哪个上层协议或应用程序
 *  **32位序号**：一次TCP通信（从TCP连接建立到断开）过程中某一个传输方向上的字节流的每个字节的编号。
 *  **32位确认号**：用作对另一方发送的tcp报文段的响应。其值是收到的TCP报文段的序号值加1。
 *  **4位头部长度**：表示tcp头部有多少个32bit字（4字节）。因为4位最大能标识15，所以TCP头部最长是60字节。
 *  **6位标志位**：URG(紧急指针是否有效)，ACk（表示确认号是否有效），PSH（缓冲区尚未填满），RST（表示要求对方重新建立连接），SYN（建立连接消息标志接），FIN（表示告知对方本端要关闭连接了）
 *  **16位窗口大小**：是TCP流量控制的一个手段。这里说的窗口，指的是接收通告窗口。它告诉对方本端的TCP接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度。
 *  **16位校验和**：由发送端填充，接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。注意，这个校验不仅包括TCP头部，也包括数据部分。这也是TCP可靠传输的一个重要保障。
 *  **16位紧急指针**：一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。因此，确切地说，这个字段是紧急指针相对当前序号的偏移，不妨称之为紧急偏移。TCP的紧急指针是发送端向接收端发送紧急数据的方法。

## （48）Nagle 算法与延迟确认 ##

### （48.1）Nagle算法 ###

如果发送方疯狂地向接收方发送很小的数据包，比如一次就发送1个字节，那么显然会有问题。

TCP/IP协议中，无论发送多少数据，总是需要在数据前面加上协议头，同时，对方接收到数据，也需要发送ACK表示确认。为了尽可能的利用网络带宽，TCP总是希望尽可能的发送足够大的数据。**Nagle算法**就是为了尽可能发送大块数据，避免网络中充斥着许多小数据块。

Nagle算法：**任意时刻，最多只能有一个未被确认的小段**。所谓“小段”，指的是小于MSS尺寸的数据块，所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。

**Nagle算法的实现规则：**

*  如果包长度达到MSS，则允许发送；
 *  如果该包含有FIN，则允许发送；
 *  设置了TCP\_NODELAY选项，则允许发送；
 *  未设置TCP\_CORK选项时，若所有发出去的小数据包（包长度小于MSS）均被确认，则允许发送；
 *  上述条件都未满足，但发生了超时（一般为200ms），则立即发送。

### （48.2）延迟确认 ###

如果接受方刚接收到发送方的数据包，在很短很短的时间内，又接收到第二个包。那么请问接收方是一个一个地回复好点，还是合在一起回复好呢？

接收方收到数据包后，如果暂时没有数据要发给对端，它可以等一小段时间，再确认（Linux上默认是40ms）。如果这段时间刚好有数据要传给对端，ACK就随着数据传输，而不需要单独发送一次ACK。如果超过时间还没有数据要发送，也发送ACK，避免对端以为丢包。

但是有些场景不能用延迟确认，比如发现了**乱序包、接收到了大于一个 frame 的报文，且需要调整窗口大小等。**

一般情况下，**Nagle算法和延迟确认**不能一起使用，Nagle算法意味着延迟发，延迟确认意味着延迟接收，酱紫就会造成更大的延迟，会产生性能问题。

## （49）说说TCP的重传机制 ##

**思路讲解： TCP的重传机制，也是道非常高频的面试题。重传包括超时重传、快速重传、带选择确认的重传（SACK）、重复SACK四种。**

### （49.1）超时重传 ###

超时重传，是TCP协议保证数据可靠性的另一个重要机制，其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。

这个一定时间内，一般是多少比较合理呢？来看下什么叫**RTT（Round-Trip Time，往返时间）**。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 41]  
RTT就是数据完全发送完，到收到确认信号的时间，即数据包的一次往返时间。超时重传时间，就是RTO（Retransmission Timeout)。

那么，**RTO到底设置多大呢？**

*  如果RTO设置很大，等了很久都没重发，这样肯定就不行。
 *  如果RTO设置很小，那很可能数据都没有丢失，就开始重发了，这会导致网络阻塞，从而恶性循环，导致更多的超时出现。

一般来说，RTO略微大于RTT，效果是最佳的。其实，RTO有个标准方法的计算公式，也叫`Jacobson / Karels` 算法。一起来看下吧：

**1. 首先计算SRTT（即计算平滑的RTT）**

SRTT = (1 - α) * SRTT + α * RTT  //求 SRTT 的加权平均

**2. 其次，计算RTTVAR (round-trip time variation)**

RTTVAR = (1 - β) * RTTVAR + β * (|RTT - SRTT|) //计算 SRTT 与真实值的差距

**3. 最后，得出最终的RTO**

RTO = µ * SRTT + ∂ * RTTVAR  =  SRTT + 4·RTTVAR

一般情况，α、β等的参数取值如下：

α = 0.125，β = 0.25， μ = 1，∂ = 4

别问这些参数是怎么来的，它们是大量实践，调出的最优参数。  
超时重传不是十分完美的重传方案，它有这些缺点：

*  当一个报文丢失时，会等待一定的超时周期，才重传分组，增加了端到端的时延。
 *  当一个报文丢失时，在其等待超时的过程中，可能会出现这种情况：其后的报文段已经被接收端接收但却迟迟得不到确认，发送端会认为也丢失了，从而引起不必要的重传，既浪费资源也浪费时间。

并且，对于TCP，如果发生一次超时重传，时间间隔下次就会加倍。

### （49.2）快速重传 ###

其实可以使用**快速重传**，来解决超时重发的时间等待问题。它不以时间驱动，而是以数据驱动。它是基于接收端的反馈信息来引发重传的。快速重传流程如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 42]  
发送方发送了 1，2，3，4，5，6份数据:

*  第一份 Seq=1 先送到了，于是就 Ack回2；
 *  第二份 Seq=2 也送到了，于是ACK回3；
 *  第三份 Seq=3 由于网络等某些原因，没送到；
 *  第四份 Seq=4 送到了，但是由于Seq=3没收到。因此ACK还是回3；
 *  后面的 Seq=5,6的也送到了，ACK还是回复3，因为Seq=3没有收到。
 *  发送方连着收到三个重复冗余ACK=3的确认（其实是4个哈，但是因为前面的一个是正常的ACK，后面三个才是重复冗余的），于是知道哪个报文段在传输过程中丢失了；发送方在定时器过期之前，重传该报文段。
 *  最后，接收方收到了 Seq=3，此时因为 Seq=4，5，6都收到了，于是它回ACK=7。

但是呢，快速重传也可能有问题：ACK只向告知发送方，最大的有序报文段。到底是哪个报文丢失了呢？并不确定！那到底该重传多少个包呢？

是重传 Seq=3 ？还是重传 Seq=3、Seq=4、Seq=5、Seq=6 呢？因为发送端并不清楚这三个连续的 ACK=3 是谁传回来的。

### （49.3）带选择确认的重传（SACK） ###

为了解决：应该重传多少个包的问题? TCP提供了带选择确认的重传（即SACK，Selective Acknowledgment）。

**SACK机制**就是，在快速重传的基础上，接收方返回最近收到报文段的序列号范围，这样发送方就知道接收方哪些数据包是没收到的。这样就很清楚应该重传哪些数据包  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 43]  
如上图中，发送方收到了三次同样的ACK=30的确认报文，于是就会触发快速重发机制，通过SACK信息发现只有30~ 39这段数据丢失，于是重发时，就只选择了这个30~39的TCP报文段进行重发。

### （49.4）重复SACK（D-SACK） ###

D-SACK，英文是Duplicate SACK，是在SACK的基础上做了一些扩展，主要用来告诉发送方，有哪些数据包，自己重复接受了。DSACK的目的是帮助发送方判断，是否发生了包失序、ACK丢失、包重复或伪重传。让TCP可以更好的做网络流控。来看个图吧：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 44]

参考文章：

*  [https://mp.weixin.qq.com/s/l3j9j-pt-bxixOLu25Kpow][https_mp.weixin.qq.com_s_l3j9j-pt-bxixOLu25Kpow]

--------------------

以上内容仅供参考学习，如有侵权请联系我删除！  
如果这篇文章对您有帮助，左下角的大拇指就是对博主最大的鼓励。  
您的鼓励就是博主最大的动力！

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70]: /images/20220829/b2b6c0885ca14c30baab1a3bc1edbba9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 1]: /images/20220829/393b658f93ec463da1776776bcc3ecaf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 2]: /images/20220829/db83987b535345baba61d8560a5093d0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 3]: /images/20220829/ef9d3b19ca594a78ab8e5c0d0d24d4d7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 4]: /images/20220829/c15cfefa6885482f977f5636ded22ba8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 5]: /images/20220829/fe3768f1097444eea350017fbb2edced.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 6]: /images/20220829/88f0ddcbaeab453db194b7f6f89802c7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 7]: /images/20220829/5d452eeb580e40fda78a2818c49a6f4e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 8]: /images/20220829/2ba1b1b0360f4135a5d198c3aea7513b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 9]: /images/20220829/17240c49fc044a728f18b4d443e42822.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 10]: /images/20220829/e388f93f8dc649d49fa81e15f46163c4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 11]: /images/20220829/4f5f6d5fb78748fa94324d3630e8315a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 12]: /images/20220829/2a996e4c0a144430a500ad7ba96c73b7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 13]: /images/20220829/2791da2f1a094165ba866110bc198c6c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 14]: /images/20220829/c468cb82ae7e41caab62fcf16bee0dc2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 15]: /images/20220829/df8b47d0f57d430b80ebdc38bab05767.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 16]: /images/20220829/ed3520e6cf1944f3bdac17f02df4a469.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 17]: /images/20220829/710a68f17028427aad853f3f6cb44a31.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 18]: /images/20220829/810ceffdec53409481e9ec2db3436de3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 19]: /images/20220829/c748444f0bf540dc938f4487aa0e82d2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 20]: /images/20220829/4f1ab14d2b5f4922bdbbc4397cc4bec0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 21]: /images/20220829/d9ed67697955498ea8c442afb013efa0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 22]: /images/20220829/2167568693944c08a6b79345ca4217bd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 23]: /images/20220829/d814685b5d7c4dfab96b5f09422e4046.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 24]: /images/20220829/a1b321e922374f70a16fae6261923efd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 25]: /images/20220829/3574394130514ad6a3357cb4c0ad845e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 26]: /images/20220829/239791ab70644836af90dbdd9b76d32a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 27]: /images/20220829/96fb325f959d4d2aa9ed914724c5f6e5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 28]: /images/20220829/d48a44bbd67140a88437ed35948d55b4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 29]: /images/20220829/f9bfbfaaa01e4aa7aa718909d8f59505.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 30]: /images/20220829/faa83857f6ac4c4e97ef3dcbb0a2605d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 31]: /images/20220829/7c4725537063491db3a2ead8bd53a5fb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 32]: /images/20220829/802a992b293c480b9965effa11d2cac1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 33]: /images/20220829/765f3d8f7dbd4c73bb6aabbbbd0b59d6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 34]: /images/20220829/b3e8b9bccbd64391ac4d077fa2155813.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 35]: /images/20220829/31faf08c3edd4555a62aab0b176c42db.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 36]: /images/20220829/47588201dd5f4b5aaa094ea46c46e651.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 37]: /images/20220829/62dca50e95614221b3dc96cfd126656c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 38]: /images/20220829/2444564074264e5f9981195a47422ce1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 39]: /images/20220829/7c343c02b3d34df2a3f005b44d9f25a0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 40]: /images/20220829/c4597a00bd154d36809085596ee5f95b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 41]: /images/20220829/e9846ad14f22429c86892d3f7ddbe355.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 42]: /images/20220829/5c37f1275bbb4ce6a774d1ebd3235860.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 43]: /images/20220829/6ab7cb32734840b8b18d899891a8ea84.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTM2NjQ5OQ_size_16_color_FFFFFF_t_70 44]: /images/20220829/1c0384916c4f4ae8860998f2a1961bc3.png
[https_mp.weixin.qq.com_s_l3j9j-pt-bxixOLu25Kpow]: https://mp.weixin.qq.com/s/l3j9j-pt-bxixOLu25Kpow