一、網路分層

1.1 OSI七層模型

由國際標準化組織提出的一種概念模型，該模型將通信系統中的資料流劃分為七個層次，每個中間層為其上一層提供功能，其自身功能則由其下一層提供，第1層在底部，

第七層應用層：提供為應用軟體而設計的介面，以設定與另一應用軟體之間的通信，

第六層表示層：把資料轉換為能與接收者的系統格式兼容并適合傳輸的格式，

第五層會話層：負責在資料傳輸中設定和維護計算機網路中兩臺計算機之間的通信連接，對應主機行程，指本地主機與遠程主機正在進行的會話

第四層傳輸層：把傳輸表頭（TH）加至資料以形成資料包，傳輸表頭包含了所使用的協議等發送資訊，

第三層網路層：進行邏輯地址尋址，實作不同網路之間的路徑選擇，

第二層資料鏈路層：負責網路尋址、錯誤偵測和改錯，將位元組合成位元組，進而組合成幀，用MAC地址訪問介質，能發現錯誤但不能糾正，

第一層物理層：建立、維護、斷開物理連接，

1.2 TCP/IP 四層模型

OSI七層模型只是一種理論上的概念模型，并沒有提供一個可以實作的方法，而只是描述了一些概念，并不一定就完全代表了實際情況，其實在實踐中不用分的那么細致，OSI中的一些理論分層可以"合并"實作，實際情況使用的就是TCP/IP四層模型，其定義如下：

第四層應用層：相當于組合了OSI七層模型中的會話層、表示層、應用層

第三層傳輸層：同OSI七層模型中的傳輸層

第二層網際層：同OSI七層模型中的網路層

第一層網路訪問(鏈接)層：相當于OSI七層模型中的物理層和資料鏈路層

1.3 五層模型

除了上面提到的理論上的七層模型和實際使用的四層模型，還有一個五層模型，這個五層模型結合了七層模型和四層模型，主要用于網路協議原理介紹，它與TCP/IP四層模型的區別就是將網路訪問(鏈接)層分為了資料鏈路層和物理層，OSI七層模型、TCP/IP四層模型和五層模型對比如下：

接下來就以五層協議為標準進行總結，

二、物理層

物理層是模型中最低的一層，它確保原始資料可以在各種物理媒介上傳播，所謂的媒介包括光纖、電纜或者電磁波等等，這些媒介可以傳輸物理信號，比如高電壓、低電壓，若用1表示高電壓，0表示低電壓，將資料轉化為按照規范組合的0/1序列，就可以在物理媒介上傳播了，對于接收設備，也需要介面能接受這些物理信號，將其重新轉換為0/1序列，以完成資料的接收，

三、資料鏈路層

即連接層，在兩個網路物體之間提供資料鏈路連接的創建、維持和釋放管理，資訊以幀為單位傳輸，所謂幀，就是一段0/1序列組合，其中有收信地址、送信地址、校驗序列（探測錯誤）等等，其中的地址是MAC地址，幀中的資料往往符合更高層協議，供上層使用，資料鏈路層就像一個送貨員，不會關心資料的具體內容，

此層中常見的協議有以太網、WiFi、幀中繼等等，通過這些協議，我們可以建立一個區域網路（局域網），使得一個局域網中的兩臺計算機可以通信，

幀分為幀頭、資料、幀尾，幀頭和幀尾包含同步資訊、收發地址資訊、差錯控制資訊等，資料部分則包含網路層傳下來的資料，比如IP資料包，

幀頭包含一段被稱為序言的0/1序列，開始會以一定的頻率發送序言，接收設備要按照一定的頻率接收才能做到不丟失資訊，就像我們收聽錄音機之前，需要先調整接收頻率，直到聽清楚播報內容，這個程序叫做調頻，在幀中，序言就是為了發送設備和接收設備頻率一致，這個程序叫做時鐘復原，時鐘調整好之后，等待幀的起始信號(SFD，start frame delimiter，為固定值)，起始信號之后，還有幀的發送地址和目的地址，當然，這個地址是MAC地址，

關于資料部分，前面已經提過了，一般包含符合更高層協議的資料，但是由于資料有最小長度限制，所以尾部可能包含一部分0填充，

幀尾包含校驗序列（FCS ,Frame Check Sequence）,主要是為了校驗資料是否發生錯誤，檢測使用CRC（Cyclic Redundancy Check，回圈冗余檢查）演算法：在一個n位二進制序列之后增加一個m位的二進制序列，生成長度為n+m的新二進制序列，這個m位的二進制序列可以稱之為校驗位，m位的校驗位與n位的原資料之間存在一定的關聯，如果原資料例外，就能通過校驗位檢測出來，

3.1 集線器和交換器

一臺集線器或者交換器上有很多埠，每個埠都能連接一臺設備，

