TCP/IP四层模型精讲：应用层、传输层、网络层、网络接口层的职责与核心协议概览
很多初学者一上来就被OSI七层模型吓住了。说实话，我在实际工作中几乎没见过谁真的拿七层模型去排障。真正干活用的，是TCP/IP四层模型。它更简洁，也更贴近真实网络的工作方式。
今天我就把这四层掰开揉碎了讲清楚。每层干什么活、有哪些核心协议、实际项目中怎么用——咱们一次说透。
为什么是四层？不是七层？
OSI七层模型是理论上的完美架构。但现实世界不讲完美，讲实用。TCP/IP在设计时就遵循一个原则：能合并的层就合并，能砍掉的层就砍掉。
比如OSI的会话层和表示层，在TCP/IP里直接被应用层吞掉了。物理层和数据链路层合并成网络接口层。剩下的就是四层：
- 应用层 —— 给用户用的，HTTP、FTP、DNS都在这一层
- 传输层 —— 负责端到端通信，TCP和UDP是主角
- 网络层 —— 负责寻址和路由，IP协议是核心
- 网络接口层 —— 负责物理传输，以太网、Wi-Fi都在这里
一句话总结：应用层管内容，传输层管可靠性，网络层管路径，网络接口层管介质。
先看一张总览图
下面这张图把四层模型的核心协议和它们之间的关系画出来了。我建议你把它存下来，后面每学一层就回来对照一下。
应用层：离用户最近的一层
应用层是用户直接打交道的地方。你打开浏览器看网页，用的是HTTP；你发邮件，用的是SMTP；你查域名，用的是DNS。这些协议都跑在应用层。
核心职责就一条：为应用程序提供网络服务接口。它不关心数据怎么传、走哪条路，它只关心「我要发什么内容」。
常见协议一览
| 协议 | 全称 | 默认端口 | 典型用途 |
|---|---|---|---|
| HTTP | 超文本传输协议 | 80 | 网页浏览 |
| HTTPS | 安全超文本传输协议 | 443 | 加密网页浏览 |
| FTP | 文件传输协议 | 20/21 | 文件上传下载 |
| SMTP | 简单邮件传输协议 | 25 | 发送邮件 |
| DNS | 域名系统 | 53 | 域名解析 |
| DHCP | 动态主机配置协议 | 67/68 | 自动分配IP地址 |
我的经验：排查应用层问题，第一件事就是看端口通不通。telnet 目标IP 端口 这个命令，我一天能用十几次。端口不通，别急着往下面几层查，先确认服务有没有启动。
传输层：端到端的可靠担当
传输层是TCP/IP模型里最核心的一层。为什么？因为它解决了网络通信中最关键的问题：可靠性。
网络层只管把数据包送到目的地，但不保证顺序、不保证不丢包。传输层就是干这个的。它有两个主力协议：TCP和UDP。
TCP vs UDP：一个稳，一个快
| 特性 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接（三次握手） | 无连接 |
| 可靠性 | 可靠，有确认重传 | 不可靠，尽力而为 |
| 顺序性 | 保证数据顺序 | 不保证顺序 |
| 流量控制 | 有（滑动窗口） | 无 |
| 拥塞控制 | 有 | 无 |
| 典型应用 | HTTP、FTP、SMTP | DNS、视频流、VoIP |
你想想看，下载文件的时候如果丢了一个包，整个文件就坏了。这时候必须用TCP，它会把丢掉的包重传回来。但如果是视频通话，丢一两个包无所谓，画面稍微花一下而已，可要是等TCP重传，那延迟就受不了了。所以视频通话用UDP。
避坑指南：我曾经遇到过一个线上事故，视频会议系统频繁卡顿。排查了半天，发现是运维把UDP端口给封了，视频流被迫走TCP重传，延迟飙升到3秒以上。记住：实时通信类应用，UDP端口一定要放行。
TCP的三次握手
TCP建立连接的过程，我习惯用「打电话」来类比：
- 第一次握手（SYN）：客户端说「喂，能听到吗？」
- 第二次握手（SYN+ACK）：服务端说「能听到，你那边能听到我吗？」
- 第三次握手（ACK）：客户端说「能听到，咱们开始聊吧」
三次握手之后，连接才算建立成功。少一次都不行。为什么？因为TCP要确保双方的收发能力都正常。
网络层：数据包的导航系统
网络层的核心是IP协议。它的工作就是给每个数据包贴上源地址和目的地址，然后决定走哪条路。
你可以把网络层想象成快递分拣中心。快递员（网络接口层）把包裹送到分拣中心，分拣员（网络层）看地址，决定发往哪个城市的分拣中心，再交给下一个快递员。
IP协议的两个版本
| 特性 | IPv4 | IPv6 |
|---|---|---|
| 地址长度 | 32位 | 128位 |
| 地址数量 | 约43亿 | 2^128个 |
| 表示方式 | 点分十进制（192.168.1.1） | 冒号十六进制（2001:db8::1） |
| 安全性 | 需额外配置IPsec | 原生支持IPsec |
| 现状 | 仍占主流，但地址枯竭 | 逐步推广中 |
IPv4地址早就分完了。我记得2019年的时候，亚太地区的IPv4地址池就已经彻底枯竭。现在新上线的业务，我建议直接上IPv6，别再用NAT（网络地址转换）去凑合了。NAT虽然能缓解地址不足，但它破坏了端到端的通信模型，很多P2P应用在NAT后面跑不起来。
路由选择：数据包怎么找到路？
网络层还有一个重要工作：路由选择。路由器通过路由表来决定数据包的下一跳。常见的路由协议有：
- RIP（路由信息协议）：基于跳数，简单但效率低
- OSPF（开放最短路径优先）：基于链路状态，收敛快
- BGP（边界网关协议）：互联网的核心路由协议
一句话理解：网络层不关心数据内容，只关心「这个包要去哪里，下一跳给谁」。
网络接口层：最底层的搬运工
网络接口层是四层模型里最底层的一层。它负责把数据转换成电信号、光信号或者无线电波，在物理介质上传输。
这一层在TCP/IP模型里把OSI的物理层和数据链路层合并了。为什么合并？因为在实际开发中，这两层的边界没那么清晰。你写网络程序的时候，基本不会直接操作网卡的物理信号，都是通过驱动和硬件打交道。
核心协议：以太网
以太网是网络接口层最常用的协议。它用MAC地址来标识设备。每个网卡出厂时都有一个全球唯一的MAC地址，就像身份证号一样。
以太网帧的结构大概是这样的：
| 前导码 | 目标MAC | 源MAC | 类型/长度 | 数据 | FCS |
| 8字节 | 6字节 | 6字节 | 2字节 | 46-1500字节 | 4字节 |这里有个关键概念：MTU（最大传输单元）。以太网的MTU默认是1500字节。如果上层传下来的数据包超过1500字节，网络层就要做分片。分片多了，性能会下降。所以我在做网络优化时，会刻意控制应用层的数据包大小，避免触发IP分片。
我的习惯：排查网络性能问题时，我第一件事就是ping一下，看延迟和丢包率。然后看MTU设置。很多莫名其妙的「网速慢」问题，最后发现是MTU不匹配导致的。
数据封装：数据在四层模型中的旅行
理解了每一层的职责，我们再来看数据是怎么从一台机器传到另一台机器的。这个过程叫数据封装。
假设你在浏览器里输入了一个网址，按下回车。数据是这样走的：
- 应用层：浏览器生成HTTP请求报文
- 传输层：TCP给HTTP报文加上TCP头部（源端口、目标端口、序列号等），形成TCP段
- 网络层：IP给TCP段加上IP头部（源IP、目标IP），形成IP数据包
- 网络接口层：以太网给IP数据包加上帧头部（源MAC、目标MAC），形成以太网帧，然后通过网线发出去
接收端收到数据后，反向操作：从帧里取出IP包，从IP包里取出TCP段，从TCP段里取出HTTP报文，交给浏览器。
核心要点：每一层只处理自己那一层的头部信息。传输层不看IP地址，网络层不看端口号。各司其职，这就是分层设计的美妙之处。
实际排障思路：从哪一层开始查？
工作中遇到网络问题，我一般按这个顺序排查：
- 先看网络接口层：网线插好了吗？Wi-Fi连上了吗？网卡灯亮吗？
- 再看网络层：ping一下网关通不通？IP地址配置对吗？
- 然后看传输层：端口通不通？telnet试一下。
- 最后看应用层：服务启动了吗？配置文件对吗？
这个顺序是从底层到上层。底层出问题，上层肯定跑不通。反过来，上层出问题，底层可能一切正常。我曾经遇到一个案例：ping网关通，ping外网也通，但就是打不开网页。最后发现是DNS配置错了。这就是典型的应用层问题，底层网络完全正常。
避坑指南：不要一上来就抓包分析。先确认最基础的东西：网线、IP、网关、DNS。我见过太多新手花半天时间分析Wireshark抓包，最后发现是网线松了。
小结
TCP/IP四层模型是网络通信的骨架。每一层都有自己的职责和协议，层与层之间通过标准接口交互。理解了这个模型，你就掌握了网络通信的全局视角。
后面我们会逐层深入，从应用层的HTTP协议开始，一步步把每一层的细节都吃透。今天先把框架搭好，后面学起来就轻松多了。