🐲【1】ShutdownHTTP系列-基础篇

Shutdown HTTP系列介绍

以前，有位大佬和我说过这么一句话："网络知识在必定程度上决定了你的上限"。前端

对HTTP只知其一;不知其二的我，上限真的这么低吗...就不能花点时间好好整理整理吗 🤔️？git

此次请给霖呆呆一个机会，跟着个人脚步👣从1开始学习它。另外我整理的HTTP系列基本都会附有一个面试时的浅答与深答的的配套答案，浅答是为了让大家更好的记住，深答保证你确实理解了浅答中的知识点。github

整个系列下来，让咱们完全 Shutdown HTTP ！！！💪面试

系列思惟导图：数据库

系列目录：浏览器

《🐲【1】Shutdown HTTP系列-基础篇》「本篇」
《🐲【2】Shutdown HTTP系列-HTTP报文篇》
《🐲【3】Shutdown HTTP系列-Cookie篇》
《🐲【4】Shutdown HTTP系列-HTTPS篇》
《🐲【5】Shutdown HTTP系列-CCPG篇》
《🐲【6】Shutdown HTTP面试系列》

全部文章内容均被收入GitHub我的博客：niubility-coding-js 快来给我Star呀😊~缓存

本篇目录

经过阅读本篇文章你能够学习到：安全

HTTP概述
HTTP特色及缺点
HTTP请求方法
HTTP状态码

（请注意，带有🌟标示的都是必需要掌握的哦）服务器

1. HTTP概述

HTTP协议（HyperText Transfer Protocol，超文本传输协议）是因特网上应用最为普遍的一种网络传输协议。markdown

设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法，它是一个基于 TCP/IP 通讯协议来传输数据的应用层协议。

要注意的点就是：

一句话概述HTTP
HTTP经典的几个版本
HTTP存在的位置

1.1 一句话概述HTTP

【面试时问起：一句话概述HTTP协议】🌟🌟🌟🌟

「HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。」

（HTTP一般跑在TCP/IP协议栈之上，依靠IP协议实现寻址和路由、TCP协议实现可靠数据传输、DNS协议实现域名查找、SSL/TLS协议实现安全通讯。固然，WebSocket、HTTPDNS依赖于HTTP。——「进击的前端工程师」HTTP的世界观(附HTTP/3中文翻译)-童欧巴）

1.2 HTTP经典的几个版本

初版 「HTTP/0.9」 于「1990年」问世，并无做为正式的标准被创建。
做为正式的标准被创建是 「HTTP/1.0」，于「1996年5月」发布。(比霖呆呆大了4个月)
目前主流的版本是 「HTTP/1.1」，于「1997年1月」发布。
「2015年5月」 正式发布「HTTP/2」。(不叫HTTP/2.0，是由于标准委员会不打算发布子版本，下一个版本直接是HTTP/3)

1.3 HTTP存在的位置

处于 TCP/IP 网络分层模型中的第一层「应用层」。

应用层的其它协议还有：

FTP：文件传输协议，用来在客户机和FTP服务器之间传输文件。
DNS域名系统：提供域名到IP地址之间的解析服务。
SMTP：邮件发送协议，用户经过SMTP服务器发送邮件。
DHCP：动态主机配置协议，DHCP服务器为客户机动态分配IP地址。
POP3：邮件接收协议，用于从POP3服务器接收邮件。

【面试时问起通常答前面三个就够了】🌟🌟

2. HTTP特色及缺点

2.1 HTTP特色

常问知识点，重要指数：🌟🌟🌟🌟🌟

HTTP协议支持客户端/服务端模式，也是一种请求/响应模式的协议。
灵活可扩展：一个是语义上的自由，只规定了基本格式，其它的各部分没有严格的限制；第二个它容许传输任意类型的数据对象，例如文本、图片、音频等，传输的类型由Content-Type加以标记。
可靠传输，HTTP 基于 TCP/IP，所以把这一特性继承了下来。
无状态，也就是说HTTP请求不具有保存以前发送过的请求或响应的功能，每一次请求都是独立无关的。

若是还要的话，能够答一下「持久链接」：

