web／服務器知識

一 PV 推到出 QPS

你想建設一個能承受500萬PV/天天的網站嗎？ 500萬PV是什麼概念？服務器每秒要處理多少個請求才能應對？若是計算呢？?

PV是什麼：PV是page view的簡寫。PV是指頁面的訪問次數，每打開或刷新一次頁面，就算作一個pv。 
計算模型： 
每臺服務器每秒處理請求的數量=((80%*總PV量)/(24小時*60分*60秒*40%)) / 服務器數量 。
其中關鍵的參數是80%、40%。表示一天中有80%的請求發生在一天的40%的時間內。24小時的40%是9.6小時，有80%的請求發生一天的9.6個小時當中（很適合互聯網的應用，白天請求多，晚上請求少）。 
簡單計算的結果：
((80%*500萬)/(24小時*60分*60秒*40%))/1 = 115.7個請求/秒 

((80%*100萬)/(24小時*60分*60秒*40%))/1 = 23.1個請求/秒 

(2)初步結論： 

如今咱們在作壓力測試時，就有了標準，若是你的服務器一秒能處理115.7個請求，就能夠承受500萬PV/天天。若是你的服務器一秒能處理23.1個請求，就能夠承受100萬PV/天天。
留足餘量：
以上請求數量是均勻的分佈在白天的9.6個小時中，但實際狀況並不會這麼均勻的分佈，會有高峯有低谷。爲了應對高峯時段，應該留一些餘地，最少也要x2倍，x3倍也不爲過。
115.7個請求/秒?*2倍=231.4個請求/秒
115.7個請求/秒?*3倍=347.1個請求/秒
23.1個請求/秒?*2倍=46.2個請求/秒
23.1個請求/秒?*3倍=69.3個請求/秒
(3)最終結論：
若是你的服務器一秒能處理231.4--347.1個請求/秒，就能夠應對平均500萬PV/天天。
若是你的服務器一秒能處理46.2--69.3個請求，就能夠應對平均100萬PV/天天。

這裏所謂的每秒N個請求，就是QPS。

(4)實際經驗：

一、根據實際經驗，採用兩臺常規配置的機架式服務器，配置是很常見的配置，例如一個4核CPU+4G內存+服務器SAS硬盤。
二、我的武斷的認爲在服務器CPU領域Intel的CPU要優於AMD的CPU，有反對的就反對吧，我都說我武斷了（請看CPU性能比較），不要太相信AMD的廣告，比較CPU性能簡單辦法就是比價格，不要比頻率與核心數，價格相差很少的性能也相差很少。
三、硬盤的性能很重要，尤爲是數據庫服務器。通常的服務器都配1.5萬轉的SAS硬盤，高級一點的能夠配SSD固態硬盤，性能會更好。最最最最重要的指標是「隨機讀寫性能」而不是「順序讀寫性能」。（本例仍是配置最多見的1.5萬轉的SAS硬盤吧）
四、一臺服務器跑Tomcat運行j2ee程序,一臺服務器跑MySql數據庫,程序寫的中等水平(這個真的很差量化)，是論壇類型的應用(總有回帖,不太容易作緩存,也沒法靜態化)。
五、以上軟硬件狀況下，是能夠承受100萬PV/天天的。(已留有餘量應對忽然的訪問高峯)
注意機房的網絡帶寬：
有人說以上條件我都知足了，但實際性能仍是達不到目標。這時請注意你對外的網絡的帶寬，在國內服務器便宜但帶寬很貴，極可能你在機房是與你們共享一條100M的光纖，實際每一個人可分到2M左右帶寬。再好一點5M,再好一點雙線機房10M獨享，這已經很貴了（北京價格）。
一天總流量：每一個頁面20k字節*100萬個頁面/1024=19531M字節=19G字節，
19531M/9.6小時=2034M/小時=578K字節/s。若是請求是均勻分佈的，須要5M（640K字節）帶寬（5Mb=640KB 注意大小寫，b是位，B是字節，差了8倍），但全部請求不多是均勻分佈的，當有高峯時5M帶寬必定不夠，X2倍就是10M帶寬。10M帶寬基本能夠知足要求。以上是假設每一個頁面20k字節，基本不包含圖片，要是包含圖片就更大了，10M帶寬也不能知足要求了

 

