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

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

1. Netty面临的安全风险


作为一个高性能的NIO通信框架,基于Netty的行业应用非常广泛,不同的行业、不同的应用场景,面临的安全挑战也不同,下面我们根据Netty的典型应用场景,分析下Netty面临的安全挑战。

1.1 仅限内部使用的RPC通信框架


随着业务的发展,网站规模的扩大,传统基于MVC的垂直架构已经无法应对业务的快速发展。需要对数据和业务进行水平拆分,基于RPC的分布式服务框架成为最佳选择。

业务水平拆分之后,内部的各个模块需要进行高性能的通信,传统基于RMI和Hession的同步阻塞式通信已经无法满足性能和可靠性要求。因此,高性能的NIO框架成为构建分布式服务框架的基石。

网站的架构演进过程如下:
1.png

高性能的RPC框架,各模块之间往往采用长连接通信,通过心跳检测保证链路的可靠性。由于RPC框架通常是在内部各模块之间使用,运行在授信的内部安全域中,不直接对外开放接口。因此,不需要做握手、黑白名单、SSL/TLS等,正所谓是“防君子不防小人”。

在这种应用场景下,Netty的安全性是依托企业的防火墙、安全加固操作系统等系统级安全来保障的,它自身并不需要再做额外的安全性保护工作。

1.2 对第三方开放的通信框架


如果使用Netty做RPC框架或者私有协议栈,RPC框架面向非授信的第三方开放,例如将内部的一些能力通过服务对外开放出去,此时就需要进行安全认证,如果开放的是公网IP,对于安全性要求非常高的一些服务,例如在线支付、订购等,需要通过SSL/TLS进行通信。

它的原理图如下:
2.png

对第三方开放的通信框架的接口调用存在三种场景:
  • 在企业内网,开放给内部其它模块调用的服务,通常不需要进行安全认证和SSL/TLS传输;
  • 在企业内网,被外部其它模块调用的服务,往往需要利用IP黑白名单、握手登陆等方式进行安全认证,认证通过之后双方使用普通的Socket进行通信,如果认证失败,则拒绝客户端连接;
  • 开放给企业外部第三方应用访问的服务,往往需要监听公网IP(通常是防火墙的IP地址),由于对第三方服务调用者的监管存在诸多困难,或者无法有效监管,这些第三方应用实际是非授信的。为了有效应对安全风险,对于敏感的服务往往需要通过SSL/TLS进行安全传输。

1.3 应用层协议的安全性


作为高性能、异步事件驱动的NIO框架,Netty非常适合构建上层的应用层协议,相关原理,如下图所示:
3.png

由于绝大多数应用层协议都是公有的,这意味着底层的Netty需要向上层提供通信层的安全传输,也就是需要支持SSL/TLS。

JDK的安全类库提供了javax.net.ssl.SSLSocket和javax.net.ssl.SSLServerSocket类库用于支持SSL/TLS安全传输,对于NIO非阻塞Socket通信,JDK并没有提供现成可用的类库简化用户开发。Netty通过JDK的SSLEngine,以SslHandler的方式提供对SSL/TLS安全传输的支持,极大的简化了用户的开发工作量,降低开发难度。

对于Netty默认提供的HTTP协议,Netty利用SslHandler,同样支持HTTPS协议。

2. Netty SSL开发


2.1. SSL单向认证


单向认证,即客户端只验证服务端的合法性,服务端不验证客户端。下面我们通过Netty的SSL单向认证代码开发来掌握基于Netty的SSL单向认证。

2.1.1SSL单向认证开发


首先,利用JDK的keytool工具,Netty服务端依次生成服务端的密钥对和证书仓库、服务端自签名证书。

生成Netty服务端私钥和证书仓库命令:

keytool -genkey -alias securechat -keysize 2048 -validity
365 -keyalg RSA -dname "CN=localhost" -keypass sNetty
-storepass sNetty -keystore sChat.jks


生成Netty服务端自签名证书:

keytool -export -alias securechat -keystore sChat.jks -storepass sNetty -file sChat.cer


生成客户端的密钥对和证书仓库,用于将服务端的证书保存到客户端的授信证书仓库中,命令如下:

keytool -genkey -alias smcc -keysize 2048 -validity 365
-keyalg RSA -dname "CN=localhost" -keypass cNetty
-storepass cNetty -keystore cChat.jks


随后,将Netty服务端的证书导入到客户端的证书仓库中,命令如下:

keytool -import -trustcacerts -alias securechat -file sChat.cer -storepass cNetty -keystore cChat.jks


