HTTP協議原理和深刻

時間 2019-11-08

原文原文鏈接

前端面試常見問題：

http method

HTTP1.0定義了三種請求方法： GET、POST 和 HEAD
HTTP1.1新增了五種請求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 、 CONNECT

http status code

2開頭 （請求成功）表示成功處理了請求的狀態代碼。

200   （成功）  服務器已成功處理了請求。 一般，這表示服務器提供了請求的網頁。 
201   （已建立）  請求成功而且服務器建立了新的資源。 
202   （已接受）  服務器已接受請求，但還沒有處理。 
203   （非受權信息）  服務器已成功處理了請求，但返回的信息可能來自另外一來源。 
204   （無內容）  服務器成功處理了請求，但沒有返回任何內容。 
205   （重置內容） 服務器成功處理了請求，但沒有返回任何內容。
206   （部份內容）  服務器成功處理了部分 GET 請求。

3開頭 （請求被重定向）表示要完成請求，須要進一步操做。 一般，這些狀態代碼用來重定向。

300   （多種選擇）  針對請求，服務器可執行多種操做。 服務器可根據請求者 (user agent) 選擇一項操做，或提供操做列表供請求者選擇。 
301   （永久移動）  請求的網頁已永久移動到新位置。 服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。
302   （臨時移動）  服務器目前從不一樣位置的網頁響應請求，但請求者應繼續使用原有位置來進行之後的請求。
303   （查看其餘位置） 請求者應當對不一樣的位置使用單獨的 GET 請求來檢索響應時，服務器返回此代碼。
304   （未修改） 自從上次請求後，請求的網頁未修改過。 服務器返回此響應時，不會返回網頁內容。 
305   （使用代理） 請求者只能使用代理訪問請求的網頁。 若是服務器返回此響應，還表示請求者應使用代理。 
307   （臨時重定向）  服務器目前從不一樣位置的網頁響應請求，但請求者應繼續使用原有位置來進行之後的請求。

4開頭 （請求錯誤）這些狀態代碼表示請求可能出錯，妨礙了服務器的處理。

400   （錯誤請求） 服務器不理解請求的語法。 
401   （未受權） 請求要求身份驗證。 對於須要登陸的網頁，服務器可能返回此響應。 
403   （禁止） 服務器拒絕請求。
404   （未找到） 服務器找不到請求的網頁。
405   （方法禁用） 禁用請求中指定的方法。 
406   （不接受） 沒法使用請求的內容特性響應請求的網頁。 
407   （須要代理受權） 此狀態代碼與 401（未受權）相似，但指定請求者應當受權使用代理。
408   （請求超時）  服務器等候請求時發生超時。 
409   （衝突）  服務器在完成請求時發生衝突。 服務器必須在響應中包含有關衝突的信息。 
410   （已刪除）  若是請求的資源已永久刪除，服務器就會返回此響應。 
411   （須要有效長度） 服務器不接受不含有效內容長度標頭字段的請求。 
412   （未知足前提條件） 服務器未知足請求者在請求中設置的其中一個前提條件。 
413   （請求實體過大） 服務器沒法處理請求，由於請求實體過大，超出服務器的處理能力。 
414   （請求的 URI 過長） 請求的 URI（一般爲網址）過長，服務器沒法處理。 
415   （不支持的媒體類型） 請求的格式不受請求頁面的支持。 
416   （請求範圍不符合要求） 若是頁面沒法提供請求的範圍，則服務器會返回此狀態代碼。 
417   （未知足指望值） 服務器未知足"指望"請求標頭字段的要求。

5開頭（服務器錯誤）這些狀態代碼表示服務器在嘗試處理請求時發生內部錯誤。 這些錯誤多是服務器自己的錯誤，而不是請求出錯。

500   （服務器內部錯誤）  服務器遇到錯誤，沒法完成請求。 
501   （還沒有實施） 服務器不具有完成請求的功能。 例如，服務器沒法識別請求方法時可能會返回此代碼。 
502   （錯誤網關） 服務器做爲網關或代理，從上游服務器收到無效響應。 
503   （服務不可用） 服務器目前沒法使用（因爲超載或停機維護）。 一般，這只是暫時狀態。 
504   （網關超時）  服務器做爲網關或代理，可是沒有及時從上游服務器收到請求。 
505   （HTTP 版本不受支持） 服務器不支持請求中所用的 HTTP 協議版本。

緩存

客戶端緩存
代理服務器緩存
緩存如何驗證可用性

cache-control：

max-age=100 靜態資源緩存100s
public、private 設置只能在客戶端緩存，仍是能夠經過代理服務器緩存
must-revalidate 在緩存過時後必須到服務器端驗證過才能繼續使用緩存
no-cache、no-store 控制是否使用緩存

