linux_https，udp，tcp协议（更新中）
目录
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次失败客户端不会建立链接，然而服务端建立了链接会且需要花费一定的时间才会将该链接断开，因此失败的代价由服务端承担
三次握手
三次握手链接的建立需要花费一定的时间，同时如果链接失败会将链接清除，又因为是基数次握手，链接失败的代价由客户端承担，因此他的方案更优
滑动窗口
发送缓冲区的处理机制类似于滑动窗口，其大小目前认为不能超过对方接收缓冲区的大小。
问题剖析：
若通信过程中确认应答丢失：
发送2000~6000编号的数据包，其中3000~4000，数据包的确认应答丢失，那么其后续的5000的返回应答依然可以证明该数据包成功送达。
如果是5000~6000编号数据包的返回应答丢失，那么就超时重传，全部丢失同样如此。
如果通讯过程中数据包丢失
同样发送2000~5000编号的数据包，如果3000~4000的数据包丢失，那么2000 4000 5000的数据包返回值都应该为3001，此时客户端就会知道数据包丢失，就会从3001开始，依次进行重传，当发送3000~4000的数据包以后，若返回值为5001，则说明了全部数据包都已发送成功，若不是则依然重传--快速重传
快速重传是有条件的，它是为了提高效率。而超时重传是兜底的作用，二者并不相同
流量控制
在 TCP 通信里，因接收端处理数据速度有限，若发送端发数据过快，接收端缓冲区会被占满，进而引发丢包、重传等连锁问题，所以有流量控制机制，让发送端依据接收端处理能力调整发送速度 。
核心交互流程
- 接收端告知窗口：接收端把自身可接收的缓冲区大小，放进 TCP 首部“窗口大小”字段，借由 ACK（确认应答）告知发送端 。窗口字段越大，理论上网络吞吐量潜力越高。
- 接收端调整窗口：若接收端发现缓冲区快满，就把窗口大小设为更小值通知发送端；若缓冲区满，窗口置 0 ，此时发送端暂停发数据，但要定期发窗口探测报文段，促使接收端反馈窗口信息 。
- 发送端响应：发送端收到新窗口值后，相应减慢发送速度；若接收端窗口置 0 ，发送端发窗口探测包，探知接收端新窗口状态，收到更新通知后，再按新窗口发数据 。
过程示例
- 正常交互：发送主机 A 发数据（如 1 - 1000 等分段），接收主机 B 回 ACK 并带窗口值（如 3000 ），告知 A 可继续按窗口发后续数据 。
- 缓冲区将满/满时：B 缓冲区快满，窗口值变小（如从 3000 逐步到 0 ）；满时窗口为 0 ，A 暂停常规数据发送，发窗口探测包 。
- 恢复通信：B 缓冲区有空间，发窗口更新通知（如窗口变回 2000 ），A 收到后，按新窗口（如接着发 4001 - 6000 等数据）恢复/调整发送 ，若更新通知丢失，A 因没收到窗口更新，会发探测包确认，保障通信持续 。
补充说明
TCP 首部“窗口大小”字段是 16 位，最大表示 65535 字节，不过 TCP 首部选项里有窗口扩大因子 M ，实际窗口大小为“窗口字段值左移 M 位”，可灵活适配不同网络场景对更大窗口的需求 ，以此精细调控发送端速率，平衡收发两端数据处理节奏，保障 TCP 连接稳定、高效传输数据 。
拥塞控制
TCP 虽有滑动窗口保障数据高效可靠传输，但初始阶段大量发数据，可能因网络实际拥堵（多主机共用网络，状态难预判 ）引发问题，故引入拥塞控制，通过“试探 - 调整”适配网络状态，平衡数据发送与网络负载 。
1. 慢启动（Slow Start）：试探网络承载，谨慎增速率
- 核心逻辑：通信初始，设拥塞窗口（cwnd） 初始值为 1 ；每收到一个 ACK 应答，拥塞窗口 +1 ；实际发送窗口取“拥塞窗口”和“接收端反馈窗口”的较小值 。借少量数据探测，让窗口（发送速率）指数级增长（如初始 1→2→4→8… ），快速逼近网络承载上限，但也存在增长过快风险 。
- 示例（结合图示）：
主机 A 发数据，从 1 - 1000 开始，收 ACK 后窗口增大，后续数据段（1001 - 2000 等）发送量随窗口增长逐步增多，体现“慢启动”前期慢、增长快的特点 。
2. 慢启动阈值：抑制过快增长，切换增长模式
- 引入原因：慢启动指数级增长易超网络承载，需限制。当拥塞窗口达慢启动阈值，增长模式从“指数”切为“线性”（加法增大 ），避免网络因突发大流量拥堵 。
- 动态调整：网络拥塞（大量丢包，超超时重传范畴 ）时，阈值调整为当前拥塞窗口的一半，且拥塞窗口重置为 1 ，重新慢启动探测，比如网络拥塞后，ssthresh 减半，cwnd 回 1 ，再逐步增长适配网络 。
3. 拥塞避免：稳定增速，维持网络健康
- 工作方式：拥塞窗口超阈值后，每收到一批 ACK（或一个 RTT 周期 ），窗口仅 +1 （线性增长 ），缓慢提升发送速率，持续“试探”网络承载上限，同时避免突发流量冲击网络 。
- 流程闭环（结合曲线）：
- 慢启动阶段：cwnd 从 1 开始指数增长，到 ssthresh 后进入拥塞避免；
- 拥塞避免阶段：cwnd 加法增大，若遇网络拥塞（丢包等 ），执行“乘法减小”（ssthresh 减半、cwnd 重置 ），重回慢启动或拥塞避免，循环适配网络状态 。
4. 拥塞控制本质与形象类比
本质是 TCP 在“快速传数据”和“保网络不堵”间找平衡的折中策略——既想高效传输，又通过动态调整发送窗口（速率 ），规避网络因过载彻底拥塞。像“热恋节奏”：初始小心试探（慢启动 ），有回应就大胆些（窗口增长 ），但发现“压力”（网络拥塞信号 ）就收敛，慢慢磨合（拥塞避免 ），持续优化传输与网络的适配度 。
简言之，TCP 拥塞控制借慢启动探底、阈值切增长模式、拥塞避免稳速，动态适配网络，让数据传输在效率与网络健康间找最优解，是保障复杂网络环境下可靠通信的关键机制 。
延迟应答
简单总结就是服务器的接收缓冲区在接收到客户端发送的数据以后不会立即应答，而是稍等一会儿，一段时间内等待上层对数据进行调用，等不到也没短息，有概率能够为服务器接收缓冲区缓冲区腾出更大的空间，嗯，下一次通讯能够接收到更多的数据，提高了这个通讯效率。
他不会对每个数据包都进行延迟应答，而是有间隔且规律性选择
捎带应答
服务器应用从通讯室一问一答制，那么ac k就可以搭上数据包的顺风车-捎带应答
