第一章 概述
- 鏈路層， 有時也稱作數據鏈路層或網絡接口層
- TCP(傳輸控制協議)爲兩臺主機提供高可靠性的數據通信。它所做的工作包括把應用程序交給它的數據分成合適的小塊交給下面的網絡層，確認接收到的分組，設置發送最後確認分組的超時時鐘等。UDP則爲應用層提供一種非常簡單的服務。它只是把稱作數據包的分組從一臺主機發送到另一臺主機，但並不在保證該數據報能到達另一端。任何必需的可靠性由應用層來提供.
- 一個互連網就是一組通過相同協議族互連在一起的網絡。
- 構造互連網最簡單的方法是把兩個或多個網絡通過路由器進行連接。
- 路由器的好處是爲不同類型的物理網絡提供連接：以太網、令牌環網、點對點的鏈接和FDDI（光纖分佈式數據接口）等等。
- 在TCP/IP協議族中，網絡層 IP提供的是一種不可靠的服務。也就是說，它只是儘可能快地把分組從源結點送到目的結點，但是並不提供任何可靠性保證。而另一方面， TCP在不可靠的IP層上提供了一個可靠的運輸層。爲了提供這種可靠的服務， T C P採用了超時重傳、發送和接收端到端的確認分組等機制。由此可見，運輸層和網絡層分別負責不同的功能。
- 連接網絡的另一個途徑是使用網橋,網橋是在鏈路層上對網絡進行互連，而路由器則是在網絡層上對網絡進行互連。
- 由於互聯網上的每個接口必須有一個唯一的 IP地址，因此必須要有一個管理機構爲接入互聯網的網絡分配 I P地址。這個管理機構就是互聯網絡信息中心（ Internet Network Information Centre），稱作InterNIC。 InterNIC只分配網絡號。
- 有三類I P地址：單播地址（目的爲單個主機） 、廣播地址（目的端爲給定網絡上的所有主機）以及多播地址。
- 封裝 當應用程序用 TCP傳送數據時，數據被送入協議棧中，然後逐個通過每一層直到被當作一串比特流送入網絡。其中每一層對收到的數據都要增加一些首部信息（有時還要增加尾部信息(以太網幀會加尾部)） T C P傳給I P的數據單元稱作 T C P報文段或簡稱爲 T C P段（ TCP segment）。 I P傳給網絡接口層的數據單元稱作 I P數據報(IP datagram)。通過以太網傳輸的比特流稱作幀(Frame )
- 以太網數據幀的物理特性是其長度必須在 46～1500字節之間
- I P必須在生成的 I P首部中加入某種標識，以表明數據屬於哪一層。爲此， I P在首部中存入一個長度爲8 bit的數值，稱作協議域。 1表示爲ICMP協議， 2表示爲ICMP協議， 6表示爲TCP協議， 17表示爲UDP協議。
- 運輸層協議在生成報文首部時要存入一個應用程序的標識符。 T C P和U D P都用一個1 6 b i t的端口號來表示不同的應用程序。TCP和UDP把源端口號和目的端口號分別存入報文首部中。
- 當使用 TCP和UDP提供相同的服務時，一般選擇相同的端口號
第二章 鏈路層
- 鏈路層主要有三個目的
- 爲IP模塊發送和接收I P數據報
- 爲ARP模塊發送 ARP請求和接收 ARP應答;
- 爲RARP發送RARP請求和接收RARP應答
- 它採用一種稱作 CSMA / CD的媒體接入方法，其意思是帶衝突檢測的載波偵聽多路接入
- 以太網幀
- 目的地址(6字節)
- 原地址(6字節)
- 類型字段(2個字節)
- 數據(46 ~ 1500)
- CRC CRC字段用於幀內後續字節差錯的循環冗餘碼檢驗（檢驗和） (它也被稱爲 FCS或幀檢驗序列） 。
- 大多數的產品都支持環回接口（ Loopback Interface），以允許運行在同一臺主機上的客戶程序和服務器程序通過 TCP / IP進行通信。 A類網絡號 127就是爲環回接口預留的。根據慣例，大多數系統把 I P地址127.0.0.1分配給這個接口，並命名爲 localhost。一個傳給環回接口的 IP數據報不能在任何網絡上出現。
- 最大傳輸單元MTU
- 以太網數據幀1500字節
第三章 IP:網際協議
-
許多剛開始接觸 TCP/IP的人對IP提供不可靠、無連接的數據報傳送服務感到很奇怪。
- 不可靠（ unreliable）的意思是它不能保證 IP數據報能成功地到達目的地。 IP僅提供最好的傳輸服務。如果發生某種錯誤時，如某個路由器暫時用完了緩衝區， I P有一個簡單的錯誤處理算法：丟棄該數據報，然後發送 ICMP消息報給信源端。任何要求的可靠性必須由上層來提供（如TCP）。
- 無連接（ connectionless）這個術語的意思是 IP並不維護任何關於後續數據報的狀態信息。每個數據報的處理是相互獨立的。這也說明， IP數據報可以不按發送順序接收。如果一信源向相同的信宿發送兩個連續的數據報（先是 A，然後是 B），每個數據報都是獨立地進行路由選擇，可能選擇不同的路線，因此 B可能在A到達之前先到達。
-
網絡字節序(大端)
- 4個字節的32 bit值以下面的次序傳輸：首先是 0～7 bit，其次8～15 bit，然後1 6～23 bit，最後是24~31 bit。這種傳輸次序稱作 big endian字節序。由於T C P / I P首部中所有的二進制整數在網絡中傳輸時都要求以這種次序，因此它又稱作網絡字節序。以其他形式存儲二進制整數。
的機器，如little endian格式，則必須在傳輸數據之前把首部轉換成網絡字節序
- 4個字節的32 bit值以下面的次序傳輸：首先是 0～7 bit，其次8～15 bit，然後1 6～23 bit，最後是24~31 bit。這種傳輸次序稱作 big endian字節序。由於T C P / I P首部中所有的二進制整數在網絡中傳輸時都要求以這種次序，因此它又稱作網絡字節序。以其他形式存儲二進制整數。
-
IP首部
- 普通的IP首部長爲20個字節。
![在這裏插入圖片描述]()
協議版本號(IPv4,IPv6)- 4位首部長度
- 首部佔32bit字的數目。2^4(0 ~ 15) 15 * 4字節。所以首部最長60個字節。普通IP數據包字段的值是5. 5 * 4也就是20個字節。
- TOS字段包含一個3bit的優先權子字段(已忽略)，4bit的TOS子字段和1bit未用位但必須置0.
- 4bit的Tos分別代表,最小時延，最大吞吐量，最高可靠性和最小費用。
- 4bit只能置其中1bit.
Telnet和Rlogin這兩個交互應用要求最小的傳輸時延，因爲人們主要用它們來傳輸少量的
交互數據 - 總長度字段(16位)
- 總長度字段是指整個IP數據包的長度 。由於該字段長16bit,所以IP數據包長度可達65535。當數據包本分片時，該字段的值也隨着變化。利用首部長度字段和總長度字段，就可以知道 I P數據報中數據內容的起始位置和長度。
- 標識字段
- 唯一地標識主機發送的每一份數據報。通常每發送一份報文它的值就會加1
- TTL(time-to-live)
- 生存時間字段設置了數據包可以經過的最多路由器數。它指定了數據包的生存時間。TTL初始值由源主機設置(通常爲32或64)，一旦經過一個處理它的路由器，它的值就減去1。當該字段的值爲0時,數據包就被丟棄，併發送ICMP報文通知 源主機。
- 協議字段
- 用來對數據報進行分用。根據它可以識別是哪個協議向 IP傳送數據。
- 首部檢驗和字段
- 首部檢驗和字段是根據 I P首部計算的檢驗和碼。它不對首部後面的數據進行計算。 ICMP、IGMP、 UDP和TCP在它們各自的首部中均含有同時覆蓋首部和數據檢驗和碼。
爲了計算一份數據報的 I P檢驗和，首先把檢驗和字段置爲 0。然後，對首部中每個 16 bit 進行二進制反碼求和（整個首部看成是由一串 16 bit的字組成） ，結果存在檢驗和字段中。當收到一份 I P數據報後，同樣對首部中每個 16 bit進行二進制反碼的求和。由於接收方在計算過程中包含了發送方存在首部中的檢驗和，因此，如果首部在傳輸過程中沒有發生任何差錯，那麼接收方計算的結果應該爲全1。如果結果不是全 1（即檢驗和錯誤），那麼I P就丟棄收到的
數據報。但是不生成差錯報文，由上層去發現丟失的數據報並進行重傳。ICMP、IGMP、 UDP和TCP都採用相同的檢驗和算法
- 每一份 IP數據報都包含源 IP地址和目的 IP地址
-
IP 路由選擇
- 從概念上說， I P路由選擇是簡單的，特別對於主機來說。如果目的主機與源主機直接相連（如點對點鏈路）或都在一個共享網絡上（以太網或令牌環網），那麼I P數據報就直接送到目的主機上。否則，主機把數據報發往一默認的路由器上，由路由器來轉發該數據報。大多數的主機都是採用這種簡單機制
- I P層在內存中有一個路由表。當收到一份數據報並進行發送時，它都要對該表搜索一次。當數據報來自某個網絡接口時， I P首先檢查目的I P地址是否爲本機的 I P地址之一或者I P廣播地址。如果確實是這樣，數據報就被送到由 I P首部協議字段所指定的協議模塊進行處理。
- 如果數據報的目的不是這些地址，那麼（1）如果 I P層被設置爲路由器的功能，那麼就對數據報進行轉發
（也就是說，像下面對待發出的數據報一樣處理）；否則（2）數據報被丟棄。- 目的I P地址。它既可以是一個完整的主機地址，也可以是一個網絡地址，由該表目中的標誌字段來指定（如下所述）。主機地址有一個非0的主機號（見圖1 - 5），以指定某一特定的主機，而網絡地址中的主機號爲0，以指定網絡中的所有主機（如以太網，令牌環網）。
- 下一站（或下一跳）路由器（ next-hop router）的I P地址，或者有直接連接的網絡 I P地址。下一站路由器是指一個在直接相連網絡上的路由器，通過它可以轉發數據報。下一站路由器不是最終的目的，但是它可以把傳送給它的數據報轉發到最終目的。
- 標誌。其中一個標誌指明目的 I P地址是網絡地址還是主機地址，另一個標誌指明下一站路由器是否爲真正的下一站路由器，還是一個直接相連的接口（我們將在 9 . 2節中詳細介紹這些標誌） 。
- 爲數據報的傳輸指定一個網絡接口。
- I P路由選擇是逐跳地（ hop - by - hop）進行的。從這個路由表信息可以看出， IP並不知道到達任何目的的完整路徑（當然，除了那些與主機直接相連的目的）。所有的IP路由選擇只爲數據報傳輸提供下一站路由器的 IP地址。它假定下一站路由器比發送數據報的主機更接近目的，而且下一站路由器與該主機是直接相連的。
- I P路由選擇主要完成以下這些功能
- 搜索路由表，尋找能與目的 I P地址完全匹配的表目（網絡號和主機號都要匹配）。如果找到，則把報文發送給該表目指定的下一站路由器或直接連接的網絡接口（取決於標誌字段的值）。
- 搜索路由表，尋找能與目的網絡號相匹配的表目。如果找到，則把報文發送給該表目指定的下一站路由器或直接連接的網絡接口（取決於標誌字段的值）。
- 搜索路由表，尋找標爲“默認（ d e f a u l t）”的表目。如果找到，則把報文發送給該表目指定的下一站路由器。
*爲一個網絡指定一個路由器，而不必爲每個主機指定一個路由器，這是 I P路由選擇機制的另一個基本特性。這樣做可以極大地縮小路由表的規模，比如 Internet上的路由器有隻有幾千個表目，而不會是超過 100萬個表目
第11章 UDP:用戶數據包協議
引言
- UDP是一個簡單的面向數據報的運輸層協議：進程的每個輸出操作都正好產生一個 UDP數據報，並組裝成一份待發送的IP數據報
![在這裏插入圖片描述]()
- 應用程序必須關心 IP數據報的長度。如果它超過網絡的 MTU，那麼就要對IP數據報進行分片。如果需要，源端到目的端之間的每個網絡都要進行分片，並不只是發送端主機連接第一個網絡才這樣做
UDP首部
- 端口號表示發送進程和接收進程
- UDP長度字段指的是UDP首部和UDP數據的字節長度
- 該字段的最小值爲 8字節（發送一份0字節的UDP數據報是OK）
- 這個UDP長度是有冗餘的。 IP數據報長度指的是數據報全長（圖3 - 1），因此UDP數據報長度是全長減去IP首部的長度
- UDP檢驗和
- UDP檢驗和覆蓋UDP首部和UDP數據。回想IP首部的檢驗和，它只覆蓋IP的首部 — 並不覆蓋IP數據報中的任何數據。
- UDP和TCP在首部中都有覆蓋它們首部和數據的檢驗和。 UDP的檢驗和是可選的，而TCP的檢驗和是必需的
- 儘管U D P檢驗和的基本計算方法與我們在 3 . 2節中描述的 I P首部檢驗和計算方法相類似（16 bit字的二進制反碼和），但是它們之間存在不同的地方。
- 首先， UDP數據報的長度可以爲奇數字節，但是檢驗和算法是把若干個 16 bit字相加。解決方法是必要時在最後增加填充字節0，這只是爲了檢驗和的計算（也就是說，可能增加的填充字節不被傳送）**
- 其次，UDP數據報和TCP段都包含一個1 2字節長的僞首部，它是爲了計算檢驗和而設置的。僞首部包含 IP首部一些字段。其目的是讓 UDP兩次檢查數據是否已經正確到達目的地
IP分片
-
物理網絡層一般要限制每次發送數據幀的最大長度，任何時候I P層接收到一份要發送的 I P數據報時，它要判斷向本地哪個接口發送數據（選路），並查詢該接口獲得其MTU。IP把MTU與數據報長度進行比較，如果需要則進行分片。分片可以發生在原始發送端主機上，也可以發生在中間路由器上
-
把一份IP數據報分片以後，只有到達目的地才進行重新組裝
-
重新組裝由目的端的IP層來完成，其目的是使分片和重新組裝過程對運輸層（ TCP和UDP）是透明的，
-
除了某些可能的越級操作外。已經分片過的數據報有可能會再次進行分片（可能不止一次）。IP首部中包含的數據爲分片和重新組裝提供了足夠的信息
-
當IP數據報被分片後，每一片都成爲一個分組，具有自己的 I P首部，並在選擇路由時與其他分組獨立。這樣，當數據報的這些片到達目的端時有可能會失序，但是在 IP首部中有足夠的信息讓接收端能正確組裝這些數據報片
-
下面這些字段用於分片過程
- 標識字段
- 對於發送端發送的每份IP數據報來說，其標識字段都包含一個唯一值。該值在數據報分片時被複制到每個片中
- 標誌字段
- 標誌字段用其中一個比特來表示“更多的片”。除了最後一片外，其他每個組成數據報的片都要把該比特置 1
- 標誌字段中有一個比特稱作“不分片”位。如果將這一比特置 1，IP將不對數據報進行分片
- 片偏移字段
- 片偏移字段指的是該片偏移原始數據報開始處的位置。另外，當數據報被分片後，每個片的總長度值要改爲該片的長度值
- 標識字段
-
儘管I P分片過程看起來是透明的，但有一點讓人不想使用它：即使只丟失一片數據也要重傳整個數據報。爲什麼會發生這種情況呢？因爲 I P層本身沒有超時重傳的機制——由更高層來負責超時和重傳（T C P有超時和重傳機制，但U D P沒有。一些UDP應用程序本身也執行超時和重傳）。當來自TCP報文段的某一片丟失後，TCP在超時後會重發整個TCP報文段，該報文段對應於一份IP數據報。沒有辦法只重傳數據報中的一個數據報片。事實上，如果對數據報分片的
是中間路由器，而不是起始端系統，那麼起始端系統就無法知道數據報是如何被分片的 -
使用UDP很容易導致IP分片（在後面我們將看到，TCP試圖避免分片，但對於應用程序來說幾乎不可能強迫 TCP發送一個需要進行分片的長報文段）
一個分片的例子
-
假定 IP首部爲20字節，UDP首部爲8字節。我們分別以數據長度爲1471, 1472, 1473和1 4 7 4字節運行sock程序。最後兩次應該發生分片
![在這裏插入圖片描述]()
-
但是對應於寫1473字節的I P數據報長度爲1501，就必須進行分片（第3行和第4行）。同理，寫1474字節產生的數據報長度爲1502，它也需要進行分片（第5行和第6行）。
-
IP首部的標識字段
- 首先，frag 26304（第3行和第4行）和frag 26313 （第5行和第6行）指的是IP首部中標識字段的值
-
UDP長度字段
- 分片信息中的下一個數字，即第 3行中位於冒號和@號之間的1480，是除IP首部外的片長
在分片時，除最後一片外，其他每一片中的數據部分（除 IP首部外的其餘部分）必須是 8字節的整數倍
- 分片信息中的下一個數字，即第 3行中位於冒號和@號之間的1480，是除IP首部外的片長
-
片偏移字段
- 位於@符號後的數字是從數據報開始處計算的片偏移值。
- 兩份數據報第1片的偏移值均爲0(第3行和第5行)，第2片的偏移值爲1480（第4行和第6行）
-
任何運輸層首部只出現在第1片數據中,所以其他分片是沒有UDP首部，也就是沒有端口號
![在這裏插入圖片描述]()
-
術語解釋
- IP數據報是指IP層端到端的傳輸單元（在分片之前和重新組裝之後），分組是指在IP層和鏈路層之間傳送的數據單元。一個分組可以是一個完整的 IP數據報，也可以是IP數據報的一個分片。
ICMP不可達差錯（需要分片)
- 發生ICMP不可達差錯的另一種情況是，當路由器收到一份需要分片的數據報，而在 IP首部又設置了不分片（DF）的標誌比特。如果某個程序需要判斷到達目的端的路途中最小 MTU是多少 — 稱作路徑MTU發現機制（2 . 9節），那麼這個差錯就可以被該程序使用
用Traceroute確定路徑MTU
- 要做的是發送分組，並設置“不分片”標誌比特。發送的第一個分組的長度正好與出口 MTU相等，每次收到ICMP“不能分片”差錯時（在上一節討論的）就減小分組的長度。
最大UDP數據報長度
- 理論上，IP數據報的最大長度是65535字節，這是由IP首部（圖3 - 1）16比特總長度字段所限制的。去除20字節的IP首部和8個字節的UDP首部，UDP數據報中用戶數據的最長長度爲65507字節。
- 如果接收到的數據報長度大於應用程序所能處理的長度，那麼會發生什麼情況呢？不幸的是，該問題的答案取決於編程接口和實現
- 在討論TCP時，我們發現它爲應用程序提供連續的字節流，而沒有任何信息邊界。 TCP以應用程序讀操作時所要求的長度來傳送數據，因此，在這個接口下，不會發生數據丟失。
UDP輸入隊列
- 通常程序所使用的每個 UDP端口都與一個有限大小的輸入隊列相聯繫。這意味着，來自不同客戶的差不多同時到達的請求將由 UDP自動排隊。接收到的 UDP數據報以其接收順序交給應用程序（在應用程序要求交送下一個數據報時）
- 然而，排隊溢出造成內核中的 UDP模塊丟棄數據報的可能性是存在的。
第12章 廣播和多播
引言
- 有三種 IP地址：單播地址、廣播地址和多播地址
- 廣播和多播僅應用於 UDP
第17章 TCP:傳輸控制協議
TCP提供一種面向連接的，可靠的字節流服務
- 面向連接意味着兩個使用 TCP的應用（通常是一個客戶和一個服務器）在彼此交換數據之前必須先建立一個 TCP連接
- TCP通過下列方式體用可靠性
- 應用數據被分割成TCP認爲最適合發送的數據塊,由 TCP傳遞給IP的信息單位稱爲報文段或段
- 當TCP發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。(超時及重傳策略)。
- 當TCP收到發自TCP連接另一端的數據，它將發送一個確認。這個確認不是立即發送，通常將推遲幾分之一秒。
- TCP將保持它首部和數據的檢驗和
- 既然TCP報文段作爲IP數據報來傳輸，而IP數據報的到達可能會失序，因此 TCP報文段的到達也可能會失序。如果必要， TCP將對收到的數據進行重新排序，將收到的數據以正確的順序交給應用層。
- 既然IP數據報會發生重複，TCP的接收端必須丟棄重複的數據。
- TCP還能提供流量控制 TCP的接收端只允許另一端發送接收端緩衝區所能接納的數據。這將防止較快主機致使較慢主機的緩衝區溢出。
- 兩個應用程序通過T C P連接交換8 bit字節構成的字節流。T C P不在字節流中插入記錄標識符。我們將這稱爲字節流服務（byte stream service）應用程序對數據的發送和接收是沒有邊界限制的 。
TCP的首部
TCP數據被封裝在一個IP數據包中
-
TCP包首部
-
![在這裏插入圖片描述]()
-
源端口和目的端口
- 每個TCP段都包含源端和目的端的端口號，用於尋找發端和收端應用進程。這兩個值加上IP首部中的源端I P地址和目的端IP地址唯一確定一個T C P連接
-
序號和確認號
- 序號用來標識從TCP發端向TCP收端發送的數據字節流，它表示在這個報文段中的的第一個字節的序號。TCP用序號對每個字節進行計數。
- 當建立一個新的連接時， SYN標誌變1。序號字段包含由這個主機選擇的該連接的初始序號ISN（Initial Sequence Number）。該主機要發送數據的第一個字節序號爲這個 ISN加1，因爲SYN標誌消耗了一個序號（將在下章詳細介紹如何建立和終止連接，屆時我們將看到 F I N標誌也要佔用一個序號）
- 既然每個傳輸的字節都被計數，確認序號包含發送確認的一端所期望收到的下一個序號。因此，確認序號應當是上次已成功收到數據字節序號加 1。只有ACK標誌（下面介紹）爲 1時確認序號字段纔有效。
- TCP爲應用層提供全雙工服務。這意味數據能在兩個方向上獨立地進行傳輸。因此，連接的每一端必須保持每個方向上的傳輸數據序號。
- 我們說TCP缺少選擇確認是因爲 T C P首部中的確認序號表示發方已成功收到字節，但還不包含確認序號所指的字節。當前還無法對數據流中選定的部分進行確認。例如，如果1～1024字節已經成功收到，下一報文段中包含序號從 20 49～3072的字節，收端並不能確認這個新的報文段。它所能做的就是發回一個確認序號爲 1025的ACK。它也無法對一個報文段進行否認。例如，如果收到包含 1025～2048字節的報文段，但它的檢驗和錯， TCP接收端所能做的就是發回一個確認序號爲 1025的ACK
-
4位首部長度
- 首部長度給出首部中32 bit字的數目。需要這個值是因爲任選字段的長度是可變的。這個字段佔4 bit，因此TCP最多有6 0字節的首部。然而，沒有任選字段，正常的長度是 2 0字節。
-
6位保留位
-
6位標誌位
- 在TCP首部中有6個標誌比特。它們中的多個可同時被設置爲 1
- URG 緊急指針（u rgent pointer）有效（見20.8節）。
- ACK 確認序號有效。
- PSH 接收方應該儘快將這個報文段交給應用層。
- RST 重建連接。
- SYN 同步序號用來發起一個連接。這個標誌和下一個標誌將在第 1 8章介紹。
- FIN 發端完成發送任務。
- 在TCP首部中有6個標誌比特。它們中的多個可同時被設置爲 1
-
16位窗口大小
- TCP的流量控制由連接的每一端通過聲明的窗口大小來提供。窗口大小爲字節數，起始於確認序號字段指明的值，這個值是接收端正期望接收的字節。窗口大小是一個 16 bit字段，因而窗口大小最大爲 65535字節。
-
16位檢驗和
- 檢驗和覆蓋了整個的T C P報文段：T C P首部和T C P數據。這是一個強制性的字段，一定是由發端計算和存儲，並由收端進行驗證
-
16位緊急指針
- 只有當URG標誌置1時緊急指針纔有效。緊急指針是一個正的偏移量，和序號字段中的值相加表示緊急數據最後一個字節的序號
-
可選字段
- 最長報文大小，又稱爲 MSS (Maximum Segment Size)。每個連接方通常都在通信的第一個報文段（爲建立連接而設置 SYN標誌的那個段）中指明這個選項 。
-
TCP將用戶數據打包構成報文段；它發送數據後啓動一個定時器；另一端對收到的數據進行確認，對失序的數據重新排序，丟棄重複數據； TCP提供端到端的流量控制，並計算和驗證一個強制性的端到端檢驗和。
第18章 TCP連接的建立與終止
TCP三次握手抓包分析
| 發送端 | 標誌位 | seq | ack | 數據長度 | 狀態 |
|---|---|---|---|---|---|
| C | SYN | 2330448289 | 0 | 0 | SYN_SENT |
| S | SYN,ACK | 982412518 | 2330448290 | 0 | SYN_RCVD |
| C | ACK | 2330448290 | 982412519 | 0 | ESTABLISHED |
S收到ACK之後也會成爲ESTABLISHED狀態
- tls
| 發送端 | 標誌位 | seq | ack | 數據長度 |
|---|---|---|---|---|
| C | Client hello | 2330448290 | 982412519 | 134 |
| S | ACK,PSH | 982412519 | 2330448424 | |
| S | Server hello | 982412519 | 2330448424 | 1460 |
| C | ACK | 2330448424 | 982413979 |
- 建立一個連接需要三次握手，而終止一個連接要經過 4次握手。這由T C P的半關閉（half - close）造成的。既然一個TCP連接是全雙工（即數據在兩個方向上能同時傳遞），因此每個方向必須單獨地進行關閉。這原則就是當一方完成它的數據發送任務後就能發送一個 FIN來終止這個方向連接。當一端收到一個 FIN，它必須通知應用層另一端幾經終止了那個方向的數據傳送。發送FIN通常是應用層進行關閉的結果。
- 收到一個FIN只意味着在這一方向上沒有數據流動。一個 TCP連接在收到一個F I N後仍能發送數據。而這對利用半關閉的應用來說是可能的，儘管在實際應用中只有很少的 TCP應用程序這樣做.
TCP四次揮手抓包分析
| 發送端 | 標誌位 | seq | ack | 狀態 |
|---|---|---|---|---|
| C | FIN,ACK | 3514992616 | 218767418 | ESTABLISHED, FIN_WAIT_1 |
| S | ACK | 218767418 | 3514992617 | CLOSE_WAIT FIN_WAIT_2 |
| S | FIN,ACK | 218767418 | 3514992617 | LAST_ACK ,TIME_WAIT |
| C | ACK | 3514992617 | 218767419 | CLOSE |
爲什麼是三次握手四次揮手
-
三次握手可以防止已經失效的連接請求報文突然又傳輸到服務器端導致的服務器資源浪費
-
資源浪費觀點：引自《計算機網絡》釋疑與習題解答 謝希仁
- 如果只有兩次握手，當客戶端的SYN請求連接在網絡管道中阻塞，客戶端沒有接收到ACK報文，就會重新發送SYN，由於沒有第三次握手，服務器不清楚客戶端是否收到了自己發送的建立連接的ACK確認信號，所以每收到一個SYN就只能主動建立一個連接，這會造成什麼情況呢？如果客戶端的SYN阻塞了，重複發送多次SYN報文，那麼服務器在收到請求後就會建立多個冗餘的無效鏈接，造成不必要的資源浪費。即兩次握手會造成消息滯留情況下，服務器重複接受無用的連接請求SYN報文，而造成重複分配資源。
-
可靠性論斷：
- 另外一種是 如果想確定雙通道通暢，必須使用三個包的發送接收，也就是三次握手：“這個問題的本質是, 信道不可靠, 但是通信雙發需要就某個問題達成一致. 而要解決這個問題, 無論你在消息中包含什麼信息, 三次通信是理論上的最小值. 所以三次握手不是TCP本身的要求, 而是爲了滿足"在不可靠信道上可靠地傳輸信息"這一需求所導致的. 請注意這裏的本質需求,信道不可靠, 數據傳輸要可靠. 三次達到了, 那後面你想接着握手也好, 發數據也好, 跟進行可靠信息傳輸的需求就沒關係了. 因此,如果信道是可靠的, 即無論什麼時候發出消息, 對方一定能收到, 或者你不關心是否要保證對方收到你的消息, 那就能像UDP那樣直接發送消息就可以了.”三次是保證雙方互相明確對方能收能發的最低值。理論上講不論握手多少次都不能確認一條信道是“可靠”的，但通過3次握手可以至少確認它是“可用”的，再往上加握手次數不過是提高“它是可用的”這個結論的可信程度。另外Tcp的可靠傳輸更多的是靠重傳機制來保證的
-
初始序列號
- 三次握手的本質是爲了同步雙方的初始序列號：
- 爲了實現可靠數據傳輸， TCP 協議的通信雙方， 都必須維護一個序列號， 以標識發送出去的數據包中， 哪些是已經被對方收到的。 三次握手的過程即是通信雙方相互告知序列號起始值， 並確認對方已經收到了序列號起始值的必經步驟。如果只是兩次握手， 至多隻有連接發起方的起始序列號能被確認， 另一方選擇的序列號則得不到確認。TCP建立連接的握手，實質上就是建立一個雙向的可靠通信連接，一邊一個來回，每一邊都自帶超時重傳來確保可靠性(而不是靠握手的次數)。TCP的3次握手是優化的結果，其實它應該是4次握手，由於是從零開始的建立連接，因此將SYN的ACK以及被動打開的SYN合併成了一個SYN-ACK。握手的作用，旨在確定兩個雙向的初始序列號，TCP用序列號來編址傳輸的字節，由於是兩個方向的連接，所以需要兩個序列號，握手過程不傳輸任何字節，僅僅確定初始序列號。
-
最大報文長度
- 最大報文段長度（MSS）表示TCP傳往另一端的最大塊數據的長度。當一個連接建立時，連接的雙方都要通告各自的 MSS.
- 如果一方不接收來自另一方的 MSS值，則MSS就定爲默認值536字節（這個默認值允許20字節的IP首部和20字節的TCP首部以適合576字節I P數據報
- 當 TCP發送一個SYN時，或者是因爲一個本地應用進程想發起一個連接，或者是因爲另一端的主機收到了一個連接請求，它能將 MSS值設置爲外出接口上的 MTU長度減去固定的I P首部和T C P首部長度。對於一個以太網，MSS值可達1460字節。
-
TCP半關閉
- TCP提供了連接的一端在結束它的發送後還能接收來自另一端數據的能力。這就是所謂的半關閉
2MSL等待狀態
- TIME_WAIT狀態也稱爲2MSL等待狀態。每個具體TCP實現必須選擇一個報文段最大生存時間MSL（Maximum Segment Lifetime）,它是任何報文段被丟棄前在網絡內的最長時間。我們知道這個時間是有限的，因爲 TCP報文段以IP數據報在網絡內傳輸，而IP數據報則有限制其生存時間的TTL字段。
- 對一個具體實現所給定的 MSL值，處理的原則是：當 TCP執行一個主動關閉，併發回最後一個ACK，該連接必須在TIME_WAIT狀態停留的時間爲 2倍的MSL。這樣可讓TCP再次發送最後的A C K以防這個ACK丟失（另一端超時並重發最後的FIN）
- 這種2MSL等待的另一個結果是這個 TCP連接在2MSL等待期間，定義這個連接的插口（客戶的IP地址和端口號，服務器的 IP地址和端口號）不能再被使用。這個連接只能在 2MSL結束後才能再被使用。
- 在連接處於2MSL等待時，任何遲到的報文段將被丟棄。因爲處於 2 MSL等待的、由該插口對(socket pair)定義的連接在這段時間內不能被再用，因此當要建立一個有效的連接時，來自該連接的一個較早替身（ incarnation）的遲到報文段作爲新連接的一部分不可能不被曲解（一個連接由一個插口對來定義。一個連接的新的實例（ instance）稱爲該連接的替身）
- 客戶執行主動關閉並進入 TIME_WAIT是正常的。服務器通常執行被動關閉，不會進入TIME_ WAIT狀態。這暗示如果我們終止一個客戶程序，並立即重新啓動這個客戶程序，則這個新客戶程序將不能重用相同的本地端口。
TIME_WAIT狀態存在的理由：
-
盡最大努力可靠地實現TCP全雙工連接的終止
- 在進行關閉連接四次揮手協議時，最後的ACK是由主動關閉端發出的，如果這個最終的ACK丟失，服務器將重發最終的FIN，因此客戶端必須維護狀態信息允許它重發最終的ACK。如果不維持這個狀態信息，那麼客戶端將響應RST分節，服務器將此分節解釋成一個錯誤因而，要實現TCP全雙工連接的正常終止，必須處理終止序列四個分節中任何一個分節的丟失情況，主動關閉的客戶端必須維持狀態信息進入TIME_WAIT狀態。
-
允許老的重複分節在網絡中消逝
- TCP分節可能由於路由器異常而“迷途”，在迷途期間，TCP發送端可能因確認超時而重發這個分節，迷途的分節在路由器修復後也會被送到最終目的地，這個原來的迷途分節就稱爲lost duplicate。
- 在關閉一個TCP連接後，馬上又重新建立起一個相同的IP地址和端口之間的TCP連接，後一個連接被稱爲前一個連接的化身（incarnation)，那麼有可能出現這種情況，前一個連接的迷途重複分組在前一個連接終止後出現，從而被誤解成從屬於新的化身。爲了避免這個情況，TCP不允許處於TIME_WAIT狀態的連接啓動一個新的化身，因爲TIME_WAIT狀態持續2MSL，就可以保證當成功建立一個TCP連接的時候，來自連接先前化身的重複分組已經在網絡中消逝。
平靜時間的概念
- 對於來自某個連接的較早替身的遲到報文段， 2MSL等待可防止將它解釋成使用相同插口對的新連接的一部分。但這隻有在處於 2 MSL等待連接中的主機處於正常工作狀態時纔有效。如果使用處於2 MSL等待端口的主機出現故障，它會在 MSL秒內重新啓動，並立即使用故障前仍處於2 M S L的插口對來建立一個新的連接嗎？如果是這樣，在故障前從這個連接發出而遲到的報文段會被錯誤地當作屬於重啓後新連接的報文段。無論如何選擇重啓後新連接的初始序號，都會發生這種情況。爲了防止這種情況，RFC 793指出TCP在重啓動後的MSL秒內不能建立任何連接。這就稱爲平靜時間(quiet time)。
異常終止
-
異常終止一個連接對應用程序來說有兩個優點：（1）丟棄任何待發數據並立即發送復位報文段；（2）RST的接收方會區分另一端執行的是異常關閉還是正常關閉。應用程序使用的API必須提供產生異常關閉而不是正常關閉的手段。
-
一個TCP連接由一個4元組唯一確定：本地 IP地址、本地端口號、遠端 IP地址和遠端端口號。
第19章 TCP的交互數據流
- 引言
- 一些有關TCP通信量的研究如[Caceres et al. 1991]發現，如果按照分組數量計算，約有一半的TCP報文段包含成塊數據（如 FTP、電子郵件和 Usenet新聞），另一半則包含交互數據（如Telnet和Rlogin）。如果按字節計算，則成塊數據與交互數據的比例約爲 90 %和10 %。這是因爲成塊數據的報文段基本上都是滿長度（ full - sized）的（通常爲512字節的用戶數據），而交互數據則小得多。
經受時延的確認
- 通常TCP在接收到數據時並不立即發送ACK；相反，它推遲發送，以便將 ACK與需要沿該方向發送的數據一起發送（有時稱這種現象爲數據捎帶ACK）。絕大多數實現採用的時延爲 200 ms，也就是說，TCP將以最大200 ms的時延等待是否有數據一起發送。
Nagle算法
- 該算法要求一個 TCP連接上最多隻能有一個未被確認的未完成的小分組，在該分組的確認到達之前不能發送其他的小分組。相反， TCP收集這些少量的分組，並在確認到來時以一個分組的方式發出去。該算法的優越之處在於它是自適應的：確認到達得越快，數據也就發送得越快。
小結
- 交互數據總是以小於最大報文段長度的分組發送,接收方使用經受時延的確認方法來判斷確認是否可被推遲發送，
以便與回送數據一起發送。
第20章 TCP的成塊數據流
引言
- 本章我們將介紹 TCP所使用的被稱爲滑動窗口協議的另一種形式的流量控制方法。該協議允許發送方在停止並等待確認前可以連續發送多個分組。由於發送方不必每發一個分組就停下來等待確認，因此該協議可以加速數據的傳輸
正常數據流
- 報文段7的A C K的序號之所以是2048而不是3073是由以下原因造成的：當一個分組到達時，它首先被設備中斷例程進行處理，然後放置到 IP的輸入隊列中。三個報文段 4、5和6依次到達並按接收順序放到 I P的輸入隊列。I P將按同樣順序將它們交給 TCP。當TCP處理報文段4時，該連接被標記爲產生一個經受時延的確認。 T C P處理下一報文段（5），由於TCP現在有兩個未完成的報文段需要確認，因此產生一個序號爲 2048的A C K（報文段7），並清除該連接產生經受時延的確認標誌。 TCP處理下一個報文段（ 6），而連接又被標誌爲產生一個經受時延的確認。在報文段9到來之前，由於時延定時器溢出，因此產生一個序號爲 3073的ACK（報文段8）。報文段8中的窗口大小爲3072表明在TCP的接收緩存中還有1024個字節的數據等待被應用程序讀取
- 通常使用的“隔一個報文段確認”的策略
- 注意到報文段7、14和1 6中的ACK確認了兩個收到的報文段是很重要的。使用 TCP的滑動窗口協議時，接收方不必確認每一個收到的分組。在 TCP中，ACK是累積的 — 它們表示接收方已經正確收到了一直到確認序號減 1的所有字節
- 發送方發送4個背靠背（back-to-back）的數據報文段去填充接收方的窗口，然後停下來等待一個ACK。接收方發送ACK（報文段8），但通告其窗口大小爲 0，這說明接收方已收到所有數據，但這些數據都在接收方的 TCP緩衝區，因爲應用程序還沒有機會讀取這些數據。另一個ACK（稱爲窗口更新）在17.4 ms後發送，表明接收方現在可以接收另外的 4096個字節的數據。雖然這看起來像一個 ACK，但由於它並不確認任何新數據，只是用來增加窗口的右邊沿，因此被稱爲窗口更新。
滑動窗口
- 滑動窗口示意圖
![在這裏插入圖片描述]()
- 我們知道窗口大小是與確認序號相對應的。發送方計算它的可用窗口，該窗口表明多少數據可以立即被髮送。
- 當接收方確認數據後，這個滑動窗口不時地向右移動。窗口兩個邊沿的相對運動增加或減少了窗口的大小。我們使用三個術語來描述窗口左右邊沿的運動：
- 稱窗口左邊沿向右邊沿靠近爲窗口合攏。這種現象發生在數據被髮送和確認時。
- 當窗口右邊沿向右移動時將允許發送更多的數據，我們稱之爲窗口張開。這種現象發生在另一端的接收進程讀取已經確認的數據並釋放了 TCP的接收緩存時
- 當右邊沿向左移動時，我們稱之爲窗口收縮。 Host Requirements RFC強烈建議不要使用這種方式。但TCP必須能夠在某一端產生這種情況時進行處理。第 2 2 . 3節給出了這樣的一個例子，一端希望向左移動右邊沿來收縮窗口，但沒能夠這樣做。
![在這裏插入圖片描述]()
- 因爲窗口的左邊沿受另一端發送的確認序號的控制，因此不可能向左邊移動。如果接收到一個指示窗口左邊沿向左移動的 ACK，則它被認爲是一個重複 ACK，並被丟棄。
- 如果左邊沿到達右邊沿，則稱其爲一個零窗口，此時發送方不能夠發送任何數據。
- 以該圖爲例可以總結如下幾點：
- 發送方不必發送一個全窗口大小的數據。
- 來自接收方的一個報文段確認數據並把窗口向右邊滑動。這是因爲窗口的大小是相對於確認序號的。
- 正如從報文段7到報文段8中變化的那樣，窗口的大小可以減小，但是窗口的右邊沿卻不能夠向左移動
- 接收方在發送一個A C K前不必等待窗口被填滿。在前面我們看到許多實現每收到兩個報文段就會發送一個ACK。
窗口大小
PUSH標誌
- 發送方使用該標誌通知接收方將所收到的數據全部提交給接收進程
慢啓動(slow start)
- 該算法通過觀察到新分組進入網絡的速率應該與另一端返回確認的速率相同而進行工作
- 慢啓動爲發送方的TCP增加了另一個窗口：擁塞窗口(congestion window)，記爲cwnd。
- 當與另一個網絡的主機建立 TCP連接時，擁塞窗口被初始化爲 1個報文段（即另一端通告的報文
段大小）。每收到一個ACK，擁塞窗口就增加一個報文段（ cwnd以字節爲單位，但是慢啓動以報文段大小爲單位進行增加） - 發送方取擁塞窗口與通告窗口中的最小值作爲發送上限。
- 擁塞窗口是發送方使用的流量控制，而通告窗口則是接收方使用的流量控制
發送方開始時發送一個報文段，然後等待 ACK。當收到該ACK時，擁塞窗口從1增加爲2，即可以發送兩個報文段。當收到這兩個報文段的 ACK時，擁塞窗口就增加爲4。這是一種指數增加的關係
- 當與另一個網絡的主機建立 TCP連接時，擁塞窗口被初始化爲 1個報文段（即另一端通告的報文
帶寬時延乘積
- 可以計算通道的容量爲：capacity (bit) = bandwidth (b/s) × round-trip time (s)
擁塞
- 當數據到達一個大的管道（如一個快速局域網）並向一個較小的管道（如一個較慢的廣域網）發送時便會發生擁塞
- 當多個輸入流到達一個路由器，而路由器的輸出流小於這些輸入流的總和時也會發生擁塞。
小結
- 正如我們在本章一開始時講的那樣，沒有一種單一的方法可以使用 TCP進行成塊數據的交換。這是一個依賴於許多因素的動態處理過程，有些因素我們可以控制（如發送和接收緩存的大小），而另一些我們則沒有辦法控制（如網絡擁塞、與實現有關的特性等）。在本章，我們已經考察了許多TCP的傳輸過程，介紹了所有我們能夠看到的特點和算法
- 進行成塊數據有效傳輸的最重要的方法是 TCP的滑動窗口協議
第21章 TCP的超時與重傳
- TCP提供可靠的運輸層。它使用的方法之一就是確認從另一端收到的數據。但數據和確認都有可能會丟失。 T C P通過在發送時設置一個定時器來解決這種問題。如果當定時器溢出時還沒有收到確認，它就重傳該數據。對任何實現而言，關鍵之處就在於超時和重傳的策略，即怎樣決定超時間隔和如何確定重傳的頻率
- 對每個連接，TCP管理4個不同的定時器。
- 重傳定時器使用於當希望收到另一端的確認。在本章我們將詳細討論這個定時器以及一些相關的問題，如擁塞避免。
- 堅持( persist)定時器使窗口大小信息保持不斷流動，即使另一端關閉了其接收窗口。第22章將討論這個問題
- 保活( keepalive )定時器可檢測到一個空閒連接的另一端何時崩潰或重啓。第 23章將描述這個定時器
- 2MSL定時器測量一個連接處於 TIME_ WAIT狀態的時間
- 超時與重傳的簡單例子
![在這裏插入圖片描述]()
- 現在檢查連續重傳之間不同的時間差，它們取整後分別爲 1、3、6、12、24、48和多個64秒。在本章的後面，我們將看到當第一次發送後所設置的超時時間實際上爲 1.5秒（它在首次發送後的1.0136秒而不是精確的1 . 5秒後，發生的原因我們已在圖 18-7中進行了解釋），此後該時間在每次重傳時增加1倍並直至64秒。這個倍乘關係被稱爲“指數退避 (exponential backoff )”
- 首次分組傳輸與復位信號傳輸之間的時間差約爲9分鐘，該時間在目前的T C P實現中是不可變的。
往返時間測量
- TCP超時與重傳中最重要的部分就是對一個給定連接的往返時間（ RTT）的測量
- 首先TCP必須測量在發送一個帶有特別序號的字節和接收到包含該字節的確認之間的RTT
慢啓動
- 連接上最初只允許傳輸一個報文段，然後在發送下一個報文段之前必須等待接收它的確認。當報文段2被接收後，就可以再發送兩個報文段。上一章介紹了慢啓動算法。
擁塞避免算法
- 擁塞避免算法是一種處理丟失分組的方法
- 擁塞避免算法和慢啓動算法是兩個目的不同、獨立的算法。但是當擁塞發生時，我們希望降低分組進入網絡的傳輸速率，於是可以調用慢啓動來作到這一點。在實際中這兩個算法通常在一起實現
- *擁塞避免算法和慢啓動算法需要對每個連接維持兩個變量：一個擁塞窗口 cwnd和一個慢啓動門限ssthresh。
- 對一個給定的連接，初始化cwnd爲1個報文段，ssthresh爲65535個字節。
- TCP輸出例程的輸出不能超過 cwnd和接收方通告窗口的大小。
- 擁塞避免是發送方使用的流量控制，而通告窗口則是接收方進行的流量控制。前者是發送方感受到的網絡擁塞的估
計，而後者則與接收方在該連接上的可用緩存大小有關。 - 擁塞發生時（超時或收到重複確認），ssthresh被設置爲當前窗口大小的一半（ cwnd和接收方通告窗口大小的最小值，但最少爲 2個報文段）。此外，如果是超時引起了擁塞，則cwnd被設置爲1個報文段（這就是慢啓動）。
- 當新的數據被對方確認時，就增加 cwnd，但增加的方法依賴於我們是否正在進行慢啓動或擁塞避免。如果 cwnd小於或等於ssthresh，則正在進行慢啓動，否則正在進行擁塞避免。慢啓動一直持續到我們回到當擁塞發生時所處位置的半時候才停止（因爲我們記錄了在步驟 2中給我們製造麻煩的窗口大小的一半），然後轉爲執行擁塞避免
擁塞避免算法要求每次收到一個確認時將 cwnd增加1 /cwnd。與慢啓動的指數增加比起來，這是一種加性增長(additive increase)。
快速重傳與快速恢復算法
- 我們認識到在收到一個失序的報文段時， TCP立即需要產生一個 ACK（一個重複的A C K）。這個重複的ACK不應該被遲延。該重複的 ACK的目的在於讓對方知道收到一個失序的報文段，並告訴對方自己希望收到的序號.
- 由於我們不知道一個重複的 A C K是由一個丟失的報文段引起的，還是由於僅僅出現了幾個報文段的重新排序，因此我們等待少量重複的 ACK到來。假如這只是一些報文段的重新排序，則在重新排序的報文段被處理併產生一個新的 ACK之前，只可能產生1 ~ 2個重複的ACK。如果一連串收到 3個或3個以上的重複ACK，就非常可能是一個報文段丟失了）。於是我們就重傳丟失的數據報文段，而無需等待超時定時器溢出。這就是快速重傳算法。接下來執行的不是慢啓動算法而是擁塞避免算法。這就是快速恢復算法。
- 在這種情況下沒有執行慢啓動的原因是由於收到重複的 A C K不僅僅告訴我們一個分組丟失了。由於接收方只有在收到另一個報文段時纔會產生重複的 A C K，而該報文段已經離開了網絡並進入了接收方的緩存。也就是說，在收發兩端之間仍然有流動的數據，而我們不想執行慢啓動來突然減少數據流。
- 這個算法通常按如下過程進行實現:
- 收到第3個重複的ACK時，將ssthresh設置爲當前擁塞窗口 cwnd的一半。重傳丟失的報文段。設置cwnd爲ssthresh加上3倍的報文段大小。
- 每次收到另一個重複的 ACK時，cwnd增加1個報文段大小併發送 1個分組（如果新的cwnd允許發送）
但是在接收到重複 ACK的過程中cwnd允許保持增加，這是因爲每個重複的ACK表示1個報文段已離開了網絡
- 下一個確認新數據的ACK到達時，設置cwnd = ssthresh。這個ACK應該是在進行重傳後的一個往返時間內對步驟 1中重傳的確認。另外，這個 ACK也應該是對丟失的分組和收到的第 1個重複的ACK之間的所有中間報文段的確認。這一步採用的是擁塞避免，因爲當分組丟失時我們將當前的速率減半。
重新分組
- 當TCP超時並重傳時，它不一定要重傳同樣的報文段
小結
- 本章提供了對TCP超時和重傳機制的詳細研究。使用的第 1個例子是一個丟失的建立連接的SYN，並觀察了在隨後的重傳和超時中怎樣使用指數退避方式
- 慢啓動、擁塞避免、快速重傳和快速恢復
第22章 TCP的堅持定時器
引言
- TCP必須能夠處理打開此窗口的 ACK丟失的情況。ACK的傳輸並不可靠，也就是說， TCP不對ACK報文段進行確認， TCP只確認那些包含有數據的ACK報文段。
- 如果一個確認丟失了，則雙方就有可能因爲等待對方而使連接終止：接收方等待接收數據（因爲它已經向發送方通告了一個非 0的窗口），而發送方在等待允許它繼續發送數據的窗口更新。爲防止這種死鎖情況的發生。發送方使用一個堅持定時器 (persist timer)來週期性地向接收方查詢，以便發現窗口是否已增大。這些從發送方發出的報文段稱爲窗口探查 ( window probe )
一個例子
![在這裏插入圖片描述]()
- 報文段13中，服務器確認了前面 4個數據報文段，然後通告窗口爲 0，從而使客戶停止發送任何其他的數據。這就引起客戶設置其堅持定時器。如果在該定時器時間到時客戶還沒有接收到一個窗口更新，它就探查這個空的窗口以決定窗口更新是否丟失。由於服務器進程處於休眠狀態，所以TCP緩存9216字節的數據並等待應用進程讀取。
- 計算堅持定時器時使用了普通的 TCP指數退避
- 窗口探查包含一個字節的數據（序號爲 9217）。TCP總是允許在關閉連接前發送一個字節的數據。請注意，盡管如此，所返回的窗口爲 0的ACK並不是確認該字節（它們確認了包括9216在內的所有數據），因此這個字節被持續重傳
- 堅持狀態與第21章中介紹的重傳超時之間一個不同的特點就是 TCP從不放棄發送窗口探查。這些探查每隔 6 0秒發送一次，這個過程將持續到或者窗口被打開，或者應用進程使用的連接被終止。
糊塗窗口綜合症
-
基於窗口的流量控制方案，如 TCP所使用的，會導致一種被稱爲“糊塗窗口綜合症 SWS(Silly Window Syndrome）”的狀況。
-
該現象可發生在兩端中的任何一端：接收方可以通告一個小的窗口（而不是一直等到有大的窗口時才通告），而發送方也可以發送少量的數據（而不是等待其他的數據以便發送一個大的報文段）。可以在任何一端採取措施避免出現糊塗窗口綜合症的現象
- 接收方不通告小窗口。通常的算法是接收方不通告一個比當前窗口大的窗口（可以爲0），除非窗口可以增加一個報文段大小（也就是將要接收的 MSS）或者可以增加接收方緩存空間的一半，不論實際有多少。
- 發送方避免出現糊塗窗口綜合症的措施是隻有以下條件之一滿足時才發送數據：
- 可以發送一個滿長度的報文段；
- 可以發送至少是接收方通告窗口大小一半的報文段；
- 可以發送任何數據並且不希望接收 ACK（也就是說，我們沒有還未被確認的數據）或者該連接上不能使用Nagle算法（見第1 9.4節）。
-
一個糊塗窗口例子
-
![在這裏插入圖片描述]()
-
![在這裏插入圖片描述]()
- 前4個數據報文段及其A C K（報文段1 ~ 5）表示發送方正在填充接收方的緩存。在那個時刻發送方停止了發送，但仍然有更多的數據需要發送。它將自己的堅持定時器置爲最小值 5分鐘。當堅持定時器時間到時，就發送出 1個字節的數據（報文段 6）。接收的應用進程已經從接收緩存中讀取了2 5 6字節的數據（在時刻3.99），因此這個字節被接受並被確認（報文段 7段）。但是通告窗口仍爲0，由於接收方仍然沒有足夠的空間來接收一個滿長度的報文，或者不能騰出緩存空間的一半。這就是接收方的糊塗窗口避免措施
- 發送方的堅持定時器被複位，並在5秒後再次到時（在時刻10. 151）。然後又發送一個字節並被確認（報文段8和9），而接收方的緩存空間還不夠用（1022字節），使得通告窗口爲0。
- 發送方的堅持定時器在時刻 15. 151再次時間到，又發送了另一個字節並被確認（報文段10和11）。這一次由於接收方有 1533字節的有效緩存空間，因此通告了一個非 0窗口。發送方立即利用這個窗口發送了1024字節的數據（報文段12）。對這1024字節數據的確認（報文段13）通告其窗口爲509字節。這看起來與我們在前面看到的小窗口通告相牴觸。
- 在這裏之所以發生這種情況，是因爲報文段 11段通告了一個大小爲 1533字節的窗口，而發送方只使用了其中的1024字節。如果在報文段13中的A C K通告其窗口爲0，就會違反窗口的右邊沿不能向左邊沿移動而導致窗口收縮的 TCP原則（見第20.3節）
- 接下來我們看到發送方沒有立即向這個小窗口發送數據。這就是發送方採取的糊塗窗口避免策略。相反，它等待另一個堅持定時器在時刻 20.151到時間，並在該時刻發送 509字節的數據。儘管它最終還是發送了一個長度爲 509字節的小數據段，但在發送前它等待了 5秒鐘，看是否會有一個ACK到達，以便可以將窗口開得更大。這 509字節的數據使得接收緩存僅剩下768字節的有效空間，因此接收方通告窗口爲 0（報文段15）。
小結
- 連接的一方需要發送數據但對方已通告窗口大小爲0時，就需要設置TCP的堅持定時器。發送方使用與第2 1章類似的重傳間隔時間，不斷地探查已關閉的窗口。這個探查過程將一直持續下去。
- 當運行一個例子來觀察堅持定時器時，我們還觀察到了 TCP的避免出現糊塗窗口綜合症的現象。這就是使 TCP避免通告小的窗口大小或發送小的報文段。在我們的例子中，可以觀察到發送方和接收方爲避免糊塗窗口綜合症所使用的策略
第23章 TCP的保活定時器
引言
- 一個服務器希望知道客戶主機是否崩潰並關機或者崩潰又重新啓動。許多實現提供的保活定時器可以提供這種能力
- 保活定時器是一個有爭論的功能。許多人認爲如果需要，這個功能不應該在 TCP中提供，而應該由應用程序來完成。這是應當認真對待的一些問題之一，因爲在這個論題上有些人表達出了很大的熱情。
- 保活功能主要是爲服務器應用程序提供的。服務器應用程序希望知道客戶主機是否崩潰，從而可以代表客戶使用資源
描述
- 如果一個給定的連接在兩個小時之內沒有任何動作，則服務器就向客戶發送一個探查報文段
- 客戶主機依然正常運行，並從服務器可達。客戶的 TCP響應正常，而服務器也知道對方是正常工作的。服務器在兩小時以後將保活定時器復位。如果在兩個小時定時器到時間之前有應用程序的通信量通過此連接，則定時器在交換數據後的未來 2小時再復位。
- 客戶主機已經崩潰，並且關閉或者正在重新啓動。在任何一種情況下，客戶的 TCP都沒有響應。服務器將不能夠收到對探查的響應，並在 75秒後超時。服務器總共發送 10個這樣的探查，每個間隔 7 5秒。如果服務器沒有收到一個響應，它就認爲客戶主機已經關閉並終止連接。
- 客戶主機崩潰並已經重新啓動。這時服務器將收到一個對其保活探查的響應，但是這個響應是一個復位，使得服務器終止這個連接。
- 客戶主機正常運行，但是從服務器不可達。這與狀態 2相同，因爲TCP不能夠區分狀態4與狀態2之間的區別，它所能發現的就是沒有收到探查的響應
- 第1種情況下，服務器的應用程序沒有感覺到保活探查的發生。 TCP層負責一切。這個過程對應用程序都是透明的，直至第 2、3或4種情況發生。在這三種情況下，服務器應用程序將收到來自它的 TCP的差錯報告（通常服務器已經向網絡發出了讀操作請求，然後等待來自客戶的數據。
第24章 TCP的未來和性能
- 路徑MTU
- 長肥管道 具有大的帶寬時延乘積的網絡被稱爲長肥網絡。使用長肥管道會遇到多種問題。
- TCP首部中窗口大小爲 16 bit，從而將窗口限制在 65535個字節內。但是從圖 2 4 - 5的最後一列可以看到，現有的網絡需要一個更大的窗口來提供最大的吞吐量
- TCP對每個字節數據使用一個32 bit無符號的序號來進行標識。如果在網絡中有一個被延遲一段時間的報文段，它所在的連接已被釋放，而一個新的連接在這兩個主機之間又建立了，怎樣才能防止這樣的報文段再次出現呢？