那些前端应该知道的HTTP知识

前言

这篇文章原本是我一年前看《图解HTTP》作的笔记，但记完后放在文件夹的某个角落一直没管。前段时间撸项目练手的时候，在状态码上碰到了问题，所以又拿了出来翻了翻，同时又在原有的基础上作了些修改，补上了HTTPs的一些东西。这篇文章主要是对HTTP相对重要的知识的一些归纳，想要好好学习HTTP仍是须要看《图解HTTP》或者《HTTP权威指南》，才能构建较为完整的知识体系。最后，你没有猜错，我就是传说中的标题党，但但愿这篇文章对你有用，哪怕是一丁点，2333。

1.HTTP简述（出自MDN）

超文本传输协议（HTTP）是用于传输诸如HTML的超媒体文档的应用层协议。它被设计用于Web浏览器和Web服务器之间的通讯，但它也能够用于其余目的。 HTTP遵循经典的客户端-服务端模型，客户端打开一个链接以发出请求，而后等待它收到服务器端响应。 HTTP是无状态协议，意味着服务器不会在两个请求之间保留任何数据（状态）。虽然一般基于TCP / IP层，但能够在任何可靠的传输层上使用.

2.URL和URI

咱们常常会接触到URL（统一资源定位符），它就是咱们用于访问web的一个字符串地址.而URI对咱们来说就相对比较陌生了，它的名字叫作统一资源标识符（URI）。咱们来看看它们具体的区别吧：

• URI：uniform resource identifier 统一资源标识符，一种资源的标识，它是一种抽象的资源标识，便可以是相对的，也能够是绝对的。
• URL：uniform resource location 统一资源定位符，同时一种资源的标识，但指明了如何定位Locate这个资源。由于它指明了定位的信息，因此必须是绝对的。

（咱们平时所说的相对地址，其实只是相对于另外一个绝对地址而言的）

2.1 URL

URL的基本格式以下：

schema://host[:port#]/path/.../[?query-string][#anchor]
复制代码

格式	意义
scheme	指定低层使用的协议(例如：http, https, ftp)。
host	HTTP服务器的IP地址或者域名。
port#	HTTP服务器的默认端口是80，这种状况下端口号能够省略。若是使用了别的端口，必须指明。
path	访问资源的路径。
query-string	发送给http服务器的数据。
anchor-	锚

3.HTTP报文

3.1 HTTP报文格式

HTTP的报文格式主要分为报文首部和报文主体：

其中的空行用于区分报文首部和报文主体内容，是由一个回车符和一个换行符组成的。

不管是请求报文仍是响应报文都须要有报文首部，而报文主体有些请求报文是没有的。而请求报文的通常格式以下：

而响应报文的格式是这样的：

下面是谷歌浏览器的HTTP报文内容，其中request headers描述了请求报文头部的内容，response headers描述了响应报文头部的内容：

其中最多见的属性以下：

1. URL, 即http访问的地址
2. request method, 报文的请求方式
3. status code, 状态码以及状态短语
4. Accept Encoding, 内容编码
5. Connection, 链接方式
6. Cookie, 添加的cookie内容
7. Host, 目标主机
8. User-Agent, 客户端浏览器的相关信息
9. Set-Cookie, 指定想要在Cookie中保存的内容

接下来就聊一聊这些属性的做用

3.2 HTTP请求方式（request method）——GET and POST

发送HTTP的方式有不少，但最经常使用的仍是POST和GET。

• GET:GET方法能够用来请求访问已经被URL识别的资源。指定的资源通过服务端解析后返回响应的内容。简单来讲，就是请求的资源是文本的话，那么就保持原样返回.

  

• POST:POST方法能够用来传输实体的主体。

这二者的区别主要以下：

1. 使用目标不一样

POST与GET都用于获取信息，可是GET方式仅仅是查询，并不对服务器上的内容产生任何做用结果；每次GET的内容都是相同的。POST则经常使用于发送必定的内容进行某些修改操做。

