TCP協(xié)議是什么

這篇文章將為大家詳細(xì)講解有關(guān)TCP協(xié)議是什么，小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

TCP協(xié)議是TCP/IP體系中核心一個(gè)協(xié)議，該協(xié)議比起IP協(xié)議，ICMP協(xié)議，UDP協(xié)議都更復(fù)雜，因此這篇文章主要分析TCP協(xié)議在建立連接和斷開連接的時(shí)候，狀態(tài)轉(zhuǎn)移以及報(bào)文段的內(nèi)容。
下面，先放一張TCP的狀態(tài)轉(zhuǎn)移圖：

TCP協(xié)議之三次握手

三次握手的過(guò)程是TCP在客戶端和服務(wù)端建立連接的過(guò)程。簡(jiǎn)單的來(lái)說(shuō)三次握手過(guò)程，就是客戶端先發(fā)送一個(gè)連接請(qǐng)求給服務(wù)端，這是第一次握手。服務(wù)端接收到客戶端發(fā)來(lái)的鏈接請(qǐng)求，然后在將確認(rèn)的消息發(fā)給客戶端，這是第二次握手?？蛻舳藢?duì)服務(wù)端發(fā)來(lái)的確認(rèn)消息進(jìn)行確認(rèn)，然后將確認(rèn)的消息發(fā)給服務(wù)端，這就是三次握手。三次握手之后，鏈接建立。
為什么一定是三次握手才能建立一個(gè)可靠地鏈接？如果不是三次握手，那么在客戶端發(fā)送了鏈接請(qǐng)求之后，服務(wù)端對(duì)這個(gè)請(qǐng)求進(jìn)行確認(rèn)，就認(rèn)定這次的鏈接已經(jīng)成功建立，俗稱的二次握手。這樣的方式的弊端在哪里？
考慮這么一種情況，當(dāng)客戶端進(jìn)行第一次握手時(shí)，發(fā)送了一個(gè)報(bào)文段，但是這個(gè)報(bào)文段因?yàn)榫W(wǎng)絡(luò)的問(wèn)題，遲遲沒(méi)有到，這時(shí)，客戶端又會(huì)再一次發(fā)送一個(gè)連接請(qǐng)求的報(bào)文段給服務(wù)端，這次成功接收，兩者建立連接，并通信結(jié)束，關(guān)閉連接。這之后，因?yàn)榫W(wǎng)絡(luò)延遲的那個(gè)報(bào)文段傳到了服務(wù)端那里，服務(wù)端又以為客戶端要建立新的連接，于是就同意了，向客戶端發(fā)送確認(rèn)。因?yàn)槭嵌挝帐?，所以服?wù)端后續(xù)要做的事情，就是等待客戶端發(fā)送的消息，但是客戶端是不會(huì)理會(huì)服務(wù)端傳來(lái)的確認(rèn)，所以服務(wù)端就會(huì)一直在等待客戶端的數(shù)據(jù)，白白浪費(fèi)了資源。

抓包分析TCP三次握手的報(bào)文段

現(xiàn)在，詳細(xì)說(shuō)一下三次握手具體是做了什么。
第一次握手，客戶端發(fā)送一個(gè)報(bào)文段給服務(wù)端，該報(bào)文段中標(biāo)志有SYN標(biāo)志，該標(biāo)志表示建立連接，以及一個(gè)初始的序列號(hào)。
第二次握手時(shí)，服務(wù)端發(fā)送一個(gè)報(bào)文段給客戶端，該報(bào)文段中標(biāo)志有SYN標(biāo)志，和ACK標(biāo)志。ACK標(biāo)志的值是客戶端發(fā)來(lái)的初始序號(hào)值+ 1，表示對(duì)客戶端進(jìn)行確認(rèn)，報(bào)文段中還有服務(wù)端自己的初始序號(hào)。
第三次握手時(shí)，客戶端發(fā)送一個(gè)報(bào)文段給服務(wù)端，該報(bào)文段中標(biāo)志只有ACK標(biāo)志，該ACK值是服務(wù)端的初始序列化的值 + 1，表示對(duì)服務(wù)端進(jìn)行確認(rèn)，以及還有一個(gè)序號(hào)值，該序號(hào)值為客戶端第一次握手時(shí)的序號(hào)值 + 1。
三次握手建立連接結(jié)束。

