HTTP學習筆記

時間 2019-12-12

標籤 http 學習筆記欄目 HTTP/TCP 简体版

原文原文鏈接

本人其實對HTTP瞭解的不是太深，學習HTTP僅僅經過相關的面試問題進行了解，如今作一個整理，但願可以有所深層次的思考

HTTP協議的版本

HTTP（HyperText Transfer Protocol）協議是基於TCP的應用層協議，它不關心數據傳輸的細節，主要是用來規定客戶端和服務端的數據傳輸格式，最初是用來向客戶端傳輸HTML頁面的內容。默認端口是80。html

主要說明一下HTTP1.0 HTTP1.1 HTTP2.0版本，說明這個問題主要能夠回答四個問題。web

HTTP協議有什麼特色？面試

簡單快速：每一個資源（好比圖片、頁面）都經過 url 來定位。這都是固定的，在http協議中，處理起來也比較簡單，想訪問什麼資源，直接輸入url便可。
靈活：http協議的頭部有一個數據類型，經過http協議，就能夠完成不一樣數據類型的傳輸。
無鏈接：鏈接一次，就會斷開，不會繼續保持鏈接。（這個特性針對HTTP1.0版本）
無狀態：客戶端和服務器端是兩種身份。第一次請求結束後，就斷開了，第二次請求時，服務器端並無記住以前的狀態，也就是說，服務器端沒法區分客戶端是否爲同一我的、同一個身份。（服務端老是被動的，這一點問題在HTTP2.0版本獲得瞭解決）

什麼是持久鏈接/HTTP長鏈接？瀏覽器

輪詢：http1.0中，客戶端每隔很短的時間，都會對服務器發出請求，查看是否有新的消息，只要輪詢速度足夠快，例如1秒，就能給人形成交互是實時進行的印象。這種作法是無奈之舉，實際上對服務器、客戶端雙方都形成了大量的性能浪費。
長鏈接：HTTP1.1中，經過使用Connection:keep-alive進行長鏈接。客戶端只請求一次，可是服務器會將繼續保持鏈接，當再次請求時，避免了從新創建鏈接。

注意， HTTP 1.1默認進行持久鏈接。在一次 TCP 鏈接中能夠完成多個 HTTP 請求，可是對每一個請求仍然要 單獨發 header，Keep-Alive不會永久保持鏈接，它有一個保持時間，能夠在不一樣的服務器軟件（如Apache）中設定這個時間。

說到長鏈接就不得不提到長鏈接的管線化問題。緩存

管線化的原理：長鏈接時，默認的請求這樣的：

請求1 --> 響應1 -->請求2 --> 響應2 --> 請求3 --> 響應3

管線化就是，把如今的請求打包，客戶端一次性發過去，服務端也給一次響應回來。

關於HTTP2.0你知道多少？安全

HTTP/2引入了"服務端推（server push）"的概念，它容許服務端在客戶端須要數據以前就主動地將數據發送到客戶端緩存中，從而提升性能。
HTTP/2提供更多的加密支持
HTTP/2使用多路技術，容許多個消息在一個鏈接上同時交差。
它增長了頭壓縮（header compression），所以即便很是小的請求，其請求和響應的header都只會佔用很小比例的帶寬

HTTP和HTTPS ？bash

HTTP協議一般承載於TCP協議之上，在HTTP和TCP之間添加一個安全協議層（SSL或TSL），這個時候，就成了HTTPS
默認HTTP的端口號爲80，HTTPS的端口號爲443

既然有了HTTP協議，爲何要有HTTPS，由於HTTPS更加的安全，那爲何HTTPS安全

由於網絡請求須要中間有不少的服務器路由器的轉發。中間的節點均可能篡改信息，而若是使用HTTPS，密鑰在你和終點站纔有。https之因此比http安全，是由於它利用ssl/tls協議傳輸。它包含證書，卸載，流量轉發，負載均衡，頁面適配，瀏覽器適配，refer傳遞等。保障了傳輸過程的安全性服務器

HTTP報文

這是一個很大的問題，這個問題不復雜就是麻煩，可是這個很重要。說明報文問題以前，先描述一下報文會在哪裏用到，在用戶輸入URL時，會用到報文。

