目錄

1.TCP相關(guān)機(jī)制

2.TCP首部格式

1.TCP三次握手

1.TCP四次揮手

一.TCP相關(guān)機(jī)制

TCP通過檢驗(yàn)和、序列號、確認(rèn)應(yīng)答、重發(fā)控制、連接管理以及窗口控制等機(jī)制實(shí)現(xiàn)可靠性傳輸。

1.確認(rèn)應(yīng)答

在TCP中，當(dāng)發(fā)送端的數(shù)據(jù)到達(dá)接收主機(jī)時，接收端主機(jī)會返回一 個已收到消息的通知。這個消息叫做確認(rèn)應(yīng)答（ACK（Positive Acknowled-gement）意指已經(jīng)接收。）
TCP通過肯定的ACK實(shí)現(xiàn)可靠的數(shù)據(jù)傳輸。當(dāng)發(fā)送端將數(shù)據(jù)發(fā)出之后會等待對端的確認(rèn)應(yīng)答。如果有確認(rèn)應(yīng)答，說明數(shù)據(jù)已經(jīng)成功到達(dá)對端。反之，則數(shù)據(jù)丟失的可能性很大。在一定時間內(nèi)沒有等到確認(rèn)應(yīng)答，發(fā)送端就可以認(rèn)為數(shù)據(jù)已經(jīng)丟失，并進(jìn)行重發(fā)。

注意：未收到確認(rèn)應(yīng)答并不意味著數(shù)據(jù)一定丟失。也有可能是數(shù)據(jù)對方已經(jīng)收到，只是返回的確認(rèn)應(yīng)答在途中丟失。這種情況也會導(dǎo)致發(fā)送端因沒有收到確認(rèn)應(yīng)答，而認(rèn)為數(shù)據(jù)沒有到達(dá)目的地，從而進(jìn)行重新發(fā)送。但是對于目標(biāo)主機(jī)來說，這簡直是一種“災(zāi)難”。它會反復(fù)收到相同的數(shù)據(jù)。而為了對上層應(yīng)用提供可靠的傳輸，必須得放棄重復(fù)的數(shù)據(jù)包。為此，就必須引入一種機(jī)制，它能夠識別是否已經(jīng)接收數(shù)據(jù)，又能夠判斷是否需要接收。

2.序列號

上述這些確認(rèn)應(yīng)答處理、重發(fā)控制以及重復(fù)控制等功能都可以通過序列號實(shí)現(xiàn)。序列號是按順序給發(fā)送數(shù)據(jù)的每一個字節(jié)（8位字節(jié)）都標(biāo)上號碼的編號（序列號的初始值并非為0。而是在建立連接以后由隨 機(jī)數(shù)生成。而后面的計算則是對每一字節(jié)加一） 。接收端查詢接收數(shù)據(jù)TCP首部中的序列號和數(shù)據(jù)的長度，將自己下一步應(yīng)該接收的序號作為確認(rèn)應(yīng)答返送回去。就這樣，通過序列號和確認(rèn)應(yīng)答號，TCP可以實(shí)現(xiàn)可靠傳輸。

TCP的數(shù)據(jù)長度并未寫入TCP首部。實(shí)際通信中求得TCP包的長度的計算公式是：IP首部中的數(shù)據(jù)包長度-IP首部長度TCP首部長度。

3.重發(fā)超時

重發(fā)超時是指在重發(fā)數(shù)據(jù)之前，等待確認(rèn)應(yīng)答到來的那個特定時間間隔。如果超過了這個時間仍未收到確認(rèn)應(yīng)答，發(fā)送端將進(jìn)行數(shù)據(jù)重發(fā)。那么這個重發(fā)超時的具體時間長度又是如何確定的呢？

最理想的是，找到一個最小時間，它能保證“確認(rèn)應(yīng)答一定能在這個時間內(nèi)返回”。然而這個時間長短隨著數(shù)據(jù)包途徑的網(wǎng)絡(luò)環(huán)境的不同而有所變化。TCP要求不論處在何種網(wǎng)絡(luò)環(huán)境下都要提供高性能通信，并且無論網(wǎng)絡(luò)擁堵情況發(fā)生何種變化，都必須保持這一特性。為此，它在每次發(fā)包時都會計算往返時間（Round Trip Time也叫RTT。是指報文段的往返時間。） 及其偏差（RTT時間波動的值、方差。有時也叫抖動。） 。將這個往返時間和偏差相加。

