七層網(wǎng)絡(luò)協(xié)議

OSI七層模型

Open System Interconnection 適用于所有網(wǎng)絡(luò)

  • 分工帶來效能
  • 將復(fù)雜的流程分解為幾個功能相對單一的子進(jìn)程
  • 整個流程更加清晰慈俯，復(fù)雜問題簡單化
  • 更容易發(fā)現(xiàn)問題并針對性的解決問題
    • 應(yīng)用層(Application)提供網(wǎng)絡(luò)與用戶應(yīng)用軟件之間的接口服務(wù)(HTTP)
    • 表示層(Presentation)提供格式化的表示和轉(zhuǎn)換數(shù)據(jù)服務(wù)归苍，如加密和壓縮
    • 會話層(Session)提供包括訪問驗(yàn)證和會話管理在內(nèi)的建立和維護(hù)應(yīng)用之間通信的機(jī)制;這三層也可歸為應(yīng)用層
    • 傳輸層(Transimission)提供建立、維護(hù)和取消傳輸連接功能麸恍，負(fù)責(zé)可靠的傳輸數(shù)據(jù)(TCP)
    • 網(wǎng)絡(luò)層(NetWork)處理網(wǎng)絡(luò)間路由灵巧，確保數(shù)據(jù)及時傳送(路由器)
    • 數(shù)據(jù)鏈路層(DataLink)負(fù)責(zé)無錯傳輸數(shù)據(jù)，確認(rèn)幀抹沪，發(fā)錯重傳等(交換機(jī))
    • 物理層(Physics)提供機(jī)械刻肄、電氣、功能和過程特性(網(wǎng)卡融欧，網(wǎng)線敏弃，雙絞線，同軸電纜噪馏，中繼器)
1.png

封裝過程

2.png

TCP/IP參考網(wǎng)絡(luò)模型

  • TCP/IP是傳輸控制協(xié)議/網(wǎng)絡(luò)互聯(lián)協(xié)議的簡稱
  • 早期的TCP/IP模型是一個四層結(jié)構(gòu)麦到，從下往上依次是網(wǎng)絡(luò)接口層绿饵，互聯(lián)網(wǎng)層；傳輸層和應(yīng)用層
  • 后來在使用過程中瓶颠，借鑒OSI七層參考模型拟赊，將網(wǎng)絡(luò)接口層劃分為物理層和數(shù)據(jù)鏈路層，形成五層結(jié)構(gòu)
3.png

協(xié)議的概念和作用

  • 為了讓計(jì)算機(jī)能夠通信粹淋，計(jì)算機(jī)需要定義通信規(guī)則吸祟，這些規(guī)則就是協(xié)議
  • 規(guī)則是多種，協(xié)議也有多種
  • 協(xié)議就是數(shù)據(jù)封裝格式+傳輸

常用協(xié)議

  • TCP/IP協(xié)議被稱為傳輸控制協(xié)議/互聯(lián)網(wǎng)協(xié)議桃移，又稱為網(wǎng)絡(luò)通訊協(xié)議
  • 是由網(wǎng)絡(luò)層的IP協(xié)議和傳輸層的TCP協(xié)議組成屋匕，是一個很大的協(xié)議集合
  • 物理層和數(shù)據(jù)鏈路層沒有定義任何特定協(xié)議，支持所有的標(biāo)準(zhǔn)和專用的協(xié)議
4.png

網(wǎng)絡(luò)接口層

  • 網(wǎng)絡(luò)接口層是TCP/IP模型的最底層借杰，負(fù)責(zé)接收從上一層交來的數(shù)據(jù)報(bào)并將數(shù)據(jù)報(bào)通過底層的物理網(wǎng)絡(luò)發(fā)送出去过吻，比較常見的就是設(shè)備的驅(qū)動程序，此層沒有特定的協(xié)議

  • 網(wǎng)絡(luò)接口層又分為物理層和數(shù)據(jù)鏈路層

  • 物理層

    • 計(jì)算機(jī)在傳輸數(shù)據(jù)的時候傳遞的都是0和1的數(shù)字第步，而物理層關(guān)心的是用什么信號來表示0和1疮装，是否可以雙向通信，最初的連接如何建立以及完成連接如何終止粘都，物理層是為數(shù)據(jù)傳輸提供可靠的環(huán)境
    • 盡可能的屏蔽掉物理設(shè)備和傳輸媒介，使數(shù)據(jù)鏈路層不考慮這些差異刷袍，只考慮本層的協(xié)議和服務(wù)
    • 為用戶提供在一條物理傳輸媒體上提供傳送和接收比特流的能力

    • 需要解決物理連接翩隧，維護(hù)和釋放的問題


      5.png

  • 數(shù)字信號的編碼

    • 數(shù)字新的編碼：用何種物理信號來表示0和1

  • 非歸零編碼


    6.png

  • 優(yōu)點(diǎn)：編/譯碼簡單

  • 缺點(diǎn)：內(nèi)部不含時鐘信號，收發(fā)端同步困難

  • 用途：計(jì)算機(jī)內(nèi)部呻纹，或低速數(shù)據(jù)通信

因?yàn)闀r鐘信號無法確定堆生，即時鐘頻率無法確定，例如一直發(fā)的都是1/0雷酪，是一條直線淑仆，怎么分割信號呢？無解

  • 曼徹斯特編碼
7.png
  • 優(yōu)點(diǎn)
    • 內(nèi)部自含時鐘哥力，收發(fā)端同步容易
    • 抗干擾能力強(qiáng)
  • 缺點(diǎn)
    • 編譯碼較復(fù)雜
    • 占用更多的信道帶寬蔗怠，在同樣的比特率的情況下，要比非歸零編碼多占用一倍信道帶寬
    • 用途：802.3局域網(wǎng)(以太網(wǎng))

數(shù)據(jù)鏈路層

  • 數(shù)據(jù)鏈路層是OSI參考模型的第二層吩跋，介乎于物理層和網(wǎng)絡(luò)層之間
  • 數(shù)據(jù)鏈路層在物理層提供的服務(wù)的基礎(chǔ)上向網(wǎng)絡(luò)層提供服務(wù)寞射，其最基本的服務(wù)是將源自網(wǎng)絡(luò)層來的數(shù)據(jù)可靠的傳輸?shù)较噜徆?jié)點(diǎn)的目標(biāo)機(jī)網(wǎng)絡(luò)層
  • 如何將數(shù)據(jù)組合成數(shù)據(jù)塊，在數(shù)據(jù)鏈路層中稱這種數(shù)據(jù)塊為幀锌钮，幀是數(shù)據(jù)鏈路層的傳輸單位
  • 如何控制幀在物理信道上的傳輸桥温，包括如何處理傳輸差錯，如何調(diào)節(jié)發(fā)送速率以使與接收方相匹配
  • 以及在兩個網(wǎng)絡(luò)實(shí)體之間提供數(shù)據(jù)鏈路通路的建立梁丘，維持和釋放的管理