Throughput（吞吐量）：按照常規理解網絡吞吐量表示在單位時間內經過網卡數據量之和，其中即包括本機網卡發送出去的數據量也包括本機網卡接收到的數據量。 一個100Mb(位)的雙工網卡，最大發送數據的速度是12.5M字節/s, 最大接收數據的速度是12.5M字節/s, 能夠同時收發數據。 
併發用戶數                             是同時執行操做的用戶(線程數) 
響應時間                                從請求發出到收到響應花費的時間
QPS(Queries Per Second)        每秒處理的查詢數（若是是數據庫，就至關於讀取）
TPS(Transactions Per Second) 每秒處理的事務數(若是是數據庫，就至關於寫入、修改)
IOPS                                     每秒磁盤進行的I/O操做次數

 

二  ip地址分類和網絡區分

IP地址分類/IP地址10開頭和172開頭和192開頭的區別/判斷是否同一網段

簡單來講在公司或企業內部看到的就基本都是內網IP，ABC三類IP地址裏的常見IP段。

每一個IP地址都包含兩部分，即網絡號和主機號。 
InterNIC將IP地址分爲五類:
A類保留給ZF或大型企業，
B類分配給中等規模的公司，
C類分配給小公司或我的，
D類用於組播，
E類用於實驗，
注：各種可容納的地址數目不一樣。 

A、B、C三類IP地址的特徵：當將IP地址寫成二進制形式時，
A類地址的第一位老是O，如，10.0.0.1==00001010-00000000-00000000-00000001
==》1.0.0.0-127.255.255.255，默認子網掩碼爲255.0.0.0，最多可容納16777215臺計算機
B類地址的前兩位老是10，如，172.16.0.1==10101100-00010000-00000000-00000001
==》128.0.0.0-191.255.255.255，默認子網掩碼爲255.255.0.0，最多可容納65535臺計算機
C類地址的前三位老是110。如，192.168.0.1==11000000-10101000-00000000-00000001
==》192.0.0.0-223.255.255.255，默認子網掩碼是255.255.255.0，最多可容納254臺計算機

IP地址中保留地址：主機部分全爲0的IP地址保留用於網絡地址，主機部分全爲1的IP地址保留爲廣播地址，224--255部分保留做爲組播和實 驗目的。 同時注意IP地址分配時不能使用最末位爲0和255的地址，由於這是廣播地址，普通計算機上不能使用，但可用於網關和路由器上。

專用IP地址： 就是咱們在3類地址中常見到內網的IP段。

10.0.0.0--10.255.255.255
172.16.0.0--172.31.255.255 
192.168.0.0--192.168.255.255 
 

內網的計算機以NAT（網絡地址轉換）協議，經過一個公共的網關訪問Internet。內網的計算機可向Internet上的其餘計算機發送鏈接請求，但Internet上其餘的計算機沒法向內網的計算機發送鏈接請求。

主機地址種類

概述

　　經過IP地址的引導位(最高位)來區分不一樣類別的IP地址： 

　　注：n爲網絡編號位，h爲主機編號位 

A類地址

　　A類地址：0nnnnnnn.hhhhhhhh.hhhhhhhh.hhhhhhhh 

　　A類地址具備7位網絡編號，所以可定義126個A類網絡{2^7－2(網絡編號不能是全0或全1 注1)-1(127爲環回地址 注2)}每一個網絡能夠擁有的主機數爲16777214{2^24-2(主機位不能是全0或全1)}

　　十進制表示範圍：1.0.0.1-126.255.255.254,任何一個0到127間的網絡地址均是一個A類地址。 

B類地址

　　B類地址：10nnnnnn.nnnnnnnn.hhhhhhhh.hhhhhhhh 

　　B類地址具備14位網絡編號，所以可定義16382個B類網絡{2^14-2} 

　　每一個網絡能夠擁有的主機數爲65534{2^16-2} 

　　十進制表示範圍：129.0.0.1-191.255.255.254,任何一個128到191間的網絡地址是一個B類地址。 

C類地址

　　C類地址：110nnnnn.nnnnnnnn.nnnnnnnn.hhhhhhhh 

　　C類地址具備21位網絡編號，所以可定義2097152個C類地址{2^21-2} 

　　每一個網絡能夠擁有的主機數爲254{2^8-2} 

