14期-連肝7個晚上，總結了計算機網絡的知識點！（共66條）

時間 2020-07-20

標籤晚上總結計算機網絡知識简体版

原文原文鏈接

前言

計算機網絡知識，是面試常考的內容，在實際工做中也經常會涉及到。javascript

最近總結了66條計算機網絡相關的知識點，你們一塊兒看一下吧：（投入本身的思考，一塊兒來解決知識點，探討問題）css

1.比較http 0.9和http 1.0😀

http0.9只是一個簡單的協議，只有一個GET方法，沒有首部，目標用來獲取HTML。
HTTP1.0協議大量內容：首部，響應碼，重定向，錯誤，條件請求，內容編碼等。

http0.9流程：html

客戶端，構建請求，經過DNS查詢IP地址，三次握手創建TCP鏈接，客戶端發起請求，服務器響應，四次揮手，斷開TCP鏈接。（一個來回：服務器收到請求信息，讀取對應的文件如HTML，並將數據返回給客戶端）前端

http1.0流程：java

客戶端，構建請求，經過DNS查詢IP地址，三次握手創建TCP鏈接，客戶端發起請求，服務器響應，四次揮手，斷開TCP鏈接。（多個來回：HTTP1.0引入請求投和響應頭，因爲出現瞭如Js,css等多種形式的文本，http0.9以知足不了需求，so，引入了content-encoding，content-type等字段）mysql

由於不足缺陷，就有了http1.1。程序員

2.關於http1.1以及http2😁

http1.1中瀏覽器不再用爲每一個請求從新發起TCP鏈接了，增長內容有：緩存相關首部的擴展，OPTIONS方法，Upgrade首部，Range請求，壓縮和傳輸編碼，管道化等。但仍是知足不了如今的web發展需求，so，就有了http.2版本。web

http2解決了（管道化特性可讓客戶端一次發送全部的請求，可是有些問題阻礙了管道化的發展，便是某個請求花了很長時間，那麼隊頭阻塞會影響其餘請求。）http中的隊頭阻塞問題。面試

使用http2會比http1.1在使用TCP時，用戶體驗的感知多數延遲的效果有了量化的改善，以及提高了TCP鏈接的利用率（並行的實現機制不依賴與服務器創建多個鏈接）算法

因此須要學習http2，瞭解更過的內容來掌握計算機網咯。

對於http2，你能夠來運行一個http2的服務器，獲取並安裝一個http2的web服務器，下載並安裝一張TLS證書，讓瀏覽器和服務器經過http2來鏈接。（從數字證書認證機構申請一張證書）。

瞭解http2的協議，先讓咱們瞭解一下web頁面的請求，就是用戶在瀏覽器中呈現的效果，發生了些什麼呢？

資源獲取的步驟：

把待請求URL放入隊列，判斷URL是否已在請求隊列，否的話就結束，是的話就判斷請求域名是否DNS緩存中，沒有的話就解析域名，有的話就到指定域名的TCP鏈接是否開啓，沒有的話就開啓TCP鏈接，進行HTTPS請求，初始化並完成TLS協議握手，向頁面對應的URL發送請求。

接收響應以及頁面渲染步驟：

接收請求，判斷是否HTML頁面，是就解析HTML，對頁面引用資源排優先級，添加引用資源到請求隊列。（若是頁面上的關鍵資源已經接收到，就開始渲染頁面），判斷是否有還要繼續接收資源，繼續解析渲染，直到結束。

3.HTTP的幾種請求方法用途😂

第一種GET方法：發送一個請求來獲取服務器上的某一些資源。

第二種POST方法：向URL指定的資源提交數據或附加新的數據。

第三種PUT方法：跟POST方法同樣，能夠向服務器提交數據，可是它們之間也全部不一樣，PUT指定了資源在服務器的位置，而POST沒有哦。

第四種HEAD方法：指請求頁面的首部。

第五種DELETE方法：刪除服務器上的某資源。

第六種OPTIONS方法：它用於獲取當前URL所支持的方法，若是請求成功，在Allow的頭包含相似GET,POST等的信息。

第七種TRACE方法：用於激發一個遠程的，應用層的請求消息迴路。

第八種CONNECT方法：把請求鏈接轉換到TCP/TP通道。

4.從瀏覽器地址欄輸入url到顯示頁面的步驟🤣

簡單說說，瀏覽器根據請求的url交給dns域名解析，查找真正的ip地址，向服務器發起請求；服務器交給後臺處理後，返回數據，瀏覽器會接收到文件數據，好比，html,js，css，圖像等；而後瀏覽器會對加載到的資源進行語法解析，創建相應的內部數據結構；載入解析到得資源文件，渲染頁面，完成顯示頁面效果。

🙅不夠清楚明白碼？

那就再次詳細一下，咳咳，從瀏覽器接收url，開始進行網絡請求線程，發出一個完整的HTTP請求，從服務器端接收請求到對應的後臺接收到請求，而後是後臺和前臺的http交互；其中的緩存問題（http的緩存），瀏覽器接收到http數據包後的解析流程，css的可視化格式模型，js引擎解析過程等；其餘呈現頁面效果。

🙅：這裏就須要你對瀏覽器內核的理解：其中主要的渲染引擎和JS引擎，這裏瞭解一下你對瀏覽器內核的理解。

渲染引擎，是負責取得網頁的內容，整理信息，以及計算網頁的顯示方式，而後輸出到顯示器上。
JS引擎是用於解析和執行javascript來實現網頁的動態效果。

瀏覽器的內核的不一樣對於網頁的語法解釋會有不一樣，因此渲染的效果也不相同。其實最開始渲染引擎和JS引擎是沒有區分明確的，不事後來JS引擎愈來愈獨立，so，內核就傾向於渲染引擎。

對於資源請求/獲取,資源響應/頁面渲染，會給網絡帶寬和設備資源帶來壓力，這個時候就會考慮到web的性能優化。

5.web的性能優化😃

其中裏面的性能關鍵：

什麼是數據包數據包（IP數據包），指封裝在固定結構的一系列字節，它定義了數據包的長度，傳輸的細節，以及其餘與TCP相關的信息。

延遲：指IP數據包從一個網絡端點到另外一個網絡端點所花費的時間。（所花費時間在於往返時延，是延遲的時間的兩倍）

帶寬：只要帶寬沒有飽和，兩個網絡端點的鏈接會一次處理儘量多的數據量（因此帶寬可能會成爲性能的瓶頸）

創建鏈接時間：在客戶端和服務器之間創建鏈接往返數據（三次握手）

TCP三次握手過程：客戶端向服務器發起一個SYN包，服務器端返回對應的SYN的ACK響應以及新的SYN包，而後客戶端返回對應的ACK。（在客戶端和服務器之間創建正常的TCP網絡鏈接時，客戶端首先發出一個SYN消息，服務器使用SYN+ACK應答表示接收了這個消息，最後客戶端再以ACK消息響應。）

SYN是同步序列編號，是TCP/IP創建鏈接時使用的握手信息。 ACK是確認字符，在數據通訊中，接收站發給發送站的一種傳輸類控制字符。表示發來的數據已確認接收無誤。在TCP/IP協議中，若是接收方成功的接收到數據，那麼會回覆一個ACK數據。經過ACK信號有本身固定的格式，長度大小，由接收方回覆給發送方。

詳解三次握手：

第一次握手，創建鏈接時，客戶端發送SYN包到服務器，並進入SYN_SENT狀態，等待服務器確認，其中SYN就是同步序列編號。

第二次握手，服務器收到SYN包，必須確認客戶的SYN，同時本身也發送一個SYN包，便是SYN+ACK包，此時服務器進入SYN_RECV狀態。

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

完成三次握手，客戶端與服務器開始傳送數據。

TLS協商時間（TLS會形成額外的往返傳輸）

客戶端發起https鏈接，須要進行傳輸層安全協議協商
TLS用來取代安全套接層SSL

除了網絡，還有頁面內容自己或服務器性能，如首字節時間TTFB，內容下載時間，開始渲染時間，文檔加載完成的時間等。

那麼什麼是TTFB，它是指客戶端從開始定位到web頁面，至接收到主體頁面響應的第一字節所耗費的時間。它是測量：從瀏覽器發起請求至收到其第一字節之間的耗時。

內容下載時間是等同於被請求資源的最後字節到達時間。

開始渲染時間，從客戶看到空白頁面的時長。

5.1web性能優化技術（減小客戶端網絡延遲和優化頁面渲染性能來提高web性能）

優化技術：

DNS查詢優化
客戶端緩存
優化TCP鏈接
避免重定向
網絡邊緣的緩存
條件緩存
壓縮和代碼極簡化
圖片優化

6. http1.1😄

改進持久鏈接和CDN域名的分片機制
不成熟的http管道化
提供虛擬主機支持
對動態生成的內容完美支持
引入cookie以及安全機制

