前端面試常問的計算機網絡知識

OSI 與TCP/IP模型

輸入域名發生了什麼

假設輸入 www.baidu.com

瀏覽器解析域名。

客戶端與服務端進行數據交互的時候，不能識別域名，通過DNS解析域名轉化未對用的IP地址

• 瀏覽器緩存中查找是否存在映射關係
• 查詢·本地host文件，查看是否存在域名與ip的對應關係，有的話則直接解析出來ip
• host文件不存在，就去本地區的DNS服務器（移動聯通電信運營商提供的dns）裏面查找ip與域名是否有映射關係，有的話返回
• 還沒找到的話去根服務器查找
• 根服務器會判斷這個域名由誰管理，這裏.com就由負責.com的頂級域名服務器管理，然後返回這個服務器的ip。頂級域名服務器（gTLD Server）： .com、.cn等域名
• 本地區的dns服務器會向這個頂級域名服務器的ip繼續查詢，他返回域名對應的域名服務器，這個域名服務器是你註冊的域名服務器，這個域名的服務商的服務器將承擔起域名解析的任務。
• 域名服務器將解析出的ip返回給本地區的服務器
• 本地區的服務器緩存解析結果
• 將解析的結果返回給用戶

TCP/IP三次握手建立連接

引出一個問題：爲什麼是三次？兩次建立連接存在什麼問題？四次呢

• 第一次握手，客戶端的TCP向服務端的TCP發送連接請求報文，SYN=1(SYN代表發起一個新連接)，和一個隨機的起始信號seq=x(seq信號，32位，用於標識TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記)
• 第二次握手，服務端TCP接收到請求報文之後，向客戶機發送請求，併爲該TCP連接分配TCP緩存和變量，他向客戶端發送四個字段：SYN=1、ACK=1(確認信號是有效的) 、ack=x+1(ack序號，32位，只有在ACK標誌位置1時，ack纔是有效的，ack=seq+1)、隨機產生一個的一個seq=y
• 客戶機收到確認的報文時，需要繼續向服務端確認，並且也要給該鏈接分配緩存和變量 ACK=1、seq=x+1、 ack=y+1

幾種狀態的說明：

• CLOSED：連接結束，沒有任何連接狀態
• LISTEN：監聽遠端的連接，可以接收連接
• SYN_SENT：客戶端連接時，發送SYN之後進入SYN_SENT狀態
• SYN_REVD:服務端接收到了客戶端發送的SYN報文
• ESTABLISHED：標識已經成功建立TCP連接

瀏覽器客戶端向後端發送數據

• 三次握手建立連接之後，向後臺發送請求

後臺返回數據給瀏覽器渲染

• 解析html結構，構建dom樹，那所有的標籤解析出來

• 構建cssom樹，解析css樣式

• 執行script標籤中的代碼（所以避免將該標籤放在頭部，造成頁面空白，形成阻塞 ）

  • 普通標籤：解析到script標籤之後，加載腳本內容，然後執行，執行完畢之後繼續解析html
  • defer：解析到script之後，不發生阻塞，一邊解析html,一遍加載腳本，等帶html解析全部解析完成之後，在執行腳本
  • async：與defer相似，只是腳本執行的時機不同，他在加載腳本時不發生阻塞，等待叫腳本加載完成之後，執行腳本

• 將dom和cssom合併成渲染樹

• 根據渲染樹將頁面繪製出來

四次揮手斷開連接

引出一個問題：三次揮手行不行

