http = TCP + 80 https = TCP + 443 ftp = TCP + 21

SMTP = TCP + 25 POP3 = TCP + 110 RDP = TCP + 3389

共享資料夾 = TCP + 445 SQL = TCP + 1433 DNS = UDP + 53 or TCP + 53（很少的時候）

3、應用層協議和服務之間的關係：

服務（對外提供的服務：Web、FTP、SMTP等）執行後，在TCP或UDP的某個埠來監聽客戶端的請求。

檢視自己計算機監聽的埠：netstat -an

4、Windows防火牆的作用：只開必要的埠。

運輸層是整個網路體系中的關鍵層次之一。一定要弄清楚以下一些重要的概念：

1、運輸層為相互通訊的應用程序提供邏輯通訊；

2、埠和套接字的意義；

3、無連線的UDP的特點；

4、面向連線的TCP的特點；

5、在不可靠的網路上實現可靠傳輸的工作原理，停止等待協議和ARQ協議；

6、TCP的滑動視窗、流量控制、擁塞控制和連線管理。

5.1 運輸層協議概述

5.1.1 程序之間的通訊

從通訊和資訊處理的角度看，運輸層向它上面的應用層提供通訊服務，它屬於面向通訊部分的最高層，同時也是使用者功能中的最低層。當網路的邊緣部分中的兩臺主機使用網路的核心部分的功能進行端到端的通訊時，只有主機的協議棧才有運輸層，而網路核心部分中的路由器在轉發分組時都只用到下三層的功能。

為什麼需要運輸層？

首先明確一個問題，兩臺主機通訊時，真正進行通訊的是兩臺主機中的程序。網路層指定明確這兩臺主機的IP地址，但是分組還停留在網路層而沒有交付到主機中的應用程序，所以需要運輸層支援程序與程序之間的資料交換。

如上圖所示，主機A的應用程序AP1和主機B的應用程序AP3通訊，同時，主機A的應用程序AP2和主機B的應用程序AP4進行通訊。這表明運輸層有一個很重要的功能：複用和分用。這裡的“複用”是指在傳送方不同的應用程序都可以使用同一個運輸層協議傳送資料，而“分用”是指接收方的運輸層在剝去報文的首部後能夠把這些資料正確交付目的應用程序。

圖中的邏輯通訊：指的是從應用層來看，只要把應用層報文交給下面的運輸層，運輸層就可以把這報文傳送到對方的運輸層，這種通訊就像是水平方向直接傳送資料。

網路層和運輸層的區別：網路層為主機之間提供邏輯通訊，而運輸層為應用程序之間提供端到端的邏輯通訊。

5.1.2 運輸層的兩個主要協議

1、使用者資料報協議UDP(User Datagram Protocol)

2、傳輸控制協議TCP(Transmission Control Protocol)

運輸層中的這兩種協議在TCP/IP協議棧中的位置如下圖所示：

按照OSI術語，兩個對等運輸實體在通訊時傳送的資料單元叫做運輸協議單元TPDU(Transport Protocol Data Unit)。但在TCP/IP體系中，則根據所使用的協議是TCP還是UDP，分別稱之為TCP報文段和UDP使用者資料報。

UDP的特點：UDP在傳送資料之前不需要建立連線，遠地主機的運輸層在收到UDP報文後，也不需要給出任何確認。雖然UDP是不可靠交付，但在某些情況下UDP確是一種最有效的工作方式。

TCP的特點：提供面向連線的服務。在傳送資料之前必須先建立連線，資料傳送結束後要釋放連線。TCP不提供廣播或多播服務。由於TCP要提供可靠的、面向連線的運輸服務，而不可避免地增加了許多開銷，如：確認、流量控制、計時器以及連線管理等。這不僅使協議單元的首部增大了很多，還要佔用許多處理機資源。

下表中列出了一些應用層協議使用的運輸層協議（UDP/TCP）：

