Netty中的流式传输

Netty中的流式传输

在网络编程中通常是使用流式传输来处理网络数据,比如对于Netty的解码处理器,如下图:
在这里插入图片描述
当从网络中读取数据的时候,并不是一次性的把所有的数据都读取到ByteBuf缓存中,虽然这样可能更方便。读取数据的时候我们是流式读取,即每次只从网络中读取一部分数据进行处理。那么采用网络传输数据的时候采用流式传输有什么样的好处呢

  • 提高出错时的传输效率。比如如果不是流式传输,而是一次性把网络中的所有数据都传输过来,会出现什么情况呢?比如你下载一个特别大的文件,下载到中间出错了,这个时候你还需要来进行重新下载,之前已经下载过的部分也需要进行重新下载,所以出错时的传输效率就很低。而如果使用流式传输的话,当中间下载出错的时候,不需要重新下载,我们只需要从出错的地方开始下载即可,已经下载过的部分无需重新下载。
  • 节省内存。如果一次性把网络中的所有数据都接收过来,那么需要很大的内存空间去处理,但是如果我们每次只接收一部分,接收完了去处理这部分数据,处理好了释放内存,这样就比较节省内存了。
  • 流式传输可以实现逐步读取数据和处理数据,这样既便数据还没有完全传输过来我们也可以使用。比如你在下载视频,如果是一次性的全部传输,那么只有等视频全部下载完了你才能去观看;但是如果是流式传输,我们一次只下载一部分视频,去读取处理这段视频,既便我们的视频还没有全部下载,我们也能观看已经下载好的小段视频。

Netty是如何支持网络中的流式传输数据的呢?
在Netty中应用程序中会有一个解码处理器,如下图:
在这里插入图片描述
每当应用程序需要从网络中读取数据的时候,第一个处理从网络中读取数据的处理器都是类似于ByteToMessageDecoder的解码处理器。但是网络冲刷数据到应用程序的解码处理器的时候,会把网络中的所有数据都一次性的冲刷到解码处理器的ByteBuf中吗?
答案是不会的。
比如现在有一个场景,客户端想要往服务端冲刷10个字节的数据,然后客户端会先把10个字节的数据冲刷到网络中,接着网络会把数据冲刷到服务端应用程序中,第一个接收网络中的数据的处理器就是解码处理器,但是因为Netty的设计考虑到了TCP网络中的流式数据传输,所以Netty也要能够支持流式数据传输,因此Netty就不会一次把网络中的数据全部接收,Netty可以选择一次只接收网络中的一部分数据。比如上图中的例子就是解码处理器中一次只接收网络中的4个字节的数据,服务端的解码处理器先接收到了网络中的4个字节的数据,然后处理这部分数据,当前处理器处理完之后再传给ChannelPipeline责任链中后续的ChannelHandler,继续处理网络中接受的这一小部分数据,最后服务端的入站处理器也可能往客户端冲刷数据,客户端可能拿到这部分数据后又会去处理,当然客户端从网络中拿数据的时候也是流式传输的,客户端也可以选择一次只读取一小部分数据,当然这些只是后话,我们重点要说的是当网络中的数据冲刷到应用程序的解码处理器之后,解码处理器一次只会处理一小部分数据,然后这一小部分数据都处理好了之后,解码处理器会继续读取网络中的数据,再继续处理新读取的这部分数据,然后再读取…
总之就是应用程序中的解码处理器一次不会读取网络中的全部数据处理,而是先读取一小部分数据,处理好了之后,再读取另外一小部分数据,再去处理…这就是Netty适应网络数据的流式传输所作的努力。

然后如果网络中的数据不足了,比如网络中只剩2个字节的数据,而我们应用程序的解码处理器一次会读取4个字节的数据,那么这个时候解码处理器会先保存这2个字节的数据,先不处理,等到后续网络中有了新的能传输的数据,解码处理器中能凑够4个字节了再做处理。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Mr-X~

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值