前端为什么要了解HTTP？

什么是 HTTP 协议？

HTTP的全称是 HyperText Transfer Protocol ，即为超文本传输协议。它最初诞生的目的是为全世界知识共享服务 WWW – 万维网 提供文档传输协议。现在更通常地来说是为了 Web 服务器和 Web 浏览器通信而设计。也可以用于其他 客户端 和 服务端 通信。HTTP 协议遵循经典的 客户端-服务端模型，客户端 打开一个链接以发出请求，然后等待走到收到 服务端 响应。

HTTP 是无状态的，它不会在两次请求间保留任何的数据。

这些我们似乎都明白！那么，前端为什么要了解 HTTP 协议呢？

为什么要了解 HTTP 协议？

相信我们工作一段时间后，有许多疑问一直埋在我们心底。比如：

• HTTP 有哪些请求方法？
• 文件过大时，网络是怎么传输的？
• 断点续传是怎么实现的？
• 如何实现请求同一URL，在不同的平台，返回不同的内容？？
• HTTP 状态码有哪些？
• requireJS 的 304 缓存是如何实现的？
• 网站开通时，为什么需要申请 SSL 证书？
• HTTPS为什么会比HTTP慢一些？

带着这些问题，我又重新系统地学习了一遍 HTTP 协议。下面就上面的疑问进行一一地解答。

HTTP 有哪些请求方法？

POST

用于将实体提交到指定的资源。

DELETE

删除指定资源。

PUT

修改、替换指定资源。

GET

请求一个指定资源的表示形式。使用GET的请求应该只被用于获取数据。

HEAD

HEAD 方法与 GET 方法相同，只是使用 HEAD 方法请求时，服务器只返回响应头，不返回响应体。这种方法可以用来获取请求中隐含的元信息，而不用传输实体本身。比如获取头部中的Content-length、Etag、Last-modified等。常用来测试超链接的有效性、可用性和最近的修改。

CONNECT

建立一个由目标资源标识的服务器隧道。只有当浏览器配置为使用代理服务器时才会用到 CONNECT 方法

为了确保数据通信的安全，HTTPS已广泛应用于互联网，浏览器与服务器之间的HTTPS通信都是加密的。然而当浏览器需要通过代理服务器发起HTTPS请求时，由于请求的站点地址和端口号都是加密保存于HTTPS请求头中的，代理服务器是如何既确保通信是加密的（代理服务器自身也无法读取通信内容）又知道该往哪里发送请求呢？为了解决这个问题，浏览器需要先通过明文HTTP形式向代理服务器发送一个CONNECT请求告诉它目标站点地址及端口号。当代理服务器收到这个请求后，会在对应的端口上与目标站点建立一个TCP连接，连接建立成功后返回一个HTTP 200状态码告诉浏览器与该站点的加密通道已建成。接下来代理服务器仅仅是来回传输浏览器与该服务器之间的加密数据包，代理服务器并不需要解析这些内容以保证HTTPS的安全性。

https://www.joji.me/zh-cn/blog/the-http-connect-tunnel/

OPTIONS

用于描述目标资源的通信选项，获取服务器支持的 HTTP 请求方法。正常情况下很少用到这个方法，在一些跨域请求时，浏览器自己的实现机制会触发OPTIONS请求，先对请求进行一次预检，预检成功后再进行真正地请求。

详细的解释什么时候会发送OPTIONS，请参见：

https://juejin.cn/post/6844903821634699277

TRACE

方法沿着到目标资源的路径执行一个消息环回测试。

客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或者其他一些应用程序。每个中间节点都可能会修改原始的 HTTP 请求。TRACE 方法允许客户端在最终将请求发送给服务器时，看看它变成了什么样子。可以知道原始报文是否以及如何被修改或者破坏掉。

PATCH

局部更新资源。

它和 PUT 更新有什么区别呢？

首先，PATCH 和 PUT 都可以更新资源。根据 restful 标准要求，更新一个完整的信息，应该使用 PUT，如果只是更新一个完整信息的部分内容，应该使用 PATCH。比如：一个UserInfo，里面有userId， userName， userGender等10个字段。如果10个字段的值都要更新，理论上应该使用 PUT，如果只更新 userName或者其中的几个值，这个时候应该使用 PATCH。

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Methods

