計算機網路2msl是什麼意思

❶ TCP和UDP的區別

首先TCP是面向連接的，UDP是無需連接的，TCP有著三握四揮，並且三次握手和四次揮手是對TCP建立的連接有著重要意義的兩步，並且TCP是對IP無可靠性提供可靠性的源頭，UDP繼承了IP的特性，不保證不丟失包，不保證按順序到達

TCP面向位元組流，發送的時候是一個流，沒有頭尾，IP包不是一個流，而是一個個的IP包，UDP也是如此

TCP是有擁塞控制的，但是UDP沒有

MAC層去掉之後，IP層首部會有一個8位的協議，這里會存放著數據里到底是TCP還是UDP，當然這里是UDP，如果我們知道UDP格式就可以解析出來了

下一步就通過UDP包中的目標埠號，將這個包交給應用程序處理

源埠和目標埠不可少，包的序號是為了解決亂序問題，為了解決包的先後順序，還有就是確認序號，發出去的包要有確認，不然無法知道是否收到，若沒有收到就要重新發送，直到送達，這就是TCP的不丟包的實質

對於TCP來說，IP層丟不丟包管不著，但是在TCP層，會努力保證可靠性

一開始，客戶端和服務端都處於CLOSED狀態，先是服務端主動監聽某個埠，處於LISTEN狀態，然後客戶端主動發起連接SYN，之後處於SYN-SENT狀態，服務端收到發起的連接，返回SYN，並且ACK客戶端的SYN，之後處於SYN-RCVD狀態。客戶端收到服務端發送的SYN和ACK之後，發送ACK的ACK，之後處於ESTABLISHED狀態，因為它一發一收成功了，服務端收到ACK的ACK之後，處於ESTABLISHED，因為它也一發一收了

所以三次握手就能確認雙發收發功能都正常，缺一不可。

最後客戶端A的TIME-WAIT狀態時間要足夠長，長到如果B沒有收到ACK的話，B會再次發送FIN關閉連接，A會重新發送一個ACK並且時間足夠長到這個包到B

A如果直接跑路的話，它的埠就空出來了，但是B不知道，原來發的包如果在路上，但是這時突然另一個應用開啟在了這個埠上，那不就混亂了，所以A也需要等待足夠時間，等到B發送的包在網路中掛掉之後再空出埠來

等待時間設置為2MSL，報文最大的生存時間，協議規定MSL為2分鍾，實際應用中常用的是30s，1分鍾和2分鍾等

為了記錄所有發送的包和接收的包，TCP也需要發送端和接收端分別都有緩存來保存這些記錄，發送端的緩存里是按照包的ID一個個排列，根據處理情況分為下面四個部分

在TCP里，接收端會給發送端報一個窗口的大小，叫做Advertised window，這個 窗口大小 應該等於上面說的第二部分加上第三部分也就是 已經發送了但是沒有得到確認的加上還沒有發送，並且正在准備發送的 ，超過這個窗口的，接收端忙不過來，就不能發送了

第二部分的窗口有多大？

NextByteExpected 和 LastByteRead的差其實是還沒有被應用層讀取的部分佔用調MaxRcvBuffer的量，定義為A， 窗口大小其實是MaxRcvBuffer減去A

其中第二部分裡面，由於收到的包可能不是順序的，會出現空檔， 只有和第一部分連續的，可以馬上進行回復 ，中間空著的部分需要等待，哪怕後面的已經來了(可以看到接收端的窗口出現了虛線和實線的區別)

發送端

接收端

在 發送端 看來，1、2、3都已經發送並且確認的；4、5、6、7、8、9都是發送了還沒有確認；10、11、12是還沒有發出的；13、14、15是接收方沒有空間不準備發送的

在 接收端 看來，1、2、3、4、5都是已經完成ACK的，但是是沒有被應用層讀取的；6、7是等待接收的；8、9是已經接收，但是還沒有ACK的

當前的狀態

假設4的ACK到了，不幸的是5的ACK丟了，6、7的數據包丟失了，這應該怎麼做？

對每一個發送了，但是沒有ACK的包，都設有一個定時器，超過了一定的時間就重新嘗試，但是這個超時的時間如何進行評估呢，這個時間不宜過短，時間必須大於往返時間RTT，否則將會引起不必要的重傳，也不宜過長，這樣的超時時間變長，訪問就變慢了

RTT(Round-Trip Time): 往返時延。在計算機網路中它是一個重要的性能指標，表示從發送端發送數據開始，到發送端收到來自接收端的確認（接收端收到數據後便立即發送確認），總共經歷的時延。

估計往返時間需要TCP通過 采樣RTT的時間，然後進行加權平均 ，計算出來一個值，並且這個值還是隨著網路的狀況 不斷變化 的，我們成為 自適應重傳演算法

如果過一段時間，5、6、7都超時了，就會重新發送，接收方發現5原來接受過，於是丟棄5；6收到了，發送ACK，要求下一個是7,7不幸又丟了，當7再次超時的時候，有需要重傳的時候， TCP的策略是超時間隔加倍，每當遇到一次超時重傳的時候，都會將下一次超時時間間隔設為先前的兩倍，兩次超時就說明網路環境差，不適合頻繁反復發送

超時觸發重傳存在的問題是，超時周期可能相對較長

有一個 快速重傳的機制 ，當接收方收到一個序號大於下一個所期望的報文段時，就檢測到了數據流中的一個間隔，於是發送三個冗餘的ACK，客戶端收到後，在定時器過期之前，重傳丟失的報文段

例如，接收方發現6、8、9都已經接收了，7還沒來，那肯定是丟了，於是發送三個6的ACK要求下一個是7，客戶端收到3個ACK就會發現7的包確實又丟了，不再等待超時，馬上重發

SACK ，這種方式需要在TCP頭加一個SACK的東西，可以將緩存的地圖發送給發送方，例如有了ACK6、ACK8、ACK9就會知道7丟了

在對於包的確認中，同時會攜帶一個窗口的大小

假設窗口不變，始終為9,4的確認來的時候，會右移一個，這個時候第13個包也可以發送了

這個時候，假設發送端發送過猛，會將第三部分的10、11、12、13全部發送完畢，之後就停止發送了，未發送可發送部分為0

當對於包5的確認到達的時候，在客戶端相當於窗口滑動了一格，這個時候才可以有更多的包可以發送了，接下來14可以被發送

如果接收方實在處理太慢，導致緩存中沒有了空間，可以通過確認信息修改窗口的大小，甚至可以設置為0，讓發送端暫時停止發送

假設接收端應用一直不讀取緩存中的數據，當數據包6被確認後，窗口大小就會減小一個變為8

這個時候可以看到，接收端的窗口並沒有向右移動，只是簡單地將左邊的標記右移一格，窗口大小變為8

如果接收端一直不處理數據，則隨著確認包越來越多，窗口越來越小直到為0

如果情況變成這樣， 發送方會定時發送窗口探測數據包，看看是否有機會調整窗口的大小 ，當接收方比較慢的時候，要防止低能窗口綜合征， 不要空出一個位元組就告訴發送方 ，然後立馬被填滿，可以當窗口太小的時候，不更新窗口，直到達到一定大小，或者緩沖區一般為空的時候再更新窗口

擁塞控制同樣通過窗口的大小來控制，滑動窗口是為了防止發送方把接收方緩存塞滿，而擁塞窗口是為了不把網路填滿

LastByteSent - LastByteAcked <= min{滑動窗口， 擁塞窗口}

TCP協議是不知道真個網路路徑都是什麼，TCP包常被比喻為往一個誰管理灌水TCP擁塞控制就是在不堵塞，不丟包的情況下，盡量發揮帶寬

網路通道的容量 = 帶寬 x 往返延遲

假設往返時間為8s，發送的過程4s，返回的時間4s，每個包1024byte，過了8s，8個包都發出去了，其中4個已經到達了接收端，但是ACK還在路上，不能算是發送成功了，5-8後四個包還在路上沒被接收，這個時候，整個管道剛好被撐滿

如果我們在這個基礎上再將窗口調大一點，會出現什麼現象？

