TCP/TP

概述

分組—面向連線
資料報—無連結

訊息邊界是兩次寫入之間的位置或位元組便移量，舉個例子，TCP協議是面向流的無訊息邊界，假設接收端有3個來自發送端的分組，但是3個總大小都小於接收端的接收緩衝區大小，則接收端可以將3個分組一起從緩衝區讀出來；UDP是面向資料報的有訊息邊界，無論資料報有多大，接收端都需要為每個單獨的資料報執行接收動作

在OSI7層模型中，傳送時每一層都有自己的訊息物件（PDU），每一層都將來自上一層的PDU視為不透明無需解釋的資訊，不會檢視具體內容。然後將上層取得的PDU封裝（增加頭部尾部），接收時相反（分解）。每層都會有一個標示符，允許接收方決定哪些協議或資料流可以複用在一起

熟知埠號0 - 1023
註冊埠號1024 - 49151
動態/私有埠49152 - 65535

有些應用以更分散式的形式設計，沒有固定的伺服器，每個應用即可以是客戶端，又可以是服務端，又可以兩者都是。這種應用成為對等或這種應用成為對等或P2P應用，併發P2P應用接收到傳入的請求確定他能否響應，如果不能則轉發給其他對等方。這種由一組P2P應用共同形成的應用網路稱為覆蓋網路 如Skype

Internet地址結構

IPv4長度為32位，IPv6長度為128位

A類地址： 0 + 7（網路號） + 24（主機）
B類地址： 10 + 14（網路號） + 16（主機）
C類地址： 110 + 21（網路號） + 8（主機）
D類地址： 1110 + 28（組播地址）
E類地址： 1111 + 28（保留）
地址塊中第一和最後一個地址通常不使用

子網定址 保留一些剩餘主機號進一步用於站點內分配。該站點可能將基礎地址中的主機進一步分為子網號和主機號

子網掩碼 用於區分多個IP地址是否在同一個網路內，IP地址和子網掩碼作與操作，如果得到的值相同，那麼這兩臺主機就可以直接通訊，如果不同，則會發往預設閘道器，由其負責路由轉發

分層路由研究，將網路拓撲排序位一棵樹，這樣既可以使每個路由器的路由表都相對較小，同時保持到所有目的地的最短路徑 —-圖 2-8右側樹

路由聚合 圖2-9

鏈路層

CSMA/CD：帶衝突檢測的載波偵聽多路訪問 – 檢測網路，並在網路空閒時傳送自己的幀，如果碰巧有其他站同時傳送，發生重疊的電訊號被檢測為一次碰撞。這種情況下每個站等待一個隨機的時間，然後再次嘗試傳送。這個時間量的選擇依據一個統一的概率分佈，隨後每個碰撞被檢測到的時間加倍，最終每個站都會找到機會發送或者在嘗試一定時間後超時

鏈路聚合：兩個或更多的介面被視為一個，通過冗餘或將資料分割到多個介面，提高效能並獲得更好的可靠性

乙太網通過使用PAUSE訊息實現流量控制 –鏈路層流量控制

分片僅用於目的地址為單播的幀

管理幀用於建立，維持，終止站和接入點之間的連線，也被用於確定是否採用加密，傳輸網路名稱（SSID和ESSID），支援哪種傳輸速率，以及採用的時間資料庫等

流量控制幀：RTS/CTS，一個站在傳送資料之前傳送一個RTS幀，如果接收方願意接收額外的流浪，就會響應一個CTS幀

幀聚合包括A-MSDU和A-MPDU，A-MSDU只包含一個FCS（幀檢驗序列），效率高，但是如果出錯，則需要重傳整個聚合幀，A-MPDU每個子幀含有自己的FCS，並且可以使用ACK確認，如果出錯只需要重傳出錯子幀就行

IP傳送的資料報如果比MTU（最大傳輸單元）大，則需要分片

地址解析協議

ARP 提供從IP地址到MAC地址的對映
RARP 提供從MAC地址到IP地址的對映

Internet協議

IP提供了一種盡力而為、無連線的資料報交付服務，任何可靠性必須由上層（傳輸層）提供
IP轉發：如果目的IP是直接相連的，IP資料報直接傳送（直接交付），如果不是，傳送到預設路由（間接交付）
主機與路由器處理IP資料報的區別在於：主機不轉發那些不是由他自己生成的資料報

