TCP的三次握手和四次揮手

簡介

TCP連接是面向連接的、可靠的用爪、基于字節(jié)流的傳輸層通信協(xié)議原押。在傳輸數(shù)據(jù)之前,通信雙方必須建立一條連接偎血。所謂的‘連接’诸衔,其實就是客戶端和服務端保存的一份對方的信息,如:ip地址颇玷、端口號等笨农。在連接的建立過程中,雙方需要交換一些連接的參數(shù)帖渠。這些參數(shù)可以放在TCP頭部谒亦。一個TCP連接由一個4元組構成,分別是兩個ip地址和兩個端口號空郊。一個TCP連接通常分為三個階段:連接诊霹、數(shù)據(jù)傳輸、退出(關閉)渣淳。通過三次握手來創(chuàng)建一個連接脾还,通過四次揮手來關閉一個連接。當一個連接被建立或被終止時入愧,交換的保溫只包含TCP頭部鄙漏,而沒有數(shù)據(jù)。

1.TCP報文的頭部結構

image.png

上圖幾個字段重點介紹下:
(1)序號:seq序號棺蛛,占32位
(2)確認序號:ack序號怔蚌,占32位,只有ACK標志位為1時旁赊,確認序號字段才有效桦踊,ack=seq+1。
(3)標志位:共6個,即URG终畅、ACK籍胯、PSH、RST离福、SYN杖狼、FIN等,具體含義如下:

ACK:確認序號有效妖爷。
FIN:釋放一個連接蝶涩。
PSH:接收方應該盡快將這個報文交給應用層。
RST:重置連接。SYN:發(fā)起一個新連接绿聘。
URG:緊急指針(urgent pointer)有效嗽上。需要注意的是:不要將確認序號ack與標志位中的ACK搞混了。確認方ack=發(fā)起方seq+1熄攘,兩端配對兽愤。
<meta charset="utf-8">

2. 三次握手

三次握手的本質是確認通信雙方收發(fā)數(shù)據(jù)的能力首先,我讓信使運輸一份信件給對方鲜屏,對方收到了烹看,那么他就知道了我的發(fā)件能力和他的收件能力是可以的国拇。于是他給我回信洛史,我若收到了,我便知我的發(fā)件能力和他的收件能力是可以的酱吝,并且他的發(fā)件能力和我的收件能力是可以也殖。然而此時他還不知道他的發(fā)件能力和我的收件能力到底可不可以,于是我最后回饋一次务热,他若收到了忆嗜,他便清楚了他的發(fā)件能力和我的收件能力是可以的。這崎岂,就是三次握手捆毫。

image
  • 第一次握手:客戶端要向服務端發(fā)起連接請求,首先客戶端隨機生成一個起始序列號ISN(比如是100)冲甘,那客戶端向服務端發(fā)送的報文段包含SYN標志位(也就是SYN=1)绩卤,序列號seq=100。
  • 第二次握手:服務端收到客戶端發(fā)過來的報文后江醇,發(fā)現(xiàn)SYN=1濒憋,知道這是一個連接請求,于是將客戶端的起始序列號100存起來陶夜,并且隨機生成一個服務端的起始序列號(比如是300)凛驮。然后給客戶端回復一段報文,回復報文包含SYN和ACK標志(也就是SYN=1,ACK=1)条辟、序列號seq=300黔夭、確認號ack=101(客戶端發(fā)過來的序列號+1)。
  • 第三次握手:客戶端收到服務端的回復后發(fā)現(xiàn)ACK=1并且ack=101,于是知道服務端已經收到了序列號為100的那段報文羽嫡;同時發(fā)現(xiàn)SYN=1纠修,知道了服務端同意了這次連接,于是就將服務端的序列號300給存下來厂僧。然后客戶端再回復一段報文給服務端扣草,報文包含ACK標志位(ACK=1)、ack=301(服務端序列號+1)、seq=101(第一次握手時發(fā)送報文是占據(jù)一個序列號的辰妙,所以這次seq就從101開始鹰祸,需要注意的是不攜帶數(shù)據(jù)的ACK報文是不占據(jù)序列號的,所以后面第一次正式發(fā)送數(shù)據(jù)時seq還是101)密浑。當服務端收到報文后發(fā)現(xiàn)ACK=1并且ack=301蛙婴,就知道客戶端收到序列號為300的報文了,就這樣客戶端和服務端通過TCP建立了連接尔破。

