掌握Linux网络通信需理解TCP/IP五层模型：物理层传比特流，数据链路层用MAC寻址，网络层靠IP路由，传输层以端口区分应用，应用层实现HTTP等协议；再通过tcpdump抓包观察封装解封装，用ip、ss、dig等命令映射各层状态，并按层排查故障。
如果您希望系统性理解Linux环境下的网络通信机制，却对TCP/IP模型各层职责与数据流转过程感到模糊，则很可能是由于缺乏对分层结构与封装/解封装行为的直观认知。以下是掌握该知识体系的核心路径：
一、厘清TCP/IP五层模型对应关系与功能边界
TCP/IP模型在Linux实践中通常采用五层划分（物理层、数据链路层、网络层、传输层、应用层），每一层承担明确职责，并通过协议头封装实现数据向下交付。理解各层的输入输出形态及典型协议，是分析网络行为的基础。
1、物理层负责原始比特流传输，不涉及IP或端口概念，仅处理电信号、光信号或无线信号的收发，网卡驱动和PHY芯片在此层工作。
2、数据链路层以帧（frame）为单位组织数据，使用MAC地址完成局域网内寻址，ARP协议和以太网头部添加发生在此层。
3、网络层引入IP地址进行跨网段路由，核心任务是将数据包（packet）从源主机送达目的主机，ip addr show 和 ip route show 命令所展示的信息均属于此层配置。
4、传输层通过端口号区分上层应用进程，TCP提供可靠有序传输并维护连接状态，UDP则仅做无连接的数据报投递，telnet 192.168.1.100 22 和 nc -zv 192.168.1.100 80 均作用于该层。
5、应用层直接面向用户服务，HTTP、DNS、SSH等协议定义数据语义与交互流程，curl、wget、dig 等命令调用的正是该层接口。
二、动手验证数据封装与解封装全过程
封装是自上而下逐层添加协议头的过程，解封装则是接收端自下而上逐层剥离头部并校验的过程。通过抓包工具可清晰观察该行为，从而建立对协议栈运作的具象认知。
1、安装tcpdump工具：执行 sudo apt install tcpdump（Debian/Ubuntu）或 sudo yum install tcpdump（CentOS/RHEL）。
2、启动监听：运行 sudo tcpdump -i eth0 -n -c 5 port 80，捕获5个目标端口为80的数据包。
3、另起终端发起请求：执行 curl -s http://httpbin.org/get > /dev/null，触发一次HTTP GET通信。
4、观察输出结果：每行显示一个数据包的时间戳、源/目的IP与端口、协议类型及长度；其中IP头部（含TTL、协议号）、TCP头部（含SYN/ACK标志、序列号）和HTTP应用层内容可被逐层识别。
5、对比不同协议：分别用 ping 8.8.8.8 和 telnet 8.8.8.8 53 抓包，确认ICMP与TCP/UDP在IP协议字段（Protocol字段值分别为1和6/17）及载荷结构上的差异。
三、使用系统命令映射协议栈各层状态
Linux内核将协议栈各层的关键运行时信息暴露为可读接口，通过标准命令可即时获取当前网络层、传输层与链路层的配置与活动状态，避免依赖抽象描述。
1、查看链路层设备与MAC地址：运行 ip link show，输出中“link/ether”后即为该接口的MAC地址。
2、查看网络层IP配置与状态：执行 ip addr show，识别每个接口的IPv4/IPv6地址、子网掩码及UP/DOWN状态。
3、查看网络层路由决策逻辑：运行 ip route show，确认默认网关、直连网络及静态路由条目，所有出向数据包均依据此表选择下一跳。
4、查看传输层连接与监听状态：执行 ss -tuln，列出所有TCP/UDP监听端口及已建立连接，其中“State”列显示ESTAB、LISTEN等TCP状态机阶段。
5、查看应用层域名解析行为：运行 dig www.example.com A +trace，跟踪从根服务器到权威服务器的完整DNS查询路径，理解应用层如何协同网络层完成名字到地址的转换。
四、模拟跨主机通信并定位中断环节
真实网络故障常发生在某一层失效，掌握分层排查法可快速缩小问题范围。以客户端无法访问Web服务为例，按模型自底向上验证各层可达性，避免盲目重启服务。
1、验证物理与数据链路层连通性：在客户端执行 ping -c 3 192.168.1.1（假设网关为该地址），若失败则检查网线、交换机端口、接口UP状态及ARP缓存（ip neigh show）。
2、验证网络层路由能力：执行 ping -c 3 192.168.2.100（目标服务器IP），若超时但网关可达，需检查客户端路由表是否含通往目标网段的条目，或目标主机是否关闭ICMP响应（sysctl net.ipv4.icmp_echo_ignore_all）。
3、验证传输层端口开放性：运行 telnet 192.168.2.100 80 或 nc -zv 192.168.2.100 80，若连接拒绝（Connection refused），说明目标未监听该端口；若超时（Timeout），则中间存在防火墙拦截或路由黑洞。
4、验证应用层服务响应：使用 curl -v http://192.168.2.100/ 查看HTTP状态码与响应头，若返回404或502，表明传输层已通但应用未正确处理请求。
5、交叉验证双向路径：在服务器端同步执行 tcpdump -i any port 80，确认请求是否真正抵达本地协议栈，排除NAT、策略路由或反向路径过滤（rp_filter）导致的单向通信问题。