移動IP：移動節點以固定的IP地址，實現跨越不同網段的漫遊功能。主要步驟是：有主機向移動節點發送IP資料包，移動節點的家代理截獲資料包，將包的目的地址與自己的移動繫結表中移動節點的家地址比較，若與其中任意地址相同，則家代理將資料包封裝，通過隧道傳送給移動節點的轉發地址，移動節點的當地代理收到該包去除封裝，傳送給移動節點，移動節點收到資料採用便準路由機制與主機建立連線

強主機模式：資料報中的目的IP地址與到達介面的IP地址匹配才接收
弱主機模式：資料包中的目的IP地址與到達的任何介面的任何本地地址匹配，則可以被任何介面接收

資料報的目的IP地址經過每跳時都不會改變，但是鏈路層封裝和鏈路層目重傳的地址每跳都會改變。主機和路由器使用轉發表和最長字首匹配演算法，以確定匹配的最好的條目來作為轉發路徑的下一跳

動態主機配置協議

在動態分配中，DHCP客戶機請求一個IP地址，伺服器從可用的地址池中選擇一個地址作為響應，這個地址池通常是為DHCP用途專門分配的一個連續的IP範圍，分配給主機的地址只在一段時間內有效，稱為租用期，客戶機可以請求續期，此時可以跳過第一個廣播階段

典型的DHCP交換：客戶機通過廣播發現一組伺服器和可提供的地址，它請求自己想獲得的地址，並接收到選定伺服器的確認 圖6-2

DHCP中繼代理可以將DHCP操作擴充套件到一個網段之外
DHCP快速確認可以快速配置可能頻繁改變其網路介面的主機（移動主機），它可以跳過offer和request，直接使用ACK響應DISCOVER訊息

PPPoe起始就是乙太網上的PPP,用於廣域網連線裝置是交換機或者網橋而不是路由器的情況下

防火牆和網路地址轉換

防火牆分為
包過濾防火牆 ：過濾丟棄一些網路流量，過濾器可以自己配置
代理防火牆 ：本質上是執行一個或多個應用層閘道器，能夠在應用層中繼兩個連線/關聯之間的流量，代理防火牆可以毫無破綻的偽裝成Internet上的真實伺服器，它可以偽裝傳送端。
閘道器 ：簡單來說就是連線兩個不同網路的裝置

主機本身不具有路由定址能力，要把所有IP資料包傳送到一個預設的中轉地址上進行轉發，這就是預設閘道器

代理防火牆最常見的兩種形式為HTTP代理防火牆和SOCKS代理防火牆
HTTP代理防火牆也成為web代理，只能用於HTTP和HTTPS協議，這種代理對於通過它訪問網站的使用者來說就像是web伺服器，對於所訪問的網站來說就像是web客戶端，一些web代理也經常被用作內容過濾器，基於“黑名單”來阻止使用者訪問某些web網站，隧道代理伺服器剛好相反，它能避免使用者被內容過濾器封阻

NAT ：允許在網際網路的不同地方重複使用相同的IP地址集的機制，NAT裝置將內部系統的地址空間和全球網際網路地址空間分隔開，所有進出流量均通過一臺NAT裝置，而只有這臺NAT裝置上才使用全球網際網路地址空間中的IP，NAT的廣泛使用帶來的問題就是IPv6的推廣受阻

普通情況下，網際網路主機不能訪問到位於NAT之後的主機（假設IP地址為10.0.0.3）提供的服務，NAT作為網際網路路由器它必須同意轉發目的IP地址為10.0.0.3傳入的流量，更重要的是網際網路的主機也無法識別這個IP，也無法路由到該IP。於是便需要用到埠轉發機制。

埠轉發：通過埠轉發，進入NAT的流量被轉發到其配置的目的地址處，通常需要用伺服器IP地址和埠號來配置這個靜態NAT

髮夾和NAT環回問題：兩臺位於NAT私有空間的主機間通訊，源地址是填NAT外部IP還是填寫自己的主機IP？通常是NAT外部IP
那麼如何不經過NAT實現兩臺NAT私有空間的主機間通訊呢？這就需要用到NAT穿越技術