2. 大小不一样

因为不一样的浏览器对URL的长度大小有必定的字符限制，所以因为GET方式放在URL的首部中，天然也跟着首先，可是具体的大小要依浏览器而定。POST方式则是把内容放在报文内容中，所以只要报文的内容没有限制，它的大小就没有限制。

3. 安全性不一样

上面也说了GET是直接添加到URL后面的，直接就能够在URL中看到内容。而POST是放在报文内部的，用户没法直接看到。

总的来讲，GET用于获取某个内容，POST用于提交某种数据请求，从使用场景来看，通常用户注册的内容是私密的，应该使用POST方式来保持私密，而当须要查询某个内容时，须要快速响应，则使用GET。

3.3 status code状态码

状态码一般就是服务器端对客户端说的话，分类以下：

状态码	含义
1**	服务器收到请求，须要请求者继续执行操做
2**	成功，操做被成功接收并处理
3**	从新定向，须要进一步的操做以完成请求
4**	客户端错误，请求包含语法错误或没法完成请求
5**	服务器错误，服务器在处理请求的过程当中发生了错误

常见的状态码：

• 200 一般的成功 OK

GET：请求的对应资源会做为响应返回。响应将包含描述或操做的结果。 POST：返回处理对应请求的结果。

• 204 成功处理请求，没有返回任何内容 No Content

表示服务器接收到的请求已经处理完毕，可是服务器不须要返回响应。好比，客户端是浏览器的话，那么浏览器显示的页面不会发生更新。

• 206 Partial Content

成功处理了部分GET请求

• 301 Moved Permanently

请求的网页已永久移动到新位置，永久性重定向

• 302 Found

网站临时性重定向，暂时不能访问（备案、被查）

• 303 See Other

该状态码表示因为请求对应的资源存在另外一个URI，并指定必须使用GET方法定向获取请求的资源。和302不一样的是，302是不会改变上次的请求方法

• 304 Not Modified

访问不了，并返回和上次同样的话,表示资源未被修改过，仍是和上次访问时同样。

• 307 Temporary Redirect

临时重定向，和30二、303相似，不一样的是，不会指定客户端要用什么样的方法请求，

• 400 Bad Request

表示客户端中存在语法错误，致使服务器没法理解该请求。客户端须要修改请求的内容后再次发送请求。

• 401 Unauthorized

即用户没有必要的凭据。该状态码表示当前请求须要用户验证。

• 403 Forbidden

服务器已经理解请求，可是拒绝执行它。

• 404 Not Found

服务器找不到请求的网页。

• 500 Internal Server Error

服务器遇到错误，没法完成请求。

• 503 Service Unavailable

因为临时的服务器维护或者过载，服务器当前没法处理请求。这个情况是暂时的.

3.4 内容编码 Accept Encoding

因为有些报文的内容会过大，为了减小传输时间，HTTP会采起一些压缩的措施，例如上面的报文信息中，Accept-Encoding就定义了内容编码的格式gzip。

总的来讲内容编码的格式有如下几种：

• gzip:GNU压缩格式
• compress:UNIX系统的标准压缩格式
• deflate:是一种同时使用了LZ77和哈夫曼编码的无损失压缩格式
• identity:不进行压缩

3.5 持久化——connection

正常发送HTTP时，咱们须要创建TCP的链接，而后再发送报文：

若是每次都要发送HTTP报文都须要经历上面的拿过过程，无疑将会耗费不少时间在创建和断开链接的过程当中，所以HTTP使用了connection属性，用于指定链接的方式，当当设置成keep-alive时，就会创建一条持久化的链接。这样就不须要每次都创建链接在中断链接：

（HTTP1.1中connection默认开启keep-alive）

3.6 无状态的HTTP——cookie

