计算机网络

1. 网络篇

1. 公钥和私钥

公钥和私钥是通过一种算法得到的一个密钥对，公钥是秘钥对中公开的部分，私钥是非公开的部分。如果用其中一个密钥加密一段数据，必须用另一个密钥解密。比如用公钥加密数据就必须用私钥解密，如果用私钥加密也必须用公钥解密，否则解密将不会成功。

原则：公钥公开，私钥只有自己拥有。

2. 对称加密与非对称加密

对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；

​ 非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。

​ 由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

总结一下：通过非对称加密的方式把秘钥发送过去，接下来用这个秘钥一直进行对称加密。

即：第一次通信采用非对称加密，接下来的通信采用对称加密

3. HTTP的相关问题

3.1 HTTP概念

HTTP协议：超文本传输协议。是应用层协议，是基于TCP协议的，明文传输，客户端与服务器端都无法验证对方的身份；

超文本：广义上的文本，包括图片、视频、压缩包、超链接等。

3.2 HTTP的特点

1、简单、灵活：HTTP头部的各类字段组成都没有固定要求，允许开发人员自定义和补充。

2、无状态：服务器不会记录HTTP的状态，减轻了服务器的开销。 但是在完成关联性操作时不方便（如玩4399小游戏，不能换一个游戏就重新登一次账户）

解决办法：使用Cookie技术，通过在请求和响应报文中写入Cookie信息来来控制客户端的状态。

当客户端第一次请求后，服务器会下发一个装有客户信息的Cookie，后续客户端请求服务器时，带上Cookie，服务器就能识别出是谁。

3、不安全

• HTTP传输文本时采用明文传输，不加密，可以直接看见信息。
• 通信时不会验证双方身份，可能访问虚假用户
• 传输过程中的报文可能遭到无疑篡改。

3.3 HTTP的状态码

1xx

1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

2xx

2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。

「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。

「206 Partial Content」是应用于 HTTP 分块下载或断电续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

3xx

3xx 类状态码表示客户端请求的资源发送了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。

「302 Moved Permanently」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制。

4xx

4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。

「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。

「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。

「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5xx

5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。

「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。

「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。

「503 Service Unavailable」表示服务器当前很忙，暂时无法响应服务器，类似“网络服务正忙，请稍后重试”的意思。

4. HTTPS相关问题

HTTP 由于是明文传输，所以安全上存在以下三个风险：

• 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。

• 篡改风险，比如强制入垃圾广告，视觉污染，用户眼容易瞎。

• 冒充风险，比如冒充淘宝网站，用户钱容易没。

1. HTTPS概念

HTTPS协议是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。

2. HTTPS为什么安全？

1、混合加密

作用：防窃听

混合加密：即同时采用公钥和私钥加密，更安全，更高效，更不易被破解。 具体操作方法见问本文章的第一个问题。

• HTTPS采用对称加密和非对称加密结合的混合加密方式
• 在通信建立前采用非对称加密的方式交换秘钥，后续就不在使用非对称加密
• 在通信过程中全部使用对称加密的会话秘钥方式，加密明文数据。

2. 摘要算法
作用：防止数据被篡改。

摘要算法：实现数据完整性，能够为数据生成独一无二的指纹，指纹用于校验数据的完整性，解决了被篡改的风险。

过程
1、客户端发送明文前，会通过摘要算法算出明文的指纹，发送时明文和指纹一同加密，发送给服务器。

2、服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的指纹和当前指纹做比较，若相同，则说明数据是完整的。

3. 数字证书
作用：解决身份认证问题。

过程：借助第三方权威机构CA（数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构办法）中，只要证书是可信的，公钥就是可信的。

3. 采用HTTPS加密的具体流程：

假设电脑A要向电脑B发送数据

电脑A发送数据前，先通过摘要算法计算出明文的指纹，然后将明文+指纹打包成数据包，并将自己的对称加密的秘钥放入数据报， 同时向电脑B索要公钥。