以太網(wǎng)
  • 以太網(wǎng)是一種計(jì)算機(jī)局域網(wǎng)技術(shù)侵浸。IEEE組織的IEEE 802.3標(biāo)準(zhǔn)制定了以太網(wǎng)的技術(shù)標(biāo)準(zhǔn)旺韭，它規(guī)定了包含物理層的連線，電子信號和介質(zhì)訪問層協(xié)議的內(nèi)容
  • 以太網(wǎng)的標(biāo)準(zhǔn)拓?fù)浣Y(jié)構(gòu)為總線型拓?fù)?/li>
  • 以太網(wǎng)仍然使用總現(xiàn)拓?fù)浜虲SMA/CD的總線技術(shù)
  • 以太網(wǎng)實(shí)現(xiàn)了網(wǎng)絡(luò)上無線電系統(tǒng)多個節(jié)點(diǎn)發(fā)送信息的想法掏觉，每個節(jié)點(diǎn)必須獲取電纜或者信道才能傳輸信息
  • 每個節(jié)點(diǎn)都有全球唯一的48位地址也就是制造商分配給網(wǎng)卡的MAC地址区端，以保證以太網(wǎng)上所有節(jié)點(diǎn)能互相鑒別
總線拓?fù)?/h5>
  • 總線型拓?fù)涫遣捎脝胃鶄鬏斪饔霉灿玫膫鬏斀橘|(zhì)，將網(wǎng)絡(luò)中的所有計(jì)算機(jī)通過相應(yīng)的硬件接口和電纜直接連接到這根共享的總線上
  • 使用總線型拓?fù)浣Y(jié)構(gòu)需解決的是確保端用戶使用媒體發(fā)送數(shù)據(jù)時不同出現(xiàn)沖突
  • 總線型網(wǎng)絡(luò)采用載波監(jiān)聽多路訪問/沖突檢測協(xié)議(CSMA/CD)作為控制策略
    8.png

載波監(jiān)聽多路訪問

  • 是一種允許多個設(shè)備在同一信道發(fā)送信號的協(xié)議履腋，其中的設(shè)備監(jiān)聽其他設(shè)備是否忙碌珊燎，只有在線路空閑時候才發(fā)送
  • 在這種訪問方式下，網(wǎng)絡(luò)中的所有用戶共享傳輸介質(zhì)遵湖，信息通過廣播傳送到所有端口悔政，網(wǎng)絡(luò)中的工作站對接收到的信息進(jìn)行確認(rèn)，若是發(fā)給自己的就接收否則不理
  • 從發(fā)送端情況看延旧，當(dāng)一個工作站有數(shù)據(jù)要發(fā)送時候谋国，它首先監(jiān)聽信道并檢測網(wǎng)絡(luò)上是否有其他的工作站正在發(fā)送DATA，如果檢測到信道忙迁沫，工作站將繼續(xù)WAIT若發(fā)現(xiàn)信道空閑芦瘾，則開始發(fā)送數(shù)據(jù)，信息發(fā)送出去后集畅，發(fā)送端還要繼續(xù)對發(fā)送的消息進(jìn)行確認(rèn)近弟，以了解接收端是否已經(jīng)正確的接收到數(shù)據(jù)，如果收到則發(fā)送結(jié)束挺智，否則再此發(fā)送
  • 核心思想
    • 先聽后講祷愉，信道空閑則發(fā)送，信道忙則等待
    • 邊聽邊講 發(fā)送信息時不斷檢測信道是否碰撞
    • 碰撞即停
    • 退避重傳 二進(jìn)制指數(shù)退避重傳
    • 多次碰撞 放棄發(fā)送赦颇，最多16次

沖突檢測

  • 沖突檢測即發(fā)送站點(diǎn)在發(fā)送數(shù)據(jù)時要邊發(fā)送邊監(jiān)聽信道二鳄，若監(jiān)聽到信道有干擾信號，則表示產(chǎn)生了沖突媒怯，于是就要立刻停止發(fā)送消息订讼，計(jì)算出退避等待時間，然后使用CSMA方法繼續(xù)嘗試發(fā)送
  • 計(jì)算退避等待時間采用的時二進(jìn)制指數(shù)退避算法

演化

上面總線形式數(shù)據(jù)傳輸有很多弊端扇苞，后期演化成交換機(jī)交換數(shù)據(jù)欺殿，交換機(jī)是二層設(shè)備在物理鏈路層上面工作，工作方式是通過MAC地址定向傳輸數(shù)據(jù)杨拐，避免了總線形式的時候所有機(jī)器都可以接收到數(shù)據(jù)的問題祈餐。

MAC地址

  • 在通信過程中是用內(nèi)置的網(wǎng)卡內(nèi)的地址來標(biāo)識計(jì)算機(jī)身份的
  • 每個網(wǎng)卡都有一個全球唯一的地址來標(biāo)識自己，不會重復(fù)

  • MAC地址48位的二進(jìn)制組成哄陶，通常分為6段帆阳，用16進(jìn)制表示


    9.png

以太網(wǎng)幀格式

  • 在以太網(wǎng)鏈路上的數(shù)據(jù)包稱為以太幀，以太幀起始部分由前導(dǎo)碼和幀開始符z盛
  • 后面緊跟著一個以太網(wǎng)報(bào)頭，以MAC地址說明目的地址和源地址
  • 幀的中部是該幀負(fù)載的包含其他協(xié)議報(bào)頭的數(shù)據(jù)包(例如IP協(xié)議)
  • 以太幀由一個32位冗余校驗(yàn)碼結(jié)尾蜒谤。它用于檢驗(yàn)數(shù)據(jù)傳輸是否出現(xiàn)損壞
10.png
11.png

路由器IP尋址網(wǎng)絡(luò)層山宾，交換機(jī)mac尋址數(shù)據(jù)鏈路層

ARP協(xié)議

  • 地址解析協(xié)議，即ARP鳍徽，是根據(jù)IP地址獲取物理地址(MAC)的一個TCP/IP協(xié)議
  • 主機(jī)發(fā)送信息時將包含目標(biāo)IP地址的ARP請求廣播到網(wǎng)絡(luò)上的所有主機(jī)资锰，并接收返回消息，以此確定目標(biāo)的物理地址阶祭；收到返回消息后將該IP地址和物理地址存入本機(jī)ARP緩存中并保留一定時間绷杜，下次請求時直接查詢ARP緩存以節(jié)約資源
  • 地址解析協(xié)議是建立在網(wǎng)絡(luò)中各個主機(jī)互相信任的基礎(chǔ)上的，網(wǎng)絡(luò)上的主機(jī)可以自主發(fā)送ARP應(yīng)答消息濒募，其他主機(jī)收到應(yīng)答報(bào)文時不會檢測該報(bào)文的真實(shí)性就會將其記入本機(jī)ARP緩存
  • 由此攻擊者就可以向某一主機(jī)發(fā)送偽ARP應(yīng)答報(bào)文鞭盟，使其發(fā)送的信息無法達(dá)到預(yù)期的主機(jī)或到達(dá)錯誤的主機(jī)，構(gòu)成ARP欺騙

ARP協(xié)議報(bào)文

1.png
2.png

