第5章傳輸層與進(jìn)程通信5.1網(wǎng)絡(luò)需求與傳輸層功能5.2傳輸控制協(xié)議TCP5.3用戶數(shù)據(jù)報(bào)協(xié)議UDP返回5.1網(wǎng)絡(luò)需求與傳輸層功能５.１.１傳輸層實(shí)現(xiàn)進(jìn)程間的通信從通信的視角看，傳輸層的作用是區(qū)分和標(biāo)識(shí)進(jìn)程，實(shí)現(xiàn)進(jìn)程間的通信。相信讀者都有自己的ＱＱ，可能不止一個(gè)吧?；叵胛覀兪煜さ囊粋€(gè)場(chǎng)景吧，網(wǎng)吧里，一臺(tái)機(jī)器上同時(shí)掛著兩三個(gè)ＱＱ，這個(gè)閃，那個(gè)叫，同時(shí)和多個(gè)號(hào)上的好友聊天。想想，好友回來(lái)的消息有沒(méi)有搞混過(guò)，也就是說(shuō)，ＱＱ１上好友的返回消息在ＱＱ２的好友窗口呈現(xiàn)了。遇到過(guò)嗎？沒(méi)有吧。那么同學(xué)們有沒(méi)有思考過(guò)這個(gè)問(wèn)題：兩個(gè)ＱＱ號(hào)在網(wǎng)上收發(fā)數(shù)據(jù)都是用的一個(gè)ＩＰ地址，對(duì)方回復(fù)回來(lái)的ＩＰ分組都是通過(guò)主機(jī)的網(wǎng)絡(luò)層接收到的，它們都以該主機(jī)的ＩＰ地址作為目標(biāo)地址，主機(jī)是如何區(qū)分這些ＩＰ分組，并將它們正確并有序地分發(fā)到多個(gè)不同的ＱＱ上的呢？下一頁(yè)返回5.1網(wǎng)絡(luò)需求與傳輸層功能或者說(shuō)，我們的機(jī)器上是如何保證同時(shí)運(yùn)行的這兩個(gè)ＱＱ數(shù)據(jù)不會(huì)混淆的。這種情況ＩＰ地址是相同的，我們主機(jī)上的網(wǎng)絡(luò)層是不能區(qū)分的，網(wǎng)絡(luò)層只能區(qū)分到ＩＰ，即區(qū)分到主機(jī)。因此我們說(shuō)，要想實(shí)現(xiàn)應(yīng)用程序間一對(duì)一的通信，單有網(wǎng)絡(luò)層是不夠的，網(wǎng)絡(luò)層只能區(qū)分到主機(jī)。就像郵差，他只負(fù)責(zé)把信件送到單位。從ＩＰ層來(lái)說(shuō)，通信的兩端是兩個(gè)主機(jī)，ＩＰ數(shù)據(jù)報(bào)的頭部明確地標(biāo)識(shí)了這兩個(gè)主機(jī)的ＩＰ地址，ＩＰ層只能識(shí)別到主機(jī)。所以，在這之前，我們一直強(qiáng)調(diào)，網(wǎng)絡(luò)層實(shí)現(xiàn)了主機(jī)間的通信。但從剛才的例子可以看到，“兩個(gè)主機(jī)之間的通信”這種說(shuō)法還不夠準(zhǔn)確。這是因?yàn)?，真正進(jìn)行通信的實(shí)體是主機(jī)中的進(jìn)程，是這個(gè)主機(jī)中的一個(gè)進(jìn)程和另一個(gè)主機(jī)中的一個(gè)進(jìn)程在交換數(shù)據(jù)（即通信）。因此更具體、更準(zhǔn)確地講，主機(jī)間的通信實(shí)質(zhì)上是主機(jī)上的應(yīng)用進(jìn)程間的相互通信。上一頁(yè)下一頁(yè)返回5.1網(wǎng)絡(luò)需求與傳輸層功能進(jìn)程（ｐｒｏｃｅｓｓ）是計(jì)算機(jī)操作系統(tǒng)中的一個(gè)基本概念。進(jìn)程與程序既有聯(lián)系，又有區(qū)別。它是應(yīng)用程序的一次執(zhí)行過(guò)程，是正在運(yùn)行的應(yīng)用程序。ＩＰ協(xié)議雖然能把分組送到目的主機(jī)，但主機(jī)的ＩＰ層只能驗(yàn)證分組中的ＩＰ地址，它并不知道送給主機(jī)上哪個(gè)進(jìn)程。所以，至此從實(shí)現(xiàn)進(jìn)程通信的需求上看還有欠缺。擔(dān)當(dāng)此任的正是傳輸層。網(wǎng)絡(luò)層從收到的ＩＰ數(shù)據(jù)報(bào)中取出數(shù)據(jù)部分交給傳輸層，由傳輸層分發(fā)給相應(yīng)的應(yīng)用進(jìn)程。那么傳輸層又是如何區(qū)分不同進(jìn)程的呢？上一頁(yè)下一頁(yè)返回5.1網(wǎng)絡(luò)需求與傳輸層功能傳輸層要對(duì)主機(jī)收到的數(shù)據(jù)進(jìn)行分發(fā)，就要區(qū)分主機(jī)上的不同進(jìn)程。傳輸層使用協(xié)議端口號(hào)（簡(jiǎn)稱端口，ｐｏｒｔ）來(lái)區(qū)分進(jìn)程。原來(lái)，不同的進(jìn)程在通過(guò)傳輸層進(jìn)行網(wǎng)絡(luò)通信時(shí)，使用不同的接口，傳輸層用端口號(hào)來(lái)標(biāo)識(shí)這個(gè)層間接口。這樣，不同的端口號(hào)就對(duì)應(yīng)著不同的進(jìn)程?；蛘哒f(shuō)，不同的應(yīng)用進(jìn)程通信時(shí)使用不同的端口號(hào)。因此，從傳輸層的角度看，通信的真正端點(diǎn)并不是主機(jī)，而是主機(jī)中的進(jìn)程，進(jìn)程是網(wǎng)絡(luò)通信的起始和終止端點(diǎn)。也就是說(shuō)，端到端的通信是應(yīng)用進(jìn)程之間的通信。在一個(gè)主機(jī)中經(jīng)常有多個(gè)應(yīng)用進(jìn)程同時(shí)分別和另一個(gè)主機(jī)中的多個(gè)應(yīng)用進(jìn)程通信，如圖５－１所示。上一頁(yè)下一頁(yè)返回5.1網(wǎng)絡(luò)需求與傳輸層功能５.１.２傳輸層實(shí)現(xiàn)可靠傳輸從為高層用戶服務(wù)的視角看，傳輸層提供可靠傳輸，提升網(wǎng)絡(luò)的傳輸質(zhì)量。網(wǎng)絡(luò)層雖然提供了從源到目標(biāo)主機(jī)的通信服務(wù)，但是數(shù)據(jù)通信的可靠性卻沒(méi)有保障。其原因是多方面的。首先，在Ｉｎｔｅｒｎｅｔ上的網(wǎng)際層，ＩＰ協(xié)議提供的是無(wú)連接的、“盡力而為”的數(shù)據(jù)報(bào)服務(wù)，是不可靠的。它不保證端到端數(shù)據(jù)傳輸?shù)目煽啃?，ＩＰ分組在傳輸過(guò)程中有眾多的原因會(huì)導(dǎo)致數(shù)據(jù)丟失、亂序或重復(fù)，對(duì)此，ＩＰ協(xié)議沒(méi)有應(yīng)對(duì)措施，它實(shí)現(xiàn)的是簡(jiǎn)單通信。其次，雖然在ＯＳＩ模型中設(shè)計(jì)了數(shù)據(jù)鏈路層的可靠傳輸，但在實(shí)際應(yīng)用中，考慮到效率、成本等因素，大多鏈路層只實(shí)現(xiàn)了簡(jiǎn)單通信，沒(méi)有實(shí)現(xiàn)可靠傳輸。上一頁(yè)下一頁(yè)返回5.1網(wǎng)絡(luò)需求與傳輸層功能這樣物理層、數(shù)據(jù)鏈路層、網(wǎng)際層的錯(cuò)誤就得不到糾正，如果傳輸層也沒(méi)有糾正，錯(cuò)誤會(huì)留到用戶哪里，使得網(wǎng)絡(luò)的可用性降低，尤其是對(duì)可靠性有要求的應(yīng)用。最后，互聯(lián)網(wǎng)上端到端的通信可能會(huì)跨越一系列的通信子網(wǎng)，不同的通信子網(wǎng)使用的技術(shù)不同，數(shù)據(jù)傳輸速率、時(shí)延、錯(cuò)誤率等通信質(zhì)量不同，這也導(dǎo)致整個(gè)端到端的通信質(zhì)量沒(méi)有保障。當(dāng)然，大量的、突發(fā)性的數(shù)據(jù)發(fā)送也容易造成網(wǎng)絡(luò)擁塞，導(dǎo)致數(shù)據(jù)丟失、時(shí)延增大。這些都是網(wǎng)絡(luò)傳輸?shù)牟豢煽?、不確定因素，使通信子網(wǎng)的服務(wù)質(zhì)量沒(méi)有保障。鑒于高層的一些應(yīng)用對(duì)可靠性的要求，傳輸層的ＴＣＰ協(xié)議提供了可靠傳輸機(jī)制。可靠傳輸?shù)募夹g(shù)原理如第３章所述，主要是在面向連接的傳輸中使用確認(rèn)、重傳、流量控制等傳輸機(jī)制，以保證數(shù)據(jù)的無(wú)錯(cuò)、無(wú)丟失、無(wú)重復(fù)、有序。上一頁(yè)下一頁(yè)返回5.1網(wǎng)絡(luò)需求與傳輸層功能５.１.３傳輸層實(shí)現(xiàn)用戶接口由上可見(jiàn)，傳輸層的作用很像現(xiàn)實(shí)中公司、單位里的秘書(shū)。對(duì)來(lái)往的信件、物資負(fù)責(zé)分發(fā)；對(duì)物流托運(yùn)中變質(zhì)、丟失的物資負(fù)責(zé)檢驗(yàn)、追討。在完成這兩項(xiàng)任務(wù)的同時(shí)，秘書(shū)的存在還使得高層主管更加省心、放心。同樣，在計(jì)算機(jī)網(wǎng)絡(luò)中，如果高層用戶直接使用網(wǎng)絡(luò)層傳輸數(shù)據(jù)會(huì)涉及通信子網(wǎng)細(xì)節(jié)，不易操作。處在高層用戶和網(wǎng)絡(luò)層之間的傳輸層，可以屏蔽通信子網(wǎng)的細(xì)節(jié)，作為用戶和網(wǎng)絡(luò)的接口，用戶通過(guò)傳輸層使用網(wǎng)絡(luò)比直接使用網(wǎng)絡(luò)層會(huì)容易得多、方便得多。上一頁(yè)下一頁(yè)返回5.1網(wǎng)絡(luò)需求與傳輸層功能正是有了傳輸層，應(yīng)用程序員才可以按照一組標(biāo)準(zhǔn)的原語(yǔ)來(lái)編寫(xiě)代碼，并且程序可以運(yùn)行在各種各樣的底層網(wǎng)絡(luò)上；他們根本無(wú)須處理不同的網(wǎng)絡(luò)接口，也不用擔(dān)心傳輸?shù)目煽啃?。如果所有?shí)際的網(wǎng)絡(luò)都完美無(wú)缺，具有相同的服務(wù)原語(yǔ)，并保證不會(huì)發(fā)生變化，那么傳輸層或許就不再需要。然而，現(xiàn)實(shí)世界中并不是，傳輸層承擔(dān)了把上層與技術(shù)、設(shè)計(jì)和各種缺陷隔離的關(guān)鍵作用。綜上可見(jiàn)，傳輸層在高層用戶和通信子網(wǎng)之間承上啟下，有多方面的功能。上一頁(yè)下一頁(yè)返回5.1網(wǎng)絡(luò)需求與傳輸層功能從通信的角度看，傳輸層使用端口機(jī)制區(qū)分進(jìn)程，向上提供進(jìn)程間端到端的通信，它屬于面向通信部分的最高層。從用戶的角度看，傳輸層面向高層用戶服務(wù)，為高層用戶提供接口和通信質(zhì)量的升值服務(wù)，是用戶功能中的最低層，是資源子網(wǎng)中的最低層，如圖５－２所示。正像秘書(shū)工作在單位里。傳輸層存在于主機(jī)里，通信子網(wǎng)中是不存在的，比如路由器上只有網(wǎng)絡(luò)層以下的層次。因此，傳輸層是直接在發(fā)送端和接收端起作用，從協(xié)議棧上看它跨越中間轉(zhuǎn)發(fā)結(jié)點(diǎn)（如路由器）提供端到端的通信，如圖５－１所示。也就是說(shuō)，網(wǎng)絡(luò)體系結(jié)構(gòu)中的底３層構(gòu)成了通信子網(wǎng)，高層協(xié)議只存在于主機(jī)中，如圖５－２所示。上一頁(yè)下一頁(yè)返回5.1網(wǎng)絡(luò)需求與傳輸層功能５.１.４ＴＣＰ／ＩＰ的傳輸層１.ＴＣＰ／ＩＰ傳輸層組成針對(duì)不同的網(wǎng)絡(luò)應(yīng)用對(duì)數(shù)據(jù)可靠性和實(shí)時(shí)性的要求，ＴＣＰ／ＩＰ傳輸層設(shè)計(jì)了兩個(gè)協(xié)議供不同應(yīng)用選擇。這兩個(gè)協(xié)議分別是用戶數(shù)據(jù)報(bào)協(xié)議ＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）和傳輸控制協(xié)議ＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）。圖５－３給出了這兩種協(xié)議在協(xié)議棧中的位置。應(yīng)用層中使用ＴＣＰ協(xié)議的應(yīng)用有ＦＴＰ、ＨＴＴＰ、ＳＭＴＰ、Ｔｅｌｎｅｔ、ＤＮＳ等；使用ＵＤＰ協(xié)議的應(yīng)用有ＤＮＳ、ＴＦＴＰ、ＳＮＭＰ等。在ＴＣＰ／ＩＰ體系中，根據(jù)所使用的協(xié)議是ＴＣＰ或ＵＤＰ，分別稱之為ＴＣＰ數(shù)據(jù)段（ｓｅｇ?ｍｅｎｔ）或ＵＤＰ用戶數(shù)據(jù)報(bào)。上一頁(yè)下一頁(yè)返回5.1網(wǎng)絡(luò)需求與傳輸層功能ＵＤＰ在傳送數(shù)據(jù)之前不需要先建立連接。遠(yuǎn)地主機(jī)的傳輸層在收到ＵＤＰ報(bào)文后，不需要給出任何確認(rèn)。雖然ＵＤＰ不提供可靠交付，但在某些情況下ＵＤＰ卻是一種最有效的工作方式，支持因特網(wǎng)音頻、視頻等實(shí)時(shí)性應(yīng)用。ＴＣＰ則提供面向連接的服務(wù)。在傳送數(shù)據(jù)之前必須先建立連接，數(shù)據(jù)傳送結(jié)束后要釋放連接。ＴＣＰ不提供廣播或多播服務(wù)。由于ＴＣＰ要提供可靠的、面向連接的傳輸服務(wù)，因此不可避免地增加了許多的開(kāi)銷，如確認(rèn)、流量控制、計(jì)時(shí)器以及連接管理等。這不僅使協(xié)議數(shù)據(jù)單元的頭部增大很多，還要占用許多的處理機(jī)資源，因此，網(wǎng)絡(luò)時(shí)延較大。支持可靠性要求高的應(yīng)用，不適合實(shí)時(shí)性強(qiáng)的應(yīng)用。ＵＤＰ和ＴＣＰ中都提供了端口機(jī)制區(qū)分進(jìn)程。上一頁(yè)下一頁(yè)返回5.1網(wǎng)絡(luò)需求與傳輸層功能２.端口前面曾講過(guò)，傳輸層與網(wǎng)絡(luò)層最大的區(qū)別是傳輸層提供進(jìn)程通信能力。為了標(biāo)識(shí)相互通信的網(wǎng)絡(luò)進(jìn)程，ＩＰ網(wǎng)絡(luò)通信的最終地址不僅要包括主機(jī)的ＩＰ地址，還要包括可描述網(wǎng)絡(luò)進(jìn)程的某種標(biāo)識(shí)。因此，無(wú)論是ＴＣＰ還是ＵＤＰ，都必須首先解決進(jìn)程的標(biāo)識(shí)問(wèn)題。我們知道，在單個(gè)計(jì)算機(jī)中的進(jìn)程是用進(jìn)程標(biāo)識(shí)符來(lái)標(biāo)志的。但是在因特網(wǎng)環(huán)境下，用計(jì)算機(jī)操作系統(tǒng)所指派的這種進(jìn)程標(biāo)識(shí)符來(lái)標(biāo)志運(yùn)行在應(yīng)用層的各種應(yīng)用進(jìn)程則是不行的。這是因?yàn)樵谝蛱鼐W(wǎng)上使用的計(jì)算機(jī)的操作系統(tǒng)種類很多，而不同的操作系統(tǒng)又使用不同格式的進(jìn)程標(biāo)識(shí)符。為了使運(yùn)行不同操作系統(tǒng)的計(jì)算機(jī)的應(yīng)用進(jìn)程能夠互相通信，就必須用統(tǒng)一的方法（而這種方法必須與特定操作系統(tǒng)無(wú)關(guān)）對(duì)ＴＣＰ／ＩＰ體系的應(yīng)用進(jìn)程進(jìn)行標(biāo)志。上一頁(yè)下一頁(yè)返回5.1網(wǎng)絡(luò)需求與傳輸層功能ＴＣＰ／ＩＰ的傳輸層用端口來(lái)標(biāo)識(shí)進(jìn)程。一個(gè)端口用一個(gè)１６位二進(jìn)制編碼來(lái)標(biāo)志。１６位的端口號(hào)可允許有６５５３５個(gè)不同的端口號(hào)，這個(gè)數(shù)目對(duì)一個(gè)計(jì)算機(jī)來(lái)說(shuō)是足夠的。端口號(hào)只具有本地意義。因此，因特網(wǎng)上不同計(jì)算機(jī)中的進(jìn)程可能具有相同的端口。所以，要在因特網(wǎng)上唯一地標(biāo)識(shí)定位一個(gè)進(jìn)程就應(yīng)該使用一個(gè)參數(shù)對(duì)，即（ＩＰ地址，端口）。在網(wǎng)絡(luò)通信中，應(yīng)用進(jìn)程通過(guò)傳輸層使用網(wǎng)絡(luò)收發(fā)數(shù)據(jù)，在因特網(wǎng)不同的計(jì)算機(jī)中，相同的端口號(hào)是沒(méi)有關(guān)聯(lián)的。ＴＣＰ／ＩＰ傳輸層使用端口號(hào)對(duì)進(jìn)程尋址，端口號(hào)的作用有點(diǎn)類似ＩＰ地址在網(wǎng)絡(luò)層的作用或ＭＡＣ地址在數(shù)據(jù)鏈路層的作用，只不過(guò)ＩＰ地址是主機(jī)的邏輯標(biāo)識(shí)，ＭＡＣ地址是主機(jī)的物理標(biāo)識(shí)，而端口號(hào)是網(wǎng)絡(luò)應(yīng)用進(jìn)程的一種邏輯標(biāo)識(shí)。由于同一時(shí)刻一臺(tái)主機(jī)上可以有大量的網(wǎng)絡(luò)應(yīng)用進(jìn)程在運(yùn)行，所以需要有多個(gè)不同的端口號(hào)來(lái)對(duì)進(jìn)程進(jìn)行標(biāo)識(shí)。上一頁(yè)下一頁(yè)返回5.1網(wǎng)絡(luò)需求與傳輸層功能原來(lái)，ＴＣＰ／ＩＰ設(shè)計(jì)了一套有效的端口分配和管理辦法，對(duì)于知名應(yīng)用端口有特別的規(guī)定。因特網(wǎng)賦號(hào)管理局（ＩＡＮＡ）將端口號(hào)分為熟知端口（Ｗｅｌｌ－ｋｎｏｗｎｐｏｒｔｓ）、登記端口和臨時(shí)端口三類。其中的熟知端口和登記端口就是用在服務(wù)器端的，臨時(shí)端口號(hào)主要在客戶機(jī)中使用。（１）熟知端口號(hào)。數(shù)值為０～１０２３，這些數(shù)值可在網(wǎng)址ｗｗｗ.ｉａｎａ.ｏｒｇ查到。ＩＡＮＡ把這些端口號(hào)指派給了ＴＣＰ／ＩＰ最重要的一些應(yīng)用程序，讓所有的用戶都知道。表５－１是一些常用的熟知端口號(hào)。這部分端口號(hào)就像生活中的１１９、１１０等服務(wù)電話號(hào)碼，眾所周知，用戶需要時(shí)可以方便地請(qǐng)求服務(wù)。上一頁(yè)下一頁(yè)返回5.1網(wǎng)絡(luò)需求與傳輸層功能當(dāng)一種新的應(yīng)用程序出現(xiàn)后，ＩＡＮＡ必須為它指派一個(gè)熟知端口，否則因特網(wǎng)上的其他應(yīng)用進(jìn)程就無(wú)法和它進(jìn)行通信。（２）登記端口號(hào)。數(shù)值為１０２４～４９１５１。這類端口號(hào)是為沒(méi)有熟知端口號(hào)的應(yīng)用程序使用的。使用這類端口號(hào)必須在ＩＡＮＡ按照規(guī)定的手續(xù)登記，以防止重復(fù)。（３）臨時(shí)端口號(hào)。數(shù)值為４９１５２～６５５３５。由于這類端口號(hào)僅在客戶進(jìn)程運(yùn)行時(shí)才動(dòng)態(tài)選擇，因此又叫作短暫端口號(hào)。這類端口號(hào)是留給客戶進(jìn)程選擇暫時(shí)使用。當(dāng)服務(wù)器進(jìn)程收到客戶進(jìn)程的報(bào)文時(shí)，就知道了客戶進(jìn)程所使用的端口號(hào)，因而可以把數(shù)據(jù)發(fā)送給客戶進(jìn)程。通信結(jié)束后，剛才已使用過(guò)的客戶端口號(hào)就不復(fù)存在。這個(gè)端口號(hào)就可以供其他客戶進(jìn)程以后使用。上一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ５.２.１ＴＣＰ的傳輸模型ＴＣＰ協(xié)議比較復(fù)雜，是面向連接的傳輸層協(xié)議。這就是說(shuō)，應(yīng)用程序在使用ＴＣＰ協(xié)議之前，必須先建立ＴＣＰ連接，在傳送數(shù)據(jù)完畢后，必須釋放已經(jīng)建立的ＴＣＰ連接。應(yīng)用進(jìn)程之間的通信好像在“打電話”：通話前要先撥號(hào)建立連接，通話結(jié)束后要掛機(jī)釋放連接。ＴＣＰ提供可靠交付的服務(wù)。通過(guò)ＴＣＰ連接傳送的數(shù)據(jù)，無(wú)差錯(cuò)、不丟失、不重復(fù)并且按序到達(dá)。所有的ＴＣＰ連接都是全雙工的，并且是點(diǎn)到點(diǎn)的通信。ＴＣＰ允許通信雙方的應(yīng)用進(jìn)程在任何時(shí)候都能發(fā)送數(shù)據(jù)；不支持多播或者廣播傳輸模式；提供面向字節(jié)流的服務(wù)；ＴＣＰ還有流量控制和擁塞控制的功能。下面詳細(xì)說(shuō)明ＴＣＰ的有關(guān)概念和傳輸模型。下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ１.ＴＣＰ連接的概念ＴＣＰ提供的是面向連接的服務(wù)，先建立ＴＣＰ連接再傳輸數(shù)據(jù)，建立連接是為了提高傳輸?shù)目煽啃?。每一條ＴＣＰ連接的兩端用兩個(gè)套接字（ｓｏｃｋｅｔ）來(lái)確定，即（ＩＰ地址，端口號(hào)）。并且每一條ＴＣＰ只能有兩個(gè)端點(diǎn)，也就是說(shuō)，ＴＣＰ連接只能是點(diǎn)對(duì)點(diǎn)的，進(jìn)行一對(duì)一的數(shù)據(jù)傳輸。ＴＣＰ把連接作為最基本的抽象。通信的雙方建立了ＴＣＰ連接，表現(xiàn)在雙方主機(jī)里動(dòng)態(tài)地相互記錄對(duì)方的狀態(tài)。ＴＣＰ“連接”不像線路交換中的端到端的ＴＤＭ或者ＦＤＭ電路，也不是一個(gè)虛電路，ＴＣＰ的連接狀態(tài)是完全駐留在兩個(gè)終端系統(tǒng)中的。中間的路由器不知道，也不保留ＴＣＰ連接的狀態(tài)。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ２.面向流的傳輸ＴＣＰ連接的兩端都設(shè)有發(fā)送緩存和接收緩存，用來(lái)臨時(shí)存放雙向通信的數(shù)據(jù)。在發(fā)送時(shí)，應(yīng)用程序在把數(shù)據(jù)傳送給ＴＣＰ的緩存后，就可以做自己的事，而ＴＣＰ在合適的時(shí)候把數(shù)據(jù)發(fā)送出去。在接收時(shí)，ＴＣＰ把收到的數(shù)據(jù)放入緩存，上層的應(yīng)用進(jìn)程在合適的時(shí)候讀取緩存中的數(shù)據(jù)。一個(gè)ＴＣＰ連接就是一個(gè)字節(jié)流，而不是消息流。端到端之間不保留消息的邊界。也就是說(shuō)，ＴＣＰ把應(yīng)用進(jìn)程送來(lái)的長(zhǎng)短不一的消息（報(bào)文）在緩沖區(qū)里排隊(duì)，它把應(yīng)用程序交來(lái)的數(shù)據(jù)看成僅僅是一連串的無(wú)結(jié)構(gòu)的字節(jié)流。每當(dāng)數(shù)據(jù)達(dá)到一個(gè)段的大小，ＴＣＰ就把它加上ＴＣＰ頭部，包裝成一個(gè)ＴＣＰ數(shù)據(jù)段發(fā)送出去，如圖５－５所示。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰＴＣＰ接收端也不能識(shí)別報(bào)文，它只是把收到的字節(jié)流上交給應(yīng)用程序。接收方的應(yīng)用程序有能力識(shí)別收到的字節(jié)流，把它還原成有意義的應(yīng)用層數(shù)據(jù)。如果傳輸中不出錯(cuò)，接收方應(yīng)用程序收到的字節(jié)流應(yīng)該和發(fā)送方應(yīng)用程序發(fā)出的字節(jié)流完全一樣。從圖５－５中可見(jiàn)，可能幾個(gè)報(bào)文封裝在一個(gè)ＴＣＰ段里發(fā)送，也可能一個(gè)報(bào)文分成幾個(gè)ＴＣＰ段發(fā)送。ＴＣＰ發(fā)送中并不考慮報(bào)文邊界，而把相繼到來(lái)的報(bào)文當(dāng)成連續(xù)的字節(jié)流來(lái)統(tǒng)一處理。發(fā)送過(guò)程中，ＴＣＰ把寫(xiě)入到發(fā)送緩沖區(qū)的數(shù)據(jù)段按字節(jié)連續(xù)編號(hào)，以便接收方按字節(jié)序號(hào)接收，從而實(shí)現(xiàn)順序接收，也能發(fā)現(xiàn)丟失的數(shù)據(jù)段。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰＴＣＰ的這種發(fā)送方式和現(xiàn)實(shí)社會(huì)中的物流模式非常一致。在物流公司收納點(diǎn)，接收并暫存各散戶的貨物，等到同一目的地的物品足夠一車時(shí)便把各散戶貨物集中裝成一車發(fā)出，若某一客戶物品足夠多，也可能要分裝成多車發(fā)送。ＴＣＰ用一個(gè)ＴＣＰ頭將用戶數(shù)據(jù)封裝，得到ＴＣＰ數(shù)據(jù)段。發(fā)送時(shí)，ＴＣＰ數(shù)據(jù)段被傳送到下面的網(wǎng)際層，在那里它被封裝到ＩＰ數(shù)據(jù)報(bào)中，以ＩＰ數(shù)據(jù)報(bào)的形式在網(wǎng)絡(luò)層傳輸。ＴＣＰ對(duì)于應(yīng)用進(jìn)程一次把多長(zhǎng)的報(bào)文發(fā)送到ＴＣＰ的緩存中是不關(guān)心的。ＴＣＰ根據(jù)對(duì)方給出的窗口值和當(dāng)前網(wǎng)絡(luò)擁塞的程度來(lái)決定一個(gè)數(shù)據(jù)段應(yīng)包含多少個(gè)字節(jié)（ＵＤＰ是把整個(gè)報(bào)文包裝成一個(gè)ＵＤＰ數(shù)據(jù)段）。如果應(yīng)用進(jìn)程傳送到ＴＣＰ緩存的數(shù)據(jù)塊太長(zhǎng)，ＴＣＰ就可以把它劃分短一些再傳送。如果應(yīng)用進(jìn)程一次只發(fā)來(lái)很少的字節(jié)，ＴＣＰ也可以等待積累有足夠多的字節(jié)后再構(gòu)成數(shù)據(jù)段發(fā)送出去。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ３.ＴＣＰ傳輸模式ＴＣＰ傳輸數(shù)據(jù)時(shí)，需要建立連接。連接是可靠傳輸?shù)幕A(chǔ)，在端到端的連接上實(shí)現(xiàn)數(shù)據(jù)流的可靠傳輸。ＴＣＰ按字節(jié)序號(hào)把數(shù)據(jù)封裝成ＴＣＰ段，使用ＴＣＰ連接發(fā)送到接收端。我們知道，ＴＣＰ發(fā)送的數(shù)據(jù)段是交給ＩＰ層傳送的。但ＩＰ層只能提供盡最大努力的服務(wù)，也就是說(shuō)，ＴＣＰ下面的網(wǎng)絡(luò)所提供的是不可靠的傳輸。因此，ＴＣＰ必須采用適當(dāng)?shù)拇胧┎拍苁沟脙蓚€(gè)傳輸層之間的通信變得可靠?？煽總鬏斒侵?jìng)鬏數(shù)臄?shù)據(jù)無(wú)差錯(cuò)、無(wú)丟失、無(wú)重復(fù)，接收的數(shù)據(jù)有次序。ＩＰ層的服務(wù)是不可靠的，ＴＣＰ是如何在不可靠的ＩＰ服務(wù)基礎(chǔ)上構(gòu)建可靠通信的？這主要得益于以下機(jī)制：差錯(cuò)校驗(yàn)機(jī)制、應(yīng)答機(jī)制、重傳機(jī)制、序號(hào)機(jī)制。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰＴＣＰ按字節(jié)序號(hào)進(jìn)行數(shù)據(jù)收發(fā)。ＴＣＰ把應(yīng)用程序送發(fā)的數(shù)據(jù)在緩沖區(qū)里排隊(duì)，并按字節(jié)編號(hào)。初始序號(hào)可以是任意值，由雙方在建立連接時(shí)商定，發(fā)送時(shí)從初始序號(hào)字節(jié)處開(kāi)始發(fā)送；在ＴＣＰ連接兩端配置發(fā)送緩沖區(qū)和接收緩沖區(qū)，發(fā)送緩沖區(qū)是存放已發(fā)送但還沒(méi)有確認(rèn)的數(shù)據(jù)段，接收緩沖區(qū)存放已接收但還沒(méi)處理的數(shù)據(jù)段；接收方處理收到的ＴＣＰ段時(shí)，進(jìn)行差錯(cuò)校驗(yàn)，丟棄出錯(cuò)的ＴＣＰ段，對(duì)正確接收的ＴＣＰ段進(jìn)行應(yīng)答，為提高效率，允許捎帶應(yīng)答和累積應(yīng)答，應(yīng)答序號(hào)是已收到的字節(jié)序號(hào)加１；對(duì)出錯(cuò)和丟失的ＴＣＰ段采用重發(fā)機(jī)制更正。ＴＣＰ中沒(méi)有否定應(yīng)答，對(duì)出錯(cuò)被丟棄的數(shù)據(jù)段不作應(yīng)答。這樣發(fā)送計(jì)時(shí)器就會(huì)超時(shí)，引起重發(fā)。對(duì)重復(fù)的數(shù)據(jù)ＴＣＰ接收方會(huì)丟棄，但要作出確認(rèn)。為什么對(duì)丟棄的重復(fù)段還要確認(rèn)？正是因?yàn)榘l(fā)送端沒(méi)收到數(shù)據(jù)段的第一次確認(rèn)才重發(fā)，所以還需要給出確認(rèn)。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ圖５－６展示了一數(shù)據(jù)流的發(fā)送模式，ＴＣＰ對(duì)數(shù)據(jù)流按字節(jié)編號(hào)（起始編號(hào)由建立連接時(shí)約定，不一定從０開(kāi)始）。每個(gè)數(shù)據(jù)段的大小為１００字節(jié)，起始序號(hào)為２０１。從圖５－６可以看出，為了提高發(fā)送效率，ＴＣＰ采用了連續(xù)ＡＲＱ的發(fā)送方式。請(qǐng)讀者注意ＴＣＰ確認(rèn)號(hào)的特點(diǎn)。圖５－６（ａ）中，Ｂ收到了Ａ發(fā)送過(guò)來(lái)的一個(gè)數(shù)據(jù)段，其序號(hào)字段值是２０１，而數(shù)據(jù)長(zhǎng)度是１００字節(jié)，檢驗(yàn)無(wú)誤后Ｂ要發(fā)回確認(rèn)。確認(rèn)序號(hào)是３０１，這表示Ｂ期望從第３０１字節(jié)處開(kāi)始接收，正是下一個(gè)數(shù)據(jù)段的起始序號(hào)。意味著Ｂ正確收到了Ａ發(fā)送的到序號(hào)３００為止的數(shù)據(jù)。因此，Ｂ在發(fā)送給Ａ的確認(rèn)數(shù)據(jù)段中把確認(rèn)號(hào)置為３０１。請(qǐng)注意，此時(shí)的確認(rèn)號(hào)不是２０１，也不是３００。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰＴＣＰ中無(wú)否定應(yīng)答。ＴＣＰ使用差錯(cuò)檢測(cè)技術(shù)對(duì)收到的數(shù)據(jù)段進(jìn)行檢驗(yàn)。圖５－６（ｂ）中，發(fā)現(xiàn)起始序號(hào)為５０１的數(shù)據(jù)段出錯(cuò)后直接丟棄，并不確認(rèn)，等待發(fā)送方超時(shí)重發(fā)。ＴＣＰ是雙工通信，接收方可以在合適的時(shí)候發(fā)送確認(rèn)，也可以在自己有數(shù)據(jù)要發(fā)送時(shí)把確認(rèn)信息順便捎帶上，以減少網(wǎng)絡(luò)數(shù)據(jù)包的發(fā)送，這稱作捎帶確認(rèn)。捎帶確認(rèn)實(shí)際上并不經(jīng)常發(fā)生，因?yàn)榇蠖鄶?shù)應(yīng)用程序不同時(shí)在兩個(gè)方向上發(fā)送數(shù)據(jù)。由于ＩＰ層提供的是數(shù)據(jù)報(bào)服務(wù)，ＴＣＰ段可能會(huì)無(wú)序到達(dá)。對(duì)于不按序到達(dá)的數(shù)據(jù)應(yīng)如何處理，ＴＣＰ標(biāo)準(zhǔn)并無(wú)明確規(guī)定。如果接收方把不按序到達(dá)的數(shù)據(jù)一律丟棄，那么接收窗口的管理將會(huì)比較簡(jiǎn)單，但這樣做對(duì)網(wǎng)絡(luò)資源的利用不利（因?yàn)榘l(fā)送方會(huì)重復(fù)傳送較多的數(shù)據(jù)）。因此ＴＣＰ通常對(duì)不按序到達(dá)的數(shù)據(jù)是先臨時(shí)存放在接收緩沖區(qū)中，等到字節(jié)流中所缺少的字節(jié)收到后，再按序交付給上層的應(yīng)用進(jìn)程。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ５.２.２ＴＣＰ數(shù)據(jù)段結(jié)構(gòu)ＴＣＰ數(shù)據(jù)段是ＴＣＰ傳送數(shù)據(jù)的單元，ＴＣＰ以數(shù)據(jù)段的形式傳輸字節(jié)流。ＴＣＰ段由一個(gè)頭部（最少２０字節(jié)）以及隨后的數(shù)據(jù)構(gòu)成。沒(méi)有任何數(shù)據(jù)的ＴＣＰ段也是合法的，通常被用作確認(rèn)和控制消息。ＴＣＰ軟件決定了段的大小，有兩個(gè)因素限制了段的大小。首先，包括ＴＣＰ頭在內(nèi)的每個(gè)段，必須適合ＩＰ數(shù)據(jù)報(bào)的６５５１５個(gè)字節(jié)的有效載荷；其次，每個(gè)鏈路層網(wǎng)絡(luò)都有一個(gè)最大傳輸單元ＭＴＵ，每個(gè)段必須適合ＭＴＵ才能以單個(gè)不分段的數(shù)據(jù)包發(fā)送和接收。實(shí)際上，ＭＴＵ通常是１５００字節(jié)（以太網(wǎng)的），它規(guī)定了段長(zhǎng)度的上界。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰＴＣＰ數(shù)據(jù)段的結(jié)構(gòu)是與ＴＣＰ的數(shù)據(jù)傳輸模式相適配，數(shù)據(jù)段結(jié)構(gòu)的設(shè)計(jì)支持ＴＣＰ的傳輸機(jī)制。ＴＣＰ頭的各字段結(jié)構(gòu)是與ＴＣＰ傳輸中實(shí)現(xiàn)的功能相適應(yīng)的。只有弄清ＴＣＰ頭部各字段的作用才能掌握ＴＣＰ的工作原理。ＴＣＰ數(shù)據(jù)段的頭部格式如圖５－７所示。ＴＣＰ數(shù)據(jù)段頭部的前２０個(gè)字節(jié)是固定的，選項(xiàng)是根據(jù)需要可選的，選項(xiàng)的長(zhǎng)度應(yīng)是４字節(jié)的整數(shù)倍（不足時(shí)可以填充）。因此ＴＣＰ頭部的最小長(zhǎng)度是２０字節(jié)。現(xiàn)在讓我們逐個(gè)字段地剖析ＴＣＰ頭結(jié)構(gòu)。源端口和目的端口各占２個(gè)字節(jié)，分別寫(xiě)入源端口號(hào)和目的端口號(hào)。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ序號(hào)字段占４字節(jié)。序號(hào)范圍是［０，２３２－１］，循環(huán)使用。ＴＣＰ是面向字節(jié)流的。在一個(gè)ＴＣＰ連接中傳送的字節(jié)流中的每一個(gè)字節(jié)都按順序編號(hào)。整個(gè)要傳送的字節(jié)流的起始序號(hào)必須在連接建立時(shí)設(shè)置。確認(rèn)號(hào)字段占４字節(jié)，是期望收到對(duì)方下一個(gè)數(shù)據(jù)段的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)，也就是已經(jīng)接收到的最后一個(gè)字節(jié)序號(hào)加１。由于序號(hào)段有３２位長(zhǎng)，可對(duì)４ＧＢ（即４千兆字節(jié)）的數(shù)據(jù)進(jìn)行編號(hào)。在一般情況下可保證當(dāng)序號(hào)重復(fù)使用時(shí)不會(huì)引起混淆，因?yàn)榕f序號(hào)的數(shù)據(jù)早已通過(guò)網(wǎng)絡(luò)到達(dá)終點(diǎn)了。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰＴＣＰ頭長(zhǎng)度字段占４位。它指明了數(shù)據(jù)段頭的長(zhǎng)度，以４字節(jié)為單位。ＴＣＰ數(shù)據(jù)段的頭部長(zhǎng)度是不確定的，因?yàn)轭^部中還有長(zhǎng)度不確定的選項(xiàng)字段，因此該字段是必要的。由于４位二進(jìn)制數(shù)能夠表示的最大十進(jìn)制數(shù)字是１５，因此數(shù)據(jù)偏移的最大值是６０字節(jié)，這也是ＴＣＰ頭部的最大長(zhǎng)度（即選項(xiàng)長(zhǎng)度不能超過(guò)４０字節(jié)）。保留部分占６位，保留為今后使用，但目前應(yīng)置為０。之后有６個(gè)比特是標(biāo)志位，它指明了本數(shù)據(jù)段的性質(zhì)。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ（１）緊急ＵＲＧ（ＵＲＧｅｎｔ）位。當(dāng)ＵＲＧ＝１時(shí)，表明緊急指針字段有效。它告訴系統(tǒng)此數(shù)據(jù)段中有緊急數(shù)據(jù)，應(yīng)盡快傳送（相當(dāng)于高優(yōu)先級(jí)的數(shù)據(jù)），而不要按原來(lái)的排隊(duì)順序來(lái)傳送。例如，已經(jīng)發(fā)送了很長(zhǎng)的一個(gè)程序要在遠(yuǎn)地的主機(jī)上運(yùn)行。但后來(lái)發(fā)現(xiàn)了一些問(wèn)題，需要取消該程序的運(yùn)行。因此用戶從鍵盤(pán)發(fā)出中斷命令（Ｃｏｎｔｒｏｌ＋Ｃ）。如果不使用緊急數(shù)據(jù)，那么這兩個(gè)字符將存儲(chǔ)在接收ＴＣＰ的緩存末尾，只有在所有的數(shù)據(jù)被處理完畢后這兩個(gè)字符才被交付到接收方的應(yīng)用進(jìn)程。這樣做就浪費(fèi)了許多時(shí)間。（２）ＡＣＫ（ＡＣＫｎｏｗｌｅｇｍｅｎｔ）標(biāo)志位設(shè)置為１時(shí)，表示確認(rèn)號(hào)字段有效。當(dāng)ＡＣＫ＝０時(shí)，確認(rèn)字段不包含確認(rèn)信息，所以可以被忽略。ＴＣＰ規(guī)定，在連接建立后所有傳送的數(shù)據(jù)段都必須把ＡＣＫ置１。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ（３）ＰＳＨ（ＰｕＳＨ）標(biāo)志位置為１時(shí)，表示這個(gè)段是被推送（ＰｕＳＨ）的數(shù)據(jù)，接收方一旦收到數(shù)據(jù)后立即將數(shù)據(jù)遞交給應(yīng)用程序，而不是將它緩沖起來(lái)直到整個(gè)緩沖區(qū)滿才處理上交數(shù)據(jù)。雖然應(yīng)用程序可以選擇推送操作，但推送操作還很少使用。（４）復(fù)位ＲＳＴ（ＲｅＳｅＴ）標(biāo)志位。當(dāng)ＲＳＴ＝１時(shí)，表明ＴＣＰ連接中出現(xiàn)嚴(yán)重差錯(cuò)（如由于主機(jī)崩潰或其他原因），必須釋放連接，然后再重新建立傳輸連接。ＲＳＴ置１還用來(lái)拒絕一個(gè)非法的數(shù)據(jù)段或拒絕打開(kāi)一個(gè)連接。ＲＳＴ也可稱為重建位或重置位。（５）ＳＹＮ（ＳＹＮｃｈｒｏｎｉｚａｔｉｏｎ）在連接建立時(shí)用來(lái)同步序號(hào)。當(dāng)ＳＹＮ＝１而ＡＣＫ＝０時(shí)，表明這是一個(gè)連接請(qǐng)求數(shù)據(jù)段。對(duì)方若同意建立連接，則應(yīng)在響應(yīng)的數(shù)據(jù)段中使ＳＹＮ＝１和ＡＣＫ＝１。因此，ＳＹＮ置為１就表示這是一個(gè)連接請(qǐng)求或連接接受報(bào)文。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ（６）終止ＦＩＮ（ＦＩＮｉｓ）標(biāo)志位用來(lái)釋放一個(gè)連接。當(dāng)ＦＩＮ＝１時(shí)，表明此數(shù)據(jù)段的發(fā)送方的數(shù)據(jù)已發(fā)送完畢，并要求釋放傳輸連接。檢驗(yàn)和字段占２字節(jié)。檢驗(yàn)和字段檢驗(yàn)的范圍包括頭部和數(shù)據(jù)這兩部分。在計(jì)算檢驗(yàn)和時(shí)，要在ＴＣＰ數(shù)據(jù)段的前面加上１２字節(jié)的偽頭部，如圖５－８所示。偽頭部的格式與ＵＤＰ用戶數(shù)據(jù)報(bào)的偽頭部一樣。接收方收到此數(shù)據(jù)段后，仍要加上這個(gè)偽頭部來(lái)計(jì)算檢驗(yàn)和。若使用ＩＰｖ６，則相應(yīng)的偽頭部也要改變。ＴＣＰ最初只規(guī)定了一種選項(xiàng)，即最大數(shù)據(jù)段長(zhǎng)度ＭＳＳ（ＭａｘｉｍｕｍＳｅｇｍｅｎｔＳｉｚｅ）。ＭＳＳ是每一個(gè)ＴＣＰ數(shù)據(jù)段中的數(shù)據(jù)字段的最大長(zhǎng)度。數(shù)據(jù)字段加上ＴＣＰ頭部才等于整個(gè)的ＴＣＰ數(shù)據(jù)段。所以ＭＳＳ并不是整個(gè)ＴＣＰ數(shù)據(jù)段的最大長(zhǎng)度，而是“ＴＣＰ數(shù)據(jù)段長(zhǎng)度減去ＴＣＰ頭部長(zhǎng)度”。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ５.２.３ＴＣＰ的流量控制１.流量控制概念與實(shí)現(xiàn)原則數(shù)據(jù)丟失是影響可靠傳輸?shù)闹匾矫?，傳輸中的?shù)據(jù)丟失有兩種：一種是在傳輸鏈路上的丟失，另一種是由于接收方來(lái)不及接收而導(dǎo)致的數(shù)據(jù)丟失。后一種情況往往會(huì)造成數(shù)據(jù)的大量丟失，為此，ＴＣＰ中設(shè)計(jì)了流量控制機(jī)制來(lái)避免這種情況出現(xiàn)。一般說(shuō)來(lái)，我們總是希望數(shù)據(jù)傳輸?shù)酶煲恍?。但如果發(fā)送方把數(shù)據(jù)發(fā)送得過(guò)快，接收方就可能來(lái)不及接收，這就會(huì)造成數(shù)據(jù)的丟失。數(shù)據(jù)丟失是影響傳輸可靠性的重大因素。其主成因分析如下。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰＴＣＰ連接的接收方機(jī)器上設(shè)置有接收緩沖區(qū)。當(dāng)ＴＣＰ接收到正確的、有序到達(dá)的字節(jié)時(shí)，它就將數(shù)據(jù)放入到接收緩沖區(qū)里。相關(guān)應(yīng)用程序進(jìn)程可以從該緩沖區(qū)中讀出數(shù)據(jù)，但不一定是在數(shù)據(jù)到達(dá)的那個(gè)時(shí)刻。事實(shí)上，接收方應(yīng)用程序可能忙于其他事務(wù)，在數(shù)據(jù)到達(dá)很久以后才會(huì)去讀。如果應(yīng)用程序讀數(shù)據(jù)的速度相對(duì)較慢，而發(fā)送方發(fā)送數(shù)據(jù)過(guò)快的話，則很容易造成連接的接收緩沖區(qū)溢出而導(dǎo)致數(shù)據(jù)丟失的情況。為此，ＴＣＰ提供了一個(gè)流量控制服務(wù)，避免因來(lái)限制發(fā)送方造成接收方緩沖區(qū)溢出的可能性。流量控制就是控制發(fā)送方的發(fā)送速度不至過(guò)快，避免因超過(guò)接收能力使接收方來(lái)不及接收而造成數(shù)據(jù)丟失。由此看來(lái)，流量控制就是一個(gè)速度匹配服務(wù)，使得發(fā)送方發(fā)送的速度與接收方讀出的速度相匹配。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ在發(fā)送方機(jī)器上也配置有一個(gè)緩沖區(qū)，用以存放應(yīng)用程序送來(lái)要發(fā)送的數(shù)據(jù)；同時(shí)，ＴＣＰ已發(fā)送出但尚未收到確認(rèn)的數(shù)據(jù)有可能需要重發(fā)，也要暫時(shí)保留在緩沖區(qū)中。在發(fā)送端，由于應(yīng)用進(jìn)程寫(xiě)入數(shù)據(jù)而使發(fā)送緩沖區(qū)變滿，因收到對(duì)方應(yīng)答釋放緩存的已發(fā)數(shù)據(jù)段而變得空閑。發(fā)送方來(lái)說(shuō)，只要應(yīng)用程序提供足夠多的數(shù)據(jù)，發(fā)送方就可以連續(xù)大流量地把數(shù)據(jù)發(fā)送到對(duì)方。但接收方的緩沖區(qū)有限，它不能允許發(fā)送方放開(kāi)量地傾瀉。采用的辦法是把接收方緩沖區(qū)的空閑大小反饋給發(fā)送方，以控制其后續(xù)發(fā)送量。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ發(fā)送窗口是發(fā)送方可以發(fā)送的數(shù)據(jù)序號(hào)范圍，它包括已經(jīng)發(fā)送還未被確認(rèn)的以及可以發(fā)送的數(shù)據(jù)。發(fā)送窗口是發(fā)送方緩沖區(qū)中的數(shù)據(jù)流中的一部分。在發(fā)送方，它要跟蹤兩個(gè)變量：一個(gè)是最后發(fā)送的字節(jié)序號(hào)，記為ｓ；一個(gè)是最后被確認(rèn)的字節(jié)序號(hào)，記為ｃ。兩個(gè)序號(hào)的差，即ｓ－ｃ就是已經(jīng)發(fā)送出去還未確認(rèn)的數(shù)據(jù)量。發(fā)送方只要在整個(gè)連接的存活期中保持ｓ－ｃ≤ｗ，就可以保證接收方緩沖區(qū)不會(huì)溢出，如圖５－９所示。可見(jiàn)，接收緩沖區(qū)與接收窗口不是一個(gè)概念，發(fā)送緩沖區(qū)與發(fā)送窗口也不是一個(gè)概念；接收窗口制約著發(fā)送窗口的大小。它們之間有關(guān)系也有區(qū)別，請(qǐng)注意分析過(guò)程、區(qū)分概念、理清聯(lián)系。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ２.滑動(dòng)窗口機(jī)制為了提高效率，ＴＣＰ使用了連續(xù)ＡＲＱ傳輸數(shù)據(jù)。連續(xù)發(fā)送提高了效率，但發(fā)送者又會(huì)擔(dān)心連續(xù)過(guò)量的發(fā)送導(dǎo)致接收方緩沖區(qū)溢出，所以，最好能讓發(fā)送方掌握一個(gè)發(fā)送上限，只要不超此限，就可以放心發(fā)送而不必?fù)?dān)心。ＴＣＰ的滑動(dòng)窗口機(jī)制正是基于此而實(shí)現(xiàn)的。根據(jù)以上ＴＣＰ的分析，我們看到發(fā)送方要保持發(fā)送窗口時(shí)刻小于接收窗口，就能保證接收主機(jī)的緩沖區(qū)不會(huì)溢出。但是，接收窗口是時(shí)刻變化的，隨著接收方接收數(shù)據(jù)段而變小，隨著應(yīng)用程序讀出數(shù)據(jù)而變大，同時(shí)，系統(tǒng)分給進(jìn)程的緩沖總數(shù)也可能動(dòng)態(tài)增多或變少。接收窗口會(huì)發(fā)生變化，發(fā)送窗口也就要隨著變化，因此，ＴＣＰ發(fā)送是一個(gè)動(dòng)態(tài)過(guò)程。那么發(fā)送方是如何跟上接收窗口的變化實(shí)現(xiàn)流量的動(dòng)態(tài)控制的呢？上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰＴＣＰ滑動(dòng)窗口是一復(fù)雜的機(jī)制，以上我們?cè)诶硐肭闆r下分析了其主要原理，以便讓讀者快速構(gòu)建一個(gè)控制模型。具體實(shí)現(xiàn)中還有許多特殊情況需要解決。比如，在發(fā)送較快的情況下，可能讓接收緩沖區(qū)充滿，接收方會(huì)發(fā)出接收窗口為０的通報(bào)，發(fā)送方將停止發(fā)送。因此，接收方以后也不會(huì)再有應(yīng)答，從而失去了向發(fā)送方通告窗口的機(jī)會(huì)，即使其緩沖區(qū)已經(jīng)被應(yīng)用進(jìn)程提取空了。最終使系統(tǒng)陷入死鎖不能推進(jìn)。對(duì)此類問(wèn)題，還需讀者深入思考或查閱相關(guān)資料。除了流量控制因素，考慮到ＴＣＰ大量的數(shù)據(jù)突發(fā)會(huì)導(dǎo)致網(wǎng)絡(luò)擁塞，正如剛才所言，ＴＣＰ的發(fā)送能力還受網(wǎng)絡(luò)擁塞狀況的制約。為此，我們進(jìn)入下一節(jié)擁塞控制的討論。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ５.２.４ＴＣＰ的擁塞控制流量控制只是考慮了接收能力而設(shè)置的控制機(jī)制，ＴＣＰ的擁塞控制是考慮到網(wǎng)絡(luò)和承受能力，考慮ＴＣＰ最大量發(fā)送對(duì)網(wǎng)絡(luò)的影響而設(shè)置的控制機(jī)制，它不同于流量控制。１.擁塞控制的一般原理在計(jì)算機(jī)網(wǎng)絡(luò)中的鏈路容量（即帶寬）、交換結(jié)點(diǎn)中的緩存和處理機(jī)等，都是網(wǎng)絡(luò)的資源。在某段時(shí)間，若對(duì)網(wǎng)絡(luò)中某一資源的需求超過(guò)了該資源所能提供的可用部分，網(wǎng)絡(luò)的性能就要變壞。這種情況就叫作擁塞（ｃｏｎｇｅｓｔｉｏｎ）?？梢园殉霈F(xiàn)網(wǎng)絡(luò)擁塞的條件寫(xiě)成如下的關(guān)系式：Σ對(duì)資源的需求＞可用資源上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ若網(wǎng)絡(luò)中有許多資源同時(shí)呈現(xiàn)供應(yīng)不足，網(wǎng)絡(luò)的性能就要明顯變壞，整個(gè)網(wǎng)絡(luò)的吞吐量將隨輸入負(fù)荷的增大而下降，嚴(yán)重的情況下導(dǎo)致網(wǎng)絡(luò)的吞吐量下降到零，即進(jìn)入死鎖狀態(tài)。擁塞控制的目的就是控制著網(wǎng)絡(luò)不進(jìn)入擁塞狀態(tài)，或檢測(cè)擁塞、解除擁塞，使網(wǎng)絡(luò)保持在一個(gè)正常的可控狀態(tài)。網(wǎng)絡(luò)擁塞的害處及擁塞控制的作用如圖５－１１所示。有人可能會(huì)說(shuō)：“只要任意增加一些資源，例如，把結(jié)點(diǎn)緩存的存儲(chǔ)空間擴(kuò)大，或把鏈路更換為更高速率的鏈路，或把結(jié)點(diǎn)處理機(jī)的運(yùn)算速度提高，就可以解決網(wǎng)絡(luò)擁塞的問(wèn)題?！逼鋵?shí)不然。網(wǎng)絡(luò)擁塞是一個(gè)非常復(fù)雜的問(wèn)題，簡(jiǎn)單地采用上述做法，在許多情況下，不但不能解決擁塞問(wèn)題，而且還可能使網(wǎng)絡(luò)的性能更壞。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ網(wǎng)絡(luò)擁塞往往是由多種因素引起的，擁塞的控制也應(yīng)該是多方面的，網(wǎng)絡(luò)層有擁塞控制的功能，ＴＣＰ的擁塞控制是整個(gè)擁塞控制系統(tǒng)的一部分。ＴＣＰ使用擁塞控制機(jī)制，避免突發(fā)數(shù)據(jù)的大量發(fā)送導(dǎo)致網(wǎng)絡(luò)擁塞。為了集中精力討論擁塞控制，我們假定：（１）數(shù)據(jù)是單方向傳送，而另一個(gè)方向只傳送確認(rèn)；（２）接收方總是有足夠大的緩存空間，因而發(fā)送窗口的大小由網(wǎng)絡(luò)的擁塞程度來(lái)決定。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ２.慢開(kāi)始和擁塞避免為了不讓發(fā)送端突發(fā)大量的數(shù)據(jù)導(dǎo)致網(wǎng)絡(luò)擁塞，發(fā)送方維持一個(gè)叫作擁塞窗口ｃｗｎｄ（ｃｏｎｇｅｓｔｉｏｎｗｉｎｄｏｗ）的狀態(tài)變量。擁塞窗口的大小取決于網(wǎng)絡(luò)的擁塞程度，并且動(dòng)態(tài)地在變化。發(fā)送方要控制自己的發(fā)送窗口不能大于擁塞窗口。以后我們就知道，如果再考慮到接收方的接收能力，發(fā)送窗口還可能小于擁塞窗口。發(fā)送方控制擁塞窗口的原則是：只要上一輪次網(wǎng)絡(luò)沒(méi)有出現(xiàn)擁塞，下一輪次擁塞窗口就再增大一些，以便把更多的分組發(fā)送出去。但只要網(wǎng)絡(luò)出現(xiàn)擁塞，擁塞窗口就減小一些，以減少注入網(wǎng)絡(luò)中的分組數(shù)。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ現(xiàn)在困難的是，傳輸層的控制實(shí)體是在主機(jī)上，而網(wǎng)絡(luò)擁塞發(fā)生在主機(jī)之外的網(wǎng)絡(luò)中。發(fā)送方的控制實(shí)體又是如何知道網(wǎng)絡(luò)發(fā)生了擁塞呢？ＴＣＰ將數(shù)據(jù)超時(shí)作為擁塞的標(biāo)志。我們知道，當(dāng)網(wǎng)絡(luò)發(fā)生擁塞時(shí)，路由器就要丟棄分組。因此只要發(fā)送方?jīng)]有按時(shí)收到應(yīng)當(dāng)?shù)竭_(dá)的確認(rèn)報(bào)文，就可以猜想網(wǎng)絡(luò)可能出現(xiàn)了擁塞，因此將數(shù)據(jù)超時(shí)視作網(wǎng)絡(luò)擁塞。當(dāng)然，導(dǎo)致超時(shí)的還有很多其他方面的因素，但確實(shí)沒(méi)有更好的辦法來(lái)區(qū)分，好在現(xiàn)在通信線路的傳輸質(zhì)量一般都很好，因傳輸出差錯(cuò)而丟棄分組的概率是很小的（遠(yuǎn)小于１％）。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ在一開(kāi)始發(fā)送方先設(shè)置ｃｗｎｄ＝１，ＴＣＰ向網(wǎng)絡(luò)發(fā)送第一個(gè)數(shù)據(jù)段并等待確認(rèn)。如果該數(shù)據(jù)段在超時(shí)之前被確認(rèn)，則發(fā)送方將擁塞窗口增加１個(gè)ＭＳＳ。于是發(fā)送方在第一個(gè)輪次中發(fā)送兩個(gè)數(shù)據(jù)段，接收方對(duì)這兩個(gè)數(shù)據(jù)段正常確認(rèn)，發(fā)送方每收到一個(gè)對(duì)新數(shù)據(jù)段的確認(rèn)（重傳的不算在內(nèi)）就使發(fā)送方的擁塞窗口加１，因此發(fā)送方在收到兩個(gè)確認(rèn)后，ｃｗｎｄ就從２增大到４，并可在下一輪次中發(fā)送４個(gè)數(shù)據(jù)段。因此使用慢開(kāi)始算法后，每經(jīng)過(guò)一個(gè)傳輸輪次（ｔｒａｎｓｍｉｓｓｉｏｎｒｏｕｎｄ），擁塞窗口ｃｗｎｄ就加倍，如圖５－１２所示。可見(jiàn)，ＴＣＰ數(shù)據(jù)發(fā)送的開(kāi)始階段是很慢，但這個(gè)階段的速率增長(zhǎng)是很快的，以指數(shù)規(guī)律遞增，是慢開(kāi)始，快增長(zhǎng)。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ在有大量數(shù)據(jù)發(fā)送的情況下，這種快速增長(zhǎng)勢(shì)必會(huì)導(dǎo)致網(wǎng)絡(luò)擁塞，所以增長(zhǎng)到一定程度，就要小心了。為此，ＴＣＰ設(shè)置了一個(gè)警界值，即慢開(kāi)始門限ｓｓｔｈｒｅｓｈ狀態(tài)變量。慢開(kāi)始門限ｓｓｔｈｒｅｓｈ的用法如下：當(dāng)ｃｗｎｄ＜ｓｓｔｈｒｅｓｈ時(shí)，使用上述的慢開(kāi)始算法；當(dāng)ｃｗｎｄ＞ｓｓｔｈｒｅｓｈ時(shí)，停止使用慢開(kāi)始算法而改用擁塞避免算法；當(dāng)ｃｗｎｄ＝ｓｓｔｈｒｅｓｈ時(shí)，既可使用慢開(kāi)始算法，也可使用擁塞避免算法。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ擁塞避免算法的思路是讓擁塞窗口ｃｗｎｄ緩慢地增大，即每經(jīng)過(guò)一個(gè)往返時(shí)間ＲＴＴ就把發(fā)送方的擁塞窗口ｃｗｎｄ加１，而不是加倍。這樣，擁塞窗口ｃｗｎｄ按線性規(guī)律緩慢增長(zhǎng)，比慢開(kāi)始算法的擁塞窗口增長(zhǎng)速率緩慢得多。擁塞避免階段是基于臨近擁塞的一個(gè)估計(jì)而小心試探的過(guò)程，這個(gè)階段的數(shù)據(jù)發(fā)送量大，同時(shí)又緩慢增長(zhǎng)，它是ＴＣＰ試圖以最高限度發(fā)送數(shù)據(jù)的體現(xiàn)。這種做法的結(jié)果很可能導(dǎo)致?lián)砣M(jìn)入擁塞階段。擁塞階段的處理算法。無(wú)論在慢開(kāi)始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞（有數(shù)據(jù)段超時(shí)），就要把慢開(kāi)始門限ｓｓｔｈｒｅｓｈ設(shè)置為出現(xiàn)擁塞時(shí)的發(fā)送方窗口值的一半（但不能小于２）。然后把擁塞窗口ｃｗｎｄ重新設(shè)置為１，執(zhí)行慢開(kāi)始算法。這樣做的目的就是要迅速減少主機(jī)發(fā)送到網(wǎng)絡(luò)中的分組數(shù)，使得發(fā)生擁塞的路由器有足夠時(shí)間把隊(duì)列中積壓的分組處理完畢。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ圖５－１３說(shuō)明了上述擁塞控制的過(guò)程?，F(xiàn)在發(fā)送窗口的大小和擁塞窗口一樣大。（１）當(dāng)ＴＣＰ連接進(jìn)行初始化時(shí)，把擁塞窗口ｃｗｎｄ置為１。前面已說(shuō)過(guò)，為了便于理解，圖中的窗口單位不使用字節(jié)而使用數(shù)據(jù)段的個(gè)數(shù)。慢開(kāi)始門限的初始值設(shè)置為１６個(gè)數(shù)據(jù)段，即ｓｓｔｈｒｅｓｈ＝１６。（２）在執(zhí)行慢開(kāi)始算法時(shí)，擁塞窗口ｃｗｎｄ的初始值為１。以后發(fā)送方每收到一個(gè)對(duì)新數(shù)據(jù)段的確認(rèn)ＡＣＫ，就把擁塞窗口值加１，然后開(kāi)始下一輪的傳輸。因此擁塞窗口ｃｗｎｄ隨著傳輸輪次按指數(shù)規(guī)律增長(zhǎng)。當(dāng)擁塞窗口ｃｗｎｄ增長(zhǎng)到慢開(kāi)始門限值ｓｓｔｈｒｅｓｈ時(shí)（即當(dāng)ｃｗｎｄ＝１６時(shí)），就改為執(zhí)行擁塞避免算法，擁塞窗口按線性規(guī)律增長(zhǎng)。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ（３）假定擁塞窗口的數(shù)值增長(zhǎng)到２４時(shí)，網(wǎng)絡(luò)出現(xiàn)超時(shí)（這很可能就是網(wǎng)絡(luò)發(fā)生擁塞了）。更新后的ｓｓｔｈｒｅｓｈ值變?yōu)椋保玻醋優(yōu)槌霈F(xiàn)超時(shí)時(shí)的擁塞窗口數(shù)值２４的一半），擁塞窗口再重新設(shè)置為１，并執(zhí)行慢開(kāi)始算法。當(dāng)ｃｗｎｄ＝ｓｓｔｈｒｅｓｈ＝１２時(shí)改為執(zhí)行擁塞避免算法，擁塞窗口按線性規(guī)律增長(zhǎng)，每經(jīng)過(guò)一個(gè)往返時(shí)間增加一個(gè)ＭＳＳ的大小。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ在ＴＣＰ擁塞控制的文獻(xiàn)中經(jīng)?？煽匆?jiàn)“乘法減小”（ＭｕｌｔｉｐｌｉｃａｔｉｖｅＤｅｃｒｅａｓｅ）和“加法增大”（ＡｄｄｉｔｉｖｅＩｎｃｒｅａｓｅ）這樣的提法?！俺朔p小”是指不論在慢開(kāi)始階段還是擁塞避免階段，只要出現(xiàn)超時(shí)（即很可能出現(xiàn)了網(wǎng)絡(luò)擁塞），就把慢開(kāi)始門限值ｓｓｔｈｒｅｓｈ減半，即設(shè)置為當(dāng)前的擁塞窗口的一半（與此同時(shí)，執(zhí)行慢開(kāi)始算法）。當(dāng)網(wǎng)絡(luò)頻繁出現(xiàn)擁塞時(shí)，ｓｓｔｈｒｅｓｈ值就下降得很快，以大大減少注入網(wǎng)絡(luò)中的分組數(shù)。而“加法增大”是指執(zhí)行擁塞避免算法后，使擁塞窗口緩慢增大，以防止網(wǎng)絡(luò)過(guò)早出現(xiàn)擁塞。上面兩種算法合起來(lái)常稱為ＡＩＭＤ算法（加法增大乘法減小）。對(duì)這種算法進(jìn)行適當(dāng)修改后，又出現(xiàn)了其他一些改進(jìn)的算法。但使用最廣泛的還是ＡＩＭＤ算法。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ３.快重傳與快恢復(fù)機(jī)制ＴＣＰ在對(duì)網(wǎng)絡(luò)擁塞的判斷上并無(wú)良策，視丟包、數(shù)據(jù)段超時(shí)為擁塞是不嚴(yán)謹(jǐn)?shù)摹＿@將導(dǎo)致在一些不應(yīng)該的時(shí)刻啟動(dòng)擁塞算法?？旎謴?fù)就是在快重傳情況下發(fā)生的，快恢復(fù)算法是對(duì)擁塞控制算法缺陷的修補(bǔ)或改進(jìn)。我們首先看快重傳的應(yīng)用情景。快重傳算法首先要求接收方每收到一個(gè)失序的數(shù)據(jù)段后就立即發(fā)出重復(fù)確認(rèn)（為的是使發(fā)送方及早知道有數(shù)據(jù)段沒(méi)有到達(dá)對(duì)方）而不要等待自己發(fā)送數(shù)據(jù)時(shí)才進(jìn)行捎帶確認(rèn)。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ在圖５－１４所示場(chǎng)景中，發(fā)送方連續(xù)發(fā)送了５個(gè)以上的數(shù)據(jù)段。接收方收到了第一個(gè)數(shù)據(jù)段Ｍ１后發(fā)出了確認(rèn)（ＡＣＫ２）。第二個(gè)數(shù)據(jù)段Ｍ２在傳輸中丟失，但后續(xù)數(shù)據(jù)段Ｍ３等都正確到達(dá)了。顯然，接收方不能確認(rèn)Ｍ３。因?yàn)椋停呈鞘盏降氖驍?shù)據(jù)段，如果對(duì)Ｍ３進(jìn)行確認(rèn)，就意味著Ｍ３之前的數(shù)據(jù)段都已經(jīng)正確接收，這里顯然不是。根據(jù)可靠傳輸原理，接收方可以什么都不做。為了實(shí)施快重傳算法，ＴＣＰ規(guī)定，接收方應(yīng)及時(shí)發(fā)送對(duì)Ｍ１的重復(fù)確認(rèn)。同樣，對(duì)后續(xù)到達(dá)的Ｍ４、Ｍ５，接收方收到后，也還要再次發(fā)出對(duì)Ｍ１的重復(fù)確認(rèn)。這就會(huì)讓發(fā)送方收到了接收方的四個(gè)對(duì)Ｍ１的確認(rèn)，其中后三個(gè)都是重復(fù)確認(rèn)。重復(fù)確認(rèn)Ｍ１，即ＡＣＫ２，意味著接收方一再向發(fā)送方索要Ｍ２，說(shuō)明接收方?jīng)]有收到Ｍ２。重復(fù)索要，說(shuō)明Ｍ２的后續(xù)數(shù)據(jù)段到達(dá)了接收方，證明網(wǎng)絡(luò)是通暢的；在網(wǎng)絡(luò)通暢的情況下Ｍ２沒(méi)有到達(dá)，意味著Ｍ２丟失，聰明的發(fā)送方應(yīng)該能意識(shí)到這點(diǎn)。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ按照一般的ＴＣＰ重傳規(guī)定，Ｍ２丟失需要依據(jù)超時(shí)來(lái)判斷，計(jì)時(shí)器超時(shí)后才重發(fā)。但這時(shí)還不到Ｍ２超時(shí)時(shí)間。如果繼續(xù)等待其超時(shí)再重發(fā)，很顯然，接收方會(huì)因?yàn)椋停踩毕荒芴幚砗罄m(xù)到達(dá)的數(shù)據(jù)段而“卡”在這里。此時(shí)，發(fā)送方聰明的做法應(yīng)該是：在連續(xù)收到三個(gè)重復(fù)確認(rèn)后立即重傳數(shù)據(jù)段Ｍ２，而不必等待Ｍ２的重傳計(jì)時(shí)器到期。這種算法，我們稱作快重傳。據(jù)統(tǒng)計(jì)，快重傳可以使整個(gè)網(wǎng)絡(luò)的吞吐量提高約２０％。與快重傳配合使用的快恢復(fù)算法有以下兩個(gè)要點(diǎn)：（１）當(dāng)發(fā)送方連續(xù)收到三個(gè)重復(fù)確認(rèn)時(shí)，就執(zhí)行“乘法減小”算法，把慢開(kāi)始門限ｓｓ?ｔｈｒｅｓｈ減半，啟動(dòng)擁塞算法；上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ（２）與慢開(kāi)始不同的是此時(shí)并不將擁塞窗口ｃｗｎｄ設(shè)置為１，即不執(zhí)行慢開(kāi)始算法，而是把ｃｗｎｄ值設(shè)置為新的慢開(kāi)始門限ｓｓｔｈｒｅｓｈ值，然后開(kāi)始執(zhí)行擁塞避免算法，即讓擁塞窗口從線性增長(zhǎng)開(kāi)始。很顯然，快恢復(fù)的使用是必要的，是對(duì)擁塞控制算法的補(bǔ)充與改進(jìn)。這樣，快重傳就把擁塞超時(shí)與偶然丟失超時(shí)兩種情況區(qū)分開(kāi)了。對(duì)于偶然丟失，使用快重傳、快恢復(fù)。對(duì)于擁塞超時(shí)事件，后續(xù)分組也都會(huì)被丟棄，因接收方一直不能收到而超時(shí)重發(fā)。當(dāng)然，此時(shí)的重發(fā)從慢開(kāi)始執(zhí)行是很有必要的。因?yàn)榫W(wǎng)絡(luò)上已經(jīng)積累了大量的分組，大量的重發(fā)會(huì)加劇網(wǎng)絡(luò)擁塞，形成惡性循環(huán)。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ５.２.５超時(shí)時(shí)間的確定從上述章節(jié)討論可見(jiàn)，網(wǎng)絡(luò)數(shù)據(jù)段的超時(shí)計(jì)時(shí)器有重要作用，可以用它判斷丟失觸發(fā)重傳，判斷擁塞觸發(fā)擁塞算法的執(zhí)行，進(jìn)而影響到整個(gè)系統(tǒng)的效率與穩(wěn)定，非同小可。然而，在現(xiàn)實(shí)實(shí)現(xiàn)中，超時(shí)時(shí)間的合理設(shè)定卻是一個(gè)模糊難題，是ＴＣＰ最復(fù)雜的問(wèn)題之一。之所以難以確定，這是因?yàn)?，作為用戶“秘?shū)”的ＴＣＰ是不出單位的，存在于主機(jī)上，并不了解網(wǎng)絡(luò)的遠(yuǎn)近、擁塞情況，只能根據(jù)數(shù)據(jù)傳輸?shù)耐禃r(shí)延ＲＴＴ來(lái)推測(cè)。而每次發(fā)送數(shù)據(jù)的目的主機(jī)的物理距離不同、網(wǎng)絡(luò)帶寬不同、時(shí)間段不同、網(wǎng)絡(luò)繁忙狀態(tài)不同，這都導(dǎo)致每次發(fā)送數(shù)據(jù)時(shí)的往返時(shí)延不同。所以即使用ＲＴＴ作參照也很難估算出超時(shí)時(shí)間的合理定值。當(dāng)然，使用ＲＴＴ作參照是最可行的辦法。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ如果把超時(shí)重傳時(shí)間設(shè)置得太短，就會(huì)引起很多數(shù)據(jù)段的不必要的重傳，使網(wǎng)絡(luò)負(fù)荷增大。但若把超時(shí)重傳時(shí)間設(shè)置得過(guò)長(zhǎng)，則又使網(wǎng)絡(luò)的空閑時(shí)間增大，降低了傳輸效率。傳輸層的超時(shí)計(jì)時(shí)器的超時(shí)重傳時(shí)間究竟應(yīng)如何確定，設(shè)置為多大呢？ＴＣＰ設(shè)計(jì)者采用了一種自適應(yīng)算法，它根據(jù)網(wǎng)絡(luò)性能的連續(xù)測(cè)量情況，不斷地調(diào)整超時(shí)間隔。通常采用的是Ｊａｃｏｂｓｏｎ算法。對(duì)于每一個(gè)連接，ＴＣＰ維護(hù)一個(gè)變量ＳＲＴＴ（ＳｍｏｏｔｈｅｄＲｏｕｎｄ?ＴｒｉｐＴｉｍｅ，平滑的往返時(shí)間），即加權(quán)平均ＲＴＴ。它代表到達(dá)接收方往返時(shí)間的當(dāng)前最佳估計(jì)值。當(dāng)一個(gè)段被發(fā)送出去時(shí)，ＴＣＰ啟動(dòng)一個(gè)計(jì)時(shí)器，該計(jì)時(shí)器有兩個(gè)作用：一是看該段被確認(rèn)需要多長(zhǎng)時(shí)間；二是若確認(rèn)時(shí)間太長(zhǎng)，則觸發(fā)重傳動(dòng)作。如果在計(jì)時(shí)器超時(shí)前確認(rèn)返回，則ＴＣＰ測(cè)量這次確認(rèn)所花的時(shí)間，即本次傳輸?shù)模遥裕裕洖椋?，我們用Ｒ作最新ＲＴＴ樣本，根?jù)下面原則確定新ＳＲＴＴ。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ在采集往返時(shí)間的樣值Ｒ過(guò)程中有可能引發(fā)的一個(gè)問(wèn)題是，當(dāng)一個(gè)段超時(shí)并重新發(fā)送，以后該怎么辦？確認(rèn)到達(dá)時(shí)，無(wú)法判斷該確認(rèn)是針對(duì)第一次傳輸，還是針對(duì)后來(lái)的重傳，如圖５－１５所示。若猜測(cè)錯(cuò)誤，則會(huì)嚴(yán)重影響重傳超時(shí)值。ＰｈｉｌＫａｒｎ發(fā)現(xiàn)這個(gè)問(wèn)題很艱難。Ｋａｒｎ是一名業(yè)余無(wú)線電愛(ài)好者，他對(duì)在一種極不可靠的無(wú)線介質(zhì)上傳輸ＴＣＰ／ＩＰ數(shù)據(jù)包有濃厚的興趣。他提出了一個(gè)很簡(jiǎn)單的建議：不更新任何重傳段的估算值ＳＲＴＴ。此外，每次連續(xù)重傳的超時(shí)時(shí)間值加倍，直到段能收到一次確認(rèn)為止。這個(gè)修正算法稱為Ｋａｒｎ算法（Ｋａｒｎ和Ｐａｒｔｒｉｄｇｅ，１９８７）。大多數(shù)ＴＣＰ實(shí)現(xiàn)都采用了此算法。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ５.２.６ＴＣＰ的連接管理ＴＣＰ的連接管理是指ＴＣＰ連接的建立、拆除和維護(hù)。傳輸連接的管理就是使傳輸連接的建立和釋放都能正常地進(jìn)行。ＴＣＰ是面向連接的協(xié)議。ＴＣＰ數(shù)據(jù)傳輸過(guò)程有三個(gè)階段，即建立連接、數(shù)據(jù)傳送和釋放連接。下面我們分別分析建立連接、釋放連接的作用和做法。１.建立連接我們首先要搞清，為什么要建立一個(gè)ＴＣＰ連接？上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ簡(jiǎn)單地說(shuō)，就是為了通信的可靠。根據(jù)５.２.１節(jié)的闡述，ＴＣＰ連接是一個(gè)虛連接，其實(shí)質(zhì)是通信雙方維持一個(gè)狀態(tài)記錄，跟蹤和記錄數(shù)據(jù)傳輸，以防出錯(cuò)；或者說(shuō)，即使出錯(cuò)也能核查出來(lái)加以糾正。建立連接的實(shí)質(zhì)一方面就是確認(rèn)對(duì)方的存在，并讓接收方做好接收數(shù)據(jù)的準(zhǔn)備，即申請(qǐng)緩沖區(qū)、數(shù)據(jù)結(jié)構(gòu)等資源；另一方面就是對(duì)通信狀態(tài)進(jìn)行初始化，這是通過(guò)建立連接的參數(shù)協(xié)商實(shí)現(xiàn)的，如確定數(shù)據(jù)流的起始序號(hào)、商定數(shù)據(jù)段的大小、確定最大窗口值、是否使用窗口擴(kuò)大選項(xiàng)和時(shí)間戳選項(xiàng)以及服務(wù)質(zhì)量等。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ用ＴＣＰ連接傳輸數(shù)據(jù)時(shí)，首先要建立連接，建立連接須由一方主動(dòng)發(fā)起，另一方響應(yīng)才能完成。主動(dòng)發(fā)起連接建立的應(yīng)用進(jìn)程叫作客戶（ｃｌｉｅｎｔ），而被動(dòng)等待連接建立的應(yīng)用進(jìn)程叫作服務(wù)器（ｓｅｒｖｅｒ）。在因特網(wǎng)上，要和另一主機(jī)進(jìn)程建立ＴＣＰ連接，必須知道對(duì)方主機(jī)的ＩＰ地址和進(jìn)程的端口號(hào)。因特網(wǎng)上最常用的方式是客戶機(jī)訪問(wèn)服務(wù)器，由客戶機(jī)發(fā)起連接，服務(wù)器端服務(wù)進(jìn)程一直監(jiān)聽(tīng)在服務(wù)端口。服務(wù)器的ＩＰ可以通過(guò)域名鍵入，服務(wù)器的端口號(hào)使用默認(rèn)熟知端口號(hào)，所以客戶端能夠聯(lián)系上服務(wù)器。ＴＣＰ使用三次握手協(xié)議來(lái)建立連接。圖５－１６給出了ＴＣＰ的建立連接的三個(gè)過(guò)程。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ主機(jī)Ａ首先發(fā)起ＴＣＰ連接請(qǐng)求（第一次握手），并將所發(fā)送的數(shù)據(jù)段頭部字段中的ＳＹＮ標(biāo)志置為１、ＡＣＫ標(biāo)志置為０，同時(shí)選擇一個(gè)初始序號(hào)ｓｅｑ＝ｘ，表明發(fā)送方字節(jié)流的起始序號(hào)是ｘ。主機(jī)Ｂ收到連接請(qǐng)求數(shù)據(jù)段后，如果同意建立連接，則發(fā)回一個(gè)連接請(qǐng)求確認(rèn)。在確認(rèn)數(shù)據(jù)段中應(yīng)把ＳＹＮ位和ＡＣＫ位都置１，確認(rèn)號(hào)是ａｃｋ＝ｘ＋１，同時(shí)也為自己選擇一個(gè)初始序號(hào)ｓｅｑ＝ｙ。完成了連接建立的第二次握手。ＴＣＰ客戶進(jìn)程收到Ｂ的確認(rèn)后，還要向Ｂ給出確認(rèn)。確認(rèn)數(shù)據(jù)段的ＡＣＫ置１，確認(rèn)號(hào)ａｃｋ＝ｙ＋１，而自己的序號(hào)ｓｅｑ＝ｘ＋１。ＴＣＰ的標(biāo)準(zhǔn)規(guī)定，ＡＣＫ數(shù)據(jù)段可以攜帶數(shù)據(jù)。但如果不攜帶數(shù)據(jù)則不消耗序號(hào)，在這種情況下，下一個(gè)數(shù)據(jù)段的序號(hào)仍是ｓｅｑ＝ｘ＋１。至此ＴＣＰ連接已經(jīng)建立。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ２.釋放連接數(shù)據(jù)都傳輸完了，釋放連接對(duì)可靠傳輸還有影響嗎？還有什么意義？答案是肯定的，首先有序地釋放連接防止了因連接中斷而導(dǎo)致的數(shù)據(jù)傳輸丟失；其次，ＴＣＰ通過(guò)釋放連接讓對(duì)方知道，發(fā)送方的數(shù)據(jù)發(fā)送全部完成，接收方不必再等待，不必再維持傳輸狀態(tài)參數(shù)，不必再保留接收緩沖區(qū)等系統(tǒng)資源?？梢?jiàn)，數(shù)據(jù)傳輸完成后，ＴＣＰ要進(jìn)行連接的拆除或釋放。ＴＣＰ連接是全雙工的，可以看作兩個(gè)不同方向的單工數(shù)據(jù)流傳輸。所以一個(gè)完整連接的拆除涉及兩個(gè)單向連接的拆除。釋放連接的過(guò)程分兩部分，如圖５－１７所示。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰＡ的應(yīng)用進(jìn)程先向其ＴＣＰ發(fā)出連接釋放數(shù)據(jù)段，并停止再發(fā)送數(shù)據(jù)，主動(dòng)關(guān)閉ＴＣＰ連接。Ａ把連接釋放數(shù)據(jù)段首部的ＦＩＮ置１，其序號(hào)ｓｅｑ＝ｕ，它等于前面已傳送過(guò)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加１。等待Ｂ的確認(rèn)。請(qǐng)注意，ＴＣＰ規(guī)定，ＦＩＮ數(shù)據(jù)段即使不攜帶數(shù)據(jù)，它也消耗掉一個(gè)序號(hào)。Ｂ收到連接釋放數(shù)據(jù)段后即發(fā)出確認(rèn)，確認(rèn)號(hào)是ａｃｋ＝ｕ＋１，而這個(gè)數(shù)據(jù)段自己的序號(hào)是ｖ，等于Ｂ前面已傳送過(guò)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加１。ＴＣＰ服務(wù)器進(jìn)程這時(shí)應(yīng)通知高層應(yīng)用進(jìn)程，因而從Ａ到Ｂ這個(gè)方向的連接就釋放了，這時(shí)的ＴＣＰ連接處于半關(guān)閉（ｈａｌｆｃｌｏｓｅ）狀態(tài)，即Ａ已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了，但Ｂ若發(fā)送數(shù)據(jù)，Ａ仍要接收。也就是說(shuō)，從Ｂ到Ａ這個(gè)方向的連接并未關(guān)閉，這個(gè)狀態(tài)可能會(huì)持續(xù)一些時(shí)間。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ若Ｂ已經(jīng)沒(méi)有要向Ａ發(fā)送的數(shù)據(jù)，其應(yīng)用進(jìn)程就通知ＴＣＰ釋放連接。這時(shí)Ｂ發(fā)出的連接釋放數(shù)據(jù)段必須使ＦＩＮ＝１?，F(xiàn)假定Ｂ的序號(hào)為ｍ（在半關(guān)閉狀態(tài)Ｂ可能又發(fā)送了一些數(shù)據(jù)），Ｂ還必須重復(fù)上次已發(fā)送過(guò)的確認(rèn)號(hào)ａｃｋ＝ｕ＋１，等待Ａ的確認(rèn)。Ａ在收到Ｂ的連接釋放數(shù)據(jù)段后，必須對(duì)此發(fā)出確認(rèn)。在確認(rèn)數(shù)據(jù)段中把ＡＣＫ置１，確認(rèn)號(hào)ａｃｋ＝ｍ＋１，而自己的序號(hào)是ｓｅｑ＝ｕ＋１。請(qǐng)注意，現(xiàn)在ＴＣＰ連接還沒(méi)有釋放掉。必須經(jīng)過(guò)時(shí)間等待計(jì)時(shí)器（ＴＩＭＥ－ＷＡＩＴｔｉｍｅｒ）設(shè)置的時(shí)間２ＭＳＬ后，Ａ才能釋放連接。一旦當(dāng)兩個(gè)單向連接都被關(guān)閉，兩個(gè)端結(jié)點(diǎn)上的ＴＣＰ軟件就要?jiǎng)h除與這個(gè)連接有關(guān)記錄，原先所建立的ＴＣＰ連接才被完全釋放。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ５.２.７ＴＣＰ可靠傳輸?shù)膶?shí)現(xiàn)綜上所述，ＴＣＰ的工作過(guò)程是很復(fù)雜的，以上也僅講了其主要實(shí)現(xiàn)過(guò)程，實(shí)現(xiàn)中的許多細(xì)節(jié)問(wèn)題還需要討論。至此，大家應(yīng)該思考一個(gè)問(wèn)題，那就是，ＴＣＰ做的這么復(fù)雜，究竟是為什么？ＴＣＰ中眾多工作機(jī)制都是為什么目的而設(shè)置？答案只有一個(gè)，那就是可靠傳輸。ＴＣＰ的目標(biāo)只有一個(gè)，所有的機(jī)制都是為此而工作的。不是嗎？這些機(jī)制包括以下幾種。（１）ＴＣＰ的連接機(jī)制：讓通信雙方協(xié)商參數(shù)，達(dá)成初始狀態(tài)，讓通信雙方主機(jī)系統(tǒng)分配資源做好接收準(zhǔn)備，跟蹤記錄通信狀態(tài)的演變，保證各個(gè)機(jī)制協(xié)調(diào)有序地進(jìn)行，最后有序地釋放連接，確保數(shù)據(jù)在最后的傳輸階段不丟失，避免因拆除連接而導(dǎo)致數(shù)據(jù)丟失。上一頁(yè)下一頁(yè)返回５.２傳輸控制協(xié)議ＴＣＰ（２）差錯(cuò)檢驗(yàn)機(jī)制：發(fā)現(xiàn)傳輸過(guò)程中出現(xiàn)的比特錯(cuò)誤。（３）應(yīng)答機(jī)制：應(yīng)答的目的是把接收情況反饋給發(fā)送方，以便讓發(fā)送方重發(fā)，通過(guò)重發(fā)改正傳輸錯(cuò)誤。同時(shí)，應(yīng)答機(jī)制也保證了丟失的數(shù)據(jù)包、超時(shí)的數(shù)據(jù)包得到重發(fā)。（４）重傳機(jī)制：重傳是更正傳輸錯(cuò)誤的機(jī)制，也是為了找回丟失數(shù)據(jù)包和因超時(shí)而失效的數(shù)據(jù)包。（５）序號(hào)機(jī)制：序號(hào)機(jī)制保證了最終接收方的有序接收，在ＩＰ傳輸