Linux学习之旅之TCP/IP模型基础认知
一、TCP/IP 模型网络模型
1、什么是TCP/IP 模型网络模型
TCP/IP 模型是互联网实际运行的分层架构，以 TCP、IP 两个核心协议命名，由美国国防部研发，是现实中所有网络设备（电脑、手机、路由器）遵循的标准；而 OSI 七层只是理论参考标准。
整体分为4 层，自上而下：应用层 → 传输层 → 互联网层 → 网络接口层。
2、四层职责
| TCP/IP 层级 | 核心作用 | 典型协议 |
|---|---|---|
| 应用层 | 为应用软件提供网络服务接口，整合数据格式转换、加密解密、会话管理功能 | HTTP、HTTPS、FTP、DNS、DHCP、SSH、Telnet、SMTP、POP3、IMAP |
| 传输层 | 实现端到端的数据传输，通过端口区分本机不同应用；提供可靠 / 高速两种传输方式 | TCP、UDP |
| 互联网层（网际/网络层） | 基于 IP 地址跨网段路由寻址、数据包转发，网络差错反馈、地址解析 | IPv4、IPv6、ICMP、ARP、IGMP、RIP、OSPF |
| 网络接口/链路层 | 处理二进制比特流、帧封装，MAC 寻址，对接物理传输介质与局域网设备 | Ethernet、PPP、HDLC、STP、VLAN；网线、光纤、Wi-Fi、RJ45 |
1. 应用层（顶层） 对应 OSI：5 会话层 +6表示层 +7应用层 作用：直接为软件程序提供网络通信接口，处理用户业务数据、数据加密、会话管理、编码转换。 常见协议： HTTP/HTTPS、FTP、TFTP、DNS、DHCP、SSH、Telnet、SMTP、POP3、IMAP、RPC2. 传输层 对应 OSI：4 传输层 作用：端到端传输，通过端口号区分同一台设备上不同程序；分可靠传输与高速无连接传输。 两大核心协议： TCP：面向连接、可靠传输（三次握手 / 四次挥手、重传、流量控制），网页、文件传输用； UDP：无连接、低延迟、不可靠，直播、游戏、DNS 查询用。3. 互联网层（IP 层，核心层） 对应 OSI：3 网络层 作用：跨网段路由寻址，基于 IP 地址完成数据包转发、差错通知、组播管理。 常见协议： IPv4/IPv6、ICMP（ping 命令）、ARP（IP 转 MAC）、IGMP（组播）、OSPF、RIP（路由协议）4. 网络接口层（底层） 对应 OSI：1 物理层 +2数据链路层 作用：负责二进制比特流传输、帧封装、局域网 MAC 寻址，对接网线、光纤、无线硬件。 协议 / 介质： Ethernet 以太网、PPP、HDLC、STP、VLAN；网线、光纤、WiFi、RJ45、交换机、集线器3、TCP/IP四层模型 vs OSI七层模型
豆包生成仅供参考
4、数据封装过程
豆包生成仅供参考
封装
应用层 用户产生原始业务数据（如网页文字、文件内容），交给下层传输。 传输层 给数据添加 TCP/UDP 头部（包含源端口、目标端口），整体称为段 / 数据报。 TCP：头部有序列号、确认号、流量控制等可靠传输字段； UDP：头部极简，仅端口信息。 互联网层（IP 层） 在传输层段前方添加 IP 头部（源 IP、目标 IP、TTL 等），整体称为数据包，实现跨网段寻址。 网络接口层 在 IP 包前后添加 MAC 头部 + MAC 尾部 FCS 校验，封装成帧；最终转为0/1 比特流，通过网线、WiFi 等物理介质发出。 封装顺序：原始数据 → TCP/UDP 头 + 数据 → IP 头 + 段 → MAC 头 + IP 包 + FCS → 比特流解封装
网络接口层 接收比特流，组装成帧，校验 FCS；剥离 MAC 头部与尾部，取出内部 IP 数据包，上交上层。 互联网层 剥离 IP 头部，读取目标 IP 确认本机接收，去掉 IP 头部，将内部 TCP/UDP 段上交传输层。 传输层 剥离 TCP/UDP 头部，根据端口号识别对应的应用程序，去除传输头部，还原原始业务数据。 应用层 把纯净原始数据交付对应软件（浏览器、QQ、FTP 客户端等）展示使用。 解封装顺序：比特流 → 帧（剥离 MAC 头尾）→ IP 数据包（剥离 IP 头）→ 段（剥离 TCP/UDP 头）→ 原始应用数据二、传输层TCP和UDP
1、TCP和UDP对比
| 对比项 | TCP（传输控制协议） | UDP（用户数据报协议） |
|---|---|---|
| 连接特性 | 面向连接，通信前建立连接（三次握手），结束断开（四次挥手） | 无连接，发送前无需建立连接，直接发包 |
| 可靠性 | 可靠传输：丢包重传、有序、流量控制、拥塞控制、差错校验 | 不可靠传输：无重传、无排序、无拥塞控制，丢包不补发 |
| 开销 | 头部 20~60 字节，控制字段多，传输开销大 | 头部固定 8 字节，极简，额外开销极小 |
| 传输方式 | 数据流，数据分段有序到达 | 独立数据报，数据包相互独立，可能乱序丢失 |
| 控制机制 | 序列号、ACK 确认、滑动窗口、重传机制 | 仅校验和，无任何流量 / 拥塞控制 |
2、为什么 UDP 不可靠，但仍大量使用？
#延迟极低TCP 握手、确认、重传机制会产生大量等待时延；UDP 无需确认，发包即走，实时性拉满。直播、语音通话无法容忍 TCP 等待重传造成卡顿。#头部开销极小UDP 仅8字节头部，带宽占用少，适合低带宽、海量并发场景。#无连接，并发承载能力强TCP 每个连接占用系统资源，百万级连接会耗尽内存；UDP 无连接，服务器可同时响应上万客户端，游戏、DNS 查询高频短报文场景优势巨大。#允许丢包，少量丢失不影响体验音视频、游戏画面少量丢包只会轻微花屏 / 卡顿，远好于 TCP 等待重传带来的长时间延迟。#支持广播、组播TCP 只支持一对一单播；UDP 可一对多广播 / 组播，用于局域网设备发现、视频组播。3、场景选择
| 协议 | 核心需求 | 适用业务场景 | 不适合场景 |
|---|---|---|---|
| TCP | 数据必须完整、无丢失、无乱序，可接受较高延迟 | 1. 网页访问 HTTP/HTTPS 2. 文件上传下载 FTP/SFTP 3. 远程管理 SSH、Telnet、RDP 4. 邮件 SMTP、POP3、IMAP 5. 数据库 MySQL、Oracle 6. 支付、表单提交等重要数据传输 | 实时语音、直播、网络游戏等对延迟敏感场景 |
| UDP | 优先低延迟，可容忍少量丢包，追求高效并发 | 1. DNS 域名解析 2. DHCP 自动分配 IP 3. 视频直播、语音通话、视频会议 4. 网络游戏实时数据同步 5. NTP 网络时间同步 6. 监控组播、局域网设备发现 | 文件传输、财务交易等不允许数据丢失的业务 |
4、常见端口和协议
TCP
| 端口 | 协议 | 用途 |
|---|---|---|
| 21 | FTP | 文件传输控制端口 |
| 22 | SSH | 安全远程登录 |
| 80 | HTTP | 网页访问 |
| 443 | HTTPS | 加密网页 |
| 3306 | MySQL | 数据库连接 |
| 25 | SMTP | 发送邮件 |
| 110 | POP3 | 接收邮件 |
| 3389 | RDP | 远程桌面 |
UDP
| 端口 | 协议 | 用途 |
|---|---|---|
| 53 | DNS | 域名解析查询 |
| 67/68 | DHCP | 自动分配 IP 地址 |
| 123 | NTP | 网络时间同步 |
| 69 | TFTP | 简单文件传输（内网启动） |
| 161 | SNMP | 网络设备监控 |
5、套接字（socket）
套接字（Socket）是网络通信端点，是应用层与传输层之间的接口，操作系统提供的一套网络编程 API。 一台主机上区分不同进程通信的唯一标识=IP 地址 + 传输层协议(TCP/UDP)+ 端口号。 客户端 Socket：主动发起连接 服务端 Socket：监听端口，等待客户端连接 例如： 本机浏览器访问百度： 客户端套接字：192.168.1.100:52000（本机 IP + 随机临时端口） 服务端套接字：180.101.49.11:80（百度服务器 IP+80 网页端口） 二者成对建立 Socket 通信通道传输网页数据。三、TCP三次握手与四次挥手
1、什么是三次握手和四次挥手
TCP 是面向连接协议，通信前通过三次握手确认双方发送、接收能力正常，协商初始序列号，建立可靠通道。
2、三次握手流程
#流程（客户端 C ↔ 服务端 S）#第一次握手（C→S）客户端发送 SYN 报文，携带客户端初始序列号随机数ISN（c），请求建立连接；客户端进入 SYN_SENT。#第二次握手（S→C）服务器收到 SYN，回复 SYN+ACK： SYN：服务器也要发起连接，携带服务器 ISN(s)ACK：确认客户端报文，确认号=ISN(c)+1 服务器进入 SYN_RCVD。#第三次握手（C→S）客户端回复 ACK，确认号=ISN(s)+1； 双方同步完成，进入 ESTABLISHED（连接已建立），开始传输业务数据。| 阶段 | 报文 | 客户端状态 | 服务端状态 | 说明 |
|---|---|---|---|---|
| 握手 1 | 客户端 → 服务端：SYN | SYN_SENT | LISTEN | 服务端一直处于监听端口状态；客户端发同步请求 |
| 握手 2 | 服务端 → 客户端：SYN+ACK | SYN_SENT | SYN_RCVD | 服务器收到 SYN，同步自身序列号并确认客户端 |
| 握手 3 | 客户端 → 服务端：ACK | ESTABLISHED | ESTABLISHED | 双方连接建立完成，可传输业务数据 |
3、四次挥手流程
#流程（C 客户端、S 服务端）#第一次挥手（C→S FIN）客户端数据发送完毕，发 FIN 报文，客户端进入 FIN_WAIT1，不再发数据。#第二次挥手（S→C ACK）服务器收到 FIN，回复 ACK 确认；此时服务器仍可向客户端发送剩余数据，客户端进入 FIN_WAIT2。#第三次挥手（S→C FIN）服务器数据全部发送完成，发送 FIN 报文，服务器进入 LAST_ACK。#第四次挥手（C→S ACK）客户端回复 ACK 确认，客户端等待 2MSL 后彻底关闭；服务器收到 ACK 直接释放连接。#2MSL 等待作用确保服务器收到最后一次 ACK；若 ACK 丢失，服务器会重发 FIN，客户端可重新回复 ACK| 阶段 | 报文 | 客户端状态 | 服务端状态 | 说明 |
|---|---|---|---|---|
| 挥手 1 | 客户端→服务端：FIN | FIN_WAIT_1 | ESTABLISHED | 客户端数据发完，请求关闭发送通道 |
| 挥手 2 | 服务端→客户端：ACK | FIN_WAIT_2 | CLOSE_WAIT | 服务器确认关闭请求，仍可向客户端发剩余数据 |
| 挥手 3 | 服务端→客户端：FIN | FIN_WAIT_2 | LAST_ACK | 服务器数据全部发送完毕，发送关闭报文 |
| 挥手 4 | 客户端→服务端：ACK | TIME_WAIT（等待2MSL） | CLOSED | 服务器收到 ACK 立即释放；客户端等待 2MSL 再关闭 |
关注重点： 大量 TIME_WAIT：正常，高并发服务的特征 大量 CLOSE_WAIT：程序bug，应用没有正确调用 close()关闭 socke 大量 SYN_RCVD ：需要查询安全类型，防止有人攻击@马哥教育