前言

大家應該都知道，在Android端實現TCP長連接場景其實不多，我們最熟悉的不過推送和HTTP協議的實現（OkHttp），本文討論的是在實現推送長連接的情況下怎么來做性能優化，下文只是我的一點拙見，有不妥之處還望指出，下面話不多說了，來一起看看詳細的介紹吧。

推送長連接

可以說大部分APP是離不開推送（push）這個功能的，不過平常我們都是接入第三方SDK（極光、個推等）居多，因為要做一個推送服務，不光客戶端要編寫相應的Socket通信代碼，服務器端更是麻煩，要處理大規模的長連接服務，消息還得及時送達，一兩臺服務器可是吃不消。相對來說客戶端編寫Socket通信的代碼會簡單一些，但是也是要處理一些平臺相關的問題，比如推送服務進程如何保活，APP進程如何跟推送服務進程通信，如何節省手機電量和手機弱網情況下如何提升通信質量等一系列的問題。這些問題以后有時間分析，下面來看看TCP長連接性能如何來優化

影響TCP性能的點

TCP/IP體系太復雜了，想完全掌握確實很困難，我們只分析影響TCP性能的幾個因素，看看在Android客戶端可不可以進行優化

TCP連接的三次握手時延

我們知道要建立TCP連接，需要經過三次握手，三次握手成功后連接建立成功

• 客戶端請求新的連接，需要發送一個設置了SYN標記的分組，向服務器說明這三個連接請求
• 如何服務器接受了這個連接請求，會向客戶端回送一個設置了SYN和ACK的分組，向客戶端說明連接請求已經被接受了
• 客戶端收到這個表明連接請求被接受的分組后，要發送一條攜帶ACK標記的確認消息（可能會在這個消息中攜帶業務數據）表明連接已經建立成功了，可以開始發送數據了

那建立TCP連接的三次握手而產生的時延對我們會有影響嗎，大部分情況下是沒有的，只有當HTTP請求傳輸的數據量比較小，然后呢這樣的HTTP請求又非常頻繁，這樣算下來，握手產生的時延占比就很高了，這種情況下就要通過重用已有的連接來減少連接的次數。而推送長連接本身就是在保持連接的穩定性，無需在這點上進行優化

延遲確認

由于因特網本身無法保證可靠的分組傳輸，TCP就自己實現確認機制來確保數據的可靠傳輸，成功接收TCP分組數據的接收者都需要向發送者回送一個小的確認分組，發送者在一定的時間內沒有收到這個確認分組，就認為之前發送的數據沒有成功，然后會重發數據

但是由于確認分組非常的小，TCP為了有效的利用網絡，會把確認分組塞到同向傳輸數據中去，組合在一起發送傳輸，如果在一定的時間內沒有同向傳輸數據咋辦，豈不是一直會重發？TCP肯定不會允許這種情況發送的，TCP針對這種情況實現了一種延遲確認算法，在一定的窗口時間（一般是100~200毫秒），確認分組還沒有被捎帶的話，那么確認分組就會單獨發送

根據自己之前編寫TCP長連接的經驗，一般會在應用層設計一個業務ACK包機制，當收到一個業務數據時，馬上會回送一個業務層的ACK包，這個業務層的ACK包就是同向傳輸數據，確認分組馬上會被捎帶，不會觸發延遲確認算法，但是如果我們收到的消息頻率很高，那產生的ACK包就會非常的多，再假設業務層的ACK包并不需要那么的及時，我們是否可以組合業務層ACK包再發送呢？

TCP慢啟動

TCP連接的性能還受到擁塞控制機制的影響，當TCP連接剛開始連接上時，并不能一下子就發送很多的分組，可能是一開始只能發送一個分組，然后收到確認分組后，就可以發送兩個分組，然后就是四個分組，以此類推。這個就是TCP慢啟動，發送數據的能力是慢慢提升的

由于我們編寫的是長連接，這種機制對我們的影響并不大

Nagle算法

由于TCP并沒有規定每個分組最小值，所以我們可以每次都傳輸一個字節的數據，但是TCP有固定的標記和首部（至少40個字節），如果TCP發送大量的包含少量數據的分組時，網絡的真實利用率就很低，網絡整體性能會嚴重的下降。

所以呢TCP利用了Nagle算法，在發送了一個分組前，將大量TCP數據綁定在一起，提高網絡的效率。Nagle算法鼓勵發送全尺寸的分組，而且只有當所有的分組都被確認后，才能發送非全尺寸的分組，不然的話就緩存起來，直到積累足夠發送一個全尺寸分組數據時才會將緩存的數據發送出去

那這個對我們編寫TCP長連接時有什么影響呢，由于我們的心跳包和ACK包一般都很小，那么服務端就不能及時收到我們的心跳包和ACK包，會產生時延，可以通過下面的代碼來禁用Nagle算法

Socket.setTcpNoDelay(true);

TIME_WAIT累積與端口耗盡

這個跟服務端相關，一般與客戶端沒什么關系，這里就不說了

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對VEVB武林網的支持。