ARP地址解析過程

3.png

主機(jī)A和B在同一個網(wǎng)段瑰剃，主機(jī)A要向主機(jī)B發(fā)送信息

  • 主機(jī)A首先查看自己的ARP表齿诉，確定其中是否包含有主機(jī)B對應(yīng)的ARP表項(xiàng)。如果找到了對應(yīng)的MAC地址晌姚，則主機(jī)A直接利用ARP表中的MAC地址粤剧，對IP數(shù)據(jù)包進(jìn)行幀封裝，并將數(shù)據(jù)包發(fā)送給主機(jī)B挥唠。
  • 如果主機(jī)A在ARP表中找不到對應(yīng)的MAC地址抵恋，則將該緩存該數(shù)據(jù)報(bào)文，然后以廣播方式發(fā)送一個ARP請求報(bào)文宝磨。ARP請求報(bào)文中的發(fā)送端IP地址和發(fā)送端MAC地址為主機(jī)A的IP地址和MAC地址馋记，目標(biāo)IP地址和目標(biāo)MAC地址為主機(jī)B的IP地址和全0的MAC地址。由于ARP請求報(bào)文以廣播方式發(fā)送懊烤，該網(wǎng)段上的所有主機(jī)都可以接收到該請求，但只有被請求的主機(jī)(即主機(jī)B)會對該請求進(jìn)行處理宽堆。
  • 主機(jī)B比較自己的IP地址和ARP請求報(bào)文中的目標(biāo)IP地址腌紧，當(dāng)兩者相同時進(jìn)行如下處理：將ARP請求報(bào)文中的發(fā)送端(即主機(jī)A)的IP地址和MAC地址存入自己的ARP表中。之后以單播的方式發(fā)送ARP響應(yīng)報(bào)文給主機(jī)A畜隶，其中包含自己的MAC地址壁肋。
  • 主機(jī)A收到ARP響應(yīng)報(bào)文后，將主機(jī)B的MAC地址加入到自己的ARP表中以用于后續(xù)報(bào)文的轉(zhuǎn)發(fā)籽慢，同時將IP數(shù)據(jù)包進(jìn)行封裝后發(fā)送出去

互聯(lián)網(wǎng)層(網(wǎng)絡(luò)層)

位于傳輸層和網(wǎng)絡(luò)接口層之間浸遗，用于把數(shù)據(jù)從源主機(jī)經(jīng)過若干個中間節(jié)點(diǎn)傳送到目標(biāo)主機(jī)，并向傳輸層提供最基礎(chǔ)的數(shù)據(jù)傳輸服務(wù)箱亿，主要提供路由和選址的工作


4.png

選址
交換機(jī)是靠MAC來尋址的跛锌，而因?yàn)镸AC地址是無層次的，所以要靠IP地址來確認(rèn)計(jì)算機(jī)的位置届惋，這就是選址

5.png

路由
在能夠選擇的多條道路之間選擇一條最短的路勁就是路由的工作

6.png

在大網(wǎng)絡(luò)情況下髓帽，起始是多個路由器跳轉(zhuǎn)菠赚，路由器之間有路由算法，即其實(shí)也不知道真實(shí)IP主機(jī)在哪里郑藏，但是可以知道轉(zhuǎn)發(fā)給哪個路由可以到達(dá)目標(biāo)IP

IP
在網(wǎng)絡(luò)中衡查，每臺計(jì)算機(jī)都有一個唯一的地址，方便別人找到它必盖，這個地址稱為IP地址

  • IP頭部


    7.png
8.png
9.png

  • IP地址格式

    • IP地址是一個網(wǎng)絡(luò)編碼渊啰，用來確定網(wǎng)絡(luò)中的一個節(jié)點(diǎn)

    • IP地址是由32位二進(jìn)制(32bit)組成


      10.png

  • IP地址組成

    • 網(wǎng)絡(luò)部分(NETWORK)
    • 主機(jī)部分(HOST)
  • IP地址的分類
    • IP地址的網(wǎng)絡(luò)部分是由Internet地址分配機(jī)構(gòu)來統(tǒng)一分配的塌计，這樣可以保證IP的唯一性
    • IP地址中全為1的IP即255.255.255.255，它稱為限制廣播地址，如果將其作為數(shù)據(jù)包的目標(biāo)地址可以理解為發(fā)送到所有網(wǎng)絡(luò)的所有主機(jī)
    • IP地址中全為0的IP即0.0.0.0腐泻，它表示啟動時的IP地址，其含義就是尚未分配時的IP地址
    • 127是用來進(jìn)行本機(jī)測試的崔赌，除了127.255.255.255外绷柒，其他的127開頭的地址都代表本機(jī)
    • 如果只有最后一位是255則表明是某網(wǎng)段的廣播地址(不能作用主機(jī)地址)，此處區(qū)別于255.255.255.255
    • 如果只有最后一位是0也代表未分配地址突勇，該IP不能作為主機(jī)地址
11.png
  • 公有地址和私有地址
分類 范圍
A類私有IP 10.0.0.0 ~10.255.255.255
B類私有IP 172.16.0.0~172.31.255.255
C類私有IP 192.168.0.0~192.168.255.255

其他范圍的IP均為公有IP地址

  • 子網(wǎng)掩碼
    • 子網(wǎng)掩碼又叫子網(wǎng)絡(luò)遮罩装盯，它是一種用來指明一個IP地址的那些位標(biāo)識的是主機(jī)所在的子網(wǎng)，以及哪些位標(biāo)識的是主機(jī)位的掩碼
    • 子網(wǎng)掩碼不能單獨(dú)存在甲馋，它必須結(jié)合IP地址一起使用
    • 子網(wǎng)掩碼只有一個作用埂奈，就是將某個IP地址劃分成網(wǎng)絡(luò)地址和主機(jī)地址部分
    • 子網(wǎng)掩碼也是32個二進(jìn)制
    • 對應(yīng)IP的網(wǎng)絡(luò)部分用1表示
    • 對應(yīng)IP的主機(jī)部分用0表示
    • IP地址和子網(wǎng)掩碼做邏輯與運(yùn)算的到網(wǎng)絡(luò)地址
      • 0和任何數(shù)相與都是0
      • 1和任何樹相與都等于任何數(shù)本身
    • A B C三類地址都有自己默認(rèn)的子網(wǎng)掩碼
      • A類255.0.0.0
      • B類255.255.0.0
      • C類255.255.255.0
12.png
13.png

說白了，網(wǎng)絡(luò)地址相同才是同一個網(wǎng)段才能通信定躏，否則即使IP地址很像也不行

