目錄
考研大綱
1.傳輸層概述
端口號
有連接/無連接傳輸
可靠/不可靠傳輸
2.UDP協議
2.1 udp數據報
2.2 udp檢驗
3.TCP協議
3.1 TCP協議的框架梳理
3.2 TCP報文段****
3.3 三次握手與四次揮手
三次握手
四次揮手
3.4 可靠傳輸與流量控制
流量控制：滑動窗口機制
可靠傳輸：確認機制，超時重傳與快重傳機制
3.5 擁塞控制
擁塞控制介紹
慢開始和擁塞避免算法
快重傳與快恢復算法
考研大綱
1.傳輸層概述
端口號
有連接/無連接傳輸
可靠/不可靠傳輸
2.UDP協議
UDP是無連接，不可靠的，不支持擁塞控制，適用于即時性的場景，如直播等
UDP接收的是應用層完整的報文，因此說udp是面向報文的
2.1 udp數據報
UDP數據報理論最大長度為65535B，但受限于IP數據報的長度，所以實際上最大不能超過65515B
UDP數據報示例
總結
2.2 udp檢驗
首先介紹一個校驗方法。發送方取每16bit數據的二進制進行相加（注意“高位回卷”），加完的結果取反，得到同樣二進制數的16bit檢驗和。把原數據和檢驗和一起發送。那么接收方判斷數據是否正確就是同樣進行原數據每16bit相加，最后和校驗和相加，如果全為1代表正確。
介紹完上面的校驗方式，那么就來看看udp校驗，其實也是這樣的方式。
發送方：
接收方：
真題：
3.TCP協議
3.1 TCP協議的框架梳理
三次握手四次揮手的整體流程
TCP有最大段長限制，同時TCP可以分段，而不像UDP要求傳輸完整報文，因此TCP也稱面向字節流
3.2 TCP報文段****
都是重點
ACK只有在握手階段的第一次握手為0，之后的全為1.
起始序號不一定從0開始，如下圖，可以從500開始
確認號ack-seq：按照教材定義，表示期望接收的下一個序列號是多少
確認后示例，如下圖，當接收方已經成功接受了1號和2號這2個報文段，那么他可以返回的ack-seq = 2500，表示2500之前的字節都成功接收了，期望接收的下一個序列號從2500開始。
數據偏移：其實就是TCP首部的長度；跟IP數據報的首部是一樣的，回憶一下，418：首總偏，ip數據報的首部也是X 4B。
SYN只有在握手1和握手2時 == 1，表示請求連接和連接接受
FIN只有在揮手1和揮手3時 == 1，表示數據發送完畢，要求釋放連接
示例
窗口字段
示例，例如主機B的TCP協議給進程2分配的接收緩沖區為2500B，現在他已經接收了1和2這兩個報文段了，剩500B，那么返回的rcvwnd=500
校驗和字段
選項字段和MSS
3.3 三次握手與四次揮手
三次握手
三次握手中的字段變化
注意下邊左右連接的區別，主要是在握手3，握手3是可以不攜帶數據的
真題，題目求的是握手2服務端要發送的TCP段的值，SYN =1在握手1和2中，所以這里是SYN =1；ACK只在握手1里為0，所以這里ACK = 1；seq是服務器自己設置要發送的起始字節，隨便都可以的，這里不能用來判斷；ack = 11220+1=11221，這里能確定。所以選c
三次握手中TCP狀態變化
三次握手中連接耗時
四次揮手
字段的變化
tcp狀態變化
連接耗時計算
真題，就是上圖算連接耗時，客戶端進入close的時間= 1倍RTT + 2MSL = 50 + 1600 =1650，服務器進入close的時間 = 1.5倍RTT = 75。
3.4 可靠傳輸與流量控制
可靠傳輸在數據鏈路層也有，二者有很多相似之處。數據鏈路層是以幀為單位進行重傳確認，而TCP是以TCP段進行重傳確認。流量控制同樣在數據鏈路層也有，也是滑動窗口機制。
流量控制：滑動窗口機制
確認號與接收窗口的大小會在TCP首部中。
發送窗口不能超過自己的發送緩沖區；也不能大于對方的接受窗口。
擴展：一個端口可以建立多個TCP連接
可靠傳輸：確認機制，超時重傳與快重傳機制
可靠傳輸依靠確認機制和重傳機制實現，確認機制就是接收方返回ACK段。重傳機制有超時重傳與快重傳，這二者的差別在于接收方是返回確認ACK段的時機，因為確認機制返回ACK的時機是“推遲確認”，快重傳會讓確認機制變為“立即確認”。
累計確認
捎帶確認
超時重傳場景：
情況1：客戶端發出的報文段丟失
情況2：服務器返回的ACK段丟失
快重傳機制
下面是推遲確認下的重傳的場景，當發送方連續發送的4個報文段中有報文段丟了，那么由于推遲確認，最后發送方要重發一堆的報文段，這會導致浪費，畢竟只是丟失了其中某個報文段，沒必要重傳一堆報文段。
推遲后發送一個ACK如下
發送方接收到ACK后調整自己的窗口，可以看到23，24，25已經在之前發送了而且他們的計時器還沒超時，所以這時候是得等待超時才能重發的。
而快重傳就是來解決這種問題，每收到一個報文段就立即返回確認。如果發送方收到三個冗余確認號相同的ACK，就立即重傳對應的報文段。按照圖示，應當是收到1+3個確認后相同的ACK。
真題
3.5 擁塞控制
擁塞控制介紹
考題中假設接收方采用的確認機制都是“立即確認”。
引發超時重傳--因為默認考題中的接收方采用的是“立即確認”，那么發出的報文未能按時收到ACK就表明網絡擁塞嚴重了。
引發快重傳--接收方“立即確認”能夠按時發送冗余ACK給發送方，說明發送方有報文丟失，但網絡情況沒那么嚴重，因為發送方還能按時收到多個冗余ACK觸發快重傳。
上圖中發送窗口的上限制 看做等于 擁塞窗口，也就是默認接收窗口一直大于擁塞窗口的情況。
慢開始和擁塞避免算法
按照上圖和下圖理解，很透徹。
慢開始階段擁塞窗口（即發送窗口）是指數型增長，當到達閾值后每次只能+1。當發生超時重傳（網絡擁塞嚴重）就恢復慢開始（擁塞窗口重置為1，同時將閾值設為 此前的窗口值/2）。如此反復。
真題
注意：發送窗口 = min（擁塞窗口，接收窗口），題目中的乙的16KB接收緩存就是接收窗口，不被取走意味著接收窗口只會越來越小。
快重傳與快恢復算法
我們說快重傳是網絡不那么擁塞的情況。快重傳觸發時閾值與擁塞窗口相等，等于發生時的擁塞窗口的一半，因此同樣觸發了擁塞避免（一次只能加1個擁塞窗口）。注意：擁塞窗口最小要大于等于2。
)
)
