【烈日炎炎战后端】计算机网络（4.2万字）

深碍√TFBOYSˉ_ 2023-03-06 05:08 54阅读 0赞

### 计算机网络（42068字） ###

*   *   *   *  2. 输入url（网址）之后到显示网页的过程？
             *  3. 什么是沾包？如何处理？
             *  【< TCP专题之三次握手四次挥手>】
             *   *  \[1\] TCP报文的结构
                 *  \[2\] 解释一下TCP三次握手四次挥手
                 *  \[3\] 为什么是三次握手，可以是两次吗？
                 *  \[4\] 为什么断开连接需要四次挥手？
                 *  \[5\] 为什么 TIME-WAIT 状态必须等待 2MSL 的时间呢？
             *  【TCP专题】
             *   *  \[1\] 讲一下TCP/IP协议？
                 *  \[2\] 讲一下TCP和UDP协议的区别（5条）？
                 *  \[3\] TCP协议是如何保证可靠传输的？
             *  【TCP 流量控制和拥塞控制专题】
             *   *  \[1\] 什么是“拥塞”？
                 *  \[2\] TCP流量控制和拥塞控制有什么区别?
                 *  \[3\] TCP拥塞控制四大算法?
             *  【HTTP专题】
             *   *  \[1\] HTTP是什么？
                 *  \[2\] HTTP概述
                 *  \[3\] HTTP 的基本性质
                 *  \[4\] HTTP 报文
                 *  \[5\] HTTP 请求方法
                 *  \[6\] HTTP 响应代码
                 *   *  信息响应（100-199）
                     *  成功响应（200-299）
                     *  重定向（300-399）
                     *  客户端响应（400-499）
                     *  服务端响应（500-599）
                 *  \[7\] 谈下 HTTP 1.0 和 1.1、2.0的主要变化？
                 *  \[8\] 讲一下HTTP和HTTPS协议的区别？
                 *  \[9\] 简单介绍一下SSL？
                 *  \[10\] HTTP中的Get，Post，Put具体指什么？
                 *  \[11\] GET和Post 请求有什么区别？
                 *  \[12\] HTTPS建立连接的过程？
         *  【<常见加密算法及实现>】
         *   *   *  1. 数字签名
                 *  2. 加密和解密
                 *   *  2.1. 加密
                     *  2.2. 解密
                 *  3. 对称加密和非对称加密
                 *   *  3.1. 对称加密
                     *  3.2. 非对称加密
                 *  4. 常见的签名加密算法
                 *   *  4.1. MD5算法
                     *  4.2. SHA1算法
                     *  4.4. AES/DES/3DES算法
                     *  4.5. RSA算法
                     *  4.6. ECC算法

1.  讲一下ISO七层模型？

图片来源：https://www.cnblogs.com/qishui/p/5428938.html  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzUxODAzOA_size_16_color_FFFFFF_t_70]  
**答：应用层->表示层->会话层->传输层->网络层->数据链路层->物理层**  
**应用层**：由用户自己规定，**规定各个应用之间消息传递的形式**等，包括各机互访协议，分布式数据库协议等。比如常见的协议：**HTTP协议**（Hyper Text Transfer Protocol）。

**表示层**：**规定传输格式**。在满足用户需求的基础上，尽可能的节省传输费用而设置的，比如传输压缩文件，jpeg或者加密文件等格式。

**会话层**：**用于建立和拆除会话**。计算机收到了发送的数据，但是有那么多进程，具体哪个进程需要用到这个数据，则把他输送到那个进程。

**传输层**：**负责将来自会话层的消息传递给网络层**。人为制定出单位，分成一个个的信息段，从中又衍生了报文，结合上面几层，我们就可以有目标的发送正确数据给某台计算机了。传输层有两个重要的协议：**TCP和UDP**。

**网络层**：**IP选址及其路由选择**。常见的网络层协议有IP，ICMP以及ARP等协议。前两层都是在于可以发数据，以及发的数据是否正确，然而如果连着两台电脑还行，多台电脑而又只想让其中一台可以通信，则需要**路由**。选择性的发，那每台电脑就得有自己的身份，于是出现了IP协议等。

**数据链路层**：**提供介质访问和连接管理**。

**物理层**：**规定一些机电性能**，也包括工作方式如双工（电话）、单工（打印机）或半双工（传呼机），建立通信的启动和终止等。

参考网站：[link][].[link][link 1].

记忆方法：鹰标会的传人、王树武

> 规定两个应用之间传输的请求和响应格式？那就是**应用层**负责的事情；接下来是不是需要规定传输格式？这就是表示层；然后需要会话层来建立会话；由传输层将数据包传输到网络层，然后通过数据链路来传输；最底层还需要物理层来规定一些物理硬件层面的东西。

![image-20200801154434207][]

#### 2. 输入url（网址）之后到显示网页的过程？ ####

> 已订正，每个步骤都可以细化成很多问题，也可以说这个问题可以覆盖计算机网络常见知识的每个内容。
> 
> 参考链接：[link][link 2]

1.  **DNS （Domain Name Server）域名解析**：浏览器查询 DNS，获取域名对应的 IP 地址。查找顺序为：**浏览器 、缓存系统的缓存、本地的hosts文件、本地DNS服务器、递归查询、迭代查询**。
2.  **TCP 连接**：浏览器获得域名对应的 IP 地址以后，浏览器向服务器请求建立链接，发起三次握手；
3.  **发送 HTTP 请求**：TCP 连接建立起来后，浏览器向服务器发送 HTTP 请求；
4.  **服务器处理请求并返回HTTP报文**：服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器。
5.  **浏览器解析渲染页面**：浏览器解析并渲染视图，若遇到对 js 文件、css 文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。
6.  **TCP断开连接**：为什么现在结束？浏览器在解析过程中，如果遇到请求外部资源时，如图像,iconfont,JS等。浏览器将重复1-5过程下载该资源。

> > **Host文件?**
> 
> > 是一个没有扩展名的系统文件，可以用记事本等工具打开，其作用就是将一些常用的网址域名与其对应的IP地址建立一个关联“数据库”。
> 
> > **为什么要域名解析？**
> 
> > 自己注册了域名之后如何才能看到自己的网站内容，用一个专业术语就叫“域名解析”。  
> > 　　在相关术语解释中已经介绍，域名和网址并不是一回事，域名注册好之后，只说明你对这个域名拥有了使用权，如果不进行域名解析，那么这个域名就不能发挥别的作用，经过解析的域名可以用来作为电子邮箱的后缀，也可以用来作为网址访问自己的网站，因此域名投入使用的必备环节是“域名解析”。  
> > 　　我们知道域名是为了方便记忆而专门建立的一套地址转换系统，要访问一台互联网上的服务器，最终还必须通过**IP地址**来实现，域名解析就是将域名重新转换为IP地址的过程。一个域名只能对应一个IP地址，而多个域名可以同时被解析到一个IP地址。域名解析需要由专门的域名解析服务器(DNS)来完成。  
> > 解析过程.比如,一个域名为: www.stasp.com,实现HTTP服务,如果想看到这个网站,要进行解析,首先在域名注册商那里通专门的DNS服务器解析解析到一个WEB服务器的一个固定IP上:211.214.1.\*\*\*,然后,通过WEB服务器来接收这个域名,把www.stasp.com 这个域名映射到这台服务器上.那么,输入www.stasp.com 这个域名就可以实现访问网站内容了.即可以实现了域名解析全过程;  
> > 人们习惯记忆域名，但机器间互相只认IP地址，域名与IP地址之间是一一对应的，它们之间的转换工作称为域名解析，域名解析需要由专门的域名解析服务器来完成，整个过程是自动进行的。
> 
> > http://baike.baidu.com/view/30676.htm
> 
> > **DNS查找详细过程**
> 
> >  *  浏览器缓存 – 浏览器会缓存DNS记录一段时间。 有趣的是，操作系统没有告诉浏览器储存DNS记录的时间，这样不同浏览器会储存个自固定的一个时间（2分钟到30分钟不等）。
> >  *  系统缓存 – 如果在浏览器缓存里没有找到需要的记录，浏览器会做一个系统调用（windows里是gethostbyname）。这样便可获得系统缓存中的记录。
> >  *  路由器缓存 – 接着，前面的查询请求发向路由器，它一般会有自己的DNS缓存。
> >  *  ISP DNS 缓存 – 接下来要check的就是ISP缓存DNS的[服务器][Link 1]。在这一般都能找到相应的缓存记录。
> >  *  递归搜索 – 你的ISP的DNS[服务器][Link 1]从跟域名[服务器][Link 1]开始进行递归搜索，从.com顶级域名[服务器][Link 1]到
> >  *  Facebook的域名[服务器][Link 1]。一般DNS[服务器][Link 1]的缓存中会 有.com域名[服务器][Link 1]中的域名，所以到顶级[服务器][Link 1]的匹配过程不是那么必要了。
> 
> **谈谈你对域名缓存的了解？**
> 
> > 为了提高 DNS 查询效率，并减轻服务器的负荷和减少因特网上的 DNS 查询报文数量，在域名服务器中广泛使用了高速缓存，用来存放最近查询过的域名以及从何处获得域名映射信息的记录。  
> > 由于名字到地址的绑定并不经常改变，为保持高速缓存中的内容正确，域名服务器应为每项内容设置计时器并处理超过合理时间的项（例如：每个项目两天）。当域名服务器已从缓存中删去某项信息后又被请求查询该项信息，就必须重新到授权管理该项的域名服务器绑定信息。当权限服务器回答一个查询请求时，在响应中都指明绑定有效存在的时间值。增加此时间值可减少网络开销，而减少此时间值可提高域名解析的正确性。  
> > 不仅在本地域名服务器中需要高速缓存，在主机中也需要。许多主机在启动时从本地服务器下载名字和地址的全部数据库，维护存放自己最近使用的域名的高速缓存，并且只在从缓存中找不到名字时才使用域名服务器。维护本地域名服务器数据库的主机应当定期地检查域名服务器以获取新的映射信息，而且主机必须从缓存中删除无效的项。由于域名改动并不频繁，大多数网点不需花精力就能维护数据库的一致性。
> > 
> > **域名解析过程**
> > 
> > 1.域名系统
> > 
> > ![img][]
> > 
> > ![img][img 1]
> > 
> > 2.域名服务器
> > 
> > ![img][img 2]
> > 
> > 1.  在浏览器中输入www.qq.com域名，操作系统会先检查自己**本地的hosts文件**是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
> > 2.  如果hosts里没有这个域名的映射，则查找**本地DNS解析器缓存**，是否有这个网址映射关系，如果有，直接返回，完成域名解析。
> > 3.  如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找T**CP/IP参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器**，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
> > 4.  4如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则**调用这个IP地址映射**，完成域名解析，此解析不具有权威性。
> > 5.  如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，
> > 
> >  *  **如果未用转发模式**，本地DNS就**把请求发至 “根DNS服务器”**，“根DNS服务器”收到请求后会判断这个域名(.com)是谁来授权管理，并会**返回一个负责该顶级域名服务器的一个IP**。**本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器**。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(qq.com)给本地DNS服务器。当**本地DNS服务器收到这个地址后，就会找qq.com域服务器，重复上面的动作，进行查询**，直至找到www.qq.com主机。
> >  *  **如果用的是转发模式**，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。
> >  *  不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。
> > 
> > **什么是递归查询，迭代查询？**
> > 
> > > 1.  **主机向本地域名服务器的查询一般都是采用递归查询**。所谓递归查询就是：如果主机所询问的本地域名服务器不知道被查询的域名的 IP 地址，那么本地域名服务器就以 DNS 客户的身份，向根域名服务器继续发出查询请求报文(即替主机继续查询)，而不是让主机自己进行下一步查询。因此，递归查询返回的查询结果或者是所要查询的 IP 地址，或者是报错，表示无法查询到所需的 IP 地址。
> > > 2.  **本地域名服务器向根域名服务器的查询的迭代查询**。迭代查询的特点：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的 IP 地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。然后让本地服务器进行后续的查询。根域名服务器通常是把自己知道的顶级域名服务器的 IP 地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所要查询的 IP 地址，要么告诉本地服务器下一步应当向哪一个权限域名服务器进行查询。最后，本地域名服务器得到了所要解析的 IP 地址或报错，然后把这个结果返回给发起查询的主机。
> > > 3.  **递归查询时，返回的结果只有两种:查询成功或查询失败.**
> > > 
> > > **迭代查询，又称作重指引,返回的是最佳的查询点或者主机地址**
> > > 
> > > https://www.cnblogs.com/qingdaofu/p/7399670.html