傳輸層

  • 位于應(yīng)用層和網(wǎng)絡(luò)接口層之間
  • 是面向連接的账磺，可靠的進(jìn)程到進(jìn)程通信的協(xié)議
  • TCP提供全雙工通信，即數(shù)據(jù)可在同一時間雙向傳播
  • TCP將若干個字節(jié)構(gòu)成一個分組痊远，此分組稱為報(bào)文段
  • 對可靠性要求高的上層協(xié)議垮抗，實(shí)現(xiàn)可靠性的保證，如果數(shù)據(jù)丟失碧聪、損壞的情況下如何保證可靠性冒版，網(wǎng)絡(luò)層只管傳遞數(shù)據(jù)，成功與否并不關(guān)心
  • TCP是在不可靠協(xié)議(互聯(lián)網(wǎng)層)基礎(chǔ)上維護(hù)可靠傳輸
  • 提供一種端到端的連接
    單工
    單向傳輸逞姿，廣播辞嗡，電視
    半雙工
    在同一個時間點(diǎn)內(nèi)，只能單向通信
    全雙工
    在任意時間點(diǎn)雙方都可以收發(fā)數(shù)據(jù) 例如：電話
1.png

協(xié)議分類

  • TCP
    • 傳輸控制協(xié)議
    • 可靠的‘面向連接的協(xié)議
    • 傳輸效率低
  • UDP
    • 用戶數(shù)據(jù)報(bào)協(xié)議
    • 不可靠的滞造，無連接的服務(wù)
    • 傳輸效率高

TCP

  • 將數(shù)據(jù)進(jìn)行分段打包傳輸
  • 對每個數(shù)據(jù)包編號進(jìn)行控制順序
  • 運(yùn)輸中丟失续室、重發(fā)和丟棄處理
  • 流量控制避免擁塞

TCP數(shù)據(jù)包封裝

  • 源端口號和目標(biāo)端口號，計(jì)算機(jī)通過端口號識別訪問哪個服務(wù)谒养，比如HTTP服務(wù)或FTP服務(wù)挺狰，發(fā)送方端口號是進(jìn)行隨機(jī)端口，目標(biāo)端口號決定了接收方是哪個程序


    2.png

32位序列號
TCP用序列號對數(shù)據(jù)包進(jìn)行標(biāo)記，以便達(dá)到目的地后重新重裝她渴，假設(shè)當(dāng)前的序列號為s,發(fā)送數(shù)據(jù)長度為l达址，則下次發(fā)送數(shù)據(jù)時的序列號為S+l。在建立連接時通常由計(jì)算機(jī)生成一個隨機(jī)數(shù)作為序列號的初始值

3.png

確認(rèn)應(yīng)答號
它等于下一次應(yīng)該接收到的數(shù)據(jù)的序列號趁耗，假設(shè)發(fā)送端的序列號為s沉唠，發(fā)送數(shù)據(jù)的長度為l,那么接收端返回的確認(rèn)應(yīng)答號也是s+l.發(fā)送端接收到這個確認(rèn)應(yīng)答后，可以認(rèn)為這個位置以前所有的數(shù)據(jù)都已被正常接收苛败，也就代表著满葛，隨機(jī)數(shù)據(jù)包前后順序不一定，但是后面包的確認(rèn)信息肯定是全面包都收到后才發(fā)送給發(fā)送端的

4.png

首部長度
TCP首部的長度罢屈，單位為4字節(jié)嘀韧。如果沒有可選字段，那么這里的值就是5缠捌。表示TCP首部的長度為20字節(jié)锄贷。

控制位

  • 控制位TCP的連接、傳輸和斷開都受這六個控制位的指揮
    • PSH緩存區(qū)將滿曼月，立刻傳輸數(shù)據(jù)
    • REST 連接斷了重新連接
    • URG 緊急信號
  • 緊急指針

盡在URG控制位為1時有效谊却。表示緊急數(shù)據(jù)的末尾在TCP數(shù)據(jù)部分中的位置。通常在暫時中斷通信時候使用(例如Crtl+C)


5.png
  • SYN

同步序號位TCP建立連接時候要將這個值設(shè)置為1


6.png
  • ACK

為1表示確認(rèn)號


7.png
  • FIN

發(fā)送端完成位哑芹，提出斷開連接的乙方把FIN置為1表示要斷開連接


8.png

窗口值

  • 窗口值：說明本地可接收數(shù)據(jù)段的數(shù)目炎辨，這個值的大小是可變的。當(dāng)網(wǎng)絡(luò)通常時將這個窗口值變大加快傳輸速度聪姿，當(dāng)網(wǎng)絡(luò)不穩(wěn)定時候減少這個值可以保證網(wǎng)絡(luò)數(shù)據(jù)的可靠傳輸碴萧。它是在TCP傳輸中進(jìn)行流量控制的
  • 窗口大小：用于表示從應(yīng)答號開始能夠接受多少個8位字節(jié)末购。如果窗口大小為0破喻，可以發(fā)送窗口探測

  • 窗口探測：例如接收方窗口已經(jīng)堆滿了數(shù)據(jù)，沒來的及處理盟榴，則接收方通過ACK返回窗口大小為0低缩，則發(fā)送方知道0了則不發(fā)送了，但是可能后期接收方處理了曹货，窗口有了，需要發(fā)送方每隔一段時間去接收方問窗口空了沒讳推，這就是窗口探測


    9.png

差錯控制

  • 校驗(yàn)和用來做差錯控制顶籽，TCP校驗(yàn)和的計(jì)算包括TCP首部，數(shù)據(jù)和其他填充字節(jié)银觅，在發(fā)送TCP數(shù)據(jù)段時候礼饱，由發(fā)送端計(jì)算校驗(yàn)和，當(dāng)?shù)竭_(dá)目的地時候又進(jìn)行一次校驗(yàn)和計(jì)算。如果兩次校驗(yàn)和一致說明數(shù)據(jù)是正確的镊绪，否則將認(rèn)為數(shù)據(jù)被破壞匀伏，接收端將丟棄數(shù)據(jù)
    10.png

    握手和斷開
  • TCP是面向連接的協(xié)議，它在源點(diǎn)和終點(diǎn)之間建立虛擬連接蝴韭，而不是物理連接
  • 在數(shù)據(jù)通信之前够颠，發(fā)送端與接收端要先建立連接，等數(shù)據(jù)發(fā)送結(jié)束后榄鉴，雙方在斷開連接

  • TCP連接的每一方都是由一個IP地址和一個端口組成


    11.png
12.png

之所以四次揮手中間兩次不能合并是因?yàn)槁哪ィ?wù)端響應(yīng)必須立刻給客戶端，否則客戶端會重新傳消息庆尘。之后確定不確定斷開在專門發(fā)FIN消息

滑動窗口

  • 滑動窗口是一種流量控制技術(shù)
  • 早期的網(wǎng)絡(luò)通信中剃诅，通信雙方不會考慮網(wǎng)絡(luò)的擁擠情況直接發(fā)送數(shù)據(jù)。由于大家不知道網(wǎng)絡(luò)擁塞狀況驶忌，同時發(fā)送數(shù)據(jù)矛辕，導(dǎo)致中間節(jié)點(diǎn)阻塞掉包，誰也發(fā)不了數(shù)據(jù)付魔，所以就有了滑動窗口機(jī)制來解決這個問題
  • TCP中采用滑動窗口來進(jìn)行傳輸控制聊品，滑動窗口的大小意味著接收方還有多大的緩沖區(qū)可以用于接收數(shù)據(jù)，發(fā)送方可以通過滑動窗口的大小來確定應(yīng)該發(fā)送多少字節(jié)的數(shù)據(jù)
  • 當(dāng)滑動窗口為0時抒抬，發(fā)送方一般不能再發(fā)送數(shù)據(jù)報(bào)杨刨，但有兩種情況除外，一種情況是可以發(fā)送緊急數(shù)據(jù)擦剑，例如：允許用戶終止再遠(yuǎn)端機(jī)上的運(yùn)行進(jìn)程妖胀。另一種情況是發(fā)送方可以發(fā)送一個1字節(jié)的數(shù)據(jù)報(bào)來通知接收方重新聲明它希望接收的下一字節(jié)及發(fā)送方的滑動窗口大小。