對於http1的問題，迎來了http2。其中http1的問題：

隊頭阻塞，大多數狀況下，瀏覽器會但願同時獲取許多資源，但http1未提供機制來同時請求這些資源，若是僅是使用一個鏈接，須要發起請求，等待響應，而後才能發起下一個請求。

在http1中要給特性爲管道化，能夠容許一次發送一組請求，可是須要按照發送順序依次接收響應。因此在請求應答過程當中，如發生什麼狀況，剩下的工做都會被阻塞，這就是「隊頭阻塞」（阻塞在那次請求應答發生錯誤），阻礙網絡傳輸和web頁面的渲染，指導失去響應。

低效的TCP利用，TCP協議做爲最可靠的協議之一，其核心是擁塞窗口。

擁塞窗口，是衛星通訊在因特網中防止通訊擁塞的一種措施，它是在發端採用了一種「擁塞避免」算法和「慢速啓動」算法相結合的機制。「擁塞窗口」就是「擁塞避免」的窗口，它是一個裝在發送端的可滑動窗口，窗口的大小是不超過接收端確認通知的窗口。

擁塞窗口指在接收方確認數據包以前，發送方能夠發送的TCP包的數據。（如擁塞窗口指定爲1的狀況，那麼發送方就發出1哥數據包以後，只有接收方確認了那個發出的數據包，才能發送下一個）

擁塞控制能防止過多的數據注入到網絡中，用於避免網絡過載，TCP中能夠經過慢啓動探索當前鏈接對應擁塞窗口的合適大小。即發送者發送數據的時候並不是一開始注入大量數據到網絡中，而是發送一個數據包進行測試，當獲得確認回覆後，額外發送一個未確認包。

這意味着獲得一個確認回覆，能夠發送兩個數據包，獲得兩個確認回覆，能夠發送四個數據包，以幾何形式增加很快到達協議規定的擁塞窗口大小（發包數上限），這時候鏈接進入擁塞避免階段，這種機制須要往返幾回才能得知最佳擁塞窗口大小，但往返幾回所需的時間成本不可忽略。

擁塞窗口的大小取決於網絡的擁塞程度，而且動態地在變化。發送方讓本身的發送窗口等於擁塞窗口。若是再考慮到接收方的接收能力，那麼發送窗口還可能小於擁塞窗口。
發送方控制擁塞窗口的原則是：只要網絡沒有出現擁塞，擁塞窗口就再增大一些，以便把更多的分組發送出去。但只要網絡出現擁塞，擁塞窗口就減小一些，以減小注入到網絡中的分組數。

tcp中的慢啓動概念，是用來探索當前鏈接對應擁塞窗口的合適大小。用來弄清楚新鏈接當前的網絡狀況。「慢速啓動」是在鏈接創建後，每收到一個來自收端的確認，就控制窗口增長一個段值大小，當窗口值達到「慢速啓動」的限值後，慢速啓動便中止工做，避免了網絡發生擁塞。

TCP傳輸控制協議的設計思路是，對假設狀況很保守狀況下，可以公平對待同一網絡的不一樣流量的應用，它的避免擁塞機制被設計城即便在最差的網絡狀況下也能夠起做用。

臃腫的消息首部，HTTP/1.1能壓縮請求內容，可是消息首部卻不能壓縮。它可能佔據請求的絕大部分（也多是所有）也是比較常見了。（在這裏若是能壓縮請求首部，把😙請求變得更小，就可以緩解帶寬壓力了，下降系統的總負載）

受限的優先級設置，即若是瀏覽器針對指定域名開啓多個socket請求，若web頁面某些資源會比另一些資源重要，會加劇資源的排隊效應，會延遲請求其餘的資源，優先級高的資源先獲取，優先級低的資源會在資源高的資源處理完成，（在處理過程當中，瀏覽器不會發起新的資源請求）等待高的完成後再發起請求，(這就會讓總的頁面下載時間延長)。

在請求優先級高的資源的時間區間內瀏覽器並不會發起優先級較低的新請求

小結：HTTP1.1慢啓動影響資源首次加載速度，TCP創建鏈接後，會開始請求傳輸，開始比較慢，而後不斷加快，爲了防止出現網絡擁堵，會讓頁面的首次渲染時間變長。開始多個tcp，如出現網絡降低，沒法識別資源的優先級，會出現競態問題。

7.如何進行網站性能優化😅

內容方面，減小Http請求（合併文件，css精靈，inline Image)，減小DNS查詢（DNS緩存，將資源分佈到合適的數量的主機名），減小DOM元素的數量。
Cookie方面，能夠減小Cookie的大小。
css方面，將樣式表放到頁面頂部；不使用css表達式；使用<link>不使用@import；可將css從外部引入；壓縮css。
JavaScript方面，將腳本放到頁面底部；將JavaScript從外部引入；壓縮JavaScript，刪除不須要的腳本，減小DOM的訪問。
圖片方面，可優化css精靈，不要再HTML中拉伸圖片，優化圖片（壓縮）。

8.http狀態碼以及含義😆

對於1xx的狀態碼，爲信息狀態碼，100 爲繼續，表示確認，成功返回具體參數信息。
對於2xx的狀態碼，200 表示正常返回信息，201表示請求成功而且服務器建立了新的資源，202表示服務器已接受請求，但還沒有處理。
對於3xx，重定向，301表示，請求的網頁已永久移動到新位置，302表示，臨時性重定向，303表示臨時性重定向，且老是使用 GET 請求新的 URI。304表示，自從上次請求後，請求的網頁未修改過。
對於4xx，客戶端錯誤，404，服務器沒法理解請求的格式，客戶端不該當嘗試再次使用相同的內容發起請求，401，請求未受權，403，禁止訪問，404，找不到如何與 URI 相匹配的資源。
對於5xx，服務器錯誤，500，最多見的服務器端錯誤，503，服務器端暫時沒法處理請求，多是過載或維護。

9.http-數據壓縮😉

數據壓縮，在瀏覽器中發送請求時會帶着Content-Encoding: gzip，裏面時瀏覽器支持的壓縮格式列表，有多種如，gzip，deflate，br等。這樣服務器就能夠從中選擇一個壓縮算法，放進Content-Encoding響應頭裏，再把原數據壓縮後發給瀏覽器。

10.http-分塊傳輸😊

分塊傳輸，就是將傳輸的文件分解成多個小塊，而後分發給瀏覽器，瀏覽器收到後再從新組裝復原。

每一個分開包含兩個部分，分塊長度和分塊數據（長度頭和數據塊），長度頭以CRLF結尾的一行明文，數據塊緊跟在長度頭後面，也是用CRLF結尾，最後用一個長度爲0的塊表示結束。

在響應報文裏用頭字段Transfer-Encoding:chunked表示報文裏的body部分不是一次性發送過來的，而是分紅了許多塊逐個發送的。

在Transfer-Encoding：chunked和Content-Length中，這兩個字段是互斥的。

一個響應報文的傳輸長度要麼已知，要麼長度未知（chunked）。

Content-Length: 299

11.http-範圍請求😋

斷點續傳

要實現該功能須要制定下載的實體範圍，這種制定範圍發送請求叫作範圍請求。

Accept-Ranges：服務器使用http響應頭Accept-Ranges標識自身支持範圍請求，字段的具體值用於定義範圍請求的單位。

語法

Accept-Ranges: bytes,範圍請求的單位是 bytes （字節）
Accept-Ranges: none,不支持任何範圍請求單位
複製代碼

範圍請求時用於不須要所有數據，只須要其中的部分請求時，可使用範圍請求，容許客戶端在請求頭裏使用專用字段來表示只獲取文件的一部分。

Range的格式，請求頭Range是HTTP範圍請求的專用字段，格式是「bytes=x-y」,以字節爲單位的數據範圍。

「0-」表示從文檔起點開始到文檔結束的整個文件。
「100-」表示從第100哥字節開始到文檔末尾。
「-10」表示從文檔末尾倒數的第10個字節開始。

示例：

執行範圍時會使用頭部字段 Range 來指定資源 byte 的範圍。
Range格式：
5001-10000字節
Range : byte = 5001-10000
5000以後的
Range : byte = 5001-
0-3000字節，5001-10000字節
Range : byte=-3000,5001-10000
複製代碼

上圖表示服務器收到Range字段後，檢測範圍合法性，範圍越界，就會返回狀態碼416，如你的文件只有1000個字節，但請求範圍在20000-3000，就會致使這個狀態碼的出現。

若是成功讀取文件，範圍正確，返回狀態碼「206」。服務器要添加一個響應頭字段Content-Range,告訴片斷的實際偏移量和資源的總大小。

最後是發送數據，直接把片斷用TCP發給客戶端，一個範圍請求就算是處理完了。

格式是「bytes x-y/length」,與Range頭區別在沒有「=」

Content-Range: bytes 0-4395719/4395720

12.http-多段數據😎

