一. OSI连接模型
二. 目前主要使用的四层模型
- 应用层
HTTP/HTTPS/FTP - 传输层
TCP/UDP - 网络层
IP - 网络接口层
三. 浏览器以HTTPS访问www.baidu.com发生的事情
- 首先需要将域名转换为ip地址
1.1 在浏览器中访问缓存的静态映射
1.2 如果没有，访问本机host缓存
1.3 仍没有，查找本地DNS服务器
1.4 本地服务器缓存没有，则以迭代的方式去查询根域名服务器（或者本机设置的优先服务器，例如谷歌的8.8.4.4/8.8.8.8），返回.com的顶级域名服务器
1.5 本地服务器再向.com的顶级域名服务器查询baidu.com
1.6 重复进行一直到查询到www.baidu.com，得到对应的IP地址 -
经过多级跳跃找到对应服务器，发起TCP连接申请，进行TCP三次握手
2.1 发起握手请求发送SYN=1同步码，顺序码x
2.2 服务器接到请求，打开连接，返回确认码为x+1，以及自己的顺序码y，表示已打开连接
2.3 客户端接到返回检查确认码，再次返回确认码为y+1表示自己知道已连接
三次握手示意图 - 在TCP连接基础上进行HTTPS请求
3.1 客户端发起HTTPS请求
3.2 服务端接受到该请求，返回一个包含公钥和服务器证书生成的SSL证书，这里的公钥是非对称加密的公钥，该证书不可逆
3.3 客户端取得证书，验证证书机构，这里涉及到CA认证，此处的证书是保证客户端接收到的密钥是目的服务器发出的，未被中间人劫持的，所以这里会传两份数据，一份是明文密钥，一份是证书，证书里包含的明文密钥经过CA加密且进行散列加密的数据，客户端拿到数字证书后使用CA证书的公钥对其进行解密，拿到hash后的数据，再将明文密钥进行hash，这两份数据对比，如果相同，则表示没有被中间人替换，而且这里会包含目标服务器的信息，所以也能保证不会被中间人替换掉整个证书包。
3.4 拿到服务器的密钥后，在客户端生成随机数，作为之后对称加密的密钥，用服务器的公钥对这个随机数进行非对称加密，然后返回给服务器
3.5 服务器拿到数据后用自己的私钥进行解密拿到该随机数，然后以此作为对称加密的密钥进行通信。 -
结束通信，四次挥手断开TCP连接
4.1 客户端发起终止连接的请求，客户端停止发送数据，但是仍可以接受数据
4.2 服务端接到终止请求，回复客户端表示收到，但还是可以发送数据
4.3 服务端将所有数据发送完，发送给客户端停止信号
4.4 客户端接收到终止信号，进入等待状态，再发送给服务端表示收到，服务器收到消息直接关闭连接，客户端等待两个单位时间后再关闭连接
四次挥手
四. 几个思考的点
为什么是三次握手？
保证双方都确保对方收到消息最少需要三次
一次握手，客户端只是将消息发出去，并不知道服务端是否收到
两次握手，客户端知道服务器收到了消息，但是服务端并不知道客户端知道了以上信息-
HTTPS为什么采用非对称加密和对称加密结合？
采用非对称加密是因为需要保证安全，而加上对称加密是因为非对称加密消耗的资源太多，所以只是在最开始连接使用非对称加密
如果只是使用这两者，仍然可能被攻击，因为如果整个过程都被监视，那么中间人完全可以取得所有客户端所知道的信息，在服务器发出公钥时，捕捉到这个公钥，替换为自己的公钥，而客户端生成随机数时，中间人就能拿到这个随机数，然后再用服务端的公钥进行加密，那么所有数据在中间人这里就都是明文的了。所以仍然需要ca证书，保证中间的信息没有被篡改。
中间人攻击原理 证书如何保证中间信息没有被篡改？
在上一个问题中知道，中间人可以通过篡改中间的数据来进行攻击，那么只需要保证中间数据不被篡改就可以，所以在证书里使用了不可逆的加密方式，客户端这边在这块不用解密，在这块对原文进行加密，然后对比结果相同就可以。为什么是四次挥手？
如果不考虑客户端断开连接时，服务端仍可能有未发送完的数据，那么三次挥手就可以，也就是第二次和第三次是放到一起的，但这块必须要考虑。为什么最后一次挥手客户端需要等待两个单位时间再关闭？
因为最后一次挥手可能服务器没收到客户端的第四次挥手信息，那么服务端就仍处于第三次挥手无结果的状态，到一次通信最长时间还无结果，服务器就认为客户端可能没收到该信息，就会重复发一次第三次挥手的信息，如果客户端收到这个信息就会重置等待时间，而这两个时间最长就是两次消息发送的最长时间server端容易受到SYN攻击？
Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时
只能尽快释放这种链接，然后开启短时间的黑名单，将对应ip拉黑（服务器在遭受大量ip撞登录密码时也可以这样处理）
参考
https://blog.csdn.net/qq_29966203/article/details/90448790
https://blog.csdn.net/qq_38984677/article/details/85621784
https://zhuanlan.zhihu.com/p/43789231
