摘要:有了多路復用之后,在同一個交易渠道上,能夠同時完成客戶所有訂單貨物的采購和交付,客戶端只要在每個訂單上備注好,貨物拆分發(fā)貨,亂序到達之后按照重新組裝即可,不會因為某個包裹的延誤導致整體配送進度的推遲。
1。 我們認識http 協(xié)議,從最初的,客戶端與服務器進行通訊,基于連接發(fā)生的請求與響應
在HTTP1.0時代,連接無法復用,每次下完單,都被強制登出/關機,下一次下單,就得重新登錄。
為了解決http1.0的單鏈接,http1.1 又提出了 保持鏈接設置Connection:Keep-Alive
http1.1 默認開啟了keep-alive,但是在keep-alive的背景下,必須等到請求1完成之后,再繼續(xù)處理2,3,這樣的方式很浪費時間,于是又提出了 HTTPpipelining 不用等到請求1 完成,就可以直接繼續(xù)2,3,4
只可惜服務器是按照順序處理的,如果服務1,沒有響應,那么2,3,4 服務就需要原地等待,只有等到1處理完成之后,才能處理后面2,3,4.為了解決這個問題,服務器需要增加好幾個通道,建立多個鏈接,就算其中一個請求堵塞了,也不會影響其他的。
但是這樣也不能解決問題 比如建立多個鏈接,鏈接數(shù)目有限,每換一個服務鏈接,就得從新TCP 三次握手,容易造成服務斷開,隨著服務的增加,訂單也只能按照先進先出的順序來排隊,但是堵塞依舊很嚴重。所以這里創(chuàng)造了SPDY協(xié)議,后續(xù)在此基礎上,又起草了 http2.0協(xié)議
由上,HTTP/1.1相較于 HTTP/1.0 協(xié)議的區(qū)別主要體現(xiàn)在:
1 緩存處理
2 帶寬優(yōu)化及網(wǎng)絡連接的使用
3 錯誤通知的管理
4 消息在網(wǎng)絡中的發(fā)送
5 互聯(lián)網(wǎng)地址的維護
6 安全性及完整性
常用的請求方式
GET 請求獲取Request-URI所標識的資源
POST 在Request-URI所標識的資源后附加新的數(shù)據(jù)
HEAD 請求獲取由Request-URI所標識的資源的響應消息報頭
PUT 請求服務器存儲一個資源,并用Request-URI作為其標識
DELETE 請求服務器刪除Request-URI所標識的資源
TRACE 請求服務器回送收到的請求信息,主要用于測試或診斷
CONNECT 保留將來使用
OPTIONS 請求查詢服務器的性能,或者查詢與資源相關的選項和需求
GET方法:在瀏覽器的地址欄中輸入網(wǎng)址的方式訪問網(wǎng)頁時,瀏覽器采用GET方法向服務器獲取資源,POST方法要求被請求服務器接受附在請求后面的數(shù)據(jù),常用于提交表單。GET是用于獲取數(shù)據(jù)的,POST一般用于將數(shù)據(jù)發(fā)給服務器之用。
HTTP 1.1狀態(tài)代碼及其含義
狀態(tài)代碼有三位數(shù)字組成,第一個數(shù)字定義了響應的類別,且有五種可能取值:
1xx:指示信息--表示請求已接收,繼續(xù)處理
2xx:成功--表示請求已被成功接收、理解、接受
3xx:重定向--要完成請求必須進行更進一步的操作
4xx:客戶端錯誤--請求有語法錯誤或請求無法實現(xiàn)
5xx:服務器端錯誤--服務器未能實現(xiàn)合法的請求
2. 多路復用多路復用,即單個鏈接同時進行多個業(yè)務單元數(shù)據(jù)的傳輸。
有了多路復用之后,在同一個交易渠道上,能夠同時完成客戶所有訂單貨物的采購和交付,客戶端只要在每個訂單上備注好ID,貨物拆分發(fā)貨,亂序到達之后按照ID重新組裝即可,不會因為某個包裹的延誤導致整體配送進度的推遲。 簡而言之 就是打包服務
請求優(yōu)先級
-假如訂單2的商品特別重要,就在訂單2上留一段備注,服務端收到訂單之后,會優(yōu)先發(fā)出訂單2的包裹。
同時,服務端評估訂單5是短保產(chǎn)品,需要盡快到貨,也會將訂單5優(yōu)先發(fā)貨。
頭部壓縮
HTTP1.X的頭部越來越膨脹,很多都是重復且多余的,HTTP2.0可以壓縮頭部的大小,并且避免了重復的傳輸,可以大大降低延遲。
就好比貨物越輕,運送速度則越快,HTTP2.0協(xié)議下,賣家發(fā)貨時將多余包裝扔掉,這樣買家就能更快地收到貨啦!
服務端推送 就是預定
服務端推送是HTTP2.0的一大亮點。
在客戶端下了訂單1之后,服務端預先判斷客戶端可能會需要下訂單2、3、4……于是主動發(fā)貨。這種主動推送的機制,可以節(jié)省接下來的幾個請求耗時,提升訪問速度。
科普完畢的分割線
有了HTTP2.0之后,賣家(網(wǎng)站)能夠更快地將內容呈現(xiàn)給買家(用戶)。
參考原文地址
文章版權歸作者所有,未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/52611.html
摘要:所以今天,就和大家一起聊一聊前端的安全那些事兒。我們就聊一聊前端工程師們需要注意的那些安全知識。殊不知,這不僅僅是違反了的標準而已,也同樣會被黑客所利用。 歡迎大家收看聊一聊系列,這一套系列文章,可以幫助前端工程師們了解前端的方方面面(不僅僅是代碼):https://segmentfault.com/blog... 隨著互聯(lián)網(wǎng)的發(fā)達,各種WEB應用也變得越來越復雜,滿足了用戶的各種需求...
摘要:靈活允許傳輸任意類型的數(shù)據(jù)對象。無連接每次響應一個請求,響應完成以后就斷開連接。無狀態(tài)服務器不保存瀏覽器的任何信息。每次提交的請求之間沒有關聯(lián)。非流水線發(fā)出一個報文,等到響應,再發(fā)下一個報文。同時,流還支持優(yōu)先級和流量控制。 版權聲明:本文為博主原創(chuàng)文章,遵循[ CC 4.0by-sa ](http://creativecommons.org/li...,轉載請附上原文出處鏈接和本...
摘要:歡迎大家收看聊一聊系列,這一套系列文章,可以幫助前端工程師們了解前端的方方面面不僅僅是代碼這一節(jié),請跟隨筆者聊一聊,網(wǎng)頁的分段傳輸與渲染,用一些非常規(guī)手段優(yōu)化我們的網(wǎng)站響應速度。可以處理完一塊就返回一塊,讓瀏覽器盡早的接收到,可以先行渲染。 歡迎大家收看聊一聊系列,這一套系列文章,可以幫助前端工程師們了解前端的方方面面(不僅僅是代碼):https://segmentfault.com/...
摘要:歡迎大家收看聊一聊系列,這一套系列文章,可以幫助前端工程師們了解前端的方方面面不僅僅是代碼什么是功能統(tǒng)計作為一名開發(fā),我們的產(chǎn)品發(fā)布出去之后,無論是產(chǎn)品還是運營,其實都是想及時了解產(chǎn)品對用戶產(chǎn)生的影響的。下一章,我們將繼續(xù)聊聊速度統(tǒng)計。 歡迎大家收看聊一聊系列,這一套系列文章,可以幫助前端工程師們了解前端的方方面面(不僅僅是代碼):https://segmentfault.com/bl...
閱讀 1808·2021-11-24 10:21
閱讀 1219·2021-09-22 15:25
閱讀 3178·2019-08-30 15:55
閱讀 718·2019-08-30 15:54
閱讀 3468·2019-08-30 14:20
閱讀 1666·2019-08-30 14:06
閱讀 646·2019-08-30 13:11
閱讀 3155·2019-08-29 16:43