网络12312

• 七层结构
  1.应用层
  2.表示层。编解码，亚索
  3.会话层（session层）应用程序之间交互
  4.传输层（tcp、udp）
  5.网络层
  6.物理链路
  7.物理层
• 对称加密的密钥是非对称加密过的
  HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。
• http2和1.1的区别
  1.多路复用，一个tcp链接可以同时传输多个请求和响应（1.1比1，支持了长连接，但不支持同时）
  2.二进制传输。节约带宽
  3.支持头部header压缩(HPACK算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。)
  4.支持服务器推
• localStorage受到同源策略的限制。为啥token安全
• jwt（主要优势是服务器不需要存储会话信息）
  Header : 描述 JWT 的元数据，定义了生成签名的算法以及 Token 的类型。Payload : 用来存放实际需要传递的数据Signature（签名）：服务器通过 Payload、Header 和一个密钥(Secret)使用 Header 里面指定的签名算法（默认是 HMAC SHA256）生成。
  即使jwt泄漏，也不能更改paylod。因为为服务端拿到 JWT 之后，会解析出其中包含的 Header、Payload 以及 Signature 。服务端会根据 Header、Payload、密钥再次生成一个 Signature。拿新生成的 Signature 和 JWT 中的 Signature 作对比，如果一样就说明 Header 和 Payload 没有被修改。
• 请求和响应的结构
  
• MSS：除去 IP 和 TCP 头部之后，一个网络包所能容纳的 TCP 数据的最大长度。
• 200成功、301永久重定向，302临时重定向，400 bad request，403 无权访问，404 请求资源不存在，500服务器错误，502 bad gateway
• 粘包
  粘包指发送端发送若干数据包，接收端发生粘合，无法区分界限
  tcp本身只是一个面向字节流的传输协议，不会提供包界限的标识，需要在应用层解决粘包问题
  解决方法：
  1 固定长度
  2 特殊分隔符
  3 固定消息格式
• http解决粘包
  HTTP 协议通过设置回车符、换行符作为 HTTP header 的边界，通过 Content-Length 字段作为 HTTP body 的边界，这两个方式都是为了解决“粘包”的问题。
• tcp字节流，udp报文传输
• http请求报文头属性accept开头居多，对应相应报文content-type居多
• HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。
• https加密过程
  客户端向服务器发送 HTTPS 请求。
  服务器将公钥证书发送给客户端。
  客户端验证服务器的证书。
  如果验证通过，客户端生成一个用于会话的对称密钥。
  客户端使用服务器的公钥对对称密钥进行加密，并将加密后的密钥发送给服务器。
  服务器使用私钥对客户端发送的加密密钥进行解密，得到对称密钥。
  服务器和客户端使用对称密钥进行加密和解密数据传输。
• 优化http1.1的三个方向
  1.减少请求次数
  2.减避免http发送
  3.压缩相应报文
• Rpc和http
  rpc的结构体自定义程度更高，可以简化很多冗余的字段（项http的content-type等），也不用考虑浏览器的各种行为（302重定向等），性能会更好
• websocket
  支持全双工，先发起http请求同种有请求升级ws字段，同时携带一个随机生成的base64码，服务器收到后通过公开算法计算base64，发送个客户端，状态101（协议切换）。客户端在通过公开算法将base64转换为一段编码，发现和服务器返回的编码一致。经过两次握手后升级成功。之后和http协议就没啥关系了，
• tcp为保证可靠性的一些机制：滑动窗口（提高传输速率），流量控制（「发送方」根据「接收方」的实际接收能力控制发送的数据量），拥塞控制（避免网络阻塞），重传机制
• 零拷贝
  零可以理解为cpu直接参与的拷贝为0
  1.传统的文件传输方式
  
  2.零拷贝实现方式一：mmp+write
  
  3.零拷贝实现方式二：linux2.1开始，提供了一个专门用来文件传输的系统调用函数sendfile（）。如果网卡支持SG-DMA才能实现真正的零拷贝
  sendfile：代替了原来的read和write，支持cpu直接从pagecache拷贝到socket缓冲区
  
  kafka，使用了零拷贝。文件传输底层用到了nio的transferTo，再底层调用了sendfile方法

Session 与 Cookie

区别：

• 存储位置：Session信息存储在服务器端，Cookie存储在客户端（通常是浏览器）。
• 安全性：Session相对更安全，因为数据存储在服务器端。Cookie数据存储在客户端，更容易被篡改和窃取。
• 生命周期：Session的生命周期由服务器控制，Cookie的生命周期则可以通过设置Cookie的过期时间来控制。

联系：

• 通常，Session ID会被存储在Cookie中，用于识别用户的会话。这样，每次客户端请求时，都会通过Cookie发送Session ID给服务器，服务器通过Session ID找到对应的Session数据。

Token

区别：

• 与Session/Cookie的区别：Token不依赖于特定的存储机制，可以存储在客户端的LocalStorage、SessionStorage或Cookie中，也可以存储在服务器端。Token设计用于无状态的场景，每个请求都需要携带Token来进行身份验证。
• 安全性：Token通常通过HTTPS传输，减少被截获的风险，并且可以通过各种手段（如Token过期机制）来增强安全性。

联系：

• Token可以被视为一种替代Session的方式来进行身份验证和状态管理。与存储在Cookie中的Session ID不同，Token通常包含更多的用户信息，减少了对服务器的查询需求。

JWT

区别：

• 与Token的区别：JWT是Token的一种实现方式，它定义了Token的结构和加密方式。JWT包含三部分：头部（Header）、载荷（Payload）、签名（Signature）。
• 安全性：JWT可以通过签名来验证Token的完整性，还可以加密整个Token来保护数据的安全。

联系：

• JWT是Token技术的一种具体实现，它使得Token的生成和验证更加标准化和安全。

总结

• Session与Cookie：Session和Cookie是传统的Web应用中用于身份验证和状态管理的技术，它们通过在客户端存储Session ID（通常在Cookie中）来实现。
• Token：Token是一种更通用的认证方式，适用于无状态的API服务。Token可以存储在客户端或服务器端，每次请求都需要携带Token。
• JWT：JWT是Token的一种格式，通过定义Token的结构和加密方式，提供了一种更安全、更标准化的Token实现方式。