【筆記】謝希仁—計網(wǎng)五版:chapter five 運輸層(一)

本章討論TCP/IP體系中運輸層最重要的兩種協(xié)議:UDP和TCP科阎。必須弄清TCP的各種機制(如面向連接的可靠服務(wù)述吸、流量控制、擁塞控制等)锣笨,以及TCP連接管理和狀態(tài)圖的概念蝌矛。

一、運輸層協(xié)議概述

1.進程之間的通信

IP協(xié)議是把分組送到目的主機错英,但這個分組還停留在主機的網(wǎng)絡(luò)層而沒有交付給主機中的應(yīng)用進程入撒。從運輸層角度看,通信的真正端點并不是主機而是主機中的進程椭岩。

復(fù)用(multiplexing)——發(fā)送方不同的應(yīng)用進程都可以使用同一個運輸層協(xié)議傳送數(shù)據(jù)(當(dāng)然需要加上適當(dāng)?shù)氖撞浚?/p>

分用(demultiplexing)——接收方的運輸層在剝?nèi)笪牡氖撞亢竽軌虬堰@些數(shù)據(jù)正確交付到目的應(yīng)用進程茅逮。

運輸層提供應(yīng)用進程間的邏輯通信:指運輸層之間的通信好像是沿水平方向傳送數(shù)據(jù),但事實上這兩個運輸層之間并沒有一條水平方向的物理連接簿煌。要傳送的數(shù)據(jù)是沿著圖中的虛線方向(經(jīng)過多個層次)傳送的氮唯。

運輸層還要對收到的報文進行差錯檢測。在網(wǎng)絡(luò)層姨伟,IP數(shù)據(jù)報首部中的檢驗和字段惩琉,只檢驗首部是否出現(xiàn)差錯而不檢查數(shù)據(jù)部分。

兩種不同協(xié)議:①面向連接的TCP:盡管下面的網(wǎng)絡(luò)是不可靠的(只提供盡最大努力服務(wù))夺荒,但這種邏輯通信信道就相當(dāng)于一條全雙工的可靠信道瞒渠。②無連接的UDP協(xié)議:仍是不可靠信道。

2.運輸層的兩個主要協(xié)議

(1)用戶數(shù)據(jù)報協(xié)議UDP(user datagram protocol)

在傳送數(shù)據(jù)之前不需要先建立連接技扼,遠地主機的運輸層在收到UDP報文后伍玖,不需要給出任何確認。不提供可靠支付剿吻。

(2)傳輸控制協(xié)議TCP(transmission control protocol)

提供可靠的窍箍、面向連接的服務(wù)。在傳送數(shù)據(jù)之前必須先建立連接,數(shù)據(jù)傳送后要釋放連接椰棘。不提供廣播或多播服務(wù)纺棺。

兩種協(xié)議在協(xié)議棧中的位置

按OSI術(shù)語,兩個對等運輸實體在通信時傳送的數(shù)據(jù)單位叫作運輸協(xié)議數(shù)據(jù)單元TPDU(transport protocol data unit)邪狞。但在TCP/IP體系中祷蝌,則根據(jù)所使用的協(xié)議是TCP或UDP,分別稱之為TCP報文段或UDP用戶數(shù)據(jù)報帆卓。

3.運輸層的端口

Ⅰ巨朦、運輸層的復(fù)用——應(yīng)用層所有的應(yīng)用進程都可以通過運輸層再傳到IP層

運輸層的分用——運輸層從IP層收到數(shù)據(jù)后必須交付給指明的應(yīng)用進程

Ⅱ、為什么要在運輸層使用協(xié)議端口號(protocol port number剑令,或端口)糊啡?

給應(yīng)用層的每個應(yīng)用進程賦予一個非常明確的標(biāo)志很重要好乐。在單個計算機中的進程是用進程標(biāo)識符來標(biāo)志的弄慰。但在因特網(wǎng)環(huán)境下把鉴,就不行了南用,因為在因特網(wǎng)上使用的計算機的操作系統(tǒng)種類很多,而不同的操作系統(tǒng)又使用不同格式的進程標(biāo)志符番捂。為了使運行不同操作系統(tǒng)的計算機的應(yīng)用進程能夠互相通信,就必須用統(tǒng)一的方法(而這種方法必須與特定操作系統(tǒng)無關(guān))對TCP/IP體系的應(yīng)用進程進行標(biāo)志。

但是潮酒,把一個特定機器上運行的特定進程指明為因特網(wǎng)上通信最后的終點還是不可行的。這是因為進程的創(chuàng)建和撤銷都是動態(tài)的邪蛔,通信的一方幾乎無法識別對方機器上的進程急黎。另外,我們往往需要利用目的主機提供的功能來識別終點侧到,而不需要知道具體實現(xiàn)這個功能的進程是哪一個勃教。

