前端開發中常見的 HTTP 相關知識（一）

劉東發布于2019-08-26 13:50 / 2080人閱讀

摘要：前言前端開發中總是要和接口和緩存打交道，所以相關內容多多少少還是要知道一些，干起活來才能事半功倍。處于中的應用層。部分安全性問題發布于年的版本，也是當前的最新標準。基于谷歌提出的而來，之前用于瀏覽器中來訪問的加密服務，在發布后功成身退。

前言

前端開發中總是要和接口和緩存打交道，所以HTTP相關內容多多少少還是要知道一些，干起活來才能事半功倍。下面我從業務出發，簡單說下一些可能會碰到的知識點。
為了盡可能減少自己表述上的不嚴謹，文中會有不少外鏈，建議大家還是能點進去看一下，也歡迎幫忙糾正。

開始前的準備

老司機可以直接忽略本段內容，我們先簡單了解下 HTTP 的基本知識

什么是HTTP協議

HTTP是 Hypertext Transfer Protocol 超文本傳輸協議的縮寫，和 HTML 一樣都是出自Hypertext家族的。處于OSI model中的應用層。
目前為止，經歷了幾個版本的迭代到了2， HTTP/3目前也是即將要標準化了
關于目前所有的HTTP相關協議的目錄可以直接看這里

wikipedia上關于HTTP的介紹

The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia information systems.[1] HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser. HTTP was developed to facilitate hypertext and the World Wide Web.

Development of HTTP was initiated by Tim Berners-Lee at CERN in 1989. Development of HTTP standards was coordinated by the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C), culminating in the publication of a series of Requests for Comments (RFCs). The first definition of HTTP/1.1, the version of HTTP in common use, occurred in RFC 2068 in 1997, although this was made obsolete by RFC 2616 in 1999 and then again by the RFC 7230 family of RFCs in 2014.

A later version, the successor HTTP/2, was standardized in 2015 (and HTTP/3 is its proposed successor (Internet Draft), that builds on HTTP/22), and is now supported by major web servers and browsers over Transport Layer Security (TLS) using Application-Layer Protocol Negotiation (ALPN) extension[4] where TLS 1.2 or newer is required.[5]

起始

最早是由萬維網的創始人Tim Berners-Lee 在1989年發起并于1990年完成了第一次服務器與客戶端之間的通訊。

HTTP/0.9

發布于1991年的0.9版本，當時只有一個GET命令，只能回應HTML格式的字符串，結束以后就關閉TCP連接

HTTP/1.0 RFC-1945

發布于1996年的 1.0 版本，除了最早的 GET 以外還引入了POST 和 HEAD 命令，以及各類標識緩存，請求狀態等headers，使任何文件都可以通過http請求進行傳輸。

HTTP/1.1 RFC-2616

發布于1999年的 1.1 版本，也是目前使用基數最大的版本，
新增了幾個基礎 Method

PUT

DELETE

TRACE

OPTIONS

CONNECT

彌補了之前HTTP/1.0的一些不足，包括：

完善了之前緩存相關的設定，也便有了我們現在常說的強緩存和協商緩存的概念

默認采用持久連接，并能很好地配合代理服務器工作。支持以piplining的方式同時發送多個請求，從而降低了線路的負載也提升了HTTP請求的響應速度。

部分安全性問題

HTTP/2.0 RFC-7540

發布于2015年的 2.0 版本，也是當前的最新標準。

基于谷歌提出的SPDY而來，之前用于Chrome瀏覽器中來訪問Google的SSL加密服務，在HTTP/2發布后功成身退。

主要新增了以下內容

多路復用

請求頭壓縮 HPACK: RFC-7541

幀、消息、流和TCP連接

服務器推送