如果從發送端到接收端會經過四個設備，每個設備處理包的時間需要1s，所以4個包的話，總共的處理時間為4s，如果窗口調大，也就有可能增加發送速度，單位時間內，會有更多的包到達這些中間設備，那麼處理中的設備會丟棄到多餘的包，這是我們不想看到的

這個時候，我們可以為這四台設備增加緩存，處理不過來的包在隊列里等待，這樣就不會丟失了，但是缺點是會增加時間，在之前我們分析過只需要4s一個包即可到達發送端，但是進入緩存中多餘的包肯定到達的時間是要超過4s的，如果這個時候發送方還是沒有收到ACK那麼就會觸發超時重傳， TCP的擁塞控制就是為了處理包的丟失和超時重傳

一條TCP連接的開始，cwnd設置為一個報文段，一次只能發送一個，當收到這個確認的時候，cwnd +1，於是一次能夠發送2個，當這兩個的確認到來的時候，每個確認的cwnd + 1 ，兩個確認的cwnd就可以 +2，現在可以發送4個， 這是指數級別的增長，但是有一個值sshthresh為65535位元組，當超過這個值的時候不要增長得這么快了，可能快滿了，再慢下來

於是，每收到一個確認後，cwnd增長1/cwnd，一共發送8個的話，當8個確認到來的時候，每個確認增加1/8，八個確認一共cwnd + 1，於是一次能夠發送9個，變成了 線性增長 ，但是肯定有一天會滿，這個時候就會出現擁堵，就需要慢慢等待包的處理

擁塞的一種形式是丟包，需要超時重傳 ，這個時候

重新開始慢啟動，這樣的話，只要超時重傳就感覺會回到解放前

快速重傳 ，當接收端發現丟了一個中間包的時候，發送三次前一個包的ACK，於是發送端就會快速重傳，不必等待超時再重傳，TCP認為這種情況不嚴重，因為大部分沒丟，只丟了一小部分

正是這種知道該快還是慢的情況下，使得時延很重要的情況下，反而降低了速度，但是 擁塞控制還是存在問題

為了優化這兩個問題，有了TCP BBR擁塞演算法，它企圖找到一個平衡點，通過不斷的加快發送速度，將管道填滿，但是不會填滿中間設備的緩存，因為這樣時延會增加，這個平衡的時點可以很好的達到高帶寬和低時延的平衡

❷ 計算機網路(5)| 運輸層

從通信和處理信息的角度看，運輸層是向它上面的應用層提供通信服務的，它屬於面向通信部分的最高層，同時也是用戶功能中的最低層。當網路的邊緣部分中的兩台主機使用網路的核心部分的功能進行端到端的通信時，只有主機的協議棧才有運輸層，而網路核心部分中的路由器在轉發分組時都只用到下三層的功能。

運輸層的兩個主要協議 TCP/IP 都是互聯網的正式標准，即：
（1）用戶數據報協議UDP
（2）傳輸控制協議TCP

TCP則是面向連接的服務。在傳送數據之前必須先建立連接，數據傳送結束後要釋放連接。TCP不提供廣播或者多播服務。由於TCP要提供可靠的面向連接的運輸服務，因此需要增加很多的開銷。

TCP/IP的運輸層用一個16位埠號來標志一個埠。埠號只有本地意義。它是為了標志本計算機應用層中的各個進程在和運輸層交互時的層間介面。

運輸層的埠號分為以下兩類：
（1）伺服器端使用的埠號： 它主要分為系統埠號0～1023和登記埠號1024～49151。

（2）客戶端使用的埠號： 49152～65535，這類埠號僅在客戶端進程運行時才動態選擇。當伺服器收到客戶端進程的報文時，就知道客戶端進程的埠號。因而可以把數據發送給客戶進程。

用戶數據報協議相比於IP的數據報服務就是只增加了復用、分用和差錯檢測功能。UDP的主要特點是：
（1）UDP是無連接的， 發送數據之前不需要建立連接，因此減少開銷和發送數據之前的時延。
（2）UDP使用盡最大努力交付， 即不保證可靠交付，因此主機不需要維持復雜的連接狀態表。
（3）UDP是面向報文的。 發送方的UDP對應用交下來的報文，添加首部後就向下交付給IP層。不對報文做任何處理，因此當報文過長時，IP層可能需要進行分片處理。
（4）UDP沒有擁塞控制， 網路出現的擁塞不會使源主機的發送速率減低。
（5）UDP支持一對一、一對多、多對一和多對多的交互通信。
（6）UDP的首部開銷小， 只有8個位元組。

UDP有兩個欄位：數據欄位和首部欄位。先介紹首部欄位，它是由4個欄位組成的，每個欄位只有2個位元組，總共有8個位元組。各個欄位的意義如下：
（1）源埠： 源埠號。在需要對方回信時選用。不需要時可用全0。
（2）目的埠： 目的埠號。在這終點交付報文時必須使用。
（3）長度： UDP用戶數據報的長度，其最小值是8（只有首部）。
（4）檢驗和： 檢測UDP用戶數據報在傳輸中是否有錯，有錯則丟棄。

當在傳送用戶數據報時，如果接收方UDP發現收到的報文中目的埠號不正確（即不存在對應於該埠號的應用進程），就丟棄該報文，並由網際控制報文協議ICMP發送「埠不可達」差錯報文給發送方。

TCP的主要特點如下：
（1）TCP是面向連接的運輸層協議。 應用程序在使用TCP協議之前，必須先建立TCP連接。傳送數據完畢後，必須釋放TCP連接。
（2）每一條TCP連接只能有兩個端點。 每一條TCP連接只能是點對點的。
（3）TCP提供可靠交付的服務。 通過TCP連接傳送的數據，無差錯、不丟失、不重復，並且按序到達。
（4）TCP提供全雙工通信。 TCP允許通信雙方的應用進程在任何時候都能發送數據。
（5）面向位元組流。 TCP中的流指的是流入到進程或進程流出的位元組序列。雖然應用程序和TCP的交互是一次一個數據塊，但TCP把應用程序交下來的數據看成一連串的無結構的位元組流。TCP不保證發送方發送的數據塊和接收方接收的數據塊一致，但保證程序接收到的位元組流和程序發送的位元組流一致。

TCP連接的端點叫做套接字或者插口。套接字是指將埠號拼接到IP地址之後，即：

每一條TCP連接唯一的被通信兩端的兩個端點所確定。即：

如圖所示，A發送分組M1，發送完畢就暫停發送，等待B的確認,B收到了M1就向A發死你確認。A在收到了對M1的確認之後，就再發送下一個分組M2，以此類推。

如圖所示，當B接收M1時檢測出了差錯，就丟棄M1，其他什麼也不做。而A只要超過了一段時間沒有收到確認，就會認為剛才發送的分組丟失了，因而重傳前面發送過的分組，這就叫做超時重傳，而實現超時重傳則需要A為每一個已發送的分組都設置一個超時計時器。
需要注意以下三點：
（1）A在發送完一個分組後，必須暫時保留已發送的分組的副本。
（2）分組和確認分組必須編號，這樣才能明確哪一個發出的分組收到了確認。
（3）超時計時器設置的重傳時間應當比數據在分組傳輸的平均往返時間更長。

如圖所示，B所發送的對M1確認丟失了，A在設定的超時重傳時間內沒有收到確認，所以無法知道自己發送的分組是怎樣出錯的，所以會重傳M1，而當B又收到了重傳的分組M1，這時應該採取兩個行動：
（1）丟棄這個重復分組M1。
（2）向A發送確認。

還有一種情況就是在傳輸過程中沒有出現差錯，但B對分組M1的確認遲到了，而A會收到重復的確認，A收下後就會丟棄，B仍然會收到重復的M1，並且同樣要丟棄重復的M1，並且重傳確認分組。

停止等待協議的優點是簡單，缺點則是信道的利用率太低。我們用TD表示A發送分組需要的時間，TA表示B發送確認分組需要的時間，RTT為往返時間，則：

為了提高傳輸的效率，發送方可以不使用低效率的停止等待協議，而是採用流水線傳輸的方式。即不必每發完一個分組就停下來等待對方的確認，這樣就可以使信道上一直有數據在不間斷的傳送。

