摘要：協(xié)議族的構(gòu)成數(shù)據(jù)鏈路層網(wǎng)絡(luò)層傳輸層應(yīng)用層和是網(wǎng)絡(luò)層的協(xié)議，但是它所工作的內(nèi)容是鏈路層的。。。發(fā)送的時(shí)候，協(xié)議為每個(gè)包編號(hào)，簡(jiǎn)稱，以便接收的一方按照順序還原。并沒有提供任何機(jī)制，表示原始文件的大小，這由應(yīng)用層的協(xié)議來規(guī)定。

* 數(shù)據(jù)鏈路層：ARP,RARP
* 網(wǎng)絡(luò)層： IP,ICMP,IGMP
* 傳輸層：TCP ,UDP,UGP
* 應(yīng)用層：Telnet,FTP,SMTP,SNMP,HTTP

ARP和RARP 是網(wǎng)絡(luò)層的協(xié)議，但是它所工作的內(nèi)容是鏈路層的。。。具體來說應(yīng)該是在網(wǎng)絡(luò)層

應(yīng)用層關(guān)注的是應(yīng)用程序的細(xì)節(jié)，而不是數(shù)據(jù)在網(wǎng)絡(luò)中的傳輸活動(dòng)

其他四層用來處理所有的通信細(xì)節(jié)，對(duì)應(yīng)用程序一無所知

通常包括操作系統(tǒng)的設(shè)備驅(qū)動(dòng)程序和計(jì)算機(jī)對(duì)應(yīng)的網(wǎng)絡(luò)接口，它們一起處理與電纜（或者其他任何傳輸媒介）的物理接口細(xì)節(jié)。主要處理有關(guān)通信媒介的細(xì)節(jié)（如以太網(wǎng)，令牌環(huán)網(wǎng)等）

ARP地址解析協(xié)議和RARP逆地址解析協(xié)議是數(shù)據(jù)鏈路層協(xié)議，

是某些網(wǎng)絡(luò)接口（如以太網(wǎng)和令牌環(huán)網(wǎng)）使用的特殊協(xié)議，用來轉(zhuǎn)換IP層和鏈路層使用的地址

包括IP網(wǎng)際協(xié)議，ICMP控制報(bào)文協(xié)議，IGMP組管理協(xié)議。
其中IP提供的是不可靠的服務(wù)，他只是負(fù)責(zé)盡可能快地將分組從源節(jié)點(diǎn)送到目的節(jié)點(diǎn)。

ICMP是IP協(xié)議的附屬協(xié)議，IP用ICMP來與其他主機(jī)或路由器交換錯(cuò)誤報(bào)文和其他重要信息，雖然ICMP主要用于IP但是其他程序也可以訪問ICMP
IGMP用來將一個(gè)UDP數(shù)據(jù)報(bào)多播到多個(gè)主機(jī)

傳輸層主要為兩臺(tái)主機(jī)上的應(yīng)用程序提供端到端的通信，在TCP/IP協(xié)議族中，有兩個(gè)互不相同的傳輸協(xié)議：TCP（傳輸控制協(xié)議）和UDP（用戶數(shù)據(jù)報(bào)協(xié)議）。TCP相對(duì)安全穩(wěn)定，但是UDP速度更快。

應(yīng)用層負(fù)責(zé)處理特定的應(yīng)用程序細(xì)節(jié)。幾乎各種不同的TCP/IP實(shí)現(xiàn)都會(huì)提供下面這些通用的應(yīng)用程序：

Telnet遠(yuǎn)程登陸

FTP文件傳輸協(xié)議

SMTP簡(jiǎn)單郵件傳輸協(xié)議

SNMP 簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議

TCP主機(jī)之間通過握手進(jìn)程互相建立起來一種虛擬連接。在握手期間，主機(jī)之間交換序號(hào)，當(dāng)數(shù)據(jù)從一臺(tái)主機(jī)發(fā)送到另一臺(tái)主機(jī)時(shí)序號(hào)便跟蹤這些數(shù)據(jù)。

