TCP/IP基礎

TCP/IP基礎

一、 計算機網絡體系結構分層

二、 數據處理流程

三、 傳輸層中的 TCP 和 UDP

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

連接識別五元素
端口號的作用：一臺計算機上同時可以運行多個程序。傳輸層協議正是利用這些端口號識別本機中正在進行通信的應用程序，並準確地將數據傳輸。

但僅憑目標端口號識別某一個通信是遠遠不夠的.

只有通過五元素纔會識別一個連接：源IP地址，目標IP地址，協議號，源端口號，目標端口號

UDP

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

TCP

TCP 與 UDP 的區別相當大。它充分地實現了數據傳輸時各種控制功能，可以進行丟包時的重發控制，還可以對次序亂掉的分包進行順序控制。而這些在 UDP 中都沒有。

• 此外，TCP 作爲一種面向有連接的協議，只有在確認通信對端存在時纔會發送數據，從而可以控制通信流量的浪費。
• 根據 TCP 的這些機制，在 IP 這種無連接的網絡上也能夠實現高可靠性的通信（ 主要通過檢驗和、序列號、確認應答、重發控制、連接管理以及窗口控制等機制實現）。

在講三次握手和四次揮手前，先來看下TCP首部:

再來看下Control Flag:

• ACK（Acknowledgement Flag）:
  該位爲1時，確認應答的字段變爲有效。TCP規定除了最初建立連接時的SYN包之外該位必須設置爲1。
• SYN（Synchronize Flag）：
  用於建立連接。SYN爲1表示希望建立連接，並在其序列號的字段進行序列號初始值的設定（Synchronize本身有同步的意思。也就意味着建立連接的雙方，序列號和確認應答號要保持同步） 。
• FIN（Fin Flag）：
  該位爲1時，表示今後不會再有數據發送，希望斷開連接。當通信結束希望斷開連接時，通信雙方的主機之間就可以相互交換FIN位置爲1
  的TCP段。每個主機又對對方的FIN包進行確認應答以後就可以斷開連接。不過，主機收到FIN設置爲1的TCP段以後不必馬上回復一個FIN包，而是可以等到緩衝區中的所有數據都因已成功發送而被自動刪除之後再發。

TCP建立連接時的三次握手（重點）

• 第一次握手：客戶端將標誌位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狀態，完成三次握手，隨後客戶端與服務器端之間可以開始傳輸數據了。

思考一下，爲何建立連接要三次握手，兩次握手行不行 ？
從上面握手的步驟中來看雙方會初始化各自的初始系列號通知對方，客戶端初始seq = J，服務端初始seq = K，後續的報文序列號會在此基礎上遞增.假如說服務端給客戶端的握手報文被丟失了，那麼在兩次握手的case下，客戶端將無法知道服務端到底有沒有收到自己發出的報文，客戶端也無法知道服務端的初始序列號,則連接會一直建立不起來.而在三次握手的case下，服務端發出握手報文後，如果在一定時間內沒有收到客戶端的回覆，就會定時重發，直到客戶端有迴音才能算連接成功.

TCP斷開連接時的四次揮手（重點）

• 中斷連接端可以是客戶端，也可以是服務器端。
• 第一次揮手：客戶端發送一個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後依然沒有收到回覆，則證明服務器端已正常關閉，那好，我客戶端也可以關閉連接了。最終完成了四次握手。

上面是一方主動關閉，另一方被動關閉的情況，實際中還會出現同時發起主動關閉的情況：

TCP通過序列號與確認應答提高可靠性

在 TCP 中，當發送端的數據到達接收主機時，接收端主機會返回一個已收到消息的通知。這個消息叫做確認應答（ACK）。當發送端將數據發出之後會等待對端的確認應答。如果有確認應答，說明數據已經成功到達對端。反之，則數據丟失的可能性很大。