窗口機(jī)制

  • 滑動窗口協(xié)議的基本原理就是在任意時刻惠勒，發(fā)送方都維持了一個連續(xù)的允許發(fā)送的幀的序號赚抡，稱為發(fā)送窗口；同時纠屋，接收方也維持一個連續(xù)的允許接收的幀的序號涂臣，稱為接收窗口
  • 發(fā)送窗口和接收窗口的序號的上下界不一定要一樣，甚至大小也可以不同
  • 不同的滑動窗口協(xié)議窗口大小一般不同
  • 發(fā)送窗口內(nèi)的序列號代表了那些已經(jīng)被發(fā)送售担，但是還沒有被確認(rèn)的幀赁遗，或者是哪些可以被發(fā)送的幀
1.png

擁塞控制

  • TCP擁塞控制是傳輸控制協(xié)議，避免網(wǎng)絡(luò)擁塞的算法族铆，是互聯(lián)網(wǎng)上主要的一個擁塞控制措施
  • TCP使用多種擁塞控制策略來避免雪崩式擁塞岩四，TCP會為每條連接維護(hù)一個"擁塞窗口"來限制端對端間傳輸?shù)奈创_認(rèn)分組總數(shù)量
  • 這類似TCP流量控制機(jī)制中使用的滑動窗口，是由發(fā)送方控制的
  • TCP在一個連接初始化或超時后使用一種"慢啟動"機(jī)制來增加擁塞窗口的大小哥攘。它的起始值一般為最大分段大小的兩倍剖煌，雖然命名為慢啟動材鹦，初始值也向當(dāng)?shù)兀湓鲩L極快耕姊；當(dāng)每個分段的到確認(rèn)時桶唐，擁塞窗口會增加一個MSS，使的再每次往返內(nèi)擁塞窗口能高效的雙倍增長
  • 再流量控制中茉兰，接收方通過TCP的"窗口"值來告知發(fā)送方尤泽，由發(fā)送方通過對擁塞窗口和接收窗口的大小比較，來確定任何時刻內(nèi)需要傳輸?shù)臄?shù)據(jù)量
  • 和式增加邦邦，積式減少是一種反饋控制算法安吁，其包含了對擁塞窗口線性增加，和當(dāng)發(fā)生擁塞時對窗口積式減少燃辖。多個使用AIMD控制的TCP流量最終會收斂到對線路的等量競爭使用
  • 未確認(rèn)的數(shù)據(jù)包剛好等于帶寬等于延遲

  • 當(dāng)發(fā)現(xiàn)丟包的時候立刻減半


    2.png

UDP

  • UDP是一個面向無連接鬼店，不保證可靠性的傳輸層協(xié)議，也就是說發(fā)送端不關(guān)心發(fā)送的數(shù)據(jù)是否達(dá)到目標(biāo)主機(jī)黔龟，數(shù)據(jù)是否出錯等妇智，收到的數(shù)據(jù)的主機(jī)也不會告訴發(fā)送方是否收到了數(shù)據(jù)，它的可靠性由上層協(xié)議來保障
  • 首部結(jié)構(gòu)簡單氏身，再數(shù)據(jù)傳輸時能實(shí)現(xiàn)最小的開銷巍棱，如果進(jìn)程想發(fā)送很短的報(bào)文而對可靠性要求不高可以使用
3.png
4.png
5.png

DNS

6.png

DNS服務(wù)器進(jìn)行域名與之對應(yīng)的IP地址轉(zhuǎn)換的服務(wù)器

  • IP地址不易記憶
  • 早期使用Hosts文件解析域名
    • 主要名稱重復(fù)
    • 主機(jī)維護(hù)困難
  • DNS(域名系統(tǒng))
    • 分布式

    • 層次性


      7.png
8.png

其中本地DNS服務(wù)器可能是路由器等

DHCP(應(yīng)用層)

  • 保證任何IP地址在同一時刻只能由一臺DHCP客戶機(jī)所使用(DHCP服務(wù)器再小網(wǎng)絡(luò)環(huán)境一般集成再路由器中)
  • DHCP應(yīng)當(dāng)可以給用戶分配永久固定的IP地址
  • DHCP應(yīng)當(dāng)可以同用其他方法獲的IP地址的主機(jī)共存(如手工設(shè)置IP地址的主機(jī))
  • DHCP服務(wù)器應(yīng)當(dāng)向現(xiàn)有的BOOTP客戶端提供服務(wù)

工作流程

  • 主機(jī)發(fā)送DHCPDISCOVER廣播包再網(wǎng)絡(luò)上尋找DHCP服務(wù)器
  • DHCP服務(wù)器向主機(jī)發(fā)送DHCPOFFER單播數(shù)據(jù)包，包含IP地址蛋欣、MAC地址航徙、域名信息以及地址租期
  • 主機(jī)發(fā)送DHCPREQUEST廣播包，正式向服務(wù)器請求分配已提供的IP地址
  • DHCP服務(wù)器向主機(jī)發(fā)送DHCPPACK單播包陷虎，確認(rèn)主機(jī)的請求
9.png

應(yīng)用層

10.png

應(yīng)用層常見協(xié)議

  • HTTP超文本傳輸協(xié)議
  • FTP文件傳輸協(xié)議
  • SMTP(發(fā)送郵件)和POP3(接收郵件)

案例

數(shù)據(jù)->傳輸層(包)->網(wǎng)絡(luò)層(段Segment)->數(shù)據(jù)鏈路層(幀)

  • 在應(yīng)用層要把各式各樣的數(shù)據(jù)如字母到踏、數(shù)字、漢字尚猿、圖片等轉(zhuǎn)換成二進(jìn)制
  • 再TCP傳輸層中窝稿，上層的數(shù)據(jù)被分割成小的數(shù)據(jù)段，并為每個分段后的數(shù)據(jù)封裝TCP報(bào)文頭部
  • 再TCP頭部有一個關(guān)鍵的字段信息端口號凿掂，它用于標(biāo)識上層的協(xié)議或應(yīng)用程序伴榔，確保上層數(shù)據(jù)的正常通信
  • 計(jì)算機(jī)可以多進(jìn)程并發(fā)運(yùn)行，例如在發(fā)郵件的同時也可以通過瀏覽器瀏覽網(wǎng)頁庄萎，這兩種應(yīng)用通過端口號進(jìn)行區(qū)分
  • 在網(wǎng)絡(luò)層踪少，上層數(shù)據(jù)被封裝上層的報(bào)文頭部(IP頭部)，上層的數(shù)據(jù)是包括TCO頭部的糠涛。IP地址包括的最關(guān)鍵字段信息就是IP地址秉馏，用于標(biāo)識網(wǎng)絡(luò)的邏輯地址
  • 數(shù)據(jù)鏈路層，上層數(shù)據(jù)包裝成一個MAC頭部脱羡，內(nèi)部有最關(guān)鍵的是MAC地址萝究。MAC地址就是固化在硬件設(shè)備內(nèi)部的全球唯一的物理地址

  • 在物理層，無論在之前哪一層封裝的報(bào)文頭和還是上層數(shù)據(jù)都是由二進(jìn)制組成锉罐，物理層將這些二進(jìn)制數(shù)據(jù)比特流轉(zhuǎn)換成電信號在網(wǎng)絡(luò)中傳輸


    11.png

