新聞中心

TCP/IP傳輸層協(xié)議

作者： 時(shí)間：2016-11-30 來(lái)源：網(wǎng)絡(luò) 收藏
當(dāng)在Windows XP中同時(shí)運(yùn)行多個(gè)網(wǎng)絡(luò)應(yīng)用程序時(shí)，每個(gè)應(yīng)用程序都會(huì)產(chǎn)生自己的
數(shù)據(jù)流，傳輸層是用什么方法區(qū)分不同應(yīng)用程序的數(shù)據(jù)流呢？
在數(shù)據(jù)流被分段(分組)以后，傳輸層依靠什么來(lái)重新組裝這些數(shù)據(jù)流呢？
如果某個(gè)數(shù)據(jù)段在傳輸過(guò)沖中丟失了或重復(fù)了，可靠的傳輸協(xié)議依據(jù)什么去要求
重傳這些數(shù)據(jù)或丟棄多余的數(shù)據(jù)呢？
帶著這些問(wèn)題，下面來(lái)談?wù)搨鬏攲铀峁┑姆?wù)。
傳輸層的主要功能是分割并重新組裝上層提供的數(shù)據(jù)流，為數(shù)據(jù)流提供端對(duì)端的
傳輸服務(wù)。
在TCP/IP協(xié)議中，有兩個(gè)傳輸層協(xié)議：傳輸控制協(xié)議(TCP)和用戶數(shù)據(jù)包協(xié)議(UDP)
TCP是一個(gè)可靠的面向連接的協(xié)議，UDP是不可靠的或非連接的協(xié)議。這種面向連接和
非連接的通信方式的區(qū)別，就像打電話和寄明信片一樣。打電話的雙方在正式通話之
前都會(huì)說(shuō)“喂”，確定對(duì)方在線以后才開(kāi)始通話，會(huì)話結(jié)束時(shí)都要說(shuō)“再見(jiàn)”，然后
才掛下電話。而寄明信片卻沒(méi)有這種機(jī)制，寄出去了但不管對(duì)方是否收到。
端口號(hào)
每個(gè)應(yīng)用程序都會(huì)產(chǎn)生自己的數(shù)據(jù)流，這些數(shù)據(jù)流可以把目標(biāo)主機(jī)上相應(yīng)的服務(wù)程序
看作自己的目的地，對(duì)于傳輸層來(lái)說(shuō)，它只需要知道目標(biāo)主機(jī)上的哪個(gè)服務(wù)程序來(lái)響
應(yīng)這應(yīng)用程序，而不需要知道這個(gè)服務(wù)程序具體是干什么的。因此，傳輸層使用一個(gè)
抽象的端口號(hào)來(lái)標(biāo)識(shí)這些應(yīng)用程序和服務(wù)程序。
端口號(hào)的功能及應(yīng)用特點(diǎn)
端口號(hào)用來(lái)跟蹤網(wǎng)絡(luò)間同時(shí)發(fā)生的不同會(huì)話。TCP和UDP可以同時(shí)接收多個(gè)應(yīng)用程序送
來(lái)的數(shù)據(jù)流，用端口號(hào)來(lái)區(qū)分他們，然后送給適當(dāng)?shù)膽?yīng)用程序處理。這時(shí)多路分解技
術(shù)的體現(xiàn)，它可以確保正確的用戶程序收到正確的數(shù)據(jù)。因此，每個(gè)應(yīng)用程序發(fā)送數(shù)
據(jù)前都會(huì)與操作系統(tǒng)進(jìn)行協(xié)商，獲得響應(yīng)的源端口號(hào)和目標(biāo)端口號(hào)。
在主機(jī)發(fā)送應(yīng)用程序的數(shù)據(jù)之前，都必須確認(rèn)端口號(hào)，如何分配這些端口號(hào)呢？一般
有兩種情況，使用中央管理機(jī)構(gòu)統(tǒng)一分配的端口號(hào)和使用動(dòng)態(tài)綁定。
使用中央管理機(jī)構(gòu)統(tǒng)一分貝的端口號(hào)。應(yīng)用程序的開(kāi)發(fā)者們都默認(rèn)在RFC1700中定義的
特殊端口號(hào)，在進(jìn)行軟件設(shè)計(jì)時(shí)，都要遵從RFC1700中定義的規(guī)則，不能隨便使用已經(jīng)
定義的端口號(hào)，那么系統(tǒng)將在一個(gè)特定的取值范圍隨機(jī)地為應(yīng)用程序分配一個(gè)端口號(hào)。
例如，任何Telnet應(yīng)用中的會(huì)話都應(yīng)用標(biāo)準(zhǔn)端口號(hào)23。
使用動(dòng)態(tài)綁定。如果一個(gè)應(yīng)用程序的會(huì)話沒(méi)有涉及到特殊的端口號(hào)，那么系統(tǒng)將在一個(gè)
特定的取值方位內(nèi)隨機(jī)地為應(yīng)用程序分配一個(gè)端口號(hào)。在應(yīng)用程序進(jìn)行通信以前，如果
不知道對(duì)方的端口號(hào)，就必須發(fā)送請(qǐng)求以獲得對(duì)方的端口號(hào)。
RFC(Request for Comments,征求意見(jiàn)資料)是一個(gè)資料系列，始創(chuàng)于1969年，其中描述
了關(guān)于Internet的協(xié)議實(shí)驗(yàn)，并不是所有RFC資料都是描述Internet標(biāo)準(zhǔn)的，但所有
Internet標(biāo)準(zhǔn)都是作為RFC資料編寫(xiě)的。RFC資料中提交的協(xié)議都是Internet研究人員和
開(kāi)發(fā)人員根據(jù)自己的情況建立、修改和擴(kuò)充的，因此不同于CCITT(國(guó)際電報(bào)電話咨詢委
員會(huì))和ANSI(美國(guó)國(guó)家標(biāo)準(zhǔn)協(xié)會(huì))等組織所倡導(dǎo)的并經(jīng)過(guò)正式評(píng)審和標(biāo)準(zhǔn)化處理的協(xié)議
Internet RFC有3種狀態(tài)：Proposed(提案)、Draft(草案)和Full(標(biāo)準(zhǔn))。
TCP/IP的設(shè)計(jì)者們采用一種混合方式實(shí)現(xiàn)端口號(hào)地址的管理，終端系統(tǒng)利用源系統(tǒng)端口
號(hào)來(lái)選擇合適的應(yīng)用程序，但是源系統(tǒng)的源端口號(hào)由源系統(tǒng)動(dòng)態(tài)分配。
常用的端口號(hào)介紹
目前的端口號(hào)的分配情況大致如下：
小于255的端口號(hào)用于公共應(yīng)用
255~1023是特定供應(yīng)商應(yīng)用程序的注冊(cè)端口號(hào)
高于1023的端口號(hào)未作規(guī)定。
常用應(yīng)用層協(xié)議或應(yīng)用程序端口號(hào)
UPP
TCP
FTP
-
21
Telnet
-
23
SMTP
-
25
DNS
53
-
TFTP
69
-
SNMP
161
-
HTTP
-
80
DHCP
-
67
RPC(遠(yuǎn)程調(diào)用)
-
135

