計算機網絡以前端必備

1、計算機網絡TCP

衆所周知:TCP是一種可靠傳輸的協議。面向字節流、全雙工通訊、可靠、面向鏈接。php

報文段格式css

TCP雖然是面向字節流的,可是他的基本傳輸單元確實報文段。報文段 = 首部 + 數據部分。html

首部字段中有幾個字段的意義很是的重要,直接體現該段的功能。web

一、實現無差錯傳輸的解決方案

無差錯傳輸是其最大特色,也是最難實現之處。面試

基本思想算法

  • 當咱們傳輸出錯的時候,要求重傳。
  • 當咱們接受方來不及接收的時候,咱們能夠適當減小發送的速率和發送的數量。

解決辦法後端

  • 重傳機制(自動重傳請求協議ARQ)
  • 流量控制和擁塞控制

這也是咱們學習TCP最爲重要的東西,咱們需瞭解TCP的可靠傳輸原理。瀏覽器

方法一: 自動重傳請求協議ARQ

中止 —— 等待 ARQ安全

所謂中止等待協議就是每發送完一組數據後,等待對方確認而且收到確認後,再發送下一組數據。bash

發送數據,收到數據,發送確認,收到確認。
複製代碼

無差錯傳輸

發送方發送分組,接收方在規定時間內收到,而且回覆確認.發送方再次發送.這是最爲理想的狀況,每次發送都在接收到上一次的確認回覆後再次發送。

傳輸差錯

傳輸過程當中某一條發生了丟失,致使在必定時間內收不到確認回覆,當超過定時器設置的時間以後,就會從新發送上一條數據。

確認丟失

上面咱們說了發送時機丟失的狀況,接下來咱們看一下確認階段丟失的狀況:

A發送數據,B收到後發送確認消息,可是確認消息途中丟失了,A並不知道B是否收到,超太重傳時間以後,就會從新發送數據,B接收到以後發現是重複發送,則丟棄該次發送的數據,從新發送確認信息。

確認遲到

A發送M1消息,B收到併發送確認。在超時時間內沒有收到確認消息,A重傳M1消息,B仍然收到並繼續發送確認消息(B收到了2份M1)。此時A收到了B第二次發送的確認消息。接着發送其餘數據。過了一會,A收到了B第一次發送的對M1的確認消息(A也收到了2份確認消息)。處理以下: A丟棄重複確認。 B丟棄重複信息。

連續ARQ協議

這是TCP的一個精華之所在,這裏咱們還須要知道滑動窗口協議的概念。

認識滑動窗口協議

首先咱們來認識滑動窗口協議。其中包括了兩個窗口,一個是發送窗口、一個是接收窗口

工做原理

發送方每收到一個確認,就把發送窗口向前滑動一個分組的位置。接收方通常採用累積確認的方式,對按序到達的最後一個分組發送確認。也就是說接收方沒必要對收到的分組逐個發送確認。而是對按序到達的最後一個發送確認。發送方收到確認信息後,認爲以前該信號以前的已經發送完畢,向前移動發送窗口至該信號,繼續發送。

通俗來說:發送方發送了5條消息,中間第三條丟失(3號),這時接收方只能對前兩個發送確認(發送確認2)。發送方沒法知道後三個分組的下落,而只好把後三個所有重傳一次。

他固然也有本身的優缺點。優勢是:容易實現,即時確認丟失也沒必要重傳。但缺點是不能向發送方反映出接收方已經正確收到的全部分組信息。

一個數據報文段的狀態能夠分爲四種:

中止等待ARQ VS 連續ARQ

經過下圖分析,咱們能夠看出,中止等待協議的信道利用率明顯太低。使用連續的ARQ協議能夠大大的提升信道利用率。

方法二: 流量控制 && 擁塞控制

流量控制

當TCP鏈接創建以後,接收方會告訴發送方本身的接收窗口大小,從而控制發送方窗口。

