什么是URL

????????統(tǒng)一資源定位符是對可以從互聯(lián)網(wǎng)上得到的資源的位置和訪問方法的一種簡潔的表示，是互聯(lián)網(wǎng)上標(biāo)準(zhǔn)資源的地址。互聯(lián)網(wǎng)上的每個文件都有一個唯一的URL，它包含的信息指出文件的位置以及瀏覽器應(yīng)該怎么處理它。

結(jié)構(gòu)

????????基本URL包含模式（或稱協(xié)議）、服務(wù)器名稱（或IP地址）、路徑和文件名，如“協(xié)議://授權(quán)/路徑?查詢”。完整的、帶有授權(quán)部分的普通統(tǒng)一資源標(biāo)志符語法看上去如下：協(xié)議://用戶名:密碼@子域名.域名.頂級域名:端口號/目錄/文件名.文件后綴?參數(shù)=值#標(biāo)志

第一部分

????????模式/協(xié)議（scheme）：它告訴瀏覽器如何處理將要打開的文件。最常用的模式是超文本傳輸協(xié)議（Hypertext Transfer Protocol，縮寫為HTTP），這個協(xié)議可以用來訪問網(wǎng)絡(luò)

常見的協(xié)議:

• http——超文本傳輸協(xié)議
• https——用安全套接字層傳送的超文本傳輸協(xié)議
• ftp——文件傳輸協(xié)議
• file——當(dāng)?shù)仉娔X或網(wǎng)上分享的文件

第二部分

????????文件所在的服務(wù)器的名稱或IP地址，后面是到達(dá)這個文件的路徑和文件本身的名稱。服務(wù)器的名稱或IP地址后面有時還跟一個冒號和一個端口號。它也可以包含接觸服務(wù)器必須的用戶名稱和密碼。路徑部分包含等級結(jié)構(gòu)的路徑定義，一般來說不同部分之間以斜線（/）分隔。詢問部分一般用來傳送對服務(wù)器上的數(shù)據(jù)庫進(jìn)行動態(tài)詢問時所需要的參數(shù)。

從輸入URL到頁面加載總體來說分為以下幾個過程

• DNS解析
• TCP連接
• 發(fā)送HTTP請求
• 服務(wù)器處理請求并返回HTTP報文
• 瀏覽器解析渲染頁面
• 連接結(jié)束

1. DNS解析

????????人們習(xí)慣記憶域名，但機(jī)器間互相只認(rèn)IP地址，域名與IP地址之間是多對一的關(guān)系，一個ip地址不一定只對應(yīng)一個域名，且一個域名只可以對應(yīng)一個ip地址，它們之間的轉(zhuǎn)換工作稱為域名解析，域名解析需要由專門的域名解析服務(wù)器來完成，整個過程是自動進(jìn)行的。
????????DNS存在著多級緩存，從離瀏覽器的距離排序的話，有以下幾種: 瀏覽器緩存，系統(tǒng)緩存，根域名服務(wù)器緩存，頂級域名服務(wù)器緩存，主域名服務(wù)器緩存。
????????解析過程,例如(www.baidu.com)，首先從瀏覽器查找DNS緩存->系統(tǒng)緩存LINUX(/etc/hosts)WINDOWS(C:\Windows\System32\drivers\etc\hosts)->根域名服務(wù)器緩存(.)->頂級域名服務(wù)器緩存(.com)->主域名服務(wù)器緩存(baidu.com)

DNS負(fù)載均衡

????????DNS負(fù)載均衡技術(shù)的實(shí)現(xiàn)原理是在DNS服務(wù)器中為同一個主機(jī)名配置多個IP地址，在應(yīng)答DNS查詢時，DNS服務(wù)器對每個查詢將以DNS文件中主機(jī)記錄的IP地址按順序返回不同的解析結(jié)果，將客戶端的訪問引導(dǎo)到不同的機(jī)器上去，使得不同的客戶端訪問不同的服務(wù)器，從而達(dá)到負(fù)載均衡的目的。
????????DNS負(fù)載均衡是一種簡單而有效的方法，但是它不能區(qū)分服務(wù)器的差異，也不能反映服務(wù)器的當(dāng)前運(yùn)行狀態(tài)。

負(fù)載均衡

????????負(fù)載均衡（Load Balance）是分布式系統(tǒng)架構(gòu)設(shè)計(jì)中必須考慮的因素之一，它通常是指，將請求/數(shù)據(jù)【均勻】分?jǐn)偟蕉鄠€操作單元上執(zhí)行，負(fù)載均衡的關(guān)鍵在于【均勻】。常見互聯(lián)網(wǎng)分布式架構(gòu)如上，分為客戶端層、反向代理nginx層、站點(diǎn)層、服務(wù)層、數(shù)據(jù)層。
一分鐘了解負(fù)載均衡的一切

