三次握手齊白首，四次揮手說分手
本篇博文其實並不只是學習三握手四揮手，而是總結計網傳輸層的內容，只是這八個字在傳輸層中地位實在太重了…故單列出來做標題，當然，你耳熟能詳的滑動窗口這裏也會涉及到
傳輸層之下的層之前也已經寫了…推薦你閱讀
計算機網絡-網絡層-詳細總結
說起來TCP的連接與釋放真是個浪漫的故事呢！~
文章目錄
TCP/IP協議概述
在TCP/IP協議棧，傳輸層有兩個協議TCP和UDP
TCP（Transmission Control Protocol，傳輸控制協議）協議：負責將要傳輸的文件分段 進行傳輸，一般用於建立會話 ，其基本特性是可靠傳輸 、流量控制，所謂三握手、四揮手也是基於TCP協議的
UDP（User Data Protocol，用戶數據報協議）協議：一個數據包就能夠完成數據通信 ，數據包不分段 ，不需要建立會話 ，不需要流量控制 ，屬於不可靠傳輸 ， 屏幕廣播 、多播 、廣播都是基於UDP協議
以上定義，下面來詳講
傳輸層協議的作用體現在應用層協議
TCP和UDP協議內指定不同的端口即可對應一個應用層的協議
端口代表主機服務的偵聽"門牌號"，不管是TCP還是UDP，帶上門牌號，它就能幫你找到主機上的對應服務
例如我們在瀏覽器訪問某個網站地址，這個動作會被我們本機上的80端口偵聽到，並處理你的網絡請求
我們主機上常見的應用層協議端口：
- HTTP默認使用TCP的80端口標識
- FTP默認使用TCP的21端口標識
- SMTP默認使用TCP的25端口標識
- POP3默認使用TCP的110端口
- HTTPS默認使用TCP的443端口
- DNS使用UDP的53端口
- 遠程桌面協議（RDP）默認使用TCP的3389端口
- telnet使用TCP的23端口Windows訪問共享資源使用TCP的445端口
但是我們通過TCP/UDP封裝的數據包，通過本機偵聽服務發送到目標主機，目標主機是如何識別並處理的呢？
如上圖，我們會在數據包中添加目標端口號，這樣目標主機相關服務偵聽到，就能處理我們的請求了
TCP/UDP傳輸層協議與網絡層協議的區別
- 網絡層實現如何把數據包從這個地址(服務器)發送到另一個地址(服務器)
- 傳輸層實現如何讓這個應用程序找到對應計算機的應用程序，即服務
說白了，IP協議主要讓數據能知道傳到哪去，不管對應目標誰來負責接待，而TCP/UDP管
越靠近頂層應用層、功能越強大
UDP協議
主要特點：
- UDP 是面向無連接的，即發送數據之前不需要建立連接，如向DNS服務器申請域名解析服務
- UDP 使用盡最大努力交付，即不保證可靠交付，同時也不使用擁塞控制
- UDP 是面向報文的。UDP 沒有擁塞控制，很適合多媒體通信的要求
- UDP 支持一對一、一對多、多對一和多對多的交互通信，這也是，應用場景如廣播、組播
- UDP 的首部開銷小，只有 8 個字節
基本描述：
UDP首部
首先得知道數據包在OSI模型中層層傳輸，自頂向下
來看看UDP首部
- 用戶數據報 UDP 有兩個字段：數據字段和首部字段。首部字段有 8 個字節，由 4 個字段組成，每個字段都是兩個字節
- 在計算檢驗和時，臨時把“僞首部”和 UDP 用戶數據報連接在一起。僞首部僅僅是爲了計算檢驗和，僞首部12個字節取自IP數據報的字段
- 檢驗和實現UDP數據檢驗，通過驗證檢驗和可以知道UDP數據包是否出現異常
TCP協議
基本特點：
TCP 是面向連接的傳輸層協議，UDP面向無連接
每一條 TCP 連接只能有兩個端點(endpoint)，每一條 TCP 連接只能是點對點的（一對一）
TCP 提供可靠交付的服務（持續交付）
TCP 提供全雙工通信（信道雙向傳輸）
面向字節流(傳送最小單位爲字節，即八位)
上圖可以看出TCP傳輸是如何面向字節流的，具體細節後面繼續解析
TCP連接基於Socket：
TCP 把連接作爲最基本的抽象，每一條 TCP 連接有兩個端點
TCP 連接的端點不是主機，不是主機的IP 地址，不是應用進程，也不是傳輸層的協議端口。TCP 連接的端點叫做套接字(socket)
IP地址+服務端口構成了套接字
TCP協議確保可靠傳輸
TCP使用自動重傳請求ARQ (Automatic Repeat reQuest)確保可靠傳輸
停止等待機制:
報文過不了檢驗的，被B丟棄，A發送發出去的報文無迴應、重新發送
請注意：
- 在發送完一個分組後，必須暫時保留已發送的分組的副本，方便重傳
- 分組和確認分組都必須進行編號
- 超時計時器的重傳時間應當比數據在分組傳輸的平均往返時間更長一些
確認丟失和確認遲到機制：
- 確認丟失機制將超時的包覆蓋爲超時重傳的包
使用上述的確認和重傳機制，我們就可以在不可靠的傳輸網絡上實現可靠的通信。
ARQ 表明重傳的請求是自動進行的
TCP流水線傳輸：
停止等待協議的優點是簡單，但缺點是信道利用率太低
改進:
發送方可連續發送多個分組，不必每發完一個分組就停頓下來等待對方的確認，由於信道上一直有數據不間斷地傳送，這種傳輸方式可獲得很高的信道利用率
連續 ARQ 協議(自動重傳協議):
連續ARQ（Automatic Repeat reQuest）協議指發送方維持着一個一定大小的發送窗口，位於發送窗口內的所有分組都可連續發送出去，而中途不需要等待對方的確認。這樣信道的利用率就提高了。而發送方每收到一個確認就把發送窗口向前滑動一個分組的位置
接收方一般都是採用積累確認的方式。這就是說，接收方不必對收到的分組逐個發送確認，而是在收到幾個分組後，對按序到達的最後一個分組發送確認，這就表示：到這個分組爲止的所有分組都已正確收到了
積累確認有優點也有缺點。優點是：容易實現，即使確認丟失也不必重傳。但缺點是不能向發送方反映出接收方已經正確收到的所有分組的信息
例如，如果發送方發送了前5個分組，而中間的第3個分組丟失了。這時接收方只是對前兩個分組發出確認。發送方無法知道後面三個分組的下落，而只好把後面的三個分組都再重傳一次。這就叫做Go-back-N（回退N），表示需要再退回來重傳已發送過的N個分組。可見當通信線路質量不好時，連續ARQ協議會帶來負面的影響
TCP 報文段的首部格式:
- 源端口和目的端口字段各佔 2 字節(16位)，源端口指發送端相關服務端口，目的端口是目標主機相關服務，端口是傳輸層與應用層的服務接口，傳輸層的複用和分用功能都要通過端口才能實現。
- 序號：當前數據組的第一個字節在整個文件中的序號
- 確認號ack：接收端發送，提示發送端下一次該發的數據在整個文件中的序號（收發連續的話就是序號+1），接收端收到後，會把這個序號之前的數據從緩存中刪掉
- 數據偏移：指明當前TCP報文段第多少個字節後是TCP的數據部分了，數據偏移最多表示1111，即15，他最多可以表示15乘以4，即60個字節的偏移量，所以選項+填充最多隻能是40個字節
- 保留：就是保留，沒有用的
- URG：urgent，意思是優先級高，發送端優先發送，而不是在緩存中排隊
- ACK：acknowledge，1意味着確認正式建立了會話
- PSH：1意味着接收端優先讀取，而不是在緩存中排隊
- RST：reset，1意味着TCP會話出現嚴重錯誤，必須釋放和重新連接，比如你打開網頁又立馬將之關掉了，那麼接收方也不用再給你傳輸網頁信息了
- SYN：同步，1意味着要發起會話
- FIN：finish，1意味着釋放連接
- 窗口：同步接收端和發送端窗口大小的，接收端先發，發送端根據接收端的窗口尺寸確定發送端窗口尺寸
- 檢驗和：略，上已講
- 緊急指針：只有URG爲1纔有用
滑動窗口
TCP 可靠通信的具體實現：
- TCP 連接的每一端都必須設有兩個窗口——一個發送窗口和一個接收窗口
- TCP 的可靠傳輸機制用字節的序號進行控制
- TCP 兩端的四個窗口經常處於動態變化之中
- TCP連接的往返時間 RTT 也不是固定不變的，需要使用特定的算法估算較爲合理的重傳時間
窗口動態變化-以字節爲單位的滑動窗口：
- A的發送窗口是由B的接受窗口長度決定的
- 在沒有收到B確認收到之前，A不能刪掉滑動窗口內的內容
- A可以持續給B發送，直到A的滑動窗口內數據都發送成功
- B收到後給A發確認收到的反饋ack（下一個應該發送的字節的序號），A收到後，就可以滑動窗口到對應的位置。例如B反饋ack是7，那麼A的滑窗可以移動到7位置，1-6刪除，21-26可以繼續發送
相關名詞：
P3 – P1 = A 的發送窗口（又稱爲通知窗口）
P2 – P1 = 已發送但尚未收到確認的字節數
P3 – P2 = 允許發送但尚未發送的字節數（又稱爲可用窗口
TCP流量控制
流量控制(flow control)就是讓發送方的發送速率不要太快，既要讓接收方來得及接收，也不要使網絡發生擁塞
利用滑動窗口機制可以很方便地在 TCP 連接上實現流量控制，收方返回的 rwnd中會包含自己的接收窗口的大小，並且利用大小來控制發送方的數據發送，發送方在rwnd窗口之後的數據不允許發送
流量控制根本目的是防止分組丟失，它是構成TCP可靠性的一方面
死鎖解決：
接收方返回窗口大小爲0，可能是緩衝區已滿，需要處理緩存中的字節，發送端收到滑動窗口爲0，不再發送，但是數據還沒發送完，這就造成了死鎖
如果在某個時候，接收方緩衝區有空間了，於是發送了一個非 0 窗口的通告給接收方，不幸的是這個通告丟失了，而發送方卻還在死等接收方的非 0 窗口通告，接下來就成了死鎖
TCP 爲每一個連接設有一個持續計時器
若持續計時器設置的時間到期，就週期性的向接收方發送 1 字節的 0 窗口探測報文
若窗口仍然是零，則收到這個報文段的一方就重新設置持續計時器，等待重傳
若窗口不是零，則死鎖的僵局就可以打破了
三次握手齊白首
傳輸連接有三個階段，即：連接建立（三次握手）、數據傳送和連接釋放（四次揮手）
頭兩次握手除了確定雙方都能聯通外，還通知了雙方的一些端口信息
A：我們談戀愛吧
B：好的（如果“好的“丟了，A就不知道B的態度，感情就無法建立起來）
C：走你~
第三次握手原因：假如把三次握手改成僅需要兩次握手，死鎖是可能發生的。作爲例子，考慮計算機A和B之間的通信，假定A給B發送一個連接請求分組，B收到了這個分組，併發送了確認應答分組。按照兩次握手的協定，B認爲連接已經成功地建立了，可以開始發送數據分組。可是，B的應答分組在傳輸中被丟失的情況下，A將不知道B是否已準備好，A認爲連接還未建立成功，將忽略B發來的任何數據分組，這樣就形成了死鎖
四次揮手說分手
A 的應用進程先向其 TCP 發出連接釋放報文段，並停止再發送數據，主動關閉 TCP
連接A 把連接釋放報文段首部的 FIN = 1，其序號seq = u，等待 B 的確認（A：分手吧？）
B 發出確認，確認號 ack = u + 1，而這個報文段自己的序號 seq = v（B：確定嗎？）
TCP 服務器進程通知高層應用要進行關閉了
從 A 到 B 這個方向的連接就釋放了，TCP 連接處於半關閉狀態。B 若發送數據，A 仍要接收（因爲A要知道B是否收到斷開請求）
若 B 已經沒有要向 A 發送的數據，其應用進程就通知 TCP 釋放連接，並通知A連接已關閉（B:那就分了吧，我走了）
A 收到連接釋放報文段後，必須發出確認(好的)
