TCP/IP協議族

時間 2019-11-08

原文原文鏈接

TCP/IP協議族的構成

* 數據鏈路層：ARP,RARP
* 網絡層： IP,ICMP,IGMP
* 傳輸層：TCP ,UDP,UGP
* 應用層：Telnet,FTP,SMTP,SNMP,HTTP

ARP和RARP 是網絡層的協議，可是它所工做的內容是鏈路層的。。。具體來講應該是在網絡層算法

應用層關注的是應用程序的細節，而不是數據在網絡中的傳輸活動segmentfault

其餘四層用來處理全部的通訊細節，對應用程序一無所知瀏覽器

數據鏈路層：

一般包括操做系統的設備驅動程序和計算機對應的網絡接口，它們一塊兒處理與電纜（或者其餘任何傳輸媒介）的物理接口細節。主要處理有關通訊媒介的細節（如以太網，令牌環網等）緩存

ARP地址解析協議和RARP逆地址解析協議是數據鏈路層協議，安全

是某些網絡接口（如以太網和令牌環網）使用的特殊協議，用來轉換IP層和鏈路層使用的地址服務器

網絡層：

包括IP網際協議，ICMP控制報文協議，IGMP組管理協議。
其中IP提供的是不可靠的服務，他只是負責儘量快地將分組從源節點送到目的節點。網絡

ICMP是IP協議的附屬協議，IP用ICMP來與其餘主機或路由器交換錯誤報文和其餘重要信息，雖然ICMP主要用於IP可是其餘程序也能夠訪問ICMP數據結構

IGMP用來將一個UDP數據報多播到多個主機優化

傳輸層：

傳輸層主要爲兩臺主機上的應用程序提供端到端的通訊，在TCP/IP協議族中，有兩個互不相同的傳輸協議：TCP（傳輸控制協議）和UDP（用戶數據報協議）。TCP相對安全穩定，可是UDP速度更快。spa

應用層：

應用層負責處理特定的應用程序細節。幾乎各類不一樣的TCP/IP實現都會提供下面這些通用的應用程序：

Telnet遠程登錄

FTP文件傳輸協議

SMTP簡單郵件傳輸協議

SNMP 簡單網絡管理協議

TCP協議的報文

TCP數據包的大小（TCP的首部）

TCP主機之間經過握手進程互相創建起來一種虛擬鏈接。在握手期間，主機之間交換序號，當數據從一臺主機發送到另外一臺主機時序號便跟蹤這些數據。

TCP把數據轉換成連續的字節流，可是不能分辨出字節流的基礎消息和消息邊界。接收到字節流後，上層應用程序再把字節流解釋成消息。

能夠這麼說：發送方將數據按協議封裝成TCP數據包，接收方也按協議讀取TCP數據包中的數據。

以太網標頭
IP標頭
TCP標頭

以太網數據包的大小是固定的，1500字節的負載+22個字節的頭信息=1522字節

IP數據包在以太網數據包的負載裏面，它也有本身的頭信息，最少須要20個字節，因此IP數據包的負載最多爲1480字節

TCP數據包在IP數據包裏面。除去頭信息，它的最大負載時1460（但因爲IP協議和TCP協議每每有額外的頭信息，因此TCP實際負載爲1440左右。所以，一條1500字節的信息須要兩個 TCP 數據包。HTTP/2協議的一大改進就是壓縮了HTTP協議的頭信息，使得一個HTTP請求能夠放在一個TCP數據包裏，而不是分紅多個，這樣就提升了速度）

下圖是TCP首部的數據結構

TCP首部的6個標誌位

URG：緊急指針有效標誌位，當它被置爲1時，緊急指針纔有效。

ACK：確認序號有效，當它被置爲1時，確認序號纔有效。

PSH：接受方應該儘快將這個報文交給應用層。

RST：重建鏈接。

SYN：同步序號用來發起一個新鏈接。

FIN：發端完成發送任務。

TCP數據包的編號（SEQ）

一個包1400字節，那麼一次性發送大量數據，就必須分紅多個包。好比，一個 10MB 的文件，須要發送7100多個包。

發送的時候，TCP 協議爲每一個包編號（sequence number，簡稱 SEQ），以便接收的一方按照順序還原。萬一發生丟包，也能夠知道丟失的是哪個包。

第一個包的編號是一個隨機數。爲了便於理解，這裏就把它稱爲1號包。假定這個包的負載長度是100字節，那麼能夠推算出下一個包的編號應該是101。這就是說，每一個數據包均可以獲得兩個編號：自身的編號，以及下一個包的編號。接收方由此知道，應該按照什麼順序將它們還原成原始文件。

