CN102811201B - Ssl非阻塞通信方法及用于ssl非阻塞通信的服务器 - Google Patents
Ssl非阻塞通信方法及用于ssl非阻塞通信的服务器 Download PDFInfo
- Publication number
- CN102811201B CN102811201B CN201110144979.6A CN201110144979A CN102811201B CN 102811201 B CN102811201 B CN 102811201B CN 201110144979 A CN201110144979 A CN 201110144979A CN 102811201 B CN102811201 B CN 102811201B
- Authority
- CN
- China
- Prior art keywords
- data
- event
- write
- module
- ssl
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Telephonic Communication Services (AREA)
Abstract
本申请提供了一种SSL非阻塞通信的方法及用于SSL非阻塞通信的服务器,所述方法包括:服务器监听网络I/O事件,若为连接事件,则注册读事件;若为写事件,则执行将所述缓冲区中的第二加密数据写入网络的写操作,然后依据预设的SSL握手过程获取当前握手状态,根据不同握手状态执行对应操作。若为读事件,则执行从网络中获取第一加密数据的读操作,并将所述第一加密数据写入预置的缓冲区中,然后依据预设的SSL握手过程获取当前握手状态,根据不同握手状态执行对应操作。本申请既能保证进行SSL协议非阻塞的高性能通讯,又能控制整个SSL协议的握手交互过程,并易于获取握手交互过程中的相关报文,解决了诸多面向SSL协议应用的问题。
Description
技术领域
本申请涉及网络通信的技术领域,特别是涉及一种SSL非阻塞通信的方法,以及一种用于SSL非阻塞通信的服务器。
背景技术
SSL(Secure Sockets Layer安全套接层)是为网络通信提供安全及数据完整性的一种安全协议,用以保障在Internet上数据传输之安全,其利用数据加密(Encryption)技术,可确保数据在网络上之传输过程中不易被截取及窃听。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。
SSL协议位于TCP/IP协议与各种应用层协议之间,为数据通讯提供安全支持。SSL协议可分为两层:
第一层:SSL记录协议(SSL Record Protocol),它建立在可靠的传输协议(如TCP)之上,为高层协议提供数据封装、压缩、加密等基本功能的支持。
第二层:SSL握手协议(SSL Handshake Protocol),它建立在SSL记录协议之上,用于在实际的数据传输开始前,通讯双方进行身份认证、协商加密算法、交换加密密钥等。
SSL协议提供的服务主要有:1)认证用户和服务器,确保数据发送到正确的客户机和服务器;2)加密数据以防止数据中途被窃取;3)维护数据的完整性,确保数据在传输过程中不被改变。
目前,基于SSL协议的通信方式主要包括阻塞通信方式和非阻塞通信方式:
JDK(Java Development Kit)中的SSLServerSocket和SSLSocket就提供了SSL协议通讯的面向字节流的阻塞实现。对于用SSLServerSocket及SSLSocket编写的服务器程序和客户程序,他们在运行过程中常常会阻塞。例如,当一个线程执行SSLServerSocket的accept()方法时,假如没有客户连接,该线程就会一直等到有客户连接才从accept()方法返回;再例如,当线程执行SSLSocket的read()方法时,如果输入流中没有数据,该线程就会一直等到读入足够的数据才从read()方法返回。假如服务器程序需要同时与多个客户通信,就必须分配多个工作线程,让他们分别负责与一个客户通信,当然每个工作线程都有可能经常处于长时间的阻塞状态。
对于SSL阻塞通信的方式而言,通常需要较大的系统开销,并且工作线程的许多时间都浪费在阻塞I/O操作上,从而导致性能较慢,通信效率较低。再者,JDK的SSLServerSocket隐藏了SSL协议的握手交互过程,将SSL协议的握手交互过程做了高度的封装,从而导致相关技术人员无法查看具体的握手交互过程,无法获取到握手交互过程中的相关报文。然而,在诸多面向SSL协议的应用中,都需要通过获知具体的握手交互过程及相关报文,来处理基于SSL协议的握手交互。例如,对电子商务平台中使用的秒杀器产生的https请求分析,或者,对其他爬虫软件模拟的https请求分析,或者,建立支持SSL协议的服务器等。
SSL非阻塞通信的方式在JDK的1.4版被引入Java语言,采用这种方式,服务器程序接收客户连接,客户程序建立与服务器的连接,以及服务器程序和客户程序收发数据的操作都可以按非阻塞的方式进行。并且,服务器程序只需要创建一个线程,就能完成同时与多个客户通信的任务。尽管SSL非阻塞通信的方式解决了SSL阻塞通信方式所存在的系统开销大、性能较慢、通信效率较低的问题,但是在安全上不支持SSL协议的握手交互。具体而言,由于JDK的1.4版中通过新的I/O库(JavaNIO)实现非阻塞通信,NIO库包含了文件、管道以及客户机和服务器套接字的非阻塞功能,然而,库中缺少的一个特性是安全的非阻塞套接字连接。在Java NIO库中没有建立安全的非阻塞通道类,故不能使用安全的非阻塞通信。
因此,目前需要本领域技术人员迫切解决的一个技术问题就是:提出一种可以支持SSL协议握手交互的非阻塞通信机制,既能保证进行SSL协议非阻塞的高性能通讯,又能控制整个SSL协议的握手交互过程,并易于获取握手交互过程中的相关报文。
发明内容
本申请所要解决的技术问题是提供一种SSL非阻塞通信的方法,用以保证进行SSL协议非阻塞的高性能通讯,又能控制整个SSL协议的握手交互过程,并易于获取握手交互过程中的相关报文。
本申请还提供了一种用于SSL非阻塞通信的服务器,用以保证上述方法在实际中的应用及实现。
为了解决上述问题,本申请公开了一种SSL非阻塞通信的方法,包括:
步骤S101、服务器监听网络I/O事件,并获取所监听到网络I/O事件的类型;若为连接事件,则执行步骤S102;若为读事件,则执行步骤S103;若为写事件,则执行步骤S110;
步骤S102、依据所述连接事件注册读事件,返回步骤S101;
步骤S103、执行从网络中获取第一加密数据的读操作,并将所述第一加密数据写入预置的缓冲区中,转步骤S104;
步骤S104、依据预设的SSL握手过程获取当前握手状态,若所述握手状态为数据解密,则执行步骤S105;若所述握手状态为数据加密,则执行步骤S109;
步骤S105、对所述缓冲区中的第一加密数据进行解密,若解密成功,获得第一数据,则执行步骤S106,若解密不成功,则执行步骤S108;
步骤S106、判断解密获得的第一数据是否为客户端请求原文,若是,则结束本次SSL握手过程;若否,则执行步骤S107;
步骤S107、将所述第一数据写入缓冲区,并返回步骤S104;
步骤S108、注册读事件,并返回步骤S101;
步骤S109、对所述缓冲区中的第一数据进行加密,获得第二加密数据,注册写事件,返回步骤S101;
步骤S110、执行将所述缓冲区中的第二加密数据写入网络的写操作,转步骤S104。
优选的,在所述握手状态为任务执行操作时,所述的方法还包括:
步骤S111、执行当前握手任务,执行完后返回步骤S104。
优选的,所述第一加密数据包括加密的客户端请求原文或客户端加密的握手报文;所述第一数据为客户端请求原文或握手报文;所述第二加密数据为服务器加密的握手报文。
优选的,所述缓冲区包括输入缓冲区和输出缓冲区,所述步骤S103中的第一加密数据写入输入缓冲区,所述步骤S107中的第一数据写入输入缓冲区;
所述步骤S109为对输出缓冲区中的第一数据进行加密,在进行加密之前,还包括:从输入缓冲区中读出第一数据并写入输出缓冲区;
所述步骤S110为,执行将输出缓冲区中的第二加密数据写入网络的写操作。
优选的,所述步骤S105中对缓冲区中的第一加密数据进行解密的步骤具体包括:
从输入缓冲区中读指针的起始位置开始读取预设大小的第一加密数据;
对所读取的第一加密数据进行解密。
优选的,在所述步骤S107将第一数据写入输入缓冲区后,还包括:
将输入缓冲区中的读指针移至第一数据的首位。
优选的,在所述步骤S108,注册读事件之前还包括:
提示当前缓冲区的数据不足,将读指针移至输入缓冲区中经过解密处理的第一加密数据之后。
优选的,在所述步骤S109对第一数据进行加密之前,还包括:
将写指针移至写入输出缓冲区中的第一数据的首位。
优选的,所述步骤S109中将第一数据写入输出缓冲区的步骤为:
从输出缓冲区中写指针的起始位置开始在输出缓冲区中写入预设大小的第一数据。
本申请还公开了一种用于SSL非阻塞通信的服务器,包括:
监听模块,用于监听网络I/O事件,并获取所监听到网络I/O事件的类型;若为连接事件,则触发连接事件处理模块;若为读事件,则触发读事件处理模块;若为写事件,则触发写事件处理模块;
连接事件处理模块,用于依据所述连接事件注册读事件,然后调用所述监听模块;
读事件处理模块,用于执行从网络中获取第一加密数据的读操作,并将所述第一加密数据写入预置的缓冲区中,然后触发握手控制模块;
握手控制模块,用于依据预设的SSL握手过程获取当前握手状态,若所述握手状态为数据解密,则触发解密操作模块;若所述握手状态为数据加密,则触发加密操作模块;
解密操作模块,用于对所述缓冲区中的第一加密数据进行解密,若解密成功,获得第一数据,则触发报文判断模块,若解密不成功,则触发读事件注册模块;
报文判断模块,用于判断解密获得的第一数据是否为客户端请求原文,若是,则触发结束模块;若否,则触发缓存写入模块;
结束模块,用于结束本次SSL握手过程;
缓存写入模块,用于将所述第一数据写入缓冲区,并调用握手控制模块;
读事件注册模块,用于注册读事件,并调用监听模块;
加密操作模块,用于对所述缓冲区中的第一数据进行加密,获得第二加密数据,注册写事件,然后调用监听模块;
写事件处理模块,用于执行将所述缓冲区中的第二加密数据写入网络的写操作,然后调用握手控制模块。
与现有技术相比,本申请具有以下优点:
针对现有的SSL非阻塞通信的方式在安全上不支持SSL协议的握手交互的问题,本申请直接面向通信底层提供了一种安全的SSL非阻塞通讯的轮循框架,在该轮循框架中,以事件机制贯穿SSL握手和NIO无阻塞通讯之间,并利用缓冲区来传递数据。具体而言,本申请有效整合了NIO无阻塞和SSLEngine握手的复杂事件机制,解决了握手状态和情形引发的通讯事件的处理。在通讯和握手过程中,将缓冲区做为共同利用的区域进行操作,通过对缓冲区的读写准备和压紧处理,高效支持无阻塞通讯和握手交互。从而既能保证进行SSL协议非阻塞的高性能通讯,又能控制整个SSL协议的握手交互过程,并易于获取握手交互过程中的相关报文,解决了诸多面向SSL协议的应用问题。
附图说明
图1是本申请的一种SSL非阻塞通信的方法实施例1的步骤流程图;
图2是本申请的一种SSL非阻塞通信的方法实施例2的步骤流程图;
图3是本申请的一种用于SSL非阻塞通信的服务器的结构框图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本申请作进一步详细的说明。
为使本领域技术人员更好地理解本申请,以下简单介绍本申请非阻塞通信的基本思想:
假如要同时做两件事:烧开水和烧粥。
烧开水的步骤如下:
锅里放水,打开煤气炉;
等待水烧开;//阻塞
关闭煤气炉,把开水灌到水壶里。
烧粥的步骤如下:
锅里放水和米,打开煤气炉;
等待粥烧开;//阻塞
调整煤气炉,改为小火;
等待粥烧熟;//阻塞
关闭煤气炉。
为了同时完成两件事,一个方案是同时请两个人分别做其中的一件事,这相当于采用多线程来同时完成多个任务。
还有一种方案是让一个人同时完成两件事,这个人应该善于利用一件事的空闲时间去做另一件事,一刻也不应该闲着:
锅子里放水,打开煤气炉;//开始烧水
锅子力放水和米,打开煤气炉;//开始烧粥
while(一直等待,直到有水烧开,粥烧开或粥烧熟事件发生){//阻塞
if(水烧开)
关闭煤气炉,把开水灌到水壶里;
if(粥烧开)
调整煤气炉,改为小火;
if(粥烧熟)
关闭煤气炉;
if(水已经烧开并且粥已经烧熟)
退出循环;
}//这里的煤气炉可以理解为每件事就有一个煤气炉配给
这个人不断监控烧水及烧粥的状态,如果发生了″水烧开″,″粥烧开″或″粥烧熟″事件,就去处理这些事件,处理完一件事后进行监控烧水及烧粥的状态,直到所有的任务都完成。
以上工作方式也可以运用到服务器程序中,服务器程序只需要一个线程就能同时负责接收客户的连接,接收各个客户发送的数据,以及向各个客户发送响应数据.服务器程序的处理流程如下:
while(一直等待,直到有接收连接就绪事件,读就绪事件或写就绪事件发生){//阻塞
if(有客户连接)
接收客户的连接;//非阻塞
if(某个Socket的输入流中有可读数据)
从输入流中读数据;//非阻塞
if(某个Socket的输出流可以写数据)
向输出流写数据;//非阻塞
}
以上处理流程采用了轮询的工作方式,当某一种操作就绪时,就执行该操作,否则就查看是否还有其他就绪的操作可以执行。线程不会因为某一个操作还没有就绪,就进入阻塞状态,一直等待这个操作就绪。
为了使轮询的工作方式顺利进行,接收客户的连接,从输入流读数据,以及,向输出流写数据的操作都应该以非阻塞的方式运行。所谓非阻塞,就是指当线程执行这些方法时,如果操作还没有就绪,就立即返回,而不会一直等到操作就绪。例如,当线程接收客户连接时,如果没有客户连接,就立即返回;再例如,当线程从输入流中读数据时,如果输入流中还没有数据,就立即返回,或者如果输入流还没有足够的数据,那么就读取现有的数据,然后返回。以上while条件中的操作还是按照阻塞方式进行的,如果未发生任何事件,就会进入阻塞状态,直到接收连接事件,读事件或写事件中至少有一个事件发生时,才会执行while循环体中的操作。在while循环体中,一般会包含在特定条件下退出循环的操作。
本申请的核心构思之一在于,直接面向通信底层提供一种实现SSL非阻塞通讯的轮循框架,在该轮循框架中,以事件机制贯穿SSL握手和NIO通讯之间,并利用缓冲区来传递数据,从而既能保证进行SSL协议非阻塞的高性能通讯,又能控制整个SSL协议的握手交互过程,并易于获取握手交互过程中的相关报文,解决了诸多面向SSL协议的应用问题。
参考图1,示出了本申请的一种SSL非阻塞通信的方法实施例1的步骤流程图,具体可以包括以下步骤:
步骤S101、服务器监听网络I/O事件,并获取所监听到网络I/O事件的类型;若为连接事件,则执行步骤S102;若为读事件,则执行步骤S103;若为写事件,执则行步骤S110;
在具体实现中,可以建立一个基于java.nio包(新I/O包)的非阻塞服务器,该服务器接收客户端连接,客户端建立与服务器的连接,以及服务器和客户端收发数据的操作都可以按非阻塞的方式进行。非阻塞的通信机制主要由java.nio包中支持非阻塞通信的类实现,如Selector和SelectionKey等。
在所述服务器上可以设置监听端口,并定义需要监听的网络I/O事件,当监听到某个事件发生时,则处理这个事件。所述“监听”可以理解为不停地选择搜索到的事件信息。作为本申请实施例应用的一种示例,可以通过向选择器Selector注册网络I/O事件来委托Selector监控网络I/O事件,Selector则会监听这些事件,获取所监听到网络I/O事件的类型,并依据类型设置SelectionKey。具体而言,Selector采用了多路复用(Multiplexing)技术,可在一个选择器上处理多个套接字,通过获取读写通道来进行IO操作。当向Selector注册事件时,可以在参数中指定SelectionKey感兴趣的事件,从而创建一个SelectionKey对象,这个SelectionKey对象是用来跟踪注册事件的句柄,SelectionKey对象的有效期间,Selector会一直监控与SelectionKey对象相关的事件。
在本申请一种优选的实施例中,所述网络I/O事件包括如下三种类型:
连接事件accept:当客户端请求被服务器接受后触发该事件。该事件表明一个新的客户端与服务器正式建立连接。
读事件read:表示网络中已经有了可读数据,可以执行读操作了;
以及,写事件write:表示已经可以向网络写数据了。
相应的SelectionKey为:SelectionKey.OP_ACCEPT:连接事件,SelectionKey.OP_READ:读事件,以及,SelectionKey.OP_WRITE:写事件。
步骤S102、依据所述连接事件注册读事件,返回步骤S101;
在具体实现中,当检测到客户端的HTTPS的访问请求时,将接受该连接事件响应,并注册感兴趣事件为读事件,然后返回由服务器继续监听。其中,HTTPS(Secure Hypertext Transfer Protocol,安全超文本传输协议)是以安全为目标的HTTP通道,即HTTP下加入SSL层,用于对数据进行压缩和解压操作,并返回网络上传送回的结果。
作为具体应用的一种示例,可以通过以下代码向Selector注册读事件:
SelectionKey key=SSLServerSocket.register(selector,SelectionKey.OP_READ)
步骤S103、执行从网络中获取第一加密数据的读操作,并将所述第一加密数据写入预置的缓冲区中,转步骤S104;
当服务器监听到读事件时,表示网络中已经有了可读数据,可以执行读操作了,于是从网络中读取客户端发送的第一加密数据。在具体实现中,所述第一加密数据为客户端加密的客户端请求原文或客户端加密的握手报文,并且通常为字节流数据。在本申请实施例中,所述网络可以理解为通道(channel),即当服务器与某个客户端建立连接后,则在该客户端与服务器之间打开了一个通道。通道可以用来连接缓冲区与数据源或数据汇(数据目的地),也就是说,数据源的数据可以经过通道到达缓冲区,缓冲区的数据经过通道到达数据汇,本步骤即为客户端(数据源)发送的数据经过通道到达缓冲区。具体可以采用参数read(ByteBufferbuffer)来接收第一加密数据,把它们存放到参数指定的缓冲区ByteBuffer中。
在非阻塞模式下,读操作采用能读到多少数据就读多少数据的原则,具体可以通过read()方法实现。read()方法读取当前通道中的可读数据,有可能不足r个字节(r为完整报文的字节),或者为0个字节,read()方法总是立即返回,而不会等到读取了r个字节再返回。
步骤S104、依据预设的SSL握手过程获取当前握手状态,若所述握手状态为数据解密,则执行步骤S105;若所述握手状态为数据加密,则执行步骤S109;
在具体实现中,SSL握手过程可以在SSL握手引擎(SSLEngine)中设置,由SSLEngine控制SSL握手过程,并进行握手状态检测和处理。公知的是,一次SSL连接的完整过程包括:
单向认证:客户端向服务器发送消息,服务器接到消息后,用服务器的密钥库中的私钥对数据进行加密,然后把加密后的数据和服务器的公钥一起发送到客户端,客户端用服务器发送来的公钥对数据解密,然后再用传到客户端的服务器公钥对数据加密传给服务器,服务器用私钥对数据进行解密。
双向认证:
(1)客户端向服务器发送消息,首先把消息用客户端证书加密然后连同时把客户端证书一起发送到服务器;
(2)服务器接到消息后首先用客户端证书把消息解密,然后用服务器私钥把消息加密,把服务器证书和消息一起发送到客户端;
(3)客户端用发来的服务器证书对消息进行解密,然后用服务器的证书对消息加密,然后在用客户端的证书对消息在进行一次加密,连同加密消息和客户端证书一起发送到服务器;
(4)服务器首先用客户端传来的证书对消息进行解密,确保消息是这个客户发来的,然后用服务器的私钥对消息再进行解密这个便得到了明文数据。
可以看出,基于SSLEngine检测到的握手状态至少可以包括:数据加密(如服务器用私钥对数据进行加密)和数据解密(如服务器用私钥对数据进行解密)。
步骤S105、对所述缓冲区中的第一加密数据进行解密,若解密成功,获得第一数据,则执行步骤S106,若解密不成功,则执行步骤S108;
当检测到的握手状态为数据解密时,则针对缓冲区中的第一加密数据,如加密的客户端请求原文或加密的握手报文进行解密,若解密成功,则获得第一数据为客户端请求原文或握手报文。
步骤S106、判断解密获得的第一数据是否为客户端请求原文,若是,则结束本次SSL握手过程;若否,则执行步骤S107;
步骤S107、将所述第一数据写入缓冲区,并返回步骤S104;
若解密获得的第一数据为客户端请求原文,则可以结束本次SSL握手过程;若解密获得的第一数据为握手报文,则将该握手报文写入缓冲区,返回SSLEngine检测的步骤以进行下一步握手操作,如进行数据加密操作,即在下一步握手操作中对该握手报文进行服务器加密。
步骤S108、注册读事件,并返回步骤S101;
如果对所述缓冲区中的第一加密数据解密不成功,通常表示写入缓冲区中的第一加密数据不是完整的加密报文,需要继续从网络中获得第一加密数据,因而注册一个读事件,然后返回服务器监听网络I/O事件的步骤。
步骤S109、对所述缓冲区中的第一数据进行加密,获得第二加密数据,注册写事件,返回步骤S101;
当检测到的握手状态为数据加密时,则针对缓冲区中的第一数据,如握手报文进行加密,则获得第二加密数据为服务器加密的握手报文。由于需要将所述第二加密数据写入网络,因而注册一个写事件,然后返回服务器监听网络I/O的步骤。
步骤S110、执行将所述缓冲区中的第二加密数据写入网络的写操作,转步骤S104。
当服务器监听到写事件时,表示已经可以向网络写数据了,于是将缓冲区中的第二加密数据写入网络。在具体实现中,所述第二加密数据为服务器加密的握手报文,具体可以采用write(ByteBuffer buffer):把指定的缓冲区ByteBuffer中的第二加密数据发送出去。
在非阻塞模式下,写操作奉行能输出多少数据就输出多少数据的原则,具体可以通过write()方法实现。write()方法向通道输出数据,有可能不足r个字节(r为完整报文的字节),或者为0个字节,write()方法总是立即返回,而不会等到输出r个字节后再返回。
在具体实现中,服务器接受客户端请求,同时将读、写通道提交由相应的读线程(Reader)和写服务线程(Writer),由读写线程分别完成对客户端数据的读取和对客户端的回应操作。具体而言,服务器接受客户端请求后,控制线程将该请求的读通道交给读线程池,由读线程池分配线程完成对客户端数据的读取操作;当读线程完成读操作后,将数据返回控制线程,进行服务器的业务处理;完成业务处理后,将需回应给客户端的数据和写通道提交给写线程池,由写线程完成向客户端发送回应数据的操作。由于网络带宽等原因,在通道的读、写操作中是容易出现等待的,所以在读、写操作中引入多线程,对性能提高明显,而且可以提高客户端的感知服务质量。
参考图2,示出了本申请的一种SSL非阻塞通信的方法实施例2的步骤流程图,具体可以包括:
步骤S201、服务器监听网络I/O事件,并获取所监听到网络I/O事件的类型;若为连接事件,则执行步骤S202;若为读事件,则执行步骤S203;若为写事件,执则行步骤S210;
步骤S202、依据所述连接事件注册读事件,返回步骤S201;
步骤S203、执行从网络中获取第一加密数据的读操作,并将所述第一加密数据写入预置的输入缓冲区中,转步骤S204;
步骤S204、依据预设的SSL握手过程获取当前握手状态,若所述握手状态为数据解密,则执行步骤S205;若所述握手状态为数据加密,则执行步骤S209;若所述握手状态为任务执行操作时,则执行步骤S211;
步骤S205、从输入缓冲区中读指针的起始位置开始读取预设大小的第一加密数据,对所读取的第一加密数据进行解密,若解密成功,获得第一数据,则执行步骤S206,若解密不成功,则执行步骤S208;
步骤S206、判断解密获得的第一数据是否为客户端请求原文,若是,则结束本次SSL握手过程;若否,则执行步骤S207;
步骤S207、将所述第一数据写入输入缓冲区,并将输入缓冲区中的读指针移至第一数据的首位,返回步骤S204;
步骤S208、提示当前缓冲区的数据不足,将读指针移至输入缓冲区中经过解密处理的第一加密数据之后,然后注册读事件,并返回步骤S201;
步骤S209、从输入缓冲区中读出第一数据,并从输出缓冲区中写指针的起始位置开始在输出缓冲区中写入预设大小的第一数据,对所述输出缓冲区中的第一数据进行加密,获得第二加密数据,注册写事件,返回步骤S201;
步骤S210、执行将输出缓冲区中的第二加密数据写入网络的写操作,将写指针移至输出缓冲区中已写入网络的第二加密数据之后,然后转步骤S204。
步骤S211、执行当前握手任务,执行完后返回步骤S204。
例如,所述握手任务为获取密钥套件或获取证书,则服务器执行相应的获取密钥套件或获取证书的操作。
为使本领域技术人员更好地理解本申请,以下通过一个具体例子说明。
(一)服务器监听到连接事件,接受所述连接事件响应并注册读事件,然后继续监听。
(二)服务器监听到读事件,表示可以执行读操作了,于是执行从网络中获取第一加密数据的读操作,并将所述第一加密数据写入预置的缓冲区中;其中,第一加密数据为客户端加密的请求原文或客户端加密的握手报文;
然后,基于SSLEngine检测当前的握手状态,若为服务器采用私钥进行数据解密,则采用预置的私钥对所述第一加密数据进行解密,若解密获得的是客户端请求原文,表示握手已经完成,于是结束本次的SSL握手过程;若解密获得的是握手报文,则将该握手报文写入输入缓冲区,然后返回由SSLEngine继续检测握手状态。若解密不成功,则表示当前输入缓冲区中的数据不是完整的报文,需要注册读事件以获取更多的网络数据,于是将输入缓冲区压紧(将读指针放到处理完的数据后面),然后注册读事件,再返回由服务器继续监听网络1/O事件;
如果SSLEngine检测当前的握手状态为服务器采用私钥进行数据加密,于是对输出缓冲区进行读写准备(调整输出缓冲区的写指针,获取写指针对应的数据位置),将输出缓冲区中的握手报文采用私钥进行加密后,注册写事件,返回由服务器继续监听网络1/O事件。
(三)服务器监听到写事件,表示可以执行写操作了,于是将输出缓冲区中的第二加密数据写入网络,写入后再将输出缓存压紧,返回SSLEngine检测的步骤进行轮循。
需要说明的是,对于方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本申请所必须的。
参考图3,示出了本申请的一种用于SSL非阻塞通信的服务器的结构框图,具体可以包括以下模块:
监听模块301,用于监听网络I/O事件,并获取所监听到网络I/O事件的类型;若为连接事件,则触发连接事件处理模块302;若为读事件,则触发读事件处理模块303;若为写事件,则触发写事件处理模块310;
连接事件处理模块302,用于依据所述连接事件注册读事件,然后调用所述监听模块301;
读事件处理模块303,用于执行从网络中获取第一加密数据的读操作,并将所述第一加密数据写入预置的缓冲区中,然后触发握手控制模块304;
握手控制模块304,用于依据预设的SSL握手过程获取当前握手状态,若所述握手状态为数据解密,则触发解密操作模块305;若所述握手状态为数据加密,则触发加密操作模块310;
解密操作模块305,用于对所述缓冲区中的第一加密数据进行解密,若解密成功,获得第一数据,则触发报文判断模块306,若解密不成功,则触发读事件注册模块309;
报文判断模块306,用于判断解密获得的第一数据是否为客户端请求原文,若是,则触发结束模块307;若否,则触发缓存写入模块308;
结束模块307,用于结束本次SSL握手过程;
缓存写入模块308,用于将所述第一数据写入缓冲区,并调用握手控制模块304;
读事件注册模块309,用于注册读事件,并调用监听模块301;
加密操作模块310,用于对所述缓冲区中的第一数据进行加密,获得第二加密数据,注册写事件,然后调用监听模块301;
写事件处理模块311,用于执行将所述缓冲区中的第二加密数据写入网络的写操作,然后调用握手控制模块304。
在本申请的一种优选实施例中,在所述握手状态为任务执行操作时,还包括:
任务执行模块,用于执行当前握手任务,执行完后调用握手控制模块。
在具体实现中,所述第一加密数据可以为加密的客户端请求原文或客户端加密的握手报文;所述第一数据可以为客户端请求原文或握手报文;所述第二加密数据可以为服务器加密的握手报文。
所述缓冲区可以包括输入缓冲区和输出缓冲区,所述第一加密数据和第一数据可以写入输入缓冲区,第二加密数据可以写入输出缓冲区。
由于本实施例基本相应于前述图1和图2所示的方法实施例,故本实施例的描述中未详尽之处,可以参见前述实施例中的相关说明,在此就不赘述了。
需要说明的是,本申请装置实施例和系统实施例中所涉及的模块、子模块和单元可以为软件,可以为硬件,也可以为软件和硬件的组合。
本申请可用于众多通用或专用的计算系统环境或配置中。例如:个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个......”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上对本申请所提供的一种SSL非阻塞通信的方法以及一种用于SSL非阻塞通信的服务器进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。
Claims (9)
1.一种SSL非阻塞通信的方法,其特征在于,包括:
步骤S101、服务器监听网络I/O事件,并获取所监听到网络I/O事件的类型;若为连接事件,则执行步骤S102;若为读事件,则执行步骤S103;若为写事件,则执行步骤S110;
步骤S102、依据所述连接事件注册读事件,返回步骤S101;
步骤S103、执行从网络中获取第一加密数据的读操作,并将所述第一加密数据写入预置的缓冲区中,转步骤S104;
步骤S104、依据预设的SSL握手过程获取当前握手状态,若所述握手状态为数据解密,则执行步骤S105;若所述握手状态为数据加密,则执行步骤S109;
步骤S105、对所述缓冲区中的第一加密数据进行解密,若解密成功,获得第一数据,则执行步骤S106,若解密不成功,则执行步骤S108;
步骤S106、判断解密获得的第一数据是否为客户端请求原文,若是,则结束本次SSL握手过程;若否,则执行步骤S107;
步骤S107、将所述第一数据写入缓冲区,并返回步骤S104;
步骤S108、注册读事件,并返回步骤S101;
步骤S109、对所述缓冲区中的第一数据进行加密,获得第二加密数据,注册写事件,返回步骤S101;
步骤S110、执行将所述缓冲区中的第二加密数据写入网络的写操作,转步骤S104;
在所述握手状态为任务执行操作时,所述的方法还包括:
步骤S111、执行当前握手任务,执行完后返回步骤S104。
2.如权利要求1所述的方法,其特征在于,所述第一加密数据包括加密的客户端请求原文或客户端加密的握手报文;所述第一数据为客户端请求原文或握手报文;所述第二加密数据为服务器加密的握手报文。
3.如权利要求2所述的方法,其特征在于,所述缓冲区包括输入缓冲区和输出缓冲区,所述步骤S103中的第一加密数据写入输入缓冲区,所述步骤S107中的第一数据写入输入缓冲区;
所述步骤S109为对输出缓冲区中的第一数据进行加密,在进行加密之前,还包括:从输入缓冲区中读出第一数据并写入输出缓冲区;
所述步骤S110为,执行将输出缓冲区中的第二加密数据写入网络的写操作。
4.如权利要求3所述的方法,其特征在于,所述步骤S105中对缓冲区中的第一加密数据进行解密的步骤具体包括:
从输入缓冲区中读指针的起始位置开始读取预设大小的第一加密数据;
对所读取的第一加密数据进行解密。
5.如权利要求4所述的方法,其特征在于,在所述步骤S107将第一数据写入输入缓冲区后,还包括:
将输入缓冲区中的读指针移至第一数据的首位。
6.如权利要求5所述的方法,其特征在于,在所述步骤S108,注册读事件之前还包括:
提示当前缓冲区的数据不足,将读指针移至输入缓冲区中经过解密处理的第一加密数据之后。
7.如权利要求6所述的方法,其特征在于,在所述步骤S109对第一数据进行加密之前,还包括:
将写指针移至写入输出缓冲区中的第一数据的首位。
8.如权利要求3所述的方法,其特征在于,所述步骤S109中将第一数据写入输出缓冲区的步骤为:
从输出缓冲区中写指针的起始位置开始在输出缓冲区中写入预设大小的第一数据。
9.一种用于SSL非阻塞通信的服务器,其特征在于,包括:
监听模块,用于监听网络I/O事件,并获取所监听到网络I/O事件的类型;若为连接事件,则触发连接事件处理模块;若为读事件,则触发读事件处理模块;若为写事件,则触发写事件处理模块;
连接事件处理模块,用于依据所述连接事件注册读事件,然后调用所述监听模块;
读事件处理模块,用于执行从网络中获取第一加密数据的读操作,并将所述第一加密数据写入预置的缓冲区中,然后触发握手控制模块;
握手控制模块,用于依据预设的SSL握手过程获取当前握手状态,若所述握手状态为数据解密,则触发解密操作模块;若所述握手状态为数据加密,则触发加密操作模块;
解密操作模块,用于对所述缓冲区中的第一加密数据进行解密,若解密成功,获得第一数据,则触发报文判断模块,若解密不成功,则触发读事件注册模块;
报文判断模块,用于判断解密获得的第一数据是否为客户端请求原文,若是,则触发结束模块;若否,则触发缓存写入模块;
结束模块,用于结束本次SSL握手过程;
缓存写入模块,用于将所述第一数据写入缓冲区,并调用握手控制模块;
读事件注册模块,用于注册读事件,并调用监听模块;
加密操作模块,用于对所述缓冲区中的第一数据进行加密,获得第二加密数据,注册写事件,然后调用监听模块;
写事件处理模块,用于执行将所述缓冲区中的第二加密数据写入网络的写操作,然后调用握手控制模块;
在所述握手状态为任务执行操作时,所述的服务器还包括:
任务执行模块,用于执行当前握手任务,执行完后调用握手控制模块。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110144979.6A CN102811201B (zh) | 2011-05-31 | 2011-05-31 | Ssl非阻塞通信方法及用于ssl非阻塞通信的服务器 |
HK13100662.2A HK1173581A1 (zh) | 2011-05-31 | 2013-01-16 | 非阻塞通信方法及用於 非阻塞通信的服務器 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110144979.6A CN102811201B (zh) | 2011-05-31 | 2011-05-31 | Ssl非阻塞通信方法及用于ssl非阻塞通信的服务器 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102811201A CN102811201A (zh) | 2012-12-05 |
CN102811201B true CN102811201B (zh) | 2015-06-03 |
Family
ID=47234779
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201110144979.6A Active CN102811201B (zh) | 2011-05-31 | 2011-05-31 | Ssl非阻塞通信方法及用于ssl非阻塞通信的服务器 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN102811201B (zh) |
HK (1) | HK1173581A1 (zh) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103093306A (zh) * | 2012-12-21 | 2013-05-08 | 大唐软件技术股份有限公司 | 一种业务数据协同处理方法和装置 |
CN104079398B (zh) * | 2013-03-28 | 2019-04-12 | 腾讯科技(深圳)有限公司 | 一种数据通信方法、装置及系统 |
CN104735023A (zh) * | 2013-12-18 | 2015-06-24 | 国家计算机网络与信息安全管理中心 | 一种高性能的ssl代理装置及其方法 |
CN104301333A (zh) * | 2014-11-05 | 2015-01-21 | 中国科学技术大学 | 非阻塞式握手实现方法及系统 |
CN104917817A (zh) * | 2015-04-23 | 2015-09-16 | 四川师范大学 | 客户端以及数据通信方法 |
CN108076106B (zh) * | 2016-11-15 | 2019-11-19 | 中国科学院声学研究所 | 一种面向云存储数据加解密的流式处理系统及方法 |
CN108228581B (zh) * | 2016-12-09 | 2022-06-28 | 阿里云计算有限公司 | Zookeeper兼容通信方法、服务器及系统 |
CN106936848A (zh) * | 2017-04-19 | 2017-07-07 | 武汉票据交易中心有限公司 | 一种服务器的socket加密通信方法 |
CN109639619A (zh) * | 2017-10-09 | 2019-04-16 | 北京安软天地科技有限公司 | 一种面向安全认证网关的大并发加密通讯算法 |
CN111212045A (zh) * | 2019-12-25 | 2020-05-29 | 四川盛趣时代网络科技有限公司 | 驱动层异步通信加密、解密传输方法及传输系统 |
CN112003767A (zh) * | 2020-08-14 | 2020-11-27 | 上海许继电气有限公司 | 一种模拟报文发送方法 |
CN112511530B (zh) * | 2020-11-26 | 2023-10-31 | 浪潮金融信息技术有限公司 | 一种对接SSLSocket通信的方法、装置及介质 |
CN114827035A (zh) * | 2022-05-05 | 2022-07-29 | 浪潮通信信息系统有限公司 | 一种网元通信方法、装置及计算机介质 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1642265A (zh) * | 2004-01-13 | 2005-07-20 | 北京中视联数字系统有限公司 | 一种数字电视网络系统的通讯方法 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7266703B2 (en) * | 2001-06-13 | 2007-09-04 | Itt Manufacturing Enterprises, Inc. | Single-pass cryptographic processor and method |
-
2011
- 2011-05-31 CN CN201110144979.6A patent/CN102811201B/zh active Active
-
2013
- 2013-01-16 HK HK13100662.2A patent/HK1173581A1/zh unknown
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1642265A (zh) * | 2004-01-13 | 2005-07-20 | 北京中视联数字系统有限公司 | 一种数字电视网络系统的通讯方法 |
Also Published As
Publication number | Publication date |
---|---|
CN102811201A (zh) | 2012-12-05 |
HK1173581A1 (zh) | 2013-05-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102811201B (zh) | Ssl非阻塞通信方法及用于ssl非阻塞通信的服务器 | |
EP3633913B1 (en) | Provisioning a secure connection using a pre-shared key | |
EP2166697B1 (en) | Method and system for authenticating a user by means of a mobile device | |
CN101916388B (zh) | 智能sd卡及利用该智能sd进行移动支付的方法 | |
CN107294709A (zh) | 一种区块链数据处理方法、装置及系统 | |
CN109688098B (zh) | 数据的安全通信方法、装置、设备及计算机可读存储介质 | |
CN101815091A (zh) | 密码提供设备、密码认证系统和密码认证方法 | |
CN102638568A (zh) | 云存储系统及其数据管理方法 | |
CN107800675A (zh) | 一种数据传输方法、终端以及服务器 | |
CN110378097A (zh) | 保障传感器数据安全 | |
CN105764051B (zh) | 认证方法、认证装置、移动设备及服务器 | |
CN101808077B (zh) | 信息安全输入处理系统和方法以及智能卡 | |
CN101819614A (zh) | 利用语音核验USBKey增强网络交易安全性的系统和方法 | |
JP2014503159A (ja) | 第2の通信装置を用いて第1の通信装置を認証する方法 | |
CN101304569A (zh) | 一种基于智能手机的移动认证系统 | |
CN102638346A (zh) | 一种用户数字证书的认证方法及装置 | |
CN105119894A (zh) | 基于硬件安全模块的通信系统及通信方法 | |
CN105391540A (zh) | 一种物联网安全系统、互联设备及实现方法 | |
CN111245607A (zh) | 一种组网方法及系统、配网设备、客户端和服务端 | |
WO2017050152A1 (zh) | 用于移动设备的密码安全系统及其密码安全输入方法 | |
CN105592431B (zh) | 基于iOS系统移动终端的短信加密系统 | |
JP2007058487A (ja) | ログイン情報管理装置及び方法 | |
CN105634720A (zh) | 加密安全配置文件 | |
CN110493265A (zh) | 加密数据的方法及存储介质 | |
CN107872315A (zh) | 数据处理方法和智能终端 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 1173581 Country of ref document: HK |
|
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: GR Ref document number: 1173581 Country of ref document: HK |