观小林coding图解网络总结
2024-06-10 11:23:30
前言：本文属于二次创作，基于自己的理解，将重点做了总结，个人总结会比较简洁，而且有所倾向（不然就原封不动复制粘贴了），可以现简单看一下这个总结，知道有哪些知识点，具体哪些知识点感兴趣的就可以去看看原文，甚至去看更多的资料。下面的文章就是总结的内容，但生成的格式可能不太好看，需要可以下载原xmind文件来看，下载链接 提取码: oh3m
总结概览：
原版是《图解网络-小林coding》需要的可以去找一下这个资源 也可以这里点击下载，提取码: cu9w
HTTPS协议
- 演变
- http明文传输带来的安全风险问题
- 窃听：拦截到的请求可以轻而易举的看到信息内容
- 篡改：可以将内容进行修改
- 冒充：可以仿冒服务端回应请求
- https安全措施
- 信息加密：通过混合加密，没有密码无法查看内容信息，解决窃听问题
- 检验机制：通过摘要算法，对内容计算出“信息指纹”，解决篡改风险
- 身份校验：通过CA证书，解决仿冒风险
- HTTP1.0->HTTP1.1->HTTP2.0的优化之路
- http明文传输带来的安全风险问题
- TLS相关加密算法
- 对称加密
- 加密与解密公用同一套密码，无法做到安全交换密钥，但运算速度快，eg: ASE、DES、3DES
- 非对称加密
- 分公私钥，加解密是不同的密码，解决了密钥交换问题，但速度慢，eg: RSA，ECC，DH
- 摘要算法
- 用于生成数据独一无二的指纹
- TLS四次握手（RSA算法）
- 1. 客户端发送请求：seq_c、tls版本号、支持的密码套件
- 2. 服务端响应：ack、seq_s、tls版本号、选用的密码套件、数字证书，done信号
- 3. 客户端，取出证书的公钥，生成pre-master，然后响应：ack，公钥加密的pre-master(client key exchange)、请求换用会话密钥(change cipher spec)、前面所有交换数据的摘要
- 服务端和客户端都会计算会话密钥：seq_c + seq_s + pre-master
- pre-master也是随机数
- 证书的验证：
- 4.服务端响应：ack,确认使用会话密钥(change cipher spec)、前面所有交换数据的摘要
- 完成4次握手后，后续通信就使用会话密钥进行加密通讯
- tls1.3之后是三次握手
- 密码套件命名格式：密钥交换算法+签名算法+对称加密算法+摘要算法
- 签名算法：防止仿冒
- 摘要算法：用于生成数据独一无二的指纹
- DH算法
- 1. 客户端、服务端生成随机数作为私钥：c和s，服务端通过公共参数：底数G和模数P，生成服务端公钥S，传给客户端参数P,G,S
- 2. 客户端收到P,G,S后，通过离散对数计算出公钥G^c(modP)=C，并计算会话密钥S^c(modP)=K，然后返回给服务端公钥C
- 3. 服务端通过C^s(modP)=K计算出会话密钥，由于离散对数符合交换率，所以计算得到的会话密钥是相同的，即K=C^s(modP)=S^c(modP)
- 具体原因：K=C^s(modP)=(G^c(modP))^s(modP)=G^cs(modP)=(G^s(modP))^c(modP)=S^c(modP) 其中modP取模取多少次都等同于取一次模，就如同9%5=4 9%5%5%5还是=4
- 离散对数幂运算有交换律: C^s(modP)=S^c(modP)
- 离散对数特点：a^i(modp)=b中，底数a和模数p，已知指数i，可以轻松计算出对数b，但已知对数b计算a非常难，需要极大地算力，尤其是模数p够大的时候
- 算法分支
- static DH算法：服务端的公钥是固定不变的；带来的风险就是：由于每次会话有很多参数是公开的，如果长期保存每次会话的这些参数就可以暴力计算出服务器的私钥，然后计算每次通讯的会话密钥，所以说改算法也不具备前向安全性。
- DHE算法：每次服务端和客户端的公私钥都是随机生成的，就可以解决该问题了；
- 但同时带来缺点: 要做大量的乘法运算，性能消耗大
- ECDHE算法：利用ECC椭圆曲线特性解决DHE的性能问题；
- 基础原理：在DHE算法的基础上加了曲线，曲线特性：公开曲线类型及基点G，双方私钥d1,d2，乘以基点G得到公钥Q1,Q2， 因为曲线符合乘法交换律和结合律，即d1Q2=d2Q1，所以计算的x坐标是相同的，x坐标就是会话密钥
- 四次握手
- 1. 客户端发送请求：seq_c，TLS版本号，密码套件
- 2. 服务端生成私钥，并响应：seq_s，确认版本号，选择ECDHE密钥协商算法为密码套件，证书，sever key exchange(曲线名、曲线公钥、基点G、曲线公钥RSA签名防篡改)，hello done
- 问题：曲线公钥RSA签名不用密钥吗？用什么密钥？
- 3. 客户端校验证书，并生成私钥和客户端曲线公钥，通过seq_c + seq_s + 计算得到的x点（不直接使用x是为了提升随机度），生成会话密钥，然后响应：client key exchange（曲线公钥），change cipher（改用会话密钥通讯，此时还是CA公钥非对称加密），信息摘要（用会话密钥加的密，来验证会话密钥是否可用）
- 4.服务端得到客户端公钥后，就可以算出会话密钥，并在接收到client change cipher后改用会话密钥进行解密验证信息，然后响应：sever change cipher，信息摘要
- 与TLS的区别：可以在连接还没完全建立前就发送数据。在第四次握手结束前就发应用数据消息，所以省了一个RTT时间
- 总结 RSA 和 ECDHE 握⼿过程的区别
- 1. RSA 密钥协商算法「不⽀持」前向保密，ECDHE 密钥协商算法「⽀持」前向保密；
- 2. 使⽤了 RSA 密钥协商算法，TLS 完成四次握⼿后，才能进⾏应⽤数据传输，⽽对于 ECDHE 算法，客户端可以不⽤等服务端的最后⼀次 TLS 握⼿，就可以提前发出加密的 HTTP 数据，节省了⼀个消息的往返时间；
- 3. 使⽤ ECDHE， 在 TLS 第 2 次握⼿中，会出现服务器端发出的「Server Key Exchange」消息，⽽ RSA 握⼿过程没有该消息；
- RSA算法
- 公私钥生成过程
- 1、 随机找两个质数 P 和 Q ,P 与 Q 越大，越安全；
- 2、 计算他们的乘积 n = P * Q
- 3、 计算 n 的欧拉函数 φ(n)：φ(n) = φ(P * Q)= φ(P - 1)φ(Q - 1) = (P - 1)(Q - 1)
- 4、 随机选择一个整数 e，条件是 1< e < φ(n)，且 e 与 φ(n) 互质
- 5、 计算e对于 φ(n) 的模反元素d，可以使得 ed 除以 φ(n) 的余数为 1
- ( 1<d<e，且ed mod φ(n) = 1 ) 即：d=e^-1 ( mod φ(n) )
- 6、 公钥（n，e)；私钥（n，d)；
- 总结：依赖欧拉函数和离散对数
- 加解密过程
- c：密文； m：明文 e为公钥，d为私钥
- 公私钥关系：d=e^-1 ( mod φ(n) )
- 加密：c = m^e mod N
- 解密：m = c^d mod N
- 总结：依赖离散对数
- 公私钥生成过程
- ECC算法基本原理
- 离散椭圆曲线Ep(a,b),p为质数，x,y in [0, p-1]，公式： y^2=x^3+ax^2+b（modp）
- ECC离散曲线的特性
- 加法法则：P+Q等于点PQ直线与曲线第三个交点的x轴对称点
- 加法法则：P+Q等于点PQ直线与曲线第三个交点的x轴对称点（计算就轻松了，有固定公式）
- 倍点运算：3P=(P+P)+P
- 零元概念：0∞+P=P 0∞即无穷远点
- 负元概念：P+(-P)=0∞ 其实-P就是P点关于x轴对称点
- 阶数运算：P点的阶数n满足P+nP=0∞,就是P+P+...+P后得到点nP与P关于x轴对称
- 重要运算：已知PQ两点可通过公式计算 2P，-P，P+Q的结果，能节省大量计算时间
- 逆运算难度高：Q=kG，已知k(密钥)，G(基点)，可以轻松计算出Q，反过来却很难实现
- 加解密过程
- 1. A端选定Ep(a,b)曲线公式E，选取基点G，计算出阶数n，生成随机数k(k<n且为质数)，然后计算出公钥Q=kG,将E,G,Q发送给B端
- 2. B端获取到E,G,Q后，
- 选取曲线上一点M，生成随机数r(r<n,n为G的阶数)
- 生成两个公钥C1=M+rQ C2=rG，再将C1,C2穿给A端
- 3. A端拿到C1 C2后，通过C1-kC2=M+rQ-k(rG)=M+r(kG)-krG=M，计算出来的M点是相同的，所以可以用它来生成相同的会话密钥
- 注意，其中各个步骤的运算规则都是依赖于上面所述ECC的特性
- 对称加密
- http时延优化思路
- 减少请求次数
- 缓存技术：1.通过url请求资源后，将该url资源缓存，并设置过期时间；2. 第二次请求该url时，读取缓存，若缓存过期则请求服务器，若服务器发现资源未发生变化，可以只返回304（而不是传资源，从而降低开销），让客户端重新激活资源
- 减少重定向请求
- 通过代理服务器
- 合并请求
- 雪碧图：通过合并资源减少请求次数
- 延迟发送请求（懒加载）
- 如渲染html，若资源过于庞大，可以先渲染一定高度，当用户向下拉时再渲染另一部分，类似分页效果
- 压缩数据，减小体积
- 头部压缩，qpack去除重复部分
- 压缩body体（无损压缩、有损压缩）
- 减少请求次数
- 采用混合加密
- 建链使用非对称，会话使用对称加密
- 连接过程
- TCP三次握手：第一次是客户端请求连接；第二次是服务端响应连接；第三次是客户端确认连接。
- 其中第三次握手存在的意义，就是防止由于网络拥塞、延迟，导致服务端获取到客户端已放弃的建链请求，若第二次握手就建链，将导致服务端浪费资源；随机数也是为了防止这一现象
- tcp, up基本认识
- tcp: 面向连接，可靠，字节流(有序，去重)
- 点对点连接，有流量控制/拥塞控制(即发现拥塞时放缓传输速率)
- TCP头部:
- 源端口号（16）目的端口号（16）
- 序列号（32）
- 应答号（32）
- 首部长度(4)保留位(6)控制位(6)窗口大小(16)
- 检验和(16)紧急指针(16)
- 可选项
- 数据
- 结构各部分的功能作用：
- 序列号：为了解决乱序问题；表示当前已传输字节数
- 应答号：解决丢包问题；表示当前已接收数
- 首部长度：因为有可选选，所以要标志头部长度；
- 控制位：urg紧急模式，结合紧急指针，优先处理指针指向的数据段；ack应答位，连接/断连接时的响应位；psh(即push)立即叫给tcp进程；rst连接异常强制断开；syn请求连接；fin请求断开连接；
- 窗口大小：与流量控制/拥塞控制有关；
- 校验和：首部和数据的检验，若检验失败则丢弃重传；
- 紧急指针：指向需要紧急处理的数据段；
- 选项：可自定义的部分；
- 数据：。。。。
- 连接三次握手：服务端的syn和ack是一起发的
- 1. 客户端seq_1序列号，syn=1
- 2. 服务端序列号=seq_2,应答号=seq_1+1，ack=1, syn=1
- 3. 客户端序列号=seq_3，应答号=seq_2+1, ack=1 （此时已经可以带数据）
- 四次挥手：fin和ack都是分开的，所以比连接多了一次握手
- 1. 客户端发送fin信号，进入fin_wait_1状态，这时表示客户端不在发送数据，但可以接受数据
- 2. 服务端收到fin后返回ack, 进入close_wait状态，此时还可以继续发送数据； 而客户端收到ack就进入fin_wait_2状态
- 3. 服务端发送fin信号，表示不再发送数据，可以断开链接
- 4. 客户端收到fin信号，响应一个ack,然后进入time_wait状态，等待2msl时间关闭（2倍报文最大自然存活时间，即最大RTT往返时延）。2msl是因为如果服务端没收到ack重发的fin信号就已经到达
- 适用场景：http, ftp，要点对点，需要有固定的次序和传输保障可靠交付
- TCP提供的可靠服务
- 快速重传机制
- 利用seq和ack号
- 1. A端发seq=1, ack=1 len=5
- 2.发生丢包，B端未能收到，就不会响应，而是重发上一个包seq=1,ack=1 直到A端重新发丢失的包
- 3.假如A端发了seq=6,ack=1,len=10,和seq=16,ack=1，才发现丢包了，这时再重复丢失的包
- 4. B端收到丢失的包，就会响应seq=1,ack=6(1+5）
- 快速重传机制
- udp:无连接，不可靠，包传输
- 广播，尽力传输（固定传输速率），简单高效
- UDP头部：
- 源端口号（16）目的端口（16）
- 包长度（16）检验和（16）
- 包长度：记录数据包长度
- 检验和：首部和数据的检验，报错直接丢包
- 与IP协议的检验和区别：IP的检验和则只校验首部，不检验数据段
- 适用场景：DNS，SNMP（包总量少）
- 实时性要求高的，如视频/音频聊天
- 不用点对点的，如广播
- socket编程
- tcp socket编程 建立连接过程
- 1. 服务端初始化socket文件，通过bing绑定，listence进行监听
- 2.客户端初始化socket文件，主动打开，通过conect阻塞，发送FIN信号，进入syn_send状态
- 3.服务端收到syn信号，插入syn队列，进入syn_rcvd状态，然后发送ack和syn信号
- 4.客户端收到信号，应用程序从connect的返回表示单向连接成功。发送ack，并进入established状态，
- 5.服务端收到ack后，放入accept队列，等待应用程序通过accept()调用取出socket文件，进入established状态
- 总结：客户端调的是connect方法，状态有syn_send和established； 而服务端是调bing,listen,accept，状态有syn_rcvd，established
- 注意：客户端connect返回是在二次握手后，而服务端accept返回是在三次握手之后
- tcp socket编程 断开链接过程：
- 1. 客户端调用close进行关闭，发送fin信号进入FIN_WAIT_1状态
- 2.服务端读到EOF,进入Closed_wait状态，返回ack
- 3.客户端收到ack进入Fin_wait_2状态
- 4.服务端调用close，进入Last_ack状态，发送fin信号
- 5.客户端收到fin信号，进入Time_wait状态，发送ack，等待2msl时间才close
- 6.服务端收到ack信号就close
- 总结：客户端调的是close ，状态有fin_wait_1, fin_wait_2, time_wait，closed; 服务端调close，状态有close_wait, last_ack, close
- 网络相关协议
- DNS协议
- 域名解析基本流程：
- 1. 查本地DNS服务器解析域名，如host
- 2.向根DNS服务器查询，它会指向顶级服务器
- 3.向顶级服务器查询，会指向权威服务器
- 4. 权威服务器会返回IP地址
- ARP协议
- 目的IP对应mac地址：
- 1. 本地arp路由表是否有ip对应的mac
- 2.广播查找子网内是否有，获得arp响应包后会取出mac，并缓存（会过期）
- RARP协议：
- 1. 设备会将mac地址注册到RARP服务器
- 2.设备请求RARP获取mac对应的ip地址，如打印机
- DHCP协议（动态主机配置协议）
- 目的：主机通过该服务器动态获取分配的ip地址
- 背景，网络未初始化，主机还不知道自己的ip也不知道DHCP服务器的地址，需要动态分配
- 基本流程：
- 1.以0.0.0.0为源ip，255.255.255为目的ip广播ip报文（DHCP DISCOVER）
- 2.DHCP发现后回复可租用的ip,子网掩码,默认网关,DNS服务器的报文(DHCP OFFER)
- 3.客户端向其中一个(因为是广播所以可能有多个)发送带回显参数的报文(DHCP REQUEST)
- 4.DHCP服务器应答ACK确认请求分配
- 注意点：全程UDP通讯；ip会过期需要续期；实际中基本是向中继代理（在子网中）发送请求，中继代理服务器单播转发给DHCP服务器，实现多网公用
- NAT协议 (公私网IP转换)
- 1. syn请求时就会产生私网和公网映射关系的表将源ip和公网ip进行映射；
- 2.报文响应回来时，将目的ip(公网ip)转回对应的私网ip
- 问题：不能解决公网ip不足的问题
- 应对：NAPT协议，将端口对不同私网ip进行映射，使得同一个公网的端口可以映射给不同的私网ip
- 问题：NAT/NAPT重启时会丢失缓存的映射表，将导致所有tcp连接重置
- 应对：使用ipv6；NAT穿透技术（客户端应用程序来维护映射关系表）
- ICMP（互联网控制报文协议）属于网络层，同IP协议
- 目的：控制ip报文的不可靠传输，能传递一定传输状态
- 两大类：
- 1. 查询报文类型，用来诊断查询消息
- 2.差错报文类型，用来传达出错原因的消息
- 具体分类：回送应答/会送请求，主机不可达/网络不可达/超时/重定向/原点抑制等
- ping命令就是基于查询类ICMP报文，并增加了序列号和标志符，可以知道数据传输有没有出现丢包
- IP报文与ICMP报文：IP头随后就是ICMP头，IP头的协议标志位标志该报文是ICMP报文，ICMP是IP的控制协议
- IGMP（互联网组管理协议）
- 与分组，广播有关
- IP协议（网络层主要协议）
- traceroute就是利用ip协议，改变其ttl获取每个路由的返回而得到链路ip；
- 结构：
- 版本(4)首部长度(4)服务类型（8）
- 总长度(16)
- 标志符(16)
- 标志位(3)片偏移(13)
- TTL(8)协议位(8)
- 首部校验和(16)
- 源ip地址(32)
- 目的ip地址(32)
- 可选部分
- 主要部分解析：
- 首部长度：因为也是可变长度，所以要记录
- TTL存活跳数，控制路由跳数（traceroute的原理）
- 协议位：可标志协议，如：tcp icmp
- DNS协议
- 网络中基本知识
- 路由器和交换机的区别：
- 1.路由器是基于IP设计，有三层结构，每个端口都有mac
- 2.交换机是基于以太网设计，只有两层，没有端口
- 网络传输的过程mac地址一直在变，而ip是不变的
- 网络包的大致结构（以http为例）：
- mac头->ip头->tcp头->http报文
- 分别携带了目标mac，源mac，目标ip，源ip，目标端口，源端口信息， 并且每个头都会记录后面跟着的是什么协议（tcp没有）
观小林coding图解网络总结相关推荐
- 操作系统----文件管理 参考王道操作系统与小林coding图解操作系统
前置:简单的个人学习笔记上传,仅供参考,想要md文档的可以评论留言 参考内容 CSDN博主 BitHachi的博文 <王道操作系统>学习笔记总目录+思维导图 CSDN博主 小林coding ...
- 小林coding 的笔记——图解网络（一）
图解网络 小林coding tcp/ip网络 应用层 不需要关心数据是如何传输的,是操作系统中的用户态,传输层以下则是在内核态 传输层 tcp 传输控制协议 其中包含流量控制 超时重传 拥塞控制等 为 ...
- 小林coding操作系统总结
文章目录 前言 名词科普 前置一.硬件结构 1.1 计算机基本结构 1.2 存储器层次结构 1.3 提升缓存命中率,提高CPU速度 1.4 缓存一致性 1.5 伪共享和CPU线程调度 1.6 中断 1 ...
- MYSQL总结（图片来源小林coding）
一.索引 1.mysql索引 按数据结构分[B+tree索引.Hash索引.Full-Text索引] 按物理引擎分[聚簇索引.二级索引] 按字段类型分[主键索引.唯一索引.普通索引.前缀索引] 按字段 ...
- 笔记：图解系统（小林coding）
目录 一.硬件结构 二.操作系统结构 三.内存管理 四.进程与线程 五.调度算法 六.文件系统 七.设备管理 八.网络系统 九.Linux命令 一.硬件结构 冯诺依曼模型:中央处理器(CPU).内存. ...
- CentOS 6.0图解网络安装全过程
转自CentOS 6.0图解网络安装全过程 国内镜像站点(东北大学.网易) 网易镜像站点:http://mirrors.163.com/centos/6.0/isos/ 中科大镜像站点:http:/ ...
- 小林求职记（六）踩过Dubbo坑，回答印象深，干货整理
小林求职记系列文章,归置到公众号菜单栏,欢迎查看历史篇 前传 小林求职记(五)上来就一连串的分布式缓存提问,我有点上头.... 终于,在小林的努力下,获得了王哥公司那边的offer,但是因为薪水没有谈 ...
- 小林求职记（五）上来就一连串的分布式缓存提问，我有点上头....
小林求职记系列文章,归置到公众号菜单栏,欢迎查看历史篇 前传 小林求职记(四)不会吧不会吧,面试还真会问这些呀 在之前王哥的辅助之下,小明的简历成功被内推进到了王哥所在公司.由于一面就是王哥自己,所以 ...
- 小林求职记（四）不会吧不会吧，面试还真会问这些呀
小林求职记系列文章,归置到公众号菜单栏,欢迎查看历史篇 前传 小林求职记(三)一上来就围绕电商系统层层提问,我太难了.... 经历了好几次求职失败的经历,小林最终找到了自己以前一起工作合作的老同事王哥 ...
最新文章
- GPT-3：人工智能的新突破
- python 人工智能课程大纲_《人工智能》教学大纲
- 汇编指令prefix rep:
- 如何处理错误信息 Pricing procedure could not be determined
- 详解用65行javascript代码做Flappy Bird
- python编码解码单词_在使用w2v时python中的编码问题
- 协程-greenlet版（python 版）
- 《Essential C++》笔记之return；分析
- JAVA编程中的类和对象
- 4399小游戏flash插件怎么下载_Flash即将关闭，但这个小游戏平台，或许可以帮你找回4399的回忆...
- error LNK2019: unresolved external symbol “__declspec(dllimport) public: __thiscall 的解决方案
- iOS 蓝牙开发中数据收发的坑
- 利用AOP+Swagger注解实现日志记录功能
- Mysql优化之explain你真的会吗？
- 深度学习-86:深度学习的降维攻击及流派
- Hive HBase
- 计算机网路——163邮箱授权码
- echarts+vue中国地图,点击进入省级地图
- MyEclipse解决SVN同步冲突问题conflict in the working copy obstructs the current operation
- 千亿市值今天解禁 美团点评“心里没谱”