（圖片說明：當前包的編號是45943，下一個數據包的編號是46183，由此可知，這個包的負載是240字節。）

TCP數據包的組裝

收到 TCP 數據包之後，組裝還原是操做系統完成的。應用程序不會直接處理 TCP 數據包。

對於應用程序來講，不用關心數據通訊的細節。除非線路異常，收到的老是完整的數據。應用程序須要的數據放在 TCP 數據包裏面，有本身的格式（好比 HTTP 協議）。

TCP 並無提供任何機制，表示原始文件的大小，這由應用層的協議來規定。好比，HTTP 協議就有一個頭信息Content-Length，表示信息體的大小。對於操做系統來講，就是持續地接收 TCP 數據包，將它們按照順序組裝好，一個包都很多。

操做系統不會去處理 TCP 數據包裏面的數據。一旦組裝好 TCP 數據包，就把它們轉交給應用程序。TCP 數據包裏面有一個端口（port）參數，就是用來指定轉交給監聽該端口的應用程序。

（圖片說明：系統根據 TCP 數據包裏面的端口，將組裝好的數據轉交給相應的應用程序。上圖中，21端口是 FTP 服務器，25端口是 SMTP 服務，80端口是 Web 服務器。）

應用程序收到組裝好的原始數據，以瀏覽器爲例，就會根據 HTTP 協議的Content-Length字段正確讀出一段段的數據。這也意味着，一次 TCP 通訊能夠包括多個 HTTP 通訊。

TCP握手（三次鏈接，四次斷開）

三次握手的目的是什麼，都實現了什麼功能？

TCP面向鏈接的傳輸是以兩個主機間的握手開始的，一個主機發送到另外一個主機之間的握手有三個做用：

確保目標主機可用，
且目標主機正在偵聽目標端口號，
通知給目的主機發出者的序號，使雙方在傳輸數據時能夠進行跟蹤。

這三點做用，也正是三次鏈接的過程，也就是目的

三次鏈接的過程

第一步創建鏈接，後兩步都是確認，可是第二次握手是收到SYN包，發送SYN+ACK包，第三次握手是收到第二次握手的SYN+ACK包，發送ACK包

第一次握手：創建鏈接時，客戶端發送syn包（syn=j）到服務器，並進入SYN_SENT狀態，等待服務器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP鏈接成功）狀態，完成三次握手。

三次握手_百度百科
 TCP3次握手鍊接協議和4次握手斷開鏈接協議 - Lostyears的專欄 - CSDN博客

四次斷開的過程

爲何創建鏈接要三次握手，而終止鏈接就要進行四次呢？

只是由於TCP鏈接是全雙工的，即數據可在兩個方向上同時傳遞，因此關閉時每一個方向上都要單獨關閉，這種單方向的關閉就叫半關閉。

這是由於服務端的LISTEN狀態下的SOCKET當收到SYN報文的鏈接請求後，它能夠把ACK和SYN(ACK起應答做用，而SYN起同步做用)放在一個報文裏來發送。但關閉鏈接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你全部的數據都所有發送給對方了，因此你可能未必會立刻會關閉SOCKET,也即你可能還須要發送一些數據給對方以後，再發送FIN報文給對方來表示你贊成如今能夠關閉鏈接了，因此它這裏的ACK報文和FIN報文多數狀況下都是分開發送的。

TCP保證網絡通訊可靠性的方法？

TCP爲了實現網絡通訊的可靠性使用了複雜的擁塞控制算法，創建了繁瑣的握手過程以及重傳策略。

因爲TCP內置在系統協議棧中，極難對其進行改進。

擁塞控制算法

擁塞避免

爲了防止cwnd增長過快而致使網絡擁塞，因此須要設置一個慢開始門限ssthresh狀態變量（我也不知道這個究竟是什麼，就認爲他是一個擁塞控制的標識）,它的用法：

1. 當cwnd > ssthresh,使用慢啓動算法，

        2. 當cwnd < ssthresh,使用擁塞控制算法，停用慢啓動算法。

        3. 當cwnd = ssthresh，這兩個算法均可以。

慢啓動機制和ACK機制

服務器發送數據包，固然越快越好，最好一次性全發出去。可是，發得太快，就有可能丟包。帶寬小、路由器過熱、緩存溢出等許多因素都會致使丟包。線路很差的話，發得越快，丟得越多。

最理想的狀態是，在線路容許的狀況下，達到最高速率。可是咱們怎麼知道，對方線路的理想速率是多少呢？答案就是慢慢試。

TCP 協議爲了作到效率與可靠性的統一，設計了一個慢啓動（slow start）機制。開始的時候，發送得較慢，而後根據丟包的狀況，調整速率：若是不丟包，就加快發送速度；若是丟包，就下降發送速度。

