Wireshark

本機(jī)ip: 192.168.0.72

訪問地址: [http://www.cnblogs.com/tankxiao]()

記錄378，419，427就對(duì)應(yīng)著著名的TCP三次握手

數(shù)據(jù)幀格式如下

三次握手流程圖

SYN：建立連接

FIN：關(guān)閉連接

ACK：響應(yīng)

PSH：數(shù)據(jù)傳輸

RST：連接重制

A->B:在嗎？聽的到嗎？

B->A:在啊？你聽得到嗎？（告訴A，通過B的回復(fù)來確認(rèn)，A->B通信正常）

A->B:聽的見（告訴B，通過A的回復(fù)來確認(rèn)，B->A通信正常）

第一次握手

客戶端向服務(wù)端建立連接的信號(hào) Syn = 1，seq 為隨機(jī)數(shù)

圖中 Sequence number: 0 (relative sequence number)，反映的是相對(duì)seq

真實(shí)的 seq 在圖中下部分，用16進(jìn)制 "532d0c99"表示，轉(zhuǎn)換成10進(jìn)制為 "1395461273"

第二次握手

服務(wù)端向客戶端發(fā)送響應(yīng) Ack = seq(來自客戶端,1395461273) + 1，Syn = 1，seq 為隨機(jī)數(shù)

圖中 Acknowledgment number: 1 (relative ack number)，反映的是相對(duì)Ack

真實(shí)的 ack 在圖中下部分，用16進(jìn)制"532d0c9a"表示，轉(zhuǎn)換成10進(jìn)制為 "1395461274"

同理 seq "96fb78d2" 的10進(jìn)制為 "2533062866"

第三次握手

客戶端向服務(wù)端發(fā)送響應(yīng) Ack = seq (來自服務(wù)端，2533062866) + 1，seq 為隨機(jī)數(shù)

圖中 Ack 的16進(jìn)制為"96fb78d3"，轉(zhuǎn)換成10進(jìn)制為"2533062867"

圖中 seq 的16進(jìn)制為"532d0c9a"，轉(zhuǎn)換成10進(jìn)制為"1395461274"

至此以后，客戶端就可以愉快地和服務(wù)端通信了

為什么是三次握手

“已失效的連接請(qǐng)求報(bào)文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒有丟失，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server。本來這是一個(gè)早已失效的報(bào)文段。但server收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求。于是就向client發(fā)出確認(rèn)報(bào)文段，同意建立連接。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬server的確認(rèn)，也不會(huì)向server發(fā)送數(shù)據(jù)。但server卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費(fèi)掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn)，就知道client并沒有要求建立連接?！?

摘自謝希仁著《計(jì)算機(jī)網(wǎng)絡(luò)》

傳輸過程

TCP維持?jǐn)?shù)據(jù)不丟失的關(guān)鍵在于Seq和Ack

在18.443018時(shí)，客戶端向服務(wù)端發(fā)送數(shù)據(jù)包P1，內(nèi)容是發(fā)送http請(qǐng)求，Seq = 1,Len = 1083，命名為數(shù)據(jù)包P1

在18.469641時(shí)，服務(wù)端告訴客戶端數(shù)據(jù)包P1已經(jīng)收到， Ack = 數(shù)據(jù)包P1的Seq + 數(shù)據(jù)包P1的Len

在18.495616時(shí)，服務(wù)端向客戶端發(fā)送數(shù)據(jù)包P2，內(nèi)容是html文檔，Seq = 1, Len = 1452

在18.495617時(shí)，服務(wù)端向客戶端發(fā)送數(shù)據(jù)包P3，內(nèi)容仍是html文檔，Seq = 1453，Len = 133

在18.495680時(shí)，客戶端告訴服務(wù)端數(shù)據(jù)包P3已經(jīng)收到，Ack = 數(shù)據(jù)包P3的Seq + 數(shù)據(jù)包P3的Len

TCP提供的確認(rèn)機(jī)制，可以在通信過程中可以不對(duì)每一個(gè)TCP數(shù)據(jù)包發(fā)出單獨(dú)的確認(rèn)包（Delayed ACK機(jī)制），而是在傳送數(shù)據(jù)時(shí)，順便把確認(rèn)信息傳出， 這樣可以大大提高網(wǎng)絡(luò)的利用率和傳輸效率。同時(shí)，TCP的確認(rèn)機(jī)制，也可以一次確認(rèn)多個(gè)數(shù)據(jù)報(bào)，例如，接收方收到了201，301，401的數(shù)據(jù)報(bào)，則只 需要對(duì)401的數(shù)據(jù)包進(jìn)行確認(rèn)即可，對(duì)401的數(shù)據(jù)包的確認(rèn)也意味著401之前的所有數(shù)據(jù)包都已經(jīng)確認(rèn)，這樣也可以提高系統(tǒng)的效率。

