思科網(wǎng)絡(luò)技術(shù)學(xué)院教程第三講傳輸層介紹

1、第三講OSI傳輸層介紹無論是本地還是全球，數(shù)據(jù)網(wǎng)絡(luò)和Internet都能為人們提供順暢、可靠的通信，以此支持以人為本的網(wǎng)絡(luò)。人們可以在一臺設(shè)備上使用多種服務(wù)來發(fā)送消息或者檢索信息。電子郵件客戶端程序、Web瀏覽器和即時消息客戶端等應(yīng)用程序使人們得以發(fā)送消息和查找信息。這些應(yīng)用程序發(fā)出的數(shù)據(jù)經(jīng)過封裝傳輸，最終送達(dá)目的設(shè)備上的相應(yīng)服務(wù)器守護(hù)程序或應(yīng)用程序。我們之前曾介紹過，OSI傳輸層的進(jìn)程從應(yīng)用層接收數(shù)據(jù)，然后進(jìn)行相應(yīng)處理以便用于網(wǎng)絡(luò)層尋址。如圖4-1所示，傳輸層負(fù)責(zé)終端應(yīng)用程序之間的全部數(shù)據(jù)傳輸。 關(guān)鍵術(shù)語流量控制控制數(shù)據(jù)互聯(lián)網(wǎng)編號指派機(jī)構(gòu)（IANA）知名端口注冊端口動態(tài)或私有端口緊

2、急指針URG確認(rèn)字段ACK護(hù)送功能PSH重置功能RST同步序列號SYN發(fā)送方已經(jīng)傳送完所有數(shù)據(jù)FIN確認(rèn)窗口大小傳輸層的作用傳輸層在終端用戶之間提供透明的數(shù)據(jù)傳輸，向上層提供可靠的數(shù)據(jù)傳輸服務(wù)。傳輸層在給定的鏈路上通過流量控、分段/重組和差錯控制。一些協(xié)議是面向鏈接的。這就意味著傳輸層能保持對分段的跟蹤，并且重傳那些失敗的分段。將這些數(shù)據(jù)片段重組為完整的應(yīng)用數(shù)據(jù)流；標(biāo)志不同的生活服務(wù)程序；在終端用戶之間執(zhí)行流量控制；差錯恢復(fù)；開始一個會話。如圖4-2所示，傳輸層確保設(shè)備上的應(yīng)用程序能夠通信。下一節(jié)描述傳輸層的不同作用以及傳輸層協(xié)議的數(shù)據(jù)要求。一、跟蹤各個會話每臺主機(jī)上都可以有多個應(yīng)用程序同時在

3、網(wǎng)絡(luò)上通信。這些應(yīng)用程序?qū)⑴c遠(yuǎn)程主機(jī)上的一個或多個應(yīng)用程序相互通信。傳輸層負(fù)責(zé)管理這些應(yīng)用程序間的多道通信流。如圖4-3所示，假設(shè)某臺連入網(wǎng)絡(luò)的計(jì)算機(jī)正在收發(fā)電子郵件、使用即時消息、瀏覽網(wǎng)站和進(jìn)行VoIP電話呼叫，那么這些應(yīng)用程序?qū)⑼瑫r通過網(wǎng)絡(luò)發(fā)送和接收數(shù)據(jù)。但是，電話呼叫的數(shù)據(jù)不會傳送到Web瀏覽器上；同樣，即時消息的內(nèi)容也不會顯示在電子郵件中。 圖4-2  傳輸層確保設(shè)備上的應(yīng)用程序能夠通信 圖4-3  跟蹤會話二、分段數(shù)據(jù)應(yīng)用程序向傳輸層傳遞大量數(shù)據(jù)。傳輸層必須將數(shù)據(jù)拆分成小的片段，更適合傳送。這些小的片段被稱為分段。這一過程包括必須在傳輸層上為每

4、段應(yīng)用程序添加報頭，以顯示關(guān)聯(lián)與該段數(shù)據(jù)相關(guān)的通信。如圖4-4所示的數(shù)據(jù)分段，與傳輸層的協(xié)議相關(guān)，在計(jì)算機(jī)上同時運(yùn)行多個程序時提供數(shù)據(jù)發(fā)送與接收。沒有分段，只有一個應(yīng)用程序，例如視頻流，才能接收數(shù)據(jù)。在觀看視頻時，你將不能接收電子郵件，用即時消息軟件聊天或?yàn)g覽網(wǎng)頁。 圖4-4  分段三、重組數(shù)據(jù)段由于網(wǎng)絡(luò)能提供不同的傳輸路徑，數(shù)據(jù)可能以錯誤的順序到達(dá)。通過編號與排序分段，傳輸層能保證這些分段能以正確的順序重組。在接收主機(jī)，數(shù)據(jù)的每個分段必須按正確的順序重組，然后傳給適當(dāng)?shù)膽?yīng)用程序。傳輸層的協(xié)議描述了傳輸層的頭信息如何用于重組數(shù)據(jù)片段成為正確的數(shù)據(jù)流傳給應(yīng)用程序。四、標(biāo)識應(yīng)用

5、程序?yàn)榱藢?shù)據(jù)流傳送到適當(dāng)?shù)膽?yīng)用程序，傳輸層必須要標(biāo)志目的應(yīng)用程序。因此，傳輸層將向應(yīng)用程序分配標(biāo)識符。TCP/IP協(xié)議族稱這種標(biāo)識符為端口號。在每臺主機(jī)中，每個需要訪問網(wǎng)絡(luò)的軟件進(jìn)程都將被分配一個唯一的端口號。該端口號將用于傳輸層報頭中，以指示與數(shù)據(jù)片段關(guān)聯(lián)的應(yīng)用程序。在傳輸層中，源應(yīng)用程序和目的應(yīng)用程序之間傳輸?shù)奶囟〝?shù)據(jù)片段集合稱為會話。將數(shù)據(jù)分割成若干小塊，然后將這些小的數(shù)據(jù)段從源設(shè)備發(fā)往目的設(shè)備，那么網(wǎng)絡(luò)中可以同時交叉收發(fā)（多路傳輸）很多不同的通信信息。傳輸層負(fù)責(zé)網(wǎng)絡(luò)傳輸，是應(yīng)用層和網(wǎng)絡(luò)層之間的橋梁。它從不同的會話接收信息后，將數(shù)據(jù)劃分成最終能在介質(zhì)上多路傳輸?shù)囊恍┍阌诠芾淼臄?shù)據(jù)片段，

