osi 思维导图模板_ProcessOn思维导图、流程图

局域网如何通信

物理层

中继器(就两个口)：实现信号再生

集线器(多个口) 可以实现多台设备交互(广播的形式发信息，不会帮你过滤敏感信息)

数据连接层

交换机(记录端口和mac地址的关系) 我们通信通过ip地址获取对方的mac地址，实现通信

外网如何传递数据

路由器（网关）

将内网转到外网中去，路由器有两张网卡，一个网卡和局域网通信，另一个负责连接外网(没有wan的路由器其实就是交换机)。路由器网卡可以将ip地址转换成外网地址，并且增加端口来识别物理设备的身份

协议

应用层

http(应用层协议)

http

在tcp的基础上增加了报文

请求报文

请求头(为了方便总结里面的字段有的是响应头的)

缓存

强制缓存

早期方案：Expires(响应头)，这个字段很难保证客户端和服务端段的时间一致

Cache-Control(响应头)

max-age=20

此字段告诉客户端多少秒不要来找我了，只有第一次访问服务器，之后会按照第一次时间去计算

no-cache

浏览器会缓存，但是会强制请求服务器。每次回来服务器询问我

no-store

不进行缓存，每次向服务器要

协商缓存

早期方案

Last-Modified(响应头)/if-modifiend-since(请求头)

第一次服务器响应设置上Last-Modified，下一次浏览器请求会携带过来 if-modifiend-since 它的值是上一次Last-Modified

现在流行的

etag指纹(响应头)/if-none-match(请求头)

生成方式一：文件大小来作为唯一标示

生成方式二：文件大小+最后修改时间

etag解决了什么问题:就是我改了文件，再改回来，内容没有变，这时候需要指纹来解决

缓存方案

如果20s内文件变化了，无法拿到最新的文件解决方案：不采用强制缓存图片适合采用强制缓存

如果20s到了后，那么会重新的返回文件（但是文件其实没变化）解决方案：强制缓存+协商缓存

只采用协商缓存,或者只采用强制缓存

压缩

浏览器请求头：Accept-encoding，告诉服务器我支持哪些压缩

服务器响应头：Content-Encoding

br

gzip

deflate

作用：减少数据传输的大小

referer&referrer防盗链(请求头)

作用：在发送图片的时候对图片进行防盗链处理：就是这个是我域名下的图片，你其他域名不能套用

如何实现防盗的：请求host和referer进行域名比对

跨域(响应头)

Access-Control-Allow-Origin：表示谁来访问服务器都可以(token不是cookie cokkie跨域不能使用*，所以一般用请求头的origin字段)

Access-Control-Allow-Headers：服务器告诉浏览器我能识别你自定的header

Access-Control-Max-Age：每隔10s试探一次减少options发送的次数

Access-Control-Allow-Methods：服务器可以接受那些方法的请求

Access-Control-Allow-Credentials：表示允许携带cookie了

Content-type传输格式

application/json：JSON格式

text/plain：文本格式

application/x-www-form-urlencoded：表单格式

multipart/form-data：图片格式

状态维持：浏览器是无状态的

cookie

cookie可以前端设置也可以服务端设置（合理设置cookie） cookie设置到了请求头上（大小限制4k）。默认cookie也不支持跨域，cookie可以支持父子域通信（内部可以区分哪些路径生效，哪些子域名生效）

cookie 最终也是存到浏览器上的（用户可以篡改如何防止cookie被篡改签名） cookie中不能存放敏感信息

重要字段

domain：限制域名

path：限制路径基本不使用

max-age：设置cookie的有限期

httpOnly：服务端设置后客户端无法获取 (不能通过代码读取用户的信息 document.cookie)

session

用来存放敏感信息的，解决了cookie的缺陷，但是需要给用户下发一个唯一标识，而且需要用户下次携带过来（cookie） session基于cookie

session的缺陷就是（如果服务器重启数据就丢失了，需要存储session对象）

token

jwt基本作用：这里服务端不需要管理我给谁发了令牌 + 唯一标识
下次来的时候通过唯一标识来识别令牌是否正确，如果令牌正确，说明你就是真的

基本理解：token 和我们刚才说的 cookie + 签名是一样的

tokne和cookie session的区别