TCP把數(shù)據(jù)轉(zhuǎn)換成連續(xù)的字節(jié)流，但是不能分辨出字節(jié)流的基礎(chǔ)消息和消息邊界。接收到字節(jié)流后，上層應(yīng)用程序再把字節(jié)流解釋成消息。

可以這么說：發(fā)送方將數(shù)據(jù)按協(xié)議封裝成TCP數(shù)據(jù)包，接收方也按協(xié)議讀取TCP數(shù)據(jù)包中的數(shù)據(jù)。

以太網(wǎng)標(biāo)頭
IP標(biāo)頭
TCP標(biāo)頭

以太網(wǎng)數(shù)據(jù)包的大小是固定的，1500字節(jié)的負(fù)載+22個(gè)字節(jié)的頭信息=1522字節(jié)
IP數(shù)據(jù)包在以太網(wǎng)數(shù)據(jù)包的負(fù)載里面，它也有自己的頭信息，最少需要20個(gè)字節(jié)，所以IP數(shù)據(jù)包的負(fù)載最多為1480字節(jié)
TCP數(shù)據(jù)包在IP數(shù)據(jù)包里面。除去頭信息，它的最大負(fù)載時(shí)1460（但由于IP協(xié)議和TCP協(xié)議往往有額外的頭信息，所以TCP實(shí)際負(fù)載為1440左右。因此，一條1500字節(jié)的信息需要兩個(gè) TCP 數(shù)據(jù)包。HTTP/2協(xié)議的一大改進(jìn)就是壓縮了HTTP協(xié)議的頭信息，使得一個(gè)HTTP請(qǐng)求可以放在一個(gè)TCP數(shù)據(jù)包里，而不是分成多個(gè)，這樣就提高了速度）

下圖是TCP首部的數(shù)據(jù)結(jié)構(gòu)

URG：緊急指針有效標(biāo)志位，當(dāng)它被置為1時(shí)，緊急指針才有效。

ACK：確認(rèn)序號(hào)有效，當(dāng)它被置為1時(shí)，確認(rèn)序號(hào)才有效。

PSH：接受方應(yīng)該盡快將這個(gè)報(bào)文交給應(yīng)用層。

RST：重建連接。

SYN：同步序號(hào)用來發(fā)起一個(gè)新連接。

FIN：發(fā)端完成發(fā)送任務(wù)。

一個(gè)包1400字節(jié)，那么一次性發(fā)送大量數(shù)據(jù)，就必須分成多個(gè)包。比如，一個(gè) 10MB 的文件，需要發(fā)送7100多個(gè)包。

發(fā)送的時(shí)候，TCP 協(xié)議為每個(gè)包編號(hào)（sequence number，簡(jiǎn)稱 SEQ），以便接收的一方按照順序還原。萬一發(fā)生丟包，也可以知道丟失的是哪一個(gè)包。

第一個(gè)包的編號(hào)是一個(gè)隨機(jī)數(shù)。為了便于理解，這里就把它稱為1號(hào)包。假定這個(gè)包的負(fù)載長(zhǎng)度是100字節(jié)，那么可以推算出下一個(gè)包的編號(hào)應(yīng)該是101。這就是說，每個(gè)數(shù)據(jù)包都可以得到兩個(gè)編號(hào)：自身的編號(hào)，以及下一個(gè)包的編號(hào)。接收方由此知道，應(yīng)該按照什么順序?qū)⑺鼈冞€原成原始文件。

（圖片說明：當(dāng)前包的編號(hào)是45943，下一個(gè)數(shù)據(jù)包的編號(hào)是46183，由此可知，這個(gè)包的負(fù)載是240字節(jié)。）

收到 TCP 數(shù)據(jù)包以后，組裝還原是操作系統(tǒng)完成的。應(yīng)用程序不會(huì)直接處理 TCP 數(shù)據(jù)包。

對(duì)于應(yīng)用程序來說，不用關(guān)心數(shù)據(jù)通信的細(xì)節(jié)。除非線路異常，收到的總是完整的數(shù)據(jù)。應(yīng)用程序需要的數(shù)據(jù)放在 TCP 數(shù)據(jù)包里面，有自己的格式（比如 HTTP 協(xié)議）。

