HTTP2.0有什麼新特性？
- 頭部壓縮：以往的http請求頭部都是用文本進行書寫的，那這個很明顯是一個可以優化的點嘛。所以HTTP2.0就用一個叫做HPACK的算法進行了壓縮。其實很簡單，就是在客戶端和服務端中維護一個類似於HashMap的結構，那每次進行傳輸的時候，請求頭部的字段使用key進行標註，那麼比直接傳輸文本肯定是更快的。
- 幀：HTTP之前的版本都是將報文進行完整的傳輸，而在2.0的版本里面，實際上它會把報文分割爲多個幀，然後再使用二進制進行編碼之後傳輸。一般來說一個報文會被分爲一個Header幀，對應的是請求頭，還有多個Data幀，對應的是請求體的數據。其實2.0它把報文進行分幀數，實際上是實現多路複用的基礎。
- 多路複用的功能：在之前的版本，HTTP是單路的，也就是說一個TCP連接一次只能接受一個HTTP請求，那麼這樣就會導致一個隊列阻塞的問題，也就是說其他請求必須等待這個請求被處理了，它才能通過同一個TCP連接進行傳輸。雖然說HTTP1.1的版本里面有管線化的機制，就是一次可以發送多個請求，但是對於單個TCP連接來說，它依舊是串行化的。並且現在的瀏覽器其實都不止是一個連接，比如說Chrome瀏覽器可以達到6個連接。但是本質上依然是單路的。那2.0的版本就有了多路複用的功能了，它是基於分幀的機制去實現。也就是說多個HTTP請求可以同時在TCP連接中傳輸自己的幀，然後在接受端進行統一的組裝，這樣就實現了多路複用的模型。
- 服務端推送：服務端推送就是說，服務端它不需要等待客戶端主動請求，就可以直接發給客戶端。比如說客戶端它請求web應用程序，這可能涉及到非常多的資源，以往的情況就是客戶端需要主動地去請求這些資源。但在2.0的版本里面，服務端就知道這些資源是相關的，那麼它就會把這些資源主動發送給客戶端，從而提升效率。
TCP的全連接隊列和半連接隊列
對於TCP三次握手的時候，對於服務端來說就有兩個隊列，一個是全連接隊列一個是半連接隊列。
- 半連接隊列：發生第一次握手的時候，服務端除了會發送確認報文，還會把這個請求加入到半連接隊列之中。
- 全連接隊列：雙方正式連接的時候，服務端就會把它加入到全連接隊列裏面
半連接隊列其實是DDos攻擊的一個點，因爲有可能製造大量的虛假的連接請求，造成半連接隊列爆滿
TCP握手的過程中是否允許傳輸數據？
前兩次握手不允許，第三次握手是允許的，因爲在發起第三握手的時候，客戶端已經處於established狀態了
另外其實TCP還有一個機制叫做快速打開，在這個機制下面其實在第一次第二次握手的時候也是可以進行數據傳輸。
快速打開機制：客戶端和服務端在進行第一次連接的時候，服務端會將一個類似於cookie的東西放到TCP報文的fast-open選項上，發送給客戶端，客戶端會保存下來。下次進行連接的時候，客戶端在第一次握手的時候，會把這個類似於cookie的東西給帶上，並且可以直接發送數據，比如說直接發送http報文。服務端接收到，然後對這個cookie進行檢驗，如果檢驗通過的話，服務端在發送第二次握手的時候，也可以發送http報文。所以在這種情況下，是可以傳輸數據的
GET和POST的區別：
耳熟能詳的有幾個：
- 功能不一樣，GET請求一般用來請求資源，而POST一般用來向服務端發送資源
- 參數的問題上，GET請求的參數會拼接到URL上，而POST請求的參數會放在報文請求體上，相對來說更加安全。而GET請求它的參數拼接URL上，而瀏覽器對URL的長度是有限制的，所有GET請求的數據量會比POST更小
- 編碼的區別，GET請求只能使用ASCLL編碼，所以使用中文會有亂碼的問題，而POST是沒有這個問題
還有一個剛知道的點：
- 與TCP相關的一個點：GET請求會把請求報文一次性發送出去，而POST請求，它先發送請求頭，等服務端響應一個100，然後再把請求體給發送過去