以下是一個調整發送速率的例子:

擁塞控制

防止過多的數據注入網絡,致使網絡擁擠,路由器、鏈路過載等狀況。

  • 與流量控制的區別:
類型 範圍 面向對象 效果
流量控制 點對點,端對端 發送方 控制發送速率
擁塞控制 全局性 整個網絡 防止過多的數據注入網絡

具體有兩種解決方案:慢開始 + 擁塞避免, 快重傳 + 快恢復。

(1)慢開始 + 擁塞避免

  • 擁塞窗口

爲了防止擁塞,TCP要求發送方維持一個擁塞窗口cwnd。擁塞窗口的值取決於網絡擁塞程度,而且動態變化着,發送方根據擁塞窗口和接收窗口來取最小值爲發送窗口的大小。

  • 慢開始

首先初始化一個慢開始門限ssthresh。

【階段1 => 階段2】 : 採用慢開始算法: 當開始發送數據的時候,從小到大一次遞增。從最開始的cwnd = 1.每通過一次就翻一倍。所以是 一、二、四、八、16...;直到 cwnd >= ssthresh。

  • 擁塞控制

【階段2 => 階段3】 :採用擁塞避免算法。(加法增大) 下降增加速度,每通過一個往返時間RTT,發送方的擁塞窗口(cwnd)加1。直到遇到網絡擁塞。

【階段3 => 階段4】:採用乘法減小。 當遇到網絡擁塞的時候,立馬將cwnd設置爲1.將ssthresh設置爲發生擁塞是擁塞窗口的一半。

【階段4 => 階段5】:從新執行慢開始算法。

(2)快重傳 + 快恢復

首先初始化一個慢開始門限ssthresh。

【階段1 => 階段2】 : 採用慢開始算法: 當開始發送數據的時候,從小到大一次遞增。從最開始的cwnd = 1.每通過一次就翻一倍。所以是 一、二、四、八、16...;直到 cwnd >= ssthresh。

【階段2 => 階段3】 :採用擁塞避免算法。(加法增大) 下降增加速度,每通過一個往返時間RTT,發送方的擁塞窗口(cwnd)加1。直到遇到網絡擁塞。

【階段3 => 階段4】 :快重傳 + 快恢復 當發生擁塞的時候,快重傳算法首先要求接收方每收到一個失序的報文段後就當即發出重複確認。這樣作可讓發送方及早知道有報文段沒有到達接收方。發送方只要一連收到三個重複確認就應當當即重傳對方還沒有收到的報文段。立馬開始從新傳輸。這意味這不是丟失了重傳計時器,而是加快了反應。 同時將ssthresh設置爲擁塞窗口的一半,cwnd也設置爲一半。

【階段4 => 階段5】:擁塞控制 每通過一個往返時間RTT,發送方的擁塞窗口(cwnd)加1。直到遇到網絡擁塞。

  • 快重傳

二、TCP鏈接與釋放

(1)創建鏈接的過程

創建的過程咱們常稱爲三次握手~

SYN = 1 表示須要對方回覆確認
ACK = 1 表示該條信息爲確認信息
seq 表示當前的序號
ack 表示指望下次從哪開始發送


第一次:喂,你能聽到我說話嗎? (將初始序號發送過去)SYN = 1, seq = x
第二次:嗯,聽獲得,你能聽到我說話嗎? (回覆確認)SYN = 1,ACK = 1,seq = x + 1, seq = y
第三次:嗯,我也聽獲得,我要開始發送數據了~(回覆確認)ACK = 1, seq = x + 1, ack = y + 1

複製代碼

(2)鏈接釋放的過程

四次揮手:

SYN = 1 表示須要對方回覆確認
ACK = 1 表示該條信息爲確認信息
seq 表示當前的序號
ack 表示指望下次從哪開始發送
FIN 表示終止的信號,表示本身這方要準備斷開鏈接了


