?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ????慕斯主頁：修仙—?jiǎng)e有洞天

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ???今日夜電波：マリンブルーの庭園—ずっと真夜中でいいのに。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? 0:34━━━━━━???──────── 3:34
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ?? ? ? ? ?? ? ????

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ???關(guān)注??點(diǎn)贊??收藏您的每一次鼓勵(lì)都是對(duì)我莫大的支持??

?

目錄

TCP協(xié)議再認(rèn)識(shí)

TCP協(xié)議段格式

選項(xiàng)

4位首部長度

如何保證TCP的可靠傳輸？確認(rèn)應(yīng)答機(jī)制

32位序號(hào)和確認(rèn)序號(hào)

為什么32位序號(hào)和32位確認(rèn)序號(hào)在不同的字段？

16位窗口大小

六個(gè)標(biāo)志位

超時(shí)重傳機(jī)制

TCP協(xié)議再認(rèn)識(shí)

????????我們都知道TCP協(xié)議叫做："傳輸控制協(xié)議(Transmission Control Protocol") 。TCP正人如其名, 要對(duì)數(shù)據(jù)的傳輸進(jìn)行一個(gè)詳細(xì)的控制。
????????TCP在操作系統(tǒng)內(nèi)也就是應(yīng)用層往下傳輸層中內(nèi)部是擁有自己的發(fā)送緩沖區(qū)和接收緩沖區(qū)的。當(dāng)建立了一個(gè)新的鏈接就會(huì)建立對(duì)應(yīng)的發(fā)送緩沖區(qū)和接收緩沖區(qū)。我們自定義在應(yīng)用層的緩沖區(qū)則稱為用戶緩沖區(qū)。實(shí)際上我們之前所說的使用write和read像文件一樣讀寫，不是直接從網(wǎng)絡(luò)中寫和讀。而是將用戶級(jí)的緩沖區(qū)寫入發(fā)送緩沖區(qū)，從接收緩沖區(qū)中讀取。本質(zhì)上都是拷貝的過程！至于什么時(shí)候發(fā)送什么時(shí)候接收，發(fā)多少收多少，怎么保障數(shù)據(jù)安全都是由TCP協(xié)議來控制的！大致圖示如下：

????????本質(zhì)上這同我們之前學(xué)的文件系統(tǒng)是一樣的，都是按照一定的規(guī)則將用戶級(jí)的緩沖區(qū)拷貝到系統(tǒng)級(jí)的緩沖區(qū)，再由系統(tǒng)級(jí)拷入磁盤，只不過這里是拷入網(wǎng)卡。發(fā)送和接收數(shù)據(jù)本質(zhì)上就是經(jīng)過網(wǎng)絡(luò)從另一方的發(fā)送緩沖區(qū)拷貝到接收緩沖區(qū)。

TCP協(xié)議段格式

????????TCP報(bào)文也是由報(bào)頭+有效載荷組成的，報(bào)頭的長度由規(guī)定和上圖可知為20字節(jié)。TCP是如何將報(bào)頭和有效載荷分離的呢？這和UDP是一樣因?yàn)閳?bào)頭都是固定大小的。因此，將報(bào)頭的20字節(jié)分離即可得到有效載荷。那他是如何交付給上層的呢？當(dāng)然也是通過源端口號(hào)和目標(biāo)端口號(hào)來確認(rèn)的。接下來我們詳細(xì)分析下面我們在報(bào)頭內(nèi)沒見過的幾部分字段：

?

選項(xiàng)

????????TCP協(xié)議段中的選項(xiàng)部分是為了適應(yīng)復(fù)雜的網(wǎng)絡(luò)環(huán)境和更好地為應(yīng)用層服務(wù)而設(shè)計(jì)的。這些選項(xiàng)為TCP連接提供了額外的配置和特性支持。下面是一些TCP協(xié)議段中常見的選項(xiàng)及其詳解：

