正文

tcp建立連接需要幾個(gè)rtt（tcp建立連接需要幾個(gè)端口）

發(fā)布時(shí)間：2023-03-19 05:25:19 稿源：創(chuàng)意嶺閱讀： 140 問大家

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于tcp建立連接需要幾個(gè)rtt的問題，以下是小編對(duì)此問題的歸納整理，讓我們一起來看看吧。

開始之前先推薦一個(gè)非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計(jì)劃、工作報(bào)告、論文、代碼、作文、做題和對(duì)話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準(zhǔn)，寫出的就越詳細(xì)，有微信小程序端、在線網(wǎng)頁版、PC客戶端

官網(wǎng)：https://ai.de1919.com

本文目錄:

1、【網(wǎng)絡(luò)】TCP的連接建立
2、TCP協(xié)議詳解及實(shí)戰(zhàn)解析【精心整理收藏】
3、創(chuàng)建TCP連接的限制
4、TCP建立連接時(shí)，（1）發(fā)送方第一次發(fā)送數(shù)據(jù)到收到對(duì)方確認(rèn)的RTT樣本值為4s，試計(jì)算超時(shí)重傳時(shí)間？

tcp建立連接需要幾個(gè)rtt（tcp建立連接需要幾個(gè)端口）

一、【網(wǎng)絡(luò)】TCP的連接建立

TCP是面向連接的協(xié)議。運(yùn)輸連接是用來傳送TCP報(bào)文的。TCP運(yùn)輸連接的建立和釋放是每一次連接通信過程中必不可少的。

因此，運(yùn)輸連接就有三個(gè)階段： 連接建立 ， 數(shù)據(jù)傳送 和 連接釋放 。

需要解決以下3個(gè)問題：

連接建立 這個(gè)過程，需要在客戶端和服務(wù)器之間，交換3個(gè)TCP報(bào)文段，也就是 三次握手 🤝x3。

📌請(qǐng)注意，在本例中， A主動(dòng)打開連接，B被動(dòng)打開連接

一開始，B就在準(zhǔn)備接受客戶進(jìn)程的連接請(qǐng)求，然后服務(wù)器進(jìn)程就處于 LISTEN （收聽）狀態(tài)，等待客戶的連接請(qǐng)求。如有，即作出響應(yīng)。

A的TCP客戶進(jìn)程像B發(fā)出連接請(qǐng)求報(bào)文段，這時(shí)，首部中的同步位SYN = 1，同時(shí)選擇一個(gè)初始序號(hào) seq = x 。

TCP規(guī)定📝，SYN報(bào)文段不能攜帶數(shù)據(jù)， 但要消耗掉一個(gè)序號(hào) 。這時(shí)，TCP客戶進(jìn)程進(jìn)入 SYN-SENT （同步已發(fā)送）狀態(tài)。

B收到連接請(qǐng)求的報(bào)文段后，如同意建立連接，則向A發(fā)送確認(rèn)。在確認(rèn)報(bào)文段中，應(yīng)把SYN位和ASK位都置1，確認(rèn)號(hào)是 ack = x + 1 ，同時(shí)也為自己選擇一個(gè)初始序號(hào) seq = y 。

請(qǐng)注意，這個(gè)報(bào)文段也不能攜帶數(shù)據(jù)。但同樣 要消耗掉一個(gè)序號(hào) 。這時(shí)，TCP服務(wù)器進(jìn)程進(jìn)入 SYN-RCVD （同步收到）狀態(tài)。

TCP客戶進(jìn)程收到B的確認(rèn)后，還要向B給出確認(rèn)。確認(rèn)報(bào)文段的ACK置1，確認(rèn)號(hào) ack = y + 1 ，而自己的序號(hào) seq = x + 1 。

TCP的標(biāo)準(zhǔn)規(guī)定📝，ACK報(bào)文段可以攜帶數(shù)據(jù)。但如果不攜帶數(shù)據(jù)則不消耗序號(hào)，在這種情況下，下一個(gè)數(shù)據(jù)報(bào)文段的序號(hào)仍是 seq = x +1 。

這時(shí)，TCP連接已經(jīng)建立🖇，A進(jìn)入 ESTABLISHED （已建立連接）狀態(tài)。當(dāng)B收到A的確認(rèn)后，也進(jìn)入 ESTABLISHED （已建立連接）

🔍 Q: 為什么A最后還有發(fā)送一次確認(rèn)呢？

📗 A: 主要是為了 防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到B，因而產(chǎn)生錯(cuò)誤。

所謂 “已失效的連接請(qǐng)求報(bào)文段” 是這樣產(chǎn)生的。

📝考慮一種正常情況，

A 發(fā)出連接請(qǐng)求📲，但因連接請(qǐng)求報(bào)文丟失而未收到確認(rèn)。于是A再重傳一次連接請(qǐng)求。后來收到了確認(rèn)，建立了連接。數(shù)據(jù)傳輸完畢后，就釋放了連接。

A共發(fā)出了兩個(gè)連接請(qǐng)求的報(bào)文段，其中第一個(gè)丟失💔，第二個(gè)到達(dá)了B💚，沒有“已失效的連接請(qǐng)求報(bào)文段”。

