HTTP

约 7858 字大约 26 分钟

2021-03-23

介绍一下网络协议

其实前端最主要用到的网络协议主要有TCP，UDP，HTTP，FTP， IP ，ICMP，IGMP， ARP，RARP等协议。我们可以看看如下图（摘自网页，主要是为了描述）：

分层对应的协议

传输层中，主要有TCP/UDP协议；
应用层中，主要有HTTP，FTP协议；
网络层中，主要有IP，ICMP，IGMP协议；
网络接口层中，主要有 ARP，RARP协议；

Http1.1、Http2、Https的区别

Http1.0协议缺陷：

无法复用链接，完成即断开。浏览器每次请求都会对服务器建立一个TCP连接(TCP的成本很高因为每次建立都需要对服务器三次握手)，服务器请求后断开TCP，浏览器也不会记录过往的每次请求
head of line blocking：线头阻塞，导致请求之间互相影响

解决方式：在请求的头信息中添加非标准的Connection字段并设定值为keep-alive

Http1.1：

相对于http1.0的改进:

引入长连接(默认keep-alive)：即TCP默认不关闭，不用声明keep-alive，复用，对于同一个域名，大多数浏览器允许同时建立6个连接。

timeout：决定当前TCP的最长保持连接时间，单位为s，超过设置的时间后断开连接
max：决定了当前连接最多的可复用次数

http管线化：同一个TCP连接中，客户端可以同时发送多个请求，不用一个个等待响应，如图：

虽然说客户端一次性能发送所有的请求，但是在服务端接收到的请求还是一一进行处理的，如果当服务器端返回的其中一个相应阻塞后，接下来的响应也会被阻塞。

分块传输编码：在长连接中，无法继续使用之前的方法来判断数据是否完全发送完毕，但是我们可以根据 Content-Length 的长度是否为 0 来判断数据是否传输完毕，请求传输的内容与长度必须保持一致，否则内容将会被截断。
由于 Content-Length 存在的弊端，我们可以使用 Transfer-Encoding 配合 Content-Encoding 来告诉浏览器传输的结果， Transfer-Encoding 的常用值为 chunked ，而 Content-Encoding 的作用是告知浏览器采用何种编码（压缩），通常使用的是 gzip 。对资源进行压缩后，再对内容进行分块传输。当最后一个分块长度为0时，则代表数据传输完成。

新增请求方式：

PUT：请求服务器存储一个资源
DELETE：请求服务器删除标识的资源
OPTIONS：请求查询服务器的性能，或者查询与资源相关的选项或需求
CONNECT：保留请求以供将来使用
TRACK：请求服务器回送收到的请求信息，主要用于测试或者诊断。

断点续传：客户端记录下当前的下载进度，并在需要续传时通知服务器本次需要下载的内容片段

新增缓存机制：

强缓存
- Cache-Control: 常用三个字段：
  - no-store：不缓存；
  - no-cache：不使用本地缓存。需要使用缓存协商，来验证是否过期；
  - max-age：相对过期时间，单位为秒(s)，告知服务器资源在多少以内是有效的，无需向服务器请求
  no-store 和 no-cache 的区别？
  将 Cache-Control 设置为 no-cache 后，那么服务器将去验证 Last-Modeified 、 ETag 等字段，而 no-store 的作用则是不进行资源的缓存.
- Expires: 该字段表示的是，设定的时间为缓存的有效时间，当发生请求时，浏览器将会把 Expires 的值与本地时间进行对比，如果本地时间小于设置的时间，则读取缓存。
  因为对比的是本地时间，所以也存在着弊端：当本地时间与服务端时间不一致时，无法达到预期的资源读取结果:
  - 当 Expires 的字段设置为 0 时，代表该资源已经过期
  - 如果在 Cache-Control 响应头设置了 "max-age" 或者 "s-max-age" 指令，那么 Expires 头会被忽略。
协商缓存
- Last-Modified：服务端将资源传送给客户端的时候，会将资源最后的修改时间以 Last-Modified: GMT 的形式加在实体首部上返回。客户端接收到后会为此资源信息做上标记，等下次重新请求该资源的时候将会带上时间信息给服务器做检查，若传递的值与服务器上的值一致，则返回 304 ，表示文件没有被修改过，若时间不一致，则重新进行资源请求并返回 200 。
  重新请求的时候，客户端要用什么方式去传递时间呢？使用If-Modified-Since：在客户端重新请求资源的时候，将会在请求头添加 If-Modifed-Since: GMT 字段传递给服务端，服务端接收后会与当前该文件的最后修改时间对比，如果时间一致则返回 304 ，如果不一致则传递最新的资源并返回 200 状态码。
