1 運輸層協議概述
1.1 進程之間的通信
- 網絡層是為主機之間提供邏輯通信，而運輸層為應用進程之間提供端到端的邏輯通信。
- 運輸層要對收到的報文進行差錯檢測。在網絡層，IP數據報首部中的檢驗和字段只檢驗首部是否出現差錯而不檢查數據部分。
- 根據應用程序的不同需求，運輸層需要有兩種不同的運輸協議，即面向連接的TCP和無連接的UDP：用戶數據報協議UDP，傳輸控制協議TCP
- 運輸層向高層用戶屏蔽了下面網絡核心的細節（如網絡拓撲、所采用的路由選擇協議等），它使應用進程看見的就是好像在兩個運輸層實體之間有一條端到端的邏輯通信信道。當運輸層采用面向連接的TCP協議時，盡管下面的網絡是不可靠的，但這種邏輯通信信道就像但與一條全雙工的可靠信道。但當運輸層采用無連接的UDP協議時，這種邏輯信道仍然是一條不可靠信道。
1.2 運輸層的兩個主要協議
UDP在傳送數據之前不需要先建立連接。遠地主機的運輸層在收到UDP豹紋后，不需要給出任何確認，雖然UDP不提供可靠交付，但在某些情況下UDP確實一種最有效的工作方式。
TCP則是提供面向連接的服務。在傳送數據之前必須先建立連接，數據傳送結束后要釋放連接。由于TCP要提供可靠的、面向連接的運輸服務，因此不可避免地增加了許多開銷，如確認、流量控制、計時器以及連接管理等。這不僅使協議數據單元的首部增大很多，還要占用許多的處理器資源。
1.3 運輸層的端口
應用層所有進程都可以通過運輸層傳送到IP層，這就是復用。運輸層從IP層收到數據后必須交付給指明的應用程序，這就是分用。顯然，給應用層的每個應用進程賦予一個非常明確的標志是至關重要的。
這個可以通過在運輸層使用端口來實現。這就是說，雖然通信的終點是應用進程，但我們只需要把要傳送的報文叫到目的主機的某一個合適的目的端口，剩下的工作（即交付給目的進程）就有TCP來完成。這里的端口是應用層的各種協議進程與運輸實體進行層間交互的一種地址。
TCP/IP的運輸層用一個16位端口號來標志一個端口。但是，端口號只具有本地意義，它只是為了標志本計算機應用層中的各個進程在運輸層交互時的層間接口。在因特網不同計算機中，相同的端口號是沒有關聯的。由此可見，兩個計算機中的進程要通信，不僅要知道對方的IP地址（為了找到對方的計算機），還要知道對方的端口號（為了找到對方計算機中的應用進程）。
因特網上的計算機通信是采用客戶-服務器方式。客戶在發起通信請求式，必須先知道對方的IP地址和端口號。因此運輸層的端口號分為服務器端使用的端口號和客戶端使用的端口號。
2 用戶數據報協議UDP
UDP協議只在IP的數據報服務之上增加了很少的功能，就是復用和分用的功能以及差錯檢測的功能。UDP的主要特點是：
- UDP是無連接的，即發送數據之間不需要建立連接，因此減少了開銷和發送數據之前的時延。
- UDO使用盡最大努力交付，即不保證可靠交付，因此主機不需要維持復雜的連接狀態。
- UDP是面向報文。發送方的UDP對應用程序交下來的報文在添加首部后就向下交付給IP層，對交下來的報文既不合并也不拆分。因此，應用進程必須選擇合適大小的報文，若報文太長，UDP把它交付給IP層后，IP層在傳送時可能要進行分片，這會降低IP層的效率；反之，若報文太短，UDO把它交給IP層后，會使IP數據報的首部的相對長度太大，也降低了IP層的效率。
- UDP沒有擁塞控制，保證了應用的實時性。
- 支持一對一、一對多、多對一和多對多的交互通信。
- UDP的首部開銷小，只有8個字節，比TCP的20個字節的首部要短。
2.1 UDP首部的格式
UDP有數據字段和首部字段兩個字段。首部字段只有8個字節，分別為源端口、目的端口、長度和檢驗和。檢驗和用于檢測UDP用戶數據報在傳輸中是否有錯，有錯就丟棄。
當運輸層從IP層收到UDP數據報時，就根據首部中的目的端口，把UDP數據報通過相應的端口上交給進程。如果接方UDP發現收到的報文中的目的端口不正確就丟棄報文，并由ICMP發送“端口不可達”差錯報文交給發送方。
在計算檢驗和時，要在UDP用戶數據報之前增加12個字節的偽首部。“偽首部”并不是用戶數據報真正的首部，只是在計算檢驗和時，臨時添加在UDP數據報前面，得到一個臨時UDP數據報。偽首部既不向下傳送也不向上遞交，僅僅是為了計算檢驗和。
2.2 UDP的典型應用
- UDP適合于這樣的進程：需要簡單的請求-響應通信，而較少考慮流量控制和差錯控制。對于需要傳送成塊數據的進程（如FTP）則不適合使用UDP。
- UDP適合于具有內部流量控制和差錯控制機制的進程，如簡單文件傳輸協議TFTP。
- 對多播來說，UDP是一個合適的傳輸協議。
- UDP常用于交互實時應用，以避免接收報文之間的不一致延時。
- UDP可用于管理進程，如SNMP。
3 傳輸控制協議TCP
3.1 TCP最主要的特點
- TCP是面向連接的運輸層協議。應用程序在使用TCP協議之前，必須先簡歷TCP連接。在傳送數據完畢后，必須釋放已經簡歷的TCP連接。
- 每一條TCP連接只能有兩個端點，只能是點對點的。
- TCP提供可靠交付的服務。TCP連接傳送的數據保證無差錯、不丟失、不重復、并按序到達。
- TCP提供全雙工通信。TCP允許通信雙方的應用進程在任何時候都能發送數據。TCP連接的兩端都設有發送緩存和接收緩存，用來臨時存放雙向通信的數據。
- 面向字節流。雖然應用程序和TCP的交互是一次一個數據塊，但TCP把應用程序交下來的數據看成是一連串的務結構的字節流。TCP不保證接收方應用程序所收到的數據塊和發送方應用程序所發出的數據塊具有對應大小的關系（例如，發送方應用程序交給發送方TCP共有10個數據塊，但接收方TCP可能只用了4個數據塊就把收到的字節流交付給了上層應用程序）。但接收方應用程序收到的字節流必須和發送方應用程序發出的字節流完全一樣。
3.2 TCP的連接
每一條TCP連接有兩個端點，而TCP的端點叫做套接字（由端口號拼接到IP地址形成的），套接字的表示方法是在點分十進制的IP地址后面寫上端口號，中間用冒號或都好隔開。
套接字Socket = (IP地址: 端口號)
每一條TCP連接唯一的被通信兩端的兩個套接字所確定：
TCP連接::={socket1, socket2} = {(IP1:port1), (IP2:port2)}
3.3 TCP報文的首部格式
TCP雖然是面向字節流的，但TCP傳送的數據單元卻是報文段。一個TCP報文段分為首部和數據兩部分，而TCP的全部功能都體現在它首部中各字段的作用。因此，只有弄清TCP首部各字段的作用才能掌握TCP的工作原理。TCP報文首部固定部分各字段的意義如下：
源端口和目的端口
各占兩字節，分別寫入源端口號和目的端口號。TCP的分用也是通過端口實現的。報文段序號
占4字節。在一個TCP連接中傳送的字節流中的每一個字節都按順序編號。整個要傳送的字節流的起始序號必須在連接建立時設置，首部中的序號字段值則是指本報文所發送的數據的第一個字節的序號。確認號
期望收到對方下一個報文段的第一個數據字節的序號。若確認號為N，則表明到序號N-1為止的所有數據都已正確收到。數據偏移
指出TCP報文段的數據起始處距離TCP報文段的起始處有多遠，實際上指出了TCP報文段的首部長度。保留
保留為今后使用，目前應置為0.6個控制位
緊急URG：當URG為1時，表明緊急指針字段有效，告訴系統有緊急數據，應盡快優先傳送。
確認ACK：TCP規定，在連接建立后所有傳送的報文段都必須把ACK置1。
推送PSH，很少使用。
復位RST：當RST=1時，表明TCP連接中出現嚴重錯誤，必須釋放連接，然后再重新建立運輸連接。
同步SYN：在連接建立時用來同步序號。當SYN=1而ACK=0時，表明這是一個連接請求報文段。對方若同意建立連接，則應在響應的報文段中使用SYN=1和ACK=1.
終止FIN：用來釋放一個連接。當FIN=1時，表明此報文段的發送方的數據已發送完畢，并要求釋放運輸連接。窗口
窗口字段明確指出了現在允許對方發送的數據量，該值經常在動態變化著。例如，設確認號是701，窗口字段是1000。這就表明從701算起，發送此報文段的一方還有接收1000個字節數據的接收緩存空間。檢驗和
檢驗和字段檢驗的范圍包括首部和數據這兩部分。和UDP一樣，在計算檢驗和時要在TCP報文段的前面加上12字節的偽首部。緊急指針
緊急指針僅在URG=1時才有意義，它指出本報文段中的緊急數據的字節數。**即使窗口為零時也可發送緊急數據。選項
可選選項有最大報文長度MSS、窗口擴大選項、時間戳選項、選擇確認選項等
3.4 TCP可靠傳輸的實現
為方便描述可靠傳輸原理，假定數據傳輸只在一個方向上進行，即A發送數據，B給出確認。TCP的滑動窗口是以字節為單位的。假定A收到B發來的確認報文字段，其中窗口是20字節，而確認號是31字節。（表明B期望接收到的下一個序號是31，序號30之前的數據已經收到了）。A的發送窗口的位置由B發來的確認報文中的確認號和窗口大小確定。
現在假定A發送了序號為31-41的數據，從下圖圖中可以看出要描述一個發送窗口的狀態需要三個指針P1， P2， P3。小于P1的是已發送并收到確認的部分，大于P3的是不允許發送部分。
B的接收窗口大小為20。在接收窗口外面，到30號為止的數據均發送過確認并交付主機使用，因此B不再保留（之前的數據）。假設B收到了32和33的數據，卻沒收到31的數據（并不保證按序到達）。因此B的發送的確認號仍然是31，而不能是32或33。
現假定B收到序號為31的數據并把序號為31-33的數據交付給主機，并刪除這些數據。接著把接收窗口向前移動3個序號，同時給A發出確認。其窗口值仍為20，但確認號為34,表明B已經接收到序號33為止的數據。而B收到的37、38和40的數據，但沒按序到達，只能先暫存在接收窗口中。A收到B的確認后，將發送窗口向前滑動3個序號，但指針P2不動。A繼續發送完序號42-53的數據后，指針P2向前與P3重合，發送窗內的數據以發送完，但還沒收到確認，因此必須停止發送。
緩存機制
在3.1節的圖中提到，發送方的應用進程把字節流寫入TCP的發送緩存，接收方的應用進程從TCP的接受緩存中讀取字節流。下面進一步談論窗口與緩存的關系。
發送緩存用來暫時存放：發送應用程序傳送給發送方TCP準備的數據，TCP已發送但尚未收到確認的數據。發送窗口通常只是發送緩存的一部分，已被確認的數據應當從發送緩存中刪除，因此發送緩存與發送窗口的后沿是重合的。發送應用程序必須控制寫入緩存的速率，不能太快，否則發送緩存就會沒有存放數據的空間。
接收緩存用來暫時存放：按序到達的，但尚未被接收應用程序讀取的數據；未按序到達的數據。如果收到的分組檢測出有差錯，則要丟棄。如果接收應用程序來不及讀取收到的數據，接收緩存最終就會被填滿，使接收窗口減小到0。反之，接收應用程序能夠及時從接收緩存中讀取收到數據，接收窗口就會變大，但最大也不能超過接收緩存的大小。
超時重傳機制
TCP每發送一個報文段，就對這個報文段設置一次計時器。只要達到計時器設置的重傳時間還沒有收到確認，就要重傳這個報文段。由于數據鏈路層和運輸層的往返實驗概率分布存在很大差異，因此有必要選擇合適的超時重傳時間。
TCP采用了一中自適應算法來確定超時重傳時間，它記錄一個報文段發出的時間，以及收到相應的確認的時間。這兩個時間差就是報文段的往返時間RTT。TCP保留了RTT的一個加權平均往返時間RTTs，RTTs的計算方法如下，推薦的阿爾法值為1/8。
顯然超時重傳時間RTO應略大于RTTs：
其中RTTd是TTT的偏差的加權平均值。
選擇確認SACK
若收到的報文段無差錯，只是未按序號，中間還缺少一些序號的數據，采用選擇確認的方法來傳送缺少的數據，而不重傳已經正確接收到的數據。
用一個例子來說明（Selctive ACK）工作原理。如圖所示，接收放收到了前面的字節流不連續的兩個字節塊。如果這些字節的序號都在接收窗口內，那么接收方就先收下這些數據，但要把這些信息準確的告訴發送放，使發送方不要在重復發送這些已經收到的數據。
TCP首部沒有哪個字段能夠提供上述這些字節快的邊界信息。如果要使用選擇確認，那么在建立TCP連接時，就要在TCP首部的選項上加上“允許SACK”的選項。
3.5 TCP的流量控制與擁塞控制
流量控制
所謂的流量控制就是讓發送方的發送速率不要太快，讓接收方來得及接受。利用滑動窗口機制可以很方便的在TCP連接上實現對發送方的流量控制。
擁塞控制
在某段時間，若對網絡中的某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就要變化，這種情況叫做擁塞。網絡擁塞往往是由許多因素引起的，簡單的提高節點處理機的速度或者擴大結點緩存的存儲空間并不能解決擁塞問題。問題的是指往往是整個系統的各個部分不匹配，只有各個部分平衡了，問題才會得到解決。
擁塞控制和流量控制的差別
- 所謂擁塞控制就是防止過多的數據注入到網絡中，這樣可以使網絡中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提，就是網絡能承受現有的網絡負荷。
- 流量控制往往指的是點對點通信量的控制，是個端到端的問題。流量控制所要做的就是控制發送端發送數據的速率，以便使接收端來得及接受。
擁塞控制是很難設計的，因為它是一個動態的問題，許多情況下，甚至正式擁塞控制機制本身成為引起網絡性能惡化甚至死鎖的原因。RFC定義了進行擁塞控制的四種算法：慢開始、擁塞避免、快重傳和快恢復。
3.6 TCP連接的建立與終止
TCP連接的建立可以簡單的稱為三次握手，而連接的中止則可以叫做四次握手。
TCP的建立
- 首先，客戶端向服務器申請打開某一個端口(用SYN段等于1的TCP報文)；
- 然后，服務器端發回一個ACK報文通知客戶端請求報文收到；
- 客戶端收到確認報文以后再次發出確認報文，確認剛才服務器端發出的確認報文。
至此，連接的建立完成。這就叫做三次握手。如果打算讓雙方都做好準備的話，一定要發送三次報文，而且只需要三次報文就可以了。如果再加上TCP的超時重傳機制，那么TCP就完全可以保證一個數據包被送到目的地。
TCP的終止
建立一個連接需要三次握手，而終止一個連接要經過4次握手，這是由TCP的半關閉（half close）造成的。既然一個 TCP連接是全雙工（即數據在兩個方向上能同時傳遞），因此每個方向必須單獨地進行關閉。這原則就是當一方完成它的數據發送任務后就能發送一個 FIN來終止這個方向連接。當一端收到一個 FIN，它必須通知應用層另一端幾經終止了那個方向的數據傳送。
客戶機給服務器一個FIN為1的TCP報文，然后服務器返回給客戶端一個確認ACK報文，并且發送一個FIN報文，當客戶機回復ACK報文后（四次握手），連接就結束了。
TCP的狀態變遷圖
TCP常見狀態
3.7 TCP計時器
為更平穩地執行操作，TCP使用至少四種計時器：重傳、堅持、保活和時間等待計時器
