<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ??一站式輕松地調用各大LLM模型接口,支持GPT4、智譜、豆包、星火、月之暗面及文生圖、文生視頻 廣告
                [TOC] ## 簡介 HTTP1.0最早在網頁中使用是在1996年,那個時候只是使用一些較為簡單的網頁上和網絡請求上,而HTTP1.1則在1999年才開始廣泛應用于現在的各大瀏覽器網絡請求中,同時HTTP1.1也是當前使用最為廣泛的HTTP協議。 主要區別主要體現在: 1. **緩存處理**,在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標準,HTTP1.1則引入了更多的緩存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。 2. 帶寬優化及網絡連接的使用,HTTP1.0中,存在一些浪費帶寬的現象,例如客戶端只是需要某個對象的一部分,而服務器卻將整個對象送過來了,并且不支持斷點續傳功能,HTTP1.1則在請求頭引入了**range頭域**,它允許只請求資源的某個部分,即返回碼是206(Partial Content),這樣就方便了開發者自由的選擇以便于充分利用帶寬和連接。 3. 錯誤通知的管理,在HTTP1.1中新增了24個錯誤狀態響應碼,如409(Conflict)表示請求的資源與資源的當前狀態發生沖突;410(Gone)表示服務器上的某個資源被永久性的刪除。 4. Host頭處理,在HTTP1.0中認為每臺服務器都綁定一個唯一的IP地址,因此,請求消息中的URL并沒有傳遞主機名(hostname)。但隨著虛擬主機技術的發展,在一臺物理服務器上可以存在多個虛擬主機(Multi-homed Web Servers),并且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持**Host頭域**,且請求消息中如果沒有Host頭域會報告一個錯誤(400 Bad Request)。 5. **長連接,**HTTP 1.1支持長連接(PersistentConnection)和請求的流水線(Pipelining)處理,在一個TCP連接上可以傳送多個HTTP請求和響應,減少了建立和關閉連接的消耗和延遲,在HTTP1.1中默認開啟**Connection: keep-alive**,一定程度上彌補了HTTP1.0每次請求都要創建連接的缺點。 ## 緩存 ### 強制緩存(不對比緩存)與 對比緩存 **強制緩存:本地有就不對比 對比緩存,每次都對比** 已存在緩存數據時,僅基于強制緩存,請求數據流程如下: ![](https://img.kancloud.cn/4f/f1/4ff1cfe8a793e8f28e3e2e074fd0f76c_865x332.png) 已存在緩存數據時,僅基于對比緩存,請求數據的流程如下: ![](https://img.kancloud.cn/5c/af/5caffa661024bbec05d1b331f30b9afb_947x340.png) **緩存規則是包含在響應header里面的** 具體步驟如下: ![](https://img.kancloud.cn/3f/d1/3fd1de23dd0c28df7d9929e7d79f3410_554x528.png) ### expires 在HTTP/1.0中expires的值圍服務器端返回的到期時間,即下一次請求時,請求時間小于服務器返回的到期時間,直接使用緩存數據,這里面有個問題,由于到期時間是服務器生成的,但是客戶端的時間可能和服務器有誤差,所以這就會導致誤差,**所以到了HTTP1.1基本上不適用expires了,使用Cache-Control替代了expires** ### Cache-Control Cache-Control 是最重要的規則。常見的取值有private、public、no-cache、max-age、no-store、默認是private。 響應頭部意義Cache-Control:public響應被共有緩存,移動端無用Cache-Control:private響應被私有緩存,移動端無用Cache-Control:no-cache不緩存Cache-Control:no-store不緩存Cache-Control:max-age=6060秒之后緩存過期 舉個例子。入下圖: ![](https://img.kancloud.cn/c9/18/c918440482c3b5d11f9a23f7279df031_326x151.png) 圖中Cache-Control僅指定了max-age所以默認是private。緩存時間是31536000,也就是說365內的再次請求這條數據,都會直接獲取緩存數據庫中的數據,直接使用。 ### Last-Modified/If-Modified-Since 第一次請求時,服務器返回資源的**最后修改時間**,后面請求是帶上最后修改時間。 對比緩存,顧名思義,需要進行比較判斷是否可以使用緩存,客戶端第一次發起請求時,服務器會將緩存標志和數據一起返回給客戶端,客戶端當二者緩存至緩存數據庫中。再次其你去數據時,客戶端將備份的緩存標志發送給服務器,服務器根據標志來進行判斷,判斷成功后,返回304狀態碼,通知客戶端比較成功,可以使用緩存數據。 #### Last-Modified 是通過Last-Modified/If-Modified-Since來實現的,服務器在響應請求時,告訴瀏覽器資源的最后修改時間。 ![](https://img.kancloud.cn/15/f1/15f1d6b06978b5603077e17d848544ec_591x221.png) #### If-Modified-Since 再次請求服務器時,通過此字段通知服務器上次請求時,服務器返回最遠的最后修改時間。服務器收到請求后發現有If-Modified-Since則與被請求資源的最后修改時間進行對比。若資源的最后修改時間大于If-Modified-Since,說明資源又被改動過,則響應整個內容,返回狀態碼是200.如果資源的最后修改時間小于或者等于If-Modified-Since,說明資源沒有修改,則響應狀態碼為304,告訴客戶端繼續使用cache. ![](https://img.kancloud.cn/f6/46/f646fc3b4381dd2b2bfe0fe966f84ab6_597x247.png) ### ETag/If-None-Match(優先級高于Last-Modified/If-Modified-Since) 第一次請求時,服務器返回資源的**唯一標記位**,后面請求是帶上最后修改時間。 #### Etag 服務響應請求時,告訴客戶端當前資源在服務器的唯一標識(生成規則由服務器決定) ![](https://img.kancloud.cn/3d/e2/3de2deb149d64a6464ab32af94dede1b_592x219.png) #### If-None-Match 再次請求服務器時,通過此字段通知服務器客戶端緩存數據的唯一標識。服務器收到請求后發現有頭部If-None-Match則與被請求的資源的唯一標識進行對比,不同則說明資源被改過,則響應整個內容,返回狀態碼是200,相同則說明資源沒有被改動過,則響應狀態碼304,告知客戶端可以使用緩存 ![](https://img.kancloud.cn/3e/11/3e113993ce57cef9b9a8bf398f8d5e86_592x228.png) ### Range 如果服務器能夠正常響應的話,服務器會返回?206 Partial Content?的狀態碼及說明. 如果不能處理這種Range的話,就會返回整個資源以及響應狀態碼為?200 OK?.(這個要注意,要分段下載時,要先判斷這個) 響應頭就是?HTTP/1.1 206 Partial Content #### 請求頭格式 > Range: bytes=start-end 例如: > Range: bytes=10- :第10個字節及最后個字節的數據 > Range: bytes=40-100 :第40個字節到第100個字節之間的數據. 注意,這個表示\[start,end\],即是包含請求頭的start及end字節的,所以,下一個請求,應該是上一個請求的\[end+1, nextEnd\] #### 響應頭 * Content-Range ~~~ Content-Range: bytes 0-10/3103 ~~~ 這個表示,服務器響應了前(0-10)個字節的數據,該資源一共有(3103)個字節大小。 * Content-Type ~~~ Content-Type: image/png ~~~ 表示這個資源的類型 * Content-Length ~~~ Content-Length: 11 ~~~ 表示這次服務器響應了11個字節的數據(0-10) ## Keep-Alive [http協議里的keep-alive](https://www.jianshu.com/p/347416aafd3f) [HTTP/1.1 持久連接](https://blog.csdn.net/duan15378766962/article/details/81073050) 我的理解: 1. http1.1協議里增加了 keepalive的支持, 并且默認開啟 2. http1.1開啟keepalive后,可以做到一個tcp上可以完成一個http請求后不會立刻關閉,而是存活一段時間。 3. 在這個時間內,有其他http請求也可以使用這個tcp連接,(但每次只有一個) 4. http2.0才真正做到了多個請求在一個tcp里并發。(每個請求分配一個requestID) ## 參考資料 [OKHttp源碼解析(七)--中階之緩存機制](https://www.jianshu.com/p/a68dc1ca6120) [一文讀懂http緩存](https://www.jianshu.com/p/227cee9c8d15)
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看