計算機網路 TCP與UDP

tcp/ip中有兩個具有代表性的傳輸層協議，它們分別是tcp與udp。

tcp提供可靠地通訊傳輸。

udp則常被用於讓廣播和細節控制交給應用的通訊傳輸。

tcp/ip的眾多應用協議大多以客戶端/服務端形式執行。

客戶端是請求的發起端。

服務端是表示提供服務的意思。服務端的程式必須提前啟動，準備接收客戶端的請求。

這些服務端程式在unix系統當中叫做守護程序。

tcp是面向連線的，可靠地流協議。

流就是指不間斷的資料結構。

當程式採用tcp傳送訊息時，雖然可以保證傳送順序，但還是猶如沒有任何間隔的資料流傳送給接收端。

tcp為提供可靠性傳輸，實行「順序控制」或「重發控制」機制。此外還具備「流控制（流量控制）」、「擁塞控制」、提高網路利用率等眾多功能。

udp是不具有可靠性的資料報協議。

在udp的情況下，雖然可以確保傳送訊息的大小，卻不能保證訊息一定會到達。

應用有時會根據自己的需要進行重發處理。

tcp和udp的區分

tcp用於在傳輸層有必要實現可靠傳輸的情況。

udp主要用於那些對高速傳輸和實時性有較高要求的通訊或廣播通訊。

rip、dhcp等基於廣播的協議也要依賴udp。

埠號埠號用來識別同一臺計算機中進行通訊的不同應用程式，因此，它被稱為程式位址。

tcp/ip或udp/ip通訊中，採用5個資訊來識別乙個通訊。

它們是源ip位址、目標ip位址、協議號、源埠號、目標埠號。

埠號如何確定

1、標準既定的埠號（靜態方法）

http、telnet、ftp等廣泛使用的應用協議中所使用的埠號就是固定的。這些埠號被稱為知名埠號。

2、時序分配法（動態方法)

動態分配的埠號取值範圍在49152~65535之間。

udp的特點及其目的

udp是user datagram protocol的縮寫。

udp是不提供複雜的控制機制，利用ip提供面向無連線的通訊服務。

即使在網路擁堵的情況下，udp也無法進行流量控制等避免網路擁塞的行為，此外，傳輸途中即使出現丟包，udp也不負責重發。甚至當出現包的到達順序亂掉時，也沒有糾正的功能。如果需要這些細節控制，那麼不得不交由udp的應用程式去處理。

tcp與udp的區別相當大。它充分的實現了資料傳輸時各種控制功能。可以進行丟包時的重發控制，還可以對次序亂掉的分包進行順序控制。

tcp作為一種面向有連線的協議，只有在確認通訊對端存在時才會傳送資料，從而可以控制通訊流量的浪費。

tcp通過檢驗和、序列號、確認應答、重發控制、連線管理以及視窗控制等機制實現可靠性傳輸。

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

在tcp中，當傳送端的資料到達接收主機時，接收端主機會返回乙個已收到訊息的通知。這個訊息叫做確認應答（ack）。

tcp通過肯定的確認應答實現可靠性的資料傳輸。當傳送端將資料發出之後會等待對端的確認應答。如果有確認應答，說明資料已經成功到達對端。反之，則資料丟失的可能性大。

如果產生了丟包，進行重發。

上述的確認應答處理、重發控制以及重複控制等功能都可以通過序列號實現。

通過序列號和確認應答號，tcp可以實現可靠傳輸。

重發超時如何確定

重發超時是指在重發資料之前，等待確認應答到來的那個特定時間間隔。如果超過了這個時間間隔，傳送端將進行資料重發。

每次發包時都會計算往返時間及其偏差。將這個往返時間和偏差相加，重發超時的時間就是比這個總和要大一點的值。

在bsd的unix以及windows系統中，超時都以0.5秒為單位進行控制，因此重發超時都是0.5秒的整數倍。最初的資料報不知道往返時間，一般設定為6秒左右。

資料重發之後如果還是收不到確認應答，則進行再次傳送，等待確認應答的時間將會以2倍，4倍的指數函式延長。

此外，資料也不會被無限、反覆地重發。達到一定重發次數之後，如果仍沒有任何確認應答返回，就會判斷為網路或對端主機發生了異常，強制關閉連線，並通知應用通訊異常強制終止。

連線管理

tcp會在通訊之前，通過tcp首部傳送乙個syn包作為建立連線的請求等待確認應答。如果對端發來確認應答，則認為可以進行資料通訊。如果對端的確認應答未能到達，就不會進行資料通訊。

此外在通訊結束時，會進行斷開連線的處理（fin包）。

可以使用tcp首部用於控制的字段來管理tcp連線。乙個連線的建立與斷開，正常過程至少需要來回傳送7個包才能完成。（四次握手，三次揮手）

tcp以段為單位傳送資料

在建立tcp連線的同時，也可以確定傳送資料報的單位，我們稱之為「最大訊息長度」（mss:maximum segment size）。最理想的情況是，最大訊息長度正好是ip中不會被分片處理的最大資料長度。

mss是在三次握手時候，在兩端的主機之間被計算得出。

利用視窗控制提高速度

tcp以1個段為單位，每發乙個段進行一次確認應答，這樣的傳輸方式有乙個缺點。那就是，包的往返時間越長通訊效能就越低。

引入視窗的概念，傳送端主機，在傳送了乙個段以後不必要一直等待確認應答，而是繼續傳送。

視窗的大小就是無需等待確認應答而可以繼續傳送資料的最大值。

在整個視窗的確認應答沒有到達之前，如果其中一部分出現丟包，那麼傳送端仍然要負責重傳，為此傳送端主機得設定快取保留這些待被重傳的資料，直到收到它們的確認應答。

當資料發出後，如期收到確認應答，就可以不用再進行重發，此時資料就可以從快取區清除。

收到確認應答後，視窗滑動到確認應答中的序列號的位置。這樣可以順序的將多個段同時傳送提高通訊效能。這種機制也被稱為滑動視窗控制。

視窗控制與重發控制

首先，我們考慮確認應答未能返回的情況，在這種情況下，資料已到對端，是不需要重發的。

使用了視窗控制，某些確認應答即使丟失也無需重發。

當某一報文段丟失後，傳送端會一直收到1001的確認應答，同乙個序號的確認應答將會被重複不斷的返回。傳送端主機如果連續3次收到同乙個確認應答，就會將其所對應的資料進行重發。

這種機制比之前提到的超時管理更加高效，因此也被稱為高速重發控制。

流控制傳送端主機會根據接收端主機的提示，對傳送資料的量進行控制。形成了乙個完整的tcp流控制。

視窗探測的資料段。

擁塞控制

在通訊的一開始會通過乙個叫做慢啟動的演算法得出的數值，對傳送資料量進行控制。

慢啟動的時候，將擁塞視窗的大小設定為1個資料段（1mss）傳送資料，之後每次收到一次應答（ack），擁塞視窗的值就加1。傳送資料時，將擁塞視窗與接收端通知的視窗大小做比較，取小的那乙個。

提高網路利用率的規範

nagle演算法

延遲確認應答

捎帶應答

如果需要應用自己處理一些更為細節上的控制，使用udp協議是不錯的選擇。

如果**數量較多、對可靠性的要求比較高時，可以選擇使用tcp。

其他傳輸層協議

udp-lite

sctp

dccp

計算機網路 TCP與UDP

計算機網路 TCP與UDP

計算機網路 TCP與UDP

計算機網路 TCP與UDP（一）

相關推薦