傳輸控制協(xié)議 TCP 概述

TCP 最主要的特點(diǎn)

TCP 是面向連接的運(yùn)輸層協(xié)議。應(yīng)用程序在使用 TCP 協(xié)議之前，必須先建立 TCP 連接。在傳送數(shù)據(jù)完畢后，必須釋放已經(jīng)建立的 TCP 連接

每一條 TCP 連接只能有兩個(gè)端點(diǎn)，每一條 TCP 連接只能是點(diǎn)對(duì)點(diǎn)的(一對(duì)一)

TCP 提供可靠交付的服務(wù)。通過(guò) TCP 連接傳送的數(shù)據(jù)，無(wú)差錯(cuò)、不丟失、不重復(fù)，并且按序到達(dá)

TCP 提供全雙工通信。TCP 允許通信雙方的應(yīng)用進(jìn)程在任何時(shí)候都能發(fā)送數(shù)據(jù)。TCP 連接的兩端都設(shè)有發(fā)送緩存和接受緩存，用來(lái)臨時(shí)存放雙向通信的數(shù)據(jù)

面向字節(jié)流。TCP 中的“流”指的是流入到進(jìn)程或從進(jìn)程流出的字節(jié)序列

面向字節(jié)流

“面向字節(jié)流”的含義是：雖然應(yīng)用程序和 TCP 的交互式一次一個(gè)數(shù)據(jù)塊(大小不等)，但 TCP 把應(yīng)用程序交下來(lái)的數(shù)據(jù)僅僅看成是一連串的無(wú)結(jié)構(gòu)的字節(jié)流。TCP 并不知道所傳送的字節(jié)流的含義

TCP 不保證接收方應(yīng)用程序所收到的數(shù)據(jù)塊和發(fā)送方應(yīng)用程序所發(fā)出的數(shù)據(jù)塊具有對(duì)應(yīng)大小的關(guān)系

例如，發(fā)送方應(yīng)用程序交給發(fā)送方的 TCP 共10個(gè)數(shù)據(jù)塊，但接收方的 TCP 可能只用了4個(gè)數(shù)據(jù)塊就把收到的字節(jié)流交付上層的應(yīng)用程序

接收方應(yīng)用程序收到的字節(jié)流必須和發(fā)送方應(yīng)用程序發(fā)出的字節(jié)流完全一樣。接收方的應(yīng)用程序必須有能力識(shí)別收到的字節(jié)流，把它還原成有意義的應(yīng)用層數(shù)據(jù)

TCP 和 UDP 在發(fā)送報(bào)文時(shí)采用的方式完全不同。TCP 并不關(guān)心應(yīng)用進(jìn)程一次把多長(zhǎng)的報(bào)文發(fā)送到 TCP 的緩存中，而是根據(jù)對(duì)方給出的窗口值和當(dāng)前網(wǎng)絡(luò)擁塞的程度來(lái)決定一個(gè)報(bào)文段應(yīng)包含多少個(gè)字節(jié)(UDP 發(fā)送的報(bào)文長(zhǎng)度是應(yīng)用進(jìn)程給出的)。如果應(yīng)用進(jìn)程傳送到 TCP 緩存的數(shù)據(jù)塊太長(zhǎng)，TCP 就可以把它劃分短一些再傳送。如果應(yīng)用進(jìn)程一次只發(fā)來(lái)一個(gè)字節(jié)，TCP 也可以等待積累有足夠多的字節(jié)后再構(gòu)成報(bào)文段發(fā)送出去

《PHP面試問(wèn)答》 https://github.com/colinlet/P...

結(jié)合實(shí)際 PHP 面試，系統(tǒng)的匯總面試中的各種各樣的問(wèn)題，嘗試提供簡(jiǎn)潔準(zhǔn)確的答案。如果你在 PHP 面試中遇到問(wèn)題，歡迎提 Issues 交流。包含網(wǎng)絡(luò)協(xié)議、數(shù)據(jù)結(jié)構(gòu)與算法、PHP、Web、MySQL、Redis、Linux、安全、設(shè)計(jì)模式、架構(gòu)、自我介紹、離職原因、職業(yè)規(guī)劃、準(zhǔn)備問(wèn)題等部分

如果覺(jué)得不錯(cuò)歡迎 star 關(guān)注，正在不斷持續(xù)更新中~~

TCP 的連接

TCP 把連接作為最基本的抽象。TCP 的許多特性都與 TCP 是面向連接的這個(gè)基本特性有關(guān)

TCP 連接的端點(diǎn)叫做套接字(socket)或插口，根據(jù) RFC 793 的定義：端口號(hào)拼接到(concatenated with) IP 地址即構(gòu)成了套接字

套接字 socket = (IP 地址：端口號(hào))

每一條 TCP 連接唯一地被通信兩端的兩個(gè)端點(diǎn)(即兩個(gè)套接字)所確定

TCP 連接 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}

TCP 連接就是由協(xié)議軟件所提供的一種抽象。TCP 連接的端口是個(gè)很抽象的套接字，即( IP地址: 端口號(hào))。同一個(gè) IP 地址可以有多個(gè)不同的 TCP 連接，而同一個(gè)端口號(hào)也可以出現(xiàn)在多個(gè)不同的 TCP 連接中

易混淆的 socket

同一個(gè)名詞 socket 卻可表示多種不同的意思，以下 socket 的意思跟本文中所引用的 RFC 793 定義的 socket(指端口號(hào)拼接到 IP 地址)不同

允許應(yīng)用程序訪問(wèn)連網(wǎng)協(xié)議的應(yīng)用編程接口 API(Application Programming Interface)，即運(yùn)輸層和應(yīng)用層之間的接口，稱為 socket API，并簡(jiǎn)稱為 socket

在 socket API 中使用的一個(gè)函數(shù)名也叫做 socket

