前端日拱一卒D4——網路基礎與HTTP

DerekZ95發表於2019-03-04

前言

餘為前端菜鳥,感姿勢水平匱乏,難觀前端之大局。遂決定循前端知識之脈絡,以興趣為引,輔以幾分堅持,望於己能解惑致知、於同道能助力一二,豈不美哉。

本系列程式碼及文件均在 此處

網路層級

20170516149490559398728.png
  • 實體層(物理層):連線計算機(光纖、電纜線、無線電波、雙絞線等)。

  • 連結層(資料鏈路層):確定0 1的分組形式。

    • 乙太網協議

      一組電訊號組成一幀,一幀分為head和data兩部分,head中包含接收方MAC地址資訊,以廣播的方式向本網路內所有計算機傳送資料包,由接收方自己比對MAC地址判斷是否接收。

  • 網路層:主機到主機的通訊。

    • 網際網路由許多子網路組成,在同一子網中可以通過MAC地址以廣播形式找到目標,但是不同子網廣播不過去,所以需要在網路層引入新的地址用於查詢子網路,即網址。

    • IP協議

      IPV4規定網路地址由32個二進位制位組成,以IP地址與子網掩碼相加是否相等判斷是否位於同一個子網路。IP資料包放入到乙太網資料包的data部分,IP資料包同樣包含head和data兩部分。

    • ARP協議

      通過IP地址獲取MAC地址(不在同一子網交由閘道器處理),在同一個子網路中廣播發出資料包包含目標IP地址,MAC地址為FF:FF:FF:FF:FF:FF目標主機接收到後比對成功後報告自己的MAC地址,於是獲取到了MAC地址,可以把資料包傳送到子網路裡任一主機。

  • 傳輸層:埠到埠的通訊。(埠為每個使用網路卡的程式的編號)

    • UDP協議

      資料包放入到IP資料包的data中,同樣由head和data組成,head主要定義發出埠和接收埠,data為具體內容。

    • TCP協議

      有確認機制的UDP,每個資料包需要確認,過程複雜,消耗更多的資源。

  • 應用層:規定應用程式的資料格式。(DHCP,DNS,HTTP,FTP,SSH等)

20170516149490921439572.png

使用者角度

  • 網路通訊是主機間資料包交換,要交換資料需要知道雙方的MAC地址和IP地址。

  • 使用者可以通過靜態IP和動態IP兩種方式實現網路通訊配置。

    • 設定本機靜態IP、子網掩碼從而確定本機所處子網路,設定閘道器用於跨子網通訊,設定DNS伺服器地址用於DNS解析。
    • 利用DHCP協議,以廣播形式向DHCP伺服器獲取動態的IP地址。
  • 例項:訪問頁面。

    • 瀏覽器中輸入URL,從本地(瀏覽器->OS)DNS快取中獲取目標伺服器IP地址,本地沒有則向DNS伺服器請求,獲取到IP地址後快取到本地。
    • 判斷是否為同一子網路,是則資料包應包含本機和目標主機的MAC、IP地址,否則目標主機的MAC地址應改為閘道器MAC地址。
    • 組裝資料包,如上圖。
    • 建立TCP連線,經歷三次握手後在第三次將資料包傳送到目標伺服器,伺服器取出完整的TCP資料包後做處理,定位資源,將資源複本寫到TCP套接字做出HTTP響應,然後藉由TCP協議再傳送回來到客戶端。
    • 客戶端收到響應,進行頁面處理、展示。

HTTP

基礎

