传输控制协议（TCP）

一、什么是TCP

定义：TCP（Transmission Control Protocol，传输控制协议）是TCP/IP协议族中的核心传输层协议 ，提供面向连接、可靠、面向字节流的传输服务。

二、TCP的核心特点

特点	说明
面向连接	通信前必须建立连接（三次握手），通信后释放连接（四次挥手）
可靠传输	确认机制 + 超时重传，保证数据完整、按序到达
面向字节流	应用层数据被视为连续的字节流，TCP可以拆分、合并发送
全双工	双方可以同时发送和接收数据
流量控制	使用滑动窗口，防止发送方过快淹没接收方
拥塞控制	根据网络状况动态调整发送速率，防止网络崩溃
点对点	每条TCP连接只能有两个端点（一对一，不支持组播/广播）

三、TCP报文段格式

格式图

段	长度	作用
源端口	2字节	发送方进程的端口号
目的端口	2字节	接收方进程的端口号
序号	4字节	标识本TCP段发送的第一个字节的编号（用于有序重组）
确认号	4字节	告诉对方"我收到了序号X及之前的所有数据，请从X+1开始发"
数据偏移	4位	TCP首部的长度（单位：4字节）。范围5-15（即20-60字节）。名称"偏移"意为它指明了数据部分开始的字节偏移量
保留	3位	保留未用，必须为0
标志位	9位（实际常用6位）	控制连接状态，见下表
窗口大小	2字节	告诉对方"我的接收缓冲区还有多少空闲"（流量控制）
校验和	2字节	校验TCP首部+数据+伪首部（类似UDP）
紧急指针	2字节	与URG标志配合，指向紧急数据的末尾
选项	可变	如MSS（最大段大小）、SACK（选择确认）、时间戳等
数据	可变	应用层传输的数据

标志位详解

标志	英文	含义	作用
URG	Urgent	紧急指针有效	紧急数据立即处理，不排队
ACK	Acknowledgment	确认号有效	表示该"确认号"对应字段有效。
PSH	Push	推送	要求接收方立即将数据交给应用层，不要等待缓冲区填满
RST	Reset	重置连接	表示需要立即重置（强制断开）当前连接，通常用于处理异常或错误
SYN	Synchronize	同步序号	在建立连接时使用，用于发起连接请求和同步初始序列号（三次握手）
FIN	Finish	结束	在释放连接时使用，表示数据发送完毕，请求关闭连接（四次挥手）

四、TCP的可靠传输机制

TCP通过四大机制 保证可靠性：校验和 + 序号/确认号 + 超时重传 + 流量控制/拥塞控制。

4.1 校验和

与UDP相同：计算伪首部+TCP首部+数据，检测数据在传输过程中是否损坏。

（点击跳转查看UDP校验和相关知识）

4.2 序号与确认号（核心）

作用：解决乱序、重复、丢失问题。

工作原理：

发送方给每个字节编号（序号）
接收方回复确认号 = 已收到的最后一个字节序号 + 1
发送方根据确认号知道哪些数据已被接收

例子：

复制代码

发送方（序号=1，数据100字节）→ 接收方
接收方收到后，回复确认号=101（表示1-100字节已收，请从101开始发）

如果发送方没收到确认号=101 → 超时后重传序号1-100的数据

为什么初始序号不固定：

防止历史连接的旧数据干扰新连接
防止伪造数据包攻击

4.3 超时重传（RTO）

过程：

发送方发送数据，启动重传计时器
如果收到ACK，取消计时器
如果计时器超时仍未收到ACK，重传该数据
超时时间（RTO）动态调整 ≈ 2 × RTT（往返时间）

RTT估算：

每次发送测量RTT
加权平均：RTTs = α × RTTs + (1-α) × 新RTT（α通常=0.875）
RTO = RTTs + 4 × RTTd（RTTd是偏差）

RTTd = β × RTTd + (1 - β) × |新RTT - RTTs|