电脑B将公钥发送过来后，电脑A采用非对称加密的方式，通过电脑B的公钥将自己的数据包加密（非对称加密的原理见之前的解答），加密后，发送给电脑B

电脑B收到电脑A发送过来的数据包后，发现是非对称加密的方式，于是使用自己的私钥解密， 解密后通过计算该数据包的指纹， 与数据包内指纹对比， 若指纹相同，则表示数据没有丢失。

接下来的通信，双方都将使用数据包内的秘钥以对称加密的方式通信。

4.HTTPS 是如何建立连接的？其间交互了什么？

SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。

• 双方协商生产「会话秘钥」。

• 双方采用「会话秘钥」进行加密通信。

前两步也就是 SSL/TLS 的建立过程，也就是握手阶段。

SSL/TLS 的「握手阶段」涉及四次通信，可见下图：

SSL/TLS 协议建立的详细流程：

1. ClientHello

首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。

在这一步，客户端主要向服务器发送以下信息：

（1）客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。

（2）客户端生产的随机数（Client Random），后面用于生产「会话秘钥」。

（3）客户端支持的密码套件列表，如 RSA 加密算法。

2. SeverHello

服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：

（1）确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。

（2）服务器生产的随机数（Server Random），后面用于生产「会话秘钥」。

（3）确认的密码套件列表，如 RSA 加密算法。

（4）服务器的数字证书。

3.客户端回应

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。

如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：

（1）一个随机数（pre-master key）。该随机数会被服务器公钥加密。

（2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

4. 服务器的最后回应

服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发生最后的信息：

（1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

5. HTTP与HTTPS区别

端口不同：HTTP与HTTPS使用不同的连接方式，用的端口也不一样，前者是80，后者是443；

资源消耗：和HTTP通信相比，HTTPS通信会由于加减密处理消耗更多的CPU和内存资源；

开销：HTTPS通信需要证书，而证书一般需要向认证机构购买；

6. 客户端在使用HTTPS方式与Web服务器通信时的步骤

​ （1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

（3）客户端的浏览器与Web服务器开始协商SSL/TLS连接的安全等级，也就是信息加密的等级。

（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。

（5）Web服务器利用自己的私钥解密出会话密钥。

（6）Web服务器利用会话密钥加密与客户端之间的通信。

7. 从输入URL到页面加载发生了什么

大致流程

1.DNS请求

2.HTTPs加密（如果是http请求就没有这一步）

3.TCP连接

4.发送HTTP请求

5.服务器处理请求并返回HTTP报文

6.浏览器解析渲染页面

7.连接结束

具体叙述

1.DNS概述

如果说ARP协议是用来将IP地址转换为MAC地址，则DNS协议就是将域名转换为IP地址。（IP地址面向主机，域名面向用户）。
 
DNS(Domain Name System，域名系统)，因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。

域名服务器是层级结构，依次分为根域名、顶级域名、权限域名、本地域名服务器

2.域名解析过程

1、解析域名时，浏览器会首先会依次查看自己的DNS缓存、操作系统中的DNS缓存、本地硬盘的 hosts 文件、路由器缓存，看看其中有没有缓存和这个域名对应的ip地址，如果有的话就直接使用 。

2、如果在上面的文件中没有找到对应的 IP 地址，浏览器就会发出一个 DNS请求到本地DNS服务器 。本地DNS服务器一般是你的网络接入服务器商提供，比如中国电信，中国移动。

3、于是本地DNS服务器查看自己有没有缓存对应的 IP 地址，若有则直接返回结果，否则本地DNS服务器需要向DNS根服务器进行查询。根 DNS 服务器没有记录具体的域名和 IP 地址的对应关系，而是告诉本地 DNS 服务器，你可以到域服务器上去继续查询，并返回顶级域名服务器的 IP 地址给本地DNS 服务器。

4、本地DNS服务器再请求顶级域名服务器返回二级域名服务器IP，再请求二级域名服务器返回三级域名服务器IP…直到找到对应的 IP 地址，返回给浏览器。