如圖表示的是發送方維持的發送窗口，它指的是位於發送窗口內的5個分組都可以連續發送出去而不需要等待對方的確認。同時連續ARP協議規定，發送方每收到一個確認，就把發送窗口向前滑動一個分組的位置。

對於接收方採用的則是累計確認的方式，即接收方不必對收到的分組逐個發送確認。而是在收到幾個分組後，對按序到達的最後一個分組發送確認，這就表示：到這個分組為止的所有分組都已正確收到了。這種方式的優點是：容易實現，即使確認丟失也不必重傳（意思是發送方不必重傳）。但缺點是不能向發送方反映出接收方已經正確收到的所有分組信息。

TCP雖然是面向位元組流的，但傳送TCP的數據單元卻是報文段。一個TCP報文段可以分為首部和數據兩部分。

為了後面講述的方便，我們假設數據傳輸只在一個方向進行，即A發送數據，B給出確認。

TCP的滑動窗口是以位元組為單位的。如圖所示，現在假定A收到了B發來的確認報文段，其中的窗口是20位元組，而確認號是31，根據這2個數據，A就構造出自己的發送窗口。

發送窗口表示：在沒有收到B的確認的情況下，A可以連續把窗口內的數據都發送出去。凡是已經發送過的數據，在未收到確認之前都必須暫時保留，以便在超時重傳時使用。發送窗口後面的部分表示已發送且已經收到了確認。而發送窗口前沿的部分表示不允許發送的。

現在假定A發送了序號為31~41的數據。這時發送窗口位置並未改變但是發送窗口內靠後面有11個位元組表示已發送但是未收到確認。而發送窗口內靠前面的9個位元組時允許發送但未發送的。如圖所示：

而對於B，它的接收窗口大小是20，在接收窗口外面到30號位置的數據是接收並確認的，因此可以丟棄。在下圖中，B收到了32和33的數據，但它們不是按序到達的，因為並沒有收到31號數據。B只能對按序達收到的數據中的最高序號給出確認，因此B發送的確認報文欄位的確認號依然是31號。

現在假定B收到了序號為31的數據，並把31～33的數據交付主機，然後B刪除這些數據。接著把窗口向前移動3個序號，同時給a發送確認，其中的窗口值仍為20，但確認號變為34。表明B已經收到序號33為止的數據。

因為TCP的發送方在規定的時間內沒有收到確認就要重傳已經發送的報文段，但是重傳時間的選擇卻TCP最復雜的問題之一。為此TCP採用了一種自適應演算法，它記錄了一個報文段發出的時間以及收到相應的確認的時間。這兩個時間之差就是報文段的往返時間RTT，同時TCP保留了RTT的加權平均往返時間RTTs。而RTTD是RTT的偏差加權平均值，它與RTTs和新的RTT樣本之差有關。

超時重傳時間的演算法如下：
第一次測量時，加權平均往返時間取往返時間RTT，以後每次測量到一個新的RTT，按以下公式計算：

第一次測量時，RTT偏差的加權平均等於RTT的一半，以後的測里中，按以下公式計算：

綜上超時重傳時間RTO計算如下：

若收到的報文無差錯，只是未按序號，使用選擇確認SACK可是讓發送方發送那些未收到的數據，而不重復發送已經收到的那些數據。如果要使用選擇確認SACK，那麼在建立TCP連接時，就要在TCP首部的選項中加上「允許SACK」的選項，並且雙方必須都事先商量好。

流量控制就是指讓發送方的發送速率不要太快，要讓接收方來得及接收。而利用滑動窗口機制就可以很方便的在TCP連接上實現對發送方的流量控制。

如上圖所示，接收方B進行了三次流量控制。第一次把窗口減小到rwnd=300，第二次又減到rwnd=100，最後是rwnd=0，即不允許發送方再發送數據了。

但是我們應該考慮一種情況，就是當接收方B的存儲已滿時，會向發送方發送零窗口的報文段，接著B的存儲又有了一些空間，B再向A發送一個不為零的窗口值，但這個報文丟失了，結果就是雙方一直等待下去。所以為了解決這個問題，TCP為每一個連接設有一個持續計時器。只要TCP連接的一方收到對方的零窗口通知，就啟動持續計時器，當計時器到期後，就發送一個探測段文段，而對方就在確認這個探測段時給出了現在的窗口值。如果窗口仍然是0，那麼收到這個報文段的一方就重新設置持續計時器，反之則死鎖的僵局就可以打破了。

應用程序把數據傳送到TCP的發送緩存後，TCP在何時發送這些數據？，在TCP的實現中廣泛使用了Nagle演算法。具體演算法如下：
（1）若發送應用進程要把數據逐個位元組地送到TCP的發送緩存，則發送方就把第一個數據位元組先發出去，把後面到達的數據位元組都緩存起來。
（2）方發送方收到對第一個數據位元組的確認後，再把發送緩存中的所有數據組裝成一個報文發送出去，同時繼續對後續到來的數據進行緩存。
（3）只有收到對前一個報文段的確認後才繼續發送下一個報文段。

當數據到達快而網路速度慢時，這種方法可以明顯減少網路帶寬。Nagle還規定：當到達的數據達到窗口的一半或最大報文長度時就立即發送一個報文。

但還還需要考慮一個叫做糊塗綜合征的問題，具體內容是若接收方的緩存已滿，應用進程每次只從緩存中取1個位元組，然後向發送方確認，並把窗口設為1個位元組（緩存只空了1個位元組的空間），接著發送方發來1個位元組，接收方發回確認，仍然將窗口設為1，這樣進行下去，網路的利用率很低。

為了解決這個問題，可以讓接收方等待一段時間，使得或者緩存已有足夠的空間或者等到接收緩存已有一半的空閑空間。此時，接收方就發出確認報文，並向發送方通知當前窗口的大小。

擁塞 是指在某一段時間內，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的性能就會變壞的情況。而所謂的 擁塞控制 就是防止過多的數據注入到網路當中，這樣可以使網路中的路由器或者鏈路不致過載，它是一個全局性的過程，涉及到所有的主機和路由器，而流量控制往往是指點對點通信量的控制。擁塞控制所要做的都有一個前提，就是網路能夠承受現有的網路負荷。

TCP進行擁塞控制的演算法有4種：慢開始、擁塞避免、快重傳和快恢復。下面在討論這些演算法時我們假定：
（1）數據是單方向傳送的，對方只傳送確認報文。
（2）接收方總是有足夠大的緩存空間。

發送方維持一個擁塞窗口的狀態變數，其大小取決於擁塞程度，並且動態變化。發送方讓自己的發送窗口小於擁塞窗口（如果考慮接收方的接收能力的話，發送窗口可能小於擁塞窗口）。發送方控制擁塞窗口的原則是：只要網路沒有擁塞，擁塞窗口就再增大一點，以便把更多的分組發送出去，只要出現擁塞，就減小擁塞窗口，以減少注入到網路的分組數。

下面會從「慢開始演算法」講起來討論擁塞窗口的大小如何變化的。

慢開始的演算法思路是：當主機開始發送數據時，由於並不清楚網路的負荷情況，所以如果立即把大量數據位元組注入到網路中，就有可能引起網路擁塞。因此會採用由小逐漸增大發送窗口。即在通常開始發送報文時，先將擁塞窗口cwnd的值設為一個最大報文段MSS的數值，而在每收到一個新的報文段確認後，把擁塞窗口增加至多一個MSS的數值。

如上圖所示，開始時cwnd=1，發送方發送一個M1，接收方收到M1發送確認，發送方收到一個確認後將cwnd加1，此時cwnd=2，因此發送方發送M2和M3兩個報文段，接收方收到後返回兩個確認，因此cwnd增加兩次，此時cwnd=4，接著發送方發送M4～M7四個報文段。依次類推。因此使用慢開始演算法後，每經過一個傳輸輪次，擁塞窗口就加倍。