β（Beta） ：平滑因子，通常取 0.75 或 0.875。

注意：β 与计算 RTTs 的 α 是两个独立的参数，通常 β > α，意味着 RTTd 比 RTTs 更关注最近的波动。

RTT 估算（RTTs, RTTd） ：是感知网络状态（计算平均往返时间及其波动）。

RTO 计算 ：是制定决策规则（根据感知到的状态，设定一个超时重传的倒计时）。

核心关系总结

概念角色公式/含义目的

RTT 测量 原始数据实际测得的单次往返时间获取真实样本

RTTs 估算结果1 加权平均，反映"基础延迟" 感知网络基础性能

RTTd 估算结果2 加权平均偏差，反映"抖动" 感知网络稳定性

RTO 决策输出 RTTs + 4 × RTTd 设定重传定时器的具体超时时间

流程拆解

测量（Measurement）：每次发送报文并收到确认后，测量得到一个具体的 RTT 样本值。

估算（Estimation）：

平均往返时间（RTTs） ：RTTs = α × RTTs + (1-α) × 新RTT

这是一个指数加权移动平均，用于平滑瞬时波动，得到长期的"标准"RTT。α=0.875 意味着历史值权重很高，更新较慢，避免受单个突发样本影响过大。

偏差（RTTd） ：通常计算为 |新RTT - RTTs|的加权平均，用于衡量 RTT 的波动程度（抖动）。

设定阈值（RTO） ：RTO = RTTs + 4 × RTTd

这是最终的动作触发点。它等于"估算的平均值"加上"4倍的估算偏差"。

逻辑：如果网络稳定（RTTd 小），RTO 就接近 RTTs；如果网络抖动大（RTTd 大），RTO 就会自动变大，给报文更多等待时间，避免不必要的重传。

概念	角色	公式/含义	目的
RTT 测量	原始数据	实际测得的单次往返时间	获取真实样本
RTTs	估算结果1	加权平均，反映"基础延迟"	感知网络基础性能
RTTd	估算结果2	加权平均偏差，反映"抖动"	感知网络稳定性
RTO	决策输出	`RTTs + 4 × RTTd`	设定重传定时器的具体超时时间

4.4 快速重传（优化）

问题：超时重传等待时间太长（可能几百毫秒到几秒）。

快速重传：

接收方收到失序段 时，立即回复重复ACK（比如缺了第3段，收到第4段时，仍然回复ACK=3）
发送方连续收到3个重复ACK → 立即重传丢失的段（不等超时）

例子：

复制代码

发送：1  2  3  4  5
接收：1  ✓  2  ✓  4  ✗（3丢失） 5  ✗
接收方回复：ACK=2（收到1）  ACK=3（收到2）  ACK=3（收到4）  ACK=3（收到5）
发送方收到3个ACK=3 → 立即重传序号3

一、为什么不能收到 1 个重复 ACK 就重传？

因为网络本身是乱序的。数据包在 IP 层可能会走不同的路径，导致后发的包先到（这种现象非常普遍）。

场景还原：假设发送了包 3 和包 4。包 3 在路上稍微慢了一点，包 4 先到了。

接收方行为 ：收到包 4（失序），根据 TCP 规范，它必须回复它期望收到的下一个序号，也就是 ACK=3（意思是"我还在等 3"）。

如果阈值是 1 ：发送方一看到这个 ACK=3，会误以为包 3 丢了，立即重传 。但实际上包 3 可能马上就到，这就造成了不必要的重传，浪费带宽。

结论：1 个重复 ACK 极有可能是网络乱序造成的假象，不足以证明丢包。

二、为什么是 3 个？（核心逻辑）

3 个重复 ACK 是"丢包"的强信号。它的逻辑推理链条如下：

触发条件：发送方收到 3 个完全相同的 ACK（比如 ACK=3）。

推导过程：

接收方收到一个包（比如包 4）后回复 ACK=3。