第一次:喂,我要關閉鏈接了~ FIN = 1 seq = x
第二次:好,我還有沒發送完的東西,等會 ACK = 1,seq = y,ack = x + 1
第三次:好了,我發送完畢了,我立刻要斷開鏈接了哦~ FIN = 1;ACK = 1;seq  = w,ack = x + 1;
第四次:ok,拜拜,合做愉快~~  ACK = 1;seq = x + 1, ack = w + 1
複製代碼

這裏的 seq,ack 是用來協商發送數據的開始序列的,當鏈接創建以後,發送方從那個序號開始發送,接收方就從那個序號開始接收,爲了確保準確無誤的接收。

2、計算機網絡UDP (用戶數據報協議)

UDP:面向無鏈接、面向報文、盡最大能力的交付,屬於不可靠傳輸、支持一對1、一對多、多對多通訊。

  • TCP vs UDP

3、計算機網絡HTTP

一、計算機網絡體系結構

計算機網絡體系結構分爲3種:OSI體系結構TCP / IP體系結構五層體系結構.

OSI是7層體系結構,
TCP/IP 是4層體系結構(網絡接口層、網絡層、傳輸層、應用層)
五層網絡體系結構則把網絡接口層分爲了物理層和數據鏈路層。
複製代碼

其實咱們最關注的仍是傳輸層和應用層。

二、HTTP協議的基本知識點

HTTP協議一般承載與TCP協議之上;有時候也承載與TLS和SSL之上,此時變成了HTTPS協議。

三、工做方式

  • HTTP協議採用 請求 / 響應 的工做方式
  • 具體工做流程以下:

四、HTTP報文

請求報文

響應報文

注意:

請求報文的回車換行符是必須的,請求行和狀態行的空格也是必須的。
複製代碼

五、HTTP請求方式

GET

從指定服務器獲取數據

使用該方法後,查詢字段會拼接到url末尾
請求字符串有長度限制
get方式的請求路徑能被瀏覽器保存
get方法主要以獲取數據
get方法不該該在處理銘感信息時候使用
複製代碼

POST

提交指定數據給服務器處理

POST發送的請求。包含的數據字段會保存在請求體中,發送給服務器
post請求的數據沒有長度大小限制
請求路徑不能被保存爲書籤
POST請求不會保存在瀏覽器瀏覽記錄中
複製代碼

DELETE

按請求URL來刪除指定的文件

PUT

將文件保存到url指定的位置。

HEAD

獲取報文首部。同GET方式相似,可是不返回主體內容,只是返回首部信息,用來判斷URI的有效性、資源更新的時間等。

OPTIONS

詢問支持的方法,詢問某個URI所支持的請求方式。 返回如:Allow: GET,POST,HEAD,DELETE

五、HTTP請求首部

HTTP首部是構成HTTP報文的重要內容,在客戶端和服務器之間的通訊過程當中,不管是請求仍是響應都須要請求首部,請求首部在傳遞的過程當中起着傳遞額外信息的做用。(好比:主體大小、編碼方式、域、認證信息等)

(1)通用首部字段

字段名 解釋 書寫格式
Cache-Control 控制緩衝機制,具體指令看下圖,(可用於請求和響應) Cache-Control: private, max-age=0, no-cache
Date 表示HTTP報文建立時間 Date:Fri, 19 Oct 2018 09:45:13 GMT
Connection 控制代理再也不轉發的字段,管理持久鏈接。如Connection:Upgrade,那麼在通過代理後,Upgrade首部字段將不會被髮送至服務器。同時能夠管理持久鏈接,Connection:Keep-Alive表示開啓長鏈接,Connection: close表示關閉本次鏈接.HTTP/1.1 版本的默認鏈接都是持久鏈接。爲此,客戶端會在持 久鏈接上連續發送請求。當服務器端想明確斷開鏈接時,則指定 Connection 首部字段的值爲 Close。 Connection:Upgrade; Connection:Keep-Alive; Connection:close;
Pragma Pragma 是 HTTP/1.1 以前版本的歷史遺留字段,僅做爲與 HTTP/1.0 的向後兼容而定義。 Pragma: no-cache
Transfer-Encoding 規定了傳輸報文主體採用的編碼方式 Transfer-Encoding: chunked
Via 沒通過一個代理或者網關都會往該字段裏面添加服務器信息,以下圖

