这是我参与8月更文挑战的第四天，活动详情查看：8月更文挑战
http协议
HTTP是一个无状态的超文本传输协议。
主机名：localhost.com
端口：8080
对象路径：/index.htm
Set-Cookie的字段属性：
NAME=VALUE：赋予Cookie的名称和值；
expires=DATE: Cookie的有效期；
path=PATH: 将服务器上的目录作为Cookie的适用对象，若不指定，则默认为文档所在的文件目录；
domin=域名：作为Cookies适用对象的域名，若不指定，则默认为创建Cookie的服务器域名；
Secure: 仅在HTTPS安全通信是才会发送Cookie；
HttpOnly: 使Cookie不能被JS脚本访问；
GET 请求的一些特性：
- GET 请求可被缓存
- GET 请求保留在浏览器历史记录中
- GET 请求可被收藏为书签
- GET 请求不应在处理敏感数据时使用
- GET 请求有长度限制
- GET 请求只应当用于取回数据（不修改）
POST 请求的特性：
- POST 请求不会被缓存
- POST 请求不会保留在浏览器历史记录中
- POST 不能被收藏为书签
- POST 请求对数据长度没有要求
浏览器发出的POST请求的body的主要格式
- application/x-www-form-urlencoded 用来传输简单的数据，如 "key1=value1&key2=value2" 这样的格式。
- multipart/form-data 主要用来传输文件内容。
- application/json 告诉服务端消息主体是序列化后的 JSON 字符串。
- text/plain 纯文本格式
HTTP应答状态码
| 状态码 | 类别 | 描述 |
|---|---|---|
| 1xx | Informational(信息性状态码) | 请求正在被处理 |
| 2xx | Success(成功状态码) | 请求处理成功 |
| 3xx | Redirection(重定向状态码) | 需要进行重定向 |
| 4xx | Client Error(客户端状态码) | 服务器无法处理请求 |
| 5xx | Server Error(服务端状态码) | 服务器处理请求时出错 |
HTTP缺点
- 通信使用明文，可能被窃听
- 不验证通信方的身份，可能遭遇伪装
- 无法证明报文的完整性，有可能遭遇篡改
相信大家对http都已经烂熟于心，就不再过多的赘述了！
https协议
HTTP协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险，而协议TLS/SSL具有身份验证、信息加密和完整性校验的功能，可以避免此类问题发生。
https加密原理
加密类型
加密算法可以分为对称加密和非对称加密：
-
对称加密： 双方使用的同一个密钥，既可以加密又可以解密，这种加密方法称为对称加密，也称为单密钥加密。
- AES加密算法： 秘钥的长度可以是128、192、256位；
- DES算法： 秘钥的长度是64位，8个字节；分组加密（将数据分成固定长度的数据块，速度快，适合对大量数据加密）
- 3DES算法： 在DES的基础上，用三个不同的秘钥进行三次加密提高密文强度。
- RC2和 RC4： 用变长密钥对大量数据进行加密，比 DES 快；
优点： 速度快，对称性加密通常在消息发送方需要加密大量数据时使用，算法公开、计算量小、加密速度快、加密效率高。
缺点： 在数据传送前，发送方和接收方必须商定好秘钥，然后 使双方都能保存好秘钥。其次如果一方的秘钥被泄露，那么加密信息也就不安全了。
-
非对称加密： 一对密钥由公钥和私钥组成（可以使用很多对密钥）。私钥解密公钥加密数据，公钥解密私钥加密数据（私钥公钥可以互相加密解密）。例如，RSA、Elgamal、背包算法、DSA、ECC（椭圆曲线加密算法）。
- RSA算法： 生成一对公钥私钥，相互加密解密；它的安全程度取决于秘钥的长度，目前主流可选秘钥长度为 1024位、2048位、4096位等。
- DSA算法： 和 RSA 不同的是 DSA 仅能用于数字签名，不能进行数据加密解密，其安全性和RSA相当，但其性能要比RSA快。
使用最广泛的是RSA算法，Elgamal是另一种常用的非对称加密算法。
缺点： 速度较慢
优点： 安全
也可以分为单向加密和双向加密：
单项加密就是加密后不可解，而双向加密就是加密后可解；比如一些签名算法就是单项加密算法：
MD5：常用于校验数据的完整性、数据(消息)摘要、数据加密等；
SHA1：SHA算法系列是中数据摘要算法，由于数据摘要比较长，比起md5，其运算速度更慢。SHA1主要应用于CA和数字证书中，另外在互联网中流行的BT软件中，也是使用SHA1来进行文件校验的。
数字证书
在建立https连接的之前，客户端需要对服务端进行身份验证，确定公钥的获取途径是合法的，需要引入第三方机构CA，CA负责核实拥有者的身份信息，并颁发证书。基本原理是对关键信息用私钥加密，并且将公钥公开发布。这样客户端就可以用公钥验证签名。
CA证书一般会包括：颁发机构，版本，使用者，公钥，有效时间，数字签名hash值和签名hash算法等。
客户端如何校验CA证书？
客户端用公钥解密证书中用私钥加密的hash值，得到一个hash-a；然后再利用证书内的签名h6666666666666666666666666ash算法生成一个hash-b，如果这两个值相等，那么就证书是正确的。服务端可以信任，否则，浏览器就会给出相应的提示。当然，校验过程不仅是校验（数字签名）hash值，还会校验有效时间，域名匹配等等。
详细讲解ssl握手过程：
- 首先，客户端访问服务端的时候会生成一个随机数1，然后把随机数和支持的ssl版本号以及加密算法等信息发送个服务端。
- 服务端B接收到这些信息后，首先确认一下双方的加密算法，然后服务端也生成一个随机数2，然后将随机数2和CA机构颁发的证书一起返回给客户端。
- 客户端得到CA证书后，回去校验CA证书的有效性，校验通过后，客户端再生成一个随机数3用公钥加密并传输给服务端。
- 服务端得到加密后的随机数3密文，然后利用私钥进行解密，得到明文随机数3.
- 最后客户端和服务端都同时有了随机数1,2,3然后双方都利用这三个随机数生成一个对称的对话秘钥。之后传输的内容通过这个秘钥进行加密解密，也就是对称加密。一般运用得是AES算法。
- 客户端会再通知服务端后面的通讯用该对称秘钥传输，并且告诉他自己的握手过程结束。
- 服务端也会通知客户端后面会用这个对称秘钥传输，然后告诉他握手结束。
- 可以开始传输数据了。
数字签名
在数据的传输过程中，如果黑客不能拿到传输的实际数据，他们就会想其他的办法，比如，可以篡改其中的内容或者是伪造一份数据发送给接收方，这样带来的损失可能是不可估量的。为了防止这样的情况发生，就有了数字签名。所谓数字签名就是发送方将发送的数据通过单项加密算法记性加密，然后同发送的数据一起发送给接收方，接收方拿到数据后，用相应的加密算法对数据进行加密，判断和数字签名的值是否相等，如果不相等就说明被篡改了，于是就可以及时发现，提出解决办法。
这里注意，在黑客解不开加密的真实数据的时候，他肯定是不能伪造这个数字签名的，因为他不知道明文，怎么能伪造数字签名呢？
数字证书到底有什么用？
有人觉得，非对称加密中，数字证书可以是多余的，用数字签名就可以保证数据不被篡改！而且凭借非对称加密的安全性，可以高枕无忧！其实不然！
假设不用数字证书进行验证。在服务端再传输公钥给客户端的时候，黑客劫持了这一数据，发现是服务端传输的公钥，这时候他将自己生成的公钥发送给了客户端，自己就保持着自己拥有的私钥。这样，一旦服务端发送数据过来，就会被黑客劫持，然后解密其中的内容，紧接着，他就用自己的私钥将生成另外一段和这个内容相关但是不正确的密文发送给你，而你持有的是黑客的公钥，也就顺理成章的解开了他发送的密文，也就成功的上套了！
从上面的分析来看，数字证书的存在就是为了验证公钥是否可靠，服务端是否值得信任。
那么又有人问了，数字证书有没有可能被伪造或者篡改呢？
要知道，CA证书中包含CA的数字签名，并且用私钥对证书的摘要进行加密的，而证书是公开的，即便篡改证书的内容，但是签名是无法伪造的，客户端也能及时发现证书已经被篡改了！
