本文引用了作者Smily（博客：blog.csdn.net/qq_20521573）的文章內(nèi)容，感謝無私分享。
1、前言
目前蘋果公司已經(jīng)強制iOS應用必須使用HTTPS協(xié)議開發(fā)（詳見《蘋果即將強制實施 ATS，你的APP準備好切換到HTTPS了嗎？》），雖然Google沒有強制開發(fā)者使用HTTPS，但相信不久的將來Android也會跟隨iOS全面轉(zhuǎn)向HTTPS。因此，HTTPS的學習也是相當重要。本篇文章涉及到的代碼不多，主要內(nèi)容是對HTTPS協(xié)議的講解，最后將結(jié)合Retrofit實現(xiàn)HTTPS的單雙向認證。
下面將通過以下幾節(jié)內(nèi)容來學習HTTPS:
1）HTTPS概述；
2）HTTPS實現(xiàn)原理；
3）數(shù)字證書；
4）Https單項認證；
5）Https雙向認證。
學習交流：
- 即時通訊開發(fā)交流3群：185926912[推薦]
- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
（本文同步發(fā)布于：http://www.52im.net/thread-1574-1-1.html）
2、相關文章
《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》
《即時通訊安全篇（二）：探討組合加密算法在IM中的應用》
《即時通訊安全篇（三）：常用加解密算法與通訊安全講解》
《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風險》
《即時通訊安全篇（五）：對稱加密技術在Android平臺上的應用實踐》
《即時通訊安全篇（六）：非對稱加密技術的原理與應用實踐》
《傳輸層安全協(xié)議SSL/TLS的Java平臺實現(xiàn)簡介和Demo演示》
《理論聯(lián)系實際：一套典型的IM通信協(xié)議設計詳解（含安全層設計）》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《來自阿里OpenIM：打造安全可靠即時通訊服務的技術實踐分享》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《移動端安全通信的利器——端到端加密（E2EE）技術詳解》
《Web端即時通訊安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》
《通俗易懂：一篇掌握即時通訊的消息傳輸安全原理》
《IM開發(fā)基礎知識補課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
>> 更多同類文章 ……
3、HTTPS概述
那么什么是HTTPS？
我們看維基百科給HTTPS的定義：
HTTPS（Hypertext Transfer Protocol Secure）是一種通過計算機網(wǎng)絡進行安全通信的傳輸協(xié)議。HTTPS經(jīng)由HTTP進行通信，但利用TLS來加密數(shù)據(jù)包。HTTPS開發(fā)的主要目的，是提供對網(wǎng)站服務器的身份認證，保護交換數(shù)據(jù)的隱私與完整性。
原來HTTPS就是在HTTP協(xié)議的基礎上加入了TLS協(xié)議。目的是保證我們的數(shù)據(jù)在網(wǎng)絡上傳輸?shù)陌踩浴?/p>
什么是TLS？
TLS是傳輸層加密協(xié)議，前身是SSL協(xié)議。由網(wǎng)景公司于1995年發(fā)布。后改名為TLS。常用的 TLS 協(xié)議版本有：TLS1.2, TLS1.1, TLS1.0 和 SSL3.0。其中 SSL3.0 由于 POODLE 攻擊已經(jīng)被證明不安全。TLS1.0 也存在部分安全漏洞，比如 RC4 和 BEAST 攻擊。
由于HTTP協(xié)議采用明文傳輸，我們可以通過抓包很輕松的獲取到HTTP所傳輸?shù)臄?shù)據(jù)。因此，采用HTTP協(xié)議是不安全的。這才催生了HTTPS的誕生。
HTTPS相對HTTP提供了更安全的數(shù)據(jù)傳輸保障，主要體現(xiàn)在三個方面：
1）內(nèi)容加密：客戶端到服務器的內(nèi)容都是以加密形式傳輸，中間者無法直接查看明文內(nèi)容；
2）身份認證：通過校驗保證客戶端訪問的是自己的服務器；
3）數(shù)據(jù)完整性：防止內(nèi)容被第三方冒充或者篡改。
4、HTTPS實現(xiàn)原理
在學習HTTPS原理之前我們先了解一下兩種加密方式： 對稱加密和非對稱加密。
對稱加密：
即加密和解密使用同一個密鑰，雖然對稱加密破解難度很大，但由于對稱加密需要在網(wǎng)絡上傳輸密鑰和密文，一旦被黑客截取很容就能被破解，因此對稱加密并不是一個較好的選擇。 （詳見文章：《即時通訊安全篇（三）：常用加解密算法與通訊安全講解》）
非對稱加密：
即加密和解密使用不同的密鑰，分別稱為公鑰和私鑰。我們可以用公鑰對數(shù)據(jù)進行加密，但必須要用私鑰才能解密。在網(wǎng)絡上只需要傳送公鑰，私鑰保存在服務端用于解密公鑰加密后的密文。但是非對稱加密消耗的CPU資源非常大，效率很低，嚴重影響HTTPS的性能和速度。因此非對稱加密也不是HTTPS的理想選擇。（詳見文章：《即時通訊安全篇（六）：非對稱加密技術的原理與應用實踐》）
那么HTTPS采用了怎樣的加密方式呢？其實為了提高安全性和效率HTTPS結(jié)合了對稱和非對稱兩種加密方式。即客戶端使用對稱加密生成密鑰（key）對傳輸數(shù)據(jù)進行加密，然后使用非對稱加密的公鑰再對key進行加密。因此網(wǎng)絡上傳輸?shù)臄?shù)據(jù)是被key加密的密文和用公鑰加密后的密文key，因此即使被黑客截取，由于沒有私鑰，無法獲取到明文key，便無法獲取到明文數(shù)據(jù)。所以HTTPS的加密方式是安全的。
接下來我們以TLS1.2為例來認識HTTPS的握手過程：
1）客戶端發(fā)送 client_hello，包含一個隨機數(shù) random1；
2）服務端回復 server_hello，包含一個隨機數(shù) random2，攜帶了證書公鑰 P；
3）客戶端接收到 random2 之后就能夠生成 premaster_secrect （對稱加密的密鑰）以及 master_secrect（用premaster_secret加密后的數(shù)據(jù)）；
4）客戶端使用證書公鑰 P 將 premaster_secrect 加密后發(fā)送給服務器 (用公鑰P對premaster_secret加密)；
5）服務端使用私鑰解密得到 premaster_secrect。又由于服務端之前就收到了隨機數(shù) 1，所以服務端根據(jù)相同的生成算法，在相同的輸入?yún)?shù)下，求出了相同的 master secrect。
HTTPS的握手過程如下圖：
5、數(shù)字證書
我們上面提到了HTTPS的工作原理，通過對稱加密和非對稱加密實現(xiàn)數(shù)據(jù)的安全傳輸。我們也知道非對稱加密過程需要用到公鑰進行加密。
那么公鑰從何而來？其實公鑰就被包含在數(shù)字證書中。數(shù)字證書通常來說是由受信任的數(shù)字證書頒發(fā)機構CA，在驗證服務器身份后頒發(fā)，證書中包含了一個密鑰對（公鑰和私鑰）和所有者識別信息。數(shù)字證書被放到服務端，具有服務器身份驗證和數(shù)據(jù)傳輸加密功能。
除了CA機構頒發(fā)的證書之外，還有非CA機構頒發(fā)的證書和自簽名證書：
1）非CA機構即是不受信任的機構頒發(fā)的證書，理所當然這樣的證書是不受信任的；
2）自簽名證書，就是自己給自己頒發(fā)的證書。當然自簽名證書也是不受信任的。
例如12306網(wǎng)站使用的就是非CA機構頒發(fā)的證書（最近發(fā)現(xiàn)12306購票頁面已經(jīng)改為CA證書了），12306的證書是由SRCA頒發(fā)，SRCA中文名叫中鐵數(shù)字證書認證中心，簡稱中鐵CA。這是個鐵道部自己搞的機構，相當于是自己給自己頒發(fā)證書。
因此我們訪問12306時通常會看到如下情景：
說了這么多，我們來總結(jié)一下數(shù)字證書的兩個作用：
1）分發(fā)公鑰：每個數(shù)字證書都包含了注冊者生成的公鑰。在 TLS握手時會通過 certificate 消息傳輸給客戶端；
2）身份授權：確保客戶端訪問的網(wǎng)站是經(jīng)過 CA 驗證的可信任的網(wǎng)站。（在自簽名證書的情況下可以驗證是否是我們自己的服務器）
最后我們從別處搬來一個中間人攻擊的例子，來認識證書是如何保證我們的數(shù)據(jù)安全的。
對于一個正常的網(wǎng)絡請求，其流程通常如下：
但是，如果這過程中有黑客在通信過程中攔截了這個請求。即相當于在客戶端和服務端中間有一個中間人，兩者之間的傳輸對中間人來說是透明的，那么中間人完全可以獲取兩端之間的任何數(shù)據(jù)并加以修改，然后轉(zhuǎn)發(fā)給兩端。
這個攔截的流程如下圖：
此時惡意服務端完全可以發(fā)起雙向攻擊：對上可以欺騙服務端，對下可以欺騙客戶端，更嚴重的是客戶端段和服務端完全感知不到已經(jīng)被攻擊了。這就是所謂的中間人攻擊。
到底什么是中間人攻擊？
中間人攻擊（MITM攻擊）是指，黑客攔截并篡改網(wǎng)絡中的通信數(shù)據(jù)。又分為被動MITM和主動MITM，被動MITM只竊取通信數(shù)據(jù)而不修改，而主動MITM不但能竊取數(shù)據(jù)，還會篡改通信數(shù)據(jù)。最常見的中間人攻擊常常發(fā)生在公共wifi或者公共路由上。
現(xiàn)在可以看看使用證書是怎么樣提高安全性，避免中間人攻擊的，用一張簡單的流程圖來說明：
6、HTTPS單項認證
所謂單項認證只要服務端配置證書，客戶端在請求服務端時驗證服務器的證書即可。我們上述講到的內(nèi)容其實都是說的HTTPS單項認證。通常來說對于安全性要求不高的網(wǎng)站單項認證就可以滿足我們的需求了。因此我們訪問的HTTPS網(wǎng)站大部分都是單項認證。
6.1 關于HTTPS的使用存在的誤區(qū)
由于我們對安全性的認識不夠重視，通常對于HTTPS存在一些誤區(qū)，這些誤區(qū)可能直接給我們帶來一些安全隱患。
誤區(qū)1：對于CA機構頒發(fā)的證書客戶端無須內(nèi)置
上面提到訪問HTTPS服務器是需要在客戶端配置服務器證書的。有些小伙伴可能就納悶了，說我們用的就是HTTPS但是并沒有在客戶端配置證書呢？比如請求百度的網(wǎng)站https://www.baidu.com/，和請求HTTP服務器沒什么區(qū)別。其實這是因為在Android系統(tǒng)中已經(jīng)內(nèi)置了所有CA機構的根證書，也就是只要是CA機構頒發(fā)的證書，Android是直接信任的。對于此種情況，雖然可以正常訪問到服務器，但是仍然存在安全隱患。假如黑客自家搭建了一個服務器并申請到了CA證書，由于我們客戶端沒有內(nèi)置服務器證書，默認信任所有CA證書（客戶端可以訪問所有持有由CA機構頒發(fā)的證書的服務器），那么黑客仍然可以發(fā)起中間人攻擊劫持我們的請求到黑客的服務器，實際上就成了我們的客戶端和黑客的服務器建立起了連接。
誤區(qū)2：對于非CA機構頒發(fā)的證書和自簽名證書，可以忽略證書校驗
另外一種情況，如果我們服務器的證書是非認證機構頒發(fā)的 (例如12306)或者自簽名證書，那么我們是無法直接訪問到服務器的，直接訪問通常會拋出如下異常：
javax.net.ssl.SSLHandshakeException:
java.security.cert.CertPathValidatorException:
Trust anchor forcertification path not found.
網(wǎng)上很多解決SSLHandshakeException異常的方案是自定義TrustManager忽略證書校驗，代碼如下：
publicstaticSSLSocketFactory getSSLSocketFactory() throwsException {
//創(chuàng)建一個不驗證證書鏈的證書信任管理器。
finalTrustManager[] trustAllCerts = newTrustManager[]{newX509TrustManager() {
@Override
publicvoidcheckClientTrusted(
java.security.cert.X509Certificate[] chain,
String authType) throwsCertificateException {
}
@Override
publicvoidcheckServerTrusted(
java.security.cert.X509Certificate[] chain,
String authType) throwsCertificateException {
}
@Override
publicjava.security.cert.X509Certificate[] getAcceptedIssuers() {
returnnewjava.security.cert.X509Certificate[0];
}
}};
// Install the all-trusting trust manager
finalSSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(null, trustAllCerts,
newjava.security.SecureRandom());
// Create an ssl socket factory with our all-trusting manager
returnsslContext
.getSocketFactory();
}
//使用自定義SSLSocketFactory
privatevoidonHttps(OkHttpClient.Builder builder) {
try{
builder.sslSocketFactory(getSSLSocketFactory()).hostnameVerifier(org.apache.http.conn.ssl.SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
} catch(Exception e) {
e.printStackTrace();
}
}
對于這樣的處理方式雖然解決了SSLHandshakeException異常，但是卻存在更大的安全隱患。因為此種做法直接使我們的客戶端信任了所有證書（包括CA機構頒發(fā)的證書和非CA機構頒發(fā)的證書以及自簽名證書），因此，這樣配置將比第一種情況危害更大。
6.2 Retrofit綁定證書實現(xiàn)HTTPS單項認證
對于上述兩種情況中存在的安全隱患，我們應該如何應對？最簡單的解決方案就是在客戶端內(nèi)置服務器的證書，我們在校驗服務端證書的時候只比對和App內(nèi)置的證書是否完全相同，如果不同則斷開連接。那么此時再遭遇中間人攻擊劫持我們的請求時由于黑客服務器沒有相應的證書，此時HTTPS請求校驗不通過，則無法與黑客的服務器建立起連接。
那么接下來我們就結(jié)合Retrofit以訪問12306為例來實現(xiàn)HTTPS的單項認證。
首先從12306網(wǎng)站下載簽名證書，并放置到我們項目資源目錄raw下。
然后根據(jù)證書構造SSLSocketFactory，代碼如下：
/**
* 單項認證
*/
publicstaticSSLSocketFactory getSSLSocketFactoryForOneWay(InputStream... certificates) {
try{
CertificateFactory certificateFactory = CertificateFactory.getInstance(CLIENT_TRUST_MANAGER, CLIENT_TRUST_PROVIDER);
KeyStore keyStore = KeyStore.getInstance(CLIENT_TRUST_KEYSTORE);
keyStore.load(null);
intindex = 0;
for(InputStream certificate : certificates) {
String certificateAlias = Integer.toString(index++);
keyStore.setCertificateEntry(certificateAlias, certificateFactory.generateCertificate(certificate));
try{
if(certificate != null)
certificate.close();
} catch(IOException e) {
e.printStackTrace();
}
}
SSLContext sslContext = SSLContext.getInstance(CLIENT_AGREEMENT);
TrustManagerFactory trustManagerFactory =
TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
trustManagerFactory.init(keyStore);
sslContext.init(null, trustManagerFactory.getTrustManagers(), newSecureRandom());
returnsslContext.getSocketFactory();
} catch(Exception e) {
e.printStackTrace();
}
returnnull;
}
接下來為OKHttpClient設置SslSocketFactory以及hostnameVerifier，代碼如下：
InputStream certificate12306 = Utils.getContext().getResources().openRawResource(R.raw.srca);
OkHttpClient okHttpClient = newOkHttpClient.Builder()
.readTimeout(Constants.DEFAULT_TIMEOUT, TimeUnit.MILLISECONDS)
.connectTimeout(Constants.DEFAULT_TIMEOUT, TimeUnit.MILLISECONDS)
.addInterceptor(interceptor)
.addInterceptor(newHttpHeaderInterceptor())
.addNetworkInterceptor(newHttpCacheInterceptor())
.sslSocketFactory(SslContextFactory.getSSLSocketFactoryForOneWay(certificate12306))
.hostnameVerifier(newSafeHostnameVerifier())
.cache(cache)
.build();
上述代碼中hostnameVerifier是對服務器的校驗，SafeHostnameVerifier代碼如下：
privateclassSafeHostnameVerifier implementsHostnameVerifier {
@Override
publicbooleanverify(String hostname, SSLSession session) {
if(Constants.IP.equals(hostname)) {//校驗hostname是否正確，如果正確則建立連接
returntrue;
}
returnfalse;
}
}
verify方法中對比了請求的IP和服務器的IP是否一致，一致則返回true表示校驗通過，否則返回false，檢驗不通過，斷開連接。對于網(wǎng)上有些處理是直接返回true，即不對請求的服務器IP做校驗，我們不推薦這樣使用。而且現(xiàn)在谷歌應用商店已經(jīng)對此種做法做了限制，禁止在verify方法中直接返回true的App上線。
7、HTTPS雙向認證
對于HTTPS雙向認證，用到的情況不多。但是對于像金融行業(yè)等對安全性要求較高的企業(yè)，通常都會使用雙向認證。所謂雙向認證就是客戶端校驗服務器證書，同時服務器也需要校驗客戶端的證書。因此，雙向認證就另需一張證書放到客戶端待服務端去驗證。
單項認證保證了我們自己的客戶端只能訪問我們自己的服務器，但并不能保證我們自己的服務器只能被我們自己的客戶端訪問（第三方客戶端忽略證書校驗即可）。那么雙向認證則保證了我們的客戶端只能訪問我們自己的服務器，同時我們的服務器也只能被我們自己的客戶端訪問。因此雙向認證可以說相比單項認證安全性足足提高一個等級。
7.1 雙向認證流程
接下來我們來了解下雙向認證的流程，以加深對雙向認證的理解：
a. 客戶端發(fā)送一個連接請求給服務器。
b. 服務器將自己的證書，以及同證書相關的信息發(fā)送給客戶端。
c. 客戶端檢查服務器送過來的證書是否和App內(nèi)置證書相同。如果是，就繼續(xù)執(zhí)行協(xié)議；如果不是則終止此次請求。
d. 接著客戶端比較證書里的消息，例如域名和公鑰，與服務器剛剛發(fā)送的相關消息是否一致，如果是一致的，客戶端認可這個服務器的合法身份。
e. 服務器要求客戶發(fā)送客戶自己的證書。收到后，服務器驗證客戶端的證書，如果沒有通過驗證，拒絕連接；如果通過驗證，服務器獲得用戶的公鑰。
f. 客戶端告訴服務器自己所能夠支持的通訊對稱密碼方案。
g. 服務器從客戶發(fā)送過來的密碼方案中，選擇一種加密程度最高的密碼方案，用客戶的公鑰加過密后通知客戶端。
h. 客戶端針對這個密碼方案，選擇一個通話密鑰，接著用服務器的公鑰加過密后發(fā)送給服務器。
i. 服務器接收到客戶端送過來的消息，用自己的私鑰解密，獲得通話密鑰。
j. 服務器通過密鑰解密客戶端發(fā)送的被加密數(shù)據(jù)，得到明文數(shù)據(jù)。
7.2 Retrofit實現(xiàn)HTTPS雙向認證
對于雙向認證，我們以華為北向平臺登錄接口為例來進行學習。想了解華為北向API：請戳此處。
我們直接通過瀏覽器訪問登錄接口可以看到如下情景：
哈，驚喜不？直接被拒絕了！這就是雙向認證，沒有證書想訪問服務器門都沒有。那么對于雙向認證我們應該做怎樣的配置？我們可以參考華為開源出來的代碼：
https://github.com/52im/IoT_OceanConnect_North_GUI_APPDemo
源碼中由兩個證書文件ca.jks和outgoing.CertwithKey.pkcs12，其中ca.jks是在客戶端配置的證書，outgoing.CertwithKey.pkcs12是在服務端配置的證書。因為我們當前客戶端是Android系統(tǒng)，由于Android系統(tǒng)不支持jks格式的證書，因此需要把jks轉(zhuǎn)成Android支持的bks格式。轉(zhuǎn)換方式不再貼出，可自行查閱。
有了證書，接下來看獲取SSLSocketFactory的代碼：
/**
* 雙向認證
*
* @return SSLSocketFactory
*/
publicstaticSSLSocketFactory getSSLSocketFactoryForTwoWay() {
try{
InputStream certificate = Utils.getContext().getResources().openRawResource(R.raw.capk);
// CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509", "BC");
KeyStore keyStore = KeyStore.getInstance(CLIENT_TRUST_KEY);
keyStore.load(certificate, SELF_CERT_PWD.toCharArray());
KeyManagerFactory kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
kmf.init(keyStore, SELF_CERT_PWD.toCharArray());
try{
if(certificate != null)
certificate.close();
} catch(IOException e) {
e.printStackTrace();
}
//初始化keystore
KeyStore clientKeyStore = KeyStore.getInstance(CLIENT_TRUST_KEYSTORE);
clientKeyStore.load(Utils.getContext().getResources().openRawResource(R.raw.cabks), TRUST_CA_PWD.toCharArray());
SSLContext sslContext = SSLContext.getInstance(CLIENT_AGREEMENT);
TrustManagerFactory trustManagerFactory = TrustManagerFactory.
getInstance(TrustManagerFactory.getDefaultAlgorithm());
trustManagerFactory.init(clientKeyStore);
KeyManagerFactory keyManagerFactory = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
keyManagerFactory.init(clientKeyStore, SELF_CERT_PWD.toCharArray());
sslContext.init(kmf.getKeyManagers(), trustManagerFactory.getTrustManagers(), newSecureRandom());
returnsslContext.getSocketFactory();
} catch(Exception e) {
e.printStackTrace();
}
returnnull;
}
接下來同樣需要配置OKHttpClient，代碼如下：
OkHttpClient okHttpClient = newOkHttpClient.Builder()
.readTimeout(Constants.DEFAULT_TIMEOUT, TimeUnit.MILLISECONDS)
.connectTimeout(Constants.DEFAULT_TIMEOUT, TimeUnit.MILLISECONDS)
.addInterceptor(interceptor)
.addInterceptor(newHttpHeaderInterceptor())
.addNetworkInterceptor(newHttpCacheInterceptor())
.sslSocketFactory(SslContextFactory.getSSLSocketFactoryForTwoWay())
.hostnameVerifier(newSafeHostnameVerifier())
.cache(cache)
.build();
這樣就完成了HTTPS的配置，接下來就可以愉快的訪問HTTPS 雙向認證的接口了。由于北向登錄接口中需要appId和secret兩個參數(shù)，因此，登錄相關代碼就不再貼出。
好了，到此關于HTTPS的學習就結(jié)束了，如果有不明白的地方可以參看文末源碼。以上內(nèi)容純屬個人對HTTPS的一些認識，如果文中有錯誤之處還請多多包涵，歡迎留言指正。
本文寫成參考了大量的相關文章，在此表示感謝。
（原文鏈接：https://blog.csdn.net/qq_20521573/article/details/79233793）
附錄1：參考源碼
（請從此鏈接的附件處下載之：http://www.52im.net/thread-1574-1-1.html）
附錄2：參考資料
《大型網(wǎng)站的 HTTPS 實踐（1）：HTTPS 協(xié)議和原理》
《Retrofit中如何正確的使用https？》
《Android Https相關完全解析 當OkHttp遇到Https》
《HTTPS原理及OKHTTP對HTTPS的支持》
附錄3：即時通訊干貨文章
《新手入門一篇就夠：從零開發(fā)移動端IM》
《從客戶端的角度來談談移動端IM的消息可靠性和送達機制》
《現(xiàn)代移動端網(wǎng)絡短連接的優(yōu)化手段總結(jié)：請求速度、弱網(wǎng)適應、安全保障》
《騰訊技術分享：社交網(wǎng)絡圖片的帶寬壓縮技術演進之路》
《IM開發(fā)基礎知識補課：正確理解前置HTTP SSO單點登陸接口的原理》
《移動端IM中大規(guī)模群消息的推送如何保證效率、實時性？》
《移動端IM開發(fā)需要面對的技術問題》
《開發(fā)IM是自己設計協(xié)議用字節(jié)流好還是字符流好？》
《請問有人知道語音留言聊天的主流實現(xiàn)方式嗎？》
《IM消息送達保證機制實現(xiàn)(一)：保證在線實時消息的可靠投遞》
《IM消息送達保證機制實現(xiàn)(二)：保證離線消息的可靠投遞》
《如何保證IM實時消息的“時序性”與“一致性”？》
《一個低成本確保IM消息時序的方法探討》
《IM單聊和群聊中的在線狀態(tài)同步應該用“推”還是“拉”？》
《IM群聊消息如此復雜，如何保證不丟不重？》
《談談移動端 IM 開發(fā)中登錄請求的優(yōu)化》
《移動端IM登錄時拉取數(shù)據(jù)如何作到省流量？》
《淺談移動端IM的多點登陸和消息漫游原理》
《完全自已開發(fā)的IM該如何設計“失敗重試”機制？》
《通俗易懂：基于集群的移動端IM接入層負載均衡方案分享》
《微信對網(wǎng)絡影響的技術試驗及分析（論文全文）》
《即時通訊系統(tǒng)的原理、技術和應用（技術論文）》
《開源IM工程“蘑菇街TeamTalk”的現(xiàn)狀：一場有始無終的開源秀》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊原創(chuàng)分享(一)：如何大幅提升移動網(wǎng)絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動網(wǎng)絡下APP的流量消耗（上篇）》
《騰訊原創(chuàng)分享(三)：如何大幅壓縮移動網(wǎng)絡下APP的流量消耗（下篇）》
《如約而至：微信自用的移動端IM網(wǎng)絡層跨平臺組件庫Mars已正式開源》
《基于社交網(wǎng)絡的Yelp是如何實現(xiàn)海量用戶圖片的無損壓縮的？》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網(wǎng)絡流量的(圖片壓縮篇)》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網(wǎng)絡流量的(音視頻技術篇)》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-1574-1-1.html）