TCP通過檢驗(yàn)和、序列號(hào)、確認(rèn)應(yīng)答、重發(fā)控制、連接管理以及窗口控制等機(jī)制實(shí)現(xiàn)可靠性傳輸。
1.確認(rèn)應(yīng)答
在TCP中，當(dāng)發(fā)送端的數(shù)據(jù)到達(dá)接收主機(jī)時(shí)，接收端主機(jī)會(huì)返回一 個(gè)已收到消息的通知。這個(gè)消息叫做確認(rèn)應(yīng)答（ACK（Positive Acknowled-gement）意指已經(jīng)接收。）
TCP通過肯定的ACK實(shí)現(xiàn)可靠的數(shù)據(jù)傳輸。當(dāng)發(fā)送端將數(shù)據(jù)發(fā)出之后會(huì)等待對(duì)端的確認(rèn)應(yīng)答。如果有確認(rèn)應(yīng)答，說明數(shù)據(jù)已經(jīng)成功到達(dá)對(duì)端。反之，則數(shù)據(jù)丟失的可能性很大。在一定時(shí)間內(nèi)沒有等到確認(rèn)應(yīng)答，發(fā)送端就可以認(rèn)為數(shù)據(jù)已經(jīng)丟失，并進(jìn)行重發(fā)。
注意：未收到確認(rèn)應(yīng)答并不意味著數(shù)據(jù)一定丟失。也有可能是數(shù)據(jù)對(duì)方已經(jīng)收到，只是返回的確認(rèn)應(yīng)答在途中丟失。這種情況也會(huì)導(dǎo)致發(fā)送端因沒有收到確認(rèn)應(yīng)答，而認(rèn)為數(shù)據(jù)沒有到達(dá)目的地，從而進(jìn)行重新發(fā)送。但是對(duì)于目標(biāo)主機(jī)來說，這簡(jiǎn)直是一種“災(zāi)難”。它會(huì)反復(fù)收到相同的數(shù)據(jù)。而為了對(duì)上層應(yīng)用提供可靠的傳輸，必須得放棄重復(fù)的數(shù)據(jù)包。為此，就必須引入一種機(jī)制，它能夠識(shí)別是否已經(jīng)接收數(shù)據(jù)，又能夠判斷是否需要接收。
2.序列號(hào)
上述這些確認(rèn)應(yīng)答處理、重發(fā)控制以及重復(fù)控制等功能都可以通過序列號(hào)實(shí)現(xiàn)。序列號(hào)是按順序給發(fā)送數(shù)據(jù)的每一個(gè)字節(jié)（8位字節(jié)）都標(biāo)上號(hào)碼的編號(hào)（序列號(hào)的初始值并非為0。而是在建立連接以后由隨機(jī)數(shù)生成。而后面的計(jì)算則是對(duì)每一字節(jié)加一） 。接收端查詢接收數(shù)據(jù)TCP首部中的序列號(hào)和數(shù)據(jù)的長(zhǎng)度，將自己下一步應(yīng)該接收的序號(hào)作為確認(rèn)應(yīng)答返送回去。就這樣，通過序列號(hào)和確認(rèn)應(yīng)答號(hào)，TCP可以實(shí)現(xiàn)可靠傳輸。
TCP的數(shù)據(jù)長(zhǎng)度并未寫入TCP首部。實(shí)際通信中求得TCP包的長(zhǎng)度的計(jì)算公式是：IP首部中的數(shù)據(jù)包長(zhǎng)度-IP首部長(zhǎng)度TCP首部長(zhǎng)度。
3.重發(fā)超時(shí)
重發(fā)超時(shí)是指在重發(fā)數(shù)據(jù)之前，等待確認(rèn)應(yīng)答到來的那個(gè)特定時(shí)間間隔。如果超過了這個(gè)時(shí)間仍未收到確認(rèn)應(yīng)答，發(fā)送端將進(jìn)行數(shù)據(jù)重發(fā)。那么這個(gè)重發(fā)超時(shí)的具體時(shí)間長(zhǎng)度又是如何確定的呢？
最理想的是，找到一個(gè)最小時(shí)間，它能保證“確認(rèn)應(yīng)答一定能在這個(gè)時(shí)間內(nèi)返回”。然而這個(gè)時(shí)間長(zhǎng)短隨著數(shù)據(jù)包途徑的網(wǎng)絡(luò)環(huán)境的不同而有所變化。TCP要求不論處在何種網(wǎng)絡(luò)環(huán)境下都要提供高性能通信，并且無論網(wǎng)絡(luò)擁堵情況發(fā)生何種變化，都必須保持這一特性。為此，它在每次發(fā)包時(shí)都會(huì)計(jì)算往返時(shí)間（Round Trip Time也叫RTT，是指報(bào)文段的往返時(shí)間） 及其偏差（RTT時(shí)間波動(dòng)的值、方差。有時(shí)也叫抖動(dòng)）。將這個(gè)往返時(shí)間和偏差相加。
數(shù)據(jù)也不會(huì)被無限、反復(fù)地重發(fā)。達(dá)到一定重發(fā)次數(shù)之后，如果仍沒有任何確認(rèn)應(yīng)答返回，就會(huì)判斷為網(wǎng)絡(luò)或?qū)Χ酥鳈C(jī)發(fā)生了異常，強(qiáng)制關(guān)閉連接。并且通知應(yīng)用通信異常強(qiáng)行終止。
4.連接管理
TCP提供面向有連接的通信傳輸。面向有連接是指在數(shù)據(jù)通信開始之前先做好通信兩端之間的準(zhǔn)備工作。它會(huì)在數(shù)據(jù)通信之前，通過TCP首部發(fā)送一個(gè)SYN包作為建立連接的請(qǐng)求等待確認(rèn)應(yīng)答（TCP中發(fā)送第一個(gè)SYN包的一方叫做客戶端，接收這個(gè)的一方叫做服務(wù)端） 如果對(duì)端發(fā)來確認(rèn)應(yīng)答，則認(rèn)為可以進(jìn)行數(shù)據(jù)通信。如果對(duì)端的確認(rèn)應(yīng)答未能到達(dá)，就不會(huì)進(jìn)行數(shù)據(jù)通信。此外，在通信結(jié)束時(shí)會(huì)進(jìn)行斷開連接的處理（通過發(fā)送FIN包）。
可以使用TCP首部用于控制的字段來管理TCP連接（也叫控制域）。一個(gè)連接的建立與斷開，正常過程至少需要來回發(fā)送7個(gè)包才能完成（“三次握手”、“四次揮手”） 。
MSS
在建立TCP連接的同時(shí)，也可以確定發(fā)送數(shù)據(jù)包的單位，我們也可以稱其為“最大消息長(zhǎng)度”（MSS：Maximum Segment Size）。最理想的情況是，最大消息長(zhǎng)度正好是IP中不會(huì)被分片處理的最大數(shù)據(jù)長(zhǎng)度。
TCP在傳送大量數(shù)據(jù)時(shí)，是以MSS的大小將數(shù)據(jù)進(jìn)行分割發(fā)送。進(jìn)行重發(fā)時(shí)也是以MSS為單位。 MSS是在三次握手的時(shí)候，在兩端主機(jī)之間被計(jì)算得出。兩端的主機(jī)在發(fā)出建立連接的請(qǐng)求時(shí)，會(huì)在TCP首部中寫入MSS選項(xiàng)，告訴對(duì)方自己的接口能夠適應(yīng)的MSS的大小。（為附加MSS選項(xiàng)，TCP首部將不再是20字節(jié)，而是4字節(jié)的整數(shù)倍）
5.窗口控制
TCP以1個(gè)段為單位，每發(fā)一個(gè)段進(jìn)行一次確認(rèn)應(yīng)答的處理這樣的傳輸方式有一個(gè)缺點(diǎn)。那就是包的往返時(shí)間越長(zhǎng)通信性能就越低。為解決這個(gè)問題，TCP引入了窗口這個(gè)概念。即使在往返時(shí)間較長(zhǎng)的情況下，它也能控制網(wǎng)絡(luò)性能的下降。確認(rèn)應(yīng)答不再是以每個(gè)分段，而是以更大的單位進(jìn)行確認(rèn)，轉(zhuǎn)發(fā)時(shí)間將會(huì)被大幅度的縮短。也就是說，發(fā)送端主機(jī)，在發(fā)送了一個(gè)段以后不必要一直等待確認(rèn)應(yīng)答，而是繼續(xù)發(fā)送。
窗口大小就是指無需等待確認(rèn)應(yīng)答而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值。這個(gè)機(jī)制實(shí)現(xiàn)使用了大量的緩沖區(qū)。
TCP提供一種機(jī)制可以讓發(fā)送端根據(jù)接收端的實(shí)際接收能力控制發(fā)送的數(shù)據(jù)量。這就是所謂的流控制。它的具體操作是，接收端主機(jī)向發(fā)送端主機(jī)通知自己可以接收數(shù)據(jù)的大小，于是發(fā)送端會(huì)發(fā)送不超過這個(gè)限度的數(shù)據(jù)。該大小限度就被稱作窗口大小。窗口大小的值就是由接收端主機(jī)決定的。 TCP首部中，專門有一個(gè)字段用來通知窗口大小。接收主機(jī)將自己可以接收的緩沖區(qū)大小放入這個(gè)字段中通知給發(fā)送端。這個(gè)字段的值越大，說明網(wǎng)絡(luò)的吞吐量越高。
收到確認(rèn)應(yīng)答的情況下，將窗口滑動(dòng)到確認(rèn)應(yīng)答中的序列號(hào)的位置。這樣可以順序地將多個(gè)段同時(shí)發(fā)送提高通信性能。這種機(jī)制也被稱為滑動(dòng)窗口控制。
窗口控制下的重發(fā)控制
重發(fā)的情況就兩種：一種是數(shù)據(jù)收到了，應(yīng)答沒有收到，第二種是數(shù)據(jù)沒有收到。
先考慮確認(rèn)應(yīng)答未能返回的情況。在這種情況下，數(shù)據(jù)已經(jīng)到達(dá)對(duì)端，是不需要再進(jìn)行重發(fā)的。然而，在沒有使用窗口控制的時(shí)候，沒有收到確認(rèn)應(yīng)答的數(shù)據(jù)都會(huì)被重發(fā)。
其次，考慮一下某個(gè)報(bào)文段丟失的情況。當(dāng)某一報(bào)文段丟失后，發(fā)送端會(huì)一直收到序號(hào)為1001的確認(rèn)應(yīng)答，這個(gè)確認(rèn)應(yīng)答好像在提醒發(fā)送端“我想接收的是從1001開始的數(shù)據(jù)”。因此，在窗口比較大，又出現(xiàn)報(bào)文段丟失的情況 下，同一個(gè)序號(hào)的確認(rèn)應(yīng)答將會(huì)被重復(fù)不斷地返回。而發(fā)送端主機(jī)如果連續(xù)3次收到同一個(gè)確認(rèn)應(yīng)答（之所以連續(xù)收到3次而不是兩次的理由是因?yàn)?，即使?shù)據(jù)段的序號(hào)被替換兩次也不會(huì)觸發(fā)重發(fā)機(jī)制） ，就會(huì)將其所對(duì)應(yīng)的數(shù)據(jù)進(jìn)行重發(fā)。這種機(jī)制比之前提到的超時(shí)管理更加高效，因此也被稱作高速重發(fā)控制。
接收端如果沒有收到自己所期望的數(shù)據(jù)時(shí)，會(huì)將之前收到的數(shù)據(jù)進(jìn)行確認(rèn)應(yīng)答，發(fā)送端一旦連續(xù)3次收到相同的確認(rèn)應(yīng)答，就會(huì)進(jìn)行數(shù)據(jù)的重發(fā)。
擁塞控制
有了TCP的窗口控制，收發(fā)主機(jī)之間即使不再以一個(gè)數(shù)據(jù)段為單位發(fā)送確認(rèn)應(yīng)答，也能夠連續(xù)發(fā)送大量數(shù)據(jù)包。然而，如果在通信剛開始時(shí)就發(fā)送大量數(shù)據(jù)，也可能會(huì)引發(fā)其他問題。 一般來說，計(jì)算機(jī)網(wǎng)絡(luò)都處在一個(gè)共享的環(huán)境。因此也有可能會(huì)因?yàn)槠渌鳈C(jī)之間的通信使得網(wǎng)絡(luò)擁堵。在網(wǎng)絡(luò)出現(xiàn)擁堵時(shí)，如果突然發(fā)送一個(gè)較大量的數(shù)據(jù)，極有可能會(huì)導(dǎo)致整個(gè)網(wǎng)絡(luò)的癱瘓。 TCP為了防止該問題的出現(xiàn)，在通信一開始時(shí)就會(huì)通過一個(gè)叫做慢啟動(dòng)的算法得出的數(shù)值，對(duì)發(fā)送數(shù)據(jù)量進(jìn)行控制。
此外，TCP中為了提高網(wǎng)絡(luò)的利用率，經(jīng)常使用一個(gè)叫做Nagle的算法。
TCP數(shù)據(jù)段格式
控制位
字段長(zhǎng)為8位，每一位從左至右分別為CWR、ECE、URG、ACK、 PSH、RST、SYN、FIN。這些控制標(biāo)志也叫做控制位。
校驗(yàn)和
TCP和UDP一樣在計(jì)算校驗(yàn)和的時(shí)候使用TCP偽首部。為了讓其全長(zhǎng)為16位的整數(shù)倍，需要在數(shù)據(jù)部分的最后填充0。首先將TCP校驗(yàn)和字段設(shè)置為0。然后以16位為單位進(jìn)行1的補(bǔ)碼和計(jì)算，再將它們總和的1的補(bǔ)碼和放入校驗(yàn)和字段。 接收端在收到TCP數(shù)據(jù)段以后，從IP首部獲取IP地址信息構(gòu)造TCP 偽首部，再進(jìn)行校驗(yàn)和計(jì)算。由于校驗(yàn)和字段里保存著除本字段以外其他部分的和的補(bǔ)碼值，因此如果計(jì)算校驗(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ù)是正確的。
首先需要清楚的一點(diǎn)，不論握手多少次都不能確認(rèn)一條信道一定是“可靠”的，但通過3次握手可以至少確認(rèn)它是“可用”的，再往上加握手次數(shù)不過是提高它是“可用”的這個(gè)結(jié)論的可信度。也就是說任意次的握手都是“不可靠”的，握手成功只能說明握手時(shí)的通信是正常的，并不能保證握手后的通信是正常的。握手只能保證盡可能的可靠，而不可能保證絕對(duì)可靠。
TCP通過三次握手來建立可靠的連接。
三次握手示意圖
第一次握手：
客戶端向服務(wù)端發(fā)送連接請(qǐng)求報(bào)文段。該報(bào)文段的頭部中SYN=1，ACK=0，同時(shí)選擇一個(gè)初始序號(hào)seq=x。請(qǐng)求發(fā)送后，客戶端便進(jìn)入SYN-SENT狀態(tài)。
第二次握手：
服務(wù)端收到連接請(qǐng)求報(bào)文段后，如果同意連接，會(huì)發(fā)送一個(gè)應(yīng)答：SYN=1，ACK=1，seq=y，ack=x 1。發(fā)送完應(yīng)答后服務(wù)端進(jìn)入SYN-RCVD狀態(tài)。
第三次握手：
客戶端收到服務(wù)端連接同意的應(yīng)答后，還會(huì)向服務(wù)端發(fā)送一個(gè)確認(rèn)報(bào)文段，表示：服務(wù)端發(fā)來的連接同意應(yīng)答已經(jīng)成功收到。該報(bào)文段的頭部為：ACK=1，seq=x 1，ack=y 1。該報(bào)文發(fā)送完畢后，客戶端和服務(wù)器端都進(jìn)入ESTABLISHED狀態(tài)，完成TCP三次握手。
相關(guān)問題
1.為什么是三次握手，而不是兩次或四次？
為什么不是兩次握手：是為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，造成服務(wù)端資源的浪費(fèi)。
在一次TCP連接中，客戶端A向服務(wù)端B發(fā)送連接請(qǐng)求SYN報(bào)文段，假如這個(gè)報(bào)文段沒有及時(shí)被服務(wù)端B接收，而是滯留在網(wǎng)絡(luò)的某處，于是客戶端A超時(shí)重傳，再次發(fā)送請(qǐng)求連接并且順利與服務(wù)端B建立了連接，交換數(shù)據(jù)后斷開連接。滯留在網(wǎng)絡(luò)中的某處的陳舊報(bào)文就變成了失效的連接請(qǐng)求報(bào)文。
但如果這個(gè)失效的請(qǐng)求SYN報(bào)文段，現(xiàn)在又突然傳送到了服務(wù)端B處，設(shè)想這時(shí)是使用兩次握手而不是三次握手，服務(wù)端B就以為客戶端A現(xiàn)在建立請(qǐng)求連接，于是服務(wù)端B發(fā)出確認(rèn)，新的連接就建立了，服務(wù)端B分配資源，等待客戶端A傳送數(shù)據(jù)，但客戶端A并沒有想要建立TCP連接，不會(huì)理會(huì)服務(wù)端B發(fā)送的應(yīng)答，也不會(huì)向服務(wù)端B傳送數(shù)據(jù)，于是服務(wù)端B就白白等待，空耗資源。
使用三次握手可以避免這個(gè)情況。服務(wù)端B收到客戶端A的失效的陳舊SYN報(bào)文段，向客戶端A發(fā)送SYN報(bào)文段，選擇自己的序號(hào)seq=y，確認(rèn)收到客戶端A的SYN報(bào)文段，確認(rèn)號(hào)ack=x 1。第三次握手客戶端A收到B的SYN報(bào)文段后，從確認(rèn)號(hào)就可得知不應(yīng)理睬這個(gè)SYN報(bào)文段（因?yàn)锳現(xiàn)在并沒有發(fā)送seq=x的報(bào)文段）。這時(shí)，客戶端A會(huì)發(fā)送復(fù)位報(bào)文段，這個(gè)復(fù)位報(bào)文段中，RST=1，ACK=1，確認(rèn)號(hào)ack=y 1。服務(wù)端B收到A的復(fù)位報(bào)文，就知道不建立TCP連接，不會(huì)分配資源等待A發(fā)送數(shù)據(jù)。
為什么不是四次握手：因?yàn)槿挝帐忠呀?jīng)能說明握手時(shí)的通信是正常的，四次握手、五次握手就顯得浪費(fèi)了。
TCP連接是雙向的，在四次揮手中，前兩次揮手用于斷開一個(gè)方向的連接，后兩次揮手用于斷開另一方向的連接。
第一次揮手
客戶端數(shù)據(jù)發(fā)送完成，則它向服務(wù)端發(fā)送連接釋放請(qǐng)求。該請(qǐng)求只有報(bào)文頭，頭中攜帶的主要參數(shù)為：FIN=1，seq=u。此時(shí)，客戶端將進(jìn)入FIN-WAIT-1狀態(tài)。TCP規(guī)定，FIN報(bào)文段即使不攜帶數(shù)據(jù)，也要消耗一個(gè)序號(hào)。
第二次揮手
服務(wù)器收到客戶端連接釋放報(bào)文，通知相應(yīng)的高層應(yīng)用進(jìn)程，告訴它客戶端向服務(wù)器這個(gè)方向的連接已經(jīng)釋放了。此時(shí)服務(wù)端進(jìn)入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)，并向客戶端發(fā)出連接釋放的應(yīng)答，其報(bào)文頭包含：ACK=1，ack=u 1，seq=v。
客戶端收到該應(yīng)答后，進(jìn)入FIN-WAIT-2狀態(tài)，等待服務(wù)器發(fā)送連接釋放報(bào)文（在這之前還需要接受服務(wù)器發(fā)送的最后的數(shù)據(jù)）。
第二次揮手完成后，客戶端到服務(wù)端方向的連接已經(jīng)釋放，服務(wù)端不會(huì)再接收客戶端的數(shù)據(jù)，客戶端也沒有數(shù)據(jù)要發(fā)送了。但服務(wù)端到客戶端方向的連接仍然存在，服務(wù)器若發(fā)送數(shù)據(jù)，客戶端依然要接受。這個(gè)狀態(tài)還要持續(xù)一段時(shí)間，也就是整個(gè)CLOSE-WAIT狀態(tài)持續(xù)的時(shí)間。
第三次揮手
服務(wù)端將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報(bào)文，其報(bào)文頭包含：FIN=1，ack=u 1，由于在CLOS-WAIT狀態(tài)，服務(wù)端很可能又發(fā)送了一些數(shù)據(jù)，假定此時(shí)的序列號(hào)為seq=w，此時(shí)，服務(wù)器就進(jìn)入了LAST-ACK（最后確認(rèn)）狀態(tài)，等待客戶端的確認(rèn)。
第四次揮手
客戶端收到服務(wù)器的連接釋放報(bào)文后，向服務(wù)端發(fā)出確認(rèn)應(yīng)答，報(bào)文頭：ACK=1，ack=w 1，seq=u 1，此時(shí)，客戶端就進(jìn)入了TIME-WAIT（時(shí)間等待）狀態(tài)。該狀態(tài)會(huì)持續(xù)2MSL（最長(zhǎng)報(bào)文段壽命）時(shí)間，這個(gè)期間TCP連接還未釋放，若該時(shí)間段內(nèi)沒有服務(wù)端的重發(fā)請(qǐng)求的話，客戶端就進(jìn)入CLOSED狀態(tài)，服務(wù)端只要收到了客戶端發(fā)出的確認(rèn)，立即進(jìn)入CLOSED狀態(tài)。就結(jié)束了這次的TCP連接?？梢钥吹?，服務(wù)器結(jié)束TCP連接的時(shí)間要比客戶端早一些。
聯(lián)系客服