　　十進制表示範圍：192.0.0.1-223.255.255.254,任何一個192到223間的網絡地址是一個C類地址。 

D類地址

　　D類地址：1110xxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx 

　　D類地址用於組播，前面4位1110引導，後面28位爲組播地址ID。 

　　十進制表示範圍：224.0.0.0-239.255.255.255 

E類地址

　　E類地址：老是以1111四位引導 

　　E類地址用於研究用 

　　十進制表示範圍：240- 

　　IP地址由InterNIC(因特網信息中心)統一分配，以保證IP地址的惟一性，但有一類IP地址是不用申請可直接用於企業內部網的，這就是 Private Address，Private Address不會被INTERNET上的任何路由器轉發，欲接入INTERNET必需要經過NAT/PAT轉換，以公有IP的形式接入。

　　這些私爲地址爲： 

　　10.0.0.0-10.255.255.255（一個A類地址） 

　　172.16.0.0－172.31.255.255（16個B類地址） 

　　192.168.0.0－192.168.255.255（256個C類地址） 

　　任何一個第一個八位組在224到239間的網絡地址是一個組播地址 

　　任何一個專用I P網絡都可以使用包括: 

　　1個A類地址( 10.0.0.0 )、 

　　16個B類地址(從172.16.0.0到172.31.0.0 ) 

　　256個C類地址(從192.168.0.0到192.168.255.0 ) 

 

 

 

三 觀察者模式對於消息的推和拉的處理

觀察者模式，指的是定義一種對象間的一對多的關係，當一個對象的狀態發生變化的時候，全部依賴於它的對象都將獲得通知並更新本身。

「推」的方式是指，Subject維護一份觀察者的列表，每當有更新發生，Subject會把更新消息主動推送到各個Observer去。

「拉」的方式是指，各個Observer維護各自所關心的Subject列表，自行決定在合適的時間去Subject獲取相應的更新數據。

 

「推」的好處包括：

一、高效。若是沒有更新發生，不會有任何更新消息推送的動做，即每次消息推送都發生在確確實實的更新事件以後，都是有意義的。

二、實時。事件發生後的第一時間便可觸發通知操做。

三、能夠由Subject確立通知的時間，能夠避開一些繁忙時間。

四、能夠表達出不一樣事件發生的前後順序。

 

「拉」的好處包括：

一、若是觀察者衆多，Subject來維護訂閱者的列表，可能困難，或者臃腫，把訂閱關係解脫到Observer去完成。

二、Observer能夠不理會它不關心的變動事件，只須要去獲取本身感興趣的事件便可。

三、Observer能夠自行決定獲取更新事件的時間。

四、拉的形式可讓Subject更好地控制各個Observer每次查詢更新的訪問權限。

 

----------------------------------------------------------------------------------------------------------------------------------

補充：

事實上「推」和「拉」能夠比較的內容太多了，好比：

客戶端一般是不穩定的，服務端是穩定的，若是消息由客戶端主動發起去獲取，它很容易找到服務端的地址，能夠比較容易地作到權限控制（集中在服務端一處），服務端也能夠比較容易地跟蹤客戶端的位置和狀態，反之則不行；

互聯網頁面的訪問就是一個最好的「拉」的模式的例子；

一般咱們但願把壓力分散到各個客戶端上去，服務端只作最核心的事情，只提供內容，無論理分發列表；

……

還有一個idea是關於「推」和「拉」結合的形式，例如，服務端只負責通知某一些數據已經準備好，至因而否須要獲取和何時客戶端來獲取這些數據，徹底由客戶端自行肯定。

 

 

 

四 虛擬內存（linux的swap）

 1 技術介紹

虛擬 內存是 計算機系統 內存管理的一種技術。它使得 應用程序認爲它擁有連續的可用的 內存（一個連續完整的 地址空間），而實際上，它一般是被分隔成多個 物理內存碎片，還有部分暫時存儲在外部 磁盤存儲器上，在須要時進行 數據交換。目前，大多數操做系統都使用了虛擬內存，如Windows家族的「虛擬內存」；Linux的「交換空間」等。

Windows 8/8.1 操做系統如出現開機時卡在Windows徽標頁面，沒法進入系統，必須強制關機再重啓才能打開時，可適當調整虛擬內存設置解決。

 