在18.496954-18.496961期間，服務(wù)端發(fā)送了5個(gè)數(shù)據(jù)包，其中最后一個(gè)數(shù)據(jù)包是響應(yīng)頭，"HTTP/1.1 200 OK..."

在18.497018-18.499389期間，客戶端對(duì)發(fā)來的數(shù)據(jù)包進(jìn)行確認(rèn)

Seq 與 Ack 的關(guān)系

發(fā)送數(shù)據(jù)包，數(shù)據(jù)的序號(hào)Seq和數(shù)據(jù)的長(zhǎng)度Len

確認(rèn)包，Ack = 收到的最后的數(shù)據(jù)包的序號(hào)Seq+Len，

同時(shí)因?yàn)樽鳛榇_認(rèn)包，在服務(wù)端與客戶端交換數(shù)據(jù)的過程中，沒有向服務(wù)端發(fā)送數(shù)據(jù)，所以 Seq 不變

在某種程度上可以這樣理解Seq和Ack，在發(fā)送這個(gè)包之前，我已經(jīng)向?qū)Ψ桨l(fā)送的數(shù)據(jù)量Seq，我已經(jīng)接受到的數(shù)據(jù)量Ack

四次揮手

為什么建立連接協(xié)議是三次握手，而關(guān)閉連接是四次握手

這是因?yàn)榉?wù)端的LISTEN狀態(tài)下的SOCKET當(dāng)收到SYN報(bào)文的連接請(qǐng)求后，它可以把ACK和SYN(ACK起應(yīng)答作用，而SYN起同步作用)放在一個(gè)報(bào)文里來發(fā)送。但關(guān)閉連接時(shí)，當(dāng)收到對(duì)方的FIN報(bào)文通知時(shí)，它僅僅表示對(duì)方?jīng)]有數(shù)據(jù)發(fā)送給你了；但未必你所有的數(shù)據(jù)都全部發(fā)送給對(duì)方了，所以你可能未必會(huì)馬上會(huì)關(guān)閉SOCKET,也即你可能還需要發(fā)送一些數(shù)據(jù)給對(duì)方之后，再發(fā)送FIN報(bào)文給對(duì)方來表示你同意現(xiàn)在可以關(guān)閉連接了，所以它這里的ACK報(bào)文和FIN報(bào)文多數(shù)情況下都是分開發(fā)送的。

由于TCP連接是全雙工的，因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。這個(gè)原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè)FIN來終止這個(gè)方向的連接。收到一個(gè) FIN只意味著這一方向上沒有數(shù)據(jù)流動(dòng)，一個(gè)TCP連接在收到一個(gè)FIN后仍能發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉，而另一方執(zhí)行被動(dòng)關(guān)閉。

（1）客戶端A發(fā)送一個(gè)FIN，用來關(guān)閉客戶A到服務(wù)器B的數(shù)據(jù)傳送。

（2）服務(wù)器B收到這個(gè)FIN，它發(fā)回一個(gè)ACK，確認(rèn)序號(hào)為收到的序號(hào)加1。和SYN一樣，一個(gè)FIN將占用一個(gè)序號(hào)。

（3）服務(wù)器B關(guān)閉與客戶端A的連接，發(fā)送一個(gè)FIN給客戶端A。

（4）客戶端A發(fā)回ACK報(bào)文確認(rèn)，并將確認(rèn)序號(hào)設(shè)置為收到序號(hào)加1。

A->B:我對(duì)你已經(jīng)沒話說了

B->A:我知道你對(duì)我沒話說了

B->A:我對(duì)你也沒話說了

A->B:我知道你對(duì)我也沒話說了

TCP和UDP的區(qū)別

TCP是基于連接的，而UDP是無連接的

TCP的數(shù)據(jù)傳輸是點(diǎn)對(duì)點(diǎn)的，而UDP支持一對(duì)一，一對(duì)多，多對(duì)一和多對(duì)多的交互通信

對(duì)系統(tǒng)資源的要求（TCP較多，UDP少）

UDP程序結(jié)構(gòu)較簡(jiǎn)單

TCP保證數(shù)據(jù)正確性，UDP可能丟包，TCP保證數(shù)據(jù)順序，UDP不保證

TCP首部開銷20字節(jié)，UDP的首部開銷小，只有8個(gè)字節(jié)

參考資料

• Wireshark基本介紹和學(xué)習(xí)TCP三次握手
• TCP三次握手四次揮手詳解

總結(jié)

以上是生活随笔為你收集整理的不抓包，如何学得了 TCP的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。