#### 3. 什么是沾包？如何处理？ ####

> https://blog.csdn.net/weixin\_45775963/article/details/107451035

1.  **什么是TCP粘包**  
    TCP粘包就是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方。
2.  **出现粘包的原因**

出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方。

*  **发送方原因**：Nagle算法造成了发送方可能会出现粘包问题。TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量），Nagle算法主要做两件事：只有上一个分组得到确认，才会发送下一个分组；收集多个小分组，在一个确认到来时一起发送。Negale 算法是指发送方发送的数据不会立即发出,而是先放在缓冲区, 等缓存区满了再发出。发送完一批数据后, 会等待接收方对这批数据的回应,然后再发送下一批数据。Negale 算法适用于发送方需要发送大批量数据, 并且接收方会及时作出回应的场合, 这种算法通过减少传输数据的次数来提高通信效率.
 *  **接收方原因**：TCP接收到数据包时，并不会马上交到应用层进行处理，或者说应用层并不会立即处理。实际上，TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

1.  **什么时候需要处理？**

*  如果发送方发送的多组数据本来就是同一块数据的不同部分，比如说一个文件被分成多个部分发送，这时当然不需要处理粘包现象，如果多个分组毫不相干，甚至是并列关系，这个时候就一定要处理粘包现象了。

1.  **如何处理？**

*  **发送方**：对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP\_NODELAY选项来关闭算法。
 *  **接收方**：接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。
 *  **应用层**：解决办法：循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成。但是如何判断每条数据的长度呢？**格式化数据**：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。**发送长度**：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置

1.  **TCP有粘包，UDP没有粘包**  
    TCP为了保证可靠传输并减少额外的开销（每次发包都要验证），采用了基于流的传输，基于流的传输不认为消息是一条一条的，是无保护消息边界的（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。

UDP则是面向消息传输的，是有保护消息边界的，接收方一次只接受一条独立的信息，所以不存在粘包问题。

#### 【< TCP专题之三次握手四次挥手>】 ####

##### \[1\] TCP报文的结构 #####

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

**TCP报文是TCP层传输的数据单元，也叫报文段。**

**1、端口号**：用来标识同一台计算机的不同的应用进程。

**1）源端口**：源端口和IP地址的作用是标识报文的返回地址。

**2）目的端口**：端口指明接收方计算机上的应用程序接口。

TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。

**2、序号和确认号**：是TCP可靠传输的关键部分。**序号**是本报文段发送的数据组的第一个字节的序号。在TCP传送的流中，每一个字节一个序号。e.g.一个报文段的序号为300，此报文段数据部分共有100字节，则下一个报文段的序号为400。所以序号确保了TCP传输的有序性。确认号，即ACK，指明下一个期待收到的字节序号，表明该序号之前的所有数据已经正确无误的收到。确认号只有当ACK标志为1时才有效。比如建立连接时，SYN报文的ACK标志位为0。

**3、数据偏移／首部长度**：4bits。由于首部可能含有可选项内容，因此TCP报头的长度是不确定的，报头不包含任何任选字段则长度为20字节，4位首部长度字段所能表示的最大值为1111，转化为10进制为15，15\*32/8 = 60，故报头最大长度为60字节。首部长度也叫数据偏移，是因为首部长度实际上指示了数据区在报文段中的起始偏移值。

**4、保留**：为将来定义新的用途保留，现在一般置0。

**5、控制位**：URG ACK PSH RST SYN FIN，共6个，每一个标志位表示一个控制功能。

**1）URG**：紧急指针标志，为1时表示紧急指针有效，为0则忽略紧急指针。

**2）ACK**：确认序号标志，为1时表示确认号有效，为0表示报文中不含确认信息，忽略确认号字段。

**3）PSH**：push标志，为1表示是带有push标志的数据，指示接收方在接收到该报文段以后，应尽快将这个报文段交给应用程序，而不是在缓冲区排队。

**4）RST**：重置连接标志，用于重置由于主机崩溃或其他原因而出现错误的连接。或者用于拒绝非法的报文段和拒绝连接请求。

**5）SYN**：同步序号，用于建立连接过程，在连接请求中，SYN=1和ACK=0表示该数据段没有使用捎带的确认域，而连接应答捎带一个确认，即SYN=1和ACK=1。

**6）FIN**：finish标志，用于释放连接，为1时表示发送方已经没有数据发送了，即关闭本方数据流。

**6、窗口**：滑动窗口大小，用来告知发送端接受端的缓存大小，以此控制发送端发送数据的速率，从而达到流量控制。窗口大小时一个16bit字段，因而窗口大小最大为65535。

**7、校验和**：奇偶校验，此校验和是对整个的 *TCP* 报文段，包括 *TCP* 头部和 *TCP* 数据，以 *16* 位字进行计算所得。由发送端计算和存储，并由接收端进行验证。

**8、紧急指针**：只有当 *URG* 标志置 *1* 时紧急指针才有效。紧急指针是一个正的偏移量，和顺序号字段中的值相加表示紧急数据最后一个字节的序号。 *TCP* 的紧急方式是发送端向另一端发送紧急数据的一种方式。

**9、选项和填充**：最常见的可选字段是最长报文大小，又称为MSS（Maximum Segment Size），每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志为1的那个段）中指明这个选项，它表示本端所能接受的最大报文段的长度。选项长度不一定是32位的整数倍，所以要加填充位，即在这个字段中加入额外的零，以保证TCP头是32的整数倍。

**10、数据部分**： *TCP* 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 *TCP* 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

**SYN，ACK，FIN等详细介绍：**

*  **同步SYN**：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。
 *  **确认ACK**：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效。
 *  **终止FIN**：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接。
 *  **序列号seq**：占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由**本地随机**产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。
 *  **确认号ack**：占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。

##### \[2\] 解释一下TCP三次握手四次挥手 #####

> [link][link 3]

图片来源于微信公众号：**码农求职小助手**  
\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-awauH9fr-1596601511600)(X:\\Users\\xu\\AppData\\Roaming\\Typora\\typora-user-images\\image-20200721194128725.png)\]  
答： 嗯(稍作思考)…

*  三次握手简单来说，在数据传输开始前：  
    **第一次：客户端将SYN标记为置为1，随机产生一个值seq=x，并将数据包发送给服务端表示要请求连接，客户端状态由CLOSE阶段切换到SYN\_SENT阶段，并等待服务端回应**。  
    **第二次：服务器端接收之后，服务端会将标志位SYN和ACK都置为1，seq=y，ack=x+1，发送给客户端，表示同意连接。服务端从LISTEN状态切换到SYN-RCVD状态**。  
    **第三次：客户端收到服务端的确认后，检查ack是否为x+1，若正确则将标志位ACK置为1，ack=y+1，并发送会服务端，此时客户端的状态切换为ESTABLISH状态，完成三次握手**。  
    三次握手完毕后，客户端与服务器才正式开始传送数据。