虛擬內存別稱 虛擬存儲器（Virtual Memory）。 電腦中所運行的
程序均需經由 內存執行，若執行的程序佔用內存很大或不少，則會致使內存消耗殆盡。爲解決該問題， Windows中運用了虛擬 內存[2]   技術，即勻出一部分硬盤空間來充當內存使用。當內存耗盡時，電腦就會自動調用硬盤來充當內存，以緩解內存的緊張。若計算機運行程序或操做所需的 隨機存儲器( RAM)不足時，則 Windows 會用 虛擬存儲器進行補償。它將計算機的 RAM和 硬盤上的臨時空間組合。當RAM運行速率緩慢時，它便將數據從RAM移動到稱爲「 分頁文件」的空間中。將數據移入 分頁文件可釋放RAM，以便完成工做。 通常而言，計算機的RAM 容量越大，程序運行得越快。若計算機的速率因爲RAM可用空間匱乏而減緩，則可嘗試經過增長虛擬內存來進行補償。可是，計算機從RAM讀取數據的速率要比從硬盤讀取數據的速率快，於是擴增RAM 容量（可加 內存條）是最佳選擇。

虛擬內存是Windows 爲做爲內存使用的一部分硬盤空間。虛擬內存在硬盤上其實就是爲一個碩大無比的文件，文件名是 PageFile.Sys，一般狀態下是看不到的。必須關閉資源管理器對系統文件的保護功能才能看到這個文件。虛擬內存有時候也被稱爲是「頁面文件」就是從這個文件的文件名中來的。

[2]   內存在計算機中的做用很大，電腦中全部運行的程序都須要通過內存來執行，若是執行的程序很大或不少，就會致使內存消耗殆盡。爲了解決這個問題，WINDOWS運用了虛擬內存技術，即拿出一部分硬盤空間來充當內存使用，這部分空間即稱爲 虛擬內存，虛擬內存在硬盤上的存在形式就是 PAGEFILE.SYS這個頁面文件。

 

2 工做原理

虛擬存儲器是由硬件和操做系統自動實現存儲信息調度和管理的。它的工做過程包括6個步驟：

① 中央處理器訪問主存的邏輯地址分解成組號a和組內地址b，並對組號a進行地址變換，即將邏輯組號a做爲索引，查地址變換表，以肯定該組信息是否存放在主存內。

②如該組號已在 主存內，則轉而執行④；若是該組號不在主存內，則檢查主存中是否有空閒區，若是沒有，便將某個暫時不用的組調出送往輔存，以便將這組信息調入主存。

③從輔存讀出所要的組，並送到主存空閒區，而後將那個空閒的物理組號a和邏輯組號a登陸在地址變換表中。

④從地址變換表讀出與邏輯組號a對應的物理組號a。

⑤從物理組號a和組內字節地址b獲得物理地址。

⑥根據物理地址從主存中存取必要的信息。

調度方式有分頁式、段式、段頁式3種。頁式調度是將邏輯和物理地址空間都分紅固定大小的頁。主存按頁順序編號，而每一個獨立編址的程序空間有本身的頁號順序，經過調度輔存中程序的各頁能夠離散裝入主存中不一樣的頁面位置，並可據表一一對應檢索。頁式調度的優勢是頁內零頭小，頁表對程序員來講是透明的，地址變換快，調入操做簡單；缺點是各頁不是程序的獨立模塊，不便於實現程序和數據的保護。段式調度是按程序的邏輯結構劃分地址空間，段的長度是隨意的，而且容許伸長，它的優勢是消除了內存零頭，易於實現存儲保護，便於程序動態裝配；缺點是調入操做複雜。將這兩種方法結合起來便構成段頁式調度。在段頁式調度中把物理空間分紅頁，程序按模塊分段，每一個段再分紅與物理空間頁一樣小的頁面。段頁式調度綜合了段式和頁式的優勢。其缺點是增長了硬件成本，軟件也較複雜。大型通用計算機系統多數採用段頁式調度。

 

3 虛實地址

實地址與虛地址

[3]   用戶編制程序時使用的地址稱爲虛地址或邏輯地址，其對應的存儲空間稱爲虛存空間或邏輯地址空間；而計算機物理內存的訪問地址則稱爲實地址或物理地址，其對應的存儲空間稱爲物理存儲空間或主存空間。程序進行虛地址到實地址轉換的過程稱爲程序的再定位。

