一、HTTP 定义
一种网络传输协议，在tcp/ip协议族中处于顶层---应用层
http html一起诞生，用于网络上请求和传输html内容
URL格式
协议类型：//服务器地址[：端口号] 路径
例如https://www.zhihu.com/question/41101031
报文
请求报文
响应报文
请求方法
1.GET
- 用于获取资源
- 对服务器数据不进行修改
- 不发送body
2.POST
- 用于增加或者修改数据
- 发送给服务器的内容写在body中
3.PUT
- 用于修改资源
- 发送给服务器的资源写在body中
4.DELETE
- 用于删除资源
- 不发送body
5.HEAD
- 和GET使用方法完全相同
- 和GET唯一的区别在于返回的响应中没有body
Status Code状态码
- 1xx：临时性消息。如：100 （继续发送）、101（正在切换协议）
- 2xx：成功。最典型的是 200（OK）
- 3xx：重定向。如 301（永久移动）、302（暂时移动）、304（内容未改变）。
- 4xx：客户端错误。如 400（客户端请求错误）、401（认证失败）、403（被禁⽌）、404（找不到内容）。
- 5xx：服务器错误。
Header首部
报文中的第二部分 ，HTTP消息的metadata。
1.Host
目标主机。不是在网络上用于寻址的，而是在目标服务器上用于定位子服务器的。
2.Content-Type
指定body的类型，主要有：text/html x-www-form-urlencoded multipart/form-data
3.Content-Length
指定 Body 的⻓度（字节）
4.Transfer: chunked (分块传输编码 Chunked Transfer Encoding)
⽤于当响应发起时，内容⻓度还没能确定的情况下。和 Content-Length 不同时使⽤。⽤途是尽早给出响应，减少⽤户等待。
5.Location
指定重定向的⽬标 URL
6.User-Agent
⽤户代理，即是谁实际发送请求、接受响应的，例如⼿机浏览器、某款⼿机 App。
7.Range / Accept-Range
按范围取数据,用于断点续传、多线程下载。
Accept-Range: bytes 响应报⽂中出现，表示服务器⽀持按字节来取范围数据
Range: bytes=<start>-<end> 请求报⽂中出现，表示要取哪段数据
Content-Range:<start>-<end>/total 响应报⽂中出现，表示发送的是哪段数据
7.其他header..
- Accept: 客户端能接受的数据类型。如 text/html
- Accept-Charset: 客户端接受的字符集。如 utf-8
- Accept-Encoding: 客户端接受的压缩编码类型。如 gzip
- Content-Encoding：压缩类型。如 gzip
8.Cache
作⽤：在客户端或中间⽹络节点缓存数据，降低从服务器取数据的频率，以提⾼⽹络性能。
9.Authorization
常用于验证身份，就像登录后以后的请求不再需要登陆账号密码验证
两种主流⽅式： Basic 和 Bearer
Basic ：Authorization: Basic <username:password(Base64ed)>
Bearer：Authorization: Bearer <bearer token>
bearer token 的获取⽅式：通过 OAuth2 的授权流程
REST
简单来说，就是正常使用HTTP，符合 HTTP 规范的设计准则
二、对称加密与非对称加密
1.对称加密
通信双方使用同一个密钥。使用加密算法配合上密钥来进行加密，使用解密算法配合上密钥来进行解密
经典算法如：DES（因密钥太短，逐渐弃用） AES（现在最流行）
2.非对称加密
使用公钥对数据进行加密得到密文，使用私钥对密文进行解密，得到原数据
使⽤⾮对称加密通信，可以在不可信⽹络上将双⽅的公钥传给对⽅，然后在发消息前分别对消息使⽤对⽅的公钥来加密和使⽤⾃⼰的私钥来签名，做到不可信⽹络上的可靠密钥传播及加密通信。
公钥和私钥互相可解，所以非对称加密还可应用再数据签名上。
对原数据的签名，通常是先对原数据进行hash后再签名，为了减小签名的大小。
经典算法如：RSA（签名和加密都可用） DSA（仅用于签名，但速度更快）
相对于对称加密，非对称加密由于更复杂的计算，性能会略差一些
三、HTTPS
HTTP over SSL 的简称，即⼯作在 SSL （或 TLS）上的 HTTP。实际上就是再HTTP之下增加了一个安全层
本质就是在客户端与服务器之间用非对称加密协商出一个对称加密的密匙，然后使用对称加密达到加密传输。
HTTPS建立的大致过程
- 客户端请求建立TLS连接
- 服务端发回证书
- 客户端验证证书
- 客户端信任服务器后，与其协商出对称加密的密钥
- 使用对称加密的密钥进行加密通信
HTTPS建立的详细过程
- 客户端发送消息给服务器，想要建立加密连接了，并附加信息TLS可选的版本集合，可选的加密套件（也就是使用那种算法），客户端随机产生的一个数
- 服务器发送给客户端消息，信息有 TLS版本，各种算法的选择，服务器生成的随机数
- 服务器再发送证书给客户端(证书为一系列数据，如服务器一些信息，服务器公钥，及其签名，以及签名要用的公钥，及这个公钥的密匙。。。。最后到根证书的信息及公钥)
- 客户端用服务器证书签名一下，在发送一个随机数（pre-master secret）
- 通过三个随机数，通过某个算法，计算出一个master secret。然后通过其得出客户端加密密钥，服务端加密密钥，客户端MAC secret 服务端MAC secret
- 客户端通知下服务端，将使用加密通信了
- 发送个测试消息给服务端，看是否能解读
- 服务端也通知客户端，将使用加密通信
- 发送个测试消息给客户端，看能否解读正常
- 在之后，就是建立加密通信后的真正消息了
什么可能会导致建立失败： 比如缺少证书了。。。在证书验证环节断了
作者：星宇V
链接：https://www.jianshu.com/p/a3a04d04f7bb
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
