網(wǎng)絡(luò)協(xié)議實踐課程第1頁，共54頁。TCP和UDP都提供了多路復(fù)用和多路分解，但是TCP提供的許多特性UDP卻不提供，比如可靠的有序報文傳輸、流量控制和擁塞控制。多路復(fù)用(multiplex)和多路分解(demultiplex)傳輸層協(xié)議指定了用于正確定位應(yīng)用程序發(fā)送端和接收端的源端口號和目的端口號。這一過程稱為多路復(fù)用(multiplex)和多路分解(demultiplex)。因特網(wǎng)同一主機(jī)上的應(yīng)用程序所產(chǎn)生的多個數(shù)據(jù)流復(fù)用一個輸出連接。因特網(wǎng)同一主機(jī)上不同應(yīng)用程序的多個數(shù)據(jù)流可能也會通過一個輸出連接傳輸，但是它們最終將會被分解并傳輸?shù)礁髯缘膽?yīng)用程序中去。第2頁，共54頁。在本章的實驗中，將會詳細(xì)討論這些特性。實驗3.1中，將首先觀察簡單的TCP流。我們將觀察TCP報文段的首部，并且討論TCP如何完成可靠的有序報文傳輸。實驗3.2中，將詳細(xì)研究TCP的重傳。我們將考慮致使TCP重新發(fā)送傳輸過的數(shù)據(jù)副本的各種事件。我們還會查看各種TCP變體，包括帶選擇確認(rèn)的TCP。實驗3.3中，將介紹UDP及其數(shù)據(jù)報首部。我們將比較傳輸同樣數(shù)據(jù)的TCP流和UDP流，我們還會分析，對于沒有接收端監(jiān)聽輸入數(shù)據(jù)的情況，TCP和UDP的發(fā)送端是如何處理的。實驗3.4中，將觀察TCP流量控制和擁塞控制屬性。我們將把TCP與既沒有流量控制又沒有擁塞控制的UDP進(jìn)行比較。我們將觀察兩個并發(fā)運(yùn)行的TCP流、一個與UDP流并發(fā)運(yùn)行的TCP流，以及兩個并發(fā)運(yùn)行的UDP流。我們將說明TCP的發(fā)送端之間會平等地共享網(wǎng)絡(luò)，而UDP的發(fā)送端卻不會限制發(fā)送速率。第3頁，共54頁。實驗3.1TCP介紹簡介

