版權聲明:本文爲做者原創文章，能夠隨意轉載，但必須在明確位置代表出處！！！windows

以前有一篇文章介紹了http協議「初識http協議」， http協議協議是基於tcp協議的，因此做者以爲有必要針對tcp協議作一個介紹，但願各位讀者可以靜下心來認真閱讀，也能夠本身去看看TCP/IP協議詳解這本書，必定要讓本身成爲那20%的人。服務器

TCP（Transmission Control Protocol 傳輸控制協議）是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議，對TCP協議的文章網上已經很成熟了，今天我只是想總結一下知識，加深印象，所謂好記心不如爛筆頭麻。網絡

TCP/IP分層結構

TCP/IP協議棧主要分爲4層：應用層，傳輸層，網絡層，數據鏈路層tcp

應用層工具

應用層負責處理特定的應用程序細節，像遠程登錄，FTP傳輸，SMTP郵件傳輸，SNMP簡單網絡管理。大數據

傳輸層3d

運輸層主要提供兩臺主機之間端到端的通訊，在TCP/IP協議族中，TCP和UPD是兩種大相徑庭的傳輸協議，TCP（傳輸控制協議）爲主機之間提供可靠傳輸，它把從應用層獲得的數據分紅適當的數據包交給下面的（IP）網絡層，肯定接收到的分組，設置發送最後確認分組的超時時鐘等，因運輸層提供了高可靠性的端到端的通訊，應用層就不須要再去關注這些細節，而UDP(用戶數據協議)提供的是不可能性的傳輸，它只負責從一臺主機發送到另外一臺主機，並不保證此數據必定到達另外一端主機，任何須需的可靠性必須由應用層來提供。指針

網絡層blog

網絡層主要處理分組在網絡中的活動，網絡層協議包涵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後已然沒有收到回覆，則證實服務端已經正常關閉了，那我也就能夠關閉鏈接了。

Wireshark抓包分析TCP協議