Android網絡編程-TCP/IP協議

在Android網絡編程-計算機網絡基礎一文中得知，IP協議屬於網絡層，TCP、UDP協議屬於傳輸層。
IP協議是TCP/IP協議族的動力，它爲上層協議提供無狀態、無鏈接、不可靠的服務。
TCP協議是面向鏈接的傳輸層協議，提供一種面向鏈接的、可靠的字節流服務。
UDP協議是面向無鏈接的傳輸層協議，提供面向事務的簡單不可靠信息傳輸服務。

數據報文

在不一樣層傳輸的數據單位名稱不一樣，在網絡層傳輸的叫數據報，在傳輸層傳輸的叫報文段。

IP數據報

IP數據報格式以下圖:

各個字段的詳細說明：

名稱	長度	說明
版本	4bit	IP協議的版本，目前的IP協議版本號爲4，下一代IP協議版本號爲6
首部長度	4bit	IP報頭的長度，最大長度60字節(15*4)， 分爲固定部分的長度(20字節)和可變部分的長度
服務類型	8bit	Type Of Service
總長度	16bit	IP報文的總長度。數據報的最大長度爲 65535 字節
標識	16bit	它是一個計數器，用來產生數據報的標識。 當IP報文長度超過傳輸網絡的MTU（最大傳輸單元）時必須分片， 此標識表示同一個數據報的分片。
標誌	3bit	R、DF、MF三位，目前只有後兩位有效。 DF位：爲1表示不分片，爲0表示分片。 MF：爲1表示「更多的片」，爲0表示這是最後一片。
片偏移	13bit	本分片在原先數據報文中相對首位的偏移位。 片偏移以8個字節爲偏移單位。
生存時間	8bit	TTL (Time To Live)表示數據報在網絡中的壽命，其單位爲秒。 在目前的實際應用中，常以「跳」爲單位。
協議	8bit	指出IP報文攜帶的數據使用的哪一種協議， 以便目的主機的IP層能知道要將數據報上交到哪一個進程。 TCP的協議號爲6，UDP的協議號爲17。 ICMP的協議號爲1，IGMP的協議號爲2.
首部校驗和	16bit	計算IP頭部的校驗和，檢查IP報頭的完整性。
源地址	32bit	標識IP數據報的源端設備。
目的地址	32bit	標識IP數據報的目的地址。
可選字段	長度可變	1～40 字節，用於增長IP數據報的控制功能。
填充		保證IP首部長度是4字節的整倍數

TCP報文

名稱	長度	說明
源端口	16bit	數據發送方的端口號
目的端口	16bit	數據接受方的端口號
序號	32bit	本數據報文中的的第一個字節的序號 (在數據流中每一個字節都對應一個序號)
確認號	32bit	但願收到的下一個數據報文中的第一個字節的序號
數據偏移	4bit	表示本報文數據段距離報文段有多遠
保留字段	6bit	保留爲從此使用，但目前應置爲0
緊急比特URG		當值爲1時表示次報文段中有須要緊急處理
確認比特ACK		值爲1時確認號有效，值爲0時確認號無效
復位比特RST		值爲1時表示TCP鏈接存在嚴重的錯誤，須要從新進行鏈接
同步比特SYN		值爲1表示這是一個鏈接請求或鏈接接受報文
終止比特FIN		值爲1表示要發送的數據報已經發送完畢，須要釋放傳送鏈接
窗口	16bit	TCP鏈接的一端根據緩存空間的大小來肯定本身接受窗口的大小 限制發送放的窗口上限
檢驗和	16bit	用來檢驗首部和數據兩部分的正確性
緊急指針字段	16bit	緊急指針指出在本報文段中的緊急數據的最後一個字節的序號
選項字段	長度可變	TCP 首部能夠有多達40字節的可選信息， 用於把附加信息傳遞給終點，或用來對齊其它選項

UDP報文

相對於TCP報文，UDP報文簡單了不少。

名稱	長度	說明
源端口	16bit	數據發送方的端口號
目的端口	16bit	數據接受方的端口號
包長度	16bit	UDP首部的長度和數據的長度之和。單位爲字節
校驗和	16bit	用來檢驗首部和數據兩部分的正確性

TCP三次握手和四次揮手

TCP用三次握手來建立鏈接，使用四次分手來釋放鏈接。

