tcp/udp協議概述

傳輸層協議基本概念

傳輸層協議建立在網絡層和會話層之間，為應用層實體提供端到端的通信功能，確保數據包的順序傳送及數據的完整性。它利用網絡層提供的服務，并通過傳輸層地址（端口號）提供給高層用戶傳輸數據的通信端口，使得應用進程之間能夠進行可靠的、透明的數據傳輸，
這里我們需要給大家介紹一下常見的網絡模型，最先是OSI七層網絡模型，但是后來變為TCP/IC四層模型。

網絡模型

OSI七層網絡模型:
每一層都專注做一件事情，并且每一層都需要使用下一層提供的功能比如傳輸層需要使用網絡層提供的路由和尋址功能，這樣傳輸層才知道把數據傳輸到哪里去。OSI 的七層體系結構概念清楚，理論也很完整，但是它比較復雜而且不實用，而且有些功能在多個層中重復出現。

TCP/IP四層網絡模型:

而我們的五層TCP/IP網絡模型是將網絡接口層換為物理層和數據鏈路層,

TCP/UDP在網絡模型的位置

由圖可知，我們的TCP/UDP位于傳輸層的位置
傳輸層： 傳輸層是TCP/IP協議五層模型中的第四層。它提供了應用程序間的通信，它負責數據能夠從發送端傳輸到接收端。其功能包括：一、格式化信息流；二、提供可靠傳輸。為實現后者，傳輸層協議規定接收端必須發回確認，并且假如分組丟失，必須重新發送。

再談端口號： 在網絡知識掃盲博客中談到端口號標識了一個主機上進行通信的不同應用程序。在TCP/IP協議中, 用"源IP", “源端口號”, “目的IP”, “目的端口號”, “協議號” 這樣一個五元組來標識一個通信(可以通過 netstat -n查看，協議號指的是那個使用協議)。
一個進程可以綁定多個端口號，但是一個端口號不能被多個進程綁定。

端口號范圍劃分：

0 - 1023： 知名端口號，HTTP、FTP、 SSH等這些廣為使用的應用層協議他們的端口號都是固定的，自己寫的程序中，不能隨意綁定知名端口號。
1024 - 65535：操作系統動態分配的端口號。 客戶端程序的端口號，就是由操作系統從這個范圍分配的。
常見的知名端口號：

ssh服務器：22端口
ftp服務器：21端口
http服務器：80端口
telnet服務器：23端口
https服務器：443端口
MYSQL服務器：3306端口
在Linux操作系統中使用命令cat /etc/services可以看到所有的知名端口。

netstat工具： 用來查看網絡狀態。

n 拒絕顯示別名，能顯示數字的全部轉化成數字
l 僅列出有在Listen (監聽)的服務狀態
p 顯示正在使用Socket的程序識別碼和程序名稱
t (tcp)僅顯示tcp相關選項
u u (udp)僅顯示udp相關選項
a (all)顯示所有選項，默認不顯示LISTEN相關
pidof [進程名]： 可以根據進程名直接查看服務器的進程id。例如：pidof sshd。

TCP/UDP的區別

• ??連接方式??
  ??TCP??：是面向連接的協議，在數據傳輸前，通信雙方需要通過三次握手建立連接，數據傳輸完成后，還需通過四次揮手釋放連接。例如，當你訪問網頁時，瀏覽器和服務器之間會先建立TCP連接，之后才開始傳輸網頁數據。
  ??UDP??：是無連接的協議，發送數據之前不需要建立連接，發送后也無需釋放連接。發送方只需將數據封裝成數據報發送出去，接收方直接接收數據報。像在網絡上觀看視頻或者聽音樂時，大多使用UDP傳輸協議。

• ??傳輸可靠性??
  ??TCP??：提供可靠的傳輸服務，它通過多種機制來確保數據的正確傳輸。包括面向字節流和緩存機制，將應用數據分割成適合發送的數據塊；超時重發和確認機制，發送數據段后啟動定時器，若未及時收到確認則重發；檢驗和機制，檢測數據在傳輸過程中的變化；字節編號機制，對字節進行編號，接收方按順序交給應用層；自動丟棄重復機制，丟棄重復的數據。這些機制保證了數據的完整、無損且按順序到達。
  ??UDP??：提供不可靠的傳輸服務，不保證數據的可靠交付，不確認報文是否到達，不對報文排序，也沒有超時重發等機制。應用程序需要自己承擔可靠性方面的工作。比如，在實時視頻流中，如果個別數據包丟失，可能不會對整體觀看體驗造成太大影響，UDP不會為此進行重傳。

