協(xié)議的定義

為了在計算機網(wǎng)絡(luò)中有條不紊地交換數(shù)據(jù)，就必須遵守一些事先約定好的規(guī)則。這些規(guī)則明確規(guī)定了所交換數(shù)據(jù)的格式以及有關(guān)的同步問題。

同步的含義：在一定條件下應當發(fā)生什么事件，因而含有時序的意思。

網(wǎng)絡(luò)協(xié)議：為進行網(wǎng)絡(luò)中的數(shù)據(jù)交換而建立的規(guī)則、標準或約定。

網(wǎng)絡(luò)協(xié)議由以下三個要素組成：

? ?1）語法：即數(shù)據(jù)與控制信息的結(jié)構(gòu)或格式

? ?2）語義：即需要發(fā)出何種控制信息，完成何種動作以及做出何種反應

? ?3）同步：即事件實現(xiàn)順序的詳細說明

運輸層概要

一、運輸層協(xié)議的概述

? ?1.1 進程之間的通信

? ?1.2 運輸層的兩個主要協(xié)議

? ?1.3 運輸層的端口

二、用戶數(shù)據(jù)報協(xié)議UDP

? ?2.1 UDP概述

? ?2.2 UDP的首部格式

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

? ?3.1 TCP的最主要的特點

? ?3.2 TCP的連接

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

? ?4.1 停止等待協(xié)議

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

五、TCP報文段的首部格式

六、TCP可靠傳輸?shù)膶崿F(xiàn)

? ?6.1 以字節(jié)為單位的滑動窗口

? ?6.2 超時重傳時間的選擇

? ?6.3 選擇確認SACK

七、TCP的流量控制

? ?7.1 利用滑動窗口實現(xiàn)流量控制

? ?7.2 必須考慮傳輸效率

八、TCP的擁塞控制

? ?8.1 擁塞控制的一般原理

? ?8.2 幾種擁塞控制方法

? ?8.3 隨機早期檢測RED

九、TCP的運輸連接管理

? ?9.1 TCP的連接建立

? ?9.2 TCP的連接釋放

? ?9.3 TCP的有限狀態(tài)機

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

一、運輸層協(xié)議的概述

1.1 進程之間的通信

1.只有主機的協(xié)議棧才有運輸層，而網(wǎng)絡(luò)核心部分中的路由器在轉(zhuǎn)發(fā)分組時都只用到了下三層的功能

2.兩個主機進行通信就是兩個主機中的應用進程互相通信。從運輸層的角度看，通信的真正端點并不是主機而是主機中的進程。（IP協(xié)議能把分組送到目的主機）

網(wǎng)絡(luò)層時為主機之間提供邏輯通信，而運輸層為應用進程之間提供端到端的邏輯通信。

3.運輸層一個重要功能——復用、分用。 （應用進程復用、分用運輸層）

1.2 運輸層的兩個主要協(xié)議

1.UDP—User Datagram Protocol 用戶數(shù)據(jù)報協(xié)議（無連接）：DNS/RIP/DHCP/SNMP/NFS

TCP—Transmission Control Protocol 傳輸控制協(xié)議（面向連接）：SMTP/TELNET/HTTP/ FTP

1.3 運輸層的端口

問題：為了使運行不同操作系統(tǒng)的計算機的應用進程能夠互相通信，就必須使用統(tǒng)一的方法（而這種方法必須與特定操作系統(tǒng)無關(guān)）對TCP/IP體系的應用進程進行標識。

為什么不用進程號來區(qū)分？（第一，不同操作系統(tǒng)的進程標識符不同；第二，用功能來識別，而不是進程，例如郵件服務功能，而不管具體是哪個進程）

解決方案：在運輸層使用協(xié)議端口號，即端口。軟件端口是應用層的各種協(xié)議進程與運輸實體進行層間交互的一種地址。（端口號只具有本地意義，只是為了標識本計算機應用層中各個進程在和運輸層交互時的層間接口。）

端口分為兩大類：

1）服務器使用的端口號：熟知端口號或系統(tǒng)端口號（0~1023）；登記端口號（1024~49151）

2）客戶端使用的端口號：49152~65535

二、用戶數(shù)據(jù)報協(xié)議UDP

2.1 UDP概述

