HTTP應用場景

大家都知道，我們的瀏覽器跟后臺的交互協議，無論是看新聞，還是刷微博，逛貼吧，買買買，最常見的就是Http協議，不僅如此，我們很多的App與后臺的交互，也采用HTTP協議，為什么不采用其他協議呢？最主要的原因，是HTTP的相關技術棧已經非常成熟，使用起來也非常方便。

HTTP站在TCP的肩膀上

如果你學過網絡分層，就知道HTTP是屬于傳輸層協議，而TCP是屬于網絡層協議，HTTP是建立再TCP之上，所以很多HTTP的性能瓶頸與優化技巧都是與TCP息息相關。TCP在此之間充當了什么角色呢？舉個例子，網絡的場景是非常復雜的，可能你從一個機器上發送一個消息給另外一個機器，中間需要經過數十臺機器與設備，不可避免地就有可能會發送失敗，但發送失敗地時候，TCP就會負責重試，而它地老板"HTTP"就不關心這些了，他只關心我讓你干活，還有你最后的結果，至于中間的場景，那個是TCP干的事情。

HTTP的歷史

HTTP誕生于1991年，那個時候只有一個GET命令，瀏覽器跟服務器建立連接之后，服務器會向客戶端回應html格式的字符串，發送完畢后，就關閉中間的TCP連接，下次請求需要重新建立連接。

1996年HTTP/1.0版本發布，因為計算機與網絡技術的提高，人們上網不僅要看文字，還要看圖片，看視頻甚至是下載電腦應用，所以HTTP也隨之升級，支持了更多格式，為了支持這些格式，也引入了信息頭，用來描述數據與編碼等。

1997年HTTP/1.1發布，雖然是一個子版本，但是直到今天還是被廣泛的應用，主要是對HTTP/1.0做一些性能上面的優化，例如引入持久連接、引入管道機制，讓客戶端跟服務端的交互可以更加順暢。

2015年，HTTP/2發布，再一次提升了性能，并且減少了帶寬浪費，后面我們會進一步進行說明。

HTTP包結構

HTTP包主要分為3部分，第一部分是請求行，用來記錄使用什么方法，訪問了什么地址，接著是首部，用來描述包的數據類型、編碼格式、是否使用緩存等信息，最后才是實體，是具體的包內容。

一個HTTP請求的奇妙之旅

那么，一個HTTP請求時如何從客戶端到服務器，最后又回來的呢？當客戶端發起一次HTTP請求的時候，會把這些數據變成一個流交給TCP層，TCP又會加上源地址跟目標地址，然后交給IP層，最后交給數據鏈路層，穿過層層交換機與網關，最后到達服務器，服務器處理完之后，再重新返回給客戶端。

總結

好了，今天的HTTP的基礎介紹我們就講到這里，如果你有什么疑問或者建議，歡迎評論，歡迎大家關注我，共同學習，共同進步。大家的支持是我繼續嘮嗑的動力。同名公眾號（沙茶敏碎碎念）