• ??傳輸效率??
  ??TCP??：由于要建立連接、進行確認、重傳等操作，會產生一定的開銷，傳輸效率相對較低，傳輸速度較慢。而且TCP不支持多播和廣播，只能進行一對一的通信。
  ??UDP??：沒有連接建立和維護的開銷，也沒有擁塞控制機制，當網絡出現擁塞時不會降低源主機的發送速率，因此傳輸速度快，適用于對實時性要求高、允許少量數據丟失的應用場景，如實時音視頻傳輸、在線游戲等。

• ??數據順序??
  ??TCP??：保證數據的順序性，接收方會按照發送方發送數據的順序將數據交付給應用層。即使數據在網絡中可能會亂序到達，TCP也會在接收端進行排序。
  ??UDP??：不保證數據的順序性，數據報可能會以亂序的方式到達接收方，接收方需要自己處理數據的順序問題。

• ??首部開銷??
  ??TCP??：首部開銷較大，一般為20個字節，包含了源端口、目的端口、序列號、確認號等多個字段，用于實現可靠傳輸和連接管理等功能。
  ??UDP??：首部開銷較小，只有8個字節，僅包含源端口、目的端口、長度和檢驗和四個字段，主要用于標識發送端和接收端的端口號以及數據報的長度和校驗。

??- 應用場景??
??TCP??：適用于對數據準確性、完整性要求較高，對實時性要求相對較低的應用，如文件傳輸（FTP）、電子郵件（SMTP）、網頁瀏覽（HTTP）等。
??UDP??：適用于對實時性要求較高、對數據丟失不太敏感、傳輸經濟性要求較高的應用，如視頻直播、在線游戲、域名系統（DNS）查詢、實時音視頻通信等。

tcp

頭部格式

源端?號和?的端?號：
?于多路復?/分解來?或送到上層應?的數據。告訴主機報?段來?哪?，傳給哪個上層協議或應?程序。
序列號：
該報?段?字節的字節流編號，?來解決?絡包亂序問題。確認應答號：對發送來的 TCP 報?段的響應，值是收到的 TCP 報?段的序號值加1，?來解決不丟包的問題。序列號和確認應答號都?于實現可靠數據傳輸。
?部?度：
標識 TCP 頭部有多少字節，最? 60。
窗???：
接收窗?，告訴對?本端TCP緩沖區還有多少空間可以接收數據，?來做流量控制。
標志字段：
ACK：?于指示確認應答號值是否有效，置1表示包含?個對已成功接收報?段的確認；
RST：?于重置?個已經混亂的連接，或拒絕?個?效的數據段或者連接請求；
SYN：?于連接建?過程，請求建??個連接；
FIN：?于斷開連接，表示發送?沒有數據要傳輸了。
檢驗和：
接收?使?檢驗和來檢查該報?段(頭部+數據)中是否出現差錯（CRC算法），同 UDP。
列舉TCP選項
TCP頭部的最后?個選項字段（options）是可變?的可選信息。這部分最多包含40字節，因為TCP頭部最?是60
字節（其中還包含前?討論的20字節的固定部分）。
選項的第?個字段kind說明選項的類型，有的TCP選項沒有后?兩個字段，僅包含1字節的kind字段。
第?個字段length（如果有的話）指定該選項的總?度。該?度包括kind字段和length字段占據的2字節。
第三個字段info（如果有的話）是選項的具體信息。

常見的TCP選項(7種)

