传输层在协议栈中的位置
打开网页、刷视频、发消息，这些日常操作背后都离不开网络通信。而数据能准确送达，靠的是网络协议分层设计。传输层就处在整个协议栈的中间位置，夹在上层的应用和下层的网络之间，像一个快递中转站，负责把数据打包、编号、检查错误，再交给下一层发送出去。
常见的协议栈模型是TCP/IP四层结构：应用层、传输层、网络层、链路层。传输层承上启下，直接为应用服务，比如浏览器用HTTP，其实底层依赖的是传输层的TCP协议。
TCP：可靠传输的主力
你在网上银行转账时，肯定不希望数据丢包或出错。这时候就得靠TCP（传输控制协议）。它提供面向连接的通信，发送前先“握手”，建立稳定通道。每个数据包都有序号，接收方要确认收到，没收到就会重传。这种机制保证了数据完整，但代价是速度慢一点。
比如你下载一份合同文件，哪怕只丢了一个包，TCP也会发现并要求补发，直到全部收齐才交给应用程序。
UDP：快而不纠结
看直播的时候，偶尔画面卡一下，但声音还在继续，这是因为用的是UDP（用户数据报协议）。它不建立连接，也不确认是否收到，发出去就不管了。虽然可能丢包，但胜在速度快、开销小。
像在线游戏、语音通话这类对实时性要求高的场景，宁愿牺牲一点完整性，也要保证低延迟，UDP就是首选。
端口号：区分不同应用的门牌号
一台手机同时运行微信、浏览器、音乐App，怎么知道哪个数据该给谁？靠的就是端口号。传输层在数据头部加上源端口和目标端口，就像写明寄件人和收件人的门牌号。
比如访问网站通常走80端口（HTTP）或443端口（HTTPS），而DNS查询用53端口。操作系统根据端口号把数据准确投递给对应的程序。
协议头结构示例
TCP和UDP虽然功能不同，但都有自己的头部格式，用来携带控制信息。
TCP头部（简化）：<br>
源端口（16位） | 目标端口（16位）<br>
序列号（32位）<br>
确认号（32位）<br>
数据偏移 | 保留 | 标志位 | 窗口大小<br>
校验和 | 紧急指针<br>
选项（可变） | 数据UDP头部（更简单）：<br>
源端口（16位） | 目标端口（16位）<br>
长度（16位） | 校验和（16位）<br>
数据可以看到，TCP头部复杂得多，支持流量控制、拥塞控制等功能；UDP则尽量精简，减少处理时间。
实际工作流程
当你在浏览器输入网址，系统会根据协议选择传输层方式。如果是加载网页，应用层生成HTTP请求后，交给TCP处理。TCP将其拆成段，加上头部，再传给网络层封装成IP包。到了对方服务器，再一层层拆解，TCP重组数据，确认无误后交给Web服务程序。
如果是发一条语音消息，App可能直接用UDP发送音频帧。即使偶尔丢一两帧，听起来只是轻微杂音，不影响整体流畅性。
传输层的存在，让上层应用不必关心底层网络细节，只需专注自己的逻辑。无论是追求可靠的TCP，还是讲求速度的UDP，都在各自适合的场景里默默工作。