6、然后再向下層傳送數(shù)據(jù)。應(yīng)用程序不需要了解所用網(wǎng)絡(luò)的詳細(xì)運(yùn)作信息，它們只需生成從一個應(yīng)用程序發(fā)送到另一個應(yīng)用程序的數(shù)據(jù)，而不必理會目的主機(jī)類型、數(shù)據(jù)必須要流經(jīng)的介質(zhì)類型、數(shù)據(jù)傳輸?shù)穆窂揭约版溌飞系膿砣闆r或網(wǎng)絡(luò)的規(guī)模。同時，OSI模型的下層也不需要知道有多少應(yīng)用程序在通過網(wǎng)絡(luò)發(fā)送數(shù)據(jù)。它們只需負(fù)責(zé)將數(shù)據(jù)傳送到適當(dāng)?shù)脑O(shè)備。然后，傳輸層將對這些數(shù)據(jù)段排序，并將其傳送到相應(yīng)的應(yīng)用程序。五、流量控制網(wǎng)絡(luò)主機(jī)只有有限的資源，如內(nèi)存或帶寬。當(dāng)傳輸層得知這些資源已經(jīng)過載，一些協(xié)議能夠要求發(fā)送程序減小數(shù)據(jù)流的流量。這些傳輸層是通過減少數(shù)據(jù)源的傳送數(shù)據(jù)組的大小實(shí)現(xiàn)的。流量控制能防止在網(wǎng)絡(luò)上丟失分段并且避免重傳。六

7、、錯誤恢復(fù)出于多種原因，數(shù)據(jù)片段在通過網(wǎng)絡(luò)傳輸時可能被破壞，從而丟失。傳輸層通過重傳任何丟失的數(shù)據(jù)確保所有的片段都能到達(dá)目的地。七、開始會話傳輸層通過在應(yīng)用程序間建立一個會話提供面向連接的定位服務(wù)。這些連接在傳送任何數(shù)據(jù)之前準(zhǔn)備好應(yīng)用程序間的通信。在這些會話中，在兩個應(yīng)用程序通信的數(shù)據(jù)可以被嚴(yán)格地管理。八、數(shù)據(jù)要求各不相同由于不同的應(yīng)用程序有不同的要求，所以傳輸層協(xié)議也有很多種。例如，只有接收和顯示完整的電子郵件或Web網(wǎng)頁，用戶才能使用其中的信息。因此，為確保接收和顯示的信息的完整性而導(dǎo)致的輕微延遲是可以接受的。相比之下，在電話交談的過程中偶爾丟失小部分內(nèi)容是可以接受的。通話人可以從交談過程

8、推斷出丟失的語音內(nèi)容，否則可以直接請對方復(fù)述剛才的話。顯然，這種方式要比請求網(wǎng)絡(luò)來管理并重發(fā)丟失的數(shù)據(jù)段更好，因?yàn)榭梢詼p少延遲。在此例中，由用戶而不是網(wǎng)絡(luò)來管理丟失信息的重發(fā)或替換工作。在當(dāng)今的融合的網(wǎng)絡(luò)中，聲音、視頻、數(shù)據(jù)都在相同的網(wǎng)絡(luò)上通信，不同傳輸層協(xié)議所包含的規(guī)則各不相同，因此設(shè)備可以處理各種各樣的數(shù)據(jù)要求。有些協(xié)議，例如UDP（用戶數(shù)據(jù)報協(xié)議），只提供在相應(yīng)的應(yīng)用程序之間高效傳送數(shù)據(jù)片段所需的一些基本功能。這類協(xié)議適用于那些對數(shù)據(jù)延遲極敏感的應(yīng)用程序。其他傳輸層協(xié)議，例如TCP（傳輸控制協(xié)議）描述的進(jìn)程提供了一些附加功能確保應(yīng)用程序之間可靠傳輸。雖然這些附加功能可以在傳輸層上提供更為

9、健全的應(yīng)用程序間數(shù)據(jù)通信，但同時也產(chǎn)生了額外的開銷并增加了對網(wǎng)絡(luò)的要求。為了識別每段數(shù)據(jù)，傳輸層向每個數(shù)據(jù)段添加包含二進(jìn)制數(shù)據(jù)的報頭。報頭含有一些比特字段。不同的傳輸層協(xié)議通過這些字段值執(zhí)行各自的功能。支持可靠通信通過前面的學(xué)習(xí)，我們了解到傳輸層的主要功能就是管理主機(jī)會話過程中的應(yīng)用程序數(shù)據(jù)。但由于不同的應(yīng)用程序?qū)?shù)據(jù)有不同的要求，因此需要開發(fā)不同的傳輸層協(xié)議來滿足這些要求。TCP是網(wǎng)絡(luò)層協(xié)議，它能確保數(shù)據(jù)的可靠傳輸。在網(wǎng)絡(luò)術(shù)語中，可靠性指從源設(shè)備發(fā)送的每段數(shù)據(jù)都能夠到達(dá)目的設(shè)備。在傳輸層中，有三項(xiàng)基本的可靠性操作：跟蹤已發(fā)送的數(shù)據(jù)；確認(rèn)已接收的數(shù)據(jù)；重新傳輸未確認(rèn)的數(shù)據(jù)。這就要求源主機(jī)的傳輸

10、層進(jìn)程持續(xù)跟蹤每個會話過程中的所有數(shù)據(jù)片段，并重新傳輸未被目的主機(jī)確認(rèn)的數(shù)據(jù)。為了支持這種可靠性操作，需要在收發(fā)主機(jī)之間交換更多的控制數(shù)據(jù)?？刂茢?shù)據(jù)位于傳輸層（第4層）的報頭中。這樣，可靠性和網(wǎng)絡(luò)負(fù)載之間就達(dá)成了平衡。應(yīng)用程序開發(fā)人員必須根據(jù)他們應(yīng)用程序的需求，選擇適合的傳輸層協(xié)議類型，如圖4-5所示。在傳輸層中，既有規(guī)定可靠保證傳輸?shù)膮f(xié)議，也有規(guī)定盡力傳輸?shù)膮f(xié)議。在網(wǎng)絡(luò)環(huán)境中，盡力傳輸被稱為不可靠傳輸，因?yàn)樗狈δ康脑O(shè)備對所收到數(shù)據(jù)的確認(rèn)機(jī)制。 圖4-5  傳輸層協(xié)議像數(shù)據(jù)庫、Web網(wǎng)頁及電子郵件等應(yīng)用程序都要求發(fā)送的數(shù)據(jù)以原始狀態(tài)到達(dá)目的設(shè)備，這樣才能夠?yàn)槟康某绦蛩褂?/p>