TCP 并沒有提供任何機(jī)制，表示原始文件的大小，這由應(yīng)用層的協(xié)議來規(guī)定。比如，HTTP 協(xié)議就有一個(gè)頭信息Content-Length，表示信息體的大小。對(duì)于操作系統(tǒng)來說，就是持續(xù)地接收 TCP 數(shù)據(jù)包，將它們按照順序組裝好，一個(gè)包都不少。

操作系統(tǒng)不會(huì)去處理 TCP 數(shù)據(jù)包里面的數(shù)據(jù)。一旦組裝好 TCP 數(shù)據(jù)包，就把它們轉(zhuǎn)交給應(yīng)用程序。TCP 數(shù)據(jù)包里面有一個(gè)端口（port）參數(shù)，就是用來指定轉(zhuǎn)交給監(jiān)聽該端口的應(yīng)用程序。

（圖片說明：系統(tǒng)根據(jù) TCP 數(shù)據(jù)包里面的端口，將組裝好的數(shù)據(jù)轉(zhuǎn)交給相應(yīng)的應(yīng)用程序。上圖中，21端口是 FTP 服務(wù)器，25端口是 SMTP 服務(wù)，80端口是 Web 服務(wù)器。）

應(yīng)用程序收到組裝好的原始數(shù)據(jù)，以瀏覽器為例，就會(huì)根據(jù) HTTP 協(xié)議的Content-Length字段正確讀出一段段的數(shù)據(jù)。這也意味著，一次 TCP 通信可以包括多個(gè) HTTP 通信。

TCP面向連接的傳輸是以兩個(gè)主機(jī)間的握手開始的，一個(gè)主機(jī)發(fā)送到另一個(gè)主機(jī)之間的握手有三個(gè)作用：

確保目標(biāo)主機(jī)可用，

且目標(biāo)主機(jī)正在偵聽目標(biāo)端口號(hào)，

通知給目的主機(jī)發(fā)出者的序號(hào)，使雙方在傳輸數(shù)據(jù)時(shí)可以進(jìn)行跟蹤。

這三點(diǎn)作用，也正是三次連接的過程，也就是目的

第一步建立連接，后兩步都是確認(rèn)，但是第二次握手是收到SYN包，發(fā)送SYN+ACK包，第三次握手是收到第二次握手的SYN+ACK包，發(fā)送ACK包

第一次握手：建立連接時(shí)，客戶端發(fā)送syn包（syn=j）到服務(wù)器，并進(jìn)入SYN_SENT狀態(tài)，等待服務(wù)器確認(rèn)；SYN：同步序列編號(hào)（Synchronize Sequence Numbers）。

第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=j+1），同時(shí)自己也發(fā)送一個(gè)SYN包（syn=k），即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)；

第三次握手：客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1），此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED（TCP連接成功）狀態(tài)，完成三次握手。

三次握手_百度百科
TCP3次握手連接協(xié)議和4次握手?jǐn)嚅_連接協(xié)議 - Lostyears的專欄 - CSDN博客

只是因?yàn)門CP連接是全雙工的，即數(shù)據(jù)可在兩個(gè)方向上同時(shí)傳遞，所以關(guān)閉時(shí)每個(gè)方向上都要多帶帶關(guān)閉，這種單方向的關(guān)閉就叫半關(guān)閉。

這是因?yàn)榉?wù)端的LISTEN狀態(tài)下的SOCKET當(dāng)收到SYN報(bào)文的連接請(qǐng)求后，它可以把ACK和SYN(ACK起應(yīng)答作用，而SYN起同步作用)放在一個(gè)報(bào)文里來發(fā)送。但關(guān)閉連接時(shí)，當(dāng)收到對(duì)方的FIN報(bào)文通知時(shí)，它僅僅表示對(duì)方?jīng)]有數(shù)據(jù)發(fā)送給你了；但未必你所有的數(shù)據(jù)都全部發(fā)送給對(duì)方了，所以你可能未必會(huì)馬上會(huì)關(guān)閉SOCKET,也即你可能還需要發(fā)送一些數(shù)據(jù)給對(duì)方之后，再發(fā)送FIN報(bào)文給對(duì)方來表示你同意現(xiàn)在可以關(guān)閉連接了，所以它這里的ACK報(bào)文和FIN報(bào)文多數(shù)情況下都是分開發(fā)送的。

