osi

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

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

物理层

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

数据连接层

局域网如何通信

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

路由器（网关）

外网如何传递数据

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

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

max-age=20

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

no-cache

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

no-store

Cache-Control(响应头)

强制缓存

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

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

早期方案

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

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

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

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

现在流行的

协商缓存

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

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

缓存方案

缓存

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

br

gzip

deflate

服务器响应头：Content-Encoding

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

压缩

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

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

referer&referrer防盗链(请求头)

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了

跨域(响应头)

application/json：JSON格式

text/plain：文本格式

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

multipart/form-data：图片格式

Content-type传输格式

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

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

domain：限制域名

path：限制 路径 基本不使用

max-age：设置cookie的有限期

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

重要字段

cookie

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

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

session

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

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

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

2.不需要后端进行存储

tokne和cookie session的区别

token

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

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

请求行

请求体

请求报文

响应头

响应行

响应体

响应报文

在tcp的基础上增加了报文

普通风格

get

post

put

delete

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

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

options预请求

restful风格

graphgl风格

请求风格

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

1XX

200成功 

204没有响应体  

206部分请求

2XX

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

302 临时重定向  

304缓存

3XX

400 参数错误 不识别的请求 

401 没有登录 没有权限   

403 登录了没权限  

404找不到 

405方法不支持

4XX

500服务端错误 

502 网关错误 服务器挂了

5XX

状态码

xhr

axios

请求方法

http

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

http1.0

1.keep-alive

2.内部加了cookie

优点

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

2.header没法压缩

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

缺点

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

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

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

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

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

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

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

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

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

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

理解

http1.1

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

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

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

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

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

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

加密方案

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

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

https

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

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

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

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

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

http2

http(应用层协议)

DNS（网址变成ip地址）

DHCP（动态主机配置协议）

应用层

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

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

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

三次握手

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

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

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

数据传输

四次挥手

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

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

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

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

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

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

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

传输层

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

网络层

协议

传输的是：报文！！！

用户最终使用的接口

数据的表示：安全，压缩

表示层

建立和管理会话

会话层

第三层

传输的是：数据段！！！

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

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

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

第二层

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

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

Ipv4

ipv6

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

mac地址

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

传输0 1 物理设备

核心是传输数据比特流

第一层

osi