> **SYN攻击：**  
> 在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN\_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：  
> \#netstat -nap | grep SYN\_RECV

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jpfnoDuy-1596601511604)(X:\\Users\\xu\\AppData\\Roaming\\Typora\\typora-user-images\\image-20200721194310325.png)\]

*  四次挥手简单来说，在数据传输结束后：  
    **第一次挥手：客户端发送一个FIN包，序号seq=u，用来关闭数据传送，客户端由FIN\_WAIT\_1状态切换到ESTABLISH状态**。  
    **第二次挥手：服务端收到FIN包后，发送一个ACK给服务端，ack=u+1，服务端由ESTABLISH状态切换到CLOSE\_WAIT状态**。  
    **第三次挥手：服务端发送一个FIN包，seq=w，状态由CLOSE\_WAIT状态切换到LAST\_ACK状态**。  
    **第四次挥手：客户端收到FIN后，发送一个确认包，ack=w+1，并且进入TIME\_WAIT状态，等待2MSL（MSL最长报文段寿命）后，进入CLOSE状态。服务端收到确认号直接进入CLOSE阶段**

> PS：ACK、SYN和FIN这些大写的单词表示标志位，其值要么是1，要么是0；ack、seq小写的单词表示序号。原文链接：[link][link 4].

##### \[3\] 为什么是三次握手，可以是两次吗？ #####

**不可以**。假如没有第三次握手，服务端在某一时刻突然收到了一个来自被客户端卡了很久已经丢弃的SYN包，此时客户端是不想建立连接的，服务端的操作是返回SYN+ACK并且进入工作状态。客户端收到反馈后，无法告诉服务端这是错误的SYN的包，**会造成资源的浪费**。

##### \[4\] 为什么断开连接需要四次挥手？ #####

答：**因为在客户端发送给服务端FIN包后，服务端返回的FIN和ACK包是分开发送的**。为什么要分开呢？因为客户端发送给服务端FIN包后，只表示客户端已经没有数据要发送了，**但是另一个方向上可能还会有数据传输进来**。所以第二次和第三次挥手分开发送，服务端先给出ACK确认信号，表示已经收到FIN请求，然后**当自己也可以结束的时候**，即真正结束数据传输的时候，再次发送FIN信号。**是为了为未传输完毕的数据预留时间**，所以需要挥手交互需要四次。

##### \[5\] 为什么 TIME-WAIT 状态必须等待 2MSL 的时间呢？ #####

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

#### 【TCP专题】 ####

##### \[1\] 讲一下TCP/IP协议？ #####

TCP/IP协议模型在OSI七层模型的基础上，通过合并的方式，简化为四层，分别为**应用层，传输层，网络层以及链路层**。

我们通常的应用程序都工作在应用层，当各个应用之间通信时，传输层的TCP模块负责给HTTP数据添加TCP头部等信息；网络层的IP模块负责给HTTP数据添加IP头部等信息；链路层添加以太网首部等信息，并且通过电信号来传输数据包；然后数据包会依次经过对方的链路层，网络层，传输层以及应用层，实现数据的通信。

##### \[2\] 讲一下TCP和UDP协议的区别（5条）？ #####

答：TCP和UDP协议都是**传输层**常见的协议，它们的主要区别如下所示：

1.  **TCP提供面向连接的传输**，通信前要先建立连接（三次握手机制）； **UDP提供无连接的传输**，通信前不需要建立连接。
2.  **TCP提供可靠的传输**（校验，重排序，应答，丢弃重复，超时重发，滑动窗口）； **UDP不能保证传输的可靠**。
3.  **TCP面向字节流的传输**，因此它能将信息分割成组，并在接收端将其重组； UDP是**面向数据报的传输**，没有分组开销。
4.  **TCP提供拥塞控制**； UDP则不提供。
5.  每一条TCP连接只能是**点到点**的；UDP支持**一对一，一对多，多对一和多对多**的交互通信；
6.  网络包中的TCP头部为**20-60**个字节；UDP头部只有**8**个字节。

> **数据报**是通过网络传输的数据的基本单元，包含一个报头（header）和数据本身，其中报头描述了数据的目的地以及和其它数据之间的关系。数据报是完备的、独立的数据实体，该实体携带要从源计算机传递到目的计算机的信息，该信息不依赖以前在源计算机和目的计算机以及传输网络间交换

> \*\*总结：\*\*TCP通信类似于打电话，接通了，确认身份后，开始通话；  
> UDP通信类似于村喇叭，很多村民都能听到。

##### \[3\] TCP协议是如何保证可靠传输的？ #####

1.  **数据包校验**：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据；
2.  **对失序数据包重排序**：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层；
3.  **丢弃重复数据**：对于重复数据，能够丢弃重复数据；
4.  **应答机制**：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个**确认**（这个确认不是立即发送，通常将推迟几分之一秒）；
5.  **超时重发**：当 TCP 发出一个段后，它启动一个**定时器**，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
6.  **滑动窗口**：**是一种流量控制技术。TCP连接每一方都有固定大小的缓冲空间，滑动窗口的大小意味这接收方有多大的缓存区接受数据。当接收缓冲池的大小发生变化时，要给对方发送更新窗口大小的通知，利用滑动窗口机制有效提高通信效率**。

#### 【TCP 流量控制和拥塞控制专题】 ####

##### \[1\] 什么是“拥塞”？ #####

当提供给任何网络的负载能力超过它的处理能力时，拥塞便会产生。

##### \[2\] TCP流量控制和拥塞控制有什么区别? #####

TCP协议有两个比较重要的控制算法，一个是**流量控制**，另一个就是**阻塞控制**。

TCP协议通过滑动窗口来进行流量控制，它是控制发送方的发送速度从而使接受者来得及接收并处理。而拥塞控制作用于整体网络，**它是防止过多的包被发送到网络中，避免出现网络负载过大，网络拥塞的情况**。

拥塞算法需要掌握其状态机和四种算法。拥塞控制状态机的状态有五种，分别是Open，Disorder，CWR，Recovery和Loss状态。四个算法为慢启动，拥塞避免，拥塞发生时算法和快恢复。

##### \[3\] TCP拥塞控制四大算法? #####

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

拥塞控制主要是四个算法：1）慢启动，2）拥塞避免，3）快重传，4）快速恢复。

1.  也就是CP连接刚建立使用**慢启动算法**，发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量，其发送的数据包数量在每一个往返时间段都会呈指数形式上升，即cwnd会加倍。
2.  直到达到预设置的一个慢开始门限 ssthresh ，就会执行**拥塞避免算法**。拥塞避免规定数据包会从指数递增切换到加法递增。
3.  若发生拥塞，比较古老的方法是超时重传算法，它会在发送一个数据以后就开启一个计时器，在一定时间内如果没有得到发送数据报的ACK报文，那么就重新发送数据，直到发送成功为止。但是如果执行**快重传算法**，发送方如果收到三个重复确认，那么可以知道下一个报文段丢失，立即重传下一个报文段，而不用等计时器到时间。
4.  超时重传算法将慢启动阈值ssthresh设置为当前cwnd的一半，即ssthresh = cwnd / 2。并且cwnd重置为1，但是使用**快速恢复算法**会将cwnd大小缩小为当前的一半，ssthresh设置为缩小后的cwnd大小。总结则是，超时重传算法会让一切重新开始，慢启动阀值折半且拥塞窗口置为1，进入慢启动。但是使用**快速恢复算法**则只需要将窗口和慢启动阀值折半，窗口重新进入线性增加状态即可。

> **详细过程：**  
> 发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量，注意拥塞窗口与发送方窗口的区别：拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。
> 
> > **慢启动算法+拥塞避免**
> > 
> >  *  发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 …
> >  *  注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。
> >  *  如果出现了**超时**，则令 ssthresh = cwnd / 2，然后重新执行慢开始。
> > 
> > **快重传+快恢复**
> > 
> >  *  在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。
> >  *  在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。
> >  *  在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免。
> >  *  慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。

#### 【HTTP专题】 ####

参考链接：[link1][][link2][]

##### \[1\] HTTP是什么？ #####

\*\*超文本传输协议（HTTP）\*\*是一个用于传输超媒体文档（例如 HTML）的[应用层][Link 2]协议。它是为 Web 浏览器与 Web 服务器之间的通信而设计的，但也可以用于其他目的。HTTP 遵循经典的[客户端-服务端模型][-]，客户端打开一个连接以发出请求，然后等待它收到服务器端响应。HTTP 是[无状态协议][Link 3]，这意味着服务器不会在两个请求之间保留任何数据（状态）。该协议虽然通常基于 TCP/IP 层，但可以在任何可靠的[传输层][Link 4]上使用；也就是说，不像 UDP，它是一个不会静默丢失消息的协议。[RUDP][]——作为 UDP 的可靠化升级版本——是一种合适的替代选择。

##### \[2\] HTTP概述 #####

![HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer.][HTTP as an application layer protocol_ on top of TCP _transport layer_ and IP _network layer_ and below the presentation layer.]

**HTTP是一种能够获取如 HTML 这样的网络资源的 [protocol][](通讯协议)**。它是在 Web 上进行数据交换的基础，是一种 client-server 协议，也就是说，请求通常是由像浏览器这样的接受方发起的。一个完整的Web文档通常是由不同的子文档拼接而成的，像是文本、布局描述、图片、视频、脚本等等。

##### \[3\] HTTP 的基本性质 #####

