面试必问【计算机网络】——Http，Https，Tcp，RAP，路由表

java面试要点总结

一 OSI与TCP/IP各层的结构与功能，都有哪些协议

OSI的七层体系结构 完整 解耦合 比较复杂。
目前在用的一般是TCP/IP五层协议
网卡在哪一层（物理层）
交换机在哪一层（链路层）交换机是一种基于MAC地址识别，能完成封装转发数据包功能的网络设备
路由器在哪一层（网络层）
网卡-交换机（寻找mac地址）-路由器

应用层

最靠近用户的一层，向应用程序提供网络通信
网络应用程序可被分为两大类：
直接网络应用程序：Browser , e-mail ,FTP , Telnet
间接网络应用程序：Word , resource manager , (viaRedirector)

掌握域名解析系统DNS

本地DNS服务器， 根据域名，查找对应的IP地址返回给解析器

HTTP协议

—超文本传输协议(Hypertext transfer protocol)。详细规定了浏览器和服务器之间互相通信的规则
Http协议运行在TCP之上，有时也承载于TLS或SSL协议层之上，就成了我们常说的HTTPS

http特点
无状态：协议对客户端没有状态存储，对事物处理没有“记忆”能力，比如访问一个网站需要反复进行登录操作
无连接：HTTP/1.1之前，由于无状态特点，每次请求需要通过TCP三次握手四次挥手，和服务器重新建立连接。多次请求同一个资源，服务器不能区别是否已经响应过，所以每次需要重新响应请求，需要耗费不必要的时间和流量。
简单快速、灵活
明文传输，没有认证机制和加密机制
http请求格式
请求行、请求头部、空行和请求数据四个部分组成。
1、请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本.
2、请求头部，服务器要使用的附加信息 key-value
3、空行，请求头部后面的空行是必须的
4、请求数据为空，也必须有空行。可以添加任意的其他数据
get、post请求示例

http响应格式
状态行、消息报头、空行和响应正文。

第一部分：状态行，由HTTP协议版本号， 状态码， 状态消息 三部分组成。
第一行为状态行，（HTTP/1.1）表明HTTP版本为1.1版本，状态码为200，状态消息为（ok）

第二部分：消息报头，用来说明客户端要使用的一些附加信息
Date:生成响应的日期和时间；Content-Type:指定了MIME类型的HTML(text/html),编码类型是ISO-8859-1
第三部分：空行，消息报头后面的空行是必须的
第四部分：响应正文，服务器返回给客户端的文本信息。
空行后面的html部分为响应正文。

HTTP状态码

HTTP请求方法
GET, POST 和 HEAD方法等

Http长连接和Keep-Alive以及Tcp的Keepalive
http是无状态无连接的，所以每次都需要重新建立连接，但是目前大部分浏览器都是用http1.1
默认开启Keep-Alive
HTTP协议简介中提到http协议是一个运行在TCP协议之上的无状态的应用层协议。它的特点是：客户端的每一次请求都要和服务端创建TCP连接，服务器响应后，断开TCP连接。下次客户端再有请求，则重新建立连接。
keep-alive机制：若开启后，在一次http请求中，服务器进行响应后，不再直接断开TCP连接，而是将TCP连接维持一段时间。在这段时间内，如果同一客户端再次向服务端发起http请求，便可以复用此TCP连接，向服务端发起请求，并重置timeout时间计数器，

http1.0中默认是关闭的，需要在http头加入”Connection: Keep-Alive”，才能启用Keep-Alive；
http 1.1中默认启用Keep-Alive，如果加入”Connection: close “才关闭。目前大部分浏览器都是用http1.1协议，也就是说默认都会发起Keep-Alive的连接请求了

开启Keep-Alive的优缺点：
优点：Keep-Alive模式更加高效，因为避免了连接建立和释放的开销。
缺点：长时间的Tcp连接容易导致系统资源无效占用，浪费系统资源。

开启了Keep-Alive，http是否就是有状态的呢？
HTTP是无状态的，但是keep-alive指的是TCP的连接，所以还是无连接无状态的，还是请求响应模式，只不过拉长了每次响应的等待时间

