TCP/IP傳輸層協(xié)議
加入技術交流群
數(shù)據(jù)流，傳輸層是用什么方法區(qū)分不同應用程序的數(shù)據(jù)流呢？
在數(shù)據(jù)流被分段(分組)以后，傳輸層依靠什么來重新組裝這些數(shù)據(jù)流呢？
如果某個數(shù)據(jù)段在傳輸過沖中丟失了或重復了，可靠的傳輸協(xié)議依據(jù)什么去要求
重傳這些數(shù)據(jù)或丟棄多余的數(shù)據(jù)呢？
帶著這些問題，下面來談論傳輸層所提供的服務。
傳輸層的主要功能是分割并重新組裝上層提供的數(shù)據(jù)流，為數(shù)據(jù)流提供端對端的
傳輸服務。
在TCP/IP協(xié)議中，有兩個傳輸層協(xié)議：傳輸控制協(xié)議(TCP)和用戶數(shù)據(jù)包協(xié)議(UDP)
TCP是一個可靠的面向連接的協(xié)議，UDP是不可靠的或非連接的協(xié)議。這種面向連接和
非連接的通信方式的區(qū)別，就像打電話和寄明信片一樣。打電話的雙方在正式通話之
前都會說“喂”，確定對方在線以后才開始通話，會話結束時都要說“再見”，然后
才掛下電話。而寄明信片卻沒有這種機制，寄出去了但不管對方是否收到。
端口號
每個應用程序都會產生自己的數(shù)據(jù)流，這些數(shù)據(jù)流可以把目標主機上相應的服務程序
看作自己的目的地，對于傳輸層來說，它只需要知道目標主機上的哪個服務程序來響
應這應用程序，而不需要知道這個服務程序具體是干什么的。因此，傳輸層使用一個
抽象的端口號來標識這些應用程序和服務程序。
端口號的功能及應用特點
端口號用來跟蹤網(wǎng)絡間同時發(fā)生的不同會話。TCP和UDP可以同時接收多個應用程序送
來的數(shù)據(jù)流，用端口號來區(qū)分他們，然后送給適當?shù)膽贸绦蛱幚?。這時多路分解技
術的體現(xiàn)，它可以確保正確的用戶程序收到正確的數(shù)據(jù)。因此，每個應用程序發(fā)送數(shù)
據(jù)前都會與操作系統(tǒng)進行協(xié)商，獲得響應的源端口號和目標端口號。
在主機發(fā)送應用程序的數(shù)據(jù)之前，都必須確認端口號，如何分配這些端口號呢？一般
有兩種情況，使用中央管理機構統(tǒng)一分配的端口號和使用動態(tài)綁定。
使用中央管理機構統(tǒng)一分貝的端口號。應用程序的開發(fā)者們都默認在RFC1700中定義的
特殊端口號，在進行軟件設計時，都要遵從RFC1700中定義的規(guī)則，不能隨便使用已經
定義的端口號，那么系統(tǒng)將在一個特定的取值范圍隨機地為應用程序分配一個端口號。
例如，任何Telnet應用中的會話都應用標準端口號23。
使用動態(tài)綁定。如果一個應用程序的會話沒有涉及到特殊的端口號，那么系統(tǒng)將在一個
特定的取值方位內隨機地為應用程序分配一個端口號。在應用程序進行通信以前，如果
不知道對方的端口號，就必須發(fā)送請求以獲得對方的端口號。
RFC(Request for Comments,征求意見資料)是一個資料系列，始創(chuàng)于1969年，其中描述
了關于Internet的協(xié)議實驗，并不是所有RFC資料都是描述Internet標準的，但所有
Internet標準都是作為RFC資料編寫的。RFC資料中提交的協(xié)議都是Internet研究人員和
開發(fā)人員根據(jù)自己的情況建立、修改和擴充的，因此不同于CCITT(國際電報電話咨詢委
員會)和ANSI(美國國家標準協(xié)會)等組織所倡導的并經過正式評審和標準化處理的協(xié)議
Internet RFC有3種狀態(tài)：Proposed(提案)、Draft(草案)和Full(標準)。
TCP/IP的設計者們采用一種混合方式實現(xiàn)端口號地址的管理，終端系統(tǒng)利用源系統(tǒng)端口
號來選擇合適的應用程序，但是源系統(tǒng)的源端口號由源系統(tǒng)動態(tài)分配。
常用的端口號介紹
目前的端口號的分配情況大致如下：
小于255的端口號用于公共應用
255~1023是特定供應商應用程序的注冊端口號
高于1023的端口號未作規(guī)定。
| 常用應用層協(xié)議或應用程序 | 端口號 |
UPP | TCP | |
FTP | - | 21 |
Telnet | - | 23 |
SMTP | - | 25 |
DNS | 53 | - |
TFTP | 69 | - |
SNMP | 161 | - |
HTTP | - | 80 |
DHCP | - | 67 |
RPC(遠程調用) | - | 135 |
下面舉例說明端口號的使用過程。
主機A要Telnet到主機B。主機A首先向TCP請求一個可用端口，假如TCP分配一個為1088
的端口，主機A將目標端口號置為23。A和B通信以后，B看到A過來的端口號為23，就知
道這時Telnet應用,它就會為此創(chuàng)建一個Telnet會話。
假如同一系統(tǒng)中有多個Telnet用戶，會發(fā)生什么情況呢？當主機A上第二個用戶要Telne到
主機B時(其實是在主機A與主機B之間建立第二個Telnet進程)，主機A的第二個用戶向TCP
TCP會選出另外一個可使用的端口號，假如為10099，給第二個用戶。主機B上便會創(chuàng)建
第二個Telnet會話。
所以在統(tǒng)一IP地址上具有不同端口號的兩個連接是不同的。IP地址和端口號被用來唯一地
確定數(shù)據(jù)連接的途徑。
UDP
UDP是TCP/IP的另一個非常重要的協(xié)議。
UDP數(shù)據(jù)域的頭部共占用了8個字節(jié)
UDP數(shù)據(jù)域的頭格式描述
名稱 | 描述 |
源端口 | 調用的端口號 |
目的端口 | 被調用的端口號 |
報文長度 | 記錄UDP數(shù)據(jù)包中的8位組數(shù)目包括UDP數(shù)據(jù)的長度 最小值為8(數(shù)據(jù)部分為0時) |
校驗和 | 頭標和數(shù)據(jù)域計算的校驗和，這一項是可選的，為的 是在高可靠性的網(wǎng)路上盡量減少開銷 |
數(shù)據(jù) | 上層協(xié)議的數(shù)據(jù) |
UDP為應用程序提供的是一種不可靠的、非連接的分組交付服務，UDP報文可能出現(xiàn)
丟失、重復、時延、亂序、連接失效的問題。但是正式由于它不提供這種可靠性，所
以它的開銷很小。換句話說，UDP提供了一種在高效可靠的網(wǎng)絡上傳輸數(shù)據(jù)而不用消
耗不必要的網(wǎng)絡資源和處理時間的通信方式。使用UDP的協(xié)議包括TFTP、SNMP、DNS
DHCP。UDP很適合這種客戶機像服務器發(fā)送簡單服務請求的環(huán)境，因為這種服務的開
銷本來就很小，如果在喀什或者結束時加入類似TCP三次握手的過程，網(wǎng)絡的實際利用
將會變得很低。
UDP還可以用于操作信息的登錄。例如，像日志服務器 syslog發(fā)送日志信息，采用UDP
不會導致多臺設備向一臺服務器發(fā)送日志信息而引起過載。
UDP依靠上層協(xié)議提供可靠性，包括處理報文的丟失、重復、時延、亂序、連接失效
等問題。如Real流格式媒體就是使用應用程序協(xié)議來保證數(shù)據(jù)的正確傳輸。
TCP
在上文中已經提到UDP為應用程序提供的是一種不可靠的、非連接的分組的交付服務。當網(wǎng)絡硬件失效
或者負擔太重時，數(shù)據(jù)段可能會產生丟失、重復、時延、亂序等現(xiàn)象，這些都會導致通信不正常。如果
讓應用程序來負擔差錯檢測和恢復的工作，將給程序員帶來很多復雜的工作，所以使用獨立的通信協(xié)議
關鍵詞：
TCPIP傳輸層協(xié)
評論