1.UDP只在IP的數(shù)據(jù)報服務至上增加了很少一點功能，就是復用、分用以及差錯檢測功能

2.特點

? ?1）無連接

? ?2）盡最大努力交付

? ?3）面向報文 （不合并、不拆分、保留這些報文的邊界）

? ?4）UDP沒有擁塞控制

? ?5）UDP支持一對一、一對多、多對一和多對多的交互通信

? ?6）UDP的首部開銷小，只有8字節(jié)

應用進程本身可以在不影響應用的實時性的前提下，增加一些提高可靠性的措施，如采用前向糾錯或重傳已丟失的報文。

2.2 UDP的首部格式

1.traceroute 讓發(fā)送的UDP用戶數(shù)據(jù)報故意使用一個非法的UDP端口號，接收方丟棄報文，并由ICMP（網(wǎng)絡(luò)控制報文協(xié)議）發(fā)送“端口不可達”差錯報文給發(fā)送方。

2.計算檢驗和。IP數(shù)據(jù)報的校驗和只檢驗IP數(shù)據(jù)報的首部，但UDP的校驗和是把首部和數(shù)據(jù)部分一起都檢驗。（12字節(jié)的首部+真正的首部+數(shù)據(jù)來進行校驗和的計算）

? ?Q1.為什么計算校驗和要加12字節(jié)的偽首部

? ?Q2.計算校驗和的原理是什么？

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

3.1 TCP的最主要的特點

1.面向連接的運輸層協(xié)議（建立連接、傳輸數(shù)據(jù)、釋放連接）

2.點對點，每一條TCP連接只能有兩個端點

3.可靠交付（無差錯、不丟失、不重復、并且按序到達）

4.全雙工通信。TCP連接的兩端都設(shè)有發(fā)送緩存和接收緩存。

5.面向字節(jié)流。（流指的是流入到進程或從進程流出的字節(jié)序列；面向字節(jié)流：TCP把應用程序交下來的數(shù)據(jù)看成是一連串的無結(jié)構(gòu)字節(jié)流。 接收方的應用程序必須有能力識別接收到的字節(jié)流，把它還原成有意義的應用層數(shù)據(jù)。 因此TCP可以根據(jù)窗口值和當前網(wǎng)絡(luò)狀況調(diào)整發(fā)送的報文長度。劃分短一點，或者積累到足夠多再發(fā)送出去。）

3.2 TCP的連接

1.TCP把連接作為最基本的抽象。

2.每一條TCP連接有兩個端點。TCP連接的端點叫作套接字。

? ?套接字soket = （IP地址：端口號）

每一條TCP連接唯一地被通信兩端的兩個端點（即兩個套接字）所確定。

? ?TCP連接 ::= {socket1, socket2}

四、可靠傳輸?shù)墓ぷ髟?/b>

理想的傳輸條件有以下兩個特點：

? ?1）傳輸信道不產(chǎn)生差錯

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

實際的網(wǎng)絡(luò)并不具備，因此：

? ?1）出現(xiàn)差錯時，讓發(fā)送方重傳

? ?2）接收方來不及處理時，及時告訴發(fā)送方適當降低發(fā)送數(shù)據(jù)的速度

4.1 停止等待協(xié)議

1.“停止等待”就是沒發(fā)送完一個分組就停止發(fā)送，等待對方的確認，在收到確認后再發(fā)送下一個分組。

2.超時重傳。在每發(fā)完一個分組就設(shè)置一個超時計時器，如果在超時計時器之前收到對方的確認，就撤銷已設(shè)置的超時計時器。如果未收到，就認為剛才的分組丟失，并重傳。

3.三種情況：A發(fā)送的分組出錯、丟失；B發(fā)送的確認丟失；B發(fā)送的確認遲到

確認丟失：B丟棄重復的分組，向A重傳確認

確認遲到：A丟棄重復的確認，B丟棄重復分組，并向A重傳確認

4.常稱為自動重傳請求ARQ，重傳時自動進行的（超時即重傳）

5.缺點：信道利用率太低

? ?U=Td/(Td+RTT+Ta)

為了提高傳輸效率，發(fā)送方不使用停止等待協(xié)議，而是采用流水線傳輸。流水線傳輸就是發(fā)送發(fā)可連續(xù)發(fā)送多個分組，不必等每發(fā)完一個分組就停頓下來等待對方的確認。（連續(xù)ARQ協(xié)議和滑動窗口協(xié)議）

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

