前段時間看了《御賜小仵作》，里面有很多細節很有心，看了一些評論都是：終于在劇里能夠看到真正在搞事業、發了工資第一時間還錢的正常人了，我印象比較深的是王府才能吃上的葡萄，覺得非常合理，劇里說的明明白白，是唐朝中晚期唐宣宗的時候，那時候絲綢之路剛剛開通，西域（現在的新疆以及更西的地方）的葡萄終于能吃上了，這就和那一整段歷史給對應上了，
談到對應的問題，咱們回到正題，http狀態碼1XX，對于http狀態200、404、500，大家可能熟悉一些，1XX可能實際中從來沒有見過，今天咱們用剝洋蔥的敘述方式，撥開1XX狀態碼的層層面紗，
定義
HTTP狀態碼（英語：HTTP Status Code）是用以表示網頁服務器超文本傳輸協議回應狀態的3位數字代碼，這句話要注意解讀了，我先來考考大家讀懂了沒，請回答：
這里我先不回答，無法決定的朋友再多讀幾遍定義，
狀態碼1XX表示服務端已經收到了請求，但是還需要進一步處理，
白居易有一首《問劉十九》：
綠蟻新醅酒，紅泥小火爐，
晚來天欲雪，能飲一杯無？
這就和服務端可能會回傳1XX的場景很像，客戶端發起一個請求：我這里有美酒和暖爐，天要下雪了，來喝一杯？服務端收到之后回傳1XX，代表接受邀請，這時候客戶端就可以真正擺上一桌酒菜迎接客人了，如果服務端回傳4XX，客戶端也不用消耗資源殺雞做菜了，
1xx狀態碼是 HTTP/1.1 版本新定義的，用來表示請求被正常接收，會進行進一步處理，這些狀態碼相對較新，并且 HTTP/1.0 版本無法識別，所以原則上不應該向HTTP/1.0版本的客戶端發送任何1xx狀態碼，
100 Continue
該狀態碼說明服務器收到了請求的初始部分，并請客戶端繼續發送，在服務器發送了 100 Continue 狀態碼之后，如果收到客戶端的請求，則必須進行回應，
這個狀態碼實際上是對如下場景的一種優化：客戶端有一個較大的檔案需要上傳并保存，但是客戶端不知道服務器是否愿意接受這個檔案，所以希望在消耗網路資源進行傳輸之前，先詢問一下服務器的意愿，實際操作為客戶端發送一條特殊的請求報文，報文的頭部應包含
Expect: 100-continue
此時，如果服務器愿意接受，就會回傳 100 Continue 狀態碼，反之則回傳 417 Expectation Failed 狀態碼，對于客戶端而言，如果客戶端沒有發送實際請求的打算，則不應該發送包含 100 Continue Expect 的報文，因為這樣會讓服務器誤以為客戶端將要發送一個請求，大家可以基于對100的理解再回想一下《問劉十九》，
之前提到過，并不是所有的HTTP應用都支持 100 Continue 這個狀態碼（例如HTTP/1.0及之前的版本的代理或服務器）所以客戶端不應該在發送 100 Continue Expect 后一直等待服務器的回應，在一定時間后，客戶端應當直接發送計劃發送的內容，
而對于服務器而言，也不應當把 100 Continue 當作一個嚴格的判斷方法，服務器有可能在發送回應之前就收到了客戶端發來的主體報文，此時服務器就不需要再發送 100 Continue 作為回應了，但仍然需要在接受完成后回傳適當的狀態碼，理論上，當服務器收到一個 100 Continue Expect 請求時，應當進行回應，但服務器永遠也不應向沒有發送 100 Continue Expect 請求的客戶端發送100 Continue 狀態碼作為回應，這里提到的應當進行回應是指：假設服務器不打算接收客戶端將要發送的主體報文，也應當做適當的回應（例如發送 417 Expectation Failed）而不是單純的關閉連接，這樣會對客戶端在網路層面上產生影響，
作為代理的HTTP應用在收到帶有 100 Continue Expect 的請求時，需要進行額外的判斷，假設代理服務器明確知道報文下游的HTTP版本是兼容 HTTP/1.1 的，或者代理服務器不知道報文下游的版本，它都應當轉發這條 100 Continue Expect 請求，但是如果代理服務器明確知道報文下游的應用無法處理 100 Continue Expect 的話，則應當直接向客戶端回傳 417 Expectation Failed 作為回應，而這也并非唯一的解決辦法，另一種可行的辦法是直接向客戶端回傳 100 Continue ，然后向下游傳遞洗掉了 100 Continue Expect 的報文，
另外，如果代理服務器決定為 HTTP/1.0 及之前的版本服務的話，那么當它收到來自服務器的 100 Continue 回應報文時，則不應當向客戶端轉發這條回應，因為客戶端很可能不知道如何處理該報文，
101 Switching Protocols
HTTP 101 Switching Protocol（協議切換）狀態碼表示服務器應客戶端升級協議的請求對協議進行切換，
此機制始終由客戶端發起，并且服務器可能接受或拒絕切換到新協議，客戶端可使用常用的協議（如HTTP / 1.1）發起請求，請求說明需要切換到HTTP / 2或甚至到WebSocket，
我們來看一個實際的例子:
為了實作WebSocket通信，首先需要客戶端發起一次普通HTTP請求，也就是說，WebSocket的建立是依賴HTTP的，
其中HTTP頭部欄位Upgrade: websocket和Connection: Upgrade非常重要，告訴服務器通信協議將發生改變，轉為WebSocket協議，支持WebSocket的服務器端在確認以上請求后，應回傳狀態碼為101 Switching Protocols的回應:
其中欄位Sec-WebSocket-Accept是由服務器對前面客戶端發送的Sec-WebSocket-Key進行確認和加密后的結果，相當于一次驗證，以幫助客戶端確信對方是真實可用的WebSocket服務器，
驗證通過后，這個握手回應就確立了WebSocket連接，此后，服務器端就可以主動發資訊給客戶端了，此時的狀態比較像服務器端和客戶端接通了電話，無論是誰有什么資訊想告訴對方，開口就好了，
一旦建立了WebSocket連接，此后的通信就不再使用HTTP了，改為使用WebSocket獨立的資料幀，
102 Processing
102 Processing是由WebDAV（RFC 2518）擴展的狀態碼，代表處理將被繼續執行，
Web服務器可能需要相當長的時間來處理復雜的請求，當客戶端的瀏覽器發送包含多個涉及復雜需求的子請求的WebDAV請求時，服務器需要一些時間來處理并發送此代碼“102–Processing”，此代碼旨在通過通知客戶端服務器收到請求并對其進行處理來避免客戶端出現超時錯誤，
總結
HTTP狀態碼的設計規則是：前面一位是分類，2XX表示服務端已經收到了請求，并且已經分析處理完；3XX表示服務端已經收到了請求，但是還需要其他資源或者服務處理；4XX表示服務端已經收到了請求，但是無法理解，說明客戶端請求姿勢不正確；5XX表示服務端已經收到了請求，但是由于服務端自身問題無法正確回應，
這種編碼方法在很多地方都在用，
比如身份證號規則
前1、2位數字表示：所在省（直轄市、自治區）的代碼；第3、4位數字表示：所在地級市（自治州）的代碼；第5、6位數字表示：所在區（縣、自治縣、縣級市）的代碼；第7—14位數字表示：出生年、月、日；第15、16位數字表示：所在地的派出所的代碼；第17位數字表示性別：奇數表示男性，偶數表示女性；第18位數字是校檢碼，
比如行別代碼
支付系統為每類參與者分配一個標識號，由三位數字組成，第一位是銀行型別，剩下兩位是標識號，
支付系統的參與者行號規則和身份證規則很像，除了每幾位都有特殊含義，結尾一位也是驗證碼，反正參與者行號規則我是記下來了，默念了8遍記下來的，真不容易，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/423143.html
標籤：架構設計