📝現(xiàn)假定出現(xiàn)一種異常情況，

即A發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒有丟失，而是在某個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)長時(shí)間的滯留🛑，以至延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)B。

本來這是一個(gè) 早已失效的報(bào)文段，但是B收到此時(shí)小的連接請(qǐng)求的報(bào)文段之后，誤以為是A又發(fā)出一次新的連接請(qǐng)求。

于是向A發(fā)出確認(rèn)報(bào)文段，同意建立連接。假定不采用報(bào)文握手。那么只要B發(fā)出確認(rèn)之后，新的連接就建立了。

由于現(xiàn)在A并沒有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬B的確認(rèn)🙉，也不會(huì)向B發(fā)送數(shù)據(jù)，但B確以為新的運(yùn)輸連接已經(jīng)建立，并一直等待A發(fā)來的數(shù)據(jù)。

B的許多資源就這樣白白浪費(fèi)了。

二、TCP協(xié)議詳解及實(shí)戰(zhàn)解析【精心整理收藏】

TCP協(xié)議是在TCP/IP協(xié)議模型中的運(yùn)輸層中很重要的一個(gè)協(xié)議、負(fù)責(zé)處理主機(jī)端口層面之間的數(shù)據(jù)傳輸。主要有以下特點(diǎn)：

1.TCP是面向鏈接的協(xié)議，在數(shù)據(jù)傳輸之前需要通過三次握手建立TCP鏈接，當(dāng)數(shù)據(jù)傳遞完成之后，需要通過四次揮手進(jìn)行連接釋放。

2.每一條TCP通信都是兩臺(tái)主機(jī)和主機(jī)之間的，是點(diǎn)對(duì)點(diǎn)傳輸?shù)膮f(xié)議。

3.TCP提供可靠的、無差錯(cuò)、不丟失、不重復(fù)，按序到達(dá)的服務(wù)。

4.TCP的通信雙方在連接建立的任何時(shí)候都可以發(fā)送數(shù)據(jù)。TCP連接的兩端都設(shè)有發(fā)送緩存和接收緩存，用來臨時(shí)存放雙向通信的數(shù)據(jù)。

5.面向字節(jié)流。在數(shù)據(jù)傳輸?shù)倪^程中如果報(bào)文比較長的話TCP會(huì)進(jìn)行數(shù)據(jù)分段傳輸，每一條分段的TCP傳輸信息都帶有分段的序號(hào)，每一段都包含一部分字節(jié)流。接收方根據(jù)每段攜帶的的序號(hào)信息進(jìn)行數(shù)據(jù)拼接，最終拼接出來初始的傳輸數(shù)據(jù)。但是在整個(gè)傳輸?shù)倪^程中每一段TCP攜帶的都是被切割的字節(jié)流數(shù)據(jù)。所以說TCP是面向字節(jié)流的。

a.TCP和UDP在發(fā)送報(bào)文時(shí)所采用的方式完全不同。TCP并不關(guān)心應(yīng)用程序一次把多長的報(bào)文發(fā)送到TCP緩存中，而是根據(jù)對(duì)方給出的窗口值和當(dāng)前網(wǎng)絡(luò)擁塞的程度來決定一個(gè)報(bào)文段應(yīng)包含多少個(gè)字節(jié)（UDP發(fā)送的報(bào)文長度是應(yīng)用程序給出的）。

b.如果應(yīng)用程序傳送到TCP緩存的數(shù)據(jù)塊太大，TCP就可以把它劃分短一些再傳。TCP也可以等待積累有足夠多的字節(jié)后再構(gòu)建成報(bào)文段發(fā)送出去。

各字段含義：

源端口：發(fā)送端的端口號(hào)

目的端口：接收端的端口號(hào)

序號(hào)：TCP將發(fā)送報(bào)文分段傳輸?shù)臅r(shí)候會(huì)給每一段加上序號(hào)，接收端也可以根據(jù)這個(gè)序號(hào)來判斷數(shù)據(jù)拼接的順序，主要用來解決網(wǎng)絡(luò)報(bào)亂序的問題

確認(rèn)號(hào)：確認(rèn)號(hào)為接收端收到數(shù)據(jù)之后進(jìn)行排序確認(rèn)以及發(fā)送下一次期待接收到的序號(hào)，數(shù)值 = 接收到的發(fā)送號(hào) + 1

數(shù)據(jù)偏移：占4比特，表示數(shù)據(jù)開始的地方離TCP段的起始處有多遠(yuǎn)。實(shí)際上就是TCP段首部的長度。由于首部長度不固定，因此數(shù)據(jù)偏移字段是必要的。數(shù)據(jù)偏移以32位為長度單位，因此TCP首部的最大長度是60（15*4）個(gè)字節(jié)。

控制位：

URG：此標(biāo)志表示TCP包的緊急指針域有效，用來保證TCP連接不被中斷，并且督促中間層設(shè)備要盡快處理這些數(shù)據(jù);

ACK：此標(biāo)志表示應(yīng)答域有效，就是說前面所說的TCP應(yīng)答號(hào)將會(huì)包含在TCP數(shù)據(jù)包中;有兩個(gè)取值：0和1，為1的時(shí)候表示應(yīng)答域有效，反之為0;