- ETag：为了解决资源修改但是内容却没被修改，却依旧返回最新的资源的问题，服务端通过某种算法（比如 MD5）计算出该资源的唯一标致符，在响应资源的时候，将会添加在实体首部字段连同资源一并返回给客户端。客户端接收到后将会保存该信息，并且在下一次请求中附上该信息给服务端，服务器只需要比较客户端传来的ETag跟自己服务器上该资源的ETag是否一致，就能很好地判断资源相对客户端而言是否被修改过了。如果服务端检测到传递过来的值与服务器端的不一致，则返回最新的资源和 200 状态码，否则返回 304 告知客户端使用缓存文件

host头部：host字段指定对应的虚拟站点，能够使不同域名配置在同一个IP地址的服务器上。

http1.1缺点：

线头阻塞：虽然允许了多个TCP连接，但是在同一个TCP连接中，所有的请求都还是按照次序执行的，服务器只允许在一个请求处理完了之后才会接着处理下一个，这导致的问题是如果排在前边的请求很慢，那么后边的请求就会一直处于等待状态，这就是线头阻塞。

解决方式：可以通过减少请求数和同时多开持久连接来解决线头阻塞的问题。

http1.x

缺陷概括来说：线程阻塞，在同一时间，同一域名的请求有一定的数量限制，超过限制数目的请求会被阻塞。

Http2.0：

二进制分帧层（Binary Format）(应用层和传输层之间):HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合，解析起来更加的高效，出错率更少。基于这种考虑HTTP2.0的协议解析决定采用二进制格式。

多路复用（MultiPlexing）:完全的多路复用，而非有序拥塞，只需要一个连接就可以实现，即连接共享。也就是每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面，不用按照顺序一一对应了，也就避免了线头阻塞。

header压缩:如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，这样会浪费带宽，也影响速度。HTTP2.0使用encoder来减少需要传输的header大小，对于相同的头部，只需要发送一次后就不必再通通过请求发送(并引入了gzip或compress头信息压缩机制)，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。

服务端推送（server push）同SPDY一样，HTTP2.0也具有server push功能，允许服务器在未经过客户端请求的情况下，向可以短发送资源，通过推送服务器任务，客户端可以把需要的内容存储在客户端中，避免了往返的延迟。

Https：较为安全的网络传输协议

证书(公钥)
SSL加密
端口443

是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL。

https也是遵循了安全通信三个原则：
内容加密：建立一个信息安全通道，来保证数据传输的安全；
身份认证：确认网站的真实性
数据完整性：防止内容被第三方冒充或者篡改

HTTP的基本优化

影响一个 HTTP 网络请求的因素主要有两个：带宽和延迟。

带宽：如果说我们还停留在拨号上网的阶段，带宽可能会成为一个比较严重影响请求的问题，但是现在网络基础建设已经使得带宽得到极大的提升，我们不再会担心由带宽而影响网速，那么就只剩下延迟了。

延迟：

浏览器阻塞（HOL blocking）：浏览器会因为一些原因阻塞请求。浏览器对于同一个域名，同时只能有 6 个连接（这个根据浏览器内核不同可能会有所差异），超过浏览器最大连接数限制，后续请求就会被阻塞。
DNS 查询（DNS Lookup）：浏览器需要知道目标服务器的 IP 才能建立连接。将域名解析为 IP 的这个系统就是 DNS。这个通常可以利用DNS缓存结果来达到减少这个时间的目的。
建立连接（Initial connection）：HTTP 是基于 TCP 协议的，浏览器最快也要在第三次握手时才能捎带 HTTP 请求报文，达到真正的建立连接，但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。

HTTP1.0和HTTP1.1的一些区别?

缓存处理:在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

带宽优化及网络连接的使用:HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

错误通知的管理:在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

Host头处理:在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。

长连接:HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

https 和 http 在工作流程上的区别？

http 的工作流程：

建立一个TCP连接
浏览器发送http请求信息到服务端
服务器发送http回应信息到浏览器
TCP连接关闭

