你发一条微信语音，看一段高清视频，或者远程连上公司电脑——这些操作背后，数据其实不是整块儿发过去的。就像快递员不会把一整车货直接塞进你家信箱，网络也得把大块数据切成小包，再按规则重新拼好。这个过程，就是数据包的拆分与合并。
为什么不能一次发完？
以太网帧最大只能承载1500字节的有效载荷（MTU），Wi-Fi、PPP、甚至某些VPN隧道还会更小。而一个2MB的PDF文件、一段4K视频流，动辄几兆甚至几十兆，远超单个数据帧的“胃口”。硬塞？不行——设备会直接丢弃超长包，通信就断了。
所以，TCP协议在发数据前会先查路径上的最小MTU（叫“路径MTU发现”），再把应用层交来的数据流，按这个尺寸切分成一个个“段”（segment）；IP层再给每个段加头，封装成“数据包”（packet）；最后链路层打包成“帧”（frame）发出去。
拆分不是乱切，合并也不是瞎拼
拆分时，TCP会给每个段打上序号（Sequence Number）。比如原始数据从字节0开始，第一个段带0~1459（1460字节），第二个段带1460~2919……即使后发的包先到，接收方也能靠序号把它插回原位。
另外，IP层本身也有分片能力（IP Fragmentation），但这是下策——路由器一旦分片，只要其中一片丢失，整组都要重传。现代网络更倾向让源端（TCP）提前切好，避免中间设备折腾。
举个真实例子
你在用浏览器打开 https://www.example.com，网页HTML约8KB。TCP把它切成6个MSS=1460字节的段，编号0/1460/2920/4380/5840/7300。网络中某台路由器延迟高，第3段（2920~4379）晚到了200ms，其他5段已到。接收方不急着交付给浏览器，而是缓存起来，等第3段一到，立刻按序组装成完整HTML，再交给渲染引擎。
抓个包看看真家伙
用Wireshark抓本地HTTP请求，过滤 tcp.stream eq 0，你会看到连续几个TCP包，Info列写着：
TCP Segment of a Reassembled PDU
TCP Segment of a Reassembled PDU
[TCP Retransmission]
TCP Segment of a Reassembled PDU最后一行说明：之前某段丢了，重发了一次；前面带“Reassembled”的，是Wireshark帮你自动拼好的逻辑视图。
别把拆分和NAT、代理混为一谈
有人以为“代理服务器改IP”或“路由器做端口映射”也算拆分合并——不是。那些是地址转换或转发策略，不改变原始数据内容和序号逻辑。真正管拆与合的，是终端设备上的TCP/IP协议栈，不是中间盒子。
下次网速慢、视频卡顿，不妨想想：是不是某个环节的包被反复重传？或是路径MTU被错误设置导致频繁分片？弄懂拆分合并，排查网络问题就多了一双透视眼。