前言

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

推送長連接

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

影響TCP性能的點

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

TCP連接的三次握手時延

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

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

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

延遲確認

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

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

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

TCP慢啟動

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

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

Nagle算法

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

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

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

Socket.setTcpNoDelay(true);

TIME_WAIT累積與端口耗盡

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

總結(jié)

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

最新評論