下面舉例說(shuō)明端口號(hào)的使用過(guò)程。
主機(jī)A要Telnet到主機(jī)B。主機(jī)A首先向TCP請(qǐng)求一個(gè)可用端口，假如TCP分配一個(gè)為1088
的端口，主機(jī)A將目標(biāo)端口號(hào)置為23。A和B通信以后，B看到A過(guò)來(lái)的端口號(hào)為23，就知
道這時(shí)Telnet應(yīng)用,它就會(huì)為此創(chuàng)建一個(gè)Telnet會(huì)話。
假如同一系統(tǒng)中有多個(gè)Telnet用戶，會(huì)發(fā)生什么情況呢？當(dāng)主機(jī)A上第二個(gè)用戶要Telne到
主機(jī)B時(shí)(其實(shí)是在主機(jī)A與主機(jī)B之間建立第二個(gè)Telnet進(jìn)程)，主機(jī)A的第二個(gè)用戶向TCP
TCP會(huì)選出另外一個(gè)可使用的端口號(hào)，假如為10099，給第二個(gè)用戶。主機(jī)B上便會(huì)創(chuàng)建
第二個(gè)Telnet會(huì)話。
所以在統(tǒng)一IP地址上具有不同端口號(hào)的兩個(gè)連接是不同的。IP地址和端口號(hào)被用來(lái)唯一地
確定數(shù)據(jù)連接的途徑。
UDP
UDP是TCP/IP的另一個(gè)非常重要的協(xié)議。