• 第一次揮手，客戶端發送一個連接釋放報文,並停止再發送數據,主動關閉TCP連接, FIN=1(釋放一個連接),seq=u
• 第二次揮手: 服務器接收連接釋放報文後即發出確認, ACK=1、ack=u+1、seq=v此時, 從客戶機到服務器這個方向的連接就釋放了, TCP連接處於半關閉狀態. 但服務器若發送數據, 客戶機仍要接收, 即從服務器到客戶機的連接仍未關閉.
• 第三次揮手: 若服務器已經沒有了要向客戶機發送的數據, 就通知TCP釋放連接, 此時其發出FIN=1的連接釋放報文FIN=1、ACK=1、seq=w、ack=u+1
• 第四步: 客戶機收到連接釋放報文後, 必鬚髮出確認. 在確認報文中, ACK字段被置爲1, 確認號ack=w+1, 序號seq=u+1. 此時, TCP連接還沒有釋放掉, 必須經過等待計時器設置的時間2MSL（MSL：報文的最大生存時間）後, 客戶端才進入到連接關閉狀態.

幾種狀態得說明：

• FIN_WAIT_1客戶端發送FIN=1得關閉連接得的請求之後進入該狀態

• CLOSE_WAIT :服務端收到客戶端發送得關閉連接的請求後，確認信號是有效的，迴應客戶端之後進入

• FIN_WAIT_2：客戶端收到服務端響應的ACK之後進入。進入半關閉的狀態，只能客戶端只能接受數據，不能發送數據

• LAST_ACK：服務端發送一個FIN關閉信號給客戶端，等待對方確認

• TIME_WAIT：客戶端接收到服務端發送的FIN關閉信號之後進入，等待足夠的時間2MSL，以此確保客戶端收到確認關閉連接的ACK

• CLOSED：連接結束

TCP與UDP協議

• UDP協議：UDP協議全稱是用戶數據報協議，在網絡中它與TCP協議一樣用於處理數據包，是一種無連接的協議。
• TCP協議：TCP協議全稱是傳輸控制協議是一種面向連接的、可靠的、基於字節流的傳輸層通信協議。T

	UDP	TCP
是否連接	無連接，不用關心對方是否接收到	面向連接，需要確保雙方建立正確的連接
是否可靠	不可靠傳輸，不使用流量控制和擁塞控制	可靠傳輸，使用流量控制和擁塞控制
連接對象個數	支持一對一，一對多，多對一和多對多交互通信	只能是一對一通信
首部開銷	首部開銷小，僅8字節	首部最小20字節，最大60字節
適用場景	適用於實時應用（IP電話、視頻會議、直播等），速度要求快	適用於要求可靠傳輸的應用，例如文件傳輸

HTTP

無狀態的，以請求/應答方式運行的協議，她使用可拓展的語義和自描述消息格式，與基於網絡的超文本信息系統（html頁面）靈活的互動

• 無狀態的：不會去存儲用戶的信息
• 請求/應答:發送請求===>得到相應
• 可拓展：在協議的基礎可以對請求頭部添加一些字段
• 自描述：可以傳輸文本、圖片等格式

請求類型

• get：參數掛載在url上，只被用於獲取數據

• post：將實體提交到指定的資源，側重於新增數據

• put：側重於修改數據 ，整體更新

• patch:對put方法的額外補充，用於局部更新

• delete:刪除指定資源

• head：與get相同，但是隻返回響應頭，沒有響應主體

• options：預檢請求，檢查服務器支持哪些http方法，響應體中包含一個Allow字段，包含了所支持的方法

• connect:創建一個客戶端與請求資源之間雙向通信的隧道，點對點通信

• trace：服務端原樣返回接收到的信息，提供了一種用於debug方法

RESTful請求風格

參考阮一峯大佬的REStful API設計指南

RESTful是面向資源請求，url中不能存在動詞，只能有名詞。

https://api.example.com/v1/zoos

對於具體資源的操作，HTTP提供了上面的請求類型，可以使用這些動詞來表對資源進行哪些操作，對於一些參數，比如：獲取Tom的數學成績，用get請求來寫的話，請求地址就是/tom?subject=math，但是用RESTful風格來寫就是/tom/math,列出一些常用例子：

