tcp
tcp 特點
tcp 是面向連線的運輸層協議，乙個應用程序在向另乙個程序傳送資料之前，兩個程序必須先建立 tcp連線，傳送某些預備報文段，建立確保資料傳輸的引數。作為 tcp 連線建立的一部分，連線雙方都將初始化與 tcp 連線相關的許多狀態變數。這種連線不是電路交換網路中的端到端電路這種物理連線，而是一種邏輯連線，tcp 報文要先傳送到 ip 層加上 ip 首部後，再傳到資料鏈路層，加上鏈路層的首部和尾部後才離開主機傳送到物理層。
tcp 連線提供全雙工服務，允許通訊雙方的應用程序在任何時候都能傳送資料。tcp 連線的兩端都有各自的傳送快取和接收快取，用來臨時存放通訊資料。在傳送時，應用程式把資料傳送給 tcp 快取後就可以做自己的事，而 tcp 在合適的時候會把資料傳送出去。在接收時，tcp 把收到的資料放入快取，上層應用程式會在合適的時候讀取快取資料。
tcp 連線是點對點的，每一條 tcp 連線只能有兩個端點，即只能是單個傳送方和單個接收方之間的連線。
tcp 提供可靠的交付服務，通過 tcp 連線傳送的資料無差錯、不丟失、不重複，按序到達。
tcp 是面向位元組流的，流是指流入到程序或從程序中流出的位元組序列。面向位元組流的含義是：雖然應用程式和 tcp 的互動是一次乙個資料塊，但是 tcp 把應用程式交下來的資料僅僅看成一連串無結構的位元組流。tcp 不保證接收方應用程式收到的資料塊和傳送方應用程式發出的資料塊具有對應大小的關係，但是接收方應用程式收到的位元組流必須和傳送方應用程式發出的位元組流完全一樣。接收方應用程式必須
有能力識別收到的位元組流，並把它還原成有意義的應用層資料。
可靠傳輸協議 arq
自動重傳請求 arq 包括了停止等待協議、回退 n 步協議和選擇重傳協議，後兩種結合了視窗機制，屬於連續 arq 協議
tcp 可靠原理
tcp 的可靠傳輸包含很多機制，例如使用檢驗和來檢測乙個傳輸分組中的位元錯誤、使用定時器來用於超時重傳乙個分組、使用序號來檢測丟失的分組和冗餘副本、使用確認來告訴傳送方確認的分組資訊、使用否定確認來告訴傳送方某個分組未被正確接收。tcp 的傳送方僅需維持已傳送過但未被確認的位元組的最小序號和下乙個要傳送的位元組的序號，從這種角度看 tcp 更像乙個 gbn 協議。但是 tcp 和 gbn 有一些顯著的區別，許多 tcp 實現會將正確接收但失序的報文段快取起來。當分組 n 丟失時，gbn 會重傳 n 之後的所有分組，但是 tcp 至多只會重傳分組n。對 tcp 提出的一種修改意見是選擇確認，它允許 tcp 接收方有選擇地確認失序報文段，而不是累積地確認最後乙個正確接收的有序報文段，從這個角度看 tcp 又像 sr 協議。因此 tcp 的差錯恢復機制是一種 gbn 和 sr 的結合體。除此之外，tcp 還使用流量控制和擁塞控制來保證可靠性。
滑動視窗
滑動視窗以位元組為單位。傳送端有乙個傳送視窗，視窗中的序號是允許傳送的序號，視窗的後沿是已經傳送並且確認的序號，視窗的前沿是不允許傳送的序號。視窗的後沿可能不動（代表沒有收到新的確認），也有可能前移（代表收到了新的確認），但是不會後移（不可能撤銷已經確認的資料）。視窗的前沿一般是向前的，也有可能不動（表示沒有收到新的請求或對方的接收視窗變小），也有可能收縮，但 tcp 強烈不建議這麼做，因為傳送端在收到通知前可能已經傳送了很多資料，此時如果收縮視窗可能會產生錯誤。
滑動視窗的狀態需要3個指標p1，p2 和 p3。p1 之前的序號表示已經傳送並且確認的序號，p1~p2 的序號表示已經傳送但還沒有確認的序號，p2~p3 表示允許傳送的序號，也叫可用視窗，p1~p3 表示傳送視窗，p3 之後的序號表示不可傳送的序號。
傳送快取用來暫時存放傳送應用程式傳給傳送方 tcp 準備傳送的資料和已經傳送但還沒確認的資料。接收快取用來暫時存放按序到達的但尚未被應用程式讀取的資料以及未按序到達的資料。
注意三點：① 傳送視窗根據接收視窗設定，但並不總是一樣大，還要根據網路的擁塞情況調整。② 對於不按序到達的資料，tcp 通常存放在接收視窗，等到位元組流缺少的位元組收到後再按序交付上層應用程式。③ 接收方必須有累積確認功能，可以減小傳輸開銷，可以在合適的時候傳送確認，也可以在自己有資料需要傳送時捎帶確認。但是接收方不能過分推遲傳送確認，不能超過0.5秒。
流量控制
如果某個應用程式讀取資料的速度較慢，而傳送方傳送得太多、太快，傳送的資料就會很容易使連線的接收快取溢位，tcp 為它的應用程式提供了流量控制以消除傳送方使接收方快取溢位的可能性。流量控制是乙個速度匹配服務，即傳送方的傳送速率與接收方的應用程式讀取速率相匹配。
tcp 通過讓傳送方維護乙個接收視窗的變數來提供流量控制。通俗地說，接收視窗用於給傳送方乙個指示，該接收方還有多少可用的快取空間，因此方法方的傳送視窗不能超過接收方給出的接收視窗的數值。因為 tcp 是全雙工通訊，在連線兩端的傳送方都各自維護乙個接收視窗。
當接收視窗 rwnd 減小到 0 時，就不再允許傳送方傳送資料了。但是可能存在一種情況，當發生了零視窗報文段不久後，傳送方的接收快取又有了一些儲存空間，因此又發生了新的報文說明自己的接收視窗大小，但是這個報文可能會在傳輸過程中丟失。接收方就會一直等待傳送方的非零視窗通知，而傳送方也一直在等待接收方傳送陣列，形成一種死鎖的狀態。為了解決這個問題，tcp 為每乙個連線設有乙個持續計時器，只要 tcp 連線的一方收到對方的零視窗通知就啟動該計時器，到期後傳送乙個零視窗探測報文，如果仍為 0 就重新設定計時器的時間，如果對方給出了新的視窗值就可以解決可能出現的死鎖問題。
還有一種問題叫做糊塗視窗綜合症，當接收方處理接收緩衝區資料很慢時，就會使應用程序間傳送的有效資料很小， 極端情況下有效資料可能只有 1 位元組但傳輸開銷卻有 40 位元組（20位元組的 ip 頭以及 20 位元組的 tcp 頭) ，導致網路效率極低。為了解決這個問題，可以讓接收方等待一段時間，使得接收快取有
足夠的空間容納乙個最長報文段或者等到接收快取已有一半的空閒空間。傳送方也不要傳送太小的報文，而是把資料積累成足夠大的報文或達到接收方快取空間的一半時才傳送。
擁塞控制
網路中對資源需求超過了資源可用量的情況就叫做擁塞。當吞吐量明顯小於理想的吞吐量時就出現了輕度擁塞，當吞吐量隨著負載的增加反而下降時，網路就進入了擁塞狀態。當吞吐量降為 0 時，網路已無法正常工作並陷入死鎖狀態。擁塞控制就是儘量減少注入網路的資料，減輕網路中的路由器和鏈路的負擔。擁塞控制是乙個全域性性的問題，它涉及網路中的所有路由器和主機，而流量控制只是乙個端到端的問題，是兩個端點之間通訊量的控制。
根據網路層是否為運輸層擁塞控制提供顯式幫助可以將擁塞控制的方法區分為兩種：端到端擁塞控制和網路輔助的擁塞控制。tcp 使用端到端的擁塞控制，因為 ip 層不會向端系統提供顯式的網路擁塞反饋。tcp 所採取的方法是讓每乙個傳送方根據所感知到的網路擁塞程度來限制其向連線傳送資料的速率。如果乙個 tcp 傳送方感知到它到目的地之間的路徑上沒什麼擁塞則會增加傳送速率，如果傳送方感知到擁塞就會降低其傳送速率。限制傳送速率是通過擁塞視窗來實現的，它對傳送方能向網路中傳送流量的速率進行了限制。判斷擁塞是通過超時或者連續接收到 3 個冗餘 ack 實現的。
tcp 的擁塞控制演算法主要包括了慢啟動、擁塞避免和快恢復。慢啟動和擁塞避免是 tcp 的強制部分，差異在於對收到的 ack 做出反應時 cwnd 增加的方式，慢啟動比擁塞避免要更快地增加 cwnd 的長度。快恢復是推薦部分，對 tcp 傳送方不是必需的。
tcp 連線和釋放機制
三次握手
tcp 是全雙工通訊，任何一方都可以發起建立連線的請求，假設 a 是客戶端，b 是伺服器。初始 a 和 b 均處於 closed 狀態，b 會建立傳輸程序控制塊 tcb 並進入 listend 狀態，監聽埠是否收到了 tcp 請求以便及時響應。
當 a 要發生資料時就向 b 傳送乙個連線請求報文，tcp 規定連線請求報文的 syn=1，ack=0，syn 不可以攜帶資料，但要消耗乙個序號，假設此時 a 傳送的序號 seq 為 x。傳送完之後 a 就進入了 synsent 同步已傳送狀態。
當 b 收到 a 的連線請求報文後，如果同意建立連線就會傳送給 a 乙個確認連線請求報文，其中syn=1，ack=1，ack=x+1，seq=y，ack 的值為 a 傳送的序號加 1，ack 可以攜帶資料，如果不攜帶的話則不消耗序號。傳送完之後，b進入 syn-rcvd 同步已接收狀態。
當 a 收到 b 的確認連線請求報文後，還要對該確認再進行一次確認，報文的 ack=1，ack=y+1，seq=x+1，傳送後 a 進入 established 狀態，當 b 接收到該報文後也進入 established 狀態，客戶端會稍早於伺服器端建立連線。
三次握手的原因主要有兩個目的，資訊對等和防止超時。
從資訊對等的角度看，雙方只有確定 4 類資訊才能建立連線，即 a 和 b 分別確認自己和對方的傳送和接收能力正常。在第二次握手後，從 b 的角度看還不能確定自己的傳送能力和對方的接收能力，只有在第三次握手後才能確認。
三次握手也是防止失效連線突然到達導致髒連線，網路報文的生存時間往往會超過 tcp 請求超時時間，a 的某個超時連線請求可能會在雙方釋放連線之後到達 b，b 會誤以為是 a 建立了新的連線請求，然後傳送確認報文建立連線。因為 a 機器的狀態不是 syn_sent，所以直接丟棄了 b 的確認資料。如果是兩次握手，連線已經建立了，伺服器資源被白白浪費。如果是三次握手，b 由於長時間沒有收到確認資訊，最終超時導致建立連線失敗，因此不會出現髒連線。
tcp 和 udp 的區別
2021秋招計算機網路面試準備
ip位址分類 osi與tcp ip各層的結構與功能 ping的整個過程。icmp報文是什麼?tcp與udp區別及其各自優缺點 tcp和udp資料報格式 tcp擁塞控制和流量控制 3次握手和4次揮手過程 time wait狀態的作用，造成的後果，以及如何避免？解釋arp，dns 滑動視窗與回退n針協議...
C 秋招記錄（五） 計算機網路
9 客戶端不斷進行請求鏈結會怎樣？ddos distributed denial of service 攻擊？10 從輸入 到獲得頁面的過程 計算機網路 執行緒 程序相關問題 除了7 8 9都被問過 tcp的三次握手過程如下 三次握手的原因 三次握手可以防止已經失效的連線請求報文突然又傳輸到伺服器端...
秋招材料整理 基礎（計算機網路等）
二 tcp四次揮手 三 udp vs.tcp 四 程序 vs.執行緒 五 程序狀態 六 程序間通訊 七 死鎖，產生條件 八 python裡面字典底層怎麼實現的 九 動態規劃 vs.貪心演算法 十 堆疊區別 十一 排序複雜度 1 首先 b 處於 listen 監聽 狀態，等待客戶的連線請求。2 a 向...