深入淺出講解TCP/UDP協議

來源:互聯網
上載者:User
圖1就是瑞星個人版防火牆軟體佈建規則的介面。細心的讀者會發現,圖1中的“協議”欄中有“TCP”、“UDP”等名詞,它們是什麼意思呢?現在我們就來講講什麼是TCP和UDP 我們學習過什麼是“資料包”。理解資料包,對於網路管理的網路安全具有至關重要的意義。比如,防火牆的作用本質就是檢測網路中的資料包,判斷其是否違反了預先設定的規則,如果違反就加以阻止。圖1就是瑞星個人版防火牆軟體佈建規則的介面。細心的讀者會發現,圖1中的“協議”欄中有“TCP”、“UDP”等名詞,它們是什麼意思呢?現在我們就來講講什麼是TCP和UDP。

 連線導向的TCP

 “連線導向”就是在正式通訊前必須要與對方建立起串連。比如你給別人打電話,必須等線路接通了、對方拿起話筒才能相互連話.

圖片附件: [1] 1.jpg (2006-6-30 14:46, 15.27 K)

TCP(Transmission Control Protocol,傳輸控制通訊協定)是基於串連的協議,也就是說,在正式收發資料前,必須和對方建立可靠的串連。一個TCP串連必須要經過三次“對話”才能建立起來,其中的過程非常複雜,我們這裡只做簡單、形象的介紹,你只要做到能夠理解這個過程即可。我們來看看這三次對話的簡單過程:主機A向主機B發出串連請求資料包:“我想給你發資料,可以嗎?”,這是第一次對話;主機B向主機A發送同意串連和要求同步(同步就是兩台主機一個在發送,一個在接收,協調工作)的資料包:“可以,你什麼時候發?”,這是第二次對話;主機A再發出一個資料包確認主機B的要求同步:“我現在就發,你接著吧!”,這是第三次對話。三次“對話”的目的是使資料包的發送和接收同步,經過三次“對話”之後,主機A才向主機B正式發送資料。

 TCP協議能為應用程式提供可靠的通訊串連,使一台電腦發出的位元組流無差錯地發往網路上的其他電腦,對可靠性要求高的資料通訊系統往往使用TCP協議傳輸資料。

圖片附件: 2.jpg (2006-6-30 14:49, 5.41 K)

我們來做一個實驗,用電腦A(安裝Windows 2000 Server作業系統)從“網路位置”上的一台電腦B拷貝大小為8,644,608位元組的檔案,通過狀態列右下角網卡的發送和接收指標就會發現:雖然是資料流是由電腦B流向電腦A,但是電腦A仍發送了3,456個資料包,2所示。這些資料包是怎樣產生的呢?因為檔案傳輸時使用了TCP/IP協議,更確切地說是使用了連線導向的TCP協議,電腦A接收資料包的時候,要向電腦B回傳資料包,所以也產生了一些通訊量。

圖片附件: 3.jpg (2006-6-30 14:49, 4.33 K)

如果事先用網路監視器監視網路流量,就會發現由此產生的資料流量是9,478,819位元組,比檔案大小多出10.96%(3所示),原因不僅在於資料包和幀本身佔用了一些空間,而且也在於TCP協議連線導向的特性導致了一些額外的通訊量的產生。

 面向非串連的UDP協議

 “面向非串連”就是在正式通訊前不必與對方先建立串連,不管對方狀態就直接發送。這與現在風行的手機簡訊非常相似:你在發簡訊的時候,只需要輸入對方手機號就OK了。
 
 UDP(User Data Protocol,使用者資料包通訊協定)是與TCP相對應的協議。它是面向非串連的協議,它不與對方建立串連,而是直接就把資料包發送過去。

圖片附件: 4.jpg (2006-6-30 14:49, 4.7 K)

UDP適用於一次只傳送少量資料、對可靠性要求不高的應用環境。比如,我們經常使用“ping”命令來測試兩台主機之間TCP/IP通訊是否正常,其實“ping”命令的原理就是向對方主機發送UDP資料包,然後對方主機確認收到資料包,如果資料包是否到達的訊息及時反饋回來,那麼網路就是通的。例如,在預設狀態下,一次“ping”操作發送4個資料包(2所示)。大家可以看到,發送的資料包數量是4包,收到的也是4包(因為對方主機收到後會發回一個確認收到的資料包)。這充分說明了UDP協議是面向非串連的協議,沒有建立串連的過程。正因為UDP協議沒有串連的過程,所以它的通訊效果高;但也正因為如此,它的可靠性不如TCP協議高。QQ就使用UDP發訊息,因此有時會出現收不到訊息的情況。

 附表:tcp協議和udp協議的差別

圖片附件: 5.jpg (2006-6-30 14:49, 5.37 K)

TCP協議和UDP協議各有所長、各有所短,適用於不同要求的通訊環境。TCP協議和UDP協議之間的差別如附表所示。1、UDP簡要介紹
UDP是傳輸層協議,和TCP協議處於一個分層中,但是與TCP協議不同,UDP協議並不提供逾時重傳,出錯重傳等功能,也就是說其是不可靠的協議。

2.UDP協議頭
2.1.UDP連接埠號碼
由於很多軟體需要用到UDP協議,所以UDP協議必須通過某個標誌用以區分不同的程式所需要的資料包。連接埠號碼的功能就在於此,例如某一個UDP程式A在系統中註冊了3000連接埠,那麼,以後從外面傳進來的目的連接埠號碼為3000的UDP包都會交給該程式。連接埠號碼理論上可以有2^16這麼多。因為它的長度是16個bit

