netty笔记

netty笔记

Linux网络I/O模型

Linux的内核将所有外部设备都看做一个文件来操作,对一个文件的读写操作会调用内核提供的系统命令,返回一个file descriptor(fd,文件描述符)。而对一个socket的读写也会有响应的描述符,成为socketfd(socket描述符),描述符就是一个数字,它指向内核中的一个结构体(文件路径,数据区等一些属性)。

根据UNIX网络编程对I/O模型的分类,UNIX提供了5中I/O模型,分别如下:

  1. 阻塞I/O模型:最常用的I/O模型就是阻塞I/O模型,缺省情况下,所有文件操作都是阻塞的。我们以套接字为例来讲解此模型:在进程空间中调用recvfrom,其系统调用知道数据包到达且复制到应用进程的缓冲区中或者发生错误时才返回,在此期间一直会等待,进程从调用recvfrom开始到它返回的整段时间内都是阻塞的,因此被称为阻塞I/O模型,如下图所示:

阻塞IO模型

  1. 非阻塞I/O模型:recvfrom从应用层到内核的时候,如果该缓冲区没有数据的话,就直接返回一个EWOULDBLOCK错误,一般都对非阻塞I/O模型就行轮训检查这个状态,看内核是不是有数据到来,如下图所示:

非阻塞IO模型

  1. I/O复用模型:Linux提供select/poll,进程通过将一个或多个fd传递给select或poll系统调用,阻塞在select操作上,这样select/poll可以帮我们侦测多个fd是否处于就绪状态。select/poll是顺序扫描fd是否就绪,而且支持的fd数量有限,因此它的使用受到了一些制约。Linux还提供了一个epoll系统调用,epoll使用基于事件驱动方式代替顺序扫描,因此性能更高。当有fd就绪时,立即回调函数rollback,如下图所示:

IO复用模型

  1. 信号驱动I/O模型:首先开启套接口信号驱动I/O功能,并通过系统调用sigaction执行一个信号处理函数(此系统调用立即返回,进程继续工作,它是非阻塞的)。当数据准备就绪时,就为该进程生成一个SIGIO信号,通过信号回调通知应用程序调用recvfrom来读取数据,并通过主循环函数处理数据,如下图所示:

信号驱动IO模型

  1. 异步I/O:告知内核启动某个操作,并让内核在整个操作完成后(包括将数据从内核复制到用户自己的缓冲区)通知我们。这种模型与信号驱动模型的主要区别是:信号驱动I/O由内核通知我们何时可以开始一个I/O操作;异步I/O模型由内核通知我们I/O操作何时已经完成,如下图所示:

异步IO模型

JvisualVM java监控

TCP/IP相关

TCP粘包/拆包问题

TCP是个“流”协议,所谓流,就是没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义,它会根据TCP缓冲区的实际情况进行包的划分,所以在业务上认为,一个完成的包可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的TCP粘包和拆包问题。

假设客户端分别发送了两个数据包D1和D2给服务端,由于服务端一次读取到的字节数是不确定的,故可能存在以下5个情况:

  1. 服务端分两次读取到了两个独立的数据包,分别是D1和D2,没有粘包和拆包;
  2. 服务端一次接收到了两个数据包,D1和D2粘合在一起,TCP粘包;
  3. 服务端分两次读取到了两个数据包,第一次读取到了完整的D1包和D2包的部分内容,第二次读取到了D2包的剩余内容,TCP拆包;
  4. 服务端分两次读取到了两个数据包,第一次读取到了D1包的部分内容D1_1,第二次读取到了D1包的剩余内容D1_2和D2的整包。
  5. 如果此时服务端TCP接收滑窗非常小,而数据包D1和D2比较大,很有可能会发生第5中可能,即服务端分多次才能将D1和D2包接收完全,期间发生多次拆包。

TCP粘包拆包问题

粘包问题的解决策略

由于底层的TCP无法理解上层的业务数据,所以在底层是无法保证数据包不被拆分和重组的,这个问题只能通过上层的应用协议栈设计来解决,根据业界的主流协议的解决方案,可以归纳如下:

  1. 消息定长,例如没个报文的大小固定长度200字节,如果不够,空位补空格;
  2. 在报尾增加回车换行符进行分割,例如FTP协议;
  3. 将消息分为消息头和消息体,消息头中包含表示消息总长度(或消息体长度)的字段,通常设计思路为消息头的第一个字段使用int32来表示消息的总长度;
  4. 更复杂的应用层协议。

IDL Interface description language

Protobuf 二进制编码 Binary

下载protoc-2.5.0-win32.zip,解压后新建

  1. file 放置.proto文件
  2. src 生成java文件

编写SubscribeReq.proto文件,形如

1
2
3
4
5
6
7
8
9
option java_package = "netty.protobuf";
option java_outer_classname = "SubscribeReqProto";

message SubscribeReq {
required int32 subReqID = 1;
required string userName = 2;
required string productName = 3;
repeated string address = 4;
}

执行 protoc --java_out=.\src .\file\SubscribeReq.proto,在src目录下即生成SubscribeReqProto.java

maven添加依赖

1
2
3
4
5
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<version>3.2.0</version>
</dependency>

测试类:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
package netty.protobuf;

import com.google.protobuf.InvalidProtocolBufferException;

import java.util.ArrayList;
import java.util.List;

public class Test {

private static byte[] encode(SubscribeReqProto.SubscribeReq req) {
return req.toByteArray();
}

private static SubscribeReqProto.SubscribeReq decode(byte[] body) throws InvalidProtocolBufferException {
return SubscribeReqProto.SubscribeReq.parseFrom(body);
}

private static SubscribeReqProto.SubscribeReq createSubscribeReq() {
SubscribeReqProto.SubscribeReq.Builder builder = SubscribeReqProto.SubscribeReq.newBuilder();
builder.setSubReqID(1);
builder.setUserName("xuhe");
builder.setProductName("Netty Book");
List<String> address = new ArrayList<String>();
address.add("NanJing YuHuaTai");
address.add("BeiJing LiuLiChang");
address.add("ShenZhen HongShuLin");
builder.addAllAddress(address);
return builder.build();
}

public static void main(String[] args) throws Exception {
SubscribeReqProto.SubscribeReq req = createSubscribeReq();
System.out.println("Before encode:" + req);

SubscribeReqProto.SubscribeReq req2 = decode(encode(req));
System.out.println("After decode:" + req2);

System.out.println("Assert equal:-->" + req2.equals(req));
}

}

Thrift

JOBss Marshalling

MessagePack

HTTP协议

编码是按照从尾到头的顺序调度执行;解码是按照从头到尾的顺序调度执行。

WebSocket

建立WebSocket连接,客户端浏览器首先要向服务器发起一个HTTP请求,这个请求和通常的HTTP请求不同,包含了一个附件头信息,其中附加头信息”Upgrade:WebSocket”表明这是一个申请协议升级的HTTP请求。服务端解析这些附加的头信息,然后生成应答消息返回给客户端,客户端和服务端的WebSocket连接建立成功。双方可以通过这个连接通道自由的传递消息,并且这个连接会持续存在直到客户端或者服务端的某一方主动关闭连接。

私有栈协议

  1. 通信模型
  2. 消息定义
  3. 编解码规范
  4. 链路建立
  5. 链路关闭
  6. 可靠性
    1. 心跳机制
    2. 重连机制
    3. 重复登录保护
    4. 消息缓存重发
  7. 安全性设计
  8. 可扩展性设计