前端面試積累

關於http的問題

1.常見Http請求頭

 

host (主機和端口號)
Accept (傳輸文件類型)
Content-Type(表示具體請求中的媒體類型信息)

Origin(表示請求出處，防止CSRF的攻擊)
Upgrade-Insecure-Requests (升級爲 HTTPS 請求)
User-Agent (瀏覽器名稱)
Referer (頁面跳轉處)
Accept-Encoding（文件編解碼格式）
Cookie （Cookie）
x-requested-with :XMLHttpRequest (是 Ajax 異步請求)

到了http2.0協議是小寫字母，這點跟HTTP1不一樣。
另外部分新增的協議用冒號開頭

 

:authority(應該和host同樣，顯示域名)

 :method（請求類型）

:path(請求接口)

:scheme(協議)

 

 2.介紹Http2.0

官網：https://http2.github.io/

http協議是互聯網上使用最普遍、最通用的通信協議，也能夠說是互聯網通信協議的事實標準,http/2是http規範的一個最新版本

HTTP2的核心是性能優化，主要是延時和帶寬兩方面。與HTTP1.X相比的優點在於：

低延時。 多路複用（一個域名一個鏈接）避免了鏈接頻繁建立和慢啓動過程；服務端推送（Server Push）實現了資源「預讀」，提早將資源推送到客戶端。
帶寬佔用少。 頭部壓縮技術及二進制協議減小了對帶寬的資源佔用

 

 多路複用：多個請求可同時在一個鏈接上並行執行。某個請求任務耗時嚴重，不會影響到其它鏈接的正常執行

頭部壓縮：hpack算法對header進行壓縮

Server push :服務器傳送

tcp三次握手，四次揮手

字段 含義
URG 緊急指針是否有效。爲1，表示某一位須要被優先處理
ACK 確認號是否有效，通常置爲1。
PSH 提示接收端應用程序當即從TCP緩衝區把數據讀走。
RST 對方要求從新創建鏈接，復位。
SYN 請求創建鏈接，並在其序列號的字段進行序列號的初始值設定。創建鏈接，設置爲1
FIN     但願斷開鏈接。

---------------------

SYN_SENT 客戶端狀態

SYN_RECV半鏈接狀態

ESTABLISHED表示兩臺機器正在傳輸數據

FIN-WAIT-1終止等待狀態

FIN-WAIT-2半關閉狀態

CLOSE-WAIT（關閉等待）狀態

LAST-ACK（最後確認）狀態

TIME-WAIT（時間等待）狀態

CLOSED沒有任何鏈接狀態。
三次握手過程理解

第一次握手：創建鏈接時，客戶端發送syn包（syn=x）到服務器，並進入SYN_SENT狀態，等待服務器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。

第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=x+1），同時本身也發送一個SYN包（syn=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態；

第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=y+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP鏈接成功）狀態，完成三次握手。

四次揮手過程理解

1）客戶端進程發出鏈接釋放報文，而且中止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即便不攜帶數據，也要消耗一個序號。
2）服務器收到鏈接釋放報文，發出確認報文，ACK=1，ack=u+1，而且帶上本身的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，可是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
3）客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送鏈接釋放報文（在這以前還須要接受服務器發送的最後的數據）。
4）服務器將最後的數據發送完畢後，就向客戶端發送鏈接釋放報文，FIN=1，ack=u+1，因爲在半關閉狀態，服務器極可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。
5）客戶端收到服務器的鏈接釋放報文後，必須發出確認，ACK=1，ack=w+1，而本身的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP鏈接尚未釋放，必須通過2∗∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
6）服務器只要收到了客戶端發出的確認，當即進入CLOSED狀態。一樣，撤銷TCB後，就結束了此次的TCP鏈接。能夠看到，服務器結束TCP鏈接的時間要比客戶端早一些。

參考：http://www.javashuo.com/article/p-fovlppmg-k.html

　　   http://www.javashuo.com/article/p-zqmaiqar-kb.html