自从用了netty框架,妈妈再也不用担心我的socket通讯了
题外话,很多人都把JDK1.4提供的NIO称之为异步非阻塞I/O;其实,并不然,从严格意义上面讲,它只能称为非阻塞I/O。在JDK1.7提供的NIO 2.0,新增了异步的套接字通道Channel,它才是真正的异步非阻塞I/O。下表是不同I/O模型的对比:
表1-1 几种I/O模型和同能对比
同步阻塞I/O(BIO) | 伪异步I/O | 非阻塞I/O(NIO) | 异步I/O(AIO) | |
---|---|---|---|---|
客户端个数:I/O线程 | 1:1 | M:N(M可以大于N) | M:1(1个I/O线程处理多个客户端连接) | M:0(不需要启动额外的I/O线程,被动回调) |
I/O类型(阻塞) | 阻塞I/O | 阻塞I/O | 非阻塞I/O | 非阻塞I/O |
I/O类型(同步) | 同步I/O | 同步I/O | 同步I/O(I/O多路复用) | 异步I/O |
API使用难度 | 简单 | 简单 | 非常复杂 | 复杂 |
调试难度 | 简单 | 简单 | 复杂 | 复杂 |
可靠性 | 非常差 | 差 | 高 | 高 |
吞吐量 | 低 | 中 | 高 | 高 |
简介
Netty是由JBOSS提供的一个java开源框架。Netty提供异步的、事件驱动的网络应用程序框架和工具,用以快速开发高性能、高可靠性的网络服务器和客户端程序。
也就是说,Netty 是一个基于NIO的客户、服务器端编程框架,使用Netty 可以确保你快速和简单的开发出一个网络应用,例如实现了某种协议的客户,服务端应用。Netty相当简化和流线化了网络应用的编程开发过程,例如,TCP和UDP的socket服务开发。
“快速”和“简单”并不用产生维护性或性能上的问题。Netty 是一个吸收了多种协议的实现经验,这些协议包括FTP,SMTP,HTTP,各种二进制,文本协议,并经过相当精心设计的项目,最终,Netty 成功的找到了一种方式,在保证易于开发的同时还保证了其应用的性能,稳定性和伸缩性。——百度百科
优点
API使用简单,开发门槛低
功能强大,预置了多种编解码功能,支持多种主流协议
性能高,通过与业界其他主流NIO框架相比,netty的综合性能最高
成熟,稳定,Netty已经修复了已经发现的所有的JDK NIO BUG,业务开发人员不用再为NIO的bug而烦恼
社区活跃,版本迭代周期短,发现bug可以及时被修复,同时有更多的新功能加入
经历了大规模的商界业务考验,只能得到了验证
粘包、拆包
概念
TCP是一个流协议,所谓的流,就是没有界限的一串数据。可以考虑河里的流水,他们并没有界限。tcp底层并不了解业务层数据的具体含义,他会根据tcp缓冲区的实际情况进行包的划分,所以在业务上认为,一个完整的包可能会被tcp拆分成多个包进行发送,也可能把多个小包封装成一个大数据一起发送,这就是所谓的tcp粘包,拆包问题
产生原因
应用程序write写入的字节大小大于套接口发送缓冲区的大小
进行MSS大小的tcp分段
以太网帧的payload大于MTU进行IP分片
解决办法
消息定长,每个报文大小固定长度,不够的补0
包尾增加回车换行符进行分割。例如:FTP协议
将消息分为消息头和消息体。消息头中包含消息的总长度字段
更复杂的应用层协议
Netty框架的解决办法
LineBasedFrameDecoder和StringDecoder两个类
LineBasedFrameDecoder
LineBasedFrameDecoder的工作原理是依次遍历ByteBuf中的可读字节,判断看是否有”\r”或者”\r\n”,如果有就以此为结束位置,从可读索引位置到结束区间的字节就组成了一行。他是以换行符为结束标志的解码器,支持携带结束符和不带结束符两种解码方式。同时支持配置单行的最大长度。如果连续读取到最大长度后仍然没有发现换行符,就会抛出异常,同时忽略掉之前读取的异常流
StringDecoder
StringDecoder的功能就非常简单,就是将接收到的对象换成字符串,然后继续调用后面的handler,LineBasedFrameDecoder+StringDecoder组合就是按换行符切换文本解码器,他被设计用来支持TCP粘包和拆包。Netty支持其他其他符号的解码器(DelimiterBasedFrameDecode)
说了这么多,代码来了,就是用Netty实现的心跳。对于懒癌晚期,已经风装好,可以直接拿过去用,注释也写的很清楚
1 | import android.util.Log; |
1 | package com.example.zwang.myapplication.socket; |