上述工作完成之后,我们就开始编写SSL服务端和客户端的代码,下面我们对核心代码进行讲解。首先看服务端的代码,在TCP链路初始化的时候,创建SSLContext并对其进行正确的初始化,下面我们对SSLContext的创建进行讲解。

因为是客户端认证服务端,因此服务端需要正确的设置和加载私钥仓库KeyStore,相关代码如下:
1.png

初始化KeyManagerFactory之后,创建SSLContext并初始化,代码如下:
2.png

由于是单向认证,服务端不需要验证客户端的合法性,因此,TrustManager为空,安全随机数不需要设置,使用JDK默认创建的即可。

服务端的SSLContext创建完成之后,利用SSLContext创建SSL引擎SSLEngine,设置SSLEngine为服务端模式,由于不需要对客户端进行认证,因此NeedClientAuth不需要额外设置,使用默认值False。相关代码如下:
3.png

SSL服务端创建完成之后,下面继续看客户端的创建,它的原理同服务端类似,也是在初始化TCP链路的时候创建并设置SSLEngine,代码如下:
4.png

由于是客户端认证服务端,因此,客户端只需要加载存放服务端CA的证书仓库即可。

加载证书仓库完成之后,初始化SSLContext,代码如下:对于客户端只需要设置信任证书TrustManager。
5.png

客户端SSLContext初始化完成之后,创建SSLEngine并将其设置为客户端工作模式,代码如下:
6.png

将SslHandler添加到pipeline中,利用SslHandler实现Socket安全传输,代码如下:
7.png

客户端和服务端创建完成之后,测试下SSL单向认证功能是否OK,为了查看SSL握手过程,我们打开SSL握手的调测日志,Eclipse设置如下:
8.png

分别运行服务端和客户端,运行结果如下。

客户端SSL握手日志:
x.png

服务端SSL握手日志:
y.png

在客户端输入信息,服务端原样返回,测试结果如下:
1.png

到此,Netty SSL单向认证已经开发完成,下个小节我们将结合SSL握手日志,详细解读下SSL单向认证的原理。

2.1.2SSL单向认证原理分析


SSL单向认证的过程总结如下:
  • SSL客户端向服务端传送客户端SSL协议的版本号、支持的加密算法种类、产生的随机数,以及其它可选信息;
  • 服务端返回握手应答,向客户端传送确认SSL协议的版本号、加密算法的种类、随机数以及其它相关信息;
  • 服务端向客户端发送自己的公钥;
  • 客户端对服务端的证书进行认证,服务端的合法性校验包括:证书是否过期、发行服务器证书的CA是否可靠、发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”、服务器证书上的域名是否和服务器的实际域名相匹配等;
  • 客户端随机产生一个用于后面通讯的“对称密码”,然后用服务端的公钥对其加密,将加密后的“预主密码”传给服务端;
  • 服务端将用自己的私钥解开加密的“预主密码”,然后执行一系列步骤来产生主密码;
  • 客户端向服务端发出信息,指明后面的数据通讯将使用主密码为对称密钥,同时通知服务器客户端的握手过程结束;
  • 服务端向客户端发出信息,指明后面的数据通讯将使用主密码为对称密钥,同时通知客户端服务器端的握手过程结束;
  • SSL的握手部分结束,SSL安全通道建立,客户端和服务端开始使用相同的对称密钥对数据进行加密,然后通过Socket进行传输。


下面,我们结合JDK的SSL工作原理对Netty的SSL单向认证过程进行讲解,首先,我们看下JDK SSL单向认证的流程图:
2.png

下面结合JDK SSL引擎的调测日志信息我们对SSL单向认证的流程进行详细讲解,对于比较简单的流程会进行步骤合并。

步骤1:客户端使用TLS协议版本发送一个ClientHello消息,这个消息包含一个随机数、建议的加密算法套件和压缩方法列表,如下所示:
*** ClientHello, TLSv1
RandomCookie:  GMT: 1389796107 bytes = { 125, 107, 138, 150, 226, 182, 238, 75, 38, 
150, 222, 147, 127, 35, 36, 149, 172, 128, 152, 34, 110, 104, 176, 34, 180, 118, 185, 55 }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
 TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,
 TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, 
TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
 SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, 
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5,
 TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, 
sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1,
 sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, 
sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]