因為強制綁定了TLS，相關的證書又是一筆新的開支，加上各種歷史遺留問題，目前大部分公司對HTTP/2的支持也是較為尷尬，就如同 ES6 一般，在落地好多年后依舊會被叫做新特性。
而解決的問題如服務器推送之類的在之前是可以通過websocket甚至客戶端輪詢等操作解決，而頭部壓縮等也只是對現有方式進行了少部分優化，所以實際應用也沒那么多，而出現的不確定性又增多了，而本身又攬了一些TCP干的活，所以協議定下后爭議還是挺多的。

~~可能還需要時間把老服務器老電腦老項目老程序員給替換掉才行。~~

1. 緩存 RFC-7234

顧名思義，緩存就是瀏覽器存儲數據的地方，平時你可以通過特定的瀏覽器功能存儲一些數據，比如localStorage ,sessionStorage，但這些都是用戶通過腳本主動向瀏覽器添加的東西。
但是還有一些是我們希望加快用戶效率而存下的數據，但很多時候用戶總是特別喜歡用各類管家清理的東西，那就是HTTP的緩存了。

而緩存的作用是方便瀏覽器更快地讀取數據而不用反復和服務器確認。前端對于緩存這件事，用得好，事半功倍，沒用對，可能會讓你踏入無底深淵。

那我們首先了解下幾個常見的緩存相關的請求頭和響應頭：

Expires: 緩存的過期時間

Age: 文件的壽命

Cache-Control / Pragma : 在HTTP/1 的年代用Pragma，因為那個時候還沒Cache-Control, 如果你在請求中看到這個頭,那多半是為了做兼容

s-max-age

max-age

private

public

no-cache

no-store

must-revalidate

Warning 主要是以幾個可能會出現的異常信息的返回碼,參考[iana]

ETag 與 If-None-Match

Last-Modified 與If-Modified-Since (HTTP:1.0 ):

關于強制緩存還是協商緩存...

不知道是不是我沒翻對地方，還是這本來就是國內大家都在來回翻二手資料翻出來的烏龍，翻了一整個RFC-7234也沒翻到和這倆詞匯表達相關的內容，如果有相關文獻麻煩告知一二。
不過在我自己的理解上
網上所說的協商緩存大致就是該不該返回304，避免再拉一遍文件。
而強緩存就是是不是返回200(from disk)的概念
而通過Cache-Control來區別不緩存所有接口只返回200呢還是只做了基本時間校驗的緩存 200(from disk) ,200(from memory)還是需要通過請求頭以及返回頭來確認文件是否更改的 304(Not Modified)

現在：問題來了

這幾年前端體系越來越健全，spa也開始大行其道，一名初出茅廬的前端新人也能基于開源項目快速構建出一個單頁應用。
那么你是否碰到過新版本項目打包了上線了，結果一進去卻是緩存，還需要刷新一下才行，有時候刷新可能都不一定有用？
而更新本來就是悄咪咪進行的，用戶如果打不開頁面就換個服務了，根本不會給你第二次機會。
所以我們肯定要把這個文件的緩存去掉，但除了html文件不緩存以外，其他的js、css文件我又要做緩存而且越久越好，但業務要更新的時候我可能又要把老的文件的緩存去掉，那該怎么辦？

CDN

先簡單說下CDN是個什么東西，我們的代碼就像一個放在服務器的包裹，而用戶從我們的服務器中取包裹就像網購一般，要先判斷能不能拿到，比如

地方太遠，運費太貴[網絡超時]

比如地址填錯快遞無法送達[404]

打包的下班了，服務器重啟服務[500]

快遞太多服務器吃不消

而普通的用服務器發版就是很早以前淘寶小商戶的模式，你要準備倉庫又準備很多錢提前租倉庫囤貨找員工，但是你又不知道會有多少客戶來買東西，萬一客戶少了就賠本，萬一客戶多了又忙不過來爆倉或者貨準備太少不夠發，而且很多海外的客戶快遞也沒辦法發。
而CDN就像一個分布于全國的物流倉儲點，你把代碼告訴一臺主服務器，然后這個服務器就會把這份數據復制很多份發到分部于全國各地的代理數據倉庫。
然后對應地區的客戶去找對應的代理服務器拿貨，這樣速度也快，存貨也足，價格也便宜。
但是隨之而來的問題就是發出去的貨容易，收回來難，嗯，我把代碼發出去就沒準備收回來。
所以發出去的代碼我們需要在后面加上對應的hash指紋
這就是為什么很多webpack配置腳手架打包的文件都帶個hash
至于找到它們的事情就交給index.html吧

