從輸入URL到頁面的渲染完成經歷了什么過程

1. 瀏覽器地址欄輸入URL並回車
2. 瀏覽器查找當前URL是否存在緩存，並比較緩存是否過期
3. DNS解析URL對應的IP
4. 根據IP建立TCP連接（三次握手）
5. 發送http請求
6. 服務器處理請求，瀏覽器接受HTTP響應
7. 瀏覽器解析並渲染頁面
8. 關閉TCP連接（四次握手）

其中涉及的知識點

多進程的瀏覽器

• 瀏覽器主進程：負責協調、主控，只有一個
• 瀏覽器渲染進程（內核）（Render進程）：每個標簽頁面有一個互不影響的進程，負責頁面渲染、腳本執行、事件處理等
• 第三方插件進程：每種類型的插件對應一個進程，僅當該插件被使用時才創建
• GPU進程：最多一個，用於3D繪制

多線程的瀏覽器內核

每個標簽頁的瀏覽器內核進程是多線程的，包括：

• GUI渲染線程：負責解析HTML/CSS，構建DOM樹/CSS規則樹和render樹，布局渲染，處理Reflow(回流)和Repaint(重繪)
• JS引擎線程：負責解釋執行js腳本，js引擎是瀏覽器內核進程中的一個單線程
• 事件觸發線程：該事件不屬於JS引擎線程，用來控制事件循環，當對應的事件（如鼠標事件）符合條件被觸發時，該線程會把事件添加到待處理事件隊列的尾部，等待JS引擎線程的處理
• 定時觸發器線程：setInterval和setTimeout所在線程，當計時完畢時將要處理的邏輯置於事件隊列中，等待JS引擎線程的處理
• 異步HTTP請求線程：用於AJAX請求，當檢測到狀態（readyState、status）發生變化時，如果設有回調函數，該線程就會產生狀態變化事件，將這個回調函數放入事件隊列中，等待JS引擎處理

　　注意：GUI渲染線程與js引擎線程互斥，當js引擎線程執行時，GUI線程會被掛起，GUI更新會被保存到事件隊列中等待JS引擎線程空閑時執行，如果JS引擎線程執行時間過長，會造成頁面渲染不連貫，導致頁面渲染加載阻塞

URL解析：解析URL的協議、域名、端口號、路徑、查詢參數、哈希值等

http：不安全

https：=http+加密+認證+完整性保護

HTTPS是身披SSL外殼的HTTP：通常情況下HTTP是直接和TCP層進行通信的。當使用SSL(安全套接字)時,則演變成HTTP先和SSL通信,SSL再和TCP通信。

https的好處：

• SEO，在搜索引擎上排名更高
• 安全性，數據的完整性，現行架構下最安全的解決方案，雖然不是絕對安全，但是大幅度增加了中間人攻擊的成本
• 缺點：費時，費資源

緩存解析：流程是先找瀏覽器緩存和本地緩存，如果存在則直接使用該緩存；如果不存在，則進行DNS緩存尋找，如果還是不存在，則進行DNS解析，查詢出域名對應的IP地址

瀏覽器緩存：

　　緩存位置：

1. Service Worker：傳輸協議必須是https，Service Worker 是運行在瀏覽器背后的獨立線程，一般可以用來實現緩存功能。
2. Memory Cache：內存中的緩存，會隨着進程的釋放而釋放，即一旦關閉頁面，內存中的緩存也就被釋放了。當我們訪問過頁面以后，再次刷新頁面，可以發現很多數據都來自於內存緩存。需要注意的事情是，內存緩存在緩存資源時並不關心返回資源的HTTP緩存頭Cache-Control是什么值，同時資源的匹配也並非僅僅是對URL做匹配，還可能會對Content-Type，CORS等其他特征做校驗。
3. Disk Cache：硬盤緩存，在所有瀏覽器緩存中，Disk Cache 覆蓋面基本是最大的。它會根據 HTTP Herder 中的字段判斷哪些資源需要緩存，哪些資源可以不請求直接使用，哪些資源已經過期需要重新請求。並且即使在跨站點的情況下，相同地址的資源一旦被硬盤緩存下來，就不會再次去請求數據。絕大部分的緩存都來自 Disk Cache
4. Push Cache：推送緩存，只有在上述三種緩存都沒有命中時才會被使用。它只在會話（Session）中存在，一旦會話結束就被釋放，並且緩存時間也很短暫，在Chrome瀏覽器中只有5分鍾左右，同時它也並非嚴格執行HTTP頭中的緩存指令。