3. 四次揮手

四次揮手的目的是關閉一個連接

image

比如客戶端初始化的序列號ISA=100街图,服務端初始化的序列號ISA=300。TCP連接成功后客戶端總共發(fā)送了1000個字節(jié)的數(shù)據(jù)懒构,服務端在客戶端發(fā)FIN報文前總共回復了2000個字節(jié)的數(shù)據(jù)餐济。

  • 第一次揮手:當客戶端的數(shù)據(jù)都傳輸完成后,客戶端向服務端發(fā)出連接釋放報文(當然數(shù)據(jù)沒發(fā)完時也可以發(fā)送連接釋放報文并停止發(fā)送數(shù)據(jù))胆剧,釋放連接報文包含F(xiàn)IN標志位(FIN=1)絮姆、序列號seq=1101(100+1+1000,其中的1是建立連接時占的一個序列號)秩霍。需要注意的是客戶端發(fā)出FIN報文段后只是不能發(fā)數(shù)據(jù)了篙悯,但是還可以正常收數(shù)據(jù);另外FIN報文段即使不攜帶數(shù)據(jù)也要占據(jù)一個序列號铃绒。
  • 第二次揮手:服務端收到客戶端發(fā)的FIN報文后給客戶端回復確認報文鸽照,確認報文包含ACK標志位(ACK=1)、確認號ack=1102(客戶端FIN報文序列號1101+1)颠悬、序列號seq=2300(300+2000)矮燎。此時服務端處于關閉等待狀態(tài),而不是立馬給客戶端發(fā)FIN報文椿疗,這個狀態(tài)還要持續(xù)一段時間漏峰,因為服務端可能還有數(shù)據(jù)沒發(fā)完。
  • 第三次揮手:服務端將最后數(shù)據(jù)(比如50個字節(jié))發(fā)送完畢后就向客戶端發(fā)出連接釋放報文届榄,報文包含F(xiàn)IN和ACK標志位(FIN=1,ACK=1)浅乔、確認號和第二次揮手一樣ack=1102、序列號seq=2350(2300+50)铝条。
  • 第四次揮手:客戶端收到服務端發(fā)的FIN報文后靖苇,向服務端發(fā)出確認報文,確認報文包含ACK標志位(ACK=1)班缰、確認號ack=2351贤壁、序列號seq=1102。注意客戶端發(fā)出確認報文后不是立馬釋放TCP連接埠忘,而是要經過2MSL(最長報文段壽命的2倍時長)后才釋放TCP連接脾拆。而服務端一旦收到客戶端發(fā)出的確認報文就會立馬釋放TCP連接馒索,所以服務端結束TCP連接的時間要比客戶端早一些。

4. 常見面試題

  1. 為什么TCP連接的時候是3次名船?2次不可以嗎绰上?
  • 因為需要考慮連接時丟包的問題,如果只握手2次渠驼,第二次握手時如果服務端發(fā)給客戶端的確認報文段丟失蜈块,此時服務端已經準備好了收發(fā)數(shù)(可以理解服務端已經連接成功)據(jù),而客戶端一直沒收到服務端的確認報文迷扇,所以客戶端就不知道服務端是否已經準備好了(可以理解為客戶端未連接成功)百揭,這種情況下客戶端不會給服務端發(fā)數(shù)據(jù),也會忽略服務端發(fā)過來的數(shù)據(jù)蜓席。如果是三次握手器一,即便發(fā)生丟包也不會有問題,比如如果第三次握手客戶端發(fā)的確認ack報文丟失瓮床,服務端在一段時間內沒有收到確認ack報文的話就會重新進行第二次握手盹舞,也就是服務端會重發(fā)SYN報文段产镐,客戶端收到重發(fā)的報文段后會再次給服務端發(fā)送確認ack報文隘庄。
  1. 為什么TCP連接的時候是3次,關閉的時候卻是4次癣亚?
  • 因為只有在客戶端和服務端都沒有數(shù)據(jù)要發(fā)送的時候才能斷開TCP丑掺。而客戶端發(fā)出FIN報文時只能保證客戶端沒有數(shù)據(jù)發(fā)了,服務端還有沒有數(shù)據(jù)發(fā)客戶端是不知道的述雾。而服務端收到客戶端的FIN報文后只能先回復客戶端一個確認報文來告訴客戶端我服務端已經收到你的FIN報文了街州,但我服務端還有一些數(shù)據(jù)沒發(fā)完,等這些數(shù)據(jù)發(fā)完了服務端才能給客戶端發(fā)FIN報文(所以不能一次性將確認報文和FIN報文發(fā)給客戶端玻孟,就是這里多出來了一次)唆缴。
  1. 為什么客戶端發(fā)出第四次揮手的確認報文后要等2MSL的時間才能釋放TCP連接?
  • 這里同樣是要考慮丟包的問題黍翎,如果第四次揮手的報文丟失面徽,服務端沒收到確認ack報文就會重發(fā)第三次揮手的報文,這樣報文一去一回最長時間就是2MSL匣掸,所以需要等這么長時間來確認服務端確實已經收到了趟紊。

