全棧必知系列之網絡知識篇

時間 2020-05-30

原文原文鏈接

爲了讓用戶可以擁有更加良好的用戶體驗，優化頁面加載速度成爲前端開發過程當中極其重要的一環，而網絡資源的傳輸速度無可厚非成爲了優化提速最重要的部分，知道網絡傳輸的各個環節的前因後果才能更好地去優化，所以做爲一名合格的前端開發人員仍是有必要了解網絡相關的知識。css

HTTP的發展進程

HTTP0.9

HTTP0.9當時主要爲了簡單的用於網絡之間傳輸HTML超文本內容，因此稱爲超文本傳輸協議，實現也相對簡單html

流程以下前端

基於TCP協議，客戶端根據IP和端口號和服務器創建TCP鏈接，創建鏈接過程就是TCP協議的三次握手過程
創建好鏈接經過GET請求獲取index.html
服務器接收請求信息以後，讀取對應的 HTML 文件，並將數據以 ASCII 字符流返回給客戶端。
HTML文檔傳輸完成，斷開鏈接

HTTP1.0

引入請求頭和迴應頭

因爲萬維網高速發展，出現了js，css以及郵件等多種形式的文本，單純的get請求和ASCII字符流沒法知足需求，經過請求頭和迴應頭指明文件類型和字符編碼以及語言等信息content-encoding content-typeweb

引入狀態碼

有的請求服務器可能沒法處理，或者處理出錯，這時候就須要告訴瀏覽器服務器最終處理該請求的狀況，這就引入了狀態碼。狀態碼是經過響應行的方式來通知瀏覽器的算法

提供了Cache機制

爲了減輕服務器的壓力，在 HTTP/1.0 中提供了Cache 機制，用來緩存已經下載過的數據。數據庫

加入用戶代理字段

服務器須要統計客戶端的基礎信息，好比 Windows 和 macOS 的用戶數量分別是多少，因此 HTTP/1.0 的請求頭中還加入了用戶代理的字段。後端

HTTP1.1

改進持久鏈接以及CDN域名的分片機制

因爲請求資源的增多，HTTP1.0的短鏈接方式沒法知足需求，HTTP1.1增長了connection:keep-alive(默認激活，關閉改成close),同一個域名能夠創建6個TCP鏈接(這也是爲啥須要配置多個DNS域名的緣由增長TCP鏈接量)瀏覽器

下圖是1.0和1.1的請求對比緩存

不成熟的HTTP管線化（部分瀏覽器嘗試失敗）

持久鏈接雖然減小了TCP的鏈接斷開次數，可是單個TCP通道請求隊列須要每一個請求發送完獲得迴應才能進行下一個任務的請求，發生隊頭阻塞,因此將請求批量發送給服務器，但服務器依然須要按順序依次處理返回安全

提供虛擬主機支持

因爲一個服務器上面增設多個虛擬主機，也就是一個IP地址對應多個域名，HTTP1.1頭部增長了Host字段

對動態生成的內容完美支持

以前傳輸內容須要標明內容大小，一次性傳輸完，隨着內容的增大，引入了chunk transfer機制

引入cookie以及安全機制

HTTP2.0

HTTP1.1的問題

HTTP1.1慢啓動影響資源首次加載速度

TCP創建鏈接後，剛開始請求傳輸速度比較慢而後逐漸的不斷提速（主要是爲了防止出現網絡擁堵）,這樣會讓頁面的首次渲染時間變長

開啓多個TCP管道，出現帶寬的競態問題

多個TCP管道一塊兒開啓一旦出現網速降低，沒法識別資源的優先級，出現競態問題

單個TCP管道隊頭阻塞

因爲管線化不成熟，隊頭阻塞依然存在

HTTP2.0的更改

多路複用機制

鑑於以上的問題，HTTP2.0引入二進制的分幀層機制來實現多路複用，關於多路複用的實現以下：

