<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ThinkChat2.0新版上線,更智能更精彩,支持會話、畫圖、視頻、閱讀、搜索等,送10W Token,即刻開啟你的AI之旅 廣告
                ## 后臺和前臺的http交互 前后端交互時,http報文作為信息的載體 所以http是一塊很重要的內容,這一部分重點介紹它 ### http報文結構 報文一般包括了:`通用頭部`,`請求/響應頭部`,`請求/響應體` **通用頭部** 這也是開發人員見過的最多的信息,包括如下: ``` Request Url: 請求的web服務器地址 Request Method: 請求方式 (Get、POST、OPTIONS、PUT、HEAD、DELETE、CONNECT、TRACE) Status Code: 請求的返回狀態碼,如200代表成功 Remote Address: 請求的遠程服務器地址(會轉為IP) ``` 譬如,在跨域拒絕時,可能是method為`options`,狀態碼為`404/405`等(當然,實際上可能的組合有很多) 其中,Method的話一般分為兩批次: ``` HTTP1.0定義了三種請求方法: GET, POST 和 HEAD方法。 以及幾種Additional Request Methods:PUT、DELETE、LINK、UNLINK HTTP1.1定義了八種請求方法:GET、POST、HEAD、OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。 ``` `HTTP 1.0`定義參考:[https://tools.ietf.org/html/rfc1945](https://tools.ietf.org/html/rfc1945) `HTTP 1.1`定義參考:[https://tools.ietf.org/html/rfc2616](https://tools.ietf.org/html/rfc2616) 這里面最常用到的就是狀態碼,很多時候都是通過狀態碼來判斷,如(列舉幾個最常見的): ``` 200——表明該請求被成功地完成,所請求的資源發送回客戶端 304——自從上次請求后,請求的網頁未修改過,請客戶端使用本地緩存 400——客戶端請求有錯(譬如可以是安全模塊攔截) 401——請求未經授權 403——禁止訪問(譬如可以是未登錄時禁止) 404——資源未找到 500——服務器內部錯誤 503——服務不可用 ... ``` 再列舉下大致不同范圍狀態的意義 ``` 1xx——指示信息,表示請求已接收,繼續處理 2xx——成功,表示請求已被成功接收、理解、接受 3xx——重定向,要完成請求必須進行更進一步的操作 4xx——客戶端錯誤,請求有語法錯誤或請求無法實現 5xx——服務器端錯誤,服務器未能實現合法的請求 ``` ![img](http://xiaoyulive.oss-cn-beijing.aliyuncs.com/date/2018-03-26/http_status_brief.png) 總之,當請求出錯時,狀態碼能幫助快速定位問題,完整版本的狀態可以自行去互聯網搜索 **請求/響應頭部** 請求和響應頭部也是分析時常用到的 常用的請求頭部(部分): ``` Accept: 接收類型,表示瀏覽器支持的MIME類型 (對標服務端返回的Content-Type) Accept-Encoding:瀏覽器支持的壓縮類型,如gzip等,超出類型不能接收 Content-Type:客戶端發送出去實體內容的類型 Cache-Control: 指定請求和響應遵循的緩存機制,如no-cache If-Modified-Since:對應服務端的Last-Modified,用來匹配看文件是否變動,只能精確到1s之內,http1.0中 Expires:緩存控制,在這個時間內不會請求,直接使用緩存,http1.0,而且是服務端時間 Max-age:代表資源在本地緩存多少秒,有效時間內不會請求,而是使用緩存,http1.1中 If-None-Match:對應服務端的ETag,用來匹配文件內容是否改變(非常精確),http1.1中 Cookie: 有cookie并且同域訪問時會自動帶上 Connection: 當瀏覽器與服務器通信時對于長連接如何進行處理,如keep-alive Host:請求的服務器URL Origin:最初的請求是從哪里發起的(只會精確到端口),Origin比Referer更尊重隱私 Referer:該頁面的來源URL(適用于所有類型的請求,會精確到詳細頁面地址,csrf攔截常用到這個字段) User-Agent:用戶客戶端的一些必要信息,如UA頭部等 ``` 常用的響應頭部(部分): ``` Access-Control-Allow-Headers: 服務器端允許的請求Headers Access-Control-Allow-Methods: 服務器端允許的請求方法 Access-Control-Allow-Origin: 服務器端允許的請求Origin頭部(譬如為*) Content-Type:服務端返回的實體內容的類型 Date:數據從服務器發送的時間 Cache-Control:告訴瀏覽器或其他客戶,什么環境可以安全的緩存文檔 Last-Modified:請求資源的最后修改時間 Expires:應該在什么時候認為文檔已經過期,從而不再緩存它 Max-age:客戶端的本地資源應該緩存多少秒,開啟了Cache-Control后有效 ETag:請求變量的實體標簽的當前值 Set-Cookie:設置和頁面關聯的cookie,服務器通過這個頭部把cookie傳給客戶端 Keep-Alive:如果客戶端有keep-alive,服務端也會有響應(如timeout=38) Server:服務器的一些相關信息 ``` 一般來說,請求頭部和響應頭部是匹配分析的。 譬如,請求頭部的`Accept`要和響應頭部的`Content-Type`匹配,否則會報錯 譬如,跨域請求時,請求頭部的`Origin`要匹配響應頭部的`Access-Control-Allow-Origin`,否則會報跨域錯誤 譬如,在使用緩存時,請求頭部的`If-Modified-Since`、`If-None-Match`分別和響應頭部的`Last-Modified`、`ETag`對應 還有很多的分析方法,這里不一一贅述 **請求/響應實體** http請求時,除了頭部,還有消息實體,一般來說 請求實體中會將一些需要的參數都放入進入(用于post請求)。 譬如實體中可以放參數的序列化形式(`a=1&b=2`這種),或者直接放表單對象(`Form Data`對象,上傳時可以夾雜參數以及文件),等等 而一般響應實體中,就是放服務端需要傳給客戶端的內容 一般現在的接口請求時,實體中就是對于的信息的json格式,而像頁面請求這種,里面就是直接放了一個html字符串,然后瀏覽器自己解析并渲染。 **CRLF** CRLF(Carriage-Return Line-Feed),意思是回車換行,一般作為分隔符存在 請求頭和實體消息之間有一個CRLF分隔,響應頭部和響應實體之間用一個CRLF分隔 一般來說(分隔符類別): ``` CRLF->Windows-style LF->Unix Style CR->Mac Style ``` 如下圖是對某請求的http報文結構的簡要分析 ![img](http://xiaoyulive.oss-cn-beijing.aliyuncs.com/date/2018-03-26/http_ajax_headers.png) ### cookie以及優化 cookie是瀏覽器的一種本地存儲方式,一般用來幫助客戶端和服務端通信的,常用來進行身份校驗,結合服務端的session使用。 場景如下(簡述): ``` 在登陸頁面,用戶登陸了 此時,服務端會生成一個session,session中有對于用戶的信息(如用戶名、密碼等) 然后會有一個sessionid(相當于是服務端的這個session對應的key) 然后服務端在登錄頁面中寫入cookie,值就是:jsessionid=xxx 然后瀏覽器本地就有這個cookie了,以后訪問同域名下的頁面時,自動帶上cookie,自動檢驗,在有效時間內無需二次登陸。 ``` 上述就是cookie的常用場景簡述(當然了,實際情況下得考慮更多因素) 一般來說,cookie是不允許存放敏感信息的(千萬不要明文存儲用戶名、密碼),因為非常不安全,如果一定要強行存儲,首先,一定要在cookie中設置`httponly`(這樣就無法通過js操作了),另外可以考慮rsa等非對稱加密(因為實際上,瀏覽器本地也是容易被攻克的,并不安全) 另外,由于在同域名的資源請求時,瀏覽器會默認帶上本地的cookie,針對這種情況,在某些場景下是需要優化的。 譬如以下場景: ``` 客戶端在域名A下有cookie(這個可以是登陸時由服務端寫入的) 然后在域名A下有一個頁面,頁面中有很多依賴的靜態資源(都是域名A的,譬如有20個靜態資源) 此時就有一個問題,頁面加載,請求這些靜態資源時,瀏覽器會默認帶上cookie 也就是說,這20個靜態資源的http請求,每一個都得帶上cookie,而實際上靜態資源并不需要cookie驗證 此時就造成了較為嚴重的浪費,而且也降低了訪問速度(因為內容更多了) ``` 當然了,針對這種場景,是有優化方案的(多域名拆分)。具體做法就是: - 將靜態資源分組,分別放到不同的域名下(如`static.base.com`) - 而`page.base.com`(頁面所在域名)下請求時,是不會帶上`static.base.com`域名的cookie的,所以就避免了浪費 說到了多域名拆分,這里再提一個問題,那就是: - 在移動端,如果請求的域名數過多,會降低請求速度(因為域名整套解析流程是很耗費時間的,而且移動端一般帶寬都比不上pc) - 此時就需要用到一種優化方案:`dns-prefetch`(讓瀏覽器空閑時提前解析dns域名,不過也請合理使用,勿濫用) 關于cookie的交互,可以看下圖總結 ![img](http://xiaoyulive.oss-cn-beijing.aliyuncs.com/date/2018-03-26/http_cookie_session.png) ### gzip壓縮 首先,明確`gzip`是一種壓縮格式,需要瀏覽器支持才有效(不過一般現在瀏覽器都支持), 而且gzip壓縮效率很好(高達70%左右) 然后gzip一般是由`apache`、`tomcat`等web服務器開啟 當然服務器除了gzip外,也還會有其它壓縮格式(如deflate,沒有gzip高效,且不流行) 所以一般只需要在服務器上開啟了gzip壓縮,然后之后的請求就都是基于gzip壓縮格式的, 非常方便。 ### 長連接與短連接 首先看`tcp/ip`層面的定義: - 長連接:一個tcp/ip連接上可以連續發送多個數據包,在tcp連接保持期間,如果沒有數據包發送,需要雙方發檢測包以維持此連接,一般需要自己做在線維持(類似于心跳包) - 短連接:通信雙方有數據交互時,就建立一個tcp連接,數據發送完成后,則斷開此tcp連接 然后在http層面: - `http1.0`中,默認使用的是短連接,也就是說,瀏覽器沒進行一次http操作,就建立一次連接,任務結束就中斷連接,譬如每一個靜態資源請求時都是一個單獨的連接 - http1.1起,默認使用長連接,使用長連接會有這一行`Connection: keep-alive`,在長連接的情況下,當一個網頁打開完成后,客戶端和服務端之間用于傳輸http的tcp連接不會關閉,如果客戶端再次訪問這個服務器的頁面,會繼續使用這一條已經建立的連接 注意: **keep-alive不會永遠保持,它有一個持續時間,一般在服務器中配置(如apache),另外長連接需要客戶端和服務器都支持時才有效** ### http 2.0 http2.0不是https,它相當于是http的下一代規范(譬如https的請求可以是http2.0規范的) 然后簡述下http2.0與http1.1的顯著不同點: - http1.1中,每請求一個資源,都是需要開啟一個tcp/ip連接的,所以對應的結果是,每一個資源對應一個tcp/ip請求,由于tcp/ip本身有并發數限制,所以當資源一多,速度就顯著慢下來 - http2.0中,一個tcp/ip請求可以請求多個資源,也就是說,只要一次tcp/ip請求,就可以請求若干個資源,分割成更小的幀請求,速度明顯提升。 所以,如果http2.0全面應用,很多http1.1中的優化方案就無需用到了(譬如打包成精靈圖,靜態資源多域名拆分等) 然后簡述下http2.0的一些特性: - 多路復用(即一個tcp/ip連接可以請求多個資源) - 首部壓縮(http頭部壓縮,減少體積) - 二進制分幀(在應用層跟傳送層之間增加了一個二進制分幀層,改進傳輸性能,實現低延遲和高吞吐量) - 服務器端推送(服務端可以對客戶端的一個請求發出多個響應,可以主動通知客戶端) - 請求優先級(如果流被賦予了優先級,它就會基于這個優先級來處理,由服務器決定需要多少資源來處理該請求。) ### https https就是安全版本的http,譬如一些支付等操作基本都是基于https的,因為http請求的安全系數太低了。 簡單來看,https與http的區別就是: **在請求前,會建立ssl鏈接,確保接下來的通信都是加密的,無法被輕易截取分析** 一般來說,如果要將網站升級成https,需要后端支持(后端需要申請證書等),然后https的開銷也比http要大(因為需要額外建立安全鏈接以及加密等),所以一般來說http2.0配合https的體驗更佳(因為http2.0更快了) 一般來說,主要關注的就是SSL/TLS的握手流程,如下(簡述): ``` 1. 瀏覽器請求建立SSL鏈接,并向服務端發送一個隨機數–Client random和客戶端支持的加密方法,比如RSA加密,此時是明文傳輸。 2. 服務端從中選出一組加密算法與Hash算法,回復一個隨機數–Server random,并將自己的身份信息以證書的形式發回給瀏覽器 (證書里包含了網站地址,非對稱加密的公鑰,以及證書頒發機構等信息) 3. 瀏覽器收到服務端的證書后 - 驗證證書的合法性(頒發機構是否合法,證書中包含的網址是否和正在訪問的一樣),如果證書信任,則瀏覽器會顯示一個小鎖頭,否則會有提示 - 用戶接收證書后(不管信不信任),瀏覽會生產新的隨機數–Premaster secret,然后證書中的公鑰以及指定的加密方法加密`Premaster secret`,發送給服務器。 - 利用Client random、Server random和Premaster secret通過一定的算法生成HTTP鏈接數據傳輸的對稱加密key-`session key` - 使用約定好的HASH算法計算握手消息,并使用生成的`session key`對消息進行加密,最后將之前生成的所有信息發送給服務端。 4. 服務端收到瀏覽器的回復 - 利用已知的加解密方式與自己的私鑰進行解密,獲取`Premaster secret` - 和瀏覽器相同規則生成`session key` - 使用`session key`解密瀏覽器發來的握手消息,并驗證Hash是否與瀏覽器發來的一致 - 使用`session key`加密一段握手消息,發送給瀏覽器 5. 瀏覽器解密并計算握手消息的HASH,如果與服務端發來的HASH一致,此時握手過程結束, ``` **之后所有的https通信數據將由之前瀏覽器生成的session key并利用對稱加密算法進行加密**
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看