Linux 网络编程学习总结

1. 引言

网络编程是 Linux 后端开发的核心技能之一。无论是编写高性能服务器、理解分布式系统通信，还是排查线上网络问题，都离不开对网络体系结构、传输层协议和应用层协议的深入理解。本文系统梳理 Linux 网络编程的关键知识点，从 OSI 与 TCP/IP 模型出发，逐步深入到 TCP/UDP 编程流程、TCP 核心机制（三次握手、四次挥手、TIME_WAIT）以及 HTTP 协议基础，最后附上常见面试题，帮助初学者建立完整的知识框架。

2. 网络体系结构

2.1 OSI 七层模型

OSI（Open Systems Interconnection）参考模型由国际标准化组织（ISO）提出，将计算机网络通信划分为七个层次，自下而上依次为：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。每一层负责特定的功能，并为上层提供服务。

层次	功能	典型协议/设备	数据单元
物理层	透明传输比特流，定义电气、机械、接口特性	网线、集线器、中继器	比特（bit）
数据链路层	将比特组装成帧，提供差错检测与流量控制，实现相邻节点可靠传输	以太网、PPP、交换机	帧（frame）
网络层	逻辑寻址与路由选择，实现跨网络的数据传输	IP、ICMP、IGMP、路由器	数据包（packet）
传输层	端到端通信，提供可靠或不可靠传输、分段与重组、流量控制	TCP、UDP	报文段（segment）
会话层	建立、管理和终止会话，提供会话同步与检查点	NetBIOS、RPC	数据
表示层	数据格式转换、加密解密、压缩解压，保证语义一致	SSL/TLS、JPEG、ASCII	数据
应用层	为应用程序提供网络服务接口	HTTP、FTP、SMTP、DNS	报文（message）

数据封装过程：发送方从应用层开始，逐层向下传递，每经过一层就添加对应的头部信息（部分层还添加尾部），最终形成完整的比特流发送到物理介质；接收方则从物理层开始，逐层向上解封装，剥离各层头部，最终还原出应用层数据。

2.2 TCP/IP 四层模型

TCP/IP 模型是实际互联网所采用的协议体系，分为四层：网络接口层、网络层、传输层、应用层。相比 OSI 七层模型，TCP/IP 模型更加简洁实用，将 OSI 的物理层和数据链路层合并为网络接口层，将会话层和表示层合并到应用层中。

TCP/IP 层次	对应 OSI 层次	核心协议	实际应用场景
应用层	应用层、表示层、会话层	HTTP、FTP、SMTP、DNS、SSH	Web 浏览、文件传输、邮件收发、域名解析
传输层	传输层	TCP、UDP	可靠数据传输、实时音视频通信
网络层	网络层	IP、ICMP、IGMP	路由寻址、网络互联、差错报告
网络接口层	数据链路层、物理层	以太网、ARP、PPP	物理介质上的帧传输与地址解析

TCP/IP 模型的设计理念是「分层协作、各司其职」：网络接口层负责物理传输，网络层负责寻址与路由，传输层负责端到端通信质量，应用层面向具体业务。实际开发中，程序员主要与传输层和应用层打交道，通过 Socket 接口进行编程。

3. 传输层协议编程

3.1 TCP 编程流程

TCP 是面向连接的、可靠的字节流协议。基于 Linux 的 TCP 编程遵循「服务器被动监听、客户端主动连接」的模式。

TCP 服务器标准流程：

创建套接字 ：调用 socket() 创建监听套接字，指定地址族（AF_INET）、套接字类型（SOCK_STREAM）和协议（0 表示自动选择 TCP）。
绑定地址端口 ：调用 bind() 将套接字与本地 IP 地址和端口号绑定，使服务器在指定地址上监听。
监听连接 ：调用 listen() 将套接字转为被动监听状态，并设置连接队列大小（backlog）。
接受连接 ：调用 accept() 从连接队列中取出一个已完成三次握手的连接，返回一个新的已连接套接字用于数据通信。
数据收发 ：使用 read()/write() 或 recv()/send() 进行数据读写。
关闭连接 ：通信结束后调用 close() 关闭套接字，释放资源。

TCP 客户端标准流程：