1.  **HTTP 是简单的**。虽然下一代HTTP/2协议将HTTP消息封装到了帧（frames）中，HTTP大体上还是被设计得简单易读。HTTP报文能够被人读懂，还允许简单测试，降低了门槛，对新人很友好。
2.  **HTTP 是可扩展的**。在 HTTP/1.0 中出现的 [HTTP headers][] 让协议扩展变得非常容易。只要服务端和客户端就新 headers 达成语义一致，新功能就可以被轻松加入进来。
3.  **HTTP 是无状态，有会话的**。HTTP是无状态的：在同一个连接中，两个执行成功的请求之间是没有关系的。这就带来了一个问题，用户没有办法在同一个网站中进行连续的交互，比如在一个电商网站里，用户把某个商品加入到购物车，切换一个页面后再次添加了商品，这两次添加商品的请求之间没有关联，浏览器无法知道用户最终选择了哪些商品。而使用HTTP的头部扩展，HTTP Cookies就可以解决这个问题。把Cookies添加到头部中，创建一个会话让每次请求都能共享相同的上下文信息，达成相同的状态。**注意，HTTP本质是无状态的，使用Cookies可以创建有状态的会话**。
4.  **HTTP 和连接**。一个连接是由传输层来控制的，这从根本上不属于HTTP的范围。HTTP并不需要其底层的传输层协议是面向连接的，只需要它是可靠的，或不丢失消息的（至少返回错误）。在互联网中，有两个最常用的传输层协议：TCP是可靠的，而UDP不是。因此，HTTP依赖于面向连接的TCP进行消息传递，但连接并不是必须的。
    
    在客户端（通常指浏览器）与服务器能够交互（客户端发起请求，服务器返回响应）之前，必须在这两者间建立一个 TCP 链接，打开一个 TCP 连接需要多次往返交换消息（因此耗时）。HTTP/1.0 默认为每一对 HTTP 请求/响应都打开一个单独的 TCP 连接。当需要连续发起多个请求时，这种模式比多个请求共享同一个 TCP 链接更低效。
    
    为了减轻这些缺陷，HTTP/1.1引入了流水线（被证明难以实现）和持久连接的概念：底层的TCP连接可以通过[`Connection`][Connection]头部来被部分控制。HTTP/2则发展得更远，通过在一个连接复用消息的方式来让这个连接始终保持为暖连接。
    
    为了更好的适合HTTP，设计一种更好传输协议的进程一直在进行。Google就研发了一种以UDP为基础，能提供更可靠更高效的传输协议[QUIC][]。

##### \[4\] HTTP 报文 #####

HTTP/1.1以及更早的HTTP协议报文都是语义可读的。在HTTP/2中，这些报文被嵌入到了一个新的二进制结构，帧。帧允许实现很多优化，比如报文头部的压缩和复用。即使只有原始HTTP报文的一部分以HTTP/2发送出来，每条报文的语义依旧不变，客户端会重组原始HTTP/1.1请求。因此用HTTP/1.1格式来理解HTTP/2报文仍旧有效。

有两种HTTP报文的类型，**请求与响应**，每种都有其特定的格式。

1.  **请求**
    
    ![image-20200511111226252][image-20200801154434207]
    
    请求由以下元素组成：
    
     *  一个HTTP的[method][]，经常是由一个动词像[`GET`][GET], [`POST`][POST] 或者一个名词像[`OPTIONS`][OPTIONS]，[`HEAD`][HEAD]来定义客户端的动作行为。通常客户端的操作都是获取资源（GET方法）或者发送[HTML form][]表单值（POST方法），虽然在一些情况下也会有其他操作。
     *  要获取的资源的路径，通常是上下文中就很明显的元素资源的URL，它没有[protocol][]（`http://`），[domain][]（`developer.mozilla.org`），或是TCP的[port][]（HTTP一般在80端口）。
     *  HTTP协议版本号。
     *  为服务端表达其他信息的可选头部[headers][HTTP headers]。
     *  对于一些像POST这样的方法，报文的body就包含了发送的资源，这与响应报文的body类似。
2.  **响应**
    
    ![image-20200511111332621][image-20200801154434207]

响应报文包含了下面的元素：

*  HTTP协议版本号。
 *  一个状态码（[status code][]），来告知对应请求执行成功或失败，以及失败的原因。
 *  一个状态信息，这个信息是非权威的状态码描述信息，可以由服务端自行设定。
 *  HTTP [headers][HTTP headers]，与请求头部类似。
 *  可选项，比起请求报文，响应报文中更常见地包含获取的资源body。

##### \[5\] HTTP 请求方法 #####

HTTP 定义了一组**请求方法**, 以表明要对给定资源执行的操作。指示针对给定资源要执行的期望动作. 虽然他们也可以是名词, 但这些请求方法有时被称为HTTP动词.

GET

GET方法请求一个指定资源的表示形式. 使用GET的请求应该只被用于获取数据.

HEAD

HEAD方法请求一个与GET请求的响应相同的响应，但没有响应体.

POST

POST方法用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用.

PUT

PUT方法用请求有效载荷替换目标资源的所有当前表示。

DELETE

DELETE方法删除指定的资源。

CONNECT

CONNECT方法建立一个到由目标资源标识的服务器的隧道。

OPTIONS

OPTIONS方法用于描述目标资源的通信选项。

TRACE

TRACE方法沿着到目标资源的路径执行一个消息环回测试。

PATCH

PATCH方法用于对资源应用部分修改。

##### \[6\] HTTP 响应代码 #####

HTTP 响应状态代码指示特定 [HTTP][] 请求是否已成功完成。响应分为五类：信息响应(`100`–`199`)，成功响应(`200`–`299`)，重定向(`300`–`399`)，客户端错误(`400`–`499`)和服务器错误 (`500`–`599`)。状态代码由 [section 10 of RFC 2616][]定义。

###### 信息响应（100-199） ######

*  [`100 Continue`][100 Continue]
    
    这个临时响应表明，迄今为止的所有内容都是可行的，客户端应该继续请求，如果已经完成，则忽略它。
 *  [`101 Switching Protocol`][101 Switching Protocol]
    
    该代码是响应客户端的 [`Upgrade`][Upgrade] 标头发送的，并且指示服务器也正在切换的协议。
 *  [`102 Processing`][102 Processing] ([WebDAV][])
    
    此代码表示服务器已收到并正在处理该请求，但没有响应可用。
 *  [`103 Early Hints`][103 Early Hints]
    
    此状态代码主要用于与[`Link`][Link] 链接头一起使用，以允许用户代理在服务器仍在准备响应时开始预加载资源。

###### 成功响应（200-299） ######

*  [`200 OK`][200 OK]
    
    请求成功。成功的含义取决于HTTP方法：GET：资源已被提取并在消息正文中传输。HEAD：实体标头位于消息正文中。POST：描述动作结果的资源在消息体中传输。TRACE：消息正文包含服务器收到的请求消息
 *  [`201 Created`][201 Created]
    
    该请求已成功，并因此创建了一个新的资源。这通常是在POST请求，或是某些PUT请求之后返回的响应。
 *  [`202 Accepted`][202 Accepted]
    
    请求已经接收到，但还未响应，没有结果。意味着不会有一个异步的响应去表明当前请求的结果，预期另外的进程和服务去处理请求，或者批处理。
 *  [`203 Non-Authoritative Information`][203 Non-Authoritative Information]
    
    服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。例如，包含资源的元数据可能导致原始服务器知道元信息的超集。使用此状态码不是必须的，而且只有在响应不使用此状态码便会返回200 OK的情况下才是合适的。
 *  [`204 No Content`][204 No Content]
    
    服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。响应可能通过实体头部的形式，返回新的或更新后的元信息。如果存在这些头部信息，则应当与所请求的变量相呼应。如果客户端是浏览器的话，那么用户浏览器应保留发送了该请求的页面，而不产生任何文档视图上的变化，即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。由于204响应被禁止包含任何消息体，因此它始终以消息头后的第一个空行结尾。
 *  [`205 Reset Content`][205 Reset Content]
    
    服务器成功处理了请求，且没有返回任何内容。但是与204响应不同，返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后，立即重置表单，以便用户能够轻松地开始另一次输入。与204响应一样，该响应也被禁止包含任何消息体，且以消息头后的第一个空行结束。
 *  [`206 Partial Content`][206 Partial Content]
    
    服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。该请求必须包含 Range 头信息来指示客户端希望得到的内容范围，并且可能包含 If-Range 来作为请求条件。
 *  [`207 Multi-Status`][207 Multi-Status] ([WebDAV][])
    
    由WebDAV(RFC 2518)扩展的状态码，代表之后的消息体将是一个XML消息，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码。
 *  [`208 Already Reported`][208 Already Reported] ([WebDAV][])
    
    在 DAV 里面使用: propstat 响应元素以避免重复枚举多个绑定的内部成员到同一个集合。
 *  [`226 IM Used`][226 IM Used] ([HTTP Delta encoding][])
    
    服务器已经完成了对资源的 GET 请求，并且响应是对当前实例应用的一个或多个实例操作结果的表示。

###### 重定向（300-399） ######