應用	應用層協議	運輸層協議
名字轉換	DNS(域名系統)	UDP
檔案傳輸	TFTP(簡單檔案傳送協議)	UDP
路由選擇協議	RIP(路由資訊協議)	UDP
IP地址配置	DHCP(動態主機配置協議)	UDP
網路管理	SNMP(簡單網路管理協議)	UDP
遠端檔案伺服器	NFS(網路檔案系統)	UDP
IP電話	專用協議	UDP
流式多媒體通訊	專用協議	UDP
多播	IGMP(網際組管理協議)	UDP
電子郵件	SMTP(簡單郵件傳輸協議)	TCP
遠端終端接入	TELNET(遠端終端協議)	TCP
全球資訊網	HTTP(超文字傳輸協議)	TCP
檔案傳送	FTP(檔案傳送協議)	TCP

5.1.3 運輸層的埠

應用層的所有應用程序都可以通過運輸層再傳送到網路層，這就是複用。運輸層從網路層收到傳送給各應用程序的資料後，必須分別交付指明的各應用程序，這就是分用。顯然，給應用層的每個應用程序賦予一個非常明確的標誌至關重要。那麼運輸層採用的則是協議埠號(protocol port number)，或者簡稱埠(port)。

雖然通訊的終點是應用程序，但只要把所傳送的報文交到目的主機的某個合適的埠，剩下的工作（即交付給目的程序）就由TCP或UDP來完成。

TCP/IP的運輸層用一個16位埠號來標誌一個埠。但是需要注意的是埠號只具有本地意義。16位的埠號可允許有65535個不同的埠號。

網際網路上的計算機通訊是採用客戶-伺服器方式。客戶在發起通訊請求時，必須先知道對方伺服器的IP地址和埠號。因此運輸層的埠號分為下面兩大類：伺服器端使用的埠號和客戶端使用的埠號。

1、伺服器端使用的埠號又分為兩類：

（1）熟知埠號/系統埠號：數值為0~1023

（2）登記埠號：1024~49151

2、客戶端使用的埠號：49152~65535

5.2 使用者資料報協議UDP

5.2.1 UDP概述 ---- 重要【UDP的特點】

使用者資料報協議UDP只在IP的資料報服務之上增加了很少的一點功能，這就是複用和分用功能以及差錯檢測功能。UDP的主要特點如下：

1、UDP是無連線的，即傳送資料之前不需要建立連線，因此減少了開銷和傳送資料之前的時延；

2、UDP使用盡最大努力交付，即不保證可靠交付，因此主機不需要維持複雜的連線狀態表；

3、UDP是面向報文的。傳送方的UDP對應用程式交下來的報文，在新增首部後就向下交付IP層。UDP對應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界；

4、UDP沒有擁塞控制，因此網路出現的擁塞不會使源主機的傳送速率降低。這對某些實時應用是很重要的。很多實時應用（如IP電話、實時視訊會議等）要求源主機以恆定的速率傳送資料，並且允許在網路發生擁塞時丟失一些資料，但卻不允許資料有太大的時延。UDP正好適合這種要求；

5、UDP支援一對一、一對多、多對一和多對多的互動通訊；

6、UDP的首部開銷較小，只有8位元組，比TCP的20位元組的首部要短。

5.2.2 UDP的首部格式

如上圖所示：使用者資料報UDP有兩個欄位組成：首部欄位和資料欄位。

首部欄位比較簡單，一共就8個位元組，由四段組成，每個欄位都是兩個位元組。各欄位的意義如下：

1、源埠：源埠號，在需要對方回信時選用，不需要時可用全0；

2、目的埠：目的埠號，這在終點交付報文時必須使用；

3、長度：UDP使用者資料報的長度，其最小值是8（僅有首部）；

4、檢驗和：檢驗UDP使用者資料報在傳輸過程中是否有錯，有錯就丟棄。

這裡需要注意的兩點是：

1、雖然在UDP之間的通訊使用到其埠號，但是由於UDP的通訊是無連線的，因此不需要使用套接字（TCP之間的通訊必須要在兩個套接字之間建立連線）。

2、IP資料報的檢驗和只檢驗IP資料報的首部，但UDP的檢驗和是把首部和資料部分一起都檢驗。

