最近看了《图解HTTP》这本书，对一些基础知识有了更新的了解，在这里分享出来，如果有什么纰漏，请指出。
HTTP请求
HTTP请求报文分为请求行,首部(通用，实体，请求),内容实体
GET / HTTP/1.1
Host: hackr.jp
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: Keep-Alive
Date: Sat, 18 Aug 2018 03:51:58 GMT
HTTP响应报文报文分为响应行,首部(通用，实体，请求)，响应体
HTTP/1.1 200 OK
Date: Sat, 18 Aug 2018 03:51:58 GMT
Server: Apache
Last-Modified: Tue, 08 Jan 2013 08:53:29 GMT
ETag: "25e-4d2c3145df440-gzip"
Accept-Ranges: bytes
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 379
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
请求报文和响应报文中的通用和实体首部都是公用的，其他的又一些区别。
- 公共部分
通用首部：
- Date:创建报文时间
- Cache_control:缓存指令
- Connection:管理持久连接实体首部：
- Content-Encoding:服务器对实体的主体选用的编码方式
- Content-Language:自然语言
- Content-Length:主体大小
- Content-Type:主体内对象的媒体类型
- Last-Modified:最终修改时间
- 差异部分
- 请求报文
- 请求行:
- 请求方法
GET - 请求资源
- 协议版本
HTTP/1.1
- 请求方法
- 请求行:
GET / HTTP/1.1
-
请求首部:
- Host:请求资源所在服务器
- User-Agent:客户端信息
- Accept:用户可处理的媒体类型
- Accept-Encoding:客户端接收优先内容编码
- Accept-Language:客户端接收优先语言
以下是补充： - Referer:请求的原始资源URI(网页中一般会用到，可以知道当前请求是从哪个页面发起的)
- If-Modified-Since:告知服务器资源如果在某个时间更新了就处理请求，反之返回304Not Modified
Host: hackr.jp
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: Keep-Alive
- 请求体：客户端发送给服务器的具体数据
- 响应报文
- 响应行：
- 协议版本：HTTP/1.1
- 状态码：200(2xx成功，3xx重定向，4xx客户端错误，5xx服务器错误)
- 原因短语：OK
- 响应行：
HTTP/1.1 200 OK
-
响应首部：
- Server:服务器应用程序的信息
- ETag:实体标识(资源的唯一标识)
- Accept-Ranges:范围请求(可处理的为bytes，反之为none)
- Vary:源服务器向代理服务器传达缓存使用方法(对缓存进行控制)
Date: Sat, 18 Aug 2018 03:51:58 GMT
Server: Apache
Last-Modified: Tue, 08 Jan 2013 08:53:29 GMT
ETag: "25e-4d2c3145df440-gzip"
Accept-Ranges: bytes
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 379
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
- 响应体：服务器返回给客户端的数据实体
接下来介绍下HTTPS
先思考几个问题？
1.为什么会出现HTTPS？
2.HTTPS的本质是什么？
3.HTTPS的通信过程
好的，那我们来一个一个慢慢的来解决疑惑吧。
1.为什么会出现HTTPS？
HTTPS的出现主要是为了弥补HTTP的一些不足
- 通信明文传输，内容有被窃听的风险
- 通信方的身份没有进行验证，我们可能会遇到"骗子"
- 报文的完整性无法得到证明，那我们怎么知道这是不是已经被别人篡改过了
那么解决方案是什么了？
通信加密防止被窃听
- 通信加密：HTTP+SSL(TLS)的组合使用，可以加密HTTP的通信内容
- 内容加密：通过对称加密和非对称加密两种方式实现
- 对称加密：就是加密和解密用的是同一个密钥(key)
- 非对称加密：加密和解密使用的是一堆密钥，加密的称为公钥(public key)，解密的称为私钥(screct key)
通信方的身份没有进行验证，我们可能会遇到"骗子"
- 想一想我们如何确定一个陌生人的身份？
身份证是一个很好证明每个人的身份的证件，那么在网络里面什么承担了这个角色了？你猜对了，那就是CA证书，通过证书我们可以证明通信方就是意料之中的服务器，不是"隔壁老王"
报文的完整性无法得到证明，那我们怎么知道这是不是已经被别人篡改过了
应用层在发送数据是附加MAC的报文摘要，可以查值报文是否被篡改，保护报文的完整性
2.HTTPS的本质是什么？
HTTPS就是HTTP+加密处理+认证+完整性保护或者可以理解为披着SSL外皮的HTTP(这个和披着羊皮的狼是两码事情喔)
3.HTTPS的通信过程？
对称加密加密速度快，但是很难保证密钥的安全性
非对称加密只要key的位数够长，以目前的条件来讲破解掉是一件比较困难的事情，但是存在一个问题：非对称加密的速度比较低，
所以HTTPS是采用了对称加密和非对称加密混合机制
非对称加密还有一个问题，那就是证明公钥的正确性，CA机构正好解决了这个问题
企业申请CA证书的一个大致流程
- 服务器的相关人员向CA机构提出公开密钥的申请
- CA验明申请者身份的正确性后，对申请的公钥进行数字签名(sign)
- 分配公钥，绑定在证书里一起发给客户
step1: Client发送Client Hello 报文开始SSL通信
step2: Server端ok的话就Server Hello 报文作为应道
step3: Server发送证书报文，包含公钥(public key)
step4: Server发送Server Hello Done 告知Client最初握手完成了喔
step5: Client 以Clinet Key Exchange 报文回应，客户端会生成一个Pre-master secret的密钥，然后通过服务器的公钥(public key)加密这个pre-master-sercet
step6: Client发送 Change Cipher Spec报文提示服务器以后我们会采用pre-master-sercet这个东东来进行加密喔
step7: Client发送Finished 报文
step8: Server同样发送Change Cipher Spec报文
step9: Server发送Finished报文
step10:报文交换完毕以后，SSL连接就算建立成功，以后就可以发送HTTP请求了
step11: HTTP响应
step12: 最后由客户端断开连接(发送close_notify报文)
