当前位置：首页 > news >正文

linux_https，udp，tcp协议（更新中）

news 2025/8/6 10:29:52

https

与普通的 “http” 相比，https 通过 SSL/TLS 加密技术对传输的数据进行加密处理，能有效防止数据在传输过程中被窃取、篡改或伪造，保障用户在浏览网页、进行在线支付、登录账号等操作时的信息安全。

加密类型

对称加密

加密和解密所用密钥是相同的。

特点：算法公开，加密速度快，加密效率高

非对称加密

需要两个密钥进行加密和解密。

特点：运行速度非常慢，用公钥加密要用私钥解密。

加密本质是通过MD5哈希将文件转化成定长字符串。

加密方案

只用对程加密

黑客拦截路由器截取内容，不安全

只用非对程加密

公钥传递过程不安全

双方都是用非对程加密

非对称+对称加密

从第三方黑客视角看，对称与非对称加密结合的“不安全点”，就是他们想突破的攻击路径，核心围绕偷密钥、破算法、钻流程漏洞：

- 截获公钥篡改：黑客先把自己的公钥，替换通信双方交换的公钥。后续甲方用假公钥加密“对称密钥”发乙方，黑客用自己私钥解密，拿到对称密钥，就能监听、篡改后续对称加密的通信内容（中间人攻击经典套路）。
- 暴力破解弱公钥：若通信方用的非对称算法参数弱（比如 RSA 选的密钥长度不够），黑客暴力穷举公钥相关参数，破解后就能解密出传递的对称密钥。

对黑客来说，找最薄弱的环节突破：要么截胡密钥传递，要么打爆弱算法，要么钻流程漏洞。只要混合加密在密钥、算法、实现上有一个环节没做到位，就成了黑客的“突破口” 。

非对称+对称加密+证书

流程图

1. 服务器找 CA 办证

- 谁做：server（网站服务器）
- 干啥：生成自己的公钥、私钥，填好域名、自身信息，打包发 CA 申请“身份证明”（证书）

2. CA 审核身份

- 谁做：CA（证书机构，类似“网络公安局” ）
- 干啥：查 server 填的信息是否真实（域名是不是你的？身份合法吗？）

3. CA 发“数字身份证”（证书）

- 谁做：CA
- 干啥：用自己的私钥，给 server 的信息“盖章签名”，做成证书发给 server（证明：这是真服务器，公钥合法）

4. server 给客户端“亮证”

- 谁做：server
- 干啥：客户端（浏览器/APP ）访问时，server 把 CA 发的“数字身份证”（证书）给客户端看

5. 客户端验“证”

- 谁做：client（浏览器/APP ）
- 干啥：用内置的 CA 公钥，检查证书签名、有效期、域名（确认：这证是 CA 发的，没造假）

6. 商量加密钥匙

- 谁做：client ↔ server
- 干啥：验完证，双方商量一个“对称加密钥匙”，后续通信就用这把钥匙加密，保证安全

一句话总结流程逻辑：
服务器找 CA 办“网络身份证”→CA 审核后发带签名的证→服务器给客户端亮证→客户端找 CA 公钥验明证→验真后商量加密钥匙，安全通信
（核心就是靠 CA 当“权威担保人”，让客户端相信服务器身份，再加密传数据～）

校验流程图

一、签名流程（左边）

1. 算哈希：对原始数据，用“散列函数（比如 MD5、SHA ）”生成固定长度的哈希值（散列值，如 101100110101 ）。作用：把任意长数据压缩成短串，当数据“指纹”。
2. 私钥加密：用签名者的私钥，加密这个哈希值，生成签名（如 11110101110 ）。作用：私钥只有自己有，加密后证明“这是我签的”。
3. 打包发送：把原始数据 + 签名 + 认证信息（可选，证明身份的证书），一起打包成“数字签名的数据”，发给别人。

二、验证流程（右边）

1. 拆包取数：收到“数字签名的数据”，拆分出原始数据、签名。
2. 重算哈希：对原始数据，用同样的散列函数，重新算哈希值（得到 101100110101 ）。
3. 公钥解密：用签名者的公钥，解签名里的哈希值（得到 101100110101 ）。
4. 对比判断：对比“重算的哈希值”和“解密得到的哈希值”：
- 一致 → 数据没被篡改，且是用对应私钥签名的（身份合法）。
- 不一致 → 数据被改过，或签名是假的。

一句话总结逻辑

签名：数据→哈希（指纹）→私钥加密指纹（签名）→打包发出去
验证：收到包→拆出数据和签名→数据重算哈希→公钥解签名哈希→对比哈希，一致就合法

