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没有）
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）