tcp協(xié)議與 udp協(xié)議的區(qū)別--精選文檔

1、TCP 與UDP的區(qū)別很多文章都說TCP協(xié)議可靠，UDP協(xié)議不可靠！為什么前者可靠，后者不可靠呢？既然UDP協(xié)議不可靠，為什么還要使用它呢？所謂的TCP協(xié)議是面向連接的協(xié)議，面向連接是什么呢？ TCP和UDP都是傳輸層的協(xié)議！從編程的角度看，就是兩個(gè)模塊（模塊就是代碼的集合，一系列代碼的組合提供相應(yīng)的功能！模塊化最終目的就是：分工協(xié)作！模塊化好處：便于擴(kuò)展開發(fā)以及維護(hù)?。?先說TCP協(xié)議： 這個(gè)協(xié)議，是面向的連接！面向連接這個(gè)概念，我們要從物理層看起。大家都知道，因?yàn)椤靶诺缽?fù)用技術(shù)”的迅猛發(fā)展，才促使了計(jì)算機(jī)網(wǎng)絡(luò)的發(fā)展！如果沒有“信道復(fù)用技術(shù)”，那么單條線路上（這里的線路指物理傳輸介質(zhì)，例如

2、：雙絞線、光纖、電話線）單位時(shí)間內(nèi)只能供一臺(tái)計(jì)算機(jī)使用！還是舉例說明：就拿你自己的計(jì)算機(jī)來說，你跟同學(xué)“小明”聊天的時(shí)候，就不能跟另外一位同學(xué)“小強(qiáng)”聊天，如果你想同時(shí)跟兩位同學(xué)聊天，那么你就得裝兩條線路！那么同時(shí)與第三位、第四位同學(xué)。第N位同學(xué)聊天的時(shí)候，你需要裝幾根線路？全世界人民聊天的時(shí)候，又需要裝幾根線路？ “信道復(fù)用技術(shù)”實(shí)現(xiàn)了，在同一條線路上，單位時(shí)間內(nèi)可供X臺(tái)計(jì)算機(jī)同時(shí)通信！Toad知道以下幾種復(fù)用技術(shù)： 1、頻分復(fù)用 2、時(shí)分復(fù)用 3、波分復(fù)用 4、碼分復(fù)用 5、空分復(fù)用 6、統(tǒng)計(jì)復(fù)用 7、極化波復(fù)用 關(guān)于“信道復(fù)用技術(shù)”更深層次的問題，需要你自己去研究！ 上面我們提到了“信道

3、復(fù)用技術(shù)”！知道了這一點(diǎn)，我們就很容易明白“物理信道”上的“虛擬信道”概念了！不同的信道復(fù)用技術(shù)，使用不同的復(fù)用技術(shù)，目的就是創(chuàng)建“虛擬信道”。 一個(gè)TCP協(xié)議連接其實(shí)就是在物理線路上創(chuàng)建的一條“虛擬信道”。這條“虛擬信道”建立后，在TCP協(xié)議發(fā)出FIN包之前（兩個(gè)終端都會(huì)向?qū)Ψ桨l(fā)送一個(gè)FIN包），是不會(huì)釋放的。正因?yàn)檫@一點(diǎn)，TCP協(xié)議被稱為面向連接的協(xié)議！ UDP協(xié)議，一樣會(huì)在物理線路上創(chuàng)建一條“虛擬信道”，否則UDP協(xié)議無法傳輸數(shù)據(jù)！但是，當(dāng)UDP協(xié)議傳完數(shù)據(jù)后，這條“虛擬信道”就被立即注銷了！因此，稱UDP是不面向連接的協(xié)議！ 大家要知道，一種物理線路，單位時(shí)間內(nèi)，能夠創(chuàng)建的“虛擬信道”

4、是有限的！從這個(gè)問題，大家應(yīng)該明白了TCP協(xié)議和UDP協(xié)議為什么會(huì)共存了吧，然而，這只是其中一個(gè)原因而已！ 那為什么又說TCP協(xié)議可靠，UDP協(xié)議不可靠呢？以上說的是一個(gè)原因，還有一個(gè)原因是：使用TCP協(xié)議傳輸數(shù)據(jù)，當(dāng)數(shù)據(jù)從A端傳到B端后，B端會(huì)發(fā)送一個(gè)確認(rèn)包（ACK包）給A端，告知A端數(shù)據(jù)我已收到！UDP協(xié)議就沒有這種確認(rèn)機(jī)制！這一點(diǎn)，在做TCP協(xié)議首部分析時(shí)，會(huì)詳加解釋！ QQ普通會(huì)員就是使用的UDP協(xié)議進(jìn)行傳輸數(shù)據(jù)！既然UDP協(xié)議自身沒有確認(rèn)機(jī)制，這個(gè)工作可以交給應(yīng)用層的進(jìn)程來完成（QQ）！大家使用QQ的時(shí)候，感覺出錯(cuò)的幾率還是非常小吧！當(dāng)然，把這個(gè)確認(rèn)工作完全交給QQ自身來做，就直接導(dǎo)

5、致了，QQ軟件體積增大！ 有些應(yīng)用，對(duì)數(shù)據(jù)傳輸可靠性要求非常高，例如大家瀏覽網(wǎng)頁，通過網(wǎng)頁注冊(cè)帳號(hào)、轉(zhuǎn)帳等服務(wù)，這是不容許出錯(cuò)的，使用TCP協(xié)議能把出錯(cuò)的可能性降到最低（當(dāng)然，網(wǎng)絡(luò)自身很糟糕，TCP協(xié)議也沒辦法）。但是，提供這種可靠服務(wù)，會(huì)加大網(wǎng)絡(luò)帶寬的開銷，因?yàn)椤疤摂M信道”是持續(xù)存在的，同時(shí)網(wǎng)絡(luò)中還會(huì)出現(xiàn)大量的ACK和FIN包！ 因此，魚和熊掌不可兼得，需根據(jù)實(shí)際情況選擇傳輸協(xié)議 TCP協(xié)議提供了可靠的數(shù)據(jù)傳輸,但是其擁塞控制、數(shù)據(jù)校驗(yàn)、重傳機(jī)制的網(wǎng)絡(luò)開銷很大,不適合實(shí)時(shí)通信,所以選擇開銷很小的UDP協(xié)議來傳輸數(shù)據(jù)。 UDP 協(xié)議是無連接的數(shù)據(jù)傳輸協(xié)議并且無重傳機(jī)制,會(huì)發(fā)生丟包、收到重復(fù)包、

6、亂序等情況。而對(duì)于數(shù)據(jù)精確性要求不高的狀態(tài)數(shù)據(jù)以及視頻數(shù)據(jù),丟包的影響不大。因?yàn)闀?huì)不斷收到新的包,丟失的個(gè)別包會(huì)有新的包來覆蓋,所以只需在遠(yuǎn)程控制系統(tǒng)的通信部分自行處理亂序及重復(fù)包的問題,而對(duì)于丟包的問題一般不作處理。 但對(duì)于命令包這種需要精確收發(fā)的數(shù)據(jù), 可在程序的開發(fā)中加入丟包重發(fā)和超時(shí)丟棄的處理。 當(dāng)然,如果開發(fā)的是對(duì)于實(shí)時(shí)性要求不高的事件型控制命令的傳輸,不希望發(fā)生指令的丟失也可以直接采用TCP協(xié)議。TCP的重傳機(jī)制正好適合這種情況。 非面向連接的傳輸協(xié)議在數(shù)據(jù)傳輸之前不建立連接，而是在每個(gè)中間節(jié)點(diǎn)對(duì)非面向連接的包和數(shù)據(jù)包進(jìn)行路由。沒有點(diǎn)到點(diǎn)的連接，非面向連接的協(xié)議，如UDP，是不可靠

