網絡管理 tcp/udp詳解 （傳輸層）

簡介：

TCP和UDP的區別

TCP是面向連接的傳輸控制協議，而UDP提供了無連接的數據報服務。

TCP具有高可靠性，確保傳輸數據的正確性，不出現丟失或亂序；UDP在傳輸數據前不建立連接，不對數據報進行檢查與修改，無須等待對方的應答，所以會出現分組丟失、重復、亂序，應用程序需要負責傳輸可靠性方面的所有工作；

UDP具有較好的實時性，工作效率較TCP協議高；

UDP段結構比TCP的段結構簡單，因此網絡開銷也小。

傳輸層主要采用的兩種通信方式，一種是提供可靠傳輸的TCP協議，一種是提供不可靠傳輸的UDP協議

軟件端口是應用層的各種協議進程與運輸實體件鍵興層間交互的一種地址

計算機中的端口分類

計算機中的端口一般分為兩種

一種是服務端使用的端口

服務端的端口也分為兩小類，一類叫做系統端口或特權端口：0~1023

應用程序 ? ? ? ? http ? https ? ftp ? ?tftp ? smtp ? pop3 ? imap ? telnet ? ssh

系統端口號 ? ? 80 ? ? ?443 ? ? 21 ? ? 69 ? ? ?25 ? ? ? ?110 ? ? 143 ? ? 23 ? ? ? ?22

另一類叫做用戶端口或者注冊端口 1024-49151 ? （使用這一類型端口需要注冊）

另一大類型為動態端口，49152~65535，在客戶端運行時才會動態選擇，也叫短暫端口號

TCP和UDP的區別：

1，tcp面向連接，udp非面向連接。—tcp提供面向連接的服務，在進行報文交互傳輸前需進行3次握手的連接建立，在數據交互完成時需要進行4次揮手的斷開連接。udp在傳輸udp用戶數據報的時候不需要提前建立連接，采用直接發送的方式。

2，tcp為可靠的交互，udp為不可靠的交互。–tcp提供重傳和按序號傳送的以及流量控制的功能，udp只是進最大的努力交付。

3，tcp拆分傳輸，udp整個傳輸。–tcp是面向字節流的，它把數據看作一連串無結構的字節流，它會對數據進行分拆包裝，udp對應用層交付下來的報文不拆分也不組合，直接發送。一次發送一個報文。

4.通信方式不同 –tcp支持一對一的交流方式，udp支持一對一，一對多，多對多，多對一的交流方式。

5，tcp有發送窗口等待的機制，可以實現流量控制，而udp沒有發送窗口的機制，它不能進行擁塞控制和流量控制。

6.檢驗方式不一樣，udp計算檢驗是把首部和數據部分一起檢驗，tcp只是檢驗IP數據報的首部

UDP的報文首部：

首部由8個字節四個部分組成，每個部分由2個字節

1，源端口：在需要交互方回復的時候選用，不需要回復使用0

2.目的端口：在終點交付報文的時候必須使用。

3，長度：udp用戶數據報的長度，最小為8

4，檢驗和：檢測udp數據報在傳輸中是否有錯誤，有錯就將其丟棄。（在計算檢驗和時，要在udp用戶數據報之前添加12個字節的偽首部，偽首部即不下傳遞也不向上遞交，作用僅為計算檢驗和）

TCP首部

1：源端口和目的端口：各占兩個字節。

2.序號：占4個字節，也叫報文段序號，TCP傳輸的每一個字節都按順序編號。序號指的是本報文段發送的數據 的第一個字節的序號

3.確認號：占4個字節，表示期望收到對方下一個報文段的第一個數據字節的序號（確認序號減去序號等于本段傳輸的報文長度，確認號表示在這個序號的前一個數據之前的信息全部正常接收）

4，數據偏移：占4個字節，指出TCP報文段的數據起始處距離tcp報文段的起始有多遠。

5，保留位：占6個字節 （一般不使用）

6，緊急指針位（URG）當urg=0時，表示緊急指針無效 ?當urg=1時表示緊急指針有效，告訴系統這個報文段中有緊急數據，應當盡快傳輸。緊急數據插入本報文數據的最前面，緊急指針指出晉級數據的末尾在報文段中的位置。

7，確認ack，當ack=1，確認號字段才有效。當ack=0時確認號無效。tcp規定在建立連接之后所傳輸的報文段都必須把ack設置為1

8.推送psh，在接收方tcp收到psh=1的報文段，就盡快交付給接收應用進程而不是在得到緩沖區都填滿之后在向上交付

9，復位rst，當rst=1，標明tcp有嚴重的錯誤，必須釋放連接，重新建立傳輸連接。rst=1還可以用來拒絕一個非法的報文段或者拒絕打開一個連接

10，同步syn，當syn=1，ack=0，標明這是個連接請求報文段，對方如果同意建立連接，在響應報文段中syn=1,ack=1.

11.終止fin，釋放一個連接，fin=1,表示報文段的發送方的數據已經發送完成，請求釋放連接。

12.窗口：占2個字節，存放的是數據是字節為單位的窗口值告訴對方，本報文段首部中的確認號算起，接收方目前允許對方發送的數據量。這是讓發送方設置發送窗口的依據

13.檢驗和，占2個字節

TCP的可靠原理

1，停止等待協議

發送方發送之后等待接收方的確認報文，在繼續發送，如果出現發送丟失或者確認報文丟失，超時計時器到期，進行超時重傳。如果編號不對，也會進行重傳的活動。

（使用確認和重傳機制，可以在不可靠的傳輸網絡上進行可靠傳輸）

2,連續arp協議：

使用了滑動窗口的機制。