2. TCP連接

????????TCP協(xié)議:Transmission Control Protocol/Internet Protocol的簡寫，中譯名為傳輸控制協(xié)議/因特網(wǎng)互聯(lián)協(xié)議，又名網(wǎng)絡(luò)通訊協(xié)議，是Internet最基本的協(xié)議、Internet國際互聯(lián)網(wǎng)絡(luò)的基礎(chǔ)，由網(wǎng)絡(luò)層的IP協(xié)議和傳輸層的TCP協(xié)議組成。TCP/IP 定義了電子設(shè)備如何連入因特網(wǎng)，以及數(shù)據(jù)如何在它們之間傳輸?shù)臉?biāo)準(zhǔn)。協(xié)議采用了4層的層級結(jié)構(gòu)，每一層都呼叫它的下一層所提供的協(xié)議來完成自己的需求。通俗而言：TCP負(fù)責(zé)發(fā)現(xiàn)傳輸?shù)膯栴}，一有問題就發(fā)出信號，要求重新傳輸，直到所有數(shù)據(jù)安全正確地傳輸?shù)侥康牡?。而IP是給因特網(wǎng)的每一臺聯(lián)網(wǎng)設(shè)備規(guī)定一個地址。

TCP鏈接的三次握手:

????????第一次握手：主機(jī)A發(fā)送位碼為syn＝1,隨機(jī)產(chǎn)生seq number=1234567的數(shù)據(jù)包到服務(wù)器，主機(jī)B由SYN=1知道，A要求建立聯(lián)機(jī)；
????????第二次握手：主機(jī)B收到請求后要確認(rèn)聯(lián)機(jī)信息，向A發(fā)送ack number=(主機(jī)A的seq+1),syn=1,ack=1,隨機(jī)產(chǎn)生seq=7654321的包
????????第三次握手：主機(jī)A收到后檢查ack number是否正確，即第一次發(fā)送的seq number+1,以及位碼ack是否為1，若正確，主機(jī)A會再發(fā)送ack number=(主機(jī)B的seq+1),ack=1，主機(jī)B收到后確認(rèn)seq值與ack=1則連接建立成功。
????????完成三次握手，主機(jī)A與主機(jī)B開始傳送數(shù)據(jù)。

HTTPS協(xié)議

????????HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。 它是一個URI scheme（抽象標(biāo)識符體系），句法類同http:體系。用于安全的HTTP數(shù)據(jù)傳輸。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默認(rèn)端口及一個加密/身份驗(yàn)證層（在HTTP與TCP之間）。現(xiàn)在它被廣泛用于萬維網(wǎng)上安全敏感的通訊，例如交易支付方面。

3598916885-5608f6c220945_articlex.png

HTTPS傳輸過程

????????HTTPS在傳輸數(shù)據(jù)之前需要客戶端與服務(wù)器進(jìn)行一個握手(TLS/SSL握手)，在握手過程中將確立雙方加密傳輸數(shù)據(jù)的密碼信息。TLS/SSL使用了非對稱加密，對稱加密以及hash等。HTTPS相比于HTTP，雖然提供了安全保證，但是必會帶來一些時間上的損耗，如握手和加密等過程，是否使用HTTPS需要根據(jù)具體情況在安全和性能方面做出權(quán)衡。

HTTP請求

• HTTP是無連接：無連接的含義是限制每次連接只處理一個請求。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間。
• HTTP是媒體獨(dú)立的：這意味著，只要客戶端和服務(wù)器知道如何處理的數(shù)據(jù)內(nèi)容，任何類型的數(shù)據(jù)都可以通過HTTP發(fā)送。客戶端以及服務(wù)器指定使用適合的MIME-type內(nèi)容類型。
• HTTP是無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時它的應(yīng)答就較快。

一個HTTP請求到服務(wù)器的請求消息包括以下格式：請求行（request line）、請求頭部（header）、請求數(shù)據(jù)三個部分組成

請求格式.png

1.請求行

格式如下:
Method Request-URL HTTP-Version CRLF

GET index.html HTTP/1.1

常用的方法有: GET, POST, PUT, DELETE, OPTIONS, HEAD。

在客戶機(jī)和服務(wù)器之間進(jìn)行請求-響應(yīng)時，兩種最常被用到的方法是：GET 和 POST。
GET - 根據(jù)HTTP規(guī)范，GET用于信息獲取。
POST - 根據(jù)HTTP規(guī)范，POST表示可能修改變服務(wù)器上的資源的請求。
淺談HTTP中Get與Post的區(qū)別