TCP是因特網(wǎng)中最主要的傳輸層協(xié)議。它能夠在兩個應(yīng)用程序間提供可靠的有序數(shù)據(jù)流傳輸，即使這兩個程序運(yùn)行在不同的主機(jī)上并且被一個會丟失、重排序或者破壞分組的不可靠網(wǎng)絡(luò)所隔開。TCP能夠檢測傳輸過程中分組是否丟失、延遲和改變，如是則重傳這些分組，從而提供了可靠的數(shù)據(jù)流傳輸?？梢韵胂褚幌?，你在用一臺可能丟頁的傳真機(jī)來傳送大量的文檔。你可能會把文檔編上頁號，這樣接收端就能知道哪部分丟失了。TCP報文段首部格式如圖（RFC793）：第4頁，共54頁。第5頁，共54頁。源端口字段和目的端口字段就不說了。序號字段表示分組中第一個字節(jié)的在傳輸字節(jié)流中的編號。確認(rèn)號字段是數(shù)據(jù)流中下一個期望接收的字節(jié)的編號。數(shù)據(jù)偏移字段，它表示報文段的數(shù)據(jù)部分的開始位置。由于TCP首部的長度會因為使用可變長度選項字段而發(fā)生變化，所以設(shè)置數(shù)據(jù)偏移字段是必要的。標(biāo)志部分含有6個不同的位:URGENT位、ACKNOWLEDGEMENT位、PUSH位、RESET位、SYN位和FIN位。ACKNOWLEDGEMENT位只表明確認(rèn)字段是否有效。PUSH位用于表示發(fā)送端應(yīng)用程序要求數(shù)據(jù)立刻發(fā)送。SYN,FIN,RESET這三位用來打開或關(guān)閉連接。URGENT位和緊急指針字段通常很少使用，所以在這里不做討論。接收端通告窗口字段和校驗和字段第6頁，共54頁。一、配置如圖2臺PC上都安裝ttcp來產(chǎn)生具有一定特征的TCP流。先在1臺PC上啟動接收端，后在另1臺PC上啟動1個發(fā)送端。建立TCP連接，發(fā)送數(shù)據(jù)。第7頁，共54頁。二、實驗本地ttcp連接接收端PC（）Ethereal開始捕獲第8頁，共54頁。啟動發(fā)送端PC（）發(fā)送端和接收端退出時候Ethereal停止捕獲,將跟蹤的結(jié)果保存在tcp_pcattcp_n1.cap中。第9頁，共54頁。三、觀察跟蹤記錄tcp_pcattcp_n1.cap連接建立分組3到5顯示的就是3次握手。第1條SYN分組。SYN位為1。序號是隨機(jī)數(shù)，而Ethereal顯示0為邏輯序號。第2條SYNACK分組。SYN、ACK位均為1。確認(rèn)號是前SYN分組隨機(jī)數(shù)+1，而Ethereal顯示1為邏輯序號。序號也是另一隨機(jī)數(shù)，而Ethereal顯示0。第3條ACK分組，客戶端發(fā)送帶有標(biāo)志ACK的TCP報文段來完成三次握手的過程。這個報文段將確認(rèn)服務(wù)器發(fā)送的SYNACK分組，并檢查TCP連接的兩端是否正確地打開和運(yùn)作。第10頁，共54頁。第11頁，共54頁。第12頁，共54頁。所有隨后的TCP報文段都將擁有ACK標(biāo)志，因為每端都會報告數(shù)據(jù)流中預(yù)期到來的下一個字節(jié)。如果一方?jīng)]有發(fā)送數(shù)據(jù)，另一方會為余下的連接發(fā)送同樣的確認(rèn)號。三次握手也會用來協(xié)商連接的某些屬性。比如，MSS（MaximumSegmentSize）。本地網(wǎng)上能發(fā)送的最大TCP報文段1460字節(jié)。單向數(shù)據(jù)流一旦連接建立了，ttcp發(fā)送端(客戶端)將向數(shù)據(jù)流寫入8192個字節(jié)。從應(yīng)用程序的角度來看，這是作為一個單位傳送的。然而，底層的網(wǎng)絡(luò)并不能支持容納8192個字節(jié)這樣大的分組，因此TCP會將這一個邏輯傳送單位分成多個報文段。第13頁，共54頁。跟蹤記錄中，包含數(shù)據(jù)的第一個報文段如分組6所示。它包含前1460個字節(jié)。再加上20個TCP首部字節(jié)和20個IP首部字節(jié)，這樣就達(dá)到了1500個字節(jié)，這也是以太網(wǎng)所允計的最大字節(jié)長度。再加上14個字節(jié)的以太網(wǎng)幀首部，這個幀的總大小為1514個字節(jié)。分組7、9、10和11也都傳送1460個字節(jié),這樣就傳送了1460x5=7300個字節(jié),剩下的8192-7300=892個字節(jié)將在分組13里面發(fā)送。本實驗服務(wù)器不會回傳任何數(shù)據(jù)給客戶端。因此，所有從端口號5001到2440發(fā)送的分組都只包含TCP首部而沒有數(shù)據(jù)。即使沒有自身要傳送的數(shù)據(jù)，服務(wù)器也要發(fā)送TCP報文段給客戶端，提供哪些數(shù)據(jù)已經(jīng)被成功接受的反饋。比如在分組8中，服務(wù)器發(fā)送一個確認(rèn)號為2921的報文段。服務(wù)器通過宣布期望接收的下一個字節(jié)號是2921來確認(rèn)分組6和分組7已經(jīng)接收。第14頁，共54頁。連接關(guān)閉當(dāng)兩端交換帶有FIN標(biāo)志的TCP報文段并且每一端都確認(rèn)另一端發(fā)送的FIN包時，TCP連接將會關(guān)閉。但那些重傳的數(shù)據(jù)仍然會被傳送，直到接收端確認(rèn)所有的信息。在tcp_pcattcp_n1.cap中，通過分組13至16我們可以看到TCP連接被關(guān)閉。ttcp發(fā)送端寫完了數(shù)據(jù)的8192個字節(jié)，它就準(zhǔn)備斷開連接了。第15頁，共54頁。在分組13里，包含了最后892節(jié)并且設(shè)置了FIN位指示沒有額外的數(shù)據(jù)將要被傳送。在分組14里，服務(wù)器確認(rèn)已經(jīng)收到了所有發(fā)送的數(shù)據(jù)。我們注意到這時確認(rèn)號為8194而不是8193。這是由于FIN自身被當(dāng)作第8193個字節(jié)了。在分組15中，服務(wù)器也發(fā)送一個FIN標(biāo)志指示不會發(fā)送任何其他附加的數(shù)據(jù)了。在分組16中，客戶端會發(fā)送最后一個確認(rèn)號為2的報文段來確認(rèn)服務(wù)器所發(fā)的FIN標(biāo)志，因為FIN本身也被看作為最后的字節(jié)。第16頁，共54頁。2個FIN和相應(yīng)ACK是用來終止一個TCP連接的較好方法。也可以通過設(shè)置RESET位來終止TCP連接。盡管設(shè)計RESET是為了處理不可恢復(fù)的錯誤，但是在實踐中也經(jīng)常用來進(jìn)行快速終止連接，以避免常規(guī)的FIN-ACK交換。第17頁，共54頁。連接統(tǒng)計StatisticTCPStreamGraphTime-SequenceGraph(tcptrace)注意只能看發(fā)送端到接收端1到8194，或者接收端到發(fā)送端0到2。Ananyze

