http2 新特性

http2服務器推送

爲何須要服務器推送？
咱們開發一個WEB頁面，好比main.jsp,常常副帶一個main.js,main.css文件。現有的HTTP方式是，先請求main.jsp，而後返回瀏覽器，再解析，發現須要依賴main.js,main.css，後面再請求main.js,main.css，這是一個通用的流程。服務器推送就是用來簡化這一流程用的。
瀏覽器若是請求main.jsp的時候，若是有個請求頭，告訴服務器，我同時須要main.js,main.css，你同時把這兩個頁面也給我推送過來吧。這就是服務器推送。

http2報文頭壓縮

http1.1 只能壓縮報文體，沒法壓縮報文頭。報文頭壓縮有兩類，自定義的不說。另外一類是RFC定義好的,好比請求頭1表明get請求，2表明POST請求。這就是報文頭壓縮。

http2隊頭阻塞解決

上面兩個都很好理解，比較簡單，關鍵是這個報文頭阻塞。
相信百度上有好多講報文頭阻塞的文章，也講了http2的解決方案。關鍵是爲何這種分流分幀的方式能解決報文頭阻塞。
先說說爲何會有報文頭阻塞。
http1.0的時代，http每發一個請求就會關閉當前鏈接，再發請求，要從新建立鏈接。可是http1.0支持keep-alive。設置這參數後，不會當前鏈接。能夠對這個鏈接進行復用。
http1.1默認設置鏈接爲keep-alive。雖然能達到複用，可是若是頁面上依賴的資源很是多，而每一個鏈接是串行的，什麼意思了，就是發送請求前，必須先獲得上個請求的響應。就是請求1->響應1->請求2->響應2。按這種模式進行。有人就會說了，那我能夠併發呀，我建立多個鏈接。這樣就能夠同時發送請求1與請求2了。OK，這樣確實能夠，瀏覽器也是這麼幹的。通常給每一個域名下的最多同時建立6個請求。但這樣帶來的問題是，服務器原本併發600，支持600人，如今只能同時支持100人了。
http1.1管線技術。爲了解決單個鏈接只能串行的問題。出現管線技術。我容許瀏覽器在單個鏈接上發送多個請求，而不用等待響應。就是請求1->請求2->響應1->響應2。可是這種模式也有問題，若是響應1很慢，那就會阻塞響應2。這就是隊頭阻塞。那有人會說，響應1既然很慢，爲何不把響應2先返回了。這裏有個問題，是不能先返回響應2。若是我先給你響應2了，瀏覽器怎麼知道這個響應是對應請求2的了？若是想讓瀏覽器知道這個響應對應於某個請求，只能修改報文頭，那就得很涉及修改http協議了，這就是http2乾的活了。
http2是怎麼解決這個問題的了，將服文分幀，發送的內容變得更小了。相似於tcp。將整個報文分紅一個流,一個流裏面分紅若干個幀，好比報文頭幀，數據幀。這樣瀏覽器就能區分服務端返回的哪一個請求對應的響應了。