　　緩存種類：

　　cookie：為了解決HTTP協議無狀態特性的方法，從而使服務器可以跟蹤會話。cookie由服務端生成，發送給User-Agent，瀏覽器會將cookie以key/value形式保存，下次請求同一網站時自動發送該cookie給服務器，即添加在請求頭部，一般大小為4KB

　　　　具有保質期：可以通過Expires、max-age來指定

　　　　需要滿足同源策略才能調用cookie

指定可訪問cookie的主機名 和路徑類似，主機名是指同一個域下的不同主機，例如：www.google.com和gmail.google.com就

是兩個不同的主機名。默認情況下，一個主機中創建的cookie在另一個主機下是不能被訪問的，但可以通過domain參數來實現對其的控制，其語法格式為：

document.cookie="name=value;//操作cookie

domain=cookieDomain";

以google為例，要實現跨主機訪問，可以寫為：

document.cookie="name=value;

domain=.google.com";

這樣，所有google.com下的主機都可以訪問該cookie。

　　localstorage：html5的一種新的本地緩存方案，目前用的比較多，一般用來存儲ajax返回的數據，加快下次頁面打開時的渲染速度。但是loaclstorage大小有限制，5MB。不適合存放過多的數據，如果數據存放超過最大值會報錯，並移除最先保存的數據

　　

　　var name = localStorage.key(i)​;

     var value = localStorage.getItem(name);​

　　localStorage.removeItem("key");//刪除名稱為“key”的信息。

　　localStorage.clear();​//清空localStorage中所有信息

　　sessionstorage：和localstorage類似，但是在瀏覽器關閉時會被刪除

　　不同瀏覽器無法共享localstorage或sessionstorage中的信息，但相同瀏覽器的不同頁面間可以共享相同的localstorage，但是不同標簽頁之間無法共享sessionstorage的信息。這里需要注意的是，頁面及標簽頁僅指頂級窗口，如果一個標簽頁包含多個iframe標簽且他們屬於同源頁面，那么他們之間是可以共享sessionStorage的。

　　緩存策略：都是通過設置HTTP Header來實現的

　　瀏覽器對於緩存的處理是根據第一次請求資源時返回的響應頭來確定的，即：

• 瀏覽器每次發起請求，都會先在瀏覽器緩存中查找該請求結果以及緩存標識
• 瀏覽器每次拿到返回的請求結果都會將該結果和緩存標識存入瀏覽器緩存中　　　　　　　　　　　　　　　　　　　　

　根據是否需要向服務器重新發起HTTP請求將緩存過程分為兩個部分，分別是強緩存和協商緩存

　　1.強緩存：不會向服務器發送請求，直接從緩存中讀取資源，在chrome控制台的Network選項中可以看到該請求返回200的狀態碼，並且Size顯示from disk cache或from memory cache。強緩存可以通過設置兩種HTTP Header來實現：Expires和Cache-Control

　　Expires：緩存過期時間，用來指定資源到期的時間，是服務器端的具體的時間點。位於Response Header中，在響應http請求時告訴瀏覽器在過期時間前瀏覽器可以直接從瀏覽器緩存獲取數據，而無需再次請求。如expires:Tue, 31 Mar 2020 14:49:57 GMT。Expires 是 HTTP/1 的產物，受限於本地時間，如果修改了本地時間，可能會造成緩存失效。

　　Cache-Control：主要控制網頁緩存，比如當Cache-Control:max-age=300時，則代表在這個請求正確返回時間（瀏覽器也會記錄下來）的5分鍾內再次加載資源，就會命中強緩存。

　　　　參數：public：所有內容都將被緩存（客戶端和代理服務器都可以緩存）

　　　　　　   private：所有內容只有客戶端可以緩存，默認

　　　　　　   no-cache：不是說瀏覽器不再緩存數據，而是瀏覽器在使用緩存數據時，需要先確認一下數據是否還跟服務器保持一致

　　　　　　   no-store：所有內容都不會被緩存，即不使用強緩存，也不使用協商緩存

　　　　　　   max-age：max-age=xxx (xxx is numeric)表示緩存內容將在xxx秒后失效