調(diào)用 socket 函數(shù)的端點(diǎn)稱為 socket，如“創(chuàng)建一個(gè)數(shù)據(jù)報(bào) socket”

調(diào)用 socket 函數(shù)時(shí)，其返回值稱為 socket 描述符，可簡(jiǎn)稱為 socket

在操作系統(tǒng)內(nèi)核中連網(wǎng)協(xié)議的 Berkeley 實(shí)現(xiàn)，稱為 socket 實(shí)現(xiàn)

可靠傳輸?shù)墓ぷ髟?/p>

理想的傳輸條件

理想的傳輸條件有以下兩個(gè)特點(diǎn)

傳輸信道不產(chǎn)生差錯(cuò)

不管發(fā)送方以多快的速度發(fā)送數(shù)據(jù)，接收方總是來(lái)得及處理收到的數(shù)據(jù)

實(shí)際的網(wǎng)絡(luò)不具備以上兩個(gè)理想條件。需要使用一些可靠的傳輸協(xié)議，當(dāng)出現(xiàn)差錯(cuò)時(shí)讓發(fā)送方重傳出現(xiàn)差錯(cuò)的數(shù)據(jù)，同時(shí)在接收方來(lái)不及處理收到的數(shù)據(jù)時(shí)，及時(shí)告訴發(fā)送方適當(dāng)減低發(fā)送數(shù)據(jù)的速度。這樣，不可靠的傳輸信道就能夠?qū)崿F(xiàn)可靠傳輸了

停止等待協(xié)議

全雙工通信的雙方既是發(fā)送方也是接收方。把傳送的數(shù)據(jù)單元都稱為分組。“停止等待”就是每發(fā)完一個(gè)分組就停止發(fā)送，等待對(duì)方的確認(rèn)。在收到確認(rèn)后再發(fā)送下一個(gè)分組

無(wú)差錯(cuò)情況

出現(xiàn)差錯(cuò)

只要超過(guò)一段時(shí)間沒(méi)有收到確認(rèn)，就認(rèn)為剛才發(fā)送的分組丟失了，因而重傳前面發(fā)送過(guò)的分組。這就叫做超時(shí)重傳。要實(shí)現(xiàn)超時(shí)重傳，就要在每發(fā)送完一個(gè)分組時(shí)設(shè)置一個(gè)超時(shí)計(jì)時(shí)器

發(fā)送完一個(gè)分組后，必須暫時(shí)保留已發(fā)送的分組的副本(在發(fā)生超時(shí)重傳時(shí)使用)。只有在收到相應(yīng)的確認(rèn)后才能清除暫時(shí)保留的分組副本

分組和確認(rèn)分組都必須進(jìn)行編號(hào)。這樣才能明確是哪一個(gè)發(fā)送出去的分組收到了確認(rèn)，而哪一個(gè)分組還沒(méi)有收到確認(rèn)

超時(shí)計(jì)時(shí)器的重傳時(shí)間應(yīng)當(dāng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r(shí)間更長(zhǎng)一些

確認(rèn)丟失和確認(rèn)遲到

使用上述的確認(rèn)和重傳機(jī)制，我們就可以在不可靠的傳輸網(wǎng)絡(luò)上實(shí)現(xiàn)可靠的通信

像上述的這種可靠傳輸協(xié)議常稱為自動(dòng)重傳請(qǐng)求 ARQ(Automatic Repeat reQuest)。重傳的請(qǐng)求是自動(dòng)進(jìn)行的。接收方不需要請(qǐng)求發(fā)送方重傳某個(gè)出錯(cuò)的分組

信道利用率

停止等待協(xié)議的優(yōu)點(diǎn)是簡(jiǎn)單，但缺點(diǎn)是信道利用率太低

為了提高傳輸效率，發(fā)送方可以不使用低效率的停止等待協(xié)議，而是采用流水線傳輸。流水線傳輸就是發(fā)送方可連續(xù)發(fā)送多個(gè)分組，不必每發(fā)完一個(gè)分組就停頓下來(lái)等待對(duì)方的確認(rèn)。這樣可使信道上一直有數(shù)據(jù)不間斷地在傳送。這種傳輸方式可以獲得很高的信道利用率

連續(xù) ARQ 協(xié)議

位于發(fā)送窗口內(nèi)的5個(gè)分組都可以連續(xù)發(fā)送出去，而不需要等待對(duì)方的確認(rèn)。可以提高信道利用率

接收方一般都是采用累積確認(rèn)的方式。接收方不需要對(duì)收到的分組逐個(gè)發(fā)送確認(rèn)，而是在收到幾個(gè)分組后，對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)

積累確認(rèn)有優(yōu)點(diǎn)也有缺點(diǎn)。優(yōu)點(diǎn)是：容易實(shí)現(xiàn)，即使確認(rèn)丟失也不必重傳。缺點(diǎn)是不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息

TCP 報(bào)文段的首部格式

TCP 雖然是面向字節(jié)流的，但 TCP 傳送的數(shù)據(jù)單元卻是報(bào)文段。一個(gè) TCP 報(bào)文段分為首部和數(shù)據(jù)兩部分。TCP 報(bào)文段首部的前20個(gè)字節(jié)是固定的，后面有4n字節(jié)是根據(jù)需要而增加的選項(xiàng)(n是整數(shù))。因此 TCP 首部的最小長(zhǎng)度是20字節(jié)

首部字段

源端口和目的端口 各占2個(gè)字節(jié)，分別寫(xiě)入源端口號(hào)和目的端口號(hào)

序號(hào) 占4字節(jié)。序號(hào)范圍是[0, 232-1]，共232(即4 294 967 296)個(gè)序號(hào)。序號(hào)增加到232-1后，下一個(gè)序號(hào)就又回到0。在一個(gè) TCP 連接中傳送的字節(jié)流中的每一個(gè)字節(jié)都按順序編號(hào)

確認(rèn)號(hào) 占4字節(jié)，是期望收到對(duì)方下一個(gè)報(bào)文段的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)