TCP為了實(shí)現(xiàn)網(wǎng)絡(luò)通信的可靠性使用了復(fù)雜的擁塞控制算法，建立了繁瑣的握手過程 以及重傳策略。

由于TCP內(nèi)置在系統(tǒng)協(xié)議棧中，極難對(duì)其進(jìn)行改進(jìn)。

為了防止cwnd增加過快而導(dǎo)致網(wǎng)絡(luò)擁塞，所以需要設(shè)置一個(gè)慢開始門限ssthresh狀態(tài)變量（我也不知道這個(gè)到底是什么，就認(rèn)為他是一個(gè)擁塞控制的標(biāo)識(shí)）,它的用法：

        1. 當(dāng)cwnd > ssthresh,使用慢啟動(dòng)算法，

        2. 當(dāng)cwnd < ssthresh,使用擁塞控制算法，停用慢啟動(dòng)算法。

        3. 當(dāng)cwnd = ssthresh，這兩個(gè)算法都可以。

服務(wù)器發(fā)送數(shù)據(jù)包，當(dāng)然越快越好，最好一次性全發(fā)出去。但是，發(fā)得太快，就有可能丟包。帶寬小、路由器過熱、緩存溢出等許多因素都會(huì)導(dǎo)致丟包。線路不好的話，發(fā)得越快，丟得越多。

最理想的狀態(tài)是，在線路允許的情況下，達(dá)到最高速率。但是我們?cè)趺粗溃瑢?duì)方線路的理想速率是多少呢？答案就是慢慢試。

TCP 協(xié)議為了做到效率與可靠性的統(tǒng)一，設(shè)計(jì)了一個(gè)慢啟動(dòng)（slow start）機(jī)制。開始的時(shí)候，發(fā)送得較慢，然后根據(jù)丟包的情況，調(diào)整速率：如果不丟包，就加快發(fā)送速度；如果丟包，就降低發(fā)送速度。

Linux 內(nèi)核里面設(shè)定了（常量TCP_INIT_CWND），剛開始通信的時(shí)候，發(fā)送方一次性發(fā)送10個(gè)數(shù)據(jù)包，即"發(fā)送窗口"的大小為10。然后停下來，等待接收方的確認(rèn)，再繼續(xù)發(fā)送。

默認(rèn)情況下，接收方每收到兩個(gè) TCP 數(shù)據(jù)包，就要發(fā)送一個(gè)確認(rèn)消息。"確認(rèn)"的英語是 acknowledgement，所以這個(gè)確認(rèn)消息就簡(jiǎn)稱 ACK。

ACK 攜帶兩個(gè)信息。

    期待要收到下一個(gè)數(shù)據(jù)包的編號(hào)
    接收方的接收窗口的剩余容量

發(fā)送方有了這兩個(gè)信息，再加上自己已經(jīng)發(fā)出的數(shù)據(jù)包的最新編號(hào)，就會(huì)推測(cè)出接收方大概的接收速度，從而降低或增加發(fā)送速率。這被稱為"發(fā)送窗口"，這個(gè)窗口的大小是可變的。

（圖片說明：每個(gè) ACK 都帶有下一個(gè)數(shù)據(jù)包的編號(hào)，以及接收窗口的剩余容量。雙方都會(huì)發(fā)送 ACK。）

注意，由于 TCP 通信是雙向的，所以雙方都需要發(fā)送 ACK。兩方的窗口大小，很可能是不一樣的。而且 ACK 只是很簡(jiǎn)單的幾個(gè)字段，通常與數(shù)據(jù)合并在一個(gè)數(shù)據(jù)包里面發(fā)送。