文件过大时，网络是怎么传输的？

数据压缩

浏览器在发送请求时都会带着 Accept-Encoding 头字段，里面是浏览器支持的压缩格式列表，如 gzip、deflate、br等。其中 gzip 压缩算法对文本文件有较好的压缩率。压缩率越大，经过压缩后的内容值越小，传输时的速度更快。

分块传输

通过设置 Transfer-Encoding 的值为 chunk 来指定传输的方式为分块传输。

分块传输表示服务器下发到客户端的内容不是一次性完成的，而是分成一小块一小块下发。过程中客户端和服务器的链接仍然维持不会断开。

注意设置了 Transfer-Encoding 为 chunk 时，就不再指定 Content-length了。

这个方式只存在于 HTTP 1.1中。

范围请求

响应头部会返回Access-Range: bytes来表示当前服务器支持范围请求。

浏览器在请求时，可以指定请求头中的 range 来设定要请求一个大文件中的哪一部分内容。

其中 Range 还有几种不同的方式来限定范围：

1. 500-1000：指定开始和结束的范围，一般用于多线程下载。
2. 500- ：指定开始区间，一直传递到结束。这个就比较适用于断点续传、或者在线播放等等。
3. -500：无开始区间，只意思是需要最后 500 bytes 的内容实体。
4. 100-300,1000-3000：指定多个范围，这种方式使用的场景很少，了解一下就好了。

多段数据

和范围传输类似，需要在每一分段前加上以 --两个横线开头的字符。

https://blog.csdn.net/qq_26046771/article/details/103321223

断点续传是怎么实现的？

断点续传的原理在于前端/服务端需要记住已上传的切片，这样下次上传就可以跳过之前已上传的部分，有两种方案实现记忆的功能

前端使用 localStorage 记录已上传的切片 hash服务端保存已上传的切片 hash，前端每次上传前向服务端获取已上传的切片

第一种是前端的解决方案，第二种是服务端，而前端方案有一个缺陷，如果换了个浏览器就失去了记忆的效果

https://juejin.cn/post/6844904046436843527#heading-0

如何实现在不同的平台，请求同一URL，返回不同的内容？

首页，什么情况下会出现这种情况？

• PC和mobile根据不同的屏幕，请求不同的图片资源。PC使用分辨率更大的，mobile上使用分辨率较小的图片。
• PC和mobile上就显示的内容都不一样时。
• 不同的国家，显示不同的语言（中文 / 英文）。

那么，我们应该怎么做呢？

HTTP协议中，有一个叫内容协商（Content Negotiation）的机制。它的目的是使用同一URL，响应的消息体可以是不同的内容。

内容协商的方式有两种：

1. 服务端驱动。客户端通过在请求头添加特定的头部字段（或URL后缀）,使服务端知道该客户端期望获取什么样的资源。然后由服务端决定返回什么样的内容给客户端。
2. 客户端驱动。服务端把所有的值都返回给客户端，由客户端决定使用哪种数据进行展示。

HTTP/1.1 协议标准里面定义了一些标准的用于服务端驱动内容协商模式的头部字段，如Accept、Accept-Charset、Accept-Encoding、Accept-Language等。服务端在处理请求返回响应给客户端时，在响应头部Vary字段告知客户端哪个头部字段被用于内容协商了。

HTTP状态码有哪些？

HTTP的状态码分为5类

• 100 – 199。信息响应类
• 200 – 299。成功响应类
• 300 – 399。重定向类
• 400 – 499。客户端错误
• 500 – 599。服务端错误

以下就常见的状态码进行整理：

信息响应

100 Continue

这个临时响应表明，迄今为止的所有内容都是可行的，客户端应该继续请求，如果已经完成，则忽略它。

101 Switching Protocol

该代码是响应客户端的 Upgrade 标头发送的，并且指示服务器也正在切换的协议。

102 Processing (WebDAV)

此代码表示服务器已收到并正在处理该请求，但没有响应可用。

成功响应

200 OK

请求成功。成功的含义取决于HTTP方法：

• GET：资源已被提取并在消息正文中传输。
• HEAD：实体标头位于消息正文中。
• POST：描述动作结果的资源在消息体中传输。
• TRACE：消息正文包含服务器收到的请求消息

201 Created