11、。任何數(shù)據(jù)的丟失都可能導(dǎo)致通信失敗，要么不能完成通信，要么通信的信息不可讀。因此，這些應(yīng)用程序都設(shè)計(jì)成使用能滿足可靠性要求的傳輸層協(xié)議，同時也會考慮這些程序所需的額外網(wǎng)絡(luò)開銷。其他應(yīng)用程序允許丟失少量的數(shù)據(jù)。例如，如果視頻數(shù)據(jù)流中的一段或者兩段數(shù)據(jù)未到達(dá)目的地，就只會造成數(shù)據(jù)流的短暫中斷。這可能表現(xiàn)為圖像失真，用戶也許不會察覺。對于這種應(yīng)用程序而言，增加開銷一方面確保了應(yīng)用程序的可靠性，但另一方面卻降低了應(yīng)用程序的實(shí)用性。如果視頻流目的設(shè)備必須獲得完整的數(shù)據(jù)，則等待丟失數(shù)據(jù)所導(dǎo)致的延遲將使圖像質(zhì)量嚴(yán)重下降。最好采用當(dāng)時收到的數(shù)據(jù)段來盡可能提供好的圖像質(zhì)量，而忽略可靠性。如果出于某種原因而需要確

12、?？煽啃詴r，可以通過應(yīng)用程序自身來提供檢查錯誤和請求重新發(fā)送機(jī)制。TCP和UDPTCP/IP協(xié)議族中最常用的兩種傳輸協(xié)議是傳輸控制協(xié)議（TCP）和用戶數(shù)據(jù)報協(xié)議（UDP）。這兩種協(xié)議都用于管理多個應(yīng)用程序的通信，其不同點(diǎn)在于每個協(xié)議執(zhí)行各自特定的功能。一、用戶數(shù)據(jù)報協(xié)議（UDP）根據(jù)RFC 768，UDP是一種簡單的無連接協(xié)議。該協(xié)議的優(yōu)點(diǎn)在于提供低開銷數(shù)據(jù)傳輸。UDP中的通信數(shù)據(jù)段稱為數(shù)據(jù)報。UDP采用"盡力"方式傳送數(shù)據(jù)報。使用UDP協(xié)議的應(yīng)用包括：域名系統(tǒng)（DNS）；視頻流；IP語音（VoIP）。圖4-6是UDP數(shù)據(jù)報的一個例子。 圖4-6  UD

13、P數(shù)據(jù)報二、傳輸控制協(xié)議（TCP）根據(jù)RFC 793，TCP是一種面向連接的協(xié)議。為實(shí)現(xiàn)額外的功能，TCP協(xié)議會產(chǎn)生額外的開銷。TCP協(xié)議描述的其他功能包括原序處理、可靠傳輸以及流量控制。每個TCP數(shù)據(jù)段在封裝應(yīng)用層數(shù)據(jù)的報頭中都有20字節(jié)的開銷，而每個UDP數(shù)據(jù)段只需要8字節(jié)的開銷。圖4-7顯示了TCP數(shù)據(jù)報。 圖4-7  TCP數(shù)據(jù)報使用TCP協(xié)議的應(yīng)用程序包括：Web瀏覽器；電子郵件；文件傳輸程序。端口尋址我們?nèi)耘e前面說過的一個例子來說明。假設(shè)一臺計(jì)算機(jī)在同時收發(fā)電子郵件和即時消息、瀏覽Web網(wǎng)頁并進(jìn)行VoIP電話呼叫。支持TCP和UDP協(xié)議的服務(wù)將對正在通信的不同應(yīng)

14、用程序進(jìn)行跟蹤。為了區(qū)分每個應(yīng)用程序的數(shù)據(jù)段和數(shù)據(jù)報，TCP和UDP協(xié)議中都有標(biāo)志應(yīng)用程序的唯一報頭字段。一、識別會話數(shù)據(jù)段或者數(shù)據(jù)報的報頭包含一個源端口和目的端口。源端口號是與本地主機(jī)上始發(fā)應(yīng)用程序相關(guān)聯(lián)的通信端口號；而目的端口號則是與遠(yuǎn)程主機(jī)上目的應(yīng)用程序相關(guān)聯(lián)的通信端口號。根據(jù)消息性質(zhì)的不同（請求或響應(yīng)），可以采用不同的方法分配端口號。服務(wù)器的進(jìn)程有靜態(tài)分配的端口號，而客戶端則為每個會話動態(tài)選擇端口號。當(dāng)客戶端應(yīng)用程序向服務(wù)器應(yīng)用程序發(fā)送請求時，包含在報頭中的目的端口號即為分配給遠(yuǎn)程主機(jī)上運(yùn)行的服務(wù)守護(hù)程序的端口號?？蛻舳塑浖仨氁琅c遠(yuǎn)程主機(jī)上的該服務(wù)器進(jìn)程相關(guān)聯(lián)的端口號。該目的端口

15、號通過手動或者默認(rèn)方式配置。例如，當(dāng)Web瀏覽器程序向Web服務(wù)器發(fā)出請求時，除非另行指定，否則瀏覽器程序都將使用TCP端口80。TCP端口80是Web服務(wù)應(yīng)用程序默認(rèn)分配的端口號。很多常見應(yīng)用程序都有其默認(rèn)的端口號?？蛻舳苏埱笮畔r，數(shù)據(jù)段或數(shù)據(jù)報的報頭包含隨機(jī)生成的源端口號。只要不與系統(tǒng)中正在使用的其他端口沖突，客戶端可以選擇任意端口號。對于請求數(shù)據(jù)的應(yīng)用程序而言，該端口號就像是一個返回地址。傳輸層將跟蹤此端口和發(fā)出該請求的應(yīng)用程序，當(dāng)返回響應(yīng)時，傳輸層可以將其轉(zhuǎn)發(fā)到正確的應(yīng)用程序。在從服務(wù)器返回響應(yīng)信息時，請求應(yīng)用程序的端口號用作目的端口號。通過傳輸層端口號和網(wǎng)絡(luò)層分配給主機(jī)的IP地址，