接着又收到一个包（比如包 5），发现还是缺 3，再次回复 ACK=3。

接着又收到一个包（比如包 6），发现还是缺 3，第三次回复 ACK=3。

逻辑判断：

如果是乱序：包 3 应该会在包 4、5、6 中的某一个之后"挤"出来到达。连续收到 3 个后续包，而中间的包 3 还没到，是乱序的概率已经很低了。

如果是丢包：包 3 彻底没了，接收方会一直收到后续的包，并一直回复 ACK=3。连续 3 个重复 ACK 是丢包的大概率事件。

"3" 的工程意义 ：它设置了一个门槛，过滤掉了大部分普通的网络抖动和乱序，只对高概率的丢包做出快速反应。

三、为什么不是 2 个或 4 个？

2 个 ：太激进。容易把网络乱序误判为丢包，导致过度重传。

4 个：太保守。虽然更确定是丢包，但等待的这段时间（多等一个包的时间）降低了"快速"重传的价值。

确认号（ACK）语义： 它的真实定义是**"期望收到的下一个字节序号"**。

ACK = N的含义是："我已经完整收到了序号 N-1 及之前的所有数据，请发送序号为 N 的数据给我。"

发送数据 Seq 接收方状态（逻辑）回复的 ACK 含义（翻译）

1 收到 1，期望下一个是 2 ACK=2 "1 已收到，请发 2"

2 收到 2，期望下一个是 3 ACK=3 "1,2 已收到，请发 3"

4 (乱序) 没收到 3，仍期望 3 ACK=3 "1,2 已收到，3 丢了？请重发 3"

为什么设计成这样？（累积确认）

这种"指下一个"的设计有两个巨大优势：

抗丢包 ：ACK=3意味着 1 和 2 都收到了。即使中间的 ACK 丢失，后续的 ACK 也能连带确认之前的数据。

指洞准 ：在乱序时（如收到 4 没收到 3），回复 ACK=3能精准地告诉发送方："3 这个位置是空的，快补这个洞"。

发送数据 Seq	接收方状态（逻辑）	回复的 ACK	含义（翻译）
1	收到 1，期望下一个是 2	ACK=2	"1 已收到，请发 2"
2	收到 2，期望下一个是 3	ACK=3	"1,2 已收到，请发 3"
4 (乱序)	没收到 3，仍期望 3	ACK=3	"1,2 已收到，3 丢了？请重发 3"

4.5 流量控制（滑动窗口）

目的：防止发送方发送太快，淹没接收方。

原理：

接收方在TCP首部的窗口大小字段告诉发送方："我还有多少空闲缓冲区"
发送方最多发送窗口大小字节的未确认数据

例子：

复制代码

接收方缓冲区大小 = 8192字节
已收到6000字节（但应用只读走了2000字节），剩余空闲 = 8192 - (6000-2000) = 4192
接收方发送窗口=4192给发送方
发送方最多再发4192字节（未确认的）

窗口关闭 ：窗口=0时，发送方停止发送，定期发送窗口探测包检查窗口是否重新打开。

4.6 拥塞控制

目的：防止发送方发送太快，压垮网络（路由器缓存溢出）。

与流量控制的区别：

控制类型	依据	目的
流量控制	接收方缓冲区大小	防止淹没接收方
拥塞控制	网络状况（路由器丢包）	防止压垮网络

四个核心算法：

（1）慢启动（Slow Start）

初始拥塞窗口（cwnd）= 1个MSS（最大段大小）
每收到一个ACK，cwnd 翻倍（指数增长）
直到达到慢启动阈值（ssthresh）

（2）拥塞避免（Congestion Avoidance）

达到ssthresh后，cwnd 线性增长（每收到一个ACK，cwnd += 1/cwnd）
试探网络可用带宽

（3）快速重传（已介绍）

收到3个重复ACK → 立即重传

（4）快速恢复（Fast Recovery）