5.3 傳輸控制協議TCP概述 ---- 重要

TCP的三個重點問題：

1、TCP協議如何實現可靠傳輸？

2、TCP協議如何實現流量控制？

3、TCP協議如何避免網路擁塞？

5.3.1 TCP最主要的特點 ---- 十分重要

TCP是TCP/IP體系中非常複雜的一個協議，下面介紹TCP最主要的特點：

1、TCP是面向連線的運輸層協議。即應用程式在使用TCP協議之前，必須先建立TCP連線。在傳送資料完畢後，也必須釋放連線；

2、每一條TCP連線只能有兩個端點(endpoint)，每一條TCP連線只能是點對點的（一對一）；

3、TCP提供可靠交付的服務。通過TCP連線傳送資料，無差錯、不丟失、不重複，並且按序到達；

4、TCP提供全雙工通訊（即：可同時接和收）。TCP允許通訊雙方的應用程序在任何時候都能傳送資料。TCP連線的兩端都設有傳送快取和接收快取，用來臨時存放雙向通訊的資料。在傳送時，應用程式在把資料傳送給TCP的快取後，就可以做自己的事，而TCP在合適的時候把資料傳送出去。在接收時，TCP把接收到的資料放入快取，上層應用程序在合適的時候讀取快取中的資料；

5、面向位元組流。TCP中的“流”(stream)指的是流入到程序或從程序流出的位元組序列。“面向位元組流”的含義是：雖然應用程式和TCP的互動是一次一個資料塊（大小不等），但TCP把應用程式交下來的資料僅僅看成是一連串的無結構資料流。TCP並不知道所傳送的位元組流的含義。TCP不保證接收方應用程式所收到的資料塊和傳送方應用程式所傳送的資料塊具有對應大小的關係（例如：傳送方應用程式交給傳送方的TCP共10個數據塊，但接收方的TCP可能只用了4個數據塊就把收到的位元組流交付上層的應用程式中）。但接收方應用程式收到的位元組流必須和傳送方應用程式發出的位元組流完全一樣。

TCP報文段先要傳送到IP層，加上IP首部後，再傳送到資料鏈路層，再加上資料鏈路層的首部和尾部後，才離開主機發送到物理鏈路。

TCP並不關心應用程式一次把多長的報文傳送到TCP的快取中，而是根據對方給出的視窗值和當前網路擁塞的程度來決定一個報文段應包含多少位元組（UDP傳送的報文長度是應用程序給出的，一次傳送完）。如果應用程序傳送到TCP快取的資料塊太長，TCP就可以把它劃分短一些再傳送。如果應用程序一次只發來一個位元組，TCP也可以等待積累有足夠多的位元組後再構成報文段傳送出去。

5.3.2 TCP的連線

TCP把連線作為最基本的抽象。

每一條TCP連線有兩個端點，它們叫套接字(socket)或插口。埠號拼接到IP地址後面就構成了套接字。如下所示：

套接字 socket = (IP地址: 埠號)

每一條TCP連線唯一地被通訊兩端的兩個端點（即兩個套接字）所確定：即

TCP連線 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}

同一個IP地址可以有多個不同的TCP連線，而同一個埠號也可以出現在多個不同的TCP連線中。

5.4 可靠傳輸的工作原理

TCP傳送的報文段是交給IP層傳送的。但是IP層只能提供盡最大努力交付，也就是說，TCP下面的網路所提供的是不可靠的傳輸。因此，TCP必須採用適當的措施使得兩個運輸層之間的通訊變得可靠。

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

1、傳輸通道不產生差錯；

2、不管傳送方以多快的速度傳送資料，接收方總是來得及處理收到的資料。

然而實際的網路都不具備以上兩個理想條件。但我們可以使用一些可靠傳輸協議，當出現差錯時讓傳送方重傳出現差錯的資料，同時在接收方來不及處理收到的資料，及時告訴傳送方適當降低傳送資料的速度。

簡單的說，實現可靠性傳輸就是：只要你沒告訴我，你收到了。那麼我就認為你沒收到，我就會給你重傳。