当用户单击一个超级链接（URL）时：
浏览器检查URL (读取浏览器的输入)
浏览器向 DNS服务器询问域名的IP地址、DNS返回对应的IP地址
浏览器和Web服务器建立TCP 连接（在端口80）三次握手
客户端组装http请求体，发送http请求
服务器接收http请求并按格式返回请求体
释放TCP连接
浏览器解释显示请求体中的html文件

三次握手
三次握手（Three-way Handshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。
第一次握手：客户端给服务端发一个 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.1 为什么需要三次握手，两次不行吗？
三次握手的目的是“为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误”
保证连接是双工的，可靠更多的是通过重传机制来保证的
假
设客户端发送了两个建立连接请求，其中一个成功了，另一个由于网络节点时延，过了一段时间才到达，服务器收到后回复客户端此时链接已成功建立。
但是这本是客户端的一个超时请求，客户端并不会继续发送数据。
但两方都会有资源开辟，白白建立连接等待使用。是浪费资源的行为。并且两方都不主动终止连接的话，会造成死锁

1.2 什么是半连接队列？
服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。

当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

1.3 ISN(Initial Sequence Number)是固定的吗？
当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器，每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它做错误的解释。

三次握手的其中一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number)，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

1.4 三次握手过程中可以携带数据吗？
第一次和第二次不可以携带数据，如果携带了数据，大量数据会浪费服务器资源
而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。
1.5 SYN攻击是什么？
服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在**短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，**Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstat 命令来检测 SYN 攻击。
缩短超时（SYN Timeout）时间
增加最大半连接数
过滤网关防护
SYN cookies技术

四次挥手
四次挥手(我要和你断开链接；好的，断吧。我也要和你断开链接；好的，断吧)：

第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。此时TCP链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。

第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

为什么要四次挥手
客户端发送第一次fin后，服务端可能还有数据没有发送完成，此时服务端只能先发送一个ack，告诉客户端收到了关闭请求，但是服务端还不能立刻关闭socket，要发送完数据，才能重新告诉客户端，并发送fin给客户端说我可以关闭了。客户端收到之后，立即回复ack，但是客户端不能立即关闭socket，要保持连接2time，为了防止最后这个关闭的消息超时服务端没有收到，还在给客户端发消息。如果2m之后服务端还是没有发消息，客户端才能关闭

只有等到我服务端所有的报文都发送完了，我才能发送FIN报文
收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的，服务端通常执行被动关闭，不会进入TIME_WAIT状态。
服务端收到客户端的fin后，可能不会立即关闭socket，只能先回复一个ack+seq。
等服务端报文都发送完了，处于close_wait状态，再给客户端发送fin

在socket编程中，任何一方执行close()操作即可产生挥手操作。

2.3 四次挥手释放连接时，等待2MSL的意义?
MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
2msl是客户端返回回复之后的等待时长
理论上，四个报文都发送完毕，就可以直接进入CLOSE状态了，但是可能网络是不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

http和https的区别
Http协议运行在TCP之上，明文传输，没有认证机制，端口80
Https基于ssl，有加密机制，有认证机制，默认端口443 http加密会消耗cpu内存资源 ，https需要向认证机构购买证书，证书要和ip绑定

https的介绍和特点
基于ssl协议，ssl运行于tcp协议，默认端口443
内容加密：采用混合加密技术，中间者无法直接查看明文内容
验证身份：通过证书认证客户端访问的是自己的服务器
保护数据完整性：防止传输的内容被中间人冒充或者篡改

什么是对称加密，以及什么是非对称加密
**对称加密：**服务端和客户端共享同一密钥，如AES加密，但是密钥可能被窃取，不够安全
**非对称加密：**密钥分为公钥和私钥，
公钥通常存放在客户端，私钥通常存放在服务器。使用公钥加密的数据只有用私钥才能解密，反过来使用私钥加密的数据也只有用公钥才能解密。
缺点是加解密的效率可能低一些
非对称加密的代表算法有：RSA

