TCPIP協(xié)議運輸層的詳細資料說明

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

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

5.1.1 進程之間的通信

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

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

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

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

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

UDP(User Datagram Protocol)[RFC 768]

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

5.1.3 運輸層的端口.

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

5.2 UDP

5.2.1 UDP概述

無連接

盡最大努力交付.

面向報文.

沒有擁塞控制.

支持1對1,1對n,n-1和n-n交互通信.

首部開銷小. 只有8個字節(jié).

5.2.2 UDP的首部格式

源端口

目的端口

長度

校驗和

5.3 TCP

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

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

每一條TCP連接只能有兩個端點(endpoint),每一條TCP連接只能是點對點.

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

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

面向字節(jié)流. TCP中的流(stream指的是流入到進程或從進程流出的字節(jié)序列. 雖然應(yīng)用程序和TCP的交互是一次一個數(shù)據(jù)塊(大小不等),但TCP把應(yīng)用程序叫下來的數(shù)據(jù)看成僅僅是一連串的無結(jié)構(gòu)的字節(jié)流. TCP并不知道所傳送的字節(jié)流的含義.TCP不保證接收方應(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é)流完全一樣.當然接收方的應(yīng)用程序必須有能力識別收到的字節(jié)流,把它還原成有意義的應(yīng)用層數(shù)據(jù).

5.3.2 TCP的連接

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

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

理想的傳輸條件有以下兩個特點:

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

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

5.4.1 停止等待協(xié)議

無差錯情況.

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

確認丟失和確認遲到

信道利用率

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

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

5.5 TCP報文段的首部格式.

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

首部不頂部分個字段的意義

源端口和目的端口

序號

確認號

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

保留

緊急URG

確認ACK

推送PSH

復(fù)位RST

同步SYN

終止FIN

窗口

校驗和

緊急指針

選項

5.6 TCP可靠傳輸?shù)膶崿F(xiàn)

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

5.6.2 超時重傳時間的選擇

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

5.6.3選擇確認SACK

5.7TCP的流量控制

5.7.1 利用滑動窗口實現(xiàn)流量控制.

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

5.9TCP的運輸連接管理

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

要使每一方能夠確知對方的存在.

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

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

5.9.1 TCP連接的建立

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

5.9.2TCP的連接釋放

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