當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

TCP 传输控制协议(转)

發(fā)布時間：2025/4/16 编程问答 29 豆豆

生活随笔收集整理的這篇文章主要介紹了 TCP 传输控制协议(转) 小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

開頭先說幾個協(xié)議：

IP：網(wǎng)際協(xié)議

TCP：傳輸控制協(xié)議

Http：超文本傳輸協(xié)議

AMQP：高級消息隊列協(xié)議

一：TCP是什么？

TCP（Transmission Control Protocol 傳輸控制協(xié)議）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。

首先來看看OSI的七層模型：

我們需要知道TCP工作在網(wǎng)絡(luò)OSI的七層模型中的第四層——Transport層，IP在第三層——Network層，ARP在第二層——Data Link層；

在第二層上的數(shù)據(jù)，我們把它叫Frame，在第三層上的數(shù)據(jù)叫Packet，第四層的數(shù)據(jù)叫Segment。

同時，我們需要簡單的知道，數(shù)據(jù)從應(yīng)用層發(fā)下來，會在每一層都會加上頭部信息，進(jìn)行封裝，然后再發(fā)送到數(shù)據(jù)接收端。這個基本的流程你需要知道，就是每個數(shù)據(jù)都會經(jīng)過數(shù)據(jù)的封裝和解封裝的過程。

在OSI七層模型中，每一層的作用和對應(yīng)的協(xié)議如下：

詳細(xì)協(xié)議：

OSI: 物理層：EIA/TIA-232, EIA/TIA-499, V.35, V.24, RJ45, Ethernet, 802.3, 802.5, FDDI, NRZI, NRZ, B8ZS 數(shù)據(jù)鏈路層：Frame Relay, HDLC, PPP, IEEE 802.3/802.2, FDDI, ATM, IEEE 802.5/802.2, 【ARP,RARP】，VLAN、MAC 網(wǎng)絡(luò)層：IP，IPX，AppleTalk DDP，OSPF、RIP、IGRP、ICMP、ARP、RARP 傳輸層：TCP，UDP，SPX 會話層：RPC,SQL,NFS,NetBIOS,names,AppleTalk,ASP,DECnet,SCP 表示層：TIFF,GIF,JPEG,PICT,ASCII,EBCDIC,encryption,MPEG,MIDI,HTML 應(yīng)用層：HTTP,FTP,WWW,Telnet,NFS,SMTP,Gateway,SNMP

在Wireshark中對應(yīng)查看：

二：查看TCP頭部：

頭部的詳細(xì)說明：

Source Port和Destination Port:分別占用16位，表示源端口號和目的端口號；用于區(qū)別主機(jī)中的不同進(jìn)程，而IP地址是用來區(qū)分不同的主機(jī)的，源端口號和目的端口號配合上IP首部中的源IP地址和目的IP地址就能唯一的確定一個TCP連接；Sequence Number:用來標(biāo)識從TCP發(fā)端向TCP收端發(fā)送的數(shù)據(jù)字節(jié)流，它表示在這個報文段中的的第一個數(shù)據(jù)字節(jié)在數(shù)據(jù)流中的序號；主要用來解決網(wǎng)絡(luò)報亂序的問題；Acknowledgment Number:32位確認(rèn)序列號包含發(fā)送確認(rèn)的一端所期望收到的下一個序號，因此，確認(rèn)序號應(yīng)當(dāng)是上次已成功收到數(shù)據(jù)字節(jié)序號加1。不過，只有當(dāng)標(biāo)志位中的ACK標(biāo)志（下面介紹）為1時該確認(rèn)序列號的字段才有效。主要用來解決不丟包的問題；Offset:給出首部中32 bit字的數(shù)目，需要這個值是因為任選字段的長度是可變的。這個字段占4bit（最多能表示15個32bit的的字，即4*15=60個字節(jié)的首部長度），因此TCP最多有60字節(jié)的首部。然而，沒有任選字段，正常的長度是20字節(jié)；TCP Flags:TCP首部中有6個標(biāo)志比特，它們中的多個可同時被設(shè)置為1，主要是用于操控TCP的狀態(tài)機(jī)的，依次為URG，ACK，PSH，RST，SYN，FIN。每個標(biāo)志位的意思如下：URG：此標(biāo)志表示TCP包的緊急指針域（后面馬上就要說到）有效，用來保證TCP連接不被中斷，并且督促中間層設(shè)備要盡快處理這些數(shù)據(jù)；ACK：此標(biāo)志表示應(yīng)答域有效，就是說前面所說的TCP應(yīng)答號將會包含在TCP數(shù)據(jù)包中；有兩個取值：0和1，為1的時候表示應(yīng)答域有效，反之為0；PSH：這個標(biāo)志位表示Push操作。所謂Push操作就是指在數(shù)據(jù)包到達(dá)接收端以后，立即傳送給應(yīng)用程序，而不是在緩沖區(qū)中排隊；RST：這個標(biāo)志表示連接復(fù)位請求。用來復(fù)位那些產(chǎn)生錯誤的連接，也被用來拒絕錯誤和非法的數(shù)據(jù)包；SYN：表示同步序號，用來建立連接。SYN標(biāo)志位和ACK標(biāo)志位搭配使用，
當(dāng)連接請求的時候，SYN=1，ACK=0；連接被響應(yīng)的時候，SYN=1，ACK=1；這個標(biāo)志的數(shù)據(jù)包經(jīng)常被用來進(jìn)行端口掃描。掃描者發(fā)送一個只有SYN的數(shù)據(jù)包，如果對方主機(jī)響應(yīng)了一個數(shù)據(jù)包回來，就表明這臺主機(jī)存在這個端口；
但是由于這種掃描方式只是進(jìn)行TCP三次握手的第一次握手，因此這種掃描的成功表示被掃描的機(jī)器不很安全，一臺安全的主機(jī)將會強制要求一個連接嚴(yán)格的進(jìn)行TCP的三次握手；FIN：表示發(fā)送端已經(jīng)達(dá)到數(shù)據(jù)末尾，也就是說雙方的數(shù)據(jù)傳送完成，沒有數(shù)據(jù)可以傳送了，發(fā)送FIN標(biāo)志位的TCP數(shù)據(jù)包后，連接將被斷開。這個標(biāo)志的數(shù)據(jù)包也經(jīng)常被用于進(jìn)行端口掃描。