概念：创建一次TCP链接便可进行屡次请求或响应的交互
产生缘由：HTTP的初始版本是每进行一次HTTP通讯就要断开一次TCP链接，下次再进行的时候又要从新链接断开。再现在请求的资源愈来愈大，每次请求若是都有无谓TCP链接和断开是很大的开销。
特色：只要有一方没有明确的提出断开链接，则保持TCP链接状态。
优势：减小了TCP链接和断开的形成的额外开销，减轻了服务端的负载，Web页面加载变快
注意点：在HTTP/1.1中全部的链接默认都是持久链接的(也就是首部字段 Connection: keep-alive，如果想要关闭则将值设置为 close)，可是HTTP/1.0并未标准化

（另外其实还有一个管线化的特色，同时并行发送多个请求，而没必要等前一个请求完毕才能发送下一个。可是由于各类缘由被各大厂商废弃了）

2.2 HTTP的缺点

常问知识点，重要指数：🌟🌟🌟🌟🌟

简单来讲：

明文传输(不加密)，内容可能被窃听。
没法验证报文的完整性，内容可能被篡改。
不验证通讯方的身份，有可能遭遇假装。
无状态，它是缺点也是优势吧，分不一样的场景。
队头阻塞。

详细来讲：

明文传输(不加密)，内容可能被窃听。协议里的报文不使用二进制数据，而是文本形式
没法验证报文的完整性，内容可能被篡改。这里说的完整性也就是指信息的准确度由于接收方或者发送方没有办法确认对方发送过来的数据在中间有没有被篡改
不验证通讯方的身份，有可能遭遇假装。由于HTTP协议中不会对通讯方进行确认任何人均可以发送请求，并且服务器它对收到的请求也不会进行确认，只要收到了请求就会返回一个响应(固然这个只是在发送端的IP地址或者端口号没被Web服务器设定限制访问的前提下)
无状态，不具有保存以前发送过的请求或响应的功能。它是缺点也是优势吧：
- 对于一些长链接的场景须要保存上下文信息，以避免传输重复的数据。
- 对于一些应用只是为了获取数据不须要保存上下文信息，无状态减小了网络开销。
队头阻塞：
- 其根本缘由在于HTTP是基于请求-响应的模型，在同一个TCP长链接中，前一个请求没有获得响应，后面的请求就会被阻塞。
- 用并发链接和域名分片来解决了这个问题。但并非从HTTP自己的层面来解决的，只是增长了 TCP 链接，分摊风险而已。
- HTTP/2中的多路复用从HTTP自己的层面解决了这个问题
- 和TCP队头阻塞的区别：TCP传输的单位是数据包，它的队头阻塞表示的是前一个报文没有收到便不会将下一个报文上传给HTTP。而HTTP队头阻塞是在请求-响应层面，前一个请求尚未处理完，后面的请求就被阻塞。

3. HTTP请求方法

3.1 方法种类

常问知识点，重要指数：🌟🌟🌟🌟🌟

GET：获取资源，幂等操做
HEAD：获取报文首部，和GET很像可是不返回报文主体，幂等操做
POST: 建立或更新资源，非幂等操做
PUT: 建立或更新资源自己，幂等操做
PATCH：对资源进行局部更新，非幂等操做
DELETE：删除资源，和PUT功能相反，幂等操做

OPTIONS：查询服务器端支持的HTTP方法种类(幂等操做)：

请求	OPTIONS * HTTP/1.1 Host: lindaidai.wang
响应	HTTP/1.1 200 OK Allow: GET, POST, HEAD, OPTIONS (返回服务器支持的方法)

CONNECT：创建链接隧道，用于代理服务器，幂等操做
TRACE：追踪请求，查询发出去的请求是怎样被加工/篡改的，幂等操做。容易引起XST跨站追踪攻击。

3.2 HTTP中的幂等是什么意思

重要指数：🌟🌟🌟🌟

(先让咱们来了解一下它的概念)

这东西其实很好理解，你只要记住：若是一个方法重复执行屡次，产生的效果是同样的，那么这个方法就是幂等的。「它本质上意味着成功执行请求的结果与其执行次数无关。」

让咱们来具体看看每一项的分析：