1. 最大報(bào)文段長度（MSS）：MSS是TCP最初規(guī)定的一種選項(xiàng)，它規(guī)定了TCP報(bào)文數(shù)據(jù)部分的最大長度。這個(gè)長度是去除了TCP首部后的數(shù)據(jù)部分的最大長度，可以理解為傳輸層TCP的“MTU值”。在TCP連接建立時(shí)，通信雙方會(huì)將自己能夠支持的MSS寫入這一字段，以后就按照這個(gè)數(shù)值傳送數(shù)據(jù)。如果沒有設(shè)置這個(gè)值，那么MSS會(huì)取默認(rèn)值，通常為536字節(jié)。
2. 窗口擴(kuò)大因子：這個(gè)選項(xiàng)用于擴(kuò)大TCP的窗口大小，從而允許更大的數(shù)據(jù)流量，提高網(wǎng)絡(luò)吞吐量。
3. 時(shí)間戳：時(shí)間戳選項(xiàng)用于幫助TCP實(shí)現(xiàn)更精確的往返時(shí)間（RTT）測量和防止序列號(hào)回繞問題。它包含了一個(gè)發(fā)送時(shí)間戳和一個(gè)接收時(shí)間戳。
4. 選擇確認(rèn)（SACK）：SACK選項(xiàng)允許接收方發(fā)送關(guān)于丟失報(bào)文段的確認(rèn)信息，而不是僅僅確認(rèn)最后一個(gè)連續(xù)接收到的報(bào)文段。這使得發(fā)送方能夠更精確地重傳丟失的報(bào)文段，提高了傳輸效率。
5. 無操作（NOP）：NOP選項(xiàng)是1字節(jié)的，用作選項(xiàng)之間的填充，可以多次使用。
6. 選項(xiàng)結(jié)束（EOF）：EOF選項(xiàng)也是1字節(jié)的，用于在選項(xiàng)區(qū)的結(jié)尾處進(jìn)行填充，表示首部中沒有更多的選項(xiàng)了，并且從應(yīng)用程序傳遞來的數(shù)據(jù)開始于下一個(gè)32位字開始的地方。它只能用作最后一個(gè)選項(xiàng)，并且只允許出現(xiàn)一次。

????????除了上述常見的選項(xiàng)外，TCP協(xié)議段還可能包含其他選項(xiàng)，這些選項(xiàng)通常用于實(shí)現(xiàn)一些特殊的網(wǎng)絡(luò)功能或優(yōu)化性能。不同的操作系統(tǒng)和網(wǎng)絡(luò)環(huán)境可能會(huì)對(duì)TCP選項(xiàng)的實(shí)現(xiàn)和支持有所不同。如：客戶端與服務(wù)端建立了鏈接，但是這個(gè)鏈接長時(shí)間不過也不發(fā)數(shù)據(jù)，所以操作系統(tǒng)會(huì)保證鏈接在一定時(shí)間自動(dòng)斷開。

????????需要注意的是，TCP選項(xiàng)是可選的，并且它們的存在和順序是由發(fā)送方根據(jù)需要來確定的。接收方在解析TCP報(bào)文段時(shí)，必須能夠正確識(shí)別和處理這些選項(xiàng)，以確保數(shù)據(jù)的正確傳輸和連接的正常運(yùn)行。

4位首部長度

????????TCP協(xié)議段中的4位首部長度是用來表示TCP協(xié)議報(bào)頭長度的。這個(gè)字段只有4位，所以其取值范圍是0101到1111。由于這4位表示的是以4字節(jié)為單位的長度，因此TCP協(xié)議報(bào)頭的最大長度是15 * 4 = 60字節(jié)。

????????如果TCP協(xié)議不帶選項(xiàng)，那么4位首部長度就應(yīng)該是0101，對(duì)應(yīng)的十進(jìn)制值是5，代表的標(biāo)準(zhǔn)長度是5 * 4 = 20字節(jié)。這20字節(jié)是TCP的固定長度，包括源端口、目的端口、序號(hào)、確認(rèn)號(hào)、數(shù)據(jù)偏移、保留、標(biāo)志、窗口、校驗(yàn)和、緊急指針等字段。

????????當(dāng)TCP協(xié)議帶上選項(xiàng)時(shí)，報(bào)頭長度就會(huì)超過20字節(jié)。此時(shí)，選項(xiàng)的長度就是4位首部長度的值減去標(biāo)準(zhǔn)長度的值。選項(xiàng)是可以選擇帶或不帶的，它是TCP協(xié)議提供的一種靈活機(jī)制，用于適應(yīng)不同的網(wǎng)絡(luò)環(huán)境和需求。因此，報(bào)頭的取值范圍為[20,60]。TCP數(shù)據(jù)部分的大小則取決于可用窗口大小、擁塞控制算法以及其他因素。

????????需要注意的是，TCP協(xié)議的具體實(shí)現(xiàn)可能因操作系統(tǒng)和網(wǎng)絡(luò)環(huán)境的不同而有所差異，但基本的報(bào)頭長度和選項(xiàng)機(jī)制是相似的。