https为了保证数据传输的安全，使用的是对称加密还是非对称加密呢？
https://blog.csdn.net/guolin_blog/article/details/104546558?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522160120501619724836738890%2522%252C%2522scm%2522%253A%252220140713.130102334…%2522%257D&request_id=160120501619724836738890&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2_alltop_click~default-1-104546558.pc_first_rank_v2_rank_v28_p&utm_term=https&spm=1018.2118.3001.4187
其实是两者结合的方式
首先，http用明文传输数据，在链路中中间件可能会监听或者篡改数据。
使用非对称加密，对密钥进行了加密和解密，以此来保证密钥的安全。 然后使用对称加密，使用解密后的私钥对数据进行加密和解密
首先，如果用对称加密的方式，由浏览器生成一个密钥，那么密钥有被监听或者篡改的风险
此时需要浏览器用公钥对密钥做加密，服务器用自己的私钥解密
但是用于加密密钥的公钥可能被篡改
此时需要引入中间机构ca，给网站签发证书
ca将我们提供的公钥，域名，有效期，用自己的加密方式加密，制作成证书返回。
将证书配置在ip上，用户访问网站时，会将证书给到ca解密，获取公钥

sql注入

2 传输层（transport layer）

两个主机进程之间的通信提供通用的数据传输服务。

运输层主要使用以下两种协议：
传输控制协议TCP（Transmisson Control Protocol）–提供面向连接的，可靠的数据传输服务。
用户数据协议UDP（User Datagram Protocol）–提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）。
UDP的主要特点：
UDP是无连接的、面向报文，没有拥塞控制
TCP的主要特点：
TCP是面向连接的、可靠的，面向字节流

TCP协议如何来保证传输的可靠性
数据包校验： 数据在传输中有变化，会重传
对失序数据包重排序： 对失序的数据报进行重拍
丢弃重复数据： 对于重复数据，能够丢弃重复数据；
应答机制： 每次都会确认应答
超时重发：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
流量控制： 使用滑动窗口协议，防止接受超过流量之外的数据

TCP 流量控制

what
防止发送方发的太快，耗尽接收方的资源，从而使接收方来不及处理
原因
发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来，这时候接收方只能把处理不过来的数据存在缓存区里
如果缓存区满了发送方还在疯狂着发送数据，接收方只能把收到的数据包丢掉，大量的丢包会极大着浪费网络资源

接收方发送确定报文，同时告诉发送方自己的缓存区还剩余多少是空闲的， 也就是窗口！！
发送方收到之后， 调整窗口也就是发送数据量。如果收到窗口是0，就停止发送数据

TCP拥塞控制

slow start: 慢启动
加增乘减
拥塞避免后缓慢增加窗口大小，增加一个MSS大小
出现拥塞时，将窗口乘0.5以减小

为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下：

当cwnd时，使用慢启动算法。也就是乘法算法
当cwnd>ssthresh时，改用拥塞避免算法。也就是加法算法
当cwnd=ssthresh时，慢开始与拥塞避免算法任意。
当出现拥塞的时候就把心的门限值设为此时窗口大小的一般，窗口大小设置为1，再重新执行上面的步骤。

当收到连续三个重传的时候这就需要快重传和快恢复了，当收到连续三个重传这个时候发送方就要重传自己的信息，然后门限减半但是这个时候并不是网络阻塞，窗口只会减半执行拥塞避免算法。

三、流量控制和拥塞控制的区别

1.相同点
（1）现象都是丢包；
（2）实现机制都是让发送方发的慢一点，发的少一点

2.不同点
（1）丢包位置不同
流量控制丢包位置是在接收端上
拥塞控制丢包位置是在路由器上
（2）作用的对象不同
流量控制的对象是接收方，怕发送方发的太快，使得接收方来不及处理
拥塞控制的对象是网络，怕发送发发的太快，造成网络拥塞，使得网络来不及处理
拥塞控制
拥塞控制通常表示的是一个全局性的过程，它会涉及到网络中所有的主机、
所有的路由器和降低网络传输性能的所有因素
流量控制
流量控制发生在发送端和接收端之间，只是点到点之间的控制