1.位于發(fā)送窗口內(nèi)的分組都可連續(xù)發(fā)送出去，而不需要等待對方的確認。

2.累積確認：接收方不必對收到的分組逐個發(fā)送確認，而是在收到幾個分組后，對按序到達的最后一個分組發(fā)送確認。

3.缺點：Go-back-N （發(fā)送前5個分組，第3個分組丟失，后面三個要重傳）

五、TCP報文段的首部格式

1.源端口和目的端口

2.序號。 每個字節(jié)都按順序編號。

3.確認號。 期望收到對方下一個報文段的第一個數(shù)據(jù)字節(jié)的序號。

若確認號=N，則表明：到序號N-1為止的所有數(shù)據(jù)都已正確收到。

4.數(shù)據(jù)偏移。 指出TCP報文段的數(shù)據(jù)起始處距離TCP報文段的起始處有多遠（也即TCP報文段首部長度）。由于首部中還有長度不確定的選項字段，因此數(shù)據(jù)偏移字段是必要的。

5.窗口。窗口字段明確指出了現(xiàn)在允許對方發(fā)送的數(shù)據(jù)量。窗口值是經(jīng)常在動態(tài)變化著。

六、TCP可靠傳輸?shù)膶崿F(xiàn)

6.1 以字節(jié)為單位的滑動窗口

1.發(fā)送緩存用來暫存：

? ?1）發(fā)送應用程序傳送給發(fā)送方TCP準備發(fā)送的數(shù)據(jù)；

? ?2）TCP已發(fā)送但未收到確認德爾數(shù)據(jù)

2.接收緩存用來存放：

? ?1）按序到達的、但尚未被接收應收程序讀取的數(shù)據(jù)；

? ?2）未按序到達的數(shù)據(jù)

3.注意三點：

? ?1）A的發(fā)送窗口是根據(jù)B的接收窗口設(shè)置的，但是在同一時刻，由于網(wǎng)絡(luò)傳輸?shù)臏?，A的發(fā)送窗口并不總是B的接收窗口一樣大

? ?2）TCP通常對不按序到達的數(shù)據(jù)是先臨時存放在接收窗口中，等到字節(jié)流中所缺少的字節(jié)收到后，再按序交付上層的應用進程

? ?3）TCP接收方有累計確認功能（不能過分推遲發(fā)送確認，否則會導致發(fā)送方不必要的重傳）

6.2 超時重傳時間的選擇

1.超時重傳時間設(shè)置太短，會引起很多不必要的重傳；如果設(shè)置太長，使網(wǎng)絡(luò)的空閑時間增大，降低傳輸效率。

2.新的RTTs = (1-a)x(舊的RTTs) + ax（新的RTT樣本），其中RTT樣本的時間為：記錄一個報文段發(fā)出的時間，以及收到相應的確認時間，時間差就是報文段的往返時間RTT。

3.RTO = RTTs + 4 x RTTd，其中RTO為超時重傳時間，RTTd是RTT的偏差的加權(quán)平均值。

新的RTTd = (1-b) x （舊的RTTd）+ b x |RTTs - 新的RTT樣本|

4.一個問題：發(fā)送一個報文段，設(shè)定的重傳時間到了，還沒有收到確認。于是重傳報文段。經(jīng)過一段時間，收到了確認報文段?，F(xiàn)在的問題是：如何判定此確認報文段是對先發(fā)送的報文段的確認，還是對后來重傳的報文段的確認？

1）解決方法1，在計算加權(quán)平均值RTTs時，只要報文段重傳了，就不采用其往返時間樣本。

引入的問題：報文段的時延突然增大的情況

2）解決方法2，報文段每重傳一次，就把超時重傳時間RTO增大一些（一般是2倍）。當不在發(fā)生報文段的重傳時，再根據(jù)加權(quán)平均計算。

6.3 選擇確認SACK

SACK文檔并沒有指明發(fā)送發(fā)應當怎樣響應SACK。因此大多數(shù)的實現(xiàn)還是重傳所有未被確認的數(shù)據(jù)塊。

七、TCP的流量控制

7.1 利用滑動窗口實現(xiàn)流量控制

1.流量控制：就是讓發(fā)送方的發(fā)送速率不要太快，要讓接收方來得及接收。