PSH：這個(gè)標(biāo)志位表示Push操作。所謂Push操作就是指在數(shù)據(jù)包到達(dá)接收端以后，立即傳送給應(yīng)用程序，而不是在緩沖區(qū)中排隊(duì);

RST：這個(gè)標(biāo)志表示連接復(fù)位請(qǐng)求。用來復(fù)位那些產(chǎn)生錯(cuò)誤的連接，也被用來拒絕錯(cuò)誤和非法的數(shù)據(jù)包;

SYN：表示同步序號(hào)，用來建立連接。SYN標(biāo)志位和ACK標(biāo)志位搭配使用，當(dāng)連接請(qǐng)求的時(shí)候，SYN=1， ACK=0;連接被響應(yīng)的時(shí)候，SYN=1，ACK=1;這個(gè)標(biāo)志的數(shù)據(jù)包經(jīng)常被用來進(jìn)行端口掃描。掃描者發(fā)送一個(gè)只有SYN的數(shù)據(jù)包，如果對(duì)方主機(jī)響應(yīng)了一個(gè)數(shù)據(jù)包回來，就表明這臺(tái)主機(jī)存在這個(gè)端口;但是由于這種掃描方式只是進(jìn)行TCP三次握手的第一次握手，因此這種掃描的成功表示被掃描的機(jī)器不很安全，一臺(tái)安全的主機(jī)將會(huì)強(qiáng)制要求一個(gè)連接嚴(yán)格的進(jìn)行TCP的三次握手;

FIN：表示發(fā)送端已經(jīng)達(dá)到數(shù)據(jù)末尾，也就是說雙方的數(shù)據(jù)傳送完成，沒有數(shù)據(jù)可以傳送了，發(fā)送FIN標(biāo)志位的TCP數(shù)據(jù)包后，連接將被斷開。這個(gè)標(biāo)志的數(shù)據(jù)包也經(jīng)常被用于進(jìn)行端口掃描。

窗口：TCP里很重要的一個(gè)機(jī)制，占2字節(jié)，表示報(bào)文段發(fā)送方期望接收的字節(jié)數(shù)，可接收的序號(hào)范圍是從接收方的確認(rèn)號(hào)開始到確認(rèn)號(hào)加上窗口大小之間的數(shù)據(jù)。后面會(huì)有實(shí)例講解。

校驗(yàn)和：校驗(yàn)和包含了偽首部、TCP首部和數(shù)據(jù)，校驗(yàn)和是TCP強(qiáng)制要求的，由發(fā)送方計(jì)算，接收方驗(yàn)證

緊急指針：URG標(biāo)志為1時(shí)，緊急指針有效，表示數(shù)據(jù)需要優(yōu)先處理。緊急指針指出在TCP段中的緊急數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)，使接收方可以知道緊急數(shù)據(jù)共有多長。

選項(xiàng)：最常用的選項(xiàng)是最大段大?。∕aximum Segment Size，MSS），向?qū)Ψ酵ㄖ緳C(jī)可以接收的最大TCP段長度。MSS選項(xiàng)只在建立連接的請(qǐng)求中發(fā)送。

放在以太網(wǎng)幀里看TCP的位置

TCP 數(shù)據(jù)包在 IP 數(shù)據(jù)包的負(fù)載里面。它的頭信息最少也需要20字節(jié)，因此 TCP 數(shù)據(jù)包的最大負(fù)載是 1480 - 20 = 1460 字節(jié)。由于 IP 和 TCP 協(xié)議往往有額外的頭信息，所以 TCP 負(fù)載實(shí)際為1400字節(jié)左右。

因此，一條1500字節(jié)的信息需要兩個(gè) TCP 數(shù)據(jù)包。HTTP/2 協(xié)議的一大改進(jìn)，就是壓縮 HTTP 協(xié)議的頭信息，使得一個(gè) HTTP 請(qǐng)求可以放在一個(gè) TCP 數(shù)據(jù)包里面，而不是分成多個(gè)，這樣就提高了速度。

以太網(wǎng)數(shù)據(jù)包的負(fù)載是1500字節(jié)，TCP 數(shù)據(jù)包的負(fù)載在1400字節(jié)左右

一個(gè)包1400字節(jié)，那么一次性發(fā)送大量數(shù)據(jù)，就必須分成多個(gè)包。比如，一個(gè) 10MB 的文件，需要發(fā)送7100多個(gè)包。

發(fā)送的時(shí)候，TCP 協(xié)議為每個(gè)包編號(hào)（sequence number，簡稱 SEQ），以便接收的一方按照順序還原。萬一發(fā)生丟包，也可以知道丟失的是哪一個(gè)包。

第一個(gè)包的編號(hào)是一個(gè)隨機(jī)數(shù)。為了便于理解，這里就把它稱為1號(hào)包。假定這個(gè)包的負(fù)載長度是100字節(jié)，那么可以推算出下一個(gè)包的編號(hào)應(yīng)該是101。這就是說，每個(gè)數(shù)據(jù)包都可以得到兩個(gè)編號(hào)：自身的編號(hào)，以及下一個(gè)包的編號(hào)。接收方由此知道，應(yīng)該按照什么順序?qū)⑺鼈冞€原成原始文件。