NGINX

生成的html文件我們有了幾個新去處，可以發到公司服務器里的nginx再加上一行不緩存的header

location ~ .*.(htm|html )$ {
    add_header Cache-Control no-store;
}

然后可以通過替換html文件做一個簡單的脫離后端服務的無感知更新
甚至可以配合后端實現藍綠部署

【待續】

云服務器 GPU云服務器前端開發基礎知識相關知識 js中常見的變量名稱 cdn相關知識

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/109641.html

前端開發知識點整理

摘要：前言本文主要是有關前端方面知識按照目前的認知進行的收集歸類概括和整理，涵蓋前端理論與前端實踐兩方面。前言：本文主要是有關前端方面知識按照 XX 目前的認知進行的收集、歸類、概括和整理，涵蓋『前端理論』與『前端實踐』兩方面。本文會告訴你前端需要了解的知識大致有什么，看上去有很多，但具體你要學什么，還是要 follow your heart & follow your BOSS。初衷...

Blackjun 2019-08-20 17:14 評論0 收藏0
前端開發知識點整理

摘要：前言本文主要是有關前端方面知識按照目前的認知進行的收集歸類概括和整理，涵蓋前端理論與前端實踐兩方面。前言：本文主要是有關前端方面知識按照 XX 目前的認知進行的收集、歸類、概括和整理，涵蓋『前端理論』與『前端實踐』兩方面。本文會告訴你前端需要了解的知識大致有什么，看上去有很多，但具體你要學什么，還是要 follow your heart & follow your BOSS。初衷...

Sike 2019-08-29 12:44 評論0 收藏0
前端開發知識點整理

摘要：前言本文主要是有關前端方面知識按照目前的認知進行的收集歸類概括和整理，涵蓋前端理論與前端實踐兩方面。前言：本文主要是有關前端方面知識按照 XX 目前的認知進行的收集、歸類、概括和整理，涵蓋『前端理論』與『前端實踐』兩方面。本文會告訴你前端需要了解的知識大致有什么，看上去有很多，但具體你要學什么，還是要 follow your heart & follow your BOSS。初衷...

tracy 2019-08-01 16:59 評論0 收藏0
參加第二屆前端開發者年度大會總結

摘要：代表公司去參加今年的第二屆前端開發者年度大會，散會的時候，技術老大問我，今天感覺怎么樣，有什么收獲，當時就零零碎碎的回答了一些，不算完美趁著還記得點什么，在這里做個自我回顧總結，謹代表個人見解，有不當之處，或若涉及圖片隱私或者其它問題，煩請代表公司去參加今年的第二屆前端開發者年度大會，散會的時候，Team 技術老大問我，今天感覺怎么樣，有什么收獲，當時就零零碎碎的回答了一些，不算完...

solocoder 2019-08-19 17:55 評論0 收藏0
前端基礎入門

摘要：手把手教你做個人火的時候，隨便一個都能賺的盆滿缽滿，但是，個人沒有服務端，沒有美工，似乎就不能開發了，真的是這樣的嗎秘密花園經典的中文手冊。涵蓋前端知識體系知識結構圖書推薦以及入門視頻教程，全的簡直不要不要的了。 JavaScript 實現點擊按鈕復制指定區域文本 html5 的 webAPI 接口可以很輕松的使用短短的幾行代碼就實現點擊按鈕復制區域文本的功能，不需要依賴 flash。...

shinezejian 2019-08-22 13:51 評論0 收藏0