當在Windows XP中同時運行多個網絡應用程序時，每個應用程序都會產生自己的
數據流，傳輸層是用什么方法區分不同應用程序的數據流呢？
在數據流被分段(分組)以后，傳輸層依靠什么來重新組裝這些數據流呢？
如果某個數據段在傳輸過沖中丟失了或重復了，可靠的傳輸協議依據什么去要求
重傳這些數據或丟棄多余的數據呢？
帶著這些問題，下面來談論傳輸層所提供的服務。
傳輸層的主要功能是分割并重新組裝上層提供的數據流，為數據流提供端對端的
傳輸服務。
在TCP/IP協議中，有兩個傳輸層協議：傳輸控制協議(TCP)和用戶數據包協議(UDP)
TCP是一個可靠的面向連接的協議，UDP是不可靠的或非連接的協議。這種面向連接和
非連接的通信方式的區別，就像打電話和寄明信片一樣。打電話的雙方在正式通話之
前都會說“喂”，確定對方在線以后才開始通話，會話結束時都要說“再見”，然后
才掛下電話。而寄明信片卻沒有這種機制，寄出去了但不管對方是否收到。
端口號
每個應用程序都會產生自己的數據流，這些數據流可以把目標主機上相應的服務程序
看作自己的目的地，對于傳輸層來說，它只需要知道目標主機上的哪個服務程序來響
應這應用程序，而不需要知道這個服務程序具體是干什么的。因此，傳輸層使用一個
抽象的端口號來標識這些應用程序和服務程序。
端口號的功能及應用特點
端口號用來跟蹤網絡間同時發生的不同會話。TCP和UDP可以同時接收多個應用程序送
來的數據流，用端口號來區分他們，然后送給適當的應用程序處理。這時多路分解技
術的體現，它可以確保正確的用戶程序收到正確的數據。因此，每個應用程序發送數
據前都會與操作系統進行協商，獲得響應的源端口號和目標端口號。
在主機發送應用程序的數據之前，都必須確認端口號，如何分配這些端口號呢？一般
有兩種情況，使用中央管理機構統一分配的端口號和使用動態綁定。
使用中央管理機構統一分貝的端口號。應用程序的開發者們都默認在RFC1700中定義的
特殊端口號，在進行軟件設計時，都要遵從RFC1700中定義的規則，不能隨便使用已經
定義的端口號，那么系統將在一個特定的取值范圍隨機地為應用程序分配一個端口號。
例如，任何Telnet應用中的會話都應用標準端口號23。
使用動態綁定。如果一個應用程序的會話沒有涉及到特殊的端口號，那么系統將在一個
特定的取值方位內隨機地為應用程序分配一個端口號。在應用程序進行通信以前，如果
不知道對方的端口號，就必須發送請求以獲得對方的端口號。
RFC(Request for Comments,征求意見資料)是一個資料系列，始創于1969年，其中描述
了關于Internet的協議實驗，并不是所有RFC資料都是描述Internet標準的，但所有
Internet標準都是作為RFC資料編寫的。RFC資料中提交的協議都是Internet研究人員和
開發人員根據自己的情況建立、修改和擴充的，因此不同于CCITT(國際電報電話咨詢委
員會) 和ANSI(美國國家標準協會)等組織所倡導的并經過正式評審和標準化處理的協議
Internet RFC有3種狀態：Proposed(提案)、Draft(草案)和Full(標準)。
TCP/IP的設計者們采用一種混合方式實現端口號地址的管理，終端系統利用源系統端口
號來選擇合適的應用程序，但是源系統的源端口號由源系統動態分配。
常用的端口號介紹
目前的端口號的分配情況大致如下：
小于255的端口號用于公共應用
255~1023是特定供應商應用程序的注冊端口號
高于1023的端口號未作規定。
| 常用應用層協議或應用程序 | 端口號 |
|
|
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應用,它就會為此創建一個Telnet會話。
假如同一系統中有多個Telnet用戶，會發生什么情況呢？當主機A上第二個用戶要Telne到
主機B時(其實是在主機A與主機B之間建立第二個Telnet進程)，主機A的第二個用戶向TCP
TCP會選出另外一個可使用的端口號，假如為10099，給第二個用戶。主機B上便會創建
第二個Telnet會話。
所以在統一IP地址上具有不同端口號的兩個連接是不同的。IP地址和端口號被用來唯一地
確定數據連接的途徑。
UDP
UDP是TCP/IP的另一個非常重要的協議。
UDP數據域的頭部共占用了8個字節
UDP數據域的頭格式描述
|
名稱
|
描述
|
|
源端口
|
調用的端口號
|
|
目的端口
|
被調用的端口號
|
|
報文長度
|
記錄UDP數據包中的8位組數目包括UDP數據的長度
最小值為8(數據部分為0時)
|
|
校驗和
|
頭標和數據域計算的校驗和，這一項是可選的，為的
是在高可靠性的網路上盡量減少開銷
|
|
數據
|
上層協議的數據
|
UDP為應用程序提供的是一種不可靠的、非連接的分組交付服務，UDP報文可能出現
丟失、重復、時延、亂序、連接失效的問題。但是正式由于它不提供這種可靠性，所
以它的開銷很小。換句話說，UDP提供了一種在高效可靠的網絡上傳輸數據而不用消
耗不必要的網絡資源和處理時間的通信方式。使用UDP的協議包括TFTP、SNMP、DNS
DHCP。UDP很適合這種客戶機像服務器發送簡單服務請求的環境，因為這種服務的開
銷本來就很小，如果在喀什或者結束時加入類似TCP三次握手的過程，網絡的實際利用
將會變得很低。
UDP還可以用于操作信息的登錄。例如，像日志服務器 syslog發送日志信息，采用UDP
不會導致多臺設備向一臺服務器發送日志信息而引起過載。
UDP依靠上層協議提供可靠性，包括處理報文的丟失、重復、時延、亂序、連接失效
等問題。如Real流格式媒體就是使用應用程序協議來保證數據的正確傳輸。
TCP
在上文中已經提到UDP為應用程序提供的是一種不可靠的、非連接的分組的交付服務。當網絡硬件失效
或者負擔太重時，數據段可能會產生丟失、重復、時延、亂序等現象，這些都會導致通信不正常。如果
讓應用程序來負擔差錯檢測和恢復的工作，將給程序員帶來很多復雜的工作，所以使用獨立的通信協議
來保證通信的可靠性是非常必要的。
傳輸控制協議TCP是在RFC793中定義的，它是一個面向連接的可靠的通信協議。總的來說，TCP主要提
供主要提供一下服務。
面向連接的虛電路：這有些和打電話相似，在開始傳輸之前，通信雙方要進行三次握手來建立連接，以保
證連接的可靠性。在傳輸過程中，通信雙方的協議模塊繼續進行通信，以確保正確到達(例如，接收會用
ACK應答發送方的報文段，發送方對未被應答的報文段提供重傳)。如果在傳輸過程中通信失敗了(例如傳
輸路徑上的某個網絡接口失效)，通信雙方都會收到錯誤報告。在通信結束時，通信雙方會使用改進的三次
握手來關閉連接。
面向流：當通信雙方傳輸大量數據時，TCP將數據流看作可分為字節的流，進行分段(分組)，接收方將收到
的報文段按原有順序復原。
流量控制，避免擁塞；為了提高傳輸效率和減少網絡通信量(協議之間的通信)，TCP會盡量一次傳輸足夠多
的數據。
多路分解技術(多路復用技術)：用端口號來實現。
全雙工連接：TCP提供全雙工連接，可以在一條連接上同時傳輸兩個獨立的、流向相反的數據流。
TCP頭格式
TCP頭共占用了20個字節
|
名稱
|
描述
|
|
源端口
|
調用的端口號
|
|
目的端口
|
被調用的端口號
|
|
序號
|
確保數據到達的序列正確的編號
|
|
應答號
|
期望下一個TCP數據段
|
|
數據偏移(頭長度)
|
以32位為單位的報頭長度
|
|
保留
|
置為0
|
|
編碼號
|
開始、終止會話之類的控制功能
|
|
窗口
|
用來控制流量
|
|
校驗和
|
頭標和數據域計算的校驗和
|
|
緊急
|
指示緊急數據的末端
|
|
可選項
|
當前定義項：TCP端的最大值
|
|
數據
|
上層協議的數據
|
建立TCP連接：三次握手
TCP是面向連接的，在面向連接的環境中，開始傳輸數據之前，在兩個終端之間必須先建立一個連接。建立
連接的過程可以卻確保通信雙方在發送應用數據包之前靜靜準備好了傳送和接收數據。對于一個要建立的連
連接的過程可以卻確保通信雙方在發送應用數據包之前靜靜準備好了傳送和接收數據。對于一個要建立的連
接，通信雙方必須用彼此的初始化序列號seq和來自對方成功傳輸確認的應答號ack來同步。(ack號致命希望收
到的下一個八位組的編號)習慣上將同步信號寫為SYN，應答信號為ACK。整個同步的過程稱為三次握手。
1)主機A發送SYN給主機B：我的序列號seq是X。
2)主機B發送SYN、ACK給主機A：我的序列號seq是X+1，應答號是X+1(等待接收第X+1號八位組)。
3)主機B發送SYN、ACK給主機B：我的序列號seq是X+1，應答號是Y+1.
通過以上3個步驟(三次握手)，TCP連接連接建立，開始傳輸數據。任何機器上的TCP都能被動地
等待握手或主動地發起握手。一旦連接建立，數據可以對等地雙向流動。
如果TCP使用1作為每次建立連接的初始化序列號，當本地系統重啟后，遠程系統會認為以前的連接依然存
在。所以每次連接時，主機都會隨機選擇一個初始化序列號，用它來辨別所傳輸的八位組在數據流中的位
置。然后雙方要對各自的序列號進行協商，因為接收收到第一個SYN時，他并不知道這是否一個被延遲的
舊信號。所以它必須要求發送驗證這個SYN。
一般情況下，TCP使用最少信息的報文段來實現三次握手，這對減少網絡通信流量是有效的�？傊�，三次握
手使通信雙方做好了傳輸數據的準備，并且使通信通信雙方統一了初始化序列號。
關閉TCP連接：改進的三次握手
對于一個已經建立的連接，TCP使用改進的三次握手來結束通話(使用一個帶有FIN附加標記的報文段)。
1)當主機A的應用程序通知TCP數據已經完畢時，TCP向主機B發送一個帶有FIN附加標記的報文段(FIN理解為
finish)。
2)主機B收到這個FIN報文段之后，并不立即用FIN報文段回復主機A，而是向主機A發送一個確認ACK，同時
同時通知自己相應的應用程序：對方要求關閉連接(先發送ACK為了防止在這段時間內，對方重傳FIN報文段)。
3)主機B的應用程序告訴TCP：我要徹底的關閉的關閉連接，TCP向主機A送第二個FIN報文段。
4)主機A收到第二個FIN報文段后，向主機B發送一個ACK表示連接徹底關閉。
TCP的可靠性
TCP是面向流的，即數據段被當作字節的序列化進行傳輸。
在通過三次握手建立連接時，序列號被初始化。在傳輸過程中，TCP繼續使用這個序列號來標記每一個發送的數據段
沒發送一個數據段，序列號加1.接收站點一句序列號重新組裝縮所收到數據段。為什么要依靠序列號來重組數據段呢？
例如，在一個告訴高速鏈路與低速鏈路并存的網絡上，可能會出現高速鏈路比低速鏈路上的數據段提前到達的情況，
此時就必須依靠序列號來重組數據段，這就是序列號的作用之一。
在傳輸過程中，確認號ACK的作用是告訴發送端那些數據包已經成功接收，并且確認號會向發送端指出了接收端希望
收到的下一個數據段的序列號，這種機制稱為預期確認，即確認號等于下一個預期的位元組。
在TCP/IP網絡中，存在超時與重傳兩種現象。如果在傳輸過程中丟失了某個序列號的數據段，導致發送端在給定時間
間隔內得不到那個數據段的應答，那么那個丟失數據段就會被要求重發。數據段會被保存在發送端的緩沖區中，直
到發送端接收到應答號，它才會釋放這個緩沖區。這種機制被稱為肯定確認與重新傳輸(Positive Acknowledgement and
Retransimission，PAR)，他是虛脫通信協議用來確�？尚哦鹊囊环N技術。
序列號的第二個作用就是消除網絡中的重復包(同步復制)。例如在網絡擁塞時，發送端遲遲沒有收到接收端某個數據段
的ACK包，它可能會認為這個序列號的數據段丟失了，于是它會重新發送，這種情況可能會導致接收端在網絡恢復正
常后收到兩個同樣序列號的數據段，此時接收端會自動丟棄第二個一樣數據段。
序列號和應答號為TCP提供了一種糾錯機制，提高了TCP的可靠性。