*  [`300 Multiple Choice`][300 Multiple Choice]
    
    被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。
 *  [`301 Moved Permanently`][301 Moved Permanently]
    
    **被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。**
 *  [`302 Found`][302 Found]
    
    **请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。**
    
    **重定向是网页制bai作中的一个知识，几个例子跟你说du明，假设你现在所处的位置是zhi一个论dao坛的登录页面，你填写了帐号，密码，点击登陆，如果你的帐号密码正确，就自动跳转到论坛的首页，不正确就返回登录页；这里的自动跳转，就是重定向的意思。或者可以说，重定向就是，在网页上设置一个约束条件，条件满足，就自动转入到其它网页、网址**
    
    **301和302区别：**
    
    https://www.cnblogs.com/tongongV/p/10944414.html
 *  [`303 See Other`][303 See Other]
    
    对应当前请求的响应可以在另一个 URI 上被找到，而且客户端应当采用 GET 的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。
 *  [`304 Not Modified`][304 Not Modified]
    
    如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。304 响应禁止包含消息体，因此始终以消息头后的第一个空行结尾。
 *  `305 Use Proxy`
    
    被请求的资源必须通过指定的代理才能被访问。Location 域中将给出指定的代理所在的 URI 信息，接收者需要重复发送一个单独的请求，通过这个代理才能访问相应资源。只有原始服务器才能建立305响应。
 *  `306 unused`
    
    在最新版的规范中，306 状态码已经不再被使用。
 *  [`307 Temporary Redirect`][307 Temporary Redirect]
    
    请求的资源现在临时从不同的URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。
 *  [`308 Permanent Redirect`][308 Permanent Redirect]
    
    这意味着资源现在永久位于由 `Location:` HTTP Response 标头指定的另一个 URI。 这与 `301 Moved Permanently HTTP` 响应代码具有相同的语义，但用户代理不能更改所使用的 HTTP 方法：如果在第一个请求中使用 `POST`，则必须在第二个请求中使用 `POST`。

###### 客户端响应（400-499） ######

*  [`400 Bad Request`][400 Bad Request]
    
    1、语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。
    
    2、请求参数有误。
 *  [`401 Unauthorized`][401 Unauthorized]
    
    当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书，那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展示响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。
 *  `402 Payment Required`
    
    此响应码保留以便将来使用，创造此响应码的最初目的是用于数字支付系统，然而现在并未使用。
 *  [`403 Forbidden`][403 Forbidden]
    
    服务器已经理解请求，但是拒绝执行它。与 401 响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个 404 响应，假如它不希望让客户端获得任何信息。
 *  [`404 Not Found`][404 Not Found]
    
    **请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。**
 *  [`405 Method Not Allowed`][405 Method Not Allowed]
    
    请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。 鉴于 PUT，DELETE 方法会对服务器上的资源进行写操作，因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法，对于此类请求均会返回405错误。
 *  [`406 Not Acceptable`][406 Not Acceptable]
    
    请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。
 *  [`407 Proxy Authentication Required`][407 Proxy Authentication Required]
    
    与401响应类似，只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。
 *  [`408 Request Timeout`][408 Request Timeout]
    
    请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。
 *  [`409 Conflict`][409 Conflict]
    
    由于和被请求的资源的当前状态之间存在冲突，请求无法完成。这个代码只允许用在这样的情况下才能被使用：用户被认为能够解决冲突，并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。
 *  [`410 Gone`][410 Gone]
    
    被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能，拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的，那么就应该使用 404 状态码。除非额外说明，否则这个响应是可缓存的。
 *  [`411 Length Required`][411 Length Required]
    
    服务器拒绝在没有定义 `Content-Length` 头的情况下接受请求。在添加了表明请求消息体长度的有效 `Content-Length` 头之后，客户端可以再次提交该请求。
 *  [`412 Precondition Failed`][412 Precondition Failed]
    
    服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息（请求头字段数据）中设置先决条件，以此避免该请求方法被应用到其希望的内容以外的资源上。
 *  [`413 Payload Too Large`][413 Payload Too Large]
    
    服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。如果这个状况是临时的，服务器应当返回一个 `Retry-After` 的响应头，以告知客户端可以在多少时间以后重新尝试。
 *  [`414 URI Too Long`][414 URI Too Long]
    
    请求的URI 长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。这比较少见，通常的情况包括：本应使用POST方法的表单提交变成了GET方法，导致查询字符串（Query String）过长。
 *  [`415 Unsupported Media Type`][415 Unsupported Media Type]
    
    对于当前请求的方法和所请求的资源，请求中提交的实体并不是服务器中所支持的格式，因此请求被拒绝。
 *  [`416 Range Not Satisfiable`][416 Range Not Satisfiable]
    
    如果请求中包含了 Range 请求头，并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义 If-Range 请求头，那么服务器就应当返回416状态码。
 *  [`417 Expectation Failed`][417 Expectation Failed]
    
    此响应代码意味着服务器无法满足 [`Expect`][Expect] 请求标头字段指示的期望值。
 *  [`418 I'm a teapot`][418 I_m a teapot]
    
    服务器拒绝尝试用 `“茶壶冲泡咖啡”`。
 *  [`421 Misdirected Request`][421 Misdirected Request]
    
    该请求针对的是无法产生响应的服务器。 这可以由服务器发送，该服务器未配置为针对包含在请求 URI 中的方案和权限的组合产生响应。
 *  [`422 Unprocessable Entity`][422 Unprocessable Entity] ([WebDAV][])
    
    请求格式良好，但由于语义错误而无法遵循。
 *  [`423 Locked`][423 Locked] ([WebDAV][])
    
    正在访问的资源被锁定。
 *  [`424 Failed Dependency`][424 Failed Dependency] ([WebDAV][])
    
    由于先前的请求失败，所以此次请求失败。
 *  [`425 Too Early`][425 Too Early]
    
    服务器不愿意冒着风险去处理可能重播的请求。
 *  [`426 Upgrade Required`][426 Upgrade Required]
    
    服务器拒绝使用当前协议执行请求，但可能在客户机升级到其他协议后愿意这样做。 服务器在 426 响应中发送 [`Upgrade`][Upgrade] 头以指示所需的协议。
 *  [`428 Precondition Required`][428 Precondition Required]
    
    原始服务器要求该请求是有条件的。 旨在防止“丢失更新”问题，即客户端获取资源状态，修改该状态并将其返回服务器，同时第三方修改服务器上的状态，从而导致冲突。
 *  [`429 Too Many Requests`][429 Too Many Requests]
    
    用户在给定的时间内发送了太多请求（“限制请求速率”）。
 *  [`431 Request Header Fields Too Large`][431 Request Header Fields Too Large]
    
    服务器不愿意处理请求，因为它的 请求头字段太大（ Request Header Fields Too Large）。 请求可以在减小请求头字段的大小后重新提交。
 *  [`451 Unavailable For Legal Reasons`][451 Unavailable For Legal Reasons]
    
    用户请求非法资源，例如：由政府审查的网页。

###### 服务端响应（500-599） ######

*  [`500 Internal Server Error`][500 Internal Server Error]
    
    **服务器遇到了不知道如何处理的情况。**
 *  [`501 Not Implemented`][501 Not Implemented]
    
    此请求方法不被服务器支持且无法被处理。只有`GET`和`HEAD`是要求服务器支持的，它们必定不会返回此错误代码。
 *  [`502 Bad Gateway`][502 Bad Gateway]
    
    此错误响应表明服务器作为网关需要得到一个处理这个请求的响应，但是得到一个错误的响应。
 *  [`503 Service Unavailable`][503 Service Unavailable]
    
    服务器没有准备好处理请求。 常见原因是服务器因维护或重载而停机。 请注意，与此响应一起，应发送解释问题的用户友好页面。 这个响应应该用于临时条件和 `Retry-After`：如果可能的话，HTTP头应该包含恢复服务之前的估计时间。 网站管理员还必须注意与此响应一起发送的与缓存相关的标头，因为这些临时条件响应通常不应被缓存。
 *  [`504 Gateway Timeout`][504 Gateway Timeout]
    
    当服务器作为网关，不能及时得到响应时返回此错误代码。
 *  [`505 HTTP Version Not Supported`][505 HTTP Version Not Supported]
    
    服务器不支持请求中所使用的HTTP协议版本。
 *  [`506 Variant Also Negotiates`][506 Variant Also Negotiates]
    
    服务器有一个内部配置错误：对请求的透明内容协商导致循环引用。
 *  [`507 Insufficient Storage`][507 Insufficient Storage]
    
    服务器有内部配置错误：所选的变体资源被配置为参与透明内容协商本身，因此不是协商过程中的适当端点。
 *  [`508 Loop Detected`][508 Loop Detected] ([WebDAV][])
    
    服务器在处理请求时检测到无限循环。
 *  [`510 Not Extended`][510 Not Extended]
    
    客户端需要对请求进一步扩展，服务器才能实现它。服务器会回复客户端发出扩展请求所需的所有信息。
 *  [`511 Network Authentication Required`][511 Network Authentication Required]
    
    511 状态码指示客户端需要进行身份验证才能获得网络访问权限。

##### \[7\] 谈下 HTTP 1.0 和 1.1、2.0的主要变化？ #####

1.  HTTP1.0 经过多年发展，在 1.1 提出了改进。首先是提出了**长连接**，HTTP 可以在一次 TCP 连接中不断发送请求。
2.  HTTP2.0 支持**多路复用**，同一个连接可以并发处理多个请求，方法是把 HTTP数据包拆为多个帧，并发有序的发送，根据序号在另一端进行重组，而不需要一个个 HTTP请求顺序到达；

##### \[8\] 讲一下HTTP和HTTPS协议的区别？ #####

> 已经订正**参考文章**：[link1][link1 1]，[link2][link2 1]

*  **HTTP数据时明文传输，HTTPS是基于SSL的密文传输**；
 *  HTTPS一般是要需要区证书，是收费的；
 *  HTTP默认使用80端口，HTTPS默认使用443端口。

##### \[9\] 简单介绍一下SSL？ #####

