看課本學習：傳輸層

前言

本文是複習原來的課本《計算機網絡（第6版）》而總結出來的梳理思惟的小筆記，由於內容也比較多，一次是整理不完了，因此又是慢慢補坑。如有錯誤歡迎提出(ง •_•)ง。

爲何會出現傳輸層

咱們知道網絡層的IP協議能夠經過IP地址來幫助咱們定位到某一臺電腦，可是真的在進行通訊的是電腦上的進程，因此咱們須要一個東西來區分不一樣電腦的不一樣進程，這也是爲何會出現一個傳輸層。
可是這裏就會出現一些問題：

1. 不一樣的操做系統的進程標識符格式不一樣。
2. 進程的建立和撤銷是動態的。
3. 咱們須要的終點入口是功能，而不是實現這個功能的進行是哪個。

解決的方法：使用協議端口號（簡稱端口）
雖然通訊的終點是應用進程，但咱們只要把傳送的東西交給端口，剩下的工做就由傳輸層的協議來完成。

關於端口

端口の分類

1. 服務器端使用的端口號
   熟知端口號（0~1023）：分派給TCP/IP重要應用程序，如DNS是53，SMTP是25。
   登記端口號（1024~49151）：爲沒有熟知端口號的應用程序使用的。
2. 客戶端使用的端口號（49152~65535）。又叫短暫端口號，客戶進程運行時才進行動態選擇。通訊結束後，端口號就會不復存在，後面又會分配給新的客戶進程使用。

傳輸層的兩種協議

分別是無鏈接的UDP和麪向鏈接的TCP。

UDP

UDP是無鏈接的

發送數據以前UDP不須要像TCP同樣創建鏈接，因此減小了開銷和時延。

UDP盡最大努力交付

UDP是不保證可靠交付的，也就是傳輸很快，可是不保證質量。

UDP面向報文

• UDP對於應用層給它的報文：不合並和不拆分，只是保留邊界。因此應用層給它多少，他就一次性發多少。
• UDP對於網絡層給它的報文：去除首部以後，就原封不動的都給應用層。

UDP沒有擁塞控制

因此即便出現網絡擁塞，主機的發送速率也不會下降。對於視頻在線直播，網絡電話之類的應用來講是頗有效的，它們須要實時的傳輸速率，又能夠適當的有數據的損失。

UDP支持x對y的交互通訊

這句話的意思是UDP支持下面四種通訊：

• 一對一
• 一對多
• 多對一
• 多對多

UDP首部開銷小

UDP首部只有8個字節，而TCP首部有20個字節。
UDP首部的結構：

1. 源端口
2. 目的端口
3. 長度
4. 檢驗和

這裏每一個都是佔了2個字節。

UDP的僞首部：
在UDP的8個字節首部的基礎上，其實還有一個12字節的僞首部。
之因此是僞首部，是由於它址在UDP計算檢驗和的時候臨時添加在數據報前的：

• 這個僞首部不會給應用層也不會給網絡層。
• 檢驗方法是把首部和數據部分一塊兒檢驗。
• 若是檢查錯誤，就丟棄/帶着警告交給應用層。

TCP

TCP是面向鏈接的

應用程序在使用TCP協議前，必需要經過三次握手進行創建，要通過四次揮手來結束鏈接。
來插一個本身畫的有機物小劇場，幫助記憶：

Q：爲何是三次握手，不是兩次握手？
A: 在某種狀況下，假如只有兩次握手，第一個分組在路上延遲發送了，等到傳輸結束後，服務器又收到了SYN請求，此時創建鏈接的話就遲遲得不到客戶端的迴應。

每條鏈接只能有兩個端口

TCP鏈接的端口叫作套接字（插口），注意不少地方都有這個套接字的概念，可是在這裏它的定義是：

端口號+IP地址

每一條TCP鏈接惟一地被通訊兩端的兩個端點所肯定。

TCP提供可靠交付的服務

現實狀況下：

1. 傳輸信道可能會有差錯。
2. 接收方可能不能及時處理收到的數據。

因此咱們必需要想辦法來應付這兩種狀況，才能實現可靠的服務：

中止等待協議

咱們假設只有年糕君在發送數據，有機物在接收數據，併發送確認（可是現實是雙方均可以做爲發送方和接收方）。

• 正常狀況下，年糕君發送數據後，有機物收到後再回復一個確認的消息，年糕君收到這個確認的消息纔會繼續發送下一個。

情景一：發送分組丟失
若是一開始年糕君發送的數據塊M丟失了，有機物遲遲沒有迴應，年糕君會經過等待迴應的時間來判斷塊M是否是丟失了，而後就選擇重發，這就是超時重傳。

• 因此必須給予年糕君一個超時計時器，若是年糕君收到有機物確認的時間比定時要早，那就撤銷目前的計時，繼續發送下一個數據塊。

注意點：

1. 年糕君在發送一個分組後，必需要保留髮送分組的副本。
2. 分組和確認分組必須進行編號，這樣才能明確哪一個收到了哪一個沒收到。
3. 計時器設置的重傳時間應該比數據在分組傳輸的平均往返時間更長。

情景二：確認丟失
若是有機物給年糕君的對數據塊M的確認丟失了。年糕君在設定時間內沒有收到確認，就會又發送一個M的副本，有機物收到後此時應該：

• 丟棄這個重複的分組
• 向年糕君發送確認，以避免年糕君又繼續重發M副本。

這樣咱們就能夠實如今不可靠的傳輸網絡上實現可靠通訊，這種協議一般稱爲：自動重傳請求ARQ。

中止等待協議的缺陷
信道利用率過低。
由於年糕君必需要等到收到有機物的確認才能發送下一個，這其中包括了不少時間，除了包括分組和確認的發送時間，還要加上往返時間（RTT）。但這個過程的核心只是分組發送的時間。

解決方法
採用流水線傳輸，也就是年糕君能夠一次性發送多個分組，沒必要收到確認才發送下一個。

TCP提供全雙工通訊

所謂全雙工通訊的定義是：

通訊的雙方能夠同時發送和接收信息的信息交互方式

TCP容許通訊雙方在任什麼時候候都能發送數據。
So，爲何？
由於發送方和接收方都擁有發送緩存和接受緩存，存放雙向通訊的數據。
因此，應用程序把數據塊放進緩存裏後，就能夠去作本身的事情了。好比在發送的時候，只用丟給緩存，就能夠拜拜啦，在接收的時候，有須要再從緩存裏去拿行了。

傳輸是面向字節流的

Q：什麼是「流」？
A: 流入到進程或從進程流出的字節序列。

雖然程序和TCP的交互是一個個數據塊（大小不等），但TCP認爲這些都只是一串無結構的字節流。【雖然個人漫畫畫的是一個個小塊（包裹)，但這個小塊是能夠被拆開，而後把裏面的東西（字節）取出來一些或者填進去一些( •̀ ω •́ )】它不保證發送方的數據塊和接收方的數據塊是同樣的大小，好比你給了它10個塊，可是它只用了4個塊就把你傳來的東西送給它的上級了。TCP是根據當前的窗口值和擁塞狀況來決定一個報文段包含多少字節的。若是TCP緩存數據塊太長，就劃分短一點再發，若是進行一次只發來一個，就等到足夠字數再發送出去。