接收數(shù)據(jù)的過程是逆向的解包操作

真實(shí)網(wǎng)絡(luò)環(huán)境

  • 發(fā)送方和接收方可能會有多個硬件中轉(zhuǎn)設(shè)備
  • 中間可能會增加交換機(jī)和路由器
  • 數(shù)據(jù)在傳輸過程中不斷的進(jìn)行封裝和解封裝的過程帆竹，每層設(shè)備只能處理那一層的數(shù)據(jù)
    • 交換機(jī)數(shù)據(jù)數(shù)據(jù)鏈路層

    • 路由器屬于網(wǎng)絡(luò)層


      12.png

HTTP緩存

該部分完全復(fù)制公眾號，連接

瀏覽器緩存幾個階段

  • 強(qiáng)緩存策略

瀏覽器端發(fā)起請求之后不會直接向服務(wù)器請求數(shù)據(jù)脓规，直接先到達(dá)強(qiáng)緩存階段栽连，如果強(qiáng)緩存命中直接返回，如果沒有命中進(jìn)入下一階段協(xié)商緩存策略侨舆。

  • 協(xié)商緩存策略

協(xié)商緩存是當(dāng)強(qiáng)緩存沒有命中的情況或者按下 F5 鍵刷新頁面會觸發(fā)秒紧，它每次都會攜帶標(biāo)識與服務(wù)器進(jìn)行校驗(yàn)，符合則返回 304 標(biāo)識挨下，表示資源沒有更新熔恢，如果協(xié)商緩存也失效了，進(jìn)入下一個階段獲取最新數(shù)據(jù)臭笆，并返回且狀態(tài)碼為 200叙淌。

  • 存儲策略

當(dāng)強(qiáng)緩存->協(xié)商緩存都未命中，請求會直接到達(dá)服務(wù)器愁铺，獲取最新資源設(shè)置緩存策略鹰霍，進(jìn)行返回。

強(qiáng)緩存

強(qiáng)緩存的實(shí)現(xiàn)分為 Expires茵乱、Cache-Control 兩個茂洒。

  • Expires
    Expires 屬于 HTTP 1.0 時期的產(chǎn)物，在響應(yīng)中進(jìn)行設(shè)置瓶竭，示例如下：
response.writeHead(200, {
    'Content-Type': 'text/javascript',
    'Expires': new Date('2020-03-25 11:19:00'),
});

設(shè)置成功運(yùn)行 node expires.js 在 Response Headers 里可以看到如下信息：

Expires: Wed Mar 25 2020 11:19:00 GMT+0800 (GMT+08:00)

刷新兩次頁面督勺，可以看到第二次 size 一欄返回了 memory cache 此時 Expires 緩存命中。

1.png

Expires 是參考的本地時間在验，如果修改本地時間玷氏，可能就會造成緩存失效。

  • Cache-Control
    Cache-Control 屬于 HTTP 1.1 時代的產(chǎn)物腋舌，可以再請求頭或者響應(yīng)頭中設(shè)置盏触，它的取值包含如下選項(xiàng)：
  1. 可緩存性
  • public：http 經(jīng)過的任何地方都可以進(jìn)行緩存（代理服務(wù)器也可緩存）
  • private：只有發(fā)起請求的這個瀏覽器才可以進(jìn)行緩存，如果設(shè)置了代理緩存块饺，那么代理緩存是不會生效的
  • no-cache：任何一個節(jié)點(diǎn)都不可以緩存（繞過強(qiáng)緩存赞辩，但是還會經(jīng)過協(xié)商緩存）
  1. 到期
  • max-age=：設(shè)置緩存到多少秒過期
  • s-maxage=：會代替 max-age，只有在代理服務(wù)器（nginx 代理服務(wù)器）才會生效
  • max-stale=：是發(fā)起請求方主動帶起的一個頭授艰，是代表即便緩存過期辨嗽，但是在 max-stale 這個時間內(nèi)還可以使用過期的緩存，而不需要向服務(wù)器請求新的內(nèi)容
  1. 重新驗(yàn)證
  • must-revalidate：如果 max-age 設(shè)置的內(nèi)容過期淮腾，必須要向服務(wù)器請求重新獲取數(shù)據(jù)驗(yàn)證內(nèi)容是否過期
  • proxy-revalidate：主要用在緩存服務(wù)器糟需，指定緩存服務(wù)器在過期后重新從原服務(wù)器獲取屉佳，不能從本地獲取
  1. 其它
  • no-store：本地和代理服務(wù)器都不可以存儲這個緩存，永遠(yuǎn)都要從服務(wù)器拿 body 新的內(nèi)容使用（強(qiáng)緩存洲押、協(xié)商緩存都不會經(jīng)過）
  • no-transform：主要用于 proxy 服務(wù)器武花，告訴代理服務(wù)器不要隨意改動返回的內(nèi)容

Cache-Control 示例

先思考兩個問題?

1. 在頁面中引入靜態(tài)資源文件，為什么靜態(tài)資源文件改變后杈帐，再次發(fā)起請求還是之前的內(nèi)容体箕，沒有變化呢？

2. 在使用webpack等一些打包工具時挑童，為什么要加上一串hash碼累铅？
  • cache-control.html
<html>
    <head>
        <meta charset="utf-8" />
        <title>cache-control</title>
    </head>
    <body>
        <script src="/script.js"></script>
    </body>
</html>
  • cache-control.js

瀏覽器輸入 http://localhost:3010/ 加載 cache-control.html 文件，該文件會請求 http://localhost:3010/script.js 如果 url 等于 /script.js 設(shè)置 cache-control 的 max-age 進(jìn)行瀏覽器緩存站叼。

const http = require('http');
const fs = require('fs');
const port = 3010;

http.createServer((request, response) => {
    console.log('request url: ', request.url);

    if (request.url === '/') {
        const html = fs.readFileSync('./example/cache/cache-control.html', 'utf-8');
    
        response.writeHead(200, {
            'Content-Type': 'text/html',
        });

        response.end(html);
    } else if (request.url === '/script.js') {
        response.writeHead(200, {
            'Content-Type': 'text/javascript',
            'Cache-Control': 'max-age=200'
        });

        response.end("console.log('script load')");
    }

}).listen(port);

