5.1 傳輸層功能
1. TCP/IP協議集
2. 傳輸層的兩個協議
在TCP/IP協議棧，傳輸層有兩個協議TCP和UDP。
TCP：需要將要傳輸的文件分段 傳輸 建立會話 可靠傳輸 流量控制 如：qq傳文件 訪問網站
UDP：一個數據包就能夠完成數據通信 不分段 不需要建立會話 不需要流量控制 不可靠傳輸。 如：屏幕廣播 多播 廣播 qq聊天
Notes:
查看會話 netstat -n
查看建立會話的進程 netstat -nb
3. 傳輸層協議和應用層協議之間的關係
常見的應用層協議使用的端口
http=TCP+80
https=TCP+443
RDP=TCP+3389
ftp=TCP+21
共享文件夾=TCP+445
SMTP=TCP+25
POP3=TCP+110
telnet=TCP+23
SQL=TCP+1433
DNS=UDP+53
4. 應用層協議和服務之間的關係
服務運行後在TCP或UDP的端口偵聽客戶端請求
客戶端使用IP地址定位服務器 使用目標端口 定位服務
可以在服務器網卡上設置只開放必要的端口 實現服務器網絡安全
Notes:
netstat -an 查看服務偵聽的端口
telnet 192.168.80.100 3389 測試遠程計算機某個端口是否打開
5. 傳輸層功能
6. 傳輸層協議和網絡層協議的主要區別
7. 傳輸層端口
（1）傳輸層的端口
（2）TCP端口
端口用一個 16 位端口號進行標誌
端口號只具有本地意義，即端口號只是爲了標誌本計算機應用層中的各進程。在因特網中不同計算機的相同端口號是沒有聯繫的。
（3）三類端口
熟知端口，數值一般爲 0～1023。
FTP:21
TELNET:23
SMTP:25
DNS:53
HTTP:80
https:443
RDP:3389
登記端口號，數值爲1024～49151
客戶端口號，數值爲49152～65535
5.2 傳輸層協議UDP和TCP
5.2.1 UDP
1. UDP特點
2. UDP報文段格式
3. UDP檢驗和
5.2.2 TCP
1. TCP特點
2. TCP面向字節流的過程
3. TCP的連接
4. TCP報文段格式
- 源端口和目的端口字段——各佔 2 字節。端口是傳輸層與應用層的服務接口。傳輸層的複用和分用功能都要通過端口才能實現。
- 序號字段——佔 4 字節。TCP 連接中傳送的數據流中的每一個字節都編上一個序號。序號字段的值則指的是本報文段所發送的數據的第一個字節的序號。
- 確認號字段——佔 4 字節，是期望收到對方的下一個報文段的數據的第一個字節的序號。
- 數據偏移——佔 4 bit，它指出 TCP 報文段的數據起始處距離 TCP 報文段的起始處有多遠。“數據偏移”的單位不是字節而是 32 bit 字（4 字節爲計算單位）。
- 保留字段——佔 6 bit，保留爲今後使用，但目前應置爲 0。
- 緊急比特 URG —— 當 URG=1 時，表明緊急指針字段有效。它告訴系統此報文段中有緊急數據，應儘快傳送(相當於高優先級的數據)。
- 確認比特 ACK —— 只有當 ACK=1 時確認號字段纔有效。當 ACK=0 時，確認號無效。
- 推送比特 PSH(Push)接收方 TCP 收到推送比特置1的報文段，就儘快地交付給接收應用進程，而不再等到整個緩存都填滿了後再向上交付.
- 復位比特 RST (Reset) —— 當 RST=1 時，表明 TCP 連接中出現嚴重差錯（如由於主機崩潰或其他原因），必須釋放連接，然後再重新建立運輸連接。
- 同步比特 SYN —— 同步比特 SYN 置爲 1，就表示這是一個連接請求或連接接受報文。
- 終止比特 FIN (FINal) —— 用來釋放一個連接。當FIN=1 時，表明此報文段的發送端的數據已發送完畢，並要求釋放運輸連接。
- 窗口字段 —— 佔 2 字節。窗口字段用來控制對方發送的數據量，單位爲字節。TCP 連接的一端根據設置的緩存空間大小確定自己的接收窗口大小，然後通知對方以控制對方的發送窗口的上限。
- 檢驗和 —— 佔 2 字節。檢驗和字段檢驗的範圍包括首部和數據這兩部分。在計算檢驗和時，要在 TCP 報文段的前面加上 12 字節的僞首部。
- 緊急指針字段 —— 佔 16 bit。緊急指針指出在本報文段中的緊急數據的最後一個字節的序號。
- 選項字段 —— 長度可變。TCP 首部可以有多達40字節的可選信息，用於把附加信息傳遞給終點，或用來對齊其它選項。
5.3 TCP如何實現可靠傳輸
1. TCP實現可靠傳輸機制
可靠傳輸的工作原理 —— 停止等待協議。
2. 優化1.中的TCP實現可靠傳輸機制
3. TCP 可靠通信的具體實現
5.4 TCP如何實現流量控制
1. 利用滑動窗口實現流量控制
流量控制就是讓發送方的發送速率不要太快，既要讓接收方來得及接收，也不要使網絡發生擁塞。
利用滑動窗口機制可以很方便地在 TCP 連接上實現流量控制。
5.5 TCP協議如何避免網絡擁塞
5.5.1 擁塞控制的一般原理
若出現擁塞而不進行控制，整個網絡的吞吐量將隨輸入負荷的增大而下降。
5.5.2 擁塞控制算法
慢開始和擁塞避免算法 && 快重傳和快恢復算法
1. 慢開始和擁塞避免算法
（1）defs
發送方維護一個叫做 擁塞窗口cwnd的狀態變量，其值取決於網絡的擁塞程度，並且動態變化。
發送方控制擁塞窗口的原則是：只要網絡沒有出現擁塞，擁塞窗口就再增大一些;但只要網絡出現擁塞,擁塞窗口就減少一些。
判斷出現網絡擁塞的依據:沒有按時收到應當到達的確認報文(即發生重傳)。
接收端窗口: rwnd ；發送端窗口: swnd
（2）慢開始和擁塞避免算法的實現舉例
1.當TCP連接進行初始化時，將擁塞窗口置爲1。
2.設置慢開始門限狀態變量ssthresh
慢開始門限 ssthresh 的用法如下：
當 cwnd < ssthresh 時，使用慢開始算法。
當 cwnd > ssthresh 時，停止使用慢開始算法而改用擁塞避免算法。
當 cwnd = ssthresh 時，既可使用慢開始算法，也可使用擁塞避免算法。
3.慢開始算法思路是讓擁塞窗口 cwnd 按指數增大，即每經過一個往返時間 RTT 就把發送方的擁塞窗口 cwnd 做一個平方，使擁塞窗口 cwnd 按指數規律增長。
4.擁塞避免算法的思路是讓擁塞窗口 cwnd 緩慢地增大，即每經過一個往返時間 RTT 就把發送方的擁塞窗口 cwnd 加 1，使擁塞窗口 cwnd 按線性規律緩慢增長。
注意：
“擁塞避免”並非指完全能夠避免了擁塞。 “擁塞避免”是說在擁塞避免階段把擁塞窗口控制爲按線性規律增長，使網絡比較不容易出現擁塞。
5.無論在慢開始階段還是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有按時收到確認），就要把慢開始門限 ssthresh 設置爲出現擁塞時的發送方窗口值的一半（但不能小於2）。
6.然後把擁塞窗口 cwnd 重新設置爲 1，執行慢開始算法。
( 這樣做的目的就是要迅速減少主機發送到網絡中的分組數，使得發生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。)
2. 快重傳和快恢復算法
(1) defs
快重傳算法首先要求接收方每收到一個失序的報文段後就立即發出重複確認。這樣做可以讓發送方及早知道有報文段沒有到達接收方。
當發送端收到連續三個重複的確認時，就執行“乘法減小”算法，把慢開始門限 ssthresh 減半，但擁塞窗口 cwnd 現在不設置爲 1，而是設置爲慢開始門限 ssthresh 減半後的數值，然後開始執行擁塞避免算法（“加法增大”），使擁塞窗口緩慢地線性增大。
（2）快重傳和快恢復算法的舉例
5.6 TCP的傳輸連接管理
TCP建立連接
TCP釋放連接