5.4.1 停止等待協議

說明：該協議並未在運輸層中使用，只是為了引出可靠性傳輸的問題。

“停止等待”就是每傳送完一個分組（資料單元）就停止傳送，等待對方的確認，在收到確認後再發送下一個分組。

在“停止等待”這個過程中會出現四種情況：無差錯情況、出現差錯，超時重傳、確認丟失和確認遲到。

1、無差錯情況

如下圖a所示：A傳送分組M1，發完就暫停傳送，等待B的確認。B收到了M1就向A傳送確認。A在收到了對M1的確認後，就再發送下一個分組M2。同樣，在收到B對M2的確認後，再發送M3。

2、出現差錯，超時重傳

如上圖b所示：B接收M1時檢測出了差錯，就丟棄M1，其他什麼也不做（不通知A收到有差錯的分組）。也有可能是M1在傳輸過程中丟失了，這時B當然什麼也不知道。在這兩種情況下，B都不會向A傳送任何訊息。

可靠性傳輸協議是這樣設計的：A只要超過了一段時間仍然沒有收到確認，就認為剛才傳送的分組丟失了，再重發前面傳送過的分組。這就叫做超時重傳。所以要在每傳送完一個分組時設定一個超時計時器。

這裡應該注意以下三點：

1、A傳送完一個分組後，必須暫時保留已傳送的分組的副本，在發生超時重傳時使用；

2、分組和確認分組都必須進行編號。這樣才能明確哪一個傳送出去的分組收到了確認，哪一個沒收到確認；

3、超時計時器設定的重傳時間應當比資料在分組傳輸的平均往返時間更長一些。

3、確認丟失

如下圖a中所示，B傳送的對M1的確認丟失了。A在設定的超時重傳時間內沒有收到確認，並無法知道是自己傳送的分組出錯、丟失，或者是B傳送的確認丟失了。因此A在超時計數器到期後就重傳M1。這時B又收到了重傳的分組M1，這時採取兩個行動：

1、丟棄這個重複的分組M1，不向上層交付；

2、向A傳送確認。不能認為已經發送過確認就不再發送了，因為A之所以重傳M1，就表示A沒有收到對M1的確認（雖然A不知道是自己傳送的分組出錯、丟失，或者是B傳送的確認丟失了，但是B知道是它傳送的確認丟失了）

4、確認遲到

如上圖b所示。傳輸過程中並沒有差錯，但是B對分組M1的確認遲到了。A會收到重複的確認（因為超時重傳M1後，會收到確認，而且這個確認在第一次M1確認的前面）。對重複的確認，A收下後就丟棄。B仍然會收到重複的M1，並且同樣丟棄，並重傳確認分組。

上訴的四種情況中使用的確認和重傳機制，我們就可以在不可靠的網路上實現可靠的通訊。這種可靠性傳輸協議稱為自動重傳請求ARQ(Automatic Repeat Request)。

5、通道利用率

停止等待協議的優點是簡單，但缺點是通道利用率太低。

如上圖所示：其中TD代表A傳送分組所需的時間，TA代表B傳送確認分組所需的時間，RTT是往返時間。則傳送一個分組需要（TD + RTT + TA），但是僅僅只有TD時間內才用來傳送資料。通道利用率U的計算公式如下：

為了提高傳輸效率，傳送方可以不使用低效率的等待協議，而是採用流水線傳輸。流水線傳輸就是傳送方可以連續傳送多個分組，不必每傳送完一個分組就停下來等待對方的確認。這樣可以使通道上一直有資料不間斷地在傳送。

當使用流水線傳輸時，就要用到下面介紹的連續ARQ協議和滑動視窗協議。

5.4.2 連續ARQ協議

滑動視窗協議比較複雜，也是TCP協議的精髓所在，後面會細講。這裡先給出連續ARQ協議最基本的概念。

如下圖所示，傳送方維持的傳送視窗，它的意義是：位於傳送視窗內的5個分組都可連續傳送出去，而不需要等待對方的確認。這樣，通道利用率就提高了。