下圖是上訴首部字段的圖解~~

(2)請求首部字段

字段名 解釋 書寫格式
Accept 告訴服務器這邊的用戶代理可以處理的媒體類型以及優先級,使用q表示優先級,q默認是1,取值範圍是0-1,1爲最高 Accept: text/html,application/xhtml+xml,application/xml;q=0.
Accept-Charset 通知服務器,用戶代理這邊能夠接受的字符集,字符集的優先順序,q來表示優先級別 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
Accept-Encoding 用戶代理支持的壓縮方式 Accept-Encoding: gzip, deflate
Accept-Language 通知服務器,用戶代理支持的語言,q來表示優先級 Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3
Authorization 用來告知服務器,用戶的代理認證信息 Authorization: Basic dWVub3NlbjpwYXNzd29yZA==
Expert 告知服務器,指望出現某種行爲,好比:首先,客戶端先發送了一個請求,這個請求的header中包含了一個屬性expect: 100-continue。這種狀況通常出現於上傳大容量body或者是須要驗證的時候。這時服務器會讀取請求的header並返回一個100 continue的響應,若是服務器能夠提供這項服務的話。客戶端再將http請求發送回去。而後服務器會讀取請求的body而且在成功後返回200狀態碼。 Expect: 100-continue
Host 告知服務器,所訪問的資源在互聯網中的主機名和端口(必須包含在首部內) 首部字段 Host 和以單臺服務器分配多個域名的虛擬主機的工做機制 有很密切的關聯,這是首部字段 Host 必須存在的意義。 Host: xxx
User-Agent 發送瀏覽器的類別,型號 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Ge
TE 告知服務器,客戶端可以處理的響應的傳輸編碼方式,以及相對優先級,與Accept-Encoding相似,可是該處用於傳輸 TE: gzip, deflate;q=0.5
Referer 指明咱們當前的請求是從哪一個web頁面發起的 從首頁發起 Referer: https://m.suning.com/
Range 告知服務器我要訪問哪一個範圍內的資源 Range: bytes=5001-10000

下面咱們再來本身分析一下請求首部中的帶有if-的條件首部:

形如 If-xxx 這種樣式的請求首部字段,均可稱爲條件請求。服務器接 收到附帶條件的請求後,只有判斷指定條件爲真時,纔會執行請求。

  • If-Match

If-Match會傳遞一個ETag值過去,若是要訪問的這個資源,當前的ETag正好是這個,那麼就返回,若是對不上,那麼就返回 412 Precondition Failed(客戶端請求條件錯誤)。若是值是 * ,則表示只要資源存在便可。

  • If-Modified-Since

修改時間 > 傳入的時間

若是在 If-Modified-Since指定的日期以後資源發生了更新,那麼就返回響應,否者不會返回。

  • If-None-Modified

與 If-Match 首部字段的做用相反,只有比對傳入的Etag和最新的ETag不一致纔會接受請求。若是爲*,則只有不存在了纔會接受請求。

  • If-Unmodified-Since

修改時間 < 傳入的時間

首部字段 If-Unmodified-Since 和首部字段 If-Modified-Since 的做用相 反。它的做用的是告知服務器,指定的請求資源只有在字段值內指定 的日期時間以後,未發生更新的狀況下,才能處理請求。

  • If-Range

若是If-Range的值與服務器的ETag或更新時間一致,那麼可使用下方的Range字段,來返回相應範圍的內容。

(3)響應首部字段