圖片上共有三行，每一行代表一次握手。我們先看第一行

可以看出，第一次握手時(shí)55732端口的程序主動(dòng)發(fā)送一個(gè)建立鏈接的報(bào)文段給8888端口。這個(gè)55732端口是Java程序?qū)懙囊粋€(gè)Socket客戶端，8888端口是Socket程序?qū)懙姆?wù)端。建立連接的報(bào)文段，F(xiàn)lags中，只有SYN是為1的，這表明這是一個(gè)建立連接的報(bào)文段，該報(bào)文段中初始的序列號(hào)為0，ACK的number也為0。

第二次握手，是服務(wù)端發(fā)送給客戶端一個(gè)報(bào)文段，表示確認(rèn)收到了客戶端的鏈接請(qǐng)求。該報(bào)文段中標(biāo)志位有兩個(gè)一個(gè)是ACK，一個(gè)SYN。表示收到鏈接請(qǐng)求，端口開放。該報(bào)文段中也會(huì)發(fā)送一個(gè)服務(wù)端自己的初始序列號(hào)。注意，這里ACK的值變成了1，是客戶端初始序列號(hào) + 1才有的。

第三次握手，是客戶端發(fā)送給服務(wù)端一個(gè)報(bào)文段，表示確認(rèn)收到了服務(wù)端的確認(rèn)。因?yàn)殡p方端口都已經(jīng)打開，所以客戶端在發(fā)，就不會(huì)再有SYN標(biāo)志了，這里只有ACK標(biāo)志，該標(biāo)志的值也是1，是因?yàn)榉?wù)端的初始序列號(hào) + 1造成的。這里的序列號(hào)為1，是因?yàn)榈谝淮挝帐?，發(fā)送了一個(gè)SYN標(biāo)志，該標(biāo)志會(huì)占用1個(gè)序號(hào)值，但是ACK不會(huì)。
對(duì)應(yīng)到上面的狀態(tài)圖中，就是客戶端是主動(dòng)打開，從起始點(diǎn)發(fā)送SYN報(bào)文段，進(jìn)入SYN_SENT狀態(tài)，然后接受SYN,ACK，走黑粗線的路徑進(jìn)入到數(shù)據(jù)傳輸狀態(tài)，也就是ESTABLISHED,對(duì)于服務(wù)端而言，就是從起始點(diǎn)走虛線的部分，被動(dòng)打開后，接受客戶端的SYN，進(jìn)入SYN_RCVD，最后，接受客戶端第三次握手的ACK，進(jìn)入數(shù)據(jù)傳輸狀態(tài)，也就是ESTABLISHED。

TCP協(xié)議之四次揮手

TCP協(xié)議是一種全雙工協(xié)議，擁有半關(guān)閉的特性。

全雙工的意思是A可以往B發(fā)送數(shù)據(jù)，B同時(shí)也可以給A發(fā)送數(shù)據(jù)。
半雙工的意思是A可以往B發(fā)送數(shù)據(jù)，B也可以給A發(fā)送數(shù)據(jù)，但是兩者不能同時(shí)。
單工的意思是只能A給B發(fā)送數(shù)據(jù)，或者B給A發(fā)送數(shù)據(jù)。
半關(guān)閉的意思是將全雙工，變成單工，也就是如果B關(guān)閉，是指B不能給A發(fā)數(shù)據(jù)了，但是A可以給B發(fā)

所以TCP協(xié)議如果要正常的關(guān)閉客戶端與服務(wù)端的鏈接，需要四次報(bào)文段，也就是4次揮手。
首先，客戶端因?yàn)閼?yīng)用程序的執(zhí)行完畢，會(huì)主動(dòng)開始斷開鏈接，這時(shí)會(huì)發(fā)送一個(gè)含有FIN標(biāo)志位的報(bào)文段。這表明客戶端不會(huì)再發(fā)送數(shù)據(jù)給服務(wù)端。這時(shí)第一次揮手。
然后，服務(wù)端接收到這個(gè)報(bào)文段，就會(huì)發(fā)送一個(gè)含有ACK標(biāo)志的報(bào)文段給客戶端，表示確認(rèn)收到了關(guān)閉的報(bào)文段。這是第二次揮手。
然后，服務(wù)端在處理完服務(wù)端的事情后，也會(huì)發(fā)送一個(gè)含有FIN的報(bào)文段給客戶端，表示服務(wù)端不會(huì)再發(fā)送數(shù)據(jù)給客戶端。這是第三次揮手。
最后，客戶端收到這個(gè)報(bào)文段后，就會(huì)發(fā)送一個(gè)含有ACK的報(bào)文段給服務(wù)端，表示確認(rèn)收到了關(guān)閉的報(bào)文段。這是第四次揮手。至此，鏈接全部關(guān)閉。

