交换机：报文记录发送发MAC地址，接收方MAC 泛洪 （查找收件方），响应方回信，交换机记录MAC地址 。二次发送不需要泛洪。 当网卡损坏后后无法收到消息，更抽象的地址 -> IP
报文同时传递：目标IP地址（无目标MAC），当前 MAC地址，IP地址。 泛洪（比对IP）比对成功：（ARP记录表 将发送方MAC与IP绑定起来记录）返回消息，同样传递MAC和IP ，交换机记录MAC 发送方收到接收方返回的消息，同样记录。 由IP获得MAC地址的过程：（ARP协议）
通过交换机的泛洪特性：可以通过交换机，将不同的网络联合起来。 但是交换机的MAC地址表无法容纳过多的地址，并且全网泛洪会导致效率问题
于是将网络隔离开来，将网络分成不同的网段，交换机只用来传输同一网段的消息 ->子网掩码（告诉计算机 子网的ID是IP前面多少位数）截取IP前面N位作为子网ID，表示在同一网段。
对于发往外网的消息，交给路由器帮忙转发。
发送方之所以知道要交给哪台路由器，是因为发送方的网关配置的是路由器的IP。 网关 是各个子网的关口，出口。非内网的消息经过网关出去。
路由器上有个路由表，可以配置网段和下一跳，来决定各个网段的消息下一步应该交给哪个路由设备，于是路由器通过接力的方式，将消息传达到了目的计算机。
路由表是手动配置的，当路由设备多了起来，人工维护困难，于是有了自动相互学习，自动管理路由表的OSPF等协议
规模继续扩大，OSPF也疲软，又会使用BGP等协议。
IP协议只负责将数据投送到对应的计算机，但计算机是多应用的，怎么区分呢？ -> 端口
报文加上端口。带端口的协议，其实就是UDP协议。 UDP不可靠 -> TCP协议
TCP和UDP是应用层协议的基础，应用层协议都是在他们的基础上建立的。
网络的发展壮大，IPV4不够用了，于是有人想出子网公用一个IP地址的方法。
路由器收到消息，建立端口映射表。 记录着源端口 新端口 以及对应的内网IP。之后将报文中来源IP改成公网IP 端口改成新端口。 响应方响应消息是，网关路由器可以根据端口映射表，找到消息应该分配给哪台内网计算机(NAT协议)
假如其他计算机知道了映射表，能通过向该端口发送消息吗？
ip地址能够手动设置，更多的是动态管理。 例如使用DHCP协议，由DHCP服务器（路由器）给计算机分配IP地址，网关等。而企业公网IP则可以根据运营商提供的静态IP手动配置。
域名表（计算机中的Hosts文件） 域名 - ip 有上限 不方便跨设备共享 ->
域名服务器 获取ip 分布式数据库 ->提高速度
代理服务器 缓存机制 DNS服务
实际上浏览器，计算机缓存会将域名ip缓存起来
ip：tcp协议通信 每次请求都会连接，断开连接
请求的内容约定好格式：请求头 请求体（HTTP协议）
每个中间路由器节点都会收到消息 不安全 ->
加密处理 先发密钥 然后密钥加密并发送数据 服务器用密钥解析
加密解密同一把密钥：对称加密
非对称加密。
攻击者掉包公钥
http + tls = https
http1 :一次请求建立一个连接 佛送 等待 响应 多个请求多次连接 资源浪费 1.1 连接保持机制 不立马关闭 下一个请求公用一个连接 -> 需要等待前一个请求完成 等待时间过长 -> 管线化机制 多个请求一起发出 前面的请求大或者丢失会阻塞后面的请求
http2 ：将单个请求数据做了拆分成数据帧 接收后重组 虽然总时长不变，但是小请求能更快完成加载 。 不是简单拆分 而是分成了头部帧和数据帧。多个请求头部高度一致 建立 头部索引表 （Hpack头部压缩） 始终无法摆脱头部阻塞问题 ->
http3 基于udp 实现了一套连接协议 QUIC http3之前需要建立连接才能建立tls握手 http3把连接建立过程和tls握手过程融合在一起