创建套接字 ：调用 socket() 创建客户端套接字。
连接服务器 ：调用 connect() 向服务器发起连接请求，触发三次握手过程。
数据收发 ：使用 send()/recv() 与服务器交换数据。
关闭连接 ：调用 close() 关闭套接字。

关键系统调用参数说明：socket(int domain, int type, int protocol) 中 domain 常用 AF_INET（IPv4）或 AF_INET6（IPv6），type 常用 SOCK_STREAM（TCP）或 SOCK_DGRAM（UDP）；bind() 需要传入 struct sockaddr_in 结构体，包含地址族、端口号（需转换为网络字节序）和 IP 地址；listen() 的 backlog 参数表示内核维护的连接队列最大长度。

3.2 UDP 编程流程

UDP 是无连接的、不可靠的数据报协议。UDP 编程不需要建立连接，也没有监听和接受连接的过程。

UDP 服务器标准流程：

创建套接字 ：调用 socket(AF_INET, SOCK_DGRAM, 0) 创建 UDP 套接字。
绑定地址端口 ：调用 bind() 绑定本地地址和端口。
数据收发 ：调用 recvfrom() 接收数据报（同时获取发送方地址），调用 sendto() 发送数据报（需指定目标地址）。
关闭连接 ：调用 close() 关闭套接字。

UDP 客户端标准流程：

创建套接字 ：调用 socket(AF_INET, SOCK_DGRAM, 0) 创建 UDP 套接字。
数据收发 ：调用 sendto() 发送数据，调用 recvfrom() 接收数据。
关闭连接 ：调用 close() 关闭套接字。

TCP 与 UDP 编程差异点：

TCP 需要 listen() 和 accept()，UDP 不需要，因为 UDP 无连接。
TCP 使用 send()/recv() 或 read()/write()，UDP 使用 sendto()/recvfrom()，后两者必须携带对端地址。
TCP 是字节流，无消息边界；UDP 是数据报，每次收发对应一个完整报文，有明确边界。
TCP 服务器通常为每个客户端连接创建独立线程/进程处理；UDP 服务器通常单线程循环处理所有客户端请求。

3.3 TCP 与 UDP 协议特性对比

对比维度	TCP	UDP
连接性	面向连接，需三次握手建立连接	无连接，直接发送数据报
可靠性	可靠传输，确认重传、序号机制保证数据不丢失、不重复、有序到达	不可靠，不保证送达、不保证顺序
流量控制	滑动窗口机制，根据接收方能力动态调整发送速率	无流量控制
拥塞控制	慢启动、拥塞避免、快重传、快恢复	无拥塞控制
数据传输方式	字节流，无消息边界，需应用层处理粘包/拆包	数据报，保留消息边界
传输效率	较低，头部开销大（20 字节），需确认和重传	较高，头部开销小（8 字节），无确认机制
适用场景	文件传输、Web 浏览、邮件、数据库连接等对可靠性要求高的场景	实时音视频、DNS 查询、游戏、广播等对实时性要求高、可容忍丢包的场景

4. TCP 协议核心机制

4.1 三次握手

TCP 建立连接需要经过三次握手，目的是同步双方的初始序列号并确认双方收发能力正常。

三次握手过程：

第一次握手：客户端发送 SYN 报文（SYN=1，seq=x），进入 SYN_SENT 状态，请求建立连接。
第二次握手：服务器收到 SYN 后，回复 SYN+ACK 报文（SYN=1，ACK=1，seq=y，ack=x+1），进入 SYN_RCVD 状态，表示同意建立连接并确认客户端的 SYN。
第三次握手：客户端收到 SYN+ACK 后，发送 ACK 报文（ACK=1，seq=x+1，ack=y+1），进入 ESTABLISHED 状态；服务器收到后也进入 ESTABLISHED 状态，连接建立完成。

三次握手的必要性：第一次和第二次握手确认了服务器的接收和发送能力，第二次和第三次握手确认了客户端的接收和发送能力。如果只进行两次握手，服务器无法确认客户端是否收到了自己的 SYN+ACK 报文，可能导致已失效的连接请求突然到达服务器，造成资源浪费和连接混乱。三次握手还能同步双方的初始序列号，为后续可靠传输奠定基础。

4.2 四次挥手