集線器：一臺設備將幀發送到集線器，集線器會將幀廣播到其他所有埠，每臺設備收到幀之后，檢查幀的目標地址是不是本設備的MAC地址，如果不是則忽略該幀，也就是以廣播的方式轉送訊息，所有設備都能收到其他設備發送的訊息，存在的問題一個是安全性，當然可以加密訊息；另外一個是不允許多路同時通信，如果兩臺設備同時向集線器發送訊息，那么集線器會提醒發生沖突，設備上可以實作沖突檢測演算法，如果發生沖突，那么隨機等待一段時間再發送，WiFi的作業方式與此類似，所以WiFi需要特別注重加密（WPA、WPA2），
交換器：交換器記錄了每個設備的MAC地址，當交換器收到幀之后，會根據幀的目的地址和本機存盤的MAC地址記錄，只將幀發送到對應的埠，進而準確發送到對應的設備，交換器允許多路同時通信，

四、網路層

資料鏈路層使得同一個局域網中的的計算機可以相互通信，但是也只限于同一個局域網，要想讓一個局域網里的計算機和以太網上的另一臺計算機通信，則需要一些其它手段，這就是網路層需要做的事兒：提供路由和尋址的功能，使兩終端系統能夠互連且決定最佳路徑，并具有一定的擁塞控制和流量控制的能力，

在資料鏈路層的幀中，只有送信地址和收信地址(MAC地址)，但是跨局域網通信至少需要四個地址（比如資料從一個計算機經過WiFi介面，以太網介面，再到另一個計算機），又由于資料鏈路層已經存在并且正在使用，不能隨意對其更改，所以只能在資料內容上做文章：將目標地址、校驗資訊等寫到資料內容開頭，反正資料鏈路層也不關心具體的資料，這就是IP協議，網路層協議由IP協議規定和實作，所以網路層又稱為IP層，

關于目標地址，IP協議需要的地址和資料鏈路層需要的地址不一樣，資料鏈路層的地址是物理地址(MAC地址)，相對應的，網路層使用的地址叫做IP地址，當設備連接網路，設備將被分配一個IP地址用作標識，通過IP地址，不同網路間的設備可以互相通訊，如果沒有IP地址，我們將無法知道哪個設備是發送方，哪個是接收方，

大多數接入Internet的方式是把主機通過局域網組織在一起，然后再通過交換機或路由器等設備和 Internet 相連接，在同一個局域網路中的計算機不需要網路層，僅依靠資料鏈路層就可以通信，但是對于不同的網路之間相互通信則必須借助路由器等設備，

4.1 MAC地址和IP地址

兩臺設備進行通訊的前提就是知道雙方的地址，而IP地址和MAC地址都是地址，那么僅僅依靠IP地址或者MAC地址能否完成路由呢？

隨著網路接入設備越來越多，為了解決尋址的問題，網路結構被層次化構造，被劃分為了很多個子網，在路由的時候，如果資料包的目的地在其他子網，那么只需要把資料包路由到該子網，剩下的作業交由子網內部處理，這極大的減少了路由器計算量，

MAC地址有48位，可以唯一表示一個網卡，是網路設備制造商生產時寫在硬體內部的，而基于子網的這個結構，如果使用MAC地址進行以太網設備的尋址，那么路由器需要記住每個MAC地址所在的子網，但是理論上，MAC地址可以有2^48個，這個資料量需要占用的記憶體就不允許我們這樣做，所以有了IP地址，（以下對于IP地址的描述都基于IPV4），

IP地址由IP協議提供統一的地址格式，一個IP地址包含兩個標識碼：網路ID和主機ID，同一個局域網路上的所有設備都是用同一個網路ID，網路上的一個主機（包括路由器）有一個主機ID與其對應，IP地址(IPV4)是一個32位的二進制數，通常被分割為4個8位二進制數，一共4個位元組，比如通過點分十進制表示格式為：123.324.213.23，其中每個部分都是對應8位二進制數的十進制形式，同時，Internet委員會定義了5種IP地址型別以適合不同容量的網路，即A類~E類，以C類IP地址為例：

一個C類IP地址的4段號碼中，前三段為網路ID，第四段為主機ID，也就是說C類IP地址由3位元組(24位)的網路地址和1位元組(8位)的主機地址組成，而C類地址的最高位固定為110(二進制)，所以其能表示的地址范圍為：11000000 00000000 00000000 00000001 - 11011111 11111111 11111111 11111110，對應的點分十進制即：192.0.0.1-223.255.255.254，子網掩碼為255.255.255.0，每個網路支持的最大主機數為256-2(除去私有地址192.168.0.0到192.168.255.255)=254臺，

有了IP地址，再回到尋址的問題，IP地址是和子網相關的，對于通一個子網上的設備，其IP地址前綴都是一樣的(網路地址)，路由器能直接通過地址前綴定位到子網，而不用像使用MAC地址那樣無助，由于IP地址必須得等到設備(網卡)接入一個子網之后才能進行分配，在設備還沒有IP地址的時候還是需要使用MAC地址來區分設備，一個設備的IP地址是可以變更的，當IP地址變了之后，還怎么唯一確定一個設備呢？所以IP地址切合的是層次結構，不能唯一標識一個設備，一個形象的比喻就是，MAC地址就像自己的ID號，能唯一標識自己，而IP地址就像一個郵編，方便別人找到自己的所在地，兩者缺一不可，

4.2 IPV6