解決這個問題的方法就是在運輸層使用協(xié)議端口號。雖然通信的終點是應(yīng)用進程匠抗,但我們只要把要傳送的報文交到目的主機的某一個合適的目的端口故源,剩下的工作(即最后交付給目的進程)就由TCP來完成

Ⅲ汞贸、端口認知

這種在協(xié)議棧層間抽象的協(xié)議端口是軟件端口绳军,軟件端口是應(yīng)用層的各種協(xié)議進程與運輸實體進行層間交互的一種地址。

路由器或交換機上的硬件端口是不同硬件設(shè)備進行交互的接口矢腻。

Ⅳ门驾、端口號

只具有本地意義,只是為了標(biāo)志本計算機應(yīng)用層中的各個進程和運輸層交互時的層間接口多柑。在因特網(wǎng)不同計算機中奶是,相同的端口號是沒有關(guān)聯(lián)的。

兩計算機中的進程通信時,不僅需要知道對方的IP地址(為了找到對方的計算機)聂沙,還要知道對方的端口號(為了找到對方計算機中的應(yīng)用進程)秆麸。因特網(wǎng)上的計算機通信采用客戶—服務(wù)器方式,于是運輸層的端口號可分為:

(1)服務(wù)器端使用的端口號

熟知端口號(well-known port number)或系統(tǒng)端口號

IANA把這些端口號指派給了TCP/IP最重要的一些應(yīng)用程序逐纬,讓所有的客戶都知道蛔屹。當(dāng)一種新的應(yīng)用程序出現(xiàn)后,IANA必須為它指派一個熟知端口豁生,否則因特網(wǎng)上的其他應(yīng)用進程就無法和它進行通信兔毒。

登記端口號

是為沒有熟知端口號的應(yīng)用程序使用的,使用這類端口號必須在IANA按照規(guī)定的手續(xù)登記甸箱,以防止重復(fù)育叁。

(2)客戶端使用的端口號(短暫端口號)

僅在客戶進程運行時才動態(tài)選擇,留給客戶進程選擇時暫時使用芍殖。當(dāng)服務(wù)器進程收到客戶進程的報文時豪嗽,就知道了客戶進程所使用的端口號,因而可以把數(shù)據(jù)發(fā)送給客戶進程豌骏。通信結(jié)束后龟梦,剛才已使用過的客戶端口號就不復(fù)存在。這個端口號就可以供其他客戶進程以后使用窃躲。

二计贰、用戶數(shù)據(jù)報協(xié)議UDP

1.UDP概述

只在IP的數(shù)據(jù)服務(wù)之上增加了很少一點功能,這就是復(fù)用和分用蒂窒、差錯檢測躁倒。

主要特點:(1)無連接的。發(fā)送數(shù)據(jù)之前不需要建立連接(發(fā)送完可釋放)(2)使用盡最大努力交付洒琢,即不保證可靠交付秧秉,主機不需要維持復(fù)雜的連接狀態(tài)表。(3)面向報文的衰抑。UDP一次交付一個完整的報文象迎,因此應(yīng)用程序必須選擇合適大小的報文。若報文太長呛踊,UDP把它交給IP層后挖帘,IP層在傳送時可能要進行分片,這會降低IP層的效率恋技。反之拇舀,若報文太短,UDP把它交給IP層后蜻底,會使IP層的首部的相對長度太大骄崩,這也降低了IP層的效率聘鳞。

(4)沒有堵塞控制

網(wǎng)絡(luò)出現(xiàn)的堵塞不會使源主機的發(fā)送速率降低,這對某些實時應(yīng)用很重要要拂,比如實時視頻會議要求源主機以恒定的速率發(fā)送數(shù)據(jù)抠璃,并且允許在網(wǎng)絡(luò)發(fā)生堵塞時丟失一些數(shù)據(jù),但卻不允許數(shù)據(jù)有太大的時延脱惰。

但當(dāng)很多源主機同時向網(wǎng)絡(luò)發(fā)送高速率的實時視頻流時搏嗡,網(wǎng)絡(luò)就有可能發(fā)生堵塞,結(jié)果大家都無法正常接收拉一。還有些實時應(yīng)用需要對它的不可靠傳輸進行適當(dāng)?shù)母脑觳珊校詼p少數(shù)據(jù)的丟失。

(5)支持一對一蔚润、一對多磅氨、多對一、多對多的交互通信

(6)首部開銷小嫡纠,只有8個字節(jié)

2.UDP的首部格式

