哈哈哈哈哈哈哈哈

TCPIP識別一個進行通信的應用需要5大要素

• 源IP地址
• 目標IP地址
• 源端口
• 目標端口
• 協議號

---

0-1023 知名端口號
1024-49151 這些端口被正式注冊了 但是可以用于任何通信
49152-65535 操作系統動態分配的端口號
一些知名端口號如下

• 20 ftp-data File Transfer [Deafult Data]
• 21 ftp File Transfer [Control]
• 22 ssh
• 23 talent
• 25 smtp Simple Mail Transfer Protocol
• 43 nicname Who Is
• 53 domain Domain Name Server
• 80 http
• 101 hostname NIC Host Name Server
• 443 https

UDP

常被用于以下幾個方面

• 包總量比較少的通信 DNS SNMP等
• 視頻 音頻等多媒體通信
• 限定于LAN等特定網絡中的應用通信
• 廣播通信(廣播 多播)

TCP

確認應答 序列號

TCP通過檢驗和 序列號 確認應答 重發控制 連接管理 窗口控制 等 機制實現可靠傳輸

確認應答ACK acknowledgement
否定確認應答 NACK negative acknowledgement

• Q1 發送端發送數據后會等待對端的確認應答

  • 一定時間未等到確認應答 發送端認為數據已經丟失 重發
    • 未收到數據也可能是返回的確認在中途丟失
    • 也有可能是對端的確認延遲到達
  • 發送端按照機制重復即可但是對接收端可能重復收到數據 簡直就是災難 需要處理這種情況

• A1 需要一種機制 能識別是否已經接收數據 能判斷是否需要接收

  • 上述確認應答處理 重發控制 重復控制 等等 功能都可以通過序列號實現 序列號是按順序給發送數據的每一個字節(8位字節)都標上號碼的編號
  • 如下圖

超時重發

• Q1 超時時間如何定義
• A1 最好找到一個 確認應答一定時間內一定能在這個時間段內返回
• Q2 TCP要求不論處在何種網絡都提供高性能通信 并且無論網絡擁堵情況發生何種變化 都必須保持這一特性
• A2 每次發包時都計算往返時間及其偏差 往返時間和偏差(RTT時間波動的值 方差)相加 超時重發時間就是這個和在大一丟丟的
• A3 在BSD的Unix以及Windows中 超時都是按0.5s為單位 偏差的最小值也是0.5 所以最小的重發時間時1s
• A4 數據被重發之后若還是收不到則再次發送 超時等待時間會2倍 4倍函數延長 數據也不會無限反復的重復 到達一定的次數后如果仍沒有任何確認應答 則會判斷網絡或對端主機異常 強制管理連接并通知應用程序
• 如下圖

連接管理

三次握手 四次揮手

MSS最大消息長度
TCP在傳送大量消息時 是以MSS進行分割 重發也是也MSS為單位
MSS是在三次握手時計算出來的 在發送SYN請求時會在TCP首部寫入MSS選項 會在兩者中選一個比較小的值投入使用

窗口

為每個數據包進行確認應答的缺點是包往返時間越長網絡的吞吐量越差
引入窗口概念 窗口的滑動如下

窗口控制和重發控制如下圖 P211

流控制

窗口大小這個字段是由接收端控制的 TCP首部中有一個字段通知窗口大小 具體過程如下

擁塞控制 P213

通信剛開始就發送大量數據 可能存在隱藏問題
在網絡擁堵時 如果突然出現一個較大量的數據可能導致網絡癱瘓
TCP為了防止該問題 在通信一開始便會通過一個慢啟動算法得出的數值對發送數據量進行控制
定義了一個擁塞窗口的概念

提高網絡利用率的規范

• Nagle算法 盡在下列任意一種條件滿足才能發送數據 這個算法可能導致某種程度的延遲因此在窗口系統(X Window System)以及繼續控制等領域中使用TCP時往往會關閉該算法的啟用
  • 已發送的數據全部都已經收到確認應答
  • 可以發送最大段長度MSS的數據時
• 延遲確認應答
  • 每次都立刻回復確認應答的話 可能會返回一個較小的窗口(因為剛接收完數據 緩沖區已滿)在流控制一節可以看到接收端可以控制窗口大小
  • 延遲機制如下
    • 在沒有收到2x最大段長度的數據為止不做確認應答(根據操作系統不同 有時不論數據大小 只要收到兩個包就即可返回確認應答的情況) 總而言之就是各種機制延遲確認應答
    • 在其他情況下 最大延遲0.5s發送確認應答 很多操作系統設置為0.2s 延遲超過0.5時很有可能導致重發數據 這個時間越小 CPU的負荷越高性能也下降 時間越大越有可能觸發發送主機的重發處理
• 捎帶應答
  • TCP的確認應答和回執數據一起返回通過一個包發送
  • 比如電子郵件協議的SMTP POP 文件傳輸協議FTP的連接控制部分等
  • 沒有啟動延遲確認應答(即接收數據后立刻返回確認應答)是無法實現捎帶應答的
  • 因為捎帶必須等待應用程序處理完數據并將作為回執的數據返回時才能進行捎帶 哈哈哈

其他傳輸層協議 P218

• UDP-Lite
• SCTP
• DCCP
• 等等

UDP-Lite

• 基于UDP的通信中 檢驗和出現錯誤 所收到的包將全部丟棄 然而現實中有些應用在面對這種情況不希望丟棄
• 如果將UDP中的檢驗和設置為無效那么即使數據的一部分毀壞也不會將整個包廢棄 不過這個方法并不好 如果是IP首部中的IP地址被破壞或者端口號被破壞等等會產生嚴重后果
• 為了解決這些問題 UDP-Lite出現了
• UDP-Lite計算校驗和的范圍可以由應用自行控制 有這樣的機制可以只針對不允許發生錯誤的部分進行校驗和的價差

UDP格式

這個沒啥好說的

TCP格式

TCP中沒有包長度和數據長度的字符串

• 數據偏移 表示TCP所傳輸的數據部分應該從TCP包的哪個部分開始計算 可以理解為TCP首部長度
• 控制位 8位大小 每一位都有其意義 P223
• 緊急指針只有在URG控制位為1時有效 P225
• 可選項 P225

TCP UDP 計算校驗和偽首部

總結

以上是生活随笔為你收集整理的图解TCPIP---第六章---传输层TCPUDP的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。