由于IPv4協議的地址為32位，所以它可以提供2^32，也就是大約40億個地址，如果地球人每人一個IP地址的話，IPv4地址已經遠遠不夠，更何況人均持有的入網設備可能要遠多于一個，所以IPV4地址遲早會耗盡，IPV6就是在IPV4的基礎上做了加長改進，IPV6地址為128位，解決了IPV4地址耗盡的問題，但是由于老的路由器只支持IPV4的IP包，但是無法理解IPV6格式的IP包，所以IPV4到IPV6的遷移需要伴隨著路由設備的更新，而且IPV4網路早已廣泛使用，所以IPV4到IPV6的遷移是一個較為漫長的程序，

4.3 IP包與接力

資料鏈路層以幀為單位傳輸，而在網路層，無論是UDP還是TCP，都是用IP資料包傳遞資訊，IP資料包分為頭部和資料，頭部是為了能夠實作IP協議而附加的資訊，資料部分則是真正要傳輸的資料，

IP包的傳輸要通過路由器的接力，每個主機和路由中都存在一個路由表，可以根據路由表找到IP資料包傳送需要走的路線，就像坐大巴，我們從A城市出發前往D城市，那么可能需要在A城市購票前往B城市，在B城市購票前往C城市，然后再從C城市到達D城市，這個就是路由的程序，只是由于網路被設計為分層的結構，以此基礎進行路由效率較高，

路由表包含地址、網關、子網掩碼和網卡等等資訊，表里描述的是一種規則：如果目的地址符合a規則，那么路由器將IP包發送到a規則規定的中間路由器，該中間路由器收到資料后，會繼續根據目的地址和本機路由表重復上述路由規則，如果根據規則，IP包能夠從本機網卡發送出去，那么就不用繼續路由，直接由本機網卡發送，這個時候IP包已經到目標局域網了，需要注意的是，一個路由器可以擁有多個網卡，也就是可以同時接入多個局域網，就這樣，資料從主機出發，根據路由表不斷接力，最終達到目標地址所在局域網，然后再由資料鏈路層根據幀中的MAC地址將資料發送給指定主機，

4.4 ARP協議(Address Resolution Protocol)

IP包正常接力的前提是，對于一個局域網內，每一臺主機和路由器都能知道局域網內主機的IP地址和其MAC地址的對應關系，每一臺主機或路由中都有一個ARP Cache用以存盤局域網內主機IP地址和MAC地址的對應關系，有了這個對應關系，就能通過一個IP地址獲取對應的MAC地址，而這個關系通過ARP協議傳播到局域網的每個主機和路由：發送資訊時將包含目標IP地址的ARP請求廣播到局域網路上的所有主機，并接識訓傳訊息，以此確定目標的物理地址；收到回傳訊息后將該IP地址和物理地址存入本機ARP快取中并保留一定時間，下次請求時直接查詢ARP快取以節約資源，

籠統的說，IP地址處于網路層，MAC地址處于資料鏈路層，相互沒有直接關聯，通過以太網發送IP資料包時，需要先封裝IP地址(網路層)，再封裝MAC地址(資料鏈路層)，但由于發送時只知道目標IP地址，不知道其MAC地址，又不能跨網路層和資料鏈路層，所以需要使用ARP協議，使用ARP協議，可根據網路層IP資料包包頭中的IP地址資訊決議出目標硬體地址（MAC地址）資訊，以保證通信的順利進行，ARP包需要包裹在一個幀中，它處于資料鏈路層和網路層之間，IPV6中使用的是NDP協議（Neighbor Discovery Protocol），作業在網路層，

4.4.1 ARP欺騙與防治

ARP協議是建立在網路中各個主機互相信任的基礎上的，局域網路上的主機可以自主發送ARP應答訊息，其他主機收到應答報文時不會檢測該報文的真實性就會將其記入本機ARP快取，由此攻擊者就可以向某一主機發送偽ARP應答報文，使發送的資訊無法到達預期的主機或到達錯誤的主機，這就構成了一個ARP欺騙，不過ARP欺騙也可以當做正當用途，比如將未登錄用戶的請求強制轉向登錄界面，

ARP欺騙防治手段

1. ARP靜態配置：由于需要靜態配置每一臺計算機的ARP表，所以不適用于大型網路，

2. DHCP Snooping：啟 DHCP Snooping 功能后，網路中的客戶端只有從管理員指定的DHCP服務器獲取IP地址，必須將交換機上的埠設定為信任(Trust)和非信任(Untrust)狀態，交換機只轉發信任埠的 DHCP OFFER/ACK/NAK報文，丟棄非信任埠的 DHCP OFFER/ACK/NAK 報文，從而達到阻斷非法DHCP服務器的目的，

4.5 RIP協議（Routing Information Protocol）

IP包正常接力的另一個前提是每個主機和路由器上都有正確且合理的路由表，這個路由表描述了網路的拓撲結構，如果你了解自己的網路連接，可以手寫自己主機的路由表，但是一個路由器可能有多個出口，路由表可能會很長，并且周圍連接的其他路由器可能會隨時發生變動(比如新增路由器或者路由器壞掉)，我們就需要路由表能及時將轉向導向其他的路由出口，所以需要一種能自動探測網路生成路由表的協議，

