应用层协议和传输层，到底谁听谁的？
打开网页、刷短视频、收发邮件，这些日常操作背后其实都有两层在悄悄配合——应用层和传输层。很多人觉得应用层是“干活的”，传输层是“跑腿的”，但它们之间的关系远不止这么简单。
应用层决定“说什么”，传输层决定“怎么送”
你可以把应用层协议理解成写信的人，比如 HTTP 写的是网页请求，SMTP 写的是邮件内容，FTP 写的是文件传输指令。这些协议定义了数据的格式和交互规则。但光有内容不行，还得有人把这封信安全送到对方手上——这就是传输层的事儿了。
传输层不关心你写的是网页还是邮件，它只管把数据从一台机器搬到另一台。常见的传输层协议有 TCP 和 UDP。TCP 像个靠谱快递员，保证包裹完整送达，顺序不错，丢了还会重发；UDP 则像寄明信片，发出去就不管了，速度快但可能丢件。
HTTP 为什么选 TCP？因为不能出错
当你在浏览器输入一个网址，HTTP 协议就开始工作了。它需要把请求发给服务器，再把完整的网页内容拿回来。这个过程容不得半点差错——少一张图片还能看，少一段 HTML 标签可能整个页面都乱套。
所以 HTTP 默认用 TCP 作为传输层协议。看看实际的数据包就能明白：
GET /index.html HTTP/1.1\r\nHost: www.example.com\r\n\r\nDNS 用 UDP 是为了快，但也留了后路
DNS 看似也是关键服务，但它多数时候用的是 UDP。因为 DNS 查询通常很小，一次请求加响应不超过 512 字节，用 UDP 发一个包就搞定，来回延迟低。用户感觉不到卡顿，体验就好。
但 UDP 不保证送达，万一丢包了怎么办？系统会自动重试，或者回退到 TCP。就像打电话没人接，你会再拨一次。这种设计在效率和可靠性之间找到了平衡。
视频通话靠 UDP，丢几帧也无妨
像 Zoom、腾讯会议这类实时通信，用的是 RTP 协议，跑在 UDP 上。为什么不怕丢包？因为音视频流讲究实时性。如果每丢一个数据包都要重传，画面就会卡顿，反而更影响体验。宁可模糊一帧，也不能停三秒。
这时候应用层就得自己想办法补救，比如前向纠错、动态码率调整。传输层提供的是通道，但上层得学会“适应路况”。
端口号：应用层和传输层的接头暗号
一台服务器可能同时运行着 Web、邮件、FTP 多种服务，传输层怎么知道收到的数据该交给谁？靠端口号。比如 TCP 收到一个数据段，看到目标端口是 80，就知道这是给 HTTP 的；如果是 53，就得转给 DNS 服务。
这就像是公司前台，根据来件上的部门编号，把快递分发到对应办公室。没有这个机制，再多的应用层协议也没法共存。
HTTPS 并没有脱离传输层，而是加了一层保护
很多人以为 HTTPS 是个全新的协议，其实它还是 HTTP，只是在应用层和传输层之间加了 TLS/SSL 加密层。真正的变化不在传输方式，而在于数据被加密了。
即便如此，它依然依赖 TCP。加密后的数据照样要拆段、编号、重传——这些底层工作一点没省。只不过现在快递员送的不是明信，而是一封封密封的信件。