console.log('server listening on port ', port);
  • 第一次運(yùn)行

瀏覽器運(yùn)行結(jié)果,沒有什么問題娃兽，正常響應(yīng)

  • 修改 cache-control.js 返回值
response.writeHead(200, {
    'Content-Type': 'text/javascript',
    'Cache-Control': 'max-age=200'
});

response.end("console.log('script load ！４竽辍换薄！')");
  • 中斷上次程序，第二次運(yùn)行
瀏覽器運(yùn)行結(jié)果
第二次運(yùn)行翔试，從 memory cahce 讀取轻要，瀏覽器控制臺并沒有打印修改過的內(nèi)容
控制臺運(yùn)營結(jié)果
只請求了 / 并沒有請求 /script.js

源碼參考：github.com/Q-Angelo/http-protocol/blob/master/example/cache/cache-control.js

以上結(jié)果瀏覽器并沒有返回給我們服務(wù)端修改的結(jié)果，這是為什么呢垦缅？

先回答第一個問題

在頁面中引入靜態(tài)資源文件冲泥，為什么靜態(tài)資源文件改變后，再次發(fā)起請求還是之前的內(nèi)容壁涎，沒有變化呢凡恍？

是因?yàn)槲覀冋埱蟮?url /script.js 沒有變，那么瀏覽器就不會經(jīng)過服務(wù)端的驗(yàn)證怔球，會直接從客戶端緩存去讀嚼酝，就會導(dǎo)致一個問題，我們的js靜態(tài)資源更新之后竟坛，不會立即更新到我們的客戶端闽巩，這也是前端開發(fā)中常見的一個問題，我們是希望瀏覽器去緩存我們的靜態(tài)資源文件（js担汤、css涎跨、img等）我們也不希望服務(wù)端內(nèi)容更新了之后客戶端還是請求的緩存的資源，

回答第二個問題

在使用webpack等一些打包工具時崭歧，為什么要加上一串hash碼隅很？

解決辦法也就是我們在做 js 構(gòu)建流程時，把打包完成的 js 文件名上根據(jù)它內(nèi)容 hash 值加上一串 hash 碼率碾，這樣你的 js 文件或者 css 文件等內(nèi)容不變叔营，這樣生成的 hash 碼就不會變屋彪，反映到頁面上就是你的 url 沒有變，如果你的文件內(nèi)容有變化那么嵌入到頁面的文件 url 就會發(fā)生變化绒尊，這樣就可以達(dá)到一個更新緩存的目的撼班，這也是目前前端來說比較常見的一個靜態(tài)資源方案。

Expires 與 Cache-Control 對比

  • HTTP 協(xié)議對比：Expires 屬于 HTTP 1.0 時代的產(chǎn)物垒酬，Cache-Control 屬于 HTTP 1.1 時代的產(chǎn)物
  • 優(yōu)先級對比：如果同時使用 Cache-Control 的 max-age 與 Expires，則 max-age 優(yōu)先級會更高件炉，會忽略掉 Expires
  • 緩存單位：Expires 與 Cache-Control 兩者的緩存單位都是以時間為維度勘究，如果我要根據(jù)文件的內(nèi)容變化來判斷緩存是否失效怎么辦呢？就需要用到下面的協(xié)商緩存了斟冕。

協(xié)商緩存

如果強(qiáng)緩存未命中或用戶按下 F5 強(qiáng)制刷新后進(jìn)入?yún)f(xié)商緩存口糕，服務(wù)器則根據(jù)瀏覽器請求時的標(biāo)識進(jìn)行判斷，如果協(xié)商緩存生效返回 304 否則返回 200磕蛇。協(xié)商緩存的實(shí)現(xiàn)也是基于兩點(diǎn) Last-Modified景描、ETag 這個需要在 HTTP Headers 中設(shè)置。

Last-Modified/If-Modified-Since

Last-Modified 是在服務(wù)端設(shè)置進(jìn)行響應(yīng)秀撇，If-Modified-Since 是在瀏覽器端根據(jù)服務(wù)端上次在 Response Headers 中設(shè)置的 Last-Modified 取其值超棺，如果存在請求時設(shè)置其 Request Headers 值 If-Modified-Since 傳到服務(wù)器，服務(wù)器也是拿到這個值進(jìn)行比對呵燕，下面為核心實(shí)現(xiàn)棠绘。

if (request.url === '/script.js') {
    const filePath = path.join(__dirname, request.url); // 拼接當(dāng)前腳本文件地址
    const stat = fs.statSync(filePath); // 獲取當(dāng)前腳本狀態(tài)
    const mtime = stat.mtime.toGMTString() // 文件的最后修改時間
    const requestMtime = request.headers['if-modified-since']; // 來自瀏覽器傳遞的值

    console.log(stat);
    console.log(mtime, requestMtime);

    // 走協(xié)商緩存
    if (mtime === requestMtime) {
        response.statusCode = 304;
        response.end();
        return;
    }

    // 協(xié)商緩存失效，重新讀取數(shù)據(jù)設(shè)置 Last-Modified 響應(yīng)頭
    console.log('協(xié)商緩存 Last-Modified 失效');
    response.writeHead(200, {
        'Content-Type': 'text/javascript',
        'Last-Modified': mtime,
    });

    const readStream = fs.createReadStream(filePath);
    readStream.pipe(response);
}

執(zhí)行 node last-modified.js 啟動程序再扭，瀏覽器執(zhí)行 http://localhost:3010/打開頁面氧苍，我多次調(diào)用發(fā)現(xiàn)第一次是從服務(wù)器拿的數(shù)據(jù)且狀態(tài)為 200，之后每次都是 memory cache 為什么不是 304 呢泛范？

2.png

顯然是強(qiáng)緩存生效了让虐，你可能會想我沒有設(shè)置強(qiáng)緩存哦??

這是因?yàn)闉g覽器默認(rèn)啟用了一個啟發(fā)式緩存，這在設(shè)置了 Last-Modified 響應(yīng)頭且沒有設(shè)置 Cache-Control: max-age/s-maxage 或 Expires時會觸發(fā)罢荡，它的一個緩存時間是用 Date - Last-Modified 的值的 10% 作為緩存時間赡突。

3.png

現(xiàn)在我們要達(dá)到 304的效果，不走強(qiáng)緩存直接走協(xié)商緩存柠傍，修改我們的響應(yīng)麸俘，設(shè)置 Cache-Control=max-age=0 修改如下：

response.writeHead(200, {
    'Content-Type': 'text/javascript',
    'Last-Modified': mtime,
    'Cache-Control': 'max-age=0', // 修改地方
});

再次運(yùn)行我們的程序，控制臺執(zhí)行 node last-modified-max-age.js 再次重新打開頁面查看效果惧笛，第二次直接走的協(xié)商緩存且 Request Headers 攜帶了 If-Modified-Since: Wed, 25 Mar 2020 12:31:58 GMT


4.png

