一篇文章帶你熟悉 TCP/IP 協議-（二）

一篇文章帶你熟悉 TCP/IP協議-（一）- https://segmentfault.com/a/11...
一篇文章帶你熟悉 TCP/IP協議-（二）- https://segmentfault.com/a/11...
一篇文章帶你熟悉 TCP/IP協議-（三）- https://segmentfault.com/a/11...

3、傳輸層中的 TCP 和 UDP

• TCP/IP 中有兩個具備表明性的傳輸層協議，分別是 TCP 和 UDP。
• TCP 是面向鏈接的、可靠的流協議。流就是指不間斷的數據結構，當應用程序採用 TCP 發送消息時，雖然能夠保證發送的順序，但仍是猶如沒有任何間隔的數據流發送給接收端。TCP 爲提供可靠性傳輸，實行「順序控制」或「重發控制」機制。此外還具有「流控制（流量控制）」、「擁塞控制」、提升網絡利用率等衆多功能。
• UDP 是不具備可靠性的數據報協議。細微的處理它會交給上層的應用去完成。在 UDP 的狀況下，雖然能夠確保發送消息的大小，卻不能保證消息必定會到達。所以，應用有時會根據本身的須要進行重發處理。
• TCP 和 UDP 的優缺點沒法簡單地、絕對地去作比較：TCP 用於在傳輸層有必要實現可靠傳輸的狀況；而在一方面，UDP 主要用於那些對高速傳輸和實時性有較高要求的通訊或廣播通訊。TCP 和 UDP 應該根據應用的目的按需使用。

1. 端口號

數據鏈路和 IP 中的地址，分別指的是 MAC 地址和 IP 地址。前者用來識別同一鏈路中不一樣的計算機，後者用來識別 TCP/IP 網絡中互連的主機和路由器。在傳輸層也有這種相似於地址的概念，那就是端口號。端口號用來識別同一臺計算機中進行通訊的不一樣應用程序。所以，它也被稱爲程序地址。

1.1 根據端口號識別應用

一臺計算機上同時能夠運行多個程序。傳輸層協議正是利用這些端口號識別本機中正在進行通訊的應用程序，並準確地將數據傳輸。

1.2 經過 IP 地址、端口號、協議號進行通訊識別

僅憑目標端口號識別某一個通訊是遠遠不夠的。

• ① 和② 的通訊是在兩臺計算機上進行的。它們的目標端口號相同，都是80。這裏能夠根據源端口號加以區分。
• ③ 和 ① 的目標端口號和源端口號徹底相同，但它們各自的源 IP 地址不一樣。
• 此外，當 IP 地址和端口號全都同樣時，咱們還能夠經過協議號來區分（TCP 和 UDP）。

1.3 端口號的肯定

• 標準既定的端口號：這種方法也叫靜態方法。它是指每一個應用程序都有其指定的端口號。但並非說能夠隨意使用任何一個端口號。例如 HTTP、FTP、TELNET 等廣爲使用的應用協議中所使用的端口號就是固定的。這些端口號被稱爲知名端口號，分佈在 0~1023 之間；除知名端口號以外，還有一些端口號被正式註冊，它們分佈在 1024~49151 之間，不過這些端口號可用於任何通訊用途。
• 時序分配法：服務器有必要肯定監聽端口號，可是接受服務的客戶端不必肯定端口號。在這種方法下，客戶端應用程序徹底能夠不用本身設置端口號，而全權交給操做系統進行分配。動態分配的端口號範圍在 49152~65535 之間。

1.4 端口號與協議

• 端口號由其使用的傳輸層協議決定。所以，不一樣的傳輸層協議可使用相同的端口號。
• 此外，那些知名端口號與傳輸層協議並沒有關係。只要端口一致都將分配同一種應用程序進行處理。

2. UDP

• UDP 不提供複雜的控制機制，利用 IP 提供面向無鏈接的通訊服務。
• 而且它是將應用程序發來的數據在收到的那一刻，當即按照原樣發送到網絡上的一種機制。即便是出現網絡擁堵的狀況，UDP 也沒法進行流量控制等避免網絡擁塞行爲。
• 此外，傳輸途中出現丟包，UDP 也不負責重發。
• 甚至當包的到達順序出現亂序時也沒有糾正的功能。
• 若是須要以上的細節控制，不得不交由採用 UDP 的應用程序去處理。
• UDP 經常使用於一下幾個方面：1.包總量較少的通訊（DNS、SNMP等）；2.視頻、音頻等多媒體通訊（即時通訊）；3.限定於 LAN 等特定網絡中的應用通訊；4.廣播通訊（廣播、多播）。

3. TCP