數(shù)據(jù)偏移 占4字節(jié)，它指出 TCP 報(bào)文段的數(shù)據(jù)起始處距離 TCP 報(bào)文段的起始處有多遠(yuǎn)。這個(gè)字段實(shí)際上是指出 TCP 報(bào)文段的首部長(zhǎng)度

保留 占6位，保留為今后使用，但目前應(yīng)置為0

下面有6個(gè)控制位，用來(lái)說(shuō)明本報(bào)文段的性質(zhì)

緊急 URG(URGent) 當(dāng) URG=1 時(shí)，表明緊急指針字段有效。它告訴系統(tǒng)此報(bào)文段中有緊急數(shù)據(jù)，應(yīng)盡快傳送(相當(dāng)于高優(yōu)先級(jí)的數(shù)據(jù))，而不是按原先的排隊(duì)順序來(lái)傳送

確認(rèn) ACK(ACKnowledgment) 僅當(dāng) ACK=1 時(shí)確認(rèn)號(hào)字段才有效。當(dāng) ACK=0 時(shí)，確認(rèn)號(hào)無(wú)效。TCP 規(guī)定，在連接建立后所有傳送的報(bào)文段都必須把 ACK 置1

推送 PSH(Push) 當(dāng)兩個(gè)應(yīng)用進(jìn)程進(jìn)行交互式的通信時(shí)，有時(shí)在一端的應(yīng)用進(jìn)程希望在鍵入一個(gè)命令后立即就能夠收到對(duì)方的響應(yīng)

復(fù)位 RST(ReSeT) 當(dāng) RST=1 時(shí)，表明 TCP 連接中出現(xiàn)嚴(yán)重差錯(cuò)(如由于主機(jī)崩潰或其他原因)，必須釋放連接，然后再重新建立運(yùn)輸連接

同步 SYN(SYNnchronization) 在連接建立時(shí)用來(lái)同步序號(hào)。當(dāng) SYN=1 而 ACK=0 時(shí)，表明這是一個(gè)連接請(qǐng)求報(bào)文段。對(duì)方若同意建立連接，則應(yīng)在響應(yīng)的報(bào)文段中使 SYN=1 和 ACK=1

終止 FIN(FINis) 用來(lái)釋放一個(gè)連接。當(dāng) FIN=1 時(shí)，表明此報(bào)文段的發(fā)送發(fā)的數(shù)據(jù)已發(fā)送完畢，并要求釋放運(yùn)輸連接

窗口 占2字節(jié)。窗口值是[0, 216-1]之間的整數(shù)。窗口值作為接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依舊

檢驗(yàn)和 占2字節(jié)。檢驗(yàn)和字段檢驗(yàn)的范圍包括首部和數(shù)據(jù)這兩部分

緊急指針 占2字節(jié)。緊急指針僅在 URG=1 時(shí)才有意義，它指出本報(bào)文段中的緊急數(shù)據(jù)的字節(jié)數(shù)

選項(xiàng) 長(zhǎng)度可變，最長(zhǎng)可達(dá)40字節(jié)

TCP 可靠傳輸?shù)膶?shí)現(xiàn)

以字節(jié)為單位的滑動(dòng)窗口

發(fā)送窗口構(gòu)造

TCP 的滑動(dòng)窗口是以字節(jié)為單位的。假定 A 收到了 B 發(fā)來(lái)的確認(rèn)報(bào)文段，其中窗口是20字節(jié)，而確認(rèn)號(hào)是31(這表明 B 期望收到的下一個(gè)序號(hào)是31，而序號(hào)30為止的數(shù)據(jù)已經(jīng)收到了)。根據(jù)這兩個(gè)數(shù)據(jù)，A 就構(gòu)造出自己的發(fā)送窗口

發(fā)送窗口標(biāo)識(shí)：在沒(méi)有收到 B 的確認(rèn)的情況下，A 可以連續(xù)把窗口內(nèi)的數(shù)據(jù)都發(fā)送出去。凡是已經(jīng)發(fā)送出去的數(shù)據(jù)，在未收到確認(rèn)之前都必須暫時(shí)保留，以便在超時(shí)重傳時(shí)使用

發(fā)送窗口變化

發(fā)送窗口的位置由窗口前沿和后沿的位置共同確定。發(fā)送窗口后沿的變化情況有兩種，即不動(dòng)(沒(méi)有收到新的確認(rèn))和前移(收到了新的確認(rèn))。發(fā)送窗口后沿不可能向后移動(dòng)，因?yàn)椴荒艹蜂N已收到的確認(rèn)

發(fā)送窗口前沿通常是不斷向前移動(dòng)，但也有可能不動(dòng)。這對(duì)應(yīng)于兩種情況：

一是沒(méi)有收到信的確認(rèn)，對(duì)應(yīng)通知的窗口大小也不變

二是收到了新的窗口單對(duì)方通知的窗口縮小了，使得發(fā)送窗口前沿正好不動(dòng)

發(fā)送窗口前沿也有可能向后收縮。這發(fā)生在對(duì)方通知的窗口縮小了。但 TCP 的標(biāo)準(zhǔn)強(qiáng)烈不贊成這樣做。因?yàn)楹芸赡馨l(fā)送方在收到這個(gè)通知以前已經(jīng)發(fā)生了窗口中的許多數(shù)據(jù)，現(xiàn)在又要收縮窗口，不讓發(fā)送這些數(shù)據(jù)，這樣就會(huì)產(chǎn)生一些錯(cuò)誤

要描述一個(gè)發(fā)送窗口的狀態(tài)需要三個(gè)指針：P1，P2，P3。指針都指向字節(jié)的序號(hào)。這三個(gè)指針指向的幾個(gè)部分的意義如下：

小于 P1 的是已發(fā)送并已收到確認(rèn)的部分，而大于 P3 的是不允許發(fā)送的部分