7、的連接。當(dāng)一個(gè)UDP數(shù)據(jù)包在網(wǎng)絡(luò)中移動(dòng)時(shí)，發(fā)送過程并不知道它是否到達(dá)了目的地，除非應(yīng)用層已經(jīng)確認(rèn)了它已到達(dá)的事實(shí)。非面向連接的協(xié)議也不能探測(cè)重復(fù)的和亂序的包。標(biāo)準(zhǔn)的專業(yè)術(shù)語用“不可靠”來描述UDP。在現(xiàn)代網(wǎng)絡(luò)中，UDP并不易于導(dǎo)致傳輸失敗，但是你也不能肯定地說它是可靠的。UDPUser Datagram Protocol用戶數(shù)據(jù)報(bào)協(xié)議UDP是ISO參考模型中一種無連接的傳輸層協(xié)議，提供面向事務(wù)的簡單不可靠信息傳送服務(wù)。 UDP 協(xié)議基本上是IP協(xié)議與上層協(xié)議的接口。UDP協(xié)議適用端口分辨運(yùn)行在同一臺(tái)設(shè)備上的多個(gè)應(yīng)用程序。目錄 1 簡介 2 為什么要使用UDP？ 3 UDP報(bào)頭 4 UDP協(xié)議的

8、幾個(gè)特性 5 UDP vs TCP 6 UDP協(xié)議的應(yīng)用 7 UDP 程序設(shè)計(jì) UDP-簡介UDP協(xié)議的全稱是用戶數(shù)據(jù)報(bào)協(xié)議，在網(wǎng)絡(luò)中它與TCP協(xié)議一樣用于處理數(shù)據(jù)包。在OSI模型中，在第四層傳輸層，處于IP協(xié)議的上一層。UDP有不提供數(shù)據(jù)報(bào)分組、組裝和不能對(duì)數(shù)據(jù)包的排序的缺點(diǎn)，也就是說，當(dāng)報(bào)文發(fā)送之后，是無法得知其是否安全完整到達(dá)的。UDP用來支持那些需要在計(jì)算機(jī)之間傳輸數(shù)據(jù)的網(wǎng)絡(luò)應(yīng)用。包括網(wǎng)絡(luò)視頻會(huì)議系統(tǒng)在內(nèi)的眾多的客戶/服務(wù)器模式的網(wǎng)絡(luò)應(yīng)用都需要使用UDP協(xié)議。UDP協(xié)議從問世至今已經(jīng)被使用了很多年，雖然其最初的光彩已經(jīng)被一些類似協(xié)議所掩蓋，但是即使是在今天，UDP仍然不失為一項(xiàng)非常實(shí)用

9、和可行的網(wǎng)絡(luò)傳輸層協(xié)議。與所熟知的TCP（傳輸控制協(xié)議）協(xié)議一樣，UDP協(xié)議直接位于IP（網(wǎng)際協(xié)議）協(xié)議的頂層。根據(jù)OSI（開放系統(tǒng)互連）參考模型，UDP和TCP都屬于傳輸層協(xié)議。UDP協(xié)議的主要作用是將網(wǎng)絡(luò)數(shù)據(jù)流量壓縮成數(shù)據(jù)報(bào)的形式。一個(gè)典型的數(shù)據(jù)報(bào)就是一個(gè)二進(jìn)制數(shù)據(jù)的傳輸單位。每一個(gè)數(shù)據(jù)報(bào)的前8個(gè)字節(jié)用來包含報(bào)頭信息，剩余字節(jié)則用來包含具體的傳輸數(shù)據(jù)。UDP-為什么要使用UDP？ 在選擇使用協(xié)議的時(shí)候，選擇UDP必須要謹(jǐn)慎。在網(wǎng)絡(luò)質(zhì)量令人不十分滿意的環(huán)境下，UDP協(xié)議數(shù)據(jù)包丟失會(huì)比較嚴(yán)重。但是由于UDP的特性：它不屬于連接型協(xié)議，因而具有資源消耗小，處理速度快的優(yōu)點(diǎn)，所以通常音頻、視頻和普

10、通數(shù)據(jù)在傳送時(shí)使用UDP較多，因?yàn)樗鼈兗词古紶杹G失一兩個(gè)數(shù)據(jù)包，也不會(huì)對(duì)接收結(jié)果產(chǎn)生太大影響。比如我們聊天用的ICQ和OICQ就是使用的UDP協(xié)議。UDP-UDP報(bào)頭 UDPUDP報(bào)頭由4個(gè)域組成，其中每個(gè)域各占用2個(gè)字節(jié)，具體如下：UDP源端口號(hào)目標(biāo)端口號(hào)數(shù)據(jù)報(bào)長度校驗(yàn)值 UDP協(xié)議使用端口號(hào)為不同的應(yīng)用保留其各自的數(shù)據(jù)傳輸通道。UDP和TCP協(xié)議正是采用這一機(jī)制實(shí)現(xiàn)對(duì)同一時(shí)刻內(nèi)多項(xiàng)應(yīng)用同時(shí)發(fā)送和接收數(shù)據(jù)的支持。數(shù)據(jù)發(fā)送一方（可以是客戶端或服務(wù)器端）將UDP數(shù)據(jù)報(bào)通過源端口發(fā)送出去，而數(shù)據(jù)接收一方則通過目標(biāo)端口接收數(shù)據(jù)。有的網(wǎng)絡(luò)應(yīng)用只能使用預(yù)先為其預(yù)留或注冊(cè)的靜態(tài)端口；而另外一些網(wǎng)絡(luò)應(yīng)用則可

11、以使用未被注冊(cè)的動(dòng)態(tài)端口。因?yàn)閁DP報(bào)頭使用兩個(gè)字節(jié)存放端口號(hào)，所以端口號(hào)的有效范圍是從0到65535。一般來說，大于49151的端口號(hào)都代表動(dòng)態(tài)端口。數(shù)據(jù)報(bào)的長度是指包括報(bào)頭和數(shù)據(jù)部分在內(nèi)的總字節(jié)數(shù)。因?yàn)閳?bào)頭的長度是固定的，所以該域主要被用來計(jì)算可變長度的數(shù)據(jù)部分（又稱為數(shù)據(jù)負(fù)載）。數(shù)據(jù)報(bào)的最大長度根據(jù)操作環(huán)境的不同而各異。從理論上說，包含報(bào)頭在內(nèi)的數(shù)據(jù)報(bào)的最大長度為65535字節(jié)。不過，一些實(shí)際應(yīng)用往往會(huì)限制數(shù)據(jù)報(bào)的大小，有時(shí)會(huì)降低到8192字節(jié)。UDP協(xié)議使用報(bào)頭中的校驗(yàn)值來保證數(shù)據(jù)的安全。校驗(yàn)值首先在數(shù)據(jù)發(fā)送方通過特殊的算法計(jì)算得出，在傳遞到接收方之后，還需要再重新計(jì)算。如果某個(gè)數(shù)據(jù)報(bào)