連續ARQ協議規定，傳送方每收到一個確認，就把傳送視窗向前滑動一個分組的位置。

接收方一般都採用累計確認的方式。也就是說，接收方不必對收到的分組逐個傳送確認，而是在收到幾個分組後，對按序到達的最後一個分組傳送確認，這就表示接收方已經正確的收到的所有分組的資訊。

例如：如果傳送方傳送了前5個分組，而中間的第3個分組丟失了。這時接收方只能對前兩個分組發出確認。傳送方無法知道後面三個分組的下落，而只好把後面的三個分組都再重傳一遍。這就叫做Go-back-N(回退N)，表示需要最退回來重傳已經發送過的N個分組。

累積確認的優點：容易實現，即使確認丟失也不必重傳；

累積確認的缺點：不能向傳送方反映出接收方已經正確收到的所有分組資訊。

5.5 TCP報文段的首部格式

TCP雖然是面向位元組流的，但TCP傳送的資料單元卻是報文段。一個TCP報文段分為首部和資料兩部分，而TCP的全部功能都體現在它的首部中各欄位的作用。因此，只有弄清楚TCP首部各欄位的作用才能掌握TCP的工作原理。

TCP報文段首部的前20個位元組是固定的，後面有4n位元組是根據需要而增加的選項。因此TCP首部的最小欄位為20位元組。

1、源埠和目標埠

各佔2個位元組，分別寫入源埠和目標埠。和UDP一樣，TCP的分用功能也是通過埠實現的。

2、序號

佔4位元組。在一個TCP連線中傳送的位元組流中的每一個位元組都按照順序標號。整個要傳送的位元組流的起始序號必須在連線建立時設定。首部中的序號欄位值則指的是本報文段所傳送的資料的第一個位元組的序號。

3、確認號

佔4位元組，是期望收到對方下一個報文段的第一個資料位元組的序號。需要記住：

若確認號 = N，則表明：到序號N-1為止的所有資料都已正確收到。

下圖為XP向Web請求資源的過程，幫助理解序號和確認號。

4、資料偏移

佔4位，它指出TCP報文段的資料起始處距離TCP報文段的起始處有多遠。因為首部中有選項欄位，所以首部的總長度並不固定（最大值：60位元組，最小值20位元組）。

5、保留

佔6位，保留為以後用，目前值設定為0。

6、緊急UGR(URGent)

當UGR=1時，表明緊急指標欄位有效。它告訴系統此報文段中有緊急資料，應儘快傳送（相當於優先順序高的資料），而不是按照原來的排隊順序來傳送。例如：取消執行很久的程式。

當UGR的值為1時，傳送應用程序就告訴傳送方的TCP有緊急資料要傳送。於是傳送方TCP就把緊急資料插入到本報文段資料的最前面，而在緊急資料後面的資料仍是普通資料。這時要與首部中緊急指標欄位配合使用。

7、確認ACK(ACKnowledgment)

僅當ACK=1時，確認號欄位才生效。當ACK=0時，確認號無效。TCP規定，在連線建立之後所有的報文段都必須把ACK置1。

8、推送PSH(PuSH)

當兩個應用程序進行互動式的通訊時，有時在一端的應用程序希望在鍵入一個命令後立即就能收到對方的響應。這種情況下，TCP就可以使用推送（push）操作。傳送方TCP把PSH置1，並立即建立一個報文段傳送出去。接收方TCP收到PSH=1的報文段，就儘快交付接收應用程序，而不再等整個快取都填滿了後再向上交付。

9、復位RST(ReSeT)

當RST=1時，表明TCP連線中出現嚴重錯誤，必須釋放連線，然後再重新建立連線。

10、同步SYN(SYNchronization)

在連線建立時用來同步序號。當SYN=1而ACK=0時，表明這是一個連線請求報文段。對方若同意建立連線，則應在響應的報文段中使用SYN=1和ACK=1。因此，SYN置為1就表示這是一個連線請求或連線接受報文。連線後資料傳送過程SYN=0。

11、終止FIN(FINis)

