一、傳輸層的功能
1.1 OSI和DoD模型
說明：在
TCP/IP協議棧中，傳輸層有兩個協議TCP和UDP
-
TCP（Transmission Control Protocol），傳輸控制協議，這是一種可靠安全的傳輸協議。一般如果一個文件在傳輸時需要分段，在需要使用此協議。此協議會建立一個會話，實現可靠傳輸。而且還有流量控制功能?？梢允褂妹?code>netstat -nb查看會話。 -
UDP（User Data Protocol），用戶數據報協議。此協議一般用在文件只需要一個數據報就可以傳輸完的情況，不需要分段，不需要建立會話，也不需要流量控制，是一種不可靠的傳輸。可用于多播和廣播。
1.2 傳輸層協議和應用層協議之間的關系
說明：常用的應用層協議使用的端口有
http=TCP+80、https=TCP+443、RDP=TCP+3389、ftp=TCP+21、共享文件夾=TCP+445、SMTP=TCP+25、PoP3=TCP+110、telnet=TCP+23、DNS=UDP+53。這里相關的服務與應用層協議之間的關系是一個偵聽的關系。當數據被發送到接收端的時候，接收端相應啟動的服務會進行偵聽。服務使用TCP或UDP的端口偵聽客戶的請求，客戶端使用IP地址定位服務器，使用目標端口定位服務，可以在服務器網卡上設置只開放必要的端口，實現服務器的網絡安全。一些命令：
- 查看服務偵聽的端口
netstat -anb - 產看建立的會話
netstat -n - 查看建立會話的進程
netstat -nb - 測試連接遠程計算機某個端口是否打開
telnet 192.168.80.100 3389
1.3 傳輸層功能
為相互通信的應用進程提供了邏輯通信
說明：傳輸層為應用進程之間提供端到端的邏輯通信（但網絡層是為主機之間提供邏輯通信），還要對收到的報文進行差錯檢測，提供面向連接和無連接的服務。
1.4 傳輸層的端口
說明：
-
TCP的端口：使用一個16位端口號進行標志，具有本地意義，即端口號只是為了標志本計算機應用層中的各進程。在Internet中不同計算機的相同端口號是沒有聯系的。
分類：
- 熟知的端口，數值一般為
0-1023
FTP:21
telnet:23
SMTP:25
PoP3:110
DNS:53
HTTP:80
https:443
RDP:3389
- 登記端口號，數值為
1024-49151 - 客戶端口號，數值為
49152-65535，使用命令netstat -n | find "ESTABLISHED"
二、傳輸層協議UDP和TCP
2.1 UDP協議
2.1.1 主要特點
此協議是無連接的，即發送數據之前不需要建立連接；使用盡最大努力交付，即不保證可靠交付，同時也不使用擁塞控制；是面向報文的，沒有擁塞控制，很適合多媒體通信的要求；支持一對一、一對多、多對一和多對多的交互通信；首部開銷小，只有八個字節。域名解析就是使用此協議。
2.1.2 UDP協議
說明：
UDP協議的首部如上圖。其中長度是指UDP用戶數據報的長度。
2.2 TCP協議
2.2.1 概述
此協議是面向連接的傳輸層協議，每一條TCP連接只能有兩個端點（endpoint），每一條TCP連接只能是點對點的（一對一），此協議提供可靠交付的服務，提供全雙工通信，面向字節流。
2.2.2 TCP的連接
此協議把連接作為最基本的抽象，每一條TCP連接有兩個端點，連接的端點不是主機，不是主機的IP地址，不是應用程序，也不是傳輸層的協議端口。TCP連接的端點叫做套接字（socket）。端口號拼接到IP地址即構成了套接字。socket=(IP：port)，每一條TCP連接唯一的被通信兩端的兩個端口（即兩個套接字）所確定。
2.2.3 可靠傳輸原理
說明：在傳輸過程中如果無差錯的情況則如圖（
a），發送端發出一個包，接收端接收到之后反饋一個消息，讓發送端發送第二個包，一次類推，直到數據發送完畢。這就是停止等待協議，因為如果接收端不反饋成功接收的消息，發送端是不會發送下一個數據報的。如果在傳輸過程中出現錯誤，則發送端需要等待，等待一個稍微大于往返時間（RTT）的時間段，如果沒收到接收端的反饋，則超時重傳。
-
確認丟失和確認遲到
8
說明：當發送端發送一個數據后，接收端接收到了，但是反饋的數據報丟了，那么發送端則重新發送前面的數據（認為沒有收到），此時發送端收到之后將其丟棄，再次發送反饋的數據。這種情況即確認丟失。而確認遲到是指在上面的情況中，反饋的消息不是丟失了，而是發送太慢，導致發送端以為丟失了，然后重傳，于是接收端繼續丟棄重復數據報，并發送一個反饋消息。 使用上述的確認和重傳機制，我們就可以在不可靠的傳輸網絡上實現可靠的通信。這種可靠傳輸協議通常稱為自動重傳請求
ARQ（Automatic Repeate reQuest）。ARQ標明重傳的請求是自動進行的。接收方不需要請求發送方重傳某個出錯的分組。-
信道利用率
停止等待協議的優點是簡單，但缺點是信道利用率太低。
8
說明：從圖中我們可以看到發送的時間為Td，而一個往返的總時間為（Td+RTT+Ta）。所以信道利用率U=Td/(Td+RTT+Ta)太低。那如果要向提高信道利用率，可選的辦法有提高Td，即流水線傳輸：
9
這種情況下，就是讓發送端一直發送數據，不要等待。那么這種情況下如何實現可靠傳輸呢？ -
連續ARQ協議
10
說明：如上有12個數據報，而發送窗口為5標明每次可以連續發送5個數據報。發送5個數據報之后等待，此時如果收到第一個數據報的反饋信息，那么發送窗口向后移動，發送第六個數據報，依次類推。同時每接受到一個數據報的反饋消息，則此數據報就可以從緩存中刪除了。當然這種方式在確認反饋消息的時候效率不高，可以使用累積確認。 累積確認
接收方一般采用累計確認。優點是容易實現，信道利用率高；缺點是不能向發送方反映出接收方已經正確收到的所有分組的信息。累積確認就是在發送時，首先發送多個數據報，比如此時發送的五個數據報中，第三個數據報沒有收到，此此時就會反饋給接收端已經收到第二個數據報的信息，而接收端則會從第三個數據報開始，進行重發（當然也包括第四個和第五個數據報，雖然它們是發送成功的）。
2.2.4 TCP報文段的首部格式
說明：在發送數據時，有時候數據需要分成很多段發送，比如第一段為
0、1、2、3、4這五個數據組成的一個段，而序號就是指每一段數據中第一個小數據（即0）在整個要發送的數據報中所占的位置（也是0）。當這個數據段被接收端收到之后會發送一個確認號，此時的確認號就是5，即要求發送端發送序號為5的數據段。TCP的首部大多數情況為20個字節，但是也有情況不是，而此時就需要使用數據偏移（首部長度）表示從第幾個字節開始為真正的數據部分了，首部最長是60=（0xFF）*4個字節，這里的0xFF即數據偏移能夠表示的最大十六進制數。
- 標記位
URG=1表示在傳輸數據報時不需要排隊，不管緩存中有多少數據。 - 標記位
ACK=0表示確認號是無效的（在接收數據后其值為1，但是如果還沒有發送數據，那當然就是0）。 - 標記位
SYN=1表示同步，也就是這個數據報的發送需要建立一個會話。 - 標志位
PSH=1表示接收端在將接收到的數據組裝的時候不排序。 - 標志位
RST=1表示TCP會話出現了嚴重的問題，需要重新建立連接。比如我們對某個打開但是會沒有完全打開時，點擊關閉，則會出現這種情況。 - 標志位
FIN=1表示數據傳輸已經完畢了，需要釋放連接。
窗口占兩個字節，比如此時有兩個主機A、B。A在發送數據時可以緩存的字節為65530個字節，于是需要將這個窗口發送給B，看B的接收緩存是不是能夠滿足最大的窗口字節，需要統一。同樣，當B向A發送數據時也需要統一窗口。
緊急指針只有在標志位URG=1的情況下才有作用，這表示TCP報文中數據部分中前面的多少個字節需要緊急處理。
選項中有很多信息，比如最大TCP報文的長度為多少個字節，是不是支持選擇性確認SACK。如果不夠四個字節則會進行填充，以達到四個字節。
2.2.5 TCP如何實現可靠傳輸
- 以字節為單位的滑動窗口技術
12
說明：首先注意發送窗口和接收窗口必須一致，這里使用前面講到的停止等待協議。如果A向B發送數據，在不出錯的情況下，比如將最前面的20個字節分成了三段，1~3、4~7、8~10、11~20進行發送，當B還沒有收到相關數據時，A是不能發送第21個字節及之后的數據的，此時如果A沒有收到B的反饋，則A緩存中的數據是不能刪除的，窗口也是不能移動的，當B反饋確認號為8時，則A緩存中，之前的數據就可以刪除了，發送第八個字節后的數據，同時A的窗口可以向后移動了，可以發送21~27的數據了，而B中就可以將1~7個字節提取出去了，緩存中就可以刪除，同時B的窗口也會向后移動，依次類推。但是如果在傳輸過程中8~10這一段數據丟失了，其他段都接收到了，于是會通過前面講的選擇性確認SACK來告訴A哪一段缺失了，要求重發。注意，不是一收到數據就發送確認，而是發現接收的數據不是連續的才發送確認號。
2.2.6 超時重傳時間的選擇
TCP每發送一個報文段，就對這個報文段設置一次計時器。只要計時器設置的重傳時間到但還沒有收到確認，就要重傳這一報文段。
超時重傳時間應略大于上面得出的加權平均往返時間
RTTs。RFC2988推薦的α值為1/8。
2.2.7 TCP的流量控制
用于解決發送端和接收端處理數據能力不同的問題。比如A發送數據很快，但是B的處理能力有限，很快A發送的數據就將B的緩存占滿了，不能再接收數據了，比如先進行一部分處理才能再次接收，于是B需要向A告知這一點，這就是流量控制。在傳輸數據的過程中會根據自己的處理能力實時反饋相應的窗口，如果不能處理數據，則將窗口設置為零，先處理一部分數據之后再反饋相關信息，當接收端表示能夠繼續接收數據了，于是向發送端發送新的窗口和確認號，但是這個反饋信息如果丟失了怎么辦？這里發送端會定時的發送窗口測定的數據報來檢查接收端的窗口。
2.2.8 TCP擁塞控制
出現資源擁塞的條件：對資源需求的綜合大于可用資源。
擁塞控制是一個全局性的過程，涉及到所有的主機、所有的路由器，以及與降低網絡傳輸性能有關的所有因素。
流量控制往往指在給定的發送端和接收端之間的點對點通信量的控制，它所要做的就是抑制發送端發送數據的速率，以便使接收端來得急接收。
-
擁塞控制所起的作用
14
說明：比如此時網路中最大的處理能力為100M，但是現在各個主機不管，都向其發送數據，使得發送的數據達到500M，此時可能路由器忙不過來了，可能只能處理了10M的數據，或者還可能死機，導致吞吐量極大的降低，這就是擁塞。而TCP都會有一個擁塞控制的作用，一般如果發現網絡較忙時，就會協調傳輸速度，可能此時發送了90M的數據，但是網絡正確處理了85個，此時網絡的吞吐量卻是很高的。 -
慢開始和擁塞避免
發送方維持擁塞窗口cwnd（congestion window）。發送放控制擁塞窗口的原則是：
1、只要網絡沒有出現擁塞，擁塞窗口就再增大一些，以便把更多的分組發送出去
2、只要網絡出現擁塞，擁塞窗口就減小一些，以減少注入到網絡中的分組數。
慢開始算法的原理：
15
說明:可以看到開始的時候只是發送了一個數據報，之后慢慢的增加發送速度，當然每次都會檢查網路傳輸的情況，在網絡暢通的情況下才會增加發送速度，反之則降低發送速度。
16
說明：剛開始的時候速度增長是以2的倍數增加，當達到慢開始門限后，則是每次增加1的速度增加。當速度達到24時發現出現了擁塞，于是則要計算一個新的慢開始門限，即此時速度的一般12，如果還是擁塞，則繼續計算新的慢開始門限，之后則又開始慢慢增長，同時注意，此時的慢開始門限就是12了，而不是最開始的16。
注意：擁塞避免并非指完全能夠避免擁塞。而是在說在擁塞避免階段把擁塞窗口控制為按線性規律增長，使網絡比較不容易出現擁塞。這是最開始的擁塞控制方法，之后又出現了新的方法，即快重傳和快恢復。 -
快重傳和快恢復
快重傳：比如此時發送端向接收端發送了1、2、3、4、5這樣一個數據段，但是在發送的過程中第三個數據丟失了，根據之前講的累積確認，此時還是必須等到第4、5個數據接收到之后才發送確認號，但是要知道只要收到的數據為1、2、4，發送端就已經知道丟包了，于是此時會向發送端連續發送三個相同的確認號，讓其發送第三個數據報，這就是快重傳。
快恢復：如上，丟失第三個數據報可能是因為擁塞，于是發送端會降低擁塞窗口，比如此時減小到了1，但是對于接收端發送的三個相同的確認號，此時卻都收到了，這標明此時網絡又是很好的，不再擁塞了，此時就不會向之前那樣先指數再線性這樣增長了，而是讓擁塞窗口快速恢復到12，然后線性增長，這是相對慢開始來說的。
17 發送窗口的實際上限值
發送方的發送窗口的上限值應當取為接收方窗口和擁塞窗口這兩個變量中較小的一個，即應按一下公式確定：
發送窗口的上限值= Min{rwnd, cwnd}
2.2.9 TCP的運輸連接管理
傳輸連接有三個階段，即：連接建立、數據傳送和連接釋放。TCP連接的建立都是采用客戶服務器方式。主動發起連接建立的應用進程叫客戶（client），被動等待連接建立的應用進程叫做服務器（server）。
-
三次握手建立
TCP連接
18
說明：建立連接個過程中首先客戶端發送一個同步數據報，此時同步標記SYN=1，標志位ACK=0，序號seq=x。服務器接受到這樣一個數據報之后就知道這是一個主動發起連接的數據報，此時服務器發送一個數據報，其中SYN=1，標志位ACK=1，序號seq=y，由服務器指定，確認號ack=x+1，讓客戶端發送第x+1個字節，接下來，客戶端就再次發送確認數據報，此時就沒有同步標記了。在前兩次數據傳輸中已經足夠確定網絡是否暢通，那么為什么還要發第三次確認數據？這是因為當客戶端發起請求，而這個請求可能在網路傳輸中傳輸較慢，一直沒有到達服務器，于是客戶端再次發出請求，而此時請求很快便到達，而此次會話在傳輸任務完成之后會話就斷開了，然而，第一次發起的請求數據報在之后又被服務器接受到了，服務器以為這是客戶端又發起的請求，于是就向客戶端發出確認，然而可能此時客戶端不需要建立連接，于是便不理睬這個確認，于是服務器就一直等待客戶端的確認且發出數據，這樣資源便被浪費了，這種情況多的時候服務器就可能宕機。而在三次握手方式中，服務器如果接受到第三次確認后，那么就人為自己發出的確認信息有用，于是就開始進行數據傳輸了，如果等了一段時間，沒有等到第三次確認，那么就釋放這個連接了。 -
三次握手建立
TCP連接的各狀態
19
說明：客戶端發出第一次請求之后就變成了SYN-SENT狀態，而服務器收到之前是LISTEN狀態，收到之后變為SYN-RCVD狀態，客戶端收到反饋后，發出請求，狀態變為ESTABLISHED，而服務器收到之后變為ESTABLISHED。 -
TCP的連接釋放
20
21
22
23
說明：連接過程如上。 -
連接釋放過程中的狀態
24
說明：連接必須經過2MSL的時間才真正釋放，因為最后一次客戶端向服務器確認的數據可能會丟失，所以需要等待。