數(shù)據(jù)也不會被無限、反復(fù)地重發(fā)。達(dá)到一定重發(fā)次數(shù)之后，如果仍沒有任何確認(rèn)應(yīng)答返回，就會判斷為網(wǎng)絡(luò)或?qū)Χ酥鳈C(jī)發(fā)生了異常，強(qiáng)制關(guān)閉連接。并且通知應(yīng)用通信異常強(qiáng)行終止。

4.連接管理

TCP提供面向有連接的通信傳輸。面向有連接是指在數(shù)據(jù)通信開始之前先做好通信兩端之間的準(zhǔn)備工作。它會在數(shù)據(jù)通信之前，通過TCP首部發(fā)送一個SYN包作為建立連接的請求等待確認(rèn)應(yīng)答（TCP中發(fā)送第一個SYN包的一方叫做客戶端，接收這個的一方叫做服務(wù)端。） 如果對端發(fā)來確認(rèn)應(yīng)答，則認(rèn)為可以進(jìn)行數(shù)據(jù)通信。如果對端的確認(rèn)應(yīng)答未能到達(dá)，就不會進(jìn)行數(shù)據(jù)通信。此外，在通信結(jié)束時會進(jìn)行斷開連接的處理（通過發(fā)送FIN包）。

可以使用TCP首部用于控制的字段來管理TCP連接（也叫控制域） 。一個連接的建立與斷開，正常過程至少需要來回發(fā)送7個包才能完成（“三次握手”、“四次揮手”） 。

MSS

在建立TCP連接的同時，也可以確定發(fā)送數(shù)據(jù)包的單位，我們也可以稱其為“最大消息長度”（MSS：Maximum Segment Size）。最理想的情況是，最大消息長度正好是IP中不會被分片處理的最大數(shù)據(jù)長度。

TCP在傳送大量數(shù)據(jù)時，是以MSS的大小將數(shù)據(jù)進(jìn)行分割發(fā)送。進(jìn)行重發(fā)時也是以MSS為單位。 MSS是在三次握手的時候，在兩端主機(jī)之間被計算得出。兩端的主機(jī)在發(fā)出建立連接的請求時，會在TCP首部中寫入MSS選項(xiàng)，告訴對方自己的接口能夠適應(yīng)的MSS的大小。（為附加MSS選項(xiàng)，TCP首部將不再是20字節(jié)，而是4字節(jié)的整數(shù)倍。）

5.窗口控制

TCP以1個段為單位，每發(fā)一個段進(jìn)行一次確認(rèn)應(yīng)答的處理這樣的傳輸方式有一個缺點(diǎn)。那就是包的往返時間越長通信性能就越低。為解決這個問題，TCP引入了窗口這個概念。即使在往返時間較長的情況下，它也能控制網(wǎng)絡(luò)性能的下降。確認(rèn)應(yīng)答不再是以每個分段，而是以更大的單位進(jìn)行確認(rèn)，轉(zhuǎn)發(fā)時間將會被大幅度的縮短。也就是說，發(fā)送端主機(jī)，在發(fā)送了一個段以后不必要一直等待確認(rèn)應(yīng)答，而是繼續(xù)發(fā)送。

窗口大小就是指無需等待確認(rèn)應(yīng)答而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值。這個機(jī)制實(shí)現(xiàn)使用大量的緩沖區(qū)。

TCP提供一種機(jī)制可以讓發(fā)送端根據(jù)接收端的實(shí)際接收能力控制發(fā)送的數(shù)據(jù)量。這就是所謂的流控制。它的具體操作是，接收端主機(jī)向發(fā)送端主機(jī)通知自己可以接收數(shù)據(jù)的大小，于是發(fā)送端會發(fā)送不超過這個限度的數(shù)據(jù)。該大小限度就被稱作窗口大小。窗口大小的值就是由接收端主機(jī)決定的。 TCP首部中，專門有一個字段用來通知窗口大小。接收主機(jī)將自己可以接收的緩沖區(qū)大小放入這個字段中通知給發(fā)送端。這個字段的值越大，說明網(wǎng)絡(luò)的吞吐量越高。

