TCP

學習 TCP 協議，首先第一個要了解固然是 TCP 鏈接是如何創建的，下面給你們介紹一下三次握手和四次揮手的過程以及爲何要這樣設計。

三次握手

在基於 TCP 通訊中，雙方要進行通訊，則須要創建一個物理鏈接，創建時須要雙方進行三次握手，成功便可完成鏈接創建。

採用三次握手的緣由：

　　在網絡通訊中，網絡存在擁塞，發送的報文可能會因爲網絡擁塞的緣由，致使對方收不到。若採用直接開啓鏈接，當客戶端發送鏈接創建請求後，不等待確認服務器能夠打開鏈接就直接打開鏈接，這樣若是服務器收不到報文，根本不知道客戶端，那麼客戶端的打開的物理鏈接是無效的，但客戶端不知道，還一直髮送數據，作無用的工做。

三次握手的過程 

四次揮手

當雙方通訊結束時，須要四次揮手來關閉鏈接。

採用四次揮手的緣由：

　　學習過 TCP 鏈接的都知道，TCP 鏈接是雙向的，一個是從客戶端到服務端，另外一個是從服務端到客戶端。假設當前客戶端已經發送完全部數據到服務器，則此時能夠告知服務器，我已經發送完數據了，能夠關閉我這端到另外一端的通道，服務器收到關閉報文則可發送一個確認，確認關閉；但此時因爲服務器可能還須要發送數據到客戶端，所以並不會關閉從服務端到客戶端方向的通道；等服務端發完了，才發送一個 FIN 報文給客戶端，客戶端收到以後發送確認，則此時 TCP 鏈接才正式關閉。

四次揮手的過程

TIME_WAIT狀態

從四次揮手過程能夠看到，當服務器像客戶端發送 FIN 報文後，客戶端響應確認報文時，客戶端處於 TIME_WAIT 狀態，而不是處於 CLOSE 狀態。之因此會這樣主要是由於客戶端發送確認報文後，不能馬上關閉鏈接。由於若是服務端收不到確認報文，會將 FIN 報文重傳，但此時客戶端已經關閉鏈接了，這樣會致使客戶端收不到，而服務端則一直苦苦等待客戶端發送確認報文，不斷重傳 FIN 報文。所以客戶端在響應確認報文後，須要等待兩個報文往返時間，以此來確保服務端可以正常收到確認報文關閉鏈接。

 

TCP的優點

從傳輸數據來說，TCP/UDP以及其餘協議均可以完成數據的傳輸，從一端傳輸到另一端，TCP比較出衆的一點就是提供一個可靠的，流控的數據傳輸，因此實現起來要比其餘協議複雜的多，先來看下這兩個修飾詞的意義：

 1. Reliability ，提供TCP的可靠性，TCP的傳輸要保證數據可以準確到達目的地，若是不能，須要能檢測出來而且從新發送數據。

 2. Data Flow Control，提供TCP的流控特性，管理髮送數據的速率，不要超過設備的承載能力

爲了可以實現以上2點，TCP實現了不少細節的功能來保證數據傳輸，好比說 滑動窗口適應系統，超時重傳機制，累計ACK等，此次先介紹一下滑動窗口的一些知識點。

滑動窗口引入

在閱讀一些文章的時候看到一個大牛作的視頻，很是不錯易於理解滑動窗口的機制，能夠先看下：http://v.youku.com/v_show/id_XNDg1NDUyMDUy.html

IP層協議屬於不可靠的協議，IP層並不關係數據是否發送到了對端，TCP經過確認機制來保證數據傳輸的可靠性，在比較早的時候使用的是send--wait--send的模式，其實這種模式叫作stop-wait模式，發送數據方在發送數據以後會啓動定時器，可是若是數據或者ACK丟失，那麼定時器到期以後，收不到ACK就認爲發送出現情況，要進行重傳。這樣就會下降了通訊的效率，以下圖所示，這種方式被稱爲 positive acknowledgment with retransmission (PAR)

滑動窗口

能夠假設一下，來優化一下PAR效率低的缺點，好比我讓發送的每個包都有一個id，接收端必須對每個包進行確認，這樣設備A一次多發送幾個片斷，而沒必要等候ACK，同時接收端也要告知它可以收多少，這樣發送端發起來也有個限制，固然還須要保證順序性，不要亂序，對於亂序的情況，咱們能夠容許等待必定狀況下的亂序，好比說先緩存提早到的數據，而後去等待須要的數據，若是必定時間沒來就DROP掉，來保證順序性！

在TCP/IP協議棧中，滑動窗口的引入能夠解決此問題，先來看從概念上數據分爲哪些類

1. Sent and Acknowledged：這些數據表示已經發送成功並已經被確認的數據，好比圖中的前31個bytes，這些數據其實的位置是在窗口以外了，由於窗口內順序最低的被確認以後，要移除窗口，其實是窗口進行合攏，同時打開接收新的帶發送的數據

