HTTP传输须知TCP/IP通信传输流按照层级细化http传输 1. 应用层HTTP相关加密算法对称加密：发送端和

TCP/IP通信传输流

按照层级细化http传输

1. 应用层HTTP相关

加密算法
- 对称加密：发送端和接收端使用相同的密钥【长度越长解密越难】
- 非对称加密也叫公开密钥加密：发送端和接收端使用不同的密钥，采用的是RSA算法（模运算）
HTTP/HTTPS
- HTTPS = HTTP + SSL/TLS
- SSL和TLS的区别：现在我们所用的其实是TLS的协议，TLS是SSL的升级协议，基于SSL上的优化，只是大家习惯统称为SSL
- HTTPS需要CA证书，采用的是混合加密方式，HTTP是明文传输不加密
- HTTP和HTTPS的连接方式不同，端口也不同，HTTP默认80，HTTPS默认443
- 经常说的跨域：怎么算跨域，域名，协议，端口不同都算跨域，判断截止到端口
- HTTPS是如何保证安全的【使用非对称加密实现身份验证和密钥协商+使用对称加密算法对数据加密，对称加密的密钥通过非对称加密的公钥加密后发送】

cookie

HTTP是无状态协议，无状态协议指不对请求和响应的状态进行管理和存储，识别当前用户实现会话持久化的当下最好的方式是cookie，cookie也叫HTTP状态管理机制
- cookie分为会话cookie和持久cookie，会话cookie是浏览器关闭后就被销毁，持久cookie存储在内存中，下次打开网页还会带cookie，持久cookie和会话cookie通过设置Expires、Max-Age
- Expires、Max-Age都没有设置就是会话cookie，两个都设置Max-Age优先级高，Max-Age设置的当前 cookie开始的秒数，Expires设置的是具体的时间
- Secure属性表示只有在https下才发送设置的cookie，HttpOnly属性表示不能用js相关语法获取到cookie，只有浏览器发出http会自己带上
- 前端对cookie的读写
```
document.cookie = 'test1=hello';
document.cookie = 'test2=world';
document.cookie// test1=hello;test2=world
document.cookie一次只能写入一个，写入并不是覆盖是添加
document.cookie一次可以读出全部cookie，一次只能写入一个cookie
各个属性写入注意
path:默认当前路径，为绝对路径
domain：默认为源域名
max-age:秒数
expires： UTC 格式，可以使用`Date.prototype.toUTCString()`进行日期格式转换
谷歌浏览器下测试过程
域名：
http://integration.m.myweimai.com/new/innovation/innovatevip/item_detail.html?id=1687105084955168770
cookie设置：
document.cookie = "bar=1; expires=Fri, 31 Dec 2022 23:59:59 GMT;";
设置的结果：
name:bar value:1 domain:integration.m.myweimai.com
path:/new/innovation/innovatevip
expires/max-age:2022-12-31T23:59:59.000Z
对cookie的增删改查
增加：document.cookie = "bar=1"; 
删除：document.cookie = "bar=1;max-age=-1"; 
     删除一个现存 Cookie 的唯一方法，是设置它的时间属性为一个过去的日期
修改：document.cookie = "bar=2"; 只能修改同一domain和path下的cookie，
     domain和path有一个不相同都不会修改，会创建新的cookie
查看：document.cookie
```
- 注意：
  
  1、限制不同域名对 cookie 的访问，不同二级域名是无法共享 cookie 的
  
  2、子域名可以访问主域名的 cookie ，例如 foo.site.com 能访问 site.com 下设置的 cookie【如果子域名和主域名设置了同一个key值的cookie，在浏览器传输的过程中两个值都会带过去，具体哪个在前哪个在后测试结果不一致，本人测试无论写入顺序如何都是主域名在后，其他人测试是按照写入顺序来的，同样是谷歌，可能我是直接用mp.weixin.qq.com/ 自己写document.cookie测试的，同事用自己干净的项目测试，后续继续测试】
  
  3、历史原因， .site.com 跟 site.com 设置效果是一样的
- 浏览器的Application中cookie有值但是http的请求头并没有带cookie过去，为啥？
  
  因为我用的请求库是ajax,ajax实现方式底层逻辑是XMLHttpRequest，XMLHttpRequest有一个属性withCredentials，该属性可以决定请求是否带cookie,该属性默认为false
cookie、session、token的区别和联系【基于第三点引入】
- cookie通过服务端Set-Cookie设置cookie,浏览器发出HTTP请求自动携带cookie，是大多数状态管理机制的基石
- session和token都是一种状态管理方案
- session【通常种在cookie上/数据存储在服务器】：种在cookie上的是一个sessionId,这个ID可能用来查一些用户信息、session 状态等等，这些信息是存储在服务器的，存储可以选择（Redis：优先推荐速度快；内存：重启就没了；数据库：慢）存在一个分布问题？不明白后续问问服务
- token【客户端存cookie或其他/数据存在客户端】：携带的信息token信息可以通过cookie或者其他方式进行传递，服务端不保存数据，验证是否有效即可
- session有效期看服务器中session状态的过期时间，token有效期看token中塞入的过期时间对比

