---

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、HTTP协议格式

HTTP (全称为 “超⽂本传输协议”) 是⼀种应⽤⾮常⼴泛的应⽤层协议。

HTTP 是⼀个⽂本格式的协议。可以通过 Chrome 开发者⼯具或者 Fiddler 抓包, 分析 HTTP 请求/响应的细节。

抓包⼯具的原理—
Fiddler 相当于⼀个 “代理”。
浏览器访问 sogou.com 时, 就会把 HTTP 请求先发给 Fiddler, Fiddler 再把请求转发给 sogou 的服务器。当 sogou 服务器返回数据时, Fiddler 拿到返回数据, 再把数据交给浏览器。因此 Fiddler 对于浏览器和 sogou 服务器之间交互的数据细节, 都是⾮常清楚的。

抓包结果
以下是⼀个 HTTP请求/响应 的抓包结果.

协议格式总结

为什么 HTTP 报⽂中要存在 “空⾏”?
因为 HTTP 协议并没有规定报头部分的键值对有多少个，空⾏就相当于是 “报头的结束标记”,或者是 “报头和正⽂之间的分隔符”，HTTP 在传输层依赖 TCP 协议, TCP 是⾯向字节流的。如果没有这个空⾏, 就会出现"粘包问题。

二、HTTP请求

2.1 URL 基本格式

2.2 URL encode

像 / ? : 等这样的字符, 已经被url当做特殊意义理解了， 因此这些字符不能随意出现。
⽐如, 某个参数中需要带有这些特殊字符, 就必须先对特殊字符进⾏转义.
⼀个中⽂字符由 UTF-8 或者 GBK 这样的编码⽅式构成, 虽然在 URL 中没有特殊含义, 但是仍然需要进⾏转义。否则浏览器可能把 UTF-8/GBK 编码中的某个字节当做 URL 中的特殊符号。

转义的规则如下: 将需要转码的字符转为16进制，然后从右到左，取4位(不⾜4位直接处理)，每2位做⼀位，前⾯加上%，编码成%XY格式。

2.3 “方法” (method)

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