12、在傳輸過程中被第三方篡改或者由于線路噪音等原因受到損壞，發(fā)送和接收方的校驗(yàn)計(jì)算值將不會(huì)相符，由此UDP協(xié)議可以檢測(cè)是否出錯(cuò)。這與TCP協(xié)議是不同的，后者要求必須具有校驗(yàn)值。檢查和的詳細(xì)計(jì)算可在RFC1071中找到，現(xiàn)舉一例說明使用檢查和檢測(cè)錯(cuò)誤的道理。例如，假設(shè)從源端A要發(fā)送下列3個(gè)16位的二進(jìn)制數(shù)：word1，word2和word3到終端B，檢查和計(jì)算如下： word10110011001100110word1 0101010101010101word1 0000111100001111sum=word1+ word2+ word31100101011001010檢查和(sum的反碼)001

13、1010100110101從發(fā)送端發(fā)出的4個(gè)(word1，2，3以及檢查和)16位二進(jìn)制數(shù)之和為1111111111111111，如果接收端收到的這4個(gè)16位二進(jìn)制數(shù)之和也是全“1”，就認(rèn)為傳輸過程中沒有出差錯(cuò)。許多鏈路層協(xié)議都提供錯(cuò)誤檢查，包括流行的以太網(wǎng)協(xié)議，也許想知道為什么UDP也要提供檢查和。其原因是鏈路層以下的協(xié)議在源端和終端之間的某些通道可能不提供錯(cuò)誤檢測(cè)。雖然UDP提供有錯(cuò)誤檢測(cè)，但檢測(cè)到錯(cuò)誤時(shí)，UDP不做錯(cuò)誤校正，只是簡單地把損壞的消息段扔掉，或者給應(yīng)用程序提供警告信息。UDP-UDP協(xié)議的幾個(gè)特性 (1) UDP是一個(gè)無連接協(xié)議，傳輸數(shù)據(jù)之前源端和終端不建立連接，當(dāng)它想傳送時(shí)

14、就簡單地去抓取來自應(yīng)用程序的數(shù)據(jù)，并盡可能快地把它扔到網(wǎng)絡(luò)上。在發(fā)送端，UDP傳送數(shù)據(jù)的速度僅僅是受應(yīng)用程序生成數(shù)據(jù)的速度、計(jì)算機(jī)的能力和傳輸帶寬的限制；在接收端，UDP把每個(gè)消息段放在隊(duì)列中，應(yīng)用程序每次從隊(duì)列中讀一個(gè)消息段。 (2) 由于傳輸數(shù)據(jù)不建立連接，因此也就不需要維護(hù)連接狀態(tài)，包括收發(fā)狀態(tài)等，因此一臺(tái)服務(wù)機(jī)可同時(shí)向多個(gè)客戶機(jī)傳輸相同的消息。(3) UDP信息包的標(biāo)題很短，只有8個(gè)字節(jié)，相對(duì)于TCP的20個(gè)字節(jié)信息包的額外開銷很小。(4) 吞吐量不受擁擠控制算法的調(diào)節(jié)，只受應(yīng)用軟件生成數(shù)據(jù)的速率、傳輸帶寬、源端和終端主機(jī)性能的限制。雖然UDP是一個(gè)不可靠的協(xié)議，但它是分發(fā)信息的一個(gè)理

15、想?yún)f(xié)議。例如，在屏幕上報(bào)告股票市場(chǎng)、在屏幕上顯示航空信息等等。UDP也用在路由信息協(xié)議RIP(Routing Information Protocol)中修改路由表。在這些應(yīng)用場(chǎng)合下，如果有一個(gè)消息丟失，在幾秒之后另一個(gè)新的消息就會(huì)替換它。UDP廣泛用在多媒體應(yīng)用中，例如，Progressive Networks公司開發(fā)的RealAudio軟件，它是在因特網(wǎng)上把預(yù)先錄制的或者現(xiàn)場(chǎng)音樂實(shí)時(shí)傳送給客戶機(jī)的一種軟件，該軟件使用的RealAudio audio-on-demand protocol協(xié)議就是運(yùn)行在UDP之上的協(xié)議，大多數(shù)因特網(wǎng)電話軟件產(chǎn)品也都運(yùn)行在UDP之上。UDP-UDP vs TCP

16、 UDPUDP和TCP協(xié)議的主要區(qū)別是兩者在如何實(shí)現(xiàn)信息的可靠傳遞方面不同。TCP協(xié)議中包含了專門的傳遞保證機(jī)制，當(dāng)數(shù)據(jù)接收方收到發(fā)送方傳來的信息時(shí)，會(huì)自動(dòng)向發(fā)送方發(fā)出確認(rèn)消息；發(fā)送方只有在接收到該確認(rèn)消息之后才繼續(xù)傳送其它信息，否則將一直等待直到收到確認(rèn)信息為止。 UDP與TCP不同，UDP協(xié)議并不提供數(shù)據(jù)傳送的保證機(jī)制。如果在從發(fā)送方到接收方的傳遞過程中出現(xiàn)數(shù)據(jù)報(bào)的丟失，協(xié)議本身并不能做出任何檢測(cè)或提示。因此，通常人們把UDP協(xié)議稱為不可靠的傳輸協(xié)議。 相對(duì)于TCP協(xié)議，UDP協(xié)議的另外一個(gè)不同之處在于如何接收突法性的多個(gè)數(shù)據(jù)報(bào)。不同于TCP，UDP并不能確保數(shù)據(jù)的發(fā)送和接收順序。例如，一

17、個(gè)位于客戶端的應(yīng)用程序向服務(wù)器發(fā)出了以下4個(gè)數(shù)據(jù)報(bào)D1D22D333D4444但是UDP有可能按照以下順序?qū)⑺邮盏臄?shù)據(jù)提交到服務(wù)端的應(yīng)用：D333D1D4444D22事實(shí)上，UDP協(xié)議的這種亂序性基本上很少出現(xiàn)，通常只會(huì)在網(wǎng)絡(luò)非常擁擠的情況下才有可能發(fā)生。UDP-UDP協(xié)議的應(yīng)用 既然UDP是一種不可靠的網(wǎng)絡(luò)協(xié)議，那么還有什么使用價(jià)值或必要呢？其實(shí)不然，在有些情況下UDP協(xié)議可能會(huì)變得非常有用。因?yàn)閁DP具有TCP所望塵莫及的速度優(yōu)勢(shì)。雖然TCP協(xié)議中植入了各種安全保障功能，但是在實(shí)際執(zhí)行的過程中會(huì)占用大量的系統(tǒng)開銷，無疑使速度受到嚴(yán)重的影響。反觀UDP由于排除了信息可靠傳遞機(jī)制，將安全和排