2. 传输层TCP/UDP相关

在传输层中有两个性质不同的协议：TCP(Transmission Control Protocol 传输控制协议)、UDP(User Data Protocol 用户数据报协议)

TCP和UDP的对比

对比项	TCP	UDP
是否连接	面向连接：有三次握手	无连接：应用层将数据给传输层UDP协议,UDP增加UDP标识头直接下发给网络层，只是数据报文的搬运工
是否进行分组，拆包	数据包大的情况下TCP会拆包，通过IP分组来传输	不进行分组拆包
传输方式	面向字节流：进行拆分标识上tcp的端口号，IP地址号	面向报文：对应用层下发的数据不合并，不拆分，保留边界原样传输
首部开销	最少20字节，最多60字节	8字节
连接对象个数	一对一：个人理解是因为TCP的连接是是通过4个值<源IP地址、源端口号、目的IP地址、目的端口号> 端口号保证连接到正确的应用程序，IP地址保证连接到正确的计算机	一对多，一对一，多对一，多对多
适用场景	适用于实时应用，例如视频会议、直播	适用于要求可靠传输的应用，例如文件传输
可靠性	可靠传输：三次握手确认，拆包IP分组保证顺序、流量和拥塞控制、消息重发机制	不可靠：不确认、不重发、无流量拥塞控制、无顺序

【TCP传输：三次握手、数据传输、四次挥手】

TCP三次握手

握手流程描述：【标记位：syn=1表示创建连接，ack=1表示确认号有效，fin=1表示断开连接，rst=1表示TCP连接出现异常，需要断开】

最开始客户端和服务器都是close状态，服务器主动监听端口处于listen状态
客户端主动发起连接请求，生成序列号(为了解决网络包的乱序)seq=x,标记位SYN=1,携带seq=x,SYN=1发送到服务端，客户端状态更改为SYN_SEND
服务端接收到SYN=1后，生成自己的序列号seq=y,确认号ack=x+1表示服务端收到了客户端的序列号x携带seq=y,ack=x+1,标记位ACK=1,SYN=1发送到客户端，服务端状态更改为SYN-REVD
客户端收到服务端的序列号后，携带标记位ACK=1,确认号ack=y+1,自己发送的序列号seq,客户端状态更改为ESTABLISHED[已建立的]
服务端收到客户端的确认消息后也进入ESTABLISHED状态，双方进行数据传输

TCP数据传输

TCP数据传输使用非对称加密传输的对称加密密钥来传输数据，TCP按照字节流传输，对于大数据包进行拆包分组用IP分组（IP数据报）来进行传输，IP分组中包含的的数据:
- IP头部（源IP地址，目的IP地址，数据长度等，IP地址来标识找到正确的计算机）
- TCP头部（TCP标识符，TCP端口号，数据排序完整性等标识，端口号标识找到正确的应用程序）
- TCP数据块
TCP四次挥手

挥手流程描述（断开连接双方都有权利，以客户端主动断开为例）

握手后双方都处于ESTABLISHED状态，客户端发起结束连接的请求，携带标志位FIN=1，序列号seq=u，发送报文给服务端，客户端进入FIN-WAIT1状态，该状态是等待服务端确认
服务端收到客户端报文，携带标识位ACK=1,序列号seq=v,确认号ack=u+1发送报文给客户端，服务端进入CLOSE-WAIT，该状态是TCP半关闭状态，客户端到服务端的连接释放，客户端不发送数据给客户端
客户端接收到服务端确认消息，状态更改为FIN-WAIT2，等待服务端发出释放连接报文端，服务端发送完自己未发完的数据后，携带FIN=1,ACK=1,seq=w,ack=u+1信息发出断开连接请求给客户端，服务端状态进入LAST-ACK，等待客户端确认
客户端收到服务端断开请求的报文消息，携带ACK=1,seq=u+1,ack=w+1回应服务端，自己进入TIME_WAIT状态
服务端收到客户端的确认消息，进入CLOSE状态，客户端需要继续等待2MSL（最大分段使用使用期的两不倍，通常是2分钟），2分钟后未收到服务器的响应，客户端进入CLOSE状态
备注：MSL【Maximum Segment Lifetime 最长报文段寿命，指的一个IP数据报可以经过的最大路由数，每经过一个路由器，它的值就减1，当此值为0则数据报被丢弃，同时发送ICMP报文通知源主机】

数据包+TCP头
TCP重传机制，流量拥塞机制

可以看看这个juejin.cn/post/684490…

6.TCP/IP五层协议和OSI的七层协议对应关系如下：