單個域名之下仍然只容許創建一個TCP管道，使用一個TCP長鏈接（整個頁面資源下載只須要一次慢啓動，並且避免了競態）
瀏覽器準備好請求數據（請求行+請求頭+請求體），而後分幀層對每一個請求進行分割，將同一個請求的分割塊打上相同的ID編號，經過協議棧將全部的分割體發給服務器
服務器端的分幀層根據ID編號進行請求組裝
服務器的分幀層將回應數據分割按同一個迴應體進行ID分割回應給客戶端
客戶端拼裝回應

能夠設置請求的優先級

客戶端的分幀層對分割塊標上請求的優先級

服務器推送服務器根據請求的資源主動推送其餘與該請求資源關聯的資源（好比請求html,服務器順便迴應內嵌的js和css資源）
頭部壓縮請求頭壓縮，增長傳輸效率

HTTP3.0

HTTP2.0雖然採用多路複用機制解決大多數問題，可是和HTTP1.1同樣，TCP管道傳輸途中也會出現丟包問題（丟包就必須等待從新發包）,形成隊頭阻塞，這樣2.0的單個TCP長鏈接丟包率太高的狀況下（高於2%）還不如1.1的6個管道傳輸效率，而且2.0的TCP創建鏈接三次握手以及HTTPS的TSL鏈接也會耗費較多時間

因爲TCP協議的僵化以及底層包括中間設備的僵化，沒法再進行修改，因而3.0基於UDP協議開發了QUIC協議

實現了相似 TCP 的流量控制、傳輸可靠性的功能。
集成了 TLS 加密功能。
實現了 HTTP/2 中的多路複用功能。和 TCP 不一樣，QUIC 實現了在同一物理鏈接上能夠有多個獨立的邏輯數據流（以下圖）。實現了數據流的單獨傳輸，就解決了 TCP 中隊頭阻塞的問題。

實現了快速握手功能。

HTTPS

HTTPS在HTTP基礎上增長了安全層(SSL安全套接層/TSL傳輸層安全)

安全層的兩個主要職責：對發起HTTP請求的數據進行加密操做和對接收到的HTTP內容進行解密操做

對稱加密

對稱加密是指加密和解密都使用的是相同的密鑰

速度快但祕鑰傳遞過程容易被中間人劫持

非對稱加密

非對稱加密算法有 A、B 兩把密鑰，若是你用 A 密鑰來加密，那麼只能使用 B 密鑰來解密；反過來，若是你要 B 密鑰來加密，那麼只能用 A 密鑰來解密

第一個是非對稱加密的效率過低
第二個是沒法保證服務器發送給瀏覽器的數據安全,服務器發送給客戶端的數據只能用私鑰加密，公鑰每一個人都有，因此中間人可解密服務端到客戶端的數據

混合加密

在傳輸數據階段依然使用對稱加密，可是對稱加密的密鑰咱們採用非對稱加密來傳輸

雖然混合加密比較安全，但咱們沒法知道數據是否被篡改，服務端沒法知道加密是不是對應客戶端的隨機數，客戶端也沒法知道獲取的必定是服務端給的公鑰

CA認證

服務器生成公鑰A+私鑰A,將公鑰A和信息(公司、網站等)發送給CA機構認證
CA用經過線上線下渠道確認該公司信息，審覈經過而後對信息進行hash加密，生成 信息摘要,而後用本身的私鑰B對信息摘要加密生成 數字簽名，將 數字簽名和 信息裝在一塊兒組成 數字證書發給服務器
服務器將數字證書發給客戶端
- 首先瀏覽器讀取證書中的證書全部者、有效期等信息進行一一校驗
- 瀏覽器開始查找操做系統中已內置的受信任的證書發佈機構CA，與服務器發來的證書中的頒發者CA比對，用於校驗證書是否爲合法機構頒發
- 若是找不到，瀏覽器就會報錯，說明服務器發來的證書是不可信任的。若是找到，那麼瀏覽器就會從操做系統中取出頒發者CA 的公鑰，而後對服務器發來的證書裏面的簽名進行解密
- 瀏覽器使用相同的hash算法根據證書內容計算出信息摘要，將這個計算的值與證書解密的值作對比
- 對比結果一致，則證實服務器發來的證書合法，沒有被冒充。此時瀏覽器就能夠讀取證書中的公鑰，用於後續加密了
客戶端用CA的私鑰B解密獲得消息摘要，並對原始信息採用一樣hash算法作比較，確認公鑰未被篡改
客戶端生成隨機數字採用公鑰加密隨機數，發給客戶端
客戶端解密獲取隨機數，創建對稱加密信息傳輸通道

