HTTP与HTTPS

谷歌玩家

已于 2022-06-27 14:48:37 修改

阅读量2.7k

点赞数 1

分类专栏：前端面试文章标签：网络

于 2022-04-14 14:29:54 首次发布

本文链接：https://blog.csdn.net/qq_43539854/article/details/124160053

版权

前端面试专栏收录该内容

55 篇文章 6 订阅

订阅专栏

这是我做的一个基于UmiJS的任务待办桌面应用，欢迎大家给我star

这是我做的一个博客管理系统，该系统在路由拦截这一块的做的非常好，欢迎大家star

HTTP

HTTP（超文本传输协议）是客户端与服务器之间交换报文的方式，默认使用80端口，属于应用层协议，它使用TCP/IP协议作为传输层协议，保障了数据传输的可靠性。

HTTP优缺点

优点：

灵活：可以传送任意数据类型。
无状态的：HTTP是无状态协议，如果后面的处理需要前面的信息，则必须重传；如果不需要，则响应速度会非常快。
无连接的：限制每次连接只处理一个请求，服务器处理完后并收到客户端响应后，才断开连接，这样可以节省传输时间。
简单：客户端发送请求时，只需要传送请求方法和路径。

缺点：

无状态的：HTTP协议不会保存用户任何信息，如果后面的处理需要前面的信息，则必须重传，那么每次要传送的数据量非常大。
没有身份认证。
不会对数据完整性进行校验。
明文传输的。

HTTP 1.0 和HTTP 1.1

HTTP1.0 是非持久化连接的，而HTTP1.1是持久化连接，多个HTTP请求可以复用一个TCP连接，不需要每次都进行建立连接，减少时延。浏览器为用同一个域名只维护一个TCP连接。
HTTP1.1 增加了HEAD、PUT的请求
HTTP1.1有更多的缓存策略，例如：Etag/if-none-match
HTTP1.0存在浪费带宽的现象，它不可以发送数据的一部分，如果想要数据的一部分，它必须将数据全部发送，而HTTP1.1支持数据的部分发送。

HTTP 1.1和HTTP 2.0

HTTP2.0的请求头也以支持二进制形式传输，HTTP1.1仅支持以文本形式传输。
HTTP2.0允许未经服务器的允许向浏览器传输一些静态资源，减少延迟。（Web Socket技术）
HTTP2.0可以同时进行多次请求和响应，HTTP规定，请求与响应只能做到一收一发，这样如果处理某个请求的操作时间很长，会导致后面的请求的不到相应，造成队头拥塞。
HTTP2.0可以压缩某些头部信息，例如：Cooike等，因为每次进行请求都要携带这些数据，而这些数据往往都是重复的。
HTTP2.0使用数据流进行传输，因为HTTP2.0不按顺序发送，每个数据包都有这个数据流ID，用于区分它是哪个数据流的。

WebSocket

WebSocket是HTML5提供的一种浏览器与服务器进行全双工通讯的网络技术，属于应用层协议，它是基于TCP传输协议的。WebSocket的出现就解决了半双工通信的弊端。服务器可以主动向客户端推送数据，客户端也可以主动向服务器推送消息。

WebSocket的原理：客户端向WebSocket服务器发送通知，带有所有接收者ID的事件，服务器会立即通知所有活跃的客户端，只有ID在接收者ID序列中的客户端才会处理这个事件。

WebSocket的特点：

支持双向通信，实时性更强
可以发送文本，也可以发送二进制数据
建立在TCP协议之上
数据格式轻量，性能开销小，通信高效
没有同源限制，客户端可以和任意服务器通信

短轮询、长轮询、SSE和WebSocket的区别

短轮询：客户端每隔一段时间就像服务器发送一次http请求，服务器收到请求后不管数据是否更新，都直接进行响应，通过客户端不断的发送请求，客户端可以收到服务器端的数据变化。这种方式简单、易于理解。缺点就是建立http请求频繁，浪费了服务器和客户端的资源。
长轮询：客户端向服务器发送请求后，服务器不会立即响应，而是判断服务器数据是否有更新，如果有更新，则进行响应；如果没有更新，则到达一定时间限制才返回。客户端 JS 响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接。长轮询和短轮询比起来，它的优点是明显减少了很多不必要的 http 请求次数，相比之下节约了资源。长轮询的缺点在于，连接挂起也会导致资源的浪费。
SSE：服务器使用流信息向客户端推送信息。严格地说，http 协议无法做到服务器主动推送信息。但是，有一种变通方法，就是服务器向客户端声明，接下来要发送的是流信息。也就是说，发送的不是一次性的数据包，而是一个数据流，会连续不断地发送过来。这时，客户端不会关闭连接，会一直等着服务器发过来的新的数据流，视频播放就是这样的例子。SSE 就是利用这种机制，使用流信息向浏览器推送信息。它基于 http 协议，目前除了 IE/Edge，其他浏览器都支持。它相对于前面两种方式来说，不需要建立过多的 http 请求，相比之下节约了资源。
WebSocket：是 HTML5 定义的一个新协议议，与传统的 http 协议不同，该协议允许由服务器主动的向客户端推送信息。使用 WebSocket 协议的缺点是在服务器端的配置比较复杂。WebSocket 是一个全双工的协议，也就是通信双方是平等的，可以相互发送消息，而 SSE 的方式是单向通信的，只能由服务器端向客户端推送信息，如果客户端需要发送信息就是属于下一个 http 请求了。