2.請求報頭

請求頭部為請求報文添加了一些附加信息，由“名/值”對組成，每行一對，名和值之間使用冒號分隔

常見請求頭如下：

請求和響應(yīng)報頭.png

????????從圖中可以看出，請求報頭中使用了Accept, Accept-Encoding, Accept-Language, Cache-Control, Connection, Cookie等字段。Accept用于指定客戶端用于接受哪些類型的信息，Accept-Encoding與Accept類似，它用于指定接受的編碼方式。Connection設(shè)置為Keep-alive用于告訴客戶端本次HTTP請求結(jié)束之后并不需要關(guān)閉TCP連接，這樣可以使下次HTTP請求使用相同的TCP通道，節(jié)省TCP連接建立的時間。

3.請求正文

????????當(dāng)使用POST, PUT等方法時，通常需要客戶端向服務(wù)器傳遞數(shù)據(jù)。這些數(shù)據(jù)就儲存在請求正文中。在請求包頭中有一些與請求正文相關(guān)的信息，例如: 現(xiàn)在的Web應(yīng)用通常采用Rest架構(gòu)，請求的數(shù)據(jù)格式一般為json。這時就需要設(shè)置Content-Type: application/json。

服務(wù)器處理請求并返回HTTP報文

????????這部分對應(yīng)的就是后端工程師眼中的HTTP。后端從在固定的端口接收到TCP報文開始，這一部分對應(yīng)于編程語言中的socket。它會對TCP連接進(jìn)行處理，對HTTP協(xié)議進(jìn)行解析，并按照報文格式進(jìn)一步封裝成HTTP Request對象，供上層使用。

HTTP響應(yīng)報文也是由三部分組成: 狀態(tài)碼, 響應(yīng)報頭和響應(yīng)報文。

響應(yīng)格式.jpg

1.狀態(tài)碼

狀態(tài)碼是由3位數(shù)組成，第一個數(shù)字定義了響應(yīng)的類別，且有五種可能取值:

1xx：指示信息–表示請求已接收，繼續(xù)處理。
2xx：成功–表示請求已被成功接收、理解、接受。
3xx：重定向–要完成請求必須進(jìn)行更進(jìn)一步的操作。
4xx：客戶端錯誤–請求有語法錯誤或請求無法實(shí)現(xiàn)。
5xx：服務(wù)器端錯誤–服務(wù)器未能實(shí)現(xiàn)合法的請求。