RIP協議就是這樣一種協議，它是一種動態路由選擇協議，通過距離來決定路由表，RIP協議基于距離矢量演算法（DistanceVectorAlgorithms），使用“跳數”(即metric)來衡量到達目標地址的路由距離，這種協議的路由器只關心自己周圍的世界，只與自己相鄰的路由器交換資訊，范圍限制在15跳(15度)之內，再遠它就不關心了，路由器向周圍的路由器和主機廣播自己前往各個IP的距離，收到RIP資料包的路由器和主機根據RIP包和自己到發送RIP包的主機的距離，算出自己前往各個IP的距離（比如我收到A路由器到IP1的距離為3，而我到A路由器的距離為1，那么我經過A路由到IP1的距離就為3+1=4），如果計算出來的新距離優于路由表快取，那么更新路由表，否則保持不變，就這樣在各個點不斷重復RIP廣播/計算距離/更新路由表的程序，最終所有的主機和路由器都能生成最合理的路徑，

由于RIP的跳數標準（超過15跳認為不可達），所以RIP更多應用于互聯網的一部分，這樣一個互聯網的部分往往屬于同一個ISP或者有同一個管理機構，所以叫做自治系統(AS,autonomous system)，自治系統內部的主機和路由根據通向外部的邊界路由器來和其它的自治系統通信，各個邊界路由器之間通過BGP(Border Gateway Protocol，邊界網關協議)來生成自己前往其它自治系統的路由表，而自治系統內部則參照邊界路由器，使用RIP來決定路由表，BGP的基本作業程序與RIP類似，但在考慮距離的同時，也權衡比如政策、連接性能等其他因素，再決定路由表，

4.6 IP協議

IP協議認為自己所處的環境是不可靠的，比如路由器壞掉、電纜斷裂等，所以IP資料包在傳輸程序中如果出現錯誤，那么IP資料包會直接被丟棄，沒有重試之類的補救措施，IP協議保持較為簡單的處理流程，更加復雜的資料可靠性控制較由高層協議處理，

前面提到的IP接力是根據路由表抉擇路徑的，但是在往同一個目的地發送連續的IP資料包的程序中，路由表可能會更新，比如出現了一條新的捷徑，那么后發送的IP資料包由于走了新的捷徑，就可能比之前發送的IP包先到達目的地，這樣就可能導致IP包到達的順序和發送的順序不一致，即使IPv6中的Flow Label可以建議路由器將一些IP包保持一樣的接力路徑，但這只是“建議”，路由器可能會忽略該建議，

4.7 ICMP協議（Internet Control Message Protocol）

ICMP協議處于網路層和傳輸層之間，用于在IP主機、路由器之間傳遞控制訊息，它基于IP協議，一個ICMP包封裝在IP資料包中，控制訊息是指網路通不通、主機是否可達、路由是否可用等網路本身的訊息，這些控制訊息雖然并不傳輸用戶資料，但是對于用戶資料的傳遞起著重要的作用，ICMP協議傳輸的資訊可以分為兩類：

一類是錯誤資訊：上面提到的IP協議本身不會保證IP資料包的可靠性，如果IP資料包丟失，那么IP協議不會做什么補救措施，所以上游發送IP資料包的主機或路由器不知道下游資料例外，會繼續發送資料包，最終導致資料包丟失，而通過ICMP包，下游的路由器和主機可以將錯誤資訊上報給上游，從而讓上游路由器和主機能夠做些補救措施，但是ICMP只負責上報資訊，后續的處理它并不負責，

一類是咨詢類資訊：比如某臺設備詢問路徑上的每個路由器都是誰，然后各個路由器同樣用ICMP包回答，

有了ICMP協議，人們可以更加方便的對IP協議出現的資料問題進行排查和錯誤糾正，ping和traceroute這類網路診斷工具就是基于ICMP協議，但是也有駭客利用偽造的IP包引發大量的ICMP錯誤訊息恢復，并將這些 ICMP包導向受害主機，從而形成DOS攻擊，

五、傳輸層

有了上面物理層、資料鏈路層和網路層協議，兩個以太網中的計算機已經可以實作通信了，但是一個計算機中有許多的行程，每個行程都可能有通信的需求，對于每一個行程，我們需要保證資料包準確的送到該行程之中，參照網路層擴展資料鏈路層的背景，我們也只能在內容資料上添加更加詳細的地址：埠，傳輸層協議(比如TCP、UDP)使用埠號來識別行程，為應用行程提供端到端的通信服務，網路層只是根據IP地址將源結點發出的資料包傳送到目的結點，而傳輸層則負責將資料可靠地傳送到相應的埠，

5.1 UDP協議（User Datagram Protocol）

UDP協議的傳輸和IP協議類似，也是不可靠的，可以將UDP協議看作IP協議暴露在傳輸層的一個介面，其他沒有什么大的區別，之所以設計UDP協議的一個重要原因是，IP協議沒有埠的概念，它只是負責IP到IP的傳輸，但是不同計算機行程之間的通信要依賴埠，也就是傳輸層協議做的事，UDP協議是一個傳輸層協議，實作了埠，從而讓資料包可以在IP協議的基礎上進一步發送到某一個埠，特別是對于不要求可靠性的傳輸，