2.利用滑動窗口機制可很方便地在TCP連接上實現(xiàn)對發(fā)送方的流量控制。發(fā)送方的發(fā)送窗口不能超過接收方給出的接收窗口的數(shù)值。

3.死鎖情況：B向A發(fā)送了零窗口的報文段后不久，B又有了一些緩存空間，因此B向A發(fā)送rwnd = 400.然而該報文段在傳送過程中丟失。A一直等待B發(fā)送的非零窗口的通知，B也一直等待A發(fā)送的數(shù)據(jù)。（窗口通知不超時重傳？為什么？）

解決方法：TCP為每個連接設(shè)有一個持續(xù)計時器。只要一方收到對方的零窗口通知，就啟動計時器。計時器到期后，發(fā)送一個零窗口探測報文段，而對方就在確認這個探測報文段時給出了現(xiàn)在的窗口值。若仍為零，收到報文段的一方重新設(shè)置持續(xù)計時器。

7.2 必須考慮傳輸效率

1.應用程序把數(shù)據(jù)傳送到TCP的發(fā)送緩存后，剩下的發(fā)送任務就由TCP來控制了。

2.三種不同的機制來控制TCP報文段的發(fā)送時機：

? ?1）TCP維持一個變量，它等于最大報文段長度MSS，只要緩存中的存放的數(shù)據(jù)達到MSS，就組裝成一個TCP報文段發(fā)送出去

? ?2）由發(fā)送方的應用進程指明要求發(fā)送報文段，即TCP支持推送操作

? ?3）發(fā)送方設(shè)置一個定時器

3.問題一、若用戶只發(fā)送一個字節(jié)，則非常浪費帶寬。

解決方法：若發(fā)送應用程序把要發(fā)送的數(shù)據(jù)逐個字節(jié)地送到TCP的發(fā)送緩存，則發(fā)送方就把第一個數(shù)據(jù)字節(jié)先發(fā)送出去，把后面到達的數(shù)據(jù)字節(jié)都緩存起來。當發(fā)送方收到對第一個數(shù)據(jù)字符的確認后，再把發(fā)送緩存中的所有數(shù)據(jù)組裝成一個報文段發(fā)送出去。（采用收到確認就發(fā)送+并開始緩存的方式；同時當?shù)竭_的數(shù)據(jù)已達到發(fā)送窗口大小的一半或已達到報文段的最大長度時，就立即發(fā)送一個報文段。）

4.問題二、糊涂窗口綜合癥。接收緩存已滿，應用程序一次只讀取一個字節(jié)，然后向發(fā)送方發(fā)送確認。

解決方法：讓接收方等待一段時間，使得接收緩存已有足夠空間容納一個最長的報文段，或者等到接收緩存已有一半空閑的空間。則接收方就發(fā)出確認報文。

八、TCP的擁塞控制

8.1 擁塞控制的一般原理

1.擁塞的定義：對資源的需求 > 可用資源。 在計算機網(wǎng)絡(luò)中的鏈路帶寬、交換結(jié)點中的緩存和處理機等，都是網(wǎng)絡(luò)中的資源。

2.擁塞解決不能靠解決某一個部分的問題。因為這會將瓶頸轉(zhuǎn)移到其他地方。問題的實質(zhì)往往是整個系統(tǒng)的各個部分不匹配。只有所有部分都平衡了，問題才會得到解決。

3.擁塞控制與流量控制的比較。

? ?1）擁塞控制：防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，這樣可以使網(wǎng)絡(luò)中的路由器或鏈路不致過載。

? ?擁塞控制有個前提：網(wǎng)絡(luò)能夠承受現(xiàn)有的網(wǎng)絡(luò)負荷

? ?擁塞控制是一個全局性過程。（發(fā)送擁塞時，不知道在某處、什么原因造成的）

? ?2）流量控制：點對點通信量的控制，是個端到端的問題

? ?流量控制：抑制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便使接收端來得及接收。

4.尋找擁塞控制的方案無非就是使不等式 “對資源的需求 > 可用資源 ”不再成立的條件。但是必須考慮該措施帶來的其他影響。

5.計算機網(wǎng)絡(luò)是個復雜的系統(tǒng)。從控制理論的角度來看擁塞控制，可以分為開環(huán)控制和閉環(huán)控制兩種方法。