用戶數(shù)據(jù)報UDP有兩個字段:數(shù)據(jù)字段和首部字段烦租。首部字段很簡單,只有8個字節(jié)除盏,由四個字段組成叉橱,每個字段的長度都是兩個字節(jié)。各字段:

(1)源端口:源端口號者蠕,在需要對方回信時選用赏迟,不需要時可用全0。

(2)目的端口:目的端口號蠢棱,這在終點交付報文時必須要使用到。

(3)長度:UDP用戶數(shù)據(jù)報的長度甩栈,其最小值是8(只有首部)泻仙。

(4)檢驗和:檢測UDP用戶數(shù)據(jù)報在傳輸中是否有差錯,有錯就丟棄量没。

當(dāng)運輸層從IP層收到UDP數(shù)據(jù)報時玉转,就根據(jù)首部中的目的端口,把UDP數(shù)據(jù)報通過相應(yīng)的端口殴蹄,上交最后的終點——應(yīng)用進程究抓。下圖是UDP基于端口的分用的示意圖。

如果接收方UDP發(fā)現(xiàn)收到的報文中的目的端口號不正確(即不存在對應(yīng)于該端口號的應(yīng)用進程)袭灯,就丟棄該報文刺下,并由ICMP發(fā)送“端口不可達”差錯報文給發(fā)送方。我們在上一章4.4.2節(jié)討論traceroute時稽荧,就是讓發(fā)送的UDP用戶數(shù)據(jù)報故意使用一個非法的UDP端口橘茉,結(jié)果ICMP就返回“端口不可達”差錯報文,因而達到了測試的目的。

檢驗和的計算方法:

(1)偽首部——12字節(jié)畅卓,它不是UDP用戶數(shù)據(jù)報真正的首部擅腰,只是用于計算檢驗和而臨時添加的,它既不向下傳送也不向上遞交翁潘。

(2)和IP數(shù)據(jù)報首部檢驗和的方法的不同——IP數(shù)據(jù)報的檢驗和只檢驗IP數(shù)據(jù)報的首部趁冈,而UDP的檢驗和是把首部和數(shù)據(jù)部分一起都檢驗。

(3)發(fā)送方——先把全零放入檢驗和字段拜马,再把偽首部以及UDP用戶數(shù)據(jù)報看成是由許多16位的字串接起來渗勘。若UDP用戶數(shù)據(jù)報的數(shù)據(jù)部分不是偶數(shù)個字節(jié),則要填入一個全零字節(jié)(但此字節(jié)不發(fā)送)一膨。然后按二進制反碼計算出這些16位字的和呀邢。將此和的二進制反碼寫入檢驗和字段后,就發(fā)送這樣的UDP用戶數(shù)據(jù)報豹绪。

(4)接收方——把收到的UDP用戶數(shù)據(jù)報連同偽首部(以及可能的填充全零字節(jié))一起价淌,按二進制反碼求這些16位字的和。當(dāng)無差錯時結(jié)果應(yīng)全1瞒津。否則就表明有差錯實現(xiàn)蝉衣,接收方就丟棄這個UDP用戶數(shù)據(jù)報(也可以上交給應(yīng)用層,但附上出現(xiàn)差錯的警告)巷蚪。

(5)評價——檢錯能力不強病毡,但簡單、處理起來較快屁柏。

偽首部的第3字段全是0啦膜,第4字段是IP首部中的協(xié)議字段的值。以前已講過淌喻,對于UDP僧家,此協(xié)議字段值為17。第5字段是UDP用戶數(shù)據(jù)報的長度裸删。因此八拱,這樣的檢驗和,既檢查了UDP用戶數(shù)據(jù)報的源端口和目的端口號以及UDP用戶數(shù)據(jù)報的數(shù)據(jù)部分涯塔,又檢查了IP數(shù)據(jù)報的源IP地址和目的地址肌稻。

接收方例子

三、傳輸控制協(xié)議TCP概述

1.TCP最重要的特點

(1)是面向連接的運輸層協(xié)議:傳送數(shù)據(jù)完畢后匕荸,必須釋放已建立的TCP連接爹谭。

(2)每一條TCP連接只能有兩個端點(endpoint),每一條TCP連接只能是點對點的榛搔。

(3)提供可靠交付的服務(wù)——無差錯旦棉、不丟失齿风、不重復(fù)、且按序到達绑洛。

(4)全雙工通信——TCP允許通信雙方的應(yīng)用進程在任何時候都能發(fā)送數(shù)據(jù)救斑,TCP連接的兩端都設(shè)有發(fā)送緩存和接收緩存,用來臨時存放雙向通信的數(shù)據(jù)真屯。

(5)面向字節(jié)流

