運(yùn)輸層向它上面的應(yīng)用層提供通信服務(wù). 兩個(gè)主機(jī)進(jìn)行通信就是兩個(gè)主機(jī)中的應(yīng)用進(jìn)程互相通信. 從運(yùn)輸層的角度看,通信的真正端點(diǎn)并不是主機(jī)而是主機(jī)的進(jìn)程.運(yùn)輸層提供應(yīng)用進(jìn)程間的邏輯通信. 運(yùn)輸層之間的通信好像是沿水平方向傳輸數(shù)據(jù).但事實(shí)上這兩個(gè)運(yùn)輸層之間并沒(méi)有一條水平方向的物理連接.要傳送的數(shù)據(jù)是沿著圖中的虛線向(經(jīng)過(guò)多個(gè)層次)傳送的.

5.1 運(yùn)輸層協(xié)議概述

5.1.1 進(jìn)程之間的通信

網(wǎng)絡(luò)層是為了主機(jī)之間提供邏輯通信,而運(yùn)輸層為應(yīng)用進(jìn)程之間提供端到端的邏輯通信.

運(yùn)輸層向高層用戶屏蔽了下面網(wǎng)絡(luò)核心的細(xì)節(jié),它使應(yīng)用進(jìn)程看見(jiàn)的就是好像在兩個(gè)運(yùn)輸層實(shí)體之間有一條端到端的邏輯通信信道.

當(dāng)運(yùn)輸層采用面向連接的TCP協(xié)議時(shí),盡管下面的網(wǎng)絡(luò)是不可靠的,但這種邏輯通信信道就相當(dāng)于一條全雙工的可信信道.

采用UDP協(xié)議時(shí),這種邏輯通信信道仍然是一條不可靠信道.

5.1.2 運(yùn)輸層的兩個(gè)主要協(xié)議.

UDP(User Datagram Protocol)[RFC 768]

TCP(Transmission Control Protocol)[RFC793] UDP在傳送數(shù)據(jù)之間不需要先建立連接. TCP 提供面向連接的服務(wù).

5.1.3 運(yùn)輸層的端口.

通過(guò)端口解決通信的目的地.雖然通信的終點(diǎn)是應(yīng)用進(jìn)程,但我們只要把要傳送的報(bào)文交到目的主機(jī)的某一個(gè)合適的目的端口,剩下的工作(即最后交付給目的進(jìn)程)就由TCP來(lái)完成.在協(xié)議棧層間的抽象的協(xié)議端口是軟件端口,軟件端口是應(yīng)用層的各種協(xié)議進(jìn)程與運(yùn)輸試題進(jìn)行層間交換的一種地址. 端口號(hào)只具有本地意義.

5.2 UDP

5.2.1 UDP概述

無(wú)連接

盡最大努力交付.

面向報(bào)文.

沒(méi)有擁塞控制.

支持1對(duì)1,1對(duì)n,n-1和n-n交互通信.

首部開(kāi)銷小. 只有8個(gè)字節(jié).

5.2.2 UDP的首部格式

源端口

目的端口

長(zhǎng)度

校驗(yàn)和

5.3 TCP

5.3.1 TCP最主要的特點(diǎn) TCP 是TCP/IP體系中非常復(fù)雜的一個(gè)協(xié)議.

面向連接的運(yùn)輸層協(xié)議.也就是說(shuō),應(yīng)用程序在使用TCP協(xié)議之前,必須先建立TCP連接.在傳送數(shù)據(jù)完畢后,必須釋放已經(jīng)建立的TCP連接.

每一條TCP連接只能有兩個(gè)端點(diǎn)(endpoint),每一條TCP連接只能是點(diǎn)對(duì)點(diǎn).

TCP提供可靠交付的服務(wù).

TCP提供全雙工通信.TCP允許通信雙方的應(yīng)用進(jìn)程在任何時(shí)候都能發(fā)送數(shù)據(jù).TCP連接的兩端都設(shè)有發(fā)送緩存和接收緩存,用來(lái)臨時(shí)存放雙向通信的數(shù)據(jù).在發(fā)送時(shí),應(yīng)用程序在把數(shù)據(jù)傳送給TCP的緩存后,就可以做自己的事,而TCP在合適的時(shí)候吧數(shù)據(jù)發(fā)送出去.在接受時(shí),TCP把收到的數(shù)據(jù)放在緩存,上層的應(yīng)用進(jìn)程在合適的時(shí)候讀取緩存中的數(shù)據(jù).