用來釋放一個連線。當FIN=1時，表明此報文段的傳送方的資料已經發送完畢，並要求釋放運輸連線。

12、視窗Window

佔2個位元組。視窗指的是傳送本報文段的一方的接收視窗（而不是自己的傳送視窗）。視窗告訴對方：從本報文段首部中的確認號算起，接收方目前允許對方傳送的資料量。之所以要有這個限制，是因為接收方的資料快取空間是有限的。總之，視窗值作為接收方讓傳送方設定其傳送視窗的依據。

13、檢驗和

佔2個位元組。檢驗和欄位檢驗的範圍包括首部和資料這兩部分。和UDP一樣，在計算檢驗和時，需要加上TCP報文段前面的12個位元組的偽首部。

14、緊急指標

佔2個位元組。緊急指標僅在URG=1時才有意義，它指出本報文段中的緊急數的位元組數。因此，緊急指標指出了緊急資料末尾在報文段中的位置。

15、選項

長度可變，最長可達40位元組。當沒有使用“選項”欄位時，TCP的首部長度為20位元組。

下面列舉幾個選項：

最大報文長度MSS(Maximum Segment Size)：TCP報文段中資料欄位的最大值。預設值是536位元組。

視窗擴大：擴大視窗；

時間戳：計算往返時間RTT以及用於處理TCP序號超過2^32的情況，防止序號繞回。

.................等等

5.6 TCP可靠傳輸的實現 ---- 重要

5.6.1 以位元組為單位的滑動視窗

這部分內容可以看書《計算機網路》的221~223，傳送視窗和接收視窗之間的資料傳輸，由於過程比較繁瑣，就不再此做詳細記錄。這裡僅記錄下關鍵知識點。

TCP的滑動視窗是以位元組為單位的。

要描述一個傳送視窗A的狀態需要三個指標P1、P2和P3。它們的意義分別為：

1、小於P1的是已傳送並已收到確認的部分，而大於P3的是不允許傳送的部分；

2、P3 - P2 = A的傳送視窗；

3、P2 - P1 = 已傳送但未收到確認的位元組數；

4、P3 - P2 = 允許傳送但當前未傳送的位元組數（又稱為可用視窗或有效視窗）。

接收視窗B只能對按序收到的資料中的最高序號給出確認。

下面來看看TCP的快取和視窗的關係：

傳送快取用來暫時存放：

1、傳送應用程式傳送給傳送方TCP準備傳送的資料；

2、TCP已傳送出去但尚未收到確認的資料。

傳送視窗通常只是傳送快取的一部分。已被確認的資料應當從傳送快取中刪除。傳送應用程式必須控制寫入快取的速率，不能太快，否則傳送快取就會沒有存放資料的空間。

接受快取用來暫時存放：

1、按序到達的、但尚未被接收應用程式讀取的資料；

2、未按序到達的資料。

如果接收應用程式來不及讀取收到的資料，接收快取最終會被填滿，使接收視窗減小到零。反之，如果接收應用程式能夠及時從接收快取中讀取收到的資料，接收視窗就可以增大，但最大不能超過接收快取的大小。

結合上面的討論，需要強調三點：

雖然A的傳送視窗是根據B的接收視窗設定的，但在同一時刻，A的傳送視窗並不總是和B的接收視窗一樣大。需要考慮網路擁塞和通過網路傳送視窗產生的時間滯後；
對於不按序到達的資料先臨時存放在接收視窗中，等到位元組流中所缺少的位元組收到後，再按順序交付上層的應用程式；
TCP要求接收方必須有累積確認功能，可以減小傳輸開銷。接收方可以在合適的時候傳送確認，也可以在自己有資料要傳送時把確認資訊捎帶上。

5.6.2 超時重傳時間的選擇

TCP的傳送方在規定的時間內沒有收到確認就要重傳已傳送的報文段。

由於TCP的下層是網際網路環境，傳送的報文段可能只經過一個高速率的區域網，也可能經過多個低速率的網路，並且每個IP資料報所選擇的路由還可能不同。如果把超時重傳時間設定得太短，就會引起很多報文段的不必要重傳，使網路負荷增大。但若把超時重傳時間設定得過長，則又使網路的空閒時間增大，降低了傳輸效率。