字段名 解釋 書寫格式
Accept-Ranges 告知客戶端,我服務器能夠處理範圍請求 Accept-Ranges: bytes
ETag 首部字段 ETag 能告知客戶端實體標識。它是一種可將資源以字符串 形式作惟一性標識的方式。服務器會爲每份資源分配對應的 ETag 值。 ETag: "82e22293907ce725faf67773957acd12"
Location 以將響應接收方引導至某個與請求 URI 位置 不一樣的資源。 Location: http://www.usagidesign.jp/sample.html

(4)實體首部字段

字段名 解釋 書寫格式
Allow 資源容許請求的方式 Allow:GET, HEAD。
Expires 資源過時的日期 Expires:Fri, 20 Oct 2018 09:45:13 GMT
Last-Modified 資源最後一次修改的時間 Last-Modified:Fri, 15 Oct 2018 09:45:13 GMT
Content-Encoding, Content-Type, Content-Language, Content-Range 表示資源具體的信息

(5)Cookies相關

字段名 解釋 書寫格式
Set-Cookie 服務端返回,用於設置Cookie Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31
Cookie 服務器接收cookie值,由客戶端發出 Cookie: status=enable

六、HTTP狀態碼

信息性狀態碼的介紹

100 Continue

100 狀態碼主要用於優化某些操做,好比客戶端不知道服務端可否處理咱們接下來要發送的這個實體主體,所以先發送一個Expert字段,而且客戶端不能一直等待服務器的100Continue響應,超過必定返回客戶端回自動發出該實體主體。若是服務器返回了417,說明了咱們Expert字段無效,服務器沒法理解。

101 Switching Protocols

Upgrade字段用於告訴服務端切換Http版本,若是能夠服務端將返回101.

成功性狀態碼的介紹

200 ok

請求成功,同時說明響應報文中含有實體內容。

201 Created

201 Created:請求已經被實現,並且有一個新的資源已經依據請求的須要而創建,且其URI已經隨Location頭信息返回或者在響應體了(好比put方式上傳文件)。假如須要的資源沒法及時創建的話,應當返回'202Accepted'。

202 Accepted

請求已被創建,可是服務器還未對其作任何處理。

204 Not Content

服務器成功處理了請求,可是並無返回任何實體內容。(好比刷新表單)

205 Reset Content

告知瀏覽器清除當前頁面html表單元素。

206 Partial Content

表示成功執行了一部分後者是Range請求。好比咱們使用的迅雷,咱們都是片斷下載,咱們能夠控制暫停和執行。

重定向狀態碼的介紹

300 Multiple Choices

多重選擇,請求的資源能夠包含多個位置信息,好比咱們的頁面能夠有多個語言版本,默認會顯示某個語言,用戶可根據本身的狀況去選擇其餘。

301 Moved Permanently

永久重定向。請求的資源已被永久的移動到新URI,返回信息會包括新的URI,瀏覽器會自動定向到新URI。

302 Found

臨時重定向。但資源只是臨時被移動。客戶端應繼續使用原有URI訪問。

303 See Other

查看其它地址。與301相似。其主要目的就是將POST響應定位到指定URI。後面還會說到一個307,它與301相似,咱們下面作比較。

304 Not Modified

未修改。所請求的資源未修改,服務器返回此狀態碼時,不會返回任何資源,咱們能夠訪問緩衝。

305 Use Proxy

表示咱們所請求的資源須要代理才行。

307 Temporary Redirect

臨時重定向。與303相似,場景:咱們訪問test.php,使用post請求發送數據,而後test作了處理讓其重定向了一下,使用303讓其重定向到test1.php。這時候咱們想在test1中拿到請求數據,這時候咱們發線拿不到的。可是若是咱們把303改成307,那麼就能夠拿到數據。咱們能夠經過抓包工具發現,使用307以後,重定向的請求仍是post,而使用303的重定向則是使用的get方式了。

客戶端錯誤狀態碼的介紹

