之前有一篇文章介紹了http協定「初識http協定」， http協定協定是基于tcp協定的，是以作者覺得有必要針對tcp協定做一個介紹，希望各位讀者能夠靜下心來認真閱讀，也可以自己去看看TCP/IP協定詳解這本書，一定要讓自己成為那20%的人。
TCP（Transmission Control Protocol 傳輸控制協定）是一種面向連接配接的、可靠的、基于位元組流的傳輸層通信協定，對TCP協定的文章網上已經很成熟了，今天我隻是想總結一下知識，加深印象，所謂好記心不如爛筆頭麻。
TCP/IP分層結構
TCP/IP協定棧主要分為4層：應用層，傳輸層，網絡層，資料鍊路層
應用層
應用層負責處理特定的應用程式細節，像遠端登陸，FTP傳輸，SMTP郵件傳輸，SNMP簡單網絡管理。
傳輸層
運輸層主要提供兩台主機之間端到端的通信，在TCP/IP協定族中，TCP和UPD是兩種截然不同的傳輸協定，TCP（傳輸控制協定）為主機之間提供可靠傳輸，它把從應用層得到的資料分成适當的資料包交給下面的（IP）網絡層，确定接收到的分組，設定發送最後确認分組的逾時時鐘等，因運輸層提供了高可靠性的端到端的通信，應用層就不需要再去關注這些細節，而UDP(使用者資料協定)提供的是不可能性的傳輸，它隻負責從一台主機發送到另一台主機，并不保證此資料一定到達另一端主機，任何必需的可靠性必須由應用層來提供。
網絡層
網絡層主要處理分組在網絡中的活動，網絡層協定包涵IP,ICMP,IGMP協定。
鍊路層
鍊路層組要包涵網卡驅動程式，它處理和電纜或者其它傳輸媒體的實體接口細節。鍊路層的主要目的有三個
為IP子產品接收和發送IP資料報
為ARP子產品發送ARP請求和接收ARP應答
為RARP子產品接收RARP應答和發送RARP請求
所謂的協定就是通信雙方都需要遵守的規則，這樣才能明白對方要表達什麼，就像兩個人打電話一樣，A說的是重慶話，B說的是廣東話，這兩人打電話肯定不知道對方說的是什麼，這就叫他們沒有遵守協定，若是都讓他們說國語這樣倆兒人就都能聽懂對方說的是什麼意識了，國語這裡就相當于協定大家都要遵守。下面我将結合Wireshark抓包工具來分析TCP/IP協定
封裝
資料進入協定棧的封裝過程
當經過以太網層的封裝後，就要通過網線或者其它傳輸媒體把此封裝好的資料封包發送到另一端去，另一段收到資料報後最先接觸的是以太網層也就是我們的資料鍊路層協定，該層協定複制把以太網首部解析掉，讓後把解析後的資料報上送到IP層，IP層把IP首部解析掉，然後上傳到TCP層，依次類推每層協定解析其首部并判斷其首部中的協定辨別以确定接收資料的上層協定，然後上送到他的上一層。這就是封層結構的好處之一，每層協定隻做自己的事，不是自己的事就交給别人去做。
TCP封包格式
Wireshark的抓包結果
原端口/目的端口(16bit)：
我們都知道網絡之前的通信是不通主機之間的通信，就windows系統而言通過檢視任務管理器我們可以知道一台主機有許多程序，當我們發送資料時怎麼知道要發送到對方主機那個程序裡呢，是以這就是端口号的作用，在TCP封包中包涵了源端口/目的端口，源端口辨別了發送程序，目的端口辨別了接收方程序。在此封包中我們的源端口号是0x8572 = 34162, 目的端口是0x01bb = 443如下圖所示
序列号(32bit)
Sequence Number這個是發送序列号，用來辨別從源端向目的端發送的資料位元組流，它表示在這個封包端中的第一個資料位元組的順序号，系列好是32位的無符号類型，序号表達達到2^32 - 1後又從0開始， 當建立一個新的連接配接時，SYN标志為1，系列号将由主機随機選擇一個順序号ISN(Initial Sequence Number)。此封包中的序列号是0x9e546d6b早已超過了2^32 - 1 是以這裡的序列号為0，如下圖
确認号(32bit)
Acknowledgment Number它包涵了發送确認一端所期望收到的下一個順序号。是以确認序列号應當是上次成功接收到資料的順序号加1。隻有ACK标志為1時确認序号字段才有效。TCP為應用層提供全雙工服務，這意味着資料能在兩個方向上獨立的進行傳輸，是以連接配接的兩斷必須要保證每個方向上的傳輸資料順序。
偏移(4bit)
這裡的偏移實際指的是TCP首部的長度，它用來表明TCP首部中32bit字的數目，通過它可以知道一個TCP包它的使用者資料從哪裡開始，這個字段占4bit，若此字段的值為1000，則說明TCP首部的長度是8 * 4 = 32位元組，是以TCP首部的最大長度是該字段的值為1111 = 15， 15 * 4 =60位元組。此封包我們的偏移量在0x80中，又因它占4bit,0x80等于二進制的1000 0000 是以我們的偏移量是 1000 = 8，是以我們的TCP封包頭為8 * 4 = 32位元組。
Reserved(6bit)
目前沒有使用，它的值都為0
标志(6bit)
在TCP首部中有6個标志比特，他們中的多個可同時被置為1
URG(Urgent Pointer Field Significant):緊急指針标志，用來保證TCP連接配接不被中斷，并且督促中間裝置盡快處理這些資料
ACK(Acknowledgement Field Signigicant):确認号字段，該字段為1時表示應答字段有效，即TCP應答号将包含在TCP封包中。
PSH(Push Function): 推送功能，所謂推送功能指的是接收端在接收到資料後立即推送給應用程式，而不是在緩沖區中排隊。
RST(Reset the connection): 重置連接配接，不過一搬表示斷開一個連接配接，如下圖，主機192.168.3.27 通路主機211.150.84.8；但主機84.8并沒有監聽對于端口，這時它會向主機3.27發送一個RST位置的TCP包斷開連接配接。
SYN(Synchronize sequence numbers):同步序列号，用來發起一個連接配接請求
FIN(No more data from sender):表示發送端發送任務已經完成（既斷開連接配接）
視窗大小(16bit)
表示源主機最大能接收多少位元組。
校驗和(16bit)
包含TCP首部和TCP資料段，這是一個強制性的字段，一定是由發送端計算和存儲，由接收端進行驗證
緊急指針(16bit)
隻有當URG标志置為1時該字段才有效，緊急指針是一個正的偏移量，和序号字段中的值相加表示緊急資料最後一個位元組的序号。TCP的緊急方式是發送端向另一段發送緊急資料的一種方式。
TCP選項
至少1個位元組的可變長字段，辨別哪個選項有效。Kind=0:選項表結束， Kind=1:無操作， Kind=2：最大封包段長度，Kind=3:視窗擴大因子， Kind=8:時間戳。
TCP的三次握手和四次揮手
整個過程如下圖所示
TCP的三次握手
TCP的三次握手過程如下圖所示，我們通過資料包來分析一下握手過程是不是和圖中所畫一緻。
第一次握手
主機192.168.3.27向主機111.13.100.91發起連接配接請求，可以看在這時的SYN被置為1了，序列号Seq = 0，如下圖
第二次握手
主機111.13.100.91應答主機192.168.3.27，可以看到這個時候的應答包含了SYN，ACK，ACK = Seq + 1 = 1， 這裡的Seq是第一次握手發起請求的Seq值，并不是下圖封包中紅框表示的Seq值。
第三次握手
主機192.168.3.27應答主機111.13.100.91，可以看到這個時候的應答包是ACK， ACK = Seq + 1 = 1，這裡的Seq是第二次握手主機111.13.100.91産生的序列值
在回頭看看我們的svr4.1037主機和bsdi.discard之前的連接配接建立是不是和我們的封包分析的一緻，第一次握手 SYN Seq = 1415531521; 第二次握手 SYN ack = 1415531521 + 1 = 1415531522 Seq = 1823083521；第三次握手 ack = 1823083521 + 1 = 1823083522；到這裡就可以看出此過程和我們的封包分析是一緻的。
可以看到三次握手後确定了雙方包的序列号，最大接收資料的大小以及MSS(Maximum Segment Size)最大分片大小 MSS = MTU - IP頭部長度 - TCP頭部長度，MTU最大傳輸單元一班為1500位元組，若TCP/IP封包都不帶選項時MSS = 1500 - 20 - 20 = 1460，MSS的意思是最大分片大小，這裡若是1460的話，那麼若是應用程式發送大于1460個位元組那麼超過1460個位元組數會分片為下一個包，下圖是應用層發送4096個位元組。
由于資料大小是4096個位元組，是以用了三次進行傳遞(1448 + 1448 + 1200)。細心的人會問為什麼每次傳送的最大資料大小不是1460個位元組呢?因為這裡的TCP攜帶可選項，TCP頭長度 = 20 + 12（可選選項大小） = 32位元組。 這樣能傳輸的最大資料為:1500 - 20 - 32 = 1448個位元組。
TCP四次揮手
第一次揮手
将設用戶端首先發起斷開連接配接，那麼用戶端回想服務端發送FIN置為1的TCP包，請求斷開連接配接，意思就是我要斷開和你的連接配接了，但是如果你還有資料沒有發送完給我你不必立即關閉連接配接。
第二次揮手
服務端收到用戶端的斷開連接配接請求立即響應一個ACK封包，意思是告訴用戶端你發起的斷開連接配接請求我已經收到了，但是我還沒有準備好，你在等一會，這個時候伺服器端可能還有資料要發送給用戶端，也可能正在準備釋放資源。這個時候用戶端進入FIN_WAIT狀态，繼續等待服務端的FIN封包。
第三次揮手
服務端确認已經發往用戶端的資料已經發送完成，則向用戶端發送FIN封包，告訴用戶端我已準備好關閉連接配接了。
第四次揮手
用戶端收到服務端的FIN封包後就知道可以關閉連接配接了，當時它還是不确定，怕服務端還是不知道我要關閉連接配接了，是以發送一個ACK包後進入TIME_WAIT狀态，如果服務端沒有收到ACK那麼服務端則可以發起重傳，如果收到了ACK封包，用戶端等待2MSL後已然沒有收到回複，則證明服務端已經正常關閉了，那我也就可以關閉連接配接了。