上訴公式中的RTO即為超時重傳時間，RTTS為報文段的加權平均往返時間，RTTD是RTT的偏差的加權平均值。公式瞭解即可。

但是重傳報文段的時候會有一個問題：如何判定此確認報文段是對先發送的報文段的確認，還是對後來重傳的報文段的確認？這對設定超時重傳時間有很大的影響。

在計算加權平均RTTS時，只要報文段重傳了，就不採用其往返時間。這樣得出的加權平均RTTS和RTO就比較準確。

5.6.3 選擇確認SACK

若收到的報文段無差錯，只是未按序號，中間還缺少一些序號的資料，我們可以利用選擇確認SACK只傳送缺少的資料而不重傳已經正確到達接收方的資料。

如果這些位元組的序號都在接收視窗之內，那麼接收方就行先收下這些資料，但要把這些資訊準確地告訴對方，使傳送方不要再重複傳送這些已經收到的資料。

如果要使用選擇確認SACK，那麼建立TCP連線時，就要在TCP首部的選項中加上“允許SACK”的選項，而雙方必須事先商定好。

5.7 TCP的流量控制

5.7.1 利用滑動視窗實現流量控制

一般來說，我們總是希望資料傳輸的快一些。但如果傳送方把資料傳送得過快，接收方就可能來不及接收，這就造成資料的丟失。所謂流量控制（flow control）就是讓傳送方的傳送速率不要太快，要讓接收方來得及接收。

利用滑動視窗機制可以很方便地在TCP連線上實現對傳送方的流量控制。

下面這個例子說明如何利用滑動視窗機制進行流量控制。

從圖中可以看到B一共給A傳送了3次rwnd(receiver window)，即傳送方的傳送視窗不能超過接收方給出的接收視窗的數值。

圖中大寫的ACK表示首部中的確認位ACK，小寫ack表示確認欄位的值。

上訴案例中，接收方的主機B進行了三次流量控制。第一次把視窗減小到rwnd=300，第二次又減到rwnd=100，最後減到rwnd=0，即不允許傳送方再發送資料了。這種使傳送方暫停傳送的狀態將持續到主機B重新發出一個新的視窗值為止。

但是上訴過程有一個問題就是：B向A傳送了一個零視窗，但是過了不久，B的接收快取又有了一些儲存空間。於是B向A傳送了rwnd=400的報文段，但是這個報文段傳輸過程中丟了。A一直等待收到B傳送的非零視窗的通知，而B也一直等待A傳送的資料。如果沒有其他措施，這種互相等待的死鎖局面將一直延續下去。

為了解決上訴這個問題，TCP為每一個連線設有一個持續計數器（persistence timer）。只要TCP連線的一方收到對方的零視窗通知，就啟動持續計數器。若持續計數器設定的時間到期，就傳送一個零視窗探測報文段（僅攜帶1位元組的資料），而對方就在確認這個探測報文段時給出了現在的視窗值。如果視窗仍然是零，那麼收到這個報文段的一方就重新設定持續計數器。如果視窗不是零，那麼死鎖的僵局就可以打破了。

5.7.2 TCP的傳輸效率

可以用不同的機制來控制TCP報文段的傳送時機。例如：

第一種機制是：TCP維持一個變數，它等於最大報文段長度MSS。只要快取中存放的資料達到MSS位元組時，就組裝成一個TCP報文段發出去。

第二種機制是：由傳送方的應用程序指明要求傳送報文段，即TCP支援的推送（push）操作；

第三種機制是：傳送方的一個計時器期限到了，這時就把當前已有的快取資料裝入報文段（但長度不能超過MSS）傳送出去。

Nagle演算法：