16、我們可以唯一識別在特定主機(jī)上運(yùn)行的特定進(jìn)程。這種組合稱為套接字。有時，"端口號"和"套接字"兩個詞可以互相替換使用。在本書中，套接字僅指IP地址和端口號的獨(dú)特組合。包含源IP地址和目的IP地址以及端口號的套接字對可以唯一識別兩臺主機(jī)之間的會話。如圖4-8所示，這些唯一的識別是端口號，進(jìn)程通過使用端口號識別不同的會話。 圖4-8  識別會話二、端口尋址類型與工具Internet編號指派機(jī)構(gòu)（IANA）負(fù)責(zé)分配端口號。IANA是一個負(fù)責(zé)分配多種地址的標(biāo)準(zhǔn)化團(tuán)體。端口號有如下不同類型：公認(rèn)端口（端口0到1023）；已注冊端口（端口1024到

17、49151）；動態(tài)或私有端口（端口49152到65535）。下面的小節(jié)將討論這三種類型的端口號，并且解釋什么時候TCP/IP和UDP使用相同的端口號。你也可以了解netstat網(wǎng)絡(luò)工具。三、知名端口公認(rèn)端口（端口0到1023）用于服務(wù)和應(yīng)用程序。HTTP（Web服務(wù)器）、POP3/SMTP（電子郵件服務(wù)器）以及Telnet等常用應(yīng)用程序通常使用這些端口號。通過為服務(wù)器應(yīng)用程序定義公認(rèn)端口，可以將客戶端應(yīng)用程序設(shè)定為請求特定端口及其相關(guān)服務(wù)的連接。表4-1列出TCP和UDP的一些知名端口號。知名端口應(yīng) 用 程 序協(xié) 議20文件傳輸協(xié)議（FTP）數(shù)據(jù)TCP21文件傳輸協(xié)議（FTP）控制TCP23T

18、elnetTCP續(xù)表知名端口應(yīng) 用 程 序協(xié) 議25簡單郵件傳輸協(xié)議（SMTP）TCP69簡單文件傳輸協(xié)議（TFTP）UDP80超文本傳輸協(xié)議（HTTP）TCP110郵局協(xié)議3（POP 3）TCP194Internet在線聊天（IRC）TCP443安全的HTTP（HTTPS）TCP520路由信息協(xié)議（RIP）UDP四、注冊端口已注冊端口（端口1024到49151）分配給用戶進(jìn)程或應(yīng)用程序。這些進(jìn)程主要是用戶選擇安裝的一些應(yīng)用程序，而不是已經(jīng)分配了公認(rèn)端口的常用應(yīng)用程序。這些端口在沒有被服務(wù)器資源占用時，可由客戶端動態(tài)選用為源端口。表4-2列出了TCP和UDP使用的注冊端口號。注冊端口應(yīng) 用 程

19、 序協(xié) 議1812RADIUS身份驗(yàn)證UDP1863MSN Messenger TCP2000思科信令連接控制協(xié)議（SCCP，用在VoIP語音程序）UDP5004實(shí)時傳輸協(xié)議（RTP，語音與視頻傳輸協(xié)議）UDP5060話路啟動協(xié)議（SIP，用于VoIP應(yīng)用程序）UDP8008HTTP備用TCP8080HTTP備用TCP五、動態(tài)或私有端口動態(tài)或私有端口（端口49152到65535），也稱為臨時端口。這些端口往往在開始連接時被動態(tài)分配給客戶端應(yīng)用程序?？蛻舳艘话愫苌偈褂脛討B(tài)或私有端口連接服務(wù)（只有一些點(diǎn)對點(diǎn)文件共享程序使用）。六、同時使用TCP和UDP一些應(yīng)用程序可能既使用TCP，又使用UDP。例

20、如，通過低開銷的UDP，DNS可以很快響應(yīng)很多客戶端的請求。但有的時候，發(fā)送被請求的信息時需要滿足TCP可靠性要求。在這種情況下，該程序內(nèi)的兩種協(xié)議將同時采用公認(rèn)端口號53。表4-3列出了TCP和UDP常用的注冊和知名端口號。常用端口應(yīng) 用 程 序端 口 類 型53DNS公認(rèn)TCP/UDP 常用端口161簡單網(wǎng)絡(luò)管理協(xié)議SNMP 公認(rèn)TCP/UDP常用端口531AOL即時通信，IRC公認(rèn)TCP/UDP常用端口續(xù)表常用端口應(yīng) 用 程 序端 口 類 型144MS SQL已注冊TCP/UDP常用端口2948WAP（MMS）已注冊TCP/UDP常用端口七、netstat命令有些時候，需要了解聯(lián)網(wǎng)主機(jī)中

21、開放并運(yùn)行了哪些活動的TCP連接。netstat是一種重要的網(wǎng)絡(luò)實(shí)用程序，可用來檢驗(yàn)此類連接。netstat可列出正在使用的協(xié)議、本地地址和端口號、外部地址和端口號以及連接的狀態(tài)。不明的TCP連接可能表示某程序或某人正連接到本地主機(jī)，這可能是一個重大的安全威脅。此外，不必要的TCP連接會消耗寶貴的系統(tǒng)資源，降低主機(jī)性能。當(dāng)性能出現(xiàn)下降時，就應(yīng)該使用netstat命令檢查主機(jī)上開放的連接。netstat命令有許多有用的選項(xiàng)。例4-1顯示了netstat的輸出。例4-1  netstat的輸出 分段和重組：分治法第2章"網(wǎng)絡(luò)通信"，解釋了如何通過不同的協(xié)議從

22、應(yīng)用程序發(fā)送數(shù)據(jù)，創(chuàng)建PDU并通過介質(zhì)將其傳輸出去。在應(yīng)用層，數(shù)據(jù)向下傳遞并且分段成片段。一個UDP的分段（片段）稱為數(shù)據(jù)報。一個TCP的分段（片段）稱為分段。一個UDP的報頭提供提供源和目的（端口）。一個TCP的報頭提供提供源和目的（端口）、順序、確認(rèn)和流控。在目的主機(jī)上，該進(jìn)程以逆序的方式執(zhí)行，直到數(shù)據(jù)傳送到正確的應(yīng)用程序。圖4-9提供了一個例子。一些應(yīng)用程序中需要傳輸大量的數(shù)據(jù)，有時能達(dá)到很多吉字節(jié)（GB）。因此，將所有數(shù)據(jù)放在一個大數(shù)據(jù)片段中發(fā)送并不現(xiàn)實(shí)。發(fā)送大段數(shù)據(jù)少則需要幾分鐘，多則需要數(shù)個小時，同一時間內(nèi)網(wǎng)絡(luò)將不能傳輸其他任何通信。此外，傳輸過程中一旦發(fā)生錯誤，整個數(shù)據(jù)文件都將丟