记录协议为不同的更高层协议提供基本的安全服务，其特点是为web客户/服务器的交互提供传输服务的[超文本][Link 5][传输协议][Link 6]（HTTP）可在SSL上面运行。三个更高层协议被定义成SSL的一部分：握手协议、修改密文规约协议和告警协议。

SSL中两个重要的概念是SSL会话和SSL连接，规约如下：

（1）连接：连接是提供恰当类型服务的传输，对于SSL这样的连接是点对点的关系。连接是短暂的，每个连接与一个会话相联系。

（2）会话：SSL的会话是客户和服务器之间的关联，会话通过[握手协议][Link 7]来创建。会话定义了加密安全参数的一个集合，该集合可以被多个连接所共享。会话可用来避免为每个连接进行昂贵的新安全参数的协商。(Secure Sockets Layer）安全套接层，**主要提供以下安全服务**。

（1）信息保密，通过使用[公开密钥][Link 8]和对称密钥技术以达到信息保密。SSL客户机和服务器之间的所有业务都使用在SSL握手过程中建立的[密钥][Link 9]和算法进行加密。这样就防止了某些用户通过使用IP数据包[嗅探][Link 10]工具非法窃听。尽管数据包嗅探仍能捕捉到通信的内容，但却无法破译。

（2）信息完整性，确保SSL业务全部达到目的。应确保服务器和客户机之间的信息内容免受破坏。SSL利用机密共享和[hash函数][hash]组提供信息完整性服务。

（3）双向认证，客户机和服务器相互识别的过程。它们的识别号用公开密钥编码，并在SSL握手时交换各自的识别号。为了验证证明持有者是其合法用户（而不是冒名用户），SSL要求证明持有者在握手时对交换数据进行数字式标识。证明持有者对包括证明的所有信息数据进行标识，以说明自己是证明的合法拥有者。这样就防止了其他用户冒名使用证明。证明本身并不提供认证，只有证明和密钥一起才起作用。

（4）SSL的安全性服务对终端用户来讲做到尽可能透明。一般情况下，用户只需单击桌面上的一个按钮或联接就可以与SSL的[主机][Link 11]相连。与标准的HTTP连接申请不同，一台支持SSL的典型网络主机接受SSL连接的默认端口是443，而不是80。

**SSL协议：**

SSL被设计成使用TCP来提供一种可靠的端到端的安全服务，不是单个协议，而是二层协议，低层是**SSL记录层**，用于封装不同的上层协议，另一层是被封装的协议，即**SSL[握手协议][Link 7]**，它可以让服务器和客户机在传输应用数据之前，协商[加密算法][Link 12]和加密密钥，客户机提出自己能够支持的全部加密算法，服务器选择最适合它的算法。

SSL中两个重要的概念是SSL会话和SSL连接，规约如下：

（1）连接：连接是提供恰当类型服务的传输，对于SSL这样的连接是点对点的关系。连接是短暂的，每个连接与一个会话相联系。

（2）会话：SSL的会话是客户和服务器之间的关联，会话通过[握手协议][Link 7]来创建。会话定义了加密安全参数的一个集合，该集合可以被多个连接所共享。会话可用来避免为每个连接进行昂贵的新安全参数的协商。

##### \[10\] HTTP中的Get，Post，Put具体指什么？ #####

**答：它们都是HTTP中的请求方法：**

1.  GET(获得)方法：对这个资源的查操作。
2.  PUT(改)和POST（更新）都有更改指定URI的语义。

> 【拓展问题！！！！！！！！！！！！！！！！！！！】
> 
> 1.  **Put和Post 请求有什么区别？**
> 
> > **Put请求：如果两个请求相同，后一个请求会把第一个请求覆盖掉**。（所以PUT用来改资源）  
> > **Post请求：后一个请求不会把第一个请求覆盖掉**。（所以Post用来增资源）
> 
> 1.  **GET和Post 请求有什么区别？**
> 
> > 1.  Get一般用来从服务器上**查询信息**；Post一般用来**插入信息**；对于服务器讲：get是安全(不更改信息)、幂等(作用1次和n次效果相同); post不安全、不幂等; ，get是安全(不更改信息)、幂等(作用1次和n次效果相同); post不安全、不幂等;
> > 2.  对于客户端来讲：Get方法将参数直接拼接在了URL后边，**明文显示**，可以通过浏览器地址栏直接访问；Post请求用于提交表单，**数据不是明文的**，安全性更高；
> > 3.  Get请求**有长度限制**，Post请求**没有长度限制**。
> 
> https://www.zhihu.com/question/28586791?sort=created

##### \[11\] GET和Post 请求有什么区别？ #####

Http定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE。URL全称是资源描述符，我们可以这样认 为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查，改，增，删4个操作。到这里，大家应该有个大概的了解了，GET一般用于获取/查询资源信息，而POST一般用于更新资源信息。

**幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。**

对于单目运算，如果一个运算对于在范围内的所有的一个数多次进行该运算所得的结果和进行一次该运算所得的结果是一样的，那么我们就称该运算是幂等的。比如绝对值运算就是一个例子，在实数集中，有abs(a) = abs(abs(a))。  
对于双目运算，则要求当参与运算的两个值是等值的情况下，如果满足运算结果与参与运算的两个值相等，则称该运算幂等，如求两个数的最大值的函数，有在在实数集中幂等，即max(x,x) = x。

从理论上讲，**如果请求是幂等的就可以使用GET，所谓幂等是指多个请求返回相同的结果**。实际上，相应的服务器方法可能会以某种方式修改状态，所以一般情况下这是不成立的。这只是一种标准。更实际的区别在于净荷的大小，在许多情况下，浏览器和服务器会限制URL的长度URL用于向服务器发送数据。 一般来讲，可以使用GET从服务器获取数据；换句话说，要避免使用GET调用改变服务器上的状态。  
一般地，当改变服务器上的状态时应当使用POST方法。不同于GET，需要设置XML-HttpRequest对象的Content-Type首部，如下所示：  
xmlHttp.setRequestHeader(“Content-Type”,“application/x-www-form-urlencoded”);与GET不同，POST不会限制发送给服务器的净荷的大小，而且POST请求不能保证是幂等的。  
你做的大多数请求可能都是GET请求，不过，如果需要，也完全可以使用POST。

##### \[12\] HTTPS建立连接的过程？ #####

> 已经订正，参考文章：[link][link 5]
> 
> **HTTPS 的握手流程？为什么密钥的传递需要使用非对称加密？双向认证了解么？[link][link 6]**

**简介**：HTTPS是在HTTP的基础上和ssl/tls证书结合起来的一种协议,保证了传输过程中的安全性,减少了被恶意劫持的可能.很好的解决了解决了http的三个缺点（被监听、被篡改、被伪装）

**对称加密和非对称加密**

*  对称加密又称公开密钥加密，加密和解密都会用到同一个密钥，如果密钥被攻击者获得，此时加密就失去了意义。
 *  非对称加密又称共享密钥加密，使用一对非对称的密钥，一把叫做私有密钥，另一把叫做公有密钥；公钥加密只能用私钥来解密，私钥加密只能用公钥来解密。

但是非对称加密加解密比较复杂，加解密没有对称加密快；HTTP 权衡两种加密方式，采用混合加密机制，在传输对称加密密钥的时候使用非对称加密，然后在通信交换报文阶段则使用对称加密方式。  
链接：https://www.jianshu.com/p/d9e4c848ad10

**建立连接(顺便复习下输入网站到显示网页的过程)**

*  HTTP和HTTPS都需要在TCP建立连接的基础上来进行数据传输
 *  当客户在浏览器中输入网址的并且按下回车,浏览器会在浏览器DNS缓存,本地DNS缓存,和Hosts中寻找对应的记录,如果没有获取到则会请求DNS服务来获取对应的ip
 *  当获取到ip后,tcp连接会进行三次握手建立连接

**HTTP请求过程**

*  建立连接完毕以后，客户端会发送响应给服务端
 *  服务端接受请求并且做出响应发送给客户端
 *  客户端收到响应并且解析响应响应给客户

**HTTPS请求过程**

![img][img 3]

1.  客户端发起一个https的请求，把自身支持的一系列Cipher Suite（密钥算法套件，简称Cipher）（自己支持的一套加密算法和哈希算法）发送给服务端
2.  服务端，接收到客户端所有的Cipher后与自身支持的对比，从中挑选出一套自己支持的加密算法和哈希算法，如果不支持则连接断开
3.  然后把自己的信息以证书的形式返回给客户端 证书内容有：湾站地址、密匙公钥、证书颁发机构、失效日期等
4.  客户端收到服务端响应后会做以下几件事:

*  验证证书的合法性：验证证书的合法性，证书中包含的网站地址是否与正在访问的地址一致、证书是否过期等

证书验证通过后，在浏览器的地址栏会加上一把小锁(如楼主使用的Chrome浏览器)

*  生成随机密码：如果证书验证通过，或者用户接受了不受信任证书，然后浏览器会生成一串随机数，然后用证书中的公钥加密。
 *  HASH握手信息：用最开始约定好的HASH方式，把握手消息取HASH值， 然后用 随机数加密 “握手消息+握手消息HASH值(签名)” 并一起发送给服务端

> 在这里之所以要取握手消息的HASH值，主要是把握手消息做一个签名，用于验证握手消息在传输过程中没有被篡改过。

1.  服务端拿到客户端传来的密文，用自己的私钥来解密握手消息取出随机数密码，再用随机数密码 解密 握手消息与HASH值，并与传过来的HASH值做对比确认是否一致。
2.  然后用随机密码加密一段握手消息(握手消息+握手消息的HASH值 )给客户端
3.  客户端用随机数解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密

> 这里使用了对称加密和非对称加密相结合的方式，保证了服务端向客户端发送消息的可靠性。
> 
> **为什么不直接使用非对称加密或对称加密？**
> 
> 为什么不使用非对称加密，客户端持有私钥，然后将公钥发送给服务端即可？因为非对称他的速度要慢很多（使用模运算，幂运算）。那为什么不直接使用对称加密？因为使用对称加密的话，那么密钥在传输过程中容易泄露。所以采用用非对称加密来加密对称加密中的密钥，可以保证安全和效率！！！妙啊！！！
> 
> **为什么不直接使用对称加密？**
> 
> **非对称加密算法**：RSA，DSA/DSS 在客户端与服务端相互验证的过程中用的是对称加密
> 
> **对称加密算法**：AES，RC4，3DES 客户端与服务端相互验证通过后，以随机数作为密钥时，就是对称加密
> 
> **HASH算法**：MD5，SHA1，SHA256 在确认握手消息没有被篡改时
> 
> **为什么说RSA的非对称加密比AES对称加密速度慢？**  
> 链接：https://www.zhihu.com/question/350824284/answer/866215364
> 
> 首先说，除去人为因素的干预下（比如代码写得太烂，对比平台不公平等），现有的技术水平下，RSA无论是加密还是解密，一般是要比同长度的AES慢的。选择特定参数，比如e=65537，是会使得加密比解密快很多，但与AES仍然不是一个量级。事实上，RSA-OAEP在RSA加密前就需要两个Hash运算：直观上，这两个HASH运算与AES就是一个级别的复杂度，甚至用时会超过AES。
> 
> 造成这种现象的本质，在于基础运算的不同。RSA的基本运算是模幂，模的部分有优化算法处理，暂且不谈，我们只看幂运算本身：幂运算的基础单位是乘法，而乘法的基础单位是加法。这个加法，就是我们最熟悉，最常见的整数加。尽管如此，如果学过数字逻辑或者硬件设计的话，应该听说过这个“加法”在电路上比异或（XOR）要麻烦的多。有各种超前进位，并行进位的加法器设计，但没听说有什么异或器设计，是不是？
> 
> 我们以5+9和5 xor 9的二进制运算为例：
> 
> ![image-20200721202635691][image-20200801154434207]
> 
> 如果手算一下上面这个过程，你会明显看到，XOR的每个比特运算完全独立，与前后的比特无关；而加法的每个比特均需要考虑低位的进位。这样，计算最高位时，原则上需要等待低位的所有比特计算完毕，而异或并没有这个限制。这个现象称为进位链（carry chain）: 尽管可以用各种技术降低它的影响，但从根本上，它使得加法很难与异或得到相同的效率。
> 
> 现有的处理器可以提供单周期的加法或者乘法操作，但这里的前提是: 1) 付出了额外的电路资源 2）固定了位宽，比如32bit或者64bit；3）根据木桶短板的方式拉低了主频，比如单做xor可能可以提高主频，但为了考虑加法，降低了实际提供的主频。也就是说，对于任意长度电路计算，异或仍要比加密高效得多。
> 
> RSA目前的推荐长度至少2048，即使用中国剩余定理，也需要1024bit的幂运算，即大量的1024bit的加法。考虑一下1024bit的进位链对于最高位的压力，就很好理解它在速度上的劣势了。
> 
> 相反，如果是1024bit的AES，分组可能就是先拆分成16个128-bit AES。AES的基础运算实际有3种，Sbox，XOR以及移位。在现有的CMOS数字逻辑里，移位代价极低。异或前面说过，代价较低。唯一代价较高的运算是Sbox： 然而，尽管8bit的Sbox可能比8-bit的加法器更慢，但AES也只使用8-bit的Sbox而已。每轮的16个Sbox之间并没有关系，完全可以并行。此外，尽管操作复杂，由于空间很小，只有256种可能，完全可以预计算结果，进行查表处理。这也是Sbox最常见的处理方法：尽管存储器的读取速度依然比CPU低一个量级，相比于1024bit的进位链，依然有很大的优势。反过来，1024bit的加法空间太大，显然是没有办法进行预计算查表处理的。
> 
> 但是，从上面这个论述中也能看到，两者实际达到的效果也有不小的差距。安全性论述起来很复杂，但简单来说，RSA可以提供很多复杂的应用，而AES，即使套用了很多复杂的工作模式，也很难达到相同的覆盖面。许多公钥系统的价值更多体现在它能提供的特定安全功能上，而不是能快速完成文本加密。