收到 TCP 數(shù)據(jù)包以后，組裝還原是操作系統(tǒng)完成的。應(yīng)用程序不會(huì)直接處理 TCP 數(shù)據(jù)包。

對(duì)于應(yīng)用程序來說，不用關(guān)心數(shù)據(jù)通信的細(xì)節(jié)。除非線路異常，否則收到的總是完整的數(shù)據(jù)。應(yīng)用程序需要的數(shù)據(jù)放在 TCP 數(shù)據(jù)包里面，有自己的格式（比如 HTTP 協(xié)議）。

TCP 并沒有提供任何機(jī)制，表示原始文件的大小，這由應(yīng)用層的協(xié)議來規(guī)定。比如，HTTP 協(xié)議就有一個(gè)頭信息Content-Length，表示信息體的大小。對(duì)于操作系統(tǒng)來說，就是持續(xù)地接收 TCP 數(shù)據(jù)包，將它們按照順序組裝好，一個(gè)包都不少。

操作系統(tǒng)不會(huì)去處理 TCP 數(shù)據(jù)包里面的數(shù)據(jù)。一旦組裝好 TCP 數(shù)據(jù)包，就把它們轉(zhuǎn)交給應(yīng)用程序。TCP 數(shù)據(jù)包里面有一個(gè)端口（port）參數(shù)，就是用來指定轉(zhuǎn)交給監(jiān)聽該端口的應(yīng)用程序。

應(yīng)用程序收到組裝好的原始數(shù)據(jù)，以瀏覽器為例，就會(huì)根據(jù) HTTP 協(xié)議的Content-Length字段正確讀出一段段的數(shù)據(jù)。這也意味著，一次 TCP 通信可以包括多個(gè) HTTP 通信。

服務(wù)器發(fā)送數(shù)據(jù)包，當(dāng)然越快越好，最好一次性全發(fā)出去。但是，發(fā)得太快，就有可能丟包。帶寬小、路由器過熱、緩存溢出等許多因素都會(huì)導(dǎo)致丟包。線路不好的話，發(fā)得越快，丟得越多。

最理想的狀態(tài)是，在線路允許的情況下，達(dá)到最高速率。但是我們?cè)趺粗?，?duì)方線路的理想速率是多少呢？答案就是慢慢試。

TCP 協(xié)議為了做到效率與可靠性的統(tǒng)一，設(shè)計(jì)了一個(gè)慢啟動(dòng)（slow start）機(jī)制。開始的時(shí)候，發(fā)送得較慢，然后根據(jù)丟包的情況，調(diào)整速率：如果不丟包，就加快發(fā)送速度；如果丟包，就降低發(fā)送速度。

Linux 內(nèi)核里面設(shè)定了（常量TCP_INIT_CWND），剛開始通信的時(shí)候，發(fā)送方一次性發(fā)送10個(gè)數(shù)據(jù)包，即"發(fā)送窗口"的大小為10。然后停下來，等待接收方的確認(rèn)，再繼續(xù)發(fā)送。

默認(rèn)情況下，接收方每收到兩個(gè) TCP 數(shù)據(jù)包，就要發(fā)送一個(gè)確認(rèn)消息。"確認(rèn)"的英語是 acknowledgement，所以這個(gè)確認(rèn)消息就簡稱 ACK。

ACK 攜帶兩個(gè)信息。

發(fā)送方有了這兩個(gè)信息，再加上自己已經(jīng)發(fā)出的數(shù)據(jù)包的最新編號(hào)，就會(huì)推測出接收方大概的接收速度，從而降低或增加發(fā)送速率。這被稱為"發(fā)送窗口"，這個(gè)窗口的大小是可變的。

注意，由于 TCP 通信是雙向的，所以雙方都需要發(fā)送 ACK。兩方的窗口大小，很可能是不一樣的。而且 ACK 只是很簡單的幾個(gè)字段，通常與數(shù)據(jù)合并在一個(gè)數(shù)據(jù)包里面發(fā)送。

即使對(duì)于帶寬很大、線路很好的連接，TCP 也總是從10個(gè)數(shù)據(jù)包開始慢慢試，過了一段時(shí)間以后，才達(dá)到最高的傳輸速率。這就是 TCP 的慢啟動(dòng)。

TCP 協(xié)議可以保證數(shù)據(jù)通信的完整性，這是怎么做到的？

前面說過，每一個(gè)數(shù)據(jù)包都帶有下一個(gè)數(shù)據(jù)包的編號(hào)。如果下一個(gè)數(shù)據(jù)包沒有收到，那么 ACK 的編號(hào)就不會(huì)發(fā)生變化。

舉例來說，現(xiàn)在收到了4號(hào)包，但是沒有收到5號(hào)包。ACK 就會(huì)記錄，期待收到5號(hào)包。過了一段時(shí)間，5號(hào)包收到了，那么下一輪 ACK 會(huì)更新編號(hào)。如果5號(hào)包還是沒收到，但是收到了6號(hào)包或7號(hào)包，那么 ACK 里面的編號(hào)不會(huì)變化，總是顯示5號(hào)包。這會(huì)導(dǎo)致大量重復(fù)內(nèi)容的 ACK。

