http1.1在應用層以純文字的形式進行通訊，每次通訊都要帶完整的http的頭，而且不考慮pipeli模式的化，每次的過程總是像上面描述的那樣一去一回。那樣在實時性、併發想上都存在問題
頭部壓縮：http2.0會對http的頭進行一定的壓縮，將原來每次都要攜帶的大量key value在兩端建立乙個索引表，對相同的頭只傳送索引表中的索引
http2.0協議將乙個tcp的連線中，切分成多個流。每個流都有自己的id，而且流可以是客戶端發服務端，也可以是服務端發客戶端，它其實只是乙個虛擬的通道。流是有優先順序的
http2.0還將所有的傳輸資訊分割為更小的資訊和幀，並對它們採用二進位制格式編碼。常見的幀有header幀，用於傳輸header內容，並且會開啟乙個新的流，再就是data幀，用來傳輸正文實體。多個data幀屬於乙個流
通過這兩種機制，http2.0的客戶端可以將對個請求不同的流中，然後將請求內容拆成幀，進行二進位制傳輸。這些真可以打散亂序傳送，然後根據每個幀首部的流識別符號重新組裝，並且可以根據優先順序，決定先處理那個流的資料
二進位制傳輸就是以上
例子：假設乙個頁面要傳送三個獨立的請求，乙個獲取css，乙個獲取js，乙個獲取jpg。如果使用http1.1就是序列的，但是如果使用http2.0，就可以在乙個連線裡，客戶端和服務端都可以同時傳送多個請求或回應，而且不用按照順序一對一對應
http2.0成功解決了http1.1的隊首阻塞問題，同時，也不需要通過http1.x的pipeline機制用多條tcp連線來實現並行請求和響應；減少了tcp連線數對伺服器效能的影響，同時將頁面的多個資料css，js，jpg等通過乙個資料鏈結進行傳輸，能夠加快頁面元件的傳輸速度。
http2.0 也是基於tcp協議的，tcp協議在處理包時是有嚴格順序的
當其中乙個資料報遇到問題，tcp連線需要等待找個包完成重傳之後才能繼續進行，雖然http2.0通過多個stream，使得邏輯上乙個tcp連線上的並行內容，進行多路資料的傳輸，然而這中間沒有關聯的資料，一前一後，前面stream2的幀沒有收到，後面stream1的幀也會因此堵塞
於是google的 quic協議從tcp切換到udp
在tcp是沒有辦法的，但是基於udp，就可以在quic自己的邏輯裡面維護連線的機制，不再以四元組標識，而是以乙個64
位的隨機數作為id來標識，而且udp是無連線的，所以當ip或者埠變化的時候，只要id不變，就不需要重新建立連線
任何乙個序號的包發過去，都要在一定的時間內得到應答，否則一旦超時，就會重發這個序號的包，通過自適應重傳演算法（通過取樣往返時間rtt不斷調整）
但是，在tcp裡面超時的取樣存在不準確的問題。例如傳送乙個包，序號100，發現沒有返回，於是在傳送乙個100，過一陣返回ack101.客戶端收到了，但是往返的時間是多少，沒法計算。是ack到達的時候減去第一還是第二。
quic也有個序列號，是遞增的，任何宇哥序列號的包只傳送一次，下次就要加1，那樣就計算可以準確了
但是有乙個問題，就是怎麼知道包100和包101傳送的是同樣的內容呢？quic定義了乙個offset概念。quic既然是面向連線的，也就像tcp一樣，是乙個資料流，傳送的資料在這個資料流裡面有個偏移量offset，可以通過offset檢視資料傳送到了那裡，這樣只有這個offset的包沒有來，就要重發。如果來了，按照offset拼接，還是能夠拼成乙個流。
有了自定義的連線和重傳機制，就可以解決上面http2.0的多路復用問題
同http2.0一樣，同一條 quic連線上可以建立多個stream，來傳送多個http請求，但是，quic是基於udp的，乙個連線上的多個stream之間沒有依賴。這樣，假如stream2丟了乙個udp包，後面跟著stream3的乙個udp包，雖然stream2的那個包需要重新傳，但是stream3的包無需等待，就可以發給使用者。
tcp的流量控制是通過滑動視窗協議。quic的流量控制也是通過window_update，來告訴對端它可以接受的位元組數。但是quic的視窗是適應自己的多路復用機制的，不但在乙個連線上控制視窗，還在乙個連線中的每個steam控制視窗。
在tcp協議中，接收端的視窗的起始點是下乙個要接收並且ack的包，即便後來的包都到了，放在快取裡面，視窗也不能右移，因為tcp的ack機制是基於序列號的累計應答，一旦ack了乙個序列號，就說明前面的都到了，所以是要前面的沒到，後面的到了也不能ack,就會導致後面的到了，也有可能超時重傳，浪費頻寬
quic的ack是基於offset的，每個offset的包來了，進了快取，就可以應答，應答後就不會重發，中間的空檔會等待到來或者重發，而視窗的起始位置為當前收到的最大offset，從這個offset到當前的stream所能容納的最大快取，是真正的視窗的大小，顯然，那樣更加準確。
HTTP快取的工作原理和實現機制
流程如下圖所示 基於http協議的http快取是通過在請求頭和響應頭中設定相應的字段值來實現的。expires欄位的值為伺服器返回的快取資源的到期時間 絕對時間 即下一次請求時間小於服務端返回的到期時間，直接使用快取資料。expires是http 1.0的東西，現在瀏覽器預設使用http 1.1，所...
Http的內容編碼機制
http報文分為報文首部和報文主體 請求報文首部包括請求行 包括方法,url和客戶端的http協議的版本 請求首部字段 通用首部字段 實體首部字段。響應報文首部包括狀態行 http版本和狀態碼 響應首部字段 通用首部字段 實體首部字段。在請求首部欄位中有accept encoding為優先的內容編碼...
PHP的HTTP認證機制
php的http認證機制因此該功能不適用於 cgi 版本。在 apache 模組的 php 指令碼中，可以用 header 函式來向客戶端瀏覽器傳送authentication required資訊，使其彈出乙個使用者名稱 密碼輸入視窗。當使用者輸入使用者名稱和密碼後，包含有 url 的 php 指...