一個頁面從輸入 URL 到頁面加載顯示完成，這個過程當中都發生了什麼？markdown

瀏覽器查找域名對應的IP地址(DNS 查詢：瀏覽器緩存->系統緩存->路由器緩存->ISP DNS 緩存->根域名服務器)
瀏覽器向 Web 服務器發送一個 HTTP 請求（TCP三次握手）---這裏用到了請求報文
服務器 301 重定向（從 http://example.com 重定向到 http://www.example.com）
瀏覽器跟蹤重定向地址，請求另外一個帶 www 的網址
服務器處理請求（經過路由讀取資源）
服務器返回一個 HTTP 響應（報頭中把 Content-type 設置爲 'text/html'）---這裏用到了響應報文
瀏覽器根據響應提進行 DOM 樹構建
瀏覽器發送請求獲取嵌在 HTML 中的資源（如圖片、音頻、視頻、CSS、JS等）
瀏覽器顯示完成頁面
瀏覽器發送異步請求

HTTP請求報文

鏈接成功創建後，開始向web服務器發送請求，當瀏覽器向Web服務器發出請求時，它向服務器傳遞了一個數據塊，也就是請求報文，HTTP請求報文由4部分組成：網絡

起始行：HTTP請求方法 URL HTTP版本
請求頭：請求頭的形式經過一個鍵值對進行渲染
空行：當服務器在解析請求頭的時候，若是遇到了空行，則代表，後面的內容是請求體
請求體：get方法的請求體是沒有內容的（放在了url裏） post方法的請求體包含請求的內容

下面是一個HTTP請求的例子：

GET /sample.jsp HTTP/1.1
Accept:image/gif.image/jpeg,*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=jinqiao&password=123412345678

起始行

請求的起始行是：」方法 URL http版本「 GET /sample.jsp HTTP/1.1
根據HTTP標準，HTTP請求可使用多種請求方法。例如：HTTP1.1支持7種請求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。在Internet應用中，最經常使用的方法是GET和POST。
URL完整地指定了要訪問的網絡資源，一般只要給出相對於服務器的根目錄的相對目錄便可，所以老是以「/」開頭。
協議版本聲明瞭通訊過程當中使用HTTP的版本。

請求頭(Request Header)

說明：經常使用的請求頭和響應頭，請看下面文章： https://blog.csdn.net/qq_3055...

請求頭包含許多有關的客戶端環境和請求正文的有用信息。例如，請求頭能夠聲明瀏覽器所用的語言，請求正文的長度等。

# host表示主機名，User-Agent表示用戶代理即瀏覽器

Accept:image/gif.image/jpeg.*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)
Accept-Encoding:gzip,deflate.123456

請求正文

請求頭和請求正文之間是一個空行，這個行很是重要，它表示請求頭已經結束，接下來的是請求正文。請求正文中能夠包含客戶提交的查詢字符串信息：

username=frewen&password=12341

HTTP響應

響應 web服務器收到這個請求，進行處理。從它的文檔空間中搜索子目錄mydir的文件index.html。若是找到該文件，Web服務器把該文件內容傳送給相應的Web瀏覽器。爲了告知瀏覽器，Web服務器首先傳送一些HTTP頭信息，而後傳送具體內容（即HTTP體信息），HTTP頭信息和HTTP體信息之間用一個空行分開。

HTTP響應與HTTP請求類似，HTTP響應也由4個部分構成，分別是：

起始行：HTTP協議版本響應狀態碼響應狀態信息
響應頭(Response Header) ：經過鍵值對的形式進行表示
空行：當客戶端在解析響應頭的時候，若是遇到了空行，則代表，後面的內容是響應體
響應體：網頁代碼 HTML、CSS、JS代碼文件

下面是一個HTTP響應的例子：

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
    <head>
        <title>HTTP響應示例<title>
    </head>
    <body>
        Hello HTTP!
    </body>
</html>