• TCP 與 UDP 的區別至關大。它充分地實現了數據傳輸時各類控制功能，能夠進行丟包時的重發控制，還能夠對次序亂掉的分包進行順序控制。而這些在 UDP 中都沒有。
• 此外，TCP 做爲一種面向有鏈接的協議，只有在確認通訊對端存在時纔會發送數據，從而能夠控制通訊流量的浪費。
• 根據 TCP 的這些機制，在 IP 這種無鏈接的網絡上也可以實現高可靠性的通訊（ 主要經過檢驗和、序列號、確認應答、重發控制、鏈接管理以及窗口控制等機制實現）。

3.1 三次握手（重點）

• TCP 提供面向有鏈接的通訊傳輸。面向有鏈接是指在數據通訊開始以前先作好兩端之間的準備工做。
• 所謂三次握手是指創建一個 TCP 鏈接時須要客戶端和服務器端總共發送三個包以確認鏈接的創建。在socket編程中，這一過程由客戶端執行connect來觸發。

下面來看看三次握手的流程圖：

• 第一次握手：客戶端將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給服務器端，客戶端進入SYN_SENT狀態，等待服務器端確認。
• 第二次握手：服務器端收到數據包後由標誌位SYN=1知道客戶端請求創建鏈接，服務器端將標誌位SYN和ACK都置爲1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給客戶端以確認鏈接請求，服務器端進入SYN_RCVD狀態。
• 第三次握手：客戶端收到確認後，檢查ack是否爲J+1，ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=K+1，並將該數據包發送給服務器端，服務器端檢查ack是否爲K+1，ACK是否爲1，若是正確則鏈接創建成功，客戶端和服務器端進入ESTABLISHED狀態，完成三次握手，隨後客戶端與服務器端之間能夠開始傳輸數據了。

3.2 四次揮手（重點）

• 四次揮手即終止TCP鏈接，就是指斷開一個TCP鏈接時，須要客戶端和服務端總共發送4個包以確認鏈接的斷開。在socket編程中，這一過程由客戶端或服務端任一方執行close來觸發。
• 因爲TCP鏈接是全雙工的，所以，每一個方向都必需要單獨進行關閉，這一原則是當一方完成數據發送任務後，發送一個FIN來終止這一方向的鏈接，收到一個FIN只是意味着這一方向上沒有數據流動了，即不會再收到數據了，可是在這個TCP鏈接上仍然可以發送數據，直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉，而另外一方則執行被動關閉。

下面來看看四次揮手的流程圖：

• 中斷鏈接端能夠是客戶端，也能夠是服務器端。
• 第一次揮手：客戶端發送一個FIN=M，用來關閉客戶端到服務器端的數據傳送，客戶端進入FIN_WAIT_1狀態。意思是說"我客戶端沒有數據要發給你了"，可是若是你服務器端還有數據沒有發送完成，則沒必要急着關閉鏈接，能夠繼續發送數據。
• 第二次揮手：服務器端收到FIN後，先發送ack=M+1，告訴客戶端，你的請求我收到了，可是我還沒準備好，請繼續你等個人消息。這個時候客戶端就進入FIN_WAIT_2 狀態，繼續等待服務器端的FIN報文。
• 第三次揮手：當服務器端肯定數據已發送完成，則向客戶端發送FIN=N報文，告訴客戶端，好了，我這邊數據發完了，準備好關閉鏈接了。服務器端進入LAST_ACK狀態。
• 第四次揮手：客戶端收到FIN=N報文後，就知道能夠關閉鏈接了，可是他仍是不相信網絡，怕服務器端不知道要關閉，因此發送ack=N+1後進入TIME_WAIT狀態，若是Server端沒有收到ACK則能夠重傳。服務器端收到ACK後，就知道能夠斷開鏈接了。客戶端等待了2MSL後依然沒有收到回覆，則證實服務器端已正常關閉，那好，我客戶端也能夠關閉鏈接了。最終完成了四次握手。

上面是一方主動關閉，另外一方被動關閉的狀況，實際中還會出現同時發起主動關閉的狀況，
具體流程以下圖：

3.3 經過序列號與確認應答提升可靠性

• 在 TCP 中，當發送端的數據到達接收主機時，接收端主機會返回一個已收到消息的通知。這個消息叫作確認應答（ACK）。當發送端將數據發出以後會等待對端的確認應答。若是有確認應答，說明數據已經成功到達對端。反之，則數據丟失的可能性很大。
• 在必定時間內沒有等待到確認應答，發送端就能夠認爲數據已經丟失，並進行重發。由此，即便產生了丟包，仍然可以保證數據可以到達對端，實現可靠傳輸。
• 未收到確認應答並不意味着數據必定丟失。也有多是數據對方已經收到，只是返回的確認應答在途中丟失。這種狀況也會致使發送端誤覺得數據沒有到達目的地而重發數據。
• 此外，也有可能由於一些其餘緣由致使確認應答延遲到達，在源主機重發數據之後纔到達的狀況也家常便飯。此時，源主機只要按照機制重發數據便可。
• 對於目標主機來講，反覆收到相同的數據是不可取的。爲了對上層應用提供可靠的傳輸，目標主機必須放棄重複的數據包。爲此咱們引入了序列號。
• 序列號是按照順序給發送數據的每個字節（8位字節）都標上號碼的編號。接收端查詢接收數據 TCP 首部中的序列號和數據的長度，將本身下一步應該接收的序列號做爲確認應答返送回去。經過序列號和確認應答號，TCP 可以識別是否已經接收數據，又可以判斷是否須要接收，從而實現可靠傳輸。