作者:InsaneLoafer
鏈接:http://www.reibang.com/p/0ad0b864b949
來源:簡書
著作權歸作者所有。商業(yè)轉載請聯(lián)系作者獲得授權碰酝,非商業(yè)轉載請注明出處霎匈。

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市送爸,隨后出現(xiàn)的幾起案子铛嘱,更是在濱河造成了極大的恐慌暖释,老刑警劉巖,帶你破解...
    沈念sama閱讀 216,692評論 6 501
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件墨吓,死亡現(xiàn)場離奇詭異饭入,居然都是意外死亡,警方通過查閱死者的電腦和手機肛真,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,482評論 3 392
  • 文/潘曉璐 我一進店門谐丢,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人蚓让,你說我怎么就攤上這事乾忱。” “怎么了历极?”我有些...
    開封第一講書人閱讀 162,995評論 0 353
  • 文/不壞的土叔 我叫張陵窄瘟,是天一觀的道長。 經常有香客問我趟卸,道長蹄葱,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,223評論 1 292
  • 正文 為了忘掉前任锄列,我火速辦了婚禮图云,結果婚禮上,老公的妹妹穿的比我還像新娘邻邮。我一直安慰自己竣况,他們只是感情好,可當我...
    茶點故事閱讀 67,245評論 6 388
  • 文/花漫 我一把揭開白布筒严。 她就那樣靜靜地躺著丹泉,像睡著了一般。 火紅的嫁衣襯著肌膚如雪鸭蛙。 梳的紋絲不亂的頭發(fā)上摹恨,一...
    開封第一講書人閱讀 51,208評論 1 299
  • 那天,我揣著相機與錄音娶视,去河邊找鬼晒哄。 笑死,一個胖子當著我的面吹牛歇万,可吹牛的內容都是我干的揩晴。 我是一名探鬼主播,決...
    沈念sama閱讀 40,091評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼贪磺,長吁一口氣:“原來是場噩夢啊……” “哼硫兰!你這毒婦竟也來了?” 一聲冷哼從身側響起寒锚,我...
    開封第一講書人閱讀 38,929評論 0 274
  • 序言:老撾萬榮一對情侶失蹤劫映,失蹤者是張志新(化名)和其女友劉穎违孝,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體泳赋,經...
    沈念sama閱讀 45,346評論 1 311
  • 正文 獨居荒郊野嶺守林人離奇死亡雌桑,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 37,570評論 2 333
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了祖今。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片校坑。...
    茶點故事閱讀 39,739評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖千诬,靈堂內的尸體忽然破棺而出耍目,到底是詐尸還是另有隱情,我是刑警寧澤徐绑,帶...
    沈念sama閱讀 35,437評論 5 344
  • 正文 年R本政府宣布邪驮,位于F島的核電站,受9級特大地震影響傲茄,放射性物質發(fā)生泄漏毅访。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,037評論 3 326
  • 文/蒙蒙 一盘榨、第九天 我趴在偏房一處隱蔽的房頂上張望喻粹。 院中可真熱鬧,春花似錦较曼、人聲如沸磷斧。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,677評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至冕末,卻和暖如春萍歉,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背档桃。 一陣腳步聲響...
    開封第一講書人閱讀 32,833評論 1 269
  • 我被黑心中介騙來泰國打工枪孩, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人藻肄。 一個月前我還...
    沈念sama閱讀 47,760評論 2 369
  • 正文 我出身青樓蔑舞,卻偏偏與公主長得像,于是被迫代替她去往敵國和親嘹屯。 傳聞我的和親對象是個殘疾皇子攻询,可洞房花燭夜當晚...
    茶點故事閱讀 44,647評論 2 354

推薦閱讀更多精彩內容