cookie

爲啥會產生cookie?

因爲HTTP1.X是一個無狀態協議，也就是客戶端同一個請求發送屢次，服務端並不能識別是否是同一個客戶端發送，爲了解決無狀態狀況，出現了cookie

cookie設置流程

客戶端請求服務端 -> 服務端迴應頭部set-cookie -> 客戶端收到並保存到本地 -> 客戶端請求攜帶頭部字段cookie

cookie屬性

屬性	解釋
expires	有效期，以客戶端爲準
max-Age	正數s，負數s馬上刪除，0爲會話cookie即關閉瀏覽器就是消失
Domin	cookie送達的主機名
Path	攜帶cookie的資源路徑
Secure	標記爲Secure只會https發送
HttpOnly	標記爲HttpOnly前端沒法經過document.cookie獲取，避免xss攻擊
SameSite	Chrome80新加入的屬性

cookie做用

會話狀態管理（如用戶登陸狀態、購物車、遊戲分數或其它須要記錄的信息）
個性化設置（如用戶自定義設置、主題等）
瀏覽器行爲跟蹤（如跟蹤分析用戶行爲等）

SameSite

好比當前網頁www.renrendai.com爲一方請求，請求後端必然根據設置的domin和path會攜帶對應的cookie,可是好比經過www.baidu.com等三方網站點擊跳轉到www.renrendai.com的請求會根據SameSite的設定一方請求是否攜帶cookie；

所謂同站(一方)就是頂級域名和二級域名相同 eg: a.taobao.com 和 b.taobao.com 頂級域名爲.com, 二級域名爲taobao, 也就是前面截去.後面截去頂級域名，中間部分爲二級域名 a.a.xx.cn二級域名爲a.xx

異步請求（不會改變當前頁面，也不會打開新頁面），好比經過 <script>、<link>、<img>、<iframe> 等標籤發起的請求，還有經過各類發送 HTTP 請求的 DOM API（XHR，fetch，sendBeacon）發起的請求。
同步請求（可能改變當前頁面，也可能打開新頁面），好比經過對 <a> 的點擊，對 <form> 的提交，還有改變 location.href，調用 window.open() 等方式產生的請求。

SameSite三個值

strict全部三方的連接都不會攜帶cookie，好比你當前淘寶處於登陸態，可是從百度跳轉到淘寶的頁面卻沒有登陸態，於是沒法發起csrf攻擊
lax只有同步且是get請求才可攜帶cookie
none全部三方的請求都會攜帶cookie

Token

token解決的問題

徹底由應用端管理，避開了同源策略
token能夠避免csrf攻擊
能夠多服務器之間共享

如何解決token過時問題

token發送給服務端，服務端緩存過時時間，每次請求都查看過時時間，若是過時則直接推遲過時時間
前端將token發送給服務端，服務端發現token過時提示前端，前端調用後端的refresh刷新過時時間

token組成

JWT格式：Header.Payload.Signature

