1. 計算機網路_運輸層
在IP層看來，通信的兩端是兩個主機，IP數據報的首部明確的標志了這兩個主機的IP地址。但是兩個主機之間的通信這種說法還不夠清楚，這是因為真正進行通信的實體是在主機中的 進程 ，是兩個進程之間在交換數據。從而引出了運輸層，從運輸層的角度看來， 通信的真正端點並不是主機而是主機中的進程 （端到端的通信）。
在一個主機中經常有多個應用進程同時分別和另一個主機的多個應用進程通信。這就表明了運輸層有一個很重要的功能， 復用和分用 ，應前畝配用層不同進程的報文通過不同的埠向下交到運輸層，再往下就共用網路層提供的服務。
「運輸層提供應用進程間的邏輯通信」。「邏輯通信」的意思是：運輸層之間的通信好像是沿水平方向傳送數據。但事實上這兩個運輸層之間並沒有一條水平方向的物理連接。
TCP/IP 的運輸層有兩個不同的協議：
由此可見兩個計算機中的進程要相互通信，不僅要知道對方的IP地址，還要知道對方的埠號。
如果接收方UDP發現收到的報文中的目的埠號不正確（即不存在對應於該埠的號的應耐戚用進程），就丟棄該報文，並由網際控制報文協議ICMP發送 埠不可達 差錯報文給發送方。
在計算檢驗和時，臨時把 「偽首部」 和 UDP 用戶數據報連接在一起得到一個臨時的數據報，它不向下傳遞也不向上遞交。 偽首部僅僅是為了計算檢驗和 。
UDP計算檢驗和的方法和IP數據報首部檢驗和方法相類似。但不同的是，IP數據報的檢驗和 只檢驗IP數據報的首部 ，但UDP的檢驗和是 把首部和數據部分一起檢驗
計算UDP檢驗和的例子：
在發送方，先把全0放入檢驗和欄位，再把偽首部以及UDP用戶數據報看成是許多16位的字串接起來。若UDP用戶報的數據部分不是慧指偶數個位元組，則要填入一個全零位元組（先不發送）。然後按照 二進制反碼 計算出這些16位字的和。將此和的二進制反碼寫入 檢驗和欄位 後，就發送這樣的UDP數據報。在接收方，把收到的UDP數據報連通偽首部（以及可能填充全零位元組）一起，按二進制反碼求這些16位字的和。當無差錯時其結果應為全1（原本的檢驗和為0，封裝成數據報後再次相加的時候就多個檢驗和反碼相加，所以無差錯時結果為1）。
每一條TCP連接唯一地被通信兩端的兩個端點（即兩個套接字）所確定，即：
TCP發送的報文段是交給IP層傳輸的。但IP層只提供盡最大努力服務，也就是說，TCP下面的網路所提供的是不可靠傳輸，因此，TCP必須採用適當的措施才能使得兩個運輸層之間的通信變得可靠。
在這樣的理想傳輸條件下，不需要採取任何措施就能夠實現可靠傳輸。然而實際的網路都不具備以上兩個理想的條件。但我們可以使用一些可靠傳輸協議，當出現差錯時讓發送方重傳出現差錯的數據，同時在接收方來不及處理收到的數據時，及時告訴發送方適當的降低發送數據的速度，這樣一來，本來是不可靠的傳輸信道就能夠實現可靠傳輸。
停止等待協議的優點是簡單，但缺點是 信道利用率 太低。
假定AB之間有一條直通的信道來傳送分組
這里的TD是A發送分組所需要的時間（顯然TD = 分組長度 / 數據速率）再假定TA是B發送確認分組所需要的時間（A和B處理分組的時間都忽略不計）那麼A在經過TD+RTT+TA時間後才能發送下一個分組，這里的RTT是往返時間，因為只有TD是採用來傳輸有用的數據（這個數據包括了分組首部，如果可以知道傳輸更精確的數據的時間，可以計算的更精確），所有信道利用率為
為了提高傳輸效率，發送方可以不使用低效率的停止等待協議，而是採用 流水線傳輸 ：就是發送方可以 連續的發送多個分組 ，不必每發完一個分組就停下來等待對方的確認。這樣可使信道上一直有數據不間斷地在傳送。顯然這種傳輸方式可以獲得很高的信道利用率
當時使用流水線傳輸時，就要使用下面介紹的 連續ARQ協議 和 滑動窗口協議
滑動窗口協議比較復雜，是TCP協議的精髓所在，在這里先給出ARQ協議最基本的概念，但不涉及到許多細節問題。
位於發送窗口的分組都可以連續的發送出去，而不需要等待對方的確認，發送方每收到一個確認，就把發送窗口向前滑動一個分組的位置。
詳細可以見P201
TCP雖然是面向位元組流的，但是TCP傳送的數據單元卻是報文段（可以看上述TCP面向流的概念），而且TCP的 全部功能都體現在它的首部中各個欄位 。
詳解請見P206，注意圖中的後沿，前沿
從下圖可以看出來，要描述一個發送窗口的狀態需要三個指針：P1，P2，P3
有很多信息見P208，這里不贅述
發送方的應用進程把位元組流寫入TCP的發送緩存，接收方的應用進程從TCP的接收緩存中讀取位元組流。下面進一步討論前面講的 窗口和緩存 的關系
發送緩存
發送窗口通常只是發送緩存的一部分，已被確認的數據應當從發送緩存中刪除，因此 發送緩存和發送窗口的後沿是重合 的。發送應用程序最後寫入發送緩存的位元組減去最後被確認的位元組，就是還保留在發送緩存中被寫入的位元組。發送應用程序必須控制寫入緩存的速率，不能太快 ，否則發送緩存就會沒有存放數據的空間。
如果收到的分組被檢測出有差錯，則要丟棄。如果接收應用程序來不及讀取收到的數據，接收緩存最終就會被填滿，使接收窗口減少到零。反之，如果接收應用程序能夠及時從接收緩存中讀取收到的數據，接收窗口就可以增大，但最大不能超過接收緩存的大小。
TCP才用了一種自適應演算法，它記錄一個報文段發出的時間，以及收到相應的確認的時間。這兩個時間之差就是報文段的往返時間RTT。
TCP 保留了 RTT 的一個 加權平均往返時間 RTTs （這又稱為平滑（smooth）的往返時間，因為是加權平均，所以是平滑的）。
第一次測量到 RTT 樣本時， RTTS 值就取為所測量到的 RTT 樣本值 。以後每測量到一個新的 RTT 樣本，就按下式重新計算一次 RTTS：
顯然，RTO 應略大於上面得出的加權平均往返時間 RTTs
RFC 2988 建議使用下式計算 RTO：
RTTD 是 RTT 的 偏差的 加權平均值，他與RTTs和新的RTT樣本之差有關。
RFC 2988 建議這樣計算 RTTD。第一次測量時，RTTD 值取為測量到的 RTT 樣本值的一半。在以後的測量中，則使用下式計算加權平均的 RTTD：
β是個小於 1 的系數，其推薦值是 1/4，即 0.25。
為了解決上面那個問題，Karn提出了一個演算法
在計算平均往返時間 RTT 時，只要**報文段重傳了，就不採用其往返時間樣本。這樣得出的加權平均平均往返時間 RTTS 和超時重傳時間 RTO 就較准確。 **
但是，這又有了新的問題、設想出現這樣的情況：報文段的時延突然增大了很多。因此在原來得出的重傳時間內，不會收到確認報文段。於是就重傳報文段。但根據Karn演算法，不考慮重傳的報文段的往返時間樣本。這樣，超時重傳時間就無法更新。
報文段每重傳一次，就把 RTO 增大一些：
系數 γ 的典型值是 2 。
當不再發生報文段的重傳時，才根據報文段的往返時延更新平均往返時延 RTT 和超時重傳時間 RTO 的數值。
實踐證明，這種策略較為合理。
接收方收到了和前面的位元組流 不連續 *的兩個位元組塊（只是未按序號，它是無差錯的）
如果這些位元組的序號都在接收窗口之內，那麼接收方就先收下這些數據，但要把這些信息准確地告訴發送方，使發送方不要再重復發送這些已收到的數據。
和前後位元組不連續的每一個位元組塊都有兩個邊界：左邊界和右邊界。圖中用四個指針標記這些邊界。第一個位元組塊的左邊界 L1 = 1501，但右邊界 R1 = 3001。左邊界指出位元組塊的第一個位元組的序號，但右邊界減 1 才是位元組塊中的最後一個序號。第二個位元組塊的左邊界 L2 = 3501，而右邊界 R2 = 4501。
詳見P211
一般說來，我們總是希望數據傳輸得更快一些。但如果發送方把數據發送得過快，
接收方就可能來不及接收，這就會造成數據的丟失。
流量控制(flow control)就是讓發送方的發送速率不要太快，既要讓接收方來得及接收，也不要使網路發生擁塞 。
利用 滑動窗口機制 可以很方便地在 TCP 連接上實現流量控制。
A 向 B 發送數據。在連接建立時，�B 告訴 A：「我的接收窗口 rwnd = 400（位元組）」。 看下TCP首部窗口欄位的用處
接收方的主機B一共進行了3次流量控制（藍線）
考慮一種情況，B向A發送了零窗口的報文段後不久，B的接收緩存又有了一些存儲空間。於是B向A發送了rwnd = 400的報文段，然而這個報文段在傳輸過程中丟失了。A一直等收到B發送非零窗口的通知，B也一直等A發送數據來，就形成了 死鎖 。下面的 持續計時器 就是為了打破死鎖僵局的
應用進程把數據傳送到TCP發送緩存後，剩下的發送任務就由TCP來控制了。可以用不同的機制來控制 TCP 報文段的發送時機:
至於如何控制發送的 時機 詳見P213
在某段時間，若對網路中某資源的需求超過了該資源所能提供的可用部分，網路的性能就要變壞——產生 擁塞(congestion)
出現資源擁塞的條件： 對資源需求的 總和 > 可用資源
若網路中有許多資源同時產生擁塞，網路的性能就要明顯變壞，整個網路的吞吐量將隨輸入負荷的增大而下降。
解決擁塞的要點是 平衡 ，要讓整個系統的性能想匹配（P214）。
橫坐標為 提供的負載 ，代表單位時間內輸入給網路的分組的數目（也叫作輸入負載或網路負載），縱坐標是 吞吐量 ，代表單位時間內從網路輸出的分組數目。
由於缺少緩存空間而被丟棄的分組的百分數，平均隊列長度，超時重傳的分組數，平均分組時延，分組時延的標准差等，這些指標的上升都標志著擁塞的增長。
方便起見，我們用 報文段的個數 作為窗口大小的單位
慢開始門限 ssthresh 的用法如下：
擁塞避免演算法的思路是讓擁塞窗口 cwnd 緩慢地增大，即每經過一個往返時間 RTT 就把發送方的擁塞窗口 cwnd 加 1，而不是加倍，使擁塞窗口 cwnd 按線性規律緩慢增長 ，比慢開始演算法的擁塞窗口增長速率緩慢很多。
網路出現擁塞時
當 TCP 連接進行初始化時，將擁塞窗口置為 1。圖中的窗口單位不使用位元組而使用 報文段 。
慢開始門限的初始值設置為 16 個報文段，即 ssthresh = 16。
發送端的發送窗口不能超過擁塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我們假定接收端窗口足夠大，因此現在發送窗口的數值等於擁塞窗口的數值。
下面的執行步驟就是按照折現上的點的順序
2. 【網路】TCP/IP-傳輸層知識概要
首先確定下傳輸層的作用
例子：
．在OSI參考模型中，自下而上第一個提供端到端服務的層次是 傳輸層
解析
傳輸層，傳輸層的是作用是負責為兩台主機中應用進程之間的通信提供服務，而對於網路層來說，提供的是主機到主機之間的通信，所謂的端到端是指應用進程到應用進程。
SYN（synchronous）是TCP/IP建立連接時使用的握手信號。在客戶機和伺服器之間建立正常的TCP網路連接時，客戶機首先發出一個SYN消息，伺服器使用SYN+ACK應答表示接收到了這個消息，最後客戶機再以ACK消息響應。這樣在客戶機和伺服器之間才能建立起可靠的TCP連接，數據才可以在客戶機和伺服器之間傳遞。
在第一次發送信息中，A隨機選取一個序列號x作為初始化序列號發送給B。
第二次B使用ack對A的數據報進行確認，因為已經收到了序列號為x的數據包，准備接收序列號為x+1的包，所以ack=x+1,同時發送自己的初始化序列號seq=y
TCP連接的第一個包，非常小的一種數據包。SYN 攻擊包括大量此類的包，由於這些包看上去來自實際不存在的站點，因此無法有效進行處理。每個機器的欺騙包都要花幾秒鍾進行嘗試方可放棄提供正常響應。
如下圖所示，IP 地址在IP 數據報的首部，而硬體地址則放在MAC 幀的首部。在網路層以上使用的是IP 地址，而鏈路層及以下使用的是硬體地址。
TCP的連接端點稱為 套接字（socket），根據TCP協議的規定，埠號拼接到IP地址即構成了套接字。
也就是說TCP連接的端點不是主機，不是IP不是應用進程，而是套接字。
套接字 socket = （IP地址：埠號）
套接字 socket = (IP地址: 埠號)
TCP 連接 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}
Socket連接是一個五元組，包括協議類型，源IP，源埠，目標地址和目標埠
TCP是面向位元組流的，每一個位元組對應一個序列號。
TCP每次發送的報文段的首部中的序列號是該報文枯世段的第一個位元組的序號。
接收端返回的確認號是收到數據的最高序號加1
一個 TCP報文段的數據部分最多是
IP數據報 的最大長度=2^16-1=65535（位元組）
TCP報文段的數據部分= IP數據報 的最大長度- IP數據報 的首部-TCP報文段的首部=65535-20-20=65495（位元組）
在IP 層抽象的互連網上，我們看到的只是IP 數據報，路由器根據目的站的 IP地址進行選路。在具體的物理網路的鏈路層，我們看到的只是 MAC 幀，IP 數據報被封裝在 MAC幀裡面。
MAC 幀在不同的網路上傳送時，其MAC 幀的首部是不同的。這種變化，在上面的IP 層上是看不到的。每個路由器都有IP 地址和硬體地址。使用IP 地址與硬體地址，盡管連接在一起的網路的硬體地址體系各不相同，但 IP層抽象的互連網卻屏蔽了下層這些很復雜的細節，並使我們能夠使用統一的、抽象的IP 地址進行通信。
當某個路由器發現一數據報的檢驗和有差錯時，會直接丟棄。
思考
如何理解TCP/IP 協議本是為非實時數據業務而設計的
例：為什麼在 TCP 首部中有一個首部長度沒羨肢欄位，而 UDP 的首部中就沒有這個欄位？
答：這是TCP 與UDP 包的區別，TCP 包的首部欄位可以更好的保證數據傳輸的可靠安全，而UDP 就不能保證，所以UDP 比TCP 快，不間斷但是不可靠，例如QQ 視頻就是使用UDP，經常出現人不動，就是這個原因
分組交換根據其通信子網向端點系統提供的服務，還可以進一步分為面向連接的虛電路方式和無連接的數據報方式。這兩種服務方式都由網路層提供。
虛電路在發送方和接受方會建立一條邏輯上的連接，並不是一條真正的物理連接。
電路交換的電話通信是先建立一條真正的物理連接，因此派銀分組交換的虛電路和電路交換的連接只是類似，並不完成一樣。
1 數據報服務發送分組前不需要建立連接
2 虛電路網路中的每個結點上都維持一張虛電路表，它的每一項記錄了一個打開的虛電路的信息，包括在接受鏈路和發送鏈路的虛電路號，前一結點和下一結點的標識。
關於擁塞上一張腦圖
發生擁塞控制的原因：資源(帶寬、交換節點的緩存、處理機)的需求 > 可用資源。作用：擁塞控制就是為了防止過多的數據注入到網路中，這樣可以使網路中的路由器或者鏈路不至於過載。擁塞控制要做的都有一個前提：就是網路能夠承受現有的網路負荷。
對比流量控制：擁塞控制是一個全局的過程，涉及到所有的主機、路由器、以及降低網路相關的所有因素。流量控制往往指點對點通信量的控制，是端對端的問題。流量控制只關心發送方和接收方點對點的發送量。它的任務是處理發送能力大於接受能力。
網路中存在太多的數據包，導致數據包被延遲和丟失，從而降低傳輸性能，這種情況稱為擁塞。網路層和傳輸層共同承擔著處理擁塞的責任。
TCP連接的每一端都必須設有兩個窗口，一個發送窗口，一個接收埠。
TCP可靠傳輸機制用位元組的序號進行控制。TCP所有的確認基於序號還不是基於報文。TCP 每發送一個報文段，就對這個報文段設置一次計時器。只要計時器設置的重傳時間到但還沒有收到確認，就要重傳這一報文段。TCP協議用於控制數據段是否需要重傳的依據是設立 重傳定時器。
保護數據不受主動攻擊(數據的偽造和變動)的措施稱為報文認證技術。
自動重傳請求（Automatic Repeat-reQuest，ARQ）是OSI模型中運輸層的錯誤糾正協議之一。它包括停止等待ARQ協議和連續ARQ協議，錯誤偵測（Error Detection）、正面確認（Positive Acknowledgment）、逾時重傳（Retransmission after Timeout）與負面確認繼以重傳（Negative Acknowledgment and Retransmission）等。
TCP協議用於控制數據段是否需要重傳的依據是設立 重發定時器
3. 計算機網路應用層和傳輸層及網路層協議有哪些
計算機網路中應用層、傳輸層和網路層涉及到的一些協議如下：
應用層協議：應用層協議是計算機網路中最高層的協議，用於處理應用程序之間的數據交換。常用的應用層協議包括HTTP、FTP、SMTP、POP3、DNS等。
傳輸層協議：傳輸層協議主要弊祥負責實現數據在網路中的可靠傳輸，通常包括TCP和UDP兩種協議。其中，TCP協議提供面向連接、可靠的數據傳輸，而UDP協議則提供無連接、不可靠的數據傳輸。
網路層協議：網路層協議主要負責實現數據在網路中的路由和轉發，以及網路地址的管桐卜局理。常用的網路層協議包括IP、ICMP、ARP、RARP、OSPF等。其中，IP協議是局讓互聯網中最重要的協議之一，負責實現數據包在網路中的傳輸和路由選擇。
這些協議在計算機網路中各自扮演不同的角色，共同組成了網路通信的基礎框架。應用層協議直接面向用戶應用程序，為其提供數據傳輸和交互的功能；傳輸層協議則通過TCP或UDP協議保證數據的可靠傳輸；網路層協議則實現數據在網路中的路由和轉發，保證數據能夠從源節點到目標節點的可靠傳輸。
-------FunNet超有趣學網路
4. [計算機網路之六] 傳輸層
傳輸層向它上面的應用層提供通信服務，它屬於面向通信部分的最高層，同時也是用戶功能中的最底層。
從傳輸層的角度，通信的真正端點並不是主機而是主機中的進程。
傳輸層有 分用 和 復用 的功能。 「復用」 是指在發送方不同的應用進程都可以使用同一個運輸層協議傳送數據， 「分用」 是指接收方的運輸層在剝去報文的首部後能夠把這些數據正確交付目的應用進程。
網路層和運輸層有明顯的區別，網路層為主機之間提供邏輯通信，而運輸層為應用進程之間提供端到端的邏輯通信。
知名埠號 ：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。
5. 網路基礎-傳輸層, 網路層數據鏈路層
同軸電纜: 半雙工通訊;
集線器: 類似同軸電纜, 半雙工通訊;容易沖突;
網橋: 兩個介面, 通過自學習記錄每個介面側的 mac 地址;從而起到隔絕沖突域的作用;
交換機: 相當於介面更多的網橋, 全芹攜橘雙工通訊;
路由器: 可以在不同網段之間發送數據, 隔絕廣播域;
IP地址的組成嫌團:
IP地址有兩部分組成: 網路標識(網路ID, 網段), 主機標識( 主機ID);
如何避免浪費IP資源?
信道:信息傳輸的通道, 一條傳輸介質上(比如網線), 可以有多條信道;
單工通信: 信號只能往一個方向傳, 任何時候不能改變信號的方向;
半雙工通信:信號可以雙向傳播, 但是必須交替進行, 同一時間只能往一個方向傳播;
全雙工通信:信號可以同時雙向傳播;
數據幀:數據鏈路層
如何確保一個數據幀的完整性:
幀的尾部有FCS標識符是根據幀首和幀尾計算得來的, 在獲得一個幀數據後幀首幀尾根據計算計算如果值等於FCS則數據幀完整, 去掉幀首幀尾即可獲得中間的數據buffer;
數據鏈路層的數據(MTU)大小為不超過1500個位元組,因此我們可以推斷出傳輸層的數據段最大為不超過1460位元組;(網路層的首部最小20個位元組, 傳輸層首部最小20個位元組, 因此傳輸層的數據段最大為1460);
ping 的幾個用法:
通過tracert, pathping ip地址的方式, 可以查看途徑的路由器;
TTL : Time To Live(生存時間) 每經過一個路由器值就會減1; 為0時數據包不再傳輸;
埠:
UDP首部中埠是佔用2個位元組(因此其取值范圍是0-65535);
防火牆可以可以設置開啟/關閉某些埠提升安全性;
常用命令:
傳輸層的兩個協議
TCP: 傳輸控制協議;
UDP: 用戶數據報協議;
TCP的數據格式:
TCP標志位的作用:
如果數據超時或者收到三次確認都會重新發送保證數據完整性;
主要是通過ARQ(自動重傳技術-超時重發)+滑動窗口協議實現(例如一次可以接收4個數據包, 就是隱洞一個緩沖區的設置);
另外通過SACK(選擇性確認)來告訴發送方哪些數據已經接收到哪些數據丟失, 這樣TCP就只發送丟失的部分即可;
如果接收方的數據緩沖區已經滿了, 而發送方還在不停的發數據, 則需要進行流量控制;如果不進行控制則接收方只能將大量的數據包進行丟棄, 造成的大量的網路資源浪費;
什麼是流量控制?
讓發送方的發送速度不要太快, 讓接收方有足夠的時間和空間來處理和接受數據;注意這個概念是指點對點之間;
原理:
通過確認報文中的窗口欄位來控制發送方的發送速率;
發送方的發送窗口大小不能超過接收方的窗口大小;
當發送方收到接收方的窗口為0時則不再發數據;
特殊情況:
剛開始接收方發送了0窗口報文給發送方, 然後發送方停止了發送數據;
後面接收方有空間了, 發送了非0窗口報文給發送方結果報文丟失了;
則接收方和發送方陷入循環;
解決方案: 發送方收到0窗口報文的時候停止發送數據, 同時開啟一個定時器, 隔一段時間發送測試報文取詢問接收方窗口的大小, 如果仍然收到0窗口報文則重新刷新啟動定 時器;
鏈路的吞吐量在過載的時候會導致擁塞;直觀的理解為, 一條路可以同時供100輛車100km/h通過, 但是當有200輛車的時候估計只能以50km/h通過, 當有300輛車時估計會堵的動不了;
擁塞控制是指避免過多的數據注入到網路中, 避免網路中的路由器或者鏈路過載;擁塞控制是一個全局性的過程, 涉及到所有的主機, 路由器; 是大家共同努力的結果; 注意區分流量控制是點對點之間的;
幾個縮寫:
MSS: 每個段最大的數據部分大小, 在建立鏈接是確定;
swnd: 擁塞窗口;
rwnd:接收窗口;
swnd:發送窗口; swnd=min(swnd, rwnd);
擁塞控制思路:
慢開始(慢啟動)-擁塞避免- 快速重傳-快速恢復;
a. 慢開始 :
b. 擁塞避免 :
c. 快重傳 :
d. 快恢復 :
e. 用圖片表示擁塞控制
狀態解讀:
Closed: Client處於關閉狀態;
Listen: Server處於監聽狀態, 等待Client鏈接;
SYN-RCVD: 表示Server收到SYN報文, 當收到Client的ack報文後進入ESTABLished狀態;
SYN-SENT: 表示Client已經發出SYN-SENT報文, 等待Server的第二次握手;
ESTABlished: 已經建立鏈接;
TCP建立鏈接前兩次握手的特點:
ACK和ack的區別:
大寫的ACK(Acknowledgement)是標識位， 可以通過它標識包的性質， [ACK] or [SYC] or [FIN] .
小寫的ack(Acknowledgement Number), 是確認號。 即收到seq=x 的數據包後，回復 ack=x+1 的確認。
狀態解讀
FIN-WAIT1: 表示向主動斷開, 向對方發送了FIN報文後進入FIN-WAIT1狀態;
CLOSE-WAIT: 表示等待關閉, 當對方發送FIN報文給自己,會回應一個ACK報文, 同時進入CLOSE-WAIT狀態, 此狀態下如果仍然有數據發送給對方則會繼續發送, 如果沒有數據發給對方,則發送FIN給對方;
FIN-WAIT2: 主動方收到對方的ACK報文後就會處於FIN-WAIT2狀態然後等待對方的FIN報文;
LASK-ACK: 被動一方在發送FIN報文後處於LAST-ACK狀態, 收到主動方的ACK報文後就進入CLOSED狀態;
TIME-WAIT: 主動方收到對方的FIN報文後回復ACK報文給對方並進入TIME-WAIT狀態, 等待2MSL時間後進入CLOSED狀態;
如果在FIN-WAIT1狀態下同時收到對方的FIN和ACK報文則直接進入TIME-WAIT狀態, 無需經過FIN-WAIT2狀態;
CLOSED: 關閉狀態;
CLOSING: 一種比較罕見的狀態, 表示發出FIN報文後沒有收到對方的ACK報文反而也收到了FIN報文,即雙方幾乎同時發送FIN報文時就會進入CLOSING狀態;表示雙方都在進行關閉鏈接;
細節補充
為了提高重傳的性能; 可靠性傳輸是在傳輸層進行控制的;
這個取決於系統的設置, 例如有些系統在重新傳輸5次後仍然不能成功, 就會發送reset報文( RST )斷開TCP鏈接;
三次握手的目的: 防止伺服器端一直等待, 浪費資源;
如果改成兩次握手會出現的情況: 假如client客戶端第一次發送的請求報文段, 因為網路延遲的原因, 在釋放鏈接後才到達伺服器端, 本來這是一個應該失效的請求鏈接, 但是server端收到這個請求後會誤認為這是client發送的新的鏈接請求, 於是sever端就會再次給client發送確認報文然後建立鏈接, 等待client發送數據過來, 這樣的話, server端就會一直處於鏈接狀態等待;
採用三次握手的方法可以防止上述情況發生:例如上述情況, client沒有向server發出確認, server端收不到確認就知道client不是建立鏈接;
另一種解析的思路 : client和server建立鏈接是為了相互交換數據, 所以得確保自己和對方的數據收發功能都處於正常狀態;
第一次握手: server端可以確認自己的接收功能和client端的發送功能正常;
第二次握手: client端可以確認自己的發送和接收功能都是正常, 並且server端的接收和發送功能都是正常的;
第三次握手: server端確認自己的發送功能和client的接收功能正常;;
第三次握手的時候server處於SYB-RCVD狀態, 如果等不到client端的ACK, server端會再次發送ACK+SYN包, 如果多次發送後仍然等不到client的ACK包, 則server端發送RST包, 強制斷開鏈接;
有必要, 而且不能省去, 原因如下: 假如Client在發送ACK報文後立即進入了斷開狀態, 然後因為網路狀態Server端沒有收到這個ACK報文則會重發FIN報文給Client, 則可能會出現的情況如下:
a. Client端沒有反應, Server重復嘗試發送FIN給Client, 浪費資源;
b. Client剛好有個新的應用分配了同一個埠, 新應用本是想建立鏈接, 結果收到FIN報文後就會進入斷開鏈接操作;
e
6. 計算機網路(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連接狀態名。狀態之間的箭頭表示可能發生的狀態變遷。箭頭旁邊的字表明引起這種變遷的原因，或表明發生狀態變遷後又出現什麼動作，在圖中粗實線箭頭表示對客戶進程的正常變遷，粗虛線箭頭表示對伺服器進程的正常變遷，細線箭頭表示異常變遷。
7. 三.傳輸層
傳輸層的 核心任務 ： 應用進程 之間提供 端到端 的 邏輯通信 服務
回顧：只有 主機 才有傳輸層，網路核心中的路由器、交換機、集線器等只用到 下三層 的功能
記：分復流擁尋差錯-可靠
一台計算機中，不同應用進程用 進程標識符(進程ID) 來區分
網路環境下：
TCP/IP 體系結構網路的解決方法：
在傳輸層使用協議埠號，通常簡稱為埠(port)， 在全網范圍內利用 IP地址+埠號 唯一標識一個通信端行辯點
傳輸層埠號為16位整數，可以編號65536個(2的16次方）
常用埠： 埠號小於256的埠
傳輸層埠號：
1、伺服器端使用的埠號：熟知埠號和登記埠號
2、客戶端使用的埠號臨時性，在客戶進程運行時由操作系統隨機選取唯一的未被使用的埠號：
多路復用 ：在源主機，傳輸層協議從不同的套接字收集應用進程發送的數據塊，並為每個數據塊封裝上首部信息(包括用於分解的信息)構成報文段，然後將報文段傳遞給網路層
多路分解 ： 在目的主機，傳輸層協議讀取報文段中的欄位，標識出接收瞎帶臘套接字，進而通過該套接字，將傳輸層報文段中的數據交付給正確的套接磨滑字
多路復用與多路分解(復用與分解/復用與分用)： 支持眾多 應用進程共用 同一個傳輸層協議，並能夠將接收到的數據准確交付給 不同的應用進程
用戶數據報協議(User Datagram Protocol, UDP)：Internet提供無連接服務的傳輸層協議
UDP套接字二元組：<目的IP地址，目的埠號>
傳輸控制協議(Transmission Control Protocol, TCP)： Internet提供面向連接服務的傳輸層協議
TCP套接字四元組: <源IP地址，源埠號，目的IP地址，目的埠號>
基於不可靠信道實現可靠數據傳輸採取的措施
差錯檢測：利用編碼實現數據報傳輸過程中的比特差錯檢測
確認： 接收方向發送方反饋接收狀態。 ACK(肯定確認) ；NAK(否定確認)
重傳：發送發 重新 發送接收方沒有正確接收的數據
序號：確保數據按序提交(對數據進行編號，即便不按序到達，可以按序提交)
計時器： 解決 數據丟失問題
TCP提供可靠數據傳輸服務
UDP不提供可靠數據傳輸服務
最簡單的自動重傳請求協議是停等協議
流水線協議：管道協議，允許發送方在沒有收到確認前連續發送 多個 分組
最典型的流水線協議： 滑動窗口協議
1、 增加分組序號
2、發送方和接收方可以緩存多個分組
發送方的發送窗口：發送方可以發送未被確認分組的最大數量
接收方的接收窗口: 接收方可以緩存到正確到達的分組的最大數量
發送：
接收：
滑動窗口協議：根據窗口的大小，可以具體分為：
回退N步協議：GBN協議(Go-Back-N)
選擇重傳協議：SR協議(Selective Repeat)
GBN協議： 發送窗口>=1； 接收窗口=1 ；
發送端 緩存能力高，可以在沒有得到確認前發送多個分組
接收端 緩存能力很低，只能接收一個按序到達的分組，不能緩存未按序到達的分組
GBN發送方響應的3類事件：
SR協議： 發送窗口>1 接收窗口>1
發送端緩存能力高
接收端緩存能力高
SR發送方響應事件：
用戶數據協議（User Datagram Protocal, UDP）: Internet 傳輸層 協議，提供 無連接 、不可靠、數據報盡力傳輸服務
0-15-31： 32位二進制
UDP首部四個欄位： 每個欄位長度都是2位元組，共8個位元組
源埠號和目的埠號：UDP實現復用和分解
長度：指示UDP報文段中的位元組數(首部和數據的總和)
校驗和：接收方使用檢測數據報是否出現差錯
應用數據欄位：應用層數據佔用
UDP校驗和：提供差錯檢測功能
UDP的校驗和用於檢測UDP報文段從源到目的地傳送過程中，其中的數據是否發生了改變
UDP校驗和計算規則
1、所有參與運算的內容按16位對齊求和
UDP校驗和計算的內容包括3部分：UDP偽首部、應用數據
傳輸控制協議(Transmission Control Protocol ,TCP): Internet 傳輸層協議
提供面向連接、可靠、有序、位元組流傳輸服務
第一：應用進程 先建立連接
第二：每一條TCP連接只有 兩個 端點
第三： 可靠交付 ：無差錯、不丟失、不重復、按序到達
第四： 全雙工 通信
第五：面向 位元組流
流：位元組序列，應用程序和TCP的交互是一個個數據塊，TCP把他們看做是無結構位元組流
1、源埠號欄位、目的埠號欄位：佔16位、復用和分解上層應用的數據
2、序號欄位、確認序號欄位：佔32位
序號欄位：TCP序號是對每個應用層數據的每個位元組進行編號
確認序號欄位：期望從對方接受數據的位元組序號，即該序號對應的位元組尚未收到
9.選項欄位長度可變，最短為0位元組，最長為40位元組
TCP連接管理：連接建立與連接拆除
以客戶端上的一個應用進程與伺服器上的一個應用進程建立一條TCP連接為例
一、建立連接
第一次握手：
客戶向伺服器發送連接請求段：(SYN=1, seq=x)
SYN = 1; 建立連接請求控制段
seq=x; 表示傳輸的報文段第1個數據位元組的序列號是x，此序列號代表整個報文段的序號
客戶端進入SYN_SEND （同步發送）
第二次握手：
服務端發回確認報文段：(SYN=1, ACK=1,seq=y,ack_seq=x+1)
SYN=1 同意建立新連接的確認段
ack_seq = x + 1; 表示已經收到序列號為x的報文段，准備接受序列號為x+1的報文段
seq=y : 伺服器告訴客戶確認報文段的序列號是y
伺服器由LISTEN進入SYN_RCVD（同步收到）
第三次握手
客戶端對伺服器的同意連接報文段進行確認：(ACK=1,seq=x+1, ack_seq=y+1)
seq=x+1 : 客戶端此次的報文段的序列號是x+1;
ack_seq = y+1 : 客戶端期望接收伺服器序列號y+1的報文段
當客戶端發送ACK時，客戶端進入ESTABLISHED狀態
當服務端收到ACK後，也進入ESTABLISHED狀態
第三次 握手可攜帶數據
二、連接拆除：四次揮手
第一次揮手
客戶端向伺服器發送釋放連接報文段：(FIN=1, seq=u)
FIN=1.發送端數據發送完畢，請求釋放連接
seq=u 傳輸的第一個數據位元組的序號是u
客戶端狀態由ESTABLISHED進入FIN_WAIT_1(終止等待1狀態)
第二次揮手
伺服器向客戶發送確認段：（ACK=1, seq=v, ack_seq=u+1）
ACK=1； 確認字型大小段有效
ack_seq=u+1 : 伺服器期望接受客戶數據序號為u+1
seq=v: 伺服器傳輸的數據序號是v
伺服器狀態由ESTABLISHED進入CLOSE_WAIT(關閉等待)
客戶端收到ACK段後，由FIN_WAIT_!進入FIN_WAIT_2
第三次揮手
伺服器向客戶發送釋放連接報文段：(FIN=1, ACK=1, seq=v+1, ack_seq=u+1)
FIN =1: 請求釋放連接
ACK = 1：確認字型大小段有效
ack_seq=u+1: 表示伺服器期望接受客戶數據序列號為1
seq=v+1 表示自己傳輸的第一個數據位元組的序號是v+1
伺服器狀態由CLOSE_WAIT進入LAST_ACK(最後確認狀態)
第四次揮手：
客戶向伺服器發送確認段：（ACK=1,seq=u+1,ack_seq=w+1）
ACK=1: 確認字型大小段有效
ack_seq=v+1+1 : 表示客戶期望接受伺服器數據序號為v+1+1
seq=u+1 表示客戶傳輸的數據的序號是u+1
客戶端狀態由FIN_WAIT_2進入TIME_WAIT 等待2MSL時間，進入CLOSED狀態
伺服器再收到最後一次ACK後，由LAST_ACK進入CLOSED
一、可靠：保證接收方應用進程從緩沖區讀出的位元組流與發送發發出的位元組流是完全一樣的
二、TCP實現可靠數據傳輸服務的工作機制
1、應用層數據被 分割 成TCP認為最適合發送的數據塊
2、序號,發送方對發送的數據包進行編號，確保數據按序提交給接收方 採用累積確認
3、確認，接收方向發送方反饋接收狀態，確認是否正確接收數據
4、差錯檢測，利用差錯編碼實現數據包傳輸過程中的比特差錯檢測（甚至糾正）
5、重傳，發送方重新發送接收方沒有正確接收的數據
6、計時器，在發送方引入計時器，解決數據丟失問題
最大報文段長度：1500位元組
報文段中封裝的應用層數據的最大長度：1480位元組 = 1500 - 最短的首部長度
TCP生成ACK的策略
流量控制：協調發送方與接收方的數據發送與接收 速度
在通信過程中，接收方設置報文段的 接收窗口欄位 來將窗口大小通知給發送方
一、網路擁塞： 太多的主機``以太快的速度 向網路中發送 太多的數據 ，超出了網路處理能力，導致大量數據分組擁擠在中間設備隊列中等待轉發， 網路性能 顯著下降的現象
二、擁塞控制：通過合理調度、規范、調整向網路中發送數據的主機數量、發送速率、數據量、以 避免 擁塞或 消除 已發生的擁塞
三、概念補充介紹
四、TCP擁塞控制演算法
閾值之前：慢啟動階段
閾值之後：擁塞避免階段
l例如： 發生計時器超時，當前擁塞窗口24MSS，當前閾值為16MSS
新的閾值：為當前擁塞窗口的一半，新的閾值=24/2=12MSS
新的擁塞窗口：直接調整為1MSS 新的擁塞窗口=1MSS
調整好新的閾值和新的擁塞窗口之後，使用 慢啟動。擁塞避免 演算法增加擁塞窗口大小
例如：發送3次重復確認時，當前擁塞窗口為24MSS，當前閾值為16MSS
新的閾值：為當前擁塞窗口的一半
新的擁塞窗口：調整為新的閾值
調整好新的閾值和新的擁塞窗口後，使用 擁塞避免 演算法增加擁塞窗口大小
五、窗口調整的基本策略（Additive Increase，Multiplicative Decrease, AIMD）:
網路未發生擁塞時：逐漸"加性"增大窗口
網路擁塞時「乘性」減小窗口
六、擁塞預防策略：流量整型技術：規范主機向網路發送數據的流量
8. 計算機網路傳輸層
端到端的連接
網路層：提供主機之間的邏輯通信
傳輸層慎銷寬：提供應用進程之間的邏輯通信
位於網路層之上、依賴網路層服務、對網路層服務進行可能的增強
接收端：多路分用
相同目的地址目的埠號的UDP會被導向同一個socket
每個srcIp srcPort DestIp DestPort 導向自寬亮己獨有的socket(創建多個socket)
(伺服器也可以讓一個進程創建多個線程與tcp連接綁定)
發送端：多路復用
什麼是可靠？ 不錯、不亂、不丟
可靠數據傳輸協議
GBN
1.發送方 分組頭部包含k-bit序列號
窗口尺寸為N，最多允許N個分組未確認
序列號 ：表示本報文段所發送數據的第一個位元組的編號。而不是報文段的編號（這里防止被攻擊混入其他的段難以檢測的問題）。
建立TCP連接時，雙方隨即選擇序列號
ACKs 表示接收方期望收到發送方下一個報文段的第一個位元組數據的編號。
累計確認：該序列號之前所有的位元組均已被正確接收到（GBN）
TCP在IP層提供的不可靠服務基礎上實現可靠數據傳輸服務
流水線機制
累積確認
TCP使用單一重傳定時器
觸發重傳的事件
超時
收到重復ACK
漸進式
暫不考慮重復ACK
暫不考慮流量控制
暫不考慮擁塞控制
1.點對點 一個sender 一個 reciever
2.可靠的、按序的位元組流
3.流水線機制
案例：
何時應該指數性增長切換為線性增長(擁塞避免)?
當CongWin達到Loss事件前值的1/2時.
實現方法:利用一個變數 Threshold， Loss事件發生時, Threshold被設為Loss事件前CongWin值的1/2。
Loss事件處理辦法
3個重復ACKs:CongWin切到一半然後線性增長
Timeout事件:CongWin直接設為1個MSS，然後指數增長，達到threshold後, 再線性增長（擁塞更嚴重了）
TCP擁塞控制演算法
4.接收方/發送方緩存
5.全雙工：同一連接中能傳輸雙數據流
6.面向連接(連接管理)
TCP連接包括：兩台主機上的緩存、連接狀態變數、socket等
客戶端初始化的序列號是隨機的
7.流量控制機制：發送方不會傳輸的太多、太快以至於淹沒接收方（buffer溢出）
8.復用/分用
1.基於「盡力而為」的網路層，沒有做（可靠性）
丟失
非按序到達
2.基於Internet IP協議
復用/分用
簡單的錯誤校驗
3.無連接
UDP發送方和接收方之間不需要握手
每個UDP段的處理獨立於其他段
UPD優點：
1.無需建立連接（減少延遲）-DNS
2.實現簡單，無需維護連接狀態
3.頭部開銷小（8byte）
4.沒有擁塞控制：應用可更斗簡好的控制發送時間和速率
常用於流媒體應用
1.容忍丟失
2.速率敏感
DNS/SNMP
在UDP上實現可靠數據傳輸
UDP校驗和：檢測UDP段在傳輸過程中是否發生錯誤
9. 【網路協議筆記】第四層:傳輸層(Transport)TCP協議簡介(1)
TCP有以下幾個知識點。
圖片備用地址
圖片備用地址
TCP的幾個要點：可靠傳輸、流量控制、擁塞控制、連接管理（建立和釋放連接）。
也正因為這幾點使得首部變得很復雜。
佔4位，取值范圍是0x0101 ~ 0x1111。
乘以4就是首部長度（Header Length）。所以取值范圍是5 ~ 60位元組，由於首部固定部分佔用20位元組，所以可選部分至多佔用40位元組（和網路層首部一樣）。
為什麼叫數據偏移？因為相對TCP報文向右偏移首部長度後就是數據部分。
UDP的首部中有個16位的欄位記錄了整個UDP報文段的長度（首部 + 數據）。
但是，TCP的首部中僅僅有個4位的欄位記錄了TCP報文段的首部長度，並沒有欄位記錄TCP報文段的數據長度。
分析：UDP首部中佔16位的長度欄位是冗餘的，純粹是為了保證首部是32bit對齊。
TCP/UDP的數據長度，完全可以由IP數據包的首部推測出來，傳輸層的數據長度 = 網路層的總長度 - 網路層的首部長度 - 傳輸層的首部長度。
佔6位，目前全為0。
與UDP一樣，TCP檢驗和的計算內容：偽首部 + 首部 + 數據。偽首部佔用12字納枯叢節，僅在計算檢驗和時起作用，並不會傳遞給網路層。
圖片備用地址
一共佔6位或9位。
有些資料中，TCP首部的保留（Reserved）欄位佔3位，標志（Flags）欄位佔9位。Wireshark中也是如此。是因為標志位中的前3位是無用的，所以兩種說法都不能說是錯的。
圖片備用地址
圖片備用地址
意思：緊急。當URG=1時，緊急指針欄位才有效。表明當前報文段中有緊急數據，應優先盡快傳送。
緊急指針存放的是長度值，表示TCP的前多少位元組是需要緊急優先處理的。
意思：確認。當ACK=1時，確認號欄位才有效。
意思：推。一般用在互動式網路中。PUSH標志位所表達的是發送方通知接收方傳輸層應該盡快的將這個報文段交給應用層。
意思：重置。當RST=1時，表明連接中出現嚴重差錯，必須釋放連接，然後再重新建立連接。
意思：同步。當SYN=1 & ACK=0時，表明這是一個建立連接的請求。若對方同意建立連接，則回復SYN=1 & ACK=1。
請求方再發送SYN=0 & ACK=1時表明開始傳輸數據。這也是三次握手的流程。
意思：完成。表明數據已經發送完畢，要求釋放連接。
佔4位元組。首先，傳輸的每一個位元組都會有一個編號（連續的位元組編號也是連續的）。
在建立連接後，序號代表這一次傳給對方的TCP數據部分的第一個位元組的編號。
佔4位元組。在建立連接後，確認號代表期望對方下一次傳過來的TCP數據部分的第一個位元組的編號。
佔2位元組。這個欄位有流量控制功能，用以告知對方下一次允許發送的數據大小（位元組為單位）。
ARQ(Automatic Repeat-reQuest), 自動重傳請求。
圖片備用地址
無差錯情況
A發送數據M1到B，B收到數據M1後向A發送確認信號M1；
A收到確認信號M1後，繼續洞櫻向B發送數據M2，B接收後向A發送確認信號M2。
超時重傳
A發送數據M1到B，A在發送數據途中丟包敗蔽或B發現數據M1有錯誤直接丟掉，導致B無法向A發送確認信號M1；
A在一定時間間隔後發現沒有收到B發送的確認信號M1，A會繼續向B發送數據M1；
B收到數據M1後向A發送確認信號M1，A收到確認信號M1後，繼續向B發送M2數據。
通過確認與超時重傳機制實現可靠傳輸，在發送完一個分組後，必須暫時保留已發送的分組的副本。
分組和確認分組都必須進行編號。超時計時器的重傳時間應當比數據在分組傳輸的平均往返時間更長一些。
圖片備用地址
確認丟失
A發送數據M1到B，B接收到數據M1後，向A發送確認信號M1；
B在向A發送確認信號M1中途丟包，此時A在一定時間間隔後發現沒有收到B發送的確認信號M1，A會繼續向B發送數據M1；
B收到數據M1後會丟棄重復的數據M1（之前已經收到數據M1，只是A不知道），繼續向A發送確認信號M1；
A收到確認信號M1後，繼續開始發送M2數據。
確認遲到
A發送數據M1到B，B接收到數據M1後，向A發送確認信號M1；
B在向A發送確認信號M1時，由於網路延遲等原因導致A在一定時間段內未收到確認信號；
A會繼續向B發送數據M1，B收到數據M1後丟棄重復的數據M1，並向A發送確認信號M1；
A收到確認信號M1後，繼續開始發送M2數據，M2數據剛發送出去，此時A剛好接收到B在第一次發送的確認信號M1，
但由於之前已經成功接收並處理了第二次的確認信號M1，所以A在收到確認信號後什麼也不做。
出現差錯或丟失的時候，發送方會將自己備份的副本再重傳一次，直到收到接收的確認信息。
當接收方收到重復的數據時，會直接丟棄，但是會給發送方請確認自己已經收到了。
上面的停止等待協議每發送一組數據就必須等到接收方回復確認後，再發起第二組數據，如果出現超時重傳的話，效率更低。
因此為了提高傳輸的效率，改進了等待傳輸協議。
連續ARQ協議和滑動窗口協議的機制是以接收方回復確認為單位，每次連續發送一個滑動窗口指定的數據組。
圖片備用地址
A發送數據給B時，一次性發送M1~M4（A和B建立連接時，B告訴A自己的緩存池可以容納多少位元組數據，
A根據這個緩存池的大小構建一個同大小的發送窗口–也可以理解為發送緩存池），此時A開始等待確認，B收到全部數據後會向A發送確認信號M4（以最後一個編號為准）；
A收到確認信號後，繼續向B發送M5 M8（A把之前構建的窗口滑動並鎖定到對應大小的數據段上，即M5 M8），以此往復直到數據傳輸完畢。
如果接收窗口最多能接收4個包（窗口大小），但發送方只發了2個包，接收方如何確定後面還有沒有2個包？
答案：接收方會在等待一定時間後發現沒有第3個包，就會返回收到2個包的確認信號給發送方。
滑動窗口是由發送方維護的類似指針的變數，在每收到一個接收方的確認消息後，
該指針向前移動並發送數據，到窗口指定大小的數據組時停下，等待接收方的確認。
圖片備用地址
累積確認機制： 發送方不對收到的分組逐個發送確認，而是對按序到達的最後一個分組發送確認，
這樣就表示：到這個分組為止的所有分組都已正確收到了。
優點：容易實現，即使確認丟失也不必重傳。
缺點：不能向發送方反映出接收方已經正確收到的所有分組的信息。
Go-back-N（回退 N）： 為了解決上述同一窗口中數據組不能完整確認的問題，連續ARQ協議採用了回退機制。
比如說：發送方發送了前5個分組，而中間的第3個分組丟失了。這時接收方只能對前兩個分組發出確認。
發送方無法知道後面三個分組的下落，而只好把後面的三個分組都再重傳一次。這就叫做 Go-back-N（回退 N），表示需要再退回來重傳已發送過的N個分組。
結論：當通信線路質量不好時，連續ARQ協議會帶來負面的影響。可能還不如傳統的停止等待協議。
TCP連接的每一端都必須設有兩個窗口——一個發送窗口和一個接收窗口。
TCP的可靠傳輸機制用位元組的序號進行控制。TCP所有的確認都是基於序號而不是基於報文段。
TCP兩端的四個窗口經常處於動態變化之中。
TCP連接的往返時間RTT也不是固定不變的。需要使用特定的演算法估算較為合理的重傳時間。
滑動窗口是面向位元組流的，為了方便記住每個分組的序號，
現在假設有一個1200位元組的數據，分12組，每一組數據是100個位元組，代表一個數據段的數據（每一個數據都有自己的TCP首部），每一組給一個編號（1~12）。
圖片備用地址
圖片備用地址
TCP通信時，如果發送序列中間某個數據包丟失，TCP會通過重傳最後確認的分組後續的分組，這樣原先已經正確傳輸的分組也可能重復發送，降低了TCP性能。
SACK（Selective Acknowledgment，選擇確認）技術 ，使TCP只重新發送丟失的包，不用發送後續所有的分組，
而且提供相應機制使接收方能告訴發送方哪些數據丟失，哪些數據已經提前收到等。
在建立TCP連接時，就要在TCP首部的選項中加上「允許SACK」的選項，而雙方必須都事先商定好。
原來首部中的「確認號欄位」的用法仍然不變。只是以後在TCP報文段的首部中都增加了SACK選項，以便報告收到的不連續的位元組塊的邊界。
圖片備用地址
Kind：佔1個位元組，值為5代表這是SACK選項。
Length：佔1個位元組，表明SACK選項一共佔用多少位元組。
Left Edge：佔4個位元組，左邊界。
Right Edge：佔4個位元組，右邊界。
圖片備用地址
上圖的著色模塊代表已接收數據，空白代表未接收數據。左右邊界意思是會把未接收完畢的TCP數據包的已接收數據進行左右標記。
由於TCP的選項不能超過40個位元組，去除Kind和Length佔用的2個位元組，還剩下38個位元組給左右邊界使用。
一組邊界佔用8個位元組（左右邊界各佔4個位元組），所以邊界不能超過4組。也能夠因此推斷出SACK選項的最大佔用位元組數是4 * 8 + 2 = 34。
思考：超過選項邊界的數據怎麼辦？
超過邊界的數據需要重新傳輸，但這已經很大程度提高了傳輸效率。
重傳機制是TCP中最重要和最復雜的問題之一。TCP每發送一個報文段，就對這個報文段設置一次計時器。
只要計時器設置的重傳時間到但還沒有收到確認，就要重傳這一報文段。那麼這個重傳時間到底應該設置多少呢？建議跳過，有興趣的可以去查閱相關資料。
圖片備用地址
為什麼選擇在傳輸層就將數據分割成多個段，而不是等到網路層再分片傳遞給數據鏈路層？
-->網路層沒有可靠傳輸協議，丟包無法只發送一個報文段，所以需要分割成多個段。
如果在傳輸層不分段，一旦出現數據丟失，整個傳輸層的數據都得重傳
如果在傳輸層分段了，一旦出現數據丟失，只需要重傳丟失的那些段即可
歡迎大家的意見和交流
email: [email protected]