三：TCP的連接

TCP的傳輸主要分為連接，傳輸數(shù)據(jù)，斷開連接

三次握手連接：主要根據(jù)TCP頭部中的Seq,Ack來進(jìn)行判斷

查看WireShark抓包記錄：

查看網(wǎng)絡(luò)說明：

第一次握手：建立連接。客戶端發(fā)送連接請求報文段，將SYN位置為1，Sequence Number為x；然后，客戶端進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器的確認(rèn)；第二次握手：服務(wù)器收到SYN報文段。服務(wù)器收到客戶端的SYN報文段，需要對這個SYN報文段進(jìn)行確認(rèn)，設(shè)置Acknowledgment Number為x+1(Sequence Number+1)；
同時，自己自己還要發(fā)送SYN請求信息，將SYN位置為1，Sequence Number為y；服務(wù)器端將上述所有信息放到一個報文段（即SYN+ACK報文段）中，一并發(fā)送給客戶端，此時服務(wù)器進(jìn)入SYN_RECV狀態(tài)；第三次握手：客戶端收到服務(wù)器的SYN+ACK報文段。然后將Acknowledgment Number設(shè)置為y+1，向服務(wù)器發(fā)送ACK報文段，這個報文段發(fā)送完畢以后，客戶端和服務(wù)器端都進(jìn)入ESTABLISHED狀態(tài)，完成TCP三次握手。完成了三次握手，客戶端和服務(wù)器端就可以開始傳送數(shù)據(jù)。以上就是TCP三次握手的總體介紹。

為什么要三次握手？
為了防止已失效的連接請求報文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯誤。

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

?完整流程圖片：

?數(shù)據(jù)傳輸完畢，斷開TCP連接，即四次揮手

第一次揮手：主機(jī)1（可以是客戶端，也可以是服務(wù)器端），設(shè)置Sequence Number和Acknowledgment Number，向主機(jī)2發(fā)送一個FIN報文段；此時，主機(jī)1進(jìn)入FIN_WAIT_1狀態(tài)；這表示主機(jī)1沒有數(shù)據(jù)要發(fā)送給主機(jī)2了；第二次揮手：主機(jī)2收到了主機(jī)1發(fā)送的FIN報文段，向主機(jī)1回一個ACK報文段，Acknowledgment Number為Sequence Number加1；主機(jī)1進(jìn)入FIN_WAIT_2狀態(tài)；主機(jī)2告訴主機(jī)1，我“同意”你的關(guān)閉請求；第三次揮手：主機(jī)2向主機(jī)1發(fā)送FIN報文段，請求關(guān)閉連接，同時主機(jī)2進(jìn)入LAST_ACK狀態(tài)；第四次揮手：主機(jī)1收到主機(jī)2發(fā)送的FIN報文段，向主機(jī)2發(fā)送ACK報文段，然后主機(jī)1進(jìn)入TIME_WAIT狀態(tài)；主機(jī)2收到主機(jī)1的ACK報文段以后，就關(guān)閉連接；此時，主機(jī)1等待2MSL后依然沒有收到回復(fù)，則證明Server端已正常關(guān)閉，那好，主機(jī)1也可以關(guān)閉連接了。

