目錄
一、運輸層概述
二、用戶數據報協議UDP
三、傳輸控制協議TCP
3.1 TCP概述
3.2 TCP連接過程
四、可靠傳輸
五、流量控制
六、擁塞控制
一、運輸層概述
運輸層向它上面的應用層提供通信服務，它屬於面向通信部分的最高層，同時也是用戶功能中的最低層。當網絡的邊緣部分中的兩臺主機使用網絡的核心部分的功能進行通信的時候，只有主機的協議棧纔有運輸層，而網絡核心部分中的路由器在轉發分組時只用到下三層的功能。
從運輸層的角度看，通信的真正端點不是主機而是主機中的進程。也就是說，端到端的通信是應用進程之間的通信。
傳輸層的功能： 提供應用進程間的邏輯通信。(網絡層提供主機之間的邏輯通信)
由這裏可以看出，網絡層爲主機之間提供邏輯通信，而運輸層爲應用進程之間提供邏輯通信。邏輯通信的意思是，好像是這樣進行通信，但事實上並非這樣通信。中間要經過各種處理。
二、用戶數據報協議UDP
UDP只在IP數據報服務之上增加了複用分用和差錯檢測功能
UDP 的特點：
1、傳送數據前無需建立連接，數據到達後無需確認。減小開銷和發送數據之前的時延
2、不保證可靠交付。(交由應用層保證可靠交付)
3、面向報文，適合一次性傳輸少量數據的網絡應用，報文頭部短，傳輸開銷小。
4、UDP無擁塞控制，適合實時應用
5、UDP首部開銷小，8B。TCP20B
應用層給UDP多長的報文，UDP只加上首部發送。即一次發送一個完整報文。
UDP報文段
UDP數據報的組成
UDP校驗
UDP校驗只提供差錯檢測，在計算校驗和時，要在UDP用戶數據報之前臨時加上12B的僞首部。包括源IP地址字段、目的IP地址字段、全0字段、協議字段(封裝UDP報文的IP數據報首部協議字段爲17)、UDP長度字段(UDP首部8B+數據部分長度不包括僞首部)。僞首部只用於計算和驗證校驗和，既不向下傳送，也不向上遞交。
發送端：
1、填上僞首部。
.
2、校驗的時候如UDP數據報數據部分的長度不是偶數字節，則需要填入一個全0字節，保證UDP數據報是4B整數倍。但此字節和僞首部一樣不發送。
.
3、僞首部+首部+數據部分採用二進制反碼求和
.
4、將和進行求反碼，再填入檢驗和字段。
.
4、去掉僞首部發送。
接收端：
1、填上僞首部
.
2、僞首部+首部+數據部分採用二進制反碼求和
.
3、和全爲1則無差錯。否則校驗出UDP數據報是錯誤的，可以丟棄或者交付上層，但需要附上錯誤報告
通過僞首部，不僅可以檢查源端口號、目的端口號和UDP用戶數據報的數據部分，還可以檢查IP數據報的源IP地址和目的地址。
雖然該檢驗方法檢錯能力不強，但是簡單，處理快。
三、傳輸控制協議TCP
3.1 TCP 概述
上面提到UDP傳送數據之前不需要先建立連接，遠地主機的運輸層在收到UDP報文後，不需要給出任何確認。不需要提供可靠交付。
與UDP不同，TCP則需要提供面向連接的服務，在傳送數據之前必須先建立連接，傳送數據之後必須取消連接。TCP不提供廣播或多播服務。由於 TCP 要提供可靠的、面向連接的運輸服務，因此不可避免的增加了許多的開銷。如確認、流量控制及連接管理。
TCP的主要特點：
1、面向連接(虛連接)，不提供廣播或多播服務
.
2、每一條TCP連接只能有兩個端點，每一條TCP連接只能是點對點的。
.
3、TCP提供可靠交付的服務，無差錯、不丟失、不重複、按序到達。
.
4、提供全雙工通信。兩個端點都設置發送緩存(準備發送的數據和已發送但未確認的數據)和接受緩存(按序到達但未被應用程序讀取的數據和不要序到達的數據)
報文段頭部長，傳輸開銷大
.
5、面向字節流。TCP把應用程序交下來的數據看成無結構的字節流。
TCP報文段
序號：TCP連接中傳送的字節流中的每一個字節都是按順序編號，該字段表示本報文段所發送的數據的第一個字節的序號。
確認號：期望收到對方下一個報文段的第一個數據字節的序號。若確認號爲N，則證明序號Ｎ-1爲止的所有數據已經確認收到。
數據偏移(首部長度)：TCP報文段的數據起始距離TCP報文段的起始處有多遠，以4B爲單位。
緊急位URG：URG=1，表明此報文段有緊急數據，高優先級的數據，需要儘快傳送，不需要在緩存裏排隊，搭配緊急指針字段使用。優先傳送。
確認位ACK：ACK=1時確認號有效，建立連接後所有傳送的報文段都必須將ACK置1。
推送位PSH：PSH=1時，接收方儘快交付接收應用進程，不再等待緩存填滿再向上交付。優先交付。
復位RST：RST=1，表明TCP連接中出現嚴重出錯，必須釋放連接，然後重新建立連接。
同步位SYN：SYN=1，表明這是一個連接請求/連接接受報文。
終止FIN：FIN=1，釋放連接。
窗口：指發送本報文段的一方的接收窗口，即允許對方發送的數據量。
檢驗和：檢驗首部+數據，檢驗時加上12B僞首部，協議字段爲6。
緊急指針：URG=1時有意義，指本報文段中緊急數據的字節數
選項：最大報文段長度MSS(每一個TCP報文段中的數據字段的最大長度，默認536B)、窗口擴大(3B)、時間戳(10B(時間戳值字段4B和時間戳回送回答字段4B))、選擇確認(SACK)…
填充
在TCP報文段的首部中只有端口號而沒有IP地址。當TCP將其報文段交給IP層時，IP如何知道目的IP地址的？
3.2 TCP 連接過程
TCP連接過程中我們主要用到三個標識位：
SYN：SYN= 1 表示這是一個連接請求或連接接受報文。在建立連接時用來進行同步序號（個人理解是，在建立連接的時候，提醒對方記錄本方的起始序號）。當SYN=1而ACK=0時，表明這是一個連接請求報文段。對方若是同意建立連接，則應響應的報文段中使SYN=1、ACK=1。因此SYN=1表示該報文是一個連接請求報文或者是一個連接請求接收報文。
ACK：確認號只有在該位設置爲1的時候才生效，當該位爲0是表示確認號無效。TCP規定，在TCP連接建立後所有傳送的數據報文段ACK都必須設置爲1。
FIN：當 FIN = 1 時，表明此報文段的發送方的數據已經發送完畢，並要求釋放連接。
此外我們還需要用到序號和確認號：
序號：佔4個字節，它的範圍在0-2^32-1，序號隨着通信的進行不斷的遞增，當達到最大值的時候重新回到0在開始遞增。TCP是面向字節流的，在一個TCP連接中傳送的字節流中的每一個字節都按照順序編號。整個要傳送的字節流的起始號必須在連接建立時設置。首部中的序列號字段指的是本報文段所發送的數據的第一個字節的序號。例如，一個報文序號是301，而攜帶的數據共有100字節。則表示本次報文中的序號是301，下一個報文的序號是401.重複一下，每一個報文的序號是該報文包含的字節中第一個字節的編號。
確認號：佔4個字節，確認號，是對下一個想要接受的字節的期望，這裏隱式確認了對上一個數據包的成功接收。如上例，在成功接收了序號爲301的數據包，想要接收下一個數據包因爲上個數據包包含100字節，所以此時的確認號應該是401，表示希望接收下一個序號是401的數據包。
三次握手過程：
1、過程描述：
首先由Client發出請求連接即 SYN=1 ACK=0 (請看頭字段的介紹)，TCP規定SYN=1時不能攜帶數據，但要消耗一個序號,因此聲明自己的序號是 seq=x。
然後 Server 進行回覆確認，即 SYN=1 ACK=1 seq=y，ack=x+1。
再然後 Client 再進行一次確認，但不用SYN 了，這時即爲 ACK=1, seq=x+1，ack=y+1。
2、爲什麼要進行三次握手（兩次確認）：
爲什麼A還要發送一側確認呢？這主要是爲了防止已失效的連接請求報文突然又傳送到了B，因而產生錯誤。
所謂“已失效的連接請求報文段”是這樣產生的。考慮一種正常情況。A發出連接請求，但因連接請求丟失而未收到確認。於是A再次重傳一次連接請求。後來收到了確認建立了連接。數據傳輸完畢後，就釋放了連接。A供發送了兩個連接請求的報文段，其中第一個丟失，第二個到達了B。沒有“已失效的連接請求報文段”。
現假定出現一種異常情況，即A發出的第一個連接請求報文段並沒有丟失，而是在某些網絡節點長時間滯留了，以致延誤到連接釋放以後的某個時間纔到B。本來這是一個已失效的報文段。但是B收到此失效的連接請求報文段後，就誤認爲是A有發出一次新的連接請求。於是就向A發出確認報文段，同意建立連接。假定不採用三次握手，那麼只要B發出確認，新的連接就建立了。
由於現在A並沒有發出建立連接的請求，因此不會理睬B的確認，也不會向B發送數據。但B卻以爲新的運輸連接已經建立了，並一直等待A發來數據。B的許多資源就這樣拜拜浪費了。
採用三次握手的辦法可以防止上述現象的發生。例如在剛纔的情況下，A不會向B的確認發出確認。B由於收不到確認，就知道A並沒有要求建立連接。
另一種解釋：
這個問題的本質是, 信道不可靠, 但是通信雙發需要就某個問題達成一致. 而要解決這個問題, 無論你在消息中包含什麼信息, 三次通信是理論上的最小值. 所以三次握手不是TCP本身的要求, 而是爲了滿足"在不可靠信道上可靠地傳輸信息"這一需求所導致的. 請注意這裏的本質需求,信道不可靠, 數據傳輸要可靠. 三次達到了, 那後面你想接着握手也好, 發數據也好, 跟進行可靠信息傳輸的需求就沒關係了. 因此,如果信道是可靠的, 即無論什麼時候發出消息, 對方一定能收到, 或者你不關心是否要保證對方收到你的消息, 那就能像UDP那樣直接發送消息就可以了”。這可視爲對“三次握手”目的的另一種解答思路。
3、四次揮手關閉連接
當客戶A 沒有東西要發送時就要釋放 A 這邊的連接，A會發送一個報文（沒有數據），其中 FIN 設置爲1, 服務器B收到後會給應用程序一個信，這時A那邊的連接已經關閉，即A不再發送信息（但仍可接收信息）。 A收到B的確認後進入等待狀態，等待B請求釋放連接， B數據發送完成後就向A請求連接釋放，也是用FIN=1 表示， 並且用 ack = u+1(如圖）， A收到後回覆一個確認信息，並進入 TIME_WAIT 狀態， 等待 2MSL（Maximum segment Lifetime） 時間。
|| 爲什麼要等待呢？
爲了防止這種情況：A接到B的釋放連接請求後會發送一個確認信息，但是如果這個確認信息丟了，也就是B沒有收到確認釋放連接，那麼B就會重發一個釋放連接請求，這時候A還處於TIME_WAIT狀態，所以會再次發送一個確認信息。
|| Q2爲什麼TIME_WAIT 狀態還需要等2*MSL秒之後才能返回到CLOSED 狀態呢？
A2因爲雖然雙方都同意關閉連接了，而且握手的4個報文也都發送完畢，按理可以直接回到CLOSED 狀態（就好比從SYN_SENT 狀態到ESTABLISH 狀態那樣），但是我們必須假想網絡是不可靠的，你無法保證你最後發送的ACK報文一定會被對方收到，就是說對方處於LAST_ACK 狀態下的SOCKET可能會因爲超時未收到ACK報文，而重發FIN報文，所以這個TIME_WAIT 狀態的作用就是用來重發可能丟失的ACK報文。
11種狀態
簡單解釋：
l CLOSED：初始狀態，表示TCP連接是“關閉着的”或“未打開的”。
l LISTEN ：表示服務器端的某個SOCKET處於監聽狀態，可以接受客戶端的連接。
l SYN_RCVD ：表示服務器接收到了來自客戶端請求連接的SYN報文。在正常情況下，這個狀態是服務器端的SOCKET在建立TCP連接時的三次握手會話過程中的一箇中間狀態，很短暫，基本上用netstat很難看到這種狀態，除非故意寫一個監測程序，將三次TCP握手過程中最後一個ACK報文不予發送。當TCP連接處於此狀態時，再收到客戶端的ACK報文，它就會進入到ESTABLISHED 狀態。
l SYN_SENT ：這個狀態與SYN_RCVD 狀態相呼應，當客戶端SOCKET執行connect()進行連接時，它首先發送SYN報文，然後隨即進入到SYN_SENT 狀態，並等待服務端的發送三次握手中的第2個報文。SYN_SENT 狀態表示客戶端已發送SYN報文。
l ESTABLISHED ：表示TCP連接已經成功建立。
l FIN_WAIT_1 ：這個狀態得好好解釋一下，其實FIN_WAIT_1 和FIN_WAIT_2 兩種狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連接，向對方發送了FIN報文，此時該SOCKET進入到FIN_WAIT_1 狀態。而當對方迴應ACK報文後，則進入到FIN_WAIT_2 狀態。當然在實際的正常情況下，無論對方處於任何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1 狀態一般是比較難見到的，而FIN_WAIT_2 狀態有時仍可以用netstat看到。
l FIN_WAIT_2 ：上面已經解釋了這種狀態的由來，實際上FIN_WAIT_2狀態下的SOCKET表示半連接，即有一方調用close()主動要求關閉連接。注意：FIN_WAIT_2 是沒有超時的（不像TIME_WAIT 狀態），這種狀態下如果對方不關閉（不配合完成4次揮手過程），那這個 FIN_WAIT_2 狀態將一直保持到系統重啓，越來越多的FIN_WAIT_2 狀態會導致內核crash。
l TIME_WAIT ：表示收到了對方的FIN報文，併發送出了ACK報文。 TIME_WAIT狀態下的TCP連接會等待2*MSL（Max Segment Lifetime，最大分段生存期，指一個TCP報文在Internet上的最長生存時間。每個具體的TCP協議實現都必須選擇一個確定的MSL值，RFC 1122建議是2分鐘，但BSD傳統實現採用了30秒，Linux可以cat /proc/sys/net/ipv4/tcp_fin_timeout看到本機的這個值），然後即可回到CLOSED 可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。（這種情況應該就是四次揮手變成三次揮手的那種情況）
l CLOSING ：這種狀態在實際情況中應該很少見，屬於一種比較罕見的例外狀態。正常情況下，當一方發送FIN報文後，按理來說是應該先收到（或同時收到）對方的ACK報文，再收到對方的FIN報文。但是CLOSING 狀態表示一方發送FIN報文後，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什麼情況下會出現此種情況呢？那就是當雙方几乎在同時close()一個SOCKET的話，就出現了雙方同時發送FIN報文的情況，這是就會出現CLOSING 狀態，表示雙方都正在關閉SOCKET連接。
l CLOSE_WAIT ：表示正在等待關閉。怎麼理解呢？當對方close()一個SOCKET後發送FIN報文給自己，你的系統毫無疑問地將會迴應一個ACK報文給對方，此時TCP連接則進入到CLOSE_WAIT狀態。接下來呢，你需要檢查自己是否還有數據要發送給對方，如果沒有的話，那你也就可以close()這個SOCKET併發送FIN報文給對方，即關閉自己到對方這個方向的連接。有數據的話則看程序的策略，繼續發送或丟棄。簡單地說，當你處於CLOSE_WAIT 狀態下，需要完成的事情是等待你去關閉連接。
l LAST_ACK ：當被動關閉的一方在發送FIN報文後，等待對方的ACK報文的時候，就處於LAST_ACK 狀態。當收到對方的ACK報文後，也就可以進入到CLOSED 可用狀態了
四、可靠傳輸
TCP 發送的報文段是交給 IP 層的。但是 IP 層只能提供盡最大努力服務，也就是說，TCP 下面的網絡的傳輸是不可靠的傳輸。因此，TCP 必須採取適當的措施才能使兩個運輸層之間的通信變得可靠。
TCP實現可靠傳輸工作的機制：
校驗：與UDP校驗一樣，增加僞首部。
序號：TCP是面向字節的。TCP將所要傳送的報文看作是字節組成的數據流，並使每一個字節對應一個序號。在連接建立時，雙方要確定初始序號。TCP每次發送的報文段的首部中的序號字段數值表示該報文段的數據部分的第一個字節的序號
確認：TCP的確認是對接收到的數據的最高序號表示確認。接收端返回的確認號是已收到的數據的最高序號加一。因此，確認號表示接收端期望下次收到的數據中的第一個數據字節的序號。
重傳：TCP的發送方在重傳時間內沒有收到確認就重傳已發送的報文段。由於TCP的下層是一個互聯網環境，IP數據報所選擇的路由變化很大，所以運輸層的往返時延的方差也很大。爲了計算超時計時器的重傳時間，TCP採用一種自適應的算法，動態改變重傳時間RTTs(加權平均往返時間)。
記錄每個報文段發出的時間以及收到相應的確認報文段的時間。時間差就是報文段的往返時間。
.
將各個報文段的往返時間樣本加權平均，得到報文段的平均往返時間RTT
.
每測量到一個新的往返時間樣本，就按公式重新計算一次平均往返時間。
.
RTT₁=(1-α)(RTT₀)+α(往返時延樣本)
.
α越接近1表示RTT的值更新越快，一般推薦α=0.125。計時器的超時重傳時間RTO應略大於RTT。
超時重傳等待時間結束才重傳，使用冗餘確認方式，在超時事件發生之前，知道發送方是否丟失報文段(快速重傳)
冗餘ACK(冗餘確認)
每當比期望序號大的失序報文段到達時，發送一個冗餘ACK，指明下一個期待字節的序號。
發送方發送1、2、3、4、5報文段 接收方收到1，返回1的確認報文段(確認號ack=2，期待收到下一個報文段2的第一個字節)
.
接收方收到3，返回1的確認報文段(冗餘確認報文段，確認號ack=2) 接收方收到4，返回1的確認報文段(冗餘確認報文段，確認號ack=2)
.
接收方收到5，返回1的確認報文段(冗餘確認報文段，確認號ack=2)
.
發送方收到3個1號報文段的冗餘確認報文段⇒認爲2號報文段丟失，重傳2號報文段。
在使用TCP傳送數據時，如果有一個確認報文段丟失了，會不會一定引起對方數據的重傳？
是否TCP和UDP都需要計算往返時間RTT？
假定在一個互聯網中，所有的鏈路的傳輸都不出現差錯，所有的結點也都不會發生故障。試問在該情況下TCP的“可靠交付”的功能是否就是多餘的？
五、流量控制
流量控制：讓發送方的發送速率不要太快，要讓接收方來得及接收。
利用滑動窗口機制可以很方便地在TCP連接上實現對發送方的流量控制。
在通信過程中，接收方根據自己接收緩存的大小，動態的調整發送方的發送窗口大小，即接收窗口rwnd(接收方設置確認報文段的窗口字段來將rwnd通知給發送方)發送方的發送窗口取接收窗口rwnd和擁塞窗口cwnd的最小值。
A向B發送數據，連接建立時，B告訴A：“rwnd=400B”，設每一個報文段100B，報文段序號初始值爲1。
接收窗口爲0，當接收應用程序讀取收到的數據，接收窗口擴大，發送方不發送數據，導致接收方無法發送確認告發送方接收窗口擴大，雙方陷入死鎖僵局。
TCP爲每一個連接設有一個持續計時器 。只要TCP連接的一方收到對方地零窗口通知，就啓動持續計時器。
若持續計時器設置的時間到期，就發送一個零窗口探測報文段(僅攜帶1Ｂ的數據)而對方就在確認這個探測報文段時給出了現在的窗口值。
若窗口仍然是零，則接收到這個報文段的一方就重新設置持續計時器。若窗口不爲零，則死鎖的僵局就被打破。
可以使用不同的機制控制TCP報文段的發送時機
TCP維持一個變量，等於最大報文段長度MSS。只要緩存中存放的數據達到MSS字節時，就組裝成一個TCP報文段發送出去。
由發送方的應用進程指明要求發送報文段，即TCP支持的推送(push)操作。
發送方的一個計時器期限到了，這是就把當前已有的緩存數據裝入報文段發送出去。
五、擁塞控制
出現擁塞的條件：對資源需求的總和＞可用資源
網絡中有許多資源同時呈現供應不足⇒網絡性能變壞⇒網絡吞吐量隨輸入負荷增大而下降。
擁塞控制：防止過多的數據注入到網絡中。
擁塞控制與流量控制的性質對比
擁塞控制所要做的只有一個前提，就是使得網絡能夠承受現有的網絡負荷。
.
擁塞控制是一個全局性的過程，涉及所有的主機、所有的路由器以及與降低網絡傳輸性能有關的所有因素。
.
流量控制往往指在給定的發送端和接收段之間的點對點通信量的控制。 流量控制所要做的就是抑制發送端發送數據的速率，以便接收端來得及接收。
.
擁塞控制很難設計，因爲它是一個動態的問題。
.
當前網絡正朝着高速化的方向發展,很容易出現緩存不夠大而造成分組的丟失。分組的都是是網絡發生擁塞的徵兆而不是原因。
.
在許多情況下，正是擁塞控制本身成爲引起網絡性能惡化甚至發生死鎖的原因。
擁塞控制分爲閉環控制和開環控制
- 開環控制方法就是在設計網絡時實現將有關發生擁塞的因素考慮周到，力求網絡在工作時不產生擁塞。
- 閉環控制是基於反饋環路的概念，屬於閉環控制的有以下措施：
1、檢測網絡系統以便檢測到擁塞在何時、何地發生。
2、將擁塞發生的信息傳送到可採取行動的地方。
3、調整網絡系統的運行已解決出現的問題。
擁塞控制算法：
假定：
數據單方向傳送，另一個方向只傳送確認。
發送端的主機在確定發送報文段的速率時，既要根據發接收端的接收能力，又要從全局考慮不使網絡發生擁塞。即TCP要求發送端維護接收窗口rwnd和擁塞窗口cwnd
接收窗口：接收方根據受緩存設置的值，並告知給發送方，反映接收方容量。
擁塞窗口：發送方根據自己估算的網絡擁塞程度而設置的窗口值，反映網絡當前容量。
接收方總是有足夠大的緩存空間，發送窗口大小取決於擁塞程度。發送窗口=Min｛接收窗口rwnd，擁塞窗口cwnd｝
慢開始和擁塞避免
慢開始原理：
-
在主機剛剛開始發送報文段時可先設置擁塞窗口cwnd=1，設置爲一個最大報文段MSS的數值。
-
在每收到一個對新的報文段的確認後，將擁塞窗口加一，既增加一個MSS的數值。
-
用該方法逐步增大發送端的擁塞窗口cwnd，可以使分組注入網絡的速率更合理。
擁塞避免算法原理：
- 爲防止擁塞窗口cwnd的增長引起網絡阻塞，需要一個狀態變量，即慢開始門限ssthresh
- 當cwnd＜ssthresh時，使用慢開始算法
- 當cwnd＞ssthresh時，停止使用慢開始算法，改用擁塞避免算法
- 當cwnd=ssthresh時，既可以使用慢開始算法，也可以使用擁塞避免算法。
- 其中，擁塞避免算法的做法爲，發送端的擁塞窗口cwnd每經過一個往返時延RTT就增加一個MSS的大小，通常表現爲按線性規律增長。
無論在慢開始階段還是擁塞避免階段，只要發送方判斷網絡出現擁塞(即未按時收到確認)就把慢開始門限ssthresh設置爲出現擁塞時的發送窗口的一半(即ssthresh(慢開始門限)：新的ssthresh門限值=½網絡擁塞時的擁塞窗口cwnd，但不能小於2)。然後把擁塞窗口cwnd重新設定爲1，執行慢開始算法。
可以減少主機發送到網絡中的分組數，使得發生擁塞的路由器有足夠的時間把隊列中積壓的分組處理完畢。
一個傳輸輪次：發送了一批報文段並收到他們的確認的時間/一個往返時延RTT/開始d發送一批擁塞窗口內的報文段到開始發送下一批擁塞窗口內的報文段的時間。快重傳和快恢復