5、最后，本地DNS服务器不仅要把IP地址返回给用户电脑，还要把这个对应关系保存在缓存中，以备下次别的用户查询时，可以直接返回结果，加快网络访问。

注：域服务器收到请求之后，不会直接返回域名和IP地址的对应关系，而是告诉本地DNS服务器，相关域名的DNS服务器的地址。

注意：DNS负载均衡：DNS返回的IP地址并非每次都一样，DNS可以根据每台机器的负载量、该机器离用户地理位置的距离等返回一个合适机器的IP给用户。

查询ip地址有迭代查询和递归查询两种
迭代查询

递归查询

域名的级别是指一个域名由多少级组成，域名的各个级别被"."分开，总而言之，有多少个点就是几级域名。
顶级域名在开头有一个点(.com .cn .net)
一级域名就是在"com cn net"前加一级 (baidu.com)
二级域名就是在一级域名前再加一级(www.baidu.com)
二级域名及以上级别的域名，统称为子域名，不在注册域名的范畴中

3.HTTPs加密

见上一个回答

4.建立TCP连接

同上

5.HTTP请求

1 http为80，https为443.

2 请求报文：请求报文头、请求行、请求正文

3 常用方法：get、post

6.服务器进行HTTP响应

响应报文头、状态码、响应报文

7.浏览器解析渲染页面

1 接收到响应报文后，解析HTML、css、js等文件进行解析渲染首部

2 先解析HTML文件构建dom树，接下来解析CSS文件构建渲染树，使用JS引擎对JS进行解析

Web优化：对内容压缩、对一些内容缓存等。

8. TCP协议的六种标志

SYN：同步标志

置1表示请求进入同步状态，二者同步即可通信。

ACK：确认标志

置1表示确认号合法，为0表示数据段不包含确认信息，确认号被忽略。

RST：复位标志

用于复位某种原因引起出现的错误连接

URG：紧急标志

紧急指针，置1时，用来避免TCP数据流中断。

PSH：推送标志

置1时，请求的数据段在接收方得到后直接送到应用程序，不必等待缓冲区满再传送

FIN：完成标志

置1时，表示此为完成报文，用来释放连接，表示发送方已经没有数据发送了

9. IP地址分类

ABCDE五类，ABC为基本类，DE作为多播和保留使用，为特殊地址。

A类地址：以0开头

B类地址：以10开头

C类地址：以110开头

D类地址：以1110开头

E类地址：以1111开头，保留地址

10. 常见状态码

1**：请求已被接受，正在处理

2**：请求被成功处理 200ok

3**：重定向，要完成请求必须进一步处理（301 永久性转移，302：暂时性转移，304：已缓存）

4**：客户端错误，请求不合法（400，请求有语法问题；403:拒绝请求；404:客户端所访问的页面不存在）

5**：服务器错误（500:服务器内部错误；504:服务器不可用）

11. 三次握手与四次挥手

运输层总结

1.1 三次握手过程

第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN。此时客户端处于 SYN_SENT 状态。

首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。

第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。

在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。

第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。

1.2 为什么要三次握手，两次不行吗？

第一次握手：客户端发送网络包，服务端收到了。
这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。
这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手：客户端发包，服务端收到了。
这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。
若为两次握手，会出现如下情况：

若客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传请求，收到确认，建立连接。

但可能第一个丢失的报文段只是在某些网络节点长时间滞留了，延误到连接释放以后的某个时间才到达服务端。

此时服务端会误认为客户端又发出一次新请求，同意建立连接。会浪费资源。

1.3 三次握手过程中可以携带数据吗

第三次握手时可以携带数据，但是第一、二次不行。

原因：设想这样的场景：若第一次握手可以携带数据，有人要恶意攻击服务器，则他每次都可以在第一次握手中的SYN报文中放入大量数据，会让服务器花费很多时间、空间来处理报文。

