- 本文部分圖檔（PPT截圖）來自中科大計算機網絡top down
3.0 目錄
[TOC]
3.1 概述
- 傳輸層TCP和UDP協定可以在IP協定主機到主機通信的基礎上，實作程序到程序之間的通信（利用端口号）真正實作端到端的通信【通過多路複用于解複用】
- 傳輸層的TCP協定可以提供可靠性的服務（RDT），但是并不能改進延時和吞吐量的性能，也不能提供安全性的保障（應用層中的SSL: Secure Socket Layer）
3.2 多路複用與解複用
A. 形象了解
- 生活中的示例：Anne家12個小孩，Bill家10個小孩，每個月Anne家的每個孩子都要給Bill家的每個孩子寫郵件，示意圖如下：
- 120封信通過郵局發出相當于多路複用過程，Bill家大孩子分信相當于解複用的過程
B. 原理分析
- 多路複用的過程：建立套接字socket，與應用程序的程序号互相關聯，并利用套接字的源端與目的端IP和Port建立TCP\UDP封包段和IP資料報的頭部
- 解複用的過程：傳輸層擷取到源IP，目标IP，源Port以及目标Port之後即可查詢本地的Socket表，便可以得知建立該套接字的應用程序
3.3 UDP協定
- UDP：User Datagram Protocol使用者資料報協定
- UDP有什麼用武之地呢？【流媒體應用】（要求實時性較高）、【DNS域名系統】（典型的事務性應用）、【SNMP簡單網絡管理協定】
A. UDP封包頭部
- UDP是面向封包的協定【封包是有界的】，TCP是面向位元組流的協定【位元組流是無界的】
- UDP封包的頭部總共8個位元組（2*32bits = 8Bytes）
- 封包長度是以位元組為機關的封包長度（包含頭部的8個位元組）
B. UDP差錯檢驗EDC（校驗和）
- EDC:Error_Detection and Correction差錯檢測與糾錯
- 将整個UDP資料報切成一個個16bits的段（頭部也要切），并将所有段加起來
- 得到校驗和需要兩個技巧：進位復原+按位取反
3.4 可靠資料傳輸RDT
- 本節采用漸進的方式講述RDT即從下層完全可靠開始，逐漸加入不可靠的因素，并了解相應的RDT可靠資料傳輸機制的可靠性措施
- 且本節采用有限狀态機FSM：Finite State Machine的形式來描述發送和接收方的狀态，有限狀态機的形式如下：
A. RDT1.0 下層可靠信道的可靠資料傳輸
- 下層提供的服務無比特差錯，無分組丢失，完全可靠
- 本層隻需要增加多路複用與解複用服務即可
- 是以，對于應用層交到傳輸層的封包，隻需要進行封裝并遞交給網絡層，對于接收方網絡層上交的封包段也隻需要解封裝并通過解複用上傳給應用層程序即可
- 其有限狀态機如下：
B.RDT2.0 具有比特差錯的下層信道
- 下層信道可以具有bit差錯（把0傳成1）是以需要有傳輸确認的機制（ACK+NAK），以及校驗和checksum校驗的機制（進位復原+按位取反）
- 是以，發送方發送封包段後進入等待确認的階段，如果受到ACK，則說明接收方成功受到并校驗通過封包段，因而發送發可以進入下一個等待上層調用的周期
- 而接收方接收到封包段後，需要利用校驗和校驗封包，校驗不通過，傳回标志NAK，并丢棄錯誤封包，等待封包重新傳輸；校驗通過，傳回标志ACK，并解封裝封包，通過解複用傳遞給應用層程序
- 其有限狀态機如下圖所示：
C. RDT2.1：解決2.0中ACK，NAK傳輸出錯問題
- RDT2.0中有個緻命的不足，若ACK或NAK在傳輸的過程中發生錯誤，或無法到達，那麼發送端将一直處于等待回複的狀态，接收端也将一直處于等待包裹的狀态，系統死鎖
- 是以，RDT2.1中加入了序号機制以及對ACK與NAK的校驗機制
- 首先，對ACK與NAK的校驗機制目的是驗證ACK與NAK在傳輸的過程中是否有發生錯誤
- 接着，引入編号對解決ACK以及NAK傳輸錯誤的問題有什麼作用呢？不是加入校驗機制就可以了嗎？
- 對于發送方而言，确實不需要編号的機制，隻要收到一個不知道是啥的回報，再将本分組發出去即可，是以，引入編号對發送方是沒影響的
- 但是對于接收方而言，如果不引入編号，那麼我們可以假設以下兩種情景：
- 發送方給接收方的封包校驗不通過，接收方本來要傳回NAK，但NAK在傳回的圖中挂了，那麼發送方重新傳遞該封包是沒問題的
- 發送方給接收方的封包校驗通過了，而接收方本來要傳回ACK，ACK在半路挂了。如果沒有序号，那麼接收方将回到等待下層封包到來的階段，如果再次收到原封包，那麼接收方也會當作正常的封包解封裝傳遞給應用層程序，導緻同樣的封包重複傳遞。即原本應該傳遞pkg0和pkg1但是現在由于傳回的ACK半路挂了，因而接收方向其應用程序輸送了兩次pkg0，顯然是有問題的
- 是以，編号機制對于接收方不重複傳遞是有重要意義的
- RDT2.1的有限狀态機如下：
D. RDT2.2：NAK_free版本的協定
- 在RDT2.2版本中，用上一個分組的确認号代表本分組的拒絕，進而實作了NAK_free的協定，進而有利于後面pipeline高效可靠資料傳輸的實作
- RDT2.2的實作示意圖如下：
- 即若發送方發送的分組1校驗失敗，則接收方發送ACK0表示收到分組0，未收到分組1，是以發送方将重新發送分組1。特别地，若第一個分組未收到，則發送ACK1，代表校驗失敗。
E. RDT3.0：完備的停止等待(stop and wait)協定
- 上述的RDT2.1和RDT2.2協定雖然解決了ACK和NAK在傳輸過程中發生錯誤的問題，但由第一章中分組交換的知識知道：當中間交換節點隊滿時，到來的分組會直接被丢失，使得丢包的出現。
- 若線路出現丢包，發送方處于等待回複的狀态，而接收方處于等待分組的狀态，那麼系統又會進入死鎖的狀态中，需要新的機制打破死鎖。
- RDT3.0中采用了逾時重傳的機制打破上述的死鎖，發送方在發送了分組之後開始計時，當時間超過設定的時間後，則重新發送該分組。【逾時時間如何計算将在TCP協定部分進行詳述】
- RDT3.0的有限狀态機如下兩圖所示：
- 需要特别說明的是，上面⭐A的部分，A部分代表什麼都不幹。可能你會有問題：在前面協定RDT2.1裡面，如果收到了NAK或者是收到了錯誤的回複，不是應該要重傳該封包嗎？為什麼這裡啥也不幹呢？
- 其實，這裡有點版本相容性的原因，在RDT3.0中，采用了逾時重傳的機制，是以不論什麼情況，隻要達到逾時時間，都需要重傳分組。是以，在收到拒絕或者錯誤的回複時，RDT3.0協定不急着立馬重傳，而是等着逾時時間到再重傳。
- 為了了解更加深入，我們再就着上面的有限狀态機推演一遍停止等待協定的循環：
- 首先應用層調用原語要發送分組0，則發送端儲存分組0的副本，并向接收端發送資料+校驗和+分組序号0。發送端進入等待回複0的狀态。
- 接收端接收到分組0，校驗正确，并向發送端發送ACK0的回複，将分組0解封裝，解複用後發送給應用層應用程序。接收端進入等待分組1的狀态。
- 接收端發送的ACK0在傳輸過程中發生錯誤，傳送到發送端，發送端啥也不幹，等着逾時事件的到來。
- 逾時時間到，發送端重新發送分組0，并重新開始計時，繼續進入等待回複0的狀态。
- 接收端再次收到分組0，校驗通過，于是接收端将分組直接丢棄，并向發送端發送ACK0。
- 成功接收到ACK0後，發送端停止計時，并進入等待應用層調用發送分組1的請求，循環完成。
F. Pipeline流水線協定
- 停止等待協定是每次發送一個分組，并且等待收到正确回複之後才能發送第二個分組，這種方式在區域網路還能湊活，如果到了廣域網就明顯效率太低了，就像華南快速幹線每次隻能通過一輛車，這輛車走完了才允許第二輛車走，明顯不行。
- 我們做一個小計算：現有發送方Sender與接收方Receiver建立了聯系，兩者建立聯系的往返延時RTT = 30ms，現有封包的大小為L = 1000kB = 8000kbits，網絡帶寬為R = 1Gbps。則發送時延為t = L/R = 8μs，是以，網絡的使用率為：
- 是以，對于較大型的網絡，流水線協定非常有必要
F1. 滑動視窗協定（Sliding Window）
- 發送緩沖區與發送視窗
- 首先，在前面講到分組交換的時候我們曾提到過發送緩沖區，用來儲存要發送的分組，如果發送緩沖區滿，那麼後來的資料分組将被直接抛棄，造成丢包。
- 而發送視窗是發送緩沖區的子集，是可以發送的資料。例如發送緩沖區可以存儲10個資料分組，而發送緩沖區的最大尺寸為4。是以對于封包0，1，2，3而言，可以直接發送，而封包4則需要等待
- 發送視窗類似于一個隊列，有頭尾兩個指針，初始狀态頭尾指針同時指向發送緩沖區的頭部，當應用層發送來一個封包，頭指針前移，尾指針不變【在發送視窗不超過最大值的情況下，循環上述操作】
- 在發送視窗内的封包可以發送，發送卻未收到回複的封包依舊保留在發送視窗中，并用逾時重傳定時器控制是否需要重發（不同協定的定時器設定不同），如果發送視窗的分組得到正确的确認，那麼發送視窗尾指針後移。
- 舊的分組完成正确确認，新的分組可以進入發送視窗中，實作發送視窗的滑動。且由于發送緩沖區的大小是有限的，因而雙指針在滑動的過程中需要進行取模的操作【類似循環隊列的操作】
- 接收視窗
- 接收視窗限定了網絡可以同時接收的分組的數目，如果接收視窗的大小為1，那麼發送方發送的資料必須順序到達，而如果接受視窗大于1，那麼允許發送方發送的資料亂序到達
- Sliding Window與Stop and wait``Go Back N以及Selective Repeat
- 發送視窗的大小為：SW，接收視窗的大小為RW
- SW = 1 && RW = 1：停止等待協定Stop and wait
- SW > 1 && RW = 1：回退N步協定Go Back N
- SW = 1 && RW = 1：選擇性重傳Selective Repeat
F2. 回退N步協定（Go Back N）
- 發送視窗大小大于1，接收視窗值等于1
- 發送端發送視窗内的所有封包（P0,P1,P2），并打開逾時重傳定時器【GBN協定隻維持一個逾時重傳定時器】。接收端的接收視窗等待接收P0
- 如果發送端P0最早到達，那麼接收端将傳回ACK0，代表P0接收成功，并将接收視窗移動到P1
- 如果發送端成功接收到ACK0，那麼發送端将定時器重新開始計時，并将發送視窗後移一位，可以發送新的分組
- 但是，分組1在傳輸過程中丢包了，因而發送端發送的分組P2比P1先到達接收端，接收端接收到P2分組，傳回ACK0，代表沒有接收到期望的分組P1，發送視窗不動，繼續等包裹
- 此時，發送端接又一次收到了ACK0，重新開機計時，并且等着逾時。到了逾時時間，發送端就把從P1開始的所有分組又重新發出去，重新計時，等待ACK1的到來
- GBN協定的有限狀态機如下圖所示：
F3. 選擇性重傳協定（Selective Repeat）
- 發送視窗和接收視窗都大于1
- 允許出現傳輸的亂序，并可以利用接收視窗的容量實作亂序分組的糾正
- 選擇性重傳協定的示意圖如下：
- 我們跟着上圖推演一下過程，深入了解協定的過程：
- 首先發送方向接收方發送分組P0，P1，P2，P3，其中，P0，P2，P3都正常傳遞，而P1在傳遞的過程中發生的丢包
- 是以，接收端最先接收到分組P0，則直接将P0解封裝上交給應用程序，并将接收視窗後移一位
- 由于分組P1丢包，是以接收端無法收到該分組，但可以正常接收分組P2和P3。但是在接收了分組P2和P3之後，接收端并不解封裝上交，而是等着P1分組的到來。并且向發送端發送确認封包ACK2和ACK3，那麼确認封包ACK2和ACK3會讓發送端的P2，P3對應的逾時重傳定時器停止計時。
- 分組1丢包必然導緻P1對應的逾時重傳定時器到時，因而發送方會重傳P1分組。該分組成功傳達後，接收端會對P1，P2，P3進行解封裝，并将三個分組稱遞給應用程序，實作順序的糾正
G. GBN與SR協定的對比
- GBN協定維持一個逾時重傳定時器，但是遇到逾時的情況需要将發送區内的所有内容都發送出去
- SR協定維持多個逾時重傳定時器，遇到逾時的情況可以有針對性地發送不能正常傳遞的分組
- GBN協定較簡單，但出錯的代價比較大，是以适合于出錯幾率比較低的網絡
- SR的協定較複雜一些，但是出錯的代價小，因而适合于比較容易出現傳輸亂序的網絡
3.5 TCP協定
- 由于需要建立連接配接，僅能提供一對一的服務，而UDP可以提供一對多，多對多的服務
- TCP是面向位元組流的協定，而UDP是面向封包的協定，TCP不維護封包的界限，而是将封包切成一個個MSS：Max Segment Size大小的封包段
- TCP是流水線形式的；且為了比對發送和接收的速率，設定發送和接收緩存；且全雙工通信，即發送和接收是同時同步進行的
- TCP具有流量控制和擁塞控制
A. MSS最大封包段大小
- 對于任何實體網絡，都具有MTU:Max Transfer Unit最大傳輸端元。對于以太網而言，最大的資料傳輸單元的大小是1500Bytes
- 而每一個封包段需要加上TCP頭部以及IP頭部需要恰好可以封裝成幀的載荷部分
- 而TCP頭部和IP頭部都是20Bytes是以MSS為1460
B. TCP封包結構
- 序号（以位元組為機關）：序号和前面RDT中的PDU序号是不一樣的，TCP封包中的序号是每個MSS的第一個位元組相對整個位元組流首位的偏移量
- 兩個應用程序在建立TCP連接配接時初始的位元組号不是為0的，因為需要防止滞留在網絡中的分組對其造成影響
- 确認号ACK（以位元組為機關）：确認号的含義：如對方發回來的ACK=555，代表我已經收到了554以及以前的所有位元組，期待你從555位元組開始發送。這個定義和我們講RDT時候的定義是不太一樣的
- 用一個例子在加深序号Seq與确認号ACK：
C. TCP逾時定時器時間的設定
- 逾時時間太短，會使得分組出現沒有必要的重發；逾時時間太長，會使得網絡過于消極，等待時間太長
- 且對于多跳的網絡，其逾時時間波動較大，即機率密度函數較為矮胖，難以挑一個固定的時間，但是對于每一個短的時間而言，其分布比較集中，機率密度函數比較高瘦，可以選出一個合适的值，是以要采用一個适應式的時間設定政策
- 上一時刻的平均往返時延為EstimateRTT0，本時刻測定其中一個分組的往返延時SampleRTT，因而本時刻平均往返時延為（移動平均值）：
- 上一時刻的偏差為DevRTT0，本時刻的偏差為|SampleRTT-EstimateRTT1|，是以同樣由滑動平均的政策可以得出本時刻的往返時延偏差（可以認為是方差）：
- 是以我們設定的逾時時間間隔為（類似機率中的3σ原則）：
D. TCP的可靠資料傳輸
- TCP的RDT是GBN與SR協定的混合體
- TCP采用累計确認的方式，而不是逐段确認
- TCP僅設定一個定時器，這一點和GBN協定是一樣的
- 但是TCP定時器是随着最老的段發出開始計時的，而當定時器到時，TCP協定會僅将最老的段發出，而不是把視窗内所有封包發出，這一點和SR協定很像
- 如果TCP收到了亂序封包段，封包段怎麼處理是可以自定義的。像GBN一樣抛棄，或者像SR一樣存下來都可以
D1. TCP的重傳機制
- 如果逾時定時器到時，肯定要重傳
- 如果在收到一個正确的封包段确認後，又收到三個備援的封包段确認，而逾時時間依然沒到，那麼會進行快速重傳。
- 也就是發送端發送了P0,P1,P2,P3,P4，P0封包段正常送達，但是P1丢包了，P2,P3,P4都陸續送到，是以又傳回了三個備援的确認，是以，TCP啟動快速重傳機制，傳出發送視窗中最老的一個封包P1
D2. TCP的有限狀态機（不包括流量和擁塞控制）
- 在收到ACK的部分，實際的TCP協定會加入快速重傳算法，快速重傳前文已經講解，不再贅述
E. TCP的流量控制
- 發送方發送的檔案速度太快，而接收方處理不過來
- TCP封包的頭部有一個Receive Window的字段，通過封包傳回，發送方即可得知現在接收方接收視窗的大小，并可以以此來控制發送方發送視窗的大小。發送視窗的計算公式如下：
- 其中，SendWindow是發送視窗的大小，ReceiveWindow是接收視窗的大小，CongestionWindow是擁塞視窗的大小
- 接收視窗的計算公式如下：
- 其中，RcvBuffer是原始整個接收視窗的大小，LastByteRcv-LastByteRead是已經占用的接收視窗大小，LastByteRcv是最近收到的最後一個位元組，LastByteRead是最近完成讀取的最後一個位元組
- 捎帶技術Piggybacking：捎帶技術就是把資料和确認資訊合并在一起（相當于農夫1給農夫2送了一頭🐖，農夫2會送給農夫1送回一頭🐏，并且在🐏屁股上貼一張紙條，說我已經收到你的🐖了【确認ACK】，我的農場還要5頭🐖的位置【接收視窗大小】）
F. 連接配接管理：連接配接建立+連接配接拆除
F1. 兩次握手可以嗎？
- 兩次握手即連接配接請求+連接配接建立有什麼問題呢？
- 兩次握手失敗的場景如下圖所示：
- 上圖左邊的情況，如果僅有兩次握手，那麼伺服器端必定在接收到請求封包之後就會進入連接配接狀态，同時發回連接配接确認封包。這就造成了伺服器先進入連接配接狀态，而使用者後進入連接配接狀态，那麼如果連接配接确認封包傳輸有誤，或者連接配接請求封包逾時重傳，而在重傳的過程中連接配接被使用者斷掉了，就有可能出現隻有伺服器在傻傻地處于連接配接狀态【半連接配接】，而使用者其實并沒有維持連接配接狀态
- 右邊的失敗情景也是由于伺服器先進入連接配接狀态，而把舊的資料當成新的資料接收了
F2. 三次握手
- TCP三向交握的示意圖：
- TCP解決兩次揮手的失敗情景：
- 對于可能存在的半連接配接情況：伺服器端接收到遲到的連接配接請求，并發回連接配接确認，此時這個連接配接确認會直接被用戶端拒絕
- 對于可能存在舊資料被當成新資料接收的情況，由于連接配接根本沒有建立起來，是以當然不會接收該資料
- 詭異的可能失敗情景以及解決辦法：
- 對于上述右邊情況，可能會存在一種更詭異的情形：假定用戶端的端口為555，伺服器的端口為80，第一次連接配接建立，有一個封包（圖中的data(x+1)）一直在網絡裡面飄。等到第二次用戶端又以555端口與伺服器的80端口建立連接配接，那個封包才到，這就有舊封包被當成新的封包接收的風險。
- 解決：我們不選擇固定的值作為序号，而是随機選擇一個32位比特作為序号的開始【可能利用時間作為随機數産生器】，這樣可以最大程度避免老資料對新連接配接的影響
F3. 連接配接結束（四次揮手）
- 分兩個方向進行連接配接拆除
- 首先，用戶端向伺服器發起連接配接拆除，伺服器回複确認，那麼就沒有資料從使用者傳遞給伺服器了，但伺服器還可能有資料傳回來用戶端
- 接着，伺服器也傳完了資料，那麼就再次向用戶端發來連接配接拆除請求，得到用戶端的确認，之後沒有資料從伺服器傳給用戶端，整個連接配接完全拆除
- 依然不完美，存在兩軍問題，都有可能存在一方維持連接配接的問題
3.6 擁塞控制
A. 擁塞控制與流量控制的差別
- 流量控制是我和你的問題，即發送方與接收方的問題
- 而擁塞控制是針對公共網絡的控制
- 就像某博物館一天隻能容納100人，而一個學校一個年級10000人，那麼流量控制就是學校每天隻能有100人去博物館，而擁塞控制則是這100個人在去往博物館的圖中盡量不要遇到塞車等情況
B. 網絡擁塞的原理
- 網絡擁塞的表現1：延時特别大（當流量強度->1時，排隊延時->+∞）
- 由第一章的排隊延時與流量強度的關系可以知道，當網絡阻塞程度增加，流量強度I->1是以延時t_queue->+∞
- 網絡擁塞的表現2：降低了goodput，為了達到有效的輸出，我得輸入更多的資料（因為逾時重傳的比例越來越大）。而且造成重複，由于網絡延時急劇增加，是以非常多的分組原本并沒有丢，但是都進行了重發，導緻嚴重的重複，進而擁塞的情況越來越嚴重，相當于一個正回報
- 網絡擁塞的表現3：網絡死鎖+浪費上遊傳輸能力
- 在上圖可以發現，當紅色流量處于上遊的時候（就是紅色流量剛剛發出，流量最大，競争力最強的時候），與之競争的是藍色的下遊流量【上面的路由器】，是以紅色流量競争力大，導緻藍色流量大量丢包
- 同樣到了紅色流量的下遊路由器【右邊的路由器】，紅色流量減小，競争力減小，而恰好遇到綠色的上遊流量，是以紅色流量丢包率大大上升。
- 其他的流量也是如此，整個網絡進入死鎖，上遊流量傳輸到下遊被大量丢包
C. 擁塞控制方法
C1. 端到端的擁塞控制方法（TCP）
- 端系統自身判斷網絡是否發生擁塞
- TCP依靠如分組丢包，備援确認等名額進行判斷
C2. 網絡輔助資訊的擁塞控制
- 網絡核心會提供擁塞資訊給端系統
- 端系統根據資訊控制發送
D.ATM異步傳輸網絡的擁塞控制方法（網絡輔助資訊擁塞控制）
- ATM網絡的資料機關是信元（短小53Byte）
- 線路交換的每個節點消耗1Byte的時間，而分組交換在每個節點消耗1分組的時間（1個分組通常1000+位元組），因而ATM網路介于兩者之間
- ABR：Available Bit Rate，例如ATM網路的正常帶寬是1Mbps，那麼在不發生擁塞的時候可以盡可能發送，而發生擁塞的時候，必須控制發送的速度不能超過1Mbps
- 信元分成兩類，資料信元以及資源管理RM信元，RM信元中有NI bit:No Increase in rate輕微擁塞信元以及CI bit:Congestion Indication擁塞訓示信元，ATM交換裝置發現網路出現擁塞的情況，那麼會将封包的對應位置位，是以就可以讓端主機知道網絡的擁塞情況
- 且資源管理信元中還有ER:Explicit Rate字段，代表網絡可以為該對連接配接提供多少帶寬，信元每次經過交換裝置，交換裝置會将可以提供的帶寬與現有的ER字段的值進行對比，如果比現有的值小，那麼就存入作為新的ER值
3.7 TCP擁塞控制（端到端擁塞控制）
- 網絡輔助資訊擁塞控制的不足：網絡交換裝置的負擔較大，對于大型網絡，成本開銷很大
- 而TCP協定的端到端擁塞控制，将最複雜的部分放在網絡邊緣，而網絡核心部分采用最簡單的設計
A. 如何檢測擁塞?
- 逾時時間的發生【擁塞】：逾時說明網絡發生擁塞，延時增大，此時應該降低發送速度；也可能是分組在傳輸過程中受到幹擾，導緻出錯，無法通過校驗和的校驗，此時不應該降低發送網絡，但是這種情況發生的機率是非常低的，是以問題不大
- 備援确認【輕微擁塞】：某一個分段丢了，但後面的幾個段都順利到達了，說明擁塞傳不到的情況還不是很普遍，是以是輕微擁塞【備援确認與快速重傳算法見前面TCP網絡部分】
B. 如何控制發送速率？
- 在發送端維持了一個變量，rate是擁塞控制的速度，CongWin是在對方未确認的情況下可以向網絡注入多少位元組
- 逾時或者3個重複ACK，CongWin↓
- 逾時：CongWin降為1MSS，在SS慢啟動階段，然後倍增到CongWin/2（每個RTT），然後進入CA階段
- 3個重複ACK：CongWin降低為CongWin/2，進入CA擁塞避免階段
- 正常收到ACK的時候，CongWin↑
- SS：Slow Start慢啟動階段：每個RTT，擁塞視窗值CongWin加倍
- CA：Congestion Avoidence擁塞避免階段：每個RTT，擁塞視窗值CongWin線性增加
C. TCP擁塞控制與流量控制聯合控制動作
- 發送視窗的大小由空閑緩沖區（接收視窗值）以及擁塞視窗值的大小限定 ，可以同時滿足擁塞控制和流量控制的要求
D. 擁塞控制政策
- 慢啟動
- TCP建立的時候，CongWin設定為1MSS
- 每受到一個确認，擁塞視窗值CongWin+1，也就是每一輪（每個RTT）CongWin翻倍
- 翻倍的CongWin很快就會導緻逾時，假設逾時的門檻值為CongWin_0，那麼逾時之後，将CongWin = 1并且将CongWin_0/2作為警戒值，在[CongWin_0/2,CongWin_0]區間内進行擁塞避免階段，在擁塞避免階段即不能再翻倍了
- 線性增加，乘性減小
- 由擁塞控制決定的平均吞吐量（忽略慢啟動階段的時間），擁塞視窗值為W：
E. TCP的公平性
- 情況一：AA'和BB'是兩對主機，都建立了一對TCP連接配接，而且兩者的往返時延是相同的，其中有一段主幹鍊路都是兩者的帶寬瓶頸鍊路，且其帶寬為Rbps，那麼兩者是公平享有一半的帶寬的
- 根據上面的圖可以發現，每當AA'和BB'發生逾時事件，AA'和BB'都會減半，朝着AA'和BB'相等的方向發展，最終達成公平
- 情況二：AA'采用TCP協定進行通信，BB'采用UDP連接配接
- 此情況是不公平的，因為TCP協定是有流量控制和擁塞控制的，但是UDP是沒有的，因而UDP對帶寬具有極強的侵略性，占據很大的帶寬
- 情況三：AA'中建立了9對TCP連接配接，而BB'隻建立了1對TCP連接配接，兩者的往返時延相同
- 那AA'将占用0.9的帶寬，BB'隻占用0.1的帶寬
- 情況四：AA'與BB'都隻建立了一對TCP連接配接，但是AA'的往返時延短一些
- 根據上面吞吐量的公式，顯然有AA'占據的帶寬要大一些