平時遇到比較常見的狀態(tài)碼有:
200（成功） 服務(wù)器已成功處理了請求
204（無內(nèi)容） 服務(wù)器成功處理了請求，但沒有返回任何內(nèi)容。
301（永久移動） 請求的網(wǎng)頁已永久移動到新位置
302（臨時移動） 服務(wù)器目前從不同位置的網(wǎng)頁響應(yīng)請求，但請求者應(yīng)繼續(xù)使用原有位置來進(jìn)行以后的請求。
304(未修改） 自從上次請求后，請求的網(wǎng)頁未修改過
400（錯誤請求） 服務(wù)器不理解請求的語法
401（未授權(quán)） 請求要求身份驗(yàn)證
403（禁止） 服務(wù)器拒絕請求
404（未找到） 服務(wù)器找不到請求的網(wǎng)頁
422（語法錯誤） 請求格式正確，但是由于含有語義錯誤，無法響應(yīng)
500（服務(wù)器內(nèi)部錯誤） 服務(wù)器遇到錯誤，無法完成請求。

2.響應(yīng)報頭

與請求頭部類似，為響應(yīng)報文添加了一些附加信息

常見響應(yīng)頭部如下。

3.響應(yīng)報文

服務(wù)器返回給瀏覽器的文本信息，通常HTML, CSS, JS, 圖片等文件就放在這一部分。

瀏覽器解析渲染頁面

????????瀏覽器在收到HTML,CSS,JS文件后，它是如何把頁面呈現(xiàn)到屏幕上的？下圖對應(yīng)的就是WebKit渲染的過程。

瀏覽器繪制過程.png

????????瀏覽器是一個邊解析邊渲染的過程。首先瀏覽器解析HTML文件構(gòu)建DOM樹，然后解析CSS文件構(gòu)建渲染樹，等到渲染樹構(gòu)建完成后，瀏覽器開始布局渲染樹并將其繪制到屏幕上。這個過程比較復(fù)雜，涉及到兩個概念: reflow(回流)和repaint(重繪)。DOM節(jié)點(diǎn)中的各個元素都是以盒模型的形式存在，這些都需要瀏覽器去計(jì)算其位置和大小等，這個過程稱為relow;當(dāng)盒模型的位置,大小以及其他屬性，如顏色,字體,等確定下來之后，瀏覽器便開始繪制內(nèi)容，這個過程稱為repaint。頁面在首次加載時必然會經(jīng)歷reflow和repaint。reflow和repaint過程是非常消耗性能的，尤其是在移動設(shè)備上，它會破壞用戶體驗(yàn)，有時會造成頁面卡頓。所以我們應(yīng)該盡可能少的減少reflow和repaint。

JS解析機(jī)制.png

????????JS的解析是由瀏覽器中的JS解析引擎完成的。JS是單線程運(yùn)行，也就是說，在同一個時間內(nèi)只能做一件事，所有的任務(wù)都需要排隊(duì)，前一個任務(wù)結(jié)束，后一個任務(wù)才能開始。但是又存在某些任務(wù)比較耗時，如IO讀寫等，所以需要一種機(jī)制可以先執(zhí)行排在后面的任務(wù)，這就是：同步任務(wù)(synchronous)和異步任務(wù)(asynchronous)。JS的執(zhí)行機(jī)制就可以看做是一個主線程加上一個任務(wù)隊(duì)列(task queue)。同步任務(wù)就是放在主線程上執(zhí)行的任務(wù)，異步任務(wù)是放在任務(wù)隊(duì)列中的任務(wù)。所有的同步任務(wù)在主線程上執(zhí)行，形成一個執(zhí)行棧;異步任務(wù)有了運(yùn)行結(jié)果就會在任務(wù)隊(duì)列中放置一個事件；腳本運(yùn)行時先依次運(yùn)行執(zhí)行棧，然后會從任務(wù)隊(duì)列里提取事件，運(yùn)行任務(wù)隊(duì)列中的任務(wù)，這個過程是不斷重復(fù)的，所以又叫做事件循環(huán)(Event loop)。

????????瀏覽器在解析過程中，如果遇到請求外部資源時，如圖像,iconfont,JS等。瀏覽器將重復(fù)1-6過程下載該資源。請求過程是異步的，并不會影響HTML文檔進(jìn)行加載，但是當(dāng)文檔加載過程中遇到JS文件，HTML文檔會掛起渲染過程，不僅要等到文檔中JS文件加載完畢還要等待解析執(zhí)行完畢，才會繼續(xù)HTML的渲染過程。原因是因?yàn)镴S有可能修改DOM結(jié)構(gòu)，這就意味著JS執(zhí)行完成前，后續(xù)所有資源的下載是沒有必要的，這就是JS阻塞后續(xù)資源下載的根本原因。CSS文件的加載不影響JS文件的加載，但是卻影響JS文件的執(zhí)行。JS代碼執(zhí)行前瀏覽器必須保證CSS文件已經(jīng)下載并加載完畢。

Web性能優(yōu)化

????????Web性能黃金準(zhǔn)則：只有10%_{20%的最終用戶響應(yīng)時間花在了下載html文檔上，其余的80%}90%時間花在了下載頁面組件上。
????????web性能對于用戶體驗(yàn)有及其重要的影響，根據(jù)著名的2-5-8原則：

• 當(dāng)用戶在2秒以內(nèi)得到響應(yīng)，會感覺系統(tǒng)的響應(yīng)非?？?；
• 當(dāng)用戶在2-5秒之內(nèi)得到響應(yīng)，會感覺系統(tǒng)的響應(yīng)速度還可以；
• 當(dāng)用戶在5-8秒之內(nèi)得到響應(yīng)，會感覺系統(tǒng)的響應(yīng)非常慢，但還可以接受；
• 當(dāng)用戶在8秒之后都沒有得到響應(yīng)，會感覺系統(tǒng)糟透了，甚至系統(tǒng)已經(jīng)掛掉；要么打開競爭對手的網(wǎng)站，要么重新發(fā)起第二次請求。

????????凡事都需要研究，通過科學(xué)的研究我們就可以找到事物的發(fā)展規(guī)律。這里要感謝雅虎的工程師總結(jié)的14條前端優(yōu)化法則，使得我們可以站在巨人的肩膀上。《高性能網(wǎng)站建設(shè)》這本書中的14條優(yōu)化原則，總結(jié)起來主要是以下個方面的優(yōu)化：

• 減少HTTP請求
• 頁面內(nèi)部優(yōu)化
• 啟用緩存
• 減少下載量
• 網(wǎng)絡(luò)連接上的優(yōu)化

Web性能優(yōu)化：What? Why? How?