TCP（Transmission Control Protocol 傳輸控制協(xié)議）是一種面向連接的锉罐、可靠的淌山、基于字節(jié)流的傳輸層通信協(xié)議屯碴。
tcp頭部關(guān)鍵字
- SYN：SYN(SYNchronization)在連接建立時用來同步序號茅逮。當SYN=1而ACK=0時巧涧，表明這是一個連接請求報文薯蝎。對方若同意建立連接，則應(yīng)在響應(yīng)報文中使SYN=1和ACK=1. 因此, SYN置1就表示這是一個連接請求或連接接受報文谤绳；
- ack：此標志表示應(yīng)答域有效占锯，就是說前面所說的TCP應(yīng)答號將會包含在TCP數(shù)據(jù)包中;有兩個取值：0和1， 為1的時候表示應(yīng)答域有效缩筛，反之為0;
- seq：Sequence Number:用來標識從TCP發(fā)端向TCP收端發(fā)送的數(shù)據(jù)字節(jié)流消略，它表示在這個報文段中的的第一個數(shù)據(jù) 字節(jié)在數(shù)據(jù)流中的序號;主要用來解決網(wǎng)絡(luò)報亂序的問題;
- FIN： 表示發(fā)送端已經(jīng)達到數(shù)據(jù)末尾，也就是說雙方的數(shù)據(jù)傳送完成瞎抛，沒有數(shù)據(jù)可以傳送了艺演，發(fā)送FIN標志 位的TCP數(shù)據(jù)包后，連接將被斷開桐臊。這個標志的數(shù)據(jù)包也經(jīng)常被用于進行端口掃描胎撤。
三次握手：
客戶端A------服務(wù)端B
第一次握手：
A-[SYN|seq]->B
客戶端向服務(wù)端發(fā)送syn標記的包，通知服務(wù)端要建立連接断凶；
此過程中服務(wù)端和客戶端均不能確定自己是否是ok的伤提；第二次握手：
B-[SYN|ACK|seq]->A
服務(wù)端向客戶端發(fā)送確認包SYN/ACK，表示收到前邊建立連接的請求懒浮；
此過程中客戶端A收到服務(wù)端的確認包飘弧，說明客戶端接收和發(fā)送的ok的识藤；但此時服務(wù)端并不知道自己的情況砚著；第三次握手：
A-[ack]->B
客戶端向服務(wù)端發(fā)送確認包，表示收到服務(wù)端的確認請求痴昧；
此過程中服務(wù)端收到客戶端發(fā)來的確認包稽穆，服務(wù)端自己的接收和發(fā)送都是ok的，雙方開始通信赶撰；三次握手完成舌镶。
客戶端收到服務(wù)器的SYN+ACK報文段柱彻。然后將Acknowledgment Number設(shè)置為y+1，向服務(wù)器發(fā)送ACK報文段餐胀，這個報文段發(fā)送完畢以后哟楷，客戶端和服務(wù)器端都進入ESTABLISHED狀態(tài)，完成TCP三次握手否灾。
完成了三次握手卖擅，客戶端和服務(wù)器端就可以開始傳送數(shù)據(jù)。
為什么一定要三次握手呢墨技？
- 保證兩端都能清楚的知道自身的收發(fā)情況惩阶，兩次握手的話客戶端雖然已經(jīng)知道自己的收發(fā)情況，并且也知道服務(wù)端的收發(fā)情況扣汪，但是服務(wù)端并不知道断楷，所以需要第三次握手；
- 防止已失效的連接請求報文段突然又傳送到了服務(wù)端崭别，因而產(chǎn)生錯誤冬筒；
例如： - 客服端發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡(luò)結(jié)點長時間的滯留了紊遵，以致延誤到連接釋放以后的某個時間才到達服務(wù)端账千。
- 本來這是一個早已失效的報文段茴她。但服務(wù)端收到此失效的連接請求報文段后椒功，就誤認為是客戶端再次發(fā)出的一個新的連接請求峰尝。于是就向客戶端發(fā)出確認報文段赃阀，同意建立連接鞠呈。
- 假設(shè)不采用“三次握手”娃豹，那么只要服務(wù)端發(fā)出確認山析，新的連接就建立了奶是。由于現(xiàn)在客戶端并沒有發(fā)出建立連接的請求瑞佩，因此不會理睬服務(wù)端的確認聚磺，也不會向服務(wù)端發(fā)送數(shù)據(jù)。
- 但服務(wù)端卻以為新的運輸連接已經(jīng)建立炬丸，并一直等待客戶端發(fā)來數(shù)據(jù)瘫寝。這樣，服務(wù)端的很多資源就白白浪費掉了稠炬。
-
采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生焕阿。例如剛才那種情況，客戶端不會服務(wù)端的確認發(fā)出確認首启。服務(wù)端由于收不到確認暮屡，就知道客戶端并沒有要求建立連接。
tcp.jpg
四次揮手：
客戶端A------服務(wù)端B
第一次揮手：
A-[FIN|seq|ack]->B
客戶端已經(jīng)沒有數(shù)據(jù)向服務(wù)端發(fā)送毅桃，并且向客服端發(fā)起結(jié)束請求褒纲；此時客戶端進入fin_wait_1階段
fin_wait_1：第一次等待結(jié)束態(tài)准夷；標明客戶端主動發(fā)起結(jié)束連接的請求第二次揮手：
B-[ack]->A
服務(wù)端收到客戶端結(jié)束的請求(此時可能服務(wù)端還有數(shù)據(jù)發(fā)送給客戶端)，不管當前狀態(tài)如何莺掠，立馬向客戶端發(fā)送已經(jīng)收到客戶端結(jié)束請求的確認信息衫嵌；
注意：如果不發(fā)送的話，客戶端長時間收不到確認消息彻秆，會認為之前發(fā)送失敗渐扮，導(dǎo)致重新發(fā)送結(jié)束請求；
此時客戶端收到服務(wù)端的確認信息進入fin_wait_2階段
fin_wait_2：第二次等待結(jié)束態(tài)掖棉；標明服務(wù)端已經(jīng)接收到客戶端的結(jié)束請求墓律，并且客戶端已經(jīng)收到確認消息第三次揮手：
B-[FIN|seq|ack]->A
服務(wù)端向客戶端發(fā)送結(jié)束連接的請求，表示服務(wù)端已經(jīng)沒有數(shù)據(jù)向客戶端發(fā)送幔亥，可以結(jié)束請求耻讽；而服務(wù)端則進入close_wait階段
close_wait： 等待關(guān)閉態(tài)；服務(wù)端發(fā)起結(jié)束連接請求帕棉，等待客戶端的確認信息第四次揮手：
A-[ack]->B
客戶端收到服務(wù)端結(jié)束連接請求针肥，向服務(wù)端發(fā)出確認關(guān)閉的請求，并進入time_wait階段香伴；
服務(wù)端接收到請求則關(guān)閉連接慰枕；
客戶端等待2MSL后依然沒有收到回復(fù)，說明服務(wù)端已經(jīng)正常關(guān)閉即纲，此時客戶端自己關(guān)閉連接具帮；
time_wait： 表示收到了對方的FIN報文，并發(fā)送出了ACK報文低斋，就等2MSL后即可回到CLOSED可用狀態(tài)了蜂厅。
注意：如果fin_wait_1狀態(tài)下，收到了對方同時帶FIN標志和ACK標志的報文時膊畴，可以直接進入到time_wait狀態(tài)掘猿，而無須經(jīng)過fin_wait_2狀態(tài)
此時，四次揮手結(jié)束唇跨。
參考：
關(guān)于TCP協(xié)議稠通，我想你應(yīng)該懂了!
通俗大白話來理解TCP協(xié)議的三次握手和四次分手
TCP協(xié)議要點和難點全解
TCP三次握手連接及seq和ack號的正確理解