• 在一定時間內沒有等待到確認應答，發送端就可以認爲數據已經丟失，並進行重發。由此，即使產生了丟包，仍然能夠保證數據能夠到達對端，實現可靠傳輸。
• 未收到確認應答並不意味着數據一定丟失。也有可能是數據對方已經收到，只是返回的確認應答在途中丟失。這種情況也會導致發送端誤以爲數據沒有到達目的地而重發數據。
• 此外，也有可能因爲一些其他原因導致確認應答延遲到達，在源主機重發數據以後纔到達的情況也屢見不鮮。此時，源主機只要按照機制重發數據即可。
• 對於目標主機來說，反覆收到相同的數據是不可取的。爲了對上層應用提供可靠的傳輸，目標主機必須放棄重複的數據包。爲此我們引入了序列號。
• 序列號是按照順序給發送數據的每一個字節（8位字節）都標上號碼的編號。接收端查詢接收數據 TCP 首部中的序列號和數據的長度，將自己下一步應該接收的序列號作爲確認應答返送回去。通過序列號和確認應答號，TCP 能夠識別是否已經接收數據，又能夠判斷是否需要接收，從而實現可靠傳輸。

TCP的重發超時的確定

重發超時是指在重發數據之前，等待確認應答到來的那個特定時間間隔。如果超過這個時間仍未收到確認應答，發送端將進行數據重發。最理想的是，找到一個最小時間，它能保證“確認應答一定能在這個時間內返回”。

• TCP 要求不論處在何種網絡環境下都要提供高性能通信，並且無論網絡擁堵情況發生何種變化，都必須保持這一特性。爲此，它在每次發包時都會計算往返時間及其偏差。將這個往返時間和偏差時間相加，重發超時的時間就是比這個總和要稍大一點的值。
• 在 BSD 的 Unix 以及 Windows 系統中，超時都以0.5秒爲單位進行控制，因此重發超時都是0.5秒的整數倍。不過，最初其重發超時的默認值一般設置爲6秒左右。
• 數據被重發之後若還是收不到確認應答，則進行再次發送。此時，等待確認應答的時間將會以2倍、4倍的指數函數延長。
• 此外，數據也不會被無限、反覆地重發。達到一定重發次數之後，如果仍沒有任何確認應答返回，就會判斷爲網絡或對端主機發生了異常，強制關閉連接。並且通知應用通信異常強行終止。

TCP以段爲單位發送數據

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

TCP 滑動窗口

TCP 以1個段爲單位，每發送一個段進行一次確認應答的處理。這樣的傳輸方式有一個缺點，就是包的往返時間越長通信性能就越低。

• 爲解決這個問題，TCP 引入了窗口這個概念。確認應答不再是以每個分段，而是以更大的單位進行確認，轉發時間將會被大幅地縮短。也就是說，發送端主機，在發送了一個段以後不必要一直等待確認應答，而是繼續發送。如下圖所示：
  
  窗口大小就是指無需等待確認應答而可以繼續發送數據的最大值。上圖中，窗口大小爲4個段.
  這個機制實現了使用大量的緩衝區（緩衝區（Buffer）在此處表示臨時保存收發數據的場所。通常是在計算機內存中開闢的一部分空
  間。） ，通過對多個段同時進行確認應答的功能。因爲發送端在沒有收到ack之前，發送緩衝區的數據是不能刪除的.
  
  上圖中發送數據中高亮圈起的部分正是前面所提到的滑動窗口。
• 窗口內的數據即便沒有收到確認應答也可以被髮送出去。不過，在整個窗口的確認應答沒有到達之前，如果其中部分數據出現丟包，那麼發送端仍然要負責重傳。爲此，發送端主機需要設置緩存保留這些待被重傳的數據，直到收到他們的確認應答。
• 在滑動窗口以外的部分包括未發送的數據以及已經確認對端已收到的數據。當數據發出後若如期收到確認應答就可以不用再進行重發，此時數據就可以從緩存區清除。
• 收到確認應答的情況下，將窗口滑動到確認應答中的序列號的位置。這樣可以順序地將多個段同時發送提高通信性能。這種機制也別稱爲滑動窗口控制。

TCP的滑動窗口中的重發控制

如果在使用滑動窗口的過程中，出現段丟失該怎麼辦?從兩種case來看:

1. 確認應答未能返回
   在這種情況下，數據已經到達對端，是不需要再進行重發的。然而，在沒有使用窗口控制的時候，沒有收到確認應答的數據都會被重發。而使用了窗口控制，就如下圖所示，某些確認應答即便丟失也無需重發。