收到確認(rèn)應(yīng)答的情況下，將窗口滑動到確認(rèn)應(yīng)答中的序列號的位置。這樣可以順序地將多個段同時發(fā)送提高通信性能。這種機(jī)制也被稱為滑動窗口控制。

窗口控制下的重發(fā)控制

重發(fā)的情況就兩種：一種是數(shù)據(jù)收到了，應(yīng)答沒有收到，第二種是數(shù)據(jù)沒有收到。

先考慮確認(rèn)應(yīng)答未能返回的情況。在這種情況下，數(shù)據(jù)已經(jīng)到達(dá)對端，是不需要再進(jìn)行重發(fā)的。然而，在沒有使用窗口控制的時候，沒有收到確認(rèn)應(yīng)答的數(shù)據(jù)都會被重發(fā)。

其次，考慮一下某個報文段丟失的情況。當(dāng)某一報文段丟失后，發(fā)送端會一直收到序號為1001的確認(rèn)應(yīng)答，這個確認(rèn)應(yīng)答好像在提醒發(fā)送端“我想接收的是從1001開始的數(shù)據(jù)”。因此，在窗口比較大，又出現(xiàn)報文段丟失的情況 下，同一個序號的確認(rèn)應(yīng)答將會被重復(fù)不斷地返回。而發(fā)送端主機(jī)如果連續(xù)3次收到同一個確認(rèn)應(yīng)答（之所以連續(xù)收到3次而不是兩次的理由是因?yàn)椋词箶?shù)據(jù)段的序號被替換兩次也不會觸發(fā)重發(fā)機(jī)制。） ，就會將其所對應(yīng)的數(shù)據(jù)進(jìn)行重發(fā)。這種機(jī)制比之前提到的超時管理更加高效，因此也被稱作高速重發(fā)控制。

接收端如果沒有收到自己所期望的數(shù)據(jù)時，會將之前收到的數(shù)據(jù)進(jìn)行確認(rèn)應(yīng)答，發(fā)送端一旦連續(xù)3次收到相同的確認(rèn)應(yīng)答，就會進(jìn)行數(shù)據(jù)的重發(fā)。

擁塞控制

有了TCP的窗口控制，收發(fā)主機(jī)之間即使不再以一個數(shù)據(jù)段為單位發(fā)送確認(rèn)應(yīng)答，也能夠連續(xù)發(fā)送大量數(shù)據(jù)包。然而，如果在通信剛開始時就發(fā)送大量數(shù)據(jù)，也可能會引發(fā)其他問題。 一般來說，計算機(jī)網(wǎng)絡(luò)都處在一個共享的環(huán)境。因此也有可能會因?yàn)槠渌鳈C(jī)之間的通信使得網(wǎng)絡(luò)擁堵。在網(wǎng)絡(luò)出現(xiàn)擁堵時，如果突然發(fā)送一個較大量的數(shù)據(jù)，極有可能會導(dǎo)致整個網(wǎng)絡(luò)的癱瘓。 TCP為了防止該問題的出現(xiàn)，在通信一開始時就會通過一個叫做慢啟動的算法得出的數(shù)值，對發(fā)送數(shù)據(jù)量進(jìn)行控制。

此外，TCP中為了提高網(wǎng)絡(luò)的利用率，經(jīng)常使用一個叫做Nagle的算法。

二.TCP首部格式

TCP數(shù)據(jù)段格式

• 源端口號：表示發(fā)送端端口號，字段長16位。

• 目標(biāo)端口號：表示接收端端口號，字段長度16位。

• 序列號：字段長32位。序列號是指發(fā)送數(shù)據(jù)的位置。每發(fā)送一次數(shù)據(jù)，就累加一次該數(shù)據(jù)字節(jié)數(shù)的大小（用來標(biāo)記數(shù)據(jù)段的順序）。序列號不會從0或1開始，而是在建立連接時由計算機(jī)生成的隨機(jī)數(shù)作為其初始值，通過SYN包傳給接收端主機(jī)。然后再將每轉(zhuǎn)發(fā)過去的字節(jié)數(shù)累加到初始值上表示數(shù)據(jù)的位置。此外，在建立連接和斷開連接時發(fā)送的SYN包和FIN包雖然并不攜帶數(shù)據(jù)，但是也會作為一個字節(jié)增加對應(yīng)的序列號。