GET方法用于获取资源，不该该有反作用，因此它是「幂等」的。例如：GET http://lindaidai.wang/account/123，不会改变资源的状态，不管是调用一次仍是N次都没有反作用。可是要注意了，这里指的是「调用多少次都没有反作用」，而不是每次GET的结果都相同。由于你想一想有可能直接去改了数据库的这条数据，那么下次获取到的可能就不相同了，可是它自己并无产生反作用，因此知足幂等。
HEAD方法GET状况同样，只不过它只用于获取报文首部，不返回报文主体，因此它也是「幂等」的。
POST和PUT很容易让人混淆，以前我老是简单的认为：POST表示建立资源，PUT表示更新资源；可是实际上它们均可用于建立和更新资源，只不过本质的差异就在于幂等性上。POST所对应的URI并不是建立资源的自己，而是「资源的接收者」。例如：POST http://lindaidai.wang/articles的语义是在http://lindaidai.wang/articles下建立一篇帖子，HTTP响应中应包含帖子的建立状态以及帖子的URI。两次相同的POST请求会在服务器端建立两份资源，它们具备不一样的URI，因此POST是「非幂等」的。
PUT方法所对应的URI是要建立或者更新「资源自己」。这点很容易让人误会它不是幂等的，但其实它是「幂等」的。例如：PUT http://lindaidai.wang/accout/321 的语义是建立或者更新ID为321的帖子。第一次PUT方法执行以后，其在服务器上生成的资源，不能被后续的PUT方法更改，因此对同一URI进行屡次PUT的反作用和一次PUT是相同的，于是它是「幂等」的。
DELETE方法用于删除资源，有反作用(意思就是会修改服务器上的资源内容)，但它倒是「幂等」的。由于例如：DELETE http://lindaidai.wang/accout/321调用一次和调用N次对系统产生的反作用是相同的，都是为了删掉ID为321的帖子。所以，调用者能够屡次调用或刷新页面而没必要担忧引发错误。
OPTIONS这个很好理解，只是为了获取服务器支持的方法，我知道的通常是使用了代理而后进行一个预请求的时候会用到。它是「幂等」的。

【面试时答法】

一个方法是否是幂等，其实就是判断一个方法重复执行屡次，产生的效果是否是同样的，若是是幂等的话，它本质上意味着成功执行请求的结果和它的执行次数无关。我所知道的，只有「POST」和「PATCH」是非幂等的，其它都是幂等操做。

3.3 GET和POST的区别

不用我多说，常问知识点，重要指数：🌟🌟🌟🌟🌟

(这里我用的是三元总结的一份答案+本身的一些理解)

从缓存的角度上说，GET会被浏览器主动缓存下来，留下历史记录，可是POST不会。
从编码的角度上说，GET只能进行URL编码，它只能接收ASCII字符，可是POST没有限制。
从参数的角度上说，GET通常放在URL上传递参数，POST放在请求体里，更适合传递敏感信息。
从幂等的角度上说，GET是幂等的，而POST不是。
不过据我了解的，其实GET和POST本质上都是TCP链接，并没有差异。可是因为HTTP的规定和浏览器/服务器的限制，致使它们在应用过程当中体现出一些不一样。
还有能够从TCP的角度上说，GET请求会把请求报文一次性发出去，可是POST会分为两个TCP数据包。首先发送的是header部分，如果服务器响应100(continue)，则会发送body部分，固然「火狐」浏览器除外，它的 POST 请求只发一个 TCP 包。

（这时候面试官可能还会追加着问你：既然POST要分为两个TCP数据包发送，那GET是否是会比POST更有效啊）

你能够这样回答：

首先，GET和POST都有它们本身的语义的，最好不要混用
另外，虽说POST会分为两个数据包发送，可是其实在网络条件好的状况下，发一次包和发两次包的相差的时间基本能够被无视了。而且在网络条件差的状况下，两次包的TCP在验证数据包的完整性上还有更大的优势。
再者，也并非全部的浏览器的POST请求都会发送两次TCP数据包的，好比火狐就不会。

3.4 支持度

OPTIONS、CONNECT、TRACE只在HTTP/1.1以上被支持
LINK、UNLINK在HTTP/1.1中被废弃

3.5 服务端收到不支持的方法会如何处理

当服务端收到不支持的方法时，会返回 405 Method Not Allowed，而且会把全部支持的方法写入响应报文首部字段Allow中返回。

4. HTTP状态码