　　　　　　   s-maxage：同max-age作用一樣，只在代理服務器中生效（比如CDN緩存）。比如當s-maxage=60時，在這60秒中，即使更新了CDN的內容，瀏覽器也不會進行請求。max-age用於普通緩存，而s-maxage用於代理緩存。s-maxage的優先級高於max-age。如果存在s-maxage，則會覆蓋掉max-age和Expires header。

　　　　　　   max-stale：能容忍的最大過期時間。

　　　　　　   min-fresh：能夠容忍的最小新鮮度。

　　Expires和Cache-Control對比：其實這兩者差別不大，區別就在於 Expires 是http1.0的產物，Cache-Control是http1.1的產物，兩者同時存在的話，Cache-Control優先級高於Expires；在某些不支持HTTP1.1的環境下，Expires就會發揮用處。所以Expires其實是過時的產物，現階段它的存在只是一種兼容性的寫法。

　　2.協商緩存：強緩存判斷是否緩存的依據是來自於是否超出某個時間或某個時間段，而不關心服務器端文件是否已經更新，這可能會導致加載文件不是服務器端的最新內容。想要獲知服務器端內容是否已經發生更新，這時就要用到協商緩存策略

　　協商緩存就是強緩存失效后，瀏覽器攜帶緩存標識向服務器發送請求，由服務器根據緩存標識決定是否使用標識的過程。主要有兩種情況：

• 協商緩存生效，返回304和Not Modified，即服務器端沒有發生該資源的更新，可以使用該緩存
• 協商緩存失效，返回200和請求結果，即從服務器端重新獲取更新之后的資源，再將其緩存到瀏覽器緩存中，並使用

　　協商緩存可以通過設置兩種HTTP Header實現：Last-Modified和ETag

　　Last-Modified：瀏覽器在第一次訪問資源時，服務器返回資源的同時，會在response header中添加Last-Modified的header，值為這個資源在服務器上最后修改的時間，如Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT

　　　　　　　　瀏覽器下一次請求這個資源時，這個值被放進資源請求發給服務器端，如果這個值沒有改變，則返回304和Modified，即協商緩存生效，否則協商緩存失效，重新請求該資源

　　　　　　　　但是根據文件修改時間來判斷是否修改這個做法有缺陷，所以引出了根據文件內容是否修改來決定的緩存策略，即ETag

　　ETag：服務器響應請求時，返回當前資源文件的一個唯一標識（由服務器生成），只要資源有變化，ETag就會重新生成。瀏覽器在下一次加載資源向服務器發送請求時，會將上一次返回的Etag值放到request header里的If-None-Match里，服務器只需要比較客戶端傳來的If-None-Match跟自己服務器上該資源的ETag是否一致，就能很好地判斷資源相對客戶端而言是否被修改過了。

　　兩者對比：

• 首先在精確度上，Etag要優於Last-Modified。

Last-Modified的時間單位是秒，如果某個文件在1秒內改變了多次，那么他們的Last-Modified其實並沒有體現出來修改，但是Etag每次都會改變確保了精度；如果是負載均衡的服務器，各個服務器生成的Last-Modified也有可能不一致。

• 第二在性能上，Etag要遜於Last-Modified，畢竟Last-Modified只需要記錄時間，而Etag需要服務器通過算法來計算出一個hash值。
• 第三在優先級上，服務器校驗優先考慮Etag

　　緩存機制：強緩存優先於協商緩存，若強制緩存(Expires和Cache-Control)生效則直接使用緩存，若不生效則進行協商緩存(Last-Modified / If-Modified-Since和Etag / If-None-Match)，協商緩存由服務器決定是否使用緩存，若協商緩存失效，那么代表該請求的緩存失效，返回200，重新返回資源和緩存標識，再存入瀏覽器緩存中；生效則返回304，繼續使用緩存。

　　 如果什么緩存策略都沒設置，那么瀏覽器會怎么處理：瀏覽器會采用一個啟發式的算法，通常會取響應頭中的 Date 減去 Last-Modified 值的 10% 作為緩存時間。

實際場景應用緩存策略

1.頻繁變動的資源

Cache-Control: no-cache

對於頻繁變動的資源，首先需要使用Cache-Control: no-cache 使瀏覽器每次都請求服務器，然后配合 ETag 或者 Last-Modified 來驗證資源是否有效。這樣的做法雖然不能節省請求數量，但是能顯著減少響應數據大小。

2.不常變化的資源

Cache-Control: max-age=31536000