18、序等功能移交給上層應(yīng)用來完成，極大降低了執(zhí)行時(shí)間，使速度得到了保證。關(guān)于UDP協(xié)議的最早規(guī)范是RFC768，1980年發(fā)布。盡管時(shí)間已經(jīng)很長，但是UDP協(xié)議仍然繼續(xù)在主流應(yīng)用中發(fā)揮著作用。包括視頻電話會(huì)議系統(tǒng)在內(nèi)的許多應(yīng)用都證明了UDP協(xié)議的存在價(jià)值。因?yàn)橄鄬?duì)于可靠性來說，這些應(yīng)用更加注重實(shí)際性能，所以為了獲得更好的使用效果（例如，更高的畫面幀刷新速率）往往可以犧牲一定的可靠性（例如，會(huì)面質(zhì)量）。這就是UDP和TCP兩種協(xié)議的權(quán)衡之處。根據(jù)不同的環(huán)境和特點(diǎn)，兩種傳輸協(xié)議都將在今后的網(wǎng)絡(luò)世界中發(fā)揮更加重要的作用。UDP-UDP 程序設(shè)計(jì) UDP Server程序1、編寫UDP Server程序的

19、步驟(1)使用socket()來建立一個(gè)UDP socket，第二個(gè)參數(shù)為SOCK_DGRAM。(2)初始化sockaddr_in結(jié)構(gòu)的變量，并賦值。sockaddr_in結(jié)構(gòu)定義：struct sockaddr_in uint8_t sin_len;sa_family_t sin_family;in_port_t sin_port;struct in_addr sin_addr;char sin_zero8;這里使用“08”作為服務(wù)程序的端口，使用“INADDR_ANY”作為綁定的IP地址即任何主機(jī)上的地址。(3)使用bind()把上面的socket和定義的IP地址和端口綁定。這里檢查bin

20、d()是否執(zhí)行成功，如果有錯(cuò)誤就退出。這樣可以防止服務(wù)程序重復(fù)運(yùn)行的問題。(4)進(jìn)入無限循環(huán)程序，使用recvfrom()進(jìn)入等待狀態(tài)，直到接收到客戶程序發(fā)送的數(shù)據(jù)，就處理收到的數(shù)據(jù)，并向客戶程序發(fā)送反饋。這里是直接把收到的數(shù)據(jù)發(fā)回給客戶程序。2、udpserv.c程序內(nèi)容：#include #include #include #include #include #include #define MAXLINE 80#define SERV_PORT 8888void do_echo(int sockfd, struct sockaddr *pcliaddr, socklen_t clilen