如何保證TCP的可靠傳輸？確認(rèn)應(yīng)答機(jī)制

????????TCP在通信的時(shí)候，難免會(huì)發(fā)送丟包、亂序、發(fā)送速度太快使得緩沖區(qū)滿了、重復(fù)等等狀況，那么如何保證數(shù)據(jù)的可靠傳輸呢？這就引出了確認(rèn)應(yīng)答機(jī)制：

????????也就是說：我給你發(fā)送了一個(gè)報(bào)文，你需要對(duì)這個(gè)報(bào)文進(jìn)行確認(rèn)并且返回確認(rèn)收到的報(bào)文（需要注意的是：他們都是TCP格式的報(bào)文，不管是否帶有數(shù)據(jù)至少擁有完整的報(bào)頭）但是我又怎么保證一定能收到對(duì)方一定能把報(bào)文發(fā)送給我，并且我能收到呢？因此只要我收到了應(yīng)答，那么對(duì)方一定是收到了，我沒有收到報(bào)文那么我就認(rèn)為報(bào)文丟失了，我會(huì)再給你發(fā)報(bào)文，直到我收到應(yīng)答。

32位序號(hào)和確認(rèn)序號(hào)

????????通過上面對(duì)于應(yīng)答機(jī)制的認(rèn)識(shí)，我們發(fā)現(xiàn)如果只是一個(gè)發(fā)一個(gè)返回信息應(yīng)答那么效率也太低了，因此我們可能會(huì)一次性向?qū)Ψ桨l(fā)大量的數(shù)據(jù)，當(dāng)然也會(huì)收大量的數(shù)據(jù)。但是這樣引出了幾個(gè)問題：（1）發(fā)的順序不一定是收的順序。（2）不能確認(rèn)應(yīng)答報(bào)文和發(fā)送報(bào)文對(duì)應(yīng)關(guān)系。 因此，需要給報(bào)文加上編號(hào)，也就是在報(bào)頭中需要包含序號(hào)！

????????TCP協(xié)議段中的32位序號(hào)和確認(rèn)序號(hào)是TCP協(xié)議中非常重要的兩個(gè)字段，它們共同確保了TCP數(shù)據(jù)傳輸?shù)目煽啃院陀行蛐浴?/p>

????????首先，32位序號(hào)表示的是該報(bào)文段所發(fā)送數(shù)據(jù)的第一個(gè)字節(jié)的編號(hào)。TCP連接中所傳輸字節(jié)流的每一個(gè)字節(jié)都會(huì)按順序編號(hào)。每發(fā)送一次數(shù)據(jù)，序號(hào)就會(huì)累加一次。當(dāng)序號(hào)達(dá)到2^32時(shí)，會(huì)發(fā)生回繞，序號(hào)重新從0開始。這樣的設(shè)計(jì)使得TCP能夠處理亂序到達(dá)的數(shù)據(jù)包，并且能夠精確地識(shí)別丟失或重復(fù)的數(shù)據(jù)包。

????????而確認(rèn)序號(hào)則是接收方期望收到發(fā)送方下一個(gè)報(bào)文段的第一個(gè)字節(jié)數(shù)據(jù)的編號(hào)。也就是說，確認(rèn)序號(hào)告訴發(fā)送方：我希望你下次發(fā)送的數(shù)據(jù)的第一個(gè)字節(jié)數(shù)據(jù)的編號(hào)為此確認(rèn)號(hào)。只有當(dāng)ACK（后續(xù)詳細(xì)介紹）標(biāo)志為1時(shí)，確認(rèn)序號(hào)才有效。發(fā)送端收到確認(rèn)應(yīng)答后，代表確認(rèn)序號(hào)之前的數(shù)據(jù)都已經(jīng)被正常接收。如下圖所示：

????????TCP將每個(gè)字節(jié)的數(shù)據(jù)都進(jìn)行了編號(hào). 即為序列號(hào).

????????每一個(gè)ACK都帶有對(duì)應(yīng)的確認(rèn)序列號(hào), 意思是告訴發(fā)送者, 我已經(jīng)收到了哪些數(shù)據(jù); 下一次你從哪里開始發(fā).

????????需要特別注意的是：如果在確認(rèn)應(yīng)答時(shí)，中間的“應(yīng)答報(bào)文”丟失了，但是他后面的報(bào)文收到了那么后面報(bào)文往前的信息都會(huì)認(rèn)為已經(jīng)收到了。因?yàn)榇_認(rèn)序號(hào)認(rèn)為他之前的序號(hào)都是已經(jīng)接受成功了的。比如：客戶端發(fā)送了1~1000、1001~2000、2001~3000.。如果其中的1001~2000并沒有收到，那么返回的確認(rèn)報(bào)文中為1001。大致圖示如下：