5.2 TCP協議（Transmission Control Protocol）

TCP協議是一種面向連接的、可靠的、基于位元組流的傳輸層通信協議，流的特點是順序，TCP協議是基于IP協議的，所以資料最侄訓是以IP資料包為單位傳輸，如果需要傳輸的資料很長，那么不能將整個資料放到一個IP資料包中，所以TCP協議封裝到IP資料包的不是整個資料，而是TCP協議規定的分段（segment）或者叫做片段，分段結構類似于IP資料包，包含頭部和資料部分，其中頭部包含該片段的序號，依賴該序號，接收方就能做到按照流的順序接收資料，比如已經接收到了分段1、分段2、分段3，那么接收方就開始期待片段4，如果接收到不符合順序的資料包(比如分段8)，則接收方的TCP模塊可以拒絕接收，以達到按順序接收的目的，一個分段在網路中有最大存活時間，稱之為MSL(Maximum Segment Lifetime)，

5.2.1 可靠性保障-ACK和重復發送

由于片段在傳輸程序中可能會丟失，所以接收主機收到的資料可能是殘缺不堪的，TCP的做法是在每收到一個正確的、符合次序的片段之后，就向發送方發送一個特殊的TCP片段作為ACK回執，告知發送方已經接收到該訊息，如果一個片段序號為M，那么對應的ACK為M+1，也就是接收方期待接收的下一個片段的序號，如果發送方在一定時間等待之后，還是沒有收到ACK回復，那么它就認為之前發送的片段發生了例外，發送方會重復發送那個出現例外的片段，等待ACK回復，如果還是沒有收到，那么再重復發送原片段... 直到收到該片段對應的ACK回復，

5.2.2 滑窗管理

按照上面ACK和重復發送的邏輯：發送->等待ACK->發送->等待ACK.......，在等待ACK的時間，網路都處于閑置狀態，最好能利用好這個時間，為了解決這個問題，發送方和接收方各有一個滑窗，當片段位于滑窗中時，表示TCP正在處理該片段，滑窗中可以有多個片段，也就是可以同時處理多個片段，滑窗越大，越大的滑窗同時處理的片段數目越多，TCP協議也有實時調整滑窗大小的演算法，以提高效率，

我們假設一個可以容納三個片段的滑窗，片段從左向右排列，對于發送方來說，滑窗的左側為已發送并收到ACK的片段序列，滑窗右側是尚未發送的片段序列，滑窗中的片段(比如片段5，6，7)被發送出去，并等待相應的ACK，如果收到片段5的ACK，滑窗將向右移動，這樣新的片段從右側進入滑窗內，被發送出去，并進入等待狀態，在接收到片段5的ACK之前，滑窗不會移動，即使已經收到了片段6和7的ACK，這樣，就保證了滑窗左側的序列是已經發送的、接收到ACK的、符合順序的片段序列，

對于接收方來說，滑窗的左側是已經正確收到并且回復過ACK的片段(比如片段1，2，3，4)，滑窗中是期望接收的片段(比如片段5, 6, 7)，同樣，如果片段6，7先到達，那么滑窗不會移動，如果片段5先到達，那么滑窗會向右移動，以等待接收新的片段，如果出現滑窗之外的片段，比如片段9，那么滑窗將拒絕接收，

對于ACK，如果每個TCP分段都回復一個ACK，那么整個網路流量無疑就翻倍了，事實上，可以將ACK和其他資料片段一起發送，并且不用對每個TCP分段都發送ACK，而是通過一個ACK來通知多個分段接收成功，也就是ACK合并，接收方在接收到片段，并應該回復ACK的時候，會故意延遲一些時間，如果在延遲的時間里有后續的片段到達，就可以利用累計ACK來一起回復，比如，滑窗還沒接收到片段7時，已經接收到片段8，9，當滑窗最終接收到片段7時，滑窗送出一個回復號為10的ACK回復，發送方收到該回復后會了解到片段10之前的片段已經被成功接收，這個程序就不用發送片段7，8所需的兩個ACK，

通過調整滑窗大小，可以方便的控制TCP流量，TCP頭部中有部分window size區域，通過這個區域，接收方將window大小通知給發送方，從而指導發送方修改視窗大小，發送方在收到通知后，會調整自己滑窗的大小，如果發送視窗變小，資料發送速率就會降低，

如果接收方不能處理訊息，可以通知發送方，指導其將視窗大小變更為0（零視窗），讓其停止發送，當接收方經過一段時間的處理，能繼續處理訊息時，可以以ACK的方式通知發送方，讓發送方調整其視窗大小，恢復發送，但是ACK可能會丟失，如果ACK丟失，那么TCP傳輸就陷入了死鎖狀態（發送方一直處于零視窗），為了防止死鎖的出現，發送方會在零視窗后，向接收方發送1byte的TCP分段，并等待包含視窗大小的ACK回復，以此當做探測的手段，如果探測結果顯示視窗依然為0，發送方會等待更長的時間，然后再次進行視窗探測，直到TCP傳輸恢復，同時，接收方宣告的視窗必須達到一定的尺寸，否則等待，這是為了防止視窗太小而導致TCP通信分段中包含的資料很小，浪費流量（主要是TCP分段頭部），除非需要最小化延遲的TCP應用(比如命令列互動)，