虛存的訪問過程

虛存空間的用戶程序按照虛地址編程並存放在輔存中。程序運行時，由地址變換機構依據當時分配給該程序的實地址空間把程序的一部分調入實存。每次訪存時，首先判斷該虛地址所對應的部分是否在實存中：若是是，則進行地址轉換並用實地址訪問主存；不然，按照某種算法將輔存中的部分程序調度進內存，再按一樣的方法訪問主存。因而可知，每一個程序的虛地址空間能夠遠大於實地址空間，也能夠遠小於實地址空間。前一種狀況以提升存儲容量爲目的，後一種狀況則以地址變換爲目的。後者一般出如今多用戶或多任務系統中：實存空間較大，而單個任務並不須要很大的 地址空間，較小的虛存空間則能夠縮短 指令中 地址字段的長度。

 

 

五 http和https

1 引言

http: 超文本傳輸協議http協議被用於在web瀏覽器和網站服務器之間傳遞信息，http協議以明文方式發送內容，不提供任何方式的數據加密，若是攻擊者截取了web瀏覽器和網站服務器之間的 傳輸報文，就能夠讀懂其中的信息。所以http協議不適合傳輸一些銀行卡號，密碼等敏感信息

https: https是以安全爲目標的http通道，簡單來講就是http的安全版，即http下加入ssl(secure sockets layer)層，https的安全基礎是ssl。https協議的主要做用能夠分爲兩種: 一種是創建一個信息安全通道，來保證數據傳輸的安全; 另外一種就是確認網站的真實性.

 

2 http和https的區別

1 https協議須要到ca申請證書，通常免費證書較少，所以須要必定費用

2 http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議

3 http和https使用的是徹底不一樣的鏈接方式，用的端口不同，前者是80，後者是443

4 http的鏈接很簡單，是無狀態的; https協議是由ssl + http協議構建的可進行加密傳輸，身份認證的網絡協議，比http協議安全

 

3 通訊過程

客戶端在使用HTTPS方式與Web服務器通訊時有如下幾個步驟，如圖所示。

　　（1）客戶使用https的URL訪問Web服務器，要求與Web服務器創建SSL鏈接。

　　（2）Web服務器收到客戶端請求後，會將網站的證書信息（證書中包含公鑰）傳送一份給客戶端。

　　（3）客戶端的瀏覽器與Web服務器開始協商SSL鏈接的安全等級，也就是信息加密的等級。

　　（4）客戶端的瀏覽器根據雙方贊成的安全等級，創建會話密鑰，而後利用網站的公鑰將會話密鑰加密，並傳送給網站。

　　（5）Web服務器利用本身的私鑰解密出會話密鑰。

　　（6）Web服務器利用會話密鑰加密與客戶端之間的通訊。

 

4 https的優缺點

優勢:

(1) 使用HTTPS協議可認證用戶和服務器，確保數據發送到正確的客戶機和服務器

(2) HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全，可防止數據在傳輸過程當中不被竊取、改變，確保數據的完整性。它是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增長了中間人攻擊的成本。

缺點:

(1) https協議握手階段比較費時，會使頁面的加載時間延長近50%。

(2) https鏈接緩存不如http高效，會增長數據開銷和功耗，甚至已有的安全措施也會所以受到影響

(3) ssl證書須要錢，功能越強大費用越高，我的網站小型網站不必用

(4) 加密範圍比較有限，在黑客攻擊，拒絕服務攻擊，服務器劫持等方面起不到什麼做用。最關鍵的，SSL證書的信用鏈體系並不安全，特別是在某些國家能夠控制CA根證書的狀況下，中間人攻擊同樣可行。

 

 

 

 

六 網絡鏈接的創建過程

當咱們在瀏覽器輸入網址並回車後，一切從這裏開始

1 DNS域名解析

將域名解析成對應的服務器ip地址這項工做，是由DNS服務器完成的

客戶端收到你輸入的域名地址後，它首先去找本地的hosts文件，檢查在該文件中是否有相應的域名，ip對應關係。若是有，則向其IP地址發送請求，若沒有，再去找DNS服務器。通常用戶不多去編輯修改hosts文件