三次握手

三次握手的目的是同步鏈接雙方的序列號和確認號並交換TCP窗口大小的信息。
握手過程：

1. 第一次握手：創建鏈接，客戶端先發送鏈接請求報文，將SYN設置爲1，Sequence Number爲x。客戶端進入SYN+SEND狀態，等待服務器確認。

2. 第二次握手：服務器收到SYN報文。服務器收到客戶端的SYN報文，須要對這個SYN報文進行確認，設置Acknowledgment Number爲x+1(Sequence+1)；同時，本身還要送法SYN消息，將SYN位置爲1，Sequence Number爲y；服務器將上述全部信息放到一個報文段(即SYN+ACK報文段)中，一併發送給客戶端，此時服務器進入SYN+RECV狀態。
3. 第三次握手：客戶端收到服務器的 SYN+ACK報文段。而後將Acknowlegment Number設爲y+1,向服務器發送ACK報文段，這個報文段發送完畢後，客戶端端服務器都進入ESTABLISHED狀態，完成TCP三次握手。

完成了三次握手，客戶端和服務器就能夠開始傳送數據了。

四次揮手

當客戶端和服務端傳輸數據完畢後，須要斷開TCP鏈接。TCP斷開的過程，就是四次揮手。

1. 第一次揮手：客戶端(也能夠是服務器)，設置Sequence Number和Acknowledgment Number，向服務器發送一個FIN報文段。此時客戶端進入FIN_WAIT_1狀態；這表示客戶端沒有數據發送給主機了。

2. 第二次揮手：服務器收到客戶端發來的FIN報文段，向客戶端回一個ACK報文段，Acknowledgement Number爲Sequence Number加1；客戶端進入FIN_WAIT_2狀態，服務器進入CLOSE_WAIT狀態；服務器告訴客戶端，我贊成你的"關閉"請求。
3. 第三次揮手：服務器向客戶端發送FIN報文段，請求關閉鏈接，同時服務器進入LAST_ACK狀態。
4. 第四次揮手：客戶端收到服務器發送的FIN報文段，向主機發送ACK報文段，而後客戶端進入TIME_WAIT狀態，服務器收到客戶端的ACK報文段之後，就關閉鏈接，此時，客戶端等待2MSL後一次沒有到收到回覆，則證實服務端已正常關閉，那好，客戶端也能夠關閉鏈接了。

TCP三次握手的必要性

防止服務器端因接收了早已失效的鏈接請求報文，從而一直等待客戶端請求，最終致使造成死鎖、浪費資源。

TCP四次揮手的必要性

爲了保證通訊雙方都能通知對方，需釋放、斷開鏈接。

爲何客戶端關閉鏈接前要等待2MSL時間

MSL: 最大報文段生存時間

四個報文發送完畢後，就能夠直接進入CLOSE狀態了，可是有可能網絡是不可靠的，一切均可能發生，好比有可能最後一個ACK丟失。因此TIME_WAIT狀態是用來重發可能丟失的ACK報文。展開具體來說：

• 爲了保證客戶端發送的最後1個鏈接釋放確認報文 能到達服務器，從而使得服務器能正常釋放鏈接。
• 防止早已失效的鏈接請求報文，出如今本鏈接中。客戶端發送了最後1個鏈接釋放請求確認報文後，再通過2MSL時間，則可以使本鏈接持續時間內所產生的全部報文段都從網絡中消失。

TCP、UDP比較

	TCP	UDP
可靠性	可靠	不可靠
鏈接性	面向鏈接	無鏈接
報文	面向字節流	面向報文
效率	低效	高效
雙工性	全雙工	一對一，一對多，多對一，多對多 支持多播和廣播
流量控制	滑動窗口機制
擁塞控制	慢開始/擁塞避免 快重傳/快恢復
傳輸速度	慢	快
應用場景	效率要求相對低，準確要求相對高。 要求有鏈接的場景	效率要求相對高，準確要求相對低
應用	SMTP，TELNET，HTTP，FTP	DNS，RIP，NFS，SNMP， IP電話，流媒體

參考

• 計算機網絡：這是一份全面 & 詳細 的TCP協議攻略
• 《圖解TCP/IP》讀書筆記
• Android網絡編程：基礎理論彙總