从一次上传失败说起
上周备份照片时，手机连着Wi-Fi传到云端，进度到98%突然断了。重新上传又得从头开始，几百张照片再等十分钟。这种情况其实很常见，问题往往不在网速，而在于传输协议靠不靠谱。
确认机制：发出去的消息必须有回音
想象你给同事发微信说“文件发你了”，但对方没回“收到”。你不确定他是看到了没理你，还是根本没收到。网络传输也一样，发出去的数据包如果没有确认机制，发送方永远不知道对方到底拿到没有。
TCP 协议的做法是每发一段数据，就等接收方返回一个 ACK（确认信号）。如果超时没收到，就重发。这个逻辑看起来简单，但在地铁里信号忽强忽弱时特别管用。
数据分片与重组
一个大文件不能一口气扔过去。网络链路像小巷子，太宽的车过不去。通常要把数据切成一个个小包，每个包带上编号，就像快递包裹贴上运单号。
接收方按编号把碎片拼回去，缺了哪一帧就告诉发送方补发。比如视频会议时某帧画面花了一下，很快又恢复正常，很可能就是中间丢了个包，靠重传补上了。
<packet>
<seq>1001</seq>
<data>...</data>
<checksum>A3F2</checksum>
</packet>校验和：防止数据被悄悄篡改
数据在传输过程中可能被干扰。比如路由器内存出错，某个字节变了，接收方却当成正确的收下。为了避免这种情况，每个数据包都要带一个校验和（checksum）。
接收方收到后重新算一遍校验值，和包里的对不上，就说明数据坏了，直接丢掉让对方重发。这就像寄贵重物品时做清单，开箱发现不对立刻拒收。
流量控制：别让接收方被压垮
发送方火力全开，接收方处理不过来，结果只能不断丢包重传，反而更慢。TCP 用滑动窗口机制控制发送节奏——接收方告诉对方：“我现在只能接5个包，多了不要发”。
这就像餐厅门口放个牌子：“当前排队等候5桌”，新客人来了就知道得等等，不会一窝蜂挤进去。
应对网络波动：自适应超时重传
固定3秒没回应就重发，并不适合所有场景。4G信号差的时候延迟可能飙到5秒，这时候3秒就重传，会造成大量重复数据。聪明的做法是动态计算平均往返时间（RTT），再乘个系数作为超时阈值。
就像你打电话催快递员，第一次等两分钟打，发现他总要三分钟才回，下次你就等四分钟再催。
加密不是附加题
明文传密码、传身份信息，等于把银行卡和密码一起塞进透明信封寄出去。哪怕协议再可靠，数据被中间人截获就全完了。TLS 加密应该从一开始就被考虑进去，而不是事后打补丁。
现在很多应用层协议都在默认启用加密，比如 HTTPS、MQTT over TLS。不加密的传输，在今天已经谈不上“可靠”了。