UDP數(shù)據(jù)域的頭部共占用了8個(gè)字節(jié)
UDP數(shù)據(jù)域的頭格式描述
名稱
描述
源端口
調(diào)用的端口號(hào)
目的端口
被調(diào)用的端口號(hào)
報(bào)文長(zhǎng)度
記錄UDP數(shù)據(jù)包中的8位組數(shù)目包括UDP數(shù)據(jù)的長(zhǎng)度
最小值為8(數(shù)據(jù)部分為0時(shí))
校驗(yàn)和
頭標(biāo)和數(shù)據(jù)域計(jì)算的校驗(yàn)和，這一項(xiàng)是可選的，為的
是在高可靠性的網(wǎng)路上盡量減少開(kāi)銷
數(shù)據(jù)
上層協(xié)議的數(shù)據(jù)

UDP為應(yīng)用程序提供的是一種不可靠的、非連接的分組交付服務(wù)，UDP報(bào)文可能出現(xiàn)
丟失、重復(fù)、時(shí)延、亂序、連接失效的問(wèn)題。但是正式由于它不提供這種可靠性，所
以它的開(kāi)銷很小。換句話說(shuō)，UDP提供了一種在高效可靠的網(wǎng)絡(luò)上傳輸數(shù)據(jù)而不用消
耗不必要的網(wǎng)絡(luò)資源和處理時(shí)間的通信方式。使用UDP的協(xié)議包括TFTP、SNMP、DNS
DHCP。UDP很適合這種客戶機(jī)像服務(wù)器發(fā)送簡(jiǎn)單服務(wù)請(qǐng)求的環(huán)境，因?yàn)檫@種服務(wù)的開(kāi)
銷本來(lái)就很小，如果在喀什或者結(jié)束時(shí)加入類似TCP三次握手的過(guò)程，網(wǎng)絡(luò)的實(shí)際利用
將會(huì)變得很低。
UDP還可以用于操作信息的登錄。例如，像日志服務(wù)器 syslog發(fā)送日志信息，采用UDP
不會(huì)導(dǎo)致多臺(tái)設(shè)備向一臺(tái)服務(wù)器發(fā)送日志信息而引起過(guò)載。
UDP依靠上層協(xié)議提供可靠性，包括處理報(bào)文的丟失、重復(fù)、時(shí)延、亂序、連接失效
等問(wèn)題。如Real流格式媒體就是使用應(yīng)用程序協(xié)議來(lái)保證數(shù)據(jù)的正確傳輸。
TCP
在上文中已經(jīng)提到UDP為應(yīng)用程序提供的是一種不可靠的、非連接的分組的交付服務(wù)。當(dāng)網(wǎng)絡(luò)硬件失效
或者負(fù)擔(dān)太重時(shí)，數(shù)據(jù)段可能會(huì)產(chǎn)生丟失、重復(fù)、時(shí)延、亂序等現(xiàn)象，這些都會(huì)導(dǎo)致通信不正常。如果
讓?xiě)?yīng)用程序來(lái)負(fù)擔(dān)差錯(cuò)檢測(cè)和恢復(fù)的工作，將給程序員帶來(lái)很多復(fù)雜的工作，所以使用獨(dú)立的通信協(xié)議
來(lái)保證通信的可靠性是非常必要的。
上一頁(yè) 1 2 下一頁(yè)

關(guān)鍵詞： TCPIP傳輸層協(xié)

評(píng)論


技術(shù)專區(qū)

關(guān)閉