你真的會TCP與UDP？

一、TCP

1.1TCP特點

• TCP是面向連接的傳輸層協議，應用層協議是用tcp協議前必須建立連接，數據傳輸完畢需要釋放tcp連接。
• TCP值能是點對點通訊
• TCP提供可靠的交付服務：數據五差錯、不丟失、不重複並且按序到達
• TCP提供的全雙工通信，TCP允許成序任何時候發送數據，TCP連接的兩端都設置有發送緩存和接收緩存，在發送時，應用程序在把數據傳送給TCP的緩存後，就可以做自己的事，而TCP在合適的時候把數據發送出去。在接收時，TCP把收到的數據放入緩存，上層的應用進程在合適的時候讀取緩存中的數據。
• TCP面向字節流：
  

面向字節流的含義是：雖然應用程序和TCP的交互是一次一個數據塊（大小不等），但TCP把應用程序交下來的數據僅僅看成是一連串的無結構的字節流。TCP並不知道所傳送的字節流的含義。TCP不保證接收方應用程序所收到的數據塊和發送方應用程序所發出的數據塊具有對應大小的關係（例如，發送方應用程序交給發送方的TCP共10個數據塊，但接收方的TCP可能只用了4個數據塊就把收到的字節流交付上層的應用程序）。但接收方應用程序收到的字節流必須和發送方應用程序發出的字節流完全一樣。當然，接收方的應用程序必須有能力識別收到的字節流，把它還原成有意義的應用層數據。

1.2 TCP報文段和首部格式

我們先看看TCP報文進出協議棧時前後封裝了些什麼


源/目端口號：應用進程與應用進程之間通信的監聽出入口。
序列號：序列號隨機生成，每次序號都會不一樣，ISN算法隨機生成。序列號會隨着雙方通訊而不斷的增加。序列號一共32比特，最大值2^32-1，到達最大值後重新從0開始。

隨機生成算法：ISN = M + F(localhost, localport, remotehost, remoteport).
M是一個計時器，這個計時器每隔4毫秒加1。
F是一個Hash算法，根據源IP、目的IP、源端口、目的端口生成一個隨機數值。要保證hash算法不能被外部輕易推算得出，用MD5算法是一個比較好的選擇。

確認序列號：確認序列號是上次已成功接收到數據字節序列號加1。ack=seq+1
首部長度：選項不用，TCP的頭部爲20字節；存在選項則爲60字節。
保留：爲將來定義新的用途保留，現在一般置0。
標誌：每個標誌佔1比特，1表示有效，0爲無效。

• URG：緊急指針是否有效。有效會告訴系統此時有緊急數據需要儘快傳送。
• ACK：確認序號是否有效。僅當ACK=1時確認字段纔有效。建立連接後，所有的傳送的報文都必須把ACK置爲1。
• PSH：推送 ，接收方應該儘快將這個報文段交給應用層。不必等待緩存區滿後再向上交付
• RST：復位，對方要求重新建立連接。當RST=1代表TCP連接出現嚴重差錯，必須釋放連接再重新建立連接。
• SYN：同步序列號，請求建立連接。在連接請求中，SYN=1 ACK=0表示該數據段是未捎帶確認的連接請求報文；SYN=1 ACK=1表示是一個捎帶了確認的連接請求報文。
• FIN：用於釋放連接，FIN=1時表示發送方已經沒有數據發送了，即關閉本方數據流。
  **窗口：**滑動窗口大小，用來告知發送端接受端的緩存大小，以此控制發送端發送數據的速率，從而達到流量控制。窗口大小最大爲65535（ 2^16 -1 ）。
  **檢驗和：**發送端基於數據內容計算一個數值，接收端要與發送端數值結果完全一樣，才能證明數據的有效性。接收端checksum校驗失敗的時候會直接丟掉這個數據包。CheckSum是根據僞頭+TCP頭+TCP數據三部分進行計算的。另外對於大的數據包，checksum並不能可靠的反應比特錯誤，應用層應該再添加自己的校驗方式。
  緊急指針： 16位，指向後面是優先數據的字節，在URG標誌設置爲1時纔有效。如果URG標誌沒有被設置，緊急域作爲填充。加快處理標示爲緊急的數據段。
  選項：長度不定，但長度必須以是32bits的整數倍,最長可以達到40字節。常見的選項包括MSS、SACK、Timestamp等等，
  **數據：**可選，在一個連接建立和一個連接終止時，雙方交換的報文段僅有 TCP 首部。如果一方沒有數據要發送，也使用沒有任何數據的首部來確認收到的數據。在處理超時的許多情況中，也會發送不帶任何數據的報文段、