P3 - P1 = A 的發(fā)送窗口

P2 - P1 已發(fā)送但尚未收到確認(rèn)的字節(jié)數(shù)

P3 - P2 允許發(fā)送但當(dāng)前尚未發(fā)送的字節(jié)數(shù)(又稱為可用窗口或有效窗口)

B 的接收窗口大小是20。在接收窗口外面，到30號(hào)為止的數(shù)據(jù)是已經(jīng)發(fā)送過(guò)確認(rèn)，并且已經(jīng)交付主機(jī)了。因此在 B 可以不再保留這些數(shù)據(jù)。接收窗口內(nèi)的序號(hào)(31~50)是允許接收的。在上圖中，B 收到了序號(hào)為32和33的數(shù)據(jù)。這些數(shù)據(jù)沒(méi)有按序到達(dá)，因?yàn)樾蛱?hào)為31的數(shù)據(jù)沒(méi)有收到(也許丟失了，也許滯留在網(wǎng)絡(luò)中的某處)。請(qǐng)注意，B 只能對(duì)按序收到的數(shù)據(jù)中的最高序號(hào)給出確認(rèn)，因此 B 發(fā)送的確認(rèn)報(bào)文段中的確認(rèn)號(hào)仍然是31(即期望收到的序號(hào))，而不是32或33

現(xiàn)在假定 B 收到了序號(hào)為31的數(shù)據(jù)，并把序號(hào)為31~33的數(shù)據(jù)交付主機(jī)，然后 B 刪除這些數(shù)據(jù)。接著把接收窗口向前移動(dòng)3個(gè)序號(hào)，同時(shí)給 A 發(fā)送確認(rèn)，其中窗口值仍為20，但確認(rèn)號(hào)是34.這表明 B 已經(jīng)收到了到序號(hào)33為止的數(shù)據(jù)。B 還收到了序號(hào)為37，38和40的數(shù)據(jù)，但這些都沒(méi)有按序到達(dá)，只能先暫存在接收窗口中。A 收到 B 的確認(rèn)后，就可以把發(fā)送窗口向前滑動(dòng)3個(gè)序號(hào)，但指針 P2 不動(dòng)。現(xiàn)在 A 的可用窗口增大了，可發(fā)送的序號(hào)范圍是42~53

A 在繼續(xù)發(fā)送完序號(hào)42~53的數(shù)據(jù)后，指針 P2 向前移動(dòng)和 P3 重合。發(fā)送窗口內(nèi)的序號(hào)都已用完，但還沒(méi)有再收到確認(rèn)。由于 A 的發(fā)送窗口已滿，可用窗口已減小到零，因此必須停止發(fā)送。發(fā)送窗口內(nèi)所有的數(shù)據(jù)都已正確到達(dá) B，B 也早已發(fā)出了確認(rèn)。但所有這些確認(rèn)都滯留在網(wǎng)絡(luò)中。在沒(méi)有收到 B 的確認(rèn)時(shí)，A 不能猜測(cè)：“或許 B 收到了吧!”為了保證可靠傳輸，A 只能認(rèn)為 B 還沒(méi)有收到這些數(shù)據(jù)。于是，A 在經(jīng)過(guò)一段時(shí)間后(由超時(shí)計(jì)時(shí)器控制)就重傳這部分?jǐn)?shù)據(jù)，重新設(shè)置超時(shí)計(jì)時(shí)器，知道收到 B 的確認(rèn)為止。如果 A 收到確認(rèn)號(hào)落在發(fā)送窗口內(nèi)，那么 A 就可以發(fā)送窗口繼續(xù)向前滑動(dòng)，并發(fā)送新的數(shù)據(jù)

緩存和窗口

發(fā)送方維持的發(fā)送緩存和發(fā)送窗口，以及接收方維持的接收緩存和接收窗口

發(fā)送緩存用來(lái)暫時(shí)存放：

發(fā)送應(yīng)用程序傳送給對(duì)方 TCP 準(zhǔn)備發(fā)送的數(shù)據(jù)

TCP 已發(fā)送出但尚未收到確認(rèn)的數(shù)據(jù)

已被確認(rèn)的數(shù)據(jù)應(yīng)當(dāng)從發(fā)送緩存中刪除，因此發(fā)送緩存和發(fā)送窗口的后沿是重合的。發(fā)送應(yīng)用程序必須控制寫(xiě)入緩存的速率，不能太快，否則發(fā)送緩存就會(huì)沒(méi)有存放數(shù)據(jù)的空間

接收緩存用來(lái)暫時(shí)存放：

按序到達(dá)的、但尚未被接收應(yīng)用程序讀取的數(shù)據(jù)

未按序到達(dá)的數(shù)據(jù)

收到的分組被檢測(cè)出有差錯(cuò)，則丟棄。接收應(yīng)用程序來(lái)不及讀取收到的數(shù)據(jù)，接收緩存最終就會(huì)被填滿，使接收窗口減小到零。接收應(yīng)用程序能夠及時(shí)從接收緩存中讀取收到的數(shù)據(jù)，接收窗口就可以增大，最大亦不能超過(guò)接收緩存的大小

要點(diǎn)小結(jié)：

雖然 A 的發(fā)送窗口是根據(jù) B 的接收窗口設(shè)置的，但在同一時(shí)刻，A 的發(fā)送窗口并不總是和 B 的接收窗口一樣大。通過(guò)網(wǎng)絡(luò)傳送窗口值需要經(jīng)歷一定的時(shí)間滯后，該時(shí)間并不確定的

對(duì)于不按序到達(dá)的數(shù)據(jù)，TCP 通常是先臨時(shí)存放在接收窗口，等字節(jié)流中所缺少的字節(jié)收到后，在按序交付上層的應(yīng)用進(jìn)程

TCP 要求接收方必須有累積確認(rèn)的功能，這樣可以減少傳輸開(kāi)銷

