OSI 模型
应用层: 计算机用户，以及各种应用程序和网络之间的接口，其功能是直接向用户提供服务，完成用户希望在网络上完成的各种工作。
HTTP SMTP FTP DNS
表示层: 负责数据格式的转换，将应用处理的信息转换为适合网络传输的格式，或者将来自下一层的数据转换为上层能处理的格式。
会话层: 建立和管理应用程序之间的通信。 ``
传输层: 监控数据传输服务的质量，保证报文的正确传输。 报文 TCP | UDP
网络层: 通过路由选择算法，为报文通过通信子网选择最适当的路径。 数据报 IP | ICMP | ARP | RARP
数据链路层: 过各种控制协议，将有差错的物理信道变为无差错的、能可靠传输数据帧的数据链路。 帧 MAC
物理层: 解决硬件通信的问题 比特
TCP
基于连接, 提供可靠传输, 适合对网络通讯要求高的场景, 如: 传输文件、发送邮件、浏览网页等。
UDP
非连接, 提供不可靠交付, 适合网络通讯要求弱的场景, 如: 视频、语音、直播等
响应状态码
200 请求成功
404 请求资源不存在
401 未验证, 需要进行身份验证
500 服务器错误, 无法完成请求(参数错误、请求方式错误无法响应)
流程
HTTP 与 HTTPS 的区别
HTTP与HTTPS都是位于应用层的数据传输协议, 它们最大的区别在于 HTTPS 对数据的安全性给予保障。
安全性
HTTP 明文传输未经过加密, 不需要使用证书; HTTPS 使用 SSL | TLS 协议进行加密, 通过证书授权来验证身份进而实现通信加密
连接方式
HTTP 是无状态协议, 服务端不保存请求信息; HTTPS 是基于安全连接的, 服务端会保存客户端的会话状态。
客户端向服务端发送 SYN 包, 如果服务端同意返回 SYN+ACK 确认, 客户端收到后再发送 ACK , 服务端收到后即可建立连接。
举例: A 与 B 隔着墙丢沙包, A说: “你可以听到我说话吗?”; B说: “可以听到”; A再说: “那我开始丢沙包了”
问题
1) 为什么不能两次握手?
为了防止已经失效的请求再次请求服务器 - 客户端挂掉的请求再次发送, 会导致服务端陷入长等待。
为了确定双方都具有收发信息的能力
2) 可以四次握手吗?
理论上是可以的, 但是三次握手就可以确保双方都拥有收发信息的能力, 4次多余了一次做了无用功。
四次挥手
已经传输数据完毕的客户端和服务端断开连接时, 客户端发送 FIN 报文标识要关闭连接, 服务端收到后发送 ACK 报文询问是否关闭并进入关闭等待状态(资源整理关闭的时间), 在处理等待完之后再次发送 FIN 字段标志服务端已经准备好关闭了, 此时客户端发送确认到服务端, 服务端关闭服务, 客户端进入超时等待。
举例: A 和 B 打电话，通话即将结束后，A 说 “我没啥要说的了”，B 回答 “我知道了”，于是 A 向 B 的连接释放了。但是 B 可能还会有要说的话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，于是 B 向 A 的连接释放了，这样整个通话就结束了。
问题
1) 为什么不可以三次挥手?
三次挥手一般指的是将服务端发送 ACK+FIN 报文的过程合并为一次, 这时服务端就无法保证服务端数据是否发送完毕。 与下面的问题等价↓
2) 为什么连接的时候是三次握手，关闭的时候却是四次握手？
在建立连接时服务端收到客户端的SYN连接报文后, 服务端发送SYN用于同步, ACK报文用于应答, 这时并没有数据处理过程自然也不需要等待。但是关闭连接时服务端收到FIN报文时, 很可能还需要发送数据, 这时服务端就会先发送 ACK 报文应答, 然后等待服务端数据发送完毕再发送FIN字段标志发送完毕。
3) 为什么客户端要等待超时时间 2MSL？
①保证客户端发送的最后一个ACK报文段能够到达服务器。 ②防止已经失效的连接请求报文段出现在本连接中(客户端在发送完最后一个ACK报文段后，再经过时间2MSL。就可以使本连接持续的时间内所产生的所有报文段都在网络中消失。这样就可以在下一个新的连接中不会出现这种旧的连接请求报文段)。
Cookie
是以键值对的形式储存在浏览器中，而且在浏览器中可以直接看到数据。
优点：
缺点：
Session
session 存储在服务器中，然后发送一个cookie存储在浏览器中，cookie中存储的是session_id，之后每次请求服务器通过session_id可以获取对应的session信息
优点：
缺点：
JWT
JWT 存储在浏览器的 storage 或者 cookie 中。由服务器产生加密的json数据包括：header，payload和signature三部分组成。header中通常来说由token的生成算法和类型组成；payload中则用来保存相关的状态信息；signature 部分由 header，payload，secret_key 三部分加密生成。 注意，不要在 JWT 的 payload 或 header 中放置敏感信息，除非它们是加密的。
优点：
缺点：