如果發(fā)送方發(fā)現(xiàn)收到三個(gè) 連續(xù)的重復(fù) ACK，或者超時(shí)了還沒有收到任何 ACK，就會(huì)確認(rèn)丟包，即5號(hào)包遺失了，從而再次發(fā)送這個(gè)包。通過這種機(jī)制，TCP 保證了不會(huì)有數(shù)據(jù)包丟失。

TCP是一個(gè)滑動(dòng)窗口協(xié)議，即一個(gè)TCP連接的發(fā)送端在某個(gè)時(shí)刻能發(fā)多少數(shù)據(jù)是由滑動(dòng)窗口控制的，而滑動(dòng)窗口的大小實(shí)際上是由兩個(gè)窗口共同決定的，一個(gè)是接收端的通告窗口，這個(gè)窗口值在TCP協(xié)議頭部信息中有，會(huì)隨著數(shù)據(jù)的ACK包發(fā)送給發(fā)送端，這個(gè)值表示的是在接收端的TCP協(xié)議緩存中還有多少剩余空間，發(fā)送端必須保證發(fā)送的數(shù)據(jù)不超過這個(gè)剩余空間以免造成緩沖區(qū)溢出，這個(gè)窗口是接收端用來進(jìn)行流量限制的，在傳輸過程中，通告窗口大小與接收端的進(jìn)程取出數(shù)據(jù)的快慢有關(guān)。另一個(gè)窗口是發(fā)送端的擁塞窗口(Congestion window)，由發(fā)送端維護(hù)這個(gè)值，在協(xié)議頭部信息中沒有，滑動(dòng)窗口的大小就是通告窗口和擁塞窗口的較小值，所以擁塞窗口也看做是發(fā)送端用來進(jìn)行流量控制的窗口?；瑒?dòng)窗口的左邊沿向右移動(dòng)稱為窗口合攏，發(fā)生在發(fā)送的數(shù)據(jù)被確認(rèn)時(shí)（此時(shí)，表明數(shù)據(jù)已被接收端收到，不會(huì)再被需要重傳，可以從發(fā)送端的發(fā)送緩存中清除了），滑動(dòng)窗口的右邊沿向右移動(dòng)稱為窗口張開，發(fā)生在接收進(jìn)程從接收端協(xié)議緩存中取出數(shù)據(jù)時(shí)。隨著發(fā)送端不斷收到的被發(fā)送數(shù)據(jù)的ACK包，根據(jù)ACK包中的確認(rèn)序號(hào)和通告窗口大小使滑動(dòng)窗口得以不斷的合攏和張開，形成滑動(dòng)窗口的向前滑動(dòng)。如果接收進(jìn)程一直不取數(shù)據(jù)，則會(huì)出現(xiàn)0窗口現(xiàn)象，即滑動(dòng)窗口左邊沿與右邊沿重合，此時(shí)窗口大小為0，就無法再發(fā)送數(shù)據(jù)。

在TCP里，接收端(B)會(huì)給發(fā)送端(A)報(bào)一個(gè)窗口的大小，叫Advertised window。

1.在沒有收到B的確認(rèn)情況下，A可以連續(xù)把窗口內(nèi)的數(shù)據(jù)都發(fā)送出去。凡是已經(jīng)發(fā)送過的數(shù)據(jù)，在

未收到確認(rèn)之前都必須暫時(shí)保留，以便在超時(shí)重傳時(shí)使用。

2.發(fā)送窗口里面的序號(hào)表示允許發(fā)送的序號(hào)。顯然，窗口越大，發(fā)送方就可以在收到對(duì)方確認(rèn)之前連續(xù)

發(fā)送更多數(shù)據(jù)，因而可能獲得更高的傳輸效率。但接收方必須來得及處理這些收到的數(shù)據(jù)。

3.發(fā)送窗口后沿的后面部分表示已發(fā)送且已收到確認(rèn)。這些數(shù)據(jù)顯然不需要再保留了。

4.發(fā)送窗口前沿的前面部分表示不允許發(fā)送的，應(yīng)為接收方都沒有為這部分?jǐn)?shù)據(jù)保留臨時(shí)存放的緩存空間。

5.發(fā)送窗口后沿的變化情況有兩種：不動(dòng)（沒有收到新的確認(rèn)）和前移（收到了新的確認(rèn)）

6.發(fā)送窗口前沿的變化情況有兩種：不斷向前移或可能不動(dòng)（沒收到新的確認(rèn)）

TCP的發(fā)送方在規(guī)定時(shí)間內(nèi)沒有收到確認(rèn)就要重傳已發(fā)送的報(bào)文段。這種重傳的概念很簡單，但重傳時(shí)間的選擇確是TCP最復(fù)雜的問題之一。TCP采用了一種自適應(yīng)算法，它記錄一個(gè)報(bào)文段發(fā)出的時(shí)間，以及收到響應(yīng)的確認(rèn)的時(shí)間

這兩個(gè)時(shí)間之差就是報(bào)文段的往返時(shí)間RTT。TCP保留了RTT的一個(gè)加權(quán)平均往返時(shí)間。超時(shí)重傳時(shí)間RTO略大于加權(quán)平均往返時(shí)間