（核心是“私钥签名、公钥验真”，靠非对称加密保证身份，哈希保证数据没被改～）

udp协议格式

数据长度=UDP长度-8

如果udp校验和错误，其内容会被抛弃；

特点

1.无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接;（不同于tcp，不需要connect）
2.不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息;
3.面向数据报: 不能够灵活的控制读写数据的次数和数量(应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并;用UDP传输100个字节的数据:如果发送端调用一次sendto, 发送100个字节, 那幺接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节，如果超过最大接受上线，需要分批传输);

UDP缓冲区

UDP没有发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作;
UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃;

udp既能收又能发的特性为全双工。

tcp协议格式

分析

32位序号及确认序号

在TCP协议中，32位序号和确认序号是保证数据可靠传输的核心机制，以下是关键信息：

32位序号

- 作用：标识发送端所发送数据字节流的位置，确保数据按序传输、无重复。
- 定义：每个字节的数据都被分配一个唯一的32位序号（范围0~2³²-1）。
- 初始序号（ISN）：连接建立时，双方会随机生成一个初始序号，避免因历史数据残留导致混淆。
- 示例：若初始序号为100，发送一个10字节的数据包，其序号为100，下一个数据包的序号则为110（100+10）。

32位确认序号

- 作用：告知发送端已成功接收的数据字节位置，用于确认数据并请求后续数据。
- 定义：确认序号的值 = 已接收的最后一个字节的序号 + 1，表示期望接收的下一个字节序号。
- 示例：若接收端收到序号为100的10字节数据（即100~109），则确认序号为110，说明“已收到109及之前的所有数据，下一步请发110开始的内容”。

两者配合实现了TCP的可靠传输：序号确保数据有序，确认序号确保数据不丢失，是TCP面向连接、可靠通信的基础。

TCP的序号和确认序号之所以不能用一个字段（或“表”）表示，核心原因是它们承担的角色、作用对象和逻辑含义完全不同，属于两个独立的通信维度，具体可从以下角度理解：

- 角色不同：序号是发送端标识自己发出的数据位置（“我发的是从X开始的数据”）；确认序号是接收端告知发送端“我已经收到了哪些数据，你接下来该发什么”。两者分别对应“发送”和“接收确认”两个方向的逻辑，无法合并。
- 作用对象不同：序号针对的是本地发送的字节流，由发送端主动生成，随数据一起传递；确认序号针对的是对端发送的字节流，由接收端根据已接收的数据计算得出，用于回应对端。一个是“自己发的”，一个是“告诉对方我收到的”，对象完全分离。
- 逻辑独立：在TCP双向通信中，双方同时既是发送端也是接收端。例如A向B发送数据时用序号，B向A回复时既用自己的序号（发B的数据），也用确认序号（告诉A“我收到你的数据到哪了”）。如果合并为一个字段，会导致双方的发送和确认逻辑混乱，无法区分“自己发的位置”和“对端该发的位置”。

简单说，序号是“我发了啥”，确认序号是“你该发啥”，两者功能互补但逻辑独立，必须分开表示才能实现TCP双向、可靠的通信机制。

4位首部

0000~1111（0-15）单位4字节；及范围位0-60字节。

TCP首部包含可选字段（如选项和填充），长度不固定（基础首部20字节，加可选字段后最长60字节）。接收端需要通过这个字段确定首部的结束位置，从而区分首部和数据部分（“哪里是首部，哪里开始是数据”）。

6位标志位

在客户端与服务端数据传输过程中，不同的报头会在不同的传输层级进行解除，而这些标识符是为了更好的区分不同报头

- URG（Urgent）：紧急指针有效标志位。当URG = 1时，表示报文中包含紧急数据，接收端应尽快将数据推送到应用层，同时紧急指针字段生效，用于指示紧急数据的位置。
- ACK（Acknowledgment）：确认标志位。若ACK = 1，表明确认序号有效，用于确认收到的报文，通常除了第一个连接请求报文外，其他报文大多会将该位置为1。
- PSH（Push）：推送标志位。当PSH = 1时，通知接收端不要将报文缓存，而是立即将数据交付给应用层处理。
- RST（Reset）：重置标志位。若RST = 1，意味着要求对方重新建立连接，常用于断开异常连接或拒绝无效连接请求。
- SYN（Synchronization）：同步标志位。在TCP三次握手过程中，客户端发送的第一个连接请求报文会将SYN置为1，用于初始化连接并同步序号。
- FIN（Finished）：结束标志位。当FIN = 1时，表明发送端已发送完数据，请求关闭连接，常用于TCP四次挥手过程中通知对方本端即将关闭连接。