TCP 关闭连接需要经过四次挥手，因为 TCP 连接是全双工的，双方需要分别关闭各自的发送方向。

四次挥手过程：

第一次挥手：主动关闭方发送 FIN 报文（FIN=1，seq=u），进入 FIN_WAIT_1 状态，表示不再发送数据。
第二次挥手：被动关闭方收到 FIN 后，回复 ACK 报文（ack=u+1），进入 CLOSE_WAIT 状态；主动关闭方收到 ACK 后进入 FIN_WAIT_2 状态。此时被动关闭方仍可继续发送数据。
第三次挥手：被动关闭方数据发送完毕后，发送 FIN 报文（FIN=1，seq=w），进入 LAST_ACK 状态。
第四次挥手：主动关闭方收到 FIN 后，回复 ACK 报文（ack=w+1），进入 TIME_WAIT 状态；被动关闭方收到 ACK 后进入 CLOSED 状态。主动关闭方经过 2MSL 后进入 CLOSED 状态。

四次挥手不能合并为三次的原因：被动关闭方收到 FIN 后，可能还有数据需要发送，因此先回复 ACK 确认收到 FIN，等数据发送完毕后再发送 FIN，所以 ACK 和 FIN 分开发送。

4.3 TIME_WAIT 状态

TIME_WAIT 是主动关闭连接的一方在发送最后一个 ACK 报文后进入的状态，持续时间为 2MSL（Maximum Segment Lifetime，报文最大生存时间，通常为 30 秒到 2 分钟）。

TIME_WAIT 存在的意义：

确保最后一个 ACK 被对方接收：如果最后一个 ACK 丢失，被动关闭方会重发 FIN，主动关闭方需要处于 TIME_WAIT 状态才能重新发送 ACK。若主动关闭方直接进入 CLOSED，将无法响应重发的 FIN，导致对方无法正常关闭。
防止延迟的重复报文干扰新连接：网络中可能残留延迟到达的旧报文，如果立即使用相同的四元组建立新连接，旧报文可能被误认为是新连接的数据。TIME_WAIT 等待 2MSL 确保所有旧报文在网络中消失。

TIME_WAIT 带来的问题与解决方案：

在高并发服务器场景下，大量主动关闭的连接会积累大量 TIME_WAIT 状态的套接字，占用端口和内存资源，可能导致端口耗尽。常见解决方案包括：

调整内核参数 net.ipv4.tcp_tw_reuse，允许在安全条件下复用 TIME_WAIT 状态的连接（仅适用于客户端主动连接场景）。
调整 net.ipv4.tcp_fin_timeout 缩短 TIME_WAIT 的等待时间。
在服务器设计中尽量避免服务器主动关闭连接，让客户端主动关闭。
使用长连接复用机制，减少频繁建立和关闭连接。

5. 应用层协议基础

5.1 HTTP 协议

HTTP（HyperText Transfer Protocol，超文本传输协议）是应用层最常用的协议，默认端口为 80（HTTPS 默认端口为 443）。HTTP 基于请求-响应模型：客户端发送请求报文，服务器处理请求后返回响应报文。

URI（Uniform Resource Identifier，统一资源标识符） 用于标识互联网上的资源，由协议名、主机名、端口号、路径和查询参数组成，例如 http://www.example.com:8080/path/page?key=value。

请求报文结构：

请求行：包含请求方法、URI 和 HTTP 版本，如 GET /index.html HTTP/1.1。
请求头：包含 Host、User-Agent、Content-Type、Accept 等键值对，描述客户端信息和请求属性。
空行：分隔请求头和请求体。
请求体：携带请求数据，GET 请求通常为空，POST 请求携带表单或 JSON 数据。

响应报文结构：

状态行：包含 HTTP 版本、状态码和状态描述，如 HTTP/1.1 200 OK。
响应头：包含 Content-Type、Content-Length、Set-Cookie 等键值对，描述响应内容属性和服务器信息。
空行：分隔响应头和响应体。
响应体：携带服务器返回的实际数据，如 HTML 页面、JSON 数据或文件内容。

5.2 HTTP 请求方法

HTTP 定义了多种请求方法，其中最常用的是 GET 和 POST。两者在参数传递方式、安全性、缓存机制等方面存在显著差异。