通常在處理這類資源時，給它們的 Cache-Control 配置一個很大的 max-age=31536000 (一年)，這樣瀏覽器之后請求相同的 URL 會命中強制緩存。而為了解決更新的問題，就需要在文件名(或者路徑)中添加 hash， 版本號等動態字符，之后更改動態字符，從而達到更改引用 URL 的目的，讓之前的強制緩存失效 (其實並未立即失效，只是不再使用了而已)。
在線提供的類庫 (如 jquery-3.3.1.min.js, lodash.min.js 等) 均采用這個模式。

八、用戶行為對瀏覽器緩存的影響

所謂用戶行為對瀏覽器緩存的影響，指的就是用戶在瀏覽器如何操作時，會觸發怎樣的緩存策略。主要有 3 種：

• 打開網頁，地址欄輸入地址： 查找 disk cache 中是否有匹配。如有則使用；如沒有則發送網絡請求。
• 普通刷新 (F5)：因為 TAB 並沒有關閉，因此 memory cache 是可用的，會被優先使用(如果匹配的話)。其次才是 disk cache。
• 強制刷新 (Ctrl + F5)：瀏覽器不使用緩存，因此發送的請求頭部均帶有 Cache-control: no-cache(為了兼容，還帶了 Pragma: no-cache),服務器直接返回 200 和最新內容。

DNS緩存：遞歸查找：查找的順序是（根域名服務器，一級域名服務器，二級域名服務器，三級域名服務器）

HTTP請求

• HTTP請求報文是由三部分組成: 請求行, 請求頭和請求正文。

請求行

Method Request-URL HTTP-Version CRLF eg: GET index.html HTTP/1.1 

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

請求頭

• 請求報頭允許客戶端向服務器傳遞請求的附加信息和客戶端自身的信息。
• 常見的請求報頭有: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Type, Authorization, Cookie, User-Agent等。
• Accept用於指定客戶端用於接受哪些類型的信息，Accept-Encoding與Accept類似，它用於指定接受的編碼方式。Connection設置為Keep-alive用於告訴客戶端本次HTTP請求結束之后並不需要關閉TCP連接，這樣可以使下次HTTP請求使用相同的TCP通道，節省TCP連接建立的時間。

請求正文

當使用POST, PUT等方法時，通常需要客戶端向服務器傳遞數據。這些數據就儲存在請求正文中。在請求包頭中有一些與請求正文相關的信息，例如: 現在的Web應用通常采用Rest架構，請求的數據格式一般為json。這時就需要設置Content-Type: application/json。

 

瀏覽器獲取HTML，解析，渲染

1. 加載解析HTML，開始構建DOM樹。
2. 遇到CSS外鏈，異步加載解析CSS，構建CSS規則樹。
3. 遇到script標簽，如果是普通JS標簽則同步加載並執行，阻塞頁面渲染，如果標簽上有defer/async屬性則異步加載JS資源。設置defer的JS資源會在DOMContentLoaded事件之前執行；設置了async的JS資源加載完就執行。
4. 合並DOM樹和CSS規則樹生成render樹。
5. 布局render樹，計算各元素的尺寸、位置等，在內存上生成Bitmap。
6. 渲染render樹，將內存上的Bitmap繪制到屏幕上。
7. 瀏覽器將各層信息發送給GPU，GPU將各層合成，顯示在屏幕上 

　　回流和重繪：

　　回流：當render tree中的一部分（或全部）因為元素的規模尺寸、布局、隱藏等改變而需要重新構建的過程，成為回流（reflow），頁面渲染的時候必然發生一次

　　重繪：當render tree中的一些元素需要更新屬性，而這些屬性只是影響元素的外觀，風格，而不會影響布局的，比如background-color。則就叫稱為重繪。

　　區別：回流必然引起重繪，但是重繪不一定引起回流，比如：只有顏色改變的時候就只會發生重繪而不會引起回流。

　　　　　當頁面布局和幾何屬性改變時就需要回流，比如：添加或者刪除可見的DOM元素，元素位置改變，元素尺寸改變——邊距、填充、邊框、寬度和高度，內容改變

　　盡量減少回流和重繪，提高性能（通過瀏覽器或代碼優化的方式）：因為，回流花銷很大，所以大部分瀏覽器對於回流都會進行優化，瀏覽器會維護1個隊列，把所有會引起回流、重繪的操作放入這個隊列，等隊列中的操作到了一定的數量或者到了一定的時間間隔，瀏覽器就會flush(清空)隊列，進行一個批處理。這樣就會讓多次的回流、重繪變成一次回流重繪。