也就是说：第一次握手无法放数据，保证了服务器的安全性。而第三次握手时，已经代表成功的建立了连接，从客户端携带数据到服务器也是被理解的。

1.4 SYN攻击是什么

概念：Client在短时间伪造大量不存在的ip地址，向Server不断发送SYN包，Server则回复确认包，并等待Client确认，这些包将长时间占用未连接队列，导致正常的SYN请求因为队列满被丢弃，从而引起网络拥塞甚至系统瘫痪（Dos/DDoS攻击）

如何检测：当看到大量半连接状态，且源地址IP为随机时，即可断定为一次SYN攻击（Linux中的netstat命令）。

解决办法：缩短SYN时间，过滤网关防护等。

2.1 四次挥手

为什么建立一个连接要三次握手，而终止需要四次呢？这是由TCP的半关闭造成的。即，TCP提供了连接的一段在结束它的发送后还能接收来自另一端数据的能力。

双方均可主动发起挥手

假设客户端先发起关闭请求：

第一次挥手：客户端发送一个FIN报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。

即：报文段：FIN=1，seq=u。 客户端进入FIN_WAIT1状态。

第二次挥手：服务器收到FIN后，会发送ACK报文，且把客户端序列号值+1作为ACK报文的序列号值，表示已经收到客户端的报文了，此时服务器处于CLOSE_WAIT状态。

即：报文段：ACK=1，ack=u+1，seq=v。服务器进入CLOSE_WAIT状态。客户端收到服务端的确认后，进入FIN_WAIT2状态。

第三次握手：如果服务器也想断开连接了，发送FIN报文，并且由于这是对于回应报文，因此确认标志ACK仍需置1，服务器端处于LAST_ACK状态

即：报文段：ACK=1，FIN=1，ack=u+1(仍算是对seq=u的回应)，seq=w。，服务器进入LAST_ACK状态。

第四次握手：客户端收到FIN后，发送一个ACK作为应答，此时客户端处于TIME_WAIT2状态，而服务端收到ACK报文后，就处于CLOSED状态

即：报文段：ACK=1，seq=u+1(第一次为seq=u)，ack=w+1。客户端进入TIME_WAIT状态，此时TCP还未释放掉，需要经过时间等待计时器设置的时间2msl后，客户端才进入CLOSED状态。

2.2 挥手为什么需要四次

当服务器端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”，只有等我服务端所有的报文都发送完毕， 我才能发送FIN报文。

2.3 等待2MSL的意义

MSL译为“最长报文段寿命”，是任何报文在网络上存在的最长时间，超过这个时间，报文将被丢弃。

理由一：保证客户端发送的最后一个ACK报文段能够到达服务端。

若客户端发送的最后一个ACK报文段在传输过程丢失，服务器接受不到回应，会启动超时重传机制，超时重传FIN-ACK。接下来客户端再重传一次确认，重新启动等待计时器。最后客户端和服务器都正常关闭。

假设客户端不能带2MSL，而是在发送完ACK后直接释放关闭，一旦这个ACK丢失的话，服务器就无法正常进入关闭连接状态。

理由二：防止“已失效的连接请求报文段”出现在本连接中

12.HTTP/1.1、HTTP/2、HTTP/3 演变

1.http/1.0

是一种无状态，无连接的应用层协议

• 规定浏览器和服务器保持短暂的链接。
• 浏览器每次请求都需要与服务器建立一个TCP连接，服务器处理完成以后立即断开TCP连接（无连接），服务器不跟踪也每个客户单，也不记录过去的请求（无状态）。
• 这种无状态性可以借助cookie/session机制来做身份认证和状态记录。

存在的问题

• 无法复用连接：每次发送请求，都需要进行一次TCP连接，而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率变低。
• 队头阻塞（head of line blocking）：由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送，假设前一个请求响应一直不到达，那么下一个请求就不发送，后面的请求就阻塞了。

2.http/1.1

HTTP/1.1 相比 HTTP/1.0 性能上的改进：

• 使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。

• 支持 管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