因为HTTP是一种无状态的协议，这是因为Web服务器要面对不少浏览器的并发访问，为了提升Web服务器对并发访问的处理能力，在设计HTTP协议时规定Web服务器发送HTTP应答报文和文档时，不保存发出请求的Web浏览器进程的任何状态信息，从而减轻服务器端的负载，同时无状态也减少了HTTP请求的开销。

但当有些场景须要时刻记住用户的信息时，无状态很明显不能知足需求，所以HTTP提供了cookie来解决这个问题，cookie技术经过在请求和相应报文中写入cookie信息来控制客户端的状态。cookie会根据从服务端发送的相应报文内的一个叫作set-cookie的首部字段信息，通知客户端保存cookie。当下次客户端再往服务器发送请求的时候，客户端会自动在请求头加入cookie值后发送出去。在没有cookie状态下的请求：

当存有cookie后的请求：

简单来讲Cookie是一种由服务器端肯定，并保存在客户端浏览器中的内容。这样就与每次都去添加用户的信息，请求会自动添加cookie中对应的内容。

（关于浏览器端的数据存储感兴趣的能够看下这篇文章：：聊一聊常见的浏览器端数据存储方案）

3.7 范围请求

在一些场景下，咱们在使用HTTP报文请求一些很大的图片时，加载过程每每会很慢。（好比一些摄影网站）这时候咱们就会发现一些图片是一块一块加载的。这是应为设置了HTTP请求的长度，从而分块的加载资源。在请求报文中使用Range属性，在响应报文中使用Content-Type属性均可以进行指定必定本身的HTTP请求。

3.8 报文首部总结

（图转自：http://www.cnblogs.com/xing901022/p/4311987.html）

4.HTTP方法

HTTP 支持几种不一样的请求命令，这些命令被称为 HTTP 方法（HTTP method）。每 条 HTTP 请求报文都包含一个方法。这个方法会告诉服务器要执行什么动做（获取 一个 Web 页面、运行一个网关程序、删除一个文件等）。下表是一些常见的HTTP方法：

HTTP方法	描述
GET	从服务器向客户端发送命名资源
PUT	未来自客户端的数据存储到一个命名的服务器资源中去
DELETE	从服务器中删除命名资源
POST	将客户端数据发送到一个服务器网关应用程序
HEAD	仅发送命名资源响应中的 HTTP 首部

（GET和POST已在上面讨论过了，这里就不在讨论了）

4.一、PUT传输文件

PUT方法用于传输文件，就像FTP协议的翁建上传同样，要求在请求报文的主题中包含文件内容，而后保存到请求URI指定的位置。因为PUT方法不带验证机制，任何人均可以任何人均可以上传文件，存在安全性问题，所以通常的web网站不适用该方法。

4.二、DELETE删除文件

DELETE方法用来删除文件，是与put相反的方法，DELETE方法按照请求url删除指定的资源。其本质和PUT方法同样不带验证机制，因此建议少用DELETE方法。

4.三、HEAD获取报文首部

HEAD和GET方法同样，只是不返回报文主体部分，一般用于确认url的有效性及资源更新的日期时间等。

5.HTTPS

5.1 什么是HTTPS

HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单来讲就是是HTTP的安全版本，即在HTTP下加入SSL层，HTTPS的安全基石是SSL，所以加密的详细内容就须要SSL。 它如今已经被普遍应用，好比GitHub，支付宝，掘金等。

5.2 为何须要HTTPS

这是因为HTTP有这么几个缺点：

• 传输的时候使用明文，这显然会被不法者截取干一些见不得人的勾当。
• 没有认证机制，这样咱们就能够伪造一些HTTP访问，这显然会形成一些困扰。好比Jmeter就是典型的例子，伪造一大堆的HTTP URL而后压力测试，这也就是DOS攻击的一种。
• 没法验证报文的完整性，好比一个HTTP的报文已经被不法者截取而且篡改，而服务器端却没法验证。

5.3 HTTP 与 HTTPS 的区别