21、)int n;socklen_t len;char mesgMAXLINE;for(;)len = clilen;/* waiting for receive data */n = recvfrom(sockfd, mesg, MAXLINE, 0, pcliaddr, &len);/* sent data back to client */sendto(sockfd, mesg, n, 0, pcliaddr, len);int main(void)int sockfd;struct sockaddr_in servaddr, cliaddr;sockfd = socket(AF_INET,

22、 SOCK_DGRAM, 0); /* create a socket */* init servaddr */bzero(&servaddr, sizeof(servaddr);servaddr.sin_family = AF_INET;servaddr.sin_addr.s_addr = htonl(INADDR_ANY);servaddr.sin_port = htons(SERV_PORT);/* bind address and port to socket */if(bind(sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr

23、) = -1)perror(bind error);exit(1);do_echo(sockfd, (struct sockaddr *)&cliaddr, sizeof(cliaddr);return 0;UDP Client程序1、編寫UDP Client程序的步驟(1)初始化sockaddr_in結(jié)構(gòu)的變量，并賦值。這里使用“8888”作為連接的服務(wù)程序的端口，從命令行參數(shù)讀取IP地址，并且判斷IP地址是否符合要求。(2)使用socket()來建立一個(gè)UDP socket，第二個(gè)參數(shù)為SOCK_DGRAM。(3)使用connect()來建立與服務(wù)程序的連接。與TCP協(xié)議不同，UDP的co

24、nnect()并沒有與服務(wù)程序三次握手。上面說了UDP是非連接的，實(shí)際上也可以是連接的。使用連接的UDP，kernel可以直接返回錯(cuò)誤信息給用戶程序，從而避免由于沒有接收到數(shù)據(jù)而導(dǎo)致調(diào)用recvfrom()一直等待下去，看上去好像客戶程序沒有反應(yīng)一樣。(4)向服務(wù)程序發(fā)送數(shù)據(jù)，因?yàn)槭褂眠B接的UDP，所以使用write()來替代sendto()。這里的數(shù)據(jù)直接從標(biāo)準(zhǔn)輸入讀取用戶輸入。(5)接收服務(wù)程序發(fā)回的數(shù)據(jù)，同樣使用read()來替代recvfrom()。(6)處理接收到的數(shù)據(jù)，這里是直接輸出到標(biāo)準(zhǔn)輸出上。udpclient.c程序內(nèi)容：#include #include #include

25、#include #include #include #include #include #define MAXLINE 80#define SERV_PORT 8888void do_cli(FILE *fp, int sockfd, struct sockaddr *pservaddr, socklen_t servlen)int n;char sendlineMAXLINE, recvlineMAXLINE + 1;/* connect to server */if(connect(sockfd, (struct sockaddr *)pservaddr, servlen) = -1)p

26、error(connect error);exit(1);while(fgets(sendline, MAXLINE, fp) != NULL)/* read a line and send to server */write(sockfd, sendline, strlen(sendline);/* receive data from server */n = read(sockfd, recvline, MAXLINE);if(n = -1)perror(read error);exit(1);recvlinen = 0; /* terminate string */fputs(recvl

27、ine, stdout);int main(int argc, char *argv)int sockfd;struct sockaddr_in srvaddr;/* check args */if(argc != 2)printf(usage: udpclient n);exit(1);/* init servaddr */bzero(&servaddr, sizeof(servaddr);servaddr.sin_family = AF_INET;servaddr.sin_port = htons(SERV_PORT);if(inet_pton(AF_INET, argv1, &serva

28、ddr.sin_addr) = 0)printf(%s is not a valid IPaddressn, argv1);exit(1);sockfd = socket(AF_INET, SOCK_DGRAM, 0);do_cli(stdin, sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr);return 0;運(yùn)行例子程序1、編譯例子程序使用如下命令來編譯例子程序：gcc -Wall -o udpserv udpserv.cgcc -Wall -o udpclient udpclient.c編譯完成生成了udpserv和udpcl

29、ient兩個(gè)可執(zhí)行程序。2、運(yùn)行UDP Server程序執(zhí)行./udpserv &命令來啟動(dòng)服務(wù)程序。我們可以使用netstat -ln命令來觀察服務(wù)程序綁定的IP地址和端口，部分輸出信息如下：Active Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address Statetcp 0 0 :32768 :* LISTENtcp 0 0 :111 :* LISTENtcp 0 0 :6000 :* L

30、ISTENtcp 0 0 :631 :* LISTENudp 0 0 :32768 :*udp 0 0 :8888 :*udp 0 0 :111 :*udp 0 0 :882 :*可以看到udp處有“:8888”的內(nèi)容，說明服務(wù)程序已經(jīng)正常運(yùn)行，可以接收主機(jī)上任何IP地址且端口為8888的數(shù)據(jù)。如果這時(shí)再執(zhí)行./udpserv &命令，就會(huì)看到如下信息：bind error: Address already in use說明已經(jīng)有一個(gè)服務(wù)

31、程序在運(yùn)行了。運(yùn)行UDP Client程序執(zhí)行./udpclient 命令來啟動(dòng)客戶程序，使用來連接服務(wù)程序，執(zhí)行效果如下：Hello, World!Hello, World!this is a testthis is a testd輸入的數(shù)據(jù)都正確從服務(wù)程序返回了，按ctrl+d可以結(jié)束輸入，退出程序。如果服務(wù)程序沒有啟動(dòng)，而執(zhí)行客戶程序，就會(huì)看到如下信息：$ ./udpclient testread error: Connection refused說明指定的IP地址和端口沒有服務(wù)程序綁定，客戶程序就退出了。這就是使用connect()

32、的好處，注意，這里錯(cuò)誤信息是在向服務(wù)程序發(fā)送數(shù)據(jù)后收到的，而不是在調(diào)用connect()時(shí)。如果使用tcpdump程序來抓包，會(huì)發(fā)現(xiàn)收到的是ICMP的錯(cuò)誤信息。TCP目錄 1 傳輸控制協(xié)議 2 運(yùn)作方式 o 2.1 通路的建立和終結(jié) o 2.2 數(shù)據(jù)傳輸 o 2.3 通路的終結(jié) 3 TCP的端口 4 TCP的封包結(jié)構(gòu) 5 TCP的發(fā)展過程 6 對(duì)TCP的選用情況 TCP-傳輸控制協(xié)議 傳輸控制協(xié)議（Transmission Control Protocol, TCP）是一種面向連接（連接導(dǎo)向）的、可靠的、基于字節(jié)流的運(yùn)輸層（Transport layer）通信協(xié)議，由IETF的RFC 793說

33、明（specified）。在簡化的計(jì)算機(jī)網(wǎng)絡(luò)OSI模型中，它完成第四層傳輸層所指定的功能，UDP是同一層內(nèi)另一個(gè)重要的傳輸協(xié)議。 在因特網(wǎng)協(xié)議族（Internet protocol suite）中，TCP層是位于IP層之上，應(yīng)用層之下的中間層。不同主機(jī)的應(yīng)用層之間經(jīng)常需要可靠的、像管道一樣的連接，但是IP層不提供這樣的流機(jī)制，而是提供不可靠的包交換。 應(yīng)用層向TCP層發(fā)送用于網(wǎng)間傳輸?shù)?、?位字節(jié)表示的數(shù)據(jù)流，然后TCP把數(shù)據(jù)流分割成適當(dāng)長度的報(bào)文段（通常受該計(jì)算機(jī)連接的網(wǎng)絡(luò)的數(shù)據(jù)鏈路層的最大傳送單元(MTU)的限制）。之后TCP把結(jié)果包傳給IP層，由它來通過網(wǎng)絡(luò)將包傳送給接收端實(shí)體的TCP層

34、。TCP為了保證不發(fā)生丟包，就給每個(gè)字節(jié)一個(gè)序號(hào)，同時(shí)序號(hào)也保證了傳送到接收端實(shí)體的包的按序接收。然后接收端實(shí)體對(duì)已成功收到的字節(jié)發(fā)回一個(gè)相應(yīng)的確認(rèn)(ACK)；如果發(fā)送端實(shí)體在合理的往返時(shí)延(RTT)內(nèi)未收到確認(rèn)，那么對(duì)應(yīng)的數(shù)據(jù)（假設(shè)丟失了）將會(huì)被重傳。TCP用一個(gè)校驗(yàn)和函數(shù)來檢驗(yàn)數(shù)據(jù)是否有錯(cuò)誤；在發(fā)送和接收時(shí)都要計(jì)算校驗(yàn)和。 TCP-運(yùn)作方式 通路的建立和終結(jié) TCP連接包括三個(gè)狀態(tài)：連接建立、數(shù)據(jù)傳送和連接終止。TCP用三路握手（three-way handshake）過程建立一個(gè)連接，用四路握手（four-way handshake）過程來拆除一個(gè)連接。在連接建立過tcp建立連接程中，很

35、多參數(shù)要被初始化，例如序號(hào)被初始化以保證按序傳輸和連接的強(qiáng)壯性。 TCP連接的正常建立一對(duì)終端同時(shí)初始化一個(gè)它們之間的連接是可能的。但通常是由一端打開一個(gè)接口(socket)然后監(jiān)聽來自另一方的連接，這就是通常所指的被動(dòng)打開(passive open)。服務(wù)器端被被動(dòng)打開以后，用戶端就能開始建立主動(dòng)打開(active open)。 1.客戶端通過向服務(wù)器端發(fā)送一個(gè)SYN來建立一個(gè)主動(dòng)打開，作為三路握手的一部分。 2.服務(wù)器端應(yīng)當(dāng)為一個(gè)合法的SYN回送一個(gè)SYN/ACK。 3.最后，客戶端再發(fā)送一個(gè)ACK。這樣就完成了三路握手，并進(jìn)入了連接建立狀態(tài)。 數(shù)據(jù)傳輸 在TCP的數(shù)據(jù)傳送狀態(tài)，很多重要的

36、機(jī)制保證了TCP的可靠性和強(qiáng)壯性。它們包括：使用序號(hào)，對(duì)收到的TCP報(bào)文段進(jìn)行排序以及檢測(cè)重復(fù)的數(shù)據(jù)；使用校驗(yàn)和來檢測(cè)報(bào)文段的錯(cuò)誤；使用確認(rèn)和計(jì)時(shí)器來檢測(cè)和糾正丟包或延時(shí)。序列號(hào)和確認(rèn)在TCP的連接建立狀態(tài)，兩個(gè)主機(jī)的TCP層間要交換初始序號(hào) (ISN:initial sequence number)。這些序號(hào)用于標(biāo)識(shí)字節(jié)流中的數(shù)據(jù)，并且還是對(duì)應(yīng)用層的數(shù)據(jù)字節(jié)進(jìn)行記數(shù)的整數(shù)。通常在每個(gè)TCP報(bào)文段中都有一對(duì)序號(hào)和確認(rèn)號(hào)。TCP報(bào)文發(fā)送者認(rèn)為自己的字節(jié)編號(hào)為序號(hào)，而認(rèn)為接收者的字節(jié)編號(hào)為確認(rèn)號(hào)。TCP報(bào)文的接收者為了確保可靠性，在接收到一定數(shù)量的連續(xù)字節(jié)流后才發(fā)送確認(rèn)。這是對(duì)TCP的一種擴(kuò)展，通

37、常稱為選擇確認(rèn)（Selective Acknowledgement）。選擇確認(rèn)使得TCP接收者可以對(duì)亂序到達(dá)的數(shù)據(jù)塊進(jìn)行確認(rèn)。每一個(gè)字節(jié)傳輸過后，ISN號(hào)都會(huì)遞增1。 通過使用序號(hào)和確認(rèn)號(hào)，TCP層可以把收到的報(bào)文段中的字節(jié)按正確的順序交付給應(yīng)用層。序號(hào)是32位的無符號(hào)數(shù)，在它增大到232-1時(shí)，便會(huì)回繞到0。對(duì)于ISN的選擇是TCP中關(guān)鍵的一個(gè)操作，它可以確保強(qiáng)壯性和安全性。 數(shù)據(jù)傳輸舉例1.發(fā)送方首先發(fā)送第一個(gè)包含序列號(hào)為1（可變化）和1460字節(jié)數(shù)據(jù)的TCP報(bào)文段給接收方。接收方以一個(gè)沒有數(shù)據(jù)的TCP報(bào)文段來回復(fù)（只含報(bào)頭），用確認(rèn)號(hào)1461來表示已完全收到并請(qǐng)求下TCP數(shù)據(jù)傳輸一個(gè)報(bào)文

38、段。 2.發(fā)送方然后發(fā)送第二個(gè)包含序列號(hào)為1461和1460字節(jié)數(shù)據(jù)的TCP報(bào)文段給接收方。正常情況下，接收方以一個(gè)沒有數(shù)據(jù)的TCP報(bào)文段來回復(fù)，用確認(rèn)號(hào)2921(1461+1460)來表示已完全收到并請(qǐng)求下一個(gè)報(bào)文段。發(fā)送接收這樣繼續(xù)下去。 3.然而當(dāng)這些數(shù)據(jù)包都是相連的情況下，接收方?jīng)]有必要每一次都回應(yīng)。比如，他收到第1到5條TCP報(bào)文段，只需回應(yīng)第五條就行了。在例子中第3條TCP報(bào)文段被丟失了，所以盡管他收到了第4和5條，然而他只能回應(yīng)第2條。 4.發(fā)送方在發(fā)送了第三條以后，沒能收到回應(yīng)，因此當(dāng)時(shí)鐘（timer）過時(shí)（expire）時(shí)，他重發(fā)第三條。（每次發(fā)送者發(fā)送一條TCP報(bào)文段后，都