1、kind=0，選項表結束（EOP）選項。
?個報?段僅??次。放在末尾?于填充，?途是說明：?部已經沒有更多的消息，應?數據在下?個32位字開始
處。
2、kind=1，空操作（NOP）選項。
沒有特殊含義，?般?于將TCP選項的總?度填充為4字節的整數倍。
3、kind=2，最?報?段?度（MSS）選項。
TCP連接初始化時，通信雙?使?該選項來協商最?報?段?度。TCP模塊通常將MSS設置為（MTU-40）字節（減
掉的這40字節包括20字節的TCP頭部和20字節的IP頭部）。
這樣攜帶TCP報?段的IP數據報的?度就不會超過MTU（假設TCP頭部和IP頭部都不包含選項字段，并且這也是?
般情況），從?避免本機發?IP分?。對以太???，MSS值是1460（1500-40）字節。
4、kind=3，窗?擴?因?選項。
TCP連接初始化時，通信雙?使?該選項來協商接收窗?的擴?因?。在TCP的頭部中，接收窗???是?16位表
示的，故最?為65535字節，但實際上TCP模塊允許的接收窗???遠不?這個數（為了提?TCP通信的吞吐
量）。窗?擴?因?解決了這個問題。
假設 TCP 頭部中的接收通告窗???是 N，窗?擴?因?（移位數）是 M，那么 TCP 報?段的實際接收通告窗?
??是 N*2M，或者說 N 左移 M 位。注意，M的取值范圍是 0～14。
和 MSS 選項?樣，窗?擴?因?選項只能出現在同步報?段中，否則將被忽略。但同步報?段本身不執?窗?擴
?操作，即同步報?段頭部的接收窗???就是該 TCP 報?段的實際接收窗???。當連接建?好之后，每個數據
傳輸?向的窗?擴?因?就固定不變了。
5、kind=4，選擇性確認（Selective Acknowledgment，SACK）選項。
TCP 通信時，如果某個 TCP 報?段丟失，則 TCP 會重傳最后被確認的 TCP 報?段后續的所有報?段，這樣原先已
經正確傳輸的 TCP 報?段也可能重復發送，從?降低了 TCP 性能。
SACK 技術使 TCP 只重新發送丟失的 TCP 報?段，?不?發送所有未被確認的 TCP 報?段。選擇性確認選項?在
連接初始化時，表示是否?持 SACK 技術。
6、kind=5，SACK實際?作的選項。
該選項的參數告訴發送?本端已經收到并緩存的不連續的數據塊，從?讓發送端可以據此檢查并重發丟失的數據
塊。
每個塊邊沿（edge of block）參數包含?個4字節的序號。其中塊左邊沿表示不連續塊的第?個數據的序號，?塊
右邊沿則表示不連續塊的最后?個數據的序號的下?個序號。這樣?對參數（塊左邊沿和塊右邊沿）之間的數據是
沒有收到的。因為?個塊信息占?8字節，所以 TCP 頭部選項中實際上最多可以包含4個這樣的不連續數據塊（考
慮選項類型和?度占?的2字節）。
7、kind=8，時間戳選項。
該選項提供了較為準確的計算通信雙?之間的回路時間（Round Trip Time，RTT）的?法，為TCP流量控制提供信
息。

可靠傳輸機制

三次握手四次揮手

TCP 是?向連接的協議，所以使? TCP 前必須先建?連接，?建?連接是通過三次握?來進?的

1、第?次握?：SYN報?：
客戶端隨機初始化序列號
client_isn ，放進TCP?部序列號段，然后把SYN置1。把SYN報?發送給服務端，表示
發起連接，之后客戶端處于
SYN-SENT 狀態。
2、第?次握?：SYN+ACK報?：
服務端收到客戶端的SYN報?之后，會把??隨機初始化的序號
號」填?
server_isn 放進TCP?部序列號段，「確認應答
client_isn + 1 ，把SYN和ACK標志位置為1。把SYN+ACK報?發送給客戶端，然后進?
SYN-RCVD 狀
態,表示服務器接受了客戶端的請求，并希望建?連接。
3、第三次握?：ACK報?：
客戶端收到服務端報?后，還要向服務端回應最后?個應答報?。?先該應答報? TCP ?部 ACK 標志位置為 1 ，
其次「確認應答號」字段填?
server_isn + 1 ，最后把報?發送給服務端，這次報?可以攜帶客戶到服務器的
數據，之后客戶端處于
ESTABLISHED 狀態, 表示客戶端已經準備好與服務器進?數據傳輸。
服務器收到客戶端的應答報?后，也進?
ESTABLISHED 狀態。
此時，TCP 連接已經建?起來，通信雙?可以開始進?數據傳輸

• 第三次握?是可以攜帶數據的，但是前兩次握?是不可以攜帶數據的。

為什么需要三次握手

三次握?才能保證雙?具有接收和發送的能?

1. 三次握?才可以阻?重復歷史連接的初始化(主因)
2. 三次握?才可以同步雙?的初始序列號
3. 三次握?才可以避免資源浪費
   解釋：