優化方案

• 減少逐項更改樣式，最好一次性更改style，或者將樣式定義為class並一次性更新
• 避免循環操作dom，創建一個documentFragment或div，在它上面應用所有DOM操作，最后再把它添加到window.document
  • （1）DocumentFragment 節點不屬於文檔樹，繼承的 parentNode 屬性總是 null。不過它有一種特殊的行為，該行為使得它非常有用，即當請求把一個 DocumentFragment 節點插入文檔樹時，插入的不是 DocumentFragment 自身，而是它的所有子孫節點。這使得 DocumentFragment 成了有用的占位符，暫時存放那些一次插入文檔的節點。它還有利於實現文檔的剪切、復制和粘貼操作。其實他就是一個游離在DOM樹外面的容器，所以你在把它插入文檔節點之前，隨便給他增刪節點都不會引起回流
  • （2）使用display:none,只引發兩次回流和重繪。道理跟上面的一樣。因為display:none的元素不會出現在render樹
  • （3）使用cloneNode和replaceChild技術，引發一次回流和重繪（這條其實沒太明白）
• 避免多次讀取offset等屬性。無法避免則將它們緩存到變量
• 將復雜的元素絕對定位或固定定位，使得它脫離文檔流，否則回流代價會很高
• 盡量不要使用表格布局，如果沒有定寬表格一列的寬度由最寬的一列決定，那么很可能在最后一行的寬度超出之前的列寬，引起整體回流造成table可能需要多次計算才能確定好其在渲染樹中節點的屬性，通常要花3倍於同等元素的時間。

資源外鏈的下載

遇到外鏈時的處理

• 遇到外鏈時，會單獨開啟一個下載線程去下載資源（http1.1中是每一個資源的下載都要開啟一個http請求，對應一個tcp/ip鏈接）

遇到CSS樣式資源

CSS資源的處理有幾個特點：

• CSS下載時異步，不會阻塞瀏覽器構建DOM樹
• 會阻塞渲染，也就是在構建render時，會等到css下載解析完畢后才進行（這點與瀏覽器優化有關，防止css規則不斷改變，避免了重復的構建）
• media query聲明的CSS是不會阻塞渲染的

遇到JS腳本資源

JS腳本資源的處理有幾個特點：

• 阻塞瀏覽器的解析，也就是說發現一個外鏈腳本時，需等待腳本下載完成並執行后才會繼續解析HTML
• 瀏覽器的優化，一般現代瀏覽器有優化，在腳本阻塞時，也會繼續下載其它資源（當然有並發上限），但是雖然腳本可以並行下載，解析過程仍然是阻塞的，也就是說必須這個腳本執行完畢后才會接下來的解析，並行下載只是一種優化而已
• defer與async，普通的腳本是會阻塞瀏覽器解析的，但是可以加上defer或async屬性，這樣腳本就變成異步了，可以等到解析完畢后再執行 詳見異步加載JS

遇到img圖片類資源

• 遇到圖片等資源時，直接就是異步下載，不會阻塞解析，下載完畢后直接用圖片替換原有src的地方

為什么要先引入CSS文件，再引入js文件？

(1)js的下載是阻塞下載，不可以和其他代碼並行下載和解析。但是CSS的加載不會阻塞DOM樹的解析（會阻塞其渲染，也會阻塞后面js的執行）

(2)頁面加載時，是按照從上到下，從左到右的順序加載的，如果將js放在前面，會立即執行，阻塞后面的資源下載和執行。如果外部腳本加載時間過長，就會造成網頁長時間失去響應，瀏覽器會呈現假死狀態

(3)部分js的執行依賴於前面的CSS樣式

(4)js一般是處理功能，所以不需要提前加載。先跟用戶觀感，再給用戶上手體驗

loaded和domcontentloaded

簡單的對比：

• DOMContentLoaded： 事件觸發時，僅當DOM加載完成，不包括樣式表，圖片(譬如如果有async加載的腳本就不一定完成)
• load： 事件觸發時，頁面上所有的DOM，樣式表，腳本，圖片都已經加載完成了

為了避免用戶的白屏時間，應盡可能提高CSS加載速度，方法？

