🔭 嗨,您好 👋 我是 vnjohn,在互联网企业担任 Java 开发,CSDN 优质创作者
📖 推荐专栏:Spring、MySQL、Nacos、Java,后续其他专栏会持续优化更新迭代
🌲文章所在专栏:网络 I/O
🤔 我当前正在学习微服务领域、云原生领域、消息中间件等架构、原理知识
💬 向我询问任何您想要的东西,ID:vnjohn
🔥觉得博主文章写的还 OK,能够帮助到您的,感谢三连支持博客🙏
😄 代词: vnjohn
⚡ 有趣的事实:音乐、跑步、电影、游戏
目录
前言
Unix/Linux 下可用的 I/O 模型有以下五种:
- 阻塞式 I/O
- 非阻塞式 I/O
- I/O 复用(select、poll)
- 信号驱动式 I/O(SIGIO)
- 异步 I/O
在 Linux 中操作内核时,所有的无非三种操作,分别是输入、输出、报错输出
0-输入
1-输出
2-报错输出
一个输入操作通常包括两个不同的阶段:
- 等待数据准备好
- 从内核向进程复制数据
对于一个套接字(Socket)的输入操作,第一步通常涉及等待数据从网络中;当所等待分组到达时,它被复制到内核中的某个缓冲区,第二步就是把数据从内核缓冲区复制到应用进程缓冲区
非阻塞式 I/O 模型
进程把一个套接字设置成非阻塞是在通知内核:当所请求的 I/O 操作非得把本进程投入睡眠才能完成时,不要把本进程投入睡眠,而是返回一个错误
前三次调用 recvfrom 时没有数据可返回,因此内核转而立即返回一个 EWOULDBLOCK
错误;第四次调用 recvfrom 时已有一个数据报准备好,它被复制到应用进程缓冲区,于是 recvfrom 成功返回,接着处理数据
EWOULDBLOCK:E 是 Error,WOULD BLOCK 是可能会被阻塞的意思
表示当前没有数据可读或没有缓冲区可写,需要等待下一次读写事件再尝试读写,非阻塞模式下可以继续尝试读写
当一个应用进程像这样对一个非阻塞描述符,循环调用 recvfrom 时,我们称之为轮询(Polling);应用进程持续轮询内核,以查看某个操作是否就绪;这么做往往耗费大量 CPU 时间,不过这种模型偶尔也会遇到,通常是在专门提供某一种功能的系统中才有.
图解分析
- 当有新的连接进来时,主线程负责执行 accept 连接客户端,clone 出一个子进程新的 sockfd 去 accept/read,等待其他客户端连接时是非阻塞的,读取客户端数据也是非阻塞的,只是返回给客户端是 EWOULDBLOCK 状态
- NIO 采用的处理方式:主线程阻塞去等待客户端连接,以非阻塞的方式为每个客户端读取数据
NIO 核心的参数设置:configureBlocking(false)
源码实践
Socket 服务端代码
package org.vnjohn.nio.server;
import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.ServerSocketChannel;
import java.nio.channels.SocketChannel;
import java.util.LinkedList;
/**
* @author vnjohn
* @since 2023/12/2
*/
public class SocketNIOServer {
public static void main(String[] args) throws Exception {
// 链表集合存放所有的 socket client 实例
LinkedList<SocketChannel> clients = new LinkedList<>();
// 服务端开启监听:接受客户端
ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();
serverSocketChannel.bind(new InetSocketAddress(8090));
// serverSocketChannel.configureBlocking(true);
// OS NONBLOCKING 只让接受客户端并不阻塞
serverSocketChannel.configureBlocking(false);
System.out.println("step1: new ServerSocketChannel(8090)");
while (true) {
// 接受客户端的连接
Thread.sleep(1000);
// 不会阻塞
// 在操作系统中返回:-1,在 Java 程序中返回 NULL
SocketChannel socketChannel = serverSocketChannel.accept();
// accept 调用内核:
// 1、没有客户端连接进来,返回值:在 BIO 时一直卡/阻塞着,但是在 NIO ,不卡着,返回 -1,NULL
// 如果来客户端的连接,accept 返回的是这个客户端的 fd5
if (socketChannel == null) {
System.out.println(".....");
} else {
// 服务端 listen socket <连接请求三次握手后,通过 accept 得到连接的 sockfd>,连接 socket <连接后读写使用>
socketChannel.configureBlocking(false);
int port = socketChannel.socket().getPort();
System.out.println("step2:client\t" + port);
clients.add(socketChannel);
}
// 堆内:allocate -> HeapByteBuffer
// 堆外:allocateDirect -> DirectByteBuffer
ByteBuffer buffer = ByteBuffer.allocateDirect(4096);
// 遍历已经链接进来的客户端读写数据
// 这里采用串行化的方式进行接收,可以更改为采用 BIO 方式,一个客户端抛出一个线程进行接收处理
for (SocketChannel client : clients) {
// 不会阻塞,返回:> 0、-1、0
int num = client.read(buffer);
if (num > 0) {
buffer.flip();
byte[] bufferByte = new byte[buffer.limit()];
buffer.get(bufferByte);
String b = new String(bufferByte);
System.out.println(client.socket().getPort() + " : " + b);
buffer.clear();
}
}
}
}
}
Socket 客户端代码
package org.vnjohn.nio.client;
import java.io.*;
import java.net.Socket;
/**
* @author vnjohn
* @since 2023/12/2
*/
public class SocketNIOClient {
public static void main(String[] args) {
try {
Socket client = new Socket("172.16.249.10", 8090);
client.setSendBufferSize(20);
client.setTcpNoDelay(true);// false 优化,true 不优化
client.setOOBInline(false);
OutputStream out = client.getOutputStream();
InputStream in = System.in;
BufferedReader reader = new BufferedReader(new InputStreamReader(in));
while (true) {
String line = reader.readLine();
if (line != null) {
byte[] bb = line.getBytes();
for (byte b : bb) {
out.write(b);
}
}
}
} catch (IOException e) {
e.printStackTrace();
}
}
}
流程说明
172.16.249.10 是之前作为 node1 节点所在 IP
将以上两个 java 源文件上传到 node1 虚拟节点上,所在目录:/opt/java
1、在虚拟节点上安装好 Java 环境
2、将源文件所在的 package 包名,通过 vim 命令将 package 包名删除首行.
3、将 Java 源文件进行编译为 .class 文件 > javac SocketServer.java、javac SocketClient.java
configureBlocking
追踪应用程序与操作系统中的交互信息
cd /opt/java
strace -ff -o out java SocketNIOServer
正常的流程都是先 socket()、bind()、listen()、accept()
关于这四个函数的详细介绍可以阅读博主「网络 I/O」专栏中的另外一篇博文:
深入理解网络阻塞 I/O:BIO
先设置 configureBlocking = true,代表当前设置 SocketChannel 是阻塞式运行的
若设置 configureBlocking = true 时,观察追踪到操作系统的操作信息,能够详细看到我们的操作系统基于内核是一个阻塞态:
accept(4,:说明当前程序是阻塞运行的
再设置 configureBlocking = false,代表当前设置 SocketChannel 是非阻塞式运行的
accept(4, 0x7f8c0d4ee0, [28]) = -1 EAGAIN (Resource temporarily unavailable)
在操作系统侧,返回的是 -1,说明是非阻塞运行的
按照代码执行的逻辑来看,控制台会一直打印:…,说明当前 SocketChannel 是非阻塞运行的.
说明通过设置 configureBlocking = false 就可以实现不阻塞,若没有客户端进行连接在操作系统中返回的是 -1,而在 Java 中返回是 null
客户端连接
在 node2 节点:172.16.249.10,运行 SocketNIOClient 程序代码
1、移除首行 package 包名
2、cd /opt/java,编译 Java 源文件:javac SocketNIOClient.java
3、运行 Java 可执行程序:java SocketNIOClient
当客户端连接以后,就会在 out.pid 文件中分配一个文件描述符给到当前这个客户端,如下:
accept(4, {sa_family=AF_INET6, sin6_port=htons(32972), inet_pton(AF_INET6, “::ffff:172.16.249.11”, &sin6_a ddr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) =
5
当在客户端中发送数据时,比如:123456,在 out.pid 文件中会触发系统调用 R/W 读写
在 out.pid 文件中,会发现大量的 EAGAIN 字眼,代表当次资源暂不可用,这个操作可能等下次重试后可用
EAGAIN 官方定义:“Resource temporarily unavailable.” The call might work if you try again later. The macro EWOULDBLOCK is another name for EAGAIN; they are always the same in the GNU C Library.
EWOULDBLOCK 官方定义:“Operation would block.” In the GNU C Library, this is another name for EAGAIN (above). The values are always the same, on every operating system.
两者都代表含义是一样的,在 GUN C 库中,EWOULDBLOCK 的另外一个名称称之为 EAGAIN
C10K 问题
当 C10K 出现时,若有 1W 个客户端建立连接,在 BIO 时需要抛出 1W 个线程,此时就会造成资源消耗越多,任务调度就会变得越多,内核态用户态之间的切换也会越多
当在 NIO 时进行使用,在内核中又会出现另外一个问题,接着向下分析
源码
package org.vnjohn.nio.client;
import java.io.IOException;
import java.net.InetSocketAddress;
import java.nio.channels.SocketChannel;
import java.util.LinkedList;
/**
* @author vnjohn
* @since 2023/12/2
*/
public class C10KClient {
public static void main(String[] args) {
LinkedList<SocketChannel> clients = new LinkedList<>();
InetSocketAddress serverAddr = new InetSocketAddress("172.16.249.10", 8090);
// 端口号的问题:65535
for (int i = 10000; i < 25000; i++) {
try {
SocketChannel client = SocketChannel.open();
// 172.16.249.10:10000 172.16.249.10:8090
client.bind(new InetSocketAddress("1172.16.249.10", i));
client.connect(serverAddr);
clients.add(client);
} catch (IOException e) {
e.printStackTrace();
}
}
for (int i = 25000; i < 50000; i++) {
try {
SocketChannel client = SocketChannel.open();
// 172.16.249.10:25000 172.16.249.10:8090
client.bind(new InetSocketAddress("172.16.249.10", i));
client.connect(serverAddr);
clients.add(client);
} catch (IOException e) {
e.printStackTrace();
}
}
System.out.println("total clients:"+ clients.size());
try {
System.in.read();
} catch (IOException e) {
e.printStackTrace();
}
}
}
修改 SocketNIOServer 服务端代码,将两行代码注释
其目的是为了让服务端能够快速与客户端建立连接,而不是 1s 处理一个客户端连接,以便我们在 Linux 中来分析最大连接数
流程分析
1、先将 SocketNIOServer 休整的代码,重新编译执行:strace -ff -o out java SocketNIOServer
2、先 C10K 问题的客户端代码编译为 class 文件,然后通过 java 运行
3、接着观察几个情况
首先是观察 socket、TCP/IP 条目信息,可以看到有很多条类目,客户端->服务端之间的二元组信息「IP:端口」
观察服务端接收客户端连接的情况,是否保持正常
客户端在满足条件时,bind 客户端是处于正常状态的,而一旦超过了内核所配置的最大的大小以后,会发现会出现一个 Error 错误信息
java.net.SocketException: Too many open files
从异常信息上来看,意思是文件描述符超过了限制的大小.
错误排查
该错误是可以被修复的,但是修复了意义上不大,这种非阻塞运行的方式对内核这块的资源损耗还是很大的
java.net.SocketException: Too many open files
可打开的文件描述符大小是受内核配置的限制的,但它也是支持可配置的,查看命令:ulimit -a 或 ulimit -n
open files = 1024:一个进程最多可以打开 1024 个文件描述符
可通过 ulimit -SHn Xxx 命令来临时调整大小
- S:soft 软
- H:hard 硬
- n:文件描述符
调整后可以通过:ulimit -n 再查看修改后的大小
在内核中会根据上限的物理内存估算出一个总文件描述符大小
[root@node1 java]# cat /proc/sys/fs/file-max
146266
BIO vs NIO
套接字的默认状态是阻塞的,当你未设置参数 configureBlocking 时,这就意味着当发出一个不能立即完成的套接字调用时,其进程被投入睡眠状态,等待相应操作完成
阻塞的套接字函数调用
可能阻塞的套接字调用可分为以下四类:
- 输入操作,包括:read、readv、recv、recvfrom、recvmsg 五个函数
既然 TCP 是字节流协议,该进程的唤醒只要有一些数据到达,这些数据即可能是单个字节,也可以是一个完整的 TCP 分节中的数据,若想等到某个固定的数目的数据可读为止,需要调用的 readn 函数或者指定 MSG_WAITALL 标志
既然 UDP 是数据报协议,若一个阻塞的 UDP 套接字的接收缓冲区为空,对它调用输入函数的进程将被投入睡眠,直到有 UDP 数据报到达
若某个进程对一个阻塞的 TCP 套接字调用这些输入函数之一,而且该套接字的接收缓冲区中没有数据可读,该进程将被投入睡眠,直到有一些数据到达
对于非阻塞的套接字,若输入操作不能被满足(对于 TCP 套接字即至少有一个字节的数据可读,对于 UDP 套接字即有一个完整的数据报可读)响应调用将立即返回一个 EWOULDBLOCK |EAGAIN 错误
- 输出操作,包括:write、writev、send、sendto、sendmsg 五个函数,对于一个 TCP 套接字,内核将从应用进程的缓冲区到该套接字的发送缓冲区复制数据
对于阻塞的套接字,若其发送缓冲区没有空间,进程将投入睡眠,直到有空间为止
对于一个非阻塞的 TCP 套接字,若其发送缓冲区中根据没有空间,输出函数调用将立即返回一个 EWOULDBLOCK |EAGAIN 错误,若其发送缓冲区有一些空间,返回值将是内核能够复制到该缓冲区中的字节数,该字节数也称之为不足计数
- 接受外来连接,即 accept 函数
若对一个阻塞的套接字调用 accept 函数,并且尚无新的连接到达,调用进程将被投入睡眠
若对一个非阻塞的套接字调用 accept 函数,并且尚无新的连接到达,accept 调用将立即返回一个 EWOULDBLOCK |EAGAIN 错误
- 发起外出连接,即用于 TCP 的 connect 函数,connect 同样可用于 UDP,不过它不能使一个 “真正” 连接建立起来,它只是使内核保存对端的 IP 地址、端口号
TCP 连接建立涉及到一个三次握手过程,而且 connect 函数一直要等到客户收到对于自己的 SYN -> ACK 为止才返回,这意味着 TCP 的每个 connect 总会阻塞其调用进程至少有一个到服务器的 RT 时间
若对于一个非阻塞的 TCP 套接字调用 connect,并且连接不会立即建立,连接的建立能照样发起(臂如:送出 TCP 三次握手的第一个分组)不过会返回一个 EINPROGRESS 错误
两者肉眼可见区别
BIO 会在主线程阻塞式的去接受一个 socket 客户端的连接,在操作系统内核中不会返回 -1,一直卡着不动: accept(4,
客户端读取数据时也是阻塞式的,没有 -1、0、>0,所以在使用 BIO 时要单独开辟新的线程去专门读取来自客户端的数据,而主线程只是阻塞式的负责接收来自客户端的连接;当客户端的连接很多时,线程的数量就会很多,线程之间的切换和任务频繁的调度就显而易见了.
主线程阻塞式接收客户端的连接:accept
每一个客户端有一个子线程负责去接收客户端的数据:read、readv
在 NIO 中,可配置式的支持配置阻塞或非阻塞,通过:configureBlocking 参数来进行配置,true:阻塞、false:非阻塞
- accept 调用了操作系统内核有以下两种情况
当没有客户端连接进来时,在 BIO 时会一直阻塞着,但是在 NIO 时,操作系统内核层面会返回 -1,而在 Java 应用程序中会返回 NULL
当有客户端连接进来时,accept 返回的是分配给这个客户端的文件描述符 socketfd,Java 中返回的是一个 SocketChannel 对象
- socket 对象分为以下两种:
服务端 ServerSocketChannel:连接请求三次握手完成后,该对象可以通过 accept 方法获取到客户端的 socket -> SocketChannel
客户端 SocketChannel:客户端与服务端之间建立好连接以后,通过该 socket 来负责读写数据使用
两者 socket 都需要配置为非阻塞式运行,才能够保证连接、读取数据都是非阻塞运行的!!!
NIO 为什么速度慢?
NIO 优势在于可以通过一个或多个线程来解决 N 个 IO 连接阻塞的问题
它的问题在于:在本篇博文通过 C10K 问题来模拟当其到达了 1W 个客户端,但是每次进行读取时都会循环一次,会带有 O(n) 复杂度的 recv 系统函数调用,可能在这些客户端中只有几个客户端是有数据的额,所以在这期间会有很多系统函数调用是没有意义的,浪费的只是系统的资源以及给操作系统内核带来没必要的压力
所以,从 NIO 来看,应该考虑的是只做那么有必要的事,没必要的事应该尽量的去避免它发生
总结
该篇博文主要介绍的是 I/O 模型中的非阻塞 I/O -> NIO,简要分析了 NIO 非阻塞式 I/O 简要的模型,通过图解分析的方式告知它与 BIO 之间的区别,通过实践代码的方式来分析非阻塞 I/O 在系统调用中所涉及到的流程,同时也介绍了 C10K 问题给非阻塞式 I/O 带来的不利之处,最后介绍了上篇 BIO 博文与 NIO 之间的相关的区别以及 NIO 为什么速度会慢的原因,希望能够得到你的支持,感谢三连
四元组唯一:源 IP、源端口、目标 IP、目标端口
🌟🌟🌟愿你我都能够在寒冬中相互取暖,互相成长,只有不断积累、沉淀自己,后面有机会自然能破冰而行!
博文放在 网络 I/O 专栏里,欢迎订阅,会持续更新!
如果觉得博文不错,关注我 vnjohn,后续会有更多实战、源码、架构干货分享!
推荐专栏:Spring、MySQL,订阅一波不再迷路文章来源:https://www.toymoban.com/news/detail-752190.html
大家的「关注❤️ + 点赞👍 + 收藏⭐」就是我创作的最大动力!谢谢大家的支持,我们下文见!文章来源地址https://www.toymoban.com/news/detail-752190.html
到了这里,关于深入理解网络非阻塞 I/O:NIO的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!