### 【<常见加密算法及实现>】 ###

[link][link 7]  
**前言**  
**数字签名**、**信息加密** 是前后端开发都经常需要使用到的技术，应用场景包括了用户登入、交易、信息通讯、`oauth` 等等，不同的应用场景也会需要使用到不同的签名加密算法，或者需要搭配不一样的 **签名加密算法** 来达到业务目标。这里简单的给大家介绍几种常见的签名加密算法和一些典型场景下的应用。  
**正文**

##### 1. 数字签名 #####

**数字签名**，简单来说就是通过提供 **可鉴别** 的 **数字信息** 验证 **自身身份** 的一种方式。一套 **数字签名** 通常定义两种 **互补** 的运算，一个用于 **签名**，另一个用于 **验证**。分别由 **发送者** 持有能够 **代表自己身份**的 **私钥** (私钥不可泄露),由 **接受者** 持有与私钥对应的 **公钥** ，能够在 **接受** 到来自发送者信息时用于 **验证** 其身份。

> **注意**：图中 **加密过程** 有别于 **公钥加密**，更多 [介绍戳这里][Link 13]。**签名** 最根本的用途是要能够唯一 **证明发送方的身份**，防止 **中间人攻击**、`CSRF` **跨域身份伪造**。基于这一点在诸如 **设备认证**、**用户认证**、**第三方认证** 等认证体系中都会使用到 **签名算法** (彼此的实现方式可能会有差异)。

##### 2. 加密和解密 #####

###### 2.1. 加密 ######

**数据加密** 的基本过程，就是对原来为 **明文** 的文件或数据按 **某种算法** 进行处理，使其成为 **不可读** 的一段代码，通常称为 **“密文”**。通过这样的途径，来达到 **保护数据** 不被 **非法人窃取**、阅读的目的。

###### 2.2. 解密 ######

**加密** 的 **逆过程** 为 **解密**，即将该 **编码信息** 转化为其 **原来数据** 的过程。

##### 3. 对称加密和非对称加密 #####

加密算法分 **对称加密** 和 **非对称加密**，其中对称加密算法的加密与解密 **密钥相同**，非对称加密算法的加密密钥与解密 **密钥不同**，此外，还有一类 **不需要密钥** 的 **散列算法**。

> 常见的 **对称加密** 算法主要有 `DES`、`3DES`、`AES` 等，常见的 **非对称算法** 主要有 `RSA`、`DSA`等，**散列算法** 主要有 `SHA-1`、`MD5` 等。

###### 3.1. 对称加密 ######

**对称加密算法** 是应用较早的加密算法，又称为 **共享密钥加密算法**。在 **对称加密算法** 中，使用的密钥只有一个，**发送** 和 **接收** 双方都使用这个密钥对数据进行 **加密** 和 **解密**。这就要求加密和解密方事先都必须知道加密的密钥。

1.  数据加密过程：在对称加密算法中，**数据发送方** 将 **明文** (原始数据) 和 **加密密钥** 一起经过特殊 **加密处理**，生成复杂的 **加密密文** 进行发送。
2.  数据解密过程：**数据接收方** 收到密文后，若想读取原数据，则需要使用 **加密使用的密钥** 及相同算法的 **逆算法** 对加密的密文进行解密，才能使其恢复成 **可读明文**。

###### 3.2. 非对称加密 ######

**非对称加密算法**，又称为 **公开密钥加密算法**。它需要两个密钥，一个称为 **公开密钥** (`public key`)，即 **公钥**，另一个称为 **私有密钥** (`private key`)，即 **私钥**。  
因为 **加密** 和 **解密** 使用的是两个不同的密钥，所以这种算法称为 **非对称加密算法**。

1.  如果使用 **公钥** 对数据 **进行加密**，只有用对应的 **私钥** 才能 **进行解密**。
2.  如果使用 **私钥** 对数据 **进行加密**，只有用对应的 **公钥** 才能 **进行解密**。

> **例子**：甲方生成 **一对密钥** 并将其中的一把作为 **公钥** 向其它人公开，得到该公钥的 **乙方** 使用该密钥对机密信息 **进行加密** 后再发送给甲方，甲方再使用自己保存的另一把 **专用密钥** (**私钥**)，对 **加密** 后的信息 **进行解密**。

##### 4. 常见的签名加密算法 #####

###### 4.1. MD5算法 ######

`MD5` 用的是 **哈希函数**，它的典型应用是对一段信息产生 **信息摘要**，以 **防止被篡改**。严格来说，`MD5`不是一种 **加密算法** 而是 **摘要算法**。无论是多长的输入，`MD5` 都会输出长度为 `128bits` 的一个串 (通常用 `16` **进制** 表示为 `32` 个字符)。

###### 4.2. SHA1算法 ######

`SHA1` 是和 `MD5` 一样流行的 **消息摘要算法**，然而 `SHA1` 比 `MD5` 的 **安全性更强**。对于长度小于 `2 ^ 64` 位的消息，`SHA1` 会产生一个 `160` 位的 **消息摘要**。基于 `MD5`、`SHA1` 的信息摘要特性以及 **不可逆**(一般而言)，可以被应用在检查 **文件完整性** 以及 **数字签名** 等场景。