• 使用CDN（Content Delivery Network，內容分發網絡），CDN會根據你的網絡狀況，替你挑選最近的一個具有緩存內容的節點為你提供資源，減少加載時間
• 將CSS壓縮
• 合理使用緩存（設置cache-control，expires以及E-tag）
• 減少HTTP請求數，多個CSS合並，或者干脆直接寫成內聯樣式（但是內聯樣式的缺點是不能緩存）

JS引擎解析過程

JS的解釋階段

• JS是解釋型語言，所以它無需提前編譯，而是由解釋器實時運行
• 核心的JIT編譯器將源碼編譯成機器碼運行

JS的預處理階段

• 分號補全
• 變量提升

JS的執行階段

• 執行上下文，執行堆棧概念（如全局上下文，當前活動上下文）
• VO（變量對象）和AO（活動對象）
• 作用域鏈
• this機制等

　　

 

HTTP和HTTPS的區別

 

HTTP（Hyper Text Transfer Protocol，超文本傳輸協議）被用於在web瀏覽器和網站服務器之間傳遞信息，HTTP協議以明文的方式發送內容，不提供任何方式的數據加密，如果攻擊者截取了web瀏覽器和網站服務器之間的傳輸報文，就可以直接讀懂其中的信息，因此，HTTP協議不適合傳輸一些敏感信息，比如：信用卡號，密碼等支付信息。

 

HTTPS（Hyper Text Transfer Protocol over Secure Socket Layer，安全套接字超文本傳輸協議），為了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL/TLS，依靠證書來驗證服務器的身份，並為瀏覽器和服務器之間的通信加密。其中SSL（Secure Socket Layer，安全套接層），TLS（Transport Layer Securit，傳輸層安全協議），SSL 3.0和TLS 1.0差別很小，在HTTPS通信中具體使用哪一個還要看客戶端和服務端的支持程度，二者在網絡模型中位於哪一層？

 

 

 

 

 

區別：

 

（1）HTTPS協議需要CA申請證書，一般免費證書比較少，所以需要一定費用

 

（2）HTTP是超文本傳輸協議，信息是明文傳輸，HTTPS則是具有安全性的SSL加密傳輸協議

 

（3）HTTP和HTTPS使用的是完全不同的連接方式，使用的端口號也不一樣，前者是80，后者是443

 

（4）HTTP連接很簡單，是無狀態的；HTTPS協議是由HTTP+SSL協議構建的可進行加密傳輸、身份認證的網絡協議，比較安全。

 

（5）谷歌搜索引擎算法中，比起同等HTTP網站，采用HTTPS加密的網站在搜索結果中排名會更高

 

15.客戶端使用HTTPS方式與web服務器通信的步驟：

 

（1）客戶使用HTTPS的URL訪問web服務器，要求與web服務器建立SSL連接

 

（2）web服務器收到客戶端請求后，將網站的證書信息（證書中包含公鑰）傳送一份給客戶端；這個證書其實是一套公鑰和私鑰，這里把公鑰給客戶端，相當於鎖頭，私鑰(唯一)服務器端保留，相當於鑰匙

 

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

 

4、客戶端解析證書

這部分工作是由客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那么就生成一個隨機值，然后用證書對該隨機值進行加密，就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內容。

5、傳送加密信息

這部分傳送的是用證書加密后的隨機值，目的就是讓服務端得到這個隨機值，以后客戶端和服務端的通信就可以通過這個隨機值來進行加密解密了。

6、服務段解密信息

服務端用私鑰解密后，得到了客戶端傳過來的隨機值(私鑰)，然后把內容通過該值進行非對稱加密，所謂非對稱加密就是，將信息和私鑰通過某種算法混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以只要加密算法夠彪悍，私鑰夠復雜，數據就夠安全。

對稱加密：使用同樣的算法和密鑰對密文進行解密。加密-解密的過程完全對稱，因此被稱為對稱密鑰加密。

7、傳輸加密后的信息

這部分信息是服務段用私鑰加密后的信息，可以在客戶端被還原。

8、客戶端解密信息

客戶端用之前生成的私鑰解密服務段傳過來的信息，於是獲取了解密后的內容，整個過程第三方即使監聽到了數據，也束手無策。

 

16.如何從HTTP切換到HTTPS？

 

（1）需要將頁面中所有的鏈接（例如js,css,圖片等鏈接）都由http改為https

 

（2）一般情況下會建議保留HTTP，所以在切換的時候可以做HTTP和HTTPS的兼容，具體實現方式是：去掉頁面連接中的http頭部，這樣可以自動匹配HTTP頭和HTTPS頭