TCP/IP HTTP 三次握手和四次握手
原文地址：http://www.cnblogs.com/kxdblog/p/4202059.html
TCP四層模型功能
TCP模型特點
TCP三次握手過程
TCP四次揮手過程
一. TCP/IP協議族
OSI模型和TCP/IP模型對應關係
物理層 --- 資料表示。物理層規定了啟用、維持、關閉通訊端點之間的機械特性、電氣特性、 功能特性以及過程特性。該層為上層協議提供了一個傳輸資料的物理媒體。。
資料鏈路層 --- 主機間通訊。資料鏈路層在不可靠的物理介質上提供可靠的傳輸。SDLC、HDLC、PPP、STP、幀中繼等
網路層 ---定址和最短路徑。網路層負責對子網間的資料包進行路由選擇。此外，網路層還可以實現擁塞控制、網際互連等功能。IP、IPX、RIP、OSPF等。
傳輸層 --- 端到端的連線。 傳輸層是第一個端到端，即主機到主機的層次。傳輸層負責將上層資料分段並提供端到端的、可靠的或不可靠的傳輸。TCP、UDP、SPX等。
會話層 --- 介質訪問。會話層管理主機之間的會話程序，即負責建立、管理、終止程序之間的會話。會話層還利用在資料中插入校驗點來實現資料的同步
表示層 --- 表示層對上層資料或資訊進行變換。以保證一個主機應用層資訊可以被另一個主機的應用程式理解。表示層的資料轉換包括資料的加密、壓縮、格式轉換等
應用層 --- 應用層為作業系統或網路應用程式提供訪問網路服務的介面。Telnet、FTP、 HTTP、SNMP等。
TCP/IP是一個協議族，通常分不同層次進行開發，每個層次負責不同的通訊功能。包含以下四個層次：
TCP四層模型功能
1. 鏈路層，也稱作資料鏈路層或者網路介面層，通常包括作業系統中的裝置驅動程式和計算機中對應的網路介面卡。它們一起處理與電纜（或其他任何傳輸媒介）的物理介面細節。
2. 網路層，也稱作網際網路層，處理分組在網路中的活動，例如分組的選路。網路層協議包括IP協議（網際協議）、ICMP協議（Internet網際網路控制報文協議），以及IGMP協議（Internet組管理協議）。
3. 運輸層主要為兩臺主機上的應用程式提供端到端的通訊。在TCP/IP協議族中，有兩個互不相同的傳輸協議：TCP（傳輸控制協議）和UDP（使用者資料報協議）。TCP為兩臺主機提供高可靠性的資料通訊。他所作的工作包括把應用程式交給它的資料分成合適的小塊交給下面的網路層，確認接收到的分組，設定傳送最後確認分組的超時時鐘等。由於運輸層提供了高可靠性的端到端通訊，因此應用層可以忽略所有這些細節。而另一方面，UDP則為應用層提供一種非常簡單的服務。它只是把稱作資料報的分組從一臺主機發送到另一臺主機，但並不保證該資料報能到達另一端。任何必須的可靠性必須由應用層來提供。
4. 應用層負責處理特定的應用程式細節。包括Telnet（遠端登入）、FTP（檔案傳輸協議）、SMTP（簡單郵件傳送協議）以及SNMP（簡單網路管理協議）等。
擁塞控制
TCP採用慢開始和擁塞避免的方法控制傳送
慢開始的思路是，先測試一下，在由小到大的增大發送視窗
具體的：預先設定一個慢開始門限，ssthresh(用於控制擁塞）
先設擁塞視窗cwnd=1，傳送第一個報文，收到確認後把cwnd設為2，在傳送，收到回覆後，再把cwnd增加2個，即，收到回覆後就把cwnd增加一倍，這就是慢開始演算法
當cwnd>ssthresh就停止上述的慢開始演算法而使用擁塞避免演算法
擁塞避免演算法就是每收到一個回覆後就把cwnd加1，直到出現擁塞
無論在慢開始還是擁塞避免時只要出現擁塞就把ssthresh設為cwnd值的一半（這就是乘法減小)並把cwnd設為1，在執行慢開始演算法，重複上述過程
流量控制
利用滑動視窗機制可以很方便地在TCP連線上實現對傳送方的流量控制。
設A向B傳送資料。在連線建立時，B告訴了A：“我的接收視窗是rwnd = 400”（這裡的rwnd表示receiver window）。因此，傳送方的傳送視窗不能超過接收方給出的接收視窗的數值。請注意：TCP的視窗單位是位元組，不是報文段
wireshark抓到的包與對應的協議層如下圖所示：
1. Frame: 物理層的資料幀概況
2. Ethernet II: 資料鏈路層乙太網幀頭部資訊
3. Internet Protocol Version 4: 網際網路層IP包頭部資訊
4. Transmission Control Protocol: 傳輸層的資料段頭部資訊，此處是TCP
5. Hypertext Transfer Protocol: 應用層的資訊，此處是HTTP協議
二. TCP協議
TCP模型特點
TCP是一種面向連線（連線導向）的、可靠的基於位元組流的傳輸層通訊協議。TCP將使用者資料打包成報文段，它傳送後啟動一個定時器，另一端收到的資料進行確認、對失序的資料重新排序、丟棄重複資料。
TCP的特點有：
1. TCP是面向連線的運輸層協議
2. 每一條TCP連線只能有兩個端點，每一條TCP連線只能是點對點的
3. TCP提供可靠交付的服務
4. TCP提供全雙工通訊。資料在兩個方向上獨立的進行傳輸。因此，連線的每一端必須保持每個方向上的傳輸資料序號。
5. 面向位元組流。面向位元組流的含義：雖然應用程式和TCP互動是一次一個資料塊，但TCP把應用程式交下來的資料僅僅是一連串的無結構的位元組流
TCP報文首部，如下圖所示：
1. 源埠號：資料發起者的埠號，16bit
2. 目的埠號：資料接收者的埠號，16bit
3. 序號：32bit的序列號，由傳送方使用
4. 確認序號：32bit的確認號，是接收資料方期望收到傳送方的下一個報文段的序號，因此確認序號應當是上次已成功收到資料位元組序號加1。
5. 首部長度：首部中32bit字的數目，可表示15*32bit=60位元組的首部。一般首部長度為20位元組。
6. 保留：6bit, 均為0
7. 緊急URG：當URG=1時，表示報文段中有緊急資料，應儘快傳送。
8. 確認位元ACK：ACK = 1時代表這是一個確認的TCP包，取值0則不是確認包。
9. 推送位元PSH：當傳送端PSH=1時，接收端儘快的交付給應用程序。
10. 復位位元（RST）：當RST=1時，表明TCP連線中出現嚴重差錯，必須釋放連線，再重新建立連線。
11. 同步位元SYN：在建立連線是用來同步序號。SYN=1， ACK=0表示一個連線請求報文段。SYN=1，ACK=1表示同意建立連線。
12. 終止位元FIN：FIN=1時，表明此報文段的傳送端的資料已經發送完畢，並要求釋放傳輸連線。
13. 視窗：用來控制對方傳送的資料量，通知發放已確定的傳送視窗上限。
14. 檢驗和：該欄位檢驗的範圍包括首部和資料這兩部分。由發端計算和儲存，並由收端進行驗證。
15. 緊急指標：緊急指標在URG=1時才有效，它指出本報文段中的緊急資料的位元組數。
16. 選項：長度可變，最長可達40位元組
wireshark捕獲到的TCP包中的每個欄位如下圖所示：
三. TCP三次握手
TCP建立連線時，會有三次握手過程，如下圖所示，wireshark截獲到了三次握手的三個資料包。第四個包才是http的，說明http的確是使用TCP建立連線的。
TCP三次握手過程
第一次握手：客戶端向伺服器傳送連線請求包，標誌位SYN（同步序號）置為1，序號為X=0
第二次握手：伺服器由SYN=1知道客戶端要求建立聯機。向客戶端傳送一個SYN和ACK都置為1的TCP報文，設定初始序號Y=0（隨機），將確認序號(Acknowledgement Number)設定為客戶的序列號加1，即X+1 = 0+1=1
第三次握手：客戶端收到伺服器發來的包後檢查確認序號(Acknowledgement Number)是否正確，即第一次傳送的序號加1（X+1=1）。以及標誌位ACK是否為1。若正確，伺服器再次傳送確認包，ACK標誌位為1，SYN標誌位為0。確認序號(Acknowledgement Number)=Y+1=0+1=1，傳送序號為X+1=1。客戶端收到後確認序號值與ACK=1則連線建立成功，可以傳送資料了。
下面來逐步分析三次握手過程：
第一次握手：客戶端向伺服器傳送連線請求包，標誌位SYN（同步序號）置為1，序號為X=0
第二次握手：伺服器收到客戶端發過來報文，由SYN=1知道客戶端要求建立聯機。向客戶端傳送一個SYN和ACK都置為1的TCP報文，設定初始序號Y=0，將確認序號(Acknowledgement Number)設定為客戶的序列號加1，即X+1 = 0+1=1, 如下圖：
第三次握手：客戶端收到伺服器發來的包後檢查確認序號(Acknowledgement Number)是否正確，即第一次傳送的序號加1（X+1=1）。以及標誌位ACK是否為1。若正確，伺服器再次傳送確認包，ACK標誌位為1，SYN標誌位為0。確認序號(Acknowledgement Number)=Y+1=0+1=1，傳送序號為X+1=1。客戶端收到後確認序號值與ACK=1則連線建立成功，可以傳送資料了。
四. TCP四次揮手
TCP斷開連線時，會有四次揮手過程，如下圖所示，wireshark截獲到了四次揮手的四個資料包。
TCP四次揮手過程
第一次揮手：客戶端給伺服器傳送TCP包，用來關閉客戶端到伺服器的資料傳送。將標誌位FIN和ACK置為1，序號為X=1，確認序號為Z=1。
第二次揮手：伺服器收到FIN後，發回一個ACK(標誌位ACK=1),確認序號為收到的序號加1，即X=X+1=2。序號為收到的確認序號=Z。
第三次揮手：伺服器關閉與客戶端的連線，傳送一個FIN。標誌位FIN和ACK置為1，序號為Y=1，確認序號為X=2。
第四次揮手：客戶端收到伺服器傳送的FIN之後，發回ACK確認(標誌位ACK=1),確認序號為收到的序號加1，即Y+1=2。序號為收到的確認序號X=2。
下面來逐步分析四次揮手過程：
第一次揮手：客戶端給伺服器傳送TCP包，用來關閉客戶端到伺服器的資料傳送。將標誌位FIN和ACK置為1，序號為X=1，確認序號為Z=1。
第二次揮手：伺服器收到FIN後，發回一個ACK(標誌位ACK=1),確認序號為收到的序號加1，即X=X+1=2。序號為收到的確認序號=Z。
第三次揮手：伺服器關閉與客戶端的連線，傳送一個FIN。標誌位FIN和ACK置為1，序號為Y=1，確認序號為X=2。
第四次揮手：客戶端收到伺服器傳送的FIN之後，發回ACK確認(標誌位ACK=1),確認序號為收到的序號加1，即Y+1=2。序號為收到的確認序號X=2。
重點補充一下：
在四次揮手的分析過程中，只看到1、3、4次揮手的資料包，第二次的不見了。
原來是因為：ACK延遲傳送機制。為了提高效能，TCP在收到ACK之後會攢起來而不是立即傳送的，在幾種情況下才會發送：
1 超過MSS（可以理解為攢得太多了，放不下了）
2 有FIN
3 系統設定為禁用延遲（TCP_NODELAY）
倒數第二條的前面應該還有一個ACK，因為不符合上述3條，所以被延遲（一般是40ms或者200ms）了，等到倒數第二條發出時符合條件了（有FIN）就一塊發出來了，所以4次揮手只能看到3個包。如果系統禁用了延遲傳送，就會看到4個包了。
所以據我自己理解，首先客戶端會發送關閉的請求（FIN=1，ACK=1），本來在第二次揮手中，應該傳送ACK=Seq+1給客戶端，但因為被延遲，直到伺服器需要傳送FIN才一起傳送出來（FIN=1，ACK=1），這樣子可以節省能量，最後客戶端收到伺服器的FIN後，發回ACK進行確認。
簡單的例子：
0.003183 192.168.21.137 72.14.203.147 TCP 38039 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSV=36941509 TSER=0 WS=6
0.011707 72.14.203.147 192.168.21.137 TCP http > 38039 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460
0.011770 192.168.21.137 72.14.203.147 TCP 38039 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0
以上三個資料包就是著名的TCP三次握手的資料包，其中38039是客戶端的TCP埠，http的預設埠是80，如果tcpdump在/etc/services中發現埠對應的服務名稱，那麼會自動的轉為名字，所以這裡會顯示為http。表示客戶端的38039埠和伺服器端的http埠進行TCP三次握手。
R1區域用來顯示簡單的資料包資訊，我們用tcpdump抓包的時候，預設情況下也是顯示成這樣的；R2區域用來顯示選中的資料包的詳細資訊，細心一點會發現他是按照TCP/IP四層結構顯示的，第一行是資料鏈路層的資訊，第二行是網路層資訊（IP協議），第三行是傳輸層資訊（TCP協議），第四行是應用層資訊（HTTP協議），可以展開每一行用來觀察具體的內容；R3區域是用來顯示此資料包的真實面目。我們在R1和R2區域看到的資訊都是Wireshark整理以後給我們看的，抓包的真實資料實際上是一堆二進位制序列，用ultraedit開啟google.cap檔案可以看到就是一些數字