> **测试结论**：`HMAC` 算法实例在 **多线程环境** 下是 **不安全的**。但是需要在 **多线程访问** 时，进行同步的辅助类，使用 `ThreadLocal` 为 **每个线程缓存** 一个实例可以避免进行锁操作。

###### 4.4. AES/DES/3DES算法 ######

`AES`、`DES`、`3DES` 都是 **对称** 的 **块加密算法**，**加解密** 的过程是 **可逆的**。常用的有 `AES128`、`AES192`、`AES256` (默认安装的 `JDK` 尚不支持 `AES256`，需要安装对应的 `jce` 补丁进行升级 `jce1.7`，`jce1.8`)。  
**4.4.1. DES算法**  
`DES` 加密算法是一种 **分组密码**，以 `64` 位为 **分组对数据** 加密，它的 **密钥长度** 是 `56` 位，**加密解密** 用 **同一算法**。  
`DES` 加密算法是对 **密钥** 进行保密，而 **公开算法**，包括加密和解密算法。这样，只有掌握了和发送方 **相同密钥** 的人才能解读由 `DES`加密算法加密的密文数据。因此，破译 `DES` 加密算法实际上就是 **搜索密钥的编码**。对于 `56` 位长度的 **密钥** 来说，如果用 **穷举法** 来进行搜索的话，其运算次数为 `2 ^ 56`次。  
**4.4.2. 3DES算法**  
是基于 `DES` 的 **对称算法**，对 **一块数据** 用 **三个不同的密钥** 进行 **三次加密**，**强度更高**。  
**4.4.3. AES算法**  
`AES` 加密算法是密码学中的 **高级加密标准**，该加密算法采用 **对称分组密码体制**，密钥长度的最少支持为 `128` 位、 `192` 位、`256` 位，分组长度 `128` 位，算法应易于各种硬件和软件实现。这种加密算法是美国联邦政府采用的 **区块加密标准**。

`AES` 本身就是为了取代 `DES` 的，`AES` 具有更好的 **安全性**、**效率** 和 **灵活性**。

###### 4.5. RSA算法 ######

`RSA` 加密算法是目前最有影响力的 **公钥加密算法**，并且被普遍认为是目前 **最优秀的公钥方案** 之一。`RSA` 是第一个能同时用于 **加密** 和 **数字签名** 的算法，它能够 **抵抗** 到目前为止已知的 **所有密码攻击**，已被 `ISO` 推荐为公钥数据加密标准。

> `RSA` **加密算法** 基于一个十分简单的数论事实：将两个大 **素数** 相乘十分容易，但想要对其乘积进行 **因式分解** 却极其困难，因此可以将 **乘积** 公开作为 **加密密钥**。

###### 4.6. ECC算法 ######

`ECC` 也是一种 **非对称加密算法**，主要优势是在某些情况下，它比其他的方法使用 **更小的密钥**，比如 `RSA` **加密算法**，提供 **相当的或更高等级** 的安全级别。不过一个缺点是 **加密和解密操作** 的实现比其他机制 **时间长** (相比 `RSA` 算法，该算法对 `CPU` 消耗严重)。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzUxODAzOA_size_16_color_FFFFFF_t_70]: /images/20230208/bdbb6264b502403e9fa8ac7350794135.png
[link]: https://blog.csdn.net/taotongning/article/details/81352985?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task
[link 1]: https://blog.csdn.net/cmyh100/article/details/82768804
[image-20200801154434207]: 
[link 2]: https://blog.csdn.net/leoe_/article/details/79476279
[Link 1]: http://www.chinahtml.com/server
[img]: /images/20230208/ed3829d91eb24a009315d083c808d099.png
[img 1]: /images/20230208/0e4c01ae4f9f4839a1fb69e3d517d6f2.png
[img 2]: /images/20230208/bbdd371fdc7d4ea2b941407b4d591cd0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzUxODAzOA_size_16_color_FFFFFF_t_70 1]: /images/20230208/4b7dc9c8e6f74c5682b42503c4fb0a10.png
[link 3]: https://blog.csdn.net/mxgsgtc/article/details/12718905?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.compare&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.compare
[link 4]: https://blog.csdn.net/qq_38950316/article/details/81087809
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzUxODAzOA_size_16_color_FFFFFF_t_70 2]: /images/20230208/2bbcf49c700a458fa45cba9187d37ad6.png
[link1]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP
[link2]: https://www.ietf.org
[Link 2]: https://en.wikipedia.org/wiki/Application_Layer
[-]: https://en.wikipedia.org/wiki/Client%E2%80%93server_model
[Link 3]: http://en.wikipedia.org/wiki/Stateless_protocol
[Link 4]: https://zh.wikipedia.org/wiki/%E4%BC%A0%E8%BE%93%E5%B1%82
[RUDP]: https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol
[HTTP as an application layer protocol_ on top of TCP _transport layer_ and IP _network layer_ and below the presentation layer.]: https://mdn.mozillademos.org/files/13673/HTTP%20&%20layers.png
[protocol]: https://developer.mozilla.org/en-US/docs/Glossary/protocol
[HTTP headers]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
[Connection]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Connection
[QUIC]: https://en.wikipedia.org/wiki/QUIC
[method]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods
[GET]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Methods/GET
[POST]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Methods/POST
[OPTIONS]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Methods/OPTIONS
[HEAD]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Methods/HEAD
[HTML form]: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms
[domain]: https://developer.mozilla.org/en-US/docs/Glossary/domain
[port]: https://developer.mozilla.org/en-US/docs/Glossary/port
[status code]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
[HTTP]: https://developer.mozilla.org/zh-cn/HTTP
[section 10 of RFC 2616]: https://tools.ietf.org/html/rfc2616#section-10
[100 Continue]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/100
[101 Switching Protocol]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/101
[Upgrade]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Upgrade
[102 Processing]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/102
[WebDAV]: https://developer.mozilla.org/en-US/docs/Glossary/WebDAV
[103 Early Hints]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/103
[Link]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Link
[200 OK]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/200
[201 Created]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/201
[202 Accepted]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/202
[203 Non-Authoritative Information]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/203
[204 No Content]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/204
[205 Reset Content]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/205
[206 Partial Content]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/206
[207 Multi-Status]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/207
[208 Already Reported]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/208
[226 IM Used]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/226
[HTTP Delta encoding]: https://tools.ietf.org/html/rfc3229
[300 Multiple Choice]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/300
[301 Moved Permanently]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/301
[302 Found]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/302
[303 See Other]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/303
[304 Not Modified]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/304
[307 Temporary Redirect]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/307
[308 Permanent Redirect]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/308
[400 Bad Request]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/400
[401 Unauthorized]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/401
[403 Forbidden]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/403
[404 Not Found]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/404
[405 Method Not Allowed]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/405
[406 Not Acceptable]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/406
[407 Proxy Authentication Required]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/407
[408 Request Timeout]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/408
[409 Conflict]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/409
[410 Gone]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/410
[411 Length Required]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/411
[412 Precondition Failed]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/412
[413 Payload Too Large]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/413
[414 URI Too Long]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/414
[415 Unsupported Media Type]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/415
[416 Range Not Satisfiable]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/416
[417 Expectation Failed]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/417
[Expect]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Expect
[418 I_m a teapot]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/418
[421 Misdirected Request]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/421
[422 Unprocessable Entity]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/422
[423 Locked]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/423
[424 Failed Dependency]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/424
[425 Too Early]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/425
[426 Upgrade Required]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/426
[428 Precondition Required]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/428
[429 Too Many Requests]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/429
[431 Request Header Fields Too Large]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/431
[451 Unavailable For Legal Reasons]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/451
[500 Internal Server Error]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/500
[501 Not Implemented]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/501
[502 Bad Gateway]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/502
[503 Service Unavailable]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/503
[504 Gateway Timeout]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/504
[505 HTTP Version Not Supported]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/505
[506 Variant Also Negotiates]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/506
[507 Insufficient Storage]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/507
[508 Loop Detected]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/508
[510 Not Extended]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/510
[511 Network Authentication Required]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/511
[link1 1]: https://blog.csdn.net/xiaoming100001/article/details/81109617
[link2 1]: https://blog.csdn.net/qq_38289815/article/details/80969419?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase
[Link 5]: https://baike.baidu.com/item/%E8%B6%85%E6%96%87%E6%9C%AC
[Link 6]: https://baike.baidu.com/item/%E4%BC%A0%E8%BE%93%E5%8D%8F%E8%AE%AE
[Link 7]: https://baike.baidu.com/item/%E6%8F%A1%E6%89%8B%E5%8D%8F%E8%AE%AE
[Link 8]: https://baike.baidu.com/item/%E5%85%AC%E5%BC%80%E5%AF%86%E9%92%A5
[Link 9]: https://baike.baidu.com/item/%E5%AF%86%E9%92%A5
[Link 10]: https://baike.baidu.com/item/%E5%97%85%E6%8E%A2
[hash]: https://baike.baidu.com/item/hash%E5%87%BD%E6%95%B0
[Link 11]: https://baike.baidu.com/item/%E4%B8%BB%E6%9C%BA
[Link 12]: https://baike.baidu.com/item/%E5%8A%A0%E5%AF%86%E7%AE%97%E6%B3%95
[link 5]: https://www.cnblogs.com/liyuhui-Z/p/7844880.html
[link 6]: https://www.jianshu.com/p/d9e4c848ad10
[img 3]: /images/20230208/32a7ab21d7cf47bfa8ee086636cedfbe.png
[link 7]: https://blog.csdn.net/weixin_33912445/article/details/88018891?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.compare&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.compare
[Link 13]: https://link.juejin.im/?target=https%3A%2F%2Fwww.zhihu.com%2Fquestion%2F25912483