重要指数：🌟🌟🌟🌟🌟

（又是个硬核的知识点啊...这里霖呆呆就只列举一些经常使用的）

1xx 信息性

「请求已经接收到，须要进一步处理才能完成，可是HTTP/1.0 不支持。」

101 Switching Protocols ：在HTTP升级为WebSocket时，若是服务器赞成变动，则返回 101。

2xx 成功状态

「成功处理请求。」

200 OK ：请求成功，一般返回的数据中带有响应体。
204 No Content：意思和200同样，不过返回的数据中不带有响应体。
206 Partial Content：客户端进行了范围请求且服务端正常处理，响应报文的首部应该还有Content-Range字段指定实体的范围。使用场景为HTTP分块下载和断点续传。

3xx 重定向

「重定向状态，资源位置发生变更，须要从新请求。」

301 Moved Permanently：永久重定向，最新的URI为响应报文首部的 Location 字段。场景是：例如你的网站换了地址了，以前的地址不用了，若用户仍是从以前的地址进的话则会返回301且在Location中带上最新的URI。且浏览器默认会作缓存优化，减小服务器压力，在第二次访问的时候自动访问重定向的那个地址。
302 Found：临时重定向，和301不一样，它表示请求的资源临时被移动到了别的URI上，由于是暂时的，因此不会被缓存。
303 See Other：临时重定向，请求的资源临时被移动到了别的URI上，可是明确表示客户端应该使用GET方法获取资源。
304 Not Modefied：客户端带条件请求时虽未知足条件可是也容许返回该资源，它虽然被划分在3xx中，但其实和重定向没有关系。场景例如：协商缓存成功就会返回304 Not Modefied，表示请求的资源在服务器上并未发送改变，告诉请求者可使用缓存。(能够看个人这篇文章哦《霖呆呆你来讲说浏览器缓存吧》)
307 Temprary Redirect：临时重定向，可是比302更加明确，重定向的请求方法和实体都不容许变更。场景例如：HSTS协议，强制客户端使用https创建链接，好比你的网站从HTTP升级到了HTTPS，而你仍是经过http://xxx访问的话，就会返回307 Internal Redirect。(能够试一下juejin.cn)

三种临时重定向简单比较：

302 Found，基本的临时重定向
303 See Other，明确表示客户端应该使用GET方法
307 Temprary Redirect，请求方法和实体都不容许变更

4xx 客户端错误

「客户端出现错误。」

400 Bad Request：请求报文中存在语法错误，可是没有具体指出是哪里。
401 Unauthorized：须要有经过HTTP认证的认证信息或者表示用户认证失败。
403 Forbidden：请求资源被拒绝，缘由是：好比法律禁止、信息敏感。
404 Not Found：请求资源未找到，表示没在服务器上找到相应的资源。

5xx 服务端出现错误

「服务端出现错误。」

500 Internal Server Error：服务器内部错误，可是没有具体指出是哪里，和400有点像。
501 Not Implemented：表示客户端请求的功能还不支持
502 Bad GateWay：服务器自身是正常的，可是代理服务器没法获取到合法响应(点外卖时外卖小哥没送)
503 Service Unavailable：服务器内部处于超负载状态或进行停机维护(就像是本店今天不开张)

参数文章

后语

你盼世界，我盼望你无bug。这篇文章就介绍到这里。

能够发现，在基础篇中，主要的都是一些概念题，花个10分钟左右就能看完了。不须要咱们像学习 RSA握手、ECDHE握手、数字签名那些知识点同样，拼命的理解。更多的都是一些硬核知识，须要咱们紧紧记住。

这个系列文章的最后我都会送给你们一段情话来表达我对你们的感谢：

"世界上有两句语言最浪漫动人"

"第一句是 “我爱你”"

"第二句是 “你写的文章真好看”"

"看官你看这样好很差？"

"之后您说第二句"

"而后我说第一句"

啊啊啊啊...太提莫的撩了我都受不了我本身...

喜欢「霖呆呆」的小伙还但愿能够关注霖呆呆的公众号 LinDaiDai 或者扫一扫下面的二维码👇👇👇.

我会不定时的更新一些前端方面的知识内容以及本身的原创文章🎉

你的鼓励就是我持续创做的主要动力 😊.