步骤2:服务端使用ServerHello消息来响应,这个消息包含由客户提供的信息基础上的另一个随机数和一个可选的会话ID,以及服务端选择的加密套件算法,响应消息如下:
*** ServerHello, TLSv1
RandomCookie:  GMT: 1389796108 bytes = { 27, 170, 76, 238, 56, 58, 172, 146, 
41, 159, 249, 213, 16, 214, 53, 167, 50, 74, 39, 107, 121, 63, 80, 26, 210, 149, 249, 194 }
Session ID:  {83, 215, 155, 12, 122, 5, 231, 3, 13, 11, 17, 204, 56, 73, 119,
 49, 85, 229, 220, 92, 55, 40, 25, 194, 198, 244, 200, 6, 55, 209, 23, 245}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***

步骤3:服务端发送自签名的证书消息,包含完整的证书链:
*** 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: 180074092335949740506599932729136061127910704822256890304785299212
89120399567693292155689698972062026646025485683710348109589875614228688670418
26997320367322716218554750309434289655244757299259864742384047112657948157239
74656070231306588457907121768485493115189644689102055777319298694358710534010
07782509767857568645054682957874162480829502504137753701941108204165639642395
91445925708790136700350526512926021140926345621403182628994210668730957728483
67874786322927437079881769937503767679525485790533062220506746478912515940552
94347989837561879359652740344329755331698082706888032724267649830488014296906
294110074041
  public exponent: 65537
  Validity: [From: Sun Jul 27 08:49:30 CST 2014,
               To: Mon Jul 27 08:49:30 CST 2015]
  Issuer: CN=localhost
  SerialNumber: [    53d44c9a]

]
  Algorithm: [SHA1withRSA]
  Signature:
0000: 10 05 5E D4 EE A8 1C 8E   82 F1 3F 6B 0A 34 9B 96  ..^.......?k.4..
0010: 97 BE 62 13 F7 2E 94 74   A5 46 CC AB C5 0B FC 67  ..b....t.F.....g
0020: 3C E1 1B 43 B8 A4 3B C9   F9 44 9F F2 D2 90 35 3C  <..C..;..D....5<
0030: F6 47 78 3A AC 6B 87 E5   43 EA C8 C5 8C 4C 6E AB  .Gx:.k..C....Ln.
0040: 46 F8 C8 C4 BA 86 97 1E   C5 75 2F 85 15 CB A1 93  F........u/.....
0050: 0E 23 06 57 93 47 DF 8D   04 0F 21 AC FC E0 7D 14  .#.W.G....!.....
0060: 07 BE 0F 62 F4 75 A9 CE   F9 B3 11 0B 75 B4 87 22  ...b.u......u.."
0070: D5 8E E2 0A A9 1F C2 15   3A 64 B2 23 8F 1A 84 6C  ........:d.#...l
0080: EE 2C 3A C3 24 65 F5 BC   5C AF BD F8 B9 C4 45 83  .,:.$e..\.....E.
0090: 5B FF BD 36 E8 5D BE 98   03 2E AB 3F FE EC 9A 7B  [..6.].....?....
00A0: 31 35 7D EF 53 81 8B 7A   8B 37 7D BD EB 17 F0 36  15..S..z.7.....6
00B0: 93 CF 74 28 A3 C1 8B E1   B1 12 9F 44 20 CA 48 64  ..t(.......D .Hd
00C0: D6 F5 B0 B1 D9 18 AA F6   88 02 26 93 C8 B8 91 1A  ..........&.....
00D0: F8 B0 8B E6 7D C6 56 39   B2 6A AF 73 D2 78 76 1A  ......V9.j.s.xv.
00E0: 10 F0 C5 98 4F 90 39 2F   84 BC A0 78 81 8B ED 04  ....O.9/...x....
00F0: B8 60 49 84 C3 BD CC D2   CA 52 0A 03 E0 6C 21 B3  .`I......R...l!.

]
***

步骤4:服务端向客户端发送自己的公钥信息,最后发送ServerHelloDone:
*** ECDH ServerKeyExchange
Server key: Sun EC public key, 256 bits
  public x coord: 11246390291863077910794590233832192297756589204670697
905888685651118114908704
  public y coord: 14161558430218398366136024174925258002831938156653157
074058492642854053163673
  parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7)
*** ServerHelloDone

步骤5:客户端对服务端自签名的证书进行认证,如果客户端的信任证书列表中包含了服务端发送的证书,对证书进行合法性认证,相关信息如下:
***
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: 18007409233594974050659993272913606112791070482225689030478529921
2891203995676932921556896989720620266460254856837103481095898756142286886704
1826997320367322716218554750309434289655244757299259864742384047112657948157
2397465607023130658845790712176848549311518964468910205577731929869435871053
4010077825097678575686450546829578741624808295025041377537019411082041656396
4239591445925708790136700350526512926021140926345621403182628994210668730957
7284836787478632292743707988176993750376767952548579053306222050674647891251
5940552943479898375618793596527403443297553316980827068880327242676498304880
14296906294110074041
  public exponent: 65537
  Validity: [From: Sun Jul 27 08:49:30 CST 2014,
               To: Mon Jul 27 08:49:30 CST 2015]
  Issuer: CN=localhost
  SerialNumber: [    53d44c9a]

]
  Algorithm: [SHA1withRSA]
  Signature:
0000: 10 05 5E D4 EE A8 1C 8E   82 F1 3F 6B 0A 34 9B 96  ..^.......?k.4..
0010: 97 BE 62 13 F7 2E 94 74   A5 46 CC AB C5 0B FC 67  ..b....t.F.....g
0020: 3C E1 1B 43 B8 A4 3B C9   F9 44 9F F2 D2 90 35 3C  <..C..;..D....5<
0030: F6 47 78 3A AC 6B 87 E5   43 EA C8 C5 8C 4C 6E AB  .Gx:.k..C....Ln.
0040: 46 F8 C8 C4 BA 86 97 1E   C5 75 2F 85 15 CB A1 93  F........u/.....
0050: 0E 23 06 57 93 47 DF 8D   04 0F 21 AC FC E0 7D 14  .#.W.G....!.....
0060: 07 BE 0F 62 F4 75 A9 CE   F9 B3 11 0B 75 B4 87 22  ...b.u......u.."
0070: D5 8E E2 0A A9 1F C2 15   3A 64 B2 23 8F 1A 84 6C  ........:d.#...l
0080: EE 2C 3A C3 24 65 F5 BC   5C AF BD F8 B9 C4 45 83  .,:.$e..\.....E.
0090: 5B FF BD 36 E8 5D BE 98   03 2E AB 3F FE EC 9A 7B  [..6.].....?....
00A0: 31 35 7D EF 53 81 8B 7A   8B 37 7D BD EB 17 F0 36  15..S..z.7.....6
00B0: 93 CF 74 28 A3 C1 8B E1   B1 12 9F 44 20 CA 48 64  ..t(.......D .Hd
00C0: D6 F5 B0 B1 D9 18 AA F6   88 02 26 93 C8 B8 91 1A  ..........&.....
00D0: F8 B0 8B E6 7D C6 56 39   B2 6A AF 73 D2 78 76 1A  ......V9.j.s.xv.
00E0: 10 F0 C5 98 4F 90 39 2F   84 BC A0 78 81 8B ED 04  ....O.9/...x....
00F0: B8 60 49 84 C3 BD CC D2   CA 52 0A 03 E0 6C 21 B3  .`I......R...l!.

]