多端數據，就是在Range頭裏使用多個「x-y"，一次性獲取多個片斷數據。使用一種特殊的MIME類型：「multipart/byteranges」，用來表示響應報文包含了多個範圍時使用。多重範圍請求響應會在頭部 Content-Type 代表 multipart-byteranges。

多段數據圖：分隔標記boundary來區分不一樣的分段

13.說一說cookies，sessionStorage 和 localStorage 的區別？😍

cookie是網站用來標識用戶身份而存儲在用戶本地終端上的數據
cookie數據始終在同源的http請求中攜帶，即便是不須要的狀況，so，會在瀏覽器和服務器間來回傳遞
sessionStorage和localStorage不會自動把數據發送給服務器，僅僅在本地保存

存儲的大小

cookie的數據大小不能超過4k；sessionStorage和localStorage雖然也有存儲大小的限制，但比cookie大得多，能夠達到5M或者更大。

有限期時間

localStorage存儲持久數據，瀏覽器關閉後數據不會丟失，除了主動刪除數據
sessionStorage數據在當前瀏覽器窗口關閉後自動刪除
設置得cookie過時時間以前都有效，就算窗口或者是瀏覽器關閉

14.爲何說利用多個域名來存儲網站資源會更有效？😘

由於CDN緩存更方便；突破瀏覽器併發限制；節約cookie帶寬；節約主域名得鏈接數，優化頁面響應速度；防止沒必要要得安全性問題。

15.http2.0的內容🥰

http2是超文本傳輸協議的第二版，相比http1協議的文本傳輸格式，http2是以二進制的格式進行數據傳輸的，具備更小的傳輸體積以及負載。

http2.0分層，分幀層（http2多路複用能力的核心部分),數據或http層（包含傳統上被認爲是 HTTP 及其關聯數據的部分）。

HTTP2.0：

多路複用機制，引入了二進制的分幀層機制來實現多路複用。（分幀層是基於幀的二進制協議。這方便了機器解析。請求和響應交織在一塊兒。）
能夠設置請求的優先級（客戶端的分幀層對分割塊標上請求的優先級）。
頭部壓縮請求頭壓縮，增長傳輸效率。

HTTP/2較HTTP/1.1優化亮點

多路複用的流
頭部壓縮
資源優先級和依賴設置
服務器推送
流量控制
重置消息

多路複用的實現：

在單個域名下仍能夠創建一個TCP管道，使用一個TCP長鏈接，下載整個資源頁面，只須要一次慢啓動，而且避免了競態，瀏覽器發起請求，分幀層會對每一個請求進行分割，將同一個請求的分割塊打上相同的id編號，而後經過協議棧將全部的分割體發送給服務器，而後經過服務器的分幀層根據id編號進行請求組裝，服務器的分幀層將回應數據分割按同一個迴應體進行ID分割回應給客戶端，客戶端拼裝回應。

對於http2中的幀（frame），http1不是基於幀（frame）的，是文本分隔的。

GET/HTTP/1.1 <crlf>

這樣，對於http1的請求或者是響應可能有的問題：

一次只能處理一個請求或者是響應，完成以前是不能中止解析的。
沒法預判解析須要多少內層。

HTTP/1 的請求和響應報文，是由起始行、首部和正文組成，換行符分隔；HTTP/2是將請求和響應數據分割成更小的幀，採用二進制編碼，易於解析的。

參考圖片：

幀結構總結全部的幀都包含一個9 byte的幀頭 + 可邊長的正文不一樣。根據幀的類型不一樣，正文部分的結構也不同。

幀頭：

16.http2-幕後😗

http2做爲一個二進制協議，擁有包含輕量型，安全和快速在內的全部優點，保留了原始的http協議語義，對於http2更改了在系統之間傳輸數據的方式。

二進制分幀層（binary framing layer），全部通訊都在單個TCP鏈接上執行，該鏈接在整個對話期間一直處於打開狀態，主要是二進制協議將通訊分解爲幀的方式，這些幀交織在客戶端與服務器之間的雙向邏輯流中。

HTTP/2 鏈接的拓撲結構(展現了一個用於創建多個流的鏈接)

在流 1 中，發送了一條請求消息，並返回了相應的響應消息。

HTTP/2 幀結構

前9個字節對於每一個幀是一致的。解析時只須要讀取這些字節，就能夠準確地知道在整個幀中指望的字節數。

幀首部字段表格：

名稱	長度	描述
length	3字節	表示幀負載的長度
type	1字節	當前幀類型
Flags	1字節	具體幀類型的標識
R	1位	保留位，不要設置，不然會帶來嚴重後果
Stream Identifier	31位	每一個流的惟一ID
Frame Payload	長度可變	真實的幀內容,長度是在length字段中設置的

備註：流Id是用來標識幀所屬的流。流看做在鏈接上的一系列幀，它們構成了單獨的 HTTP 請求和響應。

對於http1 的請求和響應都分紅消息首部和消息體兩部分；http2 從上面一張圖能夠知道，http2的請求和響應分紅HEADERS 幀和 DATA 幀。

比較一下：👇

http2的一個重要特性是基於流的流量控制。提供了客戶端調整傳輸速度的能力。其中WINDOW_UPDATE 幀用來指示流量控制信息。

有了多路複用，客戶端能夠一次發出多有資源的請求，不用像http1那樣，發出對新對象請求以前，須要等待前一個響應完成。因此瀏覽器失去了在Http1中的默認資源請求優先級策略。

17.瀏覽器生成http請求消息😙

http的頭字段

頭字段類型	含義
Date	表示請求和響應生成的日期
Pragma	表示數據是否容許緩存的通訊選項
Cache-Control	控制緩存的相關信息
Connection	設置發送響應以後TCP鏈接是否繼續保持的通訊選項
Transfer-Encoding	表示消息主體的編碼格式
Via	記錄途中通過的代理和網關
Authorization	身份認證數據
From	請求發送者的郵件地址
Referer	當經過點擊超級連接進入下一個頁面時，在這裏會記錄下上一個頁面的URI
User-Agent	客戶端軟件的名稱和版本號等相關信息
Accept	客戶端可支持的數據類型，以MIME類型來表示
Accept-Charset	客戶端可支持的字符集
Accept-Language	客戶端可支持的語言
Host	接收請求的服務器ip地址和端口號
Range	當須要只獲取部分數據而不是所有數據時，可經過這個字段指定要獲取的數據範圍
Location	表示信息的準確位置
Server	服務器程序的名稱和版本號等相關信息
Allow	表示指定的URI支持
Content-Encoding	當消息體通過壓縮等編碼處理時，表示其編碼格式
Content-Length	表示消息體的長度
Content-Type	表示消息體的數據類型，以MIME規格定義的數據類型來表示
Expires	表示消息體的有效期
Last-Modified	數據的最後更新日期
Content-Language	表示消息體的語言
Content-Location	表示消息體在服務器上的位置
Content-Range	當僅請求部分數據時，表示消息體包含的數據範圍

HTTP消息示例：

HTTP,超文本傳送協議。
協議，通訊操做的規則定義稱爲協議。
URI，統一資源標識符。
1 條請求消息中只能寫 1 個 URI。若是須要獲取多個文件，必須對每一個文件單獨發送 1 條請求。

IP 的基本思路

Ip地址的表示方法

IP地址的結構-子網掩碼錶示網絡號與主機號之間的邊界。

解析器的調用方法

DNS服務器的基本工做

DNS 服務器之間的查詢操做

數據經過相似管道的結構來流動

18.瞭解網絡基礎知識🙂

物理層
數據鏈路層
網絡層
傳輸層
會話層
表示層
應用層

計算機網絡，能夠將規模分WAN,Wide Area Network廣域網，和LAN局域網。經過電腦鏈接交換機再到路由器的鏈接。

你知道計算機與網絡都經歷了怎麼樣的一個發展過程嗎？

批處理就是指事先將用戶程序和數據裝入卡帶或磁帶，由計算機按照必定的順序讀取，使用戶所要執行的這些程序和數據可以一併批量獲得處理的方式。

分時系統，是指多個終端與同一個計算機鏈接，容許多個用戶同時使用一臺計算機的系統。

計算機網絡

TCP/IP的機制是什麼，TCP/IP通訊協議的統稱，學習這個有人必定🙅不瞭解什麼是協議。

但咱們在接觸到程序時，經常聽到協議如IP，TCP，HTTP等協議。記住TCP/IP就是IP,TCP,HTTP等協議的集合。協議就是計算機與計算機之間經過網絡實現通訊時須要達成的一種的「約定」。這些協議就是讓不一樣廠商的設備，不一樣的CPU和不一樣的操做系統組成的計算機之間進行通訊。

就是兩臺計算機之間都能支持相同的協議，並遵循才能實現相互通訊。

分組交換協議

分組交換就是將大數據分割成一個一個叫作包的較小單位進行傳輸的方法。