協議狀態代碼描述HTTP響應的第一行相似於HTTP請求的第一行，它表示通訊所用的協議是HTTP1.1服務器已經成功的處理了客戶端發出的請求（200表示成功）:
HTTP/1.1 200 OK
響應頭(Response Header)響應頭也和請求頭同樣包含許多有用的信息，例如服務器類型、日期時間、內容類型和長度等：

Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:13:33 GMT
Content-Type:text/html
Last-Moified:Mon,6 Oct 2003 13:23:42 GMT
Content-Length:11212345

響應體就是服務器返回的HTML頁面：

<html>
    <head>
        <title>HTTP響應示例<title>
    </head>
    <body>
        Hello HTTP!
    </body>
</html>

HTTP狀態碼

HTTP應答碼由3位數字構成，其中首位數字定義了應答碼的類型：

1XX－信息類(Information),表示收到Web瀏覽器請求，正在進一步的處理中
2XX－成功類（Successful）,表示用戶請求被正確接收，理解和處理例如：200 OK
3XX - 重定向類(Redirection),表示請求沒有成功，客戶必須採起進一步的動做。
4XX - 客戶端錯誤(Client Error)，表示客戶端提交的請求有錯誤例如：404 NOT Found，意味着請求中所引用的文檔不存在。
5XX - 服務器錯誤(Server Error)表示服務器不能完成對請求的處理：如 500

常見的狀態碼

100  Continue   繼續，通常在發送post請求時，已發送了http header以後服務端將返回此信息，表示確認，以後發送具體參數信息

200  OK         正常返回信息
201  Created    請求成功而且服務器建立了新的資源
202  Accepted   服務器已接受請求，但還沒有處理
206  Partial Content：客戶端發送一個帶有range頭的get請求，服務端完成它。206的應用的場景：range指的是請求的範圍，客戶端只請求某個大文件裏的一部份內容。好比說，若是播放視頻地址或音頻地址的前面一部分，能夠用到206。

301  Moved Permanently  請求的網頁已永久移動到新位置。(永久重定向)
302  Found       臨時性重定向。
303  See Other   臨時性重定向，且老是使用 GET 請求新的 URI。
304  Not Modified 自從上次請求後，請求的網頁未修改過。（服務器告訴客戶端，客戶端已經有緩存了，不須要從服務器這裏取了。）

400  Bad Request  客戶端有語法錯誤，不能被服務器所理解
401  Unauthorized 請求未受權。
403  Forbidden   禁止訪問。
404  Not Found   找不到如何與 URI 相匹配的資源。

500  Internal Server Error  最多見的服務器端錯誤。
503  Service Unavailable 服務器端暫時沒法處理請求（多是過載或維護）。

提到上面的狀態碼，不得不提到304緩存問題：304緩存的原理

服務器首先產生ETag，服務器可在稍後使用它來判斷頁面是否已經被修改。本質上，客戶端經過將該記號傳回服務器要求服務器驗證其（客戶端）緩存
304是HTTP狀態碼，服務器用來標識這個文件沒修改，不返回內容，瀏覽器在接收到個狀態碼後，會使用瀏覽器已緩存的文件
客戶端請求一個頁面（A）。服務器返回頁面A，並在給A加上一個ETag。客戶端展示該頁面，並將頁面連同ETag一塊兒緩存。客戶再次請求頁面A，並將上次請求時服務器返回的ETag一塊兒傳遞給服務器。服務器檢查該ETag，並判斷出該頁面自上次客戶端請求以後還未被修改，直接返回響應304（未修改——Not Modified）和一個空的響應體

HTTP方法

HTTP方法主要包括如下幾個：

GET：獲取資源
POST：傳輸資源
PUT：更新資源
DELETE：刪除資源
HEAD：得到報文首部

說明一下get和post的區別

瀏覽器在回退時，get 不會從新請求，可是post會從新請求。【重要】
get請求會被瀏覽器主動緩存，而post不會。【重要】
get請求的參數，會報保留在瀏覽器的歷史記錄裏，而post不會。作業務時要注意。爲了防止CSRF攻擊，不少公司把get統一改爲了post。
get請求在url中傳遞的參數有大小限制，基本是 2kb，不一樣的瀏覽器略有不一樣。而post沒有注意。
get的參數是直接暴露在url上的，相對不安全。而post是放在請求體中的。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。