累積確認的方式，對按序到達的一個分組發送確認，如果分組的數據段丟失只會確認前接收的

3.流量控制：發送方不要太快，讓接受方來得及接收。（利用滑動窗口機制實現對發制）

接收方額主機進行了三次流量控制，而且ACK=1時確認字段才有意義

TCP擁塞控制

1,基本概念

擁塞：即在某段時間，若對網絡中某一資源的需求超過了該資源所能提供的可承受能力，網絡就會變壞

擁塞控制：防止過多的數據注入到網絡中，這樣可以使網絡中的路由器或鏈路不至于過載。要實現擁塞控制都有一個前提：網絡能夠承受現有的網絡負荷。擁塞控制是一個全局性的過程。涉及到所有的主機，路由器，以及與降低網絡傳輸信能有關的所有因素。

流量控制：指點對點通信量的控制，是端到端正的問題。流量控制所要做的就是抑制發送端發送屬的速率。使接收端來得及接收。

擁塞控制代價：需要獲得網絡內部流量的分布的信息。在實現擁塞控制之前。還需要在結點之間交換信息和各種命令，以便選擇控制的策略和實施控制。這樣就產生了額外的開銷。擁塞控制還需要將一些資源分配給各個用戶單獨使用，使得網絡資源不能更好的實現共享。

2，擁塞控制的辦法

慢啟動（slow start) ? ? ? ?擁塞避免（congestion avoidance ) ? ?快速重傳（fast retransmit) ? ? ?快速恢復（fast recovery)

慢啟動和擁塞避免

1.發送方維持一個擁塞窗口cwnd的狀態變量。擁塞窗口的大小取決于網絡的擁塞程度，并且動態地在變化。

2.發送方控制擁塞窗口的原則是：只要網絡沒有出現擁塞，擁塞窗口就再增大一些，以便把更多的分組發送出去。但只要網絡出現擁塞，擁塞窗口就減少一些，以減少注入到網絡中的分組數。

3.慢啟動算法：當主機開始發送數據時，如果立即把大量數據字節注入到網絡，那么就有可能引起網絡擁塞，因為現在并不清楚網絡的負荷情況。因此，較好的辦法是先探測下，即由小到大逐漸增大發送窗口，也就說，由小到大逐漸增大擁塞窗口數值。通常在剛剛開始發送報文段時，先把擁塞窗口cwnd設置為一個最大報文段MSS的數值。而在每收到一個對新的報文段的確認后，把擁塞窗口增加至多一個MSS的數值。用這樣的方法逐步增大發送方的擁塞窗口cwnd，可以使分組注入到網絡的速率更加合理。

擁塞避免算法：讓擁塞窗口cwnd緩慢地增大，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口cwnd按線性規律緩慢增長，比慢開始算法的擁塞窗口增長速率緩慢得多。
無論慢啟動開始階段還是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有收到確認），就要把慢啟動門限ssthresh設置為出現擁塞時的發送方窗口值的一半（但不能小于2）。然后把擁塞窗口cwnd重新設置為1，執行慢啟動算法。這樣做的目的就是要迅速減少主機發送到網絡中的分組數，使得發生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。

快速重傳和快速恢復

如果發送方設置了超時計時器時限已到但還沒有收到確認，那么很可能是網絡出現了擁塞，致使報文段在網絡中的某處被丟棄。這時，TCP馬上把擁塞窗口cwnd減少到1，并執行慢啟動算法，同時把慢啟動門限值ssthresh減半。這是不使用快速重傳的情況。

快速重傳算法首先要求接收方每收到一個失序的報文段后就立即發出重復確認（為的是使發送方及早知道有報文段沒有達到對方）而不要等到自己發送數據時才進行捎帶確認。

TCP協議的三次握手

1.由客戶端發起tcp請求，SYN=1，seq=x，從而從CLOSED狀態轉變成SYNSEND狀態，準備接受服務器的響應；

2.服務器收到SYN=1的包后回應一個SYN=1，ACK=1的包表示確認，其中seq=y，確認號為x+1表示收到第一次客戶端的x包，服務器的狀態從LISTEN轉換成SYNRCVD，準備接受客戶端的下一個確認包；

3.

客戶端收到服務器的響應，從而回復一個ACK=1確認包，seq=x+1表示發送自己的下一個包，ack=y+1表示收到了服務器的y包；

客戶端發出確認包后從SYNSEND狀態切換到ESTABLISHED（已連接狀態）；服務器收到ESTABLISHED（已連接狀態），接下來就可以愉快的通信了。

TCP協議的四次揮手

1，A主機發起FIN=1表示斷開請求包，seq=u自己的數據包序號，發出FIN包后立即從ESTABLISHED狀態轉換為FIN-WAIT-1狀態，等待服務器的確認；

2，B主機收到FIN=1的包后，回應一條ACK=1的包，表示自己已經收到客戶段的分手請求，從而轉換為CLOSE-WAIT狀態；客戶端收到ACK=1的包后從FIN-WAIT-1狀態轉換為FIN-WAIT-2狀態，繼續等待服務器的同意請求；

3.B主機器繼續發出FIN=1，ACK=1表示服務器同意分手，從而由CLOSE-WAIT狀態切換到LAST-ACK狀態，等待客戶端的最后一次確認請求；

4.A主機收到FIN=1的包后再次發出一個最后的ACK=1確認包，從而轉換成TIME-WAIT狀態，等待2個MSL（一個包從客戶端到服務器的時間為一個MSL時間）時間，確保服務器最后的包全部接受后轉換成CLOSED狀態；服務器收到最后的ACK=1包后也轉換為CLOSED狀態。