分層模塊

瞭解OSI參考模型

OSI將分爲易於理解的7層：

1.物理層，2.數據鏈路層，3.網絡層，4.傳輸層，5.會話層，6.表示層，7.應用層。

應用層：是對特定應用的協議。

表示層：設備固有數據格式和網絡標準數據格式的轉換。

會話層：通訊管理。負責創建和斷開通訊鏈接。

傳輸層：管理兩個節點之間的數據傳輸。

網絡層：地址管理與路由選擇。

數據鏈路層：互連設備之間傳送和識別數據幀。

物理層：以「0」，「1」表明電壓的高低，燈光的閃滅。

如何模塊化通訊傳輸

網絡構成要素

網卡：

什麼是網關，它是OSI參考模型中負責將從傳輸層到應用層的數據進行轉換和轉發的設備。

代理服務：

19.有哪些渲染優化呢？😝

第一，咱們能夠禁止使用iframe，第二，能夠禁止使用gif圖片來實現loading效果，下降CPU的消耗，來提高渲染性能，第三，使用CSS3代碼來代替JS動畫。

對於一些小圖標，可使用base64位編碼，以減小網絡請求，但不建議大圖使用，由於比較耗費CPU，小圖標優點在於，能夠減小HTTP請求，避免文件跨域，修改及時生效。

頁面頭部的style和script會阻塞頁面，在Renderer進程中的JS線程和渲染線程是互斥的。

20.學習TCP和IP的基礎知識🤤

TCP/IP協議族市一組協議的集合，也稱爲互聯網協議族。

20世紀60年代後半葉，應DoD要求，美國開始進行通訊技術相關的演技，ARPANET的誕生，開發分組交互技術，在1975年，TCP/IP的誕生。1983年，ARPANET決定正式啓用TCP/IP爲通訊協議。

TCP/IP與OSI參考模型

對於OSI七層模型太細了，而互聯網協議族TCP/IP模型劃分爲四層。

TCP/IP模型（應用層，傳輸層，互聯網層，網絡接口層）-應用層，傳輸層，網絡層，鏈路層。

傳輸層就是可讓應用程序之間實現通訊。

在其中TCP是一種面向有鏈接的傳輸層協議，保證兩端通訊主機之間的通訊可達。UDP是一種面向無鏈接的傳輸層協議，so，UDP用於分組數據較少或者多播，廣播通訊以及視頻通訊等領域。

應用層

21.面試題：TCP/IP市如何在媒介上進行傳輸的呢？😑

在不一樣層次的協議✍

數據包首部：

以太網包首部：IP包首部，TCP包首部，數據

IP包首部：TCP包首部，數據

TCP包首部：數據

每一個分層中，都會對所發送的數據附加一個首部，它包含了該層中必要的信息。（發送的目標地址，協議相關的信息等）

包是全能性術語
幀是數據鏈路層中包的單位
數據包，IP和UDP等網絡層以上的分層中包的單位
段，表示TCP數據流中的信息
消息，應用協議中數據的單位

數據包的首部，明確代表了協議應該如何讀取數據。掌握數據包首部，一般，爲協議提供的信息爲包首部，所要發送的內容爲數據。

發送數據包，TCP/IP通訊流程：🤔

應用程序處理，發送通訊開始TCP/IP通訊，應用程序會進行編碼處理，編碼至關於OSI中的表示層功能。
TCP模塊的處理，TCP負責創建鏈接，發送數據以及斷開鏈接，TCP提供將應用層發來的數據順利發送至對端的可靠傳輸。在應用層數據的前端附加一個TCP首部，它包含源端口號和目標端口號，序號以及校驗和（用來判斷數據是否被破壞）而後附加一個TCP首部的包再發給IP。
IP模塊的處理，在TCP首部的前端加上本身的IP首部，它包含接收端IP地址和發送端IP地址。若不知道接收端的MAC地址，能夠用ARP查找，只要知道對端MAC地址，就能夠將MAC以及IP地址交給以太網的驅動程序，來實現數據傳輸。
網絡接口的處理，從IP傳過來的IP包，而後附加上以太網首部並進行發送處理，以太網首部包含接收端的MAC地址，發送端的MAC的地址，以及標誌以太網類型的以太網數據的協議。

數據包，通過以太網的數據鏈路時，大體上附加了以太網包首部，IP包首部，TCP包首部或者UDP包，以及應用本身的包首部和數據，最後包追加了包尾。

分層中包的結構

數據包接收流程🙄

網絡接口的處理，主機收到以太網包後，從以太網的包首部找到MAC地址判斷是否爲發給本身的，若不是就丟棄，若是是，就查找以太網包首部中的類型域從而肯定以太網協議所傳送過來的數據類型。
經過IP模塊處理，而後TCP模塊處理（須要判斷是否被破壞），檢查是否按照序號接收數據。當數據接收完畢後，會發送「確認回執」給發送端。注意，這裏的回執信息未能達到發送端，那麼發送端會認爲沒有收到而一直反覆發送。
應用程序的處理，接收端應用程序會直接接收發送端發送的數據信息。

22.瞭解一下http-http3.0😶

在http2.0中，TCP管道傳輸途中也會致使丟包問題，形成隊頭阻塞（在http2.0中的TCP創建鏈接三次握手，和HTTPS的TSL鏈接也會耗費較多時間）

其實多路複用技術能夠只經過一個TCP鏈接就能夠傳輸全部的請求數據。

http3中弄了一個基於UDP協議的QUIC協議，QUIC雖然說基於UDP，可是在基礎上添加了不少功能。QUIC（快速UDP網絡鏈接）是一種實驗性的網絡傳輸協議，由Google開發，該協議旨在使網頁傳輸更快。

對於在http中的缺點就是延遲，瀏覽器的阻塞，在對同一域名，同時只能鏈接4個，超過了瀏覽器的最大鏈接限數時，後面的請求就會被阻塞；DNS的查詢就是將域名解析爲IP，來向目標服務器的IP創建鏈接，其中經過DNS緩存能夠達到減小時間的做用；創建鏈接，HTTP是基於tcp協議的，三次握手，每次鏈接都沒法複用，so，會每次請求都要三次握手和慢啓動，都會影響致使延遲。（慢啓動對大量小文件請求影響較大）

http處於計算機網絡中的應用層，創建在TCP協議之上。（掌握瞭解tcp創建鏈接的3次握手和斷開鏈接的4次揮手和每次創建鏈接帶來的RTT延遲時間）。

相對於HTTP1.0使用了header裏的if-modified-since,expires來作緩存判斷，在HTTP1.1中引入了entity tag,if-unmodified-since,if-match,if-none-match等更多可供選擇的緩存頭來控制緩存策略。

http1.0傳輸數據時，每次都要從新創建鏈接，增長延遲，http1.1加入了keep-alive能夠複用部分鏈接，但在域名分片等狀況下仍要鏈接奪冠時鏈接，耗費資源，以及給服務器帶來性能壓力。

http1.1嘗試使用pipeling來解決問題，就是瀏覽器能夠一次性發出多個請求，在同一個域名下，同一條TCP鏈接，但對於pipeling要求返回是按照順序的，即（若是前面有個請求很耗時的話，後面的請求即便服務器已經處理完，任會等待前面的請求處理完纔開始按序返回。）

在http1.x中，Header攜帶內容過大，增長了傳輸的成本，在傳輸的內容都是明文，在必定程度上沒法保證其數據的安全性。（在http1.x問題的出現，有了SPDY協議，用於解決http/1.1效率不高的問題，下降延遲，壓縮Header等）

HTTP2主要解決用戶和網站只用一個鏈接（同域名下全部通訊都只用單個鏈接完成，單個鏈接能夠承載任意數量的雙向數據流，數據流是以消息的形式發送，消息由一個或多個幀組成）。

so，http採用二進制格式傳輸數據，不像http1.x的文本格式。（二進制：http2將請求和響應數據分割成幀，而且它們採用二進制的編碼），對於HTTP2的概念：（流，消息，幀）

流，它是鏈接中的一個虛擬信道；
消息，它是HTTP消息，請求，以及響應；
幀，它是HTTP2.0通訊的最小單位。

多個幀能夠亂序發送，可根據幀首部的標識流進行從新組裝。

對於http2,同一域名下只須要使用一個TCP鏈接，那麼當出現丟包時，會致使整個TCP都要開始等待重傳。對於http1.1來講，能夠開啓多個TCP鏈接，出現這種狀況指揮影響一個鏈接（或者部分），其他的TCP鏈接正常傳輸。

HTTP/2 對首部採起了壓縮策略，爲了減小資源消耗並提高性能。（由於在http1中，在header攜帶cookie下，可能每次都要重複傳輸數據）

so，有了QUIC協議，整合了TCP，TLS，和HTTP/2的優勢，並加以優化。那麼QUIC是啥，它是用來替代TCP，SSL/TLS的傳輸層協議，在傳輸層之上還有應用層。