步骤6:客户端通知服务器改变加密算法,通过Change Cipher Spec消息发给服务端,随后发送Finished消息,告知服务器请检查加密算法的变更请求:
nioEventLoopGroup-2-1, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished

步骤7:服务端读取到Change Cipher Spec变更请求消息,向客户端返回确认密钥变更消息,最后通过发送Finished消息表示SSL/TLS握手结束。
nioEventLoopGroup-3-1, READ: TLSv1 Change Cipher Spec, length = 1
nioEventLoopGroup-3-1, READ: TLSv1 Handshake, length = 48
*** Finished
verify_data:  { 157, 255, 187, 52, 139, 16, 20, 190, 11, 35, 79, 0 }
***
nioEventLoopGroup-3-1, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished

- 未完待续,请见《详解Netty的安全性:原理介绍、代码演示(下篇)》-

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


[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

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

标签:Netty
上一篇:《TCP/IP详解》学习笔记(十一):TCP 交互数据流、成块数据流下一篇:详解Netty的安全性:原理介绍、代码演示(下篇)

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

推荐方案
评论 6
写的这么细,看了头大,先收藏,需要的时候再好好看看,多谢分享!
签名: 国庆长假还没有缓过来,请让我静一静,产品狗死远点...
反正是公司内部用的办公聊天程序,搞SSL或TLS好麻烦,先裸奔吧,等老板发飙了再说。。。
签名: 好久没来了,签个到
引用:PonyZhao 发表于 2016-07-13 22:42
反正是公司内部用的办公聊天程序,搞SSL或TLS好麻烦,先裸奔吧,等老板发飙了再说。。。

还是你牛,真是面向“钱”编程啊
签名: 《IM里“附近的人”功能实现原理是什么?如何高效率地实现它?》http://www.52im.net/thread-2827-1-1.html
默默地收藏。。
收藏
签名: 心情好
默默的收藏
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部