发生丢包（收到3个重复ACK）时：
- ssthresh = cwnd / 2
- cwnd = ssthresh + 3
- 进入拥塞避免（不重新慢启动）

拥塞控制状态机：

复制代码

慢启动（cwnd指数增长）
    ↓ 达到ssthresh
拥塞避免（cwnd线性增长）
    ↓ 发生丢包
快速重传 + 快速恢复（cwnd减半）
    ↓
回到拥塞避免

五、TCP的连接管理

5.1 三次握手（建立连接）

目的：同步双方的初始序号，确认双方都能收发。

流程图：

复制代码

客户端（主动）                        服务器（被动）
     │                                    │
     │────── SYN=1, seq=x ──────────────→│  ① 客户端请求连接
     │                                    │
     │←─── SYN=1, ACK=1, seq=y, ack=x+1 ──│  ② 服务器应答并请求
     │                                    │
     │────── ACK=1, seq=x+1, ack=y+1 ───→│  ③ 客户端确认
     │                                    │
  已建立                               已建立

每一步的作用：

步骤	方向	作用
① SYN	C → S	客户端告诉服务器："我的初始序号是x，我想建立连接"
② SYN+ACK	S → C	服务器告诉客户端："我同意，我的初始序号是y，你发的x我收到了"
③ ACK	C → S	客户端告诉服务器："你发的y我收到了，连接建立"

（SYN, ACK）是 TCP 报文头部的控制标志位，用来告诉对方"我现在要做什么"。

SYN (Synchronize) ：建立连接 。只在连接的起始阶段（三次握手的第一次和第二次）出现。一旦连接建立，后续的普通数据传输就不再需要 SYN 了。

第一次握手：客户端说"我要建立连接" →带上 SYN。

第二次握手：服务器说"我也同意建立连接" →带上 SYN。

第三次握手：连接已同步，不需要再发 SYN。

ACK (Acknowledgment) ：确认收到 。一旦连接建立，之后的每一个报文都必须带上 ACK（确认号有效）。

第一次握手：还没有正式连接，通常不置位 ACK（或者置位但无意义）。

第二次握手：服务器必须回复确认收到了客户端的 SYN（客户端 --> 服务端已建立） →带上 ACK。

第三次握手：客户端必须确认回复收到了服务器的 SYN （服务端 --> 客户端已建立）→带上 ACK。

① 序列号 (seq) 的规律

定义：seq是发送方本次报文段的起始序号，它告诉接收方"我这次发的数据是从哪里开始的"。

核心规则：

初始值 ：每个连接方向（客户端到服务器，服务器到客户端）的初始 seq是一个随机数（图中的 x, y）。

控制位占号 ：SYN和 FIN标志位是特殊的控制信号，它们各自消耗一个序号 。可以理解为，发送一个 SYN或 FIN就像发送了1字节的控制信息。

序号增长规律：

发送应用数据 时：下一个 seq = 当前 seq + 发送的字节数

发送控制位 时：下一个 seq = 当前 seq + 1（因为 SYN/FIN各算作"1字节"）

重要：ACK标志位不消耗序号 。发送纯 ACK包（不带数据）时，seq保持不变。

举例理解：

发 SYN（seq=x）后，下一个可用序号是 x+1。

接下来发纯 ACK（seq=x+1）后，下一个可用序号还是 x+1（因为ACK不占号）。

再发数据"Hi"（2字节，seq=x+1）后，下一个可用序号是 x+3。

好的，我来修改这两段定义，让它们更直观、准确，并消除潜在的歧义。

① 序列号 (seq) 的规律

定义：seq是发送方本次报文段的起始序号，它告诉接收方"我这次发的数据是从哪里开始的"。

核心规则：

初始值 ：每个连接方向（客户端到服务器，服务器到客户端）的初始 seq是一个随机数（图中的 x, y）。

控制位占号 ：SYN和 FIN标志位是特殊的控制信号，它们各自消耗一个序号 。可以理解为，发送一个 SYN或 FIN就像发送了1字节的控制信息。