3、网络层

网络层为数据传输网络中寻找路由，网络层使用IP协议ARP
网络子网寻址
通过查找路由表， 根据子网掩码计算，寻找数据包要发送的下一跳（网关）

路由表

Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.10.0 * 255.255.255.0 U 0 0 0 eth0
192.168.56.0 * 255.255.255.0 U 0 0 0 eth1
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 192.168.10.1 0.0.0.0 UG 0 0 0 eth0
我们在配置好一个网络接口的时候，一个路由就被直接创建好了。当然我们也可以手动添加路由。用route add命令就可以了。

Destination： 是目的网络地址，
Gateway： 是下一跳地址/网关，
Genmask ： 是子网掩码，指定了目的地址的子网号。
目的地址是192.168.56.3，跟第一行的子网掩码做与运算得到192.168.56.0与第一行的目的网络地址不符，再跟第二行的子网掩码做与运算得到192.168.56.0，正是第二行的目的网络地址，因此从eth1接口发送出去，由于192.168.56.0/24正是与eth1接口直接相连的网络，因此可以直接发到目的主机，不需要经路由器转发。
如果要发送的数据包的目的地址是202.10.1.2，跟前三行路由表条目都不匹配，那么就要按缺省路由条目，从eth0接口发出去，首先发往192.168.10.1路由器，再让路由器根据它的路由表决定下一跳地址。

IP地址与物理地址

物理地址是数据链路层和物理层使用的地址，IP地址是网络层和以上各层使用的地址，是一种逻辑地址，其中ARP协议用于IP地址与物理地址的对应。

ARP协议

网络层的ARP协议完成了IP地址与物理地址的映射。
　　1、 首先检查自己ARP缓存列表是否有对应MAC地址
　　2、如果没有，广播一个查询mac地址的请求包。如果主机的ip和请求包中的ip相同，将mac地址和ip地址添加到自己的arp列表中 ，并返会自己的mac地址包

4、数据链路层（data link layer）
数据链路层通常简称为链路层。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。在两个相邻节点之间传送数据时，数据链路层将网络层交下来的IP数据报组装程帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。

5 物理层（physical layer）
在物理层上所传送的数据单位是比特。
物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。

socket
成对出现，一对套接字：
Socket ={(IP地址1:PORT端口号)，(IP地址2:PORT端口号)}
socket 是一个四元组 ip:端口+ip:端口 保证唯一的连接

websocket

什么是websocket

WebSocket是在HTML5基础上单个TCP连接上进行全双工通讯的协议，只要浏览器和服务器进行一次握手，就可以建立一条快速通道，两者就可以实现数据互传了。说白了，就是打破了传统的http协议的无状态传输（只能浏览器请求，服务端响应），websocket全双工通讯，就是浏览器和服务器进行一次握手，浏览器可以随时给服务器发送信息，服务器也可以随时主动发送信息给浏览器了。

环境的搭建

 <!-- springboot websocket -->
 <dependency>
     <groupId>javax</groupId>
     <artifactId>javaee-api</artifactId>
     <version>7.0</version>
     <scope>provided</scope>
 </dependency>
 <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-websocket</artifactId>
     <scope>provided</scope>
 </dependency>
 <dependency>
     <groupId>javax.servlet</groupId>
     <artifactId>javax.servlet-api</artifactId>
     <version>3.1-b07</version>
 </dependency>

websocket配置类

@Configuration
public class WebSocketStompConfig{
    
    
    @Bean
    public ServerEndpointExporter serverEndpointExporter()
    {
    
    
        return new ServerEndpointExporter();
    }
}

websocket 跟 socket 的区别
Socket 其实并不是一个协议，是应用层与 TCP/IP 协议族通信的中间软件抽象层，它是一组接口。当两台主机通信时，让 Socket 去组织数据，以符合指定的协议。TCP 连接则更依靠于底层的 IP 协议，IP 协议的连接则依赖于链路层等更低层次。
WebSocket 则是一个典型的应用层协议。
总的来说：Socket 是传输控制层协议，WebSocket 是应用层协议