5.2.3 三次握手

它使用三次握手建立全雙工連接，流程如下：

客戶端發送SYN（SEQ=x）報文給服務器端，進入SYN_SEND狀態，
服務器端收到SYN報文，回應一個SYN （SEQ=y）+ ACK（ACK=x+1）報文，進入SYN_RECV狀態，
客戶端收到服務器端的SYN報文，回應一個ACK（ACK=y+1）報文，進入Established（連接已建立）狀態，(圖片來自網路)

5.2.4 四次揮手

TCP使用四次揮手終止連接，由于TCP連接屬于全雙工，在一次連接中雙方都可以發送資料，所以兩端都需要單獨進行關閉，客戶端主動斷開連接的流程如下：

一個TCP客戶端發送一個FIN，用來關閉客戶到服務器的資料傳送，（主動關閉）
服務器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1，（服務端執行被動關閉）
服務器關閉客戶端的連接，發送一個FIN給客戶端，
客戶端發回ACK報文確認，并將確認序號設定為收到序號加1，(圖片來自于網路)

TCP連接斷開的原則是當一方完成它的資料發送任務后發送一個FIN來終止這個方向的連接，首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉，收到一個 FIN只意味著這一方向上沒有資料流動，但是一個TCP連接在收到一個FIN后仍能發送資料（另一端），這主要發生在第二和第三階段之間：客戶端(主動方)到服務器(被動方)的連接斷開，但是服務器到客戶端的連接還未斷開，此時服務端可以繼續向客戶端發送資料，但是客戶端不能向服務器發送資料，

第四步客戶端發送的ACK可能會丟失，導致服務器無法收到，服務器如果沒有收到ACK，將會不斷重復發送FIN片段，直到收到客戶端發送的ACK，所以客戶端不能立即關閉，客戶端會在ACK發出之后進入到一個TIME_WAIT狀態，客戶端會設定一個計時器，等待2MSL，如果在該時間內再次收到FIN，那么客戶端會重發ACK并再次等待2MSL，MSL在前面做過介紹，代表TCP分段的最大存活時間，2MSL就是一個發送和一個回復所需的最大時間，如果直到2MSL的等待時間，客戶端都沒有再次收到FIN，那么客戶端就推斷ACK已經被成功接收，則結束TCP連接，

注：以上的描述都是客戶端作為斷開連接的主動方，事實上服務器也可以作為關閉的主動方

5.2.5 堵塞控制

隨著網路設備接入越來越多，網路開始變的繁忙，網路中出現了大量的堵塞，類似于上下班的堵車，IP資料包在網路中經過一個個路由的接力，如果一個路由器過度繁忙，會丟棄一些資料包，UDP協議還好，不用保證資料的可靠性，但是TCP協議需要保證資料的可靠傳輸，如果包含TCP片段的IP資料包丟失時，TCP協議會重復發送該片段，于是網路中產生了更多的資料包，原本繁忙的狀況得到加劇，構成惡性回圈，這種情況被稱作堵塞崩潰，為了解決這一問題，TCP協議加入了堵塞控制，

TCP協議會探測網路狀況，如果網路發生了擁堵，那么會控制自己發送片段的速率，以緩解網路狀況，至于探測的方法主要有ACK超時和重復ACK，一旦發送方認為TCP片段丟失，則認為網路中出現堵塞，

5.3 TCP協議和UDP協議

UDP協議的產生要晚于TCP協議，早期的網路開發者開發出IP協議和TCP協議分別位于網路層和傳輸層，所有的通信都要先經過TCP封裝，再經過IP封裝(應用層->TCP->IP)，開發者將TCP/IP視為相互合作的套裝，但很快網路開發者發現，IP協議的功能和TCP協議的功能是相互獨立的，對于一些簡單的通信，我們并不需要可靠的傳輸，也就不需要TCP協議復雜的建立連接和斷開連接的方式(特別是在早期網路環境中，如果過多的建立TCP連接，會造成很大的網路負擔)，UDP協議隨之被開發出來，作為IP協議在傳輸層的"傀儡"，這樣，網路通信可以通過應用層->UDP->IP的封裝方式，繞過TCP協議，由于UDP協議本身例外簡單，實際上只為IP傳輸起到了橋梁的作用，而UDP協議也可以相對快速地處理這些簡單的通信，

六、應用層

就像現實生活中，不同國家的人可能使用不同的語言，要與一個國家的人交流，需要用他使用的語言，不然就會存在溝通問題，對應到應用程式，一個計算機中不同的行程所做的事可能不一樣，而他們所能理解的資料規則也可能不一樣，除了讓行程能夠準確接收資料包外(傳輸層保證)，還需要保證它能夠正確理解資料包，應用層協議就是做這樣一件事：進一步規范資料包，以達到我們的目的，