FollowTCPStream看到兩端所有數(shù)據(jù)，或發(fā)送端到接收端/接收端到發(fā)送端的數(shù)據(jù)。

（見下頁截圖）Statistics

ProtocolHierarchy在這種情況下，Ethereal會報告在整個跟蹤文件中總共有9090個字節(jié)的數(shù)據(jù)、8988個字節(jié)的TCP通信。在我們的跟蹤記錄中，有6個分組(分組6,7,9,10,11和13）含有數(shù)據(jù)，它們都包含有54個字節(jié)的首部（20個字節(jié)的TCP首部、20個字節(jié)的IP首部和14個字節(jié)的以太網(wǎng)首部）即總共54x6=324字節(jié)+8192字節(jié)數(shù)據(jù)=8516字節(jié)，另外8個分組不含數(shù)據(jù)，54x8=432字節(jié)，總和正好為8988字節(jié)。第18頁，共54頁。第19頁，共54頁。遠(yuǎn)程SSH連接(交互式雙向數(shù)據(jù)流）

除了在本地網(wǎng)上由ttcp產(chǎn)生的一個TCP連接以外，我們還在本地機(jī)和一個遠(yuǎn)程服務(wù)器之間產(chǎn)生一個SSH連接。將所捕獲的網(wǎng)絡(luò)通信保存在文件tcp_ssh.cap中?？蛻舳撕头?wù)器都發(fā)送數(shù)據(jù)。通過使用FollowTCPStream來分離開每一方的數(shù)據(jù)通道，你能夠很快地發(fā)現(xiàn)不同之處。實際操作來看看SSH客戶端會發(fā)送很多只有少量數(shù)據(jù)的報文段，因為這種連接代表一種交互式的數(shù)據(jù)流，而不是大量傳輸8192個字節(jié)的ttcp流?？纯雌銽CP報文段首部的PUSH標(biāo)志位。TCP層正常情況下嘗試在通過網(wǎng)絡(luò)發(fā)送數(shù)據(jù)之前收集足夠多的數(shù)據(jù)來最大限度地填滿一個報文段。在應(yīng)用程序要求該報文段不等填滿便立即被發(fā)送的時候，PUSH標(biāo)志位置1。第20頁，共54頁。TCP首部消耗了整個數(shù)據(jù)流中的較大比例。在SSH流中即使最大報文段大小仍為1460個字節(jié)，事實上，大多數(shù)報文段包含的數(shù)據(jù)都少于100個字節(jié)。整個會話過程的字節(jié)數(shù)是8606個。這比起ttcp流中的8192個字節(jié)來說并不算多，但是卻一共需要118個報文段包含數(shù)據(jù)，而不是6個報文段。在這個實驗中TCP數(shù)據(jù)流包含有8606個字節(jié)的數(shù)據(jù)，而總共傳輸卻有18508個字節(jié)（數(shù)據(jù)占46%）。而在ttcp流中含有8192個字節(jié)的數(shù)據(jù)，總共傳輸8988個字節(jié)（數(shù)據(jù)占91%）。第21頁，共54頁。小節(jié)本堂課，我們用Ethereal逆向分析了TCP協(xié)議的一些細(xì)節(jié)，讓我們對TCP報文段格式、TCP連接建立、連接關(guān)閉、單向或雙向數(shù)據(jù)流傳輸以及傳輸?shù)拈_銷都有了直觀基本的認(rèn)識。第22頁，共54頁。實驗3.2TCP重傳簡介本節(jié)重點(diǎn)探討TCP在一個不可靠的網(wǎng)絡(luò)上如何依靠接收端返回的檢查丟失或錯誤的反饋來提供一個可靠的數(shù)據(jù)傳輸。在這個實驗里，將觀察發(fā)生重傳時TCP連接的跟蹤記錄。重傳計時器當(dāng)一個TCP發(fā)送端傳輸一個報文段的同時也設(shè)置了一個重傳計時器。確認(rèn)到達(dá)時，該計時器就自動取消。如果在數(shù)據(jù)的確認(rèn)信息到達(dá)之前這個計時器超時，那么數(shù)據(jù)將會重傳。重傳計時器能夠自動靈活設(shè)置。最初，TCP是基于初始的SYN和SYNACK之間的時間來設(shè)置重傳計時器的。在整個TCP連接中，TCP都會注意每個報文段的發(fā)送和收到相應(yīng)的確認(rèn)所經(jīng)歷的時間。我們會計算出這些時間的一個平均值，那樣的話，累積平均值會比最近采樣更具有說服力。第23頁，共54頁。TCP也會把一系列重復(fù)確認(rèn)的分組當(dāng)作是數(shù)據(jù)丟失的先兆。也就是說發(fā)送端不一定非得等到超時重傳。如果接收端期望的字節(jié)號是1000，然而接收到的字節(jié)號卻是2000到3000，那么它們必須繼續(xù)設(shè)置確認(rèn)號為1000。如果包含字節(jié)號從1000到1099的段丟失了，那么它們將繼續(xù)為每個新接收的報文段發(fā)送確認(rèn)號1000。當(dāng)發(fā)送端看見帶有同樣確認(rèn)號的一系列報文段的時候，它會假設(shè)雖然數(shù)據(jù)到達(dá)了另外一端并且發(fā)送了確認(rèn)號，但是包含第1000字節(jié)的報文段卻丟失了。TCP后來的版本為接收端提供了一種方法，可以指示已經(jīng)接收到的報文段中哪些是失序的。這稱為選擇確認(rèn)，具有這種特征的TCP常常被稱作TCPSACK。發(fā)送端和接收端可以在連接建立的三次握手期間協(xié)商是否使用SACK這樣的附加特征。第24頁，共54頁。一、配置便攜式電腦使用無線接口，方便對其進(jìn)行一個強(qiáng)信號的干擾。使用ttcp來產(chǎn)生一個具有特殊屬性的TCP流，通過TCP連接下載一個文件。第25頁，共54頁。二、實驗本地TTCP連接便攜式電腦（）運(yùn)行一個ttcp流的接收端攜式電腦隨后啟動Ethereal開始捕獲臺式機(jī)先啟動Ethereal開始捕獲隨后臺式機(jī)（）啟動ttcp流發(fā)送端第26頁，共54頁。發(fā)送端和接收端程序都退出時，停止數(shù)據(jù)捕獲。將從發(fā)送端(臺式機(jī))捕獲的跟蹤記錄保存在pcattcp_retrans_t.cap，將從接收端(便攜式電腦)捕獲的跟蹤記錄保存在文件pcattcp_retrans_r.cap。第27頁，共54頁。三、跟蹤分析SACK選項協(xié)商觀察建立連接的三次握手。在SYN分組(兩個跟蹤文件中的分組1)中，臺式機(jī)在TCP的首部選項中通過包括SACKpermitted選項來希望使用TCPSACK。在SYNACK包(兩個跟蹤文件中的分組2)中，便攜式電腦表示愿意使用SACK。這樣，雙方就都同意接收選擇性確認(rèn)信息。SACK選項見圖。第28頁，共54頁。第29頁，共54頁。在TCPSACK里，如果連接的一端接收了失序數(shù)據(jù)，它將使用選項區(qū)字段來發(fā)送關(guān)于失序數(shù)據(jù)起始和結(jié)束的信息。這樣允許發(fā)送端僅僅重傳丟失的數(shù)據(jù)。在若干分組丟失情況下，這一點(diǎn)特別有用，因為重復(fù)的確認(rèn)僅僅作為一個分組丟失的提示。任何接收到的失序數(shù)據(jù)要么被丟掉，要么被暫時緩存起來。TCP發(fā)送端必須保存一份已發(fā)送的數(shù)據(jù)的副本，以防數(shù)據(jù)需要重發(fā)。發(fā)送端必須保存數(shù)據(jù)直到它們收到數(shù)據(jù)的確認(rèn)信息為止。接收端通常會分配一個固定大小的緩沖區(qū)空間來存儲這些失序數(shù)據(jù)和需要等待一個應(yīng)用程序讀取的數(shù)據(jù)。如果緩沖區(qū)空間不能夠容納下更多數(shù)據(jù)，那么接收端只有將數(shù)據(jù)丟掉。接收端的通告窗口字段用來通知發(fā)送端接收端還有多少空間可以用于輸入的數(shù)據(jù)。如果數(shù)據(jù)發(fā)送的速度快于應(yīng)用程序處理數(shù)據(jù)的速度，接收端就會發(fā)送一些信息來告知發(fā)送端其接收窗口正在減小。第30頁，共54頁。在這個跟蹤文件中，便攜式電腦發(fā)送的接收端通告窗口的大小是變化的，從16520個字節(jié)到17520個字節(jié)?？梢杂帽銛y式電腦的顯示過濾器(如tcp.srcport==5001)來分離這些響應(yīng)。TCP發(fā)送端在發(fā)送之前也有一個容納數(shù)據(jù)的有限空間。然而，和接收端不同的是，發(fā)送端是限制自己的發(fā)送速率。如果緩沖區(qū)的空間滿了，嘗試寫入更多數(shù)據(jù)的應(yīng)用程序?qū)蛔枞钡接懈嗟目臻g可以利用為止。第31頁，共54頁。分組的丟失與重傳（選擇性重傳的例子）觀察pcattcp_retrans_t.cap，用顯示過濾器尋找重傳(見圖。分組12是這9次重傳的第1次。第32頁，共54頁。分組12序號是1001，使用過濾器tcp.seq==1001，我們發(fā)現(xiàn)分組5也擁有同樣的序號。有趣的是，分組5是對1001到2460號字節(jié)的傳輸，而分組12僅是對1001到2000號字節(jié)的重傳。分組20實際上是對2001到2460號字節(jié)的重傳。

分組4傳輸1-1000號字節(jié)，分組5傳輸1001-2460號字節(jié)，分組7傳輸2461-3920號字節(jié)。第33頁，共54頁。觀察pcattcp_retrans_r.cap。分組4傳輸1-1000號字節(jié)，分組5確認(rèn)1-1000號字節(jié)。分組6傳送2461-3920號字節(jié)（而不是分組7）。接收端沒有看到發(fā)送端1001-2460號字節(jié)的傳輸。但是他們確實被發(fā)送了，僅可能在發(fā)送端和接收端之間的某個環(huán)節(jié)丟失了。接收端是如何來處理這些丟失的。在分組4到達(dá)以后，接收端會以確認(rèn)號1001（分組5）響應(yīng)。在分組6的2461-3920號字節(jié)到達(dá)之后，接收端仍然是以確認(rèn)號1001（分組7）響應(yīng)。在分組7的首部的可選擇字段里還包含有一些選擇性確認(rèn)信息。第34頁，共54頁。其中SACK選項通過左邊界684449229和右邊界684450689表示它接收了失序數(shù)據(jù)。要了解SACK選項，請記住初始的序號是隨機(jī)選擇的。而684449229到684450689正好是1460個失序字節(jié)。同樣，在含有3921-5381號字節(jié)的分組8到達(dá)之后，接收端再次響應(yīng)1001確認(rèn)號。然而分組9里面的SACK選項的右邊界增至684452149，反映接收到了更多失序數(shù)據(jù)，僅僅簡單延伸已存在的失序區(qū)域的右邊界就足夠了。第35頁，共54頁。最后，分組12重傳1001-2000號字節(jié)，分組14接收端增加確認(rèn)號到2001。分組19重傳2001-2460號字節(jié)（對應(yīng)pcattcp_retrans_t.cap的分組20），接收端立即從確認(rèn)字節(jié)2001跳到確認(rèn)字節(jié)11221。第36頁，共54頁。對發(fā)送速率的影響44085001的數(shù)據(jù)流中選一個分組，操作StatisticTCPStreamGraphTimeSequenceGraphs(Steven’s)第37頁，共54頁。分別大約在0.15秒、1.8秒、3.1秒和4.0秒看見四組垂直的點(diǎn)。1.8秒的那組包括一個孤立的點(diǎn)，它位于序號20000上面，后面跟著一組在25000上面彼此接近的點(diǎn)。該最低點(diǎn)是在0.15秒附近的已經(jīng)發(fā)送的序號的重傳點(diǎn)。這是由于SACK信息允許發(fā)送端僅僅重傳丟失的那一段，因此在同一垂直組中，那個重傳點(diǎn)和其他的點(diǎn)分開。這個分組的丟失和重傳導(dǎo)致了在數(shù)據(jù)發(fā)送過程中的一個明顯延遲。第38頁，共54頁。遠(yuǎn)程TCP連接（全部重傳的例子）用本地計算機(jī)和遠(yuǎn)程服務(wù)器之間的TCP來跟蹤HTTP連接。我們將捕獲的結(jié)果保存在tcp_http.cap文件中。這個實驗只能從接收端的角度去跟蹤。三次握手發(fā)生在分組1到分組3。我們的本地機(jī)發(fā)送SYN分組并且在TCP首部的選項字段中含有SACKpermitted選項。然而在本例中遠(yuǎn)程服務(wù)器并未在SYNACK分組中包括SACKpermitted選項，因此選擇確認(rèn)不會在這個連接中發(fā)送。也就是說該丟失分組之后的所有分組都要重傳。第39頁，共54頁。小節(jié)1.用Ethereal觀察TCP重傳細(xì)節(jié)，直觀認(rèn)識TCP重傳第40頁，共54頁。實驗3.3TCP和UDP比較簡介TCP提供可靠傳輸、流量控制、擁塞控制、點(diǎn)對點(diǎn)連接UDP只是在IP層上簡單擴(kuò)展、不可靠傳輸，非點(diǎn)對點(diǎn)連接第41頁，共54頁。一、配置

使用ttcp來生成兩個TCP流，然后再生成兩個UDP流。第42頁，共54頁。二、實驗第一個TCP流和UDP流嘗試著發(fā)送相同數(shù)量的數(shù)據(jù)到一個處于等待狀態(tài)的接收端那里?？梢詫CP和UDP作為一種傳輸具有類似特性的流的手段進(jìn)行比較。第二個TCP流和UDP流也嘗試發(fā)送同樣的數(shù)據(jù)，但這時卻沒有處于等待狀態(tài)的接收端。可以比較TCP和UDP對于發(fā)送失敗都會作出什么反映。將兩次TCP流的跟蹤記錄保存文件tcp_2transmit.cap中，并將兩次UCP流的跟蹤保存文件udp_2transmit.cap中。第43頁，共54頁。用TTCP生成TCP和UDP通信第一個TCP流便攜式電腦上運(yùn)行接收端5001端口監(jiān)聽。第44頁，共54頁。臺式機(jī)傳輸每個緩沖區(qū)1000字節(jié)的5個緩沖區(qū)數(shù)據(jù)5000字節(jié)。接收用2.48秒，傳送用0秒第45頁，共54頁。第一個UDP流在便攜式電腦上運(yùn)行接收端。在UDP端口5001上開始監(jiān)聽第46頁，共54頁。臺式機(jī)傳輸每個緩沖區(qū)為1000字節(jié)5個緩沖區(qū)數(shù)據(jù)5000字節(jié)。接收用0.01秒，傳送用0秒。UDP比TCP時間少得多。第47頁，共54頁。

觀察分析TCP傳輸?shù)恼?shù)據(jù)：tcp_2transmit.cap的分組1-3建立連接，10-13關(guān)閉連接。分組4發(fā)送1000字節(jié)，分組5發(fā)送1460字節(jié)、分組6接收端確認(rèn)、分組7發(fā)送1460字節(jié)，分組8發(fā)送1080字節(jié)，分組9接收端確認(rèn)。Ethereal顯示2.48秒正好是從初始化連接的分組1開始到關(guān)閉連接的分組10結(jié)束。第一個包含數(shù)據(jù)的分組4和最后一個分組8之間的時間大約0.01=UDP接收端所報告的0.01秒。這樣的話，增加TCP傳輸時間的主要因素就是分組10中的重傳。公平地說，UDP是幸運(yùn)的，因為它所有分組都在第一時間被接收。第48頁，共54頁。

觀察分析UDP正常數(shù)據(jù)傳輸：udp_2transmit.cap分組1到分組11,雖然像TCP流那樣傳輸了相同的數(shù)據(jù)，但是還是有很多的不同。UDP無SYN和SYNACK分組顯式連接，無FIN和FINACK分組顯式關(guān)閉連接。所有11個分組都發(fā)送數(shù)據(jù)，1是特殊4字節(jié)數(shù)據(jù)報，7-11特殊4字節(jié)數(shù)據(jù)報（由于UDP無起始，應(yīng)用程序ttcp只有依靠它們來標(biāo)志起始）。UDP2-6分組是5個1000字節(jié)直接打包5個UDP數(shù)據(jù)報。UDP在傳輸?shù)臄?shù)據(jù)中不會加上序號，接收端不可能確定丟失和重排序重傳的情況。UDP不提供接收端到發(fā)送端的反饋（確認(rèn)或降速）。第49頁，共54頁。TCP和UDP的另外一個不同之處在于TCP連接是點(diǎn)對點(diǎn)的。換句話說，TC