TCP協議段資訊及作用

在前面我們講述了UDP協議段的頭部資訊，UDP協議段資訊
那麼今天接著說傳輸層的另一個協議，TCP協議。
TCP是傳輸層中比較重要的一種協議，它運用的地方很多，比如在FTP協議、http協議中就是運用了TCP的協議，因為它的可靠性，所以很大程度解決了檔案傳輸丟失，或者錯誤順序的情況。
我們先來看TCP頭部格式

協議畫的順序是從左到右，頭部資訊也是從左到右進行的。

• 埠號
  埠號我們在UDP中已經講過，我們再來說一下，源埠號為傳送主機的某個程序的埠號，目的埠號是傳送到遠端主機的哪個埠號上。
• 32位序號
  在UDP中沒有序號，是因為UDP是不可靠傳輸，那麼TCP是可靠傳輸，就需要對可靠傳輸做出相對的辦法，序號就是其中的一種，給每個傳送的資料段打上序號，進行傳送，這樣就不會出現傳送過過去資料錯亂問題，這也是確認應答是第一步。初步瞭解
• 32位確認序號
  要想做到可靠傳輸，那麼就要有應答機制，當一個人找一個說話時候，說一會得到那個人的迴應就知道那個人聽到了，同樣的就是這個原理。至於怎麼應答，一會說~
• 4位首部長度
  首部長度是什麼意思，還是4位？首部長度就是TCP協議段中的頭部長度，為什麼要有4位的首部長度標識欄位呢？因為在TCP中頭部的長度是可變的，頭部存在一個選項，所以是不確定的，那麼用4為能標識多大呢？4位表示最大是15，但是我們就不看選項欄位，大小已經有20個位元組了，那麼怎麼表示呢？其實是4位表示的數字，數字的每個1都表示4個位元組。也就是15 * 4 = 60 那麼TCP首部最大為60個位元組，最小為20個位元組。這樣的方式就可以計算出選項的大小，就可以用4位首部的表示數乘4 減去 20 個位元組，就是選項的大小。
• 6位保留
  保留位就是目前沒有用到，所以不作為重點
• 6個標誌位
  六個標誌位，就是上面的ACK、SYN等，我們具體說說每一個標誌位的作用
  URG：緊急指標是否有效位，這個主要是搭配16位緊急指標而使用，改變資料傳送或者接收的優先順序
  ACK：是當傳送端傳送資料後，等待接收方迴應的標誌位，接收方收到，就會回覆一個ACK標誌位為1的資料報
  PSH：當接收端接緩衝區滿的時候，傳送方在等了一段時間後發現，還是沒有把緩衝區的資料取走，這時候，傳送方會發送一個PSH標誌位為1的資料報來催接收方，快點取走資料
  RST：這個標誌位主要的作用是在三次握手的過程中，如果三次握手失敗，那麼RST在就會置為1，請求重新建立連線。稍後詳細介紹~
  SYN
  ：SYN標誌位是用來進行發出建立連線的，我們把帶有SYN報文段叫做同步報文段
  FIN：在通訊進行完成後，需要關閉連線時候的的標誌位

在三次握手的過程中，我們來用圖來解釋一下RST置為1的情況。

三次握手過程
第一握手：當客戶端傳送SYN請求連線時候，伺服器接收SYN訊號後，變成SYN_RCVD狀態，然後第一次握手完成

第二次握手：伺服器給客戶端傳送一個SYN+ACK表示你傳送的請求我已經收到，伺服器再向客戶端傳送請求建立連線訊號。客戶端收到訊號後，進入ESTABLISHED狀態。

第三次握手：客戶端又給伺服器傳送ACK，表示已經收到，如果伺服器收到ACK這時候，伺服器就會進入ESTABLISHED狀態，這時才表示建立成功。

RST標誌位在第三次握手中起到作用
那麼當在第三次握手的過程中，客戶端給伺服器的ACK丟失，這時候，伺服器還未建立連線，但是客戶端認為已經建立連線，所以就會給伺服器傳送資料，當伺服器收到資料，但是伺服器沒有處於ESTABLISHED狀態，就會給客戶端傳送一個RST標誌位為1的資料報，表示需要重新建立連線。

試想為什麼要這麼設計？

如果進行兩次握手不是也可以嗎？把前兩步，把伺服器端SYN_RCVED狀態改為就緒狀態，行不行？
答案是不行。假設有圖謀不軌的人要攻擊你的伺服器，那麼他只要不停的給伺服器傳送SYN請求，而自己卻又不傳送資料，或者對伺服器迴應的ACK不理睬，這時候你就需要花費檔案描述符來進處理

• 16位視窗大小。
  這是為了解決應答機制的效率問題。
• 16位校驗和
  和UDP相同，都是為了排除資料在傳輸過程中，出現數據錯誤的情況。通過校驗和來檢測資料是否正確
• 16位緊急指標
  它也是搭配URG緊急指標是否有效的標誌位來進行使用。用來處理優先順序高的資料
• 選項
  其中就包含了一些對可靠處理，還有一些其它特殊情況的處理資訊。
• 資料
  從應用層拿來的資料進行新增頭部

可靠傳輸機制的分析

TCP的可靠傳輸的一個重要的機制就是ACK應答機制，每次在傳送資料後要等到
一個應答ACK，來確認收到了資料。

確認應答

在TCP協議段頭部有32位序號，與32位確認序號，在主機A傳送一個數據報給主機B時，就會給每個訊息打上序號，那麼在主機B收到資料後，進行排序，然後給主機A傳送確認序號為傳送資料收到的下一要接收的資料序號。

超時重傳

超時重傳也是可靠機制的一種，分為兩種情況
1）當資料丟失
2）應答ACK丟失

這兩個種情況都出現超速重傳機制，主機A給主機B傳送資料時候，資料在傳送過程中丟失，或者是應答是ACK發生丟失，當主機A傳送資料後就會啟動定時器，在特定的時間間隔中，如果沒有收到ACK就會重新發送，那麼在如果是資料丟失的情況下，一定時間間隔後就會因為沒有收到ACK就會進行重發，但是如果是在主機B收到了資料，ACK在傳送的過程中丟失，這時候，主機A給主機B的資料已經收到，再發過去的資料就會用序號來確認是否重複，重複就直接丟掉。

還有一個問題
如何確定超時重傳的時間呢？
最好要找出最小的時間，怎麼找最小的時間呢？這就要根據自己的網路狀況，要保證傳送資料後，ACK一定要能返回來，就是要有一個來回的時間，最小不能小於一個來回的時間。如果過小，就會形成頻繁的傳送重複的包

那麼給大點時間行不？要是時間間隔過大就會影響整體的重傳效率。

一般在Linux中或者Windows中超時重傳的時間為500ms為一個單位，如果再次重發後沒有收到就會等待2*500ms 以此等待，到一定的時間就會判斷為網路異常，而強行中斷。

對於TCP的可靠傳輸進行了分析，那麼為提高效率TCP又做了那些處理？下一篇詳細分析

如有錯誤，還望指正。謝謝~