《TCP/IP - TCP/UDP》

一：概述

　　- 因爲 IP 的傳輸是無狀態的，IP 提供盡力服務，但並不保證數據能夠到達主機。

　　- 因此，數據的完整性須要更上層的 傳輸層來保證。TCP和UDP 均屬於 傳輸層。

 

二：UDP

　　- 特色

　　　　- 不具備可靠性的數據報協議。

　　　　- UDP 雖然能夠肯定發送消息的大小，卻不能保證消息的到達。

　　- 應用場景

　　　　- 即時通信

　　　　- 包總量較少通信

　　　　- 廣播通訊 

 

三：TCP

　　- 特色

　　　　- 面向鏈接的，可靠的流協議。

　　　　- 流即爲不間斷的數據結構，雖然能夠保證發送的順序，可是仍是猶如沒有任何間隔的發送給服務端。

　　- 應用場景

　　　　- 對數據完整性有要求的通訊。

 

四：TCP 是經過什麼機制實現可靠傳輸的？

　　- 確認應答

　　　　- 問題

　　　　　　- 發送端在發送數據以後，並不知道發送的數據是否成功到達了接收端。

　　　　- 解決方案

　　　　　　- TCP 經過確定的確認應答ACK（Positive Acknowled-gement）實現可靠的數據傳輸。

　　　　　　- 若是有確認應答，說明數據已經成功到達對端。反之，則丟失的可能性很大。

 

　　- 序列號

　　　　- 問題

　　　　　　- 在發送端發送數據時，可能由於 某些緣由(網絡問題/硬件問題) 致使接收端沒有收到信息。

　　　　　　- 這樣會致使發送端重複發送，接收端會反覆接收一樣的數據包(而後拋棄數據包)

　　　　　　- 形成主機的壓力，和資源的浪費。

　　　　- 解決方案

　　　　　　-  發送端，數據的每個字節標明編號。

　　　　　　-  接收端，根據首部的序列號和長度，將下一步應該接受的序列號返回。

　　　　　　-  這樣，經過序列號和確認應答號，TCP 能夠實現可靠傳輸。

　　　　　　- 

 

　　- 重發控制

　　　　- 定義

　　　　　　- 重發超時指的是在重發數據以前，等待確認應答的時間間隔。

　　　　　　- 若是超過了這個時間，發送端將重發數據。

　　　　- 問題

　　　　　　- 因爲每一個網絡和當時發生的狀況不同，因此重發超時的時間是不定的。

　　　　- 解決方案

　　　　　　- TCP 會計算數據往返時間和’誤差'。計算超時時間。

　　　　　　- 數據如果重發以後仍是沒有應答，則會 2/4/…. 指數增加

　　　　　　- 當到達必定次數，則會強制關閉鏈接。 

　　- 鏈接管理

　　　　- 三次握手 (創建鏈接)

　　　　- 四次揮手 (斷開鏈接)

　　　　- 

 

　　- 發送數據 (分段傳輸)

　　　　- 問題

　　　　　　- 在 TCP 的數據傳輸中，要規定傳輸數據的大小，以避免出現發送端發送數據過大致使接收端沒法處理的問題。

　　　　- 解決方案

　　　　　　- 在創建TCP鏈接時，發送端和接收端肯定數據包大小，咱們也能夠稱爲 「最大消息長度」 MSS(Max Segment Size)。

　　　　　　-  TCP 在傳輸大數據時，是以MSS進行切割發送，重試也是以MSS爲單位。

　　　　　　- 

 

　　- 窗口控制

　　　　- 問題

　　　　　　- 因爲TCP使用了分段傳輸數據，則會致使通訊往返時間過長，性能變低。

　　　　　　- 

　　　　- 解決方案

　　　　　　-  使用緩衝區(Buffer)對請求作統一處理(有點像Redis的管道處理)，對多個段進行確認應答，提高總體效率。

　　　　　　- 

　　　　- 窗口控制下的重發機制

　　　　　　- 在窗口比較大，出現報文丟失的狀況下，統一序號的確認應答會被不停的返回。

　　　　　　- 而接收端若是連續三次收到了同一個確認應答，則將會對數據進行重發。

　　　　　　- 這種方法比超時控制更有效，也被稱爲高速重發控制。

　　　　　　- 

 

　　- 流量控制

　　　　- 問題

　　　　　　- 在特殊條件下的，接收端處於 高負荷/耗時處理 狀態，須要進行 流量控制。

　　　　- 解決方案

　　　　　　- 接收端向發送端發送本身能夠接受的數據的大小。

　　　　　　- 發送端接收信息後，就不會發送超過這個限度大小的數據，這個範圍被稱做窗口大小。

　　　　- 實例

　　　　　　- 

　　　　　　- 如圖，當接收端收到從3001以後的數據端，既緩衝區已滿，暫停接受數據。

　　　　　　- 以後收到窗口的更新通知纔會繼續發送。

　　　　　　- 可是若是這個通知在傳輸中丟失，可能致使沒法通訊。

　　　　　　- 爲了解決這個問題，發送端會不時的發送一個 窗口探測，來查看接收端狀態。

 　　- 其餘

　　　　- 擁塞控制等

 

五：TCP/UDP  首部。

　　- UDP

　　　　- 

　　　　- 源端口號 (16位)，表示發送端端口號。在不須要返回的通訊中，源端口號爲0。

　　　　- 目標端口號 (16位)，表示接收端端口號。

　　　　- 包長度，保存了UDP首都長度和數據長度之和。(字節)

　　　　- 校驗和，用於數據的校驗。

 

　　- TCP

　　　　- 

　　　　- 源端口號 (16位)，表示發送端端口號。

　　　　- 目標端口號 (16位)，表示接收端端口號。

　　　　- 序列號 (32位)

　　　　　　- 指發送數據的位置，每發送一次。就累積加一次數據字節大小。

　　　　　　- 序號不會從0，1開始，而是在創建鏈接時候已隨機數做爲開始值。

　　　　　　- 創建和斷開鏈接的 SYN和FIN雖然不攜帶數據，可是也會作爲一個字節增長對應的序列號。 

　　　　- 確認應答號 (32位)

　　　　　　- 指下一次應答應該收的的序列號。

　　　　　　- 也能夠說是確認應答-1，發送端收到這個應答就代表這個序號以前的數據被成功接收。 

 

五：三次握手和四次揮手？

　　- 爲何要三次握手？

　　　　- (不許確的)《計算機網絡》：防止已失效的鏈接請求又傳送到服務器端，於是產生錯誤。

　　　　- 爲了實現可靠數據傳輸， TCP 協議的通訊雙方， 都必須維護一個序列號， 以標識發送出去的數據包中， 哪些是已經被對方收到的。

　　　　- 三次握手的過程便是通訊雙方相互告知序列號起始值， 並確認對方已經收到了序列號起始值的必經步驟

　　　　- 若是只是兩次握手， 至多隻有鏈接發起方的起始序列號能被確認， 另外一方選擇的序列號則得不到確認.

　　

　　- 爲何要四次揮手？

　　　　- 創建鏈接，由於當Server端收到Client端的SYN鏈接請求報文後，能夠直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。

　　　　- 可是關閉鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉SOCKET，因此只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。

　　　　- 只有等到我Server端全部的報文都發送完了，我才能發送FIN報文。

　　　　- 所以不能一塊兒發送。故須要四步握手。