1.3TCP的建立和終止

1.3.1正常三次握手

注：TCP三次握手，可能是四次，如雙方同時主動請求連接

1.3.2 四次揮手

1.3.3 爲什麼連接只需要三次握手，斷開需要四次？

• 這是因爲服務端在LISTEN狀態下，收到建立連接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。而關閉連接時，當收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還能接收數據，己方是否現在關閉發送數據通道，需要上層應用來決定，因此，己方ACK和FIN一般都會分開發送。

1.3.4 三次握手存在什麼問題？怎麼解決

問題：
三次握手會存在syn flood攻擊：最基本的DoS攻擊就是利用合理的服務請求來佔用過多的服務資源，從而使合法用戶無法得到服務的響應。syn flood屬於Dos攻擊的一種。
如果惡意的向某個服務器端口發送大量的SYN包，則可以使服務器打開大量的半開連接，分配TCB（Transmission Control Block）, 從而消耗大量的服務器資源，同時也使得正常的連接請求無法被相應。當開放了一個TCP端口後，該端口就處於Listening狀態，不停地監視發到該端口的Syn報文，一 旦接收到Client發來的Syn報文，就需要爲該請求分配一個TCB，通常一個TCB至少需要280個字節，在某些操作系統中TCB甚至需要1300個字節，並返回一個SYN ACK命令，立即轉爲SYN-RECEIVED即半開連接狀態。系統會爲此耗盡資源
防禦措施：

• 無效連接的監視釋放：視系統的半開連接和不活動連接，當達到一定閾值時拆除這些連接，從而釋放系統資源。這種方法對於所有的連接一視同仁，而且由於SYN Flood造成的半開連接數量很大，正常連接請求也被淹沒在其中被這種方式誤釋放掉，因此這種方法屬於入門級的SYN Flood方法。
• 延遲TCB分配：消耗服務器資源主要是因爲當SYN數據報文一到達，系統立即分配TCB，從而佔用了資源。而SYN Flood由於很難建立起正常連接，因此，當正常連接建立起來後再分配TCB則可以有效地減輕服務器資源的消耗。常見的方法是使用Syn Cache和Syn Cookie技術。
• Syn Cache技術：系統在收到一個SYN報文時，在一個專用HASH表中保存這種半連接信息，直到收到正確的迴應ACK報文再分配TCB。這個開銷遠小於TCB的開銷。當然還需要保存序列號。
• Syn Cookie技術 ：Syn Cookie技術則完全不使用任何存儲資源，這種方法比較巧妙，它使用一種特殊的算法生成Sequence Number，這種算法考慮到了對方的IP、端口、己方IP、端口的固定信息，以及對方無法知道而己方比較固定的一些信息，如MSS(Maximum Segment Size，最大報文段大小，指的是TCP報文的最大數據報長度，其中不包括TCP首部長度。)、時間等，在收到對方的ACK報文後，重新計算一遍，看其是否與對方迴應報文中的（Sequence Number-1）相同，從而決定是否分配TCB資源。
• syn代理：SYN Proxy防火牆，防火牆確定連接有效性後防火牆纔會向內部服務器發起SYN請求。防火牆代服務器發出的SYN ACK包使用的序列號爲c, 而真正的服務器迴應的序列號爲c’, 這樣，在每個數據報文經過防火牆的時候進行序列號的修改。另一種方式是防火牆確定了連接的安全後，會發出一個safe reset命令，client會進行重新連接，這時出現的syn報文會直接放行。這樣不需要修改序列號了。但是，client需要發起兩次握手過程，因此建立連接的時間將會延長。

1.3.5 MSL與2MSL等待時間

• TCP報文的在網絡上單向傳送的最大生存時間叫做MSL

• 2MSL（最大報文段生存時間）等待狀態。之所以要等待，是因爲關閉方要確認處於“CLOSE_WAIT”狀態的被關閉方收到它最後的ACK報文，，等待確認報文來回的時間就是2MSL，如果被關閉方在2MSL內都沒有收到ACK，就會重複發送FIN報文。如果關閉方在2MSL時間內未收到被關閉方的報文，則默認收到
  Windows : MSL = 2 min
  linux(Ubuntu, CentOs) : MSL = 60s