//方法  	接口   				行爲
GET 	/zoos：				列出所有動物園
POST 	/zoos：				 新建一個動物園
GET 	/zoos/ID：			 獲取某個指定動物園的信息
PUT 	/zoos/ID：			 更新某個指定動物園的信息（提供該動物園的全部信息）
PATCH 	/zoos/ID：			 更新某個指定動物園的信息（提供該動物園的部分信息）
DELETE 	/zoos/ID：			 刪除某個動物園
GET 	/zoos/ID/animals：	  列出某個指定動物園的所有動物
DELETE 	/zoos/ID/animals/ID：  刪除某個指定動物園的指定動物

axios裏面同樣提供了這些請求方法的別名

axios.get(url[, config])
axios.delete(url[, config])
axios.head(url[, config])
axios.post(url[, data[, config]])
axios.put(url[, data[, config]])
axios.patch(url[, data[, config]])

請求頭

• Accept 瀏覽器可接受的數據格式

• Accept-Encoding 瀏覽器可接收的壓縮算法，如 gzip

• Accept-lanuage 瀏覽器能接收的語言

• Connection: keep-alive 一次TCP連接重複使用(一次連接，多次使用）

• cookie 非跨域請求都會帶上

• Host請求的域名

• User-Agent(簡稱 UA)發出請求的客戶端，瀏覽器信息

• Content-type 發送方數據的格式，如application/json

  • application/json ：轉化成json字符串形式
  • multipart/form-data: post 傳輸文件
  • application/x-www-form-urlencoded ：form表單默認格式，瀏覽器用x-www-form-urlencoded的編碼方式把form數據轉換成一個字符串（name1=value1&name2=value2）然後把這個字串append到url後面，用?分割，加載這個新的url。 當action爲post時候，瀏覽器把form數據封裝到http body中，然後發送到server。

HTTPS

• 在HTTP協議通信的基礎上，使用SSL/TLS爲網絡通信提供安全及數據完整性的一種安全協議，對網絡連接進行加密

WebSocket

參考WebSocket相關知識

跨域問題

原因

• 同源策略：協議，域名，端口號都相同的話，則稱之爲同源，爲了保證用於信息的安全，不同源的情況下，下面的行爲會受到限制：
  • cookie，localStorage，indexDB無法讀取
  • 無法獲取DOM
  • 請求的響應被瀏覽器攔截

解決方案

jsonp

img、link、script標籤不受同源策略的影響。jsonp本質是動態創建script標籤，利用他不產生跨域的特點，向後臺發送請求

• 前端先聲明一個請求成功之後的回調函數 sayName`
• 前端創建script標籤，後臺接收到請求之後，通過一些處理返回一個函數名，並且把數據當作參數放進去,返回sayName('Tom')
• 請求成功之後數據會被放進去，執行sayName

script加載資源發送的請求是get請求，以至於jsonp也有這個侷限。

node中間件代理

同源策略僅僅是瀏覽器的限制，對於服務器之間的相互請求則不做限制

例如這裏，前端需要向localhost:5000請求數據。項目npm run dev運行的時候，在本地啓動了一個服務4000，前端發送請求的時候會經由4000，然後他再向5000發送請求，4000向5000轉發請求不涉及跨域，請求成功之後，5000給4000返回響應，然後4000再轉發給前端

• 使用vue開發項目時，不可避免的要遇到跨域問題，通常去配置腳手架中的proxyTable(根據腳手架版本)，這裏就是利用了中間件，本地啓動一個服務，所有的請求都發送到本地創建的服務，然後由他轉發給後臺

• react跨域問題同樣用也可以用這個方法解決

CORS

跨域資源共享，關鍵實現在於服務端。

• Access-COntrol-Allow-Origin:關鍵屬性，要麼是請求時Origin字段的值，要麼是一個*，表示接受任意域名的請求。
• Access-Control-Allow-Credentials：默認爲false,表明請求是否攜帶credentials（代表cookies, authorization headers 或 TLS client certificates），Credentials必須在前後端都被配置（即後臺Access-Control-Allow-Credentials 和 前端XHR 或Fetch request中都要配置）才能使帶credentials的CORS請求成功。如果決定要發送cookie，那麼Access-Control-Allow-Origin屬性不能設置成*,必須指定必須的，於請求一致的域名origin
• Access-Control-Expose-Headers：出現在響應頭中，暴露出來的響應頭，供XMLHttpRequest對象的getResponseHeader()獲取額外的頭部信息
• Access-Control-Allow-Methods:出現在預檢請求的響應中，表明服務端支持跨域的方法
• Access-Control-Allow-Headers：出現在預檢請求的響應中，表示服務端支持的所有頭部信息，如果請求頭設置了Access-Control-request-Header，那麼該字段必需。
• Access-Control-Max-Age:出現在預檢請求的響應頭中，表示預檢請求的有效期，單位秒，在這個時間內不在發送預檢請求
• Access-Control-Request-Method:必選，出現在預檢請求的請求頭中，表示真正請求實會採用那種請求方法
• Access-Control-Request-Header:出現在預檢請求的請求頭中，表示服務器在真正的請求中會採用哪些請求頭

Nginx反向代理

正反向代理

配置nginx的nginx.conf文件

瀏覽器訪問 http://localhost:81時，轉發到 https://mywebsite.com

server {
    	#訪問的端口號
        listen       81;
        #訪問的地址
        server_name  localhost; 
        location / {
            root   html;
            index  index.html index.htm;
        #轉發的地址
            proxy_pass https://mywebsite.com;
        }
}

HTTP緩存

參考一文讀懂http緩存

向服務器請求數據時，會又優先查詢瀏覽器緩存，如果緩存中存在需要請求的數據，就直接從瀏覽器緩存中提取出來數據，常見的http緩存只能緩存get請求響應的資源

• http緩存分類：根據是否重新向服務器發起請求來分類，可分爲強緩存和協商緩存

• http緩存過程：

  • 第一步：瀏覽器第一次請求數據，服務端返回資源，在響應頭中添加資源的緩存參數。
  • 第二步：判斷請求的數據，查看是否命中強緩存，如果命中，則返回狀態碼200，從瀏覽器獲取資源,請求不會被髮送到服務端
  • 第三步：未命中強緩存，則向服務器發送請求，服務器會對 比緩存是否失效了，是否更新了，如果資源更新了則返回狀態碼200，從服務器獲取資源，並且更新緩存，如果判斷髮現未更新，則返回狀態碼304，然後去瀏覽器中獲取資源

強制緩存

強制緩存在緩存未過期的情況下，即Cache-Control的max-age屬性或者Expires未過期,那麼就會去返回瀏覽器的緩存，強制緩存生效時，http狀態碼是200，這種方式是頁面加載速度最快的，因爲他沒有與服務器進行交互。但是假如在服務器的資源被修改了，這時候拿到的緩存就不是我們預期的數據了，頁面上刷新了但沒有生效，因爲走的是強制緩存，所以Ctrl + F5一頓操作之後就好了。 跟強制緩存相關的header頭屬性有（Pragma/Cache-Control/Expires）

相關屬性：

• Cache-Control：
  • no-store:禁止任何緩存策策略，請求時服務器都要響應一個新的資源
  • no-cache不使用強緩存，直接去使用協商緩存，與no-cache互斥，同時設置時，以`no-store爲準
  • max-age:代表一個相對的時間長度，相對於客戶端時間，單位是秒,例如Cache-Control:max-age=31536000，意味着在成功請求的31536000秒後過期，每次請求成功會延遲失效時間
  • s-maxage:代理服務器緩存有效時間，public情況下有效
  • private:默認值，只能被瀏覽器緩存
  • public:可以被瀏覽器緩存，也可以被代理服務器緩存，
• Expires設置一個固定的時間，在這個時刻緩存過期,Expires:Mon, 20 Jul 2017 10:08:35 GMT ，在這個時刻之前都是有效的，請求成功不會延時失效時間，一般情況下都是使用Cache-Control

協商緩存

響應頭中沒有Cache-Control和Expires或者Cache-Control和Expires過期還或者它的屬性設置爲no-cache時(即不走強緩存)，那麼瀏覽器第二次請求時就會與服務器進行協商（通過判斷last-modified/if-modified-since是否一致或者Etag/If-None-Match是否一致），與服務器端對比判斷資源是否進行了修改更新。服務端資源沒有更改，則返回304.然後從瀏覽器獲取資源，已更改則從服務器獲取資源，返回200

實現協商緩存的兩種方式：

• Last-modified:存在於響應頭中，標識文件的最後修改時間
• If-modified-Since:存在於請求頭裏面，值爲之前返回的last-modified

上面一組屬性可以解決大部分緩存情況，但是存在一些不足，他們的時間戳單位是秒，也就是說，如果發生修改資源的太快，在擊幾百毫秒之內完成，對於他們來說仍是相等的，無法識別出資源已經更新。另外也可能存在只改變文件名而不改變文件內容的情況，這種情況會被認定爲資源更新，會去服務請資源而耗費性能。對於着二者的缺點，可以使用 Etag/If-None-Match的方案優化

• Etag:存在於文件的哈希值，唯一的，資源改變會改變它的Etag
• If-None-Match:存在於請求頭，值爲之前返回的Etag

比較上面兩種協商緩存的方案，他們都有一個共同流程，首次請求服務端返回一個標識放在響應頭中，第二次及以後的請求都會將響應頭的這個值放在請求頭中，通過比較兩個值來判斷資源是否更改

這種方案並不能完全替代last-modified,他只能作爲一種補充，因爲它同樣存在一些不足，首先，文件的哈希值需要服務器去計算，對服務器造成了額外的開銷，尤其對於一些大文件或者文件數目很多的情況，頻繁計算文件哈希值造成了性能的而損耗。另外，生成etag的過程中存在精度問題，某些情況會造成比對失敗

總結

• 緩存決策過程：

• 不同類型的文件緩存方案：

  具體的緩存方案需要根據實際的開發場景來決定

  • html文件需要及時的更新，需要設置成協商緩存
  • 圖片文件等媒體文件較大，可能會定期的替換更改，可以設置較短時間的強制緩存
  • css樣式文件，js腳本文件可以可以設置較長時間的強緩存

• 刷新頁面的行爲

  • F5 刷新頁面 仍然會去查找瀏覽器種的強緩存然後去找協商緩存
  • Ctrl+F5 強制刷新 Cache-Control會變成·no-chche即不走強緩存

瀏覽器存儲方案

cookie、localStorage、sessionStorage的使用

安全

XSS

跨站腳本攻擊，向客戶端插入腳本，用戶打開網頁或者點擊某個按鈕會運行注入的腳本

參考於美團技術團隊： 如何防止XSS攻擊

注入的情景

• 在 HTML 中內嵌的文本中，惡意內容以 script 標籤形成注入。渲染文本時，後臺返回的數據包含script標籤

<h1>前端渲染後臺返回的數據： <script>alert(1)</script> </h1>

• 在內聯的 JavaScript 中，拼接的數據突破了原本的限制（字符串，變量，方法名等）。

  <script>
      let backendData = alert(1) //後端的數據
      let data = backendData //前端對這些數據進行操作
      console.log(data)
    </script>

• 在標籤屬性中，惡意內容包含引號，從而突破屬性值的限制，注入其他屬性或者標籤。

後臺返回的數據   "><script>alert('XSS');</script>
<input type="text" value="<%= getParameter("keyword") %>">
拼接後：
<input type="text" value=""><script>alert('XSS');</script>">

• 在標籤的 href、src 等屬性中，包含 javascript: 等可執行代碼。

後臺返回的數據：javascript:alert('XSS')
<a href="<%= escapeHTML(getParameter("redirect_to")) %>">跳轉...</a>
拼接後
<a href="javascript:alert('XSS')">跳轉...</a>

• 在 onload、onerror、onclick 等事件中，注入不受控制代碼。
• 在 style 屬性和標籤中，包含類似 background-image:url("javascript:..."); 的代碼（新版本瀏覽器已經可以防範）。
• 在 style 屬性和標籤中，包含類似 expression(...) 的 CSS 表達式代碼（新版本瀏覽器已經可以防範）。

XSS分類

根據攻擊的來源，XSS 攻擊可分爲存儲型、反射型和 DOM 型三種。對於前兩種，後端應該做好防護，而第三種DOM型需要前端防範

• 存儲型：提交惡意代碼到數據庫中，用戶打開頁面時，從後臺取出這些數據，然後拼接數據，瀏覽器渲染頁面的時候會執行這些代碼，常見於評論，私信，發佈文章等場景
• 反射型：構造出特殊的URL，用戶點擊跳轉這個URL時，惡意代碼也被解析執行。常見於通過 URL 傳遞參數的功能，如網站搜索、跳轉等。與存儲型不同的是：存儲型 XSS 的惡意代碼存在數據庫裏，反射型 XSS 的惡意代碼存在 URL 裏。
• DOM型：攻擊者構造出特殊的 URL，用戶打開帶有惡意代碼的 URL，惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操作

如何防範

對於存儲型和反射性

他們都是從後臺取出惡意代碼，然後再html中被拼接，被瀏覽器執行，有兩種方法預防：

• 改成純前端渲染，把代碼和數據分隔開。這在很多內部、管理系統中常用

  1. 瀏覽器先加載一個靜態 HTML，此 HTML 中不包含任何跟業務相關的數據。
  2. 然後瀏覽器執行 HTML 中的 JavaScript。
  3. JavaScript 通過 Ajax 加載業務數據，調用 DOM API 更新到頁面上。明確的告訴瀏覽器：下面要設置的內容是文本（.innerText），還是屬性（.setAttribute），還是樣式（.style）等等。瀏覽器不會被輕易的被欺騙，執行預期外的代碼了

• 對 HTML 做充分轉義。採用合適的轉義庫，如 doT.js、ejs、FreeMarker 等，對 HTML 模板各處插入點進行充分的轉義。把一些關鍵字符力例如& < > " ' /等轉義掉，HTML 的編碼是十分複雜的，在不同的上下文裏要使用相應的轉義規則

對於DOM型

• DOM型是因爲頁面把不可信的數據當成了代碼執行，所以在使用 .innerHTML、.outerHTML、document.write() 時要特別小心，不要把不可信的數據作爲 HTML 插到頁面上，而應儘量使用 .textContent、.setAttribute() 等，對於Vue/React 技術棧，儘量不使用 v-html/dangerouslySetInnerHTML 功能，在前端 render 階段避免 innerHTML、outerHTML 的 XSS 隱患。DOM 中的內聯事件監聽器，如 location、onclick、onerror、onload、onmouseover 等，<a> 標籤的 href 屬性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作爲代碼運行。如果不可信的數據拼接到字符串中傳遞給這些 API，很容易產生安全隱患，

其他防範措施

• 對要提交的輸入內容做長度限制
• 對cookie設置http-only屬性，禁止前端瀏覽器讀取cookie
• 驗證碼：防止腳本冒充用戶提交危險操作

CSRF

參考美團技術團隊 如何防止CSRF攻擊

跨站請求僞造，引導用戶進入第三方網站中，然後發送請求，冒充用戶身份，對被攻擊的網站執行某些操作，

常見攻擊類型

• GET請求類型，進入第三方網站後，瀏覽器請求圖片資源，然後發送向被攻擊網站發送請求

//從 bank.example 中拿到用戶cookie
<img  style="width:0;" src="http://bank.example/withdraw?amount=10000&for=hacker" > 

• POST請求，進入第三發放網站自動提交表單發送一個post請求

<form method="POST" action="https://bank.example/xxx" enctype="multipart/form-data"> 
    <input type="hidden" name="name" value="xiaoming"/> 
    <input type="hidden" name="amount" value="10000"/>
</form> 
<script> 
    document.forms[0].submit();
</script>

• 跳轉連接，誘導用戶點擊頁面中的鏈接，在連接中僞造請求

<a href="http://bank.example/withdraw?amount=10000&for=hacker" taget="_blank">重磅消息！！ <a/>

如何防範

CSRF只是冒用cookie，並不能獲取到cookie的實際值，另外，CSRF通常發生在第三方網站

同源檢測

• Origin（只有協議、域名、端口號。不包含路徑的詳細信息） 或者Referer（協議、域名、端口號、參數。頁面來源的詳細地址）。包含了請求的來源信息，可以判斷請求的來源，禁排除掉外域（或者不受信任的域名）的請求操作

SameSite屬性

SamesiteCookie是一個可能替代同源驗證的方案，但目前還並不成熟，其應用場景有待觀望。

• SameSite=None不做限制，瀏覽器會在同站請求、跨站請求下繼續發送 cookies
• SameSite=Strict:只在訪問相同站點時發送 cookie
• SameSite=Lax:假如這個請求是這種請求（改變了當前頁面或者打開了新頁面）且同時是個GET請求，則這個Cookie可以作爲第三方Cookie

JWT驗證

• 後端根據用戶生成一個Token，然後把Token返回給前端，前端保存Token
• 調用其他接口進行交互時，新增一個請求頭字段，放Token
• 後臺接收到Token時比驗證Token是否一致

其他防範措施

• get請求不要包含增改刪功能，僅查詢數據
• 對於用戶來說，儘量避免打開可疑鏈接，或者用不常用的瀏覽器打開

攻擊者誘導受害者進入第三方網站，再第三方的網站中，向被攻擊的網站發送請求，由於再第三方網站中，用戶存在cookie，已經完成身份驗證，所以在

Fetch

參考文檔 ：使用Fetch

Fetch作爲一種Http請求方案，是XHR的代替方案，注意Fetch是基於Promise原生的API，而Axios是基於Promise的庫，Fetch使用方法與Axios十分類似，注意post請求時，fetch傳遞的時body屬性，值是對象轉化成字符串JSON.stringify(data)

拓展

TCP三次握手連接的原因

首先要知道TCP三次握手的目的是什麼：爲了確保雙方的發送和接收能力都是正常且可靠的

• 不能採用兩次握手的原因：結合三次握手的流程圖來看，去掉第二次握手----服務端向客戶端的響應的話，客戶端不能確認服務端是否具有正常的發送功能，額外舉個例子：客戶端顯示發送了一個連接請求，但是由於某些原因導致他一致在傳輸的路上，沒有被客戶端收到。這個時候客戶端會認爲這個請求是不是發送出錯了，然後又給客戶端發送了一條連接請求，然後巧了，客戶端收到了這個請求，雙方於是建立了連接，傳輸了數據，然後斷開了連。然而這個時候客戶端發送的第一條連接請求終於到了，服務端收到了，於是又建立了連接，造成服務端資源的浪費
• 不採取四次握手的原因：三次握手完全足夠雙方確認是否能夠正常收發信息，不需要額外的握手交互了

TC四次揮手的原因

• 客戶端在發送斷開連接的請求·FIN之後，服務端並不能及時的響應斷開連接的請求FIN，必須等到服務端所有的報文都發送完畢，這個過程需要一定時間。去除第二次服務端給客戶端的迴應的話，期間等待服務端發送完畢的過程中，長時間沒回應的話，客戶端會認爲丟包，然後又給服務端發了一個FIN關閉請求，這時就會出現問題。

正向代理與反向代理

正向代理是客戶端和其他所有服務器（重點：所有）的代理者，而反向代理是客戶端和反向代理服務器所代理的服務器之間的代理（也就是說反向代理有可能代理2個服務器，3個服務器等）

• 正向代理：多個用戶向代理服務器發送請求，然後轉發給一個目標服務器，比如 FQ提子
• 反向代理：一個用戶向代理服務器發送請求，然後代理服務器推斷請求，發送到多個服務器中的一個