DNS服務器層次結構

瀏覽器客戶端向本地DNS服務器發送一個含有域名www.cnblogs.com的DNS查詢報文。本地DNS服務器把查詢報文轉發到根DNS服務器，根DNS服務器注意到其com後綴，因而向本地DNS服務器返回comDNS服務器的IP地址。本地DNS服務器再次向comDNS服務器發送查詢請求，comDNS服務器注意到其www.cnblogs.com後綴並用負責該域名的權威DNS服務器的IP地址做爲迴應。最後，本地DNS服務器將含有www.cnblogs.com的IP地址的響應報文發送給客戶端。

從客戶端到本地服務器屬於遞歸查詢，而DNS服務器之間的交互屬於迭代查詢。

正常狀況下，本地DNS服務器的緩存中已有comDNS服務器的地址，所以請求根域名服務器這一步不是必需的。

 

 

2 創建TCP鏈接

費了一頓周折終於拿到服務器IP了，下一步天然就是連接到該服務器。對於客戶端與服務器的TCP連接，必然要說的就是『三次握手』。

三次握手

客戶端發送一個帶有SYN標誌的數據包給服務端，服務端收到後，回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息，最後客戶端再回傳一個帶ACK標誌的數據包，表明握手結束，鏈接成功。

上圖也能夠這麼理解：

客戶端：「你好，在家不，有你快遞。」

服務端：「在的，送來就行。」

客戶端：「好嘞。」

 

 

 

3 發送http請求

與服務器創建了鏈接後，就能夠向服務器發起請求了。這裏咱們先看下請求報文的結構（以下圖）：

請求報文

在瀏覽器中查看報文首部（以google瀏覽器爲例）：

請求行包括請求方法、URI、HTTP版本。首部字段傳遞重要信息，包括請求首部字段、通用首部字段和實體首部字段。咱們能夠從報文中看到發出的請求的具體信息。具體每一個首部字段的做用，這裏不作過多闡述。

 

4 服務器處理請求

服務器端收到請求後的由web服務器（準確說應該是http服務器）處理請求，諸如Apache、Ngnix、IIS等。web服務器解析用戶請求，知道了須要調度哪些資源文件，再經過相應的這些資源文件處理用戶請求和參數，並調用數據庫信息，最後將結果經過web服務器返回給瀏覽器客戶端。

服務器處理請求

 

 

5 返回響應結果

在HTTP裏，有請求就會有響應，哪怕是錯誤信息。這裏咱們一樣看下響應報文的組成結構：

響應報文

在響應結果中都會有個一個HTTP狀態碼，好比咱們熟知的200、30一、40四、500等。經過這個狀態碼咱們能夠知道服務器端的處理是否正常，並能瞭解具體的錯誤。

狀態碼由3位數字和緣由短語組成。根據首位數字，狀態碼能夠分爲五類：

 

6 關閉TCP鏈接

爲了不服務器與客戶端雙方的資源佔用和損耗，當雙方沒有請求或響應傳遞時，任意一方均可以發起關閉請求。與建立TCP鏈接的3次握手相似，關閉TCP鏈接，須要4次握手。

4次握手

上圖能夠這麼理解：

客戶端：「兄弟，我這邊沒數據要傳了，咱關閉鏈接吧。」

服務端：「收到，我看看我這邊有木有數據了。」

服務端：「兄弟，我這邊也沒數據要傳你了，咱能夠關閉鏈接了。」

客戶端：「好嘞。」

 

 

7 瀏覽器解析HTML

準確地說，瀏覽器須要加載解析的不只僅是HTML，還包括CSS、JS。以及還要加載圖片、視頻等其餘媒體資源。

 

瀏覽器經過解析HTML，生成DOM樹，解析CSS，生成CSS規則樹，而後經過DOM樹和CSS規則樹生成渲染樹。渲染樹與DOM樹不一樣，渲染樹中並無head、display爲none等沒必要顯示的節點。

要注意的是，瀏覽器的解析過程並不是是串連進行的，好比在解析CSS的同時，能夠繼續加載解析HTML，但在解析執行JS腳本時，會中止解析後續HTML，這就會出現阻塞問題，關於JS阻塞相關問題，這裏不過多闡述。

 

8 瀏覽器佈局渲染