• 確認(rèn)應(yīng)答號：字段長度32位。是指下一次應(yīng)該收到的數(shù)據(jù)的序列號。 實(shí)際上，它是指已收到確認(rèn)應(yīng)答號減一為止的數(shù)據(jù)。發(fā)送端收到這個確認(rèn)應(yīng)答以后可以認(rèn)為在這個序號以前的數(shù)據(jù)都已經(jīng)被正常接收。因此當(dāng)前報文段最后一個字節(jié)的編號+1即為確認(rèn)應(yīng)答號。

• 數(shù)據(jù)偏移：該字段表示TCP所傳輸?shù)臄?shù)據(jù)部分應(yīng)該從TCP包的哪個位開始計算，當(dāng)然也可以把它看作TCP首部的長度。該字段長4位，單位為4字節(jié)。（比如該值為4就表示TCP所傳輸?shù)臄?shù)據(jù)從16個字節(jié)的地方開始）；如果不包括選項(xiàng)字段的話，此數(shù)據(jù)偏移字段可以設(shè)置為5。反之，如果該字段的值為5，那說明從TCP包的最一開始到20字節(jié)為止都是TCP首部，余下的部分為TCP數(shù)據(jù)。

• 保留：該字段主要是為了以后擴(kuò)展時使用，其長度為4位，一般設(shè)置為0。

• 窗口大小：該字段長為16位。用于通知從相同TCP首部的確認(rèn)應(yīng)答號所指位置開始能夠接收的數(shù)據(jù)大小TCP不允許發(fā)送超過此處所示大小的數(shù)據(jù)。不過，如果窗口為0，則表示可以發(fā)送窗口探測，以了解最新的窗口大小。

• 緊急指針： 該字段長為16位。只有在URG控制位為1時有效。該字段的數(shù)值表示本報文段中緊急數(shù)據(jù)的指針。

• 選項(xiàng)：用于提高TCP的傳輸性能。

控制位

字段長為8位，每一位從左至右分別為CWR、ECE、URG、ACK、 PSH、RST、SYN、FIN。這些控制標(biāo)志也叫做控制位。

• CWR（Congestion Window Reduced：擁塞窗口減少）： CWR標(biāo)志與后面的ECE標(biāo)志都用于IP首部的ECN字段。ECE標(biāo)志為1時，則通知對方已將擁塞窗口縮小。

• ECE：表示ECNEcho。置為1會通知通信對方，從對方到這邊的網(wǎng)絡(luò)有擁塞。在收到數(shù)據(jù)包的IP首部中ECN為1時將TCP首部中的ECE設(shè)置為1。

校驗(yàn)和

TCP和UDP一樣在計算校驗(yàn)和的時候使用TCP偽首部。為了讓其全長為16位的整數(shù)倍，需要在數(shù)據(jù)部分的最后填充0。首先將TCP校驗(yàn)和字段設(shè)置為0。然后以16位為單位進(jìn)行1的補(bǔ)碼和計算，再將它們總和的1的補(bǔ)碼和放入校驗(yàn)和字段。 接收端在收到TCP數(shù)據(jù)段以后，從IP首部獲取IP地址信息構(gòu)造TCP 偽首部，再進(jìn)行校驗(yàn)和計算。由于校驗(yàn)和字段里保存著除本字段以外其 他部分的和的補(bǔ)碼值，因此如果計算校驗(yàn)和字段在內(nèi)的所有數(shù)據(jù)的16位和以后，得出的結(jié)果是“16位全部為1（1的補(bǔ)碼中該值為0（負(fù)數(shù)0）、 二進(jìn)制中為1111111111111111，十六進(jìn)制中為FFFF，十進(jìn)制中則為正整 數(shù)65535。） ”說明所收到的數(shù)據(jù)是正確的。

三.TCP三次握手

首先需要清楚的一點(diǎn)，不論握手多少次都不能確認(rèn)一條信道一定是“可靠”的，但通過3次握手可以至少確認(rèn)它是“可用”的，再往上加握手次數(shù)不過是提高它是“可用”的這個結(jié)論的可信度。也就是說任意次的握手都是“不可靠”的，握手成功只能說明握手時的通信是正常的，并不能保證握手后的通信是正常的。握手只能保證盡可能的可靠，而不可能保證絕對可靠。