该请求已成功，并因此创建了一个新的资源。这通常是在POST请求，或是某些PUT请求之后返回的响应。

206 Partial Content

服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。该请求必须包含 Range 头信息来指示客户端希望得到的内容范围，并且可能包含 If-Range 来作为请求条件。

重定向

300 Multiple Choice

被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。

301 Moved Permanently

被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。

302 Found

请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。

303 See Other

对应当前请求的响应可以在另一个 URI 上被找到，而且客户端应当采用 GET 的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。

304 Not Modified

如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。304 响应禁止包含消息体，因此始终以消息头后的第一个空行结尾。

307 Temporary Redirect

请求的资源现在临时从不同的URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。

308 Permanent Redirect

这意味着资源现在永久位于由 Location: HTTP Response 标头指定的另一个 URI。这与 301 Moved Permanently HTTP 响应代码具有相同的语义，但用户代理不能更改所使用的 HTTP 方法：如果在第一个请求中使用 POST，则必须在第二个请求中使用 POST。

客户端响应

400 Bad Request

1. 语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。
2. 请求参数有误。

401 Unauthorized

当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书，那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展示响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。

403 Forbidden

服务器已经理解请求，但是拒绝执行它。与 401 响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个 404 响应，假如它不希望让客户端获得任何信息。

404 Not Found

请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。

405 Method Not Allowed

请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。鉴于 PUT，DELETE 方法会对服务器上的资源进行写操作，因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法，对于此类请求均会返回405错误。

408 Request Timeout

请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。

429 Too Many Requests

用户在给定的时间内发送了太多请求（“限制请求速率”）。

服务端响应

500 Internal Server Error

服务器遇到了不知道如何处理的情况。

502 Bad Gateway

此错误响应表明服务器作为网关需要得到一个处理这个请求的响应，但是得到一个错误的响应。

503 Service Unavailable

服务器没有准备好处理请求。常见原因是服务器因维护或重载而停机。请注意，与此响应一起，应发送解释问题的用户友好页面。这个响应应该用于临时条件和 Retry-After：如果可能的话，HTTP头应该包含恢复服务之前的估计时间。网站管理员还必须注意与此响应一起发送的与缓存相关的标头，因为这些临时条件响应通常不应被缓存。

504 Gateway Timeout

当服务器作为网关，不能及时得到响应时返回此错误代码。

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status

requireJS的304缓存是如何实现的？

网站开通时，为什么要申请SSL证书？

SSL的中文翻译是安全通讯协议（全称：Secure Sockets Layer），根据维基百科的解释，SSL是一种安全协议，目的是为网络通讯提供安全及资料完整性的保障。

SSL证书就像一个保护数据的专用锁头，它可以在访客的浏览器与网站或应用之间确保安全连接并用于确保数据加密传递。此外，可以对网页进行身份验证，因此任何未经授权的人都不能监视并进行攻击，特别是对于电商网站，这可以保护非常敏感或重要的资讯。如果信用卡号、密码或其他个人资讯等未经加密，那么攻击者就可以轻松介入并窃取资料。使用SSL证书之后，任何试图窃取资料的人都无法顺利读取，唯一能够解密它的人是另一端的接收者。

SSL证书的三大好处：

1. 安全与信任：确保网站资料传输安全、可靠，并在浏览器中显示https和安全锁头标志，确保用户所访问的网站是与域名对应的真实网站。
2. 防止数据泄露：当客户的数据传输到网站或从网站传输时，数据不会受到攻击的风险。
3. 增加SEO优势：与没有SSL凭证的网站相比，加密网站更有可能获得更高的搜索排名。

和用户信息相关的，最好都需要申请一个SSL证书，以进一步保证用户数据安全。

http://sslrz.com/plus/view.php?aid=11

HTTPS为什么会比HTTP慢一些？

HTTP在建立链接时，只需要三次握手。

HTTPS在建立链接时，需要三次握手 + SSL握手。

使用SSL加密、解密时，还会消耗一些CPU和内存。

所以说HTTPS比HTTP慢。

但是数据对比它们慢都是毫秒级的。目前淘宝、京东等平台都使用了HTTPS。用户在使用时也基本上是无感的。从其他方面优化性能可以很好的弥补由于使用了SSL时造成的慢。