对比维度	GET	POST
请求参数位置	参数拼接在 URL 查询字符串中，如 `?key=value`	参数放在请求体中，URL 不携带业务参数
数据大小限制	受 URL 长度限制（通常 2KB 到 8KB，取决于浏览器和服务器）	理论上无大小限制，由服务器配置决定
安全性	参数暴露在 URL 中，易被浏览器历史、代理日志记录，安全性较低	参数在请求体中，相对更隐蔽，但仍需 HTTPS 加密保证安全
缓存机制	可被浏览器主动缓存，适合幂等查询	默认不缓存，每次请求都会到达服务器
幂等性	幂等，重复执行结果相同，不会改变服务器状态	非幂等，重复提交可能产生多次副作用（如重复下单）
适用场景	查询、搜索、浏览等只读操作	提交表单、上传数据、创建资源等写操作

选择建议：对于纯查询类操作优先使用 GET，便于缓存和分享链接；对于涉及数据变更、敏感信息传输的操作应使用 POST，避免参数暴露在 URL 中。

5.3 HTTP 状态码

HTTP 状态码由三位数字组成，用于表示服务器对请求的处理结果。第一位数字表示响应类别，常见分类如下：

1xx（信息性状态码）：请求已接收，继续处理，如 100 Continue。
2xx（成功状态码）：请求已成功处理，如 200 OK。
3xx（重定向状态码）：需要进一步操作完成请求，如 301 Moved Permanently、302 Found。
4xx（客户端错误状态码）：请求包含语法错误或无法完成，如 400 Bad Request、401 Unauthorized。
5xx（服务器错误状态码）：服务器处理请求时发生内部错误，如 500 Internal Server Error。

200 OK：请求成功，服务器已返回所请求的资源。这是最常见的成功状态码，表示请求被正常处理。

404 Not Found：服务器找不到请求的资源，通常是因为 URL 路径错误、资源已被删除或未部署。产生原因包括：用户输入了错误的链接、资源被移动未做重定向、后端路由配置缺失。

403 Forbidden：服务器理解请求但拒绝执行，客户端没有访问该资源的权限。产生原因包括：权限配置不足、IP 被限制、未通过身份认证但资源要求更高权限。

500 Internal Server Error：服务器内部发生错误，无法完成请求。产生原因包括：后端代码抛出未捕获异常、数据库连接失败、服务器配置错误、依赖服务不可用。

502 Bad Gateway：服务器作为网关或代理时，从上游服务器收到无效响应。产生原因包括：反向代理后面的应用服务宕机、上游服务超时、负载均衡配置错误、后端进程崩溃未重启。

6. 常见面试题

以下面试题覆盖本文全部核心知识点，题型包括概念解释、原理分析和对比辨析，适合用于自我检测和面试准备。

6.1 概念解释题

1.请简述 OSI 七层模型各层的名称和主要功能，并说明数据在发送和接收过程中的封装与解封装过程。

**答案与解析：**OSI 七层模型自下而上依次为物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。物理层负责透明传输比特流，定义电气、机械和接口特性；数据链路层将比特组装成帧，提供差错检测与流量控制，实现相邻节点可靠传输；网络层负责逻辑寻址与路由选择，实现跨网络数据传输；传输层提供端到端通信，负责分段与重组、流量控制；会话层建立、管理和终止会话，提供同步与检查点；表示层负责数据格式转换、加密解密和压缩解压；应用层为应用程序提供网络服务接口。发送时数据从应用层逐层向下传递，每经过一层就添加对应头部（部分层添加尾部），最终形成比特流发送到物理介质，即封装过程；接收时从物理层逐层向上解封装，剥离各层头部，最终还原出应用层数据。

2.什么是 TCP 的三次握手？请描述每一步的报文类型、标志位和序列号变化。

**答案与解析：**三次握手是 TCP 建立连接的过程。第一次握手：客户端发送 SYN 报文（SYN=1，seq=x），进入 SYN_SENT 状态，请求建立连接。第二次握手：服务器收到 SYN 后，回复 SYN+ACK 报文（SYN=1，ACK=1，seq=y，ack=x+1），进入 SYN_RCVD 状态，表示同意建立连接并确认客户端的 SYN。第三次握手：客户端收到 SYN+ACK 后，发送 ACK 报文（ACK=1，seq=x+1，ack=y+1），进入 ESTABLISHED 状态；服务器收到后也进入 ESTABLISHED 状态，连接建立完成。三次握手的核心目的是同步双方的初始序列号，并确认双方收发能力正常。