抓包分析TCP四次揮手的報(bào)文段

不用看黑色報(bào)文，4行代表關(guān)閉的4次揮手的過(guò)程，每一行是一次揮手。
第一行，是客戶端主動(dòng)關(guān)閉鏈接，發(fā)送一個(gè)含有FIN的報(bào)文段，這是第一次揮手
第二行，是服務(wù)端確認(rèn)客戶端的FIN報(bào)文，發(fā)送一個(gè)ACK的確認(rèn)報(bào)文，該ACK的值是9，而第一行的序列號(hào)的8,因?yàn)榕cSYN一樣，F(xiàn)IN也占一個(gè)序列號(hào)。
忽略黑的后第三行，服務(wù)端發(fā)送一個(gè)含有FIN的報(bào)文段，這是第三次揮手。
第四行，客戶端會(huì)這個(gè)FIN報(bào)文段進(jìn)行確認(rèn)，發(fā)送了一個(gè)ACK報(bào)文段。該ACK的值是第三行的序列號(hào) + 1。

對(duì)應(yīng)到上面的狀態(tài)圖中，先說(shuō)服務(wù)端的狀態(tài)轉(zhuǎn)移，因?yàn)槭盏搅丝蛻舳说腇IN，所以發(fā)送一個(gè)ACK給客戶端，同時(shí)自己進(jìn)入到CLOSE_WAIT狀態(tài)，等待服務(wù)端應(yīng)用程序結(jié)束，發(fā)送FIN給客戶端，自己進(jìn)入LAST_ACK狀態(tài)，等待最后的ACK到來(lái)，接收到ACK，結(jié)束狀態(tài)。

客戶端因?yàn)橄劝l(fā)起關(guān)閉，狀態(tài)比較復(fù)雜，他先發(fā)送一個(gè)FIN給服務(wù)端，自己進(jìn)入了FIN_WAIT_1狀態(tài)，這時(shí)他等待接收服務(wù)端的報(bào)文，該報(bào)文會(huì)有三種可能：

1. 只有服務(wù)端的ACK

2. 只有服務(wù)端的FIN

3. 基于服務(wù)端的ACK，又有FIN

對(duì)于第一種，該ACK是服務(wù)端確認(rèn)了客戶端的FIN而發(fā)的，這時(shí)客戶端會(huì)進(jìn)入FIN_WAIT_2狀態(tài)，這是當(dāng)他收到服務(wù)端的FIN來(lái)時(shí)，發(fā)送了一個(gè)ACK，會(huì)進(jìn)入到TIME_WAIT狀態(tài)，他要在這個(gè)狀態(tài)等待2MSL的時(shí)間，1個(gè)MSL是報(bào)文段在網(wǎng)絡(luò)的最長(zhǎng)時(shí)間，客戶端等待2MSL，是為了當(dāng)最后一個(gè)ACK丟失時(shí)，可以在發(fā)送一次，因?yàn)檫@時(shí)，服務(wù)端在等待超時(shí)后在發(fā)送一個(gè)FIN給客戶端，所以客戶端也知道了ACK丟失了。

對(duì)于第二種，只有服務(wù)端的FIN的時(shí)，會(huì)發(fā)送一個(gè)ACK給服務(wù)端，客戶端進(jìn)入CLOSING狀態(tài)，然后接收到服務(wù)端的ACK時(shí)，也會(huì)進(jìn)入TIME_WAIT狀態(tài)。

對(duì)于第三種，同時(shí)都收到了，就省略了進(jìn)入CLOSING狀態(tài)，直接進(jìn)入TIME_WAIT狀態(tài)。抓包分析的截圖，就是這種情況。

關(guān)于“TCP協(xié)議是什么”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，請(qǐng)把它分享出去讓更多的人看到。