39、會(huì)重啟動(dòng)一次時(shí)鐘:RTT）。 5.這次第三條被成功接收，接收方可以直接確認(rèn)第5條，因?yàn)?，5兩條已收到。 校驗(yàn)和TCP的16位的校驗(yàn)和(checksum)的計(jì)算和檢驗(yàn)過程如下：發(fā)送者將TCP報(bào)文段的頭部和數(shù)據(jù)部分的和計(jì)算出來，再對(duì)其求反碼(一的補(bǔ)數(shù))，就得到了校驗(yàn)和，然后將結(jié)果裝入報(bào)文中傳輸。（這里用反碼和的原因是這種方法的循環(huán)進(jìn)位使校驗(yàn)和可以在16位、32位、64位等情況下的計(jì)算結(jié)果在疊加后相同）接收者在收到報(bào)文后再按相同的算法計(jì)算一次校驗(yàn)和。這里使用的反碼使得接收者不用再將校驗(yàn)和字段保存起來后清零，而可以直接將報(bào)文段連同校驗(yàn)加總。如果計(jì)算結(jié)果是全部為一，那么就表示了報(bào)文的完整性和正確性。

40、注意：TCP校驗(yàn)和也包括了96位的偽頭部，其中有源地址、目的地址、協(xié)議以及TCP的長度。這可以避免報(bào)文被錯(cuò)誤地路由。 按現(xiàn)在的標(biāo)準(zhǔn)，TCP的校驗(yàn)和是一個(gè)比較脆弱的校驗(yàn)。具有高出錯(cuò)率的數(shù)據(jù)鏈路層需要額外的連接錯(cuò)誤糾正和探測(cè)能力。如果TCP是在今天被設(shè)計(jì)，它很可能有一個(gè)32位的CRC校驗(yàn)來糾錯(cuò)，而不是使用校驗(yàn)和。但是通過在第二層使用通常的CRC或更完全一點(diǎn)的校驗(yàn)可以部分地彌補(bǔ)這種脆弱的校驗(yàn)。第二層是在TCP層和IP層之下的，比如PPP或以太網(wǎng)，它們使用了這些校驗(yàn)。但是這也并不意味著TCP的16位校驗(yàn)和是冗余的，對(duì)于因特網(wǎng)傳輸?shù)挠^察，表明在受CRC保護(hù)的各跳之間，軟件和硬件的錯(cuò)誤通常也會(huì)在報(bào)文中引入

41、錯(cuò)誤，而端到端的TCP校驗(yàn)?zāi)軌虿蹲降胶芏嗟倪@種錯(cuò)誤。這就是應(yīng)用中的端到端原則。 流量控制和阻塞管理數(shù)據(jù)發(fā)送者之間用對(duì)接收數(shù)據(jù)的確認(rèn)或不予確認(rèn)來顯式的表示TCP發(fā)送者和接收者之間的網(wǎng)絡(luò)狀態(tài)。再加上計(jì)時(shí)器，TCP發(fā)送者和接收者就可以改變數(shù)據(jù)的流動(dòng)情況。這就是通常所指的流量控制（Flow control），擁塞控制/或擁塞避免。TCP使用大量的機(jī)制來同時(shí)獲得強(qiáng)壯性和高可靠性。這些機(jī)制包括：滑動(dòng)窗口、慢啟動(dòng)算法、擁塞避免算法、快速重啟和快速恢復(fù)算法等等。對(duì)于TCP的可靠的丟包處理、錯(cuò)誤最小化、擁塞管理以及高速運(yùn)行環(huán)境等機(jī)制的優(yōu)化的研究和標(biāo)準(zhǔn)制定，正在進(jìn)行之中。若有丟失封包，則從丟失的封包開始重送。UD

42、P因?yàn)榈么_認(rèn)正確了才能傳送下一階段，因此沒有辦法作流量管制。TCP數(shù)據(jù)傳輸不同于UDP之處 1.有序數(shù)據(jù)傳輸 2.重發(fā)丟失的封包 3.舍棄重復(fù)的封包 4.無錯(cuò)誤數(shù)據(jù)傳輸 5.阻塞/流量控制 6.連接導(dǎo)向（確認(rèn)有建立三方交握，連線已建立才作傳輸。） 通路的終結(jié) 連接終止?fàn)顟B(tài)使用了四路握手過程，在這個(gè)過程中每個(gè)終端的連接都能獨(dú)立地被終止。因此，一個(gè)典型的拆接過程需要每個(gè)終端都提供一對(duì)FIN和ACK。TCP正常終結(jié)TCP-TCP的端口 TCP使用了端口號(hào)的概念來標(biāo)識(shí)發(fā)送方和接收方的應(yīng)用層。對(duì)每個(gè)TCP連接的一端都有一個(gè)相關(guān)的16位元的無符號(hào)端口號(hào)分配給它們。端口被分為三類：眾所周知的、注冊(cè)的和動(dòng)態(tài)/

43、私有的。眾所周知的端口號(hào)是由因特網(wǎng)賦號(hào)管理局(IANA)來分配的，并且通常被用于系統(tǒng)一級(jí)或根進(jìn)程。眾所周知的應(yīng)用程序作為服務(wù)器程序來運(yùn)行，并被動(dòng)地偵聽經(jīng)常使用這些端口的連接。例如：FTP、TELNET、SMTP、HTTP等。注冊(cè)的端口號(hào)通常被用來作為終端用戶連接服務(wù)器時(shí)短暫地使用的源端口號(hào)，但它們也可以用來標(biāo)識(shí)已被第三方注冊(cè)了的、被命名的服務(wù)。動(dòng)態(tài)/私有的端口號(hào)在任何特定的TCP連接外不具有任何意義?？赡艿?、被正式承認(rèn)的端口號(hào)有65535個(gè)。TCP-TCP的封包結(jié)構(gòu) 封包來源連接埠 (16位元長) - 辨識(shí)傳送連接埠 目的連接埠 (16位元長) - 辨識(shí)接收連接埠 序列號(hào) (32位元長) 如果