400 Bad Request

客戶端請求的語法錯誤,服務器沒法理解

401 Unauthorized

請求要求用戶身份驗證。

403 Forbidden

客戶端的請求被拒絕了。

404 Not Found

服務器沒法根據客戶端的請求找到資源(網頁)。平時開發中出現這個,最多的緣由就是URI寫錯了。

405 Method Not Allowed

客戶端請求中的方法被禁止,請求方式不對應。

服務器錯誤狀態碼

500 Internal Server Error

服務器內部錯誤。

501 Not Implemented

服務器沒法正常完成請求。好比某種請求方式服務器不支持。

502 Bad Gateway

做爲網關或者代理工做的服務器嘗試執行請求時,從遠程服務器接收到了一個無效的響應

七、HTTP其餘特色

4、計算機網絡HTTPS

5、Web安全

6、面試題集

TCP 協議如何保證可靠傳輸?

爲何TCP創建鏈接需三次握手?

由於在網絡傳輸中是存在延遲的,有時候可能對方沒收到,也可能發生了超時重傳,
因此三次握手才能最大程度上保證鏈接可以正確創建,不會形成死鎖。

就好比一種狀況:

A發送給B,可是途中延遲,超過了重傳時間,這時候A發送了第二條到B,
B收到後,正式開始AB通訊,AB正常通訊完畢,這時候上一次發送的數據過來了,
B認爲A又要鏈接了,就發送確認信號,可是A知道,這是上次發的,
因此就不會給B發送數據了,B自做多情的在那等啊等。A一直不發,B一直等。
這就致使了死鎖發生。
複製代碼

爲何TCP釋放鏈接需四次揮手?

最後一次揮手是很是有必要的,由於只有此次確認信號收到了,
服務器才知道本身能夠真正的關閉了,上一次的消息客戶端是肯定收到了。
複製代碼

爲何客戶端關閉鏈接前要等待2MSL時間?(TIME—WAIT)

一、爲了保證服務器能接收到第四次分組數據,若是中途丟失了,
那麼服務器確定會從新發送第三次的數據,
那麼客戶端可以及時的再發送一次確認信號,保證服務器能準確接收到第四次握手信息

二、同時也確保咱們以前發送的延遲迴來的信息可以所有被處理完。
防止下一次鏈接時,出現上一次沒處理的失效報文

複製代碼

在瀏覽器中輸入url地址到頁面的呈現都發生了什麼?

若是問到了這麼一個過程,那麼其實就是在考你HTTP事物流程。

DNS域名解析拿到IP地址
TCP三次握手創建HTTP鏈接
客戶端發送請求到服務器
服務器處理請求並返回響應報文
瀏覽器解析並渲染頁面,同時請求加載靜態資源
TCP四次揮手斷開鏈接
複製代碼

DNS域名解析

在瀏覽器輸入網址後,首先要通過域名解析,由於瀏覽器並不能直接經過域名找到對應的服務器,而是要經過 IP 地址。

認識IP地址

IP地址標識了 每個網絡和每一臺主機。
複製代碼

具體過程以下(如訪問www.google.com)

一、首先瀏覽器去找本身的DNS緩衝,若是找到了直接返回,若是沒找到進行下一步
二、搜索操做系統自身的DNS緩衝,若是找到了直接返回,若是沒找到進行下一步
三、讀取電腦hosts文件,若是該文件有配置,則直接讀取返回,若是沒找到進行下一步
四、向本地配置的首選DNS服務器發起域名解析請求,若是它找到了直接返回,若是沒有進行下一步,哎呀我也不清楚,我去問問根域名服務器吧。
五、根域名服務器也不清楚,可是他知道com的域名服務器,因而說,你去問問com域名服務器吧
六、因而來到了com頂級域名服務器,老哥,你知道www.google.com的IP地址嗎?哎呀抱歉,我也不清楚,我知道google.com服務器的地方,你去問問他吧。
七、展轉來到了google.com域名服務器這裏,老哥你知道www.google.com的IP地址嗎?哎呀,我還真知道,我告訴你啊,他的IP是xxxx
八、個人麻葉終於拿到了,快告訴客戶端吧,我還得把這個緩衝一下,否則下次還得找個半死。
複製代碼

