就是传输控制层tcp连接通信。
fd既file descriptor-文件描述符。Java中用对象代表输入输出流等...在Linux系统中不是面向对象的,是一切皆文件的,拿文件来代表输入输出流。其实是一个数值,例如1,2,3,4...0是标准输入,1是标准输出,2是错误输出...
任何进程在操作系统中都有自己IO对应的文件描述符,参考如下:
[root@iZj6c1dib207c054itjn30Z ~]# ps -ef | grep redis
root 20688 1 0 Nov23 ? 00:01:01 /opt/redis/bin/redis-server 127.0.0.1:6379
root 20786 1 0 Nov23 ? 00:01:00 /opt/redis/bin/redis-server 127.0.0.1:6380
root 30741 30719 0 12:26 pts/1 00:00:00 grep --color=auto redis
[root@iZj6c1dib207c054itjn30Z ~]# cd /proc/20688/fd
[root@iZj6c1dib207c054itjn30Z fd]# ll
total 0
lrwx------ 1 root root 64 Nov 23 21:50 0 -> /dev/null
lrwx------ 1 root root 64 Nov 23 21:50 1 -> /dev/null
lrwx------ 1 root root 64 Nov 23 21:50 2 -> /dev/null
lr-x------ 1 root root 64 Nov 23 21:50 3 -> pipe:[27847377]
l-wx------ 1 root root 64 Nov 23 21:50 4 -> pipe:[27847377]
lrwx------ 1 root root 64 Nov 23 21:50 5 -> anon_inode:[eventpoll]
lrwx------ 1 root root 64 Nov 23 21:50 6 -> socket:[27847384]
计算机有内核,客户端和内核连接产生fd,计算机的进程或线程会读取相应的fd。 因为socket在这个时期是blocking的,线程读取socket产生的文件描述符时,如果数据包没到,读取命令不能返回,会被阻塞。导致会有更多的线程被抛出,单位CPU在某一时间片只能处理一个线程,出现数据包到了的线程等着数据包没到的线程的情况,造成CPU资源浪费,CPU切换线程成本巨大。 例如早期Tomcat7.0版默认就是BIO。
socket对应的fd是非阻塞的 单位CPU只用一个线程,就一颗CPU只跑一个线程,没有CPU切换损耗,在用户空间轮询遍历所有的文件描述符。从遍历到取数据都是自己完成,所以是同步非阻塞IO。 问题是如果有1000个fd,代表用户进程轮询调用1000次kernel, 用户空间查询一次文件描述符就得调用一次系统调用,让后内核态用户态来回切换成本很大。
内核向前发展,轮询放到内核里,内核增加一个系统调用select函数,统一把一千个fd传给select函数,内核操作select函数,fd准备好后返回给线程,拿着返回的文件描述符找出ready的再去调read。如果1000个fd只有1个有数据,以前要调1000次,现在只调1次,相对前面在系统调用上更加精准。还是同步非阻塞的,只是减少了用户态和内核态的切换。
注意Linux只能实现NIO,不能实现AIO。 问题:用户态和内核态沟通的fd相关数据要来回拷贝。
内核通过mmap实现共享空间,用户态和内核态有一个空间是共享的,文件描述符fd存在共享空间实现用户态和内核态共享。epoll里面有三个调用,用户空间先epoll_create准备一个共享空间mmap,里面维护一个红黑树,内核态将连接注册进红黑树,epoll_ctl写入。当有数据准备好了,调用epoll_wait中断阻塞,取链表fd,再单独调用read。 mmap应用:kafka实现数据通过socket存到服务器文件上的过程也是mmap。
epoll应用:redis和nginx的worker进程等等。
原文链接:https://zhuanlan.zhihu.com/p/482549633
原文作者:Hu先生的Linux