摘要：協議族的構成數據鏈路層網絡層傳輸層應用層和是網絡層的協議，但是它所工作的內容是鏈路層的。。。發送的時候，協議為每個包編號，簡稱，以便接收的一方按照順序還原。并沒有提供任何機制，表示原始文件的大小，這由應用層的協議來規定。

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

ARP和RARP 是網絡層的協議，但是它所工作的內容是鏈路層的。。。具體來說應該是在網絡層

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

其他四層用來處理所有的通信細節，對應用程序一無所知

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

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

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

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

ICMP是IP協議的附屬協議，IP用ICMP來與其他主機或路由器交換錯誤報文和其他重要信息，雖然ICMP主要用于IP但是其他程序也可以訪問ICMP
IGMP用來將一個UDP數據報多播到多個主機

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

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

Telnet遠程登陸

FTP文件傳輸協議

SMTP簡單郵件傳輸協議

SNMP 簡單網絡管理協議

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首部的數據結構

URG：緊急指針有效標志位，當它被置為1時，緊急指針才有效。

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

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

RST：重建連接。

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

FIN：發端完成發送任務。

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

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

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

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

收到 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面向連接的傳輸是以兩個主機間的握手開始的，一個主機發送到另一個主機之間的握手有三個作用：

確保目標主機可用，

且目標主機正在偵聽目標端口號，

通知給目的主機發出者的序號，使雙方在傳輸數據時可以進行跟蹤。

這三點作用，也正是三次連接的過程，也就是目的

第一步建立連接，后兩步都是確認，但是第二次握手是收到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內置在系統協議棧中，極難對其進行改進。

為了防止cwnd增加過快而導致網絡擁塞，所以需要設置一個慢開始門限ssthresh狀態變量（我也不知道這個到底是什么，就認為他是一個擁塞控制的標識）,它的用法：

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

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

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

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

最理想的狀態是，在線路允許的情況下，達到最高速率。但是我們怎么知道，對方線路的理想速率是多少呢？答案就是慢慢試。

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號數據包。）

為什么UDP有時比TCP更有優勢 - 野狗科技官方專欄 - SegmentFault

能夠對握手過程進行精簡，減少網絡通信往返次數；

能夠對TLS加解密過程進行優化；

收發快速，無阻塞。

TCP和UDP都以IP作為網絡層協議，TCP和UDP的每組數據報都通過端系統和每個中間路由器中的IP層在互聯網中傳輸

UDP是無連接協議，TCP是面向連接的協議（兩個對等端內部網之間直接建立邏輯連接）（我們都說TCP是面向連接的傳輸協議，但是網絡傳輸都是沒有連接的，包括TCP也是一樣。TCP所謂的“連接”，其實就是通訊雙方維護的一個“連接狀態”，讓它看上去像是有連接一樣。所以，TCP的狀態轉移是非常重要的。）
TCP比UDP安全。TCP通過跟蹤數據的傳送，并確認和跟蹤序號來確保它成功到達接收方。（TCP為了實現網絡通信的可靠性，使用了復雜的擁塞控制算法，建立了繁瑣的握手過程以及重傳策略。由于TCP內置在系統協議棧中，極難對其進行改進。）
相應的，UDP比TCP傳輸速度更快，實時性更高，網絡帶寬需求更小，功耗更低（雖然TCP協議中植入了各種安全保障功能，但是在實際執行的過程中會占用大量的系統開銷，無疑使速度受到嚴重的影響。反觀UDP由于排除了信息可靠傳遞機制，將安全和排序等功能移交給上層應用來完成，極大降低了執行時間，使速度得到了保證。 ）

QQ等即時通訊軟件使用UDP協議。移動端IM系統的協議選型：UDP還是TCP？ - 即時通訊開發 - SegmentFault

DNS在進行區域傳輸的時候使用TCP協議，其它時候則使用UDP協議。DNS域名解析使用的是TCP協議還是UDP協議？ - 域名解析 - SegmentFault

流媒體

實時游戲

物聯網

技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點） - 即時通訊開發 - SegmentFault

關于TCP/IP，必知必會的十個問題