目录
https
加密类型
对称加密
非对称加密
加密方案
只用对程加密
只用非对程加密
双方都是用非对程加密
非对称+对称加密
非对称+对称加密+证书
流程图
校验流程图
udp
udp协议格式
特点
UDP缓冲区
tcp
tcp协议格式
32位序号及确认序号
4位首部
6位标志位
16位窗口大小
16位紧急指针
超时处理
连接管理机制
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协议格式
数据长度=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
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时，表示报文中包含紧急数据，接收端应尽快将数据推送到应用层，同时紧急指针字段生效，用于指示紧急数据的位置。
紧急指针字段：指向紧急处理数据的偏移量，大小1字节。
应用场景：当服务端与客户端通信过程中，服务端因为过载而对客户端的数据无法做出响应，客户端并不知道，仍然连续的发送数据，此时如果客户端想要知道服务端出现的问题，可以发送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四次挥手过程中通知对方本端即将关闭连接。
16位窗口大小
TCP报头中的16位窗口大小字段用于指定接收方的缓冲区大小，告知发送方自己还有多少缓冲空间可以用来接收数据，主要用于流量控制和提高传输效率 。
16位紧急指针
紧急指针就像快递包裹上的“加急标签”，但它不光贴标签，还告诉你“加急内容到哪结束”。
- 当URG标志位（相当于“加急”开关）打开时，紧急指针才有用。
- 它的值是个数字，比如5。
- 结合当前包裹的“起始序号”（比如100），100 + 5 = 105，意思就是：从100开始，到104为止的这5个字节是紧急数据，接收方得先处理这部分，剩下的再慢慢处理。
简单说：URG=1时，紧急指针+序号=紧急数据结束的下一个位置，帮接收方快速找到“要先处理的内容”。
超时处理
情景1：数据发送失败，丢包
情景2：应答超时
客户端没有收到应答，可能会重复的发送数据，如果是网络超时，那么后面服务器会收到多条重复消息，因此服务器就要处理这些重复的数据，其这个时候我们就可以使用上述的序列号进行去重
最理想的情况下, 找到一个最小的时间, 保证 "确认应答一定能在这个时间内返回".
1.但是这个时间的长短, 随着网络环境的不同, 是有差异的.
2.如果超时时间设的太长, 会影响整体的重传效率;
3.如果超时时间设的太短, 有可能会频繁发送重复的包;
4.TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间.
Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时
##时间都是500ms的整数倍.
##如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传.
##如果仍然得不到应答, 等待 4*500ms 进行重传. 依次类推, 以指数形式递增.
##累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接.
连接管理机制
通讯为什么要三次握手
1.验证全双工
2.奇数次握手，可以确保一般情况下握手失败的链接成本是嫁接在客户端的
不同次挥手对比
一次握手
单次握手：如果客户端重复性的向服务器发起建立链接，就会大量占用服务器的内存资源，可能会导致服务器崩溃，虽然三次握手也可能会出现类似情况，但是三次握手建立失败立即会进行清除，且三次握手链接周期较长，因此三次握手，优于一次握手
二次握手
两次握手时，如果第2次握手失败，因为服务端会先建立链接，之后客户端再建立链接，如果第2次失败客户端不会建立链接，然而服务端建立了链接会且需要花费一定的时间才会将该链接断开，因此失败的代价由服务端承担
三次握手
三次握手链接的建立需要花费一定的时间，同时如果链接失败会将链接清除，又因为是基数次握手，链接失败的代价由客户端承担，因此他的方案更优
超详细)
)