應用層協議,無狀態。

  • 請求/響應模型

    客戶端向服務端傳送請求,服務端根據接收到的請求,處理後向客戶端返回響應資訊。

    前端日拱一卒D4——網路基礎與HTTP
  • url

    協議型別:[//[訪問資源需要的憑證資訊@]伺服器地址[:埠號]][/資源層級UNIX檔案路徑]檔名[?查詢][#片段ID]

    用於定位資源,輸入url->客戶端展示的過程不再贅述

  • 請求/響應結構

    • 請求:請求行、請求頭、請求正文(只有POST有)
    • 響應:狀態行、響應頭、響應正文
    • 頭域:重點關注快取相關,這裡不贅述

    get和post區別在於前者引數在url後,後者在請求正文;前者有大小限制,後者無,後者有請求體,前者無

    關於狀態碼,一般來說簡單記憶如下:1XX 可續發 2XX 成功 3XX 重定向 4XX 客戶端錯誤 5XX 服務端錯誤

HTTP1.1

  • 長連線

    // 請求頭、響應頭中包含
    Connection: keep-alive
    複製程式碼

    1.1預設開啟長連線,使得連線在一段時間內維持開啟,後續請求可複用,減少建立連線的成本

  • 協議升級

    // 請求頭中包含
    Connection: Upgrade
    Upgrade: websocket
    複製程式碼

    升級為websocket協議,後續會談到

  • 快取控制

    cache-rule
    • 1.0的expires -> 1.1的cache-control

      後者是相對時間,兩者都存在時,以後者為判斷過期依據(瀏覽器判斷)

    • Etag與Last-Modified

      如果上次返回頭中有Etag,則帶上if-none-match資訊請求到服務端,服務端進行判斷Etag是否修改,選擇304/200

      如果上次返回頭中有Last-Modified,則帶上if-modified-since資訊請求道服務端,服務端判斷是否失效,返回304/200

  • 痛點

    • 明文傳輸,不安全
    • header過大,且很多時候header變化不大,資源浪費
    • keep-alive給服務端帶來效能問題
  • 需優化點

    • 頻寬
      • pay more
    • 延遲
      • DNS解析:解決:預解析與快取。
      • 建立連線消耗:基於TCP,每次建立連線都需要經歷三次握手,最快也要在第三次才能將報文傳送到服務端。解決:keep-alive/HTTP2
      • 瀏覽器阻塞:由於瀏覽器單域名下最大連線限制(6個),達到限制後會導致後續請求阻塞,解決:將域名分割槽,提高並行資源下載能力;合併資源,減少請求個數。

HTTPS

圖解

前端日拱一卒D4——網路基礎與HTTP

HTTPS執行在SSL/TLS上,SSL/TLS執行在TCP上,所有傳輸內容都是需要加密的,可以有效防劫持

前端日拱一卒D4——網路基礎與HTTP

握手階段:

  • 客戶端給出協議版本、客戶端生成的隨機數、支援的加密方法
  • 服務端收到後確認加密方法,返回數字證書,以及一個服務端生成的隨機數
  • 客戶端確認證書有效,生成一個隨機數,用證書彙總的公鑰加密隨機數,傳送給服務端
  • 服務端使用私鑰獲得客戶端傳送的隨機數
  • 根據約定的加密演算法,使用前面的三個隨機數生成會話金鑰,用來加密後續整個會話過程

加密解密

  • 公鑰和私鑰只用於加密/解密 對話金鑰(非對稱)
  • 安全與否取決於三個隨機數中的第三個能否被破解

對稱加密/非對稱加密

  • 使用一對金鑰,公鑰用來加密,私鑰不公開,用於解密,慢,但是更安全 —-> 非對稱加密
  • 金鑰在網路中傳輸,快但是不安全 —-> 對稱加密
  • 解決:用非對稱加密的公鑰加密對稱加密的金鑰,接收方用私鑰解密得到對稱金鑰,用於加密資訊(減少複雜度,降低伺服器壓力)

升級至HTTPS

  • github免費的github pages用來搭建個人部落格非常方便,感興趣的可以參考這裡

    在專案設定下選擇開啟HTTPS即可

    前端日拱一卒D4——網路基礎與HTTP

    小綠鎖很醒目

    前端日拱一卒D4——網路基礎與HTTP
  • 個人站點升級HTTPS

    • 從域名服務商獲取免費的SSL證書

      前端日拱一卒D4——網路基礎與HTTP

      按照流程填寫

      前端日拱一卒D4——網路基礎與HTTP
    • 下載證書到伺服器(我的是一年免費的谷歌gce)

    • 修改nginx配置

      server {
          listen 80;
          server_name pandora.derekz.cn;
          # 重定向到https
          rewrite ^(.*)$  https://$host$1 permanent;
      
          location / {
              root html;
              index index.html index.htm;
          }
      }
      server {
          # 順便換http2吧
          listen 443 ssl http2;
          server_name pandora.derekz.cn;
          root html;
          index index.html index.htm;
      
          # 你的證書路徑
          ssl_certificate   /etc/nginx/cert/xxxxxxx.pem;
          ssl_certificate_key  /etc/nginx/cert/xxxxxxx.key;
      
          ssl_session_timeout 5m;
          ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
          ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
          ssl_prefer_server_ciphers on;
      }
      複製程式碼
    • 重啟nginx,稍稍等待訪問個人網站

      前端日拱一卒D4——網路基礎與HTTP

HTTP2

SPDY

SPDY與HTTP2區別在於前者強制使用SSL傳輸協議,以及兩者在首部演算法上有所區別,SPDY出現於HTTP2前,特點與HTTP2類似:多路複用、伺服器推送、頭部壓縮等。這裡暫不討論。

核心——二進位制分幀

  • HTTP2採用完全二進位制的格式傳輸資料。二進位制資料在網路中傳輸單位一般為幀
  • 一個幀包含有:型別Type、長度Length、標記Flag、流標識Stream和Frame payload(幀有效載荷)
  • 多個幀形成幀的傳輸網路流,可以認為HTTP2是流式傳輸。
前端日拱一卒D4——網路基礎與HTTP
  • 不改變HTTP的語義,方法、首部、動詞都不受影響
  • 在應用層(HTTP2.0)和傳輸層(TCP)之間多了一個二進位制分幀層
  • 將請求的內容分割為幀,頭部資訊放入headers幀,body放入data幀
  • HTTP2.0所有的通訊都在一個連線上完成,每個資料流以訊息形式傳送,一個訊息包含一個或多個幀,可以亂序,到達目的地後根據幀首部的流識別符號重組

首部壓縮

  • 客戶端和伺服器端使用“首部表”來跟蹤和儲存之前傳送的鍵-值對
  • 如果首部不發生變化,那麼首部0開銷,此時首部自動使用之前請求的首部
  • 如果發生變化,只需要將變化的部分填入首部,同時更新兩端維護的首部表即可
  • 於是,並不會有分幀後多加了很多首部幀帶來的效能問題,反而提升了效能
  • 合併資源減少請求並不適用與HTTP2,因為都在一個連線上

雙向並行

前端日拱一卒D4——網路基礎與HTTP

不需要域名分割槽,因為不限制,而且可以雙向並行多個請求/響應

HTTP2的多路複用與1.x的keep-alive本質上有區別,一個位於傳輸層,一個位於應用層,且後者是序列的,前者允許多個檔案傳輸幀在圖個TCP連線中同時流式傳輸

服務端推送

location / {
  root   /usr/share/nginx/html;
  index  index.html index.htm;
  http2_push /style.css;
  http2_push /example.png;
}
複製程式碼

http2_push欄位,只請求了/index.html 卻返回了style.css等額外資料。待研究

遷移HTTP2

細心的小夥伴也許發現了上面的nginx conf檔案內有這麼一行

listen 443 ssl http2;
複製程式碼

從HTTPS遷移到HTTP2非常簡單,只需要修改nginx配置即可,最後開啟chrome可以看到http2的連線情況

前端日拱一卒D4——網路基礎與HTTP

思考

我們說一個網頁的效能多好,最直接的一個表現是從enter敲下到頁面展示花的時間多短,也就是我們追求的低延遲高頻寬。頻寬隨著網路基礎建設不斷提高,所以效能瓶頸主要在於低延遲的難實現。

想想看,我們又要DNS解析,又要建立連線,還要加密解密,歷經千難萬險才能把請求資訊送到伺服器上。完了以後那一頭的人還得禮尚往來,這之間每個步驟都是我們實現低延遲的障礙,也是我們優化的方向。

比如DNS預解析、HTTP2的多路複用使用一條連線、頭部壓縮、對稱加密+非對稱加密、快取策略等等。理解這樣一個過程以後,要怎麼做就得實際動手處理問題中積累經驗啦。

雖發表於此,卻畢竟為一人之言,又是每日學有所得之筆記,內容未必詳實,看官老爺們還望海涵。

相關文章