RTT：

即Round Trip Time，表示從發(fā)送端到接收端的一去一回需要的時(shí)間，tcp在數(shù)據(jù)傳輸過程中會(huì)對(duì)RTT進(jìn)行采樣（即對(duì)發(fā)送的數(shù)據(jù)包及其ACK的時(shí)間差進(jìn)行測量，并根據(jù)測量值更新RTT值，具體的算法TCPIP詳解里面有），TCP根據(jù)得到的RTT值更新RTO值，即Retransmission TimeOut，就是重傳間隔，發(fā)送端對(duì)每個(gè)發(fā)出的數(shù)據(jù)包進(jìn)行計(jì)時(shí)，如果在RTO時(shí)間內(nèi)沒有收到所發(fā)出的數(shù)據(jù)包的對(duì)應(yīng)ACK，則任務(wù)數(shù)據(jù)包丟失，將重傳數(shù)據(jù)。一般RTO值都比采樣得到的RTT值要大。

如果收到的報(bào)文段無差錯(cuò)，只是未按序號(hào)，中間還缺少一些序號(hào)的數(shù)據(jù)，那么能否設(shè)法只傳送缺少的數(shù)據(jù)而不重傳已經(jīng)正確到達(dá)接收方的數(shù)據(jù)？

答案是可以的，選擇確認(rèn)就是一種可行的處理方法。

如果要使用選項(xiàng)確認(rèn)SACK，那么在建立TCP連接時(shí)，就要在TCP首部的選項(xiàng)中加上“允許SACK”的選項(xiàng)，而雙方必須都事先商定好。如果使用選擇確認(rèn)，

那么原來首部中的“確認(rèn)號(hào)字段”的用法仍然不變。SACK文檔并沒有明確發(fā)送方應(yīng)當(dāng)怎么響應(yīng)SACK.因此大多數(shù)的實(shí)現(xiàn)還是重傳所有未被確認(rèn)的數(shù)據(jù)塊。

一般說來，我們總是希望數(shù)據(jù)傳輸?shù)母煲恍绻l(fā)送方把數(shù)據(jù)發(fā)送的過快，接收方就可能來不及接收，這會(huì)造成數(shù)據(jù)的丟失。所謂流量控制就是讓發(fā)送方的發(fā)送速率不要太快，要讓接收方來得及接收。

在計(jì)算機(jī)網(wǎng)絡(luò)中的鏈路容量，交換節(jié)點(diǎn)中的緩存和處理機(jī)等，都是網(wǎng)絡(luò)的資源。在某段時(shí)間，若對(duì)網(wǎng)絡(luò)中某一資源的需求超過了該資源所能提供的可用部分，網(wǎng)絡(luò)的性能就要變壞。這種情況就叫做擁塞。

擁塞控制方法：

1.慢開始和擁塞避免

2.快重傳和快恢復(fù)

3.隨機(jī)早期檢測

1.一開始，客戶端和服務(wù)端都處于CLOSED狀態(tài)

2.先是服務(wù)端主動(dòng)監(jiān)聽某個(gè)端口，處于LISTEN狀態(tài)（比如服務(wù)端啟動(dòng)，開始監(jiān)聽）。

3.客戶端主動(dòng)發(fā)起連接SYN，之后處于SYN-SENT狀態(tài)（第一次握手，發(fā)送 SYN = 1 ACK = 0 seq = x ack = 0）。

4.服務(wù)端收到發(fā)起的連接，返回SYN，并且ACK客戶端的SYN，之后處于SYN-RCVD狀態(tài)（第二次握手，發(fā)送 SYN = 1 ACK = 1 seq = y ack = x + 1）。

5.客戶端收到服務(wù)端發(fā)送的SYN和ACK之后，發(fā)送ACK的ACK，之后處于ESTABLISHED狀態(tài)（第三次握手，發(fā)送 SYN = 0 ACK = 1 seq = x + 1 ack = y + 1）。

6.服務(wù)端收到客戶端的ACK之后，處于ESTABLISHED狀態(tài)。

（需要注意的是，有可能X和Y是相等的，可能都是0，因?yàn)樗麄兇砹烁髯园l(fā)送報(bào)文段的序號(hào)。）

TCP連接釋放四次揮手

1.當(dāng)前A和B都處于ESTAB-LISHED狀態(tài)。

2.A的應(yīng)用進(jìn)程先向其TCP發(fā)出連接釋放報(bào)文段，并停止再發(fā)送數(shù)據(jù)，主動(dòng)關(guān)閉TCP連接。

3.B收到連接釋放報(bào)文段后即發(fā)出確認(rèn)，然后B進(jìn)入CLOSE-WAIT(關(guān)閉等待)狀態(tài)。TCP服務(wù)器進(jìn)程這時(shí)應(yīng)通知高層應(yīng)用進(jìn)程，因而從A到B這個(gè)方向的連接就釋放了，這時(shí)TCP連接處于半關(guān)閉狀態(tài)，即A已經(jīng)沒有數(shù)據(jù)發(fā)送了。