“流”是指流入到進程或從進程流出的字節(jié)序列脸候。面向字節(jié)流的含義是:雖然應(yīng)用程序和TCP的交互是一次一個數(shù)據(jù)塊(大小不等),但TCP把應(yīng)用程序交下來的數(shù)據(jù)看成僅僅是一連串的無結(jié)構(gòu)的字節(jié)流绑蔫。TCP并不知道所傳送的字節(jié)流的含義运沦,它不保證接收方應(yīng)用程序所收到的數(shù)據(jù)塊和發(fā)送方應(yīng)用程序所發(fā)出的數(shù)據(jù)塊具有對應(yīng)大小的關(guān)系(例如,發(fā)送方應(yīng)用程序交給發(fā)送方的TCP共10個數(shù)據(jù)塊配深,但接收方的TCP可能只用了4個數(shù)據(jù)塊就把收到的字節(jié)流交付給了上層的應(yīng)用程序)携添。但接收方應(yīng)用程序收到的字節(jié)流必須和發(fā)送方應(yīng)用程序發(fā)出的字節(jié)流完全一樣。當(dāng)然篓叶,接收方的應(yīng)用程序必須有能力識別收到的字節(jié)流烈掠,把它還原成有意義的應(yīng)用層數(shù)據(jù)

解釋上圖:TCP連接是一條虛連接而不是一條真正的物理連接缸托。TCP報文段先要傳送到IP層左敌,加上IP首部后,再傳送到數(shù)據(jù)鏈路層俐镐。再加上數(shù)據(jù)鏈路層的首部和尾部后矫限,才離開主機發(fā)送到物理鏈路。

TCP和UDP在發(fā)送報文時采用的方式完全不同佩抹。TCP對應(yīng)用程序一次把多長的報文發(fā)送到TCP的緩存中是不關(guān)心的叼风。TCP根據(jù)對方給出的窗口值和當(dāng)前網(wǎng)絡(luò)擁塞的程度來決定一個報文段應(yīng)包含多少個字節(jié)(UDP發(fā)送的報文長度是應(yīng)用進程給出的)。如果應(yīng)用進程傳送到TCP緩存的數(shù)據(jù)塊太長棍苹,TCP就可以把它劃分短一些再傳送无宿。如果應(yīng)用進程一次只發(fā)來一個字節(jié),TCP也可以等待積累有足夠多的字節(jié)后再構(gòu)成報文段發(fā)送出去廊勃。

2.TCP的連接

TCP把連接作為最基本的抽象,TCP的許多特性都與TCP是面向連接的這個基本特性有關(guān)经窖。

每一條TCP連接有兩個端點坡垫,它不是主機、不是主機的IP地址画侣、不是應(yīng)用進程冰悠、不是運輸層的協(xié)議端口,而是套接字(是端口號拼接到IP地址即構(gòu)成了套接字)配乱。套接字socket=(IP地址:端口號)

每一條TCP連接唯一地被通信兩端的兩個端點(即兩個套接字)所確定溉卓。即:

TCP連接::={socket1皮迟,socket2}={(IP1:port1),(IP2:port2)}

TCP連接就是由協(xié)議軟件所提供的一種抽象桑寨,是應(yīng)用進程之間建立的伏尼。TCP連接的端點是套接字,即(IP地址:端口號)尉尾。同一個IP地址可以有很多個不同的TCP連接爆阶,而同一個端口號也可以出現(xiàn)在多個不同的TCP連接中

注意:socket有很多意思沙咏。

四辨图、可靠傳輸?shù)墓ぷ髟?/h3>

TCP發(fā)送的報文段是交給IP層傳送的,但IP層只能提供盡最大努力服務(wù)肢藐,也就是說故河,TCP下面的網(wǎng)絡(luò)所提供的是不可靠傳輸。TCP必須采用適當(dāng)?shù)拇胧┎拍苁沟脙蓚€運輸層之間的通信變得可靠吆豹。

理想傳輸條件有:①傳輸信道不產(chǎn)生差錯鱼的。②不管發(fā)送方以多快的速度發(fā)送數(shù)據(jù),接收方總是來得及處理收到的數(shù)據(jù)瞻讽。

在這樣的理想傳輸條件下鸳吸,不需要采取任何措施就能實現(xiàn)可靠傳輸。達不到時速勇,我們可以使用可靠傳輸協(xié)議晌砾。當(dāng)出現(xiàn)差錯時讓發(fā)送方重傳出現(xiàn)差錯的數(shù)據(jù),同時在接收方來不及處理收到的數(shù)據(jù)時烦磁,及時告訴發(fā)送方適當(dāng)降低發(fā)送數(shù)據(jù)的速度养匈。

1.停止等待協(xié)議