GET 请求的特点
• ⾸⾏的第⼀部分为 GET
• URL 的 query string 可以为空, 也可以不为空.
• header部分有若⼲个键值对结构. • body 部分为空.

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 ⼀般⽤于提交数据.
• GET 的 body ⼀般为空, 需要传递的数据通过 query string 传递, POST 的 query string ⼀般为空, 需要传递的数据通过 body 传递.
• GET 请求⼀般是幂等的, POST 请求⼀般是不幂等的. (如果多次请求得到的结果⼀样, 就视为请求是幂等的).
• GET 可以被缓存, POST 不能被缓存. (这⼀点也是承接幂等性）

2.4 认识请求 “报头” (header)

header 的整体的格式也是 “键值对” 结构.
每个键值对占⼀⾏. 键和值之间使⽤分号分割.
报头的种类有很多, 此处仅介绍⼏个常⻅的
Host

表⽰服务器主机的地址和端⼝.

Content-Length

表⽰ body中的数据⻓度.通过这个长度来处理“粘包”问题，HTTP底层也是基于TCP，连续传输多个HTTP数据报，此时接收方这边的接收缓冲区里面就会积累多个包的数据，应用程序在读取这些数据的时候就需要明确包之间的边界。

Content-Type

表⽰请求的 body 中的数据格式.boby可以传输很多种格式，包括程序员也可以自己约定任意的格式，但有些格式非常常见。
请求中：
1)application/json:数据为 json 格式.
2)application/x-www-form-urlencoded:form 表单提交的数据格式.
3)multipart/form-data: form 表单提交的数据格式(在 form 标签中加上enctyped=“multipart/form-data” . 通常⽤于提交图⽚/⽂件.

User-Agent (简称 UA)

表⽰浏览器/操作系统的属性.
形如: 1 Mozilla/5.0 (Windows NT 10.0; Win64; x64)AppleWebKit/537.36 (KHTML, like Gecko) .
其中 Windows NT 10.0; Win64; x64表⽰操作系统信息 .
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36 表⽰浏览器信息.

Referer

表⽰这个⻚⾯是从哪个⻚⾯跳转过来的.
如果直接在浏览器中输⼊URL, 或者直接通过收藏夹访问⻚⾯时是没有 Referer 的.
Q:referer是否会被篡改（eg.运营商劫持）？
A：十年前这种情况很普遍，后来通过使用HTTPS里面的SSL（网络中用于加密的协议）就能很好解决这个问题。把header和body进行加密，网络上传输的就是密文，想要篡改就需要破解，就算解密成功也不能篡改，因为一旦修改就能被用户的浏览器感知到。

Cookie

本质是一个浏览器这边本地持久化存储数据的机制（数据要存到硬盘里）。
Cookie 中存储了⼀个字符串, 这个数据可能是客⼾端(⽹⻚)⾃⾏通过 JS 写⼊的, 也可能来⾃于服务器 (服务器在 HTTP 响应的header 中通过 Set-Cookie 字段给浏览器返回数据).
往往可以通过这个字段实现 “⾝份标识” 的功能.
每个不同的域名下都可以有不同的 Cookie, 不同⽹站之间的 Cookie 并不冲突.

三、HTTP 响应

3.1 “状态码” (status code)

状态码表⽰访问⼀个⻚⾯的结果. (是访问成功, 还是失败, 还是其他的⼀些情况…).

以下为常⻅的状态码—

• 200 OK 这是⼀个最常⻅的状态码, 表⽰访问成功.
• 404 Not Found 没有找到资源.
• 403 Forbidden 请求的资源没有权限. 表⽰访问被拒绝. 有的⻚⾯通常需要⽤⼾具有⼀定的权限才能访问(登陆后才能访问). 如果⽤⼾没有登陆直接访问, 就容易⻅到 403.
• 405 Method Not Allowed
• 对⽅的服务器不⼀定都⽀持所有的⽅法(或者不允许⽤⼾使⽤⼀些其他的⽅法).eg.你的服务器只支持GET请求，但是你发了POST请求.
• 500 Internal Server Error 服务器出现内部错误（服务器挂了）. ⼀般是服务器的代码执⾏过程中遇到了⼀些特殊情况(服务器异常崩溃)会产⽣这个状态码. 咱们平时常⽤的⽹站很少会出现 500(但是偶尔也能看到)
• 504 Gateway Timeout 当服务器负载⽐较⼤的时候, 服务器处理单条请求的时候消耗的时间就会很⻓, 就可能会导致出现超时的情况. 访问服务器超时，可能是服务器挂了，也可能是网挂了.
• 302 Move temporarily 临时重定向.明明要访问的网站A，A让你去访问B，浏览器就会自动去访问B.
• 301 Moved Permanently 永久重定向. 当浏览器收到这种响应时, 后续的请求都会被⾃动改成新的地址. 301 也是通过 Location 字段来表⽰要重定向到的新地址

状态码小结：

四、HTPPS工作过程（经典面试题）

只要针对HTTPS的数据进行解密，就能得到HTTP格式的数据，前面提到的运营商劫持，无论是修改referer还是修改返回的链接（body），本质上都是明文传输造成的问题。需要引入加密，对上述传输的数据进行保护，主要是针对header和body进行加密。




上述操作，仍有严重的漏洞，黑客仍有办法破解掉其中的加密操作。
服务器也可以创建出一对公钥和私钥，按照同样的方法，冒充自己是服务器。

如何解决上述问题？
引⼊证书。
服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性。

验证证书过程：

HTTPS 工作过程中涉及到的密钥有三组.
第⼀组(非对称加密): 用于校验证书是否被篡改. 服务器持有私钥(私钥在注册证书时获得), 客户端持有
公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器使用这个私钥对证书
的签名进行加密. 客⼾端通过这个公钥解密获取到证书的签名, 从而校验证书内容是否是篡改过.
第⼆组(非对称加密): ⽤于协商⽣成对称加密的密钥. 服务器生成这组 私钥-公钥 对, 然后通过证书把公
钥传递给客户端. 然后客户端用这个公钥给⽣成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥
解密获取到对称加密密钥.
第三组(对称加密): 客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密.
其实⼀切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的.
第⼆组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器.
第⼀组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥.

---

最后，码字不易，如果觉得对你有帮助的话请点个赞吧，关注我，一起学习，一起进步！