Cookie 与 Session

cookie和session是用于跟踪会话
cookie 由于http是无状态的，服务端无法知道用户是否为上一用户。如果服务器需要记录用户状态，就给浏览器颁发状态数据列表，让浏览器存起来，下次用户请求能够记录该状态

当用户第一次通过浏览器使用用户名和密码访问服务器时，服务器会验证用户数据，验证成功后在服务器端写入session数据，向客户端浏览器返回sessionid，浏览器将sessionid保存在cookie中，当用户再次访问服务器时，会携带sessionid，服务器会拿着sessionid从数据库获取session数据，然后进行用户信息查询，查询到，就会将查询到的用户信息返回，从而实现状态保持。

Session保存在服务器端（tomcat中）。为了获得更高的存取速度，服务器一般把Session放在内存里。每个用户都会有一个独立的Session。
Session在用户第一次访问服务器的时候自动创建。
Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。
为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。
1、服务器压力增大
3、扩展性不强
如果将来搭建了多个服务器，虽然每个服务器都执行的是同样的业务逻辑，但是session数据是保存在内存中的（不是共享的），
session只能存在tomcat，需要借助redis等中间件实现分布式

Token
①认证成功后，会对当前用户数据进行加密，生成一个加密字符串token，返还给客户端（服务器端并不进行保存）
②浏览器会将接收到的token值存储在Local Storage中，（通过js代码写入Local Storage，通过js获取，并不会像cookie一样自动携带）
③再次访问时服务器端对token值的处理：服务器对浏览器传来的token值进行解密，解密完成后进行用户数据的查询，如果查询成功，则通过认证，实现状态保持，所以，即时有了多台服务器，服务器也只是做了token的解密和用户数据的查询，它不需要在服务端去保留用户的认证信息或者会话信息，

nio，多路复用-tomcat redis kafka nginx。。
nginx
正向代理反向代理
netty epoll

HTTP1.1在HTTP1.0基础上的改进

1. 长连接
   HTTP 1.0需要使用keep-alive参数来建立一个长连接，而HTTP1.1默认支持长连接
   长连接的好处：一个网页上可能有多个资源对象，长连接可以通过一个连接传输网页上的所有对象，而短连接每次连接只能传输一个对象，也就是一个网页的内容需要传输多次

2. 缓存
   HTTP1.0缓存的资源对象到了一定时间之后会失效，不能再次使用；而HTTP1.1缓存的资源对象失效后还能与源服务器进行重新激活。

3. 带宽使用
   HTTP/1.0一次只能请求一整个资源对象，而HTTP/1.1可以请求一个资源对象的一部分，因此在不需要得到整个资源对象时，可节约带宽，而且支持断点续传

4. Host域
   由于一台物理服务器上可以存在多个虚拟主机，并且它们共享一个IP地址，因此HTTP1.1在HTTP1.0的基础上加了改进，加了一个Host域，用于指定共享同一个IP地址中的某一台主机，而HTTP1.0则默认一个IP地址只能属于一台主机，没有Host域

HTTP2.0在HTTP1.1基础上的改进

1、二进制帧 增加请求的效率，吞吐量
HTTP 2.0 把传输的消息分割成二进制帧
消息头会被封装到Headers帧，
消息体则封装到Data帧里面。
一个消息中有多个二进制帧，帧可以乱序发送，再由消息头的信息组装成正序

1. 多路复用
   HTTP2.0同一个连接可以并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级，这意味着减少了建立连接所需要的开销

2. 数据压缩
   HTTP的请求和响应包括三个部分，即状态行，头部信息，消息主体。HTTP1.1只对消息主体进行压缩，而HTTP2.0对状态行，头部信息，消息主体都进行压缩

3. 服务器推送
   在使用HTTP1.1时，客户端请求什么资源，服务器才给什么；而HTTP2.0服务器会自动把客户端一定需要的资源传输给客户端，比如一些必要的附加资源等等