因為這里是討論可靠傳輸?shù)脑恚虼税褌魉偷臄?shù)據(jù)單元都稱為分組都伪,而不考慮數(shù)據(jù)是在哪一層次上傳送的呕乎。“停止等待”就是每發(fā)送完一個分組就停止發(fā)送陨晶,等待對方的確認猬仁。在收到確認后再發(fā)送下一個分組。

Ⅰ先誉、無差錯情況

A在收到了對M1的確認后湿刽,就再發(fā)送給下一個分組M2。

Ⅱ褐耳、出現(xiàn)差錯

B接收M1時檢測出了差錯诈闺,就丟棄M1,其他什么也不做(不通知A收到有差錯的分組)铃芦,也可能是M1在傳輸過程中丟失了雅镊,這時B當(dāng)然什么都不知道襟雷。在這兩種情況下,B都不會發(fā)送任何信息仁烹∷逝可靠傳輸協(xié)議是這樣設(shè)計的:A只要超過了一段時間仍然沒有收到確認,就認為剛剛發(fā)送的分組丟失了晃危,因而重傳前面發(fā)送過的分組叙赚。這就叫做超時重傳

要實現(xiàn)超時重傳僚饭,就要在每發(fā)送完一個分組設(shè)置一個超時計時器震叮。如果在超時計時器到期之前收到了對方的確認,就撤銷已設(shè)置的超時計時器鳍鸵。在a圖中苇瓣,A為每一個已發(fā)送的分組都設(shè)置了一個超時計時器,但A只要在超時計時器到期之前收到了相應(yīng)的確認偿乖,就撤銷該超時計時器击罪。

注意:①A在發(fā)送完一個分組,必須暫時保留已發(fā)送的分組的副本(為發(fā)生超時重傳時使用)贪薪。只有在收到相應(yīng)的確認后才能清除暫時保留的分組副本媳禁。

分組和確認分組都必須進行編號。這樣才能明確是哪一個發(fā)送出去的分組收到了確認画切,而哪一個分組還沒有收到確認竣稽。

