1. 课程导入与网络工程视角
当你用浏览器打开一个网页、用SSH登录一台交换机、或者用ping测试一条链路时，背后真正工作的并不是某一条命令，而是一整套协同配合的协议集合——TCP/IP协议栈。网络工程中的绝大多数排障、抓包、配置与容量规划，最终都会落到“哪一层、哪个协议、哪个字段出了问题”这个判断上。因此，本课程的第一件事不是背协议格式，而是建立一种分层定位的工程视角：把复杂的端到端通信拆成可观察、可验证的若干层，再逐层缩小问题范围。
一、TCP/IP的起源：从ARPANET到工程事实标准
TCP/IP并非先有完整理论再落地，而是伴随ARPANET的互联需求逐步演化。20世纪70年代，不同厂商的网络彼此孤立，研究者需要一种能在异构网络之间转发数据的机制。1974年Cerf与Kahn提出网络互联的核心思想：由主机负责端到端的可靠传输，由网关（后来的路由器）负责逐跳转发。1981年IPv4被标准化（RFC 791），1983年ARPANET正式切换到TCP/IP，这一天常被视为现代互联网的起点。
与OSI先制定七层参考模型、再推动实现不同，TCP/IP是“先有实现、再总结模型”。这带来两个工程后果：其一，TCP/IP的层次划分更贴近真实实现，应用层直接包含会话与表示功能；其二，它的标准以RFC文档形式滚动更新，工程实践中更看重“能否互通”，而非“是否符合某个理论模型”。理解这一点，就不会在排障时纠结“这个功能到底属于会话层还是表示层”，而会直接问：数据包在哪一层被丢弃或改写。
二、四层模型与OSI七层模型的对应关系
TCP/IP通常划分为四层：网络接口层、网际层、传输层、应用层。它与OSI七层的对应并非一一映射，而是存在合并与跨越。下面的SVG以“封装/解封装”为主线，展示数据从应用进程到链路的逐层封装过程，以及两层模型的对应位置。
需要特别说明的是，OSI的“会话层”和“表示层”在TCP/IP中被并入应用层，由具体应用协议自行处理（如TLS负责加密与身份认证，可视为表示层功能的实现）。因此，当有人问“TLS属于哪一层”时，工程上更实用的回答是：它位于应用层与传输层之间，为应用提供安全会话，但在TCP/IP四层模型中通常归入应用层范畴。
三、网络工程中协议栈分析的基本方法
协议栈分析的核心不是“逐层背诵”，而是自下而上验证连通性，自上而下定位故障域。实际工作中，一条“网页打不开”的报障，可能涉及物理链路、IP路由、TCP握手、DNS解析或应用服务多个环节。若没有分层方法，很容易在错误的方向上反复尝试。
一个可复用的分析顺序如下：
- 链路与接口层：确认本机网卡状态、IP地址、子网掩码、网关是否配置正确。命令如
ipconfig /all（Windows）或ip addr（Linux）。若接口显示DOWN或没有IP，问题在此层。 - 网际层可达性：用
ping 网关IP验证本地到网关的IP连通性。若不通，检查ARP表（arp -a）、VLAN划分、交换机端口状态。若通，再ping 8.8.8.8验证外网IP可达性。 - 传输层与端口：用
telnet 目标IP 443或nc -zv 目标IP 443测试TCP端口是否开放。若IP能ping通但端口不通，可能是防火墙ACL、服务未监听或路由不对称。 - 应用层：用
nslookup 域名验证DNS解析，用curl -v https://域名观察HTTP状态码与TLS握手过程。若DNS失败，检查DNS服务器配置与递归解析链路。
ip.addr == 192.168.1.100 && tcp.port == 443，这样可以在每一层验证“数据包是否发出、是否收到回应、回应内容是否符合预期”。以一个教学示例说明：假设某主机IP为192.168.1.100/24，网关为192.168.1.1，访问 https://example.com 失败。按上述顺序，先 ping 192.168.1.1 通，说明链路与网际层本地部分正常；再 ping 8.8.8.8 不通，说明问题出在网关之外的路由或NAT；此时检查网关设备的路由表与NAT会话表，往往能发现默认路由缺失或地址池耗尽。若 ping 8.8.8.8 通但 nslookup example.com 失败，则问题定位在DNS，而非网络层。这个示例中的IP与结果均为教学假设，实际排障需以现场抓包和日志为准。
四、建立“协议栈思维”的三个要点
第一，每层只解决特定问题。网络接口层解决“同一链路内如何找到下一跳”，网际层解决“跨网络如何寻址与转发”，传输层解决“端到端可靠或高效传输”，应用层解决“业务语义”。排障时先判断问题属于哪一类，再选择对应工具。
第二，封装与解封装是对称的。发送方逐层加头，接收方逐层去头。抓包看到的帧包含所有下层头部，因此分析时必须从外到内剥离，不能直接跳到应用数据。例如，一个TCP重传问题，可能源于链路丢帧、IP分片丢失或接收窗口为零，需要结合IP层与TCP层字段共同判断。
第三，协议栈是工程折中的产物。TCP提供可靠传输但带来延迟与开销，UDP轻量但不保证顺序与到达。选择TCP还是UDP，取决于业务对可靠性、实时性和开销的权衡。理解这一点，才能在架构设计中做出合理决策，而不是机械地“用TCP就一定好”。