TCP/IP协议族

一系列协议组成的一个网络分层模型
为什么要分层？
由于网络的不稳定 所以要分层
具体分层：
Application Layer应用层：HTTP、FTP、DNS
TransportLayer 传输层：TCP、UDP
Internet Layer 网络层:IP
Link Layer数据链路层：以太网、Wi-Fi
网络不稳定的原因：停电 网线被拔掉 网络被占用等 这样就要将信息重传
信息量大 就分块传输 然后分别进行传输 这样哪段数据失败就重新再发一次 不用全部数据都重新发送 就可以节省时间
由于分块存在，就要进行分层(如果都有公共需求，那就将这个需求抽出来)
设置超时等确认消息是否发送成功
TCP/IP:四层模型
HTTP: 把信息分配给TCP层，不传输
TCP：传输层 保证网络的稳定传输(负责编序，分块，然后将信息分配给IP）
IP: 只负责向目标地址传输 不关心数据成功失败 或者数据间是否有关系（寻址）
LINK（数据链路层）:真正的传输数据

TCP连接

什么叫做连接？
TCP是有状态的连接
双方建立一个确认的过程，就是一个连接的过程
TCP连接的建立和关闭
三次握手

image.png

TCP连接的关闭
四次挥手

image.png
具体请看 https://www.jianshu.com/writer#/notebooks/48976798/notes/89443919/preview
上述链接有详细的三次握手 四次挥手讲解

长连接

为什么要长连接？
不释放的连接即长连接----(强制不让其被关闭)
长连接的实现方式：心跳

HTTPS

HTTP over SSL
SSL：Secure Socket Layer ->TLS Transport Layer Secure
定义：在HTTP之下增加的一个安全层，用于保障HTTP的加密传输
本质：在客户端和服务器之间协商出一个对称密钥，每次发送信息之前将内容加密，收到之后解密，达到内容的加密传输。
为什么不直接用非对称加密？
非对称加密太慢
HTTPS连接
客户端请求建立TLS连接（通过TCP）
服务器发回证书
客户端验证服务器证书
客户端信任服务器后，和服务器协商对称密钥
使用对称密钥开始通信(开始使用HTTP,前面都是纯粹TCP)
1.客户端发消息给服务器 告诉服务端我要建立连接，【附加上用什么方式沟通(随机数；TLS版本，是一个序列)；Cipher Suite(加密套件)--我可以接受的对称加密的算法和非对称加密的算法以及hash(哈希)算法】---Client: Hello
2.服务器跟客户端说好的 你建立吧---【附加上用什么方式沟通(服务端随机数，客户端随机数；TLS版本，是一个序列)；Cipher Suite(加密套件)--我可以接受的对称加密的算法和非对称加密的算法以及hash(哈希)算法】Server: Hello
3.服务器证书(服务器地址，证书公钥，证书签名；证书机构公钥，证书机构其他信息；证书机构的签发方)
4.Pre-master Secret(一个随机数)
5.客户端说：我要使用加密通信了(以字节形式)
6.客户端发送：Finished(一大堆消息，把之前消息都包裹起来，使用加密，把信息发给服务端)
7.服务器说：我要开始加密通信了
8.服务器说：Finished(将1-6全部包裹)
双方验证全部结束，客户端就向服务端发送第一个https请求
大致形式如下：

image.png image.png
客户端：服务器证书公钥---唯一一次非对称加密过程
Master Secret:计算密钥
Mac Secret：验证加密
image.png
HMAC：HMAC是密钥相关的哈希运算消息认证码（Hash-based Message Authentication Code）的缩写，由H.Krawezyk，M.Bellare，R.Canetti于1996年提出的一种基于Hash函数和密钥进行消息认证的方法 image.png

上图用来加密和验证身份

在Android中应用
正常使用：直接使用
什么时候会不行？
用的是自签名证书(例如只用于内网的https---例如校园网)
证书信息不全，缺乏证书机构信息
手机操作系统较旧，没有安装最新加入的根证书
怎么办？
自己写证书验证
百度搜索：android https 即可