目录
HTTP简介
HTTP 超文本传输协议(Hyper Text Transfer Protocol)是一个应用层的协议，使用相当广泛，比如我们常说浏览器敲入网址打开网页，浏览器跟后台服务器之间就用的是HTTP，并且也常用于后端各个微服务之间的数据请求和通信。是我们常说的Web技术的基石，也是互联网的基础技术之一。
HTTP的优点
- HTTP有着简单的请求-响应数据模型，非常易于理解。
- 简单快速。客户端向服务器请求服务时，只需要传送请求方法和路径。具有无状态性。
- 他基于TCP，通信过程稳定可靠，并且对开发者透明，可以不关注数据是如何传输的。
- 由于他是应用层的协议，可以方便地实现跨网络传输，通过nginx等网关可以方面地实现跨网络转发。
- 基于HTTP，我们通常可以搭配SSL的数据加密技术，配合成为HTTPS，保证数据通信过程的数据传输安全。
HTTP协议内容
HTTP是W3C和IETF两个国际组织共同推出的标准化计算协议，目前主流的是1.1版本，2.0版本也在逐步推广中，想要查阅协议原文的可以看这里：
HTTP1.1协议（RFC 2616）: https://datatracker.ietf.org/doc/html/rfc2616
HTTP2.0协议（RFC 7540）: https://datatracker.ietf.org/doc/html/rfc7540
2.0在网络传输技术，报文细节方面有很多优化。但对于开发来讲，关联度并不大，所以后续将以目前主流的1.1版协议内容进行介绍。
请求响应模型
对于每一次的网络通信，一定会有发出的数据和返回，在HTTP中就叫做请求（Request）和响应（Response）。比如通过浏览器访问网页，我们要查看的网页url、请求参数等，都在Request对象中，返回的网页内容等，在Response对象中。
请求的数据结构
客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据四个部分组成，下图给出了请求报文的一般格式。
请求行
包含 请求方法(Method) 请求地址(Request-URI ) 协议版本(HTTP-Version ) 三部分信息。举例：
GET https://www.taobao.com HTTP/1.1
请求方式
- OPTIONS：返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送'*'的请求来测试服务器的功能性。
- HEAD：向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。
- GET：向特定的资源发出请求。
- POST：向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的创建和/或已有资源的修改。
- PUT：向指定资源位置上传其最新内容。
- DELETE：请求服务器删除 Request-URI 所标识的资源。
- TRACE：回显服务器收到的请求，主要用于测试或诊断。
- CONNECT：HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
请求地址
就是我们常说的网址，学名是统一资源定位系统（uniform resource locator;URL）。它一般包含以下几部分：
<请求协议>://<用户名>:<密码>@<域名>:<端口>/<uri路径>
请求头部(Request header)介绍
header一般包含的是针对这次请求的附加信息，他不是请求的实际数据。是针对数据的说明，有时也会携带cookie或者token等用于鉴权的信息。
请求正文(body)
是实际的数据部分。他的数据格式一般在header中的content-type中进行说明，常见以下几种：
- application/json ： JSON数据格式
- application/x-www-form-urlencoded ：ajax方式发送默认的类型，form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式）
- multipart/form-data ： 需要在表单中进行文件上传时，使用该格式。该格式下，body中会包含文件内容的起止位置说明信息。
服务器响应消息
HTTP响应也由四个部分组成，分别是：状态行、消息报头(Response Header)、空行和响应正文。
状态行介绍
HTTP 状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型。响应分为五类：信息响应(100–199)，成功响应(200–299)，重定向(300–399)，客户端错误(400–499)和服务器错误 (500–599)：
| 分类 | 分类描述 |
| 1** | 信息，服务器收到请求，需要请求者继续执行操作 |
| 2** | 成功，操作被成功接收并处理 |
| 3** | 重定向，需要进一步的操作以完成请求 |
| 4** | 客户端错误，请求包含语法错误或无法完成请求 |
| 5** | 服务器错误，服务器在处理请求的过程中发生了错误 |
HTTP数据的实际应用举例
看到这里HTTP相关的内容介绍就差不多了，大家可能会有疑问，作为软件开发工程师，我又不是搞通信的，HTTP协议对我有什么用呢？这里我基于自己的经验给大家一些建议：
- HTTP不但是一种通信协议，他的数据格式对我们也非常有用，不管是前端还是后端，还是测试。总要会看，并且能看懂接口的请求和返回数据，才能开心地开发、调试、测试、排查问题吧？
- 基于HTTP数据结构的接口定义，是我们开发过程中的重要规约，一般由开发确定，前端或者其他微服务进行调用，测试也可能会需要基于接口定义进行用例编写。
- 传统的开发中，需要后端完成开发，部署到后端服务器上之后，前端才能调用，进行开发，测试才能进行有针对性的接口用例编写。
- 但现在更加推荐的做法是：后端先定义出接口，通过swagger等方式发布出来，然后各方可以并行工作：
- 后端基于接口定义继续开发
- 前端可以使用mock工具进行数据模式，在不依赖后端的情况下，并行完成开发。
- 测试可以基于接口定义，开始接口用例的编写，待后端开发完部署到服务器后，可以直接进行测试，节约时间。
基于上面推荐的前后端以及测试的并行工作模式，我所在的大禹平台团队，做了有针对性的功能开发，以我们的功能举例：
可以通过页面录入或者导入的方式得到HTTP的接口定义。针对不同的场景，可以有多种使用方式：
- 前端接口mock： 可以在后端服务没有就绪的请情况下，以模拟返回数据的方式进行接口开发。
- 接口执行：通过接口定义直接发起接口请求，查看接口返回数据。
- 作为测试用例的数据源：基于接口定义，可以填写接口入参、提取出参、添加验证条件。判断是否在给定的请求数据下，接口返回了符合预期的数据。
- 生成java定义代码：如果是页面录入的接口定义，我们支持生成带swagger注解的java代码，方便固化接口定义，也给用户多一种选择。
- 接口导出：支持导出json、swagger等方式的数据用到其他场合，并且可以生成word格式的文件进行接口定义存档。
HTTPS简介
HTTPS 协议是 HyperText Transfer Protocol Secure（超文本传输安全协议）的缩写，是一种通过计算机网络进行安全通信的传输协议。
HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包，HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换资料的隐私与完整性。
HTTP 的 URL 是由 http:// 起始与默认使用端口 80，而 HTTPS 的 URL 则是由 https:// 起始与默认使用端口443。
HTTPS 作用
HTTPS 的主要作用是在不安全的网络上创建一个安全信道，并可在使用适当的加密包和服务器证书可被验证且可被信任时，对窃听和中间人攻击提供合理的防护。
HTTPS 的信任基于预先安装在操作系统中的证书颁发机构（CA）。
因此，与一个网站之间的 HTTPS 连线仅在这些情况下可被信任：
- 浏览器正确地实现了 HTTPS 且操作系统中安装了正确且受信任的证书颁发机构；
- 证书颁发机构仅信任合法的网站；
- 被访问的网站提供了一个有效的证书，也就是说它是一个由操作系统信任的证书颁发机构签发的（大部分浏览器会对无效的证书发出警告）；
- 该证书正确地验证了被访问的网站（例如，访问 https://www.runoob.com 时收到了签发给 www.runoob.com 而不是其它域名的证书）；
- 此协议的加密层（SSL/TLS）能够有效地提供认证和高强度的加密。
Google Chrome、Internet Explorer 和 Firefox 等浏览器在网站含有由加密和未加密内容组成的混合内容时，会发出警告。
HTTPS 的实现原理
大家可能都听说过 HTTPS 协议之所以是安全的是因为 HTTPS 协议会对传输的数据进行加密，而加密过程是使用了非对称加密实现。但其实，HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。
HTTPS的整体过程分为证书验证和数据传输阶段，具体的交互过程如下：
证书验证阶段
- 浏览器发起 HTTPS 请求
- 服务端返回 HTTPS 证书
- 客户端验证证书是否合法，如果不合法则提示告警
数据传输阶段
1.当证书验证合法后，在本地生成随机数
2.通过公钥加密随机数，并把加密后的随机数传输到服务端
3.服务端通过私钥对随机数进行解密
4.服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输
为什么数据传输是用对称加密？
首先，非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的；
另外，在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。
为什么需要 CA 认证机构颁发证书？
HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器，而 HTTPS 协议主要解决的便是网络传输的安全性问题。
首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的“中间人攻击”问题。
过程原理
1.本地请求被劫持（如DNS劫持等），所有请求均发送到中间人的服务器
2.中间人服务器返回中间人自己的证书
3.客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输
4.中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密
5.中间人以客户端的请求内容再向正规网站发起请求
6.因为中间人与服务器的通信过程是合法的，正规网站通过建立的安全通道返回加密后的数据
7.中间人凭借与正规网站建立的对称加密算法对内容进行解密
8.中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输
9.客户端通过与中间人建立的对称加密算法对返回结果数据进行解密
由于缺少对证书的验证，所以客户端虽然发起的是 HTTPS 请求，但客户端完全不知道自己的网络已被拦截，传输内容被中间人全部窃取。
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