超時(shí)重傳時(shí)間的選擇

TCP 的發(fā)送方在規(guī)定的時(shí)間內(nèi)沒(méi)有收到確認(rèn)就要重傳已發(fā)送的報(bào)文段。這種重傳的概念是很簡(jiǎn)單的，但重傳時(shí)間的選擇卻是 TCP 最復(fù)雜的問(wèn)題之一

由于 TCP 的下層是互聯(lián)網(wǎng)環(huán)境，發(fā)送的報(bào)文段可能只經(jīng)過(guò)一個(gè)高速率的局域網(wǎng)，也可能經(jīng)過(guò)多個(gè)低速率的網(wǎng)絡(luò)，并且每個(gè) IP 數(shù)據(jù)報(bào)所選擇的路由還可能不同。如果把超時(shí)重傳時(shí)間設(shè)置得太短，就會(huì)引起很多報(bào)文段的必須要的重傳，使網(wǎng)絡(luò)負(fù)荷增大。但若把超時(shí)重傳時(shí)間設(shè)置的過(guò)長(zhǎng)，則又使網(wǎng)絡(luò)的空閑時(shí)間增大，減低了傳輸效率

TCP 采用了一種自適應(yīng)算法，它記錄一個(gè)報(bào)文段發(fā)出的時(shí)間，以及收到相應(yīng)的確認(rèn)的時(shí)間。這兩個(gè)時(shí)間之差就是報(bào)文段的往返時(shí)間 RTT

新的 RTTs = (1 - α) x (舊的 RTTs) + α x (新的 RTT 樣本)

RTT：報(bào)文段往返時(shí)間

RTTs：加權(quán)平均往返時(shí)間

α： 0 ≤ α < 1，RFC 6298 推薦的 α 值為 1/8，即 0.125

RTO = RTTs + 4 x RTTD

RTO：超時(shí)重傳時(shí)間

RTTD：RTT 的偏差的加權(quán)平均值

新的 RTTD = (1 - β) x (舊的 RTTD) + β x |RTTs - 新的 RTT 樣本|

β：小于1的系數(shù)，推薦值是 1/4，即 0.25

TCP 流量控制

利用滑動(dòng)窗口實(shí)現(xiàn)流量控制

流量控制(flow control)：讓發(fā)送方的發(fā)送速率不要太快，要讓接收方來(lái)得及接收

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

發(fā)送方的發(fā)送窗口不能超過(guò)接收方給出的接收窗口的數(shù)值。TCP 的窗口單位是字節(jié)，不是報(bào)文段

避免死鎖：TCP 為每一個(gè)連接設(shè)有一個(gè)持續(xù)計(jì)時(shí)器(persistence timer)。只要 TCP 連接的一方收到對(duì)方的零窗口通知，就啟動(dòng)持續(xù)計(jì)時(shí)器。若持續(xù)計(jì)時(shí)器設(shè)置的時(shí)間到期，就發(fā)送一個(gè)零窗口探測(cè)報(bào)文段(僅攜帶1字節(jié)的數(shù)據(jù))，而對(duì)方就在確認(rèn)這個(gè)探測(cè)報(bào)文段時(shí)給出了現(xiàn)在的窗口值。如果窗口仍是零，那么收到這個(gè)報(bào)文段的一方就重新設(shè)置持續(xù)計(jì)時(shí)器。如果窗口不是零，那么死鎖的僵局就可以打破了

TCP 的傳輸效率

發(fā)送機(jī)制

TCP 維持一個(gè)變量，它等于最大報(bào)文段長(zhǎng)度 MSS。只要緩存中存放的數(shù)據(jù)達(dá)到 MSS 字節(jié)時(shí)，就組裝成一個(gè) TCP 報(bào)文段發(fā)送出去

由發(fā)送方的應(yīng)用進(jìn)程指明要求發(fā)送報(bào)文段，即 TCP 支持的推送(push)操作

發(fā)送方的一個(gè)計(jì)時(shí)器期限到了，這時(shí)把當(dāng)前已有的緩存數(shù)據(jù)裝入報(bào)文段(但長(zhǎng)度不能超過(guò) MSS)發(fā)送出去

Nagle 算法

在 TCP 的實(shí)現(xiàn)中廣泛使用 Nagle 算法

若發(fā)送應(yīng)用進(jìn)程把要發(fā)送的數(shù)據(jù)逐個(gè)字節(jié)地送到 TCP 的發(fā)送緩存，則發(fā)送方就把第一個(gè)數(shù)據(jù)字節(jié)先發(fā)送出去，把后面到達(dá)的數(shù)據(jù)字節(jié)都緩存起來(lái)。當(dāng)發(fā)送方收到對(duì)第一個(gè)數(shù)據(jù)字符的確認(rèn)后，再把發(fā)送緩存中的所有數(shù)據(jù)組裝成一個(gè)報(bào)文段發(fā)送出去，同時(shí)繼續(xù)對(duì)隨后到達(dá)的數(shù)據(jù)進(jìn)行緩存。只有在收到對(duì)前一個(gè)報(bào)文段的確認(rèn)后才繼續(xù)發(fā)送下一個(gè)報(bào)文段。當(dāng)數(shù)據(jù)達(dá)到較快而網(wǎng)絡(luò)速率較慢時(shí)，用這樣的方法可明顯地減少所用的網(wǎng)絡(luò)寬帶。Nagle 算法還規(guī)定，當(dāng)?shù)竭_(dá)的數(shù)據(jù)已達(dá)到發(fā)送窗口大小的一半或已達(dá)到報(bào)文段的最大長(zhǎng)度時(shí)，就立即發(fā)送一個(gè)報(bào)文段。這樣可以有效提高網(wǎng)絡(luò)的吞吐量

糊涂窗口綜合征