• 1.阻?重復歷史連接的初始化（主因）
  • 1. 當因為?絡阻塞原因，客戶端向服務器發送了兩次SYN報?
  • 2.舊的SYN報?先到達服務端，服務端回?個ACK+SYN報?
  • 3.客戶端收到后可以根據?身的上下?，判斷這是?個歷史連接（序列號過期或超時），那么客戶端就會發送 RST 報?給服務端，表示中?這?次連接。
  • 4. 服務器收到RST報?，會釋放連接
  • 5. 新的SYN報?抵達之后，客戶端和服務器之間進?正常的三次握?

如果只是兩次握?，服務端在收到SYN報?之后，就進?到
ESTABLISHED 狀態, 服務器端并不知道這次是歷史連
接，直接與客戶端建?連接并向客戶端發送數據（資源浪費），但是客戶端會判定這次連接是歷史連接，從?發送RST報?來斷開連接。
所以要想讓服務器發送數據前，阻?掉歷史連接，就需要三次握?。

• 2、同步雙?的初始序列號

TCP 協議的通信雙?， 都必須維護?個「序列號」， 序列號是可靠傳輸的?個關鍵因素。
1.接收端可以去除重復數據。
2.接收端可以按照序列號順序接收。
3.標識發送的數據包，哪些已經被收到。

過程

1. 客戶端發送第?個報?，攜帶客戶端初始序列號的SYN報?。
2. 服務器發送第?個報?，攜帶服務器初始序列號的ACK + SYN的應答報?，表示收到客戶端的SYN報?。
3. 客戶端發送第三個報?，攜帶服務器的ACK應答報?。
   這樣?來?回，才能確保雙?的初始序列號能被可靠的同步。
   兩次握?只保證了??的初始序列號能被對?成功接收，沒辦法保證雙?的初始序列號都能被確認接收。四次握?
   也能保證雙?的初始化序號同步，但是可以省略成三次。

3、避免資源浪費。

1. 只有兩次握?時，如果客戶端的SYN請求連接在?絡中阻塞，客戶端沒有收到服務端的ACK報?，會重新發送
   SYN。
2. 由于沒有第三次握?，服務器不清楚客戶端是否收到了??發送的建?連接的 ACK 確認信號，所以每收到?
   個 SYN 就只能先主動建??個連接， 建?多個冗余的?效鏈接，造成不必要的資源浪費。
   所以通過TCP三次握?，能能防?歷史連接的建?，能減少雙?不必要的資源開銷，能幫助雙?同步初始化序列號

• 「兩次握?」：?法防?歷史連接的建?，會造成雙?資源的浪費，也?法可靠的同步雙?序列號；
• 「四次握?」：三次握?就已經理論上最少可靠連接建?，所以不需要使?更多的通信次數。

半連接狀態

半連接隊列（SYN隊列）?于存放已經發送了 SYN（同步）包，但還未完成三次握?的連接：服務器第?次收到客戶端的 SYN 之后，就會處于 SYN_RCVD 狀態，此時雙?還沒有完全建?其連接，服務器會把此種狀態下請求連接放在?個隊列?，我們把這種隊列稱之為半連接隊列。
全連接隊列（Accept隊列）?于存放已經完成三次握?，處于完全建?連接狀態的連接。

SYN攻擊

在 SYN 攻擊中，攻擊者發送?量偽造的 SYN 請求到?標服務器，但不完成后續的握?過程，從?讓服務器?直等待確認，消耗服務器的資源（如半連接隊列和系統資源），當半連接隊列滿了之后，后續再收到SYN報?就會丟棄，導致?法與客戶端之間建?連接。

四次揮手

TCP 斷開連接是通過四次揮?來進?的，四次揮?的過程如下圖：

四次揮?的過程
在揮?之前，客戶端和服務器都處于
ESTABLISHED 狀態

1. 第?次揮?：假設客戶端打算關閉連接，發送?個TCP?部FIN被置1的
   FIN_WAIT1 狀態
   FIN 報?給服務端, 此時客戶端處于
2. 第?次揮?：服務端收到以后，向客戶端發送ACK應答報?，且把客戶端的序列號值+1作為ACK報?的序列號
   值，表明已經收到客戶端的報?了，此時服務端處于
   CLOSE_WAIT 狀態
3. 第三次揮?：等待服務端處理完數據后，向客戶端發送FIN報?。此時服務端處于
   LAST_ACK 的狀態
4. 第四次揮?：客戶端接收到FIN報?后回?個ACK應答報?，之后客戶端處于
   TIME_WAIT 狀態
5. 服務器收到ACK報?后，進?
   CLOSE 狀態，服務器完成連接關閉。