但是為了防止擁塞窗口cwnd增加過大導致網路擁塞，需要設置一個慢開始門限ssthresh，慢開始門限用法如下：
當cwnd<ssthresh時，使用上述的慢開始演算法。
當cwnd>ssthresh時，停止使用慢開始演算法，使用擁塞避免演算法。
當cwnd=ssthresh時，既可以使用慢開始演算法，也可以使用擁塞避免演算法。
這里的擁塞避免演算法是指讓擁塞窗口緩慢的增大，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是像慢開始階段那樣加倍增長。

需要注意的是無論在慢開始階段還是擁塞避免階段，只要發送方判斷網路出現擁塞（根據是沒有按時收到確認），立即把慢開始門限ssthresh設為出現擁塞時的發送窗口的一半。然後發送窗口cwnd重新設為1，執行慢開始演算法。目的是迅速減少主機發送到網路分組的分組數。

快重傳演算法要求接收方每收到一個失序的報文段後就立即發送重復確認，如下圖接收了M1和M2後，又接收到一個M4，M4屬於失序報文，則發送對M2的重復確認。發送方只要連續收到三次確認重復就立即重傳對方未收到的報文段M3。

與快重傳演算法配合的還有快恢復演算法，過程如下：
（1）當發送方連續收到三個重復確認時，就把慢開始門限ssthresh減半，這是為了防止網路擁塞，接著並不執行慢開始演算法。
（2）由於上圖這種情況很可能不是因為網路擁塞引起的，因此這里不執行慢開始演算法（即不把擁塞窗口cwnd設為1，這樣速度太慢），而是把cwnd值設置為慢開始門限ssthresh減半後的數值，然後開始執行擁塞避免演算法。

TCP的運輸連接有是三個階段：連接建立、數據傳送和連接釋放。在TCP的連接過程中要解決以下三個問題：
（1）要使每一方能夠確知對方的存在。
（2）要允許雙方協商一些參數（如最大窗口值、是否使用窗口擴大選項和時間戳選項以及服務質量）。
（3）能夠對運輸實體資源進行分配。

TCP建立連接的過程叫做握手，握手需要在客戶和伺服器之間交換3個TCP報文段。如圖是三報文握手建立的連接過程：

A最後還要發送一次確認的原因是為了防止已經失效的連接請求報文段突然又傳送到了B，因而產生錯誤。試想一種情況：如果只有第一次和第二次握手，第二次B向A發送的確認丟失了，此時B進入了連接建立狀態，A沒有收到確認，過一段時間後會再次向B發送連接請求，B收到後又會再次建立連接，白白浪費B的資源。

A在TIME-WAIT狀態等待2MSL（MSL，最長報文段壽命），主要是因為以下兩點考慮：首先是為了保證A發送的最後一個ACK報文段能夠到達B，因為這個ACK報文段可能丟失，此時B會重傳連接釋放報文，如果A已經關閉，則無法收到這個報文。其次，當A在發送完最後一個ACK報文段後，再經過時間2MSL，就可以使本連接持續時間內產生的所有報文段都從網路中消失。這樣，下一個新連接中不會出現這種舊的連接請求報文段。

在圖中每一個方框即TCP可能具有的狀態。每個方框中的大寫英文字元串時TCP標准所使用的的TCP連接狀態名。狀態之間的箭頭表示可能發生的狀態變遷。箭頭旁邊的字表明引起這種變遷的原因，或表明發生狀態變遷後又出現什麼動作，在圖中粗實線箭頭表示對客戶進程的正常變遷，粗虛線箭頭表示對伺服器進程的正常變遷，細線箭頭表示異常變遷。

❸ 運輸層知識要點——謝希仁《計算機網路》

為了在計算機網路中有條不紊地交換數據，就必須遵守一些事先約定好的規則。這些規則明確規定了所 交換數據的格式 以及有關的 同步 問題。

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

網路協議：為進行網路中的數據交換而建立的規則、標准或約定。

網路協議由以下三個要素組成：

   1）語法：即數據與控制信息的結構或格式

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

   3）同步：即事件實現順序的詳細說明

一、運輸層協議的概述

   1.1 進程之間的通信

   1.2 運輸層的兩個主要協議

   1.3 運輸層的埠

二、用戶數據報協議UDP

   2.1 UDP概述

   2.2 UDP的首部格式

三、傳輸控制協議TCP概述

   3.1 TCP的最主要的特點

   3.2 TCP的連接

四、可靠傳輸的工作原理

   4.1 停止等待協議

   4.2 連續ARQ協議

五、TCP報文段的首部格式

六、TCP可靠傳輸的實現

   6.1 以位元組為單位的滑動窗口

   6.2 超時重傳時間的選擇

   6.3 選擇確認SACK

七、TCP的流量控制

   7.1 利用滑動窗口實現流量控制

   7.2 必須考慮傳輸效率

八、TCP的擁塞控制

   8.1 擁塞控制的一般原理

   8.2 幾種擁塞控制方法

   8.3 隨機早期檢測RED

九、TCP的運輸連接管理

   9.1 TCP的連接建立

   9.2 TCP的連接釋放

   9.3 TCP的有限狀態機

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

1.1 進程之間的通信

1.只有主機的協議棧才有運輸層，而網路核心部分中的路由器在轉發分組時都只用到了下三層的功能

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

網路層時為主機之間提供邏輯通信，而運輸層為應用進程之間提供端到端的邏輯通信。

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

1.2 運輸層的兩個主要協議

1.UDP—User Datagram Protocol 用戶數據報協議（無連接）：DNS/RIP/DHCP/SNMP/NFS

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

1.3 運輸層的埠

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

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

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

埠分為兩大類：

1）伺服器使用的埠號：熟知埠號或系統埠號（0~1023）；登記埠號（1024~49151）

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

2.1 UDP概述

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

2.特點

   1）無連接

   2）盡最大努力交付

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

   4）UDP沒有擁塞控制

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

   6）UDP的首部開銷小，只有8位元組

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

2.2 UDP的首部格式

1.traceroute 讓發送的UDP用戶數據報故意使用一個非法的UDP埠號，接收方丟棄報文，並由ICMP（網路控制報文協議）發送「埠不可達」差錯報文給發送方。

2.計算檢驗和。IP數據報的校驗和只檢驗IP數據報的首部，但UDP的校驗和是把首部和數據部分一起都檢驗。（12位元組的首部+真正的首部+數據來進行校驗和的計算）

   Q1.為什麼計算校驗和要加12位元組的偽首部

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

3.1 TCP的最主要的特點

1.面向連接的運輸層協議（建立連接、傳輸數據、釋放連接）

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

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

4.全雙工通信。TCP連接的兩端都設有發送緩存和接收緩存。

5.面向位元組流。（流指的是流入到進程或從進程流出的位元組序列；面向位元組流：TCP把應用程序交下來的數據看成是一連串的無結構位元組流。 接收方的應用程序必須有能力識別接收到的位元組流，把它還原成有意義的應用層數據。 因此TCP可以根據窗口值和當前網路狀況調整發送的報文長度。劃分短一點，或者積累到足夠多再發送出去。）

3.2 TCP的連接

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

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

   套接字soket = （IP地址：埠號）

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

   TCP連接 ::= {socket1, socket2}

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

   1）傳輸信道不產生差錯

   2）不管發送方以多快的速度發送數據，接收方總是來得及處理收到的數據

實際的網路並不具備，因此：

   1）出現差錯時，讓發送方重傳

   2）接收方來不及處理時，及時告訴發送方適當降低發送數據的速度

4.1 停止等待協議

1.「停止等待」就是沒發送完一個分組就停止發送，等待對方的確認，在收到確認後再發送下一個分組。

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

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

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

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

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

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

   U=Td/(Td+RTT+Ta)

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

4.2 連續ARQ協議

1.位於發送窗口內的分組都可連續發送出去，而不需要等待對方的確認。

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

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

1.源埠和目的埠

2.序號。 每個位元組都按順序編號。

3.確認號。 期望收到對方下一個報文段的第一個數據位元組的序號。

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

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

5.窗口。窗口欄位明確指出了現在允許對方發送的數據量。窗口值是經常在動態變化著。

