请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 1
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
详解Netty的安全性:原理介绍、代码演示(下篇)

接上篇


接上篇《详解Netty的安全性:原理介绍、代码演示(上篇)》。

2.2 SSL双向认证


2.2.1SSL双向认证开发


我们在2.1章节的基础上进行开发,与单向认证不同的是服务端也需要对客户端进行安全认证。这就意味着客户端的自签名证书也需要导入到服务端的数字证书仓库中。

首先,生成客户端的自签名证书:
keytool -export -alias smcc -keystore cChat.jks -storepass cNetty 
-file cChat.cer

最后,将客户端的自签名证书导入到服务端的信任证书仓库中:
keytool -import -trustcacerts -alias smcc -file cChat.cer -storepass 
sNetty -keystore sChat.jks

证书导入之后,需要对SSL客户端和服务端的代码同时进行修改,首先我们看下服务端如何修改。

由于服务端需要对客户端进行验证,因此在初始化服务端SSLContext的时候需要加载证书仓库。首先需要对TrustManagerFactory进行初始化,代码如下:
1.png

初始化SSLContext的时候根据TrustManagerFactory获取TrustManager数组,代码如下:
2.png

最后,创建SSLEngine之后,设置需要进行客户端认证,代码如下:
3.png

完成服务端修改之后,再回头看下客户端的修改,由于服务端需要认证客户端的证书,因此,需要初始化和加载私钥仓库,向服务端发送公钥,初始化KeyStore的代码如下:
4.png

初始化SSLContext的时候需要传入KeyManager数组,代码如下:
5.png

客户端开发完成之后,测试下程序是否能够正常工作,运行结果如下所示。

客户端运行结果:
6.png

服务端运行结果:
7.png

在客户端控制台进行输入,看SSL传输是否正常:
8.png

2.2.2SSL双向认证原理分析


SSL双向认证相比单向认证,多了一步服务端发送认证请求消息给客户端,客户端发送自签名证书给服务端进行安全认证的过程。下面,我们结合Netty SSL调测日志,对双向认证的差异点进行分析。

相比于客户端,服务端在发送ServerHello时携带了要求客户端认证的请求信息,如下所示:
*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Cert Authorities:
<CN=localhost>
<CN=localhost>
*** ServerHelloDone

客户端接收到服务端要求客户端认证的请求消息之后,发送自己的证书信息给服务端,信息如下:
matching alias: smcc
*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: CN=localhost
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

  Key:  Sun RSA public key, 2048 bits
  modulus: 212639695562264078962258083015763969567082142460170954053624074
53705267323050920051941696590911289892005894127848317880153980200067657563
15944918691324084822137929027919841383304228071408660098765703368443353862
47349919704780645114810932016343908989985053434023995248208445566727867691
73042913746571760169661698040844437316556983406538131853892449014877947773
16977794500345715634646402492099542466990685058179767825995777860790787074
72339147926907851214779520246763960901175126351376922481444497141021631392
59603124160944922844840171133151822882039207352509182052426500279100525773
147139994269292585983679425433429361
  public exponent: 65537
  Validity: [From: Sun Jul 27 08:50:35 CST 2014,
               To: Mon Jul 27 08:50:35 CST 2015]
  Issuer: CN=localhost
  SerialNumber: [    53d44cdb]