3.什么是 TCP 的四次挥手？请说明为什么关闭连接需要四次而不是三次。

**答案与解析：**四次挥手是 TCP 关闭连接的过程。第一次挥手：主动关闭方发送 FIN 报文（FIN=1，seq=u），进入 FIN_WAIT_1 状态，表示不再发送数据。第二次挥手：被动关闭方收到 FIN 后，回复 ACK 报文（ack=u+1），进入 CLOSE_WAIT 状态；主动关闭方收到 ACK 后进入 FIN_WAIT_2 状态。第三次挥手：被动关闭方数据发送完毕后，发送 FIN 报文（FIN=1，seq=w），进入 LAST_ACK 状态。第四次挥手：主动关闭方收到 FIN 后，回复 ACK 报文（ack=w+1），进入 TIME_WAIT 状态；被动关闭方收到 ACK 后进入 CLOSED 状态。因为 TCP 连接是全双工的，双方需要分别关闭各自的发送方向。被动关闭方收到 FIN 后可能还有数据需要发送，因此先回复 ACK 确认收到 FIN，等数据发送完毕后再发送 FIN，所以 ACK 和 FIN 分开发送，不能合并为三次。

4.请解释 TIME_WAIT 状态的含义、持续时间以及它存在的两个主要原因。

**答案与解析：**TIME_WAIT 是主动关闭连接的一方在发送最后一个 ACK 报文后进入的状态，持续时间为 2MSL（Maximum Segment Lifetime，报文最大生存时间，通常为 30 秒到 2 分钟）。它存在的两个主要原因：一是确保最后一个 ACK 被对方接收，如果最后一个 ACK 丢失，被动关闭方会重发 FIN，主动关闭方需要处于 TIME_WAIT 状态才能重新发送 ACK；二是防止延迟的重复报文干扰新连接，TIME_WAIT 等待 2MSL 确保所有旧报文在网络中消失，避免旧报文被误认为是新连接的数据。

5.请说明 HTTP 请求报文和响应报文分别由哪几部分组成，每部分的作用是什么。

**答案与解析：**请求报文由四部分组成：请求行，包含请求方法、URI 和 HTTP 版本，如 GET /index.html HTTP/1.1；请求头，包含 Host、User-Agent、Content-Type、Accept 等键值对，描述客户端信息和请求属性；空行，用于分隔请求头和请求体；请求体，携带请求数据，GET 请求通常为空，POST 请求携带表单或 JSON 数据。响应报文也由四部分组成：状态行，包含 HTTP 版本、状态码和状态描述，如 HTTP/1.1 200 OK；响应头，包含 Content-Type、Content-Length、Set-Cookie 等键值对，描述响应内容属性和服务器信息；空行，分隔响应头和响应体；响应体，携带服务器返回的实际数据，如 HTML 页面、JSON 数据或文件内容。

6.2 原理分析题

6.为什么 TCP 建立连接需要三次握手而不是两次？如果只有两次握手会带来什么问题？

**答案与解析：**第一次和第二次握手确认了服务器的接收和发送能力，第二次和第三次握手确认了客户端的接收和发送能力。如果只进行两次握手，服务器无法确认客户端是否收到了自己的 SYN+ACK 报文。考虑一种场景：客户端发送的第一个 SYN 报文因网络拥塞延迟，客户端超时后重发 SYN 并成功建立连接，数据传输完毕后关闭连接。此时第一个延迟的 SYN 报文才到达服务器，服务器误以为客户端要建立新连接，于是回复 SYN+ACK 并分配资源，但客户端不会响应，导致服务器资源被白白占用。三次握手能同步双方的初始序列号，为后续可靠传输奠定基础，同时避免这种失效连接请求造成的资源浪费和连接混乱。

7.在四次挥手过程中，为什么被动关闭方收到 FIN 后要先回复 ACK，而不是直接回复 FIN？