Linux 內核裏面設定了（常量TCP_INIT_CWND），剛開始通訊的時候，發送方一次性發送10個數據包，即"發送窗口"的大小爲10。而後停下來，等待接收方的確認，再繼續發送。

默認狀況下，接收方每收到兩個 TCP 數據包，就要發送一個確認消息。"確認"的英語是 acknowledgement，因此這個確認消息就簡稱 ACK。

ACK 攜帶兩個信息。

期待要收到下一個數據包的編號
    接收方的接收窗口的剩餘容量

發送方有了這兩個信息，再加上本身已經發出的數據包的最新編號，就會推測出接收方大概的接收速度，從而下降或增長髮送速率。這被稱爲"發送窗口"，這個窗口的大小是可變的。

（圖片說明：每一個 ACK 都帶有下一個數據包的編號，以及接收窗口的剩餘容量。雙方都會發送 ACK。）

注意，因爲 TCP 通訊是雙向的，因此雙方都須要發送 ACK。兩方的窗口大小，極可能是不同的。並且 ACK 只是很簡單的幾個字段，一般與數據合併在一個數據包裏面發送。

（圖片說明：上圖一共4次通訊。第一次通訊，A 主機發給B 主機的數據包編號是1，長度是100字節，所以第二次通訊 B 主機的 ACK 編號是 1 + 100 = 101，第三次通訊 A 主機的數據包編號也是 101。同理，第二次通訊 B 主機發給 A 主機的數據包編號是1，長度是200字節，所以第三次通訊 A 主機的 ACK 是201，第四次通訊 B 主機的數據包編號也是201。）

即便對於帶寬很大、線路很好的鏈接，TCP 也老是從10個數據包開始慢慢試，過了一段時間之後，才達到最高的傳輸速率。這就是 TCP 的慢啓動。

丟包處理（重傳機制）

TCP 協議能夠保證數據通訊的完整性，這是怎麼作到的？

前面說過，每個數據包都帶有下一個數據包的編號。若是下一個數據包沒有收到，那麼 ACK 的編號就不會發生變化。

舉例來講，如今收到了4號包，可是沒有收到5號包。ACK 就會記錄，期待收到5號包。過了一段時間，5號包收到了，那麼下一輪 ACK 會更新編號。若是5號包仍是沒收到，可是收到了6號包或7號包，那麼 ACK 裏面的編號不會變化，老是顯示5號包。這會致使大量重複內容的 ACK。

若是發送方發現收到三個連續的重複 ACK，或者超時了尚未收到任何 ACK，就會確認丟包，即5號包遺失了，從而再次發送這個包。經過這種機制，TCP 保證了不會有數據包丟失。

（圖片說明：Host B 沒有收到100號數據包，會連續發出相同的 ACK，觸發 Host A 重發100號數據包。）

TCP協議和UDP協議的使用場景，以及區別？

爲何UDP有時比TCP更有優點 - 野狗科技官方專欄 - SegmentFault

UDP協議的優勢

可以對握手過程進行精簡，減小網絡通訊往返次數；

可以對TLS加解密過程進行優化；

收發快速，無阻塞。

TCP和UDP的相同點？

TCP和UDP都以IP做爲網絡層協議，TCP和UDP的每組數據報都經過端系統和每一箇中間路由器中的IP層在互聯網中傳輸

TCP和UDP的區別？

UDP是無鏈接協議，TCP是面向鏈接的協議（兩個對等端內部網之間直接創建邏輯鏈接）（咱們都說TCP是面向鏈接的傳輸協議，可是網絡傳輸都是沒有鏈接的，包括TCP也是同樣。TCP所謂的「鏈接」，其實就是通信雙方維護的一個「鏈接狀態」，讓它看上去像是有鏈接同樣。因此，TCP的狀態轉移是很是重要的。）

TCP比UDP安全。TCP經過跟蹤數據的傳送，並確認和跟蹤序號來確保它成功到達接收方。（TCP爲了實現網絡通訊的可靠性，使用了複雜的擁塞控制算法，創建了繁瑣的握手過程以及重傳策略。因爲TCP內置在系統協議棧中，極難對其進行改進。）

相應的，UDP比TCP傳輸速度更快，實時性更高，網絡帶寬需求更小，功耗更低（雖然TCP協議中植入了各類安全保障功能，可是在實際執行的過程當中會佔用大量的系統開銷，無疑使速度受到嚴重的影響。反觀UDP因爲排除了信息可靠傳遞機制，將安全和排序等功能移交給上層應用來完成，極大下降了執行時間，使速度獲得了保證。）