HTTP 3.0

在HTTP 2.0中多个HTTP请求会复用一个TCP，一旦发生丢包，会阻塞所有的HTTP请求，这时基于TCP传输可能出现的问题，所以HTTP 3.0把TCP换成了UDP。
UDP是不可靠的传输协议，不会管传输顺序，不管丢包，所以不会出现HTTP 1.1中的队头阻塞和HTTP 2.0中丢包全部重传的问题。

HTTP 3.0基于UDP协议实现了类似于TCP的多路复用数据流、传输可靠性等功能。HTTP 3.0在UDP的基础上增加了一层用来保障数据传输的可靠性，提供了数据包重传、拥塞控制等特性。

如何使用UDP实现可靠传输

TCP协议的缺陷

升级TCP的工作很困难
TCP建立连接的延迟
TCP存在队头阻塞问题
网络迁移需要重新建立TCP连接

1. 升级TCP工作困难

TCP协议是现在内核中实现的，应用程序只能使用不能修改，如果想升级TCP协议，那么只能升级内核，但是升级内核涉及到计算机底层，比较复杂，并且升级后还要进行大量测试，所以内核的升级都十分保守和缓慢。

2. TCP建立连接的延迟

TCP需要建立三次握手有才能进行数据传输，而如果使用了HTTPS协议还要经历TSL四次握手后才能进行TCP传输，这样就增加了传输的延迟。

3. TCP存在队头阻塞问题

HTTP 2.0多个请求实在一个TCP连接中的，当发生丢包时，整个TCP都要等待重传，那么就会阻塞该TCP连接中的所有请求。

4. 网络迁移需要重新建立TCP连接

TCP连接是通过（源IP、源端口、目标IP、目标端口）的一个四元组确定的。如果从4G网络切换到Wifi，那么IP地址就发生了变化，就意味着必须要重新建立连接。

UDP基于QUIC协议进行可靠传输

QUIC是如何实现可靠传输的？

在HTTP 3.0中，在UDP报文头部与HTTP消息之间，共有3层头部：

整体看的视角是这样的：

Packet Header：Packet Header在首次建立连接和日常传输数据时使用的Header是不同的。

Long Packet Header 用于首次建立连接。
Short Packet Header 用于日常传输数据。

QUIC也需要进行三次握手建立连接，目的是确定链接ID。

建立连接时，连接ID是由服务器根据客户端的 Source Connection ID 字段生成的，这样后续传输时，双方只需要固定住Destination Connection ID（连接 ID ）即可，从而实现连接迁移功能。所以可以看到日常传输数据的 Short Packet Header 不需要再传输 Source Connection ID 字段了。

Short Packet Header 中的 Packet Number 是每个报文独一无二的编号，它是严格递增的，也就是说就算Packet N丢失了，重传是已经不是Packet N了，还是Packet N + M。

对比TCP，TCP在重传的序号和丢包的序号是一样的，所以服务器返回的ACK也是一样的，这样的话客户端就无法判断出到底是哪一个报文的响应。在计算RTT（往返时间）时应该选择从发送原始报文开始计算，还是重传原始报文开始计算？

如果算成原始报文的响应，但实际上是重传报文的响应（上图右），会导致采样 RTT 变大；
如果算成重传报文的响应，但实际上是原始报文的响应（上图左），又很容易导致采样 RTT 过小；

RTT计算不准确的话，那么RTO（超时时间）也就不精确，因为RTO是基于RTT来计算的，RTO计算不准确可能导致重传的概率事件增大。

在QUIC中，Packet Number是严格递增的，即使是重传报文，它的Packet Number也和原始报文不同，这样就能更加精确地计算出报文的RTT。

QUIC使用的Packet Number单调递增的设计，可以让数据包不再像TCP那样必须有序确认，QUIC支持乱序确认，当报文丢后，只要新的已接收的报文确认，当前窗口就会继续移动。

待发送端超过一定时间没有收到Packet N的确认报文后，会将需要重传的数据包放到待发送的队列中，重新编号比如数据包Packet N + M后重新发送给接收端，对重传数据包的处理跟发送新的数据包类似，这样就不会因为丢包重传将当前窗口阻塞在原地，从而解决了队头阻塞的问题。