23、失或需要重傳。而在數(shù)據(jù)傳輸或接收過程中，網(wǎng)絡(luò)設(shè)備中也沒有足夠的內(nèi)存緩沖區(qū)來存儲如此大量的數(shù)據(jù)。當(dāng)然，這種局限性與網(wǎng)絡(luò)技術(shù)和所使用的特定物理介質(zhì)有關(guān)。如果將應(yīng)用程序數(shù)據(jù)分割成若干段，既可以保證所傳輸數(shù)據(jù)的大小符合傳輸介質(zhì)的限制要求，也可以確保不同應(yīng)用程序發(fā)出的數(shù)據(jù)能在介質(zhì)中多路傳輸。TCP和UDP處理數(shù)據(jù)段的方式不同。在TCP中，每個數(shù)據(jù)段報頭中都包含一個序列號。該序列號允許傳輸層在目的主機(jī)上按原次序重組數(shù)據(jù)段。這樣就確保目的應(yīng)用程序收到的數(shù)據(jù)與發(fā)送設(shè)備發(fā)送的數(shù)據(jù)完全相同。盡管使用UDP的服務(wù)也跟蹤應(yīng)用程序間的會話，但它們并不關(guān)注信息傳輸?shù)拇涡?，也不維護(hù)連接。與TCP相比，UDP是一種簡單設(shè)計(jì)，

24、所需開銷較低，因此數(shù)據(jù)傳輸速度較快。 圖4-9  傳輸層功能由于不同數(shù)據(jù)包是經(jīng)由不同的網(wǎng)絡(luò)路徑傳輸?shù)?，因此信息到達(dá)的次序可能不同。采用UDP協(xié)議的應(yīng)用程序必須接受數(shù)據(jù)到達(dá)的順序和發(fā)送的次序不同這一后果。TCP：可靠通信TCP協(xié)議通常被稱為面向連接的協(xié)議，這一協(xié)議保證可靠有序地將數(shù)據(jù)從發(fā)送者傳送到接收者。在下面的小節(jié)中，你將研究這是如何管理的。討論使用三次握手來建立和終止連接。流控，使用窗口做擁塞控制，并且實(shí)現(xiàn)數(shù)據(jù)重傳。創(chuàng)建可靠會話TCP與UDP的關(guān)鍵區(qū)別在于可靠性。TCP通信的可靠性在于使用了面向連接的會話。主機(jī)使用TCP協(xié)議發(fā)送數(shù)據(jù)到另一主機(jī)前，傳輸層會啟動一個進(jìn)程，用于

25、創(chuàng)建與目的主機(jī)之間的連接。通過該連接，可以跟蹤主機(jī)之間的會話或者通信數(shù)據(jù)流。同時，該進(jìn)程還確保每臺主機(jī)都知道并做好了通信準(zhǔn)備。完整的TCP會話要求在主機(jī)之間創(chuàng)建雙向會話。會話創(chuàng)建后，目的主機(jī)針對收到的數(shù)據(jù)段向源主機(jī)發(fā)送確認(rèn)信息。在TCP會話中，這些確認(rèn)信息構(gòu)成了可靠性的基礎(chǔ)。源主機(jī)收到確認(rèn)信息時，即表明數(shù)據(jù)成功發(fā)送，且可以退出數(shù)據(jù)跟蹤。如果源主機(jī)未在規(guī)定時間內(nèi)收到確認(rèn)信息，它將向目的主機(jī)重新發(fā)送數(shù)據(jù)。使用TCP協(xié)議的額外系統(tǒng)開銷部分源自確認(rèn)信息和重新發(fā)送信息所產(chǎn)生的網(wǎng)絡(luò)流量。建立會話產(chǎn)生的其他數(shù)據(jù)段交換也構(gòu)成系統(tǒng)開銷。此外，主機(jī)在跟蹤待確認(rèn)的數(shù)據(jù)和重新發(fā)送過程中也會產(chǎn)生額外開銷。TCP通過數(shù)據(jù)

26、段中各自具備特定功能的一些字段來滿足可靠性要求。TCP服務(wù)器進(jìn)程如在第3章"應(yīng)用層的功能與協(xié)議"中所討論的，應(yīng)用程序進(jìn)程在服務(wù)器上運(yùn)行。這些進(jìn)程需要一直等待，直到客戶端發(fā)出信息請求或者服務(wù)請求啟動通信。服務(wù)器上運(yùn)行的每個應(yīng)用程序進(jìn)程都配置有一個端口號，由系統(tǒng)默認(rèn)分配或者系統(tǒng)管理員手動分配。在同一傳輸層服務(wù)中，服務(wù)器不能同時存在具有相同端口號的兩個不同服務(wù)。主機(jī)同時運(yùn)行Web服務(wù)器應(yīng)用程序和文件傳輸應(yīng)用程序時，也不能為兩個應(yīng)程序配置相同的端口（如TCP端口8080）。當(dāng)某個動態(tài)服務(wù)器應(yīng)用程序分配到特定端口時，該端口在服務(wù)器上視為"開啟"，這表明應(yīng)用層將接受

27、并處理分配到該端口的數(shù)據(jù)段。所有發(fā)送到正確套接字地址的傳入客戶端請求都將被接受，數(shù)據(jù)將被傳送到服務(wù)器應(yīng)用程序。在同一服務(wù)器上可以同時開啟很多端口，每個端口對應(yīng)一個動態(tài)服務(wù)器應(yīng)用程序。對于服務(wù)器而言，同時開啟多個服務(wù)（如Web服務(wù)器和FTP服務(wù)器）的情況很常見。提高服務(wù)器安全性的一個辦法是限制服務(wù)器訪問，只允許授權(quán)請求者訪問與服務(wù)和應(yīng)用程序相關(guān)的端口。圖4-10中描述了TCP客戶端/服務(wù)器運(yùn)作模式中源端口和目的端口的典型配置。 圖4-10  客戶端發(fā)送TCP請求TCP連接的建立和終止當(dāng)兩臺主機(jī)采用TCP進(jìn)行通信時，在交換數(shù)據(jù)前將建立連接。通信完成后，將關(guān)閉會話并終止連接。連接