但 HTTP/1.1 还是有性能瓶颈：

• 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；

• 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；

• 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；也就是说，HTTP管道化可以让我们把先进先出队列从客户端（请求队列）迁移到服务端（响应队列）,如果，客户端同时发了两个请求分别获取html和css，假如说服务器的css资源先准备就绪，服务器也会先发送html，再发送css。 换句话来说，只有等到html响应的资源完全传输完毕后，css响应的资源才开始传输，不允许同时存在两个并行的响应。

• 没有请求优先级控制；

• 请求只能从客户端开始，服务器只能被动响应。

3.http/2.0

那 HTTP/2 相比 HTTP/1.1 性能上的改进：

1. 头部压缩

HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的分。

这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

2. 二进制格式

HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式。

头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。

这样虽然对人不友好，但是对计算机非常友好，因为计算机只懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。

3. 数据流

HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。

每个请求或回应的所有数据包，称为一个数据流（Stream）。

每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数

客户端还可以指定数据流的优先级。优先级高的请求，服务器就先响应该请求。

4. 多路复用

HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。

移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，大幅度提高了连接的利用率。

举例来说，在一个 TCP 连接里，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程非常耗时，于是就回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。

5. 服务器推送

HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。

举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会用到的 JS、CSS 文件等静态资源主动发给客户端，减少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。

4.http/3.0

HTTP/2 主要的问题在于：多个 HTTP 请求在复用一个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。

所以一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。

• HTTP/1.1 中的管道（ pipeline）传输中如果有一个请求阻塞了，那么队列后请求也统统被阻塞住了

• HTTP/2 多请求复用一个TCP连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。

这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！

UDP 发生是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞 和 HTTP/2 的一个丢包全部重传问题。

大家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

• QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响。

• TL3 升级成了最新的 1.3 版本，头部压缩算法也升级成了 QPack。

• HTTPS 要建立一个连接，要花费 6 次交互，先是建立三次握手，然后是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数。
  
  所以， QUIC 是一个在 UDP 之上的伪 TCP + TLS + HTTP/2 的多路复用的协议。

QUIC 是新协议，对于很多网络设备，根本不知道什么是 QUIC，只会当做 UDP，这样会出现新的问题。所以 HTTP/3 现在普及的进度非常的缓慢，不知道未来 UDP 是否能够逆袭 TCP。

13.OSI七层模型

详细：详细介绍OSI七层模型

2 TCP与UDP篇

核心：TCP安全但麻烦， 可试着从TCP首部讲起

1. 网络中各层协议

1. 应用层

典型设备：应用程序

协议

• FTP：文件传输协议<21>，减少或消除不同操作系统下处理文件的不兼容性
• SSH/TLS：安全外壳协议
• SMTP/POP3：用于发送/接收邮件
• HTTP：超文本传输协议<80>，面向事务的应用层协议

2. 传输层

典型设备：进程和端口

数据单元：数据段

协议

• TCP：面向连接、可靠、有序、无丢失、不重复
• UDP：最大努力交付

3. 网络层

典型设备：路由器、防火墙、多层交换机

数据单元：数据包

协议

• IP：网络之间互连的协议
• ARP：地址解析协议，实现通过IP地址得知其物理地址
• ICMP：Internet控制报文协议，在IP主机、路由器之间传递控制消息
• RIP：路由信息协议
• BGP：边界网关协议

4. 数据链路层

典型设备：网卡、网桥、交换机

数据单元：帧

协议

• ARQ：自动重传请求协议，错误纠正协议（停止等待ARQ协议和连续ARQ协议）
• 停止等待协议：CSMA/CD：总线型网络，载波监听、碰撞检测
• PPP：点对点协议
• 校验方法：循环冗余校验CRC

5. 物理层

典型设备：中继器、集线器、网线等

数据单元：比特bit

2. TCP与UDP

1. TCP首部

源端口号/目标端口号：表示数据从哪个进程来，到哪个进程去。

