Android網路編程（1）

標籤：

        本系列文章對整個Android網路編程進行了總結，包括基本的TCP/IP協議，HTTP協議，HTTPS協議，HttpClient,UrlConnection,一些網路通訊的庫到棉花糖新加入的OKHTTP。

        本文主要對TCP協議的串連管理和擁塞控制兩部分知識進行總結。

串連管理

        TCP協議是傳輸層的重要協議，負責端到端的通訊。為了實現連線導向的可靠傳輸，TCP協議使用“三向交握”和“四次揮手”的方式來建立串連，結束串連。

        三向交握：

• 第一次握手：建立串連時，用戶端C發起建立串連請求（SYN=1）到伺服器S，並進入SYN_SEND狀態，等待伺服器返回確認。
• 第二次握手：伺服器S收到用戶端C發來的串連請求後，返回確認報文（SYN=1，ACK），並進入SYN_RECV狀態。
• 第三向交握：用戶端C收到伺服器S發來的確認報文後，也要返回一個確認（SYN=0，ACK），進入ESTABLISHED狀態，開始傳送資料。

        這裡需要提一下的是確認號數值ACK=期望對方下次發來的位元組序號。

        當需要中斷連線時候，採用“四次揮手”的方式：

• 第一次揮手：用戶端C發送完資料後，發起釋放串連請求（FIN=1）,表示要關閉資料傳送，進入FIN_WAIT1狀態。
• 第二次揮手：服務端S收到請求後，會繼續發送之前未發完的資料（ACK）並進入CLOSE_WAIT狀態，關閉讀通道，也就是不能再從這個連結上讀取資料。C收到對自己釋放串連請求的ACK後，關閉寫通道，不再向串連中寫資料，進入FIN_WAIT2狀態。
• 第三次揮手：服務端S發送完要發送的資料後，發送會關閉寫通道（FIN=1）報文，進入LAST_ACK狀態。而此時用戶端接到該報文後，關閉讀通道，進入TIME_WAIT狀態。
• 第四次揮手：用戶端C發送對上一步伺服器的FIN報文的ACK，然後在等待2個MSL的時間後，進入CLOSED狀態。而伺服器S在收到該ACK後也進入CLOSED狀態。

        關於串連建立和釋放過程中，有兩個狀態需要說明一下：

• SYN_RECV:伺服器S收到了來自用戶端的建立串連請求，此時稱為半串連狀態，儲存在伺服器端的一個半串連隊列中。當收到C發來的ACK報文後，會在該隊列中尋找並移除。如果受到flood SYN攻擊，半串連隊列溢出，後續串連請求則會被丟棄。可以通過SYN Cookie來防止flood SYN攻擊。
• TIME_WAIT:用戶端C在發送對伺服器S的FIN報文的確認ACK後，進入了TIME_WAIT狀態。用戶端會維持這個狀態2MSL後才釋放socket。這個機制從邏輯上保證了重新被分配的socket不會受到之前殘留的延遲重發報文的影響。如果直接關閉用戶端C，假如伺服器S並未收到C對之前FIN報文的確認，則會重新發送FIN報文給C，但是此時C已經CLOSED了，無法找到此串連只好返回RST（reset）給S。這樣雖然沒有資料丟失，但是不符合可靠串連的要求。另外，如果C直接關閉後，又重新向server建立了一個串連，連接埠號碼又相同，但是之前上一個socket有些滯留資料也會發送到server。這時，伺服器就會認為這些滯留資料是新串連發來的，產生混淆。等待2MSL可以保證這些資料消失。

擁塞控制與流量控制

        擁塞控制就是防止過多資料注入到網路中，這樣可以使網路中的路由器和鏈路不至於過載。它是一個全域性的過程，涉及到鏈路上所有的主機和路由器。而流量控制是點對點通訊量的控制，是為了防止發送端資料發送過快接收端來不及接收。TCP協議採用慢開始、擁塞避免、快重傳以及快恢複的演算法進行擁塞控制。發送端維持了一個稱為“擁塞視窗”的狀態變數cwnd，它隨著網路擁塞程度動態變化，這裡我們先不去考慮流量控制以及接收方的接收能力，而是讓發送方的發送視窗等於擁塞視窗。

慢開始和擁塞避免演算法

        當主機開始發送資料的時候並不知道網路負荷狀況，所以由小到大逐漸增大發送視窗，即由小到大增大擁塞視窗cwnd。初始設定cwnd=1MSS，發送一個報文給接收方。接收方收到該報文後，會返回確認。發送方每次收到一個對新報文段的確認，就將cwnd增加1.因此，慢開始演算法每經過一個傳輸輪次RTT，擁塞視窗加倍：1,2,4…所以說“慢開始”不是說cwnd增長速度慢，而是說在開始發送的時候cwnd=1進行網路試探。

為了防止cwnd過速增長，需要設定一個慢開始閾值ssthresh狀態變數：

• 當cwnd<ssthresh時，使用慢開始演算法。
• 當cwnd>ssthresh時，改用擁塞避免演算法。

        這裡擁塞避免演算法與慢開始演算法不同，每經過一個傳輸輪次RTT發送方的擁塞視窗cwnd增加1，而不是加倍，同時ssthresh的值也加1.無論是在慢開始演算法還是在擁塞避免演算法階段，一旦發生擁塞（是否按時收到確認報文），則把ssthresh值設定為擁塞時cwnd值的1/2，然後cwnd設定為1，重新開始慢開始演算法。（這是不使用快重傳的思路）

快重傳和快恢複

        在傳輸過程中，如果發送方在計時器時限已到仍未收到確認，則可能出現了擁塞。對於這種可能出現的擁塞，上面所述情況未使用快重傳演算法。而對於快重傳演算法，首先要求接收方在每收到一個失序報文，都會發出重複確認，而不是等自己發資料時候才捎帶發送ack。當接收方連續收到3個重複確認，應當立即重傳該報文而不必等待計時器時間到。

        快重傳演算法需要和快恢複演算法配合使用。在連續收到3個確認報文並重發該報文的同時，為了預防擁塞發生，把慢開始閾值ssthresh減半。此時並不去執行慢開始演算法（cwnd=1），而是把cwnd設定為ssthresh減半後的數值，然後執行擁塞避免演算法。在採用快恢複的演算法時候，慢開始演算法只是在TCP串連建立時和網路出現逾時時才使用。

        我們在談論上面四種演算法的時候，假設接收方擁有足夠大的緩衝來接收資料。但是實際上接收方緩衝有限，所以需要設定一個接收視窗rwnd，在每次向發送方返回確認的時候傳送給發送方。這個接收視窗又稱為通知視窗，從流量控制的角度發送方的發送視窗不能超過接收方的rwnd值。

        綜合擁塞控制和流量控制兩方面考慮，發送視窗值=min{rwnd，cwnd}。

 

         下一篇文章中將對http協議和HTTPS協議進行總結。

 

Android網路編程（1）