（圖片說明：上圖一共4次通信。第一次通信，A 主機(jī)發(fā)給B 主機(jī)的數(shù)據(jù)包編號(hào)是1，長(zhǎng)度是100字節(jié)，因此第二次通信 B 主機(jī)的 ACK 編號(hào)是 1 + 100 = 101，第三次通信 A 主機(jī)的數(shù)據(jù)包編號(hào)也是 101。同理，第二次通信 B 主機(jī)發(fā)給 A 主機(jī)的數(shù)據(jù)包編號(hào)是1，長(zhǎng)度是200字節(jié)，因此第三次通信 A 主機(jī)的 ACK 是201，第四次通信 B 主機(jī)的數(shù)據(jù)包編號(hào)也是201。）

即使對(duì)于帶寬很大、線路很好的連接，TCP 也總是從10個(gè)數(shù)據(jù)包開始慢慢試，過了一段時(shí)間以后，才達(dá)到最高的傳輸速率。這就是 TCP 的慢啟動(dòng)。

TCP 協(xié)議可以保證數(shù)據(jù)通信的完整性，這是怎么做到的？

前面說過，每一個(gè)數(shù)據(jù)包都帶有下一個(gè)數(shù)據(jù)包的編號(hào)。如果下一個(gè)數(shù)據(jù)包沒有收到，那么 ACK 的編號(hào)就不會(huì)發(fā)生變化。

舉例來說，現(xiàn)在收到了4號(hào)包，但是沒有收到5號(hào)包。ACK 就會(huì)記錄，期待收到5號(hào)包。過了一段時(shí)間，5號(hào)包收到了，那么下一輪 ACK 會(huì)更新編號(hào)。如果5號(hào)包還是沒收到，但是收到了6號(hào)包或7號(hào)包，那么 ACK 里面的編號(hào)不會(huì)變化，總是顯示5號(hào)包。這會(huì)導(dǎo)致大量重復(fù)內(nèi)容的 ACK。

如果發(fā)送方發(fā)現(xiàn)收到三個(gè)連續(xù)的重復(fù) ACK，或者超時(shí)了還沒有收到任何 ACK，就會(huì)確認(rèn)丟包，即5號(hào)包遺失了，從而再次發(fā)送這個(gè)包。通過這種機(jī)制，TCP 保證了不會(huì)有數(shù)據(jù)包丟失。

（圖片說明：Host B 沒有收到100號(hào)數(shù)據(jù)包，會(huì)連續(xù)發(fā)出相同的 ACK，觸發(fā) Host A 重發(fā)100號(hào)數(shù)據(jù)包。）

為什么UDP有時(shí)比TCP更有優(yōu)勢(shì) - 野狗科技官方專欄 - SegmentFault

能夠?qū)ξ帐诌^程進(jìn)行精簡(jiǎn)，減少網(wǎng)絡(luò)通信往返次數(shù)；

能夠?qū)LS加解密過程進(jìn)行優(yōu)化；

收發(fā)快速，無阻塞。

TCP和UDP都以IP作為網(wǎng)絡(luò)層協(xié)議，TCP和UDP的每組數(shù)據(jù)報(bào)都通過端系統(tǒng)和每個(gè)中間路由器中的IP層在互聯(lián)網(wǎng)中傳輸

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

QQ等即時(shí)通訊軟件使用UDP協(xié)議。移動(dòng)端IM系統(tǒng)的協(xié)議選型：UDP還是TCP？ - 即時(shí)通訊開發(fā) - SegmentFault

DNS在進(jìn)行區(qū)域傳輸?shù)臅r(shí)候使用TCP協(xié)議，其它時(shí)候則使用UDP協(xié)議。DNS域名解析使用的是TCP協(xié)議還是UDP協(xié)議？ - 域名解析 - SegmentFault

流媒體

實(shí)時(shí)游戲

物聯(lián)網(wǎng)

技術(shù)往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機(jī)慎點(diǎn)） - 即時(shí)通訊開發(fā) - SegmentFault

關(guān)于TCP/IP，必知必會(huì)的十個(gè)問題