32位序号：由于TCP面向字节流，将大文件拆分成多个字节传输，序号的作用是为字节排序。

确认序号：告诉对方，要从第几个字节开始发数据，起到确认收到的作用。

首部长度：表示首部长度

保留位：无作用

6个标志

窗口：告诉对方本人的接收窗口有多大，你的发送窗口不得大于我的接收窗口，否则会出现大量的包被丢弃

校验和：对信息进行验证，防止信息在传送过程中丢失

紧急指针：紧急发送数据的方式

2. UDP首部

3. 特点与区别

TCP面向连接：传递数据前，有三次握手建立连接，传递数据时，有确认、窗口、重传和拥塞控制机制，数据传完后，还会通过四次握手断开连接
UDP无连接：知道对端的IP和端口号就可以发送，尽最大努力交付，无需建立连接，不可靠

TCP面向字节流：把数据看成一连串无结构的字节流
UDP面向报文：没有拥塞控制

TCP的通信：点对点
UDP通信：支持一对一、一对多、多对一、多对多通信

TCP首部开销20字节
UDP首部开销8字节。

3. TCP如何保证传输数据的可靠性

对失序数据包重排序（序号字段）：由于TCP面向字节流，因此当TCP报文段到达时，会根据序号字段对数据重排序

数据包校验（校验字段）：若数据在传输过程中出错or丢失，则直接丢弃，启动超时重传；若发送了重复数据，则丢弃重复数据

超时重传：当TCP发送一个段后，会启动一个定时器，等待目的端确认收到这个报文段，若不能及时收到一个确认，将重发这个报文段

流量控制：TCP连接的每一方都有固定大小的缓存空间，TCP接收端只允许另一端发送接收端缓冲区所能接纳的数据，可以防止较快主机使较慢主机的缓冲区溢出。

流量控制协议是：滑动窗口协议

拥塞处理

4. TCP的拥塞处理

拥塞窗口cwnd

其值取决于网络的拥塞程度，且动态变化。

维护原则：只要网络没有出现拥塞，就增大一些，出现了，就减小一些。

判断是否出现网络拥塞的依据：没有按时收到应当到达的确认报文（即发生重传）

慢开始门限ssthresh

cwnd < ssthresh：使用慢开始算法

cwnd > ssthresh：使用拥塞避免算法

cwnd = ssthresh：既可以使用慢开始算法，也可使用拥塞避免算法

拥塞处理概念

若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能会变坏，这种情况叫拥塞。

拥塞控制就是：防止过多的数据注入网络，可以使网络中的路由器或链路不至过载。

拥塞控制的方法主要有以下四种：

1 慢开始：每个传输轮次，拥塞窗口cwnd能传输的报文段都扩大一倍。当cwnd等于慢开始门限后，改用拥塞避免算法。

2 拥塞避免：让拥塞窗口缓慢增长，传输轮次，cwnd能传输的报文段数量+1。

若发生重传，则cwnd置1，ssthresh减半，并重新开始慢开始算法。

3 快重传：使发送方尽快进行重传。报文段都是按顺序传送的，若收到了失序的报文段，要发出对已收到报文段的重复确认。

发送方一旦受到三个连续的重复确认，就将相应的报文段立即上传。而不是等报文段的超时重传计时器超时在重传。

并直接执行快恢复算法。

4 快恢复：将慢开始门限ssthresh值和拥塞串钩cwnd值调整为当前窗口的一半，开始执行拥塞避免算法。

5. TCP粘包和拆包

1. 什么是TCP粘包？

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

2. TCP粘包原因

1、发送方原因：

要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。

TCP默认使用Nagle算法，Nagle算法可能造出现粘包问题。

Nagle算法主要作用：减少网络中报文段的数量。而Nagle算法主要做两件事：

• 只有上一个分组得到确认，才会发送下一个分组
• 收集多个小分组，在一个确认到来时一起发送

2、接收方原因
接收数据端的应用层没有及时读取接收缓存区中的数据，将发生粘包。