TCP 接收方的緩存已滿，僅剩一個(gè)字節(jié)，并還將保持這種狀態(tài)持續(xù)一段時(shí)間。導(dǎo)致發(fā)送方只能發(fā)送一個(gè)字節(jié)。導(dǎo)致網(wǎng)絡(luò)的效率很低

為了解決這個(gè)問(wèn)題，可以讓接收方等待一段時(shí)間，使得或者接受緩存已有足夠空間容納一個(gè)最長(zhǎng)的報(bào)文段，或者等到接受緩存已有一半空閑的空間。只要出現(xiàn)這兩種情況之一，接收方就發(fā)出確認(rèn)報(bào)文，并向發(fā)送方通知當(dāng)前的窗口大小。發(fā)送方也不要發(fā)送大小的報(bào)文段，而是把數(shù)據(jù)積累成足夠大的報(bào)文段，或達(dá)到接收方緩存的空間的一半大小

TCP 的擁塞控制

擁塞控制的一般原理

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

擁塞控制就是防止過(guò)多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，這樣可以使網(wǎng)絡(luò)中的路由器或鏈路不致過(guò)載。擁塞控制所要做的都是一個(gè)前提，就是網(wǎng)絡(luò)能夠承受現(xiàn)有的網(wǎng)絡(luò)負(fù)荷

TCP 的擁塞控制方法

TCP 進(jìn)行擁塞控制的算法有四種，即慢開(kāi)始(slow-start)、擁塞避免(congestion avoidance)、快重傳(fast retransmit)和快恢復(fù)(fast recovery)

慢開(kāi)始

當(dāng)主機(jī)開(kāi)始發(fā)送數(shù)據(jù)時(shí)，由于并不清楚網(wǎng)絡(luò)的負(fù)荷情況，如果立即把大量數(shù)據(jù)字節(jié)注入到網(wǎng)絡(luò)，就有可能引起網(wǎng)絡(luò)發(fā)生擁塞。經(jīng)驗(yàn)證明，較好的方法是先探測(cè)一下，即由小到大逐漸增大發(fā)送窗口，也就是說(shuō)，由小到大逐漸增大擁塞窗口數(shù)值

cwnd：發(fā)送方的擁塞窗口，開(kāi)始發(fā)送方設(shè)置 cwnd = 1

擁塞避免

讓擁塞窗口 cwnd 緩慢地增大，即每經(jīng)過(guò)一個(gè)往返時(shí)間 RTT 就把發(fā)送方的擁塞窗口 cwnd 加1，而不是像慢開(kāi)始階段那樣加倍增加。因此在擁塞避免階段就有“加法增大” AI(Additive Increase)的特點(diǎn)。這表明在擁塞避免階段，擁塞窗口 cwnd 按線性規(guī)律緩慢增長(zhǎng)，比慢開(kāi)始算法的擁塞窗口增長(zhǎng)速率緩慢得多

“擁塞避免”并非完全能夠避免擁塞，而是把擁塞窗口控制為按線性規(guī)律增長(zhǎng)，使網(wǎng)絡(luò)比較不容易出現(xiàn)擁塞

在執(zhí)行慢開(kāi)始算法時(shí)，發(fā)送方每收到一個(gè)隊(duì)新報(bào)文段的確認(rèn) ACK，就把擁塞窗口值加1，然后開(kāi)始下一輪的傳輸。因此擁塞窗口 cwnd 隨著傳輸輪次按指數(shù)規(guī)律增長(zhǎng)。當(dāng)擁塞窗口 cwnd 增長(zhǎng)到慢開(kāi)始門限值 ssthresh 時(shí)，就改成執(zhí)行擁塞避免算法，擁塞窗口按線性規(guī)律增長(zhǎng)

ssthresh：慢開(kāi)始門限，一般的，會(huì)有一個(gè)初始值，下圖中為16個(gè)報(bào)文段

當(dāng)擁塞窗口 cwnd = 24 時(shí)，網(wǎng)絡(luò)出現(xiàn)了超時(shí)，發(fā)送方判斷為網(wǎng)絡(luò)擁塞。于是調(diào)整門限值 ssthresh = cwnd / 2 = 12，同時(shí)設(shè)置擁塞窗口 cwnd = 1，進(jìn)入慢開(kāi)始階段

快重傳

采用快重傳算法可以讓發(fā)送方盡早知道發(fā)生了個(gè)別報(bào)文段的丟失。快重傳算法首先要求接收方不要等待自己發(fā)送數(shù)據(jù)時(shí)才進(jìn)行捎帶確認(rèn)，而是要立即發(fā)送確認(rèn)，即使收到了失序的報(bào)文段也要立即發(fā)出對(duì)已收到的報(bào)文段的重復(fù)確認(rèn)

快恢復(fù)

發(fā)送發(fā)知道當(dāng)前只是丟失了個(gè)別的報(bào)文段。于是不啟動(dòng)慢開(kāi)始，而是執(zhí)行快恢復(fù)算法。這時(shí)，發(fā)送方調(diào)整門限值 ssthresh = cwnd / 2 = 8，同時(shí)設(shè)置擁塞窗口 cwnd = ssthresh = 8，并開(kāi)始執(zhí)行擁塞避免算法

TCP Reno 版本：區(qū)別于老的 TCP Tahao 版本

TCP 的運(yùn)輸連接管理

TCP 是面向連接的協(xié)議。運(yùn)輸連接是用來(lái)傳送 TCP 報(bào)文的。TCP 運(yùn)輸連接的建立和釋放是每一次面向連接的通信中必不可少的過(guò)程。運(yùn)輸連接有三個(gè)階段，連接建立、數(shù)據(jù)傳送和連接釋放。運(yùn)輸?shù)倪B接管理就是使運(yùn)輸連接的建立和釋放都能夠正常地進(jìn)行

在 TCP 連接建立過(guò)程中要解決以下三個(gè)問(wèn)題：

要使每一方能夠確知對(duì)方的存在

