文章目录
- 1.计算机网络分层模型
- 2 传输层(TCP)
- 3 应用层(HTTP和DNS)
计算机网络复习笔记
本文结合计算机网络自顶向下,中科大郑烇老师网课,b 站 up 主湖科大教书匠(讲的太好了)以及优秀的博客(CS-Notes)和公众号进行总结,从问题出发,同时不破坏计算机网络得整体结结构,对问题分类总结,方便记忆
1.计算机网络分层模型
1.1计算机分层模型⭐️⭐️⭐️❤️😭😭😭
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CKhUdZiE-1631847280012)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-04-29 11.12.07.png)]
-
五层协议
- 应用层 :为特定应用程序提供数据传输服务,例如 HTTP、DNS 等协议。应用程序之间的交互数据单位为报文。
- 传输层 :为两台主机进程提供通用数据传输服务。运输层包括两种协议:传输控制协议 TCP,提供面向连接、可靠的数据传输服务,数据单位为报文段;用户数据报协议 UDP,提供无连接、尽最大努力的数据传输服务,数据单位为用户数据报。TCP 主要提供完整性服务,UDP 主要提供及时性服务。
- 网络层 :**在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路,也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点, 确保数据及时传送。**IP协议在这一层
- 数据链路层 提供链路层协议为同一链路的主机提供数据传输服务。(交换机)
- 物理层 :考虑如何在传输介质上传输数据流,使数据链路层感觉不到不同的传输介质和传输手段的差异对它造成的影响
1.2 TCP/IP分为几层?tcp属于哪一层?http属于哪一层?http基于tcp还是udp?
分为应用层 传输层 网络层 网络接口层
传输层
应用层
TCP
1.3 网络协议有哪些?❤️😭
应用层协议:HTTP,DNS
传输层协议:TCP协议、UDP协议
网络层协议:IP协议、ICMP协议、ARP协议、RARP协议
2 传输层(TCP)
2.1 TCP 和 UDP 的区别⭐️⭐️❤️
比较项 | TCP(传输控制协议) | UDP(用户数据报协议) |
---|---|---|
是否有连接 | 有连接 | 无连接 |
传输控制情况 | 有拥塞控制,流量控制,全双工😭 | 无拥塞控制 |
面向数据类型 | 面向字节流(把字节流组织成大小不同的数据块)😭 | 面向报文(应用程序传下来的报文不合并也不拆分,只添加 UDP 首部)😭 |
是否支持多点连接 | 只支持一对一 | 支持一对多,多对多,多对一,全场景 |
应用场景 | 可靠交付,适用打开网页,确保数据不丢失 | 尽可能交付,适用于直播,聊天视频,确保实时,丢失几个数据没事 |
2.2 TCP 头部格式⭐️⭐️⭐️😭😭😭
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JkRulY2T-1631847280015)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-04-29 18.55.44.png)]
-
源端口和目的端口号:表明该报文段来自的应用进程,以及要去向哪个进程😭
-
序号:一个随机值ISN加上一个偏移量(该报文段第一个字节在整个字节流中的偏移)
-
确认号:期望收到的下一个 TCP报文段的数据载荷的第一个字节的序号,也是对之前收到的数据的确认。(如果确认号 = n,则表明序号为 n - 1的所有的数据已经正确接收,期望接收序号为 n 的数据)😭
![截屏2021-04-29 19.18.13](/Users/yazhouheilong/Library/Application%20Support/typora-user-images/截屏2021-04-29%2019.18.13.png)
- 窗口:告诉对方本方的的TCp接收缓冲区还能容纳多大的字节
- SYN(Synchronize Sequence Numbers):TCP建立时来同步序号,需要建立连接就携带
- FIN(FInish):用来释放连接,只有发送方携带 FIN
- ACK:ACK 确认号字段为1时,确认字段有效,0则无效。TCP建立连接后所有的字段都必须把 ACK 设置为1.
2.3 三次握手四次挥手⭐️⭐️⭐️⭐️⭐️⭐️⭐️
seq:seq = ack(对方的的期望下一次的序号) ack = seq + 1(对方的序列号加一)
SYN:在连接建立时用来同步序号。当 SYN=1,ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接,则响应报文中 SYN=1,ACK=1。
FIN:用来释放一个连接,当 FIN=1 时,表示此报文段的发送方的数据已发送完毕,并要求释放连接。
ACK:应答
2.3.1 三次握手细节
两个序号:SYN(发送确认码),ACK
四个状态 :同步已发送,同步已接收,关闭,建立
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HXdJSXFI-1631847280016)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-05-01 16.55.49.png)]
答题反思:状态忘记😭😭,第二次的seq是y
2.3.2 为什么不能两次握手呢
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kxuUwNQP-1631847280016)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-05-01 17.05.20.png)]
答题思路:是因为为了防止已经失效的 TCP 客户端连接请求又传送到了服务器端,造成资源浪费,然后进行上图的木描述。
2.3.3 TCP 四次挥手😭
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Vo4brQPZ-1631847280017)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-05-03 10.32.47.png)]
答题思路:只有发送方会携带 FIN,状态😭
2.3.4 TCP 为什么要四次挥手(CLOSE-WAIT)⭐️
因为 TCP 服务器端可能还有一 些报文段需要发送,所以对于客户端的请求关闭连接只能先回复,你的 FIN我收到了,但是我还有一些数据要发送你等我发送完之后,我再给你发送关闭请求。
2.3.5 简述 TIME_WAIT😭
描述:客户端收到服务器端的 FIN 请求的时候进入这个状态,此时客户端并不是直接关闭进入 CLOSE 状态,而是再保持一个2MSL(报文生存时间) 再进入 CLOSED 状态。
原因:
1. 确认服务器端能够收到客户端的确认报文,万一没有收到,就会重新发送,而此时客户端已经关闭,那么服务器端就会造成资源浪费,无法关闭😭
2.使本次连接内的所有报文段都消失,下一次的连接内不会出现这一次的报文段。
2.3.6 SYN攻击
半连接队列:服务器第一次收到客户端的 SYN 之后,就会处于 SYN_RCVD 状态,此时双方还没有完全建立其连接,服务器会把此种状态下请求连接放在一个队列里,我们把这种队列称之为半连接队列。
SYN攻击即利用TCP协议缺陷,通过发送大量的半连接请求,占用半连接队列,耗费CPU和内存资源。
优化方式:
- 缩短SYN Timeout时间
- 记录IP,若连续受到某个IP的重复SYN报文,从这个IP地址来的包会被一概丢弃。
2.3.7 TCP粘包
tcp是面向字节流的,可以简单的理解成客户端调用了两次send,服务器端一个recv就把信息都读出来了。固定发送信息长度,或在两个信息之间加入分隔符。
2.4 TCP 协议如何保证传输的可靠性⭐️
2.4.1超时重传(ARQ)
发送发没有收到 ACK 那么会进行重新发送
2.4.2确认应答号和序列号
2.4.3三次握手四次挥手
2.4.4 滑动窗口和流量控制😭⭐️⭐️
TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率,保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据
2.4.5 拥塞控制⭐️
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IVncgX0L-1631847280017)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-05-03 14.54.10.png)]
2.4.5.1慢开始和拥塞避免算法😭
-
发送的最初执行慢开始,令 cwnd = 1,发送方只能发送 1 个报文段;当收到确认后,将 cwnd 加倍,因此之后发送方能够发送的报文段数量为:2、4、8 …
注意到慢开始每个轮次都将 cwnd 加倍,这样会让 cwnd 增长速度非常快,从而使得发送方发送的速度增长速度过快,网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh,当 cwnd >= ssthresh 时,进入拥塞避免,每个轮次只将 cwnd 加 1。
如果出现了重传计时器超时😭,则令 ssthresh = cwnd / 2,注意门限值是发生拥塞的一半,然后重新执行慢开始。
-
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-K0nzsOjN-1631847280018)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-05-03 15.17.10.png)]
2.4.5.2 快重传和快恢复😭
在 TCP/IP 中,快速重传和恢复(fast retransmit and recovery,FRR)是一种拥塞控制算法,它能快速恢复丢失的数据包。没有 FRR,如果数据包丢失了,TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内,没有新的或复制的数据包被发送。有了 FRR,如果接收机接收到一个不按顺序的数据段,它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认,它会假定确认件指出的数据段丢失了,并立即重传这些丢失的数据段。例如收到三个 M2,则 M3 丢失,立即重传 M3。
在这种情况下,只是丢失个别报文段,而不是网络拥塞。因此执行快恢复,令 ssthresh = cwnd / 2 ,cwnd = ssthresh,注意到此时直接进入拥塞避免。
2.4.5.3 改进的整体算法
2.4.6 拥塞控制和流量控制的区别
流量控制:是A通过网络给B发数据,A发送太快导致B没办法接收,控制的是速率,是端到端的控制
拥塞控制:拥塞控制针对的是整个网络,防止过多的数据注入到网络中,如果我们不进行拥塞控制的话,网络的性能就会随着数据增多下降
3 应用层(HTTP和DNS)
3.1 HTTP 报文结构和状态码
3.1.1报文结构⭐️⭐️⭐️⭐️
请求报文结构:
- 第一行是包含了请求方法、URL、协议版本;
- 接下来的多行都是请求首部 Header,每个首部都有一个首部名称,以及对应的值。
- 一个空行用来分隔首部和内容主体 Body
- 最后是请求的内容主体
GET http://www.example.com/ HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cache-Control: max-age=0
Host: www.example.com
If-Modified-Since: Thu, 17 Oct 2019 07:18:26 GMT
If-None-Match: "3147526947+gzip"
Proxy-Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 xxx
param1=1¶m2=2
响应报文结构:
- 第一行包含协议版本、状态码以及描述,最常见的是 200 OK 表示请求成功了
- 接下来多行也是首部内容
- 一个空行分隔首部和内容主体
- 最后是响应的内容主体
HTTP/1.1 200 OK
Age: 529651
Cache-Control: max-age=604800
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 648
Content-Type: text/html; charset=UTF-8
Date: Mon, 02 Nov 2020 17:53:39 GMT
Etag: "3147526947+ident+gzip"
Expires: Mon, 09 Nov 2020 17:53:39 GMT
Keep-Alive: timeout=4
Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
Proxy-Connection: keep-alive
Server: ECS (sjc/16DF)
Vary: Accept-Encoding
X-Cache: HIT
<!doctype html>
<html>
<head>
<title>Example Domain</title>
// 省略...
</body>
</html>
3.1.2状态码⭐️❤️😭😭😭
状态码 | 类别 | 含义 |
---|---|---|
1XX | Informational(信息性状态码) | 接收的请求正在处理 |
2XX | Success(成功状态码) | 请求正常处理完毕 |
3XX | Redirection(重定向状态码) | 需要进行附加操作以完成请求 |
4XX | Client Error(客户端错误状态码) | 服务器无法处理请求😭 |
5XX | Server Error(服务器错误状态码) | 服务器处理请求出错😭 |
- 100 continue:目前为止很正常
- 200 OK
- 301 Moved Permanently :永久性重定向
- 302 Found :临时性重定向:改变网址后的附加的操作
- 400 Bad Request :请求报文中存在语法错误。
- 403 Forbidden :请求被拒绝。
- 404 Not Found:输入了错误的 URL
- 500 Internal Server Error :服务器正在执行请求时发生错误。
- 503 Service Unavailable :服务器暂时处于超负载或正在进行停机维护,现在无法处理请求。
3.1.3 301、302的区别
-
含义:301为永久重定向,302为临时重定向
-
效果:
-
假如当你访问 a.com时 永久重定向到了 b.com ;那么下一次访问 a.com 时浏览器会直接跳转到 b.com 不会再请求a.com
-
加入当你访问 a.com 时 临时重定向到了 b.com ; 那么下一次当你请求 a.com时浏览器还会先请求 a.com ,然后再重定向到b.com
-
3.2 GET 和 POST方法区别⭐️⭐️⭐️😭😭😭
方法比较 | GET | POST |
---|---|---|
作用 | 用于获取数据 | 用于发送数据(例如登录) |
参数 | 在 URL 上面添加,有限制(浏览器窗口) | 存储在 request body 中 |
幂等性 | 调用多次客户端收到的记录一样 | 调用多次会增加记录 |
可缓存 | 可以缓存,保存浏览记录 | 不可以缓存,不可以保存浏览记录 |
安全性 | 安全的,不会改变服务器状态 | 不安全,会改变服务器的数据状态,put,delete |
3.2.1其余方法有没有了解?
1、GET请求会向数据库发索取数据的请求,从而来获取信息,该请求就像数据库的select操作一样,只是用来查询一下数据,不会修改、增加数据,不会影响资源的内容,即该请求不会产生副作用。无论进行多少次操作,结果都是一样的。
2、与GET不同的是,PUT请求是向服务器端发送数据的,从而改变信息,该请求就像数据库的update操作一样,用来修改数据的内容,但是不会增加数据的种类等,也就是说无论进行多少次PUT操作,其结果并没有不同。
3、POST请求同PUT请求类似,都是向服务器端发送数据的,但是该请求会改变数据的种类等资源,就像数据库的insert操作一样,会创建新的内容。几乎目前所有的提交操作都是用POST请求的。由于自身不带验证机制,任何人都可以上传文件,因此存在安全性问题,一般不使用该方法。
4、DELETE请求顾名思义,就是用来删除某一个资源的,该请求就像数据库的delete操作。
3.3HTTP是不保存状态的协议,如何保存用户状态?⭐️
HTTP 是一种不保存状态,即无状态(stateless)协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢?Session 机制的存在就是为了解决这个问题,Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车,当你要添加商品到购物车的时候,系统不知道是哪个用户操作的,因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了
3.4Cookie的作用是什么?和Session有什么区别?⭐️⭐️⭐️
Cookie 和 Session 都是用来跟踪浏览器用户身份的会话方式,但是两者的应用场景不太一样
cookie:
服务器发送的响应报文包含 Set-Cookie 首部字段,客户端得到响应报文后把 Cookie 内容保存到浏览器中。客户端之后对同一个服务器发送请求时,会从浏览器中取出 Cookie 信息并通过 Cookie 请求首部字段发送给服务器。
session:
存储在服务器端,更加安全。过程是借用了 cookie 的传输机制,下面是维护登录状态的过程
- 客户进行登录,浏览器进行验证账户和密码,通过之后,信息存储再 redis 里面,然后里面有一个 session id
- 服务器返回的相响应报文内包含了这个 session id,客户端收到响应报文后将 cookie 存入浏览器
- 下一次访问时候携带上 sessionid,从session id中即可获取相应的数据
区别 | cookie | session |
---|---|---|
存在的位置 | 客户端 | 服务器端 |
安全性 | 有安全隐患(得到本地 cookie) | 相对安全 |
大小 | 本地有大小限制 | 无大小限制 |
3.5 输入一个网址发生的事情(http请求过程)⭐️⭐️⭐️😭😭😭
1.DNS解析:dns是网络层协议,基于udp的,目的是什么,解析过程是什么。
2.TCP连接:结合三次握手
3.发送HTTP请求,结合https加密
4.服务器处理请求并返回HTTP报文:服务器对浏览器请求做出响应,把对应的带有HTML文本的HTTP响应报文发送给浏览器
5.浏览器解析渲染页面
6.连接结束:浏览器释放TCP连接,该步骤即四次挥手。
第5步和第6步可以认为是同时发生的,哪一步在前没有特别的要求
3.6 Http是基于 TCP 还是 UDP 的?
基于 TCP 的,每次都需要三次握手建立连接
3.7 Http短连接和长连接❤️
http1.0默认短连接 当浏览器访问一个包含多个图片的 html 页面的时候,除了访问 html 页面资源,还会访问图片资源,此时如果使用短连接,那么每进行依次 http 通信就会建立一次连接,消耗资源
长连接只需要进行一次连接就可以保持多次 http 通信,不会永久打开,而是有一个长连接的时间
http1.1之后默认长连接,connection:close(关闭),connection:keep-alive
3.7.1 如何保持长连接?❤️
不论是服务端还是客户端,一方开启KeepAlive功能后,就会自动在规定时间内向对方发送心跳包, 而另一方在收到心跳包后就会自动回复,以告诉对方我仍然在线
3.8 http和https的区别 ⭐️⭐️❤️❤️❤️😭
区别 | http | https |
---|---|---|
端口和开头 | 80/http | 443/https |
安全性 | HTTP 协议运行在 TCP 之上,所有传输的内容都是明文,客户端和服务器端都无法验证对方的身份 | HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议,SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密,加密采用对称加密,但对称加密的密钥用服务器方的证书进行了非对称加密 |
3.9 HTTPS 加密算法由来😭😭
3.9对称加密和非对称加密⭐️⭐️
-
对称密钥加密:加密和解密使用同一密钥。
缺点:首先我们无法为每个用户都私有一个k,如果这样的化,就导致k太多,存储都是一个问题。所以只能有一个key,万一这个key被黑客获取,就会出现安全性问题
典型算法: DES、AES
-
非对称密钥:加密密钥成对出现(且根据公钥无法推知私钥,根据私钥也无法推知公钥),加密解密使用不同密钥(公钥加密需要私钥解密,私钥加密需要公钥解密),相对对称加密速度较慢
非对称加密过程:
1:客户端发送请求向服务端拿取公钥pk,拿到本地。
2:客户端使用公钥加密数据生成密文Y,发到服务器,服务端用私钥解密。
存在问题:但是仔细一想,如果客户端要得到数据呢?服务端要用sk加密,那么客户端就要用pk解密,那么问题来了,黑客也能用pk来解密获得数据,显然,非对称加密也不行。
典型算法:RSA、DSA
3.9.2 混合式加密:对称 + 非对称(num1作为对称加密公钥)
1:客户端向服务端拿公钥
2:然后客户端生成一个字符串num1,用pk对num1进行加密,得到Y传给服务端。 服务端用sk对Y解密得到num1
3:之后,用num1作为今后进行对称加密的k了。由于num1是客户端随机生成的,所以,及时中途黑客进行截取,也不知道num1是多少
但是,这种方式还不是无懈可击的,面临最大的问题就是中间人问题。黑客可能会在客户端和服务端之间进行代理,让客户端以为黑客是服务端,于是黑客就能获取到客户端的num1,黑客用充当客户端,向服务端拿到公钥,这样信息就完全泄露了,关键问题在于无法判断拿到的公钥是正确的。
3.9.3 对称加密 + 非对称加密 + CA⭐️⭐️⭐️
客户端请求的时候,请求的是license而不是pk。客户端的系统中本来就已经存有CA机构的cpk,无需再去向CA拿,以为去拿又有可能被截获,不如直接写死。用cpk对license进行解密就能拿到pk。那么,之后的黑客介入,黑客能够起到窃取数据的作用吗?答案是否定的。如果黑客介入,那么他应该是已经获取到了pk,但是,客户端之前得到的pk将num1加密后形成的Y被黑客得到后,黑客并不能解密,因为没有私钥sk,所以黑客也是无能为力
3.9.4 SSl/TLS 协议四次握手⭐️⭐️😭
客户端发出请求(ClientHello):支持的协议版本,随机数num1,以及非对称加密算法
服务器回应:确认协议版本,返回随机数2,确认加密算法,回应服务器证书
客户端回应:验证证书合法性,然后获取证书内的公钥,如果合格,那么会生成一个随机数,随机数用来进行对称加密的密钥,利用非对称加密传输之后对数据进行对称加密的密钥。发起第二个请求,发送密钥。
服务端:收到密钥进行非对称解密,然后利用解密的密钥对数据进行加密,数据就变成了密文,然后将加密的密文发送到客户端
客户端:收到发送过来的密文就可以进行解密。
3.10 DNS协议
3.10.1 DNS协议是什么
DNS协议是基于UDP的应用层协议,它的功能是根据用户输入的域名,解析出该域名对应的IP地址,从而给客户端进行访问。
3.10.2 DNS解析过程
-
浏览器⾸先看⼀下⾃⼰的缓存⾥有没有,如果没有就向操作系统的缓存要,还没有就检查本机域名解析⽂件hosts文件,如果还是没有,就会 DNS 服务器进⾏查询,查询的过程如下:
-
客户端⾸先会发出⼀个 DNS 请求,并发给本地 DNS 服务器(也就是客户端 的 TCP/IP 设置中填写的 DNS 服务器地址)。
-
本地域名服务器收到客户端的请求后,如果缓存⾥的表格能找到则它直接返回 IP 地址。如 果没有,本地 DNS 会去问它的根域名服务器
-
根 DNS 收到来⾃本地 DNS 的请求后,发现后置是 .com,说这个域名归 .com 区域管 理,我给你 .com 顶级域名服务器地址给你
-
本地 DNS 收到顶级域名服务器的地址后,发起请求问 顶级域名服务器说:“我给你的权威 DNS 服务器的地址
-
本地 DNS 于是转向问权威 DNS 服务器: server.com 的权威 DNS 服务器,它是域名解析结果的原出处。权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
-
本地 DNS 再将 IP 地址返回客户端,客户端和⽬标建⽴连接。
3.11 http版本问题😭
3.11.1 HTTP1.0和HTTP1.1区别
- 管道传输:一次性发送多个request请求。然而pipelining在接收response返回时,也必须依顺序接收,如果前一个请求遇到了阻塞,后面的请求即使已经处理完毕了,仍然需要等待阻塞的请求处理完毕。第一个请求阻塞后,后面的请求都需要等待,这也就是队头阻塞(Head of line blocking)。
- Host头处理:在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。
- 长连接:HTTP1.0默认采用短连接,每次请求都需要创建连接;而HTTP 1.1支持长连接和请求的流水线处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟
性能瓶颈依然有:头部未被压缩,而且多次发送相同的头部,造成资源浪费,另外还有刚刚说的队头阻塞
3.11.2 HTTP2.0和HTTP1.X区别⭐️
- 新的二进制格式:将报文首部加报文主体改变成为,头信息帧和数据帧,都是二进制格式,对计算机非常友好,那么收到报⽂后,⽆需再将明⽂的报⽂转 成⼆进制,⽽是直接解析⼆进制报⽂,这增加了数据传输的效率。
- 多路复用:连接共享,即每一个HTTP请求都是是用作连接共享机制的。一个请求对应一个ID,多个请求可同时在一个连接上并行执行(由于支持二进制的格式,可以无序)某个请求任务耗时严重,不会影响到其它连接的正常执行
- header压缩:HTTP1.X的header中带有大量信息且每次都要重复发送;在客户端和服务器同时维护⼀张头信息表,所有字段都会存⼊这个表,⽣成⼀个索引 号,以后就不发送同样字段了,只发送索引号,这样就提⾼速度了。