HTTP协议详解

前言

什么是HTTP协议？

       在网络中，要对数据进行传输，也就是把数据从一台主机传到另外一台主机。我们就需要对数据格式进行规定，这样接收数据的那一方就知道应该怎么解析或者说是认识这份数据。而协议就是对数据格式进行规定的。HTTP协议就是应用层协议中的常见协议。举个例子，如果你传输数据使用的HTTP协议，那接收方一收到，看见是HTTP协议就知道应该用HTTP协议的方式解析这份数据然后呈现给用户。

什么时候会触发HTTP协议？

看不同应用程序服务端对应用层协议的具体实现。HTTP协议常见用到的地方就是浏览器发送请求。当你在你的浏览器中输入一个网址并敲下回车，这时候你的浏览器就向你输入的网址的服务端发送了一个HTTP请求。而这个http请求就是基于HTTP协议实现的。

举个例子：当我们访问百度的时候，浏览器就会给百度的服务端发送一个HTTP请求，这个请求的意思就相当于询问“我可以访问你吗？”，收到请求后，服务器就会给出对应的响应，响应就相当于对这个发出请求的一种回复，如果同意你访问了，就会给你返回一些数据，这些数据的格式可能有很多，比如html,css，js，图片，视频等，浏览器收到响应之后就会自动把这些数据渲染，最终呈现在用户面前。如下图就是被渲染之后呈现的画面，否则你看到的只是一堆文本。

关于html和css，在我的另外两篇文章中有详细的用法介绍，感兴趣的小伙伴可以看看~

快速上手HTML——总结HTML中常用标签的用法_今天秃头了吗？？的博客-CSDN博客

CSS选择器的常见用法_今天秃头了吗？？的博客-CSDN博客

HTTP请求格式