6. 客戶端在經過 2MSL ?段時間后，?動進?
   CLOSE 狀態，客戶端也完成連接的關閉。

為什么揮?需要四次

關閉連接時，客戶端發送FIN報?，表示其不再發送數據，但還可以接收數據。
服務端收到FIN報?，可以直接發送SYN+ACK報?。其中ACK報?是?來應答的，SYN報?是?來同步的。但是關閉連接時，服務端可能還要數據需要處理和發送，所以先回?個ACK應答報?，等到其不再發送數據時，才發送FIN報?給客戶端表示同意關閉連接。
從上?過程可知：服務端通常需要等待完成數據的發送和處理，所以服務端的ACK和FIN?般都會分開發送，從??三次握?導致多了?次。

為什么需要 TIME_WAIT 狀態

主動發起關閉連接的??，才會有 TIME-WAIT 狀態。
需要 TIME-WAIT 狀態，主要是兩個原因：

1. 防?歷史連接中的數據，被后?相同四元組的連接錯誤的接收；
   如果?絡出現擁塞或延遲，數據包可能會在?絡中滯留?段時間，甚?超過了原始連接關閉的時間。如果沒有 TIME_WAIT 狀態，客戶端直接進?到CLOSE狀態，這些滯留的數據包可能會被傳遞給新連接，導致新連接的數據被舊連接的數據?擾。
   經過 2MSL 這個時間，?以讓兩個?向上的數據包都被丟棄，使得原來連接的數據包在?絡中都?然消失，再出現的數據包?定都是新建?連接所產?的。
2. 保證「被動關閉連接」的??能被正確的關閉，即保證最后的 ACK 能讓被動關閉?接收，從?幫助其正常關閉

如果最后的?次ACK報?丟失（第四次揮?），客戶端沒有TIME_WAIT 狀態，直接進?ClOSE，服務端?直在等待ACK狀態，?直沒有等到，就會重發FIN報?，?客戶端已經進?到關閉狀態，在收到服務端重傳的 FIN 報?后，就會回 RST 報?,服務端收到這個 RST 并將其解釋為?個錯誤, 為了防?這種情況出現，客戶端必須等待?夠?的時間，確保服務端能夠收到 ACK，如果服務端沒有收到 ACK，那么就會觸發 TCP 重傳機制，服務端會重新發送?個 FIN，這樣?去?來剛好兩個 MSL 的時間。
如果 TIME-WAIT 等待?夠?的情況就會遇到兩種情況：

1. 服務端正常收到四次揮?的最后?個 ACK 報?，則服務端正常關閉連接。
2. 服務端沒有收到四次揮?的最后?個 ACK 報?時，則會重發 FIN 關閉連接報?并等待新的 ACK 報?。

為什么 TIME_WAIT 等待的時間是 2MSL

1. MSL是 Maximum Segment Lifetime ，報?最??存時間，它是任何報?在?絡上存在的最?時間，超過這個時間報?將被丟棄。
2. 等待MSL兩倍：?絡中可能存在發送?的數據包，當這些發送?的數據包被接收?處理后?會向對?發送響應，所以?來?回需要等待 2 倍的時間。
3. 1 個 MSL 確保四次揮?中主動關閉?最后的 ACK 報?最終能達到對端；1 個 MSL 確保對端沒有收到 ACK 重傳的 FIN 報?可以到達。
4. 2MSL 的時間是從客戶端接收到 FIN 后發送 ACK 開始計時的。如果在 TIME-WAIT 時間內，因為客戶端的 ACK 沒有傳輸到服務端，客戶端?接收到了服務端重發的 FIN 報?，那么 2MSL 時間將重新計時。

TIME_WAIT 過多有什么危害？

過多的TIME-WAIT 狀態主要的危害有兩種：

1. 內存資源占?；
2. 對端?資源的占?，?個 TCP 連接?少消耗?個本地端?；
   如果發起連接??的
   TIME_WAIT 狀態過多，占滿了所有端?資源，則會導致?法創建新連接。

####TCP重傳機制
//to do

####滑動窗口
/todo
####流量控制
//todo
####擁塞控制
//todo
####快速恢復

UDP

####報文結構

?標端?和源端?：
主要是告訴 UDP 協議應該把報?發給哪個進程。
包?度：
該字段保存了 UDP ?部的?度跟數據的?度之和。
校驗和：
校驗和是為了提供可靠的 UDP ?部和數據?設計，接收?使?檢驗和來檢查該報?段中是否出現差錯。