運輸層
1.運輸層與網絡層的差別。
運輸層協定是在端系統中，而不是在網絡路由器中實作的。是以路由器不處理也不識别。運輸層。所添加的任何封包資訊。
運輸層為運作在不同主機上的程序之間提供了邏輯通信。網絡層提供了主機之間的通信。
2.工作過程
發送方運輸層将接收到的來自發送應用程序的封包，轉換成運輸層封包段。一般的方法為，将應用封包轉化為較小的塊兒，并為每塊兒加上一個運輸層，首部來建立運輸層封包段。然後在發送方端系統中，運輸層将這些封包段傳遞給網絡層。網絡層将其封裝為網絡層分組并向目的地發送。
具體執行個體。
小明家有12個孩子。小紅家有12個孩子。每周，小明家的12個孩子會給小紅家的每個孩子都寫一封信。小張。作為小明家最大的孩子，每周會收取所有的信件。交到郵政運輸車上。小王作為小紅家。最大的孩子。當接收到。這些信件時會依次分發給其他的孩子。
程序 = 所有的孩子。
信封上的字 = 應用層封包。
家庭 = 主機。
小張，小王 = 運輸層協定。
郵政服務（郵政運輸車。） = 網絡層協定。
繼續讨論上面的例子。因為小張小王年紀比較大，是以他們收發信件時幾乎可以保證準确無誤。但是如果小張小王生病了，該工作由第二大的孩子來進行。由于孩子年紀比較小，可能會造成信件丢失等情況。但是他們收發比較快。
無論哪個孩子充當信件的收集和傳遞工作。他們所做的工作都是相同的，也就相當于是提供相同的服務。隻是該服務有好壞之分。就像運輸層所提供的各種協定一樣。有的可以保證資料的準确傳達。有的可以保證資料的快速傳達。
繼續上面的例子。如果郵政服務不能保證信件的傳輸在三天以内。小張，小王也無法将這些信件。收發到其他孩子手中。這說明，兩個孩子的工作取決于郵政服務的工作。
這也說明，運輸層協定所能提供的服務。受到底層網絡層協定服務類型的限制。如果網絡層協定不能為兩組級之間發送，封包提供時延和帶寬保證。那麼運輸成協定。也無法提供這種保證。
3.TCP UDP概要服務介紹
二者提供的最基本服務，将兩個端系統間IP的傳遞服務，擴充到程序間傳遞服務。服務被稱為運輸層的多路複用和多路分解。
同時他們還提供程序間資料傳遞和差錯檢驗。這也是UDP所提供的僅有的兩種服務。
TCP提供額外的服務。可靠資料傳輸。擁塞控制。
4.多路複用和多路分解
運輸層實際上沒有直接将資料傳遞給程序，而是通過一個套接字來傳遞。每個套接字都有唯一的辨別符。
運輸層封包段。如何定向的傳到合适的套接字？
通過在運輸層封包段中設計幾個字段。用來辨別接收的套接字。
多路分解。将運輸層封包段中的資料傳遞到正确的套接字。
多路複用。從不同套接字中收集到資料塊兒。并為每個資料塊封裝上首部資訊，進而形成運輸層封包段。然後傳遞給網絡層。
還是使用上面的例子。多路分解的工作過程為，當小張和小王分。郵件的時候，他們會根據收信人的名字進行郵件的分發。而這個名字就是套接字。收取全部郵件的過程就是多路複用的過程。
--------------------------------------------------------------------------------------------------------------------
下面具體來解釋兩個工作過程。
每個封包段有特殊字段來，訓示該封包段所要傳遞的套接字。
首先特殊字段是 ，源端口号字段和目的端口号字段，以及一些其他資訊。一個端口号的大小為16比特的數字。
--------------------------------------------------------------------------------------------------------------------
UDP中：
主機上的每個套接字被配置設定一個端口号。當封包段到達主機時，運輸層檢查封包段中的目的端口号。并将其定位到相應的套接字。然後封包段中的資料通過套接字進入其連接配接的程序。
一個UDP套接字是由一個包含目的的ip位址。和目的的端口号的二進制組表示。
下面我們來詳細的描述一下UDP
1. 首先如果應用開發人員選擇UDP,而不是TCP,那麼應用程式幾乎直接與ip打交道。
2.主要的性質
無連接配接。發送封包段之前，發送方跟接收方的運輸層實體之間沒有進行握手。
一般在使用該協定時沒有收到響應資訊後，那麼如何處理呢，以DNS為例？
一般的做法是，會試圖向另一個名字伺服器發送查詢資訊。或者直接通知調用的應用程式，它不能獲得響應。
3.為什麼有許多應用程式更适合UDP？
1.應用層能更好地控制要發送的資料。和發送的時間。
當我們使用TCP的時候，如果網絡曾出現壅塞現象，會議室發送方發送的速率。是以對于一些實時應用程式來講，他們要求的是更快的發送速率，不想過分的延遲，并且能夠容忍一些資料的丢失，是以UDP更合适。
2.無需連接配接
如果使用TCP，需要三次握手。這樣會産生一些時延。
3.分組首部開銷比較小。
TCP封包段的首部需要20位元組。但是，UDP隻需要8 bit樹可靠傳輸不？
4. 不可靠傳輸
當我們使用UDP時候，在信道中可能存在分組丢失的現象。這是這條協定不可避免的。但是，使用該協定的應用程式仍可以實作可靠性傳輸。主要原因是因為，該應用程式自身可以建立可靠性機制。來填補UDP不可靠傳輸的缺陷。
5.UDP封包段
5.1 封包段的結構
首部資訊一共有四個字段，每個字段由兩個位元組組成。檢驗核的作用是來判斷傳輸過程當中封包段是否存在差錯。
5.2 UDP檢驗和
5.2.1 作用。
該服務提供了差錯檢驗功能。用于确定當封包段從。目标主機到目的主機時，其比特是否發生了改變。TCP也使用相似的辦法進行差錯檢驗，這是運輸層必須提供的基本服務。
5.2.2 具體方法。
發送方的UDP對封包段中的所有16bit 的和進行反碼運算。求和時遇到的任何溢出都被回卷。得到的結果放在封包段中的檢驗和字段處。
假設有如下的3個16 bit的位元組
他們求和後的結果為：
解釋：首先把前兩個16 bit 進行相加。再與第三個，16 bit 資料進行相加。值得注意的是，在下方紅色框以裡，也就是第二次相加的時候。出現回卷的情況。
什麼是回卷呢？
就是計算後的結果有17位的時候，會把最前面的一位，去掉。把這個數字再與剩餘的16位計算後的結果進行相加。也就會得到我們最終的結果。
那我們怎麼判斷是否在傳輸過程當中比特有改變的現象嗎？
在接收方中把全部的四個比特，也就是包括之前的三個比特以及傳過來的檢驗和，進行相加。 如果計算的結果中，全部16個比特結果都為1。則無差錯。隻要有0出現，則表示在傳輸過程當中有錯誤。
--------------------------------------------------------------------------------------------------------------------
TCP中：
一個TCP套接字。是一個四元組：源ip位址。源端口号。目的ip位址。目的端口号。
--------------------------------------------------------------------------------------------------------------------
5.可靠資料傳輸協定
具體細節參考，如下的文章，因為過于冗長，是以單獨寫了一篇文章。
計算機網絡--運輸層（2）可靠資料傳輸協定：https://mp.csdn.net/postedit/101120301
--------------------------------------------------------------------------------------------------------------------
6. TCP的詳細介紹
具體細節參考，如下的文章，因為過于冗長，是以單獨寫了一篇文章。
計算機網絡--運輸層（3） TCP：https://blog.csdn.net/qq_36098284/article/details/101217287
--------------------------------------------------------------------------------------------------------------------
7.擁塞控制原理。
7.1 控制方法。
7.1.1 端到端擁塞控制。
網絡層不會提供任何關于網絡擁塞的提示資訊給運輸層。是以需要TCP自己進行觀察和控制。兩種控制辦法。增加時延的時間設定。或者減少視窗長度。
7.1.2 網絡輔助。
路由器向發送方顯示的提供網絡中擁塞狀态的回報資訊。該比特可以訓示鍊路層的擁塞情況。
如果使用網絡輔助，也有兩種方式。第一種就是路由器直接告訴發送方，我現在網絡是擁塞的狀态。第二種方式就是路由器修改。發送方傳給接收方的分組資訊。當發送方接收到接收方的資料時，會收到這組擁塞的辨別資訊。就會知道現在網絡狀态是擁塞的。
7.2 ATM ABR擁塞控制。
當網絡輕載時，ABR服務會充分利用空閑的可用代寬。當網絡擁塞時，該服務将其傳輸速率抑制為某些預先設定的最小傳輸速率。
RM資料分組之間作為網絡回報。提供網絡是否擁塞的關鍵資訊。
該控制方法是一種基于速率的方法。也就是發送方明确的計算出它所能發送的最大速率。然後，自己進行相應的調整。
--------------------------------------------------------------------------------------------------------------------
8. TCP擁塞控制。
8.1 背景
對于TCP擁塞控制，它隻能使用端到端的方式，不能使用網絡輔助的方式。
具體表現為讓每一個發送方根據所感覺到的網絡擁塞的程度來限制發送速率。如果他感覺路徑上沒有擁塞，就會增加發送速率。如果有擁塞現象，就會降低發送速率。
8.2 問題
1.如何限制發送方的發送速率？
2.如何感覺網絡的擁塞狀态？
3.什麼算法來改變發送速率？
8.3 Reno 算法
下面我們以這個算法為例研究上面提到的三個問題。
8.3.1 首先是第一個問題。如何限制發送方的發送速率？
該算法要求我們除了之前提到過的幾個變量:LastByteRead、RcvWindow等，還需要一個新的變量。擁塞視窗（congestion window ），CongWin，用于，限制發送方向網絡中發送流量的速率。
運輸層要求發送方未被确認的分組資料量不能超過RcvWindow和CongWin最小值。
8.3.2 下面研究第二個問題，如何感覺路徑上的壅塞狀态？
當出現過渡優色時，該路徑上的多台路由器的緩存會溢出，導緻資料報被丢棄。丢棄的資料接着會引發發送方的丢失事件。這時發送方就認為路徑上出現了擁塞的提示。簡單來說就是當發送方發現逾時或者收到三個備援ACK時候，就認為，資料包的丢失是因為擁塞。
同時，我們考慮在沒有擁塞的網絡環境下，發送方當收到接收方給的确認回報資訊後會認為網絡的傳輸速率是正常的。這時就會增加壅塞視窗的長度來改變傳輸速率。如果确定的速度比較慢，該視窗就會以相當慢的速度增加。如果确定的速度非常快，那麼就會與以快的速度增加視窗的長度。也就是說使用确認來觸發TCP的擁塞視窗長度的增加。是以TCP被稱之為自計時的。
8.3.3 算法細節
1.慢啟動。
2對逾時事件做出反應。
3.加性增，乘性減
### 對加性增，乘性減的解釋
出現丢包事件時，發送方降低及發送速率不僅會影響一台主機。還會影響使用同一路由器路徑的其他主機。也就意味着許多主機都會降低他們在網絡中傳輸資料的速率。進而減輕了擁塞路由器的擁塞程度。
那麼我們現在來思考減少視窗長度時，具體減少多少呢？
我們規定每發生一次丢包事件就将目前的視窗長度值減少一半。也就是乘性減的含義。
現在我們再來讨論一下當。帶寬充足的時候如何增加視窗長度？
我們規定每收到一個确認後，就把視窗長度增加一點，也就是一MSS
###慢啟動。
當一個連接配接建立起來後，初始的視窗長度值設定為一個MSS。同時在初始階段，發送速率不是線性增加的，而是指數速度增加的。計每經過一個RTT将視窗長度值翻倍。發送方繼續與指數速度增加其發送速率，直到發生一個丢包事件為止。此時視窗長度減少為原來的一半。然後就會根據上面描述的線性的進行增長。
###對逾時事件做出反應。
剛收到三個備援ACK時候，視窗長度會減小為原來的一半，然後呈線性增長。
在這個過程當中，TCP始終維持一個數值變量來管理這些複雜的過程。它是用來确定慢啟動将結束并且擁塞，避免将開始的視窗長度。
當發生逾時事件和接收到備援回報資訊時，處理方式是不同的。因為當收到三個備援回饋資訊後，取消慢啟動的階段，我們稱之為快速恢複。主要原因是因為，收到多個備援回報資訊時表明，隻是中間的某些分組在中間信道中丢失，但之後的分組資訊被正确接收。是以并不需要。開啟慢啟動。但是逾時事件發生時，意味着，多數的分組資訊都未被接收。是以幾乎需要全部沖傳。是以處理方式也就不同。