序号增长规律：

发送应用数据 时：下一个 seq = 当前 seq + 发送的字节数

发送控制位 时：下一个 seq = 当前 seq + 1（因为 SYN/FIN各算作"1字节"）

重要：ACK标志位不消耗序号 。发送纯 ACK包（不带数据）时，seq保持不变。

举例理解：

发 SYN（seq=x）后，下一个可用序号是 x+1。

接下来发纯 ACK（seq=x+1）后，下一个可用序号还是 x+1（因为ACK不占号）。

再发数据"Hi"（2字节，seq=x+1）后，下一个可用序号是 x+3。

② 确认号 (ack) 的规律

定义：ack是接收方对发送方的明确承诺 ，意思是："你发送的、序号小于 ack的所有数据我都已经收到，我下一个期望收到的是序号为 ack的数据"。

核心规则：

基本公式 ：ack = 收到的最后一个连续字节的序号 + 1

对 SYN/FIN 的确认 ：因为 SYN（或 FIN）本身消耗了一个序号，所以确认它时，ack需要在对方的 seq基础上加 1。

对数据的确认 ：确认一个包含 N 字节数据的报文段时，ack需要在对方的 seq基础上加 N。

数学表达：

ack= 对方本次报文段的 seq+ 对方本次报文段中"被消耗的序号数"

其中"被消耗的序号数"是：

如果报文段包含 SYN或 FIN标志：+1

如果报文段包含应用数据：+ 数据字节数

（ACK标志不贡献任何"被消耗的序号数"）

第一次握手（Client → Server）：

发送 SYN。SYN占用一个序号（x）。

结果：Client 的发送序列号变为 x + 1（因为 x已被 SYN占用）。

第二次握手（Server → Client）：

发送 SYN + ACK。SYN占用一个序号（y）。

结果：Server 的发送序列号变为 y + 1。

第三次握手（Client → Server）：

关键点：Client 发送的只是一个 ACK。

ACK标志位不占用新的序列号。

此时 Client 没有发送任何新的数据（Data Length = 0），也没有发送新的 SYN或 FIN。

计算：seq = 上次 seq + 数据长度 = (x+1) + 0 = x+1

结论：seq保持不变，依然是 x+1。

为什么不是两次：

防止历史连接请求干扰（如果网络延迟，旧SYN包在连接释放后才到达，两次握手会错误建立新连接）
防止SYN洪水攻击（三次握手的第三步才分配资源，可做防护）

为什么不是四次：三次已经足够同步序号，四次浪费。

5.2 四次挥手（释放连接）

目的：双方各自关闭连接，释放资源。

流程图：

复制代码

客户端                                      服务器
     │                                          │
     │────── FIN=1, seq=u ───────────────────→│  ① 客户端说"我发完了"
     │                                          │
     │←───── ACK=1, seq=v, ack=u+1 ───────────│  ② 服务器应答"收到你的FIN"
     │                                          │
     │         （此时客户端不能发，但服务器还能发）   │
     │                                          │
     │←───── FIN=1, ACK=1, seq=w, ack=u+1 ────│  ③ 服务器说"我也发完了"
     │                                          │
     │────── ACK=1, seq=u+1, ack=w+1 ────────→│  ④ 客户端应答"收到你的FIN"
     │                                          │
  关闭                                       关闭

为什么是四次：

TCP是全双工的，双方需要各自关闭自己方向的传输
客户端发FIN，表示不再发送数据，但还可以接收
服务器发FIN，表示也不再发送
每一方的关闭都需要一次FIN和一次ACK，所以2×2=4次

TIME_WAIT状态（客户端发送最后一个ACK后）：

等待 2MSL（Maximum Segment Lifetime，通常2分钟）
原因：确保服务器收到最后一个ACK；++防止旧连接的数据包干扰新连接++

