在Android網(wǎng)絡(luò)編程-計算機網(wǎng)絡(luò)基礎(chǔ)一文中得知，IP協(xié)議屬于網(wǎng)絡(luò)層，TCP、UDP協(xié)議屬于傳輸層。
IP協(xié)議是TCP/IP協(xié)議族的動力，它為上層協(xié)議提供無狀態(tài)、無連接、不可靠的服務(wù)。
TCP協(xié)議是面向連接的傳輸層協(xié)議，提供一種面向連接的、可靠的字節(jié)流服務(wù)。
UDP協(xié)議是面向無連接的傳輸層協(xié)議，提供面向事務(wù)的簡單不可靠信息傳輸服務(wù)。
數(shù)據(jù)報文
在不同層傳輸?shù)臄?shù)據(jù)單位名稱不同，在網(wǎng)絡(luò)層傳輸?shù)慕袛?shù)據(jù)報，在傳輸層傳輸?shù)慕袌笪亩巍?/p>
IP數(shù)據(jù)報
IP數(shù)據(jù)報格式如下圖:
各個字段的詳細說明：名稱長度說明版本4bitIP協(xié)議的版本，目前的IP協(xié)議版本號為4，下一代IP協(xié)議版本號為6首部長度4bitIP報頭的長度，最大長度60字節(jié)(15*4)，
分為固定部分的長度(20字節(jié))和可變部分的長度服務(wù)類型8bitType Of Service總長度16bitIP報文的總長度。數(shù)據(jù)報的最大長度為 65535 字節(jié)標識16bit它是一個計數(shù)器，用來產(chǎn)生數(shù)據(jù)報的標識。
當IP報文長度超過傳輸網(wǎng)絡(luò)的MTU(最大傳輸單元)時必須分片，此標識表示同一個數(shù)據(jù)報的分片。標志3bitR、DF、MF三位，目前只有后兩位有效。
- DF位：為1表示不分片，為0表示分片。
- MF：為1表示“更多的片”，為0表示這是最后一片。片偏移13bit本分片在原先數(shù)據(jù)報文中相對首位的偏移位。
片偏移以8個字節(jié)為偏移單位。生存時間8bitTTL (Time To Live)表示數(shù)據(jù)報在網(wǎng)絡(luò)中的壽命，其單位為秒。
在目前的實際應(yīng)用中，常以“跳”為單位。協(xié)議8bit指出IP報文攜帶的數(shù)據(jù)使用的哪種協(xié)議，以便目的主機的IP層能知道要將數(shù)據(jù)報上交到哪個進程。
TCP的協(xié)議號為6，UDP的協(xié)議號為17。
ICMP的協(xié)議號為1，IGMP的協(xié)議號為2.首部校驗和16bit計算IP頭部的校驗和，檢查IP報頭的完整性。源地址32bit標識IP數(shù)據(jù)報的源端設(shè)備。目的地址32bit標識IP數(shù)據(jù)報的目的地址。可選字段長度可變1～40 字節(jié)，用于增加IP數(shù)據(jù)報的控制功能。填充保證IP首部長度是4字節(jié)的整倍數(shù)
TCP報文
名稱長度說明源端口16bit數(shù)據(jù)發(fā)送方的端口號目的端口16bit數(shù)據(jù)接受方的端口號序號32bit本數(shù)據(jù)報文中的的第一個字節(jié)的序號
(在數(shù)據(jù)流中每個字節(jié)都對應(yīng)一個序號)確認號32bit希望收到的下一個數(shù)據(jù)報文中的第一個字節(jié)的序號數(shù)據(jù)偏移4bit表示本報文數(shù)據(jù)段距離報文段有多遠保留字段6bit保留為今后使用，但目前應(yīng)置為0緊急比特URG當值為1時表示次報文段中有需要緊急處理確認比特ACK值為1時確認號有效，值為0時確認號無效復(fù)位比特RST值為1時表示TCP連接存在嚴重的錯誤，需要重新進行連接同步比特SYN值為1表示這是一個連接請求或連接接受報文終止比特FIN值為1表示要發(fā)送的數(shù)據(jù)報已經(jīng)發(fā)送完畢，需要釋放傳送連接窗口16bitTCP連接的一端根據(jù)緩存空間的大小來確定自己接受窗口的大小
限制發(fā)送放的窗口上限檢驗和16bit用來檢驗首部和數(shù)據(jù)兩部分的正確性緊急指針字段16bit緊急指針指出在本報文段中的緊急數(shù)據(jù)的最后一個字節(jié)的序號選項字段長度可變TCP 首部可以有多達40字節(jié)的可選信息，
用于把附加信息傳遞給終點，或用來對齊其它選項
UDP報文
相對于TCP報文，UDP報文簡單了很多。
名稱長度說明源端口16bit數(shù)據(jù)發(fā)送方的端口號目的端口16bit數(shù)據(jù)接受方的端口號包長度16bitUDP首部的長度和數(shù)據(jù)的長度之和。單位為字節(jié)校驗和16bit用來檢驗首部和數(shù)據(jù)兩部分的正確性
TCP三次握手和四次揮手
TCP用三次握手來創(chuàng)建連接，使用四次分手來釋放連接。
三次握手
三次握手的目的是同步連接雙方的序列號和確認號并交換TCP窗口大小的信息。
握手過程：
- 第一次握手：建立連接，客戶端先發(fā)送連接請求報文，將SYN設(shè)置為1，Sequence Number為x?？蛻舳诉M入SYN+SEND狀態(tài)，等待服務(wù)器確認。
- 第二次握手：服務(wù)器收到SYN報文。服務(wù)器收到客戶端的SYN報文，需要對這個SYN報文進行確認，設(shè)置Acknowledgment Number為x+1(Sequence+1);同時，自己還要送法SYN消息，將SYN位置為1，Sequence Number為y;服務(wù)器將上述所有信息放到一個報文段(即SYN+ACK報文段)中，一并發(fā)送給客戶端，此時服務(wù)器進入SYN+RECV狀態(tài)。
- 第三次握手：客戶端收到服務(wù)器的 SYN+ACK報文段。然后將Acknowlegment Number設(shè)為y+1,向服務(wù)器發(fā)送ACK報文段，這個報文段發(fā)送完畢后，客戶端端服務(wù)器都進入ESTABLISHED狀態(tài)，完成TCP三次握手。
完成了三次握手，客戶端和服務(wù)器就可以開始傳送數(shù)據(jù)了。
四次揮手
當客戶端和服務(wù)端傳輸數(shù)據(jù)完畢后，需要斷開TCP連接。TCP斷開的過程，就是四次揮手。
- 第一次揮手：客戶端(也可以是服務(wù)器)，設(shè)置Sequence Number和Acknowledgment Number，向服務(wù)器發(fā)送一個FIN報文段。此時客戶端進入FIN_WAIT_1狀態(tài);這表示客戶端沒有數(shù)據(jù)發(fā)送給主機了。
- 第二次揮手：服務(wù)器收到客戶端發(fā)來的FIN報文段，向客戶端回一個ACK報文段，Acknowledgement Number為Sequence Number加1;客戶端進入FIN_WAIT_2狀態(tài)，服務(wù)器進入CLOSE_WAIT狀態(tài);服務(wù)器告訴客戶端，我同意你的”關(guān)閉”請求。
- 第三次揮手：服務(wù)器向客戶端發(fā)送FIN報文段，請求關(guān)閉連接，同時服務(wù)器進入LAST_ACK狀態(tài)。
- 第四次揮手：客戶端收到服務(wù)器發(fā)送的FIN報文段，向主機發(fā)送ACK報文段，然后客戶端進入TIME_WAIT狀態(tài)，服務(wù)器收到客戶端的ACK報文段以后，就關(guān)閉連接，此時，客戶端等待2MSL后一次沒有到收到回復(fù)，則證明服務(wù)端已正常關(guān)閉，那好，客戶端也可以關(guān)閉連接了。
TCP三次握手的必要性
防止服務(wù)器端因接收了早已失效的連接請求報文，從而一直等待客戶端請求，最終導(dǎo)致形成死鎖、浪費資源。
TCP四次揮手的必要性
為了保證通信雙方都能通知對方，需釋放、斷開連接。
為什么客戶端關(guān)閉連接前要等待2MSL時間
- MSL: 最大報文段生存時間
四個報文發(fā)送完畢后，就可以直接進入CLOSE狀態(tài)了，但是有可能網(wǎng)絡(luò)是不可靠的，一切都可能發(fā)生，比如有可能最后一個ACK丟失。所以TIME_WAIT狀態(tài)是用來重發(fā)可能丟失的ACK報文。展開具體來講：
- 為了保證客戶端發(fā)送的最后1個連接釋放確認報文 能到達服務(wù)器，從而使得服務(wù)器能正常釋放連接。
- 防止早已失效的連接請求報文，出現(xiàn)在本連接中?？蛻舳税l(fā)送了最后1個連接釋放請求確認報文后，再經(jīng)過2MSL時間，則可使本連接持續(xù)時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失。
TCP、UDP比較
- TCPUDP可靠性可靠不可靠連接性面向連接無連接報文面向字節(jié)流面向報文效率低效高效雙工性全雙工一對一，一對多，多對一，多對多
- 支持多播和廣播流量控制滑動窗口機制擁塞控制慢開始/擁塞避免
- 快重傳/快恢復(fù)傳輸速度慢快應(yīng)用場景效率要求相對低，準確要求相對高。
- 要求有連接的場景效率要求相對高，準確要求相對低應(yīng)用SMTP，TELNET，HTTP，F(xiàn)TPDNS，RIP，NFS，SNMP，
- IP電話，流媒體
