网络协议
2024-06-07 20:02:17 0 举报AI智能生成
网络协议知识体系
作者其他创作
大纲/内容
各层协议
网络层
IP (IPV4, IPV6)
ICMP
IGMP
BGP
ARP
RARP
NAT
VPN
传输层
TCP
UDP
应用层
HTTP
TELNET
SSH
FTP
DHCP
SMTP
POP3
DNS
Linux虚拟网络设备
Tun/Tap
Tun 连接协议栈和用户空间程序, TAP：虚拟网卡，作为虚拟机后端网卡
Bridge
网桥的每个端口与一个网段相连。桥接就是把一台机器上的若干个网络接口连接起来，其结果是，其中一个网口收到的报文会被复制给其他网口并发送出去，从而使得网口之间的报文能够互相转发。Linux 网桥实际上是一个拥有 IP 地址的虚拟接口，其背后的原理是：网桥本身不对数据包做任何处理，只是把来自一个子网的数据包转发至另一子网。Linux bridge 不能跨机连接网络设备
brctl addbr br0 # 创建网桥
brctl addif br0 eth0 # 把网卡 eth0 加入到网桥 br0 中
ifconfig br0 192.168.11.1 # 给网桥设置 IP 地址
Veth
连接两个网络空间
Vlan
隔离广播域
QA
tcpdump能否抓到被 iptables封禁的包
tcpdump工作在网络设备层，而iptables工作的 ip, arp 层，故接收网络包时可以抓到，而发送网络包时不可以
分支主题
分支主题
IP层报文
分支主题
分支主题
IP头部生成后还需要在IP头部之前生成MAC头部
分支主题
MAC包头部协议类型
IP协议 0800
ARP协议 0806
Address Resolution Protocol
通过广播的方式根据IP查找物理地址
websocket
与Http协议一样都属于应用层的协议，WebSocket在建立握手连接时，数据是通过http协议传输的，但是在建立连接之后，真正的数据传输阶段是不需要http协议参与的
轮询
长轮询
浏览器发起请求到服务器，服务器一直保持连接打开，直到有数据可发送
短轮询
浏览器定时向服务器发送请求，服务器收到请求不管是否有数据到达都直接响应
特点
建立在 TCP 协议之上，服务器端的实现比较容易
数据格式比较轻量，性能开销小，通信高效
可以发送文本，也可以发送二进制数据
没有同源限制，客户端可以与任意服务器通信
与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。
Upgrade: websocket
Connection: Upgrade
Linux网络收发过程
接收过程
收包前准备
1. 创建 ksoftirqd 线程，为它设置好它自己的线程函数，后面指望着它来处理软中断呢
2. 协议栈注册，linux 要实现许多协议，比如 arp，icmp，ip，udp，tcp，每一个协议都会将自己的处理函数注册一下，方便包来了迅速找到对应的处理函数
3. 网卡驱动初始化，每个驱动都有一个初始化函数，内核会让驱动也初始化一下。在这个初始化过程中，把自己的 DMA 准备好，把 NAPI 的 poll 函数地址告诉内核
4. 启动网卡，分配 RX，TX 队列，注册中断对应的处理函数
接收流程
1. 网卡将数据帧 DMA 到内存的 RingBuffer 中，然后向 CPU 发起中断通知
2. CPU 响应中断请求，调用网卡启动时注册的中断处理函数
3. 中断处理函数几乎没干啥，就发起了软中断请求
4. 内核线程 ksoftirqd 线程发现有软中断请求到来，先关闭硬中断
5. ksoftirqd 线程开始调用驱动的 poll 函数收包
6. poll 函数将收到的包送到协议栈注册的 ip_rcv 函数中
7. ip_rcv 函数再将包送到 udp_rcv 函数中（对于 tcp 包就送到 tcp_rcv）
发送过程
分支主题
网络分析工具
tcpdump
如果网络包已经被网卡丢弃了，那么 tcpdump 是抓不到它的；在发包的时候，如果网络包在协议栈里被丢弃了，比如因为发送缓冲区满而被丢弃，tcpdump 同样抓不到它
dstat
检查系统的整体状况
案例
1. 查看系统是否存在丢包
nstat -z | grep -i drop
旧版net-tools 与 iproute2工具集对比
netstat 不仅比 ss 慢，而且开销也大。netstat 是通过直接读取 /proc/net/ 下面的文件来解析网络连接信息的；而 ss 使用的是 netlink 方式，这种方式的效率会高很多。netlink 在解析时会依赖内核的一些诊断模块，比如解析 TCP 信息就需要 tcp_diag 这个诊断模块。如果诊断模块不存在，那么 ss 就无法使用 netlink 这种方式了，这个时候它就会退化到和 netstat 一样，也就是使用解析 /proc/net/ 这种方式，当然了，它的效率也会相应变差
网卡
启动流程
分配 Rx, Tx 队列内存
注册中断处理函数
ifconfig 中 Rx dropped 与 overruns区别
dropped
表示这个数据包已经进入到网卡的接收缓存 fifo 队列，并且开始被系统中断处理准备进行数据包拷贝（从网卡缓存 fifo 队列拷贝到系统内存），但由于此时的系统原因（比如内存不够等）导致这个数据包被丢掉，即这个数据包被 Linux 系统丢掉
overruns
表示这个数据包还没有被进入到网卡的接收缓存 fifo 队列就被丢掉，因此此时网卡的 fifo 是满的。为什么 fifo 会是满的？因为系统繁忙，来不及响应网卡中断，导致网卡里的数据包没有及时的拷贝到系统内存，fifo 是满的就导致后面的数据包进不来，即这个数据包被网卡硬件丢掉
RingBuffer 满以后，新来的数据包将被丢弃， 可以通过 ethtool 加大环形队列长度
ethtool
查看环形队列大小：ethtool -g eth0
查看环形队列溢出： ethtool -S eth0
在 ifconfig 体现为 overruns
调整环形队列大小： ethtool -G eth0 rx 4096 tx 4096
查看网卡支持的队列数： ethtool -l eth0
通过伪文件查看真正生效的队列数：ls /sys/class/net/eth0/queues
调整网卡队列数： ethtool -L eth0 combined 32
通过伪文件查看真正生效的队列数：ls /sys/class/net/eth0/queues
ksoftirqd 内核处理线程
机器有几核，就有几个该内核线程，该内核线程包含了所有软中断的处理逻辑。软中断信息可以在 /proc/softirqs 读取
查询环形队列 RingBuffer 对应的硬中断号
cat /proc/interrupts: 最左侧一列即为中断号，通过该中断号可以查看该中断由哪个CPU来处理，cat /proc/irp/53/smp_affinify
哪个核响应的硬中断，那么该硬中断发起的软中断就必须由该核来处理
若网络包的接收频率高而导致个别核的 si 偏高，那么通过加大网卡队列数，并设置队列中断号上的smp_affinity，将各个队列的硬中断打散到不同CPU上即可，这样硬中断后面发起的软中断CPU开销也将由多个核来分担
RPS (Receivce Packet Steering)
google 贡献给 linux kernel 的一个 patch，主要的功能是解决多核情况下，网络协议栈的软中断的负载均衡。这里的负载均衡也就是指能够将软中断均衡的放在不同的 cpu 核心上运行
多核环境网卡终端处理
单核环境
传统的单核环境中，没有太多的额外工作可以做，网卡收到数据后，驱动将中断直接给仅有的CPU
多核环境
轮询(RR)
到达一个数据包，驱动将中断传给0号CPU，再到一个数据包，驱动又将中断传给1号CPU，以此类推。这种方式的一个极大的缺陷就是，容易导致包乱序
多队列、多中断号
网卡支持多个队列，每个队列又有一个独立的中断号。但网卡中的队列数往往是固定不变的，而这个数目如果与CPU个数相统一，那么就工作的很好，如果CPU个数跟它不一样则出现 CPU 倾斜问题
RPS(ReceivePacketSteering)
驱动如果能够将中断分发到各个CPU，并且能保证每个流只用一个CPU来处理，这样就可以保证CPU的cache命中率，岂不是很好? 没错，RPS就是为此而来的。RPS方案预想通过计算包中四元组的hash值来确定这个包要被分配到哪一个CPU上，因为这样可以基本保证分配的均等性和某个流被特定CPU所处理。但是如果计算hash值的任务如果由CPU来做，那么就涉及到CPU去读取报头，这将会导致cache miss，如果每个包都来一次cache miss，结局将是悲剧的。而事实上CPU必将miss，因为这个数据包是全新的、刚刚到达的。所以这个工作万万不能有CPU来做，那么谁来做呢? 您也许想到了，是网卡本身。网卡产生了hash值后，由驱动去读取这个hash值，进而完成后续的中断分发。
off load
TSO (TCP Segmentation offload)
一种利用网卡替代 CPU 对大数据包进行分片，降低 CPU 负载的技术。如果数据包的类型只能是 TCP，则被称之为 TSO。此功能需要网卡提供支持。TSO 是使得网络协议栈能够将大块 buffer 推送至网卡，然后网卡执行分片工作，这样减轻了 CPU 的负荷，其本质实际是延缓分片
故在 IP 层若发送的数据大于 MTU, 那么就不一定会被分片
开启 tso: ethtool -K eth0 tso on
GSO(Generic Segment Offload)
延缓分片技术。它比 TSO 更通用，原因在于它不需要硬件的支持就可以进行分片。
首先查询网卡是否支持 TSO 功能，如果硬件支持 TSO 则使用网卡的硬件分片能力执行分片；如果网卡不支持 TSO 功能，则将分片的执行，延缓到了将数据推送到网卡的前一刻执行
开启 GSO: ethtool -K eth0 gso on
UFO(UDP Fragmentation offload)
LRO(Large Receive Offload )
将网卡接收到的多个数据包合并成一个大的数据包，然后再传递给网络协议栈处理的技术。这样提系统接收数据包的能力，减轻 CPU 负载
GRO(Generic Receive Offload)
LRO 的软件实现，只是 GRO 的合并条件更加的严格和灵活。
RSS (Receive-Side Scaling)
基于多个硬件接收队列执行接收操作，多 CPU 同时处理，提升接收性能。
XPS(Transmit Packet Steering)
和 RSS/RPS 相对应，对于有多队列的网卡，建立 CPU 与 tx queue 的对应关系，而对于只有单队列的网卡，则没有优化作用
udp
http
影响 HTTP 请求的因素
带宽
延迟
浏览器阻塞
DNS查询
建立连接
各版本区别
1.0
缓存处理
If-Modified-Since
Expires
1.1
长连接
更多缓存处理
Entity tag
If-Unmodified-Since
If-Match
If-None-Match
....
支持断点续传 Accept-Ranges
新增了24个错误状态响应码
409（Conflict）表示请求的资源与资源的当前状态发生冲突
410（Gone）表示服务器上的某个资源被永久性的删除
Host头处理
支持更多命令，如PUT, PATCH, OPTIONS, DELETE
支持管道机制(pipelining)，即一个TCP连接内可以同时发起多个请求
支持分块传输编码(chunked transfer encoding)
2.0
服务端推送
header头部压缩( HPACK算法 )
HTTP/2 没使用常见的 gzip 压缩方式来压缩头部，而是开发了 HPACK 算法，HPACK 算法主要包含三个组成部分。客户端和服务器两端都会建立和维护「字典」，用长度较小的索引号表示重复的字符串，再用 Huffman 编码压缩数据，可达到 50%~90% 的高压缩率
静态字典
动态字典
动态表生效有一个前提：必须同一个连接上，重复传输完全相同的 HTTP 头部
动态表越大，占用的内存也就越大，如果占用了太多内存，是会影响服务器性能的，因此 Web 服务器都会提供类似 http2_max_requests 的配置，用于限制一个连接上能够传输的请求数量，避免动态表无限增大，请求数量到达上限后，就会关闭 HTTP/2 连接来释放内存
Huffman 编码（压缩算法）
并发传输
Stream
概念
1 个 TCP 连接包含一个或者多个 Stream，Stream 是 HTTP/2 并发的关键技术；
Stream 里可以包含 1 个或多个 Message，Message 对应 HTTP/1 中的请求或响应，由 HTTP 头部和包体构成；
Message 里包含一条或者多个 Frame，Frame 是 HTTP/2 最小单位，以二进制压缩格式存放 HTTP/1 中的内容（头部和包体）；
在 HTTP/2 连接上，不同 Stream 的帧是可以乱序发送的（因此可以并发不同的 Stream ），因为每个帧的头部会携带 Stream ID 信息，所以接收端可以通过 Stream ID 有序组装成 HTTP 消息，而同一 Stream 内部的帧必须是严格有序的
客户端和服务器双方都可以建立 Stream，因为服务端可以主动推送资源给客户端， 客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号
优先级
可以对每个 Stream 设置不同优先级，帧头中的「标志位」可以设置优先级，比如客户端访问 HTML/CSS 和图片资源时，希望服务器先传递 HTML/CSS，再传图片，那么就可以通过设置 Stream 的优先级来实现，以此提高用户体验
并发设置
在 Nginx 中，可以通过 http2_max_concurrent_Streams 配置来设置 Stream 的上限，默认是 128 个
HTTP/2 通过 Stream 实现的并发，比 HTTP/1.1 通过 TCP 连接实现并发要牛逼的多，因为当 HTTP/2 实现 100 个并发 Stream 时，只需要建立一次 TCP 连接，而 HTTP/1.1 需要建立 100 个 TCP 连接，每个 TCP 连接都要经过 TCP 握手、慢启动以及 TLS 握手过程，这些都是很耗时的。
多路复用
完全采用二进制协议
HEADERS
DATA(payload)
3.0 (QUIC)
HTTP1/2存在的问题
队头堵塞
因为 TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且有序的，如果序列号较低的 TCP 段在网络传输中丢失了，即使序列号较高的 TCP 段已经被接收了，应用层也无法从内核中读取到这部分数据，从 HTTP 视角看，就是请求被阻塞了
如图所示，HTTP2 中的 Stream 2 有一个 TCP 报文丢失了，那么即使收到了 Stream 3 和 Stream 4 的 TCP 报文，应用层也是无法读取的，相当于阻塞了 Stream 3 和 Stream 4 请求
而 HTTP3 却不一样，只要某个流的数据丢失，不会影响其他流的读取
网络迁移需要重新连接
一个 TCP 连接是由四元组（源 IP 地址，源端口，目标 IP 地址，目标端口）确定的，这意味着如果 IP 地址或者端口变动了，就会导致需要 TCP 与 TLS 重新握手，这不利于移动设备切换网络的场景，比如 4G 网络环境切换成 WiFi
TCP 与 TLS 的握手延迟
发起 HTTP 请求时，需要经过 TCP 三次握手和 TLS 四次握手（TLS 1.2）的过程，因此共需要 3 个 RTT 的时延才能发出请求数据
TCP 由于具有「拥塞控制」的特性，所以刚建立连接的 TCP 会有个「慢启动」的过程，它会对 TCP 连接产生 “减速” 效果。
特性
基于 UDP 协议实现
无队头堵塞
更快的连接建立
原有的HTTP协议中TCP在传输层，TLS在表示层，两者难以合并。
QUIC 协议并不是与 TLS 分层，而是 QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的 “记录”，再加上 QUIC 使用的是 TLS 1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。
连接迁移
而 QUIC 协议没有用四元组的方式来 “绑定” 连接，而是通过连接 ID 来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以 “无缝” 地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了 连接迁移的功能。
实现在应用层，无需修改内核
Stream
分支主题
头部压缩使用 QPACK 算法，类似 http2 的HPACK
动态表是具有时序性的，如果首次出现的请求发生了丢包，后续的收到请求，对方就无法解码出 HPACK 头部，因为对方还没建立好动态表，因此后续的请求解码会阻塞到首次请求中丢失的数据包重传过来。
QPACK 通过两个特殊的单向流来同步双方的动态表，解决了 HTTP/2 的 HPACK 队头阻塞问题。
状态码
1xx：（临时响应）表示临时响应并需要请求
者继续执行操作的状态代码，HTTP1.0不支持
100（Continue）
上传大文件前使用，请求者应当继续提出请求。服务器返
回此代码表示已收到请求的第一部分，正在等待其余部分。
由客户端发起 Expect: 100-continue 头部触发
101（Switch Protocols)
协议升级，由客户端携带Upgrade 头部触发，如websocket或http/2.0
102（Processing）
WebDAV请求可能包含许多涉及文件操作的子请求，需要很长时间才能完成。
2xx：成功处理请求
200（OK）
201（Created）
如文件上传成功
202（Accepted）
服务器接收并开始处理请求，但处理未完成。如异步或需长时间处理的任务
203（Non-Authoritative Information）
当代理服务器修改了origin server的原始响应包体时（如更换HTML元素值），代理服务器可以通过修改200为203的方式告知客户端，方便客户端为这一行为做出相应的处理
不被广泛接收
204（No Content）
成功执行请求且不携带响应包体，暗示客户端无需更新当前页面视图
205（Reset Content）
成功执行请求且不携带响应包体，同时指明客户端需更新当前页面视图
206（Partial Content）
使用range协议时返回部分响应内容
207（Multi-Status）
WebDAV协议中以XML返回多个资源状态
208（Already Reported）
避免相同集合下资源在207响应码下重复上报，使用208可以使用父集合的响应码
3xx：重定向
300（Multiple Choices）
允许客户端使用一种资源表述方式
301（Move Permanently）
永久性重定向，目标资源被永久的移动到了一个新的
URI，任何未来对这个资源的引用都应该使用新的 URI。
302（Found）
临时重定向
对于非GET或HEAD请求，浏览器不会自动重定向
到Location首部所指向的链接，如POST请求
303与307是对302的细分
303（See Other，http-1.1）
重定向到服务器返回的url资源，常用于POST/PUT等方法的响应
对于POST请求，它表示请求已经被处理，客户端可以
接着使用GET方法去请求首部Location里的URI
304（Not Modified）
305 (Use Proxy)
所请求的资源必须统过代理才能访问到。由于安全原因，该状态码并未受到广泛支持。
307 (Temporary Redirect, http-1.1)
对于POST请求，表示请求还没有被处理，客户端应该
向首部Location里的URI重新发起POST请求
308 (Permanent Redirect )
永久重定向，与301不同的是，308不允许浏览器
将原本为POST的请求重定向到GET请求
4xx
400 Bad Request
请求报文存在语法错误
401 UnAuthorized
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
服务器无法根据客户端请求的内容特性完成请求
407 Proxy Authentication Required
认证信息未通过代理服务器认证
408 Request Timeout
服务器等待客户端发送的请求时间过长，超时
410 Gone
该代码与 404（未找到）代码类似，但在资源以前存在而现在不存在的情况下，有时会用来替代 404 代码。如果资源已永久移动，应使用 301 指定资源的新位置
5xx
500 internal server error
501 Not Implement
502 Bad Gateway
代理服务器无法获得源服务器的合法响应，即TCP收到了RST报文或FIN报文
服务器过早断开连接， 可以增加超时时间
服务器进程崩溃，导致代理服务器向一个不存在的端口发数据，结果服务器响应了RST报文
如何判断服务器是否崩溃过
1. 通过监控查看最近一段时间是否存在CPU暴跌的情况
2. 通过命令查看进程启动时间： ps -o lstart [pid]
503 Service Unavailable
服务器资源尚未准备好处理当前的请求.由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。如果能够预计延迟时间，那么响应中可以包含一个 Retry-After 头用以标明这个延迟时间。如果没有给出这个 Retry-After 信息，那么客户端应当以处理 500 响应的方式处理它
可能场景
1. 限速
2. 高并发导致处理不及时
504 Gateway Timeout
代理服务器无法及时获得源服务器的响应
505 Http Version Not Supported
507 Insufficient Storage
服务器没有足够空间处理请求
508 Loop Detected
访问到资源时检测到循环
511 Network Authentication Required
代理服务器需要客户端身份认证
分支主题
会话管理
cookie
每个cookie最多可存放4k数据，
一个站点最多可用存20个cookie
数据存放浏览器，安全性低
可在cookie中设置HttpOnly属性来禁止js脚本获取cookie
session
数据存放服务端
数据大小无限制
http缓存
强缓存（浏览器缓存）
Expires
来指定资源到期的时间，是服务器端的具体的时间点
Expires=max-age + 请求时间，需要和Last-modified结合使用
缺陷
失效时间是一个绝对时间，所以当客户端本地时间被修改以后，服务器与客户端时间偏差变大以后，就会导致缓存混乱，故出现了cache-control
Cache-Control 优先
一个相对时间，例如Cache-Control:3600，代表着资源的有效期是3600秒
取值
max-age
指定一个时间长度，在这个时间段内缓存是有效的，单位是s。例如设置 Cache-Control:max-age=31536000
s-maxage
同 max-age，覆盖 max-age、Expires，但仅适用于共享缓存，在私有缓存中被忽略
public
表明响应可以被任何对象（发送请求的客户端、代理服务器等等）缓存
private
表明响应只能被单个用户（可能是操作系统用户、浏览器用户）缓存，是非共享的，不能被代理服务器缓存
no-cache
不缓存过期的资源，使用缓存前会向源服务器进行有效确认
no-store
禁止缓存，每次请求都要向服务器重新获取数据
协商缓存（服务器缓存）
Last-Modify/If-Modify-Since
1. 浏览器第一次请求一个资源的时候，服务器返回的header中会加上Last-Modify，Last-modify是一个时间标识该资源的最后修改时间
2. 览器再次请求该资源时，发送的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否有修改。
3. 若未修改则直接返回304，否则直接返回新内容
缺陷
Last-Modified标注的最后修改只能精确到秒级，如果某些文件在1秒钟以内，被修改多次的话，它将不能准确标注文件的修改时间
有时内容并没有任何变化，但Last-Modified却改变了，导致文件没法使用缓存
有可能存在服务器没有准确获取文件修改时间，或者与代理服务器时间不一致等情形
ETag/If-None-Match（http 1.1）优先
Etag （entity tag）返回的是一个校验码。ETag可以保证每一个资源是唯一的，资源变化都会导致ETag变化
ETag值的变更则说明资源状态已经被修改。服务器根据浏览器上发送的If-None-Match值来判断是否命中缓存
ETag生成规则
因子
文件的i-node编号，此i-node非彼iNode。是Linux/Unix用来识别文件的编号。是的，识别文件用的不是文件名。使用命令’ls –I’可以看到。
文件最后修改时间
文件大小
生成Etag的时候，可以使用其中一种或几种因子，使用抗碰撞散列函数来生成。所以，理论上ETag也是会重复的，只是概率小到可以忽略
浏览器缓存行为与用户行为关系
分支主题
https
请求流程
1. 客户端向服务器发起https请求，同时带上自身
支持的加密算法，服务器返回证书（公钥）
2. 客户端接收到证书后验证合法性，验证通过
后生成一个随机码，并使用公钥加密发送给服务器
3. 服务器接收到后使用私钥解密得到客户端的随机码，用随机码key对内容加密，并将结果返回客户端
证书合法性验证
1. 是否在有效期内
2. 证书是否已被吊销
CRL（Certificate Revocation List）即证书撤销名单
浏览器会缓存这份名单，定期做后台更新
OCSP(Online Certificate StatusProtocol)即在线证书状态协议
3. 证书是否是上级CA签发的
历史背景
网景浏览器极大推动了HTTP的发展，网景公司为了解决HTTP的安全
问题，1994年创建了SSL协议，作为浏览器的扩展，主要用于HTTP。
网景公司意识到互联网还有其他的应用协议，如SMTP,FTP，这些协议在实际应用中也面临同样的安全问题，于是开始思考是否有统一的方案解决互联网通信安全问题。基于此考虑，SSL协议逐渐成为一个独立的协议，该协议能够保证网络通信的认证和安全问题，SSL协议有三个版本，SSL v1, SSL v2 SSL v3
1996年， IEIF组织在SSL v3的基础上进一步标准化了该协议，微软为此取名为 TLS v1.0。
SSL
1. SSL Record Protocol
建立在TCP协议之上，为高层协议提供数据封装、压缩和加密等基本功能支持
2. SSL Handshake Protocol
建立在SSL Record Protocol 之上，用于在实际的数据传输开始前，通信双方进行身份认证、密钥协商和交换加密密钥等
密钥套件（参见密码学）
CA签发证书过程
1. CA 将持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行Hash计算，得到一个Hash值
2. CA使用自己的私钥对该Hash值进行加密， 生成 Certificate Signature, 即对证书进行签名
3. 最后将 Certificate Signature 添加到文件中，形成数字证书
客户端校验服务端证书的过程
1. 客户端使用同样的算法获取证书的Hash值H1
2. 一般浏览器及操作系统都已集成CA的公钥信息，浏览器收到证书后可以使用CA公钥解密Certificate Signature内容，得到一个Hash值H2
3. 最后比较 H1 与 H2, 若两者相同则是可信赖的证书，否则不可信
TLS四次握手
1. 客户端向服务器发送一个Client Hello消息，消息包含TLS版本、支持的密码套件、随机数(Client Random, 用于生成会话秘钥)
2. 服务端收到客户端Client Hello消息后的操作流程
1. 首先确认TLS版本号是否支持，然后选择合适的密码套件，以及生成随机数（Server Random）, 接着返回Server Hello消息
2. 向客户端发送Server Certificate消息，里面包含数字证书
3. 向客户端发送Server Hello Done 消息
3. 第三次握手：客户端根据三个随机数生成会话秘钥（Master Secret），这就是对称秘钥，用于后续Http请求响应的数据加解密
1. 客户端基于Server Random及Client Random 生成随机数 pre master. 然后使用服务器的公钥加密该随机数，通过Client Key Exchange 消息传给服务端
2. 客户端生成会话秘钥后向服务器发送 Change Cipher Spec消息，告诉服务端开始使用加密方式发送数据
3. 客户端再发送一个 Encrypted Handshake Message(Finished)消息，将只有所有发送的数据做个摘要，再用会话秘钥（master secret）加密。让服务器做个验证，验证加密通信是否可用及之前握手信息是否有被中途篡改过
4. 服务器第四次握手，验证流程如客户端第三次握手
TLS四次握手流程图
TLS 版本
1.0
1.2
1.3
DH算法
前置知识
底数 a 和模数 p 是离散对数的公共参数，也就说是公开的，b 是真数，i 是对数。知道了对数，就可以用上面的公式计算出真数。但反过来，知道真数却很难推算出对数。
特别是当模数 p 是一个很大的质数，即使知道底数 a 和真数 b ，在现有的计算机的计算水平是几乎无法算出离散对数的，这就是 DH 算法的数学基础
分类
static DH
不具备前向安全，已废弃
DHE
需要做大量的乘法，计算性能不佳
ECDHE算法
在 DHE 算法的基础上利用了 ECC 椭圆曲线特性，可以用更少的计算量计算出公钥，以及最终的会话密钥
算法
RSA
不支持前向保密。
ECDHE
0 条评论
下一页