根據渲染樹佈局，計算CSS樣式，即每一個節點在頁面中的大小和位置等幾何信息。HTML默認是流式佈局的，CSS和js會打破這種佈局，改變DOM的外觀樣式以及大小和位置。這時就要提到兩個重要概念：replaint和reflow。

replaint：屏幕的一部分重畫，不影響總體佈局，好比某個CSS的背景色變了，但元素的幾何尺寸和位置不變。

reflow： 意味着元件的幾何尺寸變了，咱們須要從新驗證並計算渲染樹。是渲染樹的一部分或所有發生了變化。這就是Reflow，或是Layout

因此咱們應該儘可能減小reflow和replaint，我想這也是爲何如今不多有用table佈局的緣由之一。

最後瀏覽器繪製各個節點，將頁面展現給用戶。

 

 

 

七 網盤給每一個人免費2TB存儲空間背後的原理

前段時間在使用百度網盤時，忽然發現百度網盤能夠免費領取 2TB 空間啦！

網絡硬盤你們可能都或多或少的接觸過，不得不說在萬物皆雲的時代裏，這是一種很是好的網絡工具，而對咱們這種窮到掉渣的免費用戶來講，硬盤空間簡直就是硬傷，剛開始使用的時候真是爲了空間，各類折騰（作他那裏所謂的任務），到頭來也才擴充了5G左右。如今好了，隨隨便便、輕輕鬆鬆就有了2T的空間。

而這突如其來的2T空間是如何實現的呢？

事實是這樣滴！

假如我想要爲每一個用戶提供 1G 的網絡存儲空間。

若是服務器上有一顆 1000G 的硬盤能夠所有爲用戶提供數據儲存，若是每一個用戶分配 1G 的最大儲存空間，那麼能分配給多少個用戶使用呢？

你必定說是 1000/1=1000 個用戶。

可是事實上你這麼分配了，你會發現每一個用戶平時根本不會上傳 1G 的東西將容量佔的滿滿的，有多有少，但平均用戶平時只上傳 50M 的文件，也就是說，若是你將 1000G 的硬盤分給 1000我的使用，但只有效利用了其中的 50M*1000=50G 的空間，剩餘 950G 的空間基本都徹底浪費了。

那麼怎麼解決呢？

你能夠變通一下，將這 1000G 的空間分配給 20000個用戶使用，每一個人的上傳上限容量仍是1G，但每人平時仍是平均上傳 50M 的數據，那麼 20000*50M=1000G，這下子就把寶貴的服務器上的存儲空間充分利用了。但你又怕這樣分配給 20000我的後，萬一某一刻人們忽然多上傳點數據，那麼用戶不是就覺察出來你分給人家的 1G 空間是假的了嗎？因此能夠不分配那麼多人，只分配給 19000 人，剩下一些空間作應急之用。

忽然發現一會兒將可分配的用戶數量翻了 19倍啊，了不得。那還有沒有辦法更加有效的利用一下呢？

若是我有 1000個 以上的服務器，一個服務器上有 1000G 空間，那麼咱們每一個服務器上都要留下 50G 的空白空間以備用戶忽然上傳大數據時致使數據塞滿的狀況，那麼我這 1000個服務器上就空出了 1000臺*50G=50000G 的空間被浪費了，多麼惋惜。因此攻城獅們發明了存儲集羣，使得一個用戶的數據能夠被分配在多個服務器上存儲，但在用戶那看起來只是一個 1G 的連續空間，那麼就不必在每一個服務器上預留出應急的空間了，甚至能夠充分的將前一個服務器塞滿後，在將數據往下一個服務器中塞。這樣保證了服務器空間的 最大利用，若是某一刻管理員發現用戶都在瘋狂上傳數據（在一個大規模用戶羣下，這樣的機率少之又少）致使我現有提供的空間不夠了，不要緊，只須要隨手加幾塊硬盤或者服務器就解決了。

好吧，這下子咱們的服務器空間利用高多了，能夠將必定量的空間分配給最多的用戶使用了。但有沒有更好的改進方案呢？