DNS優化處理

  • DNS負載均衡:DNS負載均衡技術的實現原理是在DNS服務器中爲同一個主機名配置多個IP地址,在應答DNS查詢時, DNS服務器對每一個查詢將以DNS文件中主機記錄的IP地址按順序返回不一樣的解析結果,將客戶端的訪問 引導到不一樣的機器上去,使得不一樣的客戶端訪問不一樣的服務器,從而達到負載均衡的目的。

  • CDN加速:利用DNS的重定向技術,DNS服務器會返回一個跟 用戶最接近的點的IP地址給用戶,CDN節點的服務器負責響應用戶的請求,提供所需的內容。

瀏覽器解析渲染頁面

咱們來了解一下瀏覽器的渲染流程~~

  • 瀏覽器的組成

名稱 功能
用戶界面 (User Interface) 包括地址欄、後退/前進按鈕、書籤目錄等,也就是你所看到的除了用來顯示你所請求頁面的主窗口以外的其餘部分
瀏覽器引擎 (Browser Engine) 用來查詢及操做渲染引擎的接口
渲染引擎 (Rendering Engine) 用來顯示請求的內容,例如,若是請求內容爲html,它負責解析html及css,並將解析後的結果顯示出來
網絡 (Networking) 用來完成網絡調用,例如http請求,它具備平臺無關的接口,能夠在不一樣平臺上工做
JS解釋器 (JS Interpreter) 用來解釋執行JS代碼
UI後端 (UI Backend) 用來繪製相似組合選擇框及對話框等基本組件,具備不特定於某個平臺的通用接口,底層使用操做系統的用戶接口
數據存儲 (DB Persistence) 屬於持久層,瀏覽器須要在硬盤中保存相似cookie的各類數據,HTML5定義了web database技術,這是一種輕量級完整的客戶端存儲技術

總之瀏覽器由:用戶界面、瀏覽器引擎、渲染引擎、網絡、js解釋器、UI後端、和數據持久層組成。下層爲上層提供調用的接口和服務。

  • 瀏覽器是多進程的

瀏覽器有一個主控進程,和一些其餘的進程好比:插件進程、GPU進程、tab頁面(瀏覽器渲染進程內核)。

每種類型的插件對應一個進程,僅當使用該插件時才建立。GPU進程用於控制顯卡硬件加速(3d繪製時很是須要)。每開啓一個tab頁面都會建立一個新的瀏覽器渲染進程,這使得每一個tab頁面互不影響,每一個進程控制着當前tab頁面的渲染,腳本執行和事件處理。多個空白tab會合併爲一個進程。

  • 多線程的瀏覽器內核

每個tab頁面均可以看做是一個瀏覽器內核,瀏覽器內核是多線程的。

GUI線程:控制界面的顯示
JS引擎線程:腳本的執行
網絡請求線程
事件觸發線程
定時器控制線程
複製代碼
  • JS是單線程的

咱們平時所說的js單線程是指的是js引擎線程。Js引擎執行Js時只分了一個線程給他執行,也就是咱們的js引擎線程。

爲何js執行要單線程,若是多線程不是能夠執行得快一點嗎?

這個要回到Js歷史了,布蘭登·艾奇(Brendan Eich)老哥用10天創造js。當時js用來幹嗎,簡單的瀏覽器交互,驗證,
操做一下dom是吧。那把它設計成那麼複雜幹什麼,並且若是多線程的話,
操做dom會出現麻煩的事情,假設一個線程讀取DOM節點數據的同時,
另外一個線程把那個DOM節點刪了,呵呵。因此js一個線程就夠了,也就是一步一步順序運行下來。
複製代碼
  • 瀏覽器內核拿到內容後,渲染步驟大體能夠分爲如下幾步:

1)HTML文檔解析,構建DOM樹。DOM樹的構建是一個深度遍歷的過程,當前節點的全部子節 點都構建完成之後,纔會去構建當前節點的下一個兄弟節點。

2)將CSS解析成CSSOM樹(CSS Rule Tree)。遇到css樣式如link標籤或者style標籤時開始解析css,構建樣式樹。HTML解析 構建和CSS的解析是相互獨立的並不會形成衝突,所以咱們一般將css樣式放在head中, 讓瀏覽器儘早解析css;

3)當html的解析遇到script標籤會怎樣呢? 答案是中止DOM樹的解析開始下載js。由於js是會阻塞html解析的,是阻塞資源。其緣由在於js可能會改變html現有結構。例若有的節點是用js動態構建的,在這種狀況下就會中止dom樹的構建開始下載解析js。 腳本在文檔的何處插入,就在何處執行。當 HTML 解析器遇到一個 script 標記時,它會暫停構建 DOM,將控制權移交給 JavaScript 引擎;等 JavaScript 引擎運行完畢,瀏覽器會從中斷的地方恢復 DOM 構建。 而所以就會推遲頁面首繪的時間。能夠在首繪不須要js的狀況下用async和defer實現異步加載。這樣js就不會阻塞html的解析了。

4)根據DOM樹和CSSOM樹,來構建Render Tree(渲染樹),注意渲染樹,並不等於DOM樹,由於一些像head或display:none的東西,就沒有必要放在渲染樹中了。

5)有了Render Tree,瀏覽器已經能知道網頁中有哪些節點,各個節點的CSS定義,以及它們的從屬關係,下一步操做就是Layout,顧名思義,就是計算出每一個節點在屏幕中的位置。佈局使用流模型的Layout算法。Layout是一個遞歸的過程,每一個節點都負責本身及其子節點的Layout。Layout結果是相對父節點的座標和尺寸。

6)Layout後,瀏覽器已經知道哪些節點要顯示,每一個節點的CSS屬性是什麼,每一個節點在屏幕中的位置是哪裏,就進入了最後一步painting,按照算出來的規則,經過顯卡,把內容畫到屏幕上。

GET和POST方式的對比?

一、應用場景不一樣,Get 主要用於獲取資源,Post 主要用於提交數據給服務器處理。
二、Get 方式將傳遞的參數經過拼接URL的方式來傳遞,只能接收ASCII碼,中文須要URL編碼,長度限制。Get 方式的路徑能夠保存爲書籤,能夠經過查歷史記錄再次調出。
三、Post 方式將參數放在了請求體中,長度不受限制,傳輸的數據類型不受限制,不能被保存爲書籤。
四、get在瀏覽器刷新時候是無害的,可是post請求會從新提交。
五、get方式能夠被瀏覽器緩衝,可是post不會。
六、get方式的參數會暴露在URL的後面,因此咱們不能用get方式處理一些帶有銘感信息的請求


----
七、Get 和Post 本質上並無什麼不一樣,他們都是基於TCP鏈接的網絡請求,只是因爲HTTP的規定和客戶端瀏覽器和服務器的規定,纔有了GET和POST的不一樣,他們最大的不一樣在於語義的不一樣,咱們使用的過程最好嚴格遵循語義,不要隨便混用。

八、大多數框架都是儘可能在一個tcp包裏面把HTTP請求發出去的,可是也存在一些特殊狀況:對於get請求,瀏覽器會發送一次TCP數據包,也就是header和data會一次性發送,而Post請求會發送兩次數據包,第一次發送header,返回100Continue。第二次發送數據過去。(這一點其實並不重要,感興趣能夠了解一下)
複製代碼

正在努力趕稿中~~

相關文章
相關標籤/搜索