3. 什么时候需要处理粘包现象

若粘包的多组数据为同一块数据(文件)的不同部分，则无需处理。
若多个分组毫无关联，则需要处理粘包现象。

4. 如何处理粘包现象？

1、发送方
可以通过关闭Nagle算法解决，使用TCP_NODELAY选项来关闭算法
2、接收方
接收方没有办法处理粘包显现，只能交给应用层处理
3、应用层
应用层解决粘包的方法非常简单，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。

解决方法：循环处理，应用程序从接受缓存中读取分组时，读完一条数据，就应循环读取下一条数据，直到所有数据都被处理完成，但如何判断每条数据的长度呢？

格式化数据：每条数据都有固定格式，如开始符，结束符等。
这种方法简单可行，但选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。
发送长度：发送每条数据时，数据包中有专门的位置记录该数据的长度，当应用层读取数据包时，就可以根据数据包长度将每个分组进行拆包。
应用层处理粘包的方法叫拆包。

5. UDP会不会产生粘包问题？

TCP：为了保证可靠传输并减少额外开销，采用了基于流的传输，流传输不会把消息按个传输，而是无保护消息边界的。

保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息。

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

6. get与post区别

Get 方法的含义是请求从服务器获取资源，这个资源可以是静态的文本、页面、图片视频等。

比如，你打开我的文章，浏览器就会发送 GET 请求给服务器，服务器就会返回文章的所有文字及资源。

而POST 方法则是相反操作，它向 URI 指定的资源提交数据，数据就放在报文的 body 里。

比如，你在我文章底部，敲入了留言后点击「提交」（暗示你们留言），浏览器就会执行一次 POST 请求，把你的留言文字放进了报文 body 里，然后拼接好 POST 请求头，通过 TCP 协议发送给服务器。

GET 和 POST 方法都是安全和幂等的吗？

先说明下安全和幂等的概念：

• 在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。

• 所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。

那么很明显 GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。

POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。

3. 缓存篇

session、cookie与Application

Session机制采用的是服务器保持状态的方案

Cookie机制采用的是客户端保持状态的方案

1 cookie及其API

Cookie实际上是一小段文本信息，客户端请求服务器，若服务器需要记录用户状态，就是用response向客户端颁发一个cookie。

当浏览器再次请求该网站时，浏览器会把请求的网址连通该Cookie一同提交给服务器，服务器检查该Cookie，以此来辨认用户状态。

2 Session及其API

客户端请求服务器，若用服务器记录该用户状态，就获取session来保存状态。

这时，如果服务器已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用

若客户端请求不包含sessionid，则为此客户端创建一个session并生成一个与此session相关联的sessionid，并将这个sessionid在本次响应中返回给客户端保存。

保存sessionid的方式可以采用cookie机制。

3 Session与Cookie比较

实现机制：Session的实现常常依赖于Cookie。通过Cookie机制回传SessionID。

大小限制：Cookie有大小限制，并且浏览器对每个站点也有个数限制，session无大小限制，理论上只与服务器的内存大小有关。

安全性：Cookie存在安全隐患，通过拦截或本地文件找到cookie后可以进行攻击，而session由于保存在服务器端，相对更安全。

服务器资源消耗：Session保存在服务器端过一段时间才会消失，若session过多会增加服务器压力。

4 Application

即JavaWeb中的ServletContext：与一个Web应用程序相对于，为应用程序提供了一个全局状态，所有客户都可以使用该状态。

4. 攻击篇

这部分考察点很少，一般来说记住XSS就可以了

1. XSS攻击

指恶意攻击者利用网站没有对用户提交的数据进行转义处理or过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去。

使别的用户访问都会执行响应的嵌入代码，进而盗取资料、利用用户身份侵害等。如非法转账、强制发送邮件等。

主要原因：过于信任客户端提交的数据

解决办法：只要是客户端提交的数据，都应进行相应的过滤处理才能进行下一步操作。如将重要的信息设置为Http only等