• 2MLS等待原因

  • 2MSL的時間能保證在兩個傳輸方向上的未被接收的數據和遲到的數據全部被丟棄（當連接關閉時，有可能收到遲到的報文段。這時，若立馬就建立新的連接（同一端口），那麼新的連接就會接收遲到的報文，誤以爲是發給自己的）
    -保證了最後一個報文可靠到達(假設最後一個ACK丟失, 那麼服務器會再重發一個FIN. 這時雖然客戶端的進程不在了,但是TCP連接還在,仍然可以重發LAST_ACK）如果直到2MSL，客戶端都沒有再次收到FIN，那麼客戶端推斷ACK已經被成功接收，則結束TCP連接。

1.4 可靠傳輸實現機制

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

• TCP數據傳輸是以段爲單位發送數據，每一段數據都有序列號，實現數據的排序、
• TCP通過肯定的確認應答（ACK）實現可靠的數據傳輸。當發送端將數據發出之後會等待對端的確認應答。如果有確認應答，說明數據已經成功到達對端。反之，則數據丟失的可能性很大。

1.4.2 重發超時如何確定

• 數據被重發後若還沒收到確認應答，則進行再次發送，等待確認應答時間會以2倍、4倍指數延長。
  

1.5 TCP傳輸控制

1.5.1 利用窗口控制提高效率

將窗口分等級，一次簡歷

1.5.2 流控

流控：TCP提供以中機制可以讓發送段根據接收端的接收能力控制發送數據包數量

1.5.3 擁塞控制

• TCP的通信開始時間。並沒有設置慢啓動閥值，而是在重傳時纔會設置（設置爲擁塞窗口的一半大小）
• 上圖是一個簡單的示意圖，下面餓哦們介紹一個用色窗口一行設置了的啓動流程
  

1.5.4 提高網絡利用率的規範

• Nagle算法：點擊查看
• 延遲確認應答：避免因爲剛接收數據緩衝區變小而早成，窗口的大小調小。
• 捎帶應答：是TCP包中既發包有確認的一種應答機制，提高網絡利用率
  

1.6TCP中的四種計時器

• **重傳計時器：**在數據發送完成後開始計時，如果在規定的時間內沒有收到ACK就會重傳。
• **堅持計時器：**在擁塞控制的時候使用，當接收端通知發送端窗口大小爲0後，發送端會停止發送數據，但是當接收端有足夠緩存之後，會重新通知新的窗口大小給發送端，如果新窗口大小的報文丟失了，就會進入一個死循環，爲了應對這種情況，當發送端收到窗口大小爲0的通知之後，會啓動堅持計時器，到設定時間後會向接收端發送探測報文，該報文中只有一個字節的數據，他有序號，但是這個序號永遠不需要確認，探測報文的目的是提醒發送端，新發送的窗口大小丟失。發送之後會將該計時器的值設爲原來的兩倍，直到到閥值（一般爲60s），然後每隔60S就會發送一個探測報文，知道接收到新窗口的確認報文爲止。
• 保活計時器：建立TCP連接後，客戶端故障，tcp連接閒置，服務端設置保活計時器後，在超過計時器設定時間就會終止連接
• 時間等待計時器：在連接終止時，會設置一個時間等待計時器，就是time_wait狀態時的計時器，該計時器可以接受重複的Fin報文到達目的站，從而將其丟棄（時間設置一般爲報文的期待時間的2倍）

二、UDP

2.1 UDP特點

• UDP是無連接的，減小了開銷和發送數據前的時延（相對TCP而言）
• UDP採用最大努力交付，主機不需要維護複雜的連接狀態；
• UDP是面向報文的，只在應用層交下來的報文前增加了首部後就向下交付IP層；
• UDP是無阻塞控制的，即使網絡中存在阻塞，也不會影響發送端的發送頻率
• UDP支持一對一、一對多、多對一、多對多的交互通信
• UDP的首部開銷小，只有8個字節，它比TCP的20個字節的首部要短。

2.2 UDP報文結構

2.2常見應用：

• 包總量較少的通信（DNS、SNMP等）
• 視頻、音頻等多媒體通信（即時通信）
• 限定於LAN等特定網絡中的應用通信
• 廣播通信（廣播、多播）