**答案与解析：**因为 TCP 连接是全双工的，被动关闭方收到 FIN 只表示主动关闭方不再发送数据，但被动关闭方可能还有数据需要继续发送。如果被动关闭方直接回复 FIN，就会立即关闭自己的发送方向，导致尚未发送完的数据无法送达。因此被动关闭方先回复 ACK 确认收到 FIN，进入 CLOSE_WAIT 状态，继续发送剩余数据；等数据全部发送完毕后，再发送 FIN 关闭自己的发送方向。所以 ACK 和 FIN 必须分开发送，这也是四次挥手不能合并为三次的根本原因。

8.高并发服务器出现大量 TIME_WAIT 状态连接时，可能带来哪些问题？有哪些可行的解决方案？

**答案与解析：**大量 TIME_WAIT 状态的套接字会占用端口和内存资源，可能导致端口耗尽，使服务器无法建立新连接。可行的解决方案包括：调整内核参数 net.ipv4.tcp_tw_reuse，允许在安全条件下复用 TIME_WAIT 状态的连接（仅适用于客户端主动连接场景）；调整 net.ipv4.tcp_fin_timeout 缩短 TIME_WAIT 的等待时间；在服务器设计中尽量避免服务器主动关闭连接，让客户端主动关闭；使用长连接复用机制，减少频繁建立和关闭连接。

9.请分析 TCP 的流量控制和拥塞控制分别解决什么问题，两者有何区别？

**答案与解析：**流量控制解决的是发送方发送速率与接收方接收能力不匹配的问题，通过滑动窗口机制，根据接收方通告的窗口大小动态调整发送速率，防止接收方缓冲区溢出导致数据丢失。拥塞控制解决的是网络链路拥塞的问题，通过慢启动、拥塞避免、快重传、快恢复等机制，根据网络状况动态调整发送窗口，防止过多数据注入网络造成拥塞崩溃。两者的区别在于：流量控制是端到端的，只关心接收方的处理能力，由接收方通告窗口决定；拥塞控制是全局性的，关心整个网络的承载能力，由网络拥塞程度决定。两者共同作用，保证 TCP 传输既可靠又高效。

10.为什么 UDP 不需要建立连接？UDP 的不可靠性在实际应用中如何被上层协议弥补？

**答案与解析：**UDP 是无连接的协议，发送方直接调用 sendto() 发送数据报，不需要经过三次握手建立连接，也不需要维护连接状态，因此开销小、延迟低、实时性好。UDP 的不可靠性在实际应用中可以通过上层协议弥补：在应用层实现确认重传机制，如自定义 ACK 和超时重传；在应用层实现序号机制，对数据报编号以检测丢失和乱序；使用前向纠错编码，在数据报中携带冗余信息，接收方无需重传即可恢复部分丢失数据；在应用层实现拥塞控制和流量控制，如 QUIC 协议在 UDP 之上实现了可靠传输和拥塞控制。这些方式在保留 UDP 低延迟优势的同时，弥补了其不可靠的缺陷。

6.3 对比辨析题

11.请从连接性、可靠性、流量控制、拥塞控制、数据传输方式和适用场景六个方面对比 TCP 与 UDP 的区别。

**答案与解析：**连接性方面，TCP 面向连接，需三次握手建立连接；UDP 无连接，直接发送数据报。可靠性方面，TCP 可靠传输，通过确认重传、序号机制保证数据不丢失、不重复、有序到达；UDP 不可靠，不保证送达、不保证顺序。流量控制方面，TCP 使用滑动窗口机制，根据接收方能力动态调整发送速率；UDP 无流量控制。拥塞控制方面，TCP 采用慢启动、拥塞避免、快重传、快恢复；UDP 无拥塞控制。数据传输方式方面，TCP 是字节流，无消息边界，需应用层处理粘包/拆包；UDP 是数据报，保留消息边界。适用场景方面，TCP 适合文件传输、Web 浏览、邮件、数据库连接等对可靠性要求高的场景；UDP 适合实时音视频、DNS 查询、游戏、广播等对实时性要求高、可容忍丢包的场景。

12.请对比 TCP 编程与 UDP 编程在服务器端和客户端的流程差异，说明各自使用的关键系统调用。