packet Number单调递增有两个好处：

可以更加精确的计算RTT，没有TCP重传的歧义
可以支持乱序确认，防止因为丢包重传将当前窗口阻塞在原地，而TCP必须是顺序确认的，丢包时会导致窗口不滑动。

**QUIC Frame Header：**一个Packet报文中可以放多个 QUIC Frame

Packet Number 是严格递增，即使重传报文的 Packet Number 也是递增的，既然重传数据包的 Packet N+M 与丢失数据包的 Packet N 编号并不一致，我们怎么确定这两个数据包的内容一样呢？

通过Stream类型的 Frame，来确认两个保温是否一致。（还有很多其它类型的Frame）

Stream ID：多个并发传输的HTTP消息，通过不同的Stream ID加以区别
Offset：类似于TCP中的Seq，保证数据传输的有序性和可靠性
Length：指明了Frame数据的长度

通过Stream ID + Offset字段信息实现数据的有序性，通过比较两个数据包的Stream ID和Stream Offset，如果都一致，就说明这两个数据包的内容一致。

QUIC通过Packet Number配合Stream ID和Offset字段信息，可以乱序确认而不影响数据包的正确组装。

QUIC如何解决TCP队头阻塞问题的

QUIC 也借鉴 HTTP/2 里的 Stream 的概念，在一条 QUIC 连接上可以并发发送多个 HTTP 请求 (Stream)。

但是 QUIC 给每一个 Stream 都分配了一个独立的滑动窗口，这样使得一个连接上的多个 Stream 之间没有依赖关系，都是相互独立的，各自控制的滑动窗口。

假如 Stream2 丢了一个 UDP 包，也只会影响 Stream2 的处理，不会影响其他 Stream，与 HTTP/2 不同，HTTP/2 只要某个流中的数据包丢失了，其他流也会因此受影响。

HTTP性能

持久连接：HTTP通过持久连接，使多个HTTP请求复用一个TCP连接，减少建立连接时的请求时延
拥塞控制：HTTP规定请求与响应必须是一收一发，所以当某个请求处理的时间过长导致后面的请求得不到处理，就会造成队头拥塞，常见的解决办法有：
1. 增加任务队列，分配多个持久连接队列，不至于使一个任务阻塞所有任务
2. 将域名分为多个二级域名，使它们指向同一个服务器，这样，可并发的持久连接就变多了
管道网络传输：在同一个TCP中，客户端可以发送多个请求，只要第一个请求发送出去了，就可以发送第二个请求，服务器会按照请求顺序返回。

常见的HTTP请求

GET：请求服务器资源
PUT：上传文件，更新数据
POST：向服务器提交实体，主要用于修改资源
DELETE：删除服务器上的对象
HEAD：获得报文头部，与GET相比不会返回请求体
TRACE：返回服务器收到的请求，用于测试或诊断
OPTIONS：询问支持的请求方法，用来跨域请求

OPTIONS请求方法及适用场景

OPTIONS方法用于客户端请求资源时，决定对该资源采取何种必要的措施，或者了解服务器的性能。主要有以下两个用途：

获取服务器支持的所有HTTP请求方法
查询访问权限。比如使用CORS跨域之前会使用OPTIONS发送一个跨域请求，以判断当前域是否允许访问指定资源

POST和PUT的区别

PUT请求是向服务器端发送数据，从而修改数据的内容，但是不会增加数据的种类等，也就是说无论进行多少次PUT操作，其结果并没有不同。（可以理解为时更新数据）
POST请求是向服务器端发送数据，该请求会改变数据的种类等资源，它会创建新的内容。（可以理解为是创建数据）

GET和POST的区别

Post 和 Get 是 HTTP 请求的两种方法，其区别如下：

应用场景：GET 请求是一个幂等的请求，一般 Get 请求用于对服务器资源不会产生影响的场景，比如说请求一个网页的资源。而 Post 不是一个幂等的请求，一般用于对服务器资源会产生影响的情景，比如注册用户这一类的操作。
是否缓存：因为两者应用场景不同，浏览器一般会对 Get 请求缓存，但很少对 Post 请求缓存。
发送的报文格式：Get 请求的报文中实体部分为空，Post 请求的报文中实体部分一般为向服务器发送的数据。
安全性：Get 请求可以将请求的参数放入 url 中向服务器发送，这样的做法相对于 Post 请求来说是不太安全的，因为请求的 url 会被保留在历史记录中。
请求长度：浏览器由于对 url 长度的限制，所以会影响 get 请求发送数据时的长度。这个限制是浏览器规定的，并不是 RFC 规定的。
参数类型：post 的参数传递支持更多的数据类型。
GET在浏览器回退时不会再次提交请求，POST在浏览器回退时，会再次提交。