網路基礎筆記＿網路傳輸層協議(TCP/UDP)知識點
網路層負責把分組傳送到目的主機，但是真正通訊的並不是主機而是主機中的程序。傳輸層提供了程序間的邏輯通訊，傳輸層向高層使用者遮蔽了下面網路層的核心細節，使應用程式看起來像是在兩個傳輸層實體之間有一條端到端的邏輯通訊通道。
一．傳輸層中的兩種協議UDP / TCP
UDP 的特點：
使用者資料報協議 UDP（User Datagram Protocol）：是無連線的，不具有可靠性的資料報協議，細微的處理它會交給上層的應用去完成．UDP盡最大可能交付，沒有擁塞控制，面向報文（對於應用程式傳下來的報文不合並也不拆分，只是新增 UDP 首部），支援一對一、一對多、多對一和多對多的互動通訊，類似於發簡訊．UDP情況下，雖然可以確保傳送訊息的大小，卻不能保證訊息一定會到達。因此，應用有時會根據自己的需要進行重發處理．
UDP不提供複雜控制機制，利用IP提供面向無連線的通訊服務。且它是將應用程式發來的資料在收到的那一刻，立即按照原樣傳送到網路上的一種機制。
UDP面向無連線，可以隨時傳送資料。它常用於幾個方面：
包總量較少的通訊（DNS、SNMP等）
視訊、音訊等多媒體通訊（即時通訊）
限定於LAN等特定網路中的應用通訊TCP的特點：
傳輸控制協議 TCP（Transmission Control Protocol）：是面向連線的、可靠的流協議。流就是指不間斷的資料結構，你可以把它想象成排水管道中的水流。TCP提供可靠交付，實行“順序控制”或“重發控制
”機制，具有流量控制，擁塞控制，提供全雙工通訊，面向位元組流（把應用層傳下來的報文看成位元組流，把位元組流組織成大小不等的資料塊），具有提高網路利用率等眾多功能，每一條 TCP 連線只能是點對點的（一對一），類似於打電話．TCP充分實現了資料傳輸時各種控制功能，根據TCP這些機制，在IP這種無連線的網路上也能夠實現高可靠性的通訊。
TCP通過校驗和、序列號、確認應答、重發機制、連線管理以及視窗控制等機制實現可靠性傳輸。
UDP / TCP 的選擇與區分：
TCP用於在傳輸層有必要實現可靠傳輸的情況。由於它是面向有連線並具備順序控制、重發控制等機制的，所以他可以為應用提供可靠傳輸。UDP主要用於那些對高速傳輸和實時性有較高要求的通訊或廣播通訊
。多播和廣播通訊中也使用UDP而不是TCP。RIP、DHCP等基於廣播的協議也要依賴於UDP。TCP是緊小細微型的工作方式，提供可靠的通訊傳輸；而UDP是粗狂蠻幹型的工作方式，常被用於讓廣播和細節控制交給應用的通訊傳輸．
TCP可靠性高，速度慢，可被利用的漏洞多；UDP速度快，可靠性低，可被利用的漏洞少，相對較安全．
因為UDP協議的控制選項較少，在資料傳輸過程中延遲小、資料傳輸效率高，實時性好，適合對可靠性要求不高的應用程式，或者可以保障可靠性的應用程式，如DNS、TFTP、SNMP等。 在生活中音訊、視訊和普通資料都可以採用UDP協議來進行資料傳輸．
當對網路通訊質量有要求，整個資料需要準確無誤的傳遞給對方時，比如HTTP、HTTPS、FTP等傳輸檔案的協議，POP、SMTP等郵件傳輸的協議需採用TCP協議。
套接字（Socket）
使用TCP或UDP通訊時，會廣泛使用到套接字(socket)的API。套接字原本是由BSD UNIX開發的，但是後被移植到Windows以及嵌入式作業系統中。
應用程式利用套接字，可以設定對端的IP地址、埠號，並實現資料的傳送和接收。
二．傳輸層中的埠號
IP首部有一個協議欄位，用來標識網路層（IP）的上一層所採用的是哪一種傳輸層協議。根據這個欄位的協議號，就可以識別IP傳輸的資料部分究竟是TCP的內容還是UDP的內容。
同樣，傳輸層的TCP和UDP，為了識別自己所傳輸的資料部分究竟應該發給哪個應用，也設定了這樣一個編號。在TCP/IP通訊中需要指定“應用程式”。而傳輸層必須指出這個具體的程式，為了實現這一功能，使用埠號這樣一種識別碼。根據埠號可以識別在傳輸層上一層的應用層中所要進行處理的具體程式。
埠號定義
資料鏈路層中的地址指的是MAC地址，網路層 (IP層) 中的地址，指的是IP地址。前者用來識別同一鏈路中不同的計算機，後者用來識別TCP/IP網路中互連的主機和路由器。
傳輸層也有類似概念，就是埠號。埠號用來識別同一臺計算機中進行通訊的不同應用程式。因此，它也被稱為程式地址。
程序在網路通訊中的ID識別
TCP/IP或UDP/IP通訊中通常採用5個資訊來識別一對通訊中的程序。它們是“源IP地址”、“目標IP地址”、“協議號”、“源埠號”、“目標埠號”。其中“源IP地址”、“目標IP地址”、“協議號”在IP首部指定，而“源埠號”、“目標埠號”在TCP/UDP首部指定，只要其中某一項不同，則被認為是其他通訊。
埠號的確定
1>. 標準既定的埠號
這種方法也叫靜態方法。它是指每個應用程式都有其指定的埠號。但並不是說可以隨意使用任何一個埠號。每個埠號都有其對應的使用目的。如，HTTP、TELNET、FTP等埠號就是固定的。這些埠號被稱之為知名埠號（Well-Known Port Number）。知名埠號一般由0到1023的數字分配而成。
2>. 時序分配法
第二種方法也叫時序（或動態地）分配法。伺服器有必要確定用於監聽的埠號，但是接受服務的客戶端沒必要確定埠號。因此，客戶端應用程式可以完全不用自己設定埠號，而全權交給作業系統進行分配。動態分配的埠號取值範圍在49152到65535之間。
埠號與協議
埠號由其使用的傳輸層協議決定。因此，不同的傳輸協議可以使用相同的埠號。例如，TCP與UDP使用同一個埠號，但使用目的各不相同。
資料到達IP層後，會先檢查IP首部中的協議號，再傳給相應協議的模組。傳給TCP或UDP去做埠號處理。就算是同一個埠號，由於傳輸協議是各自獨立地進行處理，因此相互之間不會影響。
那些知名埠號與傳輸層協議並無關係，只要埠一致都將分配同一種程式進行處理。例如，53埠在TCP與UDP中都用於DNS服務（由域名確定IP地址時所用的協議），80埠用於HTTP通訊。從目前看，由於HTTP通訊必須使用TCP，所以UDP的80埠並未投入使用。
程序間的通訊處理
服務端程式在UNIX系統當中叫做守護程序。例如HTTP的服務端程式是httpd（HTTP守護程序），而ssh的服務端程式是sshd（SSH守護程序）。UNIX中並不需要將這些守護程序逐個啟動，而是啟動一個可以代表它們接收客戶端請求的inetd（網際網路守護程序）服務程式即可。它是一種超級守護程序。該超級守護程序收到客戶端請求以後會建立（fork）新的程序並轉換（exec）為sshd等各個守護程序。
確認一個請求究竟發給的是哪個服務端（守護程序），可以通過所收到資料包的目標埠號輕鬆識別。當收到TCP的建立連線請求時，如果目標埠為22，則轉給sshd，如果是80則轉給httpd。然後，這些守護程序會繼續對該連線上的通訊傳輸進行處理。
傳輸協議TCP、UDP通過接收資料中的目標埠識別目標處理程式。以下圖為例，傳輸協議的資料將被傳遞給HTTP、TELNET以及FTP等應用層協議。
三．UDP協議和TCP協議
UDP的首部格式
首部欄位只有 8 個位元組，包括源埠、目的埠、長度、檢驗和。12 位元組的偽首部是為了計算檢驗和臨時新增的。
- 源埠號（Source Port）：表示傳送端埠號，欄位長16位。該欄位是可選項，有時可能不會設定源埠號。沒有源埠號的時候該欄位的值設定為0。可用於不需要返回的通訊中。
- 目標埠號（Destination Port）：表示接收端埠，欄位長度16位。
- 包長度（Length）：該欄位儲存了UDP首部的長度跟資料的長度之和。單位為位元組（8位位元組）。
- 校驗和（Checksum）：校驗和是為了提供可靠的UDP首部和資料而設計。
校驗和計算中計算UDP偽首部的理由
TCP/IP中識別一個通訊的應用需要5大要素，它們分別是“源IP地址”、“目標IP地址”、“源埠”、“目標埠”、“協議號”。然而，在UDP的首部中只包含它們當中的兩項（源埠和目標埠），餘下的3項都包含在IP首部裡。假定其他3項都被破壞？顯然，這極有可能會導致應該收包的應用收不到包，不該收到包的應用卻收到了包。為了避免這類問題，有必要驗證一個通訊中必要的5項識別碼是否正確。為此，在校驗和的計算中就引入和偽首部的概念。此外，IPv6中的IP首部沒有檢驗和欄位。TCP和UDP通過偽首部，得以對5項數字進行校驗，從而實現即使在IP首部並不可靠的情況下仍然能夠提供可靠的通訊傳輸。
UDP校驗和：
在計算校驗和時，附加在UDP偽首部與UDP資料報之前。通過在最後一位增加一個“0”將全長增加16倍。此時將UDP首部的校驗和欄位設定為“0”。然後以16位元為單位進行1的補碼和，並將所得到的1的補碼和寫入校驗和欄位。
接收主機在收到UDP資料報以後，從IP首部獲知IP地址資訊構造UDP偽首部，再進行校驗和計算。校驗和制度按的值是校驗和欄位以外餘下部分的1的補碼和。因此，包括校驗和欄位在內的所有資料之和結果為“16位全部為1”時，才會被認為所收到的資料時正確的。
另外，UDP也可有可能不用校驗和。此時，校驗和欄位中填入0.這種情況下，由於不進行校驗和計算，協議處理的開銷（在處理實際資料之外，為了進行通訊控制的處理而不得不付出的必要的消耗部分）就會降低，從而提高資料轉發的速度。然而，如果UDP首部的埠號或是IP首部的IP地址遇到損壞，那麼可能會對其他通訊造成不好的影響。因此，在網際網路中比較推薦使用校驗和檢查。
原碼、反碼、補碼 ：
三種表示方法均有符號位和數值位兩部分，符號位都是用0表示“正”，用1表示“負”，而數值位，三種表示方法各不相同。
在計算機系統中，數值一律用補碼來表示和儲存。原因在於，使用補碼，可以將符號位和數值域統一處理；同時，加法和減法也可以統一處理。此外，補碼與原碼相互轉換，其運算過程是相同的，不需要額外的硬體電路。
1. 原碼
原碼就是符號位加上真值的絕對值, 即用第一位表示符號, 其餘位表示值. 比如如果是8位二進位制:
[+1]原= 0000 0001
[-1]原= 1000 0001
第一位是符號位. 因為第一位是符號位, 所以8位二進位制數的取值範圍就是:
[1111 1111 , 0111 1111]
即
[-127 , 127]
原碼是人腦最容易理解和計算的表示方式.
2. 反碼
反碼的表示方法是:
正數的反碼是其本身
負數的反碼是在其原碼的基礎上, 符號位不變,其餘各個位取反.
[+1] = [00000001]原= [00000001]反
[-1] = [10000001]原= [11111110]反
可見如果一個反碼錶示的是負數, 人腦無法直觀的看出來它的數值. 通常要將其轉換成原碼再計算.
3. 補碼
補碼的表示方法是:
正數的補碼就是其本身
負數的補碼是在其原碼的基礎上, 符號位不變, 其餘各位取反, 最後+1. (即在反碼的基礎上+1)
[+1] = [00000001]原= [00000001]反= [00000001]補
[-1] = [10000001]原= [11111110]反= [11111111]補
對於負數, 補碼錶示方式也是人腦無法直觀看出其數值的. 通常也需要轉換成原碼在計算其數值.
TCP首部格式
TCP中沒有表示包長度和資料長度的欄位。可由IP層獲知TCP的包長，由TCO的包長可知資料的長度。
- 序號 ：欄位長32位，用於對位元組流進行編號，例如序號為 301，表示第一個位元組的編號為 301，如果攜帶的資料長度為 100 位元組，那麼下一個報文段的序號應為 401。序列號不會從0或1開始，而是建立連線時由計算機生成的隨機數作為其初始值，通過SYN包傳給接收端主機。此外，在建立連線和斷開連線時傳送的SYN包和FIN包雖然並不攜帶資料，但是也會作為一個位元組增加對應的序列號。
- 確認號 ：欄位長度32位，是指期望收到的下一個報文段的序號。例如 B 正確收到 A 傳送來的一個報文段，序號為 501，攜帶的資料長度為 200 位元組，因此 B 期望下一個報文段的序號為 701，B 傳送給 A 的確認報文段中確認號就為 701。
- 資料偏移 ：該欄位長32位，指的是資料部分距離報文段起始處的偏移量，實際上指的是首部的長度。
- 控制位（Control Flag）：欄位長為8位，每一位從左至右分別為CWR、ECE、URG、ACK、PSH、RST、SYN、FIN。這些控制標誌也叫作控制位。
- CWR（Congestion Window Reduced） :CWR標誌與後面的ECE標誌都用於IP首部的ECN欄位。ECE標誌為1時，則通知對方已將擁塞視窗縮小。
- ECE（ECN-Echo） :ECE標誌表示ECN-Echo。置為1會通知通訊對方，從對方到這邊的網路有擁塞。在收到資料包的IP首部中ECN為1時將TCP首部中的ECE設定為1。
- URG（Urgent Flag） :該位為1時，確認應答的欄位變為有效。TCP規定除了最初建立連線時的SYN包之外該位必須設定為1。
- PSH（Push Flag） :該位為1時，表示需要將受到的資料立即傳給上層應用協議。PSH為0時，則不需要立即傳而是先進性快取。
- RST（Reset Flag） :該位為1時表示TCP連線中出現異常必須強制斷開連線。
- SYN（Synchronize Flag） :用於初次建立連線，在連線建立時用來初始化序號欄位．SYN＝1 表示希望建立連線，並在其序號的欄位進行序號初始值的設定。當 SYN=1，ACK=0 時表示這是一個連線請求報文段。若對方同意建立連線，則響應報文中 SYN=1，ACK=1。
- FIN（Fin Flag） :用來釋放一個連線，當 FIN=1 時，表示此報文段的傳送方的資料已傳送完畢，今後不會再有資料傳送，希望釋放連線。
- 確認 ACK ：當 ACK=1 時表示確認號欄位存在。TCP 規定，在連線建立後所有傳送的報文段都必須把 ACK 置 1，此時確認號存在。
- 視窗 ：該欄位長為16位，視窗值作為接收方讓傳送方設定其傳送視窗的依據。之所以要有這個限制，是因為接收方的資料快取空間是有限的。TCP不允許傳送超過此處所示大小的資料。不過，如果視窗為0，則表示可以傳送視窗探測，以瞭解最新的視窗大小。但這個資料必須是1個位元組。
- 校驗和：TCP的校驗和與UDP相似，區別在於TCP的校驗和無法關閉。 TCP和UDP一樣在計算校驗和的時候使用TCP偽首部。
TCP和UDP的偽首部 ：
偽首部(pseudo header)，通常有TCP偽首部和UDP偽首部。在UDP/TCP偽首部中，包含32位源IP地址，32位目的IP地址，8位填充0，8位協議，16位TCP/UDP長度。通過偽首部的校驗，UDP可以確定該資料報是不是發給本機的，通過首部協議欄位，UDP可以確認有沒有誤傳。
偽首部並非TCP/UDP資料報中實際的有效成分。偽首部是一個虛擬的資料結構，其中的資訊是從資料報所在IP分組頭的分組頭中提取的，既不向下傳送也不向上遞交，而僅僅是為計算校驗和。
TCP的三次握手
假設 A 為客戶端，B 為伺服器端
- 首先 B 處於 LISTEN（監聽）狀態，等待客戶的連線請求。
- A 向 B 傳送連線請求報文，SYN=1，ACK=0，選擇一個初始的序號 x。
- B 收到連線請求報文，如果同意建立連線，則向 A 傳送連線確認報文，SYN=1，ACK=1，確認號為 x+1，同時也選擇一個初始的序號 y。
- A 收到 B 的連線確認報文後，還要向 B 發出確認，確認號為 y+1，序號為 x+1。
- B 收到 A 的確認後，連線建立。
三次握手的原因：
第三次握手是為了防止失效的連線請求到達伺服器，讓伺服器錯誤開啟連線。
客戶端傳送的連線請求如果在網路中滯留，那麼就會隔很長一段時間才能收到伺服器端發回的連線確認。客戶端等待一個超時重傳時間之後，就會重新請求連線。但是這個滯留的連線請求最後還是會到達伺服器，如果不進行三次握手，那麼伺服器就會開啟兩個連線。如果有第三次握手，客戶端會忽略伺服器之後傳送的對滯留連線請求的連線確認，不進行第三次握手，因此就不會再次開啟連線。
TCP的四次揮手
以下描述不討論序號和確認號，因為序號和確認號的規則比較簡單。並且不討論 ACK，因為 ACK 在連線建立之後都為 1。
- A 傳送連線釋放報文，FIN=1。
- B 收到之後發出確認，此時 TCP 屬於半關閉狀態，B 能向 A 傳送資料但是 A 不能向 B 傳送資料。
- 當 B 不再需要連線時，傳送連線釋放報文，FIN=1。
- A 收到後發出確認，進入 TIME-WAIT 狀態，等待 2 MSL（最大報文存活時間）後釋放連線。
- B 收到 A 的確認後釋放連線。
四次揮手的原因
客戶端傳送了 FIN 連線釋放報文之後，伺服器收到了這個報文，就進入了 CLOSE-WAIT 狀態。這個狀態是為了讓伺服器端傳送還未傳送完畢的資料，傳送完畢之後，伺服器會發送 FIN 連線釋放報文。
TIME_WAIT
客戶端接收到伺服器端的 FIN 報文後進入此狀態，此時並不是直接進入 CLOSED 狀態，還需要等待一個時間計時器設定的時間 2MSL。這麼做有兩個理由：
確保最後一個確認報文能夠到達。如果 B 沒收到 A 傳送來的確認報文，那麼就會重新發送連線釋放請求報文，A 等待一段時間就是為了處理這種情況的發生。
等待一段時間是為了讓本連線持續時間內所產生的所有報文都從網路中消失，使得下一個新的連線不會出現舊的連線請求報文。
TCP的 "序號/確認號" 機制
在TCP中，當傳送端資料到達接受主機時，接收端主機會返回一個已收到的訊息的通知。這個訊息為：＂ACK控制位＋確認號欄位＂
正常的資料傳輸：
TCP通過ACK控制位實現可靠的資料傳輸。當傳送端將資料發出之後會等待對端的確認應答（ACK=1）。如果有確認應答，說明資料已經成功到達對端。在一定時間內沒有等到確認應答，傳送端就可以認為資料已經丟失，並進行重發。由此，即使產生了丟包，仍然能夠保證資料能夠重新發送到對端，實現可靠傳輸。
未確認應答並不意味著資料一定丟失。也有可能是資料對方已經收到，只是返回的確認應答在途中丟失。
"序號/確認號" 機制
為了防止出現數據段隨意重發的情況，就需要引入一種機制，它能夠識別是否已經接收資料，又能判斷是否需要接收。這些確認應答處理、重發控制以及重複控制等功能都可以通過序號實現。
序號是按照順序給傳送資料的每個位元組都標上號碼的編號（序列號的初始值並非為0，而是在建立連線以後由隨機數生成，後面的計算則是對每一位元組加一）。接收端查詢接收資料TCP首部中序號和資料的長度，將自己下一步應該接收的序號作為確認號返送回去。這樣，通過序號和確認應答號，TCP可以實現可靠傳輸。
TCP的資料長度並未寫入TCP首部。實際通訊中求得TCP包的長度的計算公式是：IP首部中的資料包長度-IP首部長度TCP首部長度。
TCP的超時重傳機制
TCP 使用超時重傳來實現可靠傳輸：如果一個已經發送的報文段在超時時間內沒有收到確認，那麼就重傳這個報文段。
TCP要求不論處在何種網路環境下都要提供高效能通訊，並且無論網路擁堵情況發生何種變化，都必須保持這一特性。為此，它在每次發包時都會計算往返時間（RTT Round Trip Time 指報文段的往返時間）及偏差（RTT時間波動的值，方差。有時也叫抖動）。將這個往返時間和偏差相加重發超時的時間，就是比這個綜合要稍大一點的值。
一個報文段從傳送再到接收到確認所經過的時間稱為往返時間 RTT，加權平均往返時間 RTTs 計算如下：
超時時間 RTO 應該略大於 RTTs，TCP 使用的超時時間計算如下：
其中 RTTd 為偏差。
TCP的滑動視窗機制
視窗是快取的一部分，用來暫時存放位元組流。傳送方和接收方各有一個視窗，接收方通過 TCP 報文段中的視窗欄位告訴傳送方自己的視窗大小，傳送方根據這個值和其它資訊設定自己的視窗大小。
傳送視窗內的位元組都允許被髮送，接收視窗內的位元組都允許被接收。如果傳送視窗左部的位元組已經發送並且收到了確認，那麼就將傳送視窗向右滑動一定距離，直到左部第一個位元組不是已傳送並且已確認的狀態；接收視窗的滑動類似，接收視窗左部位元組已經發送確認並交付主機，就向右滑動接收視窗。
接收視窗只會對視窗內最後一個按序到達的位元組進行確認，例如接收視窗已經收到的位元組為 {31, 34, 35}，其中 {31} 按序到達，而 {34, 35} 就不是，因此只對位元組 31 進行確認。傳送方得到一個位元組的確認之後，就知道這個位元組之前的所有位元組都已經被接收，因此，即使之前的確認應答訊號丟失，也不會進行重發，因為可以通過後面的確認應答進行確認．
滑動視窗的作用：
利用滑動視窗機制在保證可靠性的前提下提高傳輸速率．
不採用滑動視窗時，每發一個數據段都要進行一次確認應答的處理， 這樣傳輸的缺點是，包的往返時間越長通訊效能就越低。
採用滑動視窗後，處於傳送視窗內的資料段無需等待確認應答就可以繼續送．使得確認應答不再是以每個資料段，而是以更大的單位進行確認，轉發時間將會被大幅度的縮短。
傳送視窗的大小就是指無需等待確認應答而可以繼續傳送資料的最大值。
這個機制實現了使用緩衝區（Buffer 在此處標識臨時儲存收發資料的場所，通常是在計算機記憶體中開闢的一部分空間），對多個段同時進行確認應答的功能。
視窗機制與重發控制：
1>. 確認應答未能返回的情況 這種情況下，資料已經達到對端，是不需要進行重發的。因為，傳送方得到一個位元組的確認之後，就知道這個位元組之前的所有位元組都已經被接收，因此，即使之前的確認應答訊號丟失，也不會進行重發，因為可以通過後面的確認應答進行確認．然而，在沒有使用視窗控制的時候，沒有收到確認應答的資料會被重發。
2>. 某個報文段丟失的情況 接收視窗只會對視窗內最後一個按序到達的位元組進行確認．如下圖，當某一報文段（1001~2000）丟失後，傳送端會一直收到序號為1001的確認應答，這個確認應答好像在提醒傳送端“我想接收的是從1001開始的資料”。因此，在視窗比較大，又出現報文段丟失的情況下，同一個序號的確認應答將會被重複不斷地返回。而傳送端主機如果連續3次收到同一個確認應答（之所以連續收到3次而不是兩次的理由是因為，即使資料段的序號被替換兩次也不會觸發重發機制），就會將其所對應的資料進行重發。這種機制比之前提到的超時管理更加高效，因此也被稱作高速重發控制。
高速重發控制（Fast Retransmission）
TCP的流控制
流量控制是為了控制傳送方傳送速率，保證接收方來得及接收的機制。
接收方傳送的確認報文中的視窗欄位可以用來控制傳送方視窗大小，從而影響傳送方的傳送速率。將視窗欄位設定為 0，則傳送方不能傳送資料，直到傳送方收到視窗更新通知訊息，通訊才可繼續，但為了避免視窗更新通知訊息丟失，傳送端在超時後可以傳送一個視窗探測訊號，此資料段僅含一個位元組以獲取最新的視窗大小資訊。
確認報文中視窗欄位的值越大，說明網路的吞吐量越高。
根據視窗大小控制流量過程示例：
當接收端收到從3001號開始的資料段後其緩衝區即滿，不得不將視窗欄位置為０，暫時停止接收資料。之後，傳送端在收到視窗更新通知後通訊才得以繼續進行。如果這個視窗更新通知在傳輸途中丟失，可能會導致無法繼續通訊。為避免此類問題，傳送端主機會時不時傳送一個叫做視窗探測的資料段，此資料段僅含一個位元組以獲取最新的視窗大小資訊。
TCP的擁塞控制
如果網路出現擁塞，分組將會丟失，此時傳送方會繼續重傳，從而導致網路擁塞程度更高。因此當出現擁塞時，應當控制傳送方的速率。
流量控制和擁塞控制：
兩者都是用來控制傳送方的傳送速率的，但兩者的出發點不同．流量控制是為了讓接收方能來得及接收，而擁塞控制是為了降低整個網路的擁塞程度。
TCP 主要通過四個演算法來進行擁塞控制：慢開始、擁塞避免、快重傳、快恢復。
傳送方需要維護一個叫做擁塞視窗（cwnd）的狀態變數，注意擁塞視窗與傳送方視窗的區別：擁塞視窗只是一個狀態變數，實際決定傳送方能傳送多少資料的是傳送方視窗。
為了便於討論，做如下假設：
- 接收方有足夠大的接收快取，因此不會發生流量控制；
- 雖然 TCP 的視窗基於位元組，但是這裡設視窗的大小單位為報文段。
1>. 慢開始與擁塞避免
傳送的最初執行慢開始，令 cwnd = 1，傳送方只能傳送 1 個報文段；當收到確認後，將 cwnd 加倍，因此之後傳送方能夠傳送的報文段數量為：2、4、8 ...
注意到慢開始每個輪次都將 cwnd 加倍，這樣會讓 cwnd 增長速度非常快，從而使得傳送方傳送的速度增長速度過快，網路擁塞的可能性也就更高。設定一個慢開始門限 ssthresh，當 cwnd >= ssthresh 時，進入擁塞避免，每個輪次只將 cwnd 加 1。
如果出現了超時（有網路擁塞造成），則令 ssthresh = cwnd / 2，然後重新執行慢開始。
2>. 快重傳與快恢復
在接收方，要求每次接收到報文段都應該對最後一個已收到的有序報文段進行確認。例如已經接收到 M1 和 M2，此時收到 M4，應當傳送對 M2 的確認。
在傳送方，如果收到三個重複確認，那麼可以知道下一個報文段丟失，此時執行快重傳，立即重傳下一個報文段。例如收到三個 M2，則 M3 丟失，立即重傳 M3。
在這種情況下，只是丟失個別報文段，而不是網路擁塞。因此執行快恢復，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此時直接進入擁塞避免。
慢開始和快恢復的快慢指的是 cwnd 的設定值，而不是 cwnd 的增長速率。慢開始 cwnd 設定為 1，而快恢復 cwnd 設定為 ssthresh。
文章參考：學習UDP與TCP的總結