管理員有一天發現，即便每一個用戶平均下來只存儲 50M 的東西，但這 50M 也不是一蹴而就的，是隨着1-2年的使用慢慢的達到這個數量的，也就是說，一個新的用戶剛剛註冊個人網絡空間時，不會上傳東西，或者只上傳一點很是小的東西。那麼我爲每個用戶都初始分配了 50M 的空間，即便未來2年後他們會填滿這 50M ，但這期間的這空間就有不少是浪費的啊。因此聰明的攻城獅說：既然咱們能夠分佈式、集羣式存儲，一個用戶的數據能夠分佈在多個服務器上，那麼咱們就假設一開始就給一個新註冊的用戶提供 0M 的空間，未來他用多少，我就給他提供多少存儲空間，這樣就完全的保證硬盤的利用了。但用戶的前端仍是要顯示 1G 的。

工程師的這個點子，使得我在創建網盤初期能用 1臺 1000G 的服務器提供了大約 1000000 人來註冊和使用，隨着註冊的人多了，我也有錢了，也能夠不斷增長服務器以提供他們後期的存儲了。同時由於一部分服務器完成了一年多購買，個人購買成本也下來了。

那麼…這就結束了嗎？

如果郵箱提供商的話，這樣的利用率夠高了。但網盤就不同了。

聰明的工程師發現：不一樣於郵箱，你們的內容和附件絕大多數都是自創的和不一樣的。但網盤上你們上傳的東西不少都是重複的。

好比：張三今天下載了一部《TOKYO HOT》上傳到了本身的網盤上，李四在三天後也下載瞭如出一轍的《TOKYO HOT》上傳到了網絡硬盤上，隨着用戶的增多，你會發現總共有 1000我的上傳了1000份如出一轍的文件到你寶貴的服務器空間上，因此工程師想出一個辦法，既然是同樣的文件，我就只存一份不久好啦，而後在用戶的前端顯示是沒人都有一份不久行啦。當某些用戶要刪除這個文件的時候，我並不真的刪除，只須要在前端顯示彷佛刪除了，但後端一直保留着以供其餘擁有此文件的用戶下載。直到全部使用此文件的用戶都刪除了這個文件我再真的將其刪除吧。

這樣子隨着存儲的數據愈來愈多，註冊的用戶愈來愈多，其上傳的重複數據愈來愈多。你發現這樣的檢測重複文件存儲的效率愈來愈大。這樣算下來彷佛每一個人上傳的不重複的文件只能平均 1M/用戶。這下子你能夠提供超過50倍的用戶使用您這有限的空間了。

但伴隨着使用，你又發現一個規律：

張三上傳的《TOKYO HOT N0124》和李四上傳的《TH n124》是同一個文件，只不過文件名不同，難道我就不能識別出他們是一個文件，而後只將其分別給不一樣的用戶保存成不一樣的文件名不就行啦？確實可行，但這要利用一些識別文件相同性的算法，例如MD5值等。只要兩個文件的 MD5 值同樣，文件大小同樣，我就認爲它們是相同的文件，只須要保存一份文件並給不一樣的用戶記做不一樣的文件名就行了。

有一天你發現，由於每個文件都須要計算 MD5 值，致使 CPU 負荷很大，並且原本同樣的文件非要浪費帶寬上傳回來才能夠檢測一致性，能改進一下嗎？

聰明的工程師寫了個小軟件或小插件，美其名曰「上傳控件」，將計算 MD5 的工做利用這個軟件交給了上傳用戶的電腦來完成，一旦計算出用戶要上傳的數據和服務器上已經存儲的某個數據是同樣的，就乾脆不用上傳了，直接在用戶那裏標記上這個文件已經按照 XX 文件名上傳成功了。這個過程幾乎是瞬間搞定了，並給其起了個高富帥的名字「秒傳」！

經過以上這麼多步驟，你發現原本你只能給 1000用戶 提供網絡空間的，這麼多改進辦法後，在用戶端顯示 1G 空間不變的狀況下，近乎能夠爲 1000000個用戶 提供網絡空間了。

這樣如果您哪天心情好，對外宣傳說：我要將每一個用戶的存儲空間上限提高到 1TB。那麼每一個用戶平均仍是隻上傳 50M 數據，只有極個別的用戶上傳了突破 1G 原始空間的數據，你會發現所付出的成本近乎是微乎其微的。

辛勤的攻城獅還在爲如何更有效率的利用服務器提供的磁盤空間在不屑努力和挖掘着……