由于https在http的基础上新增了ssl证书的验证，所以在进行http请求之前，会进行如下的验证

验证服务器端
客户端和服务器端选择加密算法和密码，确保双方都支持
验证客户端(可选)
使用公钥加密技术来生成共享加密数据
创建一个加密的ssl连接
基于该ssl连接传递HTTP请求

https的加密方式？

密钥：密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥，分别应用在对称加密和非对称加密上。

对称加密：也叫私钥加密，加密和解密都是使用的同一个密钥，即信息的发送方和接收方使用同一个密钥去加密和解密数据。对称加密的特点是算法公开、加密和解密速度快，适合于对大数据量进行加密
常见的对称加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC4、IDEA

非对称加密：非对称加密也叫做公钥加密。非对称加密与对称加密相比，其安全性更好。对称加密的通信双方使用相同的密钥，如果一方的密钥遭泄露，那么整个通信就会被破解。而非对称加密使用一对密钥，即公钥和私钥，且二者成对出现。私钥被自己保存，不能对外泄露。公钥指的是公共的密钥，任何人都可以获得该密钥。用公钥或私钥中的任何一个进行加密，用另一个进行解密。

加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥
公钥和算法都是公开的，私钥是保密的
非对称加密过程
1. 服务器生成配对的公钥和私钥
2. 私钥保存在服务端，公钥发送给客户端
3. 客户端使用公钥加密明文传输给服务端
4. 服务端使用私钥解密密文得到明文

数字签名：签名就是在信息的后边再加上一段内容，可以证明信息没有被修改过。
数字签名的过程如下：明文 --> hash运算 --> 摘要 --> 私钥加密 --> 数字签名

数字签名有两个作用：

能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
数字签名能确定消息的完整性。

数字签名只能验证数据的完整性，数据本身是否加密不属于数字签名的控制范围

摘要算法：摘要算法又称哈希/散列算法。它通过一个函数，把任意长度的数据转换为一个长度固定的数据串（通常用16进制的字符串表示）。算法不可逆

HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别？

HTTP/1.* 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；
HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；
HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；具体如图：

HTTP2.0多路复用的好处？

HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我协调，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP的性能提升。

https的传输过程?

在服务器端存在一个公钥及私钥
客户端从服务器取得这个公钥
客户端产生一个随机的密钥
客户端通过公钥对密钥加密（非对称加密）
客户端发送到服务器端
服务器端接受这个密钥并且以后的服务器端和客户端的数据全部通过这个密钥加密

https和http的区别？

https需要CA证书，http不需要，一般免费证书很少，需要交费。
http是超文本传输协议，协议运行在TCP之上，是明文传输；https则是具有安全性的ssl加密传输协议，运行在SSL/TLS之上，SSL/TLS运行在TCP之上。
http和https使用的端口不同，http端口是80，https端口是443。
http的连接很简单，无状态；HTTPS是由SSL+HTTP构建的可进行加密传输、身份认证的网络协议，比http协议安全，对搜索引擎更加友好，利于 seo。
https 基于传输层，http 基于应用层
HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。如图所示 HTTPS 相比 HTTP 多了一层 SSL/TLS：
SSL（Secure Socket Layer，安全套接字层）: SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。

TLS（Transport Layer Security，传输层安全）: 其前身是 SSL

https用哪些端口进行通信，这些端口分别有什么用

443端口用来验证服务器端和客户端的身份，比如验证证书的合法性
80端口用来传输数据（在验证身份合法的情况下，用来数据传输）

服务器推送是什么？

服务端推送能把客户端所需要的资源伴随着index.html一起发送到客户端，省去了客户端重复请求的步骤。正因为没有发起请求，建立连接等操作，所以静态资源通过服务端推送的方式可以极大地提升速度。具体如下：

为什么需要头部压缩？

假定一个页面有100个资源需要加载（这个数量对于今天的Web而言还是挺保守的）, 而每一次请求都有1kb的消息头（这同样也并不少见，因为Cookie和引用等东西的存在）, 则至少需要多消耗100kb来获取这些消息头。HTTP2.0可以维护一个字典，差量更新HTTP头部，大大降低因头部传输产生的流量

如何确定服务端开启了gzip？

