TCP編程實踐小結1

提及TCP/IP協議，你們估計都能說出個一二，可是估計不多有人可以深刻的理解這個協議，緣由有這麼幾個：

1. 協議自己確實複雜
2. 入門教材沒選對，太抽象了，致使你們淺嘗輒止
3. 學習過程當中若是沒有配合實踐理解，過段時間也忘記了。

因此本篇文章的用意就是經過理論和實踐的結合，加深你們對TCP協議的理解，更好的應用TCP來編寫客戶端和服務端。

TCP理論介紹

說到入門教材我比較推薦《圖解TCP/IP》,本節內容也是在這本書的理論基礎上結合本身的理解構成。
首先 TCP位於七層協議中的傳輸層。

TCP通訊簡單的說是相似這樣的。

TCP協議是構建在網絡層的IP協議之上的面向鏈接的、可靠的流協議。

TCP如何保證可靠性？

推薦使用WireShark抓包來學習TCP協議的特色，推薦一篇教程。因爲HTTP協議是構建TCP協議之上的，因此能夠用Wireshark對你的上網過程進行抓包，來觀察TCP協議的流程和特性。

鏈接管理（三次握手）

上圖是在HTTP GET以前，先通過了TCP的三次握手。
192.168.5.81 ——》 191.0.0.1 SYN（發起鏈接）
191.0.0.1 ——》 192.168.5.81 ACK（對192.168.5.81 的SYN的確認）＋SYN（發起鏈接）
192.168.5.81 ——》 191.0.0.1 ACK（對191.0.0.1 的SYN的確認）

經過序列號與確認應答提升可靠性。

紅圈部分是作個示例，TCP中的每一包數據都包含着自身的數據序列號（Sequence Number），以及已收到對方數據的確認號（Acknowledgement Number）。
如下是TCP的報文頭定義，方便對照WireShark查看。

假如某包數據發送以後，遲遲未受到對方確認，則會進行超時重發。
假如重發必定次數以後，仍是沒有任何確認應答返回，就會判斷網絡或對端主機發生異常，強制關閉鏈接。
經過以上這個機制就能夠保證數據不會存在丟包、順序混亂的問題。

TCP以段爲單位發送數據

參考Wireshark的截圖，第一包數據中有個屬性 MSS＝1460（Maximum Segment Size最大消息長度，也就是所謂的「段」）。
以太網標準MSS是1460，同時兩端的主機在發出創建鏈接的請求時會在TCP首部寫入MSS選項，告訴對方本身的接口可以適應的MSS的大小。而後會在二者之間選擇一個較小的值投入使用。

利用窗口控制提升速度 和 擁塞控制

TCP以段爲單位收發數據，若是每發一個段都要進行確認的話效率有點低，因而TCP引入了窗口的概念。
窗口的大小就是指無需等待確認應答而能夠繼續發送數據的最大值。
在通訊剛開始的時候窗口大小通常爲1個段，後續隨着通訊的正常進行，窗口會變大，這叫作擁塞控制，主要是防止網絡擁堵。由於計算機網絡處在一個共享的環境中，若是你們一開始都採用最大量數據發送可能致使網絡癱瘓。
下圖紅圈是每個窗口確認的過程，能夠看出來窗口是持續增大的。

流控制

TCP的流控制的意思就是通訊雙方會協商好傳輸數據的速度，不然一方數據發送太快，另外一方數據處理能力有限就會致使數據丟棄，從而形成流量的浪費。
接收主機將本身能夠接受的緩衝區大小放入到TCP首部字段通知給發送端。這個字段越大，說明網絡的吞吐量越大。

OK，以上是TCP的一些基本概念和特性，講的比較淺，算是本身的一個總結，說多了也不容易記住。 本篇文章先到這裏，下一篇再介紹Socket API及其相關使用問題。