????????在TCP的數(shù)據(jù)傳輸過程中，發(fā)送方會(huì)不斷發(fā)送數(shù)據(jù)，并等待接收方的確認(rèn)。接收方每收到一個(gè)報(bào)文段，就會(huì)發(fā)送一個(gè)確認(rèn)報(bào)文，告訴發(fā)送方已經(jīng)成功接收到的數(shù)據(jù)的序號(hào)。這樣，發(fā)送方就可以根據(jù)接收方的確認(rèn)序號(hào)，知道哪些數(shù)據(jù)已經(jīng)被成功接收，哪些數(shù)據(jù)還需要重傳。

????????總的來說，32位序號(hào)和確認(rèn)序號(hào)是TCP協(xié)議中保證數(shù)據(jù)傳輸可靠性和有序性的關(guān)鍵機(jī)制。它們共同協(xié)作，確保數(shù)據(jù)能夠按照正確的順序、無丟失地傳輸?shù)侥康牡亍?/p>

?

為什么32位序號(hào)和32位確認(rèn)序號(hào)在不同的字段？

????????我們都知道TCP是全雙工的。那么當(dāng)客戶端發(fā)送報(bào)文給服務(wù)器，服務(wù)器在應(yīng)答時(shí)為什么僅僅就只發(fā)一個(gè)應(yīng)答報(bào)文，而不是帶上數(shù)據(jù)返回呢？這樣難道不會(huì)提高通信效率嗎？而32位序號(hào)和32位確認(rèn)序號(hào)的設(shè)計(jì)就在這里。這種報(bào)文也叫做捎帶應(yīng)答！為了保證32位序號(hào)和32位確認(rèn)序號(hào)同時(shí)存在所以需要在不同的字段。

16位窗口大小

????????應(yīng)用層和傳輸層之間有著如下的系統(tǒng)調(diào)用接口：send、write、read、recv。

????????我們?nèi)绻褂萌缟系慕涌谠谟肨CP發(fā)送數(shù)據(jù)是發(fā)送的太快，那么系統(tǒng)的緩沖區(qū)很快就被填滿了，那么后續(xù)沒收到的報(bào)文就會(huì)被丟棄。雖然TCP會(huì)重傳，但是這也太浪費(fèi)網(wǎng)絡(luò)資源和效率了。因此，我們需要控制發(fā)送的速度，該快的時(shí)候快，該慢的時(shí)候慢！這種策略叫做流量策略。發(fā)送方發(fā)送的數(shù)據(jù)大小、數(shù)據(jù)快慢是受到接收方能接收多少來控制的，這取決于接收方的緩沖區(qū)剩下的空間。因此，每個(gè)報(bào)文都會(huì)應(yīng)答自己的接收能力，這就是16為窗口大小。

????????TCP協(xié)議段中的16位窗口大小字段用于表示接收端期望接收的下一個(gè)字節(jié)的序號(hào)，同時(shí)也反映了接收端的緩沖區(qū)剩余空間大小。這個(gè)字段是TCP流量控制的關(guān)鍵部分，由連接的每一端通過聲明的窗口大小來提供。窗口大小的起始值是基于確認(rèn)序號(hào)字段指明的值，即接收端正期望接收的字節(jié)。

????????窗口大小字段是一個(gè)16位的字段，因此其最大值為65535字節(jié)。這個(gè)字段的大小限制了TCP在一次傳輸中可以發(fā)送的數(shù)據(jù)量，從而實(shí)現(xiàn)了發(fā)送方和接收方之間的流量控制。

????????在TCP連接建立之初，發(fā)送方通常從一個(gè)較小的窗口開始發(fā)送數(shù)據(jù)，然后根據(jù)接收方的ACK響應(yīng)逐漸增大窗口大小。這個(gè)過程通過TCP的慢啟動(dòng)機(jī)制來實(shí)現(xiàn)，發(fā)送窗口大小最初會(huì)成指數(shù)增長（每次是之前的2倍），但是一旦發(fā)生丟包，發(fā)送窗口大小將會(huì)減少到一個(gè)包的大小，之后再次指數(shù)級(jí)增長直到之前發(fā)生丟包時(shí)發(fā)送窗口大小的一半。此后，發(fā)送窗口大小會(huì)由指數(shù)增長變?yōu)榫€性增長。