6.1 以位元組為單位的滑動窗口

1.發送緩存用來暫存：

   1）發送應用程序傳送給發送方TCP准備發送的數據；

   2）TCP已發送但未收到確認德爾數據

2.接收緩存用來存放：

   1）按序到達的、但尚未被接收應收程序讀取的數據；

   2）未按序到達的數據

3.注意三點：

   1）A的發送窗口是根據B的接收窗口設置的，但是在同一時刻，由於網路傳輸的滯後，A的發送窗口並不總是B的接收窗口一樣大

   2）TCP通常對不按序到達的數據是先臨時存放在接收窗口中，等到位元組流中所缺少的位元組收到後，再按序交付上層的應用進程

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

6.2 超時重傳時間的選擇

1.超時重傳時間設置太短，會引起很多不必要的重傳；如果設置太長，使網路的空閑時間增大，降低傳輸效率。

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

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

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

4.一個問題：發送一個報文段，設定的重傳時間到了，還沒有收到確認。於是重傳報文段。經過一段時間，收到了確認報文段。現在的問題是：如何判定此確認報文段是對先發送的報文段的確認，還是對後來重傳的報文段的確認？

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

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

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

6.3 選擇確認SACK

SACK文檔並沒有指明發送發應當怎樣響應SACK。因此大多數的實現還是重傳所有未被確認的數據塊。

7.1 利用滑動窗口實現流量控制

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

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

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

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

7.2 必須考慮傳輸效率

1.應用程序把數據傳送到TCP的發送緩存後，剩下的發送任務就由TCP來控制了。

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

   1）TCP維持一個變數，它等於最大報文段長度MSS，只要緩存中的存放的數據達到MSS，就組裝成一個TCP報文段發送出去

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

   3）發送方設置一個定時器

3.問題一、若用戶只發送一個位元組，則非常浪費帶寬。

解決方法：若發送應用程序把要發送的數據逐個位元組地送到TCP的發送緩存，則發送方就把第一個數據位元組先發送出去，把後面到達的數據位元組都緩存起來。當發送方收到對第一個數據字元的確認後，再把發送緩存中的所有數據組裝成一個報文段發送出去。（採用收到確認就發送+並開始緩存的方式；同時當到達的數據已達到發送窗口大小的一半或已達到報文段的最大長度時，就立即發送一個報文段。）

4.問題二、糊塗窗口綜合症。接收緩存已滿，應用程序一次只讀取一個位元組，然後向發送方發送確認。

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

8.1 擁塞控制的一般原理

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

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

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

   1）擁塞控制：防止過多的數據注入到網路中，這樣可以使網路中的路由器或鏈路不致過載。

   擁塞控制有個前提：網路能夠承受現有的網路負荷

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

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

   流量控制：抑制發送端發送數據的速率，以便使接收端來得及接收。

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

5.計算機網路是個復雜的系統。從控制理論的角度來看擁塞控制，可以分為開環控制和閉環控制兩種方法。

   1）開環控制：設計網路時事先將有關發生擁塞的因素考慮周到，力求網路在工作時不產生擁塞。但一旦系統運行起來，就不再中途改正。

   2）閉環控制：基於反饋環路。

   步驟一、監測網路系統以便檢測到擁塞在何時、何處發生；

   步驟二、把擁塞發生的信息傳送到可採取行動的地方

   步驟三、調整網路系統的運行以解決出現的問題

8.2 幾種擁塞控制方法（只考慮網路擁塞程度，即假設接收方總是有足夠大的緩存空間）

1.慢開始和擁塞避免

1）發送方維持一個擁塞窗口。

   擁塞窗口的大小取決於網路的擁塞程度，並且動態地在變化。

   控制擁塞窗口的原則是：只要網路沒有出現擁塞，擁塞窗口增大；如果網路出現擁塞，則減小。

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

輪次：把擁塞窗口所允許發送的報文段都連續發送出去，並收到了對已發送的最後一位元組的確認。

慢開始的「慢」並不是指cwnd的增長速率慢，而是指TCP開始發送報文段時先設置cwnd=1（一個MSS數值）。

3）慢開始門限ssthresh

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

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

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

4）擁塞避免演算法

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

5）慢開始門限的設置

只要發送方判斷網路出現擁塞（沒有按時收到確認），就把慢開始門限ssthresh設置為出現擁塞時發送方窗口值的一半，然後把擁塞窗口cwnd重置為1，執行慢開始演算法。

6）乘法減小和加法增大

乘法減小：網路出現擁塞時，把慢開始門限ssthresh減半（當前的ssthresh的一半），並執行慢開始演算法。

加法增大：執行擁塞避免方法

2.快重傳和快恢復

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

首先，要求接收方每收到一個失序的報文段後就立即發出重復確認。（如接收方收到了M1和M2後都分別發出了確認，但接收方沒有收到M3但接著收到了M4。此時接收方立即發送對M2的重復確認。）

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

2）快恢復

要點一、當發送方連續收到三個重復確認，就執行「乘法減小」演算法，把慢開始門限ssthresh減半。

要點二、由於發送方認為網路很可能沒有發生擁塞（因為收到了連續的重復確認），把cwnd設置為慢開始門限ssthresh減半後的值，然後開始執行擁塞避免演算法

慢開始演算法只在TCP連接建立時和網路出現超時才使用。

3.發送方的窗口

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

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

1.網路層的分組丟棄策略

網路層的策略對TCP擁塞控制影響最大的就是路由器的分組丟棄策略。

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

2.全局同步

由於TCP復用IP，若發生路由器中的尾部丟棄，就可能會同時影響到很多條TCP連接，結果就使許多TCP連接在同一時間突然都進入到慢開始狀態。全局同步使得全網的通信量突然下降了很多，網路恢復正常後，其通信量又突然增大很多。

3.隨機早期檢測RED

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

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

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

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

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

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連接建立過程中要解決以下三個問題：

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

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

   3）能夠對運輸實體資源（如緩存大小、連接表中的項目等）進行分配

9.1 TCP的連接建立

1.TCP規定，SYN=1報文段不能攜帶數據，但消耗一個序號

2.TCP規定，ACK=1報文段可以攜帶數據，如果不攜帶數據則不消耗序號

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

「已失效的連接請求報文段」

A發出第一個連接請求報文段，在網路中滯留超時，又發出了第二個連接請求。但B收到第一個延遲的失效的連接請求報文段後，就誤認為是A又發出了一次新的連接請求。於是就向A發出確認報文段，同意建立連接。假定不採用三次握手，那麼只要B發出確認，新的連接就建立。此時A不會理睬B的確認，也不會發數據，但B一直等A發送數據，B的許多資源就浪費了。

採用三次握手，A不會向B發送確認，因此B就知道A並沒有要求建立確認。

9.2 TCP的連接釋放

1.TCP規定，FIN報文段基石不攜帶數據，也消耗一個序號

2.第二次握手後，TCP通知高層應用程序，因而從A到B這個方向的連接就釋放，TCP連接處於半關閉狀態

3.為什麼A在TIME-WAIT狀態必須等待2MSL的時間

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

  2）防止「已失效的連接請求報文段」出現在本連接中。可以使本連接持續時間內所產生的所有報文段都從網路中消失。

9.3 TCP的有限狀態機

❹ 網路 之 三次握手&四次揮手 介紹

要了解三次握手&四次揮手的過程，就需要對TCP的報頭以及有限狀態機的概念有所了解，本文將介紹TCP報頭的欄位的含義，以及有限狀態機各個狀態的意義，最後對三次握手和四次揮手的過程做介紹

TCP（Transmission Control Protocol 傳輸控制協議）是一種面向連接的、可靠的、基於位元組流的傳輸層通信協議，由IETF的RFC 793定義。在簡化的計算機網路OSI模型中，它完成第四層傳輸層所指定的功能，用戶數據報協議（UDP）是同一層內另一個重要的傳輸協議。在網際網路協議族（Internet protocol suite）中，TCP層是位於IP層之上，應用層之下的中間層。不同主機的應用層之間經常需要可靠的、像管道一樣的連接，但是IP層不提供這樣的流機制，而是提供不可靠的包交換。

