前言
昨天（2017.8.12）晚上9點多的時候突然接到百度的面試電話，上來就讓自我介紹，介紹完之後就開始問我知不知道滑動窗口協議，知不知道三次握手和四次揮手。於是今天又花點時間把TCP協議相關的做一下總結。
TCP特點
①TCP是面向連接的傳輸層協議。應用程序在使用TCP協議之前必須先建立TCP連接。在傳送數據結束後，必須釋放已經建立的TCP連接。
②每一條TCP連接只能有兩個端點（endpoint），每一條TCP連接只能是點對點的。
③TCP提供可靠交付的服務。通過TCP連接傳送的數據，無差錯、不丟失、不重複、並且按序到達。
④TCP提供全雙工通信。TCP連接的兩端都設有發送緩存和接收緩存，用來臨時存放雙向通信的數據。在發送時，應用程序在把數據傳送給TCP的緩存後，就可以處理其它事情，而TCP在適合的時候把數據發送出去。在接收時，TCP把收到的數據放入到緩存，上層的應用進程在適合的時候讀取緩存中的數據。
⑤面向字節流。TCP中的流（Stream）指的是流入到進程或者從進程流出的字節序列。面向字節流的含義是：雖然應用程序和TCP的交換是一次一個數據塊，但TCP把應用程序交下來的數據看成僅僅是一連串的無結構的字節流。
TCP發送方和接收方傳輸如下圖：
TCP連接
每一條TCP連接唯一地被通信兩端的兩個端點（即兩個套接字）所確定。即：
上面的 IP1和 IP2是兩個端點的IP地址，port1 和 port2是兩個主機應用的端口號，TCP連接的端點是套接字，同一個IP地址可以有不同的TCP連接，端口號不同連接不同，同一個端口號也可以有不同的TCP連接，因爲TCP連接是由IP地址和端口號唯一確定的，兩者缺一不可。
三次握手
由於TCP協議是面向連接的，在客戶端與服務器端傳輸數據之前要建立連接，（三次握手協議是TCP協議特有的，UDP協議不會進行三次握手因爲UDP協議不是面向連接的協議）。
如上圖：三次握手分爲三步：
①Client客戶端主動打開連接發送一個SYN同步請求報文。等待服務器端回覆。
②服務器端接到SYN請求報文後發送一個ACK同意連接並且SYN請求連接報文。
③客戶端接到服務器的報文後發送一個ACK報文，連接完成，服務器和客戶端可以開始通信。
更加詳細的包括序列號等的圖片如下：
爲什麼要三次揮手
爲了防止“已失效的連接請求報文段”突然又傳送到了B。假設A向B發送了連接請求，但這個連接請求報文沒有及時到達B，則A因爲沒有收到B的確認而重新發送一個連接請求報文，B確認後連接建立，然後進行一系列數據交換後關閉的連接。但此時之前A發送的連接請求報文突然到達了B，則B會對此發送確認，如果採用兩次握手，那麼此時AB又建立了連接，而A並沒有數據向B發送，白白浪費B的資源。採用三次握手則不會出現這種情況，因爲B向A發送確認時，A不會再給B發送確認，連接不會建立。
三次握手缺陷
1、SYN Flood 攻擊
SYN- Flood攻擊是當前網絡上最爲常見的DDoS攻擊，也是最爲經典的拒絕服務攻擊，它就是利用了TCP協議實現上的一個缺陷，通過向網絡服務所在端口發送大量 的僞造源地址的攻擊報文，就可能造成目標服務器中的半開連接隊列被佔滿，從而阻止其他合法用戶進行訪問。這種攻擊早在1996年就被發現，但至今仍然顯示 出強大的生命力。很多操作系統，甚至防火牆、路由器都無法有效地防禦這種攻擊，而且由於它可以方便地僞造源地址，追查起來非常困難。它的數據包特徵通常 是，源發送了大量的SYN包，並且缺少三次握手的最後一步握手ACK回覆。
原理：攻擊者首先僞造地址對 服務器發起SYN請求，服務器迴應(SYN+ACK)包，而真實的IP會認爲，我沒有發送請求，不作迴應。服務 器沒有收到迴應，這樣的話，服務器不知 道(SYN+ACK)是否發送成功，默認情況下會重試5次（tcp_syn_retries）。這樣的話，對於服務器的內存，帶寬都有很大的消耗。攻擊者 如果處於公網，可以僞造IP的話，對於服務器就很難根據IP來判斷攻擊者，給防護帶來很大的困難。
2、SYN Flood 防護措施
主要通過以下3種方式
1． 無效連接監視釋放
這種方法不停的監視系統中半開連接和不活動連接，當達到一定閾值時拆除這些連接，釋放系統資源。這種絕對公平的方法往往也會將正常的連接的請求也會被釋放掉，”傷敵一千，自損八百“
2． 延緩TCB分配方法
SYN Flood關鍵是利用了，SYN數據報文一到，系統立即分配TCB資源，從而佔用了系統資源，因此有倆種技術來解決這一問題
Syn Cache技術
這種技術在收到SYN時不急着去分配TCB，而是先回應一個ACK報文，並在一個專用的HASH表中（Cache）中保存這種半開連接，直到收到正確的ACK報文再去分配TCB。
Syn Cookie技術
Syn Cookie技術則完全不使用任何存儲資源，它使用一種特殊的算法生成Sequence Number，這種算法考慮到了對方的IP、端口、己方IP、端口的固定信息，以及對方無法知道而己方比較固定的一些信息，如MSS、時間等，在收到對方 的ACK報文後，重新計算一遍，看其是否與對方迴應報文中的（Sequence Number-1）相同，從而決定是否分配TCB資源。
3． 使用SYN Proxy防火牆
原理：對試圖穿越的SYN請求進行驗證之後才放行。
四次揮手
當客戶端和服務器數據傳送完成時要斷開TCP連接，斷開TCP連接要進行四次揮手處理如下圖：
①由上圖可知剛開始客戶端和服務器處於連接狀態時客戶端和服務器端可以雙向傳遞數據，
②然後客戶端向服務器發送FIN報文請求中斷連接，發送完報文後客戶端處於FIN_WAIT_1狀態等待服務器響應，當服務器端接收到FIN報文併發送ACK同意關閉後，客戶端向服務器端發送數據的通路關閉，此時客戶端不能再向服務器端發送數據並且處於FIN_WAIT_2狀態等待服務器端斷開連接。
③但是由於TCP是全雙工工作的，服務器端依然可以向客戶端發送數據。服務器端向客戶端發送FIN關閉連接請求，客戶端回覆ACK報文後開始計時進入TIME_WAIT狀態。
④客戶端等待2MSL（Maximum segment lifetime），MSL是報文最大生存時間，它是任何報文段被丟棄前在網絡內的最長時間。在2MSL時間內Socket中使用的本地端口不能被使用。
注意：，要等待2MSL的原因是怕客戶端向服務器發送的ACK報文丟失，如果2MSL時間後服務器端沒有接到ACK報文（TCP中有超時重傳機制），還會再次向客戶端發送一個FIN報文，直到最後服務器端接到ACK正常關閉端口。
TCP可靠傳輸
TCP發送的報文段是交給IP層傳送的。但是IP層只能提供盡最大努力服務，也就是說，TCP 下面的網絡所提供的不是可靠傳輸。因此TCP必須採用恰當的措施才能使得兩個傳輸層之間的通信變得可靠。TCP保證可靠的方式如下：
1.數據包校驗：TCP會對整個報文段進行檢驗
2.滑動窗口機制：以字節爲單位進行
3.超時重傳機制：發送方在規定時間內沒有收到確認就要重新發送報文
4.選擇確認：當報文未按序到達時，若這些在接收窗口範圍內，接收方就先收下然後將準確信息告訴發送方，讓它不要重複發送。
5.流量控制和擁塞控制：通過發送窗口和接收窗口大小來實現
傳輸方式如下：
停止等待協議
“停止等待”就是每發送完一個分組就停止發送，等待對方的確認。在收到確認後再發送下一個分組。停止等待協議分爲以下幾種情況：
1、無差錯情況
A 發送分組M1，發完就暫停發送，等待B 的確認。B 收到了M1 就向A 發送確認。A 在收到了對M1的確認後，就再發送下一個分組M2。同樣，在收到B 對M2的確認後，再發送M3。
2、超時重傳
B 接收M1時檢測出了差錯就丟棄M1，其他什麼也不做，不通知A 收到有差錯的分組戶。也可能是M1 在傳輸過程中丟失了，這時B 當然什麼都不知道。在這兩種情況下， B都不會發送任何信息。可靠傳輸協議是隻要超過了一段時間仍然沒有收到確認，就認爲剛纔發送的分組丟失了，因而重傳前面發送過的分組。這就叫做超時重傳。要實現超時重傳，就要在每發送完一個分組設置一個超時計時器。如果在超時計時器到期之前收到了對方的確認，就撤銷己設置的超時計時器。
注意以下三點：
1、A在發送完一個分組後，必須暫時保留已發送分組的副本（爲發生超時重傳時使用）。只有在收到相應的確認後才能清除暫時保留的分組副本。
2、分組和確認分組都必須進行編號。這樣才能明確是哪一個發送出去的分組收到了確認，而哪一個分組還沒有收到確認。
3、超時計時器設置的重傳時間應當比數據在分組傳輸的歐諾個級往返時間更長一些。
3、確認丟失
B所發送的對M1的確認丟失了。A在設定的超時重傳時間內沒有收到確認，因此A 在超時計時器到期後就要重傳M1。現在應注意B的動作。假定B又收到了重傳的分組M1。這時應採取兩個行動：
（1）丟棄重複的M1，不向上層交付。
（2）重新向A發送確認。不能認爲已經發送給確認就不再發送，因爲A之所以重傳M2就表示A沒有收到對M2的確認。
4、確認超時
傳輸過程中沒有出現差錯，但B 對分組M1 的確認遲到了。A 會收到重複的確認。對重複的確認的處理很簡單：收下後就丟棄。B 仍然會收到重複的M1 ，並且同樣要丟棄重複的M1 ，並重傳確認分組。
滑動窗口協議
停止等待協議每發送一幀就要停止等待知道接收到確認幀，這樣每次等待的時候不能傳送數據使得傳輸效率很低。下圖表示發送方維持的發送窗口，它的意義是：位於發送窗口內的5 個分組都可連續發送出去，而不需要等待對方的確認。這樣，信道利用率就提高了。連續ARQ 協議規定，發送方每收到一個確認，就把發送窗口向前滑動一個分組的位置。
接收方一般都是採用累積確認的方式。這就是說，接收方不必對收到的分組逐個發送確認，而是可以在收到幾個分組後，對按序到達的最後一個分組發送確認，這樣就表示：到這個分組爲止的所有分組都己正確收到了。
累積確認的優點是容易實現，即使確認丟失也不必重傳。但缺點是不能向發送方反映出接收方己經正確收到的所有分組的信息。
滑動窗口協議分爲兩種一種是後退N幀協議（Back To N）,一種是選擇重傳協議。
1、後退N幀協議
如下圖，如果發送方發送了前9個分組，而中間的第2 個分組丟失了。這時接收方只能對前兩個分組發出確認。發送方無法知道後面7個分組的下落，而只好把後面的7個分組都再重傳一次。這就叫做Go-back-N （回退N ），表示需要再退回來重傳己發送過的N 個分組。可見當通信線路質量不好時，連續ARQ 協議會帶來負面的影響。
2、選擇重傳協議
返回N協議簡化了接收方的處理過程.接收方只需跟蹤一個變量,並且不需要對失序到達的分組緩存,而是簡單地把失序到達的分組它們丟掉.但是如果底下的網絡層協議丟失了很多分組,那麼返回N協議的效率就會很低.每當一個分組損壞,發送方就需要重傳所有待確認的分組,雖然其中有些分組實際上已經完好地 被接收了。
選擇重傳協議也是滑動窗口協議，並且是在後退N幀的基礎上進行了改進，選擇重傳協議，選擇重傳協議只重傳真正丟失的分組.
選擇重傳協議的接收窗口和發送窗口一樣大(2^m-1) 比返回N協議的窗口(2^m)小了一倍
選擇重傳的接收窗口與發送窗口一樣大.選擇重傳協議允許與接受窗口一樣多的分組失序到達,並保存這些失序到達的分組,直到連續的一組分組被交付給應用層.因爲發送窗口與接收窗口是相同的,所以發送出來的所有分組都可以失序到達,而且會被保留直到交付爲止.但是必須強調一點,在一個可靠的協議中,接收方永遠不會把分組失序地交給應用層.在他們被交付給應用層之前,先要等待那些更早發出來的分組到達.
理論上選擇重傳協議要爲每個分組使用一個計時器.當某個計時器超時後,只有相應的分組被重傳.換而言之,返回N協議將所有的分組當做一個整體對待,而選擇重傳協議則分別對待每一個分組.但是大多數SR的運輸層僅使用了一個計時器. 注意只使用一個計時器而做到跟蹤所有發出去的分組的情況的做法是:標記發出分組,當ACK=Sf 時,將窗口滑過所有連續的已確認的分組,如果還有未確認的分組,則則重發所有檢測到的未被確認的分組並重啓計時器,如果所有分組都被確認了則停止計時器.
參考文獻
1.TCP/IP詳解
2.http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-3.htm
3.圖解TCP/IP