Header = {
 alg: "HS256", // 簽名算法  typ: "JWT" // 令牌類型 } Payload = { // 內容提  sub: '123123',  name: 'Jone',  admin: true, }  Signature = Hash256(`${base64(header)}.${base64(patload)}.${secret}`) 複製代碼

分離認證服務

網絡安全

聊聊大前端網絡安全那些事

TCP/IP

TCP/IP 協議其實是一系列網絡通訊協議的統稱，其中最核心的兩個協議是TCP和IP，其餘的還有 UDP、ICMP、ARP 等等，共同構成了一個複雜但有層次的協議棧。

IP協議(Internet Protocol) 主要目的是解決尋址和路由問題，以及如何在兩點間傳送數據包，採用IP地址來定位互聯網的每一臺計算機(IPV4/IPV6)

TCP協議(Transmission Control Protocol) 它位於 IP 協議之上，基於 IP 協議提供可靠的、字節流形式的通訊，是 HTTP 協議得以實現的基礎。保證數據的完整性和不丟失

HTTP 是一個"傳輸協議"，但它不關心尋址、路由、數據完整性等傳輸細節，而要求這些工做都由下層來處理。由於互聯網上最流行的是 TCP/IP 協議，而它恰好知足 HTTP 的要求，因此互聯網上的 HTTP 協議就運行在了 TCP/IP 上，HTTP 也就能夠更準確地稱爲「HTTP over TCP/IP」。

分層

TCP/IP協議總共有四層，以下

應用層決定了向用戶提供應用服務時通訊的活動。 TCP/IP協議族內預存了各種通用的應用服務。好比，FTP（File Transfer Protocol，文件傳輸協議）和DNS（Domain Name System，域名系統）服務就是其中兩類。HTTP協議也處於該層。
傳輸層對上層應用層，提供處於網絡鏈接中的兩臺計算機之間的數據傳輸。在傳輸層有兩個性質不一樣的協議：TCP（Transmission Control Protocol，傳輸控制協議）和UDP（User Data Protocol，用戶數據報協議）。傳輸層對上層應用層，提供處於網絡鏈接中的兩臺計算機之間的數據傳輸。在傳輸層有兩個性質不一樣的協議：TCP（Transmission Control Protocol，傳輸控制協議）和UDP（User Data Protocol，用戶數據報協議）。
網絡層（又名網絡互連層）網絡層用來處理在網絡上流動的數據包。數據包是網絡傳輸的最小數據單位。該層規定了經過怎樣的路徑（所謂的傳輸路線）到達對方計算機，並把數據包傳送給對方。與對方計算機之間經過多臺計算機或網絡設備進行傳輸時，網絡層所起的做用就是在衆多的選項內選擇一條傳輸路線。
鏈路層（又名數據鏈路層，網絡接口層）用來處理鏈接網絡的硬件部分。包括控制操做系統、硬件的設備驅動、NIC（Network Interface Card，網絡適配器，即網卡），及光纖等物理可見部分（還包括鏈接器等一切傳輸媒介）。硬件上的範疇均在鏈路層的做用範圍以內

七層協議

工做原理

應用層根據請求信息生成請求報文（請求行+請求頭+請求體）
在傳輸層（TCP協議）把從應用層處收到的數據（HTTP請求報文）進行分割，並在各個報文上打上標記序號及端口號後轉發給網絡層。
網絡層增長通訊的Mac地址，搜索對方的地址，一邊中轉一邊傳送
接收端的服務器在鏈路層接收到數據，按序往上層發送，一直到應用層。當傳輸到應用層，才能算真正接收到由客戶端發送過來的HTTP請求。
發送端在層與層之間傳輸數據時，每通過一層時一定會被打上一個該層所屬的首部信息。反之，接收端在層與層傳輸數據時，每通過一層時會把對應的首部消去。

TCP三次握手和四次揮手

發送端首先發送一個帶SYN標誌的數據包給對方。接收端收到後，回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息。最後，發送端再回傳一個帶ACK標誌的數據包，表明「握手」結束。若在握手過程當中某個階段莫名中斷，TCP協議會再次以相同的順序發送相同的數據包。

DNS

全稱 Domain Name System ,即域名系統。在 TCP/IP 協議中使用 IP 地址來標識計算機，數字形式的地址對於計算機來講是方便了，但對於人類來講卻既難以記憶又難以輸入。因此出現了域名

DNS結構

根域名服務器（Root DNS Server）：管理頂級域名服務器，返回「com」「net」「cn」等頂級域名服務器的 IP 地址；
頂級域名服務器（Top-level DNS Server）：管理各自域名下的權威域名服務器，好比 com 頂級域名服務器能夠返回 apple.com 域名服務器的 IP 地址；
權威域名服務器（Authoritative DNS Server）：管理本身域名下主機的 IP 地址，好比 apple.com 權威域名服務器能夠返回 www.apple.com 的 IP 地址。
本地域名服務器 (Local DNS Server)，不少大公司和網絡運營商創建本身的DNS服務器

DNS查詢過程

iOS設備請直接跳到第三步驟

首先搜索瀏覽器自身的DNS緩存,若是存在，則域名解析到此完成。
若是瀏覽器自身的緩存裏面沒有找到對應的條目，那麼會嘗試讀取操做系統的hosts文件看是否存在對應的映射關係,若是存在，則域名解析到此完成。
若是本地Host文件中沒有那麼操做系統會把這個域名發送給這裏設置的LocalDNS，也就是本地區的域名服務器。這個DNS一般都提供給你本地互聯網接入的一個DNS解析服務。這個專門的域名解析服務器性能都會很好，它們通常都會緩存域名解析結果，固然緩存時間是受域名的失效時間控制的，通常緩存空間不是影響域名失效的主要因素。
若是本地DNS服務器還沒找到的話,它就會向根服務器發出請求,進行遞歸查詢。
根域名服務器返回給本地域名服務器一個所查詢的域的主域名服務器（gTLD Server）地址。gTLD是國際頂級域名服務器，如.com，.cn、.org等。全球只有13臺左右。
本地域名服務器（Local DNS Server）再向上一步返回的gTLD服務器發送請求。
接受請求的gTLD服務器查找並返回此域名對應的Name Server域名服務器的地址，這個Name Server一般就是你註冊的域名服務器，例如你在某個域名服務提供商申請的域名，那麼這個域名解析任務就由這個域名提供商的服務器來完成
Name Server域名服務器會查詢存儲的域名和IP的映射關係表，正常狀況下都根據域名獲得目標IP記錄，連同一個TTL值返回給DNS Server域名服務器。
返回該域名對應的IP和TTL值，Local DNS Server會緩存這個域名和IP的對應關係，緩存的時間由TTL值控制。
返回該域名對應的IP和TTL值，Local DNS Server會緩存這個域名和IP的對應關係，緩存的時間由TTL值控制。

CDN

CDN，全稱Content Delivery Network，根本的做用是將網站的內容發佈到最接近用戶的網絡「邊緣」，使用戶能夠就近取得所需的內容，提升用戶訪問網站的響應速度。他-有別於鏡像，它比鏡像更智能，能夠這樣作一個比喻：CDN=鏡像（Mirror） + 緩存（cache） + 總體負載均衡（GSLB），於是，CDN能夠明顯提升Internet中信息流動的效率。目前CDN都以緩存網站中的靜態數據爲主，如CSS、JS、圖片和靜態網頁等數據。用戶在從主站服務器請求到動態內容後再從CDN上下載這些靜態數據，從而加速網頁數據內容的下載速度，如淘寶有90%以上的數據都是由CDN來提供的。這裏引用一個網上比較形象的例子：A家的網速 100M的，但他只用了10M的速度，B家的網速是10M的，可是他須要15M的速度才行。怎麼辦呢。 C是一家CDN服務商，在A家有個節點（就像A是一個贊助商同樣）B在C家買了CDN加速服務。當B的速度不夠的時候，CDN加速就會選擇有節餘的節點來幫B，提升B的速度。這樣B的速度就能達到或超過15M ，皆大歡喜。A沒浪費，B速度有了，C賺了錢。當C的節點在全國都有，很是多的時候。那麼你用C家的CDN加速服務，你就會大步流星了。

CDN工做流程

一個用戶訪問某個靜態文件（如CSS），這個靜態文件的域名假如是www.baidu.com，而這個域名最終會被指向CDN全局中CDN負載均衡服務器，再由這個負載均衡服務器來最終分配是哪一個地方的訪問用戶，返回給離這個訪問用戶最近的CDN節點。以後用戶就直接去這個CDN節點訪問這個靜態文件了，若是這個節點中請求的文件不存在，就會再回到源站去獲取這個文件，而後再返回給用戶。

代理

代理是一種有轉發功能的應用程序，它扮演了位於服務器和客戶端「中間人」的角色，接收由客戶端發送的請求並轉發給服務器，同時也接收服務器返回的響應並轉發給客戶端。代理服務器的基本行爲就是接收客戶端發送的請求後轉發給其餘服務器。代理不改變請求URI，會直接發送給前方持有資源的目標服務器。持有資源實體的服務器被稱爲源服務器。從源服務器返回的響應通過代理服務器後再傳給客戶端。

代理服務器種類

匿名代理：徹底「隱匿」了被代理的機器，外界看到的只是代理服務器；
透明代理：顧名思義，它在傳輸過程當中是「透明開放」的，外界既知道代理，也知道客戶端；
正向代理：靠近客戶端，表明客戶端向服務器發送請求；
反向代理：靠近服務器端，表明服務器響應客戶端的請求；

代理能夠作的事情

負載均衡：把訪問請求均勻分散到多臺機器，實現訪問集羣化；
內容緩存：暫存上下行的數據，減輕後端的壓力；
安全防禦：隱匿 IP, 使用 WAF 等工具抵禦網絡攻擊，保護被代理的機器；
數據處理：提供壓縮、加密等額外的功能。

網關

網關是轉發其餘服務器通訊數據的服務器，接收從客戶端發送來的請求時，它就像本身擁有資源的源服務器同樣對請求進行處理。有時客戶端可能都不會察覺，本身的通訊目標是一個網關。網關的工做機制和代理十分類似。而網關能使通訊線路上的服務器提供非HTTP協議服務。利用網關能提升通訊的安全性，由於能夠在客戶端與網關之間的通訊線路上加密以確保鏈接的安全。好比，網關能夠鏈接數據庫，使用SQL語句查詢數據。另外，在Web購物網站上進行信用卡結算時，網關能夠和信用卡結算系統聯動。

隧道

隧道是在相隔甚遠的客戶端和服務器二者之間進行中轉，並保持雙方通訊鏈接的應用程序。隧道可按要求創建起一條與其餘服務器的通訊線路，屆時使用SSL等加密手段進行通訊。隧道的目的是確保客戶端能與服務器進行安全的通訊。隧道自己不會去解析HTTP請求。也就是說，請求保持原樣中轉給以後的服務器。隧道會在通訊雙方斷開鏈接時結束。

HTTP請求方式

常見狀態碼

1××：提示信息，表示目前是協議處理的中間狀態，還須要後續的操做；
2××：成功，報文已經收到並被正確處理；
3××：重定向，資源位置發生變更，須要客戶端從新發送請求；
4××：客戶端錯誤，請求報文有誤，服務器沒法處理；
5××：服務器錯誤，服務器在處理請求時內部發生了錯誤。

狀態碼	含義
200 OK	表示從客戶端發來的請求在服務器端被正常處理了。
220 No Content	該狀態碼錶明服務器接收的請求已成功處理，但在返回的響應報文中不含實體的主體部分。
206 Partial Content	該狀態碼錶示客戶端進行了範圍請求，而服務器成功執行了這部分的GET請求。響應報文中包含由Content-Range指定範圍的實體內容。
301 Moved Permanently	永久性重定向。該狀態碼錶示請求的資源已被分配了新的URI，之後應使用資源如今所指的URI。也就是說，若是已經把資源對應的URI保存爲書籤了，這時應該按Location首部字段提示的URI從新保存。
302 Found	臨時性重定向。該狀態碼錶示請求的資源已被分配了新的URI，但願用戶（本次）能使用新的URI訪問。和301 狀態碼類似，但302狀態碼錶明的資源不是被永久移動，只是臨時性質的。換句話說，已移動的資源對應的URI未來還有可能發生改變。好比，用戶把URI保存成書籤，但不會像301狀態碼出現時那樣去更新書籤，而是仍舊保留返回302狀態碼的頁面對應的URI。
304 Not Modified	該狀態碼錶示客戶端發送附帶條件的請求[插圖]時，服務器端容許請求訪問資源，但因發生請求未知足條件的狀況後，直接返回304 Not Modified（服務器端資源未改變，可直接使用客戶端未過時的緩存）。304狀態碼返回時，不包含任何響應的主體部分。304雖然被劃分在3XX類別中，可是和重定向沒有關係
400 Bad Request	該狀態碼錶示請求報文中存在語法錯誤。當錯誤發生時，需修改請求的內容後再次發送請求。另外，瀏覽器會像200 OK同樣對待該狀態碼。
401 Unauthorized	該狀態碼錶示發送的請求須要有經過HTTP認證（BASIC認證、DIGEST認證）的認證信息。另外若以前已進行過1次請求，則表示用戶認證失敗。返回含有401的響應必須包含一個適用於被請求資源的WWW-Authenticate首部用以質詢（challenge）用戶信息。當瀏覽器初次接收到401響應，會彈出認證用的對話窗口。
403 Forbidden	該狀態碼代表對請求資源的訪問被服務器拒絕了。服務器端沒有必要給出拒絕的詳細理由，但若是想做說明的話，能夠在實體的主體部分對緣由進行描述，這樣就能讓用戶看到了。
404 Not Found	該狀態碼代表服務器上沒法找到請求的資源。除此以外，也能夠在服務器端拒絕請求且不想說明理由時使用。
500 Internal Server Error	該狀態碼代表服務器端在執行請求時發生了錯誤。也有多是Web應用存在的bug或某些臨時的故障。
503 Service Unavailable	該狀態碼代表服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。若是事先得知解除以上情況須要的時間，最好寫入Retry-After首部字段再返回給客戶端。

首部字段

首部字段名	說明
通用首部字段
Cache-Control	控制緩存的行爲
Connection	逐跳首部、鏈接的管理
Date	建立報文的日期時間
Pragma	報文指令
Trailer	報文末端的首部一覽
Transfer-Encoding	指定報文主體的傳輸編碼方式
Upgrade	升級爲其餘協議
Via	代理服務器的相關信息
Warning	錯誤通知
請求首部字段
Accept	用戶代理可處理的媒體類型
Accept-Charset	優先的字符集
Accept-Encoding	優先的內容編碼
Accept-Language	優先的語言（天然語言）
Authorization	Web認證信息
Expect	期待服務器的特定行爲
From	用戶的電子郵箱地址
Host	請求資源所在服務器
If-Match	比較實體標記（ETag)
If-Modified-Since	比較資源的更新時間
If-None-Match	比較實體標記（與lf-Match相反）
If-Range	資源未更新時發送實體Byte的範圍請求
If-Unmodified-Since	比較資源的更新時間（與lf-Modified-Since相反
Max-Forwards	最大傳輸逐跳數
Proxy-Authorization	代理服務器要求客戶端的認證信息
Range	實體的字節範圍請求
Referer	對請求中URI的原始獲取方
TE	傳輸編碼的優先級
User-Agent	HTTP客戶端程序的信息
響應首部字段
Accept-Ranges	是否接受字節範圍請求
Age	推算資源建立通過時間
ETag	資源的匹配信息
Location	令客戶端重定向至指定URI
Proxy-Authenticate	代理服務器對客戶端的認證信息
Retry-After	對再次發起請求的時機要求
Server	HTTP服務器的安裝信息
Vary	代理服務器緩存的管理信息
WWW-Authenticate	服務器對客戶端的認證信息
實體首部字段
Allow	資源可支持的HTTP方法
Content-Encoding	實體主體適用的編碼方式
Content-Language	實體主體的天然語言
Content-Length	實體主體的大小（單位：字節）
Content-Location	替代對應資源的URI
Content-MD5	實體主體的報文摘要
Content-Range	實體主體的位置範圍
Content-Type	實體主體的媒體類型
Expires	實體主體過時的日期時間
Last-Modified	資源的最後修改日期時間

瀏覽器緩存

緩存優勢

減小冗餘的數據傳輸
減小服務器的負擔，大大提高了網站的性能
加快了客戶端加載網頁的速度