????????這種動(dòng)態(tài)調(diào)整發(fā)送窗口大小的方式，可以根據(jù)網(wǎng)絡(luò)狀況實(shí)時(shí)調(diào)整數(shù)據(jù)傳輸速率，從而提高數(shù)據(jù)傳輸效率，同時(shí)避免網(wǎng)絡(luò)擁塞。因此，16位窗口大小字段在TCP協(xié)議中扮演著至關(guān)重要的角色，是確保TCP數(shù)據(jù)傳輸可靠性和效率的重要機(jī)制之一。

六個(gè)標(biāo)志位

????????六個(gè)標(biāo)記位的功能為的是區(qū)分TCP報(bào)文的類型，對(duì)于不同報(bào)文將會(huì)有不同的處理動(dòng)作。TCP協(xié)議段中的六個(gè)標(biāo)志位各自承載著不同的功能，它們在TCP通信過程中起著至關(guān)重要的作用。需要注意的是：每個(gè)標(biāo)志位僅占1bit。下面是對(duì)這六個(gè)標(biāo)志位的詳細(xì)解釋：

1. URG（緊急）標(biāo)志位：

• • 當(dāng)URG=1時(shí)，表示TCP報(bào)文段中有緊急數(shù)據(jù)，應(yīng)盡快傳送，此時(shí)緊急指針字段有效。它告訴系統(tǒng)此報(bào)文段中有緊急數(shù)據(jù)，應(yīng)盡快傳送（相當(dāng)于按“緊急呼叫”）。
  • 緊急指針是一個(gè)正的偏移量，和序號(hào)字段中的值相加表示緊急數(shù)據(jù)最后一個(gè)字節(jié)的序號(hào)。TCP的緊急方式是發(fā)送端向另一端發(fā)送緊急數(shù)據(jù)的一種方式。

????????當(dāng)設(shè)置URG為1時(shí)，意味著這個(gè)報(bào)文中含有緊急數(shù)據(jù)，報(bào)文中的字段16為緊急指針將會(huì)有效，緊急指針表示的是該報(bào)文數(shù)據(jù)中緊急數(shù)據(jù)的偏移量。而這個(gè)緊急數(shù)據(jù)的大小為1字節(jié)?？梢酝ㄟ^設(shè)置send中的flags參數(shù)為MSG_OOB,recv也設(shè)置為MSG_OOB來接收。

1. ACK（確認(rèn)）標(biāo)志位：

• • 僅當(dāng)ACK=1時(shí)確認(rèn)號(hào)字段才有效。當(dāng)ACK標(biāo)志位為1時(shí)，確認(rèn)號(hào)字段有效，TCP規(guī)定，在連接建立后所有傳送的報(bào)文段都必須把ACK置為1。
  • TCP報(bào)文段一旦發(fā)送，則啟動(dòng)一個(gè)定時(shí)器，等待對(duì)方的確認(rèn)。如果在規(guī)定時(shí)間內(nèi)未收到對(duì)方的確認(rèn)，則重發(fā)此報(bào)文段。

1. PSH（推送）標(biāo)志位：

• • 當(dāng)PSH=1時(shí)，接收端TCP應(yīng)盡快地交付給應(yīng)用進(jìn)程。發(fā)送方TCP把PSH置為1，并請求接收方TCP在收到該報(bào)文段后就把數(shù)據(jù)立即傳送給接收應(yīng)用程序，而不是等到緩沖區(qū)滿后再傳送。
  • PSH標(biāo)志位適用于交互式應(yīng)用，如telnet或rlogin等。在這些應(yīng)用中，需要盡可能地減少數(shù)據(jù)的傳輸延遲。

1. RST（復(fù)位）標(biāo)志位：

• • 用于復(fù)位那些產(chǎn)生錯(cuò)誤的連接，也被用來拒絕錯(cuò)誤和非法的數(shù)據(jù)包。當(dāng)RST=1時(shí)，表明TCP連接中出現(xiàn)嚴(yán)重差錯(cuò)（如由于主機(jī)崩潰或其他原因），必須釋放連接，然后再重新建立運(yùn)輸連接。
  • RST標(biāo)志位還可以用來拒絕一個(gè)無效的數(shù)據(jù)段或拒絕一個(gè)連接請求。

1. SYN（同步）標(biāo)志位：