要允許雙方協(xié)商一些參數(shù)(最大窗口值、是否使用窗口擴(kuò)大選項(xiàng)和時(shí)間戳選項(xiàng)以及服務(wù)質(zhì)量等)

能夠?qū)\(yùn)輸實(shí)體資源(緩存大小、連接表中的項(xiàng)目等)進(jìn)行分配

TCP 的連接建立

TCP 建立連接的過(guò)程叫做握手，握手需要在客戶和服務(wù)器之間交換三個(gè) TCP 報(bào)文段

連接建立過(guò)程

最初客戶/服務(wù)器的 TCP 進(jìn)程都處于 CLOSED(關(guān)閉)狀態(tài)。在本實(shí)例中，A 主動(dòng)打開(kāi)連接，而 B 被動(dòng)打開(kāi)連接

B 的 TCP 服務(wù)器進(jìn)程先創(chuàng)建傳輸控制塊 TCB，并處于 LISTEN(收聽(tīng)) 狀態(tài)，等待客戶的連接請(qǐng)求

A 的 TCP 客戶進(jìn)程創(chuàng)建傳輸控制模塊 TCB。并向 B 發(fā)出連接請(qǐng)求報(bào)文段，首部中的同部位 SYN = 1，選擇一個(gè)初始序號(hào) seq = x。TCP 客戶端進(jìn)程進(jìn)入 SYN-SENT(同步已發(fā)送) 狀態(tài)。TCP 規(guī)定，SYN 報(bào)文段(即 SYN = 1 的報(bào)文段)不能攜帶數(shù)據(jù)，但要消耗一個(gè)序號(hào)

B 收到連接請(qǐng)求報(bào)文段后，如同意建立連接，則向 A 發(fā)送確認(rèn)。在確認(rèn)報(bào)文段中應(yīng)把 SYN 位和 ACK 位都置1，確認(rèn)號(hào)是 ack = x + 1，同時(shí)也為自己選擇一個(gè)初始序號(hào) seq = y。這時(shí) TCP 服務(wù)器進(jìn)程進(jìn)入 SYN-RCVD(同步收到) 狀態(tài)。這個(gè)報(bào)文段也不能攜帶數(shù)據(jù)，但同樣要消耗掉一個(gè)序號(hào)

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 狀態(tài)

傳輸控制塊 TCB(Transmission Control Block)存儲(chǔ)了每一個(gè)連接中的一些重要信息，如：TCP 連接表，指向發(fā)送和接收緩存的指針，指向重傳隊(duì)列的指針，當(dāng)前的發(fā)送和接收序號(hào)等等

四報(bào)文握手

B 發(fā)送給 A 的報(bào)文段，可拆成兩個(gè)報(bào)文段。先發(fā)送一個(gè)確認(rèn)報(bào)文段(ACK = 1，ack = x + 1)，然后再發(fā)送一個(gè)同步報(bào)文段(SYN = 1，seq = y)。這樣的過(guò)程就變成了四報(bào)文握手，與三報(bào)文握手效果一致

異常情況

為什么 A 最后還要發(fā)送一次確認(rèn)呢？這主要是為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳到了 B，因而產(chǎn)生錯(cuò)誤

正常情況：A 發(fā)出連接請(qǐng)求，但因連接請(qǐng)求報(bào)文丟失而未收到確認(rèn)。于是 A 再重傳一次連接請(qǐng)求。后來(lái)收到了確認(rèn)，建立了連接。數(shù)據(jù)傳輸完畢后，就釋放了連接。A 共發(fā)送了兩個(gè)連接請(qǐng)求報(bào)文段，其中第一個(gè)丟失，第二個(gè)到達(dá)了 B，沒(méi)有“已失效的連接請(qǐng)求報(bào)文段”

異常情況：A 發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒(méi)有丟失，而是在某些網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá) B。本來(lái)這是一個(gè)早已失效的報(bào)文段。但 B 收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是 A 又發(fā)出一次新的連接請(qǐng)求。于是就向 A 發(fā)出確認(rèn)報(bào)文段，同意建立連接。假定不采用報(bào)文握手，那么只要 B 發(fā)出確認(rèn)，新的連接就建立了。

現(xiàn)在 A 并沒(méi)有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬 B 的確認(rèn)，也不會(huì)向 B 發(fā)送數(shù)據(jù)。但 B 卻以為新的運(yùn)輸連接已經(jīng)建立了，并一直等待 A 發(fā)來(lái)數(shù)據(jù)。B 的許多資源就這樣被浪費(fèi)了。

采用三報(bào)文握手的辦法，可以防止上述現(xiàn)象的發(fā)生

TCP 的連接釋放

連接釋放過(guò)程

A 的應(yīng)用進(jìn)程先向其 TCP 發(fā)出連接釋放報(bào)文段，并停止再發(fā)送數(shù)據(jù)，主動(dòng)關(guān)閉 TCP 連接。A 把連接釋放報(bào)文段首部的終止控制位 FIN 置1，其序號(hào) seq = u，它等于前面已傳送過(guò)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加1。這時(shí) A 進(jìn)入 FIN-WAIT-1(終止等待1) 狀態(tài)，等待 B 的確認(rèn)。TCP 規(guī)定，FIN 報(bào)文段即使不攜帶數(shù)據(jù)，也消耗一個(gè)序號(hào)

B 收到連接釋放報(bào)文段后即發(fā)出確認(rèn)，確認(rèn)號(hào)是 ack = u + 1，而這個(gè)報(bào)文段自己的序號(hào)是 v，等于 B 前面已傳送過(guò)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加1。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)閉(half-close) 狀態(tài)，即 A 已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了，但 B 若發(fā)送數(shù)據(jù)，A 仍要接收。也就是說(shuō)，從 B 到 A 這個(gè)方向的連接并未關(guān)閉，這個(gè)狀態(tài)可能會(huì)持續(xù)一段時(shí)間

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