ETag 和 If-None-Match
Last-Modified 是以文件的修改時間來判斷从媚，Etag 是根據(jù)文件的內(nèi)容是否修改來判斷，如果 Etag 有修改重新獲取新的資源返回患整，如果未修改返回 304 通知客戶端使用本地緩存拜效。

Etag 的判斷主要也是在服務(wù)端通過一種 Hash 算法實(shí)現(xiàn)喷众，核心實(shí)現(xiàn)如下：

if (request.url === '/script.js') {
    const filePath = path.join(__dirname, request.url); // 拼接當(dāng)前腳本文件地址
    const buffer = fs.readFileSync(filePath); // 獲取當(dāng)前腳本狀態(tài)
    const fileMd5 = md5(buffer); // 文件的 md5 值
    const noneMatch = request.headers['if-none-match']; // 來自瀏覽器端傳遞的值

    if (noneMatch === fileMd5) {
        response.statusCode = 304;
        response.end();
        return;
    }

    console.log('Etag 緩存失效');
    response.writeHead(200, {
        'Content-Type': 'text/javascript',
        'Cache-Control': 'max-age=0',
        'ETag': fileMd5,
    });

    const readStream = fs.createReadStream(filePath);
    readStream.pipe(response);
}

node etag.js 運(yùn)行我們程序，打開我們的頁面多次訪問紧憾，第二次會看到瀏覽器會攜帶一個 If-None-Match 的 Header 頭傳遞到服務(wù)端進(jìn)行校驗(yàn)到千，當(dāng)前協(xié)商緩存命中了所以響應(yīng)狀態(tài)為 304.

5.png

Last-Modified 與 Etag 對比

  • 精確度：Last-Modified 以時間（秒）為單位，如果出現(xiàn) 1 秒內(nèi)文件多次修改赴穗，在 Last-Modified 緩存策略下也不會失效憔四，Etag 是對內(nèi)容進(jìn)行 Hash 比較，只要內(nèi)容變動 Etag 就會發(fā)生變化般眉，精確度更高了赵。
  • 分布式部署問題：分布式部署必然涉及到負(fù)載均衡，造成的一種現(xiàn)象是 Last-Modified 的時間可能還不太一致甸赃，而 Etag 只要保證每臺機(jī)器的 Hash 算法是一致的就可保證一致性柿汛。
  • 性能消耗：Etag 需要讀取文件做 Hash 計(jì)算，相比 Last-Modified 性能上是有損耗的埠对。
  • 優(yōu)先級：如果 Last-Modified/Etag 同時設(shè)置络断，Etag 的優(yōu)先級會更高些。
  • 相同點(diǎn)：校驗(yàn)通過返回 304 通知客戶端使用本地緩存项玛，校驗(yàn)不通過重新獲取最新資源貌笨，設(shè)置 Last-Modified/Etag 響應(yīng)頭，返回狀態(tài)碼 200 稍计。

疑問躁绸？

POST 可以緩存嗎？

GET 是一個冪等操作臣嚣，通常用于緩存净刮，POST 是一個非冪等的操作，每次創(chuàng)建新的資源硅则，也不會自動處理 POST 請求進(jìn)行緩存淹父，參考 rfc2616-sec9.html#sec9.1

附錄

  • 不同層中的稱謂：
    • 數(shù)據(jù)幀(Frame):是一種信息單位，它的起始點(diǎn)和目的點(diǎn)都是數(shù)據(jù)鏈路層
    • 數(shù)據(jù)包(Packet):也是一種信息單位怎虫，它的起始和目的地都是網(wǎng)絡(luò)層
    • 段(Segment): 通常是指起始點(diǎn)和目的地都是傳輸層的信息單元
    • 消息(message): 是指起始點(diǎn)和目的地都在網(wǎng)絡(luò)層以上(經(jīng)常在應(yīng)用層)的信息單元
最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末暑认，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子大审，更是在濱河造成了極大的恐慌蛙吏，老刑警劉巖禀崖，帶你破解...
    沈念sama閱讀 221,695評論 6贊 515
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件龄寞，死亡現(xiàn)場離奇詭異兵志，居然都是意外死亡，警方通過查閱死者的電腦和手機(jī)，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,569評論 3贊 399
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門导坟，熙熙樓的掌柜王于貴愁眉苦臉地迎上來屿良，“玉大人，你說我怎么就攤上這事惫周〕揪澹” “怎么了？”我有些...
    開封第一講書人閱讀 168,130評論 0贊 360
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵递递，是天一觀的道長喷橙。 經(jīng)常有香客問我，道長登舞，這世上最難降的妖魔是什么重慢？ 我笑而不...
    開封第一講書人閱讀 59,648評論 1贊 297
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮逊躁，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘隅熙。我一直安慰自己稽煤，他們只是感情好，可當(dāng)我...
    茶點(diǎn)故事閱讀 68,655評論 6贊 397
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布囚戚。 她就那樣靜靜地躺著酵熙，像睡著了一般。 火紅的嫁衣襯著肌膚如雪驰坊。 梳的紋絲不亂的頭發(fā)上匾二，一...
    開封第一講書人閱讀 52,268評論 1贊 309
  • 城市分裂傳說
    那天，我揣著相機(jī)與錄音拳芙，去河邊找鬼察藐。 笑死，一個胖子當(dāng)著我的面吹牛舟扎，可吹牛的內(nèi)容都是我干的分飞。 我是一名探鬼主播，決...
    沈念sama閱讀 40,835評論 3贊 421
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼睹限，長吁一口氣：“原來是場噩夢啊……” “哼譬猫！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起羡疗，我...
    開封第一講書人閱讀 39,740評論 0贊 276
  • 萬榮殺人案實(shí)錄
    序言：老撾萬榮一對情侶失蹤染服，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后叨恨，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體柳刮，經(jīng)...
    沈念sama閱讀 46,286評論 1贊 318
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,375評論 3贊 340
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了诚亚。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片晕换。...
    茶點(diǎn)故事閱讀 40,505評論 1贊 352
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖站宗，靈堂內(nèi)的尸體忽然破棺而出闸准，到底是詐尸還是另有隱情，我是刑警寧澤梢灭，帶...
    沈念sama閱讀 36,185評論 5贊 350
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布夷家，位于F島的核電站，受9級特大地震影響敏释，放射性物質(zhì)發(fā)生泄漏库快。R本人自食惡果不足惜，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,873評論 3贊 333
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一钥顽、第九天 我趴在偏房一處隱蔽的房頂上張望义屏。 院中可真熱鬧，春花似錦蜂大、人聲如沸闽铐。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,357評論 0贊 24
  • 一樁弒父案奶浦，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽兄墅。三九已至，卻和暖如春澳叉，著一層夾襖步出監(jiān)牢的瞬間隙咸，已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,466評論 1贊 272
  • 情欲美人皮
    我被黑心中介騙來泰國打工成洗， 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留五督，地道東北人。 一個月前我還...
    沈念sama閱讀 48,921評論 3贊 376
  • 代替公主和親
    正文 我出身青樓瓶殃，卻偏偏與公主長得像概荷，于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子碌燕，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,515評論 2贊 359