28、和會話機(jī)制保障了TCP的可靠性功能。三次握手主機(jī)將跟蹤會話過程中的每個數(shù)據(jù)段，并使用TCP報頭中的信息了解每臺主機(jī)所接收到的數(shù)據(jù)。每個連接都代表兩股單向通信數(shù)據(jù)流或者會話。若要建立連接，主機(jī)應(yīng)執(zhí)行"三次握手"。TCP報頭中的控制位指出了連接的進(jìn)度和狀態(tài)。"三次握手"執(zhí)行如下功能： 確認(rèn)目的設(shè)備存在于網(wǎng)絡(luò)上；確認(rèn)目的設(shè)備有活動的服務(wù)，并且正在源客戶端要使用的目的端口號上接受請求；通知目的設(shè)備源客戶端想要在該端口號上建立通信會話。在TCP連接中，充當(dāng)客戶端的主機(jī)將向服務(wù)器發(fā)起該會話。TCP連接創(chuàng)建的過程分為以下三個步驟。1客戶端向服務(wù)器發(fā)送包含初始序列值的數(shù)

29、據(jù)段，開啟通信會話。2服務(wù)器發(fā)送包含確認(rèn)值的數(shù)據(jù)段，其值等于收到的序列值加1，并加上其自身的同步序列值。該值比序列號大1，因?yàn)锳CK總是下一個預(yù)期字節(jié)或二進(jìn)制八位數(shù)。通過此確認(rèn)值，客戶端可以將響應(yīng)和上一次發(fā)送到服務(wù)器的數(shù)據(jù)段連接起來。3發(fā)送帶確認(rèn)值的客戶端響應(yīng)，其值等于接受的序列值加1。這便完成了整個建立連接的過程。圖4-11顯示了建立一個TCP連接的步驟。 圖4-11  TCP連接的建立：SYN ACK為了理解"三次握手"的過程，必須考察兩臺主機(jī)間交換的不同值。在TCP數(shù)據(jù)段報頭中，有6個包含控制信息的1比特字段，用于管理TCP進(jìn)程。這些字段分別是：U

30、RG-緊急指針；ACK-確認(rèn)字段；PSH-推送功能；RST-重置連接；SYN-同步序列號；FIN-發(fā)送方已傳輸完所有數(shù)據(jù)。這些字段用作標(biāo)志，由于它們都只有1比特大小，所以它們都只有兩個值：1或者0。當(dāng)值設(shè)為1時，表示數(shù)據(jù)段中包含控制信息。下一部分描述"三次握手"每一步的細(xì)節(jié)。一、步驟1：SYNTCP客戶端發(fā)送帶SYN（同步序列號）控制標(biāo)志設(shè)置的數(shù)據(jù)段，指示包含在報頭中的序列號字段的初始值，用以開啟"三次握手"。序列號的初始值稱為初始序列號（ISN），由系統(tǒng)隨機(jī)選取，并用于跟蹤會話過程中從客戶端到服務(wù)器的數(shù)據(jù)流。在會話過程中，每從客戶端向服務(wù)器發(fā)送一個字節(jié)

31、的數(shù)據(jù)，數(shù)據(jù)段報頭中包含的ISN值就要加1。SYN控制標(biāo)志被置位并且相應(yīng)的序列號設(shè)定為0。二、步驟2：SYN和ACKTCP服務(wù)器需要確認(rèn)從客戶端處收到SYN數(shù)據(jù)段，從而建立從客戶端到服務(wù)器的會話。為了達(dá)到此目的，服務(wù)器應(yīng)向客戶端發(fā)送帶ACK標(biāo)志設(shè)置的數(shù)據(jù)段，表明確認(rèn)編號有效?？蛻舳藢⑦@種帶確認(rèn)標(biāo)志設(shè)置的數(shù)據(jù)段理解為確認(rèn)信息，即服務(wù)器已收到從TCP客戶端發(fā)出的SYN信息。確認(rèn) 編號字段的值等于客戶端初始序列號加1。此時創(chuàng)建從客戶端到服務(wù)器的會話。ACK標(biāo)志將在會話期間保持平衡設(shè)置。客戶端和服務(wù)器之間的會話實(shí)際上是由兩個單向的會話組成的：一個是從客戶端到服務(wù)器的會話，另一個則正好相反。在"

32、;三次握手"過程的第二步中，服務(wù)器必須發(fā)起從服務(wù)器到客戶端的響應(yīng)。為開啟會話，服務(wù)器應(yīng)采用與客戶端同樣的方法使用SYN標(biāo)志。該操作設(shè)置報頭中的SYN控制標(biāo)志，從而建立從服務(wù)器到客戶端的會話。SYN標(biāo)志表明序列號字段的初始值已包含在報頭中，且該值將用于跟蹤會話過程中從服務(wù)器返回客戶端的數(shù)據(jù)流。三、步驟3：ACK最后，TCP客戶端發(fā)送包含ACK信息的數(shù)據(jù)段，以示對服務(wù)器發(fā)送的TCP SYN信息的響應(yīng)。在該數(shù)據(jù)段中，不包括用戶數(shù)據(jù)。確認(rèn)號字段的值比從服務(wù)器接收的初始序列號值大1。一旦在客戶端和服務(wù)器之間建立了雙向會話，該通信過程中交換的所有數(shù)據(jù)段都將包含ACK標(biāo)志設(shè)置。通過以下方式，你可以

33、加強(qiáng)數(shù)據(jù)網(wǎng)絡(luò)的安全性：拒絕建立TCP會話；只允許建立特定服務(wù)的會話；只允許已建立會話之間的通信。你可以將安全策略應(yīng)用于所有TCP會話，也可以僅應(yīng)用于某些選定的會話。TCP會話終止若要關(guān)閉連接，應(yīng)設(shè)置數(shù)據(jù)段報頭中的FIN（結(jié)束）控制標(biāo)志。為終止每個單向TCP會話，需采用包含F(xiàn)IN數(shù)據(jù)段和ACK數(shù)據(jù)段的二次握手。因此，若要終止TCP支持的整個會話過程，需要實(shí)施4次交換，以終止兩個雙向會話：1當(dāng)客戶端的數(shù)據(jù)流中沒有其他要發(fā)送的數(shù)據(jù)時，它將發(fā)送帶FIN標(biāo)志設(shè)置的數(shù)據(jù)段；2服務(wù)器發(fā)送ACK信息，確認(rèn)收到從客戶端發(fā)出的請求終止會話的FIN信息；3服務(wù)器向客戶端發(fā)送FIN信息，終止從服務(wù)器到客戶端的會話；4