從B到A這個(gè)方向的連接并未關(guān)閉，這個(gè)狀態(tài)可能會(huì)持續(xù)一些時(shí)間。

4.A收到來自B的確認(rèn)后，就進(jìn)入FIN-WAIT-2(終止等待2)狀態(tài)，等待B發(fā)出的連接釋放報(bào)文端。

5.若B已經(jīng)沒有向A發(fā)送的數(shù)據(jù)，B發(fā)出連接釋放信號(hào)，這時(shí)B進(jìn)入LAST-ACK(最后確認(rèn))狀態(tài)等待A的確認(rèn)。

6.A再收到B的連接釋放消息后，必須對(duì)此發(fā)出確認(rèn)，然后進(jìn)入TIME-WAIT（時(shí)間等待）狀態(tài)。請(qǐng)注意，現(xiàn)在TCP連接還沒有釋放掉，必須經(jīng)過時(shí)間等待計(jì)時(shí)器（TIME－WAIT timer）設(shè)置的時(shí)間2MSL后，A才進(jìn)入CLOSED狀態(tài)。

7。B收到A發(fā)出的確認(rèn)消息后，進(jìn)入CLOSED狀態(tài)。

以請(qǐng)求百度為例，看一下三次握手真實(shí)數(shù)據(jù)的TCP連接建立過程

我們?cè)賮砜此拇螕]手。TCP斷開連接時(shí)，會(huì)有四次揮手過程，標(biāo)志位是FIN，我們?cè)诜獍斜碇姓业綄?duì)應(yīng)位置，理論上應(yīng)該找到4個(gè)數(shù)據(jù)包，但我試了好幾次，實(shí)際只抓到3個(gè)數(shù)據(jù)包。查了相關(guān)資料，說是因?yàn)榉?wù)器端在給客戶端傳回的過程中，將兩個(gè)連續(xù)發(fā)送的包進(jìn)行了合并。因此下面會(huì)按照合并后的三次揮手解釋，若有錯(cuò)誤之處請(qǐng)指出。

第一步，當(dāng)主機(jī)A的應(yīng)用程序通知TCP數(shù)據(jù)已經(jīng)發(fā)送完畢時(shí)，TCP向主機(jī)B發(fā)送一個(gè)帶有FIN附加標(biāo)記的報(bào)文段（FIN表示英文finish）。

第二步，主機(jī)B收到這個(gè)FIN報(bào)文段之后，并不立即用FIN報(bào)文段回復(fù)主機(jī)A，而是先向主機(jī)A發(fā)送一個(gè)確認(rèn)序號(hào)ACK，同時(shí)通知自己相應(yīng)的應(yīng)用程序：對(duì)方要求關(guān)閉連接（先發(fā)送ACK的目的是為了防止在這段時(shí)間內(nèi)，對(duì)方重傳FIN報(bào)文段）。

第三步，主機(jī)B的應(yīng)用程序告訴TCP：我要徹底的關(guān)閉連接，TCP向主機(jī)A送一個(gè)FIN報(bào)文段。

第四步，主機(jī)A收到這個(gè)FIN報(bào)文段后，向主機(jī)B發(fā)送一個(gè)ACK表示連接徹底釋放。

這是因?yàn)榉?wù)端在LISTEN狀態(tài)下，收到建立連接請(qǐng)求的SYN報(bào)文后，把ACK和SYN放在一個(gè)報(bào)文里發(fā)送給客戶端。而關(guān)閉連接時(shí)，當(dāng)收到對(duì)方的FIN報(bào)文時(shí)，僅僅表示對(duì)方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，己方也未必全部數(shù)據(jù)都發(fā)送給對(duì)方了，所以己方可以立即close，也可以發(fā)送一些數(shù)據(jù)給對(duì)方后，再發(fā)送FIN報(bào)文給對(duì)方來表示同意現(xiàn)在關(guān)閉連接，因此，己方ACK和FIN一般都會(huì)分開發(fā)送。

原因有二：

一、保證TCP協(xié)議的全雙工連接能夠可靠關(guān)閉

二、保證這次連接的重復(fù)數(shù)據(jù)段從網(wǎng)絡(luò)中消失

先說第一點(diǎn)，如果Client直接CLOSED了，那么由于IP協(xié)議的不可靠性或者是其它網(wǎng)絡(luò)原因，導(dǎo)致Server沒有收到Client最后回復(fù)的ACK。那么Server就會(huì)在超時(shí)之后繼續(xù)發(fā)送FIN，此時(shí)由于Client已經(jīng)CLOSED了，就找不到與重發(fā)的FIN對(duì)應(yīng)的連接，最后Server就會(huì)收到RST而不是ACK，Server就會(huì)以為是連接錯(cuò)誤把問題報(bào)告給高層。這樣的情況雖然不會(huì)造成數(shù)據(jù)丟失，但是卻導(dǎo)致TCP協(xié)議不符合可靠連接的要求。所以，Client不是直接進(jìn)入CLOSED，而是要保持TIME_WAIT，當(dāng)再次收到FIN的時(shí)候，能夠保證對(duì)方收到ACK，最后正確的關(guān)閉連接。