注意，它是一個基於UDP協議的QUIC協議，使用在http3上。

QUIC 新功能

HTTPS 的一次徹底握手的鏈接過程

QUIC能夠解決傳輸單個數據流能夠保證有序的交付，而且不會影響其餘的數據流。（解決http2問題）

表示在QUIC鏈接中，一個鏈接上的多個stream，如其中stream1,stream2,stream3,stream4，其中stream2丟失（quic packet)，其他UDP到達，應用層直接讀取。--- 無需等待，不存在TCP隊頭阻塞，丟失的包須要從新傳便可。

補充：

TCP是基於IP和端口去識別鏈接的；
QUIC是經過ID的方式去識別鏈接的

對於QUIC的包都是通過認證的，除了個別，so，這樣，經過加密認證的報文，就能夠下降安全風險。

HTTP2-TLS,TCP,IP

小結QUIC特色：（基於UDP）--- http3-QUIC,UDP,IP

多路數據流
TLS
有序交付
快速握手
可靠性

23.網絡中的UDP😛

UPD面向報文的協議，就是UDP只是報文的搬運工，不會對報文進行任何拆分和拼接操做，在發送端，應用層將數據傳給傳輸層的UDP協議，UDP會給數據加一個UDP頭標識下是UUDP協議，而後傳給網絡層。

接收端，網絡層將數據傳給傳輸層，UDP只去除IP報文頭就傳給應用層，不會任何拼接操做。

UDP是無鏈接，通訊不須要創建和斷開鏈接，UDP是不可靠的，不關心數據的安全等問題，UDP是沒有擁塞控制，在網絡條件很差的狀況下可能會致使丟包。

傳輸：UDP 支持一對一，一對多，多對多，多對一的的傳輸方式， UDP 提供了單播，多播，廣播的功能。

24.網絡中的TCP😜

UDP沒有TCP那麼複雜，UDP頭部開銷小，可是TCP頭部比UDP頭部複雜得多，UDP頭部只有8字節，相比TCP的至少20字節要少不少。

Sequence number

這個序號保證了TCP傳輸的報文都是有序的，對端能夠經過序號順序的拼接報文

Window Size

表示窗口大小，還能接收多少字節的數據

Acknowledgement Number

表示上一個序號的數據已經接收到，接收端指望接收的下一個字節的編號是多少

標識符

當ACK=1，表示確認號字段有效

當SYN=1，ACK=0時，表示當前報文段是一個鏈接請求報文

當SYN=1，ACK=1時，表示當前報文段是一個贊成創建鏈接的應答報文

當FIN=1，表示此報文段是一個釋放鏈接的請求報文

性能指標 RTT

表示發送端發送數據到接收到對端數據所需的往返時間

小結

TCP（Transmission Control Protocol，傳輸控制協議）是基於鏈接的協議
UDP（User Data Protocol，用戶數據報協議）是面向非鏈接的協議。

25.創建鏈接三次握手😕

創建鏈接開始時，兩端都是CLOSED狀態，通訊開始前，雙方都會建立 TCB，後進入 LISTEN 狀態，開始等待客戶端發送數據。

第一次握手

客戶端向服務器端發送鏈接請求報文段，請求發送後，客戶端進入SYN-SENT 狀態。

第二次握手

服務端收到鏈接請求報文段後，發送完成後便進入 SYN-RECEIVED 狀態。

第三次握手

客戶端收到鏈接贊成的應答後，要向服務端發送一個確認報文。客戶端發完這個報文段後便進入ESTABLISHED 狀態，服務端收到這個應答後也進入 ESTABLISHED狀態，此時鏈接創建成功。

有人問了，兩次握手就能夠創建鏈接了，爲啥要第三次呢？

由於防止失效的鏈接請求報文段被服務器端接收，從而致使錯誤。

26.http請求碼有哪些？🤑

100爲繼續，通常發送post請求時，已經發送了http header以後服務端將返回此信息，表示確認，以後發送具體參數信息；201，請求成功而且服務器建立了新的資源；202，服務器已接受請求，但未處理。

301，請求的網頁已經永久移動到新的位置；302，臨時性重定向；303，臨時性重定向，且老是使用GET請求新的URI；304，自從上次請求後，請求的網頁未修改過。

404，服務器沒法理解請求；401，請求未受權；403，禁止訪問。

27.面試時，簡單說說TCP傳輸的三次握手四次揮手😲

傳輸，爲了準確無誤地把數據傳輸給目標，TCP協議採用了三次握手策略，用TCP協議把數據包送出去後，會向對方確認是否成功達到，發送端發送一個帶SYN標誌的數據包給到對方，接收端收到後，會回傳一個帶有SYN/ACK標誌的數據包表示傳送到達的確認信息，而後發送端也再次回傳一個帶有ACK標誌的數據包，表示「握手」結束了。

握手過程當中使用的標誌：SYN和ACK

斷開一個TCP鏈接須要四次揮手：

第一次揮手

主動關閉的一方，發送一個FIN(上述講過---當FIN=1，表示此報文段是一個釋放鏈接的請求報文)，傳送數據，用來告訴對方（被動關閉方），說不會再給你發送數據了。---主動關閉的一方能夠接受數據。

第二次揮手

被動關閉方收到 FIN 包，發送 ACK 給對方，確認序號。

第三次揮手

被動關閉方發送一個 FIN，關閉方，說我不會再給你發數據了。（你不給我發送數據，我也不給你發送數據了）

第四次揮手

主動關閉一方收到 FIN ，發送要給 ACK ，用來確認序號

28.常說的HTTPS🙁

其實HTTP協議時承載於TCP協議之上的，再HTTP和TCP之間添加一個安全協議層，SSL或者TSL（ssl/tls協議傳輸，包含證書，卸載，流量轉發，負載均衡，頁面適配，瀏覽器適配，refer傳遞等），則就是常說的HTTPS。

29.GET和POST的區別，什麼時候使用POST？😖

GET是用於信息獲取，使用URL傳遞參數，發送信息的數量有限；
POST是用於修改服務器上的資源；
通常使用POST，當沒法使用緩存文件，向服務器發送大量的數據，發送未知的字符

30.面試問，HTTP協議的主要特色😨

簡單快速
靈活
無鏈接
無狀態

31.面試問，說說HTTP報文的組成部分😟

HTTP報文的組成部分包含：請求報文和響應報文

請求報文：有請求行，請求頭，空行，請求體

響應報文：有狀態行，響應頭，空行，響應體

請求報文包含：

1.請求方法，2.請求URL，3.HTTP協議以及版本，4.報文頭，5.報文體

請求行，有請求方法，請求URL，http協議以及版本；
請求頭，一堆鍵值對
空行，當服務器在解析請求頭的時候，遇到了空行，代表後面的內容是請求體
請求體，請求數據

響應報文包含：

1.報文協議以及版本，2，狀態碼以及狀態描述，3，響應頭，4，響應體

狀態行：http協議和版本，狀態碼以及狀態描述
響應頭
空行
響應體

32.面試時問，知道哪些HTTP方法😤

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

33.持久連接😢

在http1.0中，客戶端每隔很短期會對服務器發出請求，查看是否有新的數據，只要輪詢足夠快，就能夠形成交互實時進行，但這個作法，會對兩端形成大量的性能浪費。

對於http1.1中的長鏈接，使用connection:keep-alive進行長鏈接，客戶端只請求一次，可是服務器會將繼續保持鏈接，再次請求時，避免了從新創建鏈接。

注意，keep-alive不會永久保持鏈接，只有保持一個時間段。

34.安全問題：CSRF和XSS😭

CSRF的基本概念，攻擊原理，防護措施

CSRF（Cross-site request forgery）：跨站請求僞造

理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求。

以你名義發送郵件，發消息，盜取你的帳號，甚至於購買商品，虛擬貨幣轉帳……形成的問題包括：我的隱私泄露以及財產安全。

CSRF的原理:(要完成一次CSRF攻擊)

登陸受信任網站A，並在本地生成Cookie。
在不登出A的狀況下，訪問危險網站B。

XSS的基本概念,跨域腳本攻擊。

xss是一種發生在web前端的漏洞，因此其危害的對象也主要是前端用戶。

跨域腳本攻擊是，惡意攻擊者往web頁面裏插入惡意的script代碼，在瀏覽器中運行script代碼，達到惡意攻擊用戶的目的。

so，實現xss攻擊具有2個條件，第一須要向web頁面注入惡意的代碼，第二，這些惡意代碼被瀏覽器成功的執行。

CSRF和XSS的區別：

CSRF須要登陸，獲取COOKIE，利用網站自己的漏洞，去請求網站的api
XSS,不須要登陸，向網站注入JS代碼，執行JS裏的代碼，篡改網站的內容

35.從一個HTTP請求來看網絡分層原理

一個HTTP請求的分層解析流程：