TCP通過三次握手來建立可靠的連接。

三次握手示意圖

第一次握手：

客戶端向服務(wù)端發(fā)送連接請求報文段。該報文段的頭部中SYN=1，ACK=0，同時選擇一個初始序號seq=x。請求發(fā)送后，客戶端便進(jìn)入SYN-SENT狀態(tài)。

第二次握手：

服務(wù)端收到連接請求報文段后，如果同意連接，會發(fā)送一個應(yīng)答：SYN=1，ACK=1，seq=y，ack=x+1。發(fā)送完應(yīng)答后服務(wù)端進(jìn)入SYN-RCVD狀態(tài)。

第三次握手：

客戶端收到服務(wù)端連接同意的應(yīng)答后，還會向服務(wù)端發(fā)送一個確認(rèn)報文段，表示：服務(wù)端發(fā)來的連接同意應(yīng)答已經(jīng)成功收到。該報文段的頭部為：ACK=1，seq=x+1，ack=y+1。該報文發(fā)送完畢后，客戶端和服務(wù)器端都進(jìn)入ESTABLISHED狀態(tài)，完成TCP三次握手。

相關(guān)問題

1.為什么是三次握手，而不是兩次或四次？

為什么不是兩次握手：是為了防止已失效的連接請求報文段突然又傳送到了服務(wù)端，造成服務(wù)端資源的浪費(fèi)。

在一次TCP連接中，客戶端A向服務(wù)端B發(fā)送連接請求SYN報文段，假如這個報文段沒有及時被服務(wù)端B接收，而是滯留在網(wǎng)絡(luò)的某處，于是客戶端A超時重傳，再次發(fā)送請求連接并且順利與服務(wù)端B建立了連接，交換數(shù)據(jù)后斷開連接。滯留在網(wǎng)絡(luò)中的某處的陳舊報文就變成了失效的連接請求報文。

但如果這個失效的請求SYN報文段，現(xiàn)在又突然傳送到了服務(wù)端B處，設(shè)想這時是使用兩次握手而不是三次握手，服務(wù)端B就以為客戶端A現(xiàn)在建立請求連接，于是服務(wù)端B發(fā)出確認(rèn)，新的連接就建立了，服務(wù)端B分配資源，等待客戶端A傳送數(shù)據(jù)，但客戶端A并沒有想要建立TCP連接，不會理會服務(wù)端B發(fā)送的應(yīng)答，也不會向服務(wù)端B傳送數(shù)據(jù)，于是服務(wù)端B就白白等待，空耗資源。

使用三次握手可以避免這個情況。服務(wù)端B收到客戶端A的失效的陳舊SYN報文段，向客戶端A發(fā)送SYN報文段，選擇自己的序號seq=y，確認(rèn)收到客戶端A的SYN報文段，確認(rèn)號ack=x+1。第三次握手客戶端A收到B的SYN報文段后，從確認(rèn)號就可得知不應(yīng)理睬這個SYN報文段（因?yàn)锳現(xiàn)在并沒有發(fā)送seq=x的報文段）。這時，客戶端A會發(fā)送復(fù)位報文段，這個復(fù)位報文段中，RST=1，ACK=1，確認(rèn)號ack=y+1。服務(wù)端B收到A的復(fù)位報文，就知道不建立TCP連接，不會分配資源等待A發(fā)送數(shù)據(jù)。

為什么不是四次握手：因?yàn)槿挝帐忠呀?jīng)能說明握手時的通信是正常的，四次握手、五次握手就顯得浪費(fèi)了。

四.TCP四次揮手

TCP連接是雙向的，在四次揮手中，前兩次揮手用于斷開一個方向的連接，后兩次揮手用于斷開另一方向的連接。

第一次揮手

客戶端數(shù)據(jù)發(fā)送完成，則它向服務(wù)端發(fā)送連接釋放請求。該請求只有報文頭，頭中攜帶的主要參數(shù)為：FIN=1，seq=u。此時，客戶端將進(jìn)入FIN-WAIT-1狀態(tài)。TCP規(guī)定，FIN報文段即使不攜帶數(shù)據(jù)，也要消耗一個序號。

第二次揮手