34、客戶端發(fā)送ACK響應(yīng)信息，確認(rèn)收到從服務(wù)器發(fā)出的FIN信息。圖4-12顯示了終止一個TCP連接所使用的步驟。 注  意 在本部分中，為了更容易理解，采用了客戶端和服務(wù)器端進(jìn)行說明。實(shí)際上，終止的過程可以在任意兩臺完成會話的主機(jī)之間展開。當(dāng)會話中的客戶端沒有其他要傳輸?shù)臄?shù)據(jù)時，它將在數(shù)據(jù)段報頭中設(shè)置FIN標(biāo)志。然后，會話中的服務(wù)器端將發(fā)送包含ACK標(biāo)志設(shè)置的一般數(shù)據(jù)段信息，通過確認(rèn)號確認(rèn)已經(jīng)收到所有數(shù)據(jù)。當(dāng)所有數(shù)據(jù)段得到確認(rèn)后，會話關(guān)閉。另一方向的會話采用相同的方式關(guān)閉。接收方在數(shù)據(jù)段的報頭中設(shè)置FIN標(biāo)志，然后發(fā)送到發(fā)送方，表明沒有其他需要發(fā)送的數(shù)據(jù)。返回的確認(rèn)信

35、息確定已接收所有數(shù)據(jù)，隨即該方向的會話關(guān)閉。也可以通過"三次握手"方式關(guān)閉連接。當(dāng)客戶端沒有其他要傳輸?shù)臄?shù)據(jù)時，它將向服務(wù)器發(fā)送FIN信息。如果服務(wù)器也沒有其他要傳輸?shù)臄?shù)據(jù)，它將發(fā)送同時包含F(xiàn)IN和ACK標(biāo)志設(shè)置的響應(yīng)信息，將兩步并作一步。最后，客戶端返回ACK信息。TCP窗口確認(rèn)TCP的一項(xiàng)功能是確保每個數(shù)據(jù)段都能到達(dá)目的地。位于目的主機(jī)的TCP服務(wù)對接收到的數(shù)據(jù)進(jìn)行確認(rèn)，并向源應(yīng)用程序發(fā)送確認(rèn)信息。使用數(shù)據(jù)段報頭序列號以及確認(rèn)號來確認(rèn)已收到包含在數(shù)據(jù)段中的相關(guān)的數(shù)據(jù)字節(jié)。這個序列號表明在這個會話中被傳送的已經(jīng)接收到的字節(jié)數(shù)和當(dāng)前分段中包含的字節(jié)。TCP在發(fā)回源設(shè)備的數(shù)據(jù)

36、段中使用確認(rèn)號，指示接收設(shè)備期待接收的下一字節(jié)。該過程稱為期待確認(rèn)。收到確認(rèn)信息后，源設(shè)備即得知目的設(shè)備已收到數(shù)據(jù)流中確認(rèn)號之前的所有字節(jié)，但不包括確認(rèn)號所指示的字節(jié)。隨后，源主機(jī)將繼續(xù)發(fā)送數(shù)據(jù)段，且數(shù)據(jù)段的序列號應(yīng)等于該確認(rèn)號。請記住，每個連接都實(shí)際包含兩個單向會話，且兩個方向上都在進(jìn)行序列號和確認(rèn)號的交換。在圖4-13中，左側(cè)主機(jī)正在向右側(cè)主機(jī)發(fā)送數(shù)據(jù)。它發(fā)送的數(shù)據(jù)段包含10字節(jié)的會話數(shù)據(jù)，數(shù)據(jù)段報頭中的序列號等于1。 圖4-13  TCP數(shù)據(jù)段的確認(rèn) 主機(jī)B在網(wǎng)絡(luò)層接收數(shù)據(jù)段，并確認(rèn)其序列號為1，且數(shù)據(jù)字節(jié)數(shù)為10。主機(jī)B隨即向主機(jī)A發(fā)送數(shù)據(jù)段，確認(rèn)收到數(shù)據(jù)。在確認(rèn)數(shù)

37、據(jù)段中，該主機(jī)將確認(rèn)號設(shè)為11，表明它期望下一接收數(shù)據(jù)的字節(jié)數(shù)為11。當(dāng)主機(jī)A接收到該確認(rèn)信息時，它可以立即發(fā)送字節(jié)編號為11的下一會話數(shù)據(jù)段。在本例中，如果主機(jī)A需要等待每個10字節(jié)數(shù)據(jù)段的確認(rèn)信息，網(wǎng)絡(luò)將負(fù)擔(dān)很多額外開銷。為減少這些確認(rèn)信息的開銷，可以預(yù)先發(fā)送多個數(shù)據(jù)段，并在相反方向上采用單一TCP消息進(jìn)行確認(rèn)。這種確認(rèn)消息中包含基于所接收的所有會話字節(jié)的確認(rèn)號。例如當(dāng)序列號從2000起算時，如果已接收到10個1000字節(jié)的數(shù)據(jù)段，則可以向源設(shè)備發(fā)送一條編號為12001的確認(rèn)消息。源主機(jī)在收到確認(rèn)消息之前可以傳輸?shù)臄?shù)據(jù)大小稱為窗口大小。窗口大小是TCP報頭中的一個字段，用于管理丟失數(shù)據(jù)和流

38、量控制。TCP重傳無論網(wǎng)絡(luò)設(shè)計(jì)得如何完美，都可能發(fā)生數(shù)據(jù)丟失現(xiàn)象。因此，TCP提供了管理數(shù)據(jù)段丟失的方法，其中一個方法就是重新發(fā)送未確認(rèn)的數(shù)據(jù)。使用TCP的目的主機(jī)服務(wù)通常只確認(rèn)相鄰序列的數(shù)據(jù)。如果一個或多個數(shù)據(jù)段丟失，只確認(rèn)已完成數(shù)據(jù)流中的數(shù)據(jù)段。例如，如果接收到序列號為1500到3000以及3400到3500的數(shù)據(jù)段，那么確認(rèn)號應(yīng)為3001。這是因?yàn)槲词盏叫蛄刑枮?001到3399之間的數(shù)據(jù)段。如果源主機(jī)上的TCP未在規(guī)定時間內(nèi)收到確認(rèn)消息，它將根據(jù)收到的最后一個確認(rèn)號重新發(fā)送數(shù)據(jù)。RFC793中未對重新發(fā)送過程進(jìn)行說明，這屬于TCP的特殊實(shí)施過程。TCP的標(biāo)準(zhǔn)實(shí)施流程是：主機(jī)傳輸數(shù)據(jù)段，