旧连接结束 ：你和服务器进行了一次通信（旧连接），发送了一些数据包（比如 seq=100到 seq=200）。

立即重启 ：旧连接刚结束，你立刻用相同的四元组 （源IP、源端口、目的IP、目的端口）建立了新连接。

幽灵迟到包 ：此时，旧连接中某个延迟了很久 的数据包（比如 seq=150），经过网络绕路，突然到达了服务器。

灾难发生 ：服务器看到 seq=150，发现它在当前新连接的接收窗口内（因为新连接的初始序列号虽然随机，但可能刚好覆盖这个范围），会误以为这是新连接的数据 ，从而接收并处理这个过期的、错误的数据。

这就是"干扰新连接"：旧连接的"僵尸包"被新连接误认，导致数据错乱或安全漏洞。
TIME_WAIT 如何充当"净化期"？

TIME_WAIT状态（通常为 2MSL ，即 2 倍报文最大生存时间）的作用，就是给这个连接打上一个 "冷却期"或"静默期"。

**MSL (Maximum Segment Lifetime)** 定义了一个数据包在网络中"存活"的最长时间（通常 1-2 分钟）。等待 2MSL 意味着：

彻底清除旧包 ：确保旧连接产生的所有数据包（包括重传的、绕路的）都已经在网络中"老死"（超过生存时间被丢弃）。

强制隔离 ：在 2MSL 期间，不允许立即使用相同的四元组建立新连接。这就物理上阻断了旧包混入新连接的可能性。

为什么是"2MSL"而不是 1MSL？

这是一个双向保险机制：

1MSL ：等待我发出的最后一个 ACK 在网络中正确消失（防止它丢失后我重发，干扰别人）。

1MSL ：等待对方可能重发的 FIN 在网络中消失（防止它重发的 FIN 被我新连接误认）。

2MSL = 1MSL(我方) + 1MSL(对方)

六、TCP的面向字节流

含义：TCP将应用层数据视为连续的字节流，没有边界。

后果：

发送方可以合并小的数据块一起发送（Nagle算法）
接收方可以拆分大的数据块分多次读取
应用层需要自己设计消息边界（如使用长度前缀、分隔符）

对比UDP：

协议	数据边界	发送	接收
UDP	保留	发100字节	一次收100字节
TCP	不保留	发100字节	可能一次收50字节，下次收50字节

七、常用网络端口与服务详解

端口	服务	协议全称	核心功能与特性	典型应用/注意
20/21	FTP	File Transfer Protocol	21端口（控制）：建立连接、发送命令。 20端口（数据）：实际传输文件内容。	⚠️ 高危：默认明文传输（账号密码、文件均暴露），生产环境务必使用 SFTP(22) 或 FTPS。
22	SSH	Secure Shell	加密的远程管理。提供安全的命令行登录、文件传输（SFTP）、端口转发。	服务器运维的标准入口。相比 Telnet 的绝对安全替代。
23	Telnet	Teletype Network	明文的远程终端。功能类似SSH，但无任何加密。	⚠️ 高危：仅用于内网调试或老旧设备，互联网环境极易被嗅探。
25	SMTP	Simple Mail Transfer Protocol	邮件发送协议。负责"从客户端/服务器"将邮件推送到邮件服务器。	通常用于邮件服务器之间的通信（MTA to MTA）。
80	HTTP	HyperText Transfer Protocol	超文本传输协议。传输网页、图片等，但内容未加密。	浏览器默认访问端口。HTTP/2、HTTP/3 仍可用此端口。
110	POP3	Post Office Protocol v3	邮局协议。从服务器下载邮件到本地（通常下载后删除服务器副本）。	早期客户端常用（如Outlook），适合单设备查看。
143	IMAP	Internet Message Access Protocol	互联网消息访问协议。在服务器上管理邮件（文件夹、状态同步）。	现代主流，支持多设备（手机、电脑）同步邮件状态。
443	HTTPS	HTTP Secure	安全的HTTP。在 HTTP 基础上增加 SSL/TLS 加密层。	现代网站标配，用于登录、支付等敏感操作。
3306	MySQL	MySQL Database	关系型数据库服务。接收客户端的 SQL 查询并返回结果。	⚠️ 安全建议：默认不应暴露在公网，需配合防火墙限制访问IP。
3389	RDP	Remote Desktop Protocol	远程桌面协议。图形化远程控制 Windows 服务器/PC。	⚠️ 高危：是黑客爆破的重灾区，公网暴露需设强密码或改端口。