**答案与解析：**TCP 服务器流程为：socket() 创建监听套接字、bind() 绑定地址端口、listen() 转为监听状态、accept() 接受连接、read()/write() 或 recv()/send() 数据收发、close() 关闭连接。TCP 客户端流程为：socket() 创建套接字、connect() 连接服务器、send()/recv() 数据收发、close() 关闭连接。UDP 服务器流程为：socket(AF_INET, SOCK_DGRAM, 0) 创建套接字、bind() 绑定地址端口、recvfrom()/sendto() 数据收发、close() 关闭连接。UDP 客户端流程为：socket() 创建套接字、sendto()/recvfrom() 数据收发、close() 关闭连接。核心差异在于：TCP 需要 listen() 和 accept()，UDP 不需要；TCP 使用 send()/recv() 或 read()/write()，UDP 使用 sendto()/recvfrom()，后两者必须携带对端地址；TCP 是字节流无消息边界，UDP 是数据报有明确边界。

13.请对比 GET 与 POST 方法在参数位置、数据大小限制、安全性、缓存机制和幂等性方面的区别，并说明各自的适用场景。

**答案与解析：**参数位置方面，GET 参数拼接在 URL 查询字符串中，POST 参数放在请求体中。数据大小限制方面，GET 受 URL 长度限制（通常 2KB 到 8KB），POST 理论上无大小限制，由服务器配置决定。安全性方面，GET 参数暴露在 URL 中，易被浏览器历史、代理日志记录，安全性较低；POST 参数在请求体中相对更隐蔽，但仍需 HTTPS 加密保证安全。缓存机制方面，GET 可被浏览器主动缓存，适合幂等查询；POST 默认不缓存，每次请求都会到达服务器。幂等性方面，GET 幂等，重复执行结果相同，不会改变服务器状态；POST 非幂等，重复提交可能产生多次副作用（如重复下单）。适用场景方面，GET 适合查询、搜索、浏览等只读操作；POST 适合提交表单、上传数据、创建资源等写操作。

14.请对比 OSI 七层模型与 TCP/IP 四层模型的层次划分，说明两者的对应关系及 TCP/IP 模型更实用的原因。

**答案与解析：**OSI 七层模型自下而上为物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。TCP/IP 四层模型为网络接口层、网络层、传输层、应用层。对应关系为：TCP/IP 应用层对应 OSI 的应用层、表示层、会话层；TCP/IP 传输层对应 OSI 传输层；TCP/IP 网络层对应 OSI 网络层；TCP/IP 网络接口层对应 OSI 数据链路层和物理层。TCP/IP 模型更实用的原因在于：它基于实际互联网协议设计，层次划分更简洁，将 OSI 中功能相近的层合并，减少了不必要的抽象；OSI 模型是理论参考模型，先于协议制定，部分层次（如会话层、表示层）在实际应用中功能较弱，而 TCP/IP 模型是实际互联网所采用的协议体系，与真实网络环境高度吻合。

15.请对比 404 Not Found、403 Forbidden、500 Internal Server Error 和 502 Bad Gateway 四种状态码的含义及产生原因。

**答案与解析：**404 Not Found 表示服务器找不到请求的资源，属于客户端错误，产生原因包括用户输入了错误的链接、资源被移动未做重定向、后端路由配置缺失。403 Forbidden 表示服务器理解请求但拒绝执行，客户端没有访问该资源的权限，产生原因包括权限配置不足、IP 被限制、未通过身份认证但资源要求更高权限。500 Internal Server Error 表示服务器内部发生错误，无法完成请求，属于服务器错误，产生原因包括后端代码抛出未捕获异常、数据库连接失败、服务器配置错误、依赖服务不可用。502 Bad Gateway 表示服务器作为网关或代理时，从上游服务器收到无效响应，产生原因包括反向代理后面的应用服务宕机、上游服务超时、负载均衡配置错误、后端进程崩溃未重启。四者的核心区别在于：404 和 403 是客户端问题（资源不存在或无权访问），500 和 502 是服务器问题（内部错误或上游服务异常）。

7. 总结

本文系统梳理了 Linux 网络编程的核心知识体系：从 OSI 七层模型和 TCP/IP 四层模型的层次结构，到 TCP/UDP 编程的标准流程与差异对比，再到 TCP 三次握手、四次挥手和 TIME_WAIT 等核心机制，最后介绍了 HTTP 协议基础与常见状态码。