观小林coding图解网络总结

前言：本文属于二次创作，基于自己的理解，将重点做了总结，个人总结会比较简洁，而且有所倾向（不然就原封不动复制粘贴了），可以现简单看一下这个总结，知道有哪些知识点，具体哪些知识点感兴趣的就可以去看看原文，甚至去看更多的资料。下面的文章就是总结的内容，但生成的格式可能不太好看，需要可以下载原xmind文件来看，下载链接  提取码: oh3m

总结概览：

 原版是《图解网络-小林coding》需要的可以去找一下这个资源 也可以这里点击下载，提取码: cu9w

HTTPS协议

• 演变
  • http明文传输带来的安全风险问题
    • 窃听：拦截到的请求可以轻而易举的看到信息内容
    • 篡改：可以将内容进行修改
    • 冒充：可以仿冒服务端回应请求
  • https安全措施
    • 信息加密：通过混合加密，没有密码无法查看内容信息，解决窃听问题
    • 检验机制：通过摘要算法，对内容计算出“信息指纹”，解决篡改风险
    • 身份校验：通过CA证书，解决仿冒风险
  • HTTP1.0->HTTP1.1->HTTP2.0的优化之路
• 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
• 网络中基本知识
  • 路由器和交换机的区别：
  • 1.路由器是基于IP设计，有三层结构，每个端口都有mac
  • 2.交换机是基于以太网设计，只有两层，没有端口
  • 网络传输的过程mac地址一直在变，而ip是不变的
  • 网络包的大致结构（以http为例）：
  •  mac头->ip头->tcp头->http报文
  • 分别携带了目标mac，源mac，目标ip，源ip，目标端口，源端口信息， 并且每个头都会记录后面跟着的是什么协议（tcp没有）