S07-01 网络编程-网络基础
[TOC]
网络编程概述
Java 网络编程主要是利用 java.net 与 java.nio 等包提供的 API，实现跨网络主机间的数据通信。Java 屏蔽了底层的套接字（Socket）细节，提供了面向连接（TCP）与面向无连接（UDP）的高层抽象。
为了帮助你系统化掌握，以下按网络基础、TCP 编程、UDP 编程以及 NIO 高级演进四个阶段展开介绍。
核心概念
网络编程的核心在于定位主机与指定进程。
地址与端口：
- IP 地址 (
InetAddress)：标识网络中的唯一设备。Java 中通过InetAddress.getByName("host")或getLocalHost()进行解析与操作。 - 端口号 (Port)：标识设备上的特定应用程序。取值范围为 0 至 65535（其中 0 至 1024 为系统保留端口）。
- 套接字 (Socket)：IP 地址与端口号的组合，是网络通信的逻辑端点。
TCP 与 UDP 对比：
| 特性 | TCP (传输控制协议) | UDP (用户数据报协议) |
|---|---|---|
| 连接状态 | 面向连接（三次握手） | 无连接（直接发送） |
| 可靠性 | 高（保证顺序、无丢包、重传机制） | 低（可能丢包、乱序） |
| 传输单位 | 字节流 (InputStream/OutputStream) | 数据报 (DatagramPacket) |
| 适用场景 | 文件传输、网页浏览、远程登录 | 实时视频、在线游戏、DNS 查询 |
TCP 编程
TCP 编程采用典型的客户端-服务端（Client-Server）模式。服务端监听端口，客户端发起连接，建立双向字节流通道。
核心 API：
ServerSocket：服务端套接字，调用accept()方法阻塞等待客户端连接。Socket：客户端套接字，通过getInputStream()和getOutputStream()实现数据的读写。
UDP 编程
UDP 是无连接协议，不建立长期通道，每个数据报（Datagram）都是独立的包。
核心 API：
DatagramSocket：用于发送与接收数据报套接字。DatagramPacket：数据包容器，封装实际数据字节数组、目标 IP 地址及目标端口。
发送与接收机制：
接收方：实例化
DatagramSocket(port)绑定端口，创建空DatagramPacket，调用receive()方法阻塞等待数据填入。发送方：将字节数据、目标 IP 与端口打包放入
DatagramPacket，通过DatagramSocket的send()方法直接发送。
高级演进
在面对高并发场景时，传统的阻塞式 I/O（BIO）会占用过多线程，因此 Java 引入了非阻塞 I/O 及现代化 API。
I/O 模型演进：
- BIO (Blocking I/O)：一个连接对应一个处理线程，高并发下线程切换开销巨大。
- NIO (Non-blocking I/O)：引入
Channel（通道）、Buffer（缓冲区）和Selector（多路复用器）。单个线程可同时轮询管理成千上万个连接。 - Netty 框架：基于 Java NIO 构建的高性能网络应用框架，屏蔽了原生 NIO 复杂的细节，是目前工业级网络开发的首选。
现代 HTTP 客户端：
从 Java 11 开始，引入了全新的 HttpClient API，全面替代旧有的 HttpURLConnection：
- 原生支持 HTTP/1.1 与 HTTP/2 协议。
- 支持同步与基于
CompletableFuture的异步非阻塞请求。 - 采用链式调用设计，语法简洁易用。
软件系统架构
在软件工程中，C/S 架构（Client/Server，客户端/服务器）与 B/S 架构（Browser/Server，浏览器/服务器）是两种最为经典的软件系统体系结构。两者的核心区别在于客户端的形态以及业务逻辑在前端与服务端的分配比例。
核心定义
- C/S 架构：需要用户在本地设备上安装专门的客户端软件。客户端承担部分业务逻辑和界面渲染，服务端负责核心数据与逻辑处理。
- B/S 架构：客户端统一采用通用的 Web 浏览器。业务逻辑、页面渲染与数据存储主要由服务端的 Web 服务器与数据库系统协同完成。
C/S 架构
C/S 架构采用典型的两层（或三层）结构，将应用逻辑划分在客户端与服务端之间。
工作机制
客户端（Client）：负责用户交互界面（UI）展示、输入校验、本地数据缓存以及部分业务逻辑计算。
服务端（Server）：负责核心业务逻辑运算、事务处理、数据库存取与安全控制。
通信协议：双方通常使用底层网络协议（如 TCP/IP Socket）或自定义二进制协议传输数据。
优缺点分析
优点：- 响应速度快：充分调用本地 CPU、显卡等硬件资源，界面渲染与动画流畅，适合高频复杂交互。
- 网络依赖较低：支持较强的本地缓存与离线操作能力，仅在数据同步时占用网络带宽。
- 安全性可控：传输协议与数据包可进行深度加密，通信限制在特定客户端与服务器之间。
缺点：- 部署运维成本高：每个客户端均需单独下载、安装与环境配置。
- 跨平台能力差：针对 Windows、macOS、Linux 或移动端需要分别进行代码适配与开发。
- 版本更新困难：新功能发布需要用户手动下载升级包或重新安装。
B/S 架构
随着互联网与 Web 技术的发展，B/S 架构成为了大多数企业级应用与消费级互联网产品的首选架构。
工作机制
浏览器（Browser）：作为统一客户端，仅负责接收并解析标准 Web 资源（HTML、CSS、JavaScript），通过 DOM 渲染界面。
Web 服务器（Server）：处理 HTTP/HTTPS 请求，执行后端业务逻辑，通过数据库存取数据并返回结果（如 HTML 页面或 JSON 数据）。
前后端分离趋势：现代 B/S 架构普遍采用前后端分离模式，前端运行在浏览器单页应用（SPA）中，通过 RESTful API 或 GraphQL 与后端通信。
优缺点分析
优点：零安装与跨平台：只要设备拥有浏览器和网络，即可随时随地访问，天然跨操作系统与硬件平台。
维护升级极简：版本更新只需在服务端重新部署，所有用户刷新网页即可使用最新版本（无客户端维护开销）。
开发生态繁荣：基于 Web 标准构建，具备海量的开源框架、组件库与标准化工具。
缺点：- 硬件调用受限：出于浏览器安全沙箱限制，难以直接调用客户端本地硬件设备（如串口、蓝牙、高精度加密狗等）。
- 网络依赖性高：绝大多数功能依赖实时网络连接，网络断开或高延迟会直接影响可用性。
- 首屏加载开销：初次加载需要通过网络传输 JavaScript 和 CSS 样式资源，受网络带宽影响较明显。
深度对比
| 对比维度 | C/S 架构 (Client / Server) | B/S 架构 (Browser / Server) |
|---|---|---|
| 客户端要求 | 需安装专门的客户端软件 | 仅需通用浏览器 |
| 跨平台性 | 较差，需要多平台独立开发 | 极佳，天然跨操作系统与设备 |
| 交互与性能 | 强，响应极快，可充分利用本地硬件 | 受限于网络带宽和浏览器渲染性能 |
| 升级与维护 | 困难，需逐台终端更新 | 极简，仅需升级服务端 |
| 通信协议 | TCP / UDP / 自定义二进制协议 | HTTP / HTTPS / WebSocket |
| 安全防护 | 较强，面向专用网络或特定用户 | 较弱，面向公网，易受 Web 漏洞攻击（XSS、CSRF 等） |
| 典型应用 | 3D 大型游戏、专业图形设计软件（Photoshop、CAD）、桌面 IDE | 电子政务系统、企业 ERP/CRM、电商平台、Web 邮箱 |
融合趋势
现代软件工程逐渐打破了 C/S 与 B/S 的绝对界限，呈现出相互融合的发展方向：
融合1：桌面端 Web 化
利用 Electron、Tauri 等跨平台框架，开发者可以使用 HTML/CSS/JavaScript 构建前端界面，同时利用 Node.js 或 Rust 底层能力访问系统 API。常见的应用如 VS Code、Slack、Discord，兼具了 B/S 的开发效率与 C/S 的原生系统控制能力。
融合2：Web 端原生化
通过 WebAssembly（Wasm）技术，开发者可以将 C++、Rust、Go 等高性能语言编译并在浏览器沙箱中高效运行。例如 Figma、Photoshop Web 版，使得原先必须运行在 C/S 客户端的大型专业工具也能直接在 B/S 架构下平滑运行。
IP 地址
IP 地址（Internet Protocol Address，网际协议地址） 是分配给接入网络中的设备的逻辑标识符。它的作用类似于现实生活中的邮政地址，使得数据包能够在复杂的互联网路由中准确送达目标设备。
概述
网络通信发生在 OSI 模型中的网络层（第三层）。IP 地址作为逻辑地址，与物理硬件决定的 MAC 地址不同，它可以根据设备接入的网络环境动态改变或重新分配。
IP 地址的核心作用包括：
- 定位设备：在全局网络中唯一标识一台主机或路由器接口。
- 路由寻址：指导路由器将数据包从源网络逐跳传输至目标网络。
IPv4 详解
IPv4（网际协议第 4 版） 是目前应用最为普及的互联网协议。
结构构成
IPv4 地址由 32 位二进制数（4 个字节）组成。为了方便人类阅读，通常采用点分十进制表示法（如 192.168.1.1）。
每个 IPv4 地址在逻辑上划分为两部分：
- 网络标识（Network ID）：标识设备所在的子网。
- 主机标识（Host ID）：标识该子网内的具体设备。
地址分类
传统的 IPv4 采用 ABCDE 五类划分法：
- A 类：前 8 位为网络号（以
0开头），适用于超大型网络（如10.0.0.0）。 - B 类：前 16 位为网络号（以
10开头），适用于中型网络（如172.16.0.0）。 - C 类：前 24 位为网络号（以
110开头），适用于小型局域网（如192.168.1.0）。 - D 类：组播地址（以
1110开头）。 - E 类：保留用于科研（以
1111开头）。
子网掩码与 CIDR@
为了解决分类地址造成的地址浪费，后续引入了子网掩码（Subnet Mask）与 CIDR（无分类域间路由）：
- 子网掩码：用连续的
1表示网络位，用连续的0表示主机位（如255.255.255.0）。 - CIDR 表示法：如
192.168.1.0/24，/24表示前 24 位全为网络位，剩余 8 位为主机位。
特殊地址
- 回环地址：
127.0.0.1，用于本机进程间网络测试。 - 私有地址：用于局域网内部，不可直接在公网上路由（如
10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）。 - 广播地址：主机号全为
1的地址（如192.168.1.255），用于给网段内所有设备发包。
IPv6 详解
由于 IPv4 地址在 2011 年左右已被各大区域互联网注册机构分配完毕，IPv6 作为下一代互联网协议被广泛推广。
结构构成
IPv6 地址长度扩充至 128 位（16 字节），采用冒号十六进制表示法（如 2001:0db8:85a3:0000:0000:8a2e:0370:7334），并支持前导零省略与双冒号 :: 压缩。
核心优势
- 海量地址空间：提供约 个地址，彻底解决地址耗尽问题。
- 简化报头：精简了报头字段，提高了路由器的路由转发效率。
- 无状态自动配置（SLAAC）：设备连网后无需依赖 DHCP 服务器即可自动生成有效 IP 地址。
- 原生安全：设计之初即集成了 IPsec 加密与身份认证支持。
IPv4 与 IPv6 对比
| 维度 | IPv4 | IPv6 |
|---|---|---|
| 地址长度 | 32 位（4 字节） | 128 位（16 字节） |
| 表示方式 | 点分十进制（如 192.168.1.1） | 冒号十六进制（如 2001:db8::1） |
| 地址数量 | 约 43 亿个 | 约 个 |
| 配置方式 | 手动配置或 DHCP | 支持无状态（SLAAC）与有状态（DHCPv6） |
| 首部校验和 | 包含（每一跳重新计算） | 移除（交由上层协议保障） |
地址分配与转换
在实际网络运营中，IP 地址的管理与数据转发依赖以下关键技术：
DHCP 协议
动态主机配置协议（Dynamic Host Configuration Protocol，DHCP），自动为接入网络的设备分配 IP 地址、子网掩码、默认网关与 DNS 服务器地址，避免人工手动配置引发的 IP 冲突。
NAT 技术
网络地址转换（Network Address Translation，NAT），允许多台局域网内部设备共享同一个公网 IP 地址访问互联网，既缓解了 IPv4 公网地址紧缺的问题，又对内网设备起到了安全隔离保护作用。
端口
在计算机网络中，端口（Port） 是操作系统用于区分不同网络服务或应用程序的逻辑通道。如果把 IP 地址比作一栋大楼的地址，那么端口号就是这栋大楼里的房间号或分机号，数据包通过 IP 地址找到设备后，再通过端口号准确定位到具体的应用程序。
核心定义
网络中的端口通常特指逻辑端口（协议端口），属于 OSI 模型中的传输层（Transport Layer）。
作用与本质
- 标识进程：网络设备通常同时运行多个网络服务（如网页服务、邮件服务）。端口号用于确保传入的数据能准确分发给对应的处理进程。
- 数据结构：端口号由一个 16 位无符号二进制数表示，因此取值范围为
0至65535（共 65,536 个可用端口）。
端口分类
国际 Internet 数字地址分配机构（IANA）将 0 到 65535 的端口划分为三个标准区间：
分类1：公认端口 (Well-Known Ports)
- 范围：
0至1023 - 特点：预留给系统核心服务和通用标准网络协议（如 Web、SSH、DNS）。在类 Unix 系统中，绑定此类端口通常需要 root 或管理员权限。
分类2：注册端口 (Registered Ports)
- 范围：
1024至49151 - 特点：分配给用户自定应用或商业软件（如数据库、中间件）。开发人员可向 IANA 注册申请特定的默认端口，普通用户权限即可绑定。
分类3：动态/私有端口 (Dynamic / Private Ports)
- 范围：
49152至65535 - 特点：又称临时端口（Ephemeral Ports）。当客户端（如浏览器）主动向服务端发起请求时，操作系统会在该范围内随机分配一个临时端口，用于接收服务端的响应数据。通信结束后该端口会被自动释放。
常见端口
下表罗列了互联网中最常用的服务及其对应的默认端口与传输层协议：
| 协议 / 服务 | 默认端口 | 传输层协议 | 主要用途 |
|---|---|---|---|
| FTP | 21 | TCP | 文件传输控制端口 |
| SSH | 22 | TCP | 远程安全登录与命令执行 |
| Telnet | 23 | TCP | 明文远程终端登录 |
| DNS | 53 | UDP / TCP | 域名解析服务 |
| HTTP | 80 | TCP | 超文本传输（未加密网页） |
| HTTPS | 443 | TCP | 加密超文本传输（SSL/TLS） |
| MySQL | 3306 | TCP | MySQL 数据库连接 |
| Redis | 6379 | TCP | Redis 内存数据库服务 |
| HTTP-Alt | 8080 | TCP | 常用 Web 代理或 Java Web 应用端口 |
工作机制
数据包在网络中传输时，依靠四元组（源 IP、源端口、目的 IP、目的端口）来唯一定位一次通信会话。
套接字与端口绑定：
- 套接字 (Socket)：套接字是网络通信的端点，表达形式为
IP 地址 : 端口号（例如192.168.1.10:80）。 - 端口排他性：在同一台设备上，同一个传输层协议（TCP 或 UDP）下，一个端口同时只能被一个进程占用。尝试重复绑定会导致“端口已被占用”（Port already in use）错误。
- 协议独立：TCP 与 UDP 的端口空间相互独立。也就是说，TCP 80 端口与 UDP 80 端口可以同时存在并分属不同的进程。
安全与管理
端口是外部访问系统内部服务的入口，也是网络安全防护的重中之重。
端口扫描
安全人员或攻击者使用工具（如 Nmap）扫描目标 IP 的端口开放情况，以侦测目标主机运行了哪些服务、是否存在已知安全漏洞。
防火墙控制
通过配置网络或本机防火墙规则（如 iptables、ufw 或安全组），仅开放必要的服务端口（如 80、443），封禁不必要的敏感端口（如 22、3306），能够显著降低攻击面。
端口映射/转发
在 NAT（网络地址转换）网络环境中，公网路由器可以将公网 IP 的某个端口映射到内网私有 IP 的特定端口上，使外部用户能够访问内网服务器。
端口占用排查
在日常开发与运维中，端口被程序意外占用（如 Port 8080 is already in use）是十分常见的问题。定位并清除占用端口的流程通常分为三步：查找占用端口 -> 定位进程 PID -> 强制终止进程。
Windows 系统
在 Windows 系统中，可通过命令提示符（CMD） 或 PowerShell 完成排查与清除。
步骤1：查看端口占用与 PID
打开 CMD（建议以管理员身份运行），使用 netstat 结合 findstr 过滤目标端口：
netstat -ano | findstr :8080参数含义：
-a：显示所有连接和监听端口。-n：以数字形式（如 IP 地址和端口号）显示地址。-o：显示与每个连接关联的进程 PID。
输出示例：
textTCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 12345
最后一列数字 12345 即为占用该端口的进程 PID。
步骤2：查看 PID 对应的进程名称
获取到 PID 后，使用 tasklist 确认具体的程序名称，避免误杀系统关键服务：
tasklist | findstr 12345输出示例：
textjava.exe 12345 Console 1 150,200 K
步骤3：强行解除端口占用
使用 taskkill 命令强行结束该 PID 对应的进程：
taskkill /F /PID 12345- 参数含义：
/F：强制终止进程。/PID：指定要终止的进程 ID。/T（可选）：终止指定的进程及其派生的任何子进程。
提示：也可以直接按进程名称强行终止所有同名进程（慎用）：
taskkill /F /IM java.exe
Linux 系统
Linux 下有多种工具（lsof、ss、fuser）可快速检索端口，建议在命令前加上 sudo 以获取查看所有系统进程的权限。
方法一：使用 lsof 命令
lsof（List Open Files）可以直接一步定位占用端口的进程与 PID：
sudo lsof -i :8080只查看监听状态的 TCP 端口：
bashsudo lsof -iTCP:8080 -sTCP:LISTEN输出示例：
textCOMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME java 12345 root 4u IPv6 123456 0t0 TCP *:8080 (LISTEN)
其中 COMMAND 为进程名，PID 为进程 ID。
方法二：使用 ss 或 netstat 命令
ss 是现代 Linux 系统中更高效的网络排查工具：
sudo ss -tulnp | grep :8080参数含义：
-t(TCP)、-u(UDP)、-l(监听状态)、-n(数字形式)、-p(显示进程名与 PID)。如果系统未安装
ss，可使用旧版netstat：bashsudo netstat -tulnp | grep :8080
方法三：使用 fuser 命令
fuser 可以直接通过端口号查找或终止进程：
查找端口 PID：
bashsudo fuser 8080/tcp直接强行终止占用该端口的进程：
bashsudo fuser -k -9 8080/tcp
后续操作：强行解除端口占用
若使用 lsof 或 ss 获取到了 PID（如 12345），使用 kill -9 发送 SIGKILL 信号强制终止进程：
sudo kill -9 12345注意：建议先使用不带
-9的默认命令（sudo kill 12345）尝试让程序优雅退出，若程序无响应再使用kill -9。
命令汇总对比
| 操作阶段 | Windows 命令 | Linux 命令 |
|---|---|---|
| 查看端口与 PID | netstat -ano | findstr :端口号 | sudo lsof -i :端口号sudo ss -tulnp | grep :端口号 |
| 确认进程名称 | tasklist | findstr PID | ps -ef | grep PID |
| 强制终止进程 | taskkill /F /PID PID | sudo kill -9 PID sudo fuser -k -9 端口号/tcp |
域名
域名（Domain Name） 是互联网上用于标识计算机或服务位置的字符化名称。它是对数字形式 IP 地址的一种人类易读化映射，由域名系统（DNS，Domain Name System） 统一管理和解析。
核心概念
网络设备在传输数据包时依靠 IP 地址进行定位，但数字形式的 IP 地址（如 192.0.2.1 或 2001:db8::1）难以记忆。
域名的主要作用与特性包括：
- 人机可读：将复杂的数字 IP 地址转化为形如
example.com的文字，便于记忆与传播。 - 解耦与灵活：服务器的实际 IP 地址发生变更时，只需更新 DNS 解析记录，无需改变用户访问的域名。
- 多服务映射：一个 IP 地址可以绑定多个域名；反之，一个域名也可以通过负载均衡解析到多个 IP 地址。
域名结构
域名系统采用树状分层结构，各级名称由点号 . 分隔，层级从右向左递减（即最右侧为最高层级）。
层级划分：
根域（Root Domain）：位于树状结构的最顶端，用点
.表示（通常在网址中被隐式省略）。全局共有 13 组根域名服务器。顶级域（TLD, Top-Level Domain）：
- 通用顶级域（gTLD）：如
.com（商业）、.org（组织）、.net（网络服务）、.edu（教育）。 - 国家/地区代码顶级域（ccTLD）：如
.cn（中国）、.us（美国）、.jp（日本）。 - 新通用顶级域（new gTLD）：如
.app、.tech、.xyz等。
- 通用顶级域（gTLD）：如
二级域（SLD, Second-Level Domain）：用户向域名注册商（如阿里云、腾讯云、Cloudflare）付费注册的主名称（如
google、baidu）。三级域与子域（Subdomain）：由域名拥有者自行在二级域下创建的前缀，用于区分不同业务（如
blog.example.com或api.example.com）。
完全合格域名（FQDN）：指明确指定了从主机名一直延伸到根域的完整路径名称（如
[www.example.com](https://www.example.com).）。
解析流程
当你在浏览器输入一个域名时，系统需要通过递归与迭代查询将域名转换为对应的 IP 地址。
解析步骤：
以访问 www.example.com 为例：
检查本地缓存：浏览器首先检查自身缓存、操作系统 DNS 缓存及本地
hosts文件。若已命中则直接返回 IP。请求本地 DNS 服务器：若本地未命中，请求发送至网络配置的本地 DNS（如运营商 DNS 或
1.1.1.1、8.8.8.8）。查询根域名服务器：本地 DNS 依次发起迭代查询，首先问根服务器：“
www.example.com的 IP 是什么？”根服务器告知.com顶级域服务器的地址。查询 TLD 服务器：本地 DNS 询问
.comTLD 服务器，TLD 服务器告知负责example.com的权威 DNS 服务器地址。查询权威 DNS 服务器：本地 DNS 询问权威服务器，权威服务器查找解析记录并返回最终的 IP 地址（如
93.184.216.34）。缓存并建立连接：本地 DNS 将结果缓存（在 TTL 规定时间内有效）并返回给用户浏览器，浏览器向该 IP 发起 TCP 连接。
常见 DNS 记录
权威 DNS 服务器通过不同的资源记录（Resource Record） 来指导流量的去向：
| 记录类型 | 全称 | 作用与说明 | 示例 |
|---|---|---|---|
| A 记录 | Address Record | 将域名直接映射到 IPv4 地址 | example.com -> 93.184.216.34 |
| AAAA 记录 | IPv6 Address Record | 将域名映射到 IPv6 地址 | example.com -> 2606:2800:220:1:248:1893:25c8:1946 |
| CNAME 记录 | Canonical Name | 别名记录，将一个域名指向另一个域名 | [www.example.com](https://www.example.com) -> example.cdn.com |
| MX 记录 | Mail Exchanger | 指定接收该域名电子邮件的邮件服务器 | example.com -> mail.example.com |
| TXT 记录 | Text Record | 存储文本信息，常用于域名所有权验证与邮件安全（SPF、DKIM、DMARC） | "v=spf1 include:_spf.google.com ~all" |
| NS 记录 | Name Server | 指定该域名的权威 DNS 解析服务器 | NS1.CLOUDFLARE.COM |
| CAA 记录 | CA Authorization | 规定哪些证书颁发机构（CA）有权为该域名签发 SSL/TLS 证书 | 0 issue "letsencrypt.org" |
域名管理
域名的运营与安全管理涉及以下关键环节：
管理角色：
- ICANN：互联网名称与数字地址分配机构，负责全球顶级域名和 IP 地址分配的统筹管理。
- 注册局（Registry）：维护特定顶级域数据库的组织（如 CNNIC 管理
.cn，Verisign 管理.com）。 - 注册商（Registrar）：获得 ICANN/注册局授权、向公众提供域名注册与续费服务的代理商。
域名安全：
- DNSSEC（DNS 安全扩展）：通过数字签名验证 DNS 数据的真实性与完整性，防止 DNS 缓存污染和域名劫持。
- 隐私保护（WHOIS Privacy）：隐藏域名所有者的个人联系方式（姓名、邮箱、电话），防止隐私泄露与垃圾邮件打扰。
- 域名锁（Registrar Lock）：防止未经授权的域名转移或 DNS 服务器篡改。
Socket
套接字（Socket） 是操作系统提供给应用程序进行网络通信的编程接口（API）与逻辑端点。它封装了底层复杂的 TCP/IP 协议栈细节，让开发者无需关心 IP 头部校验、TCP 乱序重组等底层机制，只需像操作本地文件一样（打开、读取、写入、关闭）进行网络数据传输。
核心概念
在网络通信中，Socket 作为应用层与传输层之间的桥梁而存在。
一个完整的网络 Socket 通信由五元组唯一标识：
- 源 IP 地址：发送方设备标识
- 源端口号：发送方应用进程标识
- 目的 IP 地址：接收方设备标识
- 目的端口号：接收方应用进程标识
- 传输层协议：TCP 或 UDP
Unix 哲学的体现：在 Unix/Linux 系统中，“一切皆文件”。Socket 在操作系统内核中表现为一个文件描述符（File Descriptor, FD），应用程序对 Socket 的读写本质上是对对应内核缓冲区的 I/O 操作。
工作原理
TCP Socket 的通信建立在客户端-服务端（Client-Server）模型之上，遵循严格的状态流转与交互序列。
通信建立流程：
服务端初始化与监听: bind -> listen
服务端创建套接字后，将其绑定（bind）到指定的本地 IP 和端口，并开启监听（listen）模式，等待客户端请求。
客户端发起连接请求: connect
客户端创建套接字后，指定服务端的 IP 和端口，调用
connect()发起 TCP 三次握手。服务端接收连接: accept
服务端调用
accept()阻塞等待。握手成功后，内核为该连接生成一个新的已连接套接字（Connected Socket），专用于与该客户端通信。数据双向传输: read / write
双方通过各自套接字的输入/输出流读写数据，操作系统负责数据的分段、确认与重传。
连接关闭: close
任一方调用
close()发起 TCP 四次挥手，释放端口及相关内核资源。
主要分类
根据传输层协议和通信特性的不同，Socket 主要分为以下三种类型：
| 套接字类型 | 对应协议 | 特性与优缺点 | 常见应用场景 |
|---|---|---|---|
| 流式套接字 (SOCK_STREAM) | TCP | 面向连接、可靠传输、顺序无误、无记录边界（字节流） | Web 浏览 (HTTP)、文件传输 (FTP)、远程登录 (SSH) |
| 数据报套接字 (SOCK_DGRAM) | UDP | 无连接、不可靠、速度快、保留报文边界（数据报） | 实时视频会议、在线游戏、DNS 查询、语音通话 |
| 原始套接字 (SOCK_RAW) | IP / ICMP | 绕过传输层，直接访问底层 IP 数据包或自定义协议头 | 网络抓包 (Wireshark)、Ping 命令 (ICMP)、网络安全扫描 |
关键机制
深入理解 Socket 需要掌握以下底层工作机制：
套接字缓冲区
每个 Socket 在内核中都拥有独立的发送缓冲区（SO_SNDBUF）与接收缓冲区（SO_RCVBUF）：
- 当应用层调用发送方法时，数据被复制到内核发送缓冲区，由 TCP 协议栈按滑动窗口机制发送。
- 当数据到达网卡，内核将其放入接收缓冲区，应用层调用读取方法时从该缓冲区读取数据。
TCP 粘包与拆包
TCP 是基于字节流的协议，没有明确的数据包边界：
粘包：发送方连续发送的小数据块在接收缓冲区被合并成一次读取。
拆包：单个较大数据块被 TCP 拆分为多个分段发送，接收方单次读取不完整。
常见解决方案：
固定长度：规定每条消息长度固定（不足部分填充空格或零字节）。
分隔符：在数据包末尾添加特定字符（如
\n或\r\n）。自定义协议头：在消息头部指定变长数据体（Body）的实际字节长度（Length Header）。
阻塞与非阻塞 I/O
- 阻塞 Socket：调用
read()时若无数据到达，线程会挂起，直到数据准备就绪。 - 非阻塞 Socket：调用立即返回，无数据时返回错误码，结合多路复用（如 Linux 的
epoll）可实现单线程管理成千上万个 Socket。
WebSocket 对比
传输层的 TCP Socket 与应用层的 WebSocket 容易被混淆：
| 对比维度 | TCP Socket | WebSocket |
|---|---|---|
| 所属层级 | 传输层（Transport Layer） | 应用层（Application Layer） |
| 底层协议 | 直接建立在 IP 协议之上 | 建立在 TCP 之上，握手阶段借用 HTTP/HTTPS |
| 数据格式 | 原始字节流（Raw Bytes） | 带有帧结构（Frame）的文本或二进制数据 |
| 环境支持 | 适用于桌面端/服务端原生开发 | 原生受所有主流 Web 浏览器支持 |
| 适用场景 | 高性能网络编程、游戏客户端 | Web 端实时交互、聊天室、实时数据看板 |
OSI 网络模型
OSI（Open Systems Interconnection，开放式系统互联） 参考模型由国际标准化组织（ISO）于 1984 年提出。它将复杂的网络通信过程抽象为 7 个逻辑层级，每一层专注于特定的职责，并为其上层提供服务。
概念
OSI 模型的核心设计思想是分层与解耦：
- 模块化设计：将复杂的网络通信拆解为独立子问题，降低系统复杂度。
- 标准化接口：只要相邻层之间的接口规范不变，某一层内部实现的修改不会影响其他层。
- 排错基石：网络工程师通常按照 OSI 的分层顺序（自底向上或自顶向下）逐步排查网络故障。
七层架构
OSI 模型从高到低分为以下 7 层：
第7层：应用层（Application）
- 核心功能：直接面向终端用户和应用程序，提供网络服务的接口。
- 代表协议：HTTP、HTTPS、FTP、DNS、SMTP、SSH。
第6层：表示层（Presentation）
- 核心功能：负责数据的语法转换、加密解密、压缩与解压缩，确保不同操作系统间的数据格式能够互相理解。
- 代表技术：SSL/TLS、JPEG、ASCII、Base64。
第5层：会话层（Session）
- 核心功能：负责建立、管理与终止不同设备进程之间的通信会话，维护连接状态与同步校验点。
- 代表协议：RPC、PPTP、NetBIOS。
第4层：传输层（Transport）
- 核心功能：提供端到端（End-to-End）的数据传输服务，负责数据分段、流量控制、差错校验与端口寻址。
- 代表协议：TCP（可靠连接）、UDP（无连接）。
第3层：网络层（Network）
- 核心功能：负责逻辑寻址（IP 地址）与路由选择，决定数据包在异构网络间的最佳传输路径。
- 代表协议与设备：IP（IPv4/IPv6）、ICMP、ARP；核心设备为路由器。
第2层：数据链路层（Data Link）
- 核心功能：通过物理地址（MAC 地址）在同一网段内的节点间传输数据，进行帧同步、介质访问控制与硬件差错检测。
- 代表技术与设备：以太网（Ethernet）、Wi-Fi（802.11）；核心设备为交换机、网卡。
第1层：物理层（Physical）
- 核心功能：定义物理介质（线缆、接口、电压、频率）规范，将二进制比特流转换为电信号、光信号或无线电波进行传输。
- 代表介质与设备：双绞线、光纤、集线器、中继器。
封包过程
网络通信中，数据在发送方自顶向下封装，在接收方自底向上解封。
数据封装与解封：
发送端封装（Encapsulation）：
数据从应用层产生后向下流动。每经过一层，操作系统协议栈就会在该层数据前加上包含控制信息的头部（Header）（数据链路层还会额外加上尾部 Trailer）。
接收端解封（Decapsulation）：
数据到达接收方后向上流动。每经过一层，协议栈读取并剥离对应的层头部，校验无误后将载荷（Payload）交付给上一层，直至恢复出原始应用数据。
模型对比
在实际互联网工业界中，TCP/IP 四层（或五层）模型成为了事实上的标准，而 OSI 则作为理论分析参考模型。
| OSI 七层参考模型 | TCP/IP 四层模型 | 寻址标识 | 协议数据单元 (PDU) |
|---|---|---|---|
| 应用层 / 表示层 / 会话层 | 应用层 | - | 数据（Data） |
| 传输层 | 传输层 | 端口号（Port） | 数据段（Segment） |
| 网络层 | 网际层（IP 层） | IP 地址 | 数据包（Packet） |
| 数据链路层 / 物理层 | 网络接口层 | MAC 地址 | 数据帧（Frame） / 比特（Bit） |
- OSI 模型的价值：定义严格、结构清晰，是教学、网络设计与排错的标准语言。
- TCP/IP 的优势：实现简洁、性能高效，伴随互联网的普及成为了当下的主流规范。
TCP/IP 协议族
TCP/IP（Transmission Control Protocol / Internet Protocol，传输控制协议/网际协议） 是现代互联网通信的基础架构。它并非单一的协议，而是一个由数十个网络协议构成的协议族（Protocol Suite）。
协议概述
TCP/IP 协议族规定了计算机在网络中如何接入、如何寻址、数据如何打包传输以及如何接收处理。
- 开放性：TCP/IP 是独立于特定硬件和操作系统的开放标准，推动了全球互联网的统一。
- 分层设计：采用分层架构，上下层之间通过标准接口交互，降低了系统的耦合度。
- 端到端寻址：基于 IP 地址和端口号实现跨局域网、跨自治系统的全局寻址与通信。
体系架构
与 OSI 七层参考模型不同，TCP/IP 协议族通常采用更为实用的 四层架构模型：
TCP/IP 与 OSI 对比@
核心协议
TCP/IP 协议族在每一层均定义了专门的协议以协同工作：
应用层协议
- HTTP / HTTPS：超文本传输协议，Web 网页访问的基础。
- DNS：域名系统，将人类易记的域名映射为机器可读的 IP 地址。
- FTP：文件传输协议，用于网络节点间的文件双向传输。
- SMTP / POP3 / IMAP：电子邮件发送与接收协议。
传输层协议
网际层协议
- IP (IPv4 / IPv6)：网际协议，负责定义逻辑地址与数据包的跨网路由转发。
- ICMP：网际控制报文协议，用于传输网络诊断与错误信息（如
ping命令）。 - ARP：地址解析协议，负责在同一网段内将逻辑 IP 地址转换为物理 MAC 地址。
网络接口层协议
- Ethernet (以太网)：有线局域网的主流数据链路层与物理层标准。
- Wi-Fi (802.11)：无线局域网标准。
封装解封
数据在网络中从一台主机传输至另一台主机时，必须经历发送端的层层封装和接收端的层层解封。
封装过程
应用层：生成原始数据（Data）。
传输层：加上 TCP 或 UDP 首部（包含源端口、目的端口），形成数据段（Segment）/ 数据报（Datagram）。
网际层：加上 IP 首部（包含源 IP、目的 IP），形成数据包（Packet）。
网络接口层：加上链路层首部（包含源 MAC、目的 MAC）与尾部（FCS 校验），形成数据帧（Frame），最终转为二进制比特流通过物理介质发往网络。
解封过程
接收端网卡收到比特流后，自底向上逐层剥离协议头部，校验无误后将上一层的纯数据（Payload）向上交付，直至应用层拿到原始消息。
寻址通信
TCP/IP 协议族依靠三重寻址机制保障数据的准确送达：
- MAC 地址（网络接口层）：标识同一局域网内的网卡物理设备，实现相邻节点间的单跳（Hop-by-Hop）传输。
- IP 地址（网际层）：标识全球网络中的逻辑设备位置，指导路由器进行跨网路由选择。
- 端口号（传输层）：标识设备上的具体应用程序或进程，实现端到端的通信复用与分用。
TCP 协议~
TCP（Transmission Control Protocol，传输控制协议） 是互联网协议套件（TCP/IP）核心的传输层协议。它在不可靠的 IP 层之上，为应用层提供了一种面向连接的、可靠的、基于字节流的全双工通信服务。
协议概述
TCP 协议的设计目标是在复杂的网络环境中实现数据的无差错传输。
其核心特性包括：
- 面向连接：在传输数据前，通信双方必须先建立传输连接，传输结束后必须释放连接。
- 点对点通信：一条 TCP 连接只能有两个端点（Socket），不支持广播或多播。
- 高可靠性：保证数据无差错、不丢失、不重复、且按序到达。
- 全双工通信：连接双方在任何时刻都可以同时发送和接收数据，各自拥有独立的发送与接收缓冲区。
- 面向字节流：将应用层交下来的数据块仅视为无结构的字节序列，通过拆分或组合成报文段（Segment）进行传输。
首部结构
TCP 报文段由 TCP 首部 和 数据载荷（Payload） 组成。默认固定首部长度为 20 字节（可通过选项扩展至 60 字节）。
核心字段含义
| 字段名称 | 位数 | 作用与说明 |
|---|---|---|
| 源端口 / 目的端口 | 各 16 位 | 标识发送方与接收方的应用进程 |
| 序号 (Sequence Number) | 32 位 | 本报文段所发送数据的首个字节的编号，用于解决乱序问题 |
| 确认号 (Acknowledgment Number) | 32 位 | 期望收到对方下一个报文段的首字节编号，表明该编号之前的数据已全部成功接收 |
| 数据偏移 (Data Offset) | 4 位 | 指示 TCP 首部的实际长度（以 4 字节为单位计算） |
| 控制标志位 (Flags) | 6 位 | 包含 URG、ACK、PSH、RST、SYN、FIN，用于控制连接状态 |
| 窗口大小 (Window Size) | 16 位 | 告知对方本端接收缓冲区的剩余空间，用于流量控制 |
| 校验和 (Checksum) | 16 位 | 涵盖首部和数据的端到端差错校验 |
关键标志位
- SYN (Synchronize)：同步序号，用于在建立连接时同步初始序号（ISN）。
- ACK (Acknowledgment)：确认指示，当 ACK=1 时确认号字段有效。
- FIN (Finish)：终止指示，用于释放连接，表明发送方数据已发送完毕。
- RST (Reset)：复位指示，用于强制断开异常连接或拒绝非法请求。
连接管理
TCP 连接的生命周期包括连接建立（三次握手）、数据传输与连接释放（四次挥手）。
三次握手@
建立连接的过程旨在确认双方的发送与接收能力正常，并同步初始序列号（ISN）。
第一次握手（SYN）：
客户端发送
SYN=1，随机生成初始序号seq=x，进入SYN-SENT状态。第二次握手（SYN + ACK）：
服务端收到后，回应
SYN=1, ACK=1，设置ack=x+1，并随机生成自己的初始序号seq=y，进入SYN-RCVD状态。第三次握手（ACK）：
客户端收到响应，发送
ACK=1，设置ack=y+1，进入ESTABLISHED状态。服务端收到后也进入ESTABLISHED状态，连接成功建立。
为什么必须是三次握手？
- 防止历史重复连接的初始化：避免因网络延迟滞留的旧 SYN 包到达服务端而错误建立连接。
- 同步双向序列号：确保双方都能明确确认对方已成功接收到自己的初始序列号。
四次挥手@
由于 TCP 是全双工的，每个方向的连接需要单独关闭，因此释放连接需要进行四次交互。
第一次挥手（FIN）：
主动关闭方发送
FIN=1（seq=u），停止发送数据，进入FIN-WAIT-1状态。第二次挥手（ACK）：
被动关闭方收到后回应
ACK=1（ack=u+1），进入CLOSE-WAIT状态。此时主动方到被动方的方向已关闭，但被动方仍可继续发送未传完的数据。第三次挥手（FIN）：
被动关闭方数据发送完毕后，发送
FIN=1, ACK=1（seq=w），进入LAST-ACK状态。第四次挥手（ACK）：
主动关闭方回应
ACK=1（ack=w+1），进入TIME-WAIT状态。经过 2MSL（最大报文生存时间）后彻底关闭连接；被动关闭方收到 ACK 后直接进入CLOSED状态。
TIME-WAIT 状态等待 2MSL 的原因：
- 确保最后的 ACK 报文能够送达被动方（若丢失，被动方会重发 FIN）。
- 让本连接持续时间内产生的所有报文段从网络中彻底消失，避免影响后续的新连接。
TCP 连接完整生命周期@
可靠传输
TCP 为了保证数据传输的绝对可靠，在底层实现了多重保障机制：
序号与确认机制
TCP 给每个字节编上序号。接收方收到数据后回应累计确认（Cumulative ACK），告诉发送方“序号在 之前的数据都已经收到，请发送序号为 及以后的数据”。
重传机制
- 超时重传（RTO）：发送方发出报文后启动定时器，若在重传超时时间（RTO）内未收到 ACK，则重新发送该报文段。RTO 根据网络动态变化的往返时间（RTT）自适应调整。
- 快速重传（Fast Retransmit）：当接收方发现数据中间有空缺时，后续收到数据会连续发送相同确认号的冗余 ACK。发送方若连续收到 3 个重复的 ACK，会触发快速重传，无需等待重传定时器超时。
滑动窗口机制
如果不使用窗口，发送方必须发送一个数据包并等待确认后再发下一个，效率极低。
滑动窗口允许发送方在未经确认的情况下连续发送多个报文段（受窗口大小限制），显著提高了信道利用率。
流量与拥塞
TCP 通过流量控制保护接收端，通过拥塞控制保护网络通道。
流量控制
- 目的：防止发送方发送数据过快，导致接收方缓冲区溢出。
- 实现原理：接收方在 ACK 报文中携带自身的接收窗口大小（rwnd）。发送方根据 rwnd 动态调整发送窗口大小，当 rwnd 变为 0 时，发送方停止发送，直至收到窗口更新通知。
拥塞控制
- 目的：防止过多数据注入网络导致路由器或链路过载拥塞。
- 实现原理：发送方维护一个拥塞窗口（cwnd），实际发送窗口大小取
Min(rwnd, cwnd)。
拥塞控制包含四个核心算法：
慢启动（Slow Start）：连接建立初期，cwnd 从较小值开始以指数级增长，快速探测网络容量。
拥塞避免（Congestion Avoidance）：当 cwnd 达到慢启动门限（ssthresh）后，改为线性加法增长（加性增大）。
快重传（Fast Retransmit）：收到 3 个重复 ACK 时触发，不等待超时直接重传缺失报文。
快恢复（Fast Recovery）：发生快重传后，将 ssthresh 减半，并设置
cwnd = ssthresh直接进入拥塞避免阶段（乘性减小），避免 cwnd 降回 1。
UDP 协议~
UDP（User Datagram Protocol，用户数据报协议） 是 TCP/IP 协议族中核心的传输层协议之一。它提供了一种无连接、不可靠但极具效率的数据传输服务。
协议概述
UDP 的核心设计理念是精简：它仅在 IP 协议的基础上增加了端口复用/分用以及基础的差错校验功能，几乎不引入额外的控制开销。
- 无连接：发送数据前不需要建立连接，减少了往返时延（RTT）。
- 轻量级：首部字段很少，处理逻辑简单，资源占用低。
- 尽力而为：网络尽最大努力交付数据，但不对数据的完整性、顺序与丢包作保证。
首部结构
与 TCP 复杂的 20 字节（或更多）首部不同，UDP 报文头部的结构极其轻量，固定仅占用 8 个字节。
报文格式：
| 字段名称 | 占用位数 | 作用与说明 |
|---|---|---|
| 源端口号 (Source Port) | 16 位 | 发送方应用进程的端口号（可选，若不需要回复可填 0） |
| 目的端口号 (Destination Port) | 16 位 | 接收方应用进程的端口号 |
| UDP 长度 (Length) | 16 位 | 包含 UDP 首部和数据载荷的总字节数（最小值为 8） |
| 校验和 (Checksum) | 16 位 | 检测 UDP 首部与数据在传输过程中是否发生比特错误 |
伪首部与校验和：在计算校验和时，UDP 会在报文前临时加上 12 字节的“伪首部”（包含源 IP、目的 IP、协议类型等字段）。伪首部仅用于校验计算，并不在网络中传输，主要用于防止数据包被错误送达主机。
核心特性
UDP 的特性源于其简单无状态的设计：
特性1：无连接与低延迟
发送数据前不需要像 TCP 那样进行“三次握手”建立连接，传输结束后也无需“四次挥手”释放连接。数据一旦产生即可立即打包发送，没有建立连接的延迟。
特性2：面向报文
UDP 对应用层交付的报文既不合并，也不拆分，而是保留报文边界。应用层给 UDP 多长的报文，UDP 就照样加上首部发送。因此，UDP 协议不存在 TCP 中的粘包与拆包问题。
特性3：不保证可靠交付
- 无确认重传：不使用 ACK 确认机制，数据包丢失不会重传。
- 无按序到达：数据包可能因网络路由不同而发生乱序，UDP 不会重新排序。
- 无拥塞与流量控制：不会根据网络拥塞情况或接收端缓冲区容量降低发送速率，发端可以按照固定速率持续发送数据。
特性4：天然支持多播与广播
TCP 仅支持一对一的点对点通信，而 UDP 可以利用 IP 层的多播和广播能力，实现一对多（广播）、多对多（组播）的高效数据分发。
UDP 与 TCP 对比
| 维度 | UDP 协议 | TCP 协议 |
|---|---|---|
| 连接状态 | 无连接 | 面向连接（需三次握手） |
| 可靠性 | 不可靠（可能丢包、乱序、重复） | 绝对可靠（按序、无误、无丢包） |
| 传输模式 | 面向报文（保留报文边界） | 面向字节流（无边界，存在粘包） |
| 首部开销 | 8 字节（固定） | 20 ~ 60 字节 |
| 传输效率 | 极高，延迟低，资源开销少 | 较低，受握手、重传与拥塞控制限制 |
| 通信方式 | 支持单播、多播、广播 | 仅支持一对一点对点单播 |
应用场景
凭借高吞吐、低延迟的优势，UDP 广泛应用于对实时性要求极高、或能容忍少量丢包的业务场景：
场景1：实时音视频通信
在视频会议（Zoom、腾讯会议）、实时语音（Discord）和直播传输中，偶发的像素丢失或音质微损伤不影响大局，但超过几百毫秒的延迟会直接破坏互动体验。
场景2：在线竞技游戏
FPS（如 CS:GO）、MOBA（如王者荣耀）等实时游戏，需要以每秒几十次的频率同步玩家位置和状态。丢弃一两个历史位置数据包不影响游戏运行，最新的位置数据才是关键。
场景3：基础设施与基础服务
- DNS (域名解析)：采用 UDP 53 端口，单次查询只需一发一收，避免握手开销。
- DHCP (动态主机配置)：利用 UDP 广播在局域网内分配 IP 地址。
- NTP (网络时间协议)：使用 UDP 进行精确的时间同步。
场景4：现代化协议演进 (QUIC / HTTP/3)
由于传统 TCP 存在队头阻塞（Head-of-Line Blocking）和握手延迟问题，现代互联网协议（如 HTTP/3 底层的 QUIC 协议）转而基于 UDP 构建。通过在应用层重新实现可靠传输、拥塞控制与 TLS 1.3 加密，结合了 UDP 的高效与 TCP 的可靠。