Internet控制報文協議

ICMP控制報文協議與IP協議結合使用，以便提供與IP協議層配置和資料包處置相關的診斷和控制資訊，它既不是網路層協議也不是傳輸層協議，而是位於兩者之間（最常見的應用就是Ping程式）

ICMP報文可分為兩大類：有關資訊傳遞的ICMP也稱差錯報文，以及有關資訊採集和配置的ICMP稱為查詢或資訊類報文

傳入的資訊類ICMP報文請求被作業系統自動處理，而差錯類ICMP報文傳遞給使用者或傳輸層協議

ICMP差錯報文不會對某些報文進行響應（361頁），這樣作是為了限制生成所謂的廣播風暴

當傳入的資料報的目的應用程式還沒準備好接收它時，會生成一個埠不可達報文
加入一個路由器收到一個來自主機的資料報，並確定自身並不是主機將資料包投遞到目的地址的嚇一跳地址，於是路由器傳送一個重定向報文到主機，並將該報文傳送到正確的路由器

唯一儲存下來的廣泛使用的ICMP查詢/資訊類報文是回顯請求/應答報文，也就是Ping

UDP

它是不可靠的，不提供差錯糾正，佇列管理，重複消除， 流量控制， 擁塞控制，但它擁有差錯檢測（校驗和）

兩個完全不同的伺服器可以使用相同的埠號和IP地址，只要他們使用不同的傳輸協議

UDP校驗和是一個端到端的傳輸層校驗和，UDP的差錯檢測就是基於檢驗和的，由傳送方計算得到，最終的目的方校驗，這也就說明，UDP資料報的校驗和在傳輸過程中不會被修改，而IP資料報頭部中的校驗和，每一跳都會重新計算，因為其TTL欄位每次轉發都會減少

Teredo隧道為沒有其他IPv6選項的系統傳送IPv6資料報，方法是將IPv6資料報至於UDP/IPv4資料報的負載區裡

鏈路層通常對可傳輸的每個幀的最大長度有一個上限，所以IP分片和重組發生在IP層

分片的計算的例子 —–圖10-9
分片過後，標示符欄位（IP頭部中）被複制到每個分片，再結合分片偏移欄位就能將分片的UDP資料報重組，分片導致的一個問題是如果任何一個分片丟失，那麼整個資料報就丟失了

如果有很多個數據報都只到達了部分分片，這樣將導致這些分片都待在接收方快取中等待重組，這樣勢必會導致接收方快取用盡，於是IP層使用了計時器來處理這種情況
路徑MTU發現機制使用ICMP PTB訊息來確認一個路徑不引起分片的最大分組大小

IP資料包的每個分片都需要請求ARP
帶指定IP地址的端點優先順序比帶萬用字元的優先順序高
Local Adress本地地址，只有到達的資料報的目的地址和本地地址匹配的資料報才接收
Foreign Adress 外部地址，只有到達的資料報的源地址和外部地址匹配的資料報才接收

大多數UDP伺服器是迭代伺服器，每個UDP埠都有一個大小有限的佇列與之對應，到達的資料報按先後順序排在佇列中等待應用程式處理，然後UDP是不可靠的，它不提供流量控制，如果佇列滿了，那麼後續到達的資料報只是簡單的被丟棄。而同樣的問題也會發生在傳送方和接收方之間的路由器上，這種情況叫做擁塞，擁塞是非常嚴重的，因為它不止影響一對傳送法和接收方，所有經過該路由器的流量都會被影響。

TCP

ARQ：自動重複請求，當一個分組丟失或者有錯時，傳送方就接收不到接收方傳來的直接使用ACK，於是他就會重新發送分組視窗：傳送方已經注入，但還沒有完成確認的分組存在的集合
滑動視窗：在傳送方，記錄著哪些視窗已經被確認可釋放，哪些正在等待ACK， 哪些還不能被髮送，在接收方，記錄著哪些視窗已經被接收和確認，哪些是下一步期望的（已經分配記憶體來保護），以及哪些分組因為緩衝區滿而會被丟棄