6.1 DNS協議

域名是IP地址的代號，通常由字符構成，比如blog.csdn.net，這要比101.200.35.175這種IP格式更加容易記憶，域名決議系統（DNS）就負責將域名翻譯為IP地址，域名和IP地址的對應關系存盤在DNS服務器，這些服務器是指在網路中進行域名決議的一些服務器(計算機)，它們也有自己的IP地址，使用DNS協議進行通信，DNS協議基于UDP協議，屬于應用層協議，

DNS服務器構成一個分級的樹狀體系，上圖中(網圖)，每個節點為一個DNS服務器，每個節點都有自己的IP地址，樹的頂端為用戶電腦出口處的DNS服務器，樹的末端是真正的域名/IP對應關系記錄，一次DNS查詢就是從樹的頂端節點出發，最終找到相應末端記錄的程序，在Linux下，可以使用cat /etc/resolv.conf，在Windows下，可以使用ipcofig /all，來查詢出口DNS服務器，

中間節點根據域名的構成，將DNS查詢引導向下一級的服務器，比如說一個域名cs.berkeley.edu，DNS決議會將域名分割為cs, berkeley, edu，然后按照相反的順序查詢(edu, berkeley, cs)，出口DNS首先根據edu，將查詢指向下一層的edu節點，然后edu節點根據berkeley，將查詢指向下一層的berkeley節點，這臺berkeley服務器上存盤有cs.berkeley.edu的IP地址，

并不是每次域名決議都要完整的經歷決議程序，本機DNS Resolver通常都有DNS快取，在進行DNS查詢之前，計算機會先查詢快取，

6.1.1 反向DNS

上面的DNS查詢均為正向DNS查詢：已經知道域名，想要查詢對應IP，而反向DNS(reverse DNS)是已經知道IP的前提下，想要查詢域名，

6.2 HTTP協議

即超文本傳輸協議，是一個簡單的請求(request)-回應(response)協議，它通常運行在TCP協議之上，屬于應用層協議，它指定了客戶端可能發送給服務器什么樣的訊息，以及得到什么樣的回應，

HTTP協議規定了請求和回應的格式，請求包含請求行、請求頭、空行和請求體，回應包含狀態行、回應頭、空行和回應體，

6.2.1 請求行、請求頭和請求體

請求行：

只有一行，包含三部分資訊，分別是請求的方法(比如POST、GET等)，請求的資源路徑和HTTP協議的版本，比如 GET /shakespeare/v2/notes/636c1ee16eba/book HTTP/1.1，

HTTP/1.1協議定義的8中請求方法，但是并不是所有的服務器都必須支持所有的請求方法，比如APACHE作為一個網頁服務器，支持GET、POST等方法，但是不必支持CONNECT等方法：

GET：主要用于從服務器獲取資源，也可以用于傳輸不重要的資料，通過改寫URL的方式實作：URL?param={param}&...
POST：主要用于向服務器提交資料，資料位于http請求的主體，比如提交表單，
HEAD：類似于GET，不過回傳的回應中沒有資料，回應頭中包含的元資訊應該和一個GET請求的回應訊息相同，常用來測驗超鏈接的有效性、可用性和是否被串改等，
DELETE：請求服務器洗掉Request-URL所標識的資源，
CONNECT：HTTP/1.1協議預留的方法，能夠將連接改為管道方式的代理服務器，通常用于代理服務器，以代理服務器為跳板代替用戶發起請求，然后將資料原模原樣的回傳，
OPTIONS：類似于HEAD方法，這個方法會請求服務器回傳該資源所支持的所有HTTP請求方法，該方法會用*來代替資源名稱，向服務器發送OPTIONS請求，可以測驗服務器功能是否正常，
TRACE：請求服務器回顯其收到的請求資訊，該方法主要用于HTTP請求的測驗或診斷，
PUT：從語意上來說，PUT方法向指定資源位置(URI)上傳其最新內容，如果已經存在則完全覆寫，否則新建，PUT和POST的主要區別可以從冪等性切入，由于PUT是上傳最新的內容，服務器原有資源會被完全代替，所以是冪等的，如果只提交部分內容，又需要冪等，那么不要使用PUT（因為會完全覆寫），而POST在服務端的實作是不可預知的，如果每次更新部分內容，那么不能保證冪等性，

請求頭：頭資訊可以有多行，每一行都是一個鍵值對，關鍵字和值用英文冒號“:”分隔，請求頭通知服務器有關于客戶端請求的資訊比如 Content-type: text/plain，頭資訊是對請求行的補充，

請求體：主體部分包含了具體的資源

6.2.2 狀態行、回應頭和回應體

狀態行：

類似于請求行，回應行也包含三部分資訊，分別是協議版本、狀態碼和狀態描述，比如 HTTP/1.1 200 OK，其中OK是對狀態碼200的描述，只是為了方便人類閱讀，計算機只關心狀態碼，即這里的200，表示一切OK，資源正常回傳，狀態碼有很多，比如302：重定向，404：找不到資源，403：權限不足等等

