計算機網絡
目錄
- OSI與TCP/IP各層的結構與功能,都有哪些協定?
- 三次握手和四次揮手
- TCP,UDP 協定的差別
- TCP 協定如何保證可靠傳輸
- 在浏覽器中輸入url位址 ->> 顯示首頁的過程
- URI和URL的差別是什麼?
- HTTP 和 HTTPS 的差別？
- 狀态碼
- HTTP長連接配接,短連接配接
- HTTP是不儲存狀态的協定,如何儲存使用者狀态?
- Cookie的作用是什麼?和Session有什麼差別？、
- Get與POST的差別
注：題目從牛客 Java部門面經整理而來。
2020秋招面經大彙總！（崗位劃分）
1. OSI與TCP/IP各層的結構與功能,都有哪些協定?
學習計算機網絡時我們一般采用折中的辦法，也就是中和 OSI 和 TCP/IP 的優點，采用一種隻有五層協定的體系結構，這樣既簡潔又能将概念闡述清楚。
###################################################### 圖檔
結合網際網路的情況，自上而下地，非常簡要的介紹一下各層的作用。
1.1 應用層
應用層(application-layer）的任務是通過應用程序間的互動來完成特定網絡應用。應用層協定定義的是應用程序（程序：主機中正在運作的程式）間的通信和互動的規則。對于不同的網絡應用需要不同的應用層協定。在網際網路中應用層協定很多，如域名系統DNS，支援網際網路應用的 HTTP協定，支援電子郵件的 SMTP協定等等。我們把應用層互動的資料單元稱為封包。
域名系統
域名系統(Domain Name System縮寫 DNS，Domain Name被譯為域名)是網際網路的一項核心服務，它作為可以将域名和IP位址互相映射的一個分布式資料庫，能夠使人更友善的通路網際網路，而不用去記住能夠被機器直接讀取的IP數串。（百度百科）例如：一個公司的 Web 網站可看作是它在網上的門戶，而域名就相當于其門牌位址，通常域名都使用該公司的名稱或簡稱。例如上面提到的微軟公司的域名，類似的還有：IBM 公司的域名是 www.ibm.com、Oracle 公司的域名是 www.oracle.com、Cisco公司的域名是 www.cisco.com 等。
HTTP協定
超文本傳輸協定（HTTP，HyperText Transfer Protocol)是網際網路上應用最為廣泛的一種網絡協定。所有的 WWW（網際網路） 檔案都必須遵守這個标準。設計 HTTP 最初的目的是為了提供一種釋出和接收 HTML 頁面的方法。（百度百科）
1.2 運輸層
運輸層(transport layer)的主要任務就是負責向兩台主機程序之間的通信提供通用的資料傳輸服務。應用程序利用該服務傳送應用層封包。“通用的”是指并不針對某一個特定的網絡應用，而是多種應用可以使用同一個運輸層服務。由于一台主機可同時運作多個線程，是以運輸層有複用和分用的功能。所謂複用就是指多個應用層程序可同時使用下面運輸層的服務，分用和複用相反，是運輸層把收到的資訊分别傳遞上面應用層中的相應程序。
運輸層主要使用以下兩種協定:
- 傳輸控制協定 TCP（Transmission Control Protocol）–提供面向連接配接的，可靠的資料傳輸服務。
- 使用者資料協定 UDP（User Datagram Protocol）–提供無連接配接的，盡最大努力的資料傳輸服務（不保證資料傳輸的可靠性）。
1.3 網絡層
在 計算機網絡中進行通信的兩個計算機之間可能會經過很多個資料鍊路，也可能還要經過很多通信子網。網絡層的任務就是選擇合适的網間路由和交換結點， 確定資料及時傳送。 在發送資料時，網絡層把運輸層産生的封包段或使用者資料報封裝成分組和包進行傳送。在 TCP/IP 體系結構中，由于網絡層使用 IP 協定，是以分組也叫 IP 資料報 ，簡稱 資料報。
這裡要注意：不要把運輸層的“使用者資料報 UDP ”和網絡層的“ IP 資料報”弄混。另外，無論是哪一層的資料單元，都可籠統地用“分組”來表示。
這裡強調指出，網絡層中的“網絡”二字已經不是我們通常談到的具體網絡，而是指計算機網絡體系結構模型中第三層的名稱.
網際網路是由大量的異構（heterogeneous）網絡通過路由器（router）互相連接配接起來的。網際網路使用的網絡層協定是無連接配接的網際協定（Intert Protocol）和許多路由選擇協定，是以網際網路的網絡層也叫做網際層或IP層。
2. 三次握手和四次揮手
1. TCP 三次握手
所謂三次握手（Three-Way Handshake）即建立TCP連接配接，就是指建立一個TCP連接配接時，需要用戶端和服務端總共發送3個包以确認連接配接的建立。在socket程式設計中，這一過程由用戶端執行connect來觸發，整個流程如下圖所示：
- 第一次握手：Client将标志位SYN置為1，随機産生一個值seq=J，并将該資料包發送給Server，Client進入SYN_SENT狀态，等待Server确認。
- 第二次握手：Server收到資料包後由标志位 SYN=1 知道Client請求建立連接配接，Server将标志位SYN和ACK都置為1，ack=J+1，随機産生一個值 seq=K，并将該資料包發送給Client以确認連接配接請求，Server進入 SYN_RCVD 狀态。
- 第三次握手：Client收到确認後，檢查ack是否為J+1，ACK是否為1，如果正确則将标志位ACK置為1，ack=K+1，并将該資料包發送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正确則連接配接建立成功，Client和Server進入ESTABLISHED狀态，完成三次握手，随後Client與Server之間可以開始傳輸資料了。
2. 為什麼要三次握手？兩次不行麼？為什麼？
三次握手的目的是建立可靠的通信信道，簡單來說就是資料的發送與接收，而三次握手最主要的目的就是雙方确認自己與對方的發送與接收是正常的。
- 第一次握手：Client 什麼都不能确認；Server 确認了對方發送正常
- 第二次握手：Client 确認了：自己發送、接收正常，對方發送、接收正常；Server 确認了：自己接收正常，對方發送正常
- 第三次握手：Client 确認了：自己發送、接收正常，對方發送、接收正常；Server 确認了：自己發送、接收正常，對方發送接收正常
是以三次握手就能确認雙發收發功能都正常，缺一不可。
如果采用兩次握手，那麼隻要伺服器發送确認資料包就會建立連接配接，但由于此時用戶端并未響應伺服器端請求，那麼此時伺服器端就會一直在等待用戶端，這樣伺服器端就白白浪費了一定的資源。若采用握手，伺服器端沒有收到來自用戶端的再次确認，則就會知道用戶端并沒有要求建立請求，就不會浪費伺服器的資源。
3. 為什麼要傳回 SYN？
接收端傳回發送端所發送的 SYN 是為了告訴發送端，我接收到的資訊确實就是你所發送的信号了。
SYN 是 TCP/IP 建立連接配接時使用的握手信号。在客戶機和伺服器之間建立正常的 TCP 網絡連接配接時，客戶機首先發出一個 SYN 消息，伺服器使用 SYN-ACK 應答表示接收到了這個消息，最後客戶機再以ACK(Acknowledgement[漢譯：确認字元,在資料通信傳輸中，接收站發給發送站的一種傳輸控制字元。它表示确認發來的資料已經接受無誤。 ]）消息響應。這樣在客戶機和伺服器之間才能建立起可靠的TCP連接配接，資料才可以在客戶機和伺服器之間傳遞。
4. 傳了 SYN，為什麼還要傳 ACK？
雙方通信無誤必須是兩者互相發送資訊都無誤。傳了 SYN，證明發送方到接收方的通道沒有問題，但是接收方到發送方的通道還需要 ACK 信号來進行驗證。
5. 四次揮手
四次揮手（Four-Way Wavehand）即終止TCP連接配接，就是指斷開一個TCP連接配接時，需要用戶端和服務端總共發送4個資料包以确認連接配接的斷開。在socket程式設計中，這一過程由用戶端或服務端任一方執行close來觸發，整個流程如下圖所示：
由于TCP連接配接時全雙工的，是以，每個方向都必須要單獨進行關閉，這一原則是當一方完成資料發送任務後，發送一個FIN來終止這一方向的連接配接，收到一個FIN隻是意味着這一方向上沒有資料流動了，即不會再收到資料了，但是在這個TCP連接配接上仍然能夠發送資料，直到這一方向也發送了FIN。首先進行關閉的一方将執行主動關閉，而另一方則執行被動關閉，上圖描述的即是如此。
- 第一次揮手：Client發送一個FIN，用來關閉Client到Server的資料傳送，Client進入FIN_WAIT_1狀态。
- 第二次揮手：Server收到FIN後，發送一個ACK給Client，确認序号為收到序号+1（與SYN相同，一個FIN占用一個序号），Server進入CLOSE_WAIT狀态。
- 第三次揮手：Server發送一個FIN，用來關閉Server到Client的資料傳送，Server進入LAST_ACK狀态。
- 第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀态，接着發送一個ACK給Server，确認序号為收到序号+1，Server進入CLOSED狀态，完成四次揮手。
6. 為什麼要四次揮手
任何一方都可以在資料傳送結束後發出連接配接釋放的通知，待對方确認後進入半關閉狀态。當另一方也沒有資料再發送的時候，則發出連接配接釋放通知，對方确認後就完全關閉了TCP連接配接。
7. 為什麼用戶端最後還要等待2MSL？
MSL（Maximum Segment Lifetime：最長封包段壽命），TCP允許不同的實作可以設定不同的MSL值。
第一，保證用戶端發送的最後一個ACK封包能夠到達伺服器，因為這個ACK封包可能丢失，站在伺服器的角度看來，我已經發送了FIN+ACK封包請求斷開了，用戶端還沒有給我回應，應該是我發送的請求斷開封包它沒有收到，于是伺服器又會重新發送一次，而用戶端就能在這個2MSL時間段内收到這個重傳的封包，接着給出回應封包，并且會重新開機2MSL計時器。
第二，防止類似與“三次握手”中提到了的“已經失效的連接配接請求封包段”出現在本連接配接中。用戶端發送完最後一個确認封包後，在這個2MSL時間中，就可以使本連接配接持續的時間内所産生的所有封包段都從網絡中消失。這樣新的連接配接中不會出現舊連接配接的請求封包。
8. 為什麼建立連接配接是三次握手，關閉連接配接确是四次揮手呢？
- 建立連接配接的時候， 伺服器在LISTEN狀态下，收到建立連接配接請求的SYN封包後，把ACK和SYN放在一個封包裡發送給用戶端。
- 而關閉連接配接時，伺服器收到對方的FIN封包時，僅僅表示對方不再發送資料了但是還能接收資料，而自己也未必全部資料都發送給對方了，是以己方可以立即關閉，也可以發送一些資料給對方後，再發送FIN封包給對方來表示同意現在關閉連接配接，是以，己方ACK和FIN一般都會分開發送，進而導緻多了一次。
3. TCP,UDP 協定的差別
UDP 在傳送資料之前不需要先建立連接配接，遠地主機在收到 UDP 封包後，不需要給出任何确認。雖然 UDP 不提供可靠傳遞，但在某些情況下 UDP 确是一種最有效的工作方式（一般用于即時通信），比如： QQ 語音、 QQ 視訊 、直播等等
TCP 提供面向連接配接的服務。在傳送資料之前必須先建立連接配接，資料傳送結束後要釋放連接配接。 TCP 不提供廣播或多點傳播服務。由于 TCP 要提供可靠的，面向連接配接的傳輸服務（TCP的可靠展現在TCP在傳遞資料之前，會有三次握手來建立連接配接，而且在資料傳遞時，有确認、視窗、重傳、擁塞控制機制，在資料傳完後，還會斷開連接配接用來節約系統資源），這一難以避免增加了許多開銷，如确認，流量控制，計時器以及連接配接管理等。這不僅使協定資料單元的首部增大很多，還要占用許多處理機資源。TCP 一般用于檔案傳輸、發送和接收郵件、遠端登入等場景。
使用TCP的協定有哪些？使用UDP的協定有哪些？
運作于TCP協定之上的協定：
- HTTP協定：超文本傳輸協定，用于普通浏覽
- HTTPS協定：安全超文本傳輸協定，身披SSL外衣的HTTP協定
- FTP協定：檔案傳輸協定，用于檔案傳輸
- POP3協定：郵局協定，收郵件使用
- SMTP協定：簡單郵件傳輸協定，用來發送電子郵件
- Telent協定：遠端登陸協定，通過一個終端登陸到網絡
- SSH協定：安全外殼協定，用于加密安全登陸，替代安全性差的Telent協定
運作于UDP協定之上的協定：
- DHCP協定：動态主機配置協定，動态配置IP位址
- NTP協定：網絡時間協定，用于網絡時間同步
- BOOTP協定：引導程式協定，DHCP協定的前身，用于無盤工作站從中心伺服器上擷取IP位址
4. TCP 協定如何保證可靠傳輸
- 應用資料被分割成 TCP 認為最适合發送的資料塊。
- TCP 給發送的每一個包進行編号，接收方對資料包進行排序，把有序資料傳送給應用層。
- 校驗和： TCP 将保持它首部和資料的檢驗和。這是一個端到端的檢驗和，目的是檢測資料在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP 将丢棄這個封包段和不确認收到此封包段。
- TCP 的接收端會丢棄重複的資料。
- 流量控制： TCP 連接配接的每一方都有固定大小的緩沖空間，TCP的接收端隻允許發送端發送接收端緩沖區能接納的資料。當接收方來不及處理發送方的資料，能提示發送方降低發送的速率，防止包丢失。TCP 使用的流量控制協定是可變大小的滑動視窗協定。 （TCP 利用滑動視窗實作流量控制）
- 擁塞控制： 當網絡擁塞時，減少資料的發送。
- ARQ協定： 也是為了實作可靠傳輸的，它的基本原理就是每發完一個分組就停止發送，等待對方确認。在收到确認後再發下一個分組。
- 逾時重傳： 當 TCP 發出一個段後，它啟動一個定時器，等待目的端确認收到這個封包段。如果不能及時收到一個确認，将重發這個封包段。
4.1 ARQ協定
自動重傳請求（Automatic Repeat-reQuest，ARQ）是OSI模型中資料鍊路層和傳輸層的錯誤糾正協定之一。它通過使用确認和逾時這兩個機制，在不可靠服務的基礎上實作可靠的資訊傳輸。如果發送方在發送後一段時間之内沒有收到确認幀，它通常會重新發送。ARQ包括停止等待ARQ協定和連續ARQ協定。
停止等待ARQ協定
- 停止等待協定是為了實作可靠傳輸的，它的基本原理就是每發完一個分組就停止發送，等待對方确認（回複ACK）。如果過了一段時間（逾時時間後），還是沒有收到 ACK 确認，說明沒有發送成功，需要重新發送，直到收到确認後再發下一個分組；
- 在停止等待協定中，若接收方收到重複分組，就丢棄該分組，但同時還要發送确認；
優點： 簡單
缺點： 信道使用率低，等待時間長
1) 無差錯情況:
發送方發送分組,接收方在規定時間内收到,并且回複确認.發送方再次發送。
2) 出現差錯情況（逾時重傳）:
停止等待協定中逾時重傳是指隻要超過一段時間仍然沒有收到确認，就重傳前面發送過的分組（認為剛才發送過的分組丢失了）。是以每發送完一個分組需要設定一個逾時計時器，其重傳時間應比資料在分組傳輸的平均往返時間更長一些。這種自動重傳方式常稱為 自動重傳請求 ARQ 。另外在停止等待協定中若收到重複分組，就丢棄該分組，但同時還要發送确認。連續 ARQ 協定 可提高信道使用率。發送維持一個發送視窗，凡位于發送視窗内的分組可連續發送出去，而不需要等待對方确認。接收方一般采用累積确認，對按序到達的最後一個分組發送确認，表明到這個分組位置的所有分組都已經正确收到了。
3) 确認丢失和确認遲到
- 确認丢失 ：确認消息在傳輸過程丢失。當A發送M1消息，B收到後，B向A發送了一個M1确認消息，但卻在傳輸過程中丢失。而A并不知道，在逾時計時過後，A重傳M1消息，B再次收到該消息後采取以下兩點措施：1. 丢棄這個重複的M1消息，不向上層傳遞。 2. 向A發送确認消息。（不會認為已經發送過了，就不再發送。A能重傳，就證明B的确認消息丢失）。
- 确認遲到 ：确認消息在傳輸過程中遲到。A發送M1消息，B收到并發送确認。在逾時時間内沒有收到确認消息，A重傳M1消息，B仍然收到并繼續發送确認消息（B收到了2份M1）。此時A收到了B第二次發送的确認消息。接着發送其他資料。過了一會，A收到了B第一次發送的對M1的确認消息（A也收到了2份确認消息）。處理如下：1. A收到重複的确認後，直接丢棄。2. B收到重複的M1後，也直接丢棄重複的M1。
連續ARQ協定
連續 ARQ 協定可提高信道使用率。發送方維持一個發送視窗，凡位于發送視窗内的分組可以連續發送出去，而不需要等待對方确認。接收方一般采用累計确認，對按序到達的最後一個分組發送确認，表明到這個分組為止的所有分組都已經正确收到了。
優點： 信道使用率高，容易實作，即使确認丢失，也不必重傳。
缺點： 不能向發送方反映出接收方已經正确收到的所有分組的資訊。 比如：發送方發送了 5條 消息，中間第三條丢失（3号），這時接收方隻能對前兩個發送确認。發送方無法知道後三個分組的下落，而隻好把後三個全部重傳一次。這也叫 Go-Back-N（回退 N），表示需要退回來重傳已經發送過的 N 個消息。
4.2 滑動視窗和流量控制
TCP 利用滑動視窗實作流量控制。流量控制是為了控制發送方發送速率，保證接收方來得及接收。 接收方發送的确認封包中的視窗字段可以用來控制發送方視窗大小，進而影響發送方的發送速率。将視窗字段設定為 0，則發送方不能發送資料。
4.3 擁塞控制
在某段時間，若對網絡中某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就要變壞。這種情況就叫擁塞。擁塞控制就是為了防止過多的資料注入到網絡中，這樣就可以使網絡中的路由器或鍊路不緻過載。擁塞控制所要做的都有一個前提，就是網絡能夠承受現有的網絡負荷。擁塞控制是一個全局性的過程，涉及到所有的主機，所有的路由器，以及與降低網絡傳輸性能有關的所有因素。相反，流量控制往往是點對點通信量的控制，是個端到端的問題。流量控制所要做到的就是抑制發送端發送資料的速率，以便使接收端來得及接收。
為了進行擁塞控制，TCP 發送方要維持一個 擁塞視窗(cwnd) 的狀态變量。擁塞控制視窗的大小取決于網絡的擁塞程度，并且動态變化。發送方讓自己的發送視窗取為擁塞視窗和接收方的接受視窗中較小的一個。
TCP的擁塞控制采用了四種算法，即 慢開始 、 擁塞避免 、快重傳 和 快恢複。在網絡層也可以使路由器采用适當的分組丢棄政策（如主動隊列管理 AQM），以減少網絡擁塞的發生。
- 慢開始： 慢開始算法的思路是當主機開始發送資料時，如果立即把大量資料位元組注入到網絡，那麼可能會引起網絡阻塞，因為現在還不知道網絡的符合情況。經驗表明，較好的方法是先探測一下，即由小到大逐漸增大發送視窗，也就是由小到大逐漸增大擁塞視窗數值。cwnd初始值為1，每經過一個傳播輪次，cwnd加倍。
- 擁塞避免： 擁塞避免算法的思路是讓擁塞視窗cwnd緩慢增大，即每經過一個往返時間RTT就把發送方的cwnd加1.
- 快重傳與快恢複： 在 TCP/IP 中，快速重傳和恢複（fast retransmit and recovery，FRR）是一種擁塞控制算法，它能快速恢複丢失的資料包。沒有 FRR，如果資料包丢失了，TCP 将會使用定時器來要求傳輸暫停。在暫停的這段時間内，沒有新的或複制的資料包被發送。有了 FRR，如果接收機接收到一個不按順序的資料段，它會立即給發送機發送一個重複确認。如果發送機接收到三個重複确認，它會假定确認件指出的資料段丢失了，并立即重傳這些丢失的資料段。有了 FRR，就不會因為重傳時要求的暫停被耽誤。 當有單獨的資料包丢失時，快速重傳和恢複（FRR）能最有效地工作。當有多個資料資訊包在某一段很短的時間内丢失時，它則不能很有效地工作。
5. 在浏覽器中輸入url位址 ->> 顯示首頁的過程
總體來說分為以下幾個過程:
- DNS解析
- TCP連接配接
- 發送HTTP請求
- 伺服器處理請求并傳回HTTP封包
- 浏覽器解析渲染頁面
- 連接配接結束
1. DNS解析
DNS解析的過程就是尋找哪台機器上有你需要資源的過程。當你在浏覽器中輸入一個位址時，例如www.baidu.com，其實不是百度網站真正意義上的位址。網際網路上每一台計算機的唯一辨別是它的IP位址，但是IP位址并不友善記憶。使用者更喜歡用友善記憶的網址去尋找網際網路上的其它計算機，也就是上面提到的百度的網址。是以網際網路設計者需要在使用者的友善性與可用性方面做一個權衡，這個權衡就是一個網址到IP位址的轉換，這個過程就是DNS解析。它實際上充當了一個翻譯的角色，實作了網址到IP位址的轉換。網址到IP位址轉換的過程是如何進行的?
DNS解析是一個遞歸查詢的過程。
上述圖檔是查找www.google.com的IP位址過程。首先在本地域名伺服器中查詢IP位址，如果沒有找到的情況下，本地域名伺服器會向根域名伺服器發送一個請求，如果根域名伺服器也不存在該域名時，本地域名會向com頂級域名伺服器發送一個請求，依次類推下去。直到最後本地域名伺服器得到google的IP位址并把它緩存到本地，供下次查詢使用。從上述過程中，可以看出網址的解析是一個從右向左的過程: com -> google.com -> www.google.com。但是你是否發現少了點什麼，根域名伺服器的解析過程呢？事實上，真正的網址是www.google.com.，并不是我多打了一個.，這個.對應的就是根域名伺服器，預設情況下所有的網址的最後一位都是.，既然是預設情況下，為了友善使用者，通常都會省略，浏覽器在請求DNS的時候會自動加上，所有網址真正的解析過程為: . -> .com -> google.com. -> www.google.com.。
DNS優化
了解了DNS的過程，可以為我們帶來哪些？上文中請求到google的IP位址時，經曆了8個步驟，這個過程中存在多個請求(同時存在UDP和TCP請求，為什麼有兩種請求方式，請自行查找)。如果每次都經過這麼多步驟，是否太耗時間？如何減少該過程的步驟呢？那就是DNS緩存。
DNS緩存
DNS存在着多級緩存，從離浏覽器的距離排序的話，有以下幾種: 浏覽器緩存，系統緩存，路由器緩存，IPS伺服器緩存，根域名伺服器緩存，頂級域名伺服器緩存，主域名伺服器緩存。
在你的chrome浏覽器中輸入:chrome://dns/，你可以看到chrome浏覽器的DNS緩存。
系統緩存主要存在/etc/hosts(Linux系統)中:
2. TCP連接配接
浏覽器獲得域名對應的IP位址以後，浏覽器向伺服器請求建立連結，發起三次握手；
3. 發送HTTP請求
其實這部分又可以稱為前端工程師眼中的HTTP，它主要發生在用戶端。發送HTTP請求的過程就是建構HTTP請求封包并通過TCP協定發送到伺服器指定端口(HTTP協定80/8080, HTTPS協定443)。HTTP請求封包是由三部分組成: 請求行, 請求報頭和請求正文。
4. 伺服器處理HTTP請求并傳回HTTP封包
自然而然這部分對應的就是後端工程師眼中的HTTP。後端從在固定的端口接收到TCP封包開始，這一部分對應于程式設計語言中的socket。它會對TCP連接配接進行處理，對HTTP協定進行解析，并按照封包格式進一步封裝成HTTP Request對象，供上層使用。這一部分工作一般是由Web伺服器去進行。
HTTP響應封包也是由三部分組成: 狀态碼, 響應報頭和響應封包。
5. 遊覽器解析渲染頁面
浏覽器是一個邊解析邊渲染的過程。首先浏覽器解析HTML檔案建構DOM樹，然後解析CSS檔案建構渲染樹，等到渲染樹建構完成後，浏覽器開始布局渲染樹并将其繪制到螢幕上。這個過程比較複雜，涉及到兩個概念: reflow(回流)和repain(重繪)。DOM節點中的各個元素都是以盒模型的形式存在，這些都需要浏覽器去計算其位置和大小等，這個過程稱為relow;當盒模型的位置,大小以及其他屬性，如顔色,字型,等确定下來之後，浏覽器便開始繪制内容，這個過程稱為repain。頁面在首次加載時必然會經曆reflow和repain。reflow和repain過程是非常消耗性能的，尤其是在移動裝置上，它會破壞使用者體驗，有時會造成頁面卡頓。是以我們應該盡可能少的減少reflow和repain。
浏覽器在解析過程中，如果遇到請求外部資源時，如圖像,iconfont,JS等。浏覽器将重複1-6過程下載下傳該資源。請求過程是異步的，并不會影響HTML文檔進行加載，但是當文檔加載過程中遇到JS檔案，HTML文檔會挂起渲染過程，不僅要等到文檔中JS檔案加載完畢還要等待解析執行完畢，才會繼續HTML的渲染過程。原因是因為JS有可能修改DOM結構，這就意味着JS執行完成前，後續所有資源的下載下傳是沒有必要的，這就是JS阻塞後續資源下載下傳的根本原因。CSS檔案的加載不影響JS檔案的加載，但是卻影響JS檔案的執行。JS代碼執行前浏覽器必須保證CSS檔案已經下載下傳并加載完畢。
6. 連接配接結束
6. URI和URL的差別是什麼?
- URI(Uniform Resource Identifier) 是統一資源标志符，可以唯一辨別一個資源。
- URL(Uniform Resource Location) 是統一資源定位符，可以提供該資源的路徑。它是一種具體的 URI，即 URL 可以用來辨別一個資源，而且還指明了如何 locate 這個資源。
URI的作用像身份證号一樣，URL的作用更像家庭住址一樣。URL是一種具體的URI，它不僅唯一辨別資源，而且還提供了定位該資源的資訊。
7. HTTP 和 HTTPS 的差別？
- 端口 ：HTTP的URL由“http://”起始且預設使用端口80，而HTTPS的URL由“https://”起始且預設使用端口443。
- 安全性和資源消耗： HTTP協定運作在TCP之上，所有傳輸的内容都是明文，用戶端和伺服器端都無法驗證對方的身份。HTTPS是運作在SSL/TLS之上的HTTP協定，SSL/TLS 運作在TCP之上。所有傳輸的内容都經過加密，加密采用對稱加密，但對稱加密的密鑰用伺服器方的證書進行了非對稱加密。是以說，HTTP 安全性沒有 HTTPS高，但是 HTTPS 比HTTP耗費更多伺服器資源。
- 費用：https協定需要到ca申請證書，一般免費證書較少，因而需要一定費用。
對稱加密：密鑰隻有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；
非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。
8. 狀态碼
2XX——表明請求被正常處理了
- 200 OK：請求已正常處理。
- 204 No Content：請求處理成功，但沒有任何資源可以傳回給用戶端，一般在隻需要從用戶端往伺服器發送資訊，而對用戶端不需要發送新資訊内容的情況下使用。
- 206 Partial Content：是對資源某一部分的請求，該狀态碼表示用戶端進行了範圍請求，而伺服器成功執行了這部分的GET請求。響應封包中包含由Content-Range指定範圍的實體内容。
3XX——表明浏覽器需要執行某些特殊的處理以正确處理請求
- 301 Moved Permanently：資源的uri已更新，你也更新下你的書簽引用吧。永久性重定向，請求的資源已經被配置設定了新的URI，以後應使用資源現在所指的URI。
- 302 Found：資源的URI已臨時定位到其他位置了，姑且算你已經知道了這個情況了。臨時性重定向。和301相似，但302代表的資源不是永久性移動，隻是臨時性性質的。換句話說，已移動的資源對應的URI将來還有可能發生改變。
-
303 See Other：資源的URI已更新，你是否能臨時按新的URI通路。該狀态碼表示由于請求對應的資源存在着另一個URL，應使用GET方法定向擷取請求的資源。303狀态碼和302狀态碼有着相同的功能，但303狀态碼明确表示用戶端應當采用GET方法擷取資源，這點與302狀态碼有差別。
當301,302,303響應狀态碼傳回時，幾乎所有的浏覽器都會把POST改成GET，并删除請求封包内的主體，之後請求會自動再次發送。
- 304 Not Modified：資源已找到，但未符合條件請求。該狀态碼表示用戶端發送附帶條件的請求時（采用GET方法的請求封包中包含If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since中任一首部）服務端允許請求通路資源，但因發生請求未滿足條件的情況後，直接傳回304.。
- 307 Temporary Redirect：臨時重定向。與302有相同的含義。
4XX——表明用戶端是發生錯誤的原因所在
- 400 Bad Request：伺服器端無法了解用戶端發送的請求，請求封包中可能存在文法錯誤。
- 401 Unauthorized：該狀态碼表示發送的請求需要有通過HTTP認證（BASIC認證，DIGEST認證）的認證資訊。
- 403 Forbidden：不允許通路那個資源。該狀态碼表明對請求資源的通路被伺服器拒絕了。（權限，未授權IP等）
- 404 Not Found：伺服器上沒有請求的資源。路徑錯誤等。
5XX——伺服器本身發生錯誤
- 500 Internal Server Error：貌似内部資源出故障了。該狀态碼表明伺服器端在執行請求時發生了錯誤。也有可能是web應用存在bug或某些臨時故障。
- 503 Service Unavailable：抱歉，我現在正在忙着。該狀态碼表明伺服器暫時處于超負載或正在停機維護，現在無法處理請求。
9. HTTP長連接配接,短連接配接
在HTTP/1.0中預設使用短連接配接。也就是說，用戶端和伺服器每進行一次HTTP操作，就建立一次連接配接，任務結束就中斷連接配接。當用戶端浏覽器通路的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript檔案、圖像檔案、CSS檔案等），每遇到這樣一個Web資源，浏覽器就會重建立立一個HTTP會話。
而從HTTP/1.1起，預設使用長連接配接，用以保持連接配接特性。使用長連接配接的HTTP協定，會在響應頭加入這行代碼：
Connection:keep-alive
在使用長連接配接的情況下，當一個網頁打開完成後，用戶端和伺服器之間用于傳輸HTTP資料的TCP連接配接不會關閉，用戶端再次通路這個伺服器時，會繼續使用這一條已經建立的連接配接。Keep-Alive不會永久保持連接配接，它有一個保持時間，可以在不同的伺服器軟體（如Apache）中設定這個時間。實作長連接配接需要用戶端和服務端都支援長連接配接。
HTTP協定的長連接配接和短連接配接，實質上是TCP協定的長連接配接和短連接配接。
HTTP長連接配接、短連接配接究竟是什麼？
10. HTTP是不儲存狀态的協定,如何儲存使用者狀态?
HTTP 是一種不儲存狀态，即無狀态（stateless）協定。也就是說 HTTP 協定自身不對請求和響應之間的通信狀态進行儲存。那麼我們儲存使用者狀态呢？Session 機制的存在就是為了解決這個問題，Session 的主要作用就是通過服務端記錄使用者的狀态。典型的場景是購物車，當你要添加商品到購物車的時候，系統不知道是哪個使用者操作的，因為 HTTP 協定是無狀态的。服務端給特定的使用者建立特定的 Session 之後就可以辨別這個使用者并且跟蹤這個使用者了（一般情況下，伺服器會在一定時間内儲存這個 Session，過了時間限制，就會銷毀這個Session）。
在服務端儲存 Session 的方法很多，最常用的就是記憶體和資料庫(比如是使用記憶體資料庫redis儲存)。既然 Session 存放在伺服器端，那麼我們如何實作 Session 跟蹤呢？大部分情況下，我們都是通過在 Cookie 中附加一個 Session ID 來方式來跟蹤。
Cookie 被禁用怎麼辦?
最常用的就是利用 URL 重寫把 Session ID 直接附加在URL路徑的後面。
11. Cookie的作用是什麼?和Session有什麼差別？
Cookie 和 Session都是用來跟蹤浏覽器使用者身份的會話方式，但是兩者的應用場景不太一樣。
Cookie 一般用來儲存使用者資訊 比如①我們在 Cookie 中儲存已經登入過得使用者資訊，下次通路網站的時候頁面可以自動幫你登入的一些基本資訊給填了；②一般的網站都會有保持登入也就是說下次你再通路網站的時候就不需要重新登入了，這是因為使用者登入的時候我們可以存放了一個 Token 在 Cookie 中，下次登入的時候隻需要根據 Token 值來查找使用者即可(為了安全考慮，重新登入一般要将 Token 重寫)；③登入一次網站後通路網站其他頁面不需要重新登入。Session 的主要作用就是通過服務端記錄使用者的狀态。 典型的場景是購物車，當你要添加商品到購物車的時候，系統不知道是哪個使用者操作的，因為 HTTP 協定是無狀态的。服務端給特定的使用者建立特定的 Session 之後就可以辨別這個使用者并且跟蹤這個使用者了。
Cookie 資料儲存在用戶端(浏覽器端)，Session 資料儲存在伺服器端。
Cookie 存儲在用戶端中，而Session存儲在伺服器上，相對來說 Session 安全性更高。如果要在 Cookie 中存儲一些敏感資訊，不要直接寫入 Cookie 中，最好能将 Cookie 資訊加密然後使用到的時候再去伺服器端解密。
12. HTTP 1.0和HTTP 1.1的主要差別是什麼?
這部分回答引用這篇文章 https://mp.weixin.qq.com/s/GICbiyJpINrHZ41u_4zT-A? 的一些内容。
HTTP1.0最早在網頁中使用是在1996年，那個時候隻是使用一些較為簡單的網頁上和網絡請求上，而HTTP1.1則在1999年才開始廣泛應用于現在的各大浏覽器網絡請求中，同時HTTP1.1也是目前使用最為廣泛的HTTP協定。 主要差別主要展現在：
- 長連接配接 : 在HTTP/1.0中，預設使用的是短連接配接，也就是說每次請求都要重建立立一次連接配接。HTTP 是基于TCP/IP協定的,每一次建立或者斷開連接配接都需要三次握手四次揮手的開銷，如果每次請求都要這樣的話，開銷會比較大。是以最好能維持一個長連接配接，可以用個長連接配接來發多個請求。HTTP 1.1起，預設使用長連接配接 ,預設開啟Connection： keep-alive。 HTTP/1.1的持續連接配接有非流水線方式和流水線方式 。流水線方式是客戶在收到HTTP的響應封包之前就能接着發送新的請求封包。與之相對應的非流水線方式是客戶在收到前一個響應後才能發送下一個請求。
- 錯誤狀态響應碼 :在HTTP1.1中新增了24個錯誤狀态響應碼，如409（Conflict）表示請求的資源與資源的目前狀态發生沖突；410（Gone）表示伺服器上的某個資源被永久性的删除。
- 緩存處理 :在HTTP1.0中主要使用header裡的If-Modified-Since,Expires來做為緩存判斷的标準，HTTP1.1則引入了更多的緩存控制政策例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存政策。
- 帶寬優化及網絡連接配接的使用 :HTTP1.0中，存在一些浪費帶寬的現象，例如用戶端隻是需要某個對象的一部分，而伺服器卻将整個對象送過來了，并且不支援斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它允許隻請求資源的某個部分，即傳回碼是206（Partial Content），這樣就友善了開發者自由的選擇以便于充分利用帶寬和連接配接。
13. Get與POST的差別
- 從功能上講，GET一般用來從伺服器上擷取資源，POST一般用來更新伺服器上的資源；
- 從REST服務角度上說，GET是幂等的，即讀取同一個資源，總是得到相同的資料，而POST不是幂等的，因為每次請求對資源的改變并不是相同的；進一步地，GET不會改變伺服器上的資源，而POST會對伺服器資源進行改變；
- 從請求參數形式上看，GET請求的資料會附在URL之後，即将請求資料放置在HTTP封包的 請求頭 中，以?分割URL和傳輸資料，參數之間以&相連。特别地，如果資料是英文字母/數字，原樣發送；否則，會将其編碼為 application/x-www-form-urlencoded MIME 字元串(如果是空格，轉換為+，如果是中文/其他字元，則直接把字元串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符号以16進制表示的ASCII)；而POST請求會把送出的資料則放置在是HTTP請求封包的 請求體 中。
- 就安全性而言，POST的安全性要比GET的安全性高，因為GET請求送出的資料将明文出現在URL上，而且POST請求參數則被包裝到請求體中，相對更安全。
- 從請求的大小看，GET請求的長度受限于浏覽器或伺服器對URL長度的限制，允許發送的資料量比較小，而POST請求則是沒有大小限制的。
還會補充----------------------