1.可以放到url路径上，header body

2.不需要后端进行存储

请求行

请求体

响应报文

响应头

响应行

响应体

请求风格

普通风格

restful风格

get

post

put

delete

options预请求

一：简单请求不会发送预检请求的
get post(在get和post的基础上增加了header 就变为了复杂请求)

二：其他的delete put都是复杂请求在跨域的时候，复杂请求都会发送options请求
预检请求可以设置，有效期来减少发送次数

graphgl风格

状态码

1XX

101 ws 基于http的要将协议升级成ws 101

2XX

200成功

204没有响应体

206部分请求

3XX

301永久重定向，尽可能减少永久重定义

302 临时重定向

304缓存

4XX

400 参数错误不识别的请求

401 没有登录没有权限

403 登录了没权限

404找不到

405方法不支持

5XX

500服务端错误

502 网关错误服务器挂了

请求方法

xhr

axios

http1.0

特点和缺陷：没有所谓的长链接，每个请求都会创建一个tcp链接

http1.1

优点

1.keep-alive

2.内部加了cookie

缺点

1.http请求导致队头阻塞问题

2.header没法压缩

3.不安全（明文，可能内容被篡改）

理解

keep-alive （不断开链接，尽可能复用链接）我们可以再一个tcp链接中发送多个http请求（content-length对请求的分割）

请求和响应都是1:1对应的，请求都是串行的

缺陷：队头阻塞 head-of-line-blocking

管线化浏览器默认不启动：可以同时在一个管道tcp，中同时整批提交http请求，无法解决队头阻塞问题

1个域名我们可以开启（6）个tcp链接（经历6次慢启动，竞争带宽）（可以解决并发问题）
如果多增加域名（域名多了需要做dns解析，浪费性能）

文件我是尽可能的小，还是尽可能的合并？

雪碧图、文件尽可能合并、减少请求

如果都合并了会导致缓存问题、下载慢、压缩、静态文件的优化就是cdn (内容分发网络，核心就是找最近的服务商底层原理就是dns解析)

为什么不能再一个tcp链接上并发请求?

http无序，响应就不知道哪个对应哪个了

https

1.对数据进行加密：https = http + ssl/tls 目前都叫tls 不叫ssl了

1.对称加密 AES：一把钥匙可以加密也可以解密

2.非对称加密 RSA：两把钥匙公钥私钥

加密方案

1.客户端主动去像服务端获取密钥，服务端返回密钥，之后进行通信（密钥要先在网络传递一次，可能被劫持了）不可靠

2.非对称加密（服务端产生两把钥匙，分别是公钥和私钥，将公钥发给客户端）客户端发送消息的时候通过公钥加密，服务端通过私钥解密。中间有可能公钥被劫持了，但是公钥无法解密内容（单向）如果想实现双向？分别两方都有一对钥匙,这导致性能不好

3.混合加密：考虑用两种加密方式来实现，第一次我们通过非对称加密，让服务端把自己的公钥交给客户端（公钥不怕劫持，因为劫持到公钥是无法解密的），客户端生成一个会话密钥（随机值）用服务器的公钥加密这个随机值（只能服务端解密），服务端收到加密后的内容，进行解密拿到了这个随机值（双方都有了一个随机值了）后面可以通过对称加密通信。第一次你访问服务端的时候可能访问的不是真正的服务端（中间商）

4.通过证书来确定对方的身份是正确的（找个公安局，发个身份证，我就知道我是我了）给公钥增加认证
通过证书让公钥变得可信任，客户端向服务端要证书，服务端通过ca机构(ca机构有两把钥匙公私钥)生成一个证书（服务器：公钥，过期：xxx）。将生成的证书通过ca机构的私钥来进行加密，发送给客户端。客户端收到证书后（内置了ca机构的公钥，可以解密），这样就可以顺利的拿到对方的公钥，而且能确定对方身份
缺陷：问题在于证书比较大，直接私钥加密，公钥解密浪费性能。我们将证书进行摘要（摘要的结果很短）用ca的私钥对这个摘要进行加密。客户收到后会采用摘要算法对内容再次进行摘要，用内置的ca机构的公钥解密出摘要的结果。看一下两个摘要是否一致，一致说明内容没有被篡改
为了解决直接加密证书的问题，就变成了对证书进行摘要，再将摘要的结果私钥进行签名。客户端采用公钥来解密签名。获得了证书的摘要结果。再次对证书的内容进行摘要，如果摘要结果一致，则说明证书可信