2. 某個報文段丟失
   如下圖所示，接收主機如果收到一個自己應該接收的序號以外的數據時，會針對當前爲止收到數據返回確認應答（不過即使接收端主機收到的包序號並不連續，也不會將數據丟棄而是暫時保存至緩衝區中）。
   下入中，當某一報文段丟失後，發送端會一直收到序號爲1001的確認應答，這個確認應答好像在提醒發送端“我想接收的是從1001開始的數據”。因此，在窗口比較大，又出現報文段丟失的情況下，同一個序號的確認應答將會被重複不斷地返回。而發送端主機如果連續3次收到同一個確認應答（之所以連續收到3次而不是兩次的理由是因爲，即使數據段的序號被替換兩次也不會觸發重發機制）,就會將其所對應的數據進行重發。這種機制比之前提到的超時管理更加高效，因此也被稱作高速重發控制。
   

TCP流控制 – 動態協商滑動窗口大小

TCP提供一種機制可以讓發送端根據接收端的實際接收能力控制發送的數據量。這就是所謂的流控制。它的具體操作是，接收端主機向發送端主機通知自己可以接收數據的大小，於是發送端會發送不超過這個限度的數據。該大小限度就被稱作窗口大小.最開始的時候這個窗口大小是由發送端自行決定的.
TCP首部中，專門有一個字段Window Size用來通知窗口大小。接收主機將自己可以接收的緩衝區大小放入這個字段中通知給發送端。這個字段的值越大，說明網絡的吞吐量越高。不過，接收端的這個緩衝區一旦面臨數據溢出時，窗口大小的值也會隨之被設置爲一個更小的值通知給發送端，從而控制數據發送量。也就是說，發送端主機會根據接收端主機的指示，對發送數據的量進行控制。這也就形成了一個完整的TCP流控制（流量控制）。

如上圖所示，當接收端收到從3001號開始的數據段後其緩衝區即滿，不得不暫時停止接收數據。之後，在收到發送窗口更新通知後通信才得以繼續進行。如果這個窗口的更新通知在傳送途中丟失，可能會導致無法繼續通信。爲避免此類問題的發生，發送端主機會時不時的發送一個叫做窗口探測的數據段，此數據段僅含一個字節以獲取最新的窗口大小信息。

TCP擁塞控制 – 慢啓動，擁塞窗口調整

一般來說，計算機網絡都處在一個共享的環境。因此也有可能會因爲其他主機之間的通信使得網絡擁堵。在網絡出現擁堵時，如果突然發
送一個較大量的數據，極有可能會導致整個網絡的癱瘓。TCP爲了防止該問題的出現，在通信一開始時就會通過一個叫做慢啓動的算法得出的數值，對發送數據量進行控制。

• 爲了在發送端調節所要發送數據的量，定義了一個叫做“擁塞窗口”的概念(應該是發送端的滑動窗口)。於是在慢啓動的時候，將這個擁塞窗口的大小設置爲1個數據段（1MSS）發送數據，之後每收到一次確認應答（ACK），擁塞窗口的值就加1。在發送數據包時，將擁塞窗口的大小與接收端主機通知的窗口大小做比較，然後按照它們當中較小那個值，發送比其還要小的數據量。
• 如果觸發超時重發機制，那麼擁塞窗口的初始值可以設置爲1以後再進行慢啓動修正.
• 隨着包的每次往返，擁塞窗口也會以1、2、4等指數函數的增長，擁堵狀況激增甚至導致網絡擁塞的發生。爲了防止這些，引入了
  慢啓動閥值的概念。只要擁塞窗口的值超出這個閥值，在每收到一次確認應答時，只允許以下面這種比例放大擁塞窗口：
  
  TCP的通信開始時，並沒有設置相應的慢啓動閥值（與窗口的最大值相同） 。
• 超時重發時，慢啓動閥值的大小被設置爲當時擁塞窗口一半的大小。然後將滑動窗口大小設置爲1,再慢慢增長和窗口探測.
  因爲高速重發要求至少3次的確認應答數據段到達對方主機後纔會觸發，相比超時重發,高速重發時候的網絡擁堵要輕一些。
• 由重複確認應答進行高速重發控制時，慢啓動閥值的大小被設置爲當時窗口大小的一半+3個數據段的大小.
  IP層請看後續博客…