流量控制分為基於速率的流量控制和基於視窗的流量控制
基於速率：給傳送方指定某個速率，同時確保速率永遠不能超過這個速率傳送
基於視窗：滑動視窗大小不固定，允許隨著時間而變動，視窗通告讓接收方通知傳送方使用多大的視窗，傳送方根據視窗通高作出調整，視窗通告往往會和ACK一起傳送，傳送方在收到確認後隨即調整視窗大小
然而就像前面所說的那樣，接收方和傳送方之間往往會存在中間路由，而那個既適合傳送方也適合接收方的速率很有可能並不適合中間路由，從而導致擁塞，這便需要 擁塞控制 來處理

TCP不會解讀位元組流中的位元組內容，它不知道正在交換的資料位元組是不是二進位制資料或者ASCII碼或者其他東西。所以TCP並不推薦使用緊急機制

TCP把要傳送的位元組流轉換成一組IP可以攜帶的分組（每個分組都是最佳大小，不分片），稱為組包。這些分組中包含序列號（每個分組第一個位元組在整個位元組流的偏移位置），這允許分組在傳送中是可變大小的，並允許重新組合，稱為重新組包
TCP傳給IP的塊稱為報文段

TCP使用的ACK是累計的，一個指示位元組號N的ACK，暗示著所有直到N的位元組已經被接收成功，但這同時頁出現一個問題，假設3， 4， 5三個資料報，接收方收到了3和5，但他並沒有收到4，於是它會等待接收4，才會傳送5的ACK，假如發生超時，則5也會被重傳，於是就需要用到 SACK ，SACK選擇確認選項，當亂序到達的資料報導致出現空洞時（上面例子中的4），如果使用了SACK選項，就可以幫助傳送方有效的進行重傳

TCP是一種面向連線的單播協議，服務模型是位元組流，並且需要對連線狀態進行管理

三次握手和四次揮手 圖13-1
同時開啟和同時關閉 圖13-3和13-4

初始序列號會根據時間而改變，這就保證了每個連線都有不同的初始序列號

一條連線的兩個方向的路徑最大傳輸單元是不同的
分組層路徑最大傳輸單元發現：—–436-437頁

TCP狀態轉換圖 圖13-8

TIME_WAIT的2MSL：在本地與外地IP還有埠號都相同的情況下，2MSL狀態能夠將防止新的連線將前一個連線的延遲報文段解釋成自身資料，但是這都是建立在正常處於這種狀態的情況下的，如果主機崩潰並在MSL內重啟，之前延遲的資料依然會被認為是新連線的資料，所以在主機崩潰重啟到建立連線之前應等待MSL，這段時間稱為靜默時間。

可以傳送一條RTS報文段代替FIN來終止連線（非正常），這種情況下，任何排隊資料都會丟棄，並且接收方或說明發送方採用了終止的方式而不是正常方式關閉連線，

半開連線：在未告訴對端的情況下關閉或終止了連線，常常是因為主機崩潰

時間等待錯誤：圖13-10

處於ESTABLISHED（客戶端完成連線後的狀態）狀態的節點不能接收SYN報文段，處於LISTEN狀態（伺服器等待連線）的節點不能接收資料段

處於偵聽狀態下的節點維護著一個連線佇列，其中的連線三次握手已經完成，但並未被應用程式接受。

設定重傳超時（RTO）的值（465頁）
在測量RTT的過程中很容易出現問題，比如一個數據報超時重傳，那麼收到這個包的確認資訊對第一次的還是第二次的，這就是重傳二義性，可用Karn演算法解決，它規定收到重傳的確認資訊時進行RTT的測量，對該資料包之後的包採用退避策略，直到收到一個沒有重傳的資料包的確認資訊時才將RTT用於更新SRTT（平滑的RTT估計值）

快速重傳機制是基於接收端的反饋資訊來引發重傳的，當失序資料到達時，（接收端）重複ACK（收到亂序報文時發出的TCP報文）立即返回，不延時，同時重複ACK包中包含SACK資訊，利用該資訊即可獲知多個空缺，從而避免重傳正確接收的資料，當接收到3個重複ACK後，則傳送端立即重傳可能丟失的資料分組，而不必等待超時。不採用SACK，接收到有效ACK之前只能重傳一個報文段，而使用SACK，則ACK可以包含額外資訊，可以在每個RTT時間段內填補多個空缺。