若 B 已經(jīng)沒(méi)有要向 A 發(fā)送的數(shù)據(jù)，其應(yīng)用進(jìn)程就通知 TCP 釋放連接。這時(shí) B 發(fā)出的連接釋放報(bào)文段必須使 FIN = 1。現(xiàn)假定 B 的序號(hào)為 w(在半關(guān)閉狀態(tài) B 可能又發(fā)送了一些數(shù)據(jù))。B 還必須重復(fù)上次已發(fā)送過(guò)的確認(rèn)號(hào) ack = u + 1。這時(shí) B 就進(jìn)入 LAST-ACK(最后確認(rèn))狀態(tài)，等待 A 的確認(rèn)

A 在收到 B 的連接釋放報(bào)文段后，必須對(duì)此發(fā)出確認(rèn)。在確認(rèn)報(bào)文段中把 ACK 置1，確認(rèn)號(hào) ack = w + 1，而自己的序號(hào)是 seq = u + 1(根據(jù) TCP 標(biāo)準(zhǔn)，前面發(fā)送過(guò)的 FIN 報(bào)文段要消耗一個(gè)序號(hào))。然后進(jìn)入到 TIME-WAIT(時(shí)間等待)狀態(tài)。此時(shí) TCP 連接還沒(méi)有釋放掉。必須經(jīng)過(guò)時(shí)間等待計(jì)時(shí)器(TIME-WAIT timer)設(shè)置的時(shí)間2MSL后，A 才進(jìn)入到 CLOSED 狀態(tài)

當(dāng) A 撤銷相應(yīng)的傳輸控制塊 TCB 后，就結(jié)束了這次的 TCP 連接

時(shí)間 MSL 叫做最長(zhǎng)報(bào)文段壽命(Maximum Segment Lifetime)，RFC 793建議設(shè)為2分鐘。但這完全是從工程上來(lái)考慮的，對(duì)于現(xiàn)在的網(wǎng)絡(luò)，MSL = 2分鐘可能太長(zhǎng)了一些

TIME-WAIT 等待時(shí)間

為什么 A 在 TIME-WAIT 狀態(tài)必須等待 2MSL 的時(shí)間呢？

為了保證 A 發(fā)送的最后一個(gè) ACK 報(bào)文段能夠到達(dá) B。這個(gè) ACK 報(bào)文段有可能丟失，因而使處在 LAST-ACK 狀態(tài)的 B 收不到對(duì)已發(fā)送的 FIN + ACK 報(bào)文段的確認(rèn)。B 會(huì)超時(shí) 重傳這個(gè) FIN + ACK 報(bào)文段，而 A 就能在 2MSL 時(shí)間內(nèi)收到這個(gè)重傳的 FIN + ACK 報(bào)文段。接著 A 重傳一次確認(rèn)，重新啟動(dòng) 2MSL 計(jì)時(shí)器。最后，A 和 B 都正常進(jìn)入到 CLOSED 狀態(tài)。如果 A 在 TIME-WAIT 狀態(tài)不等待一段時(shí)間，而是在發(fā)完 ACK 報(bào)文段后立即釋放連接，那么就無(wú)法收到 B 重傳的 FIN + ACK 報(bào)文段，因而也不會(huì)再發(fā)送一次確認(rèn)報(bào)文段。這樣，B 就無(wú)法安裝正常步驟進(jìn)入 CLOSED 狀態(tài)

防止前面提到的“已失效的連接請(qǐng)求報(bào)文段”出現(xiàn)在本連接中。A 在發(fā)送完最后一個(gè) ACK 報(bào)文段后，再經(jīng)過(guò)時(shí)間 2MSL，就可以使本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失。這樣就可以使下一個(gè)新的連接中不會(huì)出現(xiàn)這種舊的連接請(qǐng)求報(bào)文段

B 只要收到 A 發(fā)出的確認(rèn)，就進(jìn)入 CLOSED 狀態(tài)。同樣，B 在撤銷相應(yīng)的傳輸控制 TCB 后，就結(jié)束了這次的 TCP 連接。B 結(jié)束 TCP 連接的時(shí)間要比 A 早一些

保活計(jì)時(shí)器(keepalive timer)：服務(wù)器每收到一次客戶的數(shù)據(jù)，就重新設(shè)置保活計(jì)時(shí)器，時(shí)間的設(shè)置通常是兩小時(shí)。若兩小時(shí)沒(méi)有收到客戶的數(shù)據(jù)，服務(wù)器就發(fā)送一個(gè)探測(cè)報(bào)文段，以后則每隔75秒發(fā)送一次。若一連發(fā)送10個(gè)探測(cè)報(bào)文段后仍無(wú)客戶的響應(yīng)，服務(wù)器就認(rèn)為客戶端出了故障，接著就關(guān)閉這個(gè)連接

TCP 的有限狀態(tài)機(jī)

為了更清晰地看出 TCP 連接的各種狀態(tài)之間的關(guān)系，下圖為 TCP 的有限狀態(tài)機(jī)。圖中每一個(gè)方框即 TCP 可能具有的狀態(tài)。每個(gè)方框中的大寫(xiě)英文字符串是 TCP 標(biāo)準(zhǔn)所使用的 TCP 連接狀態(tài)名。狀態(tài)之間的箭頭表示可能發(fā)生的狀態(tài)變遷。箭頭旁邊的字，表明引起這種變遷的原因，或表明發(fā)生狀態(tài)變遷后又出現(xiàn)什么動(dòng)作。請(qǐng)注意圖中有三種不同的箭頭。粗實(shí)線箭頭表示對(duì)客戶進(jìn)程的正常變遷。粗虛線箭頭表示對(duì)服務(wù)器進(jìn)程的正常變遷。另一種細(xì)線箭頭表示異常變遷

總結(jié)

以上是生活随笔為你收集整理的mysql协议重传_TCP协议详解的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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