客户端请求中增加Accept-Encoding: gzip表示客户端支持gzip；
服务端接收到请求后，将结果通过gzip压缩后返回给客户端并在响应头中增加Content-Encoding:gzip 表示响应数据已被压缩
客户端接收请求，响应头中有Content-Encodin:gzip表示数据需解压处理

为什么需要CA机构对证书签名，证书包含哪些内容？

如果不签名会存在中间人攻击的风险，签名之后保证了证书里的信息，比如公钥、服务器信息、企业信息等不被篡改，能够验证客户端和服务器端的“合法性”。

证书包含的内容：

证书颁发机构的名称
证书本身的数字签名
证书持有者公钥
证书签名用到的Hash算法

证书的有效性：
浏览器默认都会内置CA根证书，其中根证书包含了CA的公钥

证书颁发的机构是伪造的：浏览器不认识，直接认为是危险证书。

证书颁发的机构是确实存在的，于是根据CA名，找到对应内置的CA根证书、CA的公钥。用CA的公钥，对伪造的证书的摘要进行解密，发现解不了，认为是危险证书。

对于篡改的证书，使用CA的公钥对数字签名进行解密得到摘要A，然后再根据签名的Hash算法计算出证书的摘要B，对比A与B，若相等则正常，若不相等则是被篡改过的。

证书可在其过期前被吊销，通常情况是该证书的私钥已经失密。较新的浏览器如Chrome、Firefox、Opera和Internet Explorer都实现了在线证书状态协议（OCSP）以排除这种情形：浏览器将网站提供的证书的序列号通过OCSP发送给证书颁发机构，后者会告诉浏览器证书是否还是有效的。

HTTP request报文结构是怎样的

首行是Request-Line包括：请求方法，请求URI，协议版本，CRLF
首行之后是若干行请求头，包括general-header，request-header或者entity-header，每个一行以CRLF结束
请求头和消息实体之间有一个CRLF分隔
根据实际请求需要可能包含一个消息实体栗如：

GET /Protocols/rfc2616/rfc2616-sec5.html HTTP/1.1
Host: www.w3.org
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/\*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Referer: https://www.google.com.hk/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
Cookie: authorstyle=yes
If-None-Match: "2cc8-3e3073913b100"
If-Modified-Since: Wed, 01 Sep 2004 13:24:52 GMT

name=qiu&age=25

HTTP response报文结构是怎样的

首行是状态行包括：HTTP版本，状态码，状态描述，后面跟一个CRLF
首行之后是若干行响应头，包括：通用头部，响应头部，实体头部
响应头部和响应实体之间用一个CRLF空行分隔
最后是一个可能的消息实体，响应报文例子如下：

HTTP/1.1 200 OK
Date: Tue, 08 Jul 2014 05:28:43 GMT
Server: Apache/2
Last-Modified: Wed, 01 Sep 2004 13:24:52 GMT
ETag: "40d7-3e3073913b100"
Accept-Ranges: bytes
Content-Length: 16599
Cache-Control: max-age=21600
Expires: Tue, 08 Jul 2014 11:28:43 GMT
P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"
Content-Type: text/html; charset=iso-8859-1

{"name": "qiu", "age": 25}

1xx的状态会被HTTP库直接处理掉，不会让上层应用知晓

100 Continue 继续，一般在发送post请求时，已发送了http header之后服务端将返回此信息，表示确认，之后发送具体参数信息
101(切换协议) ：请求者已要求服务器切换协议，服务器已确认并准备进行切换。

2XX：成功状态码

200 OK 请求成功
正常返回信息
201 Created 创建成功
请求成功并且服务器创建了新的资源，对于POST或PUT请求的响应很有用
202 Accepted 服务器已接受请求，但尚未处理，这时候客户端可以通过轮询等机制继续请求
203: 非授权信息，服务器已成功处理了请求，但返回的信息可能来自另一个源；
204 No Content 没有内容
请求操作成功，但是没有返回任何内容，对于不需要响应主体的操作很有用，例如delete
205 Reset Content 重置内容
表示请求成功，但响应报文不包含实体的主体部分，但与204响应不同的在于要求请求方重置内容
206: 部分内容，服务器成功处理了部分请求；

3XX：重定向