服务端对客户端的自签名证书进行认证,信息如下:
***
Found trusted certificate:
[
[
  Version: V3
  Subject: CN=localhost
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

  Key:  Sun RSA public key, 2048 bits
  modulus: 21263969556226407896225808301576396956708214246017095405362407
4537052673230509200519416965909112898920058941278483178801539802000676575
6315944918691324084822137929027919841383304228071408660098765703368443353
8624734991970478064511481093201634390898998505343402399524820844556672786
7691730429137465717601696616980408444373165569834065381318538924490148779
4777316977794500345715634646402492099542466990685058179767825995777860790
7870747233914792690785121477952024676396090117512635137692248144449714102
1631392596031241609449228448401711331518228820392073525091820524265002791
00525773147139994269292585983679425433429361
  public exponent: 65537
  Validity: [From: Sun Jul 27 08:50:35 CST 2014,
               To: Mon Jul 27 08:50:35 CST 2015]
  Issuer: CN=localhost
  SerialNumber: [    53d44cdb]

2.3 第三方CA认证


使用jdk keytool生成的数字证书是自签名的。自签名就是指证书只能保证自己是完整且没有经过非法修改,但是无法保证这个证书是属于谁的。为了对自签名证书进行认证,需要每个客户端和服务端都交换自己自签名的私有证书,对于一个大型网站或者应用服务器,这种工作量是非常大的。

基于自签名的SSL双向认证,只要客户端或者服务端修改了密钥和证书,就需要重新进行签名和证书交换,这种调试和维护工作量是非常大的。因此,在实际的商用系统中往往会使用第三方CA证书颁发机构进行签名和验证。我们的浏览器就保存了几个常用的CA_ROOT。每次连接到网站时只要这个网站的证书是经过这些CA_ROOT签名过的。就可以通过验证了。

CA数字证书认证服务往往是收费的,国内有很多数字认证中心都提供相关的服务,如下所示:
a.png

作为示例,我们自己生成一个CA_ROOT的密钥对,部署应用时,把这个CA_ROOT的私钥部署在所有需要SSL传输的节点就可以完成安全认证。作为示例,如果要生成CA_ROOT,我们使用开源的OpenSSL。

在Windows上安装和使用OpenSSL网上有很多教程,也不是本文的重点,因此,OpenSSL的安装和使用本文不详细介绍。

下面我们对基于第三方CA认证的步骤进行详细介绍。

2.3.1服务端证书制作


步骤1:利用OpenSSL生成CA证书:
openssl req -new -x509 -keyout ca.key -out ca.crt -days 365

步骤2:生成服务端密钥对:
keytool -genkey -alias securechat -keysize 2048 -validity 365 
-keyalg RSA -dname "CN=localhost" -keypass sNetty -storepass sNetty
 -keystore sChat.jks

步骤3:生成证书签名请求:
keytool -certreq -alias securechat -sigalg MD5withRSA -file  sChat.csr 
-keypass sNetty -storepass sNetty -keystore sChat.jks

步骤4:用CA私钥进行签名:
openssl ca -in sChat.csr -out sChat.crt -cert ca.crt -keyfile ca.key -notext

步骤5:导入信任的CA根证书到keystore:
keytool -import -v -trustcacerts -alias ca_root -file ca.crt -storepass 
sNetty -keystore sChat.jks

步骤6:将CA签名后的server端证书导入keystore:
keytool -import -v -alias securechat -file server.crt -keypass sNetty 
-storepass sNetty -keystore sChat.jks

2.3.2客户端证书制作


步骤1:生成客户端密钥对:
keytool -genkey -alias smcc -keysize 2048 -validity 365 -keyalg 
RSA -dname "CN=localhost" -keypass cNetty -storepass cNetty -keystore cChat.jks

步骤2:生成证书签名请求:
keytool -certreq -alias smcc -sigalg MD5withRSA -file  cChat.csr 
-keypass cNetty -storepass cNetty -keystore cChat.jks

步骤3:用CA私钥进行签名:
openssl ca -in cChat.csr -out cNetty.crt -cert ca.crt -keyfile ca.key -notext

步骤4:导入信任的CA根证书到keystore:
keytool -import -v -trustcacerts -alias ca_root -file ca.crt 
-storepass cNetty -keystore cChat.jks

步骤5:将CA签名后的client端证书导入keystore:
keytool -import -v -alias smcc -file cNetty.crt -keypass cNetty -storepass 
cNetty -keystore cChat.jks

2.3.3开发和测试


基于CA认证的开发和测试与SSL双向和单向认证代码相同,此处不再赘述。

3. Netty SSL源码分析


3.1 SSL客户端


当客户端和服务端的TCP链路建立成功之后,SslHandler的channelActive被触发,SSL客户端通过SSL引擎发起握手请求消息,代码如下:
1.png

发起握手请求之后,需要将SSLEngine创建的握手请求消息进行SSL编码,发送给服务端,因此,握手之后立即调用wrapNonAppData方法,下面具体对该方法进行分析:
2.png

因为只需要发送握手请求消息,因此Source ByteBuf为空,下面看下wrap方法的具体实现:
3.png

将SSL引擎中创建的握手请求消息编码到目标ByteBuffer中,然后对写索引进行更新。判断写入操作是否越界,如果越界说明out容量不足,需要调用ensureWritable对ByteBuf进行动态扩展,扩展之后继续尝试编码操作。如果编码成功,返回SSL引擎操作结果。

对编码结果进行判断,如果编码字节数大于0,则将编码后的结果发送给服务端,然后释放临时变量out。

判断SSL引擎的操作结果,SSL引擎的操作结果定义如下:
  • FINISHED:SSLEngine 已经完成握手;
  • NEED_TASK:SSLEngine 在继续进行握手前需要一个(或多个)代理任务的结果;
  • NEED_UNWRAP:在继续进行握手前,SSLEngine 需要从远端接收数据,所以应带调用SSLEngine.unwrap();
  • NEED_WRAP:在继续进行握手前,SSLEngine 必须向远端发送数据,所以应该调用 SSLEngine.wrap();
  • NOT_HANDSHAKING:SSLEngine 当前没有进行握手。

下面我们分别对5种操作的代码进行分析:
1.png

如果握手成功,则设置handshakePromise的操作结果为成功,同时发送SslHandshakeCompletionEvent.SUCCES给SSL监听器,代码如下:
2.png

如果是NEED_TASK,说明异步执行SSL Task,完成后续可能耗时的操作或者任务,Netty封装了一个任务立即执行线程池专门处理SSL的代理任务,代码如下:
3.png

如果是NEED_UNWRAP,则判断是否由UNWRAP发起,如果不是则执行UNWRAP操作。

如果是NOT_HANDSHAKING,则调用unwrap,继续接收服务端的消息。

服务端应答消息的接收跟服务端接收客户端的代码类似,唯一不同之处在于SSL引擎的客户端模式设置不同,一个是服务端,一个是客户端。上层的代码处理是相同的,下面我们在SSL服务端章节分析握手消息的接收。

3.2 SSL服务端


SSL服务端接收客户端握手请求消息的入口方法是decode方法,下面对它进行详细分析。

首先获取接收缓冲区的读写索引,并对读取的偏移量指针进行备份:
1.png

对半包标识进行判断,如果上一个消息是半包消息,则判断当前可读的字节数是否小于整包消息的长度,如果小于整包长度,则说明本次读取操作仍然没有把SSL整包消息读取完整,需要返回IO线程继续读取,代码如下:
2.png

如果消息读取完整,则修改偏移量:同时置位半包长度标识。
3.png

下面在for循环中读取SSL消息,因为TCP存在拆包和粘包,因此一个ByteBuf可能包含多条完整的SSL消息。

首先判断可读的字节数是否小于协议消息头长度,如果是则退出循环继续由IO线程接收后续的报文:
4.png

获取SSL消息包的报文长度,具体算法不再介绍,可以参考SSL的规范文档进行解读,代码如下:
5.png

对长度进行判断,如果SSL报文长度大于可读的字节数,说明是个半包消息,将半包标识长度置位,返回IO线程继续读取后续的数据报,代码如下:
6.png

对消息进行解码,将SSL加密的消息解码为加密前的原始数据,unwrap方法如下:
7.png

调用SSLEngine的unwrap方法对SSL原始消息进行解码,对解码结果进行判断,如果越界,说明out缓冲区不够,需要进行动态扩展。如果是首次越界,为了尽量节约内存,使用SSL最大缓冲区长度和SSL原始缓冲区可读的字节数中较小的。如果再次发生缓冲区越界,说明扩张后的缓冲区仍然不够用,直接使用SSL缓冲区的最大长度,保证下次解码成功。

解码成功之后,对SSL引擎的操作结果进行判断:如果需要继续接收数据,则继续执行解码操作;如果需要发送握手消息,则调用wrapNonAppData发送握手消息;如果需要异步执行SSL代理任务,则调用立即执行线程池执行代理任务;如果是握手成功,则设置SSL操作结果,发送SSL握手成功事件;如果是应用层的业务数据,则继续执行解码操作,其它操作结果,抛出操作类型异常。
8.png

需要指出的是,SSL客户端和服务端接收对方SSL握手消息的代码是相同的,那为什么SSL服务端和客户端发送的握手消息不同呢?这些是SSL引擎负责区分和处理的,我们在创建SSL引擎的时候设置了客户端模式,SSL引擎就是根据这个来进行区分的,代码如下:
9.png

无论客户端还是服务端,只需要围绕SSL引擎的操作结果进行编程即可。

3.3 SSL消息读取


SSL的消息读取实际就是ByteToMessageDecoder将接收到的SSL加密后的报文解码为原始报文,然后将整包消息投递给后续的消息解码器,对消息做二次解码。基于SSL的消息解码模型如下:
1.png

SSL消息读取的入口都是decode,因为是非握手消息,它的处理非常简单,就是循环调用引擎的unwrap方法,将SSL报文解码为原始的报文,代码如下:
2.png

握手成功之后的所有消息都是应用数据,因此它的操作结果为NOT_HANDSHAKING,遇到此标识之后继续读取消息,直到没有可读的字节,退出循环,代码如下:
3.png

如果读取到了可用的字节,则将读取到的缓冲区加到输出结果列表中,代码如下:
4.png

ByteToMessageDecoder判断解码结果List,如果非空,则循环调用后续的Handler,由后续的解码器对解密后的报文进行二次解码。

3.4 SSL消息发送


SSL消息发送时,由SslHandler对消息进行编码,编码后的消息实际就是SSL加密后的消息,它的入口是flush方法,代码如下:
1.png

从待加密的消息队列中弹出消息,调用SSL引擎的wrap方法进行编码,代码如下:
2.png

wrap方法很简单,就是调用SSL引擎的编码方法,然后对写索引进行修改,如果缓冲区越界,则动态扩展缓冲区:
3.png

对SSL操作结果进行判断,因为已经握手成功,因此返回的结果是NOT_HANDSHAKING,执行finishWrap方法,调用ChannelHandlerContext的write方法,将消息写入发送缓冲区中,如果待发送的消息为空,则构造空的ByteBuf写入:
4.png

编码后,调用ChannelHandlerContext的flush方法消息发送给对方,代码如下:
ctx.flush();

4.作者简介


111648elfbgg6nx4x2i6if.jpg 李林锋

2007年毕业于东北大学,2008年进入华为公司从事高性能通信软件的设
计和开发工作,有6年NIO设计和开发经验,精通Netty、Mina等NIO框架。
Netty中国社区创始人,《Netty权威指南》作者。
联系方式:新浪微博 Nettying 微信:Nettying。

全站即时通讯技术资料分类


[1] 网络编程基础资料:
TCP/IP详解 - 第11章·UDP:用户数据报协议
TCP/IP详解 - 第17章·TCP:传输控制协议
TCP/IP详解 - 第18章·TCP连接的建立与终止
TCP/IP详解 - 第21章·TCP的超时与重传
技术往事:改变世界的TCP/IP协议(珍贵多图、手机慎点)
通俗易懂-深入理解TCP协议(上):理论基础
通俗易懂-深入理解TCP协议(下):RTT、滑动窗口、拥塞处理
理论经典:TCP协议的3次握手与4次挥手过程详解
理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程
计算机网络通讯协议关系图(中文珍藏版)
UDP中一个包的大小最大能多大?
P2P技术详解(一):NAT详解——详细原理、P2P简介
P2P技术详解(二):P2P中的NAT穿越(打洞)方案详解
P2P技术详解(三):P2P技术之STUN、TURN、ICE详解
通俗易懂:快速理解P2P技术中的NAT穿透原理
高性能网络编程(一):单台服务器并发TCP连接数到底可以有多少
高性能网络编程(二):上一个10年,著名的C10K并发连接问题
高性能网络编程(三):下一个10年,是时候考虑C10M并发问题了
高性能网络编程(四):从C10K到C10M高性能网络应用的理论探索
不为人知的网络编程(一):浅析TCP协议中的疑难杂症(上篇)
不为人知的网络编程(二):浅析TCP协议中的疑难杂症(下篇)
不为人知的网络编程(三):关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT
不为人知的网络编程(四):深入研究分析TCP的异常关闭
不为人知的网络编程(五):UDP的连接性和负载均衡
不为人知的网络编程(六):深入地理解UDP协议并用好它
网络编程懒人入门(一):快速理解网络通信协议(上篇)
网络编程懒人入门(二):快速理解网络通信协议(下篇)
网络编程懒人入门(三):快速理解TCP协议一篇就够
网络编程懒人入门(四):快速理解TCP和UDP的差异
Netty干货分享:京东京麦的生产级TCP网关技术实践总结
>> 更多同类文章 ……

[2] NIO异步网络编程资料:
Java新一代网络编程模型AIO原理及Linux系统AIO介绍
有关“为何选择Netty”的11个疑问及解答
开源NIO框架八卦——到底是先有MINA还是先有Netty?
选Netty还是Mina:深入研究与对比(一)
选Netty还是Mina:深入研究与对比(二)
NIO框架入门(一):服务端基于Netty4的UDP双向通信Demo演示
NIO框架入门(二):服务端基于MINA2的UDP双向通信Demo演示
NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战
NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战
Netty 4.x学习(一):ByteBuf详解
Netty 4.x学习(二):Channel和Pipeline详解
Netty 4.x学习(三):线程模型详解
Apache Mina框架高级篇(一):IoFilter详解
Apache Mina框架高级篇(二):IoHandler详解
MINA2 线程原理总结(含简单测试实例)
Apache MINA2.0 开发指南(中文版)[附件下载]
MINA、Netty的源代码(在线阅读版)已整理发布
解决MINA数据传输中TCP的粘包、缺包问题(有源码)
解决Mina中多个同类型Filter实例共存的问题
实践总结:Netty3.x升级Netty4.x遇到的那些坑(线程篇)
实践总结:Netty3.x VS Netty4.x的线程模型
详解Netty的安全性:原理介绍、代码演示(上篇)
详解Netty的安全性:原理介绍、代码演示(下篇)
详解Netty的优雅退出机制和原理
NIO框架详解:Netty的高性能之道
Twitter:如何使用Netty 4来减少JVM的GC开销(译文)
绝对干货:基于Netty实现海量接入的推送服务技术要点
Netty干货分享:京东京麦的生产级TCP网关技术实践总结
>> 更多同类文章 ……

[3] 有关IM/推送的通信格式、协议的选择:
简述传输层协议TCP和UDP的区别
为什么QQ用的是UDP协议而不是TCP协议?
移动端即时通讯协议选择:UDP还是TCP?
如何选择即时通讯应用的数据传输格式
强列建议将Protobuf作为你的即时通讯应用数据传输格式
全方位评测:Protobuf性能到底有没有比JSON快5倍?
移动端IM开发需要面对的技术问题(含通信协议选择)
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
理论联系实际:一套典型的IM通信协议设计详解
58到家实时消息系统的协议设计等技术实践分享
详解如何在NodeJS中使用Google的Protobuf
>> 更多同类文章 ……

[4] 有关IM/推送的心跳保活处理:
应用保活终极总结(一):Android6.0以下的双进程守护保活实践
应用保活终极总结(二):Android6.0及以上的保活实践(进程防杀篇)
应用保活终极总结(三):Android6.0及以上的保活实践(被杀复活篇)
Android进程保活详解:一篇文章解决你的所有疑问
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
深入的聊聊Android消息推送这件小事
为何基于TCP协议的移动端IM仍然需要心跳保活机制?
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
>> 更多同类文章 ……

[5] 有关WEB端即时通讯开发:
新手入门贴:史上最全Web端即时通讯技术原理详解
Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE
SSE技术详解:一种全新的HTML5服务器推送事件技术
Comet技术详解:基于HTTP长连接的Web端实时通信技术
新手快速入门:WebSocket简明教程
WebSocket详解(一):初步认识WebSocket技术
WebSocket详解(二):技术原理、代码演示和应用案例
WebSocket详解(三):深入WebSocket通信协议细节
socket.io实现消息推送的一点实践及思路
LinkedIn的Web端即时通讯实践:实现单机几十万条长连接
Web端即时通讯技术的发展与WebSocket、Socket.io的技术实践
Web端即时通讯安全:跨站点WebSocket劫持漏洞详解(含示例代码)
开源框架Pomelo实践:搭建Web端高性能分布式IM聊天服务器
使用WebSocket和SSE技术实现Web端消息推送
详解Web端通信方式的演进:从Ajax、JSONP 到 SSE、Websocket
>> 更多同类文章 ……

[6] 有关IM架构设计:
浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)
一套原创分布式即时通讯(IM)系统理论架构方案
从零到卓越:京东客服即时通讯系统的技术架构演进历程
蘑菇街即时通讯/IM服务器开发之架构选择
腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
微信后台基于时间序的海量数据冷热分级架构设计实践
微信技术总监谈架构:微信之道——大道至简(演讲全文)
如何解读《微信技术总监谈架构:微信之道——大道至简》
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
17年的实践:腾讯海量产品的技术方法论
移动端IM中大规模群消息的推送如何保证效率、实时性?
现代IM系统中聊天消息的同步和存储方案探讨
>> 更多同类文章 ……

[7] 有关IM安全的文章:
即时通讯安全篇(一):正确地理解和使用Android端加密算法
即时通讯安全篇(二):探讨组合加密算法在IM中的应用
即时通讯安全篇(三):常用加解密算法与通讯安全讲解
即时通讯安全篇(四):实例分析Android中密钥硬编码的风险
即时通讯安全篇(五):对称加密技术在Android平台上的应用实践
即时通讯安全篇(六):非对称加密技术的原理与应用实践
传输层安全协议SSL/TLS的Java平台实现简介和Demo演示
理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享
简述实时音视频聊天中端到端加密(E2EE)的工作原理
移动端安全通信的利器——端到端加密(E2EE)技术详解
Web端即时通讯安全:跨站点WebSocket劫持漏洞详解(含示例代码)
通俗易懂:一篇掌握即时通讯的消息传输安全原理
>> 更多同类文章 ……

[8] 有关实时音视频开发:
专访微信视频技术负责人:微信实时视频聊天技术的演进
即时通讯音视频开发(一):视频编解码之理论概述
即时通讯音视频开发(二):视频编解码之数字视频介绍
即时通讯音视频开发(三):视频编解码之编码基础
即时通讯音视频开发(四):视频编解码之预测技术介绍
即时通讯音视频开发(五):认识主流视频编码技术H.264
即时通讯音视频开发(六):如何开始音频编解码技术的学习
即时通讯音视频开发(七):音频基础及编码原理入门
即时通讯音视频开发(八):常见的实时语音通讯编码标准
即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述
即时通讯音视频开发(十):实时语音通讯的回音消除技术详解
即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解
即时通讯音视频开发(十二):多人实时音视频聊天架构探讨
即时通讯音视频开发(十三):实时视频编码H.264的特点与优势
即时通讯音视频开发(十四):实时音视频数据传输协议介绍
即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况
即时通讯音视频开发(十六):移动端实时音视频开发的几个建议
即时通讯音视频开发(十七):视频编码H.264、VP8的前世今生
实时语音聊天中的音频处理与编码压缩技术简述
网易视频云技术分享:音频处理与压缩技术快速入门
学习RFC3550:RTP/RTCP实时传输协议基础知识
简述开源实时音视频技术WebRTC的优缺点
良心分享:WebRTC 零基础开发者教程(中文)
开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用
基于RTMP数据传输协议的实时流媒体技术研究(论文全文)
声网架构师谈实时音视频云的实现难点(视频采访)
浅谈开发实时视频直播平台的技术要点
还在靠“喂喂喂”测试实时语音通话质量?本文教你科学的评测方法!
实现延迟低于500毫秒的1080P实时音视频直播的实践分享
移动端实时视频直播技术实践:如何做到实时秒开、流畅不卡
如何用最简单的方法测试你的实时音视频方案
技术揭秘:支持百万级粉丝互动的Facebook实时视频直播
简述实时音视频聊天中端到端加密(E2EE)的工作原理
移动端实时音视频直播技术详解(一):开篇
移动端实时音视频直播技术详解(二):采集
移动端实时音视频直播技术详解(三):处理
移动端实时音视频直播技术详解(四):编码和封装
移动端实时音视频直播技术详解(五):推流和传输
移动端实时音视频直播技术详解(六):延迟优化
理论联系实际:实现一个简单地基于HTML5的实时视频直播
IM实时音视频聊天时的回声消除技术详解
浅谈实时音视频直播中直接影响用户体验的几项关键技术指标
如何优化传输机制来实现实时音视频的超低延迟?
首次披露:快手是如何做到百万观众同场看直播仍能秒开且不卡顿的?
实时通信RTC技术栈之:视频编解码
开源实时音视频技术WebRTC在Windows下的简明编译教程
Android直播入门实践:动手搭建一套简单的直播系统
>> 更多同类文章 ……

[9] IM开发综合文章:
移动端IM中大规模群消息的推送如何保证效率、实时性?
移动端IM开发需要面对的技术问题
开发IM是自己设计协议用字节流好还是字符流好?
请问有人知道语音留言聊天的主流实现方式吗?
IM消息送达保证机制实现(一):保证在线实时消息的可靠投递
IM消息送达保证机制实现(二):保证离线消息的可靠投递
如何保证IM实时消息的“时序性”与“一致性”?
一个低成本确保IM消息时序的方法探讨
IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?
IM群聊消息如此复杂,如何保证不丢不重?
谈谈移动端 IM 开发中登录请求的优化
移动端IM登录时拉取数据如何作到省流量?
浅谈移动端IM的多点登陆和消息漫游原理
完全自已开发的IM该如何设计“失败重试”机制?
通俗易懂:基于集群的移动端IM接入层负载均衡方案分享
微信对网络影响的技术试验及分析(论文全文)
即时通讯系统的原理、技术和应用(技术论文)
开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀
QQ音乐团队分享:Android中的图片压缩技术详解(上篇)
QQ音乐团队分享:Android中的图片压缩技术详解(下篇)
腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(上篇)
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(下篇)
如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源
基于社交网络的Yelp是如何实现海量用户图片的无损压缩的?
>> 更多同类文章 ……

[10] 开源移动端IM技术框架资料:
开源移动端IM技术框架MobileIMSDK:快速入门
开源移动端IM技术框架MobileIMSDK:常见问题解答
开源移动端IM技术框架MobileIMSDK:压力测试报告
>> 更多同类文章 ……

[11] 有关推送技术的文章:
iOS的推送服务APNs详解:设计思路、技术原理及缺陷等
信鸽团队原创:一起走过 iOS10 上消息推送(APNS)的坑
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
扫盲贴:认识MQTT通信协议
一个基于MQTT通信协议的完整Android推送Demo
IBM技术经理访谈:MQTT协议的制定历程、发展现状等
求教android消息推送:GCM、XMPP、MQTT三种方案的优劣
移动端实时消息推送技术浅析
扫盲贴:浅谈iOS和Android后台实时消息推送的原理和区别
绝对干货:基于Netty实现海量接入的推送服务技术要点
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
为何微信、QQ这样的IM工具不使用GCM服务推送消息?
极光推送系统大规模高并发架构的技术实践分享
从HTTP到MQTT:一个基于位置服务的APP数据通信实践概述
魅族2500万长连接的实时消息推送架构的技术实践分享
专访魅族架构师:海量长连接的实时消息推送系统的心得体会
深入的聊聊Android消息推送这件小事
基于WebSocket实现Hybrid移动应用的消息推送实践(含代码示例)
一个基于长连接的安全可扩展的订阅/推送服务实现思路
实践分享:如何构建一套高可用的移动端消息推送系统?
Go语言构建千万级在线的高并发消息推送系统实践(来自360公司)
腾讯信鸽技术分享:百亿级实时消息推送的实战经验
百万在线的美拍直播弹幕系统的实时推送技术实践之路
>> 更多同类文章 ……

[12] 更多即时通讯技术好文分类:
http://www.52im.net/forum.php?mod=collection&op=all

(原文链接:http://www.infoq.com/cn/articles/netty-security
- (全篇完) -

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:详解Netty的安全性:原理介绍、代码演示(上篇)下一篇:常见TCP/UDP端口号大全

本帖已收录至以下技术专辑

推荐方案
评论 1
学习学习
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部