有時，沒有出現數據丟失也可能引發重傳，稱為偽重傳，原因是偽超時，過早判定超時，原因可能是網路吞吐量過慢導致資料傳輸過慢或者ACK丟失或者ACK傳輸過慢。處理方法為，檢測演算法和響應演算法，前者判斷是否是真的超時，後者響應處理，用於減輕或撤銷超時帶來的影響
DSACK（重複SACK）用於判斷何時的重傳是不必要的
Eifel檢測演算法通過超時重傳後接收到的第一個ACK來判斷是否為偽超時，然後Eifel響應演算法處理偽超時，檢測演算法和響應演算法是相互獨立的，如果使用其他方法獲知發生了偽重傳，一樣可以使用Eifel響應演算法（但不針對遲偽超時）。
Eifel檢測演算法：當傳送一個重傳報文段後，儲存它的時間戳值，接收到相應的ACK後檢測它的時間戳回顯，如果小於之前儲存的值，則可判定該ACK對應的時前一個原始的報文段，判定發生了偽重傳。
Eifel響應演算法：485頁
F-RTO也是偽超時的檢測演算法：在超時重傳後，收到第一個ACK，修改TCP的行為，讓TCP傳送一個新的資料包，而非檢測ACK，然後再收到後一個ACK後，如果ACK有一個是重複的，則此次重傳正確，如果，兩個都不是重複ACK，則該重傳 是偽重傳
F-RTO和Eifel檢測演算法檢測的時偽超時，通過檢測第一個ACK來反映是否與原始報文段對應，DSACK檢測的是遲偽超時，基於超時引發的重傳所返回的ACK來判定

在互動式通訊中，例如使用ssh遠端連線伺服器，ssh會在遠端系統呼叫一個shell，對客戶端的輸入字元做出回顯。因此每個字元都會生成4個TCP資料段，就算使用稍帶延時確認也會需要3個數據段，有效的資料所佔比例甚微，處理這種小資料包多的連線Nagle演算法可以較好的解決，當一個TCP連線中有在傳資料，小的報文段就不能被髮送，直到所有在傳資料都收到了ACK，然後再將這些小資料整合到一個報文段傳送。演算法的精妙之出在於，它實現了自時鐘，ACK返回越快，資料傳輸也就越快
然而延時ACK和Nagle演算法結合使用往往會導致某種程度的死鎖，考慮，客戶端使用延時ACK方法傳送對一個伺服器的請求，而伺服器端開啟了Nagle演算法，伺服器端傳送一個全長資料包，然後準備傳送一個小包，但是由於全長資料包還沒有收到ACK，所以小包不能傳送，而客戶端由於使用了延時ACK，所以它需要等待兩個全長資料包的到達再回應一個ACK，於是便產生了死鎖，不過這種死鎖在ACK計時器超時後便會解鎖。

由於TCP的累計ACK結構，只有當視窗序列號等於左邊界時才不會被丟棄 圖15-10
當視窗大小（視窗大小隻視窗當前可用空間）變為0時，返回的ACK中帶有視窗通告，可以有效阻止傳送端繼續傳送，直到視窗大小恢復為非0，接收端會給傳送端傳輸一個視窗更新通告，通常不包含資料，為純ACK,不能保證其傳輸的可靠性，很有可能就會發生死鎖，為防止這種死鎖，傳送端會採用一種持續計時器，持續計時器會觸發視窗探測機制強制性的要求接收端返回一個包含一個視窗大小的ACK。

糊塗視窗綜合徵：當傳送端應用程序產生資料很慢、或接收端應用程序處理接收緩衝區資料很慢，或二者兼而有之；就會使應用程序間傳送的報文段很小，特別是有效載荷很小； 極端情況下，有效載荷可能只有1個位元組；傳輸開銷有40位元組(20位元組的IP頭+20位元組的TCP頭) 這種現象。應對方法是，接收端直到能夠接收一個全長報文段或者緩衝區有一半可用時才傳送視窗更新通告，對於傳送端，則不應傳送小的報文段，使用Nagle演算法控制，直到滿足下列任意條件時才可傳送報文段，1.全長報文段，2.資料段長度>=接收端通告過的最大的視窗的一半時，3.沒有在傳的未經確認的資料或者禁用Nagle演算法。