44、含有同步化旗標(biāo) (SYN)，則此為最初的序列號(hào)；第一個(gè)資料位元的序列碼為本序列號(hào)加一。 如果沒有同步化旗標(biāo) (SYN)，則此為第一個(gè)資料位元的序列碼。TCP-TCP的發(fā)展過程 TCP是一個(gè)復(fù)雜的但同時(shí)又是在發(fā)展之中的協(xié)議。盡管許多重要的改進(jìn)被提出和實(shí)施，發(fā)表于1981年的RFC793中說明的TCP (TCP-Tahoe)的許多基本操作還是未作多大改動(dòng)。RFC1122：因特網(wǎng)對(duì)主機(jī)的要求闡明了許多TCP協(xié)議的實(shí)現(xiàn)要求。RFC2581：TCP的擁塞控制是一篇近年來關(guān)于TCP的很重要的RFC，描述了更新后的避免過度擁塞的算法。寫于2001年的RFC3168描述了對(duì)明顯擁塞的報(bào)告，這是一種擁塞避免的信

45、號(hào)量機(jī)制。在21世紀(jì)早期，在所有因特網(wǎng)的數(shù)據(jù)包中，通常有大約95%的包使用了TCP協(xié)議。常見的使用TCP的應(yīng)用層有HTTP/HTTPS（萬維網(wǎng)協(xié)議），SMTP/POP3/IMAP（電子郵件協(xié)議）以及FTP（文件傳輸協(xié)議）。這些協(xié)議在今天被廣泛地使用，這證明了它們的原作者的創(chuàng)造是卓越的。 最近，一個(gè)新協(xié)議已經(jīng)被加州理工學(xué)院的科研人員開發(fā)出來，命名為FAST TCP（基于快速活動(dòng)隊(duì)列管理的規(guī)?？勺兊膫鬏斂刂茀f(xié)議）。它使用排隊(duì)延遲作為擁塞控制信號(hào)；但是因?yàn)槎说蕉说难舆t通常不僅僅包括排隊(duì)延遲，所以FAST TCP (或更一般地，所有基于排隊(duì)延遲的算法) 在實(shí)際互聯(lián)網(wǎng)中的能否工作仍然是一個(gè)沒有解決的問題

46、。TCP-對(duì)TCP的選用情況 TCP并不是對(duì)所有的應(yīng)用都適合，一些新的帶有一些內(nèi)在的脆弱性的運(yùn)輸層協(xié)議也被設(shè)計(jì)出來。比如，實(shí)時(shí)應(yīng)用并不需要甚至無法忍受TCP的可靠傳輸機(jī)制。在這種類型的應(yīng)用中，通常允許一些丟包、出錯(cuò)或擁塞，而不是去校正它們。例如通常不使用TCP的應(yīng)用有：實(shí)時(shí)流多媒體（如因特網(wǎng)廣播）、實(shí)時(shí)多媒體播放器和游戲、IP電話（VoIP）等等。任何不是很需要可靠性或者是想將功能減到最少的應(yīng)用可以避免使用TCP。在很多情況下，當(dāng)只需要多路復(fù)用應(yīng)用服務(wù)時(shí)，用戶數(shù)據(jù)報(bào)協(xié)議（UDP）可以代替TCP為應(yīng)用提供服務(wù)。端口計(jì)算機(jī)端口是英文port的意譯，可以認(rèn)為是計(jì)算機(jī)與外界通訊交流的出口。其中硬件領(lǐng)域

47、的端口又稱接口， 如：USB端口、串行端口等。軟件領(lǐng)域的端口一般指網(wǎng)絡(luò)中面向連接服務(wù)和無連接服務(wù)的通信協(xié)議端口，是一種抽 象的軟件結(jié)構(gòu)，包括一些數(shù)據(jù)結(jié)構(gòu)和I/O（基本輸入輸出）緩沖區(qū)。 可以先了解面向連接和無連接協(xié)議（ConnectionOriented and Connectionless Protocols）面向連接服務(wù)的主要特點(diǎn)有：面向連接服務(wù)要經(jīng)過三個(gè)階段：數(shù)據(jù)傳數(shù)前，先建立連接，連接建立后再傳輸數(shù)據(jù)，數(shù)據(jù)傳送完后，釋放連接。面向連接服務(wù)，可確保數(shù)據(jù)傳送的次序和傳輸?shù)目煽啃浴?無連接服務(wù)的特點(diǎn)是：無連接服務(wù)只有傳輸數(shù)據(jù)階段。消除了除數(shù)據(jù)通信外的其它開銷。只要發(fā)送實(shí)體是活躍 的，無須接收

48、實(shí)體也是活躍的。它的優(yōu)點(diǎn)是靈活方便、迅速，特別適合于傳送少量零星的報(bào)文，但無連接服務(wù)不能 防止報(bào)文的丟失、重復(fù)或失序。 區(qū)分面向連接服務(wù)和無連接服務(wù)的概念，特別簡單、形象的例子是：打電話和寫信。兩個(gè)人如果要通電話 ，必須先建立連接-撥號(hào)，等待應(yīng)答后才能相互傳遞信息，最后還要釋放連接-掛電話。寫信就沒有那么復(fù)雜了， 地址姓名填好以后直接往郵筒一扔，收信人就能收到。TCP/IP協(xié)議在網(wǎng)絡(luò)層是無連接的（數(shù)據(jù)包只管往網(wǎng)上發(fā)，如 何傳輸和到達(dá)以及是否到達(dá)由網(wǎng)絡(luò)設(shè)備來管理）。而端口，是傳輸層的內(nèi)容，是面向連接的。協(xié)議里面低于 1024的端口都有確切的定義，它們對(duì)應(yīng)著因特網(wǎng)上常見的一些服務(wù)。 這些常見的服務(wù)

49、可以劃分為使用TCP端口（面向連接如打電話）和使用UDP端口（無連接如寫信）兩種。 網(wǎng)絡(luò)中可以被命名和尋址的通信端口是操作系統(tǒng)的一種可分配資源。由網(wǎng)絡(luò)OSI（開放系統(tǒng)互聯(lián)參考模型， Open System Interconnection Reference Model）七層協(xié)議可知，傳輸層與網(wǎng)絡(luò)層最大的區(qū)別是傳輸層提供進(jìn)程 通信能力，網(wǎng)絡(luò)通信的最終地址不僅包括主機(jī)地址，還包括可描述進(jìn)程的某種標(biāo)識(shí)。所以TCP/IP協(xié)議提出的協(xié)議端 口，可以認(rèn)為是網(wǎng)絡(luò)通信進(jìn)程的一種標(biāo)識(shí)符。 應(yīng)用程序（調(diào)入內(nèi)存運(yùn)行后一般稱為：進(jìn)程）通過系統(tǒng)調(diào)用與某端口建立連接（binding，綁定）后，傳輸層 傳給該端口的數(shù)據(jù)都被

