目錄
TCP與UDP的區別
|
TCP（Transmission Control Protocol）的概念 TCP是一種面向連接的，提供可靠交付服務和全雙工通信的，基於字節流的端到端的傳輸層通信協議。
TCP在傳輸數據之前必須先建立連接，數據傳輸結束後要釋放連接。 每一條TCP連接只能有2個端點，故TCP不提供廣播或多播服務。 TCP提供可靠交付，通過TCP連接傳輸的數據，無差錯、不丟失、不重複、並且按序到達。 TCP是面向字節流的。雖然應用進程和TCP的交互是一次一個數據塊(大小不等），但TCP把應用程序交下來的數據看成僅僅是一連串的無結構的字節流。TCP並不知道所傳輸的字節流的含義。
UDP（UserDatagram Protocol）的概念 UDP是一種無連接的，盡最大努力交付的，基於報文的端到端的傳輸層通信協議。 UDP在發送數據之前不需要建立連接 UDP不保證可靠交付，主機不需要建立複雜的連接狀態 UDP是面向報文的。UDP對應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界，即應用層交給UDP多長的報文，UDP就照樣發送，即一次發送一個報文。在接收端，UDP一次交付一個完整的報文。 UDP沒有擁塞控制，網絡出現的擁塞不會使源主機的發送速率降低。 UDP支持一對一、一對多、多對一和多對多的交互通信。 UDP的首部開銷小，只有8個字節，比TCP的20個字節的首部要短。
使用情況 TCP協議適用於對效率要求相對低，但對準確性要求相對高的場景下，或者是有一種連接概念的場景下；而UDP協議適用於對效率要求相對高，對準確性要求相對低的場景。
很多文章都說TCP協議可靠，UDP協議不可靠！爲什麼前者可靠，後者不可靠呢？既然UDP協議不可靠，爲什麼還要使用它呢？所謂的TCP協議是面向連接的協議，面向連接是什麼呢？TCP和UDP都是傳輸層的協議！從編程的角度看，就是兩個模塊（模塊就是代碼的集合，一系列代碼的組合提供相應的功能！模塊化最終目的就是：分工協作！模塊化好處：便於擴展開發以及維護！）。
在一個TCP連接中，僅有兩方進行彼此通信，因此廣播和多播不能用於TCP TCP使用校驗和，累積確認和重傳機制來保證可靠傳輸 TCP使用滑動窗口機制來實現流量控制，通過動態改變窗口的大小進行擁塞控制
|
TCP協議和UDP協議爲什麼會共存
|
1）大家要知道，一種物理線路，單位時間內，能夠創建的“虛擬信道”是有限的！ 2）使用TCP協議傳輸數據，當數據從A端傳到B端後，B端會發送一個確認包（ACK包）給A端，告知A端數據我已收到！UDP協議就沒有這種確認機制！這就是爲什麼說TCP協議可靠，UDP協議不可靠. QQ普通會員就是使用的UDP協議進行傳輸數據！既然UDP協議自身沒有確認機制，這個工作可以交給應用層的進程來完成（QQ）！大家使用QQ的時候，感覺出錯的機率還是非常小吧！當然，把這個確認工作完全交給QQ自身來做，就直接導致了，QQ軟件體積增大！ 有些應用，對數據傳輸可靠性要求非常高，例如大家瀏覽網頁，通過網頁註冊帳號、轉帳等服務，這是不容許出錯的，使用TCP協議能把出錯的可能性降到最低（當然，網絡自身很糟糕，TCP協議也沒辦法）。但是，提供這種可靠服務，會加大網絡帶寬的開銷，因爲“虛擬信道”是持續存在的，同時網絡中還會出現大量的ACK和FIN包！ 因此，魚和熊掌不可兼得，需根據實際情況選擇傳輸協議。TCP協議提供了可靠的數據傳輸,但是其擁塞控制、數據校驗、重傳機制的網絡開銷很大,不適合實時通信,所以選擇開銷很小的UDP協議來傳輸數據。 |
TCP和UDP分別對應的協議
|
TCP對應的協議： （1） FTP：定義了文件傳輸協議，使用21端口。 （2） Telnet：一種用於遠程登陸的端口，使用23端口，用戶可以以自己的身份遠程連接到計算機上，可提供基於DOS模式下的通信服務。 （3） SMTP：郵件傳送協議，用於發送郵件。服務器開放的是25號端口。 （4） POP3：它是和SMTP對應，POP3用於接收郵件。POP3協議所用的是110端口。 （5） HTTP：是從Web服務器傳輸超文本到本地瀏覽器的傳送協議，使用80端口。
UDP對應的協議： （1） DNS：用於域名解析服務，將域名地址轉換爲IP地址。DNS用的是53號端口。 （2） SNMP：簡單網絡管理協議，使用161號端口，是用來管理網絡設備的。由於網絡設備很多，無連接的服務就體現出其優勢。 （3） TFTP(Trival File Transfer Protocal)，簡單文件傳輸協議，該協議在熟知端口69上使用UDP服務。
|
爲什麼 TCP 叫數據流模式？ UDP 叫數據報模式？
|
所謂的“流模式”，是指TCP發送端發送幾次數據和接收端接收幾次數據是沒有必然聯繫的，比如你通過 TCP連接給另一端發送數據，你只調用了一次 write，發送了100個字節，但是對方可以分10次收完，每次10個字節；你也可以調用10次write，每次10個字節，但是對方可以一次就收完。
原因：這是因爲TCP是面向連接的，一個 socket 中收到的數據都是由同一臺主機發出，且有序地到達，所以每次讀取多少數據都可以。
所謂的“數據報模式”，是指UDP發送端調用了幾次 write，接收端必須用相同次數的 read 讀完。UDP是基於報文的，在接收的時候，每次最多隻能讀取一個報文，報文和報文是不會合並的，如果緩衝區小於報文長度，則多出的部分會被丟棄。
原因：這是因爲UDP是無連接的，只要知道接收端的 IP 和端口，任何主機都可以向接收端發送數據。 這時候，如果一次能讀取超過一個報文的數據， 則會亂套。 |
怎樣使用 UDP 實現 TCP 的可靠傳輸
|
要使用 UDP 來構建可靠的面向連接的數據傳輸，就要實現類似於 TCP 協議的超時重傳，有序接收，應答確認，校驗，滑動窗口，流量控制等機制，等於說要在傳輸層的上一層（或者直接在應用層）實現 TCP 協議的可靠數據傳輸機制，比如使用 UDP 數據包+序列號，UDP 數據包+時間戳等方法，在服務器端進行應答確認機制，這樣就會保證不可靠的 UDP 協議進行可靠的數據傳輸 |
TCP通過哪些措施，保證傳輸可靠？
|
TCP提供一種面向連接的、可靠的字節流服務。 面向連接：意味着兩個使用TCP的應用（通常是一個客戶和一個服務器）在彼此交換數據之前必須先建立一個TCP連接。在一個TCP連接中，僅有兩方進行彼此通信。廣播和多播不能用於TCP。
TCP通過下列方式來提供可靠性： 1、應用數據被分割成TCP認爲最適合發送的數據塊。這和UDP完全不同，應用程序產生的數據報長度將保持不變。(將數據截斷爲合理的長度，數據塊)
2、當TCP發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。 (超時重傳)
3、當TCP收到發自TCP連接另一端的數據，它將發送一個確認。這個確認不是立即發送，通常將推遲幾分之一秒 (對於收到的請求，給出確認響應) (之所以推遲，可能是要對包做完整校驗)
4、TCP將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP將丟棄這個報文段和不確認收到此報文段。 (校驗出包有錯，丟棄報文段，不給出響應，TCP發送數據端，超時會重發數據)（校驗機制）
5、既然TCP報文段作爲IP數據報來傳輸，而IP數據報的到達可能會失序，因此TCP報文段的到達也可能會失序。如果必要，TCP將對收到的數據進行重新排序，將收到的數據以正確的順序交給應用層。 (對失序數據進行重新排序，然後才交給應用層)
6、既然IP數據報會發生重複，TCP的接收端必須丟棄重複的數據。(對於重複數據，能夠丟棄重複數據)
7、TCP還能提供流量控制。TCP連接的每一方都有固定大小的緩衝空間。TCP的接收端只允許另一端發送接收端緩衝區所能接納的數據。這將防止較快主機致使較慢主機的緩衝區溢出。(TCP可以進行流量控制，防止較快主機致使較慢主機的緩衝區溢出)TCP使用的流量控制協議是可變大小的滑動窗口協議。
字節流服務: 兩個應用程序通過TCP連接交換8bit字節構成的字節流。TCP不在字節流中插入記錄標識符。我們將這稱爲字節流服務（bytestreamservice）。
TCP對字節流的內容不作任何解釋。TCP不知道傳輸的數據字節流是二進制數據，還是ASCII字符、EBCDIC字符或者其他類型數據。對字節流的解釋由TCP連接雙方的應用層解釋。 |
TCP的擁塞控制原理
|
爲防止過多的數據注入到網絡中，這樣可以使網絡中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提：網絡能夠承受現有的網絡負荷。擁塞控制是一個全局性的過程，涉及到所有的主機、路由器，以及與降低網絡傳輸性能有關的所有因素。 擁塞控制代價：需要獲得網絡內部流量分佈的信息。在實施擁塞控制之前，還需要在結點之間交換信息和各種命令，以便選擇控制的策略和實施控制。這樣就產生了額外的開銷。擁塞控制還需要將一些資源分配給各個用戶單獨使用，使得網絡資源不能更好地實現共享。
幾種擁塞控制方法： 慢開始(slow-start )、擁塞避免(congestion avoidance )； 快重傳( fastretransmit )、快恢復( fastrecovery )。 一切的基礎還是慢開始，這種方法的思路是這樣的： 1. 發送方維持一個叫做“擁塞窗口”的變量，該變量和接收窗口共同決定了發送者的發送窗口，發送方的發送窗口的上限值應當爲接收方窗口rwnd和擁塞窗口cwnd這兩個變量中的較小的一個； 2. 當主機開始發送數據時，避免一下子將大量字節注入到網絡，造成或者增加擁塞，選擇發送一個1字節的試探報文； 3. 當收到第一個字節的數據的確認後，就發送2個字節的報文； 4. 若再次收到2個字節的確認，則發送4個字節，依次遞增2的指數級； 5. 最後會達到一個提前預設的“慢開始門限ssthresh”，比如24，即一次發送了24個分組，此時遵循下面的條件判定： a. cwnd < ssthresh， 繼續使用慢開始算法； b. cwnd > ssthresh，停止使用慢開始算法，改用擁塞避免算法； c. cwnd = ssthresh，既可以使用慢開始算法，也可以使用擁塞避免算法； 6. 所謂擁塞避免算法就是：每經過一個往返時間RTT就把發送方的擁塞窗口+1，即讓擁塞窗口緩慢地增大，按照線性規律增長； 7. 當出現網絡擁塞，比如丟包時，將慢開始門限ssthresh設置爲出現擁塞時的發送方窗口的一半(但不能小於2)，然後將cwnd設爲1，執行慢開始算法（較低的起點，指數級增長）；
上述方法的目的是在擁塞發生時循序減少主機發送到網絡中的分組數，使得發生擁塞的路由器有足夠的時間把隊列中積壓的分組處理完畢。慢開始和擁塞控制算法常常作爲一個整體使用，而快重傳和快恢復則是爲了減少因爲擁塞導致的數據包丟失帶來的重傳時間，從而避免傳遞無用的數據到網絡。下圖爲TCP Tahoe（慢開始+擁塞避免）版本，實際已廢棄不用
快重傳的機制是： 1. 接收方建立這樣的機制，如果一個包丟失，則對後續的包繼續發送針對該包的重傳請求； 2. 一旦發送方接收到三個一樣的確認，就知道該包之後出現了錯誤，立刻重傳該包； 3. 此時發送方開始執行“快恢復”算法： a. 慢開始門限變爲出現擁塞時的一半（爲了預防網絡發生擁塞）； b. 擁塞窗口cwnd設爲上面變化後的慢開始門限的值； c. 執行擁塞避免算法（高起點，線性增長）；
新的TCP Reno版本是在快重傳後採用快恢復算法而不是採用慢開始算法。 在採用快恢復算法時，慢開始算法只是在TCP連接建立時和網絡出現超時 時才使用。
|
TCP的滑動窗口協議與停止等待協議的區別
|
滑動窗口協議中，允許發送方發送多個分組（當有多個分組可用時）而不需等待確認，但它受限於在流水線中爲未確認的分組數不能超過某個最大允許數N。滑動窗口協議是TCP使用的一種流量控制方法，此協議能夠加速數據的傳輸。只有在接收窗口向前滑動時（與此同時也發送了確認），發送窗口才有可能向前滑動。 收發兩端的窗口按照以上規律不斷地向前滑動，因此這種協議稱爲滑動窗口協議。 當發送窗口和接收窗口的大小都等於1時，就是停止等待協議。
所謂滑動窗口協議，自己理解有兩點： 1.“窗口”對應的是一段可以被髮送者發送的字節序列，其連續的範圍稱之爲“窗口”； 2.“滑動”則是指這段“允許發送的範圍”是可以隨着發送的過程而變化的，方式就是按順序“滑動”。在引入一個例子來說這個協議之前，我覺得很有必要先了解以下前提： a. TCP協議的兩端分別爲發送者A和接收者B，由於是全雙工協議，因此A和B應該分別維護着一個獨立的發送緩衝區和接收緩衝區，由於對等性（A發B收和B發A收），我們以A發送B接收的情況作爲例子； b. 發送窗口是發送緩存中的一部分，是可以被TCP協議發送的那部分，其實應用層需要發送的所有數據都被放進了發送者的發送緩衝區； c. 發送窗口中相關的有四個概念：已發送並收到確認的數據（不在發送窗口和發送緩衝區之內）、已發送但未收到確認的數據（位於發送窗口之中）、允許發送但尚未發送的數據以及發送窗口外發送緩衝區內暫時不允許發送的數據； d. 每次成功發送數據之後，發送窗口就會在發送緩衝區中按順序移動，將新的數據包含到窗口中準備發送；
TCP建立連接的初始，B會告訴A自己的接收窗口rwnd大小，比如爲‘20’： 字節31-50爲發送窗口
A發送11個字節後，發送窗口位置不變，B接收到了亂序的數據分組，如下圖：
只有當A成功發送了數據，即發送的數據得到了B的確認之後，纔會移動滑動窗口離開已發送的數據；同時B則確認連續的數據分組，對於亂序的分組則先接收下來，避免網絡重複傳遞：
|
TCP流量控制原理
|
1.概述 所謂的流量控制就是讓發送方的發送速率不要太快，讓接收方來得及接收。利用滑動窗口機制可以很方便的在TCP連接上實現對發送方的流量控制。TCP的窗口單位是字節，不是報文段，發送方的發送窗口不能超過接收方給出的接收窗口的數值。接收方在返回的ACK中會包含自己的接收窗口的大小，以控制發送方的數據發送。
如上圖所示A向B發送數據。在連接建立時，B告訴A接收窗口rwnd（receiver window）= 400，單位字節，因此發送方A的發送窗口不能400。 （可以看出，B向A發送的三個報文段都設置了 ACK = 1以保證字段有效，後面的rwnd值就是接收方對發送方的三次流量控制。） 如圖所示，說明了利用可變窗口大小進行流量控制。設主機A向主機B發送數據。雙方確定的窗口值是400.再設每一個報文段爲100字節長，序號的初始值爲seq=1,圖中的箭頭上面大寫ACK，表示首部中的確認字段爲ACK，小寫ack表示確認字段的值。 接收方的主機B進行了三次流量控制。第一次把窗口設置爲rwnd=300，第二次減小到rwnd=100最後減到rwnd=0，即不允許發送方再發送過數據了。這種使發送方暫停發送的狀態將持續到主機B重新發出一個新的窗口值爲止。 假如，B向A發送了零窗口的報文段後不久，B的接收緩存又有了一些存儲空間。於是B向A發送了rwind=400的報文段，然而這個報文段在傳送中丟失了。A一直等待收不到B發送的非零窗口的通知，而B也一直等待A發送的數據。這樣就死鎖了。爲了解決這種死鎖狀態，TCP爲每個連接設有一個持續計時器。只要TCP連接的一方收到對方的零窗口通知，就啓動持續計時器，週期性的發送一個零窗口探測報文段。對方就在確認這個報文的時候給出 現在的窗口大小（注意：TCP規定，即使設置爲零窗口，也必須接收以下幾種報文段：零窗口探測報文段、確認報文段和攜帶緊急數據的報文段）。
2.TCP報文段發送時機的選擇 TCP報文段發送時機主要有以下幾種選擇途徑。 1）TCP維持一個變量，它等於最大報文段長度MSS，只要緩存中存放的數據達到MSS字節就組裝成一個TCP報文段發送出去。 2）由發送方的應用程序指明要求發送報文段，即TCP支持的推送操作 3）是發送方的一個計時器期限到了，這時就把當前已有的緩存數據裝入報文段發送出去。
傳遞效率的問題： 一個顯而易見的問題是：單個發送字節單個確認，和窗口有一個空餘即通知發送方發送一個字節，無疑增加了網絡中的許多不必要的報文（請想想爲了一個字節數據而添加的40字節頭部吧！），所以我們的原則是儘可能一次多發送幾個字節，或者窗口空餘較多的時候通知發送方一次發送多個字節。 對於前者我們廣泛使用Nagle算法，即： 1. 若發送應用進程要把發送的數據逐個字節地送到TCP的發送緩存，則發送方就把第一個數據字節先發送出去，把後面的字節先緩存起來；（擁塞控制） 2. 當發送方收到第一個字節的確認後（也得到了網絡情況和對方的接收窗口大小），再把緩衝區的剩餘字節組成合適大小的報文發送出去； 3. 當到達的數據已達到發送窗口大小的一半或已達到報文段的最大長度時，就立即發送一個報文段； 對於後者我們往往的做法是讓接收方等待一段時間，或者接收方獲得足夠的空間容納一個報文段或者等到接收緩存有一半空閒的時候，再通知發送方發送數據。 |