這里將介紹TCP報頭的特性以及TCP報頭各個欄位的含義

.工作在傳輸層面向連接協議

.全雙工協議

.半關閉

.錯誤檢查

.將數據打包成段，排序

.確認機制

.數據恢復，重傳

.流量控制，滑動窗口

.擁塞控制，慢啟動和擁塞避免演算法

.源埠、目標埠 ：計算機上的進程要和其他進程通信是要通過計算機埠的，而一個計算機埠某個時刻只能被一個進程佔用，所以通過指定源埠和目標埠，就可以知道是哪兩個進程需要通信。源埠、目標埠是用16位表示的，可推算計算機的埠個數為2^16個

. 序列號 ：表示本報文段所發送數據的第一個位元組的編號。在TCP連接中所傳送的位元組流的每一個位元組都會按順序編號。由於序列號由32位表示，所以每2^32個位元組，就會出現序列號回繞，再次從0 開始

. 確認號 ：表示接收方期望收到發送方下一個報文段的第一個位元組數據的編號。也就是告訴發送發：我希望你（指發送方）下次發送的數據的第一個位元組數據的編號是這個確認號

. 數據偏移 ：表示TCP報文段的首部長度，共4位，由於TCP首部包含一個長度可變的選項部分，需要指定這個TCP報文段到底有多長。它指出TCP 報文段的數據起始處距離TCP 報文段的起始處有多遠。該欄位的單位是32位(即4個位元組為計算單位），4位二進制最大表示15，所以數據偏移也就是TCP首部最大60位元組

. URG ：表示本報文段中發送的數據是否包含緊急數據。後面的緊急指針欄位（urgent pointer）只有當URG=1時才有效

. ACK ：表示是否前面的確認號欄位是否有效。ACK=1，表示有效。只有當ACK=1時，前面的確認號欄位才有效。TCP規定，連接建立後，ACK必須為1,帶ACK標志的TCP報文段稱為確認報文段

. PSH ：提示接收端應用程序應該立即從TCP接收緩沖區中讀走數據，為接收後續數據騰出空間。如果為1，則表示對方應當立即把數據提交給上層應用，而不是緩存起來，如果應用程序不將接收到的數據讀走，就會一直停留在TCP接收緩沖區中

. RST ：如果收到一個RST=1的報文，說明與主機的連接出現了嚴重錯誤（如主機崩潰），必須釋放連接，然後再重新建立連接。或者說明上次發送給主機的數據有問題，主機拒絕響應，帶RST標志的TCP報文段稱為復位報文段

. SYN ：在建立連接時使用，用來同步序號。當SYN=1，ACK=0時，表示這是一個請求建立連接的報文段；當SYN=1，ACK=1時，表示對方同意建立連接。SYN=1，說明這是一個請求建立連接或同意建立連接的報文。只有在前兩次握手中SYN才置為1，帶SYN標志的TCP報文段稱為同步報文段

. FIN ：表示通知對方本端要關閉連接了，標記數據是否發送完畢。如果FIN=1，即告訴對方：「我的數據已經發送完畢，你可以釋放連接了」，帶FIN標志的TCP報文段稱為結束報文段

. 窗口大小 ：表示現在充許對方發送的數據量，也就是告訴對方，從本報文段的確認號開始允許對方發送的數據量

. 校驗和 ：提供額外的可靠性

. 緊急指針 ：標記緊急數據在數據欄位中的位置

. 選項部分 ：其最大長度可根據TCP首部長度進行推算。TCP首部長度用4位表示，選項部分最長為：(2^4-1)*4-20=40位元組

常見選項 ：

.最大報文段長度：MaxiumSegment Size，MSS

.窗口擴大：Windows Scaling

.時間戳：Timestamps

.a 最大報文段長度

指明自己期望對方發送TCP報文段時那個數據欄位的長度。默認是536位元組。數據欄位的長度加上TCP首部的長度才等於整個TCP報文段的長度。MSS不宜設的太大也不宜設的太小。若選擇太小，極端情況下，TCP報文段只含有1位元組數據，在IP層傳輸的數據報的開銷至少有40位元組（包括TCP報文段的首部和IP數據報的首部）。這樣，網路的利用率就不會超過1/41。若TCP報文段非常長，那麼在IP層傳輸時就有可能要分解成多個短數據報片。在終點要把收到的各個短數據報片裝配成原來的TCP報文段。當傳輸出錯時還要進行重傳，這些也都會使開銷增大。因此MSS應盡可能大，只要在IP層傳輸時不需要再分片就行。在連接建立過程中，雙方都把自己能夠支持的MSS接入這一欄位。MSS只出現在SYN報文中。即：MSS出現在SYN=1的報文段中

.b 窗口擴大

為了擴大窗口，由於TCP首部的窗口大小欄位長度是16位，所以其表示的最大數是65535。但是隨著時延和帶寬比較大的通信產

生（如衛星通信），需要更大的窗口來滿足性能和吞吐率，所以產生了這個窗口擴大選項

.c 時間戳

可以用來計算RTT(往返時間)，發送方發送TCP報文時，把當前的時間值放入時間戳欄位，接收方收到後發送確認報文時，把這個時間戳欄位的值復制到確認報文中，當發送方收到確認報文後即可計算出RTT。也可以用來防止回繞序號PAWS，也可以說可以用來區分相同序列號的不同報文。因為序列號用32為表示，每2^32個序列號就會產生回繞，那麼使用時間戳欄位就很容易區分相同序列號的不同報文

2.3 TCP協議PORT

.傳輸層通過port號，確定應用層協議

.Port number:

. tcp ：0-65535,傳輸控制協議，面向連接的協議；通信前需要建立虛擬鏈路；結束後拆除鏈路.

. udp ：0-65535,User Datagram Protocol，無連接的協議.

. IANA :互聯網數字分配機構（負責域名，數字資源，協議分配）

0-1023：系統埠或特權埠(僅管理員可用) ，眾所周知，永久的分配給固定的系統應用使用，22/tcp(ssh), 80/tcp(http), 443/tcp(https)

1024-49151：用戶埠或注冊埠，但要求並不嚴格，分配給程序注冊為某應用使用，1433/tcp(SqlServer)，1521/tcp(oracle),

3306/tcp(mysql),11211/tcp/udp(memcached)

49152-65535：動態埠或私有埠，客戶端程序隨機使用的埠

其范圍的定義：/proc/sys/net/ipv4/ip_local_port_range

有限狀態機，（英語：Finite-state machine, FSM），又稱有限狀態自動機，簡稱狀態機，是表示有限個狀態以及在這些狀態之間的轉移和動作等行為的數學模型。

常見的計算機就是使用有限狀態機作為計算模型的：對於內存的不同狀態，CPU通過讀取內存值進行計算，更新內存中的狀態。CPU還通過消息匯流排接受外部輸入設備（如鍵盤、滑鼠）的指令，計算後更改內存中的狀態，計算結果輸出到外部顯示設備（如顯示器），以及持久化存儲在硬碟。

TCP協議也存在有限狀態機的概念，TCP 協議的操作可以使用一個具有 11 種狀態的有限狀態機來表示

.CLOSED 沒有任何連接狀態

.LISTEN 偵聽狀態，等待來自遠方TCP埠的連接請求

.SYN-SENT 在發送連接請求後，等待對方確認

.SYN-RECEIVED 在收到和發送一個連接請求後，等待對方確認

.ESTABLISHED 代表傳輸連接建立，雙方進入數據傳送狀態

.FIN-WAIT-1 主動關閉,主機已發送關閉連接請求，等待對方確認

.FIN-WAIT-2 主動關閉,主機已收到對方關閉傳輸連接確認，等待對方發送關閉傳輸連接請求

.TIME-WAIT 完成雙向傳輸連接關閉，等待所有分組消失

.CLOSE-WAIT 被動關閉,收到對方發來的關閉連接請求，並已確認

.LAST-ACK 被動關閉,等待最後一個關閉傳輸連接確認，並等待所有分組消失

.CLOSING 雙方同時嘗試關閉傳輸連接，等待對方確認

.客戶端通過connect系統調用主動與伺服器建立連接connect系統調用首先給伺服器發送一個同步報文段，使連接轉移到SYN_SENT狀態。

.此後connect系統調用可能因為如下兩個原因失敗返回：

.1、如果connect連接的目標埠不存在（未被任何進程監聽），或者該埠仍被處於TIME_WAIT狀態的連接所佔用（見後文），則伺服器將給客戶端發送一個復位報文段，connect調用失敗。

.2、如果目標埠存在，但connect在超時時間內未收到伺服器的確認報文段，則connect調用失敗。

.connect調用失敗將使連接立即返回到初始的CLOSED狀態。如果客戶端成功收到伺服器的同步報文段和確認，則connect調用成功返回，連接轉移至ESTABLISHED狀態

.當客戶端執行主動關閉時，它將向伺服器發送一個結束報文段FIN，同時連接進入FIN_WAIT_1狀態。若此時客戶端收到伺服器專門用於確認目的的確認報文段，則連接轉移至FIN_WAIT_2狀態。當客戶端處於FIN_WAIT_2狀態時，伺服器處於CLOSE_WAIT狀態，這一對狀態是可能發生半關閉的狀態。此時如果伺服器也關閉連接（發送結束報文段），則客戶端將給予確認並進入TIME_WAIT狀態

.客戶端從FIN_WAIT_1狀態可能直接進入TIME_WAIT狀態（不經過FIN_WAIT_2狀態），前提是處於FIN_WAIT_1狀態的伺服器直接收到帶確認信息的結束報文段（而不是先收到確認報文段，再收到結束報文段）

注意，客戶端先發送一個FIN給服務端，自己進入了FIN_WAIT_1狀態，這時等待接收服務端的報文，該報文會有三種可能：

a 只有服務端的ACK，只收到伺服器的ACK，客戶端會進入FIN_WAIT_2狀態，後續當收到服務端的FIN時，回應發送一個ACK，會進入到TIME_WAIT狀態，這個狀態會持續2MSL(TCP報文段在網路中的最大生存時間,RFC 1122標準的建議值是2min).客戶端等待2MSL，是為了當最後一個ACK丟失時，可以再發送一次。因為服務端在等待超時後會再發送一個FIN給客戶端，進而客戶端知道ACK已丟失

b 只有服務端的FIN，回應一個ACK給服務端，進入CLOSING狀態，然後接收到服務端的ACK時，進入TIME_WAIT狀態

c 同時收到服務端的ACK和FIN，直接進入TIME_WAIT狀態

.收到伺服器ACK後，客戶端處於FIN_WAIT_2狀態，此時需要等待伺服器發送結束報文段，才能轉移至TIME_WAIT狀態，否則它將一直停留在這個狀態。如果不是為了在半關閉狀態下繼續接收數據，連接長時間地停留在FIN_WAIT_2狀態並無益處。連接停留在FIN_WAIT_2狀態的情況可能發生在：客戶端執行半關閉後，未等伺服器關閉連接就強行退出了。此時客戶端連接由內核來接管，可稱之為孤兒連接（和孤兒進程類似）。

.Linux為了防止孤兒連接長時間存留在內核中，定義了兩個內核參數：

./proc/sys/net/ipv4/tcp_max_orphans 指定內核能接管的孤兒連接數目

./proc/sys/net/ipv4/tcp_fin_timeout指定孤兒連接在內核中生存的時間

TCP協議中的三次握手和四次揮手

客戶機端的三次握手和四次揮手

伺服器端的三次握手和四次揮手

1 client 首先發送一個連接試探，此時ACK=0,表示確認號無效，SYN=1表示這是一個請求連接或連接接受報文，同時表示這個數據包不攜帶數據，seq=x表示此時client自己數據的初始序號是x,這時候client進入syn_sent狀態，表示客戶端等等伺服器的回復

2 server 監聽到連接請求報文後，如同意建立連接，則向client發送確認，將TCP報文首部的SYN和ACK都置為1，因為client上一個請求連接的報文中seq=x,所以伺服器端這次就發ack=x+1,表示伺服器端希望客戶端下一個報文段的第一個數據位元組序號是x+1，同時表示x為止的所有數據都已經正確收到了，其中，此時伺服器端發送seq=y表示server自己的初始序號是y，這時伺服器進入了SYN_RCVD狀態，表示伺服器已經收到了客戶端的請求，等待client的確認。

3 client收到確認後還要再次給伺服器端發送確認，同時攜帶要發給server的數據。ACK=1表示確認號ack=y+1有效，client這時的序號seq為x+1

一旦client確認後，這個TCP連接的client 和 server 都直接進入到established狀態，可以發起http請求了

4.2 四次揮手詳解

第一次揮手：client向server，發送FIN報文段，表示關閉數據傳送，此時ACK=0,seq=u,表示客戶端此時數據的報文序號是u，此時，client進入FIN_WAIT_1狀態，表示沒有數據要傳輸了

第二次揮手：server收到FIN報文段後進入CLOSE_WAIT狀態（被動關閉），然後發送ACK確認，表示同意你關閉請求了，主機到主機的數據鏈路關閉，同時發送seq=v,表示此時server端的數據包位元組序號是v,ack=u+1,表示希望client發送的下一個包的序號是u+1,表示確認了序號u之前的包都已經收到，客戶端收到server的ACK報文後，進入FIN_WAIT_2狀態

第三次揮手：server等待client發送完數據，發送FIN=1，ACK=1到client請求關閉，server進入LAST_ACK狀態。此時發送的seq有變化，因為上一個ACK的後server端可能又發送了一些數據，說以數據位元組序號發送了變化，為w,但是ack還是保持不變

第四次揮手：client收到server發送的FIN後，回復ACK確認到server，client進入TIME_WAIT狀態。發送ack=w+1,表示希望伺服器下個發送的報文的位元組序號是w+1,確認了伺服器之前發送的w位元組都已經正確收到，發送seq=u+1表示當前client的位元組序號是u+1.server收到client的ACK後就關閉連接了，狀態為CLOSED。client等待2MSL，仍然沒有收到server的回復，說明server已經正常關閉了，client關閉連接。

其中，MSL（Maximum Segment Lifetime）：報文最大生存時間，是任何報文段被丟棄前在網路內的最長時間。當client回復server的FIN後，等待(2-4分鍾)，即使兩端的應用程序結束。

TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態的原因是如果client直接進入CLOSED狀態，由於IP協議不可靠性或網路問題，導致client最後發出的ACK報文未被server接收到，那麼server在超時後繼續向client重新發送FIN，而client已經關閉，那麼找不到向client發送FIN的連接，server這時收到RST並把錯誤報告給高層，不符合TCP協議的可靠性特點。如果client直接進入CLOSED狀態，而server還有數據滯留在網路中，當有一個新連接的埠和原來server的相同，那麼當原來滯留的數據到達後，client認為這些數據是新連接的。等待2MSL確保本次連接所有數據消失。

當客戶端等待2MSL後伺服器端沒有再次發送確認的報文後，client認為該次斷開連接已經正常結束，client進入closed狀態。四次揮手正式結束

❺ 運輸層為什麼要提供TCP和UDP兩個協議

TCP 是全雙工的，在斷開連接時兩端都需要發送 FIN 和 ACK。

第一次握手

若客戶端 A 認為數據發送完成，則它需要向服務端 B 發送連接釋放請求。

第二次握手

B 收到連接釋放請求後，會告訴應用層要釋放 TCP 鏈接。然後會發送 ACK 包，並進入 CLOSE_WAIT 狀態，此時表明 A 到 B 的連接已經釋放，不再接收 A 發的數據了。但是因為 TCP 連接是雙向的，所以 B 仍舊可以發送數據給 A。

第三次握手

B 如果此時還有沒發完的數據會繼續發送，完畢後會向 A 發送連接釋放請求，然後 B 便進入 LAST-ACK 狀態。

第四次握手

A 收到釋放請求後，向 B 發送確認應答，此時 A 進入 TIME-WAIT 狀態。該狀態會持續 2MSL（最大段生存期，指報文段在網路中生存的時間，超時會被拋棄） 時間，若該時間段內沒有 B 的重發請求的話，就進入 CLOSED 狀態。當 B 收到確認應答後，也便進入 CLOSED 狀態。

3. TCP協議的特點

面向連接

面向連接，是指發送數據之前必須在兩端建立連接。建立連接的方法是「三次握手」，這樣能建立可靠的連接。建立連接，是為數據的可靠傳輸打下了基礎。

僅支持單播傳輸

每條TCP傳輸連接只能有兩個端點，只能進行點對點的數據傳輸，不支持多播和廣播傳輸方式。

面向位元組流

TCP不像UDP一樣那樣一個個報文獨立地傳輸，而是在不保留報文邊界的情況下以位元組流方式進行傳輸。

可靠傳輸

對於可靠傳輸，判斷丟包，誤碼靠的是TCP的段編號以及確認號。TCP為了保證報文傳輸的可靠，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的位元組發回一個相應的確認(ACK)；如果發送端實體在合理的往返時延(RTT)內未收到確認，那麼對應的數據（假設丟失了）將會被重傳。

提供擁塞控制

當網路出現擁塞的時候，TCP能夠減小向網路注入數據的速率和數量，緩解擁塞

TCP提供全雙工通信

TCP允許通信雙方的應用程序在任何時候都能發送數據，因為TCP連接的兩端都設有緩存，用來臨時存放雙向通信的數據。當然，TCP可以立即發送一個數據段，也可以緩存一段時間以便一次發送更多的數據段（最大的數據段大小取決於MSS）

四、TCP和UDP的比較

1. 對比

UDP

TCP

是否連接 無連接 面向連接

是否可靠 不可靠傳輸，不使用流量控制和擁塞控制 可靠傳輸，使用流量控制和擁塞控制

連接對象個數 支持一對一，一對多，多對一和多對多交互通信 只能是一對一通信

傳輸方式 面向報文 面向位元組流

首部開銷 首部開銷小，僅8位元組 首部最小20位元組，最大60位元組

適用場景 適用於實時應用（IP電話、視頻會議、直播等） 適用於要求可靠傳輸的應用，例如文件傳輸

2. 總結

TCP向上層提供面向連接的可靠服務 ，UDP向上層提供無連接不可靠服務。

雖然 UDP 並沒有 TCP 傳輸來的准確，但是也能在很多實時性要求高的地方有所作為

對數據准確性要求高，速度可以相對較慢的，可以選用TCP

❻ TIME_WAIT是什麼意思

一、TIME_WAIT的意思是結束了這次連接。

二、以tcp中time_wait狀態為例如下：

1、簡單來說：time_wait狀態是四次揮手中server向client發送FIN終止連接後進入的狀態。

❼ TCP四次分手中，主動關閉方最後為什麼要等待2MSL之後才關閉連接

因為主動方不確定對面是否收到關閉信息，

這個2MSL好像是一次消息回應的最大時長，超過這個時間了如果還是沒有消息，就判定為網路連接斷開了。因此，也可以關閉連接了。

❽ 計算機網路

TCP/IP五層協議的體系結構，自頂向下依次為：應用層、傳輸層、網路層、數據鏈路層、物理層。

不使用兩次握手和四次握手的原因

為什麼TIME_WAIT等待的時間是2MSL
MSL，Maximum Segment Lifetime英文的縮寫， 報文最大生存時間 ，它是任何報文在網路上存在的最長時間，超過這個時間將被丟棄。

概述

區別 ：

區別（表形式）

概念

超時時間應該設置為多少呢

8、快速重傳

概念

SACK（Selective Acknowledgment 選擇性確認），這種方式需要在 TCP 頭部選項欄位里加一個 叫SACK 的東西，它可以將 緩存的地圖發送給發送方 ，這樣發送方就可以知道哪些數據收到了，哪些數據沒收到，知道了這些信息，就可以 只重傳丟失的數據 。

D-SACK，其主要使用了 SACK 來 告訴發送方有哪些數據被重復接收了 。
下面以兩個例子，來說明D-SACK的作用。

D-SACK有這么幾個好處 ：

引入滑動窗口的原因

窗口的實現

窗口的大小

窗口應用示例

窗口的大小由哪一方決定？

TCP 利用滑動窗⼝實現流量控制。流量控制是為了控制發送方發送速率，保證接收方來得及接收（讓發送方根據接收方的實際接收能力控制發送的數據量）。 接收方發送的確認報文中的窗口欄位可以用來控制發送方窗口大小，從而影響發送方的發送速率。將窗口欄位設置為 0，則發送方不能發送數據。

HTTP協議的⻓連接和短連接，實質上是TCP協議的⻓連接和短連接。

HTTP 是⼀種不保存狀態的協議，即無狀態（stateless）協議。也就是說 HTTP 協議⾃身不對請求和響應之間的通信狀態進⾏保存。
無狀態的利弊：

對於無狀態的問題，解法方案有很多種，其中比較簡單的方式用 Cookie 技術 。Cookie的工作原理如下：
（1）瀏覽器端第一次發送請求到伺服器端
（2）伺服器端創建Cookie，該Cookie中包含用戶的信息，然後將該Cookie發送到瀏覽器端
（3）瀏覽器端再次訪問伺服器端時會攜帶伺服器端創建的Cookie
（4）伺服器端通過Cookie中攜帶的數據區分不同的用戶

此外，還有 Session 機制來解決這一問題。Session的工作原理如下：
（1）瀏覽器端第一次發送請求到伺服器端，伺服器端創建一個Session，同時會創建一個 特殊 的Cookie（name為JSESSIONID的固定值，value為session對象的ID），然後將該Cookie發送至瀏覽器端
（2）瀏覽器端發送第N（N>1）次請求到伺服器端,瀏覽器端訪問伺服器端時就會攜帶該name為JSESSIONID的Cookie對象
（3）伺服器端根據name為JSESSIONID的Cookie的value(sessionId),去查詢Session對象，從而區分不同用戶。

Cookie 和 Session都是⽤來跟蹤瀏覽器⽤戶身份的會話⽅式，但是兩者的應⽤場景不太⼀樣。

Cookie ⼀般⽤來保存⽤戶信息。比如①我們在 Cookie 中保存已經登錄過得⽤戶信息，下次訪問⽹站的時候⻚⾯可以⾃動幫你登錄的⼀些基本信息給填了；②⼀般的⽹站都會有保持登錄也就是說下次你再訪問⽹站的時候就不需要重新登錄了，這是因為⽤戶登錄的時候我們可以存放了⼀個Token 在 Cookie 中，下次登錄的時候只需要根據 Token 值來查找⽤戶即可(為了安全考慮，重新登錄⼀般要將 Token 重寫)；③登錄⼀次⽹站後訪問⽹站其他⻚⾯不需要重新登錄。

Session 的主要作⽤就是通過服務端記錄⽤戶的狀態。 典型的場景是購物⻋，當你要添加商品到購物⻋的時候，系統不知道是哪個⽤戶操作的，因為 HTTP 協議是⽆狀態的。服務端給特定的⽤戶創建特定的 Session 之後就可以標識這個⽤戶並且跟蹤這個⽤戶了。

Cookie數據存儲在客戶端（瀏覽器）中，⽽Session數據保存在伺服器上，相對來說 Session 安全性更⾼。如果要在Cookie 中存儲⼀些敏感信息，不要直接寫⼊ Cookie 中，最好能將 Cookie 信息加密然後使⽤到的時候再去伺服器端解密。

HTTP1.0最早在⽹⻚中使⽤是在1996年，那個時候只是使⽤⼀些較為為簡單的⽹⻚上和⽹絡請求上，⽽HTTP1.1則在1999年才開始⼴泛應⽤於現在的各⼤瀏覽器⽹絡請求中，同時HTTP1.1也是當前使⽤最為⼴泛的HTTP協議。 主要區別主要體現在：

URI的作⽤像身份證號⼀樣，URL的作⽤更像家庭住址⼀樣。URL是⼀種具體的URI，它不僅唯⼀標識資源，⽽且還提供了定位該資源的信息。