承接前面第一章的笔记:【计算机网络】八股文 | 第一章
PS :下面部分图来源于之前看的博客及视频,之前做笔记没有记录来源,如果知道可以留,我把链接放上。
推荐博客:
从HTTP协议角度上来看,POST 和 PUT 都是用于提交数据给服务器常用的请求方法,两者主要区别在于它们的作用和提交数据的方式。
HTTP1.0(第一个正式版本,短连接,连接无法复用….)
HTTP第一个正式版本,HTTP/1.0中浏览器与服务器只保持短暂的连接,连接无法复用,不支持缓存。也就是说每个TCP连接只能发送一个请求。每次请求和响应完毕后都会销毁 TCP 连接,同时规定前一个响应完成后才能发送下一个请求。这样可能导致队头阻塞的问题。
HTTP1.1(引入长连接,管道机制和Host字段, 支持虚拟机,缓存,支持跨域请求和流水线工作….,新增请求方法,如PUT,HEAD等)
相较于HTTP1.0,HTTP1.1主要的改进是引入了长连接和管道机制(pipelining),并且支持流水线,支持缓存和跨域请求。所谓长连接即TCP连接默认不关闭,可以被多个请求复用。此外,HTTP1.1还可以支持虚拟机,但HTTP1版本都不压缩首部字段,也不支持资源优先级设置,这导致HTTP1版本中的流量和利用率浪费。同时,HTTP1.1并没有解决多路复用的问题。
HTTP2.0(引入二进制分帧,多路复用,头部压缩,服务器推送….)
相较于HTTP1.x版本的文本(字符串)传送, HTTP2.0 采用二进制传送。客户端和服务器传输数据时把数据分成帧,帧组成了数据流,流具有流 ID 标识和优先级,通过优先级以及流依赖能够一定程度上解决关键请求被阻塞的问题。
基于二进制分帧,HTTP2.0实现了多路复用。即在一个TCP连接里,客户端和浏览器都可以同时发送多个请求或回应,而且不用按照顺序一一对应。
此外,HTTP2.0采用了头部压缩算法(HPACK)和服务器推送。HTTP2.0通过gzip 和 compress 压缩头部,大大减少了流量浪费。HTTP/2 允许服务器未经请求,主动向客户端发送静态资源,这样可以相对减少一些延迟时间。
HTTP3.0(引入安全传输协议TLS/SSL,UDP协议,新的头部压缩算法….)
HTTP/3是基于QUIC协议发展起来的,它完全抛弃了 TCP 协议,在底层使用UDP协议进行数据传输,上层仍然使用 HTTP/2.0。所以,HTTP3.0也被称之为基于UDP的安全可靠的HTTP2.0协议。在 UDP与HTTP2.0之间存在一个 QUIC 层,在该层建立连接过程中会完成TLS加密握手。使用 QPACK 进行头部压缩,因为 在 HTTP/2 中的 HPACK 要求传输过程有序,这会导致队头阻塞,而 QPACK 不存在这个问题。
虽然 HTTP2.0进行了大量的优化,但它无法摆脱 TCP 协议本身的问题,比如建立连接时间长、对头阻塞问题等等。为了保证传输的可靠性,HTTP3.0 使用了 QUIC 协议。HTTP3.0基于 UDP,又取了 TCP 中的精华,实现了即快又可靠的协议。
HTTP 3.0 是 Web 协议的一种新的最终协议,与前一个HTTP协议版本HTTP2.0相比,HTTP3.0摒弃以TCP协议中作为传输层通信,而在底层中采用UDP协议进行数据传输,具有快速握手的优点,在其上层仍然可以看出采用HTTP2.0协议。因此,HTTP3.0综合了UDP和TCP的优势,可以看为是基于UDP的安全可靠的HTTP2.0协议。同时,在UDP和HTTP2.0之间存在一个QUIC层,该层集成了安全加密的功能,如TLS和SSL,可以实现可靠安全的传输。同时QUIC具有多路数据流的优点,可以实现多路复用,解决了TCP队头阻塞的问题。此外,HTTP3.0采用新的头部压缩算法,也可以避免队头阻塞的问题。
队头阻塞是指在网络通信过程中,由于队首的数据包发送接收或处理存在较大时延,而队列中后面的数据包也需要跟着一起等待,结果导致其他请求承担不应该有的时间成本(这里是指不能及时接收到数据,而不是不能接收数据
),造成一种“队头阻塞”的现象。队头阻塞一般发生在HTTP层和TCP层,因此可以分为两种类型,即HTTP队头阻塞和TCP队头阻塞。两者虽然不相同,但存在一定联系,毕竟HTTP 是建立在 TCP 协议之上的应用层协议。队头阻塞与短连接/长连接无关,而是由HTTP基本的”请求-应答“模式所导致的
TCP队头阻塞
TCP采用了“顺序控制”和“重发控制”机制,另外还使用“流量控制”和“拥塞控制”来提高网络利用率。这里的“顺序控制”指的是最终顺序是按序排列的,也就是说每当有一个或几个Packet丢失的时候,会等待它到达后合并,然后再向上交付。因此,很容易可以理解,当一个流的第一个数据包丢失了,那么即使后面的数据包都到达了,后面的这些数据包也不能被处理,而是要等第一个数据包到了之后才能被上层接收处理,那么这个时候不止是第一个数据包需要额外等待一个或多个RTT,后面的第二个Packet、第三个Packet…都需要同样多等待那么多时间才能处理,但实际上他们是按时到达了的,这也就是所谓的TCP队头阻塞。
TCP 的阻塞问题是因为传输阶段可能会丢包
,TCP是一个按序传输的通道,一旦丢包就会等待重新发包,阻塞后续内容传输
HTTP队头阻塞
对于每一个HTTP请求,会被放入一个任务队列中串行执行,一旦队首任务请求太慢时,就会阻塞后面的请求处理。
HTTP1.x有非管道化和管道化,两种方式。
在HTTP3之前,HTTP协议都是基于TCP协议进行通信的,而基于TCP协议会引起队头堵塞
等问题。队头堵塞
问题可能存在于HTTP层和TCP层,在HTTP1.x时两个层次都存在该问题。HTTP2.0协议的多路复用机制解决了HTTP层的队头阻塞问题,但是在TCP层仍然存在队头阻塞问题。虽然TCP协议是面向连接的可靠传输,但TCP协议建立接连时间(三次握手时间)相对较长,通信速度相对缓慢,而且基于TCP协议栈是Linux系统内部的核心部分,修改和升级成本比较大,开发的协议和设备较多,需要考虑的兼容也比较多。因此,谷歌选择UDP(无连接,速度快,耗时第等优点)来改造升级HTTP,但由于UDP本身不可靠,又不能直接用,所以谷歌基于UDP,添加了具备TCP可靠安全的属性,成为新的协议QUIC。
HTTP/3
抛弃 TCP
后,基于 UDP
实现的可靠传输 QUIC
协议,带来这四点好处:
前提知识:
HTTP多路复用指在HTTP协议中,通过将多个请求和响应同时放在一个 TCP 连接中,从而提高网站的性能和吞吐量。它可以在不增加 TCP 连接数的情况下,增加网站的处理能力,同时减少网络延迟和带宽浪费。多路复用,就是在一个 TCP 连接中可以存在多条流。换句话说,也就是可以发送多个请求,对端可以通过帧中的标识知道属于哪个请求。
回答:
根据HTTP/1.1 协议的定义,TTP1.1 协议是基于请求 - 响应模型的,每个请求和响应都是通过独立的 TCP 连接传输的。这种独立性使得 HTTP1.1 协议无法实现多路复用,因为每个请求和响应都需要独立的 TCP 连接。
同时,HTTP1.1采用文本进行传输,没有流的概念。文本传输是一种非实时的数据传输模式,也就是说无法保证连接的实时性,数据到达的顺序,若文本传输采用多路复用则在接收端无法区分多个响应分别对应的请求,所以无法将多个响应的结果重新进行组装,也就实现不了多路复用。
客户端请求服务器时,通过请求行告诉服务器使用的协议是 http1.1,同时在请求头中附带connection:keep-alive(为保持兼容),告诉服务器这是一个长连接,后续请求可以重复使用这一次的 TCP 连接。
这样做的好处是减少了三次握手和四次挥手的次数,一定程度上提升了网络利用率。但由于 http1.1 不支持多路复用,响应顺序必须按照请求顺序抵达客户端,不能真正实现并行传输,因此在 http2.0 出现之前,实际项目中往往把静态资源,比如图片,分发到不同域名下的资源服务器,以便实现真正的并行传输。
首先,HTTP多路复用是指一个TCP连接中存在多个请求和响应。所以,实现多路复用其实就是使一个TCP连接可以同时发送多个请求并可识别对应请求而做出响应。根据这个原理,可以采用三种策略。
第一个是采用异步处理策略,使服务器在在等待客户端请求时,可以同时处理多个请求,比如非阻塞IO模型,管道模式,事件驱动,轮询复用。
第二是采用多线程/进程来处理,使HTTP服务器同时处理多个请求,比如线程池。
第三则是利用带标识的优化及缓存等技术来实现,比如请求分片、应答分片和HTTP 缓存 。
回答一
在 HTTP 多路复用中,通常使用非阻塞 IO 模型和事件驱动模型来实现多路复用。非阻塞 IO 模型可以在 TCP 连接上并发发送和接收数据,而事件驱动模型可以实时处理 HTTP 请求和响应。
回答二
HTTP 多路复用可以通过以下两种方式实现:
回答三
HTTP2和HTTP3的头部压缩算法都是用来减少所要传输的数据量,可以提高网络的传输效率,提高网页的加载速度和用户体验。其中HTTP2中采用HPACK做为头部压缩算法,而HTTP3采用QPACK算法。
HPACK算法是一种用于数据包缓存和传输优化的算法,它基于贪心策略来缓存和传输数据包,从而提高网络传输效率。HPACK 算法会计算出每个数据包的哈希值、已接收标记和优先级标记,以优化数据包的缓存和传输。
HPACK算法采用哈夫曼编码来压缩整数和字符串,可以达到50%~90%的高压缩率。HTTP2会在客户端和服务器两端建立“字典”,用索引号表示重复的字符串。
具体来说:
QPACK算法使用哈希表技术来删除数据中的重复字符,从而提高压缩效率和压缩比。QPACK 算法通常被应用于数据压缩和文件压缩领域。
其核心思想是使用一个哈希表来记录数据中出现的字符,并将哈希值作为索引来访问哈希表,以查找重复的字符。如果哈希表中已经存在该字符,则直接将该字符对应的数据压缩成一个独立的压缩块;如果哈希表中不存在该字符,则将该字符对应的数据添加到压缩块中,并返回该压缩块的唯一标识符。
区别:
从实现方式来看,QPACK 算法是一种数据压缩算法,它通过对数据进行哈希表压缩来减少数据存储空间和传输带宽。而 HPACK 算法是一种用于优化数据包传输和缓存的算法,它通过贪心策略来缓存数据包并计算出每个数据包的优先级,以确保数据包可以被更快地传输和缓存。
HTTP是一种以保证客户端与服务端通信为目的的超文本传输协议,而HTTPS是以通信安全为设计目标的安全超文本传输协议,虽然两者都是用于 Web 浏览器和 服务器之间的通信协议。但两者有很大的区别,尤其是在安全和隐私保护能力上。
总的来说,HTTPS实际上可以看成HTTP协议的安全版本,HTTPS=HTTP+加密+认证+完整性保护。
HTTPS表示超文本传输安全协议,是以为通信安全为设计目标,采用SSL/TSL协议来加密HTTP请求和响应内容的安全通信传输协议。HTTPS=HTTP+加密+认证+完整性保护
HTTPS主要目的是提供对网站服务器的身份认证,保护交换数据的隐私安全与完整性。这使得 HTTPS 协议成为访问敏感资源时的首选协议。
HTTP协议采用明文传输信息,存在信息窃听、信息篡改和信息劫持的风险,而协议TLS/SSL具有身份验证、信息加密和完整性校验的功能,可以避免此类问题发生。
HTTPS 的工作过程可以概括为以下几个步骤:
密钥:是在明文转换为密文或将密文转换为明文的算法中输入的参数
密钥是一种参数,它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥,分别应用在对称加密和非对称加密上。
对称加密(私钥加密):指通信双方使用相同的密钥进行数据的加密和解密
对称加密又叫做私钥加密,即信息的发送方和接收方使用同一个密钥去加密和解密数据。对称加密的特点是算法公开、加密和解密速度快,适合于对大数据量进行加密
,常见的对称加密算法有 DES、3DES、TDEA、Blowfish、RC5 和 IDEA。
非对称加密(公钥加密):指通信双方使用不同的密钥进行加密和解密,其中加密使用公钥,解密使用私钥
非对称加密也叫做公钥加密。非对称加密与对称加密相比,其安全性更好
。对称加密的通信双方使用相同的密钥,如果一方的密钥遭泄露,那么整个通信就会被破解。而非对称加密使用一对密钥,即公钥和私钥,且二者成对出现。私钥被自己保存,不能对外泄露。公钥指的是公共的密钥,任何人都可以获得该密钥。用公钥或私钥中的任何一个进行加密,用另一个进行解密。
摘要: 又称哈希/散列算法,即把摘要算法又称哈希/散列算法。它通过一个函数,把任意长度的数据转换为一个长度固定的数据串(通常用 16 进制的字符串表示)。算法不可逆。
对称加密和非对称加密都是HTTPS中常见的加密方式。
对称加密是指加密和解密使用相同的密钥,即对称密钥
非对称加密是指加密和解密使用不同的密钥,即非对称密钥——公钥和私钥。
数字证书是一种用于验证数字信息真实性和完整性的证书。它通常由一个第三方机构颁发,用于验证客户端与服务器之间通信的密钥、证书持有者的身份以及数据完整性。
数字签名是一种用于保证数字信息真实性和完整性的算法。它通过将数据与签名者的数字私钥进行数字签名,来确保数据在传输过程中没有被篡改或伪造,同时验证者可以通过计算签名值来验证签名的真实性。
数字签名通常使用哈希算法和私钥加密技术来实现。数字签名可以将原始数据转化为哈希值,并将哈希值作为签名附加到原始数据上。验证者接收到数据后,可以使用签名者的私钥对哈希值进行计算,并将其与接收到的哈希值进行比较。如果计算结果相同,则可以确定数据没有被篡改或伪造。(就是先用CA自带的Hash算法来计算出证书内容的一个摘要,然后使用CA私钥进行加密,组成数字签名。)
两者都是用于保证传输安全的协议,介于TCP和HTTP之间的一层安全协议,不影响原有的TCP协议和HTTP协议,TLS 是 SSL 的升级版。他们的功能实现和基本流程一致。
两者功能实现主要依赖三类基本算法:散列函数hash、对称加密、非对称加密。这三类算法的作用如下:
基本流程:
HTTPS 采用混合的加密机制,就是发送方用非对称加密的公钥对对称加密的密钥进行加密,然后发送出去,之后,接收方使用私钥进行解密得到对称加密中的密钥,最后双方使用对称密钥进行通信。因此,HTTPS其实就是用非对称密钥保证密钥传输过程的安全性,用对称密钥保证通信过程的效率,结合了对称密钥和非对密钥的优点。
确保传输安全过程(其实就是rsa原理):
1. Client给出协议版本号、一个客户端生成的随机数(Client random),以及客户端支持的加密方法。
2. Server确认双方使用的加密方法,并给出数字证书、以及一个服务器生成的随机数(Server random)。
3. Client确认数字证书有效,然后生成呀一个新的随机数(Premaster secret),并使用数字证书中的公钥,加密这个随机数,发给Server。
4. Server使用自己的私钥,获取Client发来的随机数(Premaster secret)。
5. Client和Server根据约定的加密方法,使用前面的三个随机数,生成”对话密钥”(session key),用来加密接下来的整个对话过程。
💡 扩展
虽然HTTPS的混合加密机制兼顾了安全性和通信效率,但是在保证安全过程中第一步发送方获取的公开密钥可能被篡改(也就是中间人问题)。这是可以通过数字证书来解决。但是中间人篡改了证书是,则需要数字签名来保证安全性了。
摘要是指对请求或响应的内容进行计算的一种算法,以便在传输过程中验证数据是否被篡改或伪造。
数字签名技术主要包括两个组成部分:数字证书和数字签名。数字证书是由证书颁发机构 (CA) 颁发的,用于验证数字签名者的身份和数字签名的有效性。数字证书通常包含数字签名者的有效公钥、数字签名日期、数字签名算法等信息。数字签名则是数字证书中的数字签名部分,用于对数据进行数字签名,确保数据的完整性和真实性。
也就是 TSL/SSL 身份验证的过程
下一章笔记的链接:
【计算机网络】八股文 | 第三章
笔记链接:【计算机网络】八股文 | 第三章
主要知识点:主要包括的知识有HHTP的劫持与攻击,DNS与XSS劫持以及相关的定义与方式,HTTP的两种连接法师,Keep-alive的理解与作用,HHTP缓存的相关知识点等知识要点。