TCP，它是面向鏈接的，可靠的，基於字節流的傳輸層通訊協議。

特色：

基於鏈接，數據傳輸以前須要創建鏈接
全雙工的，雙向傳輸
字節流，不限制數據大小，打包成報文段，保證有序接收，重複報文自動丟棄
流量緩衝，解決雙方處理能力的不匹配
可靠的傳輸服務，保證可達，丟包時經過重發機制實現可靠性
擁塞控制，防止網絡出現惡性擁塞

TCP鏈接，源地址，源端口，目的地址，目的端口

從TCP-IP協議底層

滑動窗口協議與累計確認（延時ACK）

滑動窗口大小同經過tcp三次握手和對端協商，且受網絡情況影響

36.HTTPS安全加密通道原理分析

什麼是HTTPS協議，因爲HTTP天生「明文」的特色，整個傳輸過程徹底透明，任何人都可以在鏈路中截獲，修改或者僞造請求、響應報文，數據不具備可信性。

使用HTTPS時，全部的HTTP請求和響應發送到網絡前，都要進行加密。

https = http + ssl/tls

對稱加密：加密 解密使用同一密鑰

非對稱加密：公鑰-隨意分發，私鑰-服務器本身保持

公鑰加密的數據，只能經過私鑰解密
私鑰加密的數據，只能公鑰能解密
複製代碼

加密算法：

對稱密鑰加密算法，編，解碼使用相同密鑰的算法

非對稱密鑰加密算法，一個公鑰，一個私鑰，兩個密鑰是不一樣的，公鑰能夠公開給如何人使用，私鑰是嚴格保密的。

加密通道的創建：

數字證書的申請和驗證

如何申請：

生成本身的公鑰和私鑰，服務器本身保留私鑰
向CA機構提交公鑰，公司，域名信息等待認證
CA機構經過線上，線下多種途徑驗證你提交信息的真實性，合法性
信息審覈經過，CA機構則會向你簽發認證的數字證書，包含了公鑰，組織信息，CA信息，有效時間，證書序列號，同時生成了一個簽名
簽名步驟：hash(用於申請證書所提交的明文信息)= 信息摘要
CA再使用CA機構的私鑰對信息摘要進行加密，密文就是證書的數字簽名

37.https的對稱加密，非對稱加密，混合加密，CA認證😨

HTTPS ，超文本傳輸安全協議，目標是安全的HTTP通道，應用是安全數據傳輸。HTTP協議雖然使用廣，可是存在不小的安全缺陷，主要是數據的明文傳送和消息完整性檢測的缺少。

HTTPS協議是由HTTP加上TLS/SSL協議構建的可進行加密傳輸，身份認證的網絡協議。

經過，數字證書，加密算法，非對稱密鑰等技術完成互聯網數據傳輸加密，實現互聯網傳輸安全保護。

HTTPS主要特性：

數據保密性
數據完整性
身份校驗安全性

客戶端和服務器端在傳輸數據以前，會經過基於證書對雙方進行身份認證。客戶端發起SSL握手消息給服務端要求鏈接，服務端將證書發送給客戶端。客戶端檢查服務器端證書，確認是否由本身信任的證書籤發機構簽發，若是不是，將是否繼續通信的決定權交給用戶選擇，若是檢查無誤或者用戶選擇繼續，則客戶端承認服務端的身份。

服務端要求客戶端發送證書，並檢查是否經過驗證，失敗則關閉鏈接，認證成功，從客戶端證書中得到客戶端的公鑰。

HTTP原理

客戶端的瀏覽器首先要經過網絡與服務器創建鏈接，該鏈接時經過TCP來完成的，通常TCP鏈接的端口號是80，創建鏈接後，客戶端發送一個請求給服務器端；服務器端接收到請求後，給予相應的響應信息。

HTTPS原理

客戶端將它所支持的算法列表和一個用做產生密鑰的隨機數發送給服務器，服務器從算法列表中選擇一種加密算法，並將它和一份包含服務器公用密鑰的證書發送給客戶端，該證書還包含了用於認證目的的服務器標識，服務器同時還提供了一個用做產生密鑰的隨機數。

客戶端對服務器的證書進行驗證，並抽取服務器的公用密鑰，再產生一個稱做pre_master_secret的隨機密碼串，並使用服務器的公用密鑰對其進行加密，並將加密後的信息發送給服務器。

客戶端與服務器端根據pre_master_secret以及客戶端與服務器的隨機數獨立計算出加密和MAC密鑰。

混合加密

在傳輸數據中使用對稱加密，但對稱加密的密鑰採用非對稱加密來傳輸，混合加密比較安全，但沒法知道數據是否被篡改

CA認證

CA認證, 便是電子認證服務，指電子簽名相關各方提供真實性，可靠性驗證的活動。

特性：參閱百度百科—簡介，點擊進入

38.https對比http🥶

http傳輸方式：明文傳輸，網站或相關服務與用戶之間的數據交互無加密，容易被監聽，篡改。

https傳輸方式：在HTTP加入了SSL層，用於數據傳輸加密。

http身份認證：無任何身份認證，用戶沒法經過http辨認出網站的真實身份。

https身份認證：通過CA多重認證，包含域名管理權限認證等。

http成本：無任何使用成本，全部網站默認是http模式。

https須要成本，須要申請SSL證書來實現https。

http鏈接端口：80端口。

https鏈接端口：443端口。

39.證書如何安全傳輸，被掉包了怎麼辦？😳

40.http3中QUIC😵

QUIC是谷歌制定的一種基於UDP的低時延的互聯網傳輸層協議。

一、避免前序包阻塞；二、零RTT建連；三、FEC前向糾錯

HTTP 的歷史

HTTP/2 和 HTTP/3 創建鏈接的差異

TCP/創建鏈接與QUIC創建鏈接

隊頭阻塞/多路複用

HTTP/1.1 提出了 Pipelining 技術，容許一個 TCP 鏈接同時發送多個請求

請求與響應，與，Pipelining

http/1.1隊頭阻塞

HTTP/2 的多路複用解決了隊頭阻塞問題

擁塞控制：

慢啓動
擁塞避免
快速重傳
快速恢復

41.HTTP 協議入門

HTTP 基於TCP/IP 協議的應用層協議，不涉及數據包packet傳輸，主要客戶端和服務器之間的通訊格式，默認使用80端口。TCP鏈接創建後，客戶端向服務器請求網頁，協議規定，服務器只能迴應HTML格式的字符串，不能迴應別的格式。

http1.0能夠傳輸文字，傳輸圖像，視頻，二進制文件；除了GET方法，還有POST，HEAD等；每次通訊都須要頭信息HTTP header，狀態碼，多字符集支持，緩存，權限等。

字段：ontent-Type 字段

頭信息必須是 ASCII 碼，後面的數據能夠是任何格式，字段值：

text/plain
text/html
text/css
image/jpeg
image/png
image/svg+xml
audio/mp4
video/mp4
application/javascript
application/pdf
application/zip
application/atom+xml
複製代碼

客戶端請求的時候，使用Accept字段，表示能夠接受哪些數據格式。