緩存驗證

last-modified配合if-modified-since
etage配合if-none-match

緩存是web開發中對性能提高最大的一面javascript

更有意義的頭部

Content-type、Content-Encoding等用來約束數據類型
cookie保持會話信息
CORS實現跨域並保持安全性限制

深刻到 TCP：

什麼是三次握手
HTTPS連接的建立過程，以及爲何HTTPS就是安全的
什麼是長連接，爲何須要長連接
HTTP2的信道複用爲何能提高性能

輸入URL後HTTP請求返回的完整過程

一、爲何一開始須要作redirect：由於瀏覽器可能記錄了這個地址永久跳轉成一個新的地址，一開始瀏覽器須要判斷redirect，redirect到什麼地址
二、看緩存：看請求的資源是否已經緩存
三、dns解析
四、建立鏈接
五、開始發送數據包

Nginx

配置ngnix做爲http的代理
開啓ngnix的緩存功能
利用代理緩存提升http性能

HTTP協議基礎及發展歷史

五層網絡模型介紹

物理層：主要定義物理設備如何傳輸數據，硬件設備

數據鏈路層：在通訊的實體間簡歷數據鏈路連接

網絡層：爲數據在節點之間傳輸建立邏輯鏈路

傳輸層：像用戶提供可靠的端到端(End-to-End)服務傳輸層向高層屏蔽了下層數據通訊的細節

應用層:爲應用軟件提供了不少服務

構建於TCP協議之上

屏蔽了網絡傳輸相關細節html

HTTP協議發展歷史

HTTP 0.9

一、只有一個命令GET
二、沒有header等描述數據的信息
三、服務器發送完畢，就關閉了TCP鏈接

HTTP1.0

一、增長了不少命令
二、增長status code和header
三、多字符集支持、多部分發送、權限、緩存等

HTTP1.1

一、持久鏈接(創建TCP消耗)
二、pipeline(同一個連接能夠發送多個請求，服務端是按照順序接受，可能須要等待，串行)
三、增長host和其餘一些命令

HTTP2（還沒有普及）
一、全部數據以二進制進行傳輸
二、同一個連接裏面發送多個請求再也不小按照順序來(並行)
三、頭信息壓縮以及推送等提升效率的功能

HTTP的三次握手

客戶端和服務器端進行信息發送，是須要建立一個TCP-connetion
http是不存在鏈接這個概念，只有請求和響應，它們都是數據包
tcp連接能夠發送多個http請求

三次握手時序圖

URI-URL和URN

Uniform Resource Locator/統一資源定位器

http://user:pass@host.com:80/path?query=string#hash

URN:永久統一資源定位符

在資源移動以後還能找到
目前尚未很是成熟的使用方案

HTTP報文格式

HTTP各類特性總覽

認識http客戶端

curl -v  www.baidu.com

CORS跨域請求的限制與解決

請求已經發送，已經獲取到了返回數據。不過瀏覽器在解析返回的時候，發現是不容許的，瀏覽器攔截了，隱藏了數據。必須服務器容許跨越請求。前端

瀏覽器容許link、script、img這些在標籤上寫路徑加載的時候，容許跨越，無論服務器是否容許跨域請求。jsnop原理也是如此

服務器端能夠加：'Access-Control-Allow-Origin': ''，表示容許跨域訪問。''表示容許全部跨域訪問，能夠設置指定的服務器訪問。多域能夠動態判斷

CORS跨域限制以及預請求驗證

不須要預請求的限制：

一、容許method：
GET、HEAD、POST
二、容許Content-Type：
text/plain、
multipart/form-data、
application/x-www-form-urlencoded
三、請求頭限制：
Accept
Accept-Language
Content-Language
Last-Event-ID

Content-Type：java

只限於三個值 application/x-www-form-urlencoded、
        multipart/form-data、
        text/plain

四、XMLHttpRequestUpload對象軍沒有註冊任何事件監聽器
五、請求中沒有使用ReadableStream

解決方法：

'Access-Control-Allow-Origin': 'http://127.0.0.1:8888',
'Access-Control-Allow-Headers': 'X-Test-Cors',
'Access-Control-Allow-Methods': 'POST, PUT, DELETE',

'Access-Control-Max-Age': '1000'
//容許以這種方式發送預請求的時間，這段時間內不須要再發送預請求了

緩存頭Cache-Control的含義和使用

可緩存性

pulic :http請求通過的任何路徑均可以對返回內容的緩存
private:只有發起請求的瀏覽器才能夠進行緩存
non-cache:任何節點都不能夠進行緩存

到期：

max-age=<seconds>
s-maxage=<seconds> //若是兩個都設置，代理服務器會讀取
max-stale=<seconds> //只有在發起端設置才管用，即使max-age過時，只要在max-stale時間內仍然可使用過時的緩存，服務端返回中設置沒有做用