回應頭：類似請求頭，Content-type說明了主體所包含的資源的型別，根據型別的不同，客戶端可以啟動不同的處理程式，比如：

text/plain：普通文本
text/html：HTML文本
application/json; charset=utf-8：json資料，編碼為utf-8

回應體：回傳的資源，型別參照Content-type，

6.2.3 HTTP請求流程

通過瀏覽器訪問一個網頁：

1、瀏覽器向DNS服務器請求決議該 URL 中的域名所對應的 IP 地址

　　2、決議出 IP 地址后，根據該 IP 地址和默認埠 80，和服務器建立 TCP 連接

　　3、瀏覽器發起HTTP 請求，該請求報文作為 TCP 三次握手的第三個報文的資料發送給服務器

　　4、服務器對瀏覽器請求作出回應，并把對應的 html 文本發送給瀏覽器

　　5、釋放 TCP 連接：若connection 模式為close，則服務器主動關閉TCP 連接，客戶端被動關閉連接，釋放TCP 連接；若connection 模式為keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求

　　6、瀏覽器將該 html 文本并顯示內容

6.2.4 HTTP/2改進

多路復用(Multiplexing)

在 HTTP/1.1 協議中，瀏覽器客戶端在同一時間，針對同一域名下的請求有一定數量限制，超過限制數目的請求會被阻塞，所以一些站點會有多個CDN域名，目的就是為了變相解決對同一域名的請求限制問題，多路復用則允許同時通過單一的 HTTP/2 連接發起多重的請求-回應訊息，所以HTTP/2可以不依賴建立多個TCP連接實作多流并行處理，HTTP/2 把 HTTP 協議通信的基本單位縮小為一個一個的幀，這些幀對應著邏輯流中的訊息，并行的在同一個TCP連接上流轉，

二進制分幀

在HTTP/2(應用層)和傳輸層之間新加入了一個二進制分幀層，在二進制分幀層中，HTTP/2 把傳輸的訊息分割為更小的訊息和幀，并且采用二進制的格式和編碼，而非HTTP/1.0的文本格式，效率更高，其中 HTTP1.x 的頭部資訊會被封裝到 HEADER frame，而相應的訊息體則封裝到 DATA frame 里面，多個幀之間可以亂序發送，根據幀首部的流標識可以重新組裝，

服務器推送

服務端可以在發送HTML時主動推送其它資源，而不用等到瀏覽器決議到相應位置，發起請求再回應，例如服務端可以主動把JS和CSS檔案推送給客戶端，而不需要客戶端決議HTML時再發送這些請求，服務端可以主動推送，客戶端也有權利選擇是否接收，如果服務端推送的資源已經被瀏覽器快取過，瀏覽器可以通過發送RST_STREAM幀來拒收，主動推送也遵守同源策略，服務器不會隨便推送第三方資源給客戶端，

頭部壓縮

HTTP/2對訊息頭采用HPACK（專為HTTP/2頭部設計的壓縮格式）進行壓縮傳輸，能夠節省訊息頭占用的網路流量，而HTTP/1.x每次請求，都會攜帶大量冗余頭資訊，浪費了很多帶寬資源，

6.3 DHCP協議（Dynamic Host Configuration Protocol，動態主機配置協議）

DHCP協議基于UDP協議，常被應用在大型的局域網路環境中，主要作用是集中的管理、分配IP地址，使網路環境中的主機動態的獲得IP地址、Gateway地址、DNS服務器地址等資訊，并能夠提升地址的使用率，網路上的點對點溝通需要有IP地址，但是新接入網路中的主機需要通過DHCP獲取IP地址，所以DHCP需要依賴UDP協議的廣播通信，把UDP資料包發送到網路的廣播地址上，網路上的每個設備都能收到，

DHCP通信分為四步：

Discovery：客戶機發廣播，搜尋DHCP服務器
Offer：DHCP服務器發出邀請，提供一個可用的IP地址
Request：客戶機正式請求使用該IP地址
Acknowledge：DHCP服務器確認，并提供其他配置引數

6.3.1 DHCP攻擊

針對DHCP的一種攻擊辦法是從服務器那里騙IP地址，攻擊者的電腦可以不斷發出DHCP請求，冒充成新入網的客戶機，于是DHCP服務器的地址池被耗干，無法分配地址給后來的用戶，后來的用戶再也沒法使用網路服務，攻擊者很可能會繼續下套，攻擊者占有了大量IP地址，可以裝扮成新的DHCP服務器，把自己騙來的IP地址分配給網路上的新用戶，攻擊者偽裝DHCP服務器之后，可以讓自己成為DNS服務器或者網路的出口，于是客戶機的域名決議和外網通信，必須經過攻擊者的電腦，這個時候，攻擊者可以偷聽通信、偽裝成客戶機、假扮成某個域名的網站，

參考：

https://www.cnblogs.com/vamei

百度百科

維基百科

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/259731.html

標籤：其他

上一篇：藍橋杯演算法提高高精度除高精度

下一篇：關于在進行板載計算機控制的時候用PX4比用APM好的個人感受

網路協議極簡總結

目錄