IOS —— 網路那些事(上) - http協議
作為一名並不太合格的程式設計師,今天要分享學習的成果,竟然講的是網路相關HTTP協議的事情。(也算是複習了)
乍看HTTP協議的內容著實是十分複雜的,涉及到十分多網際網路"底層"框架的東西。今天就先撇開這部分詳細內容。
簡單的來說說HTTP協議,以及連線的事項。
HTTP協議發展至今也有二十多年曆史,版本也從原來的1.0 進化到了2.0
那麼還是一如既往,圖文理解比較簡單。
以下圖片以"下單"表示客戶端向伺服器端傳送資料
以"發貨"表示伺服器端對客戶端的迴應
"商家"表示伺服器端(server) , "買家"表示客戶端(user)
HTTP協議1.0版
在解釋這張圖的含義之前,引用百度百科的一段話解釋下 HTTP協議
HTTP協議:
HTTP協議(HyperText Transfer Protocol,超文字傳輸協議)是用於從WWW伺服器傳輸超文字到本地瀏覽器的傳輸協議。它可以使瀏覽器更加高效,使網路傳輸減少。它不僅保證計算機正確快速地傳輸超文字文件,還確定傳輸文件中的哪一部分,以及哪部分內容首先顯示(如文字先於圖形)等。 HTTP是客戶端瀏覽器或其他程式與 Web服務器之間的應用層通訊協議。在Internet上的Web伺服器上存放的都是超文字資訊,客戶機需要通過HTTP協議傳輸所要訪問的超文字資訊。HTTP包含命令和傳輸資訊,不僅可用於Web訪問,也可以用於其他因特網/內聯網應用系統之間的通訊,從而實現各類應用資源超媒體訪問的整合。
仔細閱讀完會發現,HTTP協議的作用和開篇時,我所描述的一樣。
你可以將買外賣的這件事情代入進來,傳輸協議實際上也可以當做是"下單"的過程。
在1996年的第一版HTTP協議中(以下統稱http1.0),可以看到的整個"外賣"系統已經成型。
已經具備"下單"以及"發貨"的能力,但是有所不足的是使用者並不能同一時間,點複數的餐。
http1.0是無法複用連線的。一次傳輸對應的是一次返回,並且直接關閉這個傳輸鏈。
你只能下一張單了,商家迴應並且發一份貨物了。這次買賣就結束了!
你並不同時在一次購買中同時和商家說我這次要買三份外賣!
那麼這樣方便嗎?我要買三份外賣還必須撥打三次電話下三次單才能完成呢
很遺憾的是http1.0中,只能夠這麼處理事情。
於是乎這些問題就留到了第二版HTTP協議中解決,他也就這麼誕生了(以下統稱http1.1)
HTTP協議1.1版
在http1.1中加入了倆個新指令
1. Connection :keep-ALive :讓客戶端和伺服器之間的聯絡保持一段時間。(再也不需要重新撥打電話才能下第二張單了)
2. HttpPipelining:同時建立多個連線。(並且不用以一張一張訂單的形式告訴商家,直接說我要買三份青菜!)
可以看到的是http1.1中,1.0所遇到的問題已經基本上解決了。
這麼仔細一想,問題都解決了。為什麼還有2.0版本的出現呢
因為http1.1中只有單一執行緒處理工作,任務耗時較重的情況下,當前執行緒會堵塞其中。並且使得後續執行緒也只能跟著堵塞。
遇到伺服器未響應的情況下,執行緒將會直接卡死在那造成 "線頭阻塞"
意思就是商家只有一個廚子,廚子炒菜炒不過來的情況下。後續訂單出貨量就慢了。但是!雖然炒菜慢但是還是能發貨
當廚子突然消失的情況下,訂單就出不了貨了。這個發貨流程就直接卡死了。
回過頭來,當問題出現的時候。首先就得尋求解決方法。
那麼http協議的第三版就出現了。
HTTP協議2.0版
乍看之下,好像還真的有點不一樣啊。相比起第二版HTTP協議來說
感覺第三版HTTP(以下統稱http2.0)像似"暴富"一般,手頭闊了,人也多了。
是的沒錯,http2.0連線中執行緒可以併發的執行任務了。並不會像前者http1.1一樣遇到單一執行緒堵塞或未響應時的延緩或者卡死整條連線鏈路,先執行便迴應。
結合http1.1舉得例子來說
廚子多了,並且不用對應使用者1的三份外賣,同時做好同時發。在同一個訂單裡,先做好哪份就發哪份。
如果遇到某客戶的訂單中的某一份外賣要求比較多(加蔥加辣加泡菜等等等)延緩出單的情況,也只是該訂單出單慢。影響不了其他倆單的出貨。
所以也就就把HTTP協議中大部位問題給解決了。
文章總結:
HTTP協議可以引用這麼一句話 "一就是全,全就是一"。
當一卡住了,全也就卡住了。當全部東西解決完了,一條協議連線也就完成了。~
讀這篇文章的時候估計很多人也有很多疑惑吧
還有很多謎團沒揭曉呢,連線又是啥,網路請求這麼複雜的嗎?
是的,網路這塊特別複雜,今天說的這三個版本連冰山一角上的冰塊都沒摸著。
接下來我還要繼續對連線這塊,以自己的理解解刨一下。
下期講的是TCP協議白話版理解(專業角度剖析對俺來說是有點難)
end