TCP與UDP篇
TCP提供可靠的通信傳輸,而UDP則常被用於廣播和細節控制交給應用的通信傳輸
傳輸層
傳輸層的作用:
網絡層只把分組發送到目的主機，但是真正通信的並不是主機而是主機中的進程。傳輸層提供了進程間的邏輯通信，傳輸層向高層用戶屏蔽了下面網絡層的核心細節，使應用程序看起來像是在兩個傳輸層實體之間有一條端到端的邏輯通信信道。
以快遞包裹爲例,運輸包裹的快遞單上寫了發貨的地址(源IP地址)和收貨的地址(目標IP地址),這樣就可以把包裹發送到指定的地點了,但是到了指定地點後怎麼才能知道應該發送給那個人呢,這個時候就需要依靠快遞單上的聯繫人信息了(傳輸層協議指定的端口號對應的應用程序).
常用的端口號
| 應用程序 | DNS | HTTP | SMTP | FTP | TFTP | TELNET | SSH | MySQL |
|---|---|---|---|---|---|---|---|---|
| 熟知端口 | 53 | 80 | 25 | 20,21 | 69 | 23 | 22 | 3306 |
| 傳輸層協議 | UDP | TCP | TCP | TCP | UDP | TCP |
TCP與UDP特點
- 傳輸控制協議 TCP（Transmission Control Protocol）是面向連接的，提供可靠交付，有流量控制，擁塞控制，提供全雙工通信，面向字節流（把應用層傳下來的報文看成字節流，把字節流組織成大小不等的數據塊），每一條 TCP 連接只能是點對點的（一對一）。
- 用戶數據報協議 UDP（User Datagram Protocol）是無連接的，盡最大可能交付，沒有擁塞控制，面向報文（對於應用程序傳下來的報文不合並也不拆分，只是添加 UDP 首部），支持一對一、一對多、多對一和多對多的交互通信。
UDP首部
首部字段只有 8 個字節，包括源端口、目的端口、長度、檢驗和。12 字節的僞首部是爲了計算檢驗和臨時添加的。
TCP首部
- 源端口號 : 表示發送端端口號
- 目的端口 : 表示接收端端口號
- 序列號 : 用於對字節流進行編號,序列號在建立連接時由計算機生成的隨機數作爲其初始值,假如第一個字節流的編號爲123,如果攜帶的數據長度爲100字節,則下一個報文段的序列號爲223.
- 確認應答號 : 期望收到的下一個報文段的序號. 例如 B 正確收到 A 發送來的一個報文段，序號爲 501，攜帶的數據長度爲 200 字節，因此 B 期望下一個報文段的序號爲 701，B 發送給 A 的確認報文段中確認應答號就爲 701。
- 數據偏移 : 指的是數據部分距離報文段起始處的偏移量，實際上指的是首部的長度。
- 保留 : 該字段是爲了以後擴展時使用
- 控制位 :
確認ACK: 當 ACK=1 時確認號字段有效，否則無效。TCP 規定，在連接建立後所有傳送的報文段都必須把 ACK 置 1
同步SYN: 在連接建立時用來同步序號。當 SYN=1，ACK=0 時表示這是一個連接請求報文段。若對方同意建立連接，則響應報文中 SYN=1，ACK=1
終止FIN: 用來釋放一個連接，當 FIN=1 時，表示此報文段的發送方的數據已發送完畢，並要求釋放連接 - 窗口大小 : 窗口值作爲接收方讓發送方設置其發送窗口的依據。之所以要有這個限制，是因爲接收方的數據緩存空間是有限的。
在建立連接和斷開連接時發送的SYN包和FIN雖然不攜帶數據,但是也會作爲一個字節增加對應的序列號
TCP三次握手(TCP連接建立)
- TCP服務器進程先創建傳輸控制塊TCB，時刻準備接受客戶進程的連接請求，此時服務器就進入了LISTEN（監聽）狀態；
- TCP客戶進程也是先創建傳輸控制塊TCB，然後向服務器發出連接請求報文，這是報文首部中的同步位SYN=1，確認位ACK=0，同時選擇一個初始序列號 seq=x ，此時，TCP客戶端進程進入了 SYN-SENT（同步已發送狀態）狀態。TCP規定，SYN報文段（SYN=1的報文段）不能攜帶數據，但需要消耗掉一個序號。
- TCP服務器收到請求報文後，如果同意連接，則發出確認報文。確認報文中 ACK=1，SYN=1，確認號是ack=x+1，同時也要爲自己初始化一個序列號 seq=y，此時，TCP服務器進程進入了SYN-RCVD（同步收到）狀態。這個報文也不能攜帶數據，但是同樣要消耗一個序號。
- TCP客戶進程收到確認後，還要向服務器給出確認。確認報文的ACK=1，ack=y+1，自己的序列號seq=x+1，此時，TCP連接建立，客戶端進入ESTABLISHED（已建立連接）狀態。TCP規定，ACK報文段可以攜帶數據，但是如果不攜帶數據則不消耗序號。
爲什麼TCP客戶端最後還要發送一次確認呢？
一句話，主要防止已經失效的連接請求報文突然又傳送到了服務器，從而產生錯誤。
如果使用的是兩次握手建立連接，假設有這樣一種場景，客戶端發送了第一個請求連接並且沒有丟失，只是因爲在網絡結點中滯留的時間太長了，由於TCP的客戶端遲遲沒有收到確認報文，以爲服務器沒有收到，此時重新向服務器發送這條報文，此後客戶端和服務器經過兩次握手完成連接，傳輸數據，然後關閉連接。此時此前滯留的那一次請求連接，網絡通暢了到達了服務器，這個報文本該是失效的，但是，客戶端並不會處理這個連接,而服務器錯以爲連接已經建立,開始等待客戶端發送請求,這將導致不必要的錯誤和服務器資源的浪費。
如果採用的是三次握手，就算是那一次失效的報文傳送過來了，服務端接受到了那條失效報文並且回覆了確認報文，但是客戶端不會再次發出確認。由於服務器收不到確認，就知道客戶端並沒有請求連接。
TCP四次揮手(TCP連接釋放)
數據傳輸完畢後，雙方都可釋放連接。最開始的時候，客戶端和服務器都是處於ESTABLISHED狀態，然後客戶端主動關閉，服務器被動關閉。
- 客戶端進程發出連接釋放報文，並且停止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。
- 服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，但是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
- 客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送連接釋放報文（在這之前還需要接受服務器發送的最後的數據）。
- 服務器將最後的數據發送完畢後，就向客戶端發送連接釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。
- 客戶端收到服務器的連接釋放報文後，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2∗∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
- 服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB後，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。
四次揮手的原因
客戶端發送了 FIN 連接釋放報文之後，服務器收到了這個報文，就進入了 CLOSE-WAIT 狀態。這個狀態是爲了讓服務器端發送還未傳送完畢的數據，傳送完畢之後，服務器會發送 FIN 連接釋放報文。
爲什麼客戶端最後還要等待2MSL？
客戶端接收到服務器端的 FIN 報文後進入此狀態，此時並不是直接進入 CLOSED 狀態，還需要等待一個時間計時器設置的時間 2MSL。這麼做有兩個理由：
- 確保最後一個確認報文能夠到達。如果 B 沒收到 A 發送來的確認報文，那麼就會重新發送連接釋放請求報文，A 等待一段時間就是爲了處理這種情況的發生
- 等待一段時間是爲了讓本連接持續時間內所產生的所有報文都從網絡中消失，使得下一個新的連接不會出現舊的連接請求報文。
TCP滑動窗口
窗口是緩存的一部分，用來暫時存放字節流。發送方和接收方各有一個窗口，接收方通過 TCP 報文段中的窗口字段告訴發送方自己的窗口大小，發送方根據這個值和其它信息設置自己的窗口大小。
發送窗口內的字節都允許被髮送，接收窗口內的字節都允許被接收。如果發送窗口左部的字節已經發送並且收到了確認，那麼就將發送窗口向右滑動一定距離，直到左部第一個字節不是已發送並且已確認的狀態；接收窗口的滑動類似，接收窗口左部字節已經發送確認並交付主機，就向右滑動接收窗口。
接收窗口只會對窗口內最後一個按序到達的字節進行確認，例如接收窗口已經收到的字節爲 {31, 34, 35}，其中 {31} 按序到達，而 {34, 35} 就不是，因此只對字節 31 進行確認。發送方得到一個字節的確認之後，就知道這個字節之前的所有字節都已經被接收。
[外鏈圖片轉存失敗(img-8RAsQqtk-1566975560833)(https://github.com/CyC2018/CS-Notes/raw/master/docs/notes/pics/a3253deb-8d21-40a1-aae4-7d178e4aa319.jpg)]
TCP 流量控制
流量控制是爲了控制發送方發送速率，保證接收方來得及接收。
接收方發送的確認報文中的窗口字段可以用來控制發送方窗口大小，從而影響發送方的發送速率。將窗口字段設置爲 0，則發送方不能發送數據。
TCP 擁塞控制
如果網絡出現擁塞，分組將會丟失，此時發送方會繼續重傳，從而導致網絡擁塞程度更高。因此當出現擁塞時，應當控制發送方的速率。這一點和流量控制很像，但是出發點不同。流量控制是爲了讓接收方能來得及接收，而擁塞控制是爲了降低整個網絡的擁塞程度。
[外鏈圖片轉存失敗(img-Yl6jmDJa-1566975560833)(https://github.com/CyC2018/CS-Notes/raw/master/docs/notes/pics/51e2ed95-65b8-4ae9-8af3-65602d452a25.jpg)]
TCP 主要通過四個算法來進行擁塞控制：慢開始、擁塞避免、快重傳、快恢復。
發送方需要維護一個叫做擁塞窗口（cwnd）的狀態變量，注意擁塞窗口與發送方窗口的區別：擁塞窗口只是一個狀態變量，實際決定發送方能發送多少數據的是發送方窗口。
爲了便於討論，做如下假設：
- 接收方有足夠大的接收緩存，因此不會發生流量控制；
- 雖然 TCP 的窗口基於字節，但是這裏設窗口的大小單位爲報文段。
[外鏈圖片轉存失敗(img-Ne0xMSPf-1566975560834)(https://github.com/CyC2018/CS-Notes/raw/master/docs/notes/pics/910f613f-514f-4534-87dd-9b4699d59d31.png)]
1. 慢開始與擁塞避免
發送的最初執行慢開始，令 cwnd = 1，發送方只能發送 1 個報文段；當收到確認後，將 cwnd 加倍，因此之後發送方能夠發送的報文段數量爲：2、4、8 …
注意到慢開始每個輪次都將 cwnd 加倍，這樣會讓 cwnd 增長速度非常快，從而使得發送方發送的速度增長速度過快，網絡擁塞的可能性也就更高。設置一個慢開始閥值 ssthresh，當 cwnd >= ssthresh 時，進入擁塞避免，每個輪次只將 cwnd 加 1。
如果出現了超時，則令 ssthresh = cwnd / 2，然後重新執行慢開始。
2. 快重傳與快恢復
在接收方，要求每次接收到報文段都應該對最後一個已收到的有序報文段進行確認。例如已經接收到 M1 和 M2，此時收到 M4，應當發送對 M2 的確認。
在發送方，如果收到三個重複確認，那麼可以知道下一個報文段丟失，此時執行快重傳，立即重傳下一個報文段。例如收到三個 M2，則 M3 丟失，立即重傳 M3。
在這種情況下，只是丟失個別報文段，而不是網絡擁塞。因此執行快恢復，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此時直接進入擁塞避免。
慢開始和快恢復的快慢指的是 cwnd 的設定值，而不是 cwnd 的增長速率。慢開始 cwnd 設定爲 1，而快恢復 cwnd 設定爲 ssthresh。
[外鏈圖片轉存失敗(img-8HMKtR5R-1566975560835)(https://github.com/CyC2018/CS-Notes/raw/master/docs/notes/pics/f61b5419-c94a-4df1-8d4d-aed9ae8cc6d5.png)]