2. Send But Not Yet Acknowledged：這部分數據稱爲發送但沒有被確認，數據被髮送出去，沒有收到接收端的ACK，認爲並無完成發送，這個屬於窗口內的數據。

3. Not Sent，RecipientReady to Receive：這部分是儘快發送的數據，這部分數據已經被加載到緩存中，也就是窗口中了，等待發送，其實這個窗口是徹底有接收方告知的，接收方告知仍是可以接受這些包，因此發送方須要儘快的發送這些包

4. Not Sent，RecipientNot Ready to Receive： 這些數據屬於未發送，同時接收端也不容許發送的，由於這些數據已經超出了發送端所接收的範圍

對於接收端也是有一個接收窗口的，相似發送端，接收端的數據有3個分類，由於接收端並不須要等待ACK因此它沒有相似的接收並確認了的分類，狀況以下

1.  Received and ACKNot Send to Process：這部分數據屬於接收了數據可是尚未被上層的應用程序接收，也是被緩存在窗口內

2.  Received  Not ACK: 已經接收並，可是尚未回覆ACK，這些包可能輸屬於Delay ACK的範疇了

3.  Not Received：有空位，尚未被接收的數據。

發送窗口和可用窗口

對於發送方來說，窗口內的包括兩部分，就是發送窗口（已經發送了，可是沒有收到ACK），可用窗口，接收端容許發送可是沒有發送的那部分稱爲可用窗口。

1. Send Window ： 20個bytes 這部分值是有接收方在三次握手的時候進行通告的，同時在接收過程當中也不斷的通告能夠發送的窗口大小，來進行適應

2. Window Already Sent: 已經發送的數據，可是並無收到ACK。

滑動窗口原理

TCP並非每個報文段都會回覆ACK的，可能會對兩個報文段發送一個ACK，也可能會對多個報文段發送1個ACK【累計ACK】，好比說發送方有1/2/3 3個報文段，先發送了2,3 兩個報文段，可是接收方指望收到1報文段，這個時候2,3報文段就只能放在緩存中等待報文1的空洞被填上，若是報文1，一直不來，報文2/3也將被丟棄，若是報文1來了，那麼會發送一個ACK對這3個報文進行一次確認。

舉一個例子來講明一下滑動窗口的原理：

1. 假設32~45 這些數據，是上層Application發送給TCP的，TCP將其分紅四個Segment來發往internet

2. seg1 32~34 seg3 35~36 seg3 37~41 seg4 42~45  這四個片斷，依次發送出去，此時假設接收端之接收到了seg1 seg2 seg4

3. 此時接收端的行爲是回覆一個ACK包說明已經接收到了32~36的數據，並將seg4進行緩存（保證順序，產生一個保存seg3 的hole）

4. 發送端收到ACK以後，就會將32~36的數據包從發送並無確認切到發送已經確認，提出窗口，這個時候窗口向右移動

5. 假設接收端通告的Window Size仍然不變，此時窗口右移，產生一些新的空位，這些是接收端容許發送的範疇

6. 對於丟失的seg3，若是超過必定時間，TCP就會從新傳送（重傳機制），重傳成功會seg3 seg4一塊被確認，不成功，seg4也將被丟棄

就是不斷重複着上述的過程，隨着窗口不斷滑動，將真個數據流發送到接收端，實際上接收端的Window Size通告也是會變化的，接收端根據這個值來肯定什麼時候及發送多少數據，從對數據流進行流控。原理圖以下圖所示：

滑動窗口動態調整

主要是根據接收端的接收狀況，動態去調整Window Size，而後來控制發送端的數據流量

1. 客戶端不斷快速發送數據，服務器接收相對較慢，看下實驗的結果

a. 包175，發送ACK攜帶WIN = 384，告知客戶端，如今只能接收384個字節

b. 包176，客戶端果然只發送了384個字節，Wireshark也比較智能，也宣告TCP Window Full

c. 包177，服務器回覆一個ACK，並通告窗口爲0，說明接收方已經收到全部數據，並保存到緩衝區，可是這個時候應用程序並無接收這些數據，致使緩衝區沒有更多的空間，故通告窗口爲0, 這也就是所謂的零窗口，零窗口期間，發送方中止發送數據

d. 客戶端察覺到窗口爲0，則再也不發送數據給接收方

e. 包178，接收方發送一個窗口通告，告知發送方已經有接收數據的能力了，能夠發送數據包了

f.  包179，收到窗口通告以後，就發送緩衝區內的數據了.

總結一點，就是接收端能夠根據本身的情況通告窗口大小，從而控制發送端的接收，進行流量控制

本文分享自微信公衆號 - IT技術小咖（IT-arch）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。