Java IO——网络IO
本文最后更新于:2 分钟前
引言
网络 IO (Network IO) 是分布式系统和互联网应用的基础。在 Java 生态中,从最初的 Socket
/ ServerSocket
(阻塞式 BIO)到基于 Selector
的 NIO、再到 AIO(异步 IO)和高性能框架 Netty,都为不同规模的网络应用提供了丰富的选择。本文将介绍 Java 网络编程中常见的 TCP/UDP 套接字用法,并进一步探讨在高并发场景下广泛应用的Netty框架和零拷贝技术。
简介
网络IO(Network IO)指的是计算机通过网络进行数据传输的输入与输出操作,通常基于 Socket(套接字)进行通信。Socket是操作系统提供的编程接口(API),用于在不同设备或进程间建立网络连接,并进行数据收发。
网络 IO 模式
网络IO可以分为不同的模式:
- 阻塞 IO(BIO, Blocking IO)
- 服务器为每个客户端维护一个线程,适用于连接数较少的场景。
- 典型实现:
ServerSocket
和Socket
。
- 非阻塞 IO(NIO, Non-blocking IO)
- 采用多路复用(Selector),可以管理多个Socket连接,提高性能。
- 适用于高并发场景,如 Netty 框架。
- 异步 IO(AIO, Asynchronous IO)
- 使用回调机制,完全异步非阻塞,适用于高吞吐需求的应用。
Socket 与 ServerSocket
Socket 通信模型
基于Socket的网络IO通信模型一般包含以下几个关键步骤:
- 服务器端
- 创建Socket(
ServerSocket
)。 - 绑定端口,监听客户端连接。
- 等待客户端连接(
accept()
)。 - 读取/发送数据(
InputStream
/OutputStream
)。 - 关闭连接。
- 创建Socket(
- 客户端
- 创建Socket并连接服务器(
Socket
)。 - 发送/接收数据。
- 关闭连接。
- 创建Socket并连接服务器(
在 Java 中,Socket
和 ServerSocket
主要用于基于 TCP 协议的网络通信。ServerSocket
用于服务器端监听连接,Socket
用于客户端与服务器端通信。
ServerSocket(服务器端)
ServerSocket
主要用于监听客户端的连接请求,一旦接受连接,它会返回一个新的 Socket
实例与客户端进行通信。
主要方法
方法 | 作用 |
---|---|
ServerSocket(int port) |
创建绑定到指定端口的服务器套接字 |
accept() |
监听并接受客户端连接(阻塞式) |
close() |
关闭服务器套接字 |
setSoTimeout(int timeout) |
设置 accept() 方法的超时时间 |
getInetAddress() |
获取服务器的 IP 地址 |
getLocalPort() |
获取服务器监听的端口号 |
代码示例
1 |
|
说明
ServerSocket
监听端口8080
,等待客户端连接。- 每个连接由一个独立的线程处理,读取数据并回传给客户端。
Socket(客户端)
Socket
负责建立连接并进行数据收发。
主要方法
方法 | 作用 |
---|---|
Socket(String host, int port) |
连接到指定主机和端口 |
getInputStream() |
获取输入流(接收数据) |
getOutputStream() |
获取输出流(发送数据) |
close() |
关闭套接字 |
getInetAddress() |
获取远程服务器的 IP 地址 |
setSoTimeout(int timeout) |
设置读取数据的超时时间 |
代码示例
1 |
|
说明
- 连接服务器
127.0.0.1:8080
。 - 通过
BufferedWriter
发送消息,读取服务器的响应。
运行流程
运行服务器:先启动
SimpleServer
,服务器会监听8080
端口,等待客户端连接。运行客户端:启动
SimpleClient
,成功连接服务器后,可以在终端输入消息。服务器收到消息后,会原样返回。示例交互:
服务器启动:
1
服务器启动,监听端口:8080
客户端启动:
1
已连接到服务器 127.0.0.1:8080
服务器连接成功:
1
客户端连接:/127.0.0.1
客户端发送消息:
1
2已连接到服务器 127.0.0.1:8080
hello服务器收到消息并自动响应:
1
2
3服务器启动,监听端口:8080
客户端连接:/127.0.0.1
收到客户端消息: hello客户端接收到服务器的响应:
1
2
3已连接到服务器 127.0.0.1:8080
hello
服务器回复: 服务端回复: hello
底层原理
TCP 通信特性
- 面向连接:必须先建立连接(三次握手)。
- 可靠传输:数据按序到达,无丢失(超时重传、流量控制、拥塞控制)。
- 流式传输:数据以字节流方式传输,接收端需要解析数据边界。
TCP 底层实现
TCP 的底层基于操作系统内核协议栈完成数据传输,主要包括:
三次握手建立连接,当
Socket
进行connect()
时,操作系统会执行 TCP 三次握手,过程如下:- 客户端发送
SYN
包给服务器,请求建立连接。 - 服务器返回
SYN + ACK
,表示接受连接请求。 - 客户端回复
ACK
,完成握手,连接建立。
三次握手后,
Socket
连接才真正建立,之后可以进行数据传输。- 客户端发送
数据传输:
TCP 使用滑动窗口和 ACK 确认机制保证数据可靠性。
TCP 会对数据进行分片和重组(MSS),并处理乱序、丢失的数据包(重传机制)。
关闭连接(四次挥手),当
Socket
关闭时,会执行 TCP 四次挥手:- 客户端发送
FIN
,请求断开连接。 - 服务器返回
ACK
,表示收到请求。 - 服务器发送
FIN
,请求关闭连接。 - 客户端发送
ACK
,确认关闭。
四次挥手完成后,操作系统释放
Socket
相关资源。- 客户端发送
DatagramSocket
DatagramSocket(UDP 套接字)
DatagramSocket
用于在发送端和接收端创建 UDP 连接。
- 发送方用于发送
DatagramPacket
。 - 接收方用于接收
DatagramPacket
。
主要方法
方法 | 作用 |
---|---|
DatagramSocket() |
创建默认端口的 UDP 套接字 |
DatagramSocket(int port) |
绑定指定端口的 UDP 套接字 |
send(DatagramPacket p) |
发送数据包 |
receive(DatagramPacket p) |
接收数据包(阻塞等待) |
setSoTimeout(int timeout) |
设置接收超时时间 |
close() |
关闭套接字 |
DatagramPacket(UDP 数据包)
DatagramPacket
用于封装要发送和接收的数据。
- 发送方:指定目标地址、端口、数据内容。
- 接收方:用于存储接收到的数据。
构造方法:
方法 | 作用 |
---|---|
DatagramPacket(byte[] buf, int length, InetAddress address, int port) |
创建用于发送的 UDP 数据包 |
DatagramPacket(byte[] buf, int length) |
创建用于接收的 UDP 数据包 |
代码示例
UDP 是无连接的,因此不需要像 TCP 那样建立 Socket
连接。下面是一个 UDP 通信的完整示例,包括服务器端(接收)和客户端(发送)。
UDP 服务器端
1 |
|
说明:
- 服务器创建
DatagramSocket
监听8080
端口。 - 通过
socket.receive(packet)
接收 UDP 数据包(阻塞等待)。 - 解析
packet.getData()
获取消息内容。 - 服务器收到消息后,使用
socket.send(responsePacket)
发送回复消息。
UDP 客户端
1 |
|
说明:
- 客户端创建
DatagramSocket
用于发送数据包。 - 通过
DatagramPacket
发送数据到127.0.0.1:8080
服务器端。 - 发送后,阻塞等待服务器的响应并打印出来。
运行流程
运行服务器:先启动
UDPServer
,服务器会在8080
端口监听 UDP 数据包,等待客户端连接。运行客户端:启动
UDPClient
,成功连接服务器后,可以在终端输入消息。服务器收到消息后,会原样返回。示例交互:
服务器启动:
1
UDP 服务器已启动,监听端口:8080
客户端启动连接。
服务器连接成功。
客户端发送消息:
1
请输入消息: hello
服务器收到消息并自动响应:
1
2UDP 服务器已启动,监听端口:8080
收到消息: hello 来自 /127.0.0.1:56379客户端接收到服务器的响应:
1
2
3请输入消息: hello
服务器回复: 服务器已收到:hello
请输入消息:
底层原理
UDP 通信特性
- 无连接:数据直接发送,无需建立连接。
- 不可靠:不保证数据到达、顺序,也不处理丢包。
- 面向数据报:UDP 以数据报(
DatagramPacket
)的方式发送和接收。
UDP 底层实现
UDP 依赖 IP 层+UDP 协议进行数据传输,主要流程如下:
发送数据
用户数据封装成
DatagramPacket
(包括数据、目标 IP/端口)。UDP
协议在数据前面添加 UDP 头部(源端口、目标端口、长度、校验和)。IP
层负责查找路由,将数据发送到目标主机。
UDP 头部只有 8 字节,比 TCP 小很多,传输效率更高。
接收数据:
操作系统监听 UDP 端口,接收符合条件的数据报文。
UDP 解析数据报头,去掉 UDP 头部后,将数据传递给应用层。
UDP 不会自动重传丢失数据,应用层需要自己实现超时重传机制。
Socket 模型对比
对比项 | TCP(Socket ) |
UDP(DatagramSocket ) |
---|---|---|
是否连接 | 需要建立连接(三次握手) | 无连接,直接发送 |
可靠性 | 可靠,保证数据到达、顺序、完整性 | 不可靠,可能丢包、乱序 |
传输方式 | 面向流,按字节流传输 | 面向数据报,每个 DatagramPacket 是独立数据 |
头部大小 | 20-60 字节(TCP 头部) | 8 字节(UDP 头部) |
速度 | 较慢(有流控和拥塞控制) | 快(无流控、无握手) |
适用场景 | 文件传输、Web 服务、数据库连接 | 直播、语音通话、游戏 |
DatagramSocket
用于 UDP 通信,无需建立连接,适用于高速数据传输。DatagramPacket
封装 UDP 数据,可用于发送或接收数据包。- UDP 适用于实时性高、对数据完整性要求不高的场景,如:
- 视频直播
- 语音通话
- 在线游戏
- IoT 设备通信
高性能网络框架 Netty
简介
Netty 是基于 Java NIO(非阻塞 IO) 开发的异步、高性能、事件驱动的网络通信框架,广泛用于高并发的网络应用,如 IM、RPC、网关、游戏服务器等。具有如下特性:
- 原生 NIO 复杂(如
Selector
、ByteBuffer
、多线程管理) - Netty 封装了 NIO,提供高效、简洁的 API
- 适用于 TCP、UDP、WebSocket 等多种协议
底层架构
Netty 的核心架构包括:
- Bootstrap & ServerBootstrap(启动器)
- EventLoopGroup(事件循环线程组)
- Channel & ChannelPipeline(通道 & 处理管道)
- ChannelHandler(事件处理器)
- ByteBuf(高效数据缓冲区)
核心组件解析
Bootstrap / ServerBootstrap
Bootstrap
:用于客户端启动 Netty。ServerBootstrap
:用于服务器端启动 Netty。
EventLoopGroup(事件循环组)
BossGroup
:处理客户端连接。WorkerGroup
:处理具体数据读写。- 每个 EventLoop 绑定一个
Selector
,监听 Channel 事件(如 read、write)。
Channel(通道)
- 封装底层
SocketChannel
,用于数据读写。
ChannelPipeline(处理管道)
- 多个
ChannelHandler
组成的责任链,依次处理数据。 - 事件流转:
Inbound(入站)
→Outbound(出站)
。
ChannelHandler(事件处理器)
- 入站处理器(处理读事件)
- 出站处理器(处理写事件)
1 |
|
Netty 服务器端代码
1 |
|
Netty 客户端代码
1 |
|
Netty VS 原生 NIO
对比项 | Netty | Java NIO |
---|---|---|
API 简洁性 | 封装好,使用简单 | 复杂,需要手动管理 |
线程管理 | 自动优化 EventLoopGroup |
需手动创建 Selector 、ThreadPool |
数据处理 | ByteBuf 更高效 |
ByteBuffer 操作繁琐 |
支持协议 | TCP、UDP、WebSocket、HTTP | 仅支持 TCP/UDP |
扩展性 | 支持插件、拦截器、编解码器 | 需手写业务逻辑 |
适用场景
- IM 即时通讯(如微信、QQ、聊天室)
- RPC 远程调用(Dubbo、gRPC)
- 网关、代理服务器(如 Nginx、Kong)
- 游戏服务器(高并发,低延迟)
- 高性能 WebSocket 应用
零拷贝
定义
在传统的 IO 模型中,数据通常需要在用户空间和内核空间之间多次拷贝。例如,从磁盘读取数据到内核空间,然后再将其拷贝到用户空间,接着再从用户空间拷贝回内核空间,最后才发送到网络或写入到另一个文件。这种反复拷贝过程会带来额外的 CPU 开销和内存带宽消耗。
零拷贝(Zero Copy)技术通过利用操作系统(OS)的底层支持,将数据在文件(或其他数据源)与网络或另一数据目标之间直接在内核空间完成传输,从而省去或减少不必要的用户态-内核态数据拷贝。零拷贝并不是绝对 “零”,而是指对用户态来说不再进行额外拷贝,极大地减少了数据在用户空间与内核空间之间的来回移动。
机制
FileChannel 的 transferTo / transferFrom
在 Java 的 NIO 中,FileChannel
提供了两个方法来支持零拷贝式的数据传输:
transferTo(long position, long count, WritableByteChannel target)
- 可以将当前文件通道的数据直接传输到目标通道(比如网络通道或另一个文件通道)。
- 底层可能调用操作系统的
sendfile
等本地方法,避免了用户空间的拷贝。
transferFrom(ReadableByteChannel src, long position, long count)
- 与
transferTo
相反,将数据从可读通道直接传输到当前文件通道。
- 与
工作原理:
- 如果操作系统及其底层驱动支持 “零拷贝” 功能(如 Linux 的
sendfile()
系统调用),Java NIO 就能利用这些系统调用将数据直接从文件通道拷贝到网络或另一个文件通道的内核缓冲区。 - 这样做的好处是:数据并不会再返回到 Java 用户态中,从而显著降低了 CPU 消耗和内存带宽的占用。
MappedByteBuffer 与内存映射文件
在 Java NIO 中,还可以使用 MappedByteBuffer
(通过 FileChannel.map
方法)将文件直接映射到内存中,这也是一种 “零拷贝” 的思想体现。
- 当文件被映射到内存之后,就可以像操作内存数组一样对文件进行读写,而实际上读写的过程由操作系统负责将磁盘数据加载到内存(往往使用分页和缓存)。
- 对于大文件,操作系统会根据需要分段将数据加载到内存,且会使用缺页中断技术实现部分加载;对文件的写操作也可以 “懒加载” 或 “延时写回”。
- 这样也避免了传统 IO 对文件内容进行多次复制,有助于提升 IO 性能。
需要注意的是,MappedByteBuffer
常用于大文件或随机读写场景,且要留意可能出现的 “直接内存” 占用过大或文件锁问题。
底层原理
以 Linux 平台为例,在使用零拷贝进行文件到网络的传输时,一般会调用操作系统的 sendfile()
或者更先进的 splice()
、sendfile64()
之类的系统调用,整体流程可以概括如下:
内核读取文件页缓存:
当需要将文件数据发送到网络时,操作系统首先会将文件对应的磁盘数据读入到内核空间的页缓存(page cache)中(如果先前还没在缓存里)。
直接将内核缓存数据传送到 Socket 缓冲区:
通过零拷贝方法(如
sendfile()
),文件数据不需要再拷贝到用户空间,而是直接在内核态将数据从页缓存复制(或映射)到 Socket 缓冲区。DMA(Direct Memory Access)驱动的数据发送:
网络接口卡(NIC)在发送数据时,会由 DMA 控制器直接从 Socket 缓冲区中读取数据并发送到网络上,这一步也不需要 CPU 参与数据拷贝。
整个过程中,CPU 不再需要进行数据的用户态/内核态切换拷贝,大幅减少了复制开销。
对比传统网络 IO
传统 Socket 发送文件流程
当应用使用 read()
读取磁盘文件并通过 Socket
发送时,数据会经历多个拷贝:
sequenceDiagram
autonumber
participant 应用层
participant 用户态缓冲区
participant 内核态缓冲区
participant 磁盘
participant 网卡
rect rgb(255, 204, 204)
应用层->>磁盘: read()
磁盘-->>内核态缓冲区: DMA拷贝(磁盘->内核)
内核态缓冲区-->>用户态缓冲区: CPU拷贝(内核->用户)
用户态缓冲区-->>内核态缓冲区: CPU拷贝(用户->内核)
内核态缓冲区-->>网卡: DMA拷贝(内核->网卡)
end
read()
:数据从磁盘拷贝到内核缓冲区(Page Cache)(DMA 拷贝)。- 拷贝到用户态:数据从内核缓冲区拷贝到用户缓冲区(CPU 拷贝)。
write()
:用户缓冲区数据拷贝回内核 Socket 缓冲区(CPU 拷贝)。- 数据发送:数据从 Socket 缓冲区拷贝到网卡缓冲区(DMA 拷贝)。
问题:有 4 次数据拷贝,其中 2 次 CPU 拷贝(用户态 ⇄ 内核态)会造成 CPU 额外开销。
零拷贝 sendfile() 方式
sendfile()
是 Linux 提供的零拷贝系统调用,用于高效传输文件:
sequenceDiagram
autonumber
participant 应用层
participant 用户态缓冲区
participant 内核态缓冲区
participant 磁盘
participant 网卡
rect rgb(204, 255, 204)
磁盘-->>内核态缓冲区: DMA拷贝(磁盘->内核)
内核态缓冲区-->>网卡: DMA拷贝(内核->网卡)
end
sendfile(fd, socket, offset, length)
直接让内核缓冲区数据通过 DMA 传输送到 Socket 缓冲区。- 数据直接传输到网卡,不进入用户态,减少 CPU 参与。
优势:
- 少了 CPU 拷贝(不进入用户态),极大地减少了 CPU 消耗。
- 适用于大文件传输,如文件服务器、Web 服务器。
更高级的 mmap + sendfile(splice 技术)
Linux 2.6 之后,提供了 mmap + sendfile()
或 splice()
:
mmap()
:将文件映射到用户态虚拟地址空间,避免read()
时拷贝到用户态。sendfile()
或splice()
:直接从 Page Cache 传输到 Socket 缓冲区。
这样,数据只在内核中流转,不需要进入用户态,大大提高高吞吐场景 的性能。
Java Netty 零拷贝
Netty 广泛使用零拷贝技术,以下是 Netty 相关的零拷贝机制:
Netty FileRegion 实现零拷贝
在 Netty 服务器中,可以使用 DefaultFileRegion
直接将文件数据传输到 SocketChannel
,避免数据进入用户态:
1 |
|
原理:直接调用 sendfile()
发送数据,不经过 ByteBuf
,避免数据拷贝,提高效率。
Netty ByteBuf 的零拷贝
Netty 通过 ByteBuf
优化数据存储,减少拷贝:
CompositeByteBuf
(组合缓冲区):多个ByteBuf
共享数据,避免byte[]
拷贝。slice()
(数据切片):共享数据,而不是复制数据。DirectByteBuf
(直接缓冲区):绕过 JVM 堆,直接使用ByteBuffer.allocateDirect()
进行零拷贝。
1 |
|
优势:
- 减少
byte[]
数组拷贝 - 直接使用 NIO
ByteBuffer
,减少 Java 堆 GC 开销 - 高效的网络数据处理
优势与适用场景
优势
减少数据拷贝次数:
传统 IO 模型需要多次在用户态和内核态之间进行数据拷贝,而零拷贝大幅减少了这些拷贝次数。
降低 CPU 占用:
由于减少了内核态-用户态的拷贝操作,CPU 不再需要消耗额外的计算资源来进行大规模的数据搬运。
提高数据吞吐量:
减少拷贝与减少 CPU 开销相结合,可以提升整体吞吐量。对于大文件传输或高并发场景,性能改进尤其明显。
典型适用场景
文件服务器或大文件传输:
比如实现一个高效的文件下载服务器,把本地磁盘文件通过网络 Socket 发给客户端,这时可以使用
FileChannel.transferTo()
实现高效的零拷贝传输。Log 传输 / 实时流媒体:
对于需要快速推送大批量数据的日志系统或流媒体服务器,也可以利用零拷贝来减少负载。
高并发、高吞吐网络应用:
在 Netty 等高性能网络框架中,也常常依赖操作系统底层的零拷贝机制来提升 IO 性能。
注意事项
操作系统及硬件支持:
零拷贝通常依赖底层操作系统(如 Linux)的特定系统调用,以及硬件(如 NIC)对 DMA 的支持,不同操作系统上的实现和限制可能有所不同。
在某些情况下仍有拷贝:
- 如果要对数据进行修改或处理(比如加密、压缩、数据格式转换等),那必须由用户态程序拿到数据再进行操作,这时就无法完全规避拷贝。
- 如果数据目标通道不支持零拷贝特性,也可能会退回到传统方式传输。
transferTo 和 transferFrom 可能会有大小限制:
在一些操作系统版本或某些 JDK 实现中,对可传输的字节数有一定限制,需要分段传输大文件。
MappedByteBuffer 占用直接内存:
映射文件时操作系统会分配 “直接内存”,如果映射文件非常大或未及时释放,可能造成内存紧张甚至
OutOfMemoryError
。
总结
Java 网络编程既可以使用阻塞 IO(BIO)搭配 Socket
/ ServerSocket
来编写简单直接的服务端与客户端,也能借助 NIO(非阻塞 IO)和 Selector
实现单线程管理多连接的高并发模型。对于需要更强性能、可扩展性的场景,如即时通讯、大规模并发连接或实时数据传输,Netty 框架提供了事件驱动、线程池分工以及强大的编解码处理能力,让网络开发更高效。
此外,零拷贝技术与 Netty 的 FileRegion
、ByteBuf
等特性更是通过操作系统底层优化极大降低了复制开销,进一步提高了吞吐量。在选择合适的网络 IO 模型时,应结合应用需求(延迟、吞吐、并发数、数据可靠性等)进行权衡,从而在正确的场景下用合适的技术发挥最大的效能。
本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!