從新驗證：

一、must-revalidate//設置了max-age中若是已通過期了，必須去原服務端從新發送請求，從新獲取數據驗證是否真的過時
二、proxy-revalidate//緩存服務器中
三、no-store//永遠都要去服務器拿新的
四、no-transform//告訴代理服務器不可改動內容

cache-control應用

一、只是聲明性的，並無強制約束力
二、chrome 裏面的disable cache必須勾掉
三、cache-control是一種客戶端緩存，並且通常緩存時間都比較長，可能會致使服務端靜態資源改變而客戶端沒法更新。解決方案：在靜態資源文件後面加上一串哈希碼，若是內容沒有變，哈希碼沒變，可使用靜態資源緩存；若是文件有邊，發的請求就是新的靜態資源請求。

'Cache-Control': 'max-age=200,public'

緩存驗證Last-Modefied和Etag的使用

資源驗證

last-modified

上次修改時間
配合If-Modified-Since或者If-Unmodified-Since使用

Etag

更加嚴格的驗證
數據簽名(任何的修改，惟一)，最典型的就是哈希計算獲得惟一值
配合If-Match或者If-Non-Match
對比資源的簽名判斷是否使用緩存

一、304:Not Modified。資源沒有修改，能夠直接讀緩存。會忽略response  body裏面的內容。
二、If-Modified-since和If-None-Match，disable cache 緩存驗證頭就不發送這兩個參數。
三、若是設置了no-store會忽略全部跟緩存有關的

const http = require('http')
const fs = require('fs')

http.createServer(function(request, response) {
    console.log('request ', request.url)
    const html = fs.readFileSync('test.html', 'utf8')
    if (request.url === '/') {
        const html = fs.readFileSync('test.html', 'utf8')
        response.writeHead(200, {
            'Content-Type': 'text/html'
        })
        response.end(html)
    }
    if (request.url === '/script.js') {
        const html = fs.readFileSync('test.html', 'utf8')

        const etag = request.headers['if-none-match']
        if (request.getHeader = '777') {
            response.writeHead(304, {
                'Content-Type': 'text/javascript',
                'Cache-Control': 'max-age=2000000,no-cache',
                'Last-Modified': '123',
                'Etag': '777'
            })
            response.end('123')
        } else {
            response.writeHead(200, {
                'Content-Type': 'text/javascript',
                'Cache-Control': 'max-age=2000000,no-cache',
                'Last-Modified': '123',
                'Etag': '777'
            })
            response.end('console.log("script loadded")')
        }
    }
}).listen(8888)

console.log('serve listening on 8888')

const http = require('http')
const fs = require('fs')

http.createServer(function(request, response) {
    console.log('request ', request.url)
    const html = fs.readFileSync('test.html', 'utf8')
    response.writeHead(200, {
        'Access-Control-Allow-Origin': '*',
        'Access-Control-Allow-Headers': 'X-Test-Cors'

    })
    response.end(html)
}).listen(8887)

console.log('serve listening on 8887')

cookie和session

cookie

經過Set-Cookie設置，同域請求中
下次請求會自動帶上
鍵值對，能夠設置多個

cookie屬性

max-age 和 expires設置過時時間
secure只在https的時候發送
httpOnly沒法經過document.cookie訪問

'Set-Cookie':['id=12343','max-age=10','name=dafdafda';HttpOnly]

不一樣域cookie不能獲取，同一個主域名的二級域名能夠共享cookie。web

HTTP長鏈接

複用TCP/IP鏈接
三次握手的開銷可能不要比長鏈接消耗的高
Connection: keep-alive
chrome通常六個併發
HTTP2信道複用

數據協商

請求

Accept：//返回數據類型
Accept-Encoding：//主要是如何數據壓縮
Accept-Language://返回語言
User-Agent：//返回pc端仍是移動端

返回

Content-Type：對應Accept
Content-Encoding:對應Accept-Encoding
Content-Language:對應Accept-Language

X-Content-Type-Options:nosniff  //不會主動預測返回內容

數據壓縮

const zlib = require('zlib')
'Content-Encoding':'gzip'

Redirect

301 Moved Permanently 被請求的資源已永久移動到新位置，而且未來任何對此資源的引用都應該使用本響應返回的若干個URI之一。若是可能，擁有連接編輯功能的客戶端應當自動把請求的地址修改成從服務器反饋回來的地址。除非額外指定，不然這個響應也是可緩存的。
重定向在瀏覽器緩存中，若是用戶不清理緩存，那麼服務端無法控制
302 Found
請求的資源如今臨時從不一樣的URI響應請求。因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。面試