Accept: */* 複製代碼

Content-Encoding字段,表示數據的壓縮方式

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
複製代碼

客戶端在請求時，用Accept-Encoding字段說明接受哪些壓縮方法。

Accept-Encoding: gzip, deflate
複製代碼

http1.0就是每一個TCP鏈接只能發送一個請求，發送完畢後就關閉，so，爲解決問題，用了一個非標準Connection字段，Connection:keep-alive。

HTTP/1.1引入了持久鏈接（persistent connection），TCP鏈接默認不關閉，能夠被多個請求複用，不用聲明Connection: keep-alive。

也不是永久性不關閉的，只要有一段時間沒有活動，就會關閉TCP鏈接，通常對於同一個域名，大多數瀏覽器容許同時創建6個持久鏈接。

1.1 版引入了管道機制（pipelining），同一個TCP鏈接裏，能夠同時發送多個請求。可是仍是按照順序，一個請求迴應後，再回應另外一個請求。（但也減小不小的消耗時間）。

使用分塊傳輸編碼，只要請求或迴應的頭信息有Transfer-Encoding字段

Transfer-Encoding: chunked
複製代碼

什麼是多工？雙向，實時的通訊就叫多工。

HTTP2 複用TCP鏈接，在一個鏈接裏，兩端均可以同時發送多個請求或響應，並且不用按照順序一一對應，避免了「隊頭堵塞」。

http2引入了頭信息壓縮機，頭信息使用gzip或compress壓縮後再發送，客戶端和服務器同時維護一張頭信息表，全部字段存在這個表裏，生成一個索引號，之後就只發送索引號，這樣就提升速度了。

HTTP/2容許服務器未經請求，主動向客戶端發送資源（服務器推送）

42.什麼是cookie呢🥴

cookie是某網站爲了辨別用戶身份，進行session跟蹤而存儲在用戶本地終端的數據（一般通過加密），由用戶客戶端計算機暫時或永久保存的信息。

存儲在用戶本地終端上的數據
用來辨別用戶身份
保存在用戶本地終端

cookie是一些數據，存儲在你電腦上的文本文件中，當web服務器向瀏覽器發送web頁面時，在鏈接關閉後，服務端不會記錄用戶的信息，cookie的做用就是解決如何記錄客戶端的用戶信息。

場景：當用戶訪問web頁面，用戶信息記錄在cookie中，當用戶下一次訪問頁面後，能夠在cookie中讀取用戶訪問記錄。

cookie是以鍵值對形式存儲的，當瀏覽器從服務器上請求web頁面，該頁面的cookie會被添加到請求中，服務端經過這種方式用來獲取用戶信息。

可使用JavaScript來建立，讀取，修改，刪除cookie

使用document.cookie屬性來建立，讀取以及刪除cookie

建立：

document.cookie = "username = dadaqianduan";
複製代碼

給cookie添加一個過時時間：

document.cookie = "username = dadaqianduan; expires=xxxxxx";
複製代碼

默認狀況下，cookie屬於當前頁面：

document.cookie = "username = dadaqianduan; expires= ; path=/";
複製代碼

讀取cookie

var x = document.cookie;
複製代碼

修改cookie

document.cookie = "username = dada; expires=xxx; path=/";
複製代碼

刪除cookie，把設置時間的expires 參數改成之前的時間便可。

document.cookie = "username = ; expires= xxx";
複製代碼

爲何會有cookie呢？由於http請求時無協議的，http1.x，無狀態協議，客戶端同一個請求發送屢次，服務端並不能識別是否是同一個客戶端發送，爲了解決無狀態，就有了cookie。

cookies是服務器暫存放在你的電腦裏的資料，以.txt格式的文本文件，好讓服務器用來辨認你的計算機，當你在瀏覽網站時，web服務器會發送一個小小的資料放在你的計算機上。

當你下一次訪問同一個網站，web瀏覽器會先看看有沒有它上次留下來的cookies資料，有的話就輸出特定的內容給你。

cookie原理

瀏覽器第一次請求服務器，服務器響應請求中攜帶cookie，給瀏覽器，瀏覽器第二次請求，攜帶cookie，給服務器，服務器根據cookie辨別用戶，也能夠修改cookie內容。

domain時.baidu.com的cookie綁定到了域名商。跨域的域名不能寫入在cookies文件裏

cookie的屬性有哪些

Name, Value, Domain, Path, Expires/Max-Age, Size, HttpOnly, Secure, SameSite

掌握面試中的HttpOnly,這個屬性設置爲true，就不能經過js腳本獲取cookie的指，能有效防止xss的攻擊。

Cookie中的HttpOnly和Secure中：

標記爲Secure的Cookie只能被https協議加密過的請求發送給服務端。但也沒法保證其安全保障。

若是cookie中設置了HttpOnly屬性，經過js腳本將沒法讀取到cookie信息，有效防止xss的攻擊，竊取cookie內容，增長了cookie的安全性，可是重要信息仍是不要存儲在cookie中。

由於xss爲跨站腳本攻擊，是web程序常見的漏洞，屬於被動式且用於客戶端的攻擊方式

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
複製代碼

SameSite

SameSite Cookie容許服務器要求某個cookie在跨站請求時不會被髮送，從而能夠阻止跨站請求僞造攻擊（CSRF）。

示例：

Set-Cookie: key=value; SameSite=Strict
複製代碼

SameSite有三個值：

None: 瀏覽器在同站請求，跨站請求下繼續發送cookies，不區分大小寫。（全部三方的請求都會攜帶cookie)

Strict: 瀏覽器將只在訪問相同站點時發送cookie。（全部三方的連接都不會攜帶cookie)

Lax: Same-site cookies 將會爲一些跨站子請求保留，如圖片加載或者frames的調用，但只有當用戶從外部站點導航到URL時纔會發送。(只有同步且是get請求才可攜帶cookie)

在https協議中，才能經過js去設置secure類型的cookie,在http協議的網頁中是沒法設置secure類型cookie的。默認狀況，https協議仍是http協議的請求，cookie都會被髮送到服務端。

43.什麼是token呢？🤬

token的出現，是在客戶端頻繁向服務端請求數據，服務端頻繁的去數據庫查詢用戶名和密碼並進行對比，判斷用戶名和密碼正確與否，並做出相應提示。token是服務端生成的一串字符串，以做客戶端進行請求的一個令牌，第一登陸時，服務器生成一個token，將此token返回給客戶端，客戶端帶上這個token，無需再次帶上用戶名和密碼了。

token的出現減輕了服務器的壓力，減小頻繁地數據庫查詢。

token的優勢

無狀態，可擴展
安全性
多平臺跨域
基於標準

基於Token的身份驗證的過程

瀏覽器，輸入userName, Password，到mysql，校驗成功生成token，將token返回給客戶端，當客戶端發起請求時，每次訪問api都攜帶token到服務器端，通過過濾器，校驗token，校驗成功後返回請求數據，校驗失敗後返回錯誤碼。

44.cookie,session,token😷

cookie，記錄訪問過的網站或正在訪問的網站，對於HTTP 協議是無狀態的，服務器不知道瀏覽器上一次訪問作了什麼，也沒法對用戶會話進行跟蹤鏈接，因此，cookie是由服務器發送到客戶端瀏覽器的一段文本文件，包含了網站訪問活動信息。Cookie 存放在客戶端，用來保存客戶端會話信息；因爲存儲在客戶端，它的安全性不能徹底保證。

session表示是c/s架構中服務器和客戶端一次會話的過程，用來保存認證用戶信息。session是一種HTTP存儲機制，提供持久機制。Session存放在服務器端，用戶驗證客戶端信息。因爲存儲在服務器，安全性有必定的保證。

token是一種認證方式(是「令牌」的意思，主要是用於身份的驗證方式。)

45.跨域🤒

網頁的URL的協議、域名、端口有一個不一樣，就算是跨域了

跨域：JSONP

46.思惟導圖http小結

47.http中的字段🤠

accept，數據格式，請求accept，響應，content-type，表示收到的數據格式
accept，壓縮方式，請求accept-encoding，響應，content-encoding，採用什麼樣的壓縮方式
accept，支持語言，請求accept-language，響應content-language
accept，字符集，請求accept-charset，響應content-type，指定字符集
accept，範圍請求，請求if-range和range，響應accept-anges和content-range
cookie，請求時傳遞給服務端的cookie信息
set-cookie，響應報文首部設置要傳遞給客戶端的cookie信息
allow，支持什麼HTTP方法
last-modified，資源的最後修改時間
expires,設置資源緩存的失敗日期
content-language，實體的資源語言
content-encoding，實體的編碼格式
content-length，實體主體部分的大小單位是字節
content-range，返回的實體的哪些範圍
content-type，哪些類型
accept-ranges，處理的範圍請求
age，告訴客戶端服務器在多久前建立了響應
vary，代理服務器的緩存信息
location，用於指定重定向後的URI
If-Match，值是資源的惟一標識
User-Agent，將建立請求的瀏覽器和用戶代理名稱等信息傳遞給服務器
Transfer-Encoding，傳輸報文的主體編碼方式
connection，管理持久鏈接，keep-alive , close
Cache-Control，控制瀏覽器的強緩存

48.若是面試問HTTP報文結構是什麼，你能回答上來不？

對於 TCP 而言

起始行 + 頭部 + 空行 + 實體
複製代碼

請求報文

GET /home HTTP/1.1
複製代碼

響應報文

HTTP/1.1 200 OK
複製代碼

空行是用來分開頭部和實體。

49.若是面試問HTTP請求方法有哪些，你能回答上來不？🤥

GET方法，用來獲取資源
POST方法，用來提交數據
PUT方法，用來修改數據
DELETE方法，用來刪除資源
OPTIONS方法，用來跨域請求
HEAD方法，用來獲取資源的元信息
CONNECT方法，用來創建鏈接，用於代理服務器

50.若是面試問，你對URI是如何理解的，你能回答上來不？🤫

URL統一資源定位符，URI，統一資源標識符。URI用於區分網絡上不一樣的資源。

URI包含了URN和URL。

URL的結構：

協議名，登陸主機的用戶信息，主機名和端口，請求路徑，查詢參數，URI上定位資源內的一個錨點。

51.若是面試問，你對HTTP狀態碼的瞭解有多少，你能回答上來不？

瞭解一些特定的HTTP狀態碼：

52.若是面試問，說說HTTP特色以及缺點，你能回答上來不？

特色是：

靈活可擴展
可靠傳輸
無狀態等

缺點是：

無狀態
明文傳輸
隊頭阻塞問題

53.若是面試問，說說你對Accept字段的理解，你能回答上來不？

數據格式
壓縮方式
支持語言
字符集

54.若是面試問，什麼是隊頭阻塞問題，你能回答上來不？🤭

TCP中是報文，HTTP是請求。

對於解決HTTP的隊頭阻塞問題是：併發鏈接和域名分片。

55.若是面試問，說說你對HTTP代理的理解，你能回答上來不？🧐

代理服務器功能：1，負載均衡，2，保障安全（利用心跳機制監控服務器，一旦發現故障機就將其踢出集羣。），3，緩存代理。

理解代理緩存：

由一個代理服務器下載的頁面存儲；
一個代理服務器爲多個用戶提供一條通道；
緩衝的代理容許一個代理服務器減小對同一個網站的一樣頁面的請求次數
一旦代理服務器的一個用戶請求了某個頁面，代理服務器就保存該頁面以服務於它的其餘用戶的一樣的請求
代理緩存，這種處理減小了用戶等待頁面顯示的時間

緩存的做用：

代理服務器或客戶端本地磁盤內保存的資源副本，利用緩存可減小對源服務器的訪問，能夠節省通訊流量和通訊時間。

示例：

Cache-Control: max-age=300；
複製代碼

表示時間間隔，再次請求的時間間隔300s內，就在緩存中獲取，不然就在服務器中

Cache-Control:

public 表示響應可被任何中間節點緩存
private 表示中間節點不容許緩存
no-cache 表示不使用Cache-Control的緩存控制方式作前置驗證
no-store 表示真正的不緩存任何東西
max-age 表示當前資源的有效時間

強緩存：瀏覽器直接從本地存儲中獲取數據，不與服務器進行交互

協商緩存：瀏覽器發送請求到服務器，瀏覽器判斷是否可以使用本地緩存

學習瞭解強緩存👍：

強緩存主要學習expires和cache-control

cache-control該字段：max-age，s-maxage，public，private，no-cache，no-store。

cache-control: public, max-age=3600, s-maxage=3600 
複製代碼

表示資源過了多少秒以後變爲無效
s-maxage 的優先級高於 max-age
在代理服務器中，只有 s-maxage 起做用

public 和 private

public 表示該資源能夠被全部客戶端和代理服務器緩存
private 表示該資源僅能客戶端緩存

當瀏覽器去請求某個文件的時候，服務端就在response header裏作了緩存的配置：

表現爲：respone header 的cache-control

學習瞭解✍協商緩存：

response header裏面的設置

etag: 'xxxx-xxx
last-modified: xx, 24 Dec xxx xxx:xx:xx GMT
複製代碼

56.若是面試問，HTTP/2，你能回答上來不？🤓

HTTP/2採用哈夫曼編碼來壓縮整數和字符串，能夠達到50%~90%的高壓縮率。

服務器推送

57.B/S 結構定義😈

瀏覽器-服務器結構，B/S結構，客戶端不須要安裝專門的軟件，只須要瀏覽器便可，瀏覽器經過web服務器與數據庫進行交互，能夠方便的在不一樣平臺下工做。

B/S結構簡化了客戶端的工做，它是隨着Internet技術興起而產生的，對C/S技術的改進，但該結構下服務器端的工做較重，對服務器的性能要求更高。

58.URI統一資源標識符👿

統一資源標識符是一個用於標識某一互聯網資源名稱的字符串。該標識容許用戶對網絡中的資源經過特定的協議進行交互操做。URI常見形式爲統一資源定位符（URL），URN爲統一資源名稱。用於在特定的命令空間資源的標識，以補充網址。

59.HTTP 協議👹

HTTP超文本傳輸協議是互聯網上應用最爲普遍的一種網絡協議。設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法。經過HTTP或者HTTPS協議請求的資源由統一資源標識符來標識

HTTP 協議主要特色

60.數據鏈路🔪-數據鏈路層

數據鏈路層：以太網，無線LAN，PPP。。。(無線，光纖。。。)

數據鏈路的知識對了解TCP/IP與網絡起到重要的做用
數據鏈路層的協議定義了經過通訊媒介互連的設備傳輸的規範
物理層面是將實際的通訊媒介如電壓的高低，電波的強弱等信號與二進制01進行轉換
數據鏈路層處理的數據是一種集合爲「幀」的塊
WLAN，無線局域網
PPP，點對點協議，便是1對1鏈接計算機的協議
ATM，異步傳輸方式

數據鏈路是讓互聯網計算機之間相互通訊的一種協議，通訊手段

MAC地址用於識別數據鏈路中互連的節點

無線通訊是使用電磁波，紅外線，激光等方式進行傳播數據。通常在辦公室的局域網範圍內組成的較高速的鏈接稱爲無線局域網。
IP-x-x-x，在IP網絡上創建x-x-x,網絡服務商提供一種在IP網絡商使用MPLS技術構建x-x-x的服務。

61.TCP和UDP的區別

TCP是一個面向鏈接，可靠，基於字節流的傳輸層協議。

UDP是一個面向無鏈接的傳輸層協議。

TCP是面向鏈接的，客戶端和服務器端的鏈接，雙方互相通訊以前，TCP須要三次握手創建鏈接，而UDP沒有創建鏈接的過程

tcp是面向字節流，udp是面向報文的。UDP的數據傳輸是基於數據報的，TCP繼承了IP層的特性，TCP爲了維護狀態，將一個個IP包變成了字節流。

TCP報文格式圖：

序號：Seq序號，佔32位，標識從TCP源端口向目的端口發送的字節流，發起方發送數據時，對此進行標記
確認序號：Ack序號，佔32位，只有ACK標誌位爲1時，確認序號字段纔有效，Ack=Seq+1
標誌位：共6個，即URG、ACK、PSH、RST、SYN、FIN等

URG，緊急指有效
ACK，確認序號有效
RST，重置鏈接
SYN，發起一個新鏈接
FIN，釋放一個鏈接
PSH，接收方應該儘快將這個報文交給應用層

62.三次握手創建鏈接

TCP 的三次握手的過程:

有圖可知都處於closed狀態，服務器開始監聽某個端口進入listen狀態，客戶端發起請求，發送SYN,seq=x，而後狀態變爲syn-sent狀態。

服務器端接收到返回syn和ack,seq=x,ack =x+1,而後狀態變成syn-rcvd狀態。

客戶端收到後，發送ack,seq=x+1,ack=y+1給服務器端，狀態變爲established，服務器收到後，狀態變成established。

在鏈接過程當中，須要對端確認的，須要消耗TCP報文的序列號。SYN消耗一個序列號而ACK不須要。

對於鏈接四次握手多餘，二次握手，會帶來資源的浪費，當遇到丟包，重傳，鏈接關閉後，丟包到達服務端，就默認創建鏈接，可客戶端以及關閉，因此三次握手就能夠了。

63.四次揮手斷開鏈接

TCP 四次揮手的過程

三次揮手，當服務器將ack和fin合併爲一次揮手，會致使長時間的延遲，以致於客戶端誤認爲fin沒有到達客戶端，讓客戶端不斷重發fin。

64.TCP 滑動窗口

TCP 滑動窗口:

發送窗口

接收窗口

65.TCP 的擁塞控制？

TCP鏈接，擁塞控制：

擁塞窗口（Congestion Window，cwnd）
慢啓動閾值（Slow Start Threshold，ssthresh）

TCP/IP協議四層

應用層決定了向用戶提供應用服務時通訊的活動。
傳輸層對上層應用層，提供處於網絡鏈接中兩臺計算機之間的數據傳輸。
網絡層用來處理在網絡上流動的數據包。
鏈路層，用來處理鏈接網絡的硬件部分。

HTTP協議的職責，生成對目標web服務器的HTTP請求報文
tcp協議的職責，爲了方便通訊，將HTTP請求報文分割成報文段
IP協議的職責，搜索對方的地址，一邊中轉一邊傳送
TCP協議的職責，從對方那裏接收到的報文段，重組到達的報文段，按序號以原來的順序重組請求報文

66.瞭解一下DNS

DNS是域名解析系統，它的做用很是簡單，就是根據域名查出對應的IP地址。

從根域名服務器查到頂級域名服務器的NS記錄和A記錄，IP地址
從頂級域名服務器查到次級域名服務器的NS記錄和A記錄，IP地址
從次級域名服務器查出主機名的IP地址

參考文獻

點關注，不迷路

願你遇到那個心疼你付出的人~

囊括前端Vue、JavaScript、數據結構與算法、實戰演練、Node全棧一線技術，緊跟業界發展步伐，一個熱愛前端的達達程序員。

好了各位，以上就是這篇文章的所有內容，能看到這裏的人都是人才。我後面會不斷更新網絡技術相關的文章，若是以爲文章對你有用，歡迎給個「贊」，也歡迎分享，感謝你們！！

喜歡本文的朋友們，歡迎長按下圖關注公衆號達達前端，收看更多精彩內容

相關標籤/搜索

每日一句

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