整个https的过程就是先采用非对称加密，来传递公钥，之后通过对称加密来进行解析。

2.防止传递的数据被篡改：使用签名

http2

特点：我们一个域名只建立一个tcp链接，在一个tcp链接中实现数据的收发。给数据标号（类似tcp的seq）

2.http2 采用了多路复用，可以将数据编程帧进行传输（以前http1.1 有队头阻塞问题， http2 请求不用等待可以并发发送）流、帧
流是虚拟的，真正传输的叫帧

3.http2 中实现了这样一个分帧层，可以实现流量控制、优先级控制。支持了服务端推送（1.1应答模式）

4.头部压缩静态表替换相同的内容为数字动态表，比较两次header的差异只发送差异的部分哈夫曼编码（哈夫曼树左树为0 右树为1）核心就是用出现少的数编码采用长的，出现多的数编码用短的

缺点

我们解决的永远是http层面的，但是服务端在处理的时候还是 tcp（队头阻塞问题）无法解决的 -最后解决办法：http3 采用了udp协议

DNS（网址变成ip地址）

DHCP（动态主机配置协议）

传输层

tcp(面向连接安全可靠慢)

优点

三次握手

客户端和服务端分别有一个序列号 seq = 0;
客户端我的序列号是0 seq=0

服务端要表示我收到了这个数据做应答 ack=客户端 seq+1
并且告诉客户端服务端的seq是多少 seq = 0

客户端收到客户端的ack = 服务端的seq +1,
服务端响应给客户端的ack 或作为客户端的seq

总结：握手后：ack=1 seq=1 （两个序号分别是客户端的序号和服务端序号）

数据传输

客户端和服务端说 hello->服务端要立刻响应
客户端的 seq=1 ack的值也是 1 len长度为5个字节的大小内容

服务端响应 ack = 客户端的seq+len=6 我的序号还是seq = 1

服务端和客户端说 hi-> 客户端要响应
服务端的序列号是seq=1 我的ack=6 len = 2 我要发送两个字节的消息

客户端就收到消息要响应 ack = 服务端的seq + 服务端的len, 我的序号是上次服务端ack的值 seq=6

四次挥手

缺点

慢启动(解决办法：keep-alive)

tcp每次传输一个数据段的时候，都要增加一个20子节点的头部(解决办法:粘包,将小包粘一起)

每次断开的时候，都不能立即断开，导致端口无法释放，可能导致端口用尽(解决办法:keep-alive长连接)

滑动窗口导致的队头堵塞(解决办法:无法解决)

在发送数据的时候，发送方有对应的缓存区，对方有接受的缓存区，在创建tcp链接的时候，会进行窗口协商，自动的会更新窗口大小

流量控制(滑动窗口，当队头的tcp端发送过去并且确认了，才会滑动) 这里会发生阻塞情况，除了队头的收到了，也不能发送其他数据(tcp的队头阻塞问题，无解的) tcp每个数据段都标示了 seq

udp(非连接不安全不可靠快)

网络层

ip协议寻址的 arp协议(交换机根据目的ip地址解析目的mac地址)(下两层不具备协议，所以把arp算是ip层上)

第三层

应用层

用户最终使用的接口

传输的是：报文！！！

表示层

数据的表示：安全，压缩

会话层

建立和管理会话

第二层

传输层

传输数据的，保证可靠的传输 http协议数据丢了需要重传，拆分数据(对数据进行拆分和分割)

传输的是：数据段！！！

网络层

主要关心的是寻址，进行逻辑寻址，定位到对方

传输的是：数据包！！！添加原地址和目标地址

第一层

数据连接层

建立逻辑连接，将数据组合成数据帧进行传递

传输的是：帧！！！增加 mac地址中转

mac地址

网卡和网卡的通信靠的就是mac地址一般情况下 mac地址是唯一的通过mac地址交换数据(长)

ip短所谓的寻址就是寻找mac地址

Ipv4

ipv6

物理层

核心是传输数据比特流

传输0 1 物理设备