超時計時器設(shè)置的重傳時間應(yīng)當(dāng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r間更長一些。如果重傳時間設(shè)定長了霍弹,通信效率就低毫别;如果短了,產(chǎn)生不必要的重傳典格,浪費了網(wǎng)絡(luò)資源岛宦。設(shè)定準(zhǔn)確的重傳時間是復(fù)雜的,因為已發(fā)送出的分組到底會經(jīng)過哪些網(wǎng)絡(luò)耍缴,以及時延砾肺,都是不確定因素。

Ⅲ防嗡、確認丟失和確認遲到

圖a:B收到重傳分組M1時变汪,采取兩行動,一是丟棄這個重復(fù)的分組M1本鸣,不向上層支付疫衩;二是向A發(fā)送確認硅蹦,不能認為已經(jīng)發(fā)送過確認就不再發(fā)送荣德,因為A之所以重傳M1就表示A沒有收到對M1的確認闷煤。

圖b:確認遲到了,收到就丟棄涮瞻。如果A不斷重傳分組但總是收不到確認鲤拿,說明通信線路太差,不能進行通信署咽。

使用上述的確認和重傳機制近顷,我們就可以在不可靠的傳輸網(wǎng)絡(luò)上實現(xiàn)可靠的通信。像上述的這種可靠傳輸協(xié)議常稱為自動重傳請求ARQ(automatic repeat reQuest)宁否,意思是重傳的請求是自動進行的窒升。接收方不需要請求發(fā)送方重傳某個出錯的分組。

Ⅳ慕匠、信道利用率

停止等待協(xié)議的優(yōu)點是簡單饱须,但缺點是信道利用率太低。

假定A發(fā)送分組需要的時間是Td(=分組長度/數(shù)據(jù)率)台谊;分組正確到達B后蓉媳,B處理分組的時間可以忽略不計,同時立即發(fā)回確認锅铅;B發(fā)送確認分組需要時間Ta酪呻。如果A處理確認分組的時間也可以忽略不計,那么A在經(jīng)過時間(Td+RTT+Ta)后就可以再發(fā)送下一個分組盐须,這里的RTT是往返時間玩荠。因為僅僅是在時間Td內(nèi)才用來送有用的數(shù)據(jù)(包括分組的首部),因此信道的利用率U可以用下式計算:

為了提高傳輸效率丰歌,發(fā)送方可以不使用低效率的停止等待協(xié)議姨蟋,而是采用流水線傳輸×⑻看下圖眼溶,它就是發(fā)送方可連續(xù)發(fā)送多個分組,不必每發(fā)完一個分組就停下來等待對方的確認晓勇。這樣可使信道上一直有數(shù)據(jù)不間斷地在傳送堂飞。顯然,這樣可獲得很高的信道利用率绑咱。

當(dāng)使用流水線傳輸時绰筛,就要使用下面介紹的連續(xù)ARQ協(xié)議滑動窗口協(xié)議(5.6節(jié)討論)。

2.連續(xù)ARQ協(xié)議

圖a表示發(fā)送方維持的發(fā)送窗口描融,它的意義是:位于發(fā)送窗口內(nèi)的5個分組都可以連續(xù)發(fā)送出去铝噩,而不需要等待對方的確認。這樣提高了信道利用率窿克。

根據(jù)ARQ協(xié)議規(guī)定骏庸,發(fā)送方每收到一個確認毛甲,就把發(fā)送窗口向前滑動一個分組的位置。圖b表示發(fā)送方收到了對第一個分組的確認具被,于是把發(fā)送窗口向前移動一個分組的位置玻募。如果原來已經(jīng)發(fā)送了前5個分組,那么現(xiàn)在就可以發(fā)送窗口內(nèi)的第6個分組了一姿。

接收方一般都是采用累積確認的方式七咧,即在收到幾個分組后,對按序到達的最后一個分組發(fā)送確認叮叹。這樣就表示:到這個分組為止的所有分組都已正確收到了艾栋。

累積確認優(yōu)點:容易實現(xiàn),及時確認丟失也不必重傳蛉顽。缺點:不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息裹粤。

例如,如果發(fā)送方發(fā)送了前5個分組蜂林,而中間的第3個分組丟失了遥诉。這時接收方只能對前兩個分組發(fā)送確認。發(fā)送方無法知道后面三個分組的下落噪叙,而只好把后面的三個分組都再重傳一次矮锈。這就叫作Go-back-N(回退N),表示需要再退回來重傳已發(fā)送過的N個分組睁蕾“浚可見,當(dāng)通信線路質(zhì)量不好時子眶,連續(xù)ARQ協(xié)議會帶來負面的影響瀑凝。

五、TCP報文段的首部格式

TCP雖然是面向字節(jié)流的臭杰,但TCP傳送的數(shù)據(jù)單元卻是報文段粤咪。一個TCP報文段分為首部和數(shù)據(jù)兩部分,而TCP的全部功能都體現(xiàn)在它首部中各字段的作用渴杆。因此寥枝,弄清首部各字段作用才能弄清它的工作原理。

前20字節(jié)固定磁奖,后4N(N是整數(shù))字節(jié)是根據(jù)需要而增加的選項囊拜。

(1)源端口和目的端口:TCP的分用是通過端口實現(xiàn)的。

(2)序號

序號范圍[0,2^32-1]比搭,序號增加到最大值時冠跷,下一個序號就又回到0。TCP是面向字節(jié)流的,在一個TCP連接中傳送的字節(jié)流中的每一個字節(jié)都按順序編號蜜托,整個要傳送的字節(jié)流的起始序號必須在連接建立時設(shè)置弟疆。首部中的序號字段(也叫作報文段序號)值則指的是本報文段所發(fā)送的數(shù)據(jù)的第一個字節(jié)的序號。

(3)確認號:是期望收到對方下一個報文段的第一個數(shù)據(jù)字節(jié)的序號盗冷。若確認號=N,則表明:到序號N-1為止的所有數(shù)據(jù)都已正確收到同廉。

(5)數(shù)據(jù)偏移:占4位仪糖,指出TCP報文段的數(shù)據(jù)起始處距離TCP報文段的起始處有多遠。這個字段實際上指出TCP報文段的首部長度迫肖。(首部中還有長度不確定的選項字段)

(6)保留:占6位锅劝,保留為今后用,但目前設(shè)置為0蟆湖。

(7)緊急URG

當(dāng)URG置1時故爵,發(fā)送應(yīng)用進程就告訴發(fā)送方的TCP有緊急數(shù)據(jù)要傳送。于是發(fā)送方TCP就把緊急數(shù)據(jù)插入到本報文段數(shù)據(jù)的最前面隅津,而在緊急數(shù)據(jù)后面的數(shù)據(jù)仍是普通數(shù)據(jù)诬垂,這時要與首部中緊急指針(urgent pointer)字段配合使用。

(8)確認ACK(ACKnowlegment)

僅當(dāng)ACK置1時伦仍,確認號字段才有效结窘。為0時無效。TCP規(guī)定充蓝,在連接建立后所有傳送的報文段都必須把ACK置1隧枫。

(9)推送PSH(push)

當(dāng)兩個應(yīng)用進程進行交互式的通信時,有時在一端的應(yīng)用進程希望在鍵入一個命令后立即就能夠收到對方的響應(yīng)谓苟。在這種情況下官脓,TCP就可以使用推送(push)操作。這時涝焙,發(fā)送方TCP把PSH置1卑笨,并立即創(chuàng)建一個報文段發(fā)送出去。接收方TCP收到PSH=1的報文段仑撞,就盡快地交付給接收應(yīng)用進程湾趾,而不再等到整個緩存都填滿了后再向上交付。得少用派草。

(10)復(fù)位RST(ReSeT)

為1時表明TCP連接中出現(xiàn)嚴重差錯(如主機崩潰)搀缠,必須釋放連接,然后再重新建立運輸連接近迁。RST置1還用來拒絕一個非法的報文段或拒絕打開一個連接艺普。也成為重建位或重置位。

(11)同步SYN(SYNchronization)

在連接建立時用來同步序號。當(dāng)SYN=1而ACK=0時歧譬,表明這是一個連接請求報文段岸浑。對方若同意建立連接,則應(yīng)在響應(yīng)的報文段中使SYN=1和ACK=1瑰步。因此矢洲,SYN置1就表示這是一個連接請求或連接接受報文

(12)終止FIN(FINis)

用來釋放一個連接缩焦。為1時表明此報文段的發(fā)送方的數(shù)據(jù)已發(fā)送完畢读虏,并要求釋放運輸連接。

(13)窗口

窗口值是[0,2^16-1]之間的整數(shù)袁滥。明確指出了現(xiàn)在允許對方發(fā)送的數(shù)據(jù)量盖桥,窗口值作為接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依據(jù)。有這個限制是因為接收方的數(shù)據(jù)緩存空間是有限的题翻。

(14)檢驗和

檢驗和字段檢驗的范圍包括首部和數(shù)據(jù)這兩部分揩徊。和UDP用戶數(shù)據(jù)報一樣,在計算檢驗和時嵌赠,要在TCP報文段的前面加上12字節(jié)的偽首部塑荒。偽首部的格式與UDP用戶數(shù)據(jù)報的偽首部一樣。但應(yīng)把偽首部第4個字段中的17改為6(TCP的協(xié)議號是6)姜挺,把第5字段中的UDP長度改為TCP長度袜炕。接收方收到此報文段后,仍要加上這個偽首部來計算檢驗和初家。若使用IPv6偎窘,則相應(yīng)的偽首部也要改變。

(15)緊急指針

僅在URG=1時才有意義溜在,指出本報文段中的緊急數(shù)據(jù)的字節(jié)數(shù)(緊急數(shù)據(jù)結(jié)束后就是普通數(shù)據(jù))陌知。當(dāng)所有緊急數(shù)據(jù)處理完時,TCP就告訴應(yīng)用程序恢復(fù)到正常操作掖肋。即使窗口為零時也可以發(fā)送緊急數(shù)據(jù)仆葡。

(16)選項

長度可變,最長可達40字節(jié)志笼。沒有使用選項時沿盅,TCP首部長度是20字節(jié)。有以下幾種:

①最大報文段長度MSS(maximum segment size)

理解——它是每一個TCP報文段中的數(shù)據(jù)字段的最大長度纫溃。數(shù)據(jù)字段加上TCP首部才等于整個的TCP報文段腰涧。所以MSS并不是整個TCP報文段的最大長度,而是“TCP報文段長度減去TCP首部長度”紊浩。

出現(xiàn)緣由——并不是考慮接收方的接收緩存可能放不下TCP報文段中的數(shù)據(jù)窖铡。實際上疗锐,MSS與接收窗口值沒有關(guān)系。我們知道费彼,TCP報文段的數(shù)據(jù)部分滑臊,至少加上40字節(jié)的首部(TCP首部20字節(jié)和IP首部20字節(jié),這里都還沒有考慮首部中的選項部分)箍铲,才能組裝成一個IP數(shù)據(jù)報雇卷。MISS長度小時,網(wǎng)絡(luò)的利用率低颠猴。長度大時关划,IP層傳輸時就有可能要分解成多個短數(shù)據(jù)報片,在終點要把收到的各個短數(shù)據(jù)報片裝配成原來的TCP報文段芙粱。當(dāng)傳輸出錯時要重傳,這些使開銷增大氧映。

因此春畔,MSS應(yīng)盡可能大些,只要在IP層傳輸時不需要再分片就行岛都。而IP數(shù)據(jù)報所經(jīng)歷的路徑是動態(tài)變化的律姨,因此這條路徑不用分片下條路徑可能要分片,于是最佳MSS難確定臼疫。在連接建立過程中择份,雙方都把自己能夠支持的MSS寫入這一字段,以后就按照這個數(shù)值傳送數(shù)據(jù)烫堤,兩個傳送方向可以有不同的MSS值荣赶。若主機未填寫這一項,則MSS的默認值是536字節(jié)長鸽斟。因此拔创,所有在因特網(wǎng)上的主機都應(yīng)能接受的報文段長度是536+20(固定首部長度)=556字節(jié)。

②窗口擴大選項

為了擴大窗口富蓄。占3字節(jié)剩燥,其中有一個字節(jié)表示移位值S。新的窗口值等于TCP首部中的窗口數(shù)從16增大到(16+S)立倍,這相當(dāng)于把窗口值向左移動S位后獲得實際的窗口大小灭红。移位值允許使用的最大值是14,相當(dāng)于窗口最大值增大到2^(16+14)-1口注。

窗口擴大選項可以在雙方初始建立TCP連接時進行協(xié)商变擒。如果連接的某一端實現(xiàn)了窗口擴大,當(dāng)它不再需要擴大其窗口時寝志,可發(fā)送S=0的選項赁项,使窗口大小回到16葛躏。

③時間戳選項

占10字節(jié),最主要的字段時間戳字段(4字節(jié))和時間戳回送回答字段(4字節(jié))悠菜。功能:一是用來計算往返時間RTT撞鹉。發(fā)送方在發(fā)送報文段時把當(dāng)前時鐘的時間值放入時間戳字段,接收方在確認該報文段時把時間戳字段值復(fù)制到時間戳回送回答字段兔甘。因此谣妻,發(fā)送方在收到確認報文后,可以準(zhǔn)確計算出RTT來芬骄。二是處理TCP序號超過2^32的情況猾愿,這又稱為防止序號繞回PAWS(protect against wrapped sequence nambers),可以使接收方能夠把新的報文段和遲到很久的報文段區(qū)分開账阻。

④選擇確認選項

5.6.3節(jié)介紹

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末蒂秘,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子淘太,更是在濱河造成了極大的恐慌姻僧,老刑警劉巖,帶你破解...
    沈念sama閱讀 216,591評論 6 501
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件蒲牧,死亡現(xiàn)場離奇詭異撇贺,居然都是意外死亡,警方通過查閱死者的電腦和手機冰抢,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,448評論 3 392
  • 文/潘曉璐 我一進店門松嘶,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人挎扰,你說我怎么就攤上這事翠订。” “怎么了遵倦?”我有些...
    開封第一講書人閱讀 162,823評論 0 353
  • 文/不壞的土叔 我叫張陵蕴轨,是天一觀的道長。 經(jīng)常有香客問我骇吭,道長橙弱,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,204評論 1 292
  • 正文 為了忘掉前任燥狰,我火速辦了婚禮棘脐,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘龙致。我一直安慰自己蛀缝,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 67,228評論 6 388
  • 文/花漫 我一把揭開白布目代。 她就那樣靜靜地躺著屈梁,像睡著了一般嗤练。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上在讶,一...
    開封第一講書人閱讀 51,190評論 1 299
  • 那天煞抬,我揣著相機與錄音,去河邊找鬼构哺。 笑死革答,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的曙强。 我是一名探鬼主播残拐,決...
    沈念sama閱讀 40,078評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼碟嘴!你這毒婦竟也來了溪食?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 38,923評論 0 274
  • 序言:老撾萬榮一對情侶失蹤娜扇,失蹤者是張志新(化名)和其女友劉穎错沃,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體袱衷,經(jīng)...
    沈念sama閱讀 45,334評論 1 310
  • 正文 獨居荒郊野嶺守林人離奇死亡捎废,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,550評論 2 333
  • 正文 我和宋清朗相戀三年笑窜,在試婚紗的時候發(fā)現(xiàn)自己被綠了致燥。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 39,727評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡排截,死狀恐怖嫌蚤,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情断傲,我是刑警寧澤脱吱,帶...
    沈念sama閱讀 35,428評論 5 343
  • 正文 年R本政府宣布,位于F島的核電站认罩,受9級特大地震影響箱蝠,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜垦垂,卻給世界環(huán)境...
    茶點故事閱讀 41,022評論 3 326
  • 文/蒙蒙 一宦搬、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧劫拗,春花似錦间校、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,672評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽胁附。三九已至,卻和暖如春滓彰,著一層夾襖步出監(jiān)牢的瞬間控妻,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,826評論 1 269
  • 我被黑心中介騙來泰國打工找蜜, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留饼暑,地道東北人。 一個月前我還...
    沈念sama閱讀 47,734評論 2 368
  • 正文 我出身青樓洗做,卻偏偏與公主長得像弓叛,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子诚纸,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 44,619評論 2 354

推薦閱讀更多精彩內(nèi)容