• • 用來建立連接。當(dāng)SYN=1而ACK=0時(shí)，表明這是一個(gè)連接請求報(bào)文段。對(duì)方若同意建立連接，則應(yīng)在應(yīng)答的報(bào)文段中使SYN=1和ACK=1。因此，SYN置為1就表示這是一個(gè)連接請求或連接接受報(bào)文。
  • SYN標(biāo)志位和ACK標(biāo)志位搭配使用，共同參與了TCP的三次握手過程，確保連接的可靠建立。

1. FIN（結(jié)束）標(biāo)志位：

• • 用來釋放一個(gè)連接。當(dāng)FIN=1時(shí)，表明此報(bào)文段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢，并要求釋放運(yùn)輸連接。
  • 在TCP的四次斷開過程中，F(xiàn)IN標(biāo)志位被用來通知對(duì)方本端已經(jīng)完成了數(shù)據(jù)的發(fā)送，準(zhǔn)備關(guān)閉連接。雖然對(duì)應(yīng)的端口仍處于開放狀態(tài)，準(zhǔn)備接收后續(xù)數(shù)據(jù)，但實(shí)際上已經(jīng)沒有數(shù)據(jù)需要發(fā)送了。

????????這六個(gè)標(biāo)志位協(xié)同工作，確保了TCP協(xié)議在復(fù)雜多變的網(wǎng)絡(luò)環(huán)境中能夠?qū)崿F(xiàn)可靠的數(shù)據(jù)傳輸和連接管理。

超時(shí)重傳機(jī)制

????????主機(jī)A發(fā)送數(shù)據(jù)給B之后, 可能因?yàn)榫W(wǎng)絡(luò)擁堵等原因, 數(shù)據(jù)無法到達(dá)主機(jī)B;
????????如果主機(jī)A在一個(gè)特定時(shí)間間隔內(nèi)沒有收到B發(fā)來的確認(rèn)應(yīng)答, 就會(huì)進(jìn)行重發(fā);

????????但是, 主機(jī)A未收到B發(fā)來的確認(rèn)應(yīng)答, 也可能是因?yàn)锳CK丟失了;

????????因此主機(jī)B會(huì)收到很多重復(fù)數(shù)據(jù). 那么TCP協(xié)議需要能夠識(shí)別出那些包是重復(fù)的包, 并且把重復(fù)的丟棄掉.去重的效果. 這時(shí)候我們可以利用前面提到的序列號(hào)

????????那么, 如果超時(shí)的時(shí)間如何確定?
????????最理想的情況下, 找到一個(gè)最小的時(shí)間, 保證 "確認(rèn)應(yīng)答一定能在這個(gè)時(shí)間內(nèi)返回".但是這個(gè)時(shí)間的長短, 隨著網(wǎng)絡(luò)環(huán)境的不同, 是有差異的.如果超時(shí)時(shí)間設(shè)的太長, 會(huì)影響整體的重傳效率;如果超時(shí)時(shí)間設(shè)的太短, 有可能會(huì)頻繁發(fā)送重復(fù)的包;
????????TCP為了保證無論在任何環(huán)境下都能比較高性能的通信, 因此會(huì)動(dòng)態(tài)計(jì)算這個(gè)最大超時(shí)時(shí)間.
Linux中(BSD Unix和Windows也是如此), 超時(shí)以500ms為一個(gè)單位進(jìn)行控制, 每次判定超時(shí)重發(fā)的超時(shí)時(shí)間都是500ms的整數(shù)倍.如果重發(fā)一次之后, 仍然得不到應(yīng)答, 等待 2*500ms 后再進(jìn)行重傳.如果仍然得不到應(yīng)答, 等待 4*500ms 進(jìn)行重傳. 依次類推, 以指數(shù)形式遞增.累計(jì)到一定的重傳次數(shù), TCP認(rèn)為網(wǎng)絡(luò)或者對(duì)端主機(jī)出現(xiàn)異常, 強(qiáng)制關(guān)閉連接。

?

??????????????????? ? ?感謝你耐心的看到這里?( ′???` )比心，如有哪里有錯(cuò)誤請?zhí)咭荒_作者o(╥﹏╥)o！?

????????????????????????????????? ? ? ?

????????????????????????????????????????????????????????????????????????給個(gè)三連再走嘛~??

?文章來源地址http://www.zghlxwxcb.cn/news/detail-853641.html

到了這里，關(guān)于計(jì)算機(jī)網(wǎng)絡(luò)—TCP協(xié)議詳解：協(xié)議構(gòu)成、深度解析（1）的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！