39、并將數(shù)據(jù)段的副本列入重新發(fā)送隊(duì)列，然后啟動計(jì)時器。當(dāng)接收到數(shù)據(jù)確認(rèn)信息時，主機(jī)將從隊(duì)列中刪除對應(yīng)數(shù)據(jù)段；如果到計(jì)時器超時還沒有收到確認(rèn)信息，將重新傳輸數(shù)據(jù)段?，F(xiàn)在，主機(jī)還擁有一項(xiàng)備選功能：選擇性確認(rèn)。如果兩臺主機(jī)都支持選擇性確認(rèn)功能，目的主機(jī)便可以確認(rèn)間斷數(shù)據(jù)段中的數(shù)據(jù)，那么源主機(jī)就只需要重新傳輸丟失的數(shù)據(jù)。TCP擁塞控制：將可能丟失的數(shù)據(jù)段降到最少TCP通過使用少量控制與動態(tài)窗口大小提供擁塞控制。下面將討論這些技術(shù)如何最小化丟失的數(shù)據(jù)段，以減小因重傳丟失的數(shù)據(jù)段而造成的網(wǎng)絡(luò)負(fù)擔(dān)。一、Flow控制流量控制功能通過調(diào)整會話過程中兩個服務(wù)之間的數(shù)據(jù)流速率，幫助實(shí)現(xiàn)TCP的可靠傳輸。當(dāng)源主機(jī)被告知已

40、收到數(shù)據(jù)段中指定數(shù)量的數(shù)據(jù)時，它就可以繼續(xù)發(fā)送更多的數(shù)據(jù)。TCP報頭中的"窗口大小"字段指出了在收到確認(rèn)信息之前可以傳輸?shù)臄?shù)據(jù)量。初始窗口大小應(yīng)在會話創(chuàng)建階段通過"三次握手"來確定。TCP反饋機(jī)制將根據(jù)網(wǎng)絡(luò)和目的設(shè)備所能支持的最大容量（以不丟失數(shù)據(jù)為前提）將數(shù)據(jù)傳輸速率調(diào)整到最大。通過對傳輸速率的管理，TCP嘗試確保收到全部數(shù)據(jù)且將數(shù)據(jù)重發(fā)率降到最低。請參看圖4-14中對窗口大小和確認(rèn)消息的簡易展示。在本例中，TCP會話的初始窗口大小為3000字節(jié)。此會話的發(fā)送方在傳輸3000字節(jié)后等待這些數(shù)據(jù)的確認(rèn)消息，以便繼續(xù)傳輸更多數(shù)據(jù)段。一旦發(fā)送方收到接收方發(fā)送

41、的確認(rèn)消息，它就可以傳送另外3000字節(jié)的數(shù)據(jù)段。 接收確認(rèn)信息出現(xiàn)延遲時，發(fā)送方將不再發(fā)送任何會話數(shù)據(jù)段。如果網(wǎng)絡(luò)擁堵，或者接收主機(jī)資源緊張，延遲時間可能就更長。延遲時間越長，該會話過程的有效傳輸速率越低，而數(shù)據(jù)傳輸速率的降低有助于緩解資源緊張的狀態(tài)。二、動態(tài)窗口大小我們也可以通過動態(tài)窗口大小來控制數(shù)據(jù)流量。當(dāng)網(wǎng)絡(luò)資源受到限制時，TCP可以減小窗口的大小，這樣，目的主機(jī)就需要更加頻繁地確認(rèn)所接收的數(shù)據(jù)段。由于源主機(jī)需要更加頻繁地等待數(shù)據(jù)確認(rèn)，這便可以大大降低傳輸?shù)乃俾?。TCP目的主機(jī)將窗口大小值發(fā)給源主機(jī)，表明它在該會話過程中準(zhǔn)備接收的字節(jié)數(shù)。如果目的主機(jī)由于緩沖內(nèi)存受限需要降低通

42、信速率，那么它向源主機(jī)發(fā)送的確認(rèn)信息中可以包含一條較小的窗口大小值。如圖4-15所示，如果目的主機(jī)發(fā)生擁堵，它可以向源主機(jī)發(fā)送包含較小窗口大小的數(shù)據(jù)段。圖4-15中顯示，其中一個數(shù)據(jù)段丟失了。目的主機(jī)將返回數(shù)據(jù)段的TCP報頭中的窗口字段值由3000減為1500，即將窗口大小改為1500。 圖4-15  TCP擁塞控制和流量控制如果過了一段時間，在傳輸過程中沒有發(fā)生數(shù)據(jù)丟失或者資源受限，目的主機(jī)將增加窗口大小值。由于此時只需發(fā)送少量的確認(rèn)信息，因此該方式減少了網(wǎng)絡(luò)的開銷。窗口大小將持續(xù)增加，直至有數(shù)據(jù)丟失，然后窗口大小又將隨之減少。TCP中這種增減窗口大小值的動態(tài)運(yùn)動不斷進(jìn)行

43、，直至達(dá)到每個TCP會話的最佳窗口大小。在高效網(wǎng)絡(luò)中，由于不丟失數(shù)據(jù)，窗口大小可能會相當(dāng)大；而在基礎(chǔ)架構(gòu)緊張的網(wǎng)絡(luò)中，窗口大小就會很小。UDP協(xié)議：低開銷通信UDP是一種簡單協(xié)議，提供了基本的傳輸層功能。與TCP相比，UDP的開銷極低，因?yàn)閁DP是無連接的，并且不提供復(fù)雜的重新傳輸、排序和流量控制機(jī)制。UDP：低開銷與可靠性對比由于UDP的開銷極低，不像TCP那樣提供可靠性的功能，當(dāng)你選擇UDP的時候要小心。不過，這并不說明使用UDP的應(yīng)用程序不可靠，而僅僅是說明，作為傳輸層協(xié)議，UDP不提供上述幾項(xiàng)功能，如果需要這些功能，必須通過其他方式來實(shí)現(xiàn)。某些應(yīng)用程序可以容許小部分?jǐn)?shù)據(jù)丟失（如網(wǎng)絡(luò)游戲或VoIP）。如果這些應(yīng)用程序采用TCP，那么將面臨巨大的網(wǎng)絡(luò)延遲，因?yàn)門CP需要不停檢測數(shù)據(jù)是否丟失并重傳丟失的數(shù)據(jù)。與丟失小部分?jǐn)?shù)據(jù)相比，網(wǎng)絡(luò)延遲對這些應(yīng)用程序造成的負(fù)面影響更大。例如像DNS這樣的應(yīng)用，如果收不到回應(yīng)，它就再次發(fā)出請求。因此，它不需要TCP來保證消息的可靠傳輸。正是由于UDP的開銷低，對此類應(yīng)用程序就非常有吸引力。與TCP的通信機(jī)制不同，由于UDP是無連接協(xié)議，因此