3.4 重發超時的肯定

• 重發超時是指在重發數據以前，等待確認應答到來的那個特定時間間隔。若是超過這個時間仍未收到確認應答，發送端將進行數據重發。最理想的是，找到一個最小時間，它能保證「確認應答必定能在這個時間內返回」。
• TCP 要求不論處在何種網絡環境下都要提供高性能通訊，而且不管網絡擁堵狀況發生何種變化，都必須保持這一特性。爲此，它在每次發包時都會計算往返時間及其誤差。將這個往返時間和誤差時間相加，重發超時的時間就是比這個總和要稍大一點的值。
• 在 BSD 的 Unix 以及 Windows 系統中，超時都以0.5秒爲單位進行控制，所以重發超時都是0.5秒的整數倍。不過，最初其重發超時的默認值通常設置爲6秒左右。
• 數據被重發以後若仍是收不到確認應答，則進行再次發送。此時，等待確認應答的時間將會以2倍、4倍的指數函數延長。

此外，數據也不會被無限、反覆地重發。達到必定重發次數以後，若是仍沒有任何確認應答返回，就會判斷爲網絡或對端主機發生了異常，強制關閉鏈接。而且通知應用通訊異常強行終止。

3.5 以段爲單位發送數據

• 在創建 TCP 鏈接的同時，也能夠肯定發送數據包的單位，咱們也能夠稱其爲「最大消息長度」（MSS）。最理想的狀況是，最大消息長度正好是 IP 中不會被分片處理的最大數據長度。
• TCP 在傳送大量數據時，是以 MSS 的大小將數據進行分割發送。進行重發時也是以 MSS 爲單位。
• MSS 在三次握手的時候，在兩端主機之間被計算得出。兩端的主機在發出創建鏈接的請求時，會在 TCP 首部中寫入 MSS 選項，告訴對方本身的接口可以適應的 MSS 的大小。而後會在二者之間選擇一個較小的值投入使用。

3.6 利用窗口控制提升速度

• TCP 以1個段爲單位，每發送一個段進行一次確認應答的處理。這樣的傳輸方式有一個缺點，就是包的往返時間越長通訊性能就越低。
• 爲解決這個問題，TCP 引入了窗口這個概念。確認應答再也不是以每一個分段，而是以更大的單位進行確認，轉發時間將會被大幅地縮短。也就是說，發送端主機，在發送了一個段之後沒必要要一直等待確認應答，而是繼續發送。以下圖所示：

• 窗口大小就是指無需等待確認應答而能夠繼續發送數據的最大值。上圖中窗口大小爲4個段。這個機制實現了使用大量的緩衝區，經過對多個段同時進行確認應答的功能。

3.7 滑動窗口控制

• 上圖中的窗口內的數據即使沒有收到確認應答也能夠被髮送出去。不過，在整個窗口的確認應答沒有到達以前，若是其中部分數據出現丟包，那麼發送端仍然要負責重傳。爲此，發送端主機須要設置緩存保留這些待被重傳的數據，直到收到他們的確認應答。
• 在滑動窗口之外的部分包括未發送的數據以及已經確認對端已收到的數據。當數據發出後若如期收到確認應答就能夠不用再進行重發，此時數據就能夠從緩存區清除。
• 收到確認應答的狀況下，將窗口滑動到確認應答中的序列號的位置。這樣能夠順序地將多個段同時發送提升通訊性能。這種機制也別稱爲滑動窗口控制。

3.8 窗口控制中的重發控制在使用窗口控制中， 出現丟包通常分爲兩種狀況：

• ① 確認應答未能返回的狀況。在這種狀況下，數據已經到達對端，是不須要再進行重發的，以下圖：

• ② 某個報文段丟失的狀況。接收主機若是收到一個本身應該接收的序列號之外的數據時，會針對當前爲止收到數據返回確認應答。以下圖所示，當某一報文段丟失後，發送端會一直收到序號爲1001的確認應答，所以，在窗口比較大，又出現報文段丟失的狀況下，同一個序列號的確認應答將會被重複不斷地返回。而發送端主機若是連續3次收到同一個確認應答，就會將其對應的數據進行重發。這種機制比以前提到的超時管理更加高效，所以也被稱爲高速重發控制。