面向字節(jié)流. TCP中的流(stream指的是流入到進(jìn)程或從進(jìn)程流出的字節(jié)序列. 雖然應(yīng)用程序和TCP的交互是一次一個(gè)數(shù)據(jù)塊(大小不等),但TCP把應(yīng)用程序叫下來(lái)的數(shù)據(jù)看成僅僅是一連串的無(wú)結(jié)構(gòu)的字節(jié)流. TCP并不知道所傳送的字節(jié)流的含義.TCP不保證接收方應(yīng)用程序鎖收到的數(shù)據(jù)塊和發(fā)送方應(yīng)用程序所發(fā)出的數(shù)據(jù)塊具有對(duì)應(yīng)大小的關(guān)系(例如,發(fā)送方應(yīng)用程序交給發(fā)送方的TCP供10個(gè)數(shù)據(jù)塊,但接收方的TCP可能只用了4個(gè)數(shù)據(jù)塊就把收到的字節(jié)流交付給了上層的應(yīng)用程序).但接收方應(yīng)用程序收到的字節(jié)流必須和發(fā)送方應(yīng)用程序發(fā)送的字節(jié)流完全一樣.當(dāng)然接收方的應(yīng)用程序必須有能力識(shí)別收到的字節(jié)流,把它還原成有意義的應(yīng)用層數(shù)據(jù).

5.3.2 TCP的連接

TCP把連接作為最基本的抽象. 每一條TCP連接有兩個(gè)端點(diǎn). TCP 連接的端點(diǎn)叫做套接字(socket)或者插口. 根據(jù)RFC793的定義:端口號(hào)拼接到(conatenated with)IP地址即構(gòu)成了套接字.

5.4 可靠傳輸?shù)?a target="_blank">工作原理

理想的傳輸條件有以下兩個(gè)特點(diǎn):

傳輸信道不產(chǎn)生差錯(cuò).

不管發(fā)送方以多快的速度發(fā)送數(shù)據(jù),接收方總是來(lái)得及處理收到的數(shù)據(jù). 在以上理想傳輸條件下,不需要采取任何措施就能夠?qū)崿F(xiàn)可靠傳輸

5.4.1 停止等待協(xié)議

無(wú)差錯(cuò)情況.

出現(xiàn)差錯(cuò)情況.

確認(rèn)丟失和確認(rèn)遲到

信道利用率

5.4.1 連續(xù)ARQ協(xié)議

滑動(dòng)窗口協(xié)議比較復(fù)雜,是TCP協(xié)議的精髓所在.

5.5 TCP報(bào)文段的首部格式.

TCP雖然是面向字節(jié)流的,但TCP傳送的數(shù)據(jù)單元確實(shí)報(bào)文段.一個(gè)TCP報(bào)文段分為首部和數(shù)據(jù)兩個(gè)部分.

首部不頂部分個(gè)字段的意義

源端口和目的端口

序號(hào)

確認(rèn)號(hào)

數(shù)據(jù)便宜

保留

緊急URG

確認(rèn)ACK

推送PSH

復(fù)位RST

同步SYN

終止FIN

窗口

校驗(yàn)和

緊急指針

選項(xiàng)

5.6 TCP可靠傳輸?shù)膶?shí)現(xiàn)

5.6.1 以字節(jié)為單位的滑動(dòng)窗口

5.6.2 超時(shí)重傳時(shí)間的選擇

TCP采用自適應(yīng)算法,記錄一個(gè)報(bào)文段發(fā)出的時(shí)間,以及受到相應(yīng)的確認(rèn)的時(shí)間.這兩個(gè)時(shí)間之差就是報(bào)文段的往返時(shí)間RTT.TCP保留了RTT的一個(gè)加權(quán)平均往返時(shí)間RTTs.

5.6.3選擇確認(rèn)SACK

5.7TCP的流量控制

5.7.1 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制.

流量控制(flow control)就是讓發(fā)送方的發(fā)送速率不要太快,要讓接收方來(lái)得及接受. 發(fā)送方的發(fā)送窗口不能超過(guò)接收方給出的接受窗口的數(shù)值.

5.9TCP的運(yùn)輸連接管理

連接建立,數(shù)據(jù)傳送 連接釋放. TCP連接建立過(guò)程中要解決以下三個(gè)問(wèn)題:

要使每一方能夠確知對(duì)方的存在.

要允許雙方協(xié)商一些參數(shù)(如最大窗口值,是否使用窗口擴(kuò)大選項(xiàng)和時(shí)間戳選項(xiàng)及服務(wù)質(zhì)量等)

能夠?qū)\(yùn)輸實(shí)體資源(如緩存大小,連接表中的項(xiàng)目等)進(jìn)行分配. TCP連接的建立采用客戶服務(wù)器方式.主動(dòng)發(fā)起連接建立的應(yīng)用進(jìn)程叫做客戶(client).而被動(dòng)等待連接建立的應(yīng)用進(jìn)程叫做服務(wù)器(server).

5.9.1 TCP連接的建立

為什么A還要發(fā)送一次確認(rèn)呢,這主要是為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了B,而產(chǎn)生錯(cuò)誤. A發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文沒(méi)有丟失,滯留在網(wǎng)絡(luò)上,延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)B.本來(lái)這個(gè)是早已失效的報(bào)文段.但是B收到此失效的連接請(qǐng)求報(bào)文段后,就誤認(rèn)為是A有發(fā)出一次新的連接請(qǐng)求.于是就向A發(fā)出確認(rèn)報(bào)文段,同意建立連接.假定不采用三次握手,那么只要B發(fā)出確認(rèn),新的連接就建立了. 由于現(xiàn)在A并沒(méi)有發(fā)出建立連接的請(qǐng)求,因此不會(huì)理財(cái)B的確認(rèn).也不會(huì)向B發(fā)送數(shù)據(jù).但是B卻以為新的運(yùn)輸連接已經(jīng)建立了,并一直等待A發(fā)送數(shù)據(jù).B的許多資源就這樣白白浪費(fèi)的.

5.9.2TCP的連接釋放

數(shù)據(jù)傳輸結(jié)束后,通信的雙方都可釋放連接.