若傳送應用程序要把傳送的資料逐個位元組地送到TCP的傳送快取，則傳送方就把第一個資料位元組先發出去，把後面到達的資料位元組都快取起來。當傳送方收到對第一個資料字元的確認後，再把傳送快取中的所有資料組裝成一個報文段發出去，同時繼續對隨後達到的資料進行快取。只有在收到對前一個報文段的確認後才繼續傳送下一個報文段。當資料較快而網路速率較慢時，用這樣的方法可明顯地減少所用的網路頻寬。Nagle演算法還規定，當到達的資料已達到傳送視窗大小的一半或已達到報文段的最大長度時，就立即傳送一個報文段。

解決糊塗視窗綜合徵（設定過小的接收視窗）：讓接收方等待一段時間，使得或者接收快取已有足夠空間容納一個最長的報文段，或者等到接收快取已有一半空閒空間。只要出現這兩種情況之一，接收方就發出確認報文，並向傳送方通知當前的視窗大小。

上面兩種方法可以配合使用，傳送方不要傳送很小的報文段的同時，接收方也不要在快取剛剛有了一點小的空間就急忙把這個很小的視窗大小資訊通知給對方。

5.8 TCP的擁塞控制 ---- 重要

這部分內容比較重要，書上講的很詳細，可以直接看書229~238頁。

5.8.1 擁塞控制的原理

在計算機網路中的鏈路容量（即頻寬）、交換結點中的快取和處理機等，都是網路的資源。在某段時間，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的效能就要變壞。這種情況就叫“擁塞”，出現擁塞的條件公式如下所示：

解決擁塞問題不能簡單的增加一些資源，比如，把結點快取的儲存空間擴大，更換高速鏈路等等，許多情況下簡單採用上訴做法都會引起一些列的其他問題，不但不能解決問題，還有可能使網路變得更壞。總之網路擁塞是一個多因素造成的結果，因此調整時也不能簡單的考慮某一因素，要綜合考慮各種因素。問題的實質往往是整個系統的各個部分不匹配，只有所有的部分都平衡了，問題才能得到解決。

擁塞控制：就是防止過多的資料注入到網路中，這樣可以使網路中的路由器或鏈路不致過載。

擁塞控制所要做的都有一個前提，就是網路能夠承受現有網路的網路負荷。

流量控制與擁塞控制的區別：

流量控制：往往是指點到點通訊的控制，是個端到端的問題（接收端控制傳送端）。流量控制要做的就是抑制傳送端傳送資料的速率，以便接收端來得及接收。

擁塞控制：是一個全域性性的過程，涉及到所有主機、所有的路由器、以及與降低網路傳輸效能有關的所有因素。

橫座標：提供的負載：代表單位時間內輸入給網路的分組數目；

縱座標：吞吐量：代表單位時間內從網路中輸出的分組數目。

理想擁塞控制的網路，在吞吐量飽和之前，網路吞吐量應等於提供的負載。

實際的網路中，隨著提供的負載的增大，網路吞吐量的增長速率逐漸減小，也就是說，在網路還沒有達到飽和時，就已經有一部分的輸入分組被丟棄了。

當網路的吞吐量明顯地小於理想的吞吐量時，網路進入了輕度擁塞的狀態；
當提供的負載達到某一數值時，網路的吞吐量反而隨提供的負載的增大而下降，這時網路就進入了擁塞狀態；
當提供的負載繼續增大到某一數值時，網路的吞吐量就下降到零，網路已無法工作，這就是所謂的死鎖狀態。

開環控制和閉環控制：

開環控制：在設計網路時事先將有關發生擁塞的因素考慮周到，力求網路在工作時不產生擁塞。但一旦整個系統執行起來，就不再中途進行改正了；
閉環控制基於反饋環路的概念，主要有以下幾種措施：

檢測網路系統以便檢測到擁塞何時、何處發生；
把擁塞發生的資訊傳送到可採取行動的地方；
調整網路系統的執行以解決出現的問題。

讀書筆記 ---- 《計算機網路—謝希仁第7版》---- 第5章 運輸層

網路層（上篇）：https://blog.csdn.net/pcwl1206/article/details/83999363

網路層（下篇）：https://blog.csdn.net/pcwl1206/article/details/84098381

第5章：運輸層