正是因为以上这些缺点，HTTPS做出了如下一些改变：

• HTTP 是明文传输，HTTPS 经过 SSL\TLS 进行了加密；
• HTTP 的端口号是 80，HTTPS 是 443；
• HTTPS 须要到 CA 申请证书，通常免费证书不多，须要交费；
• -HTTP 的链接很简单，是无状态的。而 HTTPS 协议则是由 SSL+HTTP； 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全

5.4 HTTPS的缺陷

能够说HTTPS相对于HTTP就是套上了黄金甲的圣斗士，变了身的奥特曼，沉睡了的毛利小五郎，不只仅提高了安全，还提高了逼格。但HTTPS也有一些缺陷：

• 通讯的速度变慢，因为须要加密，一个握手就多了好几个往返；
• 对用户的机器负载的增长。（说出来大家可能不信，咱们学校一到晚上，用HTTPS协议的网站基本上都上不了）

  

6. HTTP认证

有一些网站须要用户的登陆从而获取用户的我的信息来进行接下来的操做，所以须要随时知道这些消息，可是确定不能每次都让用户输入用户密码，这样会让用户感受很不爽，所以HTTP也自带了认证的功能，认证方式主要以下：

6.1 BASIC认证

其中BASIC认证是最简单的认证，大体过程以下：

1. 客户端访问某URL。
2. 服务器端返回401状态码，提示用户输入用户名密码。
3. 用户输入用户名密码，经过BASE64编码传输。
4. 服务器经过认证，返回状态码200

但它有如下缺陷：

1. 仅仅经过BASE64编码，其实仍是属于明文传输，安全性不高
2. 有的浏览器不支持注销

6.2 DIGEST认证

正是因为BASIC认证存在弱点，所以从HTTP/1.1起就有了DIGEST认证，DIGEST认证一样使用质询/响应的方式，但不会像BASIC认证那样直接明文发送密码。

6.3 SSL认证（比较常见）

SSL客户端认证是借由HTTPS的客户端证书完成认证的方式。凭借客户端证书认证，服务器可确认访问是否来自已登陆的客户端。

SSL客户端认证的步骤：

1. 服务器接收到须要认证资源的请求时，服务器会发送CertificateRequest报文，要求客户端提供客户端证书。
2. 客户端将客户端证书信息以Client Certificate报文方式发送给服务器。
3. 服务器验证客户端证书验证经过后才能领取证书内客户端的公开密钥，而后开始HTTPS加密通讯。

像支付宝，网银之类对安全要求很高的网站，在登陆时，都须要下载一个数字认证，这个数字认证就属于一种SSL客户端的验证。但它的缺点也很明显，须要手动下载，对于如今愈来愈懒的网民们来说会感受很麻烦（包括我）

6.4 表单认证（最经常使用的）

最后一种认证方式是最多见的，咱们能够经过cookie或session来进行认证。

Session管理和Cookie应用的结合

我前面提到过，HTTP是无状态协议，没法实现状态管理，所以有了cookie。咱们就可使用Cookie来管理Session（会话），以弥补HTTP协议中不存在的状态管理功能。

认证步骤：

1. 客户端把用户的ID和密码等相关信息放入报文的实体部分，而后一般以POST请求的方式发送给服务器。
2. 服务器会发放用以识别用户的Session ID。经过验证从客户端发送过来的登陆信息进行身份认证，将用户的认证状态和Session ID绑定后记录在服务器端。
3. 客户端接收到Session ID后，会将其做为Cookie保存在本地。下次向服务器发送请求时，浏览器自动发送Cookie，Session ID会随之发送到服务器。服务端经过验证接收到的Session ID识别用户和其认证状态，而后用户就能执行特定的操做了。

参考资料：

1. 《图解HTTP》
2. https://juejin.im/post/59e4c02151882578d02f4aca
3. http://www.cnblogs.com/xing901022/p/4309840.html