50、相應(yīng)的進(jìn)程所接收，相應(yīng)進(jìn)程發(fā)給傳輸層的數(shù)據(jù)都從該端口輸出。在TCP/IP協(xié)議的實(shí)現(xiàn)中， 端口操作類似于一般的I/O操作，進(jìn)程獲取一個(gè)端口，相當(dāng)于獲取本地唯一的I/O文件，可以用一般的讀寫方式訪問 類似于文件描述符，每個(gè)端口都擁有一個(gè)叫端口號(hào)的整數(shù)描述符，用來區(qū)別不同的端口。由于TCP/IP傳輸層的 TCP和UDP兩個(gè)協(xié)議是兩個(gè)完全獨(dú)立的軟件模塊，因此各自的端口號(hào)也相互獨(dú)立。如TCP有一個(gè)255號(hào)端口，UDP也可 以有一個(gè)255號(hào)端口，兩者并不沖突。 端口號(hào)有兩種基本分配方式：第一種叫全局分配這是一種集中分配方式，由一個(gè)公認(rèn)權(quán)威的中央機(jī)構(gòu)根據(jù)用戶 需要進(jìn)行統(tǒng)一分配，并將結(jié)果公布于眾，第二種是本地

51、分配，又稱動(dòng)態(tài)連接，即進(jìn)程需要訪問傳輸層服務(wù)時(shí)，向本 地操作系統(tǒng)提出申請(qǐng)，操作系統(tǒng)返回本地唯一的端口號(hào)，進(jìn)程再通過合適的系統(tǒng)調(diào)用，將自己和該端口連接起來（ binding，綁定）。TCP/IP端口號(hào)的分配綜合了以上兩種方式，將端口號(hào)分為兩部分，少量的作為保留端口，以全 局方式分配給服務(wù)進(jìn)程。每一個(gè)標(biāo)準(zhǔn)服務(wù)器都擁有一個(gè)全局公認(rèn)的端口叫周知口，即使在不同的機(jī)器上，其端口號(hào) 也相同。剩余的為自由端口，以本地方式進(jìn)行分配。TCP和UDP規(guī)定，小于256的端口才能作為保留端口。 按端口號(hào)可分為3大類： （1）公認(rèn)端口（Well Known Ports）：從0到1023，它們緊密綁定（binding）于一

52、些服務(wù)。通常這些端口的通訊 明確表明了某種服務(wù)的協(xié)議。例如：80端口實(shí)際上總是HTTP通訊。 （2）注冊(cè)端口（Registered Ports）：從1024到49151。它們松散地綁定于一些服務(wù)。也就是說有許多服務(wù)綁定于 這些端口，這些端口同樣用于許多其它目的。例如：許多系統(tǒng)處理動(dòng)態(tài)端口從1024左右開始。 （3）動(dòng)態(tài)和/或私有端口（Dynamic and/or Private Ports）：從49152到65535。理論上，不應(yīng)為服務(wù)分配這些端口。實(shí)際上，機(jī)器通常從1024起分配動(dòng)態(tài)端口。但也有例外：SUN的RPC端口從32768開始。 系統(tǒng)管理員可以重定向端口： 一種常見的技術(shù)是把一個(gè)端口

53、重定向到另一個(gè)地址。例如默認(rèn)的HTTP端口是80，不少人將它重定向到另一個(gè)端口，如8080。如果是這樣改了，要訪問本文就應(yīng)改用這個(gè)地址:8080/index.htm（當(dāng)然， 這僅僅是理論上的舉例）。 實(shí)現(xiàn)重定向是為了隱藏公認(rèn)的默認(rèn)端口，降低受破壞率。這樣如果有人要對(duì)一個(gè)公認(rèn)的默認(rèn)端口進(jìn)行攻擊則必 須先進(jìn)行端口掃描。大多數(shù)端口重定向與原端口有相似之處，例如多數(shù)HTTP端口由80變化而來：81，88，8000，8080，8888。同樣POP的端口原來在110，也常被重定向到1100。也有不少情況是選取統(tǒng)計(jì)上有特別意義的數(shù)，象 1234，23456，34567等。許多人有其它原因選擇奇怪的數(shù)，42，

54、69，666，31337。近來，越來越多的遠(yuǎn)程控制木馬 (Remote Access Trojans, RATs )采用相同的默認(rèn)端口。 如NetBus的默認(rèn)端口是12345。Blake R. Swopes指出使用 重定向端口還有一個(gè)原因，在UNIX系統(tǒng)上，如果你想偵聽1024以下的端口需要有root權(quán)限。如果你沒有root權(quán)限而 又想開web服務(wù)，你就需要將其安裝在較高的端口。此外，一些ISP的防火墻將阻擋低端口的通訊，這樣的話即使你 擁有整個(gè)機(jī)器你還是得重定向端口。需要注意的是，端口并不是一一對(duì)應(yīng)的。比如你的電腦作為客戶機(jī)訪 問一臺(tái)WWW服務(wù)器時(shí)，WWW服務(wù)器使用“80”端口與你的電腦通信

55、，但你的電腦則 可能使用“3457”這樣的端口，如圖1所示。 按對(duì)應(yīng)的協(xié)議類型，端口有兩種：TCP端口和UDP端口。由于TCP和UDP 兩個(gè)協(xié)議是獨(dú)立的，因此各自的端口號(hào)也相互獨(dú)立，比如TCP有235端口，UDP也 可以有235端口，兩者并不沖突。 1.周知端口（Well Known Ports） 周知端口是眾所周知的端口號(hào)，范圍從0到1023，其中80端口分配給W WW服務(wù)，21端口分配給FTP服務(wù)等。我們?cè)贗E的地址欄里輸入一個(gè)網(wǎng)址的時(shí)候（ 比如）是不必指定端口號(hào)的，因?yàn)樵谀J(rèn)情況下WWW服務(wù)的端口 號(hào)是“80”。 網(wǎng)絡(luò)服務(wù)是可以使用其他端口號(hào)的，如果不是默認(rèn)的端口號(hào)則應(yīng)該在 地址欄上指定端口號(hào)，方法是在地址后面加上冒號(hào)“:”（半角），再加上端口 號(hào)。比如使用“8080”作為WWW服務(wù)的端口，則需要在地址欄里輸入“:8080”。 但是有些系統(tǒng)協(xié)議使用固定的端口號(hào)，它是不能被改變的，比如139 端口專門用于NetBIOS與TCP/IP之間的通信，不能手動(dòng)改變。 2.動(dòng)態(tài)端口（Dynamic Ports） 動(dòng)態(tài)端口的范圍是從1024到65535。之所以稱為動(dòng)態(tài)端口，是因?yàn)樗?一般不固定分配某種服務(wù)，而是動(dòng)態(tài)分配。動(dòng)態(tài)分配是指當(dāng)一個(gè)系統(tǒng)進(jìn)程或應(yīng)用 程序進(jìn)程需要網(wǎng)絡(luò)通信時(shí)，它向主機(jī)申請(qǐng)一個(gè)端口，主機(jī)從可用的端口號(hào)中分配 一個(gè)供它