所谓零拷贝

前言

晚上看到一个零拷贝,觉得算是稍微拓展一下知识面吧

正文

简单拷贝场景

从一个文件中独处数据并将数据传到另一台服务器上,我们的常规操作是

File.read(file, buf, len);
Socket.send(socket, buf, len);

这种方式设计了4次拷贝,文字有点干瘪,上图

1、应用程序中调用read()方法,这里会涉及到一次上下文切换(用户态->内核态),底层采用DMA(direct memory access)读取磁盘的文件,并把内容存储到内核地址空间的读取缓存区。

2、由于应用程序无法读取内核地址空间的数据,如果应用程序要操作这些数据,必须把这些内容从读取缓冲区拷贝到用户缓冲区。这个时候,read() 调用返回,且引发一次上下文切换(内核态->用户态),现在数据已经被拷贝到了用户地址空间缓冲区,这时,如果有需要,应用程序可以操作修改这些内容。

3、我们最终目的是把这个文件内容通过Socket传到另一个服务中,调用Socket的send()方法,这里又涉及到一次上下文切换(用户态->内核态),同时,文件内容被进行第三次拷贝,被再次拷贝到内核地址空间缓冲区,但是这次的缓冲区与目标套接字相关联,与读取缓冲区没有半点关系。

4、send()调用返回,引发第四次的上下文切换,同时进行第四次的数据拷贝,通过DMA把数据从目标套接字相关的缓存区传到协议引擎进行发送。

过程1和4是由DMA负责,并不会消耗CPU,只有过程2和3的拷贝需要CPU参与

零拷贝

常规操作是否感觉好几次拷贝很多余,接下来便是零拷贝的方式

这种实现,可以有以下几点改进:

  • 上下文切换的次数从四次减少到了两次
  • 数据拷贝次数从四次减少到了三次(其中DMA copy 2次,CPU copy 1次)

“在Java中,正好FileChanneltransferTo() 方法可以实现这个过程,该方法将数据从文件通道传输到给定的可写字节通道, 上面的file.read()socket.send() 调用动作可以替换为transferTo() 调用”

public void transferTo(long position, long count, WritableByteChannel target);

在 UNIX 和各种 Linux 系统中,此调用被传递到 sendfile() 系统调用中,最终实现将数据从一个文件描述符传输到了另一个文件描述符。

继续优化?

Linux 内核 2.4 及后期版本中,针对套接字缓冲区描述符做了相应调整,DMA自带了收集功能,对于用户方面,用法还是一样的,但是内部操作已经发生了改变:

  • 第一步,transferTo() 方法引发 DMA 将文件内容拷贝到内核读取缓冲区。
  • 第二步,把包含数据位置和长度信息的描述符追加到套接字缓冲区,避免了内容整体的拷贝,DMA 引擎直接把数据从内核缓冲区传到协议引擎,从而消除了最后一次 CPU参与的拷贝动作。

该文引用自https://www.jianshu.com/p/2581342317ce

文中阐述不妥之处还望雅正,不吝感激。

转载请注明:天雷

以上。

谢谢你请我吃糖果