服務(wù)器收到客戶端連接釋放報文，通知相應(yīng)的高層應(yīng)用進(jìn)程，告訴它客戶端向服務(wù)器這個方向的連接已經(jīng)釋放了。此時服務(wù)端進(jìn)入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)，并向客戶端發(fā)出連接釋放的應(yīng)答，其報文頭包含：ACK=1，ack=u+1，seq=v。

客戶端收到該應(yīng)答后，進(jìn)入FIN-WAIT-2狀態(tài)，等待服務(wù)器發(fā)送連接釋放報文（在這之前還需要接受服務(wù)器發(fā)送的最后的數(shù)據(jù)）。

第二次揮手完成后，客戶端到服務(wù)端方向的連接已經(jīng)釋放，服務(wù)端不會再接收客戶端的數(shù)據(jù)，客戶端也沒有數(shù)據(jù)要發(fā)送了。但服務(wù)端到客戶端方向的連接仍然存在，服務(wù)器若發(fā)送數(shù)據(jù)，客戶端依然要接受。這個狀態(tài)還要持續(xù)一段時間，也就是整個CLOSE-WAIT狀態(tài)持續(xù)的時間。

第三次揮手

服務(wù)端將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報文，其報文頭包含：FIN=1，ack=u+1，由于在CLOS-WAIT狀態(tài)，服務(wù)端很可能又發(fā)送了一些數(shù)據(jù)，假定此時的序列號為seq=w，此時，服務(wù)器就進(jìn)入了LAST-ACK（最后確認(rèn)）狀態(tài)，等待客戶端的確認(rèn)。

第四次揮手

客戶端收到服務(wù)器的連接釋放報文后，向服務(wù)端發(fā)出確認(rèn)應(yīng)答，報文頭：ACK=1，ack=w+1，seq=u+1，此時，客戶端就進(jìn)入了TIME-WAIT（時間等待）狀態(tài)。該狀態(tài)會持續(xù)2MSL（最長報文段壽命）時間，這個期間TCP連接還未釋放，若該時間段內(nèi)沒有服務(wù)端的重發(fā)請求的話，客戶端就進(jìn)入CLOSED狀態(tài)，服務(wù)端只要收到了客戶端發(fā)出的確認(rèn)，立即進(jìn)入CLOSED狀態(tài)。就結(jié)束了這次的TCP連接。可以看到，服務(wù)器結(jié)束TCP連接的時間要比客戶端早一些。

相關(guān)問題

1.為什么客戶端最后還要等待2MSL？

第一：為了保證服務(wù)端能收到客戶端的確認(rèn)應(yīng)答。若客戶端發(fā)完確認(rèn)應(yīng)答后直接進(jìn)入CLOSED狀態(tài)，那么如果該應(yīng)答丟失，服務(wù)端等待超時后就會重新發(fā)送連接釋放請求，但此時客戶端已經(jīng)關(guān)閉了，不會作出任何響應(yīng)，因此服務(wù)端就無法正常關(guān)閉。

第二：防止類似與“三次握手”中提到了的“已經(jīng)失效的連接請求報文段”出現(xiàn)在本連接中。客戶端發(fā)送完最后一個確認(rèn)報文后，在這個2MSL時間中，就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失。這樣新的連接中不會出現(xiàn)舊連接的請求報文。

2.為什么是四次揮手？

關(guān)閉連接時，服務(wù)器收到客戶端的FIN報文時，僅僅表示客戶端不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，并且服務(wù)端也未必全部數(shù)據(jù)都發(fā)送給對方了，所以服務(wù)端可以立即關(guān)閉，也可以發(fā)送一些數(shù)據(jù)給對方后，再發(fā)送FIN報文給對方來表示同意現(xiàn)在關(guān)閉連接，因此，服務(wù)端的ACK和FIN一般都會分開發(fā)送，從而導(dǎo)致多了一次。

總結(jié)

TCP作為一種面向連接的，可靠的協(xié)議，它屬于傳輸層的協(xié)議。只有在確認(rèn)通信對端存在時才會發(fā)送數(shù)據(jù)，從而可以控制通信流量的浪費(fèi)。TCP通過檢驗(yàn)和、序列號、確認(rèn)應(yīng)答、重發(fā)控制、連接管理以及窗口控制等機(jī)制實(shí)現(xiàn)可靠性傳輸。

Kotlin項(xiàng)目實(shí)戰(zhàn)