上面提到過，如果傳送端或接收端指定一個很小的緩衝，即使另一邊指定了一個大快取，效率一樣會很低，所以TCP協議棧中上層應用指定的快取大小會被忽視，有作業系統來指定一個較大的動態變化的計算值。

TCP擁塞控制

擁塞控制的基本方法就是，在有理由認為網路即將進入擁塞狀態（路由器丟包）時減緩TCP傳輸，難點就在於如何準確判斷何時減緩何時恢復
擁塞視窗和傳送端接收端視窗一樣，是反映網路傳輸能力的變數，所以傳送端視窗應等於接收端視窗和擁塞視窗的較小值
擁塞控制的經典演算法
TCP通過與接收方交換一個數據就能獲得接收端的視窗，但是擁塞視窗只能通過一次次的的增加發送速率直到包丟失才能獲取擁塞視窗，由於多個TCP連線共享同一個網路傳送路徑，如果直接以全速啟動會影響其他傳輸的效能，所以會採用特定的演算法來控制過快的啟動，穩定傳輸後，才會執行相應的演算法。
傳送方的擁塞控制是基於某種守恆來的，即傳送一個包就會收到一個ACK（這裡指數量，而不是次數，因為考慮會使用累計ACK），傳送方接收到一個ACK就表明可以傳送下一個資料包，這叫做自同步
前面提到的慢啟動在傳輸之初和重傳計時器檢測到丟包之後，以及長時間處於空閒狀態都會執行，因為網路傳輸能力未知。 慢啟動方法圖16-2
慢啟動：在接收到一個數據段的ACK後，擁塞視窗翻倍（初始為1），然後傳送資料也翻倍，變為傳送2個數據段，依次類推，k輪後，傳送端的傳送視窗就會變為2^k，擁塞視窗也是，然而大量的資料包的傳送總有一刻會導致網路出現問題，這個闕值就是慢啟動闕值，也是慢啟動階段到擁塞避免階段的轉折點

擁塞避免：由於慢啟動階段是指數型增長的，所以通常情況下，未超過慢啟動闕值和超過慢啟動闕值之間跨度往往很大，很有可能還可以增長但是不能以指數型增長，於是擁塞避免就可以較好的解決這個問題，慢啟動到達闕值後，轉為擁塞避免階段，擁塞避免階段以較小的波動增長,線性增長 圖16-3

Tahoe演算法：連線指出處於慢啟動階段，監測到丟包則將擁塞視窗減小為初值並且重新進入慢啟動狀態，改進方法是，如果是因為重複ACK引起的丟包，引發快速重傳，則將擁塞視窗改為上一步的大小。
標準TCP(Reno)：在TCP建立連線之初處於慢啟動階段，慢啟動闕值通常取較大值至少為接收端通知的視窗大小，接收到一個好的ACK則會更新擁塞視窗大小（前面講的慢啟動階段轉擁塞控制階段，臨界點就是闕值），當收到3次重複ACK，則證明網路上存在丟包問題，當前網路狀況不能承載當前這麼多的網路流量，如果不減少擁塞視窗，則網路流量繼續按當前這麼多來通訊，則很可能會再次導致丟包，則將慢啟動闕值減小為當前傳送端視窗大小的一半（不低於2個全長資料段，這一步可能增加也可能減少闕值），然後進入快速恢復，當接收到一個好的ACK，則擁塞視窗重設為當前闕值（收縮）
快速恢復：快速恢復演算法，先啟動快速重傳演算法，快速重傳演算法則會先將擁塞視窗減為一半，因為收到了3個重複的ACK，所以至少可以證明3個數據都是被收到了的，只是可能存在上面提到過的失序造成漏洞，所以擁塞視窗變為闕值+3SMSS（此時闕值已經被減半），每收到一個重複的ACK，則證明之前傳送的資料都是收到了的，證明當前網路可以承受當前網路流量，則試探性的將擁塞視窗暫時加一（臨時膨脹），退出條件是收到一個非重複的ACK。（這裡收到的3個重複的ACK，以及後來收到的重複ACK，都是之前丟包的那段時間傳送的資料包）