首行：请求方法 + url(网址） + 协议版本号

header：里面包括很多键值对。每一行一个键值对。键和值用：分割。这里面的键值对都是有有规定的，但是也可以有自定义的。

空行

body：放数据。

下面用抓包工具Fiddler，抓一个HTTP请求。例如我在百度上搜索周杰伦：

用抓包工具抓到发送的请求如下：

我们可以看到这个HTTP请求的请求方式是GET，而它的url是https://www.baidu.com/s?ie=utf-8&csq=1&pstg=20&mod=2&isbd=1&cqid=94640ccb0022df62&istc=884&ver=02ttGAFU_0Xajeud6fDWzu9Z0LN8ZCqNDY_&chk=650f144e&isid=aae5a60d00054dd5&ie=utf-8&f=8&rsv_bp=1&tn=02003390_21_hao_pg&wd=%E5%91%A8%E6%9D%B0%E4%BC%A6&oq=%25E5%2591%25A8%25E6%259D%25B0%25E4%25BC%25A6&rsv_pq=aae5a60d00054dd5&rsv_t=85deIS8Uv%2FgX3hsTb6Nelh9BWufEALKGUhVzZHumVHVzs3UvP%2BlAaaKBdzAm6Cql3SEIx%2F53r%2F8h&rqlang=cn&rsv_dl=tb&rsv_enter=0&rsv_btype=t&rsv_sug=1&bs=%E5%91%A8%E6%9D%B0%E4%BC%A6&f4s=1&_ck=70595.1.81.81.5439453125.23.011573791503906.806.38&isnop=0&rsv_stat=1_0_-1_1_3.&rsv_bp=1

 我们可以看到在百度网址后面还跟了很多字符串，在后续文章讲解url的时候会详细讲里面的含义。

第二行之后就都是header，header中包含很多键值对，后续对header的讲解中，会讲几个比较重要常见的键值对。

然后这个请求是没有body（正文）的。

HTTP响应格式

首行：协议版本号 状态码 状态码描述

header：和HTTP请求的header一样，都是由很多键值对组成。

空行

body：具体要返回给客户端的数据。数据格式可以是json，html，css，图片等等。

还是上述的例子，用抓包工具抓百度搜索周杰伦后，获取的响应：

首行， 说明了协议的版本号HTTP/1.1， 状态码是200，状态码描述是ok,这就表示访问成功了。状态码是2开头的，都表示访问成功了。后续讲状态码时会细讲。

从第二行开始到空行前，都是header，其中header的最后一行即最后一个键值对：Content-Length: 728424，这里表示的是body(正文）的长度。

第二张图片就都是body（正文）里的数据，我们可以看到传的数据是html格式的，后面其实还有css和js（太长了图没有截完）。

而响应中body的数据被浏览器渲染之后就会变成我们看到的页面那样，呈现在用户面前：

HTTPS

HTTPS其实跟HTTP没有本质的区别，唯一的差别就是HTTPS多了一层加密机制，可以保证数据传输的安全性。在HTTP请求中给大家的举例中，用到的也是HTTPS并非HTTP。

 现在很少见到使用HTTP进行数据传输的了，大多都是用HTTPS,就比如CSDN，你现在打开的这个网址前面，也是用的https://,而非http://。

URL

什么是URL？

URL其实就是网址，www.baidu.com，就是一个网址。但是在刚刚百度举例的那个HTTP请求中，为什么网址这么复杂？后面跟了这么多字符串。域名之后也就是www.baidu.com后跟着的就是文件路径。表示百度给你返回的资源是在该文件路径下的。在这个例子中路径就是“/s”,“/s”之后跟着的就是键值对，路径和键值对之间用“？”隔开。而这里键值对，键和值都用“=”进行分割。键值对和键值对之间用&连接。而每个键和每个值，具体表示什么意思，完全是由开发这个服务器的程序员决定的，也就是说我们是不知道他具体的含义的。但是有些键值对我们也可以猜出来表示什么，比如wd，其实就是word的意思。wd后面等于的那一串字符，其实用urldecode解码之后就是周杰伦。表示我们搜索的关键词是周杰伦。

 具体的URL格式：

协议名 + ip地址/域名 + 端口号 + 文件路径 + 查询字符串 + 片段标识符

其中有很多可以省略，如果把协议名省略，那么默认就是http://，端口号如果省略，http协议默认的端口号是80，https默认的端口号是443。文件路径省略就相当于/根路径。查询字符串主要看客户端，比如刚刚的例子中我们搜索了周杰伦，那么我们查询的字符串就是周杰伦。片段标识符就是在同一个页面中定位到不同的位置中。比如在一些文档网站中就比较常见，通过#加字符串定位到不同的知识点片段，但是页面还是application.htm。

URL encode

为什么上面我们搜索的周杰伦，url里面对应的是一堆奇怪的字符呢？这是因为url都是用了url特殊的编码方式，url encode就表示给url进行编码。为什么要编码呢？因为在上述我们讲到的url的结构中，“？”、“/”、“=”以及“&”这些符号都是有特殊含义的，如果直接写上去，浏览器把它们当做普通的字符处理，那么就会引发很多问题，可能你根本就访问不到你想访问的那个网址了，所以这时候我们进行统一的编码，把这些特殊的字符进行转义，让浏览器能够正确识别我们的网址。

对应的url decode就是对url进行解码，比如我们拿上述例子中wd的值去解码，就是周杰伦

Header中常见的键

Cookie和Set-Cookie

出现在HTTP请求的header中，它起什么作用呢？它的作用就是让服务器认识你，记得你是谁。在第一次访问一个网站的时候是不会有cookie的，但是当你访问过一次之后就会有cookie了，这可能是在你第一次请求返回的响应中的header中的Set-Cookie中设置的，也可能是客户端网页自行通过js写入的。浏览器看到Set—Cookie就会把这样的数据保存在浏览器本地。

那么记得你，认识你之后又起什么作用呢？对于服务器来说每个客户的需求是不一样的，有了cookie身份标识之后方便服务器对客户的管理，和个性化定制。当你有了服务器给你的身份标识之后，最常见的作用就是你登录了一个网站，当你关闭这个网页，等一会儿再重新访问这个网站的时候，你还是登录状态，并不会重新让你登录，这就是因为cookie。有时候你很久之后去访问登录一个网站，网页显示“好久不见，欢迎回来”,也是cookie起的作用，因为它把你的身份信息通过HTTP请求发送给了服务器，服务器就可以通过你的身份知道你上次浏览这个网站是多久。

举一个具体例子：在腾讯视频首页，点击地址栏中的小锁，就可以看到当前网站所用的cookie，cookie里面都是简单的键值对，即简单的字符串。所以cookie也不会很占空间。而且cookie也是有过期时间的，一段时间后浏览器会清理一些网站的cookie。

我们现在是腾讯视频登录状态，那么当我们把cookie清理之后会发生什么呢？

刷新页面之后，就发现登录状态没了。

Content-Type和Content-Length

Content-Length:表示 body 中的数据长度。

Content-Type：表示请求的 body 中的数据格式。

User-Agent

如果学过一点爬虫的同学相信对这个不陌生。他们它是干嘛的呢？它是用来表示浏览器/操作系统的属性的。如下：

它设计之初是为了通过客户使用的不同浏览器或者操作系统返回不同的页面。最开始网络发展没这么快，有些浏览器只能支持文本，图片和视频都看不了，但是其他浏览器是可以支持的，为了让使用这些浏览器的客户都能有更好的体验，所以就会根据用户浏览器的信息，返回不同的页面给客户。让能支持图片和视频的浏览器的客户能看到图片和视频，让不能支持图片和视频的浏览器的客户也能正常的访问页面，只不过就是只有文本而已。到后面浏览器的内核都变得强大了，这些问题也就不存在了。后面的问题就变成了PC端和移动端的问题，也就是用电脑浏览网站和用手机浏览网站，页面显示的问题，如果你用手机看电脑显示的页面就会显得很小，也不舒服，所以又会根据不同的操作系统去定制不同的页面返回给客户。但是后面这些都被响应式页面解决了，就是一份页面可以即让PC端用，又可以让移动端用，可以实现自适应。

请求方法

最常见的请求方法就是GET和POST，本文只讲述这两种方法。

GET方法

GET 是最常用的 HTTP 方法. 常用于获取服务器上的某个资源.在浏览器中直接输入 URL, 此时浏览器就会发送出一个 GET 请求.另外, HTML 中的 link, img, script 等标签, 也会触发 GET 请求。

GET请求（用GET方法的请求）的特点

• 首行的第一部分为 GET
• URL 的 query string 可以为空, 也可以不为空.
• header 部分有若干个键值对结构.
• body 部分为空.

POST方法

POST 方法也是一种常见的方法. 多用于提交用户输入的数据给服务器(例如登陆页面)。通过 HTML 中的 form 标签可以构造 POST 请求, 或者使用 JavaScript 的 ajax 也可以构造 POST请求。

POST 请求的特点：

• 首行的第一部分为 POST
• URL 的 query string 一般为空 (也可以不为空)
• header 部分有若干个键值对结构.
• body 部分一般不为空. body 内的数据格式通过 header 中的 Content-Type 指定. body 的长度由header 中的 Content-Length 指定

GET和POST的区别

没有本质的区别，因为GET能做到的POST能做到，POST能做到的GET也能做到，只是一些习惯用法上的差别。

• 语义不同: GET 一般用于获取数据, POST 一般用于提交数据.
• GET 的 body 一般为空, 需要传递的数据通过 query string 传递, POST 的 query string 一般
• 为空, 需要传递的数据通过 body 传递
• GET 请求一般是幂等的, POST 请求一般是不幂等的. (如果多次请求得到的结果一样, 就视为
• 请求是幂等的).
• GET 可以被缓存, POST 不能被缓存. (这一点也是承接幂等性).

关于安全性，GET和POST本质上都是不安全的，因为他们都没有加密操作，要想实现安全的真正机制就是在传输数据的时候加密，比如HTTPS请求。

状态码

状态码是服务器接收到客户端的请求后，给客户返回的状态信息，是成功还是失败。

一般遇到4XX 的主要就是404，这说明你的网址很可能写错了找不到这个网址，或者说这个网址已经不存在了访问不了。403就是拒绝访问，常见的就是如果你是一个为登录的身份去访问一个需要登录的私有页面，就会遇到403。如果学过爬虫的小伙伴，对于403这种错误应该也很常见，当你爬取太多数据，服务器会把你的IP拉黑禁止你访问，因为服务器认为一个正常的用户是无法在短时间内发送这么多次HTTP请求的，这时候他就会认为是有人故意在搞破坏所以禁止访问。

【扩展】HTTPS如何实现安全？

前文说过了，HTTPS是在HTTP的基础上实现了一个加密层。因为HTTP协议是明文传输的，这就导致信息泄露或者被篡改的现象。

当你在网页上想下载一个音乐软件，结果点击下载，却出来浏览器的下载链接，这就是你的响应被篡改了。

为了让数据更安全，不被泄露和篡改，于是我们想到了给数据加密。有两种加密方式，一种是对称加密，一种是非对称加密。对称加密就是，我们通过算法1给数据加密，那么算法1也能给数据解密。非对称加密就是，我们用算法1给数据加密，算法2给数据解密。

那么我们HTTP请求中应该对数据用对称加密还是非对称加密呢？如果客户端和服务端要实现加密数据通信，那么首先这个加密和解密的方法双方都应该知道，才能正常通信。

方案1：用对称加密，服务器先给客户端传递公钥，即告诉客户端以后我们传数据就用这个公钥加密和解密。但是这个公钥要是在传输的时候被黑客劫持了，不是黑客也知道怎么加密解密了吗？所以这个方法行不通。

方案2：用非对称加密，服务器生成公钥跟私钥，公钥用于给数据加密，私钥用于给数据解密。这时候服务器先把公钥发送个客户端，告诉它就用这个给咱俩传输的数据加密，这个时候黑客就算劫持了公钥也没有什么用，因为公钥不能解密只能加密。然后客户端就用这个公钥把数据加密传输给服务器，但是这时候就能传数据了吗？因为私钥只要服务器有，客户端这里是没有的，如果后续服务器传正真的数据返回给客户端的时候用公钥加密，由于客户端这边没有私钥所以也解密不了这个数据，那不就没什么用了吗？所以我们应该在正真的数据传输前，也就是客户端第一次拿到服务器给的公钥的时候，在客户端生成一个对称加密的公钥2，再用公钥1对这个公钥2进行加密，返回给服务器。服务器收到之后就会用私钥进行解密，然后就得到了公钥2。然后用公钥2对数据进行加密发送给客户端。

但是这样就真的安全了吗？？？如果黑客伪装成客户端或者服务器呢？客户端怎么分辨你是真的服务器的响应还是黑客篡改后的？，服务器怎么分辨你是真的客户端还是黑客冒充的？如下图：

所以我们引入了证书，来证明身份。证书是给服务器的身份标识。HTTPS正是利用了证书这一点，实现了安全性。搭建一个HTTPS网站要在CA机构先申请一个证书。这个证书就相当于这个网站的身份证。能够让客户端知道你是真的服务器还是假的服务器。

证书的内容会被计算成一个哈希值和证书内容一起发送给看客户端，这个哈希值是通过特殊的方法计算的，它能够保证唯一性，可以认为如果两个字符串的哈希值相同，那么他们的内容就是完全一样的。

当客户端获取到证书之后，会对证书进行校验（防止证书是伪造的）

• 判断证书是否过期，（或许你访问到一些网站上面提示不安全，证书已过期）
• 判断证书的发布机构是否受信任，我们的操作系统中已经内置了受信任的证书发布机构
• 验证证书是否被篡改，即验证收到证书的哈希值是否和证书内容计算的哈希值匹配。

哈希值是不能够明文传输的，因为明文传输被黑客劫持，黑客直接把证书内容和哈希值，一起给你改了，因为把内容计算成哈希值的方法是大家都知道的都可以用的，所以黑客要实现这一点很容易。如果黑客把证书内容给你修改了，哈希值也给你修改成对应的哈希值，客户端一验证，证书没过期，发布机构也受信任，计算哈希值也匹配，直接就相信了这个假身份，但是或许证书里面真正的网站信息以及被修改了。所以我们得对哈希值进行加密。而这个加密就是服务器在申请证书的时候，证书机构发布给服务器的私钥。服务器在传输证书内容和哈希值的时候，就会用这个私钥给哈希值加密。然后客户端再根据操作系统里面已经存了的证书发布机构的公钥进行解密，得到哈希值进行校验。

这时候还有一个疑问，既然是操作系统里面都能有这个公钥，那黑客岂不是也能得到这个公钥解密出服务器加密的哈希值？是的没错，确实可以解密出来，但是只要解密了，就算你修改了，你加密不回去了，因为黑客没有认证结构给的私钥进行加密，还原不回去人家本来的样子，客户端直接就识破了黑客的假身份。

所以实现HTTPS真正安全通信的流程如下图：