FTP vs SFTP vs FTPS

1. FTP（File Transfer Protocol）

定义：明文传输文件，无加密
通俗理解：像寄明信片，路上谁都能看到内容（账号、密码、文件全部暴露）
结论：⚠️ 不安全，生产环境禁止使用

2. FTPS（FTP over SSL/TLS）

定义：在 FTP 基础上增加 SSL/TLS 加密层
通俗理解：给明信片加了个密封信封，别人看不到内容了
结论：比 FTP 安全，但配置稍复杂，不如 SFTP 常用

3. SFTP（SSH File Transfer Protocol）

定义：基于 SSH 协议的文件传输
通俗理解：走的是加密的"安全通道"，配置简单，一条命令就能用
结论：✅ 最推荐，生产环境首选

SMTP vs POP3 vs IMAP

1. SMTP（Simple Mail Transfer Protocol）

定义：邮件发送协议，负责把邮件"推"到服务器
通俗理解：邮局的寄信口，只管把信投递出去，不管收信
结论：只负责发，不收

2. POP3（Post Office Protocol version 3）

定义：从服务器下载邮件到本地，通常删除服务器副本
通俗理解：从邮局把信拿回家，邮局里的信就没了
结论：适合单一设备使用，换设备就看不到历史邮件

3. IMAP（Internet Message Access Protocol）

定义：邮件保留在服务器上，多设备状态同步
通俗理解：邮局帮你保管信，手机、电脑看到的完全一样（已读/删除会同步）
结论：✅ 现代主流，适合多设备使用

HTTP vs HTTPS

1. HTTP（HyperText Transfer Protocol）

定义：明文传输网页数据，无加密
通俗理解：像大声念出银行卡密码，周围人都能听见
结论：⚠️ 不安全，不适用于敏感信息

2. HTTPS（HTTP Secure）

定义：HTTP + SSL/TLS 加密层
通俗理解：把密码写进保险箱再送出去，别人截获也打不开
结论：✅ 现代网站标配，登录/支付必用

Telnet vs SSH

1. Telnet（Teletype Network）

定义：明文远程终端协议
通俗理解：对着玻璃房里的电脑喊密码，路人都能听到
结论：⚠️ 极不安全，已被淘汰

2. SSH（Secure Shell）

定义：加密远程管理协议
通俗理解：走进密室操作电脑，外面谁也看不到
结论：✅ Telnet 的完全替代品，服务器运维标准入口

RDP（单独说明）

1. RDP（Remote Desktop Protocol）

定义：图形化远程桌面协议
通俗理解：像隔空操作对方的屏幕，能看到桌面、鼠标、窗口
结论：适合 Windows 远程管理

2. 安全警告

问题：3389 端口是黑客暴力破解的重灾区
建议：不要直接暴露在公网，用 VPN 或跳板机访问 + 强密码

八、TCP vs UDP 总结对比

维度	TCP	UDP
连接	面向连接	无连接
可靠性	可靠（确认+重传）	不可靠
顺序	保证	不保证
流量控制	有（滑动窗口）	无
拥塞控制	有	无
面向	字节流	报文
首部	20-60字节	8字节
效率	较低	较高
速度	较慢	较快
组播/广播	不支持	支持
典型应用	HTTP、FTP、SSH	DNS、游戏、音视频

（查看用户数据报协议（UDP）点击跳转）