再說第二點(diǎn)，如果Client直接CLOSED，然后又再向Server發(fā)起一個(gè)新連接，我們不能保證這個(gè)新連接與剛關(guān)閉的連接的端口號(hào)是不同的。也就是說有可能新連接和老連接的端口號(hào)是相同的。一般來說不會(huì)發(fā)生什么問題，但是還是有特殊情況出現(xiàn)：假設(shè)新連接和已經(jīng)關(guān)閉的老連接端口號(hào)是一樣的，如果前一次連接的某些數(shù)據(jù)仍然滯留在網(wǎng)絡(luò)中，這些延遲數(shù)據(jù)在建立新連接之后才到達(dá)Server，由于新連接和老連接的端口號(hào)是一樣的，又因?yàn)門CP協(xié)議判斷不同連接的依據(jù)是socket pair，于是，TCP協(xié)議就認(rèn)為那個(gè)延遲的數(shù)據(jù)是屬于新連接的，這樣就和真正的新連接的數(shù)據(jù)包發(fā)生混淆了。所以TCP連接還要在TIME_WAIT狀態(tài)等待2倍MSL，這樣可以保證本次連接的所有數(shù)據(jù)都從網(wǎng)絡(luò)中消失。

硬件速度

網(wǎng)絡(luò)和服務(wù)器的負(fù)載

請(qǐng)求和響應(yīng)報(bào)文的尺寸

客戶端和服務(wù)器之間的距離

TCP 協(xié)議的技術(shù)復(fù)雜性

TCP 連接建立握手；

TCP 慢啟動(dòng)擁塞控制；

數(shù)據(jù)聚集的 Nagle 算法；

用于捎帶確認(rèn)的 TCP 延遲確認(rèn)算法；

TIME_WAIT 時(shí)延和端口耗盡。

介紹完畢，就這？

是的，就這。

補(bǔ)充：

大部分內(nèi)容為網(wǎng)絡(luò)整理，方便自己學(xué)習(xí)回顧，參考文章：

TCP 協(xié)議簡介

TCP協(xié)議圖文詳解

什么是TCP協(xié)議？

wireshark抓包分析——TCP/IP協(xié)議

TCP協(xié)議的三次握手和四次揮手

TCP協(xié)議詳解

TCP帶寬和時(shí)延的研究(1)

三、創(chuàng)建TCP連接的限制

1. 端口號(hào)限制?

首先，不存在由于端口號(hào)限制 65535 個(gè)的說法，因?yàn)槟繕?biāo)端的ip和端口是無限的。

當(dāng)然, Linux 對(duì)可使用的端口范圍是有具體限制的，具體可以用如下命令查看:

這個(gè)限制可以 vim /etc/sysctl.conf 這個(gè)文件進(jìn)行修改，我們?cè)谶@個(gè)文件里添加一行記錄:

保存好后執(zhí)行 sysctl -p /etc/sysctl.conf 使其生效。

2. 文件描述符的限制?

修改單個(gè)進(jìn)程可打開的最大文件描述符限制為100，可以這樣:

理論上文件描述符可以設(shè)置的足夠大。

3. 線程數(shù)的限制?

每建一個(gè)TCP連接就創(chuàng)建一個(gè)線程的方式，是最傳統(tǒng)的多線程并發(fā)模型，早期的操作系統(tǒng)也只支持這種方式。

C10K 問題: 當(dāng)服務(wù)器連接數(shù)達(dá)到 1 萬且每個(gè)連接都需要消耗一個(gè)線程資源時(shí)，操作系統(tǒng)就會(huì)不停地忙于線程的上下文切換，最終導(dǎo)致系統(tǒng)崩潰。

但是:

現(xiàn)在的操作系統(tǒng)都支持 IO 多路復(fù)用的方式，簡單說就是一個(gè)線程可以管理多個(gè) TCP 連接的資源，這樣就可以用少量的線程來管理大量的 TCP 連接了。

4. 內(nèi)存的限制?

這個(gè)錯(cuò)誤叫內(nèi)存溢出，每個(gè)TCP連接本身，以及這個(gè)連接所用到的緩沖區(qū)，都是需要占用一定內(nèi)存的

5. CPU的限制?

6. 總結(jié)一下，創(chuàng)建tcp連接需要的資源:

四、TCP建立連接時(shí)，（1）發(fā)送方第一次發(fā)送數(shù)據(jù)到收到對(duì)方確認(rèn)的RTT樣本值為4s，試計(jì)算超時(shí)重傳時(shí)間？

數(shù)據(jù)傳輸舉例 TCP數(shù)據(jù)傳輸發(fā)送方首先發(fā)送第一個(gè)包含序列號(hào)為1（可變化）和1460字節(jié)數(shù)據(jù)的TCP報(bào)文段給接收方。接收方以一個(gè)沒有數(shù)據(jù)的TCP報(bào)文段來回復(fù)（只含報(bào)頭）...

以上就是關(guān)于tcp建立連接需要幾個(gè)rtt相關(guān)問題的回答。希望能幫到你，如有更多相關(guān)問題，您也可以聯(lián)系我們的客服進(jìn)行咨詢，客服也會(huì)為您講解更多精彩的知識(shí)和內(nèi)容。