① 運輸層知識要點——謝希仁《計算機網路》
為了在計算機網路中有條不紊地交換數據，就必須遵守一些事先約定好的規則。這些規則明確規定了所 交換數據的格式 以及有關的 同步 問題。
同步的含義：在一定條件下應當發生什麼事件，因而含有時序的意思。
網路協議：為進行網路中的數據交換而建立的規則、標准或約定。
網路協議由以下三個要素組成：
1）語法：即數據與控制信息的結構或格式
2）語義：即需要發出何種控制信息，完成何種動作以及做出何種反應
3）同步：即事件實現順序的詳細說明
一、運輸層協議的概述
1.1 進程之間的通信
1.2 運輸層的兩個主要協議
1.3 運輸層的埠
二、用戶數據報協議UDP
2.1 UDP概述
2.2 UDP的首部格式
三、傳輸控制協議TCP概述
3.1 TCP的最主要的特點
3.2 TCP的連接
四、可靠傳輸的工作原理
4.1 停止等待協議
4.2 連續ARQ協議
五、TCP報文段的首部格式
六、TCP可靠傳輸的實現
6.1 以位元組為單位的滑動窗口
6.2 超時重傳時間的選擇
6.3 選擇確認SACK
七、TCP的流量控制
7.1 利用滑動窗口實現流量控制
7.2 必須考慮傳輸效率
八、TCP的擁塞控制
8.1 擁塞控制的一般原理
8.2 幾種擁塞控制方法
8.3 隨機早期檢測RED
九、TCP的運輸連接管理
9.1 TCP的連接建立
9.2 TCP的連接釋放
9.3 TCP的有限狀態機
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
1.1 進程之間的通信
1.只有主機的協議棧才有運輸層，而網路核心部分中的路由器在轉發分組時都只用到了下三層的功能
2.兩個主機進行通信就是兩個主機中的應用進程互相通信。從運輸層的角度看，通信的真正端點並不是主機而是主機中的進程。（IP協議能把分組送到目的主機）
網路層時為主機之間提供邏輯通信，而運輸層為應用進程之間提供端到端的邏輯通信。
3.運輸層一個重要功能——復用、分用。 （應用進程復用、分用運輸層）
1.2 運輸層的兩個主要協議
1.UDP—User Datagram Protocol 用戶數據報協議（無連接）：DNS/RIP/DHCP/SNMP/NFS
TCP—Transmission Control Protocol 傳輸控制協議（面向連接）：SMTP/TELNET/HTTP/ FTP
1.3 運輸層的埠
問題：為了使運行不同操作系統的計算機的應用進程能夠互相通信，就必須使用統一的方法（而這種方法必須與特定操作系統無關）對TCP/IP體系的應用進程進行標識。
為什麼不用進程號來區分？（第一，不同操作系統的進程標識符不同；第二，用功能來識別，而不是進程，例如郵件服務功能，而不管具體是哪個進程）
解決方案：在運輸層使用協議埠號，即埠。軟體埠是應用層的各種協議進程與運輸實體進行層間交互的一種地址。（埠號只具有本地意義，只是為了標識本計算機應用層中各個進程在和運輸層交互時的層間介面。）
埠分為兩大類：
1）伺服器使用的埠號：熟知埠號或系統埠號（0~1023）；登記埠號（1024~49151）
2）客戶端使用的埠號：49152~65535
2.1 UDP概述
1.UDP只在IP的數據報服務至上增加了很少一點功能，就是復用、分用以及差錯檢測功能
2.特點
1）無連接
2）盡最大努力交付
3）面向報文 （不合並、不拆分、保留這些報文的邊界）
4）UDP沒有擁塞控制
5）UDP支持一對一、一對多、多對一和多對多的交互通信
6）UDP的首部開銷小，只有8位元組
應用進程本身可以在不影響應用的實時性的前提下，增加一些提高可靠性的措施，如採用前向糾錯或重傳已丟失的報文。
2.2 UDP的首部格式
1.traceroute 讓發送的UDP用戶數據報故意使用一個非法的UDP埠號，接收方丟棄報文，並由ICMP（網路控制報文協議）發送「埠不可達」差錯報文給發送方。
2.計算檢驗和。IP數據報的校驗和只檢驗IP數據報的首部，但UDP的校驗和是把首部和數據部分一起都檢驗。（12位元組的首部+真正的首部+數據來進行校驗和的計算）
Q1.為什麼計算校驗和要加12位元組的偽首部
Q2.計算校驗和的原理是什麼？
3.1 TCP的最主要的特點
1.面向連接的運輸層協議（建立連接、傳輸數據、釋放連接）
2.點對點，每一條TCP連接只能有兩個端點
3.可靠交付（無差錯、不丟失、不重復、並且按序到達）
4.全雙工通信。TCP連接的兩端都設有發送緩存和接收緩存。
5.面向位元組流。（流指的是流入到進程或從進程流出的位元組序列；面向位元組流：TCP把應用程序交下來的數據看成是一連串的無結構位元組流。 接收方的應用程序必須有能力識別接收到的位元組流，把它還原成有意義的應用層數據。 因此TCP可以根據窗口值和當前網路狀況調整發送的報文長度。劃分短一點，或者積累到足夠多再發送出去。）
3.2 TCP的連接
1.TCP把連接作為最基本的抽象。
2.每一條TCP連接有兩個端點。TCP連接的端點叫作套接字。
套接字soket = （IP地址：埠號）
每一條TCP連接唯一地被通信兩端的兩個端點（即兩個套接字）所確定。
TCP連接 ::= {socket1, socket2}
理想的傳輸條件有以下兩個特點：
1）傳輸信道不產生差錯
2）不管發送方以多快的速度發送數據，接收方總是來得及處理收到的數據
實際的網路並不具備，因此：
1）出現差錯時，讓發送方重傳
2）接收方來不及處理時，及時告訴發送方適當降低發送數據的速度
4.1 停止等待協議
1.「停止等待」就是沒發送完一個分組就停止發送，等待對方的確認，在收到確認後再發送下一個分組。
2.超時重傳。在每發完一個分組就設置一個超時計時器，如果在超時計時器之前收到對方的確認，就撤銷已設置的超時計時器。如果未收到，就認為剛才的分組丟失，並重傳。
3.三種情況：A發送的分組出錯、丟失；B發送的確認丟失；B發送的確認遲到
確認丟失：B丟棄重復的分組，向A重傳確認
確認遲到：A丟棄重復的確認，B丟棄重復分組，並向A重傳確認
4.常稱為自動重傳請求ARQ，重傳時自動進行的（超時即重傳）
5.缺點：信道利用率太低
U=Td/(Td+RTT+Ta)
為了提高傳輸效率，發送方不使用停止等待協議，而是採用流水線傳輸。流水線傳輸就是發送發可連續發送多個分組，不必等每發完一個分組就停頓下來等待對方的確認。（連續ARQ協議和滑動窗口協議）
4.2 連續ARQ協議
1.位於發送窗口內的分組都可連續發送出去，而不需要等待對方的確認。
2.累積確認：接收方不必對收到的分組逐個發送確認，而是在收到幾個分組後，對按序到達的最後一個分組發送確認。
3.缺點：Go-back-N （發送前5個分組，第3個分組丟失，後面三個要重傳）
1.源埠和目的埠
2.序號。 每個位元組都按順序編號。
3.確認號。 期望收到對方下一個報文段的第一個數據位元組的序號。
若確認號=N，則表明：到序號N-1為止的所有數據都已正確收到。
4.數據偏移。 指出TCP報文段的數據起始處距離TCP報文段的起始處有多遠（也即TCP報文段首部長度）。由於首部中還有長度不確定的選項欄位，因此數據偏移欄位是必要的。
5.窗口。窗口欄位明確指出了現在允許對方發送的數據量。窗口值是經常在動態變化著。
6.1 以位元組為單位的滑動窗口
1.發送緩存用來暫存：
1）發送應用程序傳送給發送方TCP准備發送的數據；
2）TCP已發送但未收到確認德爾數據
2.接收緩存用來存放：
1）按序到達的、但尚未被接收應收程序讀取的數據；
2）未按序到達的數據
3.注意三點：
1）A的發送窗口是根據B的接收窗口設置的，但是在同一時刻，由於網路傳輸的滯後，A的發送窗口並不總是B的接收窗口一樣大
2）TCP通常對不按序到達的數據是先臨時存放在接收窗口中，等到位元組流中所缺少的位元組收到後，再按序交付上層的應用進程
3）TCP接收方有累計確認功能（不能過分推遲發送確認，否則會導致發送方不必要的重傳）
6.2 超時重傳時間的選擇
1.超時重傳時間設置太短，會引起很多不必要的重傳；如果設置太長，使網路的空閑時間增大，降低傳輸效率。
2.新的RTTs = (1-a)x(舊的RTTs) + ax（新的RTT樣本），其中RTT樣本的時間為：記錄一個報文段發出的時間，以及收到相應的確認時間，時間差就是報文段的往返時間RTT。
3.RTO = RTTs + 4 x RTTd，其中RTO為超時重傳時間，RTTd是RTT的偏差的加權平均值。
新的RTTd = (1-b) x （舊的RTTd）+ b x |RTTs - 新的RTT樣本|
4.一個問題：發送一個報文段，設定的重傳時間到了，還沒有收到確認。於是重傳報文段。經過一段時間，收到了確認報文段。現在的問題是：如何判定此確認報文段是對先發送的報文段的確認，還是對後來重傳的報文段的確認？
1）解決方法1，在計算加權平均值RTTs時，只要報文段重傳了，就不採用其往返時間樣本。
引入的問題：報文段的時延突然增大的情況
2）解決方法2，報文段每重傳一次，就把超時重傳時間RTO增大一些（一般是2倍）。當不在發生報文段的重傳時，再根據加權平均計算。
6.3 選擇確認SACK
SACK文檔並沒有指明發送發應當怎樣響應SACK。因此大多數的實現還是重傳所有未被確認的數據塊。
7.1 利用滑動窗口實現流量控制
1.流量控制：就是讓發送方的發送速率不要太快，要讓接收方來得及接收。
2.利用滑動窗口機制可很方便地在TCP連接上實現對發送方的流量控制。發送方的發送窗口不能超過接收方給出的接收窗口的數值。
3.死鎖情況：B向A發送了零窗口的報文段後不久，B又有了一些緩存空間，因此B向A發送rwnd = 400.然而該報文段在傳送過程中丟失。A一直等待B發送的非零窗口的通知，B也一直等待A發送的數據。（ 窗口通知不超時重傳？為什麼？ ）
解決方法：TCP為每個連接設有一個持續計時器。只要一方收到對方的零窗口通知，就啟動計時器。計時器到期後，發送一個零窗口探測報文段，而對方就在確認這個探測報文段時給出了現在的窗口值。若仍為零，收到報文段的一方重新設置持續計時器。
7.2 必須考慮傳輸效率
1.應用程序把數據傳送到TCP的發送緩存後，剩下的發送任務就由TCP來控制了。
2.三種不同的機制來控制TCP報文段的發送時機：
1）TCP維持一個變數，它等於最大報文段長度MSS，只要緩存中的存放的數據達到MSS，就組裝成一個TCP報文段發送出去
2）由發送方的應用進程指明要求發送報文段，即TCP支持推送操作
3）發送方設置一個定時器
3.問題一、若用戶只發送一個位元組，則非常浪費帶寬。
解決方法：若發送應用程序把要發送的數據逐個位元組地送到TCP的發送緩存，則發送方就把第一個數據位元組先發送出去，把後面到達的數據位元組都緩存起來。當發送方收到對第一個數據字元的確認後，再把發送緩存中的所有數據組裝成一個報文段發送出去。（採用收到確認就發送+並開始緩存的方式；同時當到達的數據已達到發送窗口大小的一半或已達到報文段的最大長度時，就立即發送一個報文段。）
4.問題二、糊塗窗口綜合症。接收緩存已滿，應用程序一次只讀取一個位元組，然後向發送方發送確認。
解決方法：讓接收方等待一段時間，使得接收緩存已有足夠空間容納一個最長的報文段，或者等到接收緩存已有一半空閑的空間。則接收方就發出確認報文。
8.1 擁塞控制的一般原理
1.擁塞的定義：對資源的需求 > 可用資源。 在計算機網路中的鏈路帶寬、交換結點中的緩存和處理機等，都是網路中的資源。
2.擁塞解決不能靠解決某一個部分的問題。因為這會將瓶頸轉移到其他地方。問題的實質往往是整個系統的各個部分不匹配。只有所有部分都平衡了，問題才會得到解決。
3.擁塞控制與流量控制的比較。
1）擁塞控制：防止過多的數據注入到網路中，這樣可以使網路中的路由器或鏈路不致過載。
擁塞控制有個前提：網路能夠承受現有的網路負荷
擁塞控制是一個全局性過程。（發送擁塞時，不知道在某處、什麼原因造成的）
2）流量控制：點對點通信量的控制，是個端到端的問題
流量控制：抑制發送端發送數據的速率，以便使接收端來得及接收。
4.尋找擁塞控制的方案無非就是使不等式 「對資源的需求 > 可用資源 」不再成立的條件。但是必須考慮該措施帶來的其他影響。
5.計算機網路是個復雜的系統。從控制理論的角度來看擁塞控制，可以分為開環控制和閉環控制兩種方法。
1）開環控制：設計網路時事先將有關發生擁塞的因素考慮周到，力求網路在工作時不產生擁塞。但一旦系統運行起來，就不再中途改正。
2）閉環控制：基於反饋環路。
步驟一、監測網路系統以便檢測到擁塞在何時、何處發生；
步驟二、把擁塞發生的信息傳送到可採取行動的地方
步驟三、調整網路系統的運行以解決出現的問題
8.2 幾種擁塞控制方法（只考慮網路擁塞程度，即假設接收方總是有足夠大的緩存空間）
1.慢開始和擁塞避免
1）發送方維持一個擁塞窗口。
擁塞窗口的大小取決於網路的擁塞程度，並且動態地在變化。
控制擁塞窗口的原則是：只要網路沒有出現擁塞，擁塞窗口增大；如果網路出現擁塞，則減小。
2）慢開始的思路：由小到大逐漸增大擁塞窗口數值。每收到一個對新的報文段的確認，把擁塞窗口增加至多一個MSS的數值。（沒經過一個傳輸輪次，擁塞窗口cwnd就加倍）
輪次：把擁塞窗口所允許發送的報文段都連續發送出去，並收到了對已發送的最後一位元組的確認。
慢開始的「慢」並不是指cwnd的增長速率慢，而是指TCP開始發送報文段時先設置cwnd=1（一個MSS數值）。
3）慢開始門限ssthresh
為防止擁塞窗口增長過大，引入一個慢開始門限ssthresh。
當cwnd < ssthresh時，使用上述的慢開始演算法
當cwnd > ssthresh時，停止使用慢開始演算法而改用擁塞避免演算法
4）擁塞避免演算法
思路：讓擁塞窗口cwnd緩慢增大，即沒經過一個往返時間RTT就把發送方的擁塞窗口cwnd增加1，而不是加倍。
5）慢開始門限的設置
只要發送方判斷網路出現擁塞（沒有按時收到確認），就把慢開始門限ssthresh設置為出現擁塞時發送方窗口值的一半，然後把擁塞窗口cwnd重置為1，執行慢開始演算法。
6）乘法減小和加法增大
乘法減小：網路出現擁塞時，把慢開始門限ssthresh減半（當前的ssthresh的一半），並執行慢開始演算法。
加法增大：執行擁塞避免方法
2.快重傳和快恢復
1）快重傳（盡快重傳未被確認的報文段）
首先，要求接收方每收到一個失序的報文段後就立即發出重復確認。（如接收方收到了M1和M2後都分別發出了確認，但接收方沒有收到M3但接著收到了M4。此時接收方立即發送對M2的重復確認。）
其次，發送方只要一連收到三個重復確認，就應當立即重傳對方尚未收到的報文段M3.
2）快恢復
要點一、當發送方連續收到三個重復確認，就執行「乘法減小」演算法，把慢開始門限ssthresh減半。
要點二、由於發送方認為網路很可能沒有發生擁塞（因為收到了連續的重復確認），把cwnd設置為慢開始門限ssthresh減半後的值，然後開始執行擁塞避免演算法
慢開始演算法只在TCP連接建立時和網路出現超時才使用。
3.發送方的窗口
發送方窗口的上限值 = Min [rwnd, cwnd]
8.3 隨機早期檢測RED（IP層影響TCP層的擁塞控制）
1.網路層的分組丟棄策略
網路層的策略對TCP擁塞控制影響最大的就是路由器的分組丟棄策略。
如果路由器隊列已滿，則後續到達的分組將都被丟棄。這就叫做尾部丟棄策略。
2.全局同步
由於TCP復用IP，若發生路由器中的尾部丟棄，就可能會同時影響到很多條TCP連接，結果就使許多TCP連接在同一時間突然都進入到慢開始狀態。全局同步使得全網的通信量突然下降了很多，網路恢復正常後，其通信量又突然增大很多。
3.隨機早期檢測RED
使路由器的隊列維持兩個參數，即隊列長度最小門限THmin和最大門限THmax。當每一個分組到達時，RED就先計算平均隊列長度Lav。RED演算法是：
1）若平均隊列長度小於最小門限THmin，則把新到達的分組放入隊列進行排隊
2）若平均隊列長度超過最大門限THmax，則把新到達的分組丟棄
3）若平均隊列長度在最小門限THmin和最大門限THmax之間，則按照某一概率p將新到達的分組丟棄。
隨機體現在3），在檢測到網路擁塞的早期徵兆時（即路由器的平均隊列長度超過一定的門限值時），就先以概率p隨機丟棄個別的分組，讓擁塞控制只在個別的TCP連接上進行，因而避免發生全局性的擁塞控制。
4.平均隊列長度Lav和分組丟棄概率p
Lav = (1-d) x (舊的Lav) +d x (當前的隊列長度樣本)
p = ptemp / (1- count x ptemp)
ptemp = pmax x (Lav - THmin) / (THmax - THmin)
TCP時面向連接的協議。
運輸連接就有三個階段：連接建立、數據傳送和連接釋放
運輸連接的管理：使運輸連接的建立和釋放都能正常地進行。
在TCP連接建立過程中要解決以下三個問題：
1）要使每一方能夠確知對方的存在
2）要允許雙方協商一些參數（如最大窗口值、是否使用窗口擴大選項和時間戳等等）
3）能夠對運輸實體資源（如緩存大小、連接表中的項目等）進行分配
9.1 TCP的連接建立
1.TCP規定，SYN=1報文段不能攜帶數據，但消耗一個序號
2.TCP規定，ACK=1報文段可以攜帶數據，如果不攜帶數據則不消耗序號
3.為什麼A還要發送一次確認？為了防止已失效的連接請求報文突然又傳送到B，因而產生錯誤。
「已失效的連接請求報文段」
A發出第一個連接請求報文段，在網路中滯留超時，又發出了第二個連接請求。但B收到第一個延遲的失效的連接請求報文段後，就誤認為是A又發出了一次新的連接請求。於是就向A發出確認報文段，同意建立連接。假定不採用三次握手，那麼只要B發出確認，新的連接就建立。此時A不會理睬B的確認，也不會發數據，但B一直等A發送數據，B的許多資源就浪費了。
採用三次握手，A不會向B發送確認，因此B就知道A並沒有要求建立確認。
9.2 TCP的連接釋放
1.TCP規定，FIN報文段基石不攜帶數據，也消耗一個序號
2.第二次握手後，TCP通知高層應用程序，因而從A到B這個方向的連接就釋放，TCP連接處於半關閉狀態
3.為什麼A在TIME-WAIT狀態必須等待2MSL的時間
1）為了保證A發送的最後一個ACK報文段能夠到達B。因為ACK可能丟失，此時B可能會超時重傳，然後A重傳確認，並重新啟動2MSL計時器
2）防止「已失效的連接請求報文段」出現在本連接中。可以使本連接持續時間內所產生的所有報文段都從網路中消失。
9.3 TCP的有限狀態機
② 計算機網路——TCP/UDP協議
計算機網路七層模型中，傳輸層有兩個重要的協議：
（1）用戶數據報協議UDP (User Datagram Protocol)
（2）傳輸控制協議TCP (Transmission Control Protocol)
UDP 在傳送數據之前不需要先建立連接。遠地主機的運輸層在收到UDP 報文後，不需要給出任何確認。雖然UDP 不提供可靠交付，但在某些情況下UDP 卻是一種最有效的工作方式。
TCP 則提供面向連接的服務。在傳送數據之前必須先建立連接，數據傳送結束後要釋放連接。TCP 不提供廣播或多播服務。由於TCP 要提供可靠的、面向連接的運輸服務，因此不可避免地增加了許多的開銷，如確認、流量控制、計時器以及連接管理等。
UDP 的主要特點是：
首部手段很簡單，只有8 個位元組，由四個欄位組成，每個欄位的長度都是兩個位元組。
前面已經講過，每條TCP 連接有兩個端點，TCP 連接的端點叫做套接字（socket）或插口。套接字格式如下：
套接寧socket= (IP 地址：埠號』）
每一條TCP 連接唯一地被通信兩端的兩個端點（即兩個套接宇）所確定。即：
TCP 連接＝ {socket1, socket2} = {(IP1: port1), (IP2: port2)}
3次握手鏈接
4次握手釋放鏈接
斷開連接請求可以由客戶端發出，也可以由伺服器端發出，在這里我們稱A端向B端請求斷開連接。
各個狀態節點解釋如下：
下面為了討論問題的萬便，我們僅考慮A發送數據而B 接收數據並發送確認。因此A 叫做發送方，而B 叫做接收方。
「停止等待」就是每發送完一個分組就停止發送，等待對方的確認。在收到確認後再發送下一個分組。
使用上述的確認和重傳機制，我們就可以在不可靠的傳輸網路上實現可靠的通信。像上述的這種可靠傳輸協議常稱為自動重傳請求ARQ (Automatic Repeat reQuest）。意思是重傳的請求是自動進行的。接收方不需要請求發送方重傳某個出錯的分組。
滑動窗口協議比較復雜，是TCP 協議的精髓所在。這里先給出連續ARQ 協議最基本的概念，但不涉提到許多細節問題。詳細的滑動窗口協議將在後面討論。
下圖表示發送方維持的發送窗口，它的意義是：位於發送窗口內的5 個分組都可連續發送出去，而不需要等待對方的確認。這樣，信道利用率就提高了。
連續ARQ 協議規定，發送方每收到一個確認，就把發送窗口向前滑動一個分組的位置。
接收方一般都是採用 累積確認 的方式。這就是說，接收方不必對收到的分組逐個發送確認，而是可以在收到幾個分組後，對按序到達的最後一個分組發送確認，這樣就表示：到這個分組為止的所有分組都己正確收到了。
累積確認 的優點是容易實現，即使確認丟失也不必重傳。但缺點是不能向發送方反映出接收方己經正確收到的所有分組的信息。
例如，如果發送方發送了前5 個分組，而中間的第3 個分組丟失了。這時接收方只能對前兩個分組發出確認。發送方無法知道後面三個分組的下落，而只好把後面的三個分組都再重傳一次。這就叫做Go-back-N （回退N ），表示需要再退回來重傳己發送過的N 個分組。可見當通信線路質量不好時，連續ARQ 協議會帶來負面的影響。
TCP 的滑動窗口是以位元組為單位的。現假定A 收到了B 發來的確認報文段，其中窗口是20 （位元組），而確認號是31 （這表明B 期望收到的下一個序號是31 ，而序號30 為止的數據己經收到了）。根據這兩個數據， A 就構造出自己的發送窗口，其位置如圖所示。
發送窗口表示：在沒有收到B 的確認的情況下， A可以連續把窗口內的數據都發送出去。凡是己經發送過的數據，在未收到確認之前都必須暫時保留，以便在超時重傳時使用。
發送窗口後沿的後面部分表示己發送且己收到了確認。這些數據顯然不需要再保留了。而發送窗口前沿的前面部分表示不允許發送的，因為接收方都沒有為這部分數據保留臨時存放的緩存空間。
現在假定A 發送了序號為31 ～ 41 的數據。這時發送窗口位置並未改變，但發送窗口內靠後面有11個位元組（灰色小方框表示）表示己發送但未收到確認。而發送窗口內靠前面的9 個位元組（ 42 ～ 50 ）是允許發送但尚未發送的。】
再看一下B 的接收窗口。B 的接收窗口大小是20，在接收窗口外面，到30 號為止的數據是已經發送過確認，並且己經交付給主機了。因此在B 可以不再保留這些數據。接收窗口內的序號（31～50）足允許接收的。B 收到了序號為32 和33 的數據，這些數據沒有按序到達，因為序號為31 的數據沒有收到（也許丟失了，也許滯留在網路中的某處）。 請注意， B 只能對按序收到的數據中的最高序號給出確認，因此B 發送的確認報文段中的確認號仍然是31 （即期望收到的序號）。
現在假定B 收到了序號為31 的數據，並把序號為31～33的數據交付給主機，然後B刪除這些數據。接著把接收窗口向前移動3個序號，同時給A 發送確認，其中窗口值仍為20，但確認號是34，這表明B 已經收到了到序號33 為止的數據。我們注意到，B還收到了序號為37, 38 和40 的數據，但這些都沒有按序到達，只能先存在接收窗口。A收到B的確認後，就可以把發送窗口向前滑動3個序號，指針P2 不動。可以看出，現在A 的可用窗口增大了，可發送的序號范圍是42～53。整個過程如下圖：
A 在繼續發送完序號42-53的數據後，指針P2向前移動和P3重合。發送窗口內的序號都已用完，但還沒有再收到確認。由於A 的發送窗口己滿，可用窗口己減小到0，因此必須停止發送。
上面已經講到， TCP 的發送方在規定的時間內沒有收到確認就要重傳已發送的報文段。這種重傳的概念是很簡單的，但重傳時間的選擇卻是TCP 最復雜的問題之一。
TCP採用了一種自適應演算法 ，它記錄一個報文段發出的時間，以及收到相應的確認的時間。這兩個時間之差就是報文段的往返時間RTT，TCP 保留了RTT的一個加權平均往返時間RTTs （這又稱為平滑的往返時間， S 表示Smoothed 。因為進行的是加權平均，因此得出的結果更加平滑）。每當第一次測量到RTT樣本時， RTTs值就取為所測量到的RTT樣本值。但以後每測量到一個新的RTT樣本，就按下式重新計算一次RTTs:
新的RTTs = (1 － α）×（舊的RTTs) ＋ α ×（新的RTT樣本）
α 越大表示新的RTTs受新的RTT樣本的影響越大。推薦的α 值為0.125，用這種方法得出的加權平均往返時間RTTs 就比測量出的RTT值更加平滑。
顯然，超時計時器設置的超時重傳時間RTO (RetransmissionTime-Out）應略大於上面得出的加權平均往返時間RTTs。RFC 2988 建議使用下式計算RTO:
RTO = RTTs + 4 × RTTd
RTTd是RTT 的偏差的加權平均值，它與RTTs和新的RTT樣本之差有關。計算公式如下：
新的RTTd= (1- β）×（舊的RTTd) + β × |RTTs－新的RTT樣本|
發現問題： 如圖所示，發送出一個報文段。設定的重傳時間到了，還沒有收到確認。於是重
傳報文段。經過了一段時間後，收到了確認報文段。現在的問題是：如何判定此確認報文段是對先發送的報文段的確認，還是對後來重傳的報文段的確認？
若收到的確認是對重傳報文段的確認，但卻被源主機當成是對原來的報文段的確認，則這樣計算出的RTTs 和超時重傳時間RTO 就會偏大。若後面再發送的報文段又是經過重傳後才收到確認報文段，則按此方法得出的超時重傳時間RTO 就越來越長。
若收到的確認是對原來的報文段的確認，但被當成是對重傳報文段的確認，則由此計算出的RTTs 和RTO 都會偏小。這就必然導致報文段過多地重傳。這樣就有可能使RTO 越來越短。
Kam 提出了一個演算法：在計算加權平均RTTs 時，只要報文段重傳了就不採用其往返時間樣本。這樣得出的加權平均RTTs 和RTO 就較准確。
新問題： 設想出現這樣的情況：報文段的時延突然增大了很多。因此在原來得出的重傳時間內，不會收到確認報文段。於是就重傳報文段。但根據Kam 演算法，不考慮重傳的報文段的往返時間樣本。這樣，超時重傳時間就無法更新。
解決方案： 對Kam 演算法進行修正，方法是z報文段每重傳一次，就把超時重傳時間RTO 增大一些。典型的做法是取新的重傳時間為2 倍的舊的重傳時間。當不再發生報文段的重傳時，才根據上面給出的公式計算超時重傳時間。
流量控制（flow control）就是讓發送方的發送速率不要太快，要讓接收方來得及接收。
利用滑動窗口機制可以很方便地在TCP 連接上實現對發送方的流量控制。
接收方的主機B 進行了三次流量控制。第一次把窗口減小到rwnd =300，第二次又減到rwnd = 100 ，最後減到rwnd = 0 ，即不允許發送方再發送數據了。這種使發送方暫停發送的狀態將持續到主機B 重新發出一個新的窗口值為止。我們還應注意到，B 向A 發送的三個報文段都設置了ACK=1，只有在ACK=1 時確認號欄位才有意義。
發生死鎖： 現在我們考慮一種情況。上圖中， B 向A 發送了零窗口的報文段後不久， B 的接收緩存又有了一些存儲空間。於是B 向A 發送了rwnd = 400 的報文段。然而這個報文段在傳送過程中丟失了。A 一直等待收到B 發送的非零窗口的通知，而B 也一直等待A 發送的數據。如果沒有其他措施，這種互相等待的死鎖局面將一直延續下去。
解決方案： TCP 為每一個連接設有一個 持續計時器（persistence timer） 。只要TCP 連接的一方收到對方的零窗口通知，就啟動持續計時器。若持續計時器設置的時間到期，就發送一個 零窗口探測報文段 （僅攜帶1 宇節的數據），而對方就在確認這個探測報文段時給出了現在的窗口值。
1 TCP連接時是三次握手，那麼兩次握手可行嗎？
在《計算機網路》中是這樣解釋的：已失效的連接請求報文段」的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連接釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認為是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不採用「三次握手」，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送ACK包。這樣就會白白浪費資源。而經過三次握手，客戶端和伺服器都有應有答，這樣可以確保TCP正確連接。
2 為什麼TCP連接是三次，揮手確是四次？
在TCP連接中，伺服器端的SYN和ACK向客戶端發送是一次性發送的，而在斷開連接的過程中，B端向A端發送的ACK和FIN是是分兩次發送的。因為在B端接收到A端的FIN後，B端可能還有數據要傳輸，所以先發送ACK，等B端處理完自己的事情後就可以發送FIN斷開連接了。
3 為什麼在第四次揮手後會有2個MSL的延時？
MSL是Maximum Segment Lifetime，最大報文段生存時間，2個MSL是報文段發送和接收的最長時間。假定網路不可靠，那麼第四次發送的ACK可能丟失，即B端無法收到這個ACK，如果B端收不到這個確認ACK，B端會定時向A端重復發送FIN，直到B端收到A的確認ACK。所以這個2MSL就是用來處理這個可能丟失的ACK的。
1 文件傳送協議
文件傳送協議FTP (File Transfer Protocol) [RFC 959］是網際網路上使用得最廣泛的文件傳送協議，底層採用TCP協議。
盯P 使用客戶伺服器方式。一個FTP 伺服器進程可同時為多個客戶進程提供服務。FTP的伺服器進程由兩大部分組成：一個主進程，負責接受新的請求：另外有若干個從屬進程，負責處理單個請求。
在進行文件傳輸時，客戶和伺服器之間要建立兩個並行的TCP 連接：「控制連接」（21埠）和「數據連接」（22埠）。控制連接在整個會話期間一直保持打開， FTP 客戶所發出的傳送請求，通過控制連接發送給伺服器端的控制進程，但控制連接並不用來傳送文件。實際用於傳輸文件的是「數據連接」。伺服器端的控制進程在接收到FTP 客戶發送來的文件傳輸請求後就創建「數據傳送進程」和「數據連接」，用來連接客戶端和伺服器端的數據傳送進程。
2 簡單文件傳送協議TFTP
TCP/IP 協議族中還有一個簡單文件傳送協議TFfP (Trivial File Transfer Protocol），它是一個很小且易於實現的文件傳送協議，埠號69。
TFfP 也使用客戶伺服器方式，但它使用UDP 數據報，因此TFfP 需要有自己的差錯改正措施。TFfP 只支持文件傳輸而不支持交耳。
3 TELNET
TELNET 是一個簡單的遠程終端協議，底層採用TCP協議。TELNET 也使用客戶伺服器方式。在本地系統運行TELNET 客戶進程，而在遠地主機則運行TELNET 伺服器進程，佔用埠23。
4 郵件傳輸協議
一個電子郵件系統應具如圖所示的三個主要組成構件，這就是用戶代理、郵件伺服器，以及郵件發送協議（如SMTP ）和郵件讀取協議（如POP3)， POP3 是郵局協議（Post Office Protocol）的版本3 。
SMTP 和POP3 （或IMAP ）都是在TCP 連接的上面傳送郵件，使用TCP 的目的是為了使郵件的傳送成為可靠的。
③ 計算機網路基礎知識（一）
參考：計算機網路 謝希仁 第7版
一、現在最主要的三種網路
電信網路(電話網)
有線電視網路
計算機網路 (發展最快，信息時代的核心技術)
二、internet 和 Internet
internet 是普通名詞
泛指一般的互連網(互聯網)
Internet 是專有名詞,標准翻譯是「網際網路」 世界范圍的互連網(互聯網)
使用 TCP/IP 協議族
前身是美國的阿帕網 ARPANET
三、計算機網路的帶寬
計算機網路的帶寬是指網路可通過的最高數據率，即每秒多少比特。 描述帶寬也常常把「比特/秒」省略。
例如，帶寬是 10 M，實際上是 10 Mb/s。注意:這里的 M 是 106。
四、對寬頻傳輸的錯誤概念
在網路中有兩種不同的速率:
信號(即電磁波)在傳輸媒體上的傳播速率(米/秒，或公里/秒)
計算機向網路發送比特的速率(比特/秒),也叫傳輸速率。 這兩種速率的意義和單位完全不同。
寬頻傳輸:計算機向網路發送比特的速率較高。 寬頻線路:每秒有更多比特從計算機注入到線路。 寬頻線路和窄帶線路上比特的傳播速率是一樣的。
早期的計算機網路採用電路交換，新型的計算機網路採用分組交換的、基於存儲轉發的方式。 分組交換:
在發送端把要發送的報文分隔為較短的數據塊
每個塊增加帶有控制信息的首部構成分組(包)
依次把各分組發送到接收端
接收端剝去首部，抽出數據部分，還原成報文
IP 網路的重要特點
每一個分組獨立選擇路由。
發往同一個目的地的分組，後發送的有可能先收到(即可能不按順序接收)。 當網路中的通信量過大時，路由器就來不及處理分組，於是要丟棄一些分組。 因此， IP 網路不保證分組的可靠地交付。
IP 網路提供的服務被稱為:
盡最大努力服務(best effort service) 五、最重要的兩個協議:IP 和 TCP
TCP 協議保證了應用程序之間的可靠通信,IP 協議控制分組在網際網路的傳輸,但網際網路不保證可靠交付.
在 TCP/IP 的應用層協議使用的是客戶伺服器方式。
客戶(client)和伺服器(server)都是指通信中所涉及的兩個應用進程。
客戶伺服器方式所描述的是進程之間服務和被服務的關系。
當 A 進程需要 B 進程的服務時就主動呼叫 B 進程，在這種情況下，A 是客戶而 B 是伺服器。
可能在下一次通信中，B 需要 A 的服務，此時，B 是客戶而 A 是伺服器。
注意:
使用計算機的人是「用戶」(user)而不是「客戶」(client)。
客戶和伺服器都指的是進程，即計算機軟體。
由於運行伺服器進程的機器往往有許多特殊的要求，因此人們經常將主要運行伺服器進程的
機器(硬體)不嚴格地稱為伺服器。
例如，「這台機器是伺服器。」 意思是:「這台機器(硬體)主要是用來運行伺服器進程(軟體)。」 因此，伺服器(server)一詞有時指的是軟體，但也有時指的是硬體。
六、總結
網際網路(Internet)是世界范圍的、互連起來的計算機網路，它使用 TCP/IP 協議族，並且它的前身是美 國阿帕網 ARPANET。
計算機網路的帶寬是網路可通過的最高數據率。
網際網路使用基於存儲轉發的分組交換，並使用 IP 協議傳送 IP 分組。
路由器把許多網路互連起來，構成了互連網。路由器收到分組後，根據路由表查找出下一跳路由器的
地址，然後轉發分組。
路由器根據與其他路由器交換的路由信息構造出自己的路由表。
IP 網路提供盡最大努力服務，不保證可靠交付。
TCP 協議保證計算機程序之間的、端到端的可靠交付。
在 TCP/IP 的應用層協議使用的是客戶伺服器方式。
客戶和伺服器都是進程(即軟體)。客戶是服務請求方，伺服器是服務提供方。
伺服器有時也指「運行伺服器軟體」的機器。
一、IP 網路是虛擬網路
IP 網路是虛擬的。在 IP 網路上傳送的是 IP 數據報(IP 分組)。
實際上在網路鏈路上傳送的是「幀」，使用的是幀的硬體地址(MAC 地址)。
地址解析協議 ARP 用來把 IP 地址(虛擬地址)轉換為硬體地址(物理地址)。
二、IP 地址的表示方法
IP 地址的表示方法有兩種:二進制和點分十進制。
IP 地址是 32 位二進制數字，為方便閱讀和從鍵盤上輸入，可把每 8 位二進制數字轉換成一個十進制數字，並 用小數點隔開，這就是點分十進制。
三、網際網路的域名
網際網路的域名分為: 頂級域名 二級域名 三級域名
四級域名
四、域名伺服器 DNS (Domain Name Server)
網際網路中設有很多的域名伺服器 DNS，用來把域名轉換為 IP 地址。
五、電子郵件
發送郵件使用的協議——簡單郵件傳送協議 SMTP (Simple Mail Transfer Protocol) 接收郵件使用的協議——郵局協議版本 3 POP3 (Post Office Protocol version 3) 注:郵件的傳送仍然要使用 IP 和 TCP 協議
六、統一資源定位符 URL (Uniform Resource Locator)
URL 用來標識萬維網上的各種文檔。
網際網路上的每一個文檔，在整個網際網路的范圍內具有惟一的標識符 URL。 URL 實際上就是文檔在網際網路中的地址。
七、超文本傳送協議 HTTP (HyperText Transfer Protocol) 萬維網客戶程序與伺服器程序之間的交互遵守超文本傳送協議 HTTP。
八、結束語
IP 地址是 32 位二進制數字。為便於閱讀和鍵入，也常使用點分十進制記法。 個人用戶上網可向本地 ISP 租用臨時的 IP 地址。
域名伺服器 DNS 把計算機域名轉換為計算機使用的 32 位二進制 IP 地址。 發送電子郵件使用 SMTP 協議，接收電子郵件使用 POP3 協議。
統一資源定位符 URL 惟一地確定了萬維網上文檔的地址。
超文本傳送協議 HTTP 用於萬維網瀏覽器程序和伺服器程序的信息交互。
超文本標記語言 HTML 使萬維網文檔有了統一的格式。
IP 電話不使用 TCP 協議。利用 IP 電話網關使得在普通電話之間可以打 IP 電話。
一、網際網路服務提供者 ISP (Internet Service Provider) 根據提供服務的覆蓋面積大小以及所擁有的 IP 地址數目的不同，ISP 也分成為不同的層次。
二、兩種通信方式
在網路邊緣的端系統中運行的程序之間的通信方式通常可劃分為兩大類:C/S 方式 和 P2P 方式
(Peer-to-Peer，對等方式)。
三、網際網路的核心部分
網路核心部分是網際網路中最復雜的部分。
網路中的核心部分要向網路邊緣中的大量主機提供連通性，使邊緣部分中的任何一個主機都能夠向其 他主機通信(即傳送或接收各種形式的數據)。
網際網路的核心部分是由許多網路和把它們互連起來的路由器組成，而主機處在網際網路的邊緣部分。
在網際網路核心部分的路由器之間一般都用高速鏈路相連接，而在網路邊緣的主機接入到核心部分則通 常以相對較低速率的鏈路相連接。
主機的用途是為用戶進行信息處理的，並且可以和其他主機通過網路交換信息。路由器的用途則是用 來轉發分組的，即進行分組交換的。
在網路核心部分起特殊作用的是路由器(router)。
路由器是實現分組交換(packet switching)的關鍵構件，其任務是轉發收到的分組，這是網路核心部分
最重要的功能。
四、電路交換
電路交換必定是面向連接的。 電路交換的三個階段:建立連接、通信、釋放連接。
五、網路的分類
不同作用范圍的網路
廣域網 WAN (Wide Area Network)
區域網 LAN (Local Area Network)
城域網 MAN (Metropolitan Area Network)
個人區域網 PAN (Personal Area Network)
從網路的使用者進行分類
公用網 (public network)
專用網 (private network)
用來把用戶接入到網際網路的網路
接入網 AN (Access Network)，它又稱為本地接入網或居民接入網。
注:由 ISP 提供的接入網只是起到讓用戶能夠與網際網路連接的「橋梁」作用。
六、計算機網路的性能指標
速率
帶寬
吞吐量
時延(delay 或 latency)
傳輸時延(發送時延) —— 從發送數據幀的第一個比特算起，到該幀的最後一個比特發送完 畢所需的時間。
傳播時延 —— 電磁波在信道中需要傳播一定的距離而花費的時間。 注:信號傳輸速率(即發送速率)和信號在信道上的傳播速率是完全不同的概念。
處理時延 —— 交換結點為存儲轉發而進行一些必要的處理所花費的時間。
排隊時延 —— 結點緩存隊列中分組排隊所經歷的時延。 總時延 = 發送時延+傳播時延+處理時延+處理時延
時延帶寬積
利用率 —— 分為信道利用率和網路利用率。
信道利用率——某信道有百分之幾的時間是被利用的(有數據通過)。 網路利用率——全網路的信道利用率的加權平均值。 注:信道利用率並非越高越好。
七、網路協議(network protocol) 簡稱為協議，是為進行網路中的數據交換而建立的規則、標准或約定。其組成要素有以下三點:
語法 語義 同步
數據與控制信息的結構或格式 。
需要發出何種控制信息，完成何種動作以及做出何種響應。 事件實現順序的詳細說明。
八、實體、協議、服務和服務訪問點
實體(entity)——表示任何可發送或接收信息的硬體或軟體進程。 協議——是控制兩個對等實體進行通信的規則的集合。
在協議的控制下，兩個對等實體間的通信使得本層能夠向上一層提供服務。 要實現本層協議，還需要使用下層所提供的服務。
本層的服務用戶只能看見服務而無法看見下面的協議。
下面的協議對上面的服務用戶是透明的。
協議是「水平的」，即協議是控制對等實體之間通信的規則。
服務是「垂直的」，即服務是由下層向上層通過層間介面提供的。 同一系統相鄰兩層的實體進行交互的地方，稱為服務訪問點 SAP (Service Access Point)。
九、TCP/IP 的體系結構
路由器在轉發分組時最高只用到網路層，而沒有使用運輸層和應用層。
④ 計算機網路(5)| 運輸層
從通信和處理信息的角度看，運輸層是向它上面的應用層提供通信服務的，它屬於面向通信部分的最高層，同時也是用戶功能中的最低層。當網路的邊緣部分中的兩台主機使用網路的核心部分的功能進行端到端的通信時，只有主機的協議棧才有運輸層，而網路核心部分中的路由器在轉發分組時都只用到下三層的功能。
運輸層的兩個主要協議 TCP/IP 都是互聯網的正式標准，即：
（1）用戶數據報協議UDP
（2）傳輸控制協議TCP
TCP則是面向連接的服務。在傳送數據之前必須先建立連接，數據傳送結束後要釋放連接。TCP不提供廣播或者多播服務。由於TCP要提供可靠的面向連接的運輸服務，因此需要增加很多的開銷。
TCP/IP的運輸層用一個16位埠號來標志一個埠。埠號只有本地意義。它是為了標志本計算機應用層中的各個進程在和運輸層交互時的層間介面。
運輸層的埠號分為以下兩類：
（1）伺服器端使用的埠號： 它主要分為系統埠號0～1023和登記埠號1024～49151。
（2）客戶端使用的埠號： 49152～65535，這類埠號僅在客戶端進程運行時才動態選擇。當伺服器收到客戶端進程的報文時，就知道客戶端進程的埠號。因而可以把數據發送給客戶進程。
用戶數據報協議相比於IP的數據報服務就是只增加了復用、分用和差錯檢測功能。UDP的主要特點是：
（1）UDP是無連接的， 發送數據之前不需要建立連接，因此減少開銷和發送數據之前的時延。
（2）UDP使用盡最大努力交付， 即不保證可靠交付，因此主機不需要維持復雜的連接狀態表。
（3）UDP是面向報文的。 發送方的UDP對應用交下來的報文，添加首部後就向下交付給IP層。不對報文做任何處理，因此當報文過長時，IP層可能需要進行分片處理。
（4）UDP沒有擁塞控制， 網路出現的擁塞不會使源主機的發送速率減低。
（5）UDP支持一對一、一對多、多對一和多對多的交互通信。
（6）UDP的首部開銷小， 只有8個位元組。
UDP有兩個欄位：數據欄位和首部欄位。先介紹首部欄位，它是由4個欄位組成的，每個欄位只有2個位元組，總共有8個位元組。各個欄位的意義如下：
（1）源埠： 源埠號。在需要對方回信時選用。不需要時可用全0。
（2）目的埠： 目的埠號。在這終點交付報文時必須使用。
（3）長度： UDP用戶數據報的長度，其最小值是8（只有首部）。
（4）檢驗和： 檢測UDP用戶數據報在傳輸中是否有錯，有錯則丟棄。
當在傳送用戶數據報時，如果接收方UDP發現收到的報文中目的埠號不正確（即不存在對應於該埠號的應用進程），就丟棄該報文，並由網際控制報文協議ICMP發送「埠不可達」差錯報文給發送方。
TCP的主要特點如下：
（1）TCP是面向連接的運輸層協議。 應用程序在使用TCP協議之前，必須先建立TCP連接。傳送數據完畢後，必須釋放TCP連接。
（2）每一條TCP連接只能有兩個端點。 每一條TCP連接只能是點對點的。
（3）TCP提供可靠交付的服務。 通過TCP連接傳送的數據，無差錯、不丟失、不重復，並且按序到達。
（4）TCP提供全雙工通信。 TCP允許通信雙方的應用進程在任何時候都能發送數據。
（5）面向位元組流。 TCP中的流指的是流入到進程或進程流出的位元組序列。雖然應用程序和TCP的交互是一次一個數據塊，但TCP把應用程序交下來的數據看成一連串的無結構的位元組流。TCP不保證發送方發送的數據塊和接收方接收的數據塊一致，但保證程序接收到的位元組流和程序發送的位元組流一致。
TCP連接的端點叫做套接字或者插口。套接字是指將埠號拼接到IP地址之後，即：
每一條TCP連接唯一的被通信兩端的兩個端點所確定。即：
如圖所示，A發送分組M1，發送完畢就暫停發送，等待B的確認,B收到了M1就向A發死你確認。A在收到了對M1的確認之後，就再發送下一個分組M2，以此類推。
如圖所示，當B接收M1時檢測出了差錯，就丟棄M1，其他什麼也不做。而A只要超過了一段時間沒有收到確認，就會認為剛才發送的分組丟失了，因而重傳前面發送過的分組，這就叫做超時重傳，而實現超時重傳則需要A為每一個已發送的分組都設置一個超時計時器。
需要注意以下三點：
（1）A在發送完一個分組後，必須暫時保留已發送的分組的副本。
（2）分組和確認分組必須編號，這樣才能明確哪一個發出的分組收到了確認。
（3）超時計時器設置的重傳時間應當比數據在分組傳輸的平均往返時間更長。
如圖所示，B所發送的對M1確認丟失了，A在設定的超時重傳時間內沒有收到確認，所以無法知道自己發送的分組是怎樣出錯的，所以會重傳M1，而當B又收到了重傳的分組M1，這時應該採取兩個行動：
（1）丟棄這個重復分組M1。
（2）向A發送確認。
還有一種情況就是在傳輸過程中沒有出現差錯，但B對分組M1的確認遲到了，而A會收到重復的確認，A收下後就會丟棄，B仍然會收到重復的M1，並且同樣要丟棄重復的M1，並且重傳確認分組。
停止等待協議的優點是簡單，缺點則是信道的利用率太低。我們用TD表示A發送分組需要的時間，TA表示B發送確認分組需要的時間，RTT為往返時間，則：
為了提高傳輸的效率，發送方可以不使用低效率的停止等待協議，而是採用流水線傳輸的方式。即不必每發完一個分組就停下來等待對方的確認，這樣就可以使信道上一直有數據在不間斷的傳送。
如圖表示的是發送方維持的發送窗口，它指的是位於發送窗口內的5個分組都可以連續發送出去而不需要等待對方的確認。同時連續ARP協議規定，發送方每收到一個確認，就把發送窗口向前滑動一個分組的位置。
對於接收方採用的則是累計確認的方式，即接收方不必對收到的分組逐個發送確認。而是在收到幾個分組後，對按序到達的最後一個分組發送確認，這就表示：到這個分組為止的所有分組都已正確收到了。這種方式的優點是：容易實現，即使確認丟失也不必重傳（意思是發送方不必重傳）。但缺點是不能向發送方反映出接收方已經正確收到的所有分組信息。
TCP雖然是面向位元組流的，但傳送TCP的數據單元卻是報文段。一個TCP報文段可以分為首部和數據兩部分。
為了後面講述的方便，我們假設數據傳輸只在一個方向進行，即A發送數據，B給出確認。
TCP的滑動窗口是以位元組為單位的。如圖所示，現在假定A收到了B發來的確認報文段，其中的窗口是20位元組，而確認號是31，根據這2個數據，A就構造出自己的發送窗口。
發送窗口表示：在沒有收到B的確認的情況下，A可以連續把窗口內的數據都發送出去。凡是已經發送過的數據，在未收到確認之前都必須暫時保留，以便在超時重傳時使用。發送窗口後面的部分表示已發送且已經收到了確認。而發送窗口前沿的部分表示不允許發送的。
現在假定A發送了序號為31~41的數據。這時發送窗口位置並未改變但是發送窗口內靠後面有11個位元組表示已發送但是未收到確認。而發送窗口內靠前面的9個位元組時允許發送但未發送的。如圖所示：
而對於B，它的接收窗口大小是20，在接收窗口外面到30號位置的數據是接收並確認的，因此可以丟棄。在下圖中，B收到了32和33的數據，但它們不是按序到達的，因為並沒有收到31號數據。B只能對按序達收到的數據中的最高序號給出確認，因此B發送的確認報文欄位的確認號依然是31號。
現在假定B收到了序號為31的數據，並把31～33的數據交付主機，然後B刪除這些數據。接著把窗口向前移動3個序號，同時給a發送確認，其中的窗口值仍為20，但確認號變為34。表明B已經收到序號33為止的數據。
因為TCP的發送方在規定的時間內沒有收到確認就要重傳已經發送的報文段，但是重傳時間的選擇卻TCP最復雜的問題之一。為此TCP採用了一種自適應演算法，它記錄了一個報文段發出的時間以及收到相應的確認的時間。這兩個時間之差就是報文段的往返時間RTT，同時TCP保留了RTT的加權平均往返時間RTTs。而RTTD是RTT的偏差加權平均值，它與RTTs和新的RTT樣本之差有關。
超時重傳時間的演算法如下：
第一次測量時，加權平均往返時間取往返時間RTT，以後每次測量到一個新的RTT，按以下公式計算：
第一次測量時，RTT偏差的加權平均等於RTT的一半，以後的測里中，按以下公式計算：
綜上超時重傳時間RTO計算如下：
若收到的報文無差錯，只是未按序號，使用選擇確認SACK可是讓發送方發送那些未收到的數據，而不重復發送已經收到的那些數據。如果要使用選擇確認SACK，那麼在建立TCP連接時，就要在TCP首部的選項中加上「允許SACK」的選項，並且雙方必須都事先商量好。
流量控制就是指讓發送方的發送速率不要太快，要讓接收方來得及接收。而利用滑動窗口機制就可以很方便的在TCP連接上實現對發送方的流量控制。
如上圖所示，接收方B進行了三次流量控制。第一次把窗口減小到rwnd=300，第二次又減到rwnd=100，最後是rwnd=0，即不允許發送方再發送數據了。
但是我們應該考慮一種情況，就是當接收方B的存儲已滿時，會向發送方發送零窗口的報文段，接著B的存儲又有了一些空間，B再向A發送一個不為零的窗口值，但這個報文丟失了，結果就是雙方一直等待下去。所以為了解決這個問題，TCP為每一個連接設有一個持續計時器。只要TCP連接的一方收到對方的零窗口通知，就啟動持續計時器，當計時器到期後，就發送一個探測段文段，而對方就在確認這個探測段時給出了現在的窗口值。如果窗口仍然是0，那麼收到這個報文段的一方就重新設置持續計時器，反之則死鎖的僵局就可以打破了。
應用程序把數據傳送到TCP的發送緩存後，TCP在何時發送這些數據？，在TCP的實現中廣泛使用了Nagle演算法。具體演算法如下：
（1）若發送應用進程要把數據逐個位元組地送到TCP的發送緩存，則發送方就把第一個數據位元組先發出去，把後面到達的數據位元組都緩存起來。
（2）方發送方收到對第一個數據位元組的確認後，再把發送緩存中的所有數據組裝成一個報文發送出去，同時繼續對後續到來的數據進行緩存。
（3）只有收到對前一個報文段的確認後才繼續發送下一個報文段。
當數據到達快而網路速度慢時，這種方法可以明顯減少網路帶寬。Nagle還規定：當到達的數據達到窗口的一半或最大報文長度時就立即發送一個報文。
但還還需要考慮一個叫做糊塗綜合征的問題，具體內容是若接收方的緩存已滿，應用進程每次只從緩存中取1個位元組，然後向發送方確認，並把窗口設為1個位元組（緩存只空了1個位元組的空間），接著發送方發來1個位元組，接收方發回確認，仍然將窗口設為1，這樣進行下去，網路的利用率很低。
為了解決這個問題，可以讓接收方等待一段時間，使得或者緩存已有足夠的空間或者等到接收緩存已有一半的空閑空間。此時，接收方就發出確認報文，並向發送方通知當前窗口的大小。
擁塞 是指在某一段時間內，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的性能就會變壞的情況。而所謂的 擁塞控制 就是防止過多的數據注入到網路當中，這樣可以使網路中的路由器或者鏈路不致過載，它是一個全局性的過程，涉及到所有的主機和路由器，而流量控制往往是指點對點通信量的控制。擁塞控制所要做的都有一個前提，就是網路能夠承受現有的網路負荷。
TCP進行擁塞控制的演算法有4種：慢開始、擁塞避免、快重傳和快恢復。下面在討論這些演算法時我們假定：
（1）數據是單方向傳送的，對方只傳送確認報文。
（2）接收方總是有足夠大的緩存空間。
發送方維持一個擁塞窗口的狀態變數，其大小取決於擁塞程度，並且動態變化。發送方讓自己的發送窗口小於擁塞窗口（如果考慮接收方的接收能力的話，發送窗口可能小於擁塞窗口）。發送方控制擁塞窗口的原則是：只要網路沒有擁塞，擁塞窗口就再增大一點，以便把更多的分組發送出去，只要出現擁塞，就減小擁塞窗口，以減少注入到網路的分組數。
下面會從「慢開始演算法」講起來討論擁塞窗口的大小如何變化的。
慢開始的演算法思路是：當主機開始發送數據時，由於並不清楚網路的負荷情況，所以如果立即把大量數據位元組注入到網路中，就有可能引起網路擁塞。因此會採用由小逐漸增大發送窗口。即在通常開始發送報文時，先將擁塞窗口cwnd的值設為一個最大報文段MSS的數值，而在每收到一個新的報文段確認後，把擁塞窗口增加至多一個MSS的數值。
如上圖所示，開始時cwnd=1，發送方發送一個M1，接收方收到M1發送確認，發送方收到一個確認後將cwnd加1，此時cwnd=2，因此發送方發送M2和M3兩個報文段，接收方收到後返回兩個確認，因此cwnd增加兩次，此時cwnd=4，接著發送方發送M4～M7四個報文段。依次類推。因此使用慢開始演算法後，每經過一個傳輸輪次，擁塞窗口就加倍。
但是為了防止擁塞窗口cwnd增加過大導致網路擁塞，需要設置一個慢開始門限ssthresh，慢開始門限用法如下：
當cwnd<ssthresh時，使用上述的慢開始演算法。
當cwnd>ssthresh時，停止使用慢開始演算法，使用擁塞避免演算法。
當cwnd=ssthresh時，既可以使用慢開始演算法，也可以使用擁塞避免演算法。
這里的擁塞避免演算法是指讓擁塞窗口緩慢的增大，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是像慢開始階段那樣加倍增長。
需要注意的是無論在慢開始階段還是擁塞避免階段，只要發送方判斷網路出現擁塞（根據是沒有按時收到確認），立即把慢開始門限ssthresh設為出現擁塞時的發送窗口的一半。然後發送窗口cwnd重新設為1，執行慢開始演算法。目的是迅速減少主機發送到網路分組的分組數。
快重傳演算法要求接收方每收到一個失序的報文段後就立即發送重復確認，如下圖接收了M1和M2後，又接收到一個M4，M4屬於失序報文，則發送對M2的重復確認。發送方只要連續收到三次確認重復就立即重傳對方未收到的報文段M3。
與快重傳演算法配合的還有快恢復演算法，過程如下：
（1）當發送方連續收到三個重復確認時，就把慢開始門限ssthresh減半，這是為了防止網路擁塞，接著並不執行慢開始演算法。
（2）由於上圖這種情況很可能不是因為網路擁塞引起的，因此這里不執行慢開始演算法（即不把擁塞窗口cwnd設為1，這樣速度太慢），而是把cwnd值設置為慢開始門限ssthresh減半後的數值，然後開始執行擁塞避免演算法。
TCP的運輸連接有是三個階段：連接建立、數據傳送和連接釋放。在TCP的連接過程中要解決以下三個問題：
（1）要使每一方能夠確知對方的存在。
（2）要允許雙方協商一些參數（如最大窗口值、是否使用窗口擴大選項和時間戳選項以及服務質量）。
（3）能夠對運輸實體資源進行分配。
TCP建立連接的過程叫做握手，握手需要在客戶和伺服器之間交換3個TCP報文段。如圖是三報文握手建立的連接過程：
A最後還要發送一次確認的原因是為了防止已經失效的連接請求報文段突然又傳送到了B，因而產生錯誤。試想一種情況：如果只有第一次和第二次握手，第二次B向A發送的確認丟失了，此時B進入了連接建立狀態，A沒有收到確認，過一段時間後會再次向B發送連接請求，B收到後又會再次建立連接，白白浪費B的資源。
A在TIME-WAIT狀態等待2MSL（MSL，最長報文段壽命），主要是因為以下兩點考慮：首先是為了保證A發送的最後一個ACK報文段能夠到達B，因為這個ACK報文段可能丟失，此時B會重傳連接釋放報文，如果A已經關閉，則無法收到這個報文。其次，當A在發送完最後一個ACK報文段後，再經過時間2MSL，就可以使本連接持續時間內產生的所有報文段都從網路中消失。這樣，下一個新連接中不會出現這種舊的連接請求報文段。
在圖中每一個方框即TCP可能具有的狀態。每個方框中的大寫英文字元串時TCP標准所使用的的TCP連接狀態名。狀態之間的箭頭表示可能發生的狀態變遷。箭頭旁邊的字表明引起這種變遷的原因，或表明發生狀態變遷後又出現什麼動作，在圖中粗實線箭頭表示對客戶進程的正常變遷，粗虛線箭頭表示對伺服器進程的正常變遷，細線箭頭表示異常變遷。
⑤ 計算機網路中，可靠交付有什麼來負責端系統路由器NAT設備端系統是什麼
A）端系統。
端系統就是終端系統，藉助於internet的盡力而為、無連接性的高效，由復雜的終端系統來保證可靠交付！
⑥ 計算機網路第四章（網路層）
4.1、網路層概述
簡介
網路層的主要任務是 實現網路互連 ，進而 實現數據包在各網路之間的傳輸
這些異構型網路N1~N7如果只是需要各自內部通信，他們只要實現各自的物理層和數據鏈路層即可
但是如果要將這些異構型網路互連起來，形成一個更大的互聯網，就需要實現網路層設備路由器
有時為了簡單起見，可以不用畫出這些網路，圖中N1~N7，而將他們看做是一條鏈路即可
要實現網路層任務，需要解決一下主要問題：
網路層向運輸層提供怎樣的服務（「可靠傳輸」還是「不可靠傳輸」）
在數據鏈路層那課講過的可靠傳輸，詳情可以看那邊的筆記：網路層對以下的 分組丟失 、 分組失序 、 分組重復 的傳輸錯誤採取措施，使得接收方能正確接受發送方發送的數據，就是 可靠傳輸 ，反之，如果什麼措施也不採取，則是 不可靠傳輸
網路層定址問題
路由選擇問題
路由器收到數據後，是依據什麼來決定將數據包從自己的哪個介面轉發出去？
依據數據包的目的地址和路由器中的路由表
但在實際當中，路由器是怎樣知道這些路由記錄？
由用戶或網路管理員進行人工配置，這種方法只適用於規模較小且網路拓撲不改變的小型互聯網
另一種是實現各種路由選擇協議，由路由器執行路由選擇協議中所規定的路由選擇演算法，而自動得出路由表中的路有記錄，這種方法更適合規模較大且網路拓撲經常改變的大型互聯網
補充 網路層（網際層） 除了 IP協議 外，還有之前介紹過的 地址解析協議ARP ，還有 網際控制報文協議ICMP ， 網際組管理協議IGMP
總結
4.2、網路層提供的兩種服務
在計算機網路領域，網路層應該向運輸層提供怎樣的服務（「 面向連接 」還是「 無連接 」）曾引起了長期的爭論。
爭論焦點的實質就是： 在計算機通信中，可靠交付應當由誰來負責 ？是 網路 還是 端系統 ？
面向連接的虛電路服務
一種觀點：讓網路負責可靠交付
這種觀點認為，應藉助於電信網的成功經驗，讓網路負責可靠交付，計算機網路應模仿電信網路，使用 面向連接 的通信方式。
通信之前先建立 虛電路 (Virtual Circuit)，以保證雙方通信所需的一切網路資源。
如果再使用可靠傳輸的網路協議，就可使所發送的分組無差錯按序到達終點，不丟失、不重復。
發送方 發送給 接收方 的所有分組都沿著同一條虛電路傳送
虛電路表示這只是一條邏輯上的連接，分組都沿著這條邏輯連接按照存儲轉發方式傳送，而並不是真正建立了一條物理連接。
請注意，電路交換的電話通信是先建立了一條真正的連接。
因此分組交換的虛連接和電路交換的連接只是類似，但並不完全一樣
無連接的數據報服務
另一種觀點：網路提供數據報服務
互聯網的先驅者提出了一種嶄新的網路設計思路。
網路層向上只提供簡單靈活的、 無連接的 、 盡最大努力交付 的 數據報服務 。
網路在發送分組時不需要先建立連接。每一個分組（即 IP 數據報）獨立發送，與其前後的分組無關（不進行編號）。
網路層不提供服務質量的承諾 。即所傳送的分組可能出錯、丟失、重復和失序（不按序到達終點），當然也不保證分組傳送的時限。
發送方 發送給 接收方 的分組可能沿著不同路徑傳送
盡最大努力交付
如果主機（即端系統）中的進程之間的通信需要是可靠的，那麼就由網路的 主機中的運輸層負責可靠交付（包括差錯處理、流量控制等） 。
採用這種設計思路的好處是 ：網路的造價大大降低，運行方式靈活，能夠適應多種應用。
互連網能夠發展到今日的規模，充分證明了當初採用這種設計思路的正確性。
虛電路服務與數據報服務的對比
對比的方面 虛電路服務 數據報服務
思路 可靠通信應當由網路來保證 可靠通信應當由用戶主機來保證
連接的建立 必須有 不需要
終點地址 僅在連接建立階段使用，每個分組使用短的虛電路號 每個分組都有終點的完整地址
分組的轉發 屬於同一條虛電路的分組均按照同一路由進行轉發 每個分組獨立選擇路由進行轉發
當結點出故障時 所有通過出故障的結點的虛電路均不能工作 出故障的結點可能會丟失分組，一些路由可能會發生變化
分組的順序 總是按發送順序到達終點 到達終點時不一定按發送順序
端到端的差錯處理和流量控制 可以由網路負責，也可以由用戶主機負責 由用戶主機負責
4.3、IPv4
概述
分類編制的IPv4地址
簡介
每一類地址都由兩個固定長度的欄位組成，其中一個欄位是 網路號 net-id ，它標志主機（或路由器）所連接到的網路，而另一個欄位則是 主機號 host-id ，它標志該主機（或路由器）。
主機號在它前面的網路號所指明的網路范圍內必須是唯一的。
由此可見， 一個 IP 地址在整個互聯網范圍內是唯一的 。
A類地址
B類地址
C類地址
練習
總結
IP 地址的指派范圍
一般不使用的特殊的 IP 地址
IP 地址的一些重要特點
(1) IP 地址是一種分等級的地址結構 。分兩個等級的好處是：
第一 ，IP 地址管理機構在分配 IP 地址時只分配網路號，而剩下的主機號則由得到該網路號的單位自行分配。這樣就方便了 IP 地址的管理。
第二 ，路由器僅根據目的主機所連接的網路號來轉發分組（而不考慮目的主機號），這樣就可以使路由表中的項目數大幅度減少，從而減小了路由表所佔的存儲空間。
(2) 實際上 IP 地址是標志一個主機（或路由器）和一條鏈路的介面 。
當一個主機同時連接到兩個網路上時，該主機就必須同時具有兩個相應的 IP 地址，其網路號 net-id 必須是不同的。這種主機稱為 多歸屬主機 (multihomed host)。
由於一個路由器至少應當連接到兩個網路（這樣它才能將 IP 數據報從一個網路轉發到另一個網路），因此 一個路由器至少應當有兩個不同的 IP 地址 。
(3) 用轉發器或網橋連接起來的若干個區域網仍為一個網路 ，因此這些區域網都具有同樣的網路號 net-id。
(4) 所有分配到網路號 net-id 的網路，無論是范圍很小的區域網，還是可能覆蓋很大地理范圍的廣域網，都是平等的。
劃分子網的IPv4地址
為什麼要劃分子網
在 ARPANET 的早期，IP 地址的設計確實不夠合理：
IP 地址空間的利用率有時很低。
給每一個物理網路分配一個網路號會使路由表變得太大因而使網路性能變壞。
兩級的 IP 地址不夠靈活。
如果想要將原來的網路劃分成三個獨立的網路
所以是否可以從主機號部分借用一部分作為子網號
但是如果未在圖中標記子網號部分，那麼我們和計算機又如何知道分類地址中主機號有多少比特被用作子網號了呢？
所以就有了劃分子網的工具： 子網掩碼
從 1985 年起在 IP 地址中又增加了一個「 子網號欄位 」，使兩級的 IP 地址變成為 三級的 IP 地址 。
這種做法叫做 劃分子網 (subnetting) 。
劃分子網已成為互聯網的正式標准協議。
如何劃分子網
基本思路
劃分子網純屬一個 單位內部的事情 。單位對外仍然表現為沒有劃分子網的網路。
從主機號 借用 若干個位作為 子網號 subnet-id，而主機號 host-id 也就相應減少了若干個位。
凡是從其他網路發送給本單位某個主機的 IP 數據報，仍然是根據 IP 數據報的 目的網路號 net-id，先找到連接在本單位網路上的路由器。
然後 此路由器 在收到 IP 數據報後，再按 目的網路號 net-id 和 子網號 subnet-id 找到目的子網。
最後就將 IP 數據報直接交付目的主機。
劃分為三個子網後對外仍是一個網路
優點
1. 減少了 IP 地址的浪費 2. 使網路的組織更加靈活 3. 更便於維護和管理
劃分子網純屬一個單位內部的事情，對外部網路透明 ，對外仍然表現為沒有劃分子網的一個網路。
子網掩碼
(IP 地址) AND (子網掩碼) = 網路地址 重要，下面很多相關知識都會用到
舉例
例子1
例子2
默認子網掩碼
總結
子網掩碼是一個網路或一個子網的重要屬性。
路由器在和相鄰路由器交換路由信息時，必須把自己所在網路（或子網）的子網掩碼告訴相鄰路由器。
路由器的路由表中的每一個項目，除了要給出目的網路地址外，還必須同時給出該網路的子網掩碼。
若一個路由器連接在兩個子網上，就擁有兩個網路地址和兩個子網掩碼。
無分類編址的IPv4地址
為什麼使用無分類編址
無分類域間路由選擇 CIDR (Classless Inter-Domain Routing)。
CIDR 最主要的特點
CIDR使用各種長度的「 網路前綴 」(network-prefix)來代替分類地址中的網路號和子網號。
IP 地址從三級編址（使用子網掩碼）又回到了兩級編址 。
如何使用無分類編址
舉例
路由聚合（構造超網）
總結
IPv4地址的應用規劃
給定一個IPv4地址快，如何將其劃分成幾個更小的地址塊，並將這些地址塊分配給互聯網中不同網路，進而可以給各網路中的主機和路由器介面分配IPv4地址
定長的子網掩碼FLSM（Fixed Length Subnet Mask）
劃分子網的IPv4就是定長的子網掩碼
舉例
通過上面步驟分析，就可以從子網1 ~ 8中任選5個分配給左圖中的N1 ~ N5
採用定長的子網掩碼劃分，只能劃分出2^n個子網，其中n是從主機號部分借用的用來作為子網號的比特數量，每個子網所分配的IP地址數量相同
但是也因為每個子網所分配的IP地址數量相同，不夠靈活，容易造成IP地址的浪費
變長的子網掩碼VLSM（Variable Length Subnet Mask）
無分類編址的IPv4就是變長的子網掩碼
舉例
4.4、IP數據報的發送和轉發過程
舉例
源主機如何知道目的主機是否與自己在同一個網路中，是直接交付，還是間接交付？
可以通過 目的地址IP 和 源地址的子網掩碼 進行 邏輯與運算 得到 目的網路地址
如果 目的網路地址 和 源網路地址 相同 ，就是 在同一個網路 中，屬於 直接交付
如果 目的網路地址 和 源網路地址 不相同 ，就 不在同一個網路 中，屬於 間接交付 ，傳輸給主機所在網路的 默認網關 （路由器——下圖會講解）,由默認網關幫忙轉發
主機C如何知道路由器R的存在？
用戶為了讓本網路中的主機能和其他網路中的主機進行通信，就必須給其指定本網路的一個路由器的介面，由該路由器幫忙進行轉發，所指定的路由器，也被稱為 默認網關
例如。路由器的介面0的IP地址192.168.0.128做為左邊網路的默認網關
主機A會將該IP數據報傳輸給自己的默認網關，也就是圖中所示的路由器介面0
路由器收到IP數據報後如何轉發？
檢查IP數據報首部是否出錯：
若出錯，則直接丟棄該IP數據報並通告源主機
若沒有出錯，則進行轉發
根據IP數據報的目的地址在路由表中查找匹配的條目：
若找到匹配的條目，則轉發給條目中指示的嚇一跳
若找不到，則丟棄該數據報並通告源主機
假設IP數據報首部沒有出錯，路由器取出IP數據報首部各地址欄位的值
接下來路由器對該IP數據報進行查表轉發
逐條檢查路由條目，將目的地址與路由條目中的地址掩碼進行邏輯與運算得到目的網路地址，然後與路由條目中的目的網路進行比較，如果相同，則這條路由條目就是匹配的路由條目，按照它的下一條指示，圖中所示的也就是介面1轉發該IP數據報
路由器是隔離廣播域的
4.5、靜態路由配置及其可能產生的路由環路問題
概念
多種情況舉例
靜態路由配置
舉例
默認路由
舉例
默認路由可以被所有網路匹配，但路由匹配有優先順序，默認路由是優先順序最低的
特定主機路由
舉例
有時候，我們可以給路由器添加針對某個主機的特定主機路由條目
一般用於網路管理人員對網路的管理和測試
多條路由可選，匹配路由最具體的
靜態路由配置錯誤導致路由環路
舉例
假設將R2的路由表中第三條目錄配置錯了下一跳
這導致R2和R3之間產生了路由環路
聚合了不存在的網路而導致路由環路
舉例
正常情況
錯誤情況
解決方法
黑洞路由的下一跳為null0，這是路由器內部的虛擬介面，IP數據報進入它後就被丟棄
網路故障而導致路由環路
舉例
解決方法
添加故障的網路為黑洞路由
假設。一段時間後故障網路恢復了
R1又自動地得出了其介面0的直連網路的路由條目
針對該網路的黑洞網路會自動失效
如果又故障
則生效該網路的黑洞網路
總結
4.6、路由選擇協議
概述
網際網路所採用的路由選擇協議的主要特點
網際網路採用分層次的路由選擇協議
自治系統 AS ：在單一的技術管理下的一組路由器，而這些路由器使用一種 AS 內部的路由選擇協議和共同的度量以確定分組在該 AS 內的路由，同時還使用一種 AS 之間的路由選擇協議用以確定分組在 AS之間的路由。
自治系統之間的路由選擇簡稱為域間路由選擇，自治系統內部的路由選擇簡稱為域內路由選擇
域間路由選擇使用外部網關協議EGP這個類別的路由選擇協議
域內路由選擇使用內部網關協議IGP這個類別的路由選擇協議
網關協議 的名稱可稱為 路由協議
常見的路由選擇協議
⑦ 計算機網路第4章（網路層）
計算機網路微課堂 的筆記整理
筆記也放到了 我的github 和 我的gitee 上
一種觀點：讓網路負責可靠交付
發送方 發送給 接收方 的所有分組都沿著同一條虛電路傳送
另一種觀點：網路提供數據報服務
發送方 發送給 接收方 的分組可能沿著不同路徑傳送
A類地址
B類地址
C類地址
練習
IP 地址的指派范圍
一般不使用的特殊的 IP 地址
IP 地址的一些重要特點
(1) IP 地址是一種分等級的地址結構 。分兩個等級的好處是：
(2) 實際上 IP 地址是標志一個主機（或路由器）和一條鏈路的介面 。
(3) 用轉發器或網橋連接起來的若干個區域網仍為一個網路 ，因此這些區域網都具有同樣的網路號 net-id。
(4) 所有分配到網路號 net-id 的網路，無論是范圍很小的區域網，還是可能覆蓋很大地理范圍的廣域網，都是平等的。
在 ARPANET 的早期，IP 地址的設計確實不夠合理：
如果想要將原來的網路劃分成三個獨立的網路
所以是否可以從主機號部分借用一部分作為子網號
基本思路
劃分為三個子網後對外仍是一個網路
舉例
例子1
例子2
默認子網掩碼
無分類域間路由選擇 CIDR (Classless Inter-Domain Routing)。
舉例
給定一個IPv4地址快，如何將其劃分成幾個更小的地址塊，並將這些地址塊分配給互聯網中不同網路，進而可以給各網路中的主機和路由器介面分配IPv4地址
劃分子網的IPv4就是定長的子網掩碼
舉例
無分類編址的IPv4就是變長的子網掩碼
舉例
舉例
源主機如何知道目的主機是否與自己在同一個網路中，是直接交付，還是間接交付？
主機C如何知道路由器R的存在？
路由器收到IP數據報後如何轉發？
假設IP數據報首部沒有出錯，路由器取出IP數據報首部各地址欄位的值
接下來路由器對該IP數據報進行查表轉發
路由器是隔離廣播域的
靜態路由配置
舉例
默認路由
舉例
默認路由可以被所有網路匹配，但路由匹配有優先順序，默認路由是優先順序最低的
特定主機路由
舉例
有時候，我們可以給路由器添加針對某個主機的特定主機路由條目
一般用於網路管理人員對網路的管理和測試
靜態路由配置錯誤導致路由環路
舉例
假設將R2的路由表中第三條目錄配置錯了下一跳
這導致R2和R3之間產生了路由環路
聚合了不存在的網路而導致路由環路
舉例
正常情況
錯誤情況
解決方法
網路故障而導致路由環路
舉例
解決方法
添加故障的網路為黑洞路由
⑧ [計算機網路之六] 傳輸層
傳輸層向它上面的應用層提供通信服務，它屬於面向通信部分的最高層，同時也是用戶功能中的最底層。
從傳輸層的角度，通信的真正端點並不是主機而是主機中的進程。
傳輸層有 分用 和 復用 的功能。 「復用」 是指在發送方不同的應用進程都可以使用同一個運輸層協議傳送數據， 「分用」 是指接收方的運輸層在剝去報文的首部後能夠把這些數據正確交付目的應用進程。
網路層和運輸層有明顯的區別，網路層為主機之間提供邏輯通信，而運輸層為應用進程之間提供端到端的邏輯通信。
知名埠號 ：0~1023
登記埠號 ：1024~49151
客戶端短暫埠號 ：49152~65535
① 無連接。 發送數據之前不需要建立連接，因此減少了開銷和發送數據之前的時延。
② 盡最大努力交付。 即不保證可靠交付，因此主機不需要維持復雜的連接狀態表。
③ 面向報文的。 對應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界，UDP 一次交付一個完整的報文。
用戶數據報 UDP 有兩個欄位：數據欄位和首部欄位。首部欄位很簡單，只有 8 個位元組，由四個欄位組成，每個欄位的長度都是兩個位元組。各欄位意義如下：
① 源埠 在需要對方回信時選用。不需要時可用全0。
② 目的埠 目的埠號。這在終點交付報文時必須使用。
③ 長度 用戶數據報的長度，最小值為 8 （僅有首部）。
④ 檢驗和 檢測用戶數據報在傳輸中是否有錯。有錯就丟棄。
用戶數據報首部檢驗和的計算和校驗都要計算出一個偽首部。
① 面向連接。
應用程序在使用 TCP 協議之前，必須先建立 TCP 連接；傳送數據完畢後，必須釋放已經建立的 TCP 連接。類似於打電話：通話前要先撥號建立連接，通話結束後要掛機釋放連接。
② 一對一。
TCP 連接只能是點對點的（一對一）。
③ 可靠交付。
通過 TCP 連接傳送的數據，無差錯、不丟失、不重復，並且按序到達。
④ 全雙工通信。
通信雙方的應用進程在任何時候都能發送和接收數據，TCP 連接的兩端都設有發送緩存和接收緩存，用來臨時存放雙向通信的數據。
⑤ 面向位元組流。
TCP 中的 「流」 指的是流入到進程或從進程流出的位元組序列。
「面向位元組流」 的含義：雖然應用程序和 TCP 的互動式一次一個數據塊（大小不等），但 TCP 把應用程序交下來的數據僅僅看成是一連串無結構的位元組流。TCP 並不知道所傳送的位元組流的含義。TCP 不保證接收方應用程序鎖收到的數據塊和發送方應用程序所發出的數據塊具有對應的大小關系。但接收方應用程序收到的位元組流必須和發送方應用程序發出的位元組流完全一樣，當然接收方的應用程序必須有能力識別收到的位元組流，把它還原成有意義的應用層數據。
TCP 連接是協議軟體提供的一種抽象，每一條 TCP 連接唯一地被通信兩端的兩個端點（即兩個套接字）所確定，即：
TCP 連接 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}
IP1 和 IP2 分別是兩個端點主機的 IP 地址，port1 和 port2 分別是兩端端點主機中的埠號。
網路只能提供最大努力的服務，是不可靠的，因此 TCP 必須採用適當的措施才能使得兩個運輸層之間的通信變得可靠。當出現差錯時讓發送方重傳出現差錯的數據，同時在接收方來不及處理收到的數據時，及時告知發送方適當降低發送數據的速度，這樣就可以在不可靠的傳輸信道實現可靠傳輸。
ARQ（Auto Repeat-reQuest）：自動重傳請求。
發送方每發送完一個分組就停止發送，等待接收方確認，在收到確認後再發送下一個分組。
A 是發送方，B 是接收方。
A 每發送一個分組後，等待 B 對該分組的確認後，再接著發送下一個分組。
【發送方】A 發送的分組在傳輸過程中出錯，可能是丟失了，也可能是分組受到干擾出錯了
【接收方】這時 B 直接丟棄分組，什麼也不做（也不通知 A 受到的分組有差錯）。
【解決方案】發送方在每發送完一個分組時設置一個 超時計數器 ，只要超過一段時間仍然沒有接收到確認，就認為剛才發送的分組丟失了，因而重傳前面發送過的分組，這叫 超時重傳 。反之在超時計時器到期之前收到了相應的確認，就撤銷該超時計時器。
第一，A 在發送完一個分組後， 必須暫時保留已發送的分組的副本 （在發生超時重傳時使用）。只有在收到相應的確認後才能清楚暫時保留的分組副本。
第二，分組和確認分組都必須進行 編號 。這樣才能明確是哪一個發送出去的分組受到了確認，而哪一個分組還沒有收到確認。
第三，超時計時器設置的 重傳時間應當比數據在分組傳輸的平均往返時間更長一些 。
【發送方】超時重傳時間內沒有收到確認報文，無法確認是發送出錯、丟失，還是接收方的確認丟失，超時計時器到期後就要重傳。
【接收方】丟棄收到的重復分組，不向上層交付；向發送方發送確認。
【發送方】收下遲到的確認，並且丟棄
發送方大部分時間都在等待確認，信道的利用率低
使用流水線的 ARQ 可以提高信道利用率
【發送方】維持一個發送窗口，位於發送窗口內的分組都可連續發送出去，而不需要等待對方的確認。
回退N幀協議 ：如果發送方發送了多個分組，但中間的某個分組丟失了，這時接收方只能對丟失分組之前的分組發出確認，而發送方無法知道丟失分組及後面分組的接收情況，只好把丟失分組及後面的分組重傳一次，這叫 Go-back-N ，表示需要再退回來重傳已發送過的 N 個分組。
前面 20 個位元組固定，因此 TCP 首部最小長度是 20 位元組。
TCP 的滑動窗口以位元組為單位，窗口後沿的部分表示已發送且已收到通知，窗口裡的序號表示允許發送的序號，窗口前沿之前的數據暫時不允許發送，需要等待收到接收方的確認後前沿往前移才可發送。
描述一個發送窗口需要三個指針：P1、P2 和 P3，如圖所示：
小於 P1 的是已發送並已收到確認的部分，而大於 P3 的是不允許發送的部分。
P3 - P1 = A 的發送窗口
P2 - P1 = 已發送但尚未收到確認的位元組數
P3 - P2 = 允許發送但當前尚未發送的位元組數（又稱為 可用窗口 或 有效窗口 ）
接收方 B 接收窗口大小為20，因為未收到 31 的數據，即使已收到後面的序號 32、33 的數據，返回的確認號仍然是 31。
現在接收方收到了 31、32、33，並返回確認號 33，接收窗口往前滑動 3 個序號，發送方接收到確認，發送窗口也向前滑動 3 個序號大小，現在 A 可以發送序號 51~53 的數據了。
當發送方將發送窗口內的數據都發送出去，但是接收方的確認可能由於網路擁塞滯留，這時發送方發送窗口已滿，可用窗口為 0，只能等待接收方的確認報文到達。
TCP 為了保證可靠傳輸，要求必須受到對已發送報文的確認，如果超過一定時間未受到確認報文，則重傳已發送的報文。這個時間就叫 超時重傳時間 ，很明顯超時重傳時間的大小設置應該更貼近網路的實際情況，如果網路狀況好，就設短一點，否則使網路的空閑時間增大，降低了傳輸效率；網路差就設長一點，否則會引起很多不必要的重傳，使網路負荷增大。
TCP 採用了一種自適應的演算法：
RTT（報文段的往返時間）、RTTs（加權平均往返時間），RTTs 的計算公式：
RTTd（RTT 的偏差的加權平均值）、RTO（RetransmissionTime-Out 超時重傳時間）:
【場景】TCP 的接收方在接收對方發送過來的數據位元組流的序號不連續，形成一些不連續的位元組塊，如果簡單按照回退N幀協議處理，意味著要重傳第一個未收到的序號數據塊及之後的數據，如果能通知發送方已收到了哪些數據（選擇確認），就可以讓發送方只發送接收方未收到的數據。
流量控制就是讓發送方的發送速率不要太快，要讓接收方來得及接收。
當發送方收到接收方通知，將窗口縮小為 0 時，發送方將暫時不能發送數據了，必須等接收方通知更新接收窗口大小，但是這個通知又有可能丟失，導致發送方沒收到通知。
為了避免雙方互相等待死鎖，TCP 為每個鏈接設有一個 持續計時器 ，只要 TCP 連接的一方收到對方的零窗口通知，就啟動持續計時器。若持續計時器設置的時間到期，就發送一個零窗口 探測報文段 （僅攜帶 1 位元組的數據），而對方就在確認這個探測報文段時給出了現在的窗口值。如果窗口仍然是零，那麼受到這個報文段的一方就重新設置持續計時器；如果窗口不是零，那麼死鎖的僵局就可以打破了。
【優點】提高網路利用率
【缺點】可能會發生某種程度的延遲
【場景】接收數據的主機如果每次都立刻回復確認應答的話，可能會返回一個較小的窗口，因為接收方剛接收完數，緩沖區已滿。
【糊塗窗口綜合征問題】
TCP 接收方緩存已滿，而互動式的應用進程一次只從接收緩存中讀取 1 個位元組（這樣就使接收緩存空間僅騰出 1 個位元組），然後向發送方發送確認，並把窗口設置為 1 個位元組（但發送的數據報是 40 位元組長，TCP 首部 + IP 數據報首部）。接著，發送方又發來 1 個位元組的數據（注意發送方發送的 IP 數據報是 41 位元組長）。接收方發回確認，仍然將窗口設置為 1 個位元組。這樣進行下去，使網路的效率很低。
TCP 文件傳輸中，就採用了兩個數據段返回一次確認應答，並且等待一定時間後沒有其他數據包到達時也依然發送確認應答。
當對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的性能就要變壞，這種情況就叫做 擁塞 。
慢開始（slow-start）、擁塞避免（congestion avoidance）、快重傳（fast retransmit）和快恢復（fast recovery）。
【演算法思路】
當主機開始發送數據時，由於並不清楚網路的負荷情況，所以如果立即把大量數據位元組注入網路，那麼就有可能引起網路發生擁塞。較好的方法是先探測一下，即 由小到大逐漸增大發送窗口 ，也就是說， 由小到大逐漸增大擁塞窗口數值 。
【處理過程】
慢開始門限值 ssthresh 決定了擁塞窗口達到多大時要執行什麼演算法。
① 當 cwnd < ssthresh 時，使用慢開始演算法；
② 當 cwnd > ssthresh 時，停止使用慢開始演算法而改用擁塞避免演算法；
③ 當 cwnd = ssthresh 時，既可使用慢開始演算法，也可使用擁塞避免演算法。
在擁塞窗口 cwnd 達到門限值之前，發送方每一輪次收到確認應答後，cwnd 就增大為原來的兩倍；達到門限值後，執行擁塞避免演算法。
PS. 慢開始只是表示初始發送數據少，不代表發送速率增長速度慢，實際上是指數級增長非常快。
【演算法思路】
讓擁塞窗口 cwnd 緩慢地增大，即每經過一個往返時間 RTT 就把發送方的擁塞窗口 cwnd 加 1，而不是像慢開始階段那樣加倍增長。擁塞避免階段有 「加法增大」 的特點，按線性規律緩慢增長，使網路比較不容易出現擁塞 。
【處理過程】
在執行擁塞避免演算法階段，當網路出現超時時，發送方判斷為網路擁塞，調整門限值為當前擁塞窗口的一半，即 ssthresh = cwnd / 2，同時擁塞窗口重置為 1，即 cwnd = 1，進入慢開始階段。
【演算法原理】
① 快重傳
【場景】有時，個別報文段會在網路中丟失，但實際上網路並未發生擁塞。如果發送方遲遲收不到確認，就會產生超時，就會誤認為網路發生了擁塞，導致發送方錯誤地啟動慢開始，把擁塞窗口 cwnd 又設置為 1，因而降低了傳輸效率。
【方案】接收方不要等待自己發送數據時才進行捎帶確認，而是要立即發送確認，即使收到了失序的報文段也要立即發出對已收到的報文段的重復確認，當發送方 一連收到 3 個重復確認 ，就知道接收方確實沒有收到某個報文段，因而應當 立即進行重傳 。
② 快恢復：
發送方知道只是丟失了個別的報文段，於是不啟動慢開始，而是執行快恢復演算法，調整發送方門限值 ssthresh = cwnd / 2，同時設置擁塞窗口 cwnd = ssthresh = 8，並開始執行擁塞避免演算法。
擁塞控制的流程如下：
擁塞窗口 cwnd，接收方窗口 rwnd， 發送方發送窗口的上限值 = Min[rwnd, cwnd] 。
① 當 rwnd < cwnd，接收方的接收能力限制發送方窗口大小；
② 當 cwnd < rwnd，網路的擁塞程度限制發送方窗口大小。
【問題背景】
路由器採取分組丟棄策略，即按照 先進先出（FIFO） 規則處理分組，當隊列已滿時，則丟棄後面到達的分組，這叫 尾部丟棄策略 。
丟失的分組會導致發送方出現超時重傳，發送方轉而執行慢開始演算法，不同分組屬於不同 TCP 連接，導致很多 TCP 同時進入慢開始狀態，這種現象稱為 全局同步 。
【解決方案】
主動隊列管理 AQM：不等到路由器的隊列長度已經達到最大值時才不得不丟棄後面到達的分組，而是在隊列長度達到某個警惕值時就主動丟棄到達的分組，這樣就提醒了發送方放慢發送的速率，因而有可能使網路擁塞的程度減輕，甚至不出現網路擁塞。
TCP 是面向連接的協議，運輸連接有三個階段： 連接建立、數據傳送、連接釋放 。
TCP 連接建立過程要解決的幾個問題：
① 使每一方能夠確知對方的存在；
② 允許雙方協商一些參數（如最大窗口值、是否使用窗口擴大選項和時間戳選項以及服務質量等）；
③ 能夠對運輸實體資源（如緩存大小、連接表中的項目等）進行分配。
TCP 建立連接的過程叫做握手，握手需要在客戶和伺服器之間交換三個 TCP 報文段，即 三次握手 。
最初客戶端和服務端都處於 CLOSED（關閉） 狀態，A（Client）主動打開連接，B（Server）被動打開連接。
一開始，B 的 TCP 伺服器進程先創建 傳輸控制塊 TCB ，准備接受客戶進程的連接請求。然後伺服器進程就處於 LISTEN（收聽）狀態，等待客戶端的連接請求。如有，即作出響應。
第一次握手 ：A 的 TCP 客戶進程也是首先創建傳輸控制塊 TCB，准備接受客戶進程的連接請求。然後在打算建立 TCP 連接時，向 B 發出連接請求報文段，這時首部中的同步位 SYN = 1，同時選擇一個初始序號 seq = x。TCP 規定，SYN 報文段（即 SYN = 1 的報文段）不能攜帶數據，但要 消耗掉一個序號 。這時，TCP 客戶進程進入 SYN-SENT（同步已發送） 狀態。
第二次握手 ：B 收到連接請求報文段後，如同意建立連接，則向 A 發送確認。在確認報文段中應把 SYN 位和 ACK 位都置 1，確認號是 ack = x + 1，同時也為自己選擇一個初始序號 seq = y。請注意，這個報文段也不能攜帶數據，但同樣 要消耗掉一個序號 。這時 TCP 伺服器進程進入 SYN-RCVD（同步收到） 狀態。
第三次握手 ：TCP 客戶進程收到 B 的確認後，還要向 B 給出確認。確認報文段的 ACK 置 1，確認號 ack = y + 1，而自己的序號 seq = x + 1。TCP 的標准規定，ACK 報文段可以攜帶數據。但 如果不攜帶數據則不消耗序號 ，在這種情況下，下一個數據報文段的序號仍是 seq = x + 1。這時，TCP 連接已經建立，A 進入 ESTABLISHED（已建立連接） 狀態。當 B 收到 A 的確認後，也進入 ESTABLISHED（已建立連接）狀態。
數據傳輸結束後，通信的方法都可釋放連接。現在 A 和 B 都處於 ESTABLISHED 狀態。
第一次揮手 ：A 的應用進程先向其 TCP 發出連接釋放報文段，並停止再發送數據，主動關閉 TCP 連接。A 把連接釋放報文段首部的終止控制位 FIN 置 1，其序號 seq = u，它等於前面已傳送過的數據的最後一個位元組的序號加 1。這時 A 進入 FIN-WAIT-1（終止等待 1）狀態，等待 B 的確認。請注意，TCP 規定，FIN 報文段即使不攜帶數據，它也消耗掉一個序號。
第二次揮手 ：B 收到連接釋放報文後即發出確認，確認號是 ack = u + 1，而這個報文段自己的序號是 v，等於 B 前面已傳送過的最後一個位元組的序號加 1。然後 B 就進入 CLOSE-WAIT（關閉等待）狀態。TCP 伺服器進程這時應通知高層應用程序，因而從 A 到 B 這個方向的連接就釋放了，這時的 TCP 連接處於半關閉（half-close）狀態，即 A 已經沒有數據要發送了，但 B 若發送數，A 仍要接收。也就是說，從 B 到 A 這個方向的連接並未關閉，這個狀態可能會持續一段時間。A 收到來自 B 的確認後，就進入 FIN-WAIT-2（終止等待 2）狀態，等待 B 發出的連接釋放報文段。
第三次揮手 ：若 B 已經沒有要向 A 發送的數據，其應用進程就通知 TCP 釋放連接。這時 B 發出的連接釋放報文段必須使 FIN = 1。現假定 B 的序號為 w（在半關閉狀態 B 可能又發送了一些數據）。B 還必須重復上次已發送過的確認號 ack = u + 1。這時 B 就進入 LAST-ACK（最後確認）狀態，等待 A 的確認。
第四次揮手 ：A 在收到 B 的連接釋放報文段後，必須對此發出確認。在確認報文段中把 ACK 置 1，確認號 ack = w + 1，而自己的序號是 seq = u + 1（根據 TCP 標准，前面發送過的 FIN 報文段要消耗一個序號）。然後進入 TIME-WAIT（時間等待）狀態。請注意，現在 TCP 連接還沒有釋放掉。必須經過時間等待計時器（TIME-WAIT timer）設置的時間 2MSL 後，A 才進入到 CLOSED 狀態，然後撤銷傳輸控制塊，結束這次 TCP 連接。當然如果 B 一收到 A 的確認就進入 CLOSED 狀態，然後撤銷傳輸控制塊。所以在釋放連接時，B 結束 TCP 連接的時間要早於 A。
⑨ 計算機網路-可靠傳輸-滑動窗口協議
TCP的滑動窗口是以位元組為單位的 。為了便於說明滑動窗口的工作原理，我們故意把後面圖5-15至圖5-18中的位元組編號都取得很小。現假定A收到了B發來的確認報文段，其中窗口是20位元組，而 確認號是31 （這表明 B期望收到的下一個序號是31 ，而序號30為止的數據已經收到了)。根據這兩個數據，A就構造出自己的發送窗口。
我們先討論發送方A的發送窗口。發送窗口表示：在沒有收到B的確認的情況下，A可以連續把窗口內的數據都發送出去。凡是已經發送過的數據，在未收到確認之前都必須暫時保留，以便在超時重傳時使用。
發送窗口裡面的序號表示允許發送的序號。顯然，窗口越大，發送方就可以在收到對方確認之前連續發送更多的數據，因而可能獲得更高的傳輸效率。接收方會把自己的接收窗口數值放在窗口欄位中發送給對方。因此，A的發送窗口一定不能超過B的接收窗口數值。發送方的發送窗口大小還要受到當時網路擁塞程度的制約。但在目前，暫不考慮網路擁塞的影響。
發送窗口後沿的後面部分表示己發送且己收到了確認。這些數據顯然不需要再保留了。而發送窗口前沿的前面部分表示不允許發送的，因為接收方都沒有為這部分數據保留臨時存放的緩存空間。
發送窗口的位置由窗口前沿和後沿的位置共同確定。發送窗口後沿的變化情況有兩種可能，即不動（沒有收到新的確認）和前移（收到了新的確認）。發送窗口後沿不可能向後移動，因為不能撤銷掉已收到的確認。發送窗口前沿通常是不斷向前移動，但也有可能不動。這對應於兩種情況：一是沒有收到新的確認，對方通知的窗口大小也不變；二是收到了新的確認但對方通知的窗口縮小了，使得發送窗口前沿正好不動。
發送窗口前沿 也有可能 向後收縮 。這發生在對方通知的窗口縮小了。但 TCP的標准強烈不贊成 這樣做。因為很可能發送方在收到這個通知以前已經發送了窗口中的許多數據，現在又要收縮窗口，不讓發送這些數據，這樣就會產生一些錯誤。
現在假定A發送了序號為31-41的數據。這時， A發送窗口位置並未改變 （圖5-16），但發送窗口內靠後面有11個位元組（31~41）表示己發送但未收到確認。而發送窗口內靠前面的9個位元組(42~50)是允許發送但尚未發送的。
從以上所述可以看出，要描述一個發送窗口的狀態需要三個指針：P1,P2和P3(圖5-16)。指針都指向位元組的序號。這三個指針指向的幾個部分的意義如下：
小於P1的是已發送並已收到確認的部分，而大於P3的是不允許發送的部分。
P3-P1=A的發送窗口
P2-P1=己發送但尚未收到確認的位元組數
P3-P2=允許發送但當前尚未發送的位元組數（又稱為 可用窗口或有效窗口 ）
再看一下B的接收窗口。B的接收窗口大小是20。在接收窗口外面，到30號為止的數據是已經發送過確認，並且己經交付主機了。因此在B可以不再保留這些數據。接收窗口內的序號(31~50)是允許接收的。在圖5-16中，B收到了序號為32和33的數據。這些數據沒有按序到達，因為序號為31的數據沒有收到（也許丟失了，也許滯留在網路中的某處)。請注意，B只能對按序收到的數據中的最高序號給出確認，因此B發送的確認報文段中的確認號仍然是31（即期望收到的序號），而不能是32或33。
現在假定B收到了序號為31的數據，並把序號為31~33的數據交付主機，然後B刪除這些數據。接著把接收窗口向前移動3個序號（圖5-17），同時給A發送確認，其中窗口值仍為20，但確認號是34。這表明B已經收到了到序號33為止的數據。我們注意到，B還收到了序號為37,38和40的數據，但這些都沒有按序到達，只能先暫存在接收窗口中，等待缺少的數據到達。A收到B的確認後，就可以把發送窗口向前滑動3個序號，但指針P2不動。可以看出，現在A的可用窗口增大了，可發送的序號范圍是42~53。
A在繼續發送完序號42~53的數據後，指針P2向前移動和P3重合。發送窗口內的序號都已用完，但還沒有再收到確認（圖5-18）。由於A的發送窗口已滿，可用窗口已減小到零，因此必須停止發送。請注意，存在下面這種可能性，就是發送窗口內所有的數據都已正確到達B,B也早已發出了確認。但不幸的是，所有這些確認都滯留在網路中。在沒有收到B的確認時，A不能猜測：「或許B收到了吧！」為了保證可靠傳輸，A只能認為B還沒有收到這些數據。於是，A在經過一段時間後（由超時計時器控制）就重傳這部分數據，重新設置超時計時器，直到收到B的確認為止。如果A收到確認號落在發送窗口內，那麼A就可以使發送窗口繼續向前滑動，並發送新的數據。
我們在前面的圖5-18中曾給出了這樣的概念：發送方的應用進程把位元組流寫入TCP的發送緩存，接收方的應用進程從TCP的接收緩存中讀取位元組流。
窗口和緩存的關系
第一，緩存空間和序號空間都是有限的，並且都是循環使用的。最好是把它們畫成圓環狀的，但這里為了畫圖的方便，我們還是把它們畫成長條狀的。
第二，由於實際上緩存或窗口中的位元組數是非常之大的，因此圖5-19（a發送緩存和發送窗口，b接收緩存和接收窗口）僅僅是個示意圖，沒有標出具體的數值。但用這樣的圖米說明緩存和發送窗口以及接收窗口的關系是很清楚的。
發送緩存用來暫時存放：
(1)發送應用程序傳送給發送方TCP准備發送的數據；
2)TCP已發送出但尚未收到確認的數據。
發送窗口通常只是發送緩存的一部分，已被確認的數據應當從發送緩存中刪除，因此發送緩存和發送窗口的後沿是重合的。發送應用程序最後寫入發送緩存的位元組減去最後被確認的位元組，就是還保留在發送緩存中的被寫入的位元組數。發送應用程序必須控制寫入緩存的速率，不能太快，否則發送緩存就會沒有存放數據的空間。
接收緩存用來暫時存放：
(1)按序到達的、但尚未被接收應用程序讀取的數據；
(2)末按序到達的數據。
如果收到的分組被檢測出有差錯，則要丟棄。如果接收應用程序來不及讀取收到的數據，接收緩存最終就會被填滿，使接收窗口減小到零。反之，如果接收應用程序能夠及時從接收緩存中讀取收到的數據，接收窗口就可以增大，但最大不能超過接收緩存的大小。圖5-19(b)中還指出了下一個期望收到的位元組號。這個位元組號也就是接收方給發送方的報文段的首部中的確認號。
根據以上所討論的，我們還要再強調以下三點。
第一，雖然A的發送窗口是根據B的接收窗口設置的，但在同一時刻，A的發送窗口並不總是和B的接收窗口一樣大。這是因為通過網路傳送窗口值需要經歷一定的時間滯後(這個時間還是不確定的)。另外，發送方A還可能根據網路當時的擁塞情況適當減小自己的發送窗口數值。
第二，對於不按序到達的數據應如何處理，TCP標准並無明確規定。如果接收方把不按序到達的數據一律丟棄，那麼接妝窗口的管理將會比較簡單，但這樣做對網路資源的利用不利（因為發送方會重復傳送較多的數據）。因此TCP通常對不按序到達的數據是先臨時存放在接收窗口中，等到位元組流中所缺少的位元組收到後，再按序交付上層的應用進程。
第三，TCP要求接收方必須有累積確認的功能，這樣可以減小傳輸開銷。接收方可以在合適的時候發送確認，也可以在自己有數據要發送時把確認信息順便梢帶上。但請注意兩點。一是接收方不應過分推遲發送確認，否則會導致發送方不必要的重傳，這反而浪費了網路的資源。TCP標准規定，確認推遲的時間不應超過0.5秒。若收到一連申具有最大長度的報文段，則必須每隔一個報文段就發送一個確認。二是梢帶確認實際上並不經常發生，因為大多數應用程序很少同時在兩個方向上發送數據。
最後再強調一下，TCP的通信是全雙工通信。通信中的每一方都在發送和接收報文段。因此，每一方都有自己的發送窗口和接收窗口。在談到這些窗口時，一定要弄清是哪一方的窗口。