NewReno：當處於快速恢復階段時，如果接收到一個非重複ACK，就會停止快速恢復，轉而進行正常的擁塞視窗更新，即未發生快速重傳之前的更新方式，然而很多時候都會出現多個數據包丟失，如果只收到了一個ACK就停止，並將其減少到闕值，那麼可能導致，在重傳計時器超時之前，傳輸通道都處於區域性空閒狀態（因為講道理的話，既然丟失的資料包都沒有完全傳輸成功，那麼擁塞視窗的膨脹就應該繼續，那麼如果減少擁塞視窗，傳輸的資料勢必就會減少，就會導致傳輸通道沒有完全利用起來）。於是NewReno演算法做出了改進，它記錄了上一次傳輸視窗傳輸的資料的最高序列號，在未收到該序列號的資料包對應的ACK之前都不停止快速恢復。

選擇確認機制的擁塞控制：採用SACK後，傳送端可以知道，漏洞有哪些，於是可以即時的重傳丟失的資料，但是如果不考慮擁塞控制，如果需要重傳的資料太多（快速重傳的優勢就是可以在每個RTT時間內填補多個漏洞）則很有可能削弱擁塞控制的效果。於是TCP還負責記錄傳送端注入網路的資料量，如果擁塞視窗大於這個資料量，且差值大於一個傳送端最大資料段，則傳送端可以繼續傳送。

速率減半：在快速重傳結束後，擁塞視窗減半，在傳送新資料之前至少可以接收一半的已傳送資料的ACK，我們不希望在前一半時間內一直等待ACK，後一半時間才傳送資料，所以就要用到速率減半。基本思想是在接收到兩個重複的ACK後就傳送一個新資料，這樣資料傳送會比較均衡。

擁塞視窗校驗：在傳送端長時間暫停下（可能由於本來就沒有資料需要傳送，或其他原因），之前維護的擁塞視窗大小可能不能反映當前網路狀況。擁塞視窗校驗的基本思想是，如果距離上次傳送時間超過一次RTO,則更新闕值為max（當前闕值， 3/4 * 當前擁塞視窗大小），沒經過一個空閒的RTT，則將擁塞視窗減少為一半。我們注意到這並沒有減少闕值，而只是減少了擁塞視窗的大小，這是因為長時間暫停後傳送方通常會進入慢啟動階段。

當一個TCP關閉時，需要儲存RTT測量值，擁塞視窗大小，以及闕值，當相同主機間建立新連線時，該資訊就可以拿來用。

TCP友好性：多個TCP共享頻寬資源時，他們並非均勻的共享，而是根據連線引數，環境變數（丟包率，RTT）來加權平均。

基於延遲的擁塞控制演算法
vegas演算法：首先估算一定時間內網路能夠傳輸的資料量，然後與實際的傳輸能力相比較，若本該傳輸的資料沒有被傳輸，那麼就有可能是被鏈路上某個路由器掛起，如果持續發生這種情況，則減小發送端的傳送速率。
FAST演算法：FAST演算法原理上與vegas演算法一直，但他的特性是它能應對高速網路環境，高速網路環境中延遲與闕值差距較大，它會根據差距調整增長或減緩的速率的增量（差距較大則讓他進行較快的增長，反之亦然）

TCP保活機制

雙方建立互動的連線，但是並不是一直存在資料互動，有些連線會在資料互動完畢後，主動釋放連線，而有些不會，那麼在長時間無資料互動的時間段內，互動雙方都有可能出現掉電、宕機、異常重啟等各種意外，當這些意外發生之後，這些TCP連線並未來得及正常釋放，那麼，連線的另一方並不知道對端的情況，它會一直維護這個連線，長時間的積累會導致非常多的半開啟連線，造成端系統資源的消耗和浪費，為了解決這個問題，在傳輸層可以利用TCP的保活報文來實現。

傳送端（開啟了保活功能）向接收端傳送一個保活探測報文，如果傳送端沒有收到響應，經過一個提前設定的保活時間間隔，繼續傳送，如果達到了提前設定的保活探測次數，則對方主機被判定為不可達，斷開連線。探測以及響應報文都不包含任何有效資料，當他們丟失時也不進行重傳