? ?1）開環(huán)控制：設(shè)計網(wǎng)絡(luò)時事先將有關(guān)發(fā)生擁塞的因素考慮周到，力求網(wǎng)絡(luò)在工作時不產(chǎn)生擁塞。但一旦系統(tǒng)運行起來，就不再中途改正。

? ?2）閉環(huán)控制：基于反饋環(huán)路。

? ?步驟一、監(jiān)測網(wǎng)絡(luò)系統(tǒng)以便檢測到擁塞在何時、何處發(fā)生；

? ?步驟二、把擁塞發(fā)生的信息傳送到可采取行動的地方

? ?步驟三、調(diào)整網(wǎng)絡(luò)系統(tǒng)的運行以解決出現(xiàn)的問題

8.2 幾種擁塞控制方法（只考慮網(wǎng)絡(luò)擁塞程度，即假設(shè)接收方總是有足夠大的緩存空間）

1.慢開始和擁塞避免

1）發(fā)送方維持一個擁塞窗口。

? ?擁塞窗口的大小取決于網(wǎng)絡(luò)的擁塞程度，并且動態(tài)地在變化。

? ?控制擁塞窗口的原則是：只要網(wǎng)絡(luò)沒有出現(xiàn)擁塞，擁塞窗口增大；如果網(wǎng)絡(luò)出現(xiàn)擁塞，則減小。

2）慢開始的思路：由小到大逐漸增大擁塞窗口數(shù)值。每收到一個對新的報文段的確認，把擁塞窗口增加至多一個MSS的數(shù)值。（沒經(jīng)過一個傳輸輪次，擁塞窗口cwnd就加倍）

輪次：把擁塞窗口所允許發(fā)送的報文段都連續(xù)發(fā)送出去，并收到了對已發(fā)送的最后一字節(jié)的確認。

慢開始的“慢”并不是指cwnd的增長速率慢，而是指TCP開始發(fā)送報文段時先設(shè)置cwnd=1（一個MSS數(shù)值）。

3）慢開始門限ssthresh

? ?為防止擁塞窗口增長過大，引入一個慢開始門限ssthresh。

? ?當cwnd < ssthresh時，使用上述的慢開始算法

? ?當cwnd > ssthresh時，停止使用慢開始算法而改用擁塞避免算法

4）擁塞避免算法

思路：讓擁塞窗口cwnd緩慢增大，即沒經(jīng)過一個往返時間RTT就把發(fā)送方的擁塞窗口cwnd增加1，而不是加倍。

5）慢開始門限的設(shè)置

只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞（沒有按時收到確認），就把慢開始門限ssthresh設(shè)置為出現(xiàn)擁塞時發(fā)送方窗口值的一半，然后把擁塞窗口cwnd重置為1，執(zhí)行慢開始算法。

6）乘法減小和加法增大

乘法減?。壕W(wǎng)絡(luò)出現(xiàn)擁塞時，把慢開始門限ssthresh減半（當前的ssthresh的一半），并執(zhí)行慢開始算法。

加法增大：執(zhí)行擁塞避免方法

2.快重傳和快恢復

1）快重傳（盡快重傳未被確認的報文段）

首先，要求接收方每收到一個失序的報文段后就立即發(fā)出重復確認。（如接收方收到了M1和M2后都分別發(fā)出了確認，但接收方?jīng)]有收到M3但接著收到了M4。此時接收方立即發(fā)送對M2的重復確認。）

其次，發(fā)送方只要一連收到三個重復確認，就應當立即重傳對方尚未收到的報文段M3.

2）快恢復

要點一、當發(fā)送方連續(xù)收到三個重復確認，就執(zhí)行“乘法減小”算法，把慢開始門限ssthresh減半。

要點二、由于發(fā)送方認為網(wǎng)絡(luò)很可能沒有發(fā)生擁塞（因為收到了連續(xù)的重復確認），把cwnd設(shè)置為慢開始門限ssthresh減半后的值，然后開始執(zhí)行擁塞避免算法

慢開始算法只在TCP連接建立時和網(wǎng)絡(luò)出現(xiàn)超時才使用。

3.發(fā)送方的窗口

發(fā)送方窗口的上限值 = Min [rwnd, cwnd]