為什么要四次分手？

TCP協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的運輸層通信協(xié)議。TCP是全雙工模式，這就意味著，當(dāng)主機(jī)1發(fā)出FIN報文段時，只是表示主機(jī)1已經(jīng)沒有數(shù)據(jù)要發(fā)送了，主機(jī)1告訴主機(jī)2，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了；但是，這個時候主機(jī)1還是可以接受來自主機(jī)2的數(shù)據(jù)；當(dāng)主機(jī)2返回ACK報文段時，表示它已經(jīng)知道主機(jī)1沒有數(shù)據(jù)發(fā)送了，但是主機(jī)2還是可以發(fā)送數(shù)據(jù)到主機(jī)1的；當(dāng)主機(jī)2也發(fā)送了FIN報文段時，這個時候就表示主機(jī)2也沒有數(shù)據(jù)要發(fā)送了，就會告訴主機(jī)1，我也沒有數(shù)據(jù)要發(fā)送了，之后彼此就會愉快的中斷這次TCP連接。

?查看最后四條tcp記錄：

再看一張完整流程的圖：

TCP流量控制：

如果發(fā)送方把數(shù)據(jù)發(fā)送得過快，接收方可能會來不及接收，這就會造成數(shù)據(jù)的丟失。所謂流量控制就是讓發(fā)送方的發(fā)送速率不要太快，要讓接收方來得及接收。

利用滑動窗口機(jī)制可以很方便地在TCP連接上實現(xiàn)對發(fā)送方的流量控制。

設(shè)A向B發(fā)送數(shù)據(jù)。在連接建立時，B告訴了A：“我的接收窗口是 rwnd = 400 ”(這里的 rwnd 表示 receiver window) 。因此，發(fā)送方的發(fā)送窗口不能超過接收方給出的接收窗口的數(shù)值。

請注意，TCP的窗口單位是字節(jié)，不是報文段。假設(shè)每一個報文段為100字節(jié)長，而數(shù)據(jù)報文段序號的初始值設(shè)為1。大寫ACK表示首部中的確認(rèn)位ACK，小寫ack表示確認(rèn)字段的值ack。

從圖中可以看出，B進(jìn)行了三次流量控制。第一次把窗口減少到 rwnd = 300 ，第二次又減到了 rwnd = 100 ，最后減到 rwnd = 0 ，即不允許發(fā)送方再發(fā)送數(shù)據(jù)了。

這種使發(fā)送方暫停發(fā)送的狀態(tài)將持續(xù)到主機(jī)B重新發(fā)出一個新的窗口值為止。B向A發(fā)送的三個報文段都設(shè)置了 ACK = 1 ，只有在ACK=1時確認(rèn)號字段才有意義。

TCP為每一個連接設(shè)有一個持續(xù)計時器(persistence timer)。只要TCP連接的一方收到對方的零窗口通知，就啟動持續(xù)計時器。若持續(xù)計時器設(shè)置的時間到期，就發(fā)送一個零窗口控測報文段（攜1字節(jié)的數(shù)據(jù)），那么收到這個報文段的一方就重新設(shè)置持續(xù)計時器。

https://github.com/jawil/blog/issues/14

http://www.cnblogs.com/TankXiao/archive/2012/10/10/2711777.html

https://hit-alibaba.github.io/interview/basic/network/TCP.html

https://mp.weixin.qq.com/s?__biz=MzIxMjE5MTE1Nw==&mid=2653193018&idx=1&sn=2b445ce9637c46a422488ee53ca701d2&chksm=8c99f1e0bbee78f6fbca4974cd357bf933985d20494dc98f7147ce5017f6396b7feefc55002e&scene=0#rd

轉(zhuǎn)載于:https://www.cnblogs.com/zhangjianbin/p/9962549.html

總結(jié)

以上是生活随笔為你收集整理的TCP 传输控制协议(转)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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

协议
tcp