2.2.UDP檢驗和
這是一個可選的選項,並不是所有的系統都對UDP資料包加以檢驗和資料(相對TCP協議的必須來說),但是RFC中標準要求,發送端應該計算檢驗和。

UDP檢驗和覆蓋UDP協議頭和資料,這和IP的檢驗和是不同的,IP協議的檢驗和只是覆蓋IP資料頭,並不覆蓋所有的資料。UDP和TCP都包含一個偽首部,這是為了計算檢驗和而攝製的。偽首部甚至還包含IP地址這樣的IP協議裡面都有的資訊,目的是讓UDP兩次檢查資料是否已經正確到達目的地。如果發送端沒有開啟檢驗和選項,而接收端計算檢驗和有差錯,那麼UDP資料將會被悄悄的丟掉(不保證送達),而不產生任何差錯報文。

2.3.UDP長度
UDP可以很長很長,可以有65535位元組那麼長。但是一般網路在傳送的時候,一次一般傳送不了那麼長的協議(涉及到MTU的問題),就只好對資料分區,當然,這些是對UDP等上級協議透明的,UDP不需要關心IP協議層對資料如何分區,下一個章節將會稍微討論一些分區的策略。

3.IP分區
IP在從上層接到資料以後,要根據IP地址來判斷從那個介面發送資料(通過選路),並進行MTU的查詢,如果資料大小超過MTU就進行資料分區。資料的分區是對上層和下層透明,而資料也只是到達目的地還會被重新組裝,不過不用擔心,IP層提供了足夠的資訊進行資料的再組裝。

在IP頭裡面,16bit識別號唯一記錄了一個IP包的ID,具有同一個ID的IP片將會被重新組裝;而13位片位移則記錄了某IP片相對整個包的位置;而這兩個表示中間的3bit標誌則標示著該分區後面是否還有新的分區。這三個標示就組成了IP分區的所有資訊,接受方就可以利用這些資訊對IP資料進行重新組織(就算是後面的分區比前面的分區先到,這些資訊也是足夠了)。

因為分區技術在網路上被經常的使用,所以偽造IP分區包進行流氓攻擊的軟體和人也就層出不窮。

可以用Trancdroute程式來進行簡單的MTU偵測。請參看教材。

3.UDP和ARP之間的互動式用
這是不常被人注意到的一個細節,這是針對一些系統地實現來說的。當ARP緩衝還是空的時候。UDP在被發送之前一定要發送一個ARP請求來獲得目的主機的MAC地址,如果這個UDP的資料包足夠大,大到IP層一定要對其進行分區的時候,想象中,該UDP資料包的第一個分區會發出一個ARP查詢請求,所有的分區都輝等到這個查詢完成以後再發送。事實上是這樣嗎?

結果是,某些系統會讓每一個分區都發送一個ARP查詢,所有的分區都在等待,但是接受到第一個回應的時候,主機卻只發送了最後一個資料片而拋棄了其他,這實在是讓人匪夷所思。這樣,因為分區的資料不能被及時組裝,接受主機將會在一段時間內將永遠無法組裝的IP資料包拋棄,並且發送組裝逾時的ICMP報文(其實很多系統不產生這個差錯),以保證接受主機自己的接收端緩衝不被那些永遠得不到組裝的分區充滿。

4.ICMP來源站點抑制差錯
當目標主機的處理速度趕不上資料接收的速度,因為接受主機的IP層緩衝會被佔滿,所以主機就會發出一個“我受不了”的一個ICMP報文。

5.UDP伺服器設計
UDP協議的某些特性將會影響我們的伺服器程式設計,大致總結如下:

關於客戶IP和地址:伺服器必須有根據客戶IP地址和連接埠號碼判斷資料包是否合法的能力(這似乎要求每一個伺服器都要具備)
關於目的地址:伺服器必須要有過濾廣播位址的能力。
關於資料輸入:通常伺服器系統的每一個連接埠號碼都會和一塊輸入緩衝區對應,進來的輸入根據先來後到的原則等待伺服器的處理,所以難免會出現緩衝區溢位的問題,這種情況下,UDP資料包可能會被丟棄,而應用伺服器程式本身並不知道這個問題。
伺服器應該限制本地IP地址,就是說它應該可以把自己綁定到某一個網路介面的某一個連接埠上。 TCP和UDP處在同一層---運輸層,但是TCP和UDP最不同的地方是,TCP提供了一種可靠的Data Transmission Service,TCP是連線導向的,也就是說,利用TCP通訊的兩台主機首先要經曆一個“撥打到電話”的過程,等到通訊準備結束才開始傳輸資料,最後結束通話。所以TCP要比UDP可靠的多,UDP是把資料直接發出去,而不管對方是不是在收信,就算是UDP無法傳遞的,也不會產生ICMP差錯報文,這一經時重申了很多遍了。

TCP的首部和UDP首部一樣,都有傳送埠號和接收埠號。但是顯然,TCP的首部資訊要比UDP的多,可以看到,TCP協議提供了發送和確認所需要的所有必要的資訊。

雙方建立串連
發送方給接受方TCP資料報,然後等待對方的確認TCP資料報,如果沒有,就重新發,如果有,就發送下一個資料報。
接受方等待發送方的資料報,如果得到資料報並檢驗無誤,就發送ACK(確認)資料報,並等待下一個TCP資料報的到來。直到接收到FIN(發送完成資料報)
中止串連
可以想見,為了建立一個TCP串連,系統可能會建立一個新的進程(最差也是一個線程),來進行資料的傳送

 

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.