301 Moved Permanently 请求的网页已永久移动到新位置。
用于通知浏览器所请求的文件已被移动，并且它应该从服务器提供的位置请求文件，并记住该新位置以供将来参考。这只能用于HTTP GET 和 HEAD请求。此资源已移至另一个位置，并返回该位置，当URL随着时间的推动变化时(尤其是由于版本，迁移或其他一些破坏性的更改)，此标头特别有用，保留旧标头将重定向返回到新的位置允许旧客户端更新其引用自己的时间。
302 Found 临时性重定向。
和301比较相似，但是是临时重定向。它将客户端从旧资源引导到新资源，但它不会告诉搜索引擎更新页面的索引。告诉客户端浏览另一个URL。
303 See Other 临时性重定向，且总是使用 GET 请求新的 URI。
304 Not Modified 自从上次请求后，请求的网页未修改过。
产生的前提：客户端本地已经有了缓存的版本，并且在Request中告诉了服务端，当服务端通过时间或者tag，发现没有更新的时候，就会返回一个不含body的304状态码。
305: 使用代理，请求者应该使用代理访问该页面；
306: 临时重定向，请求的资源临时从其他位置响应；
307 temporary redirect 暂时移动
临时重定向，和302含义类似，但是期望客户端保持请求方法不变向新的地址发出请求

4XX：客户端错误

400 Bad Request 错误请求
服务器无法理解请求的格式(比如缺少必要参数)，客户端不应当尝试再次使用相同的内容发起请求。
401 Unauthorized 请求未授权。
当拥有请求用户身份无法访问所请求的资源时，对于身份验证特别有用。
402: 为以后需要所保留的状态码；
403 Forbidden 禁止访问。
通常在请求的文件有效，但文件无法提供时发出，这通常是由于服务器权限问题导致的web服务器不允许将文件提供给客户端

401和403的区别：
401: 我去找个人，门卫说不认识我不让我进
403: 我去找个人，门卫说认识我，但我没资格进。

404 Not Found 请求资源不存在。
这是最常见的错误，的那个web浏览器请求服务器上不存在的文件时，会发生此问题。
405 方法不允许
不允许在资源上使用HTTP动作（如在只读资源上做 POST，GET，PUT等）
406：不接受，无法使用请求的内容响应请求的页面；
407: 请求者需要使用代理授权；
408: 服务器请求超时；
409: 服务器在完成请求时发生冲突；
410：请求的资源已永久删除；
411: 需要有效长度。服务器不接受不含有效内容长度标头字段的请求；
412: 服务器未满足请求者在请求中设置的其中一个前提条件；
413: 请求实体过大，超出服务器的处理能力；
414: 请求网址过长，服务器无法处理；
415: 请求格式不被请求页面支持；
416: 页面无法提供请求的范围;
417: 服务器未满足期望请求标头字段的要求;
418 I'm a teapot
这是IETF在1988年愚人节发的一个玩笑。

5XX: 服务器错误

500 Internal Server Error 最常见的服务器端错误。
这是一个不幸的模糊通用错误代码。只要认为服务器遇到与任何更具体的错误代码不匹配的错误，就会发出它。
501 Not Implemented 未实现
服务器要么不识别请求方法，要么不支持请求。
502 - Bad Gateway：错误网关
当Web浏览器联系充当另一个服务器的代理的Web服务器并且从另一个服务器获得无效响应时，会发生这种情况。
503 Service Unavailable 服务器端暂时无法处理请求（可能是过载或维护）。
这通常在服务器暂时性错误（暂时处于超负载或正在停机维护）的情况下遇到，此时服务器无法处理请求，可以一会再试
504：网关超时，服务器作为网关或代理。但是没有及时从上游服务器收到请求；
505：HTTP版本不支持，服务器不支持请求中所用的HTTP协议版本。

HTTP的几种请求方法用途

方法	说明/用途
GET	发送一个请求来取得服务器上的某一资源
POST	向URL指定的资源提交数据或附加新的数据
PUT	跟POST方法很像，也是想服务器提交数据。但是，它们之间有不同。PUT指定了资源在服务器上的位置，而POST没有
HEAD	只请求页面的首部
DELETE	删除服务器上的某资源
OPTIONS	它用于获取当前URL所支持的方法。如果请求成功，会有一个Allow的头包含类似"GET,POST"这样的信息
TRACE	TRACE方法被用于激发一个远程的，应用层的请求消息回路
CONNECT	把请求连接转换到透明的TCP/IP通道

字节跳动最爱考的前端面试题：计算机网络基础经得住拷问的HTTPS原理解析