8.3 隨機早期檢測RED（IP層影響TCP層的擁塞控制）

1.網(wǎng)絡(luò)層的分組丟棄策略

網(wǎng)絡(luò)層的策略對TCP擁塞控制影響最大的就是路由器的分組丟棄策略。

如果路由器隊列已滿，則后續(xù)到達的分組將都被丟棄。這就叫做尾部丟棄策略。

2.全局同步

由于TCP復用IP，若發(fā)生路由器中的尾部丟棄，就可能會同時影響到很多條TCP連接，結(jié)果就使許多TCP連接在同一時間突然都進入到慢開始狀態(tài)。全局同步使得全網(wǎng)的通信量突然下降了很多，網(wǎng)絡(luò)恢復正常后，其通信量又突然增大很多。

3.隨機早期檢測RED

使路由器的隊列維持兩個參數(shù)，即隊列長度最小門限THmin和最大門限THmax。當每一個分組到達時，RED就先計算平均隊列長度Lav。RED算法是：

1）若平均隊列長度小于最小門限THmin，則把新到達的分組放入隊列進行排隊

2）若平均隊列長度超過最大門限THmax，則把新到達的分組丟棄

3）若平均隊列長度在最小門限THmin和最大門限THmax之間，則按照某一概率p將新到達的分組丟棄。

隨機體現(xiàn)在3），在檢測到網(wǎng)絡(luò)擁塞的早期征兆時（即路由器的平均隊列長度超過一定的門限值時），就先以概率p隨機丟棄個別的分組，讓擁塞控制只在個別的TCP連接上進行，因而避免發(fā)生全局性的擁塞控制。

4.平均隊列長度Lav和分組丟棄概率p

Lav = (1-d) x (舊的Lav) +d x (當前的隊列長度樣本)

p = ptemp / (1- count x ptemp)

ptemp = pmax x (Lav - THmin) / (THmax - THmin)

九、TCP的運輸連接管理

TCP時面向連接的協(xié)議。

運輸連接就有三個階段：連接建立、數(shù)據(jù)傳送和連接釋放

運輸連接的管理：使運輸連接的建立和釋放都能正常地進行。

在TCP連接建立過程中要解決以下三個問題：

? ?1）要使每一方能夠確知對方的存在

? ?2）要允許雙方協(xié)商一些參數(shù)（如最大窗口值、是否使用窗口擴大選項和時間戳等等）

? ?3）能夠?qū)\輸實體資源（如緩存大小、連接表中的項目等）進行分配

9.1 TCP的連接建立

1.TCP規(guī)定，SYN=1報文段不能攜帶數(shù)據(jù)，但消耗一個序號

2.TCP規(guī)定，ACK=1報文段可以攜帶數(shù)據(jù)，如果不攜帶數(shù)據(jù)則不消耗序號

3.為什么A還要發(fā)送一次確認？為了防止已失效的連接請求報文突然又傳送到B，因而產(chǎn)生錯誤。

“已失效的連接請求報文段”

A發(fā)出第一個連接請求報文段，在網(wǎng)絡(luò)中滯留超時，又發(fā)出了第二個連接請求。但B收到第一個延遲的失效的連接請求報文段后，就誤認為是A又發(fā)出了一次新的連接請求。于是就向A發(fā)出確認報文段，同意建立連接。假定不采用三次握手，那么只要B發(fā)出確認，新的連接就建立。此時A不會理睬B的確認，也不會發(fā)數(shù)據(jù)，但B一直等A發(fā)送數(shù)據(jù)，B的許多資源就浪費了。

采用三次握手，A不會向B發(fā)送確認，因此B就知道A并沒有要求建立確認。

9.2 TCP的連接釋放

1.TCP規(guī)定，F(xiàn)IN報文段基石不攜帶數(shù)據(jù)，也消耗一個序號

2.第二次握手后，TCP通知高層應用程序，因而從A到B這個方向的連接就釋放，TCP連接處于半關(guān)閉狀態(tài)

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

? 1）為了保證A發(fā)送的最后一個ACK報文段能夠到達B。因為ACK可能丟失，此時B可能會超時重傳，然后A重傳確認，并重新啟動2MSL計時器

? 2）防止“已失效的連接請求報文段”出現(xiàn)在本連接中?？梢允贡具B接持續(xù)時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失。

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