前端技術-HTML頁面的加載

HTML頁面的加載

HTML頁面的加載其實是基於http過程+瀏覽器對數據的解析渲染。

http協議的請求過程是基於TCP協議的。http是要基於TCP鏈接基礎上，簡單的說，TCP單純創建鏈接，不涉及任何咱們須要請求的實際數據，簡單的傳輸。http基於TCP創建的鏈接來收發數據，即實際應用上來的。

一個HTML頁面的加載的交互流程大體以下：

0.輸入URL
1.解析URL
2.構造併發送HTTP請求
服務器的永久重定向響應（從 http://example.com 到 http://www.example.com）
瀏覽器跟蹤重定向地址
3.HTTP報文傳輸過程
4.服務器接受並處理HTTP報文
5.服務器構造併發送響應報文（傳輸過程略）
6.瀏覽器接收報文，並開始構建頁面
7.（可選）瀏覽器發送嵌入在 HTML 中的靜態資源如圖片、音頻、視頻、CSS、JS等等）
8.（可選）瀏覽器發送Ajax異步請求（處理過程略）
9.頁面構建完成

一.http過程

http協議的請求過程是基於TCP協議的。其實是TCP/IP協議簇的共同做用。

1.TCP/IP協議

TCP/IP協議，Transmission Control Protocol/Internet Protocol的簡寫，中譯名爲傳輸控制協議/因特網互聯協議，又名網絡通信協議，是Internet最基本的協議、Internet國際互聯網絡的基礎，由網絡層的IP協議和傳輸層的TCP協議組成的協議簇。它是計算機網絡的的實際分層方式。

計算機網絡的分層

第一種ISO/OSI模型，即開放式通訊系統互聯參考模型（Open System Interconnection Reference Model），是國際標準化組織（ISO）提出的一個試圖使各類計算機在世界範圍內互連爲網絡的標準框架，簡稱OSI。但是實踐中沒有普遍應用。

層	簡介	協議
第一層：物理層（PhysicalLayer)	規定通訊設備的機械的、電氣的、功能的和過程的特性，用以創建、維護和拆除物理鏈路鏈接。具體地講，機械特性規定了網絡鏈接時所需接插件的規格尺寸、引腳數量和排列狀況等；電氣特性規定了在物理鏈接上傳輸bit流時線路上信號電平的大小、阻抗匹配、傳輸速率距離限制等；功能特性是指對各個信號先分配確切的信號含義，即定義了DTE和DCE之間各個線路的功能；規程特性定義了利用信號線進行bit流傳輸的一組操做規程，是指在物理鏈接的創建、維護、交換信息是，DTE和DCE雙放在各電路上的動做系列。 在這一層，數據的單位稱爲比特（bit）。	屬於物理層定義的典型規範表明包括：EIA/TIA RS-23二、EIA/TIA RS-44九、V.3五、RJ-45等。
第二層：數據鏈路層（DataLinkLayer)	在物理層提供比特流服務的基礎上，創建相鄰結點之間的數據鏈路，經過差錯控制提供數據幀（Frame）在信道上無差錯的傳輸，並進行各電路上的動做系列。  數據鏈路層在不可靠的物理介質上提供可靠的傳輸。該層的做用包括：物理地址尋址、數據的成幀、流量控制、數據的檢錯、重發等。 在這一層，數據的單位稱爲幀（frame）。	數據鏈路層協議的表明包括：SDLC、HDLC、PPP、STP、幀中繼等。
第三層是網絡層(Network layer)	在計算機網絡中進行通訊的兩個計算機之間可能會通過不少個數據鏈路，也可能還要通過不少通訊子網。網絡層的任務就是選擇合適的網間路由和交換結點， 確保數據及時傳送。網絡層將數據鏈路層提供的幀組成數據包，包中封裝有網絡層包頭，其中含有邏輯地址信息- -源站點和目的站點地址的網絡地址。 若是你在談論一個IP地址，那麼你是在處理第3層的問題，這是「數據包」問題，而不是第2層的「幀」。IP是第3層問題的一部分，此外還有一些路由協議和地址解析協議（ARP）。有關路由的一切事情都在第3層處理。地址解析和路由是3層的重要目的。網絡層還能夠實現擁塞控制、網際互連等功能。 在這一層，數據的單位稱爲數據包（packet）。	網絡層協議的表明包括：IP、IPX、RIP、OSPF等。
第四層是處理信息的傳輸層(Transport layer)	第4層的數據單元也稱做數據包（packets）。可是，當你談論TCP等具體的協議時又有特殊的叫法，TCP的數據單元稱爲段（segments）而UDP協議的數據單元稱爲「數據報（datagrams）」。這個層負責獲取所有信息，所以，它必須跟蹤數據單元碎片、亂序到達的數據包和其它在傳輸過程當中可能發生的危險。第4層爲上層提供端到端（最終用戶到最終用戶）的透明的、可靠的數據傳輸服務。所爲透明的傳輸是指在通訊過程當中傳輸層對上層屏蔽了通訊傳輸系統的具體細節。	傳輸層協議的表明包括：TCP、UDP、SPX等。
第五層是會話層(Session layer)	這一層也能夠稱爲會晤層或對話層，在會話層及以上的高層次中，數據傳送的單位再也不另外命名，統稱爲報文。會話層不參與具體的傳輸，它提供包括訪問驗證和會話管理在內的創建和維護應用之間通訊的機制。如服務器驗證用戶登陸即是由會話層完成的。
第六層是表示層(Presentation layer)	這一層主要解決用戶信息的語法表示問題。它將欲交換的數據從適合於某一用戶的抽象語法，轉換爲適合於OSI系統內部使用的傳送語法。即提供格式化的表示和轉換數據服務。數據的壓縮和解壓縮， 加密和解密等工做都由表示層負責。
第七層應用層(Application layer)	應用層爲操做系統或網絡應用程序提供訪問網絡服務的接口。	應用層協議的表明包括：Telnet、FTP、HTTP、SNMP等。

第二種TCP/IP協議模型（Transmission Control Protocol/Internet Protocol），包含了一系列構成互聯網基礎的網絡協議，是Internet的核心協議。根據實際狀況將ISO的OSI模型改造爲5層，這種模型具備現實可行性。目前已成爲事實上的國際標準。TCP/IP協議簇是一組不一樣層次上的多個協議的組合，一般被認爲是一個五層協議系統，與OSI的七層模型相對應。

TCP/IP協議簇中不一樣層次的協議：

(1). 鏈路層 
也稱做數據鏈路層或網絡接口層（在第一個圖中爲網絡接口層和硬件層），一般包括操做系統中的設備驅動程序和計算機中對應的網絡接口卡。它們一塊兒處理與電纜（或其餘任何傳輸媒介）的物理接口細節。ARP（地址解析協議）和RARP（逆地址解析協議）是某些網絡接口（如以太網和令牌環網）使用的特殊協議，用來轉換IP層和網絡接口層使用的地址。     
(2). 網絡層
也稱做互聯網層（在第一個圖中爲網際層），處理分組在網絡中的活動，例如分組的選路。在TCP/IP協議族中，網絡層協議包括IP協議（網際協議），ICMP協議（Internet互聯網控制報文協議），以及IGMP協議（Internet組管理協議）。     
IP是一種網絡層協議，提供的是一種不可靠的服務，它只是儘量快地把分組從源結點送到目的結點，可是並不提供任何可靠性保證。同時被TCP和UDP使用。TCP和UDP的每組數據都經過端系統和每一箇中間路由器中的IP層在互聯網中進行傳輸。  IP層接收由更低層（網絡接口層例如以太網設備驅動程序）發來的數據包，並把該數據包發送到更高層---TCP或UDP層；相反，IP層也把從TCP或UDP層接收來的數據包傳送到更低層。IP數據包是不可靠的，由於IP並無作任何事情來確認數據包是按順序發送的或者沒有被破壞。IP數據包中含有發送它的主機的地址（源地址）和接收它的主機的地址（目的地址）。   
ICMP是IP協議的附屬協議（PING是最經常使用的基於ICMP的服務）。IP層用它來與其餘主機或路由器交換錯誤報文和其餘重要信息。  IGMP是Internet組管理協議。它用來把一個UDP數據報多播到多個主機。
(3). 傳輸層
主要爲兩臺主機上的應用程序提供端到端的通訊。在TCP/IP協議族中，有兩個互不相同的傳輸協議：TCP（傳輸控制協議）和UDP（用戶數據報協議）。     
TCP爲兩臺主機提供高可靠性的數據通訊。它所作的工做包括把應用程序交給它的數據分紅合適的小塊交給下面的網絡層，確認接收到的分組，設置發送最後確認分組的超時時鐘等。因爲運輸層提供了高可靠性的端到端的通訊，所以應用層能夠忽略全部這些細節。爲了提供可靠的服務，TCP採用了超時重傳、發送和接收端到端的確認分組等機制。  UDP則爲應用層提供一種很是簡單的服務。它只是把稱做數據報的分組從一臺主機發送到另外一臺主機，但並不保證該數據報能到達另外一端。一個數據報是指從發送方傳輸到接收方的一個信息單元（例如，發送方指定的必定字節數的信息）。UDP協議任何須需的可靠性必須由應用層來提供。     
(4). 應用層
應用層負責處理特定的應用程序細節。

接下來介紹TCP鏈接的創建。

2.TCP的三次握手與四次分手

TCP是面向鏈接的，不管哪一方向另外一方發送數據以前，都必須先在雙方之間創建一條鏈接。在TCP/IP協議中，TCP協議提供可靠的鏈接服務，鏈接是經過三次握手進行初始化的。三次握手的目的是同步鏈接雙方的序列號和確認號並交換 TCP窗口大小信息。先來看圖說話。

三次握手

第一次握手：創建鏈接。客戶端發送鏈接請求報文段，將SYN位置爲1，Sequence Number爲x；而後，客戶端進入SYN_SEND狀態，等待服務器的確認；
第二次握手：服務器收到SYN報文段。服務器收到客戶端的SYN報文段，須要對這個SYN報文段進行確認，設置Acknowledgment Number爲x+1(Sequence Number+1)；同時，本身本身還要發送SYN請求信息，將SYN位置爲1，Sequence Number爲y；服務器端將上述全部信息放到一個報文段（即SYN+ACK報文段）中，一併發送給客戶端，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN+ACK報文段。而後將Acknowledgment Number設置爲y+1，向服務器發送ACK報文段，這個報文段發送完畢之後，客戶端和服務器端都進入ESTABLISHED狀態，完成TCP三次握手。
完成了三次握手，客戶端和服務器端就能夠開始傳送數據。

四次分手

當客戶端和服務器經過三次握手創建了TCP鏈接之後，當數據傳送完畢，確定是要斷開TCP鏈接的啊。那對於TCP的斷開鏈接，這裏就有了神祕的「四次分手」。
第一次分手：主機1（可使客戶端，也能夠是服務器端），設置Sequence Number和Acknowledgment Number，向主機2發送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有數據要發送給主機2了；
第二次分手：主機2收到了主機1發送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number爲Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我也沒有數據要發送了，能夠進行關閉鏈接了；
第三次分手：主機2向主機1發送FIN報文段，請求關閉鏈接，同時主機2進入CLOSE_WAIT狀態；
第四次分手：主機1收到主機2發送的FIN報文段，向主機2發送ACK報文段，而後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段之後，就關閉鏈接；此時，主機1等待2MSL後依然沒有收到回覆，則證實Server端已正常關閉，那好，主機1也能夠關閉鏈接了。發送完畢以後，客戶端進入等待狀態，等待兩個時間週期。關閉。
至此，TCP的四次分手就這麼愉快的完成了。當你看到這裏，你的腦子裏會有不少的疑問，不少的不懂，感受很凌亂；沒事，咱們繼續總結。

爲何要三次握手

既然總結了TCP的三次握手，那爲何非要三次呢？怎麼以爲兩次就能夠完成了。

爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤。

舉例以下：

「已失效的鏈接請求報文段」的產生在這樣一種狀況下：client發出的第一個鏈接請求報文段並無丟失，而是在某個網絡結點長時間的滯留了，以至延誤到鏈接釋放之後的某個時間纔到達server。原本這是一個早已失效的報文段。但server收到此失效的鏈接請求報文段後，就誤認爲是client再次發出的一個新的鏈接請求。因而就向client發出確認報文段，贊成創建鏈接。假設不採用「三次握手」，那麼只要server發出確認，新的鏈接就創建了。因爲如今client並無發出創建鏈接的請求，所以不會理睬server的確認，也不會向server發送數據。但server卻覺得新的運輸鏈接已經創建，並一直等待client發來數據。這樣，server的不少資源就白白浪費掉了。採用「三次握手」的辦法能夠防止上述現象發生。例如剛纔那種狀況，client不會向server的確認發出確認。server因爲收不到確認，就知道client並無要求創建鏈接。」
這就很明白了，防止了服務器端的一直等待而浪費資源。

那四次分手又是爲什麼呢？

TCP協議是一種面向鏈接的、可靠的、基於字節流的運輸層通訊協議。TCP是全雙工模式，這就意味着，當主機1發出FIN報文段時，只是表示主機1已經沒有數據要發送了，主機1告訴主機2，它的數據已經所有發送完畢了；可是，這個時候主機1仍是能夠接受來自主機2的數據；當主機2返回ACK報文段時，表示它已經知道主機1沒有數據發送了，可是主機2仍是能夠發送數據到主機1的；當主機2也發送了FIN報文段時，這個時候就表示主機2也沒有數據要發送了，就會告訴主機1，我也沒有數據要發送了，以後彼此就會愉快的中斷此次TCP鏈接。

爲何四次分手TIME_WAIT狀態還須要等2MSL後才能返回到CLOSED狀態？

這是由於雖然雙方都贊成關閉鏈接了，並且握手的4個報文也都協調和發送完畢，按理能夠直接回到CLOSED狀態（就比如從SYN_SEND狀態到ESTABLISH狀態那樣）；可是由於咱們必需要假想網絡是不可靠的，你沒法保證你最後發送的ACK報文會必定被對方收到，所以對方處於LAST_ACK狀態下的SOCKET可能會由於超時未收到ACK報文，而重發FIN報文，因此這個TIME_WAIT狀態的做用就是用來重發可能丟失的ACK報文。
一、  客戶端的最後一個ACK報文在傳輸的時候丟失，服務器並無接收到這個報文。這個候。
服務器就會超時重傳這個FIN消息，而後客戶端就會從新返回最後一個ACK報文，等待兩個時間週期，完成關閉。若是不等待這兩個時間週期，服務器重傳的那條消息就不會收到。服務器就由於接收不到客戶端的信息而沒法正常關閉。
二、  預防上一次在三次握手中提到的失效的報文干擾。兩個時間週期過去以後，全部的報文都會在網絡中消失，保證下一次從新鏈接的時候有亂七八糟的報文影響。

TCP創建了鏈接，咱們看看http是在TCP鏈接基礎上進行請求的。

3.HTTP協議詳解

HTTP是一個屬於應用層的面向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。它於1990年提出，通過幾年的使用與發展，獲得不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工做正在進行之中，並且HTTP-NG(Next Generation of HTTP)的建議已經提出。
HTTP協議的主要特色可歸納以下：

1.支持客戶/服務器模式。
2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。
3.靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
4.無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。
5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

HTTP協議之URL

http URL (URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息)的格式以下：
http://host[":"port][abs_path]
http表示要經過HTTP協議來定位網絡資源；
host表示合法的Internet主機域名或者IP地址；
port指定一個端口號，爲空則使用缺省端口 80；
abs_path指定請求資源的URI；若是URL中沒有給出abs_path，那麼當它做爲請求URI時，必須以「/」的形式給出，一般這個工做瀏覽器自動幫咱們完成。

如：

一、輸入：www.guet.edu.cn
瀏覽器自動轉換成：http://www.guet.edu.cn/
二、http:192.168.0.116:8080/index.jsp

HTTP協議之請求

http請求由三部分組成，分別是：請求行、消息報頭、請求正文

Request 消息分爲3部分，第一部分叫請求行， 第二部分叫http header, 第三部分是body. header和body之間有個空行， 結構以下圖

請求行以一個方法符號開頭，以空格分開，後面跟着請求的URI和協議的版本，格式以下：

Method Request-URI HTTP-Version CRLF

其中 Method表示請求方法；Request-URI是一個統一資源標識符；HTTP-Version表示請求的HTTP協議版本；CRLF表示回車和換行（除了做爲結尾的CRLF外，不容許出現單獨的CR或LF字符）。

請求方法（全部方法全爲大寫）有多種，各個方法的解釋以下：

GET     請求獲取Request-URI所標識的資源
POST    在Request-URI所標識的資源後附加新的數據
HEAD    請求獲取由Request-URI所標識的資源的響應消息報頭
PUT     請求服務器存儲一個資源，並用Request-URI做爲其標識
DELETE  請求服務器刪除Request-URI所標識的資源
TRACE   請求服務器回送收到的請求信息，主要用於測試或診斷
CONNECT 保留未來使用
OPTIONS 請求查詢服務器的性能，或者查詢與資源相關的選項和需求

HEAD方法與GET方法幾乎是同樣的，對於HEAD請求的迴應部分來講，它的HTTP頭部中包含的信息與經過GET請求所獲得的信息是相同的。利用這個方法，沒必要傳輸整個資源內容，就能夠獲得Request-URI所標識的資源的信息。該方法經常使用於測試超連接的有效性，是否能夠訪問，以及最近是否更新。

應用：
GET方法：在瀏覽器的地址欄中輸入網址的方式訪問網頁時，瀏覽器採用GET方法向服務器獲取資源

POST方法要求被請求服務器接受附在請求後面的數據，經常使用於提交表單。

當使用的是"GET" 方法的時候， body是爲空的
好比咱們打開博客園首頁的request 以下

GET http://www.cnblogs.com/ HTTP/1.1
Host: www.cnblogs.com

咱們用Fiddler 捕捉一個博客園登陸的Request 而後分析下它的結構， 在Inspectors tab下以Raw的方式能夠看到完整的Request的消息，   以下圖

 

get和post：

根據HTTP規範，Get是向服務器發索取數據的一種請求（GET獲取信息是安全的和冪等的），而Post是向服務器提交數據的一種請求。

在HTML中：

相同點：均可（帶參數）以向服務器發送請求。GET和POST只是發送機制不一樣，嚴格是並不區分一個取一個發，但會根據狀況考慮哪一種方式更合適。

主要用於from表單的提交（html的默認提交方式爲get而不是post），以及ajax獲取數據。

不一樣點：

get是把參數數據隊列加到提交表單的ACTION屬性所指的URL中，值和表單內各個字段一一對應，在URL中能夠看到。post是經過HTTP post機制，將表單內各個字段與其內容放置在HTML BODY中一塊兒傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。
GET的URL會有長度上的限制，則POST的數據則能夠很是大。
POST比GET安全，由於數據在地址欄上不可見。
get請求需注意緩存問題,post請求不需擔憂這個問題。
post請求必須設置Content-Type值爲application/x-form-www-urlencoded
在客戶端使用get請求時,服務器端使用Request.QueryString來獲取參數,而客戶端使用post請求時,服務器端使用Request.Form來獲取參數.

建議：
一、get方式的安全性較Post方式要差些，包含機密信息的話，建議用Post數據提交方式；
二、在作數據查詢時，建議用Get方式；而在作數據添加、修改或刪除時，建議用Post方式，例如form中的內容；

不一樣點的解釋：

在HTTP中：

1. GET和POST與數據如何傳遞沒有關係

GET和POST是由HTTP協議定義的。在HTTP協議中，Method和Data（URL， Body， Header）是正交的兩個概念，也就是說，使用哪一個Method與應用層的數據如何傳輸是沒有相互關係的。

HTTP沒有要求，若是Method是POST數據就要放在BODY中。也沒有要求，若是Method是GET，數據（參數）就必定要放在URL中而不能放在BODY中。
這只是HTML標準對HTTP協議的用法的約定。

2. HTTP協議對GET和POST都沒有對長度的限制

HTTP協議明確地指出了，HTTP頭和Body都沒有長度的要求。而對於URL長度上的限制，有兩方面的緣由形成：

瀏覽器。聽說早期的瀏覽器會對URL長度作限制。聽說IE對URL長度會限制在2048個字符內。
服務器。URL長了，對服務器處理也是一種負擔。多數服務器出於安全、穩定方面的考慮，會給URL長度加限制。可是這個限制是針對全部HTTP請求的，與GET、POST沒有關係。

3.安全不安全和GET、POST沒有關係

並且，現代的Web Server都是支持GET中包含BODY這樣的請求。雖然這種請求不可能從瀏覽器發出，可是如今的Web Server又不是隻給瀏覽器用，已經徹底地超出了HTML服務器的範疇了。

HTTP協議之響應

在接收和解釋請求消息後，服務器返回一個HTTP響應消息。

HTTP響應也是由三個部分組成，分別是：狀態行、消息報頭、響應正文

第一部分叫request line, 第二部分叫request header，第三部分是body. header和body之間也有個空行，  結構以下圖

狀態行格式以下：

HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服務器HTTP協議的版本；Status-Code表示服務器發回的響應狀態代碼；Reason-Phrase表示狀態代碼的文本描述。
狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：

1xx：指示信息--表示請求已接收，繼續處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操做
4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現
5xx：服務器端錯誤--服務器未能實現合法的請求

常見狀態代碼、狀態描述、說明：

200 OK      //客戶端請求成功
400 Bad Request  //客戶端請求有語法錯誤，不能被服務器所理解
401 Unauthorized //請求未經受權，這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用
403 Forbidden  //服務器收到請求，可是拒絕提供服務
404 Not Found  //請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error //服務器發生不可預期的錯誤
503 Server Unavailable  //服務器當前不能處理客戶端的請求，一段時間後可能恢復正常
eg：HTTP/1.1 200 OK （CRLF）

 

咱們用Fiddler 捕捉一個博客園首頁的Response而後分析下它的結構， 在Inspectors tab下以Raw的方式能夠看到完整的Response的消息，   以下圖

HTTPS協議：

HTTPS應用了Netscape的安全套接字層（SSL）做爲HTTP應用層的子層。SSL協議位於TCP/IP協議與各類應用層協議之間，爲數據通信提供安全支持。SSL協議可分爲兩層： SSL記錄協議（SSL Record Protocol）：它創建在可靠的傳輸協議（如TCP）之上，爲高層協議提供數據封裝、壓縮、加密等基本功能的支持。 SSL握手協議（SSL Handshake Protocol）：它創建在SSL記錄協議之上，用於在實際的數據傳輸開始前，通信雙方進行身份認證、協商加密算法、交換加密密鑰等。

SSL協議通訊過程

(1) 瀏覽器發送一個鏈接請求給服務器;服務器將本身的證書(包含服務器公鑰S_PuKey)、對稱加密算法種類及其餘相關信息返回客戶端;
(2) 客戶端瀏覽器檢查服務器傳送到CA證書是否由本身信賴的CA中心簽發。如果，執行4步;不然，給客戶一個警告信息：詢問是否繼續訪問。
(3) 客戶端瀏覽器比較證書裏的信息，如證書有效期、服務器域名和公鑰S_PK，與服務器傳回的信息是否一致，若是一致，則瀏覽器完成對服務器的身份認證。
(4) 服務器要求客戶端發送客戶端證書(包含客戶端公鑰C_PuKey)、支持的對稱加密方案及其餘相關信息。收到後，服務器進行相同的身份認證，若沒有經過驗證，則拒絕鏈接;
(5) 服務器根據客戶端瀏覽器發送到密碼種類，選擇一種加密程度最高的方案，用客戶端公鑰C_PuKey加密後通知到瀏覽器;
(6) 客戶端經過私鑰C_PrKey解密後，得知服務器選擇的加密方案，並選擇一個通話密鑰key，接着用服務器公鑰S_PuKey加密後發送給服務器;
(7) 服務器接收到的瀏覽器傳送到消息，用私鑰S_PrKey解密，得到通話密鑰key。
(8) 接下來的數據傳輸都使用該對稱密鑰key進行加密。
上面所述的是雙向認證 SSL 協議的具體通信過程，服務器和用戶雙方必須都有證書。因而可知，SSL協議是經過非對稱密鑰機制保證雙方身份認證，並完成創建鏈接，在實際數據通訊時經過對稱密鑰機制保障數據安全性

 

https是一個安全通訊通道，它基於HTTP開發，用於在客戶計算機和服務器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來講它是HTTP的安全版。

兩者的區別：

協議基礎不一樣：Https在Http下加入了SSL層。http是超文本傳輸協議，信息是明文傳輸，https 則是具備安全性的ssl加密傳輸協議
通信方式不一樣：Https在數據通訊以前須要客戶端、服務器進行握手(身份認證)，創建鏈接後，傳輸數據通過加密，通訊端口443。
https協議須要到ca申請證書，通常免費證書不多，須要交費。
http的鏈接很簡單,是無狀態的

4.從實際上的數據應用來講http的過程

在前面客戶端和應用服務器創建TCP鏈接以後，就須要用http協議來傳送數據了，HTTP協議簡單來講，仍是請求，確認，鏈接。
整體就是C發送一個HTTP請求給S，S收到了這個http請求，而後返回給Chttp響應，而後C的中間件或者說瀏覽器把這些數據渲染成爲了網頁，展現在用戶面前。
第一：發送一個http請求給S，這個請求包括請求頭和請求內容：
request header：
包括了，1.請求的方法是POST/GET,請求的URL，http協議版本2.請求的數據，和編碼方式3是否有cookie和cooies，是否緩存等。
post和get請求方式的區別是，get把請求內容放在URL後面，可是URL長度有限制。而post是以表單的形勢，適合要輸入密碼之類的，由於不在URL中顯示，因此比較安全。
request body：
即請求的內容.
第二：S收到了http請求，而後根據請求頭，返回http響應。
response header:包括了1.cookies或者sessions2.狀態嗎3.內容大小等
response body：
即響應的內容，包括，JS什麼的。
第三，C收到了之後，就由瀏覽器完成一系列的渲染，包括執行JS腳本等。
這就是我所理解的webTCP,HTTP基礎知識，待續。。。。。

例如：

在上圖中，可清晰的看到客戶端瀏覽器（ip爲192.168.2.33）與服務器的交互過程：
1）No1：瀏覽器（192.168.2.33）向服務器（220.181.50.118）發出鏈接請求。此爲TCP三次握手第一步，此時從圖中能夠看出，爲SYN，seq:X （x=0）
2）No2：服務器（220.181.50.118）迴應了瀏覽器（192.168.2.33）的請求，並要求確認，此時爲：SYN，ACK，此時seq：y（y爲0），ACK：x+1（爲1）。此爲三次握手的第二步；
3）No3：瀏覽器（192.168.2.33）迴應了服務器（220.181.50.118）的確認，鏈接成功。爲：ACK，此時seq：x+1（爲1），ACK：y+1（爲1）。此爲三次握手的第三步；
4）No4：瀏覽器（192.168.2.33）發出一個頁面HTTP請求；
5）No5：服務器（220.181.50.118）確認；
6）No6：服務器（220.181.50.118）發送數據；
7）No7：客戶端瀏覽器（192.168.2.33）確認；
8）No14：客戶端（192.168.2.33）發出一個圖片HTTP請求；
9）No15：服務器（220.181.50.118）發送狀態響應碼200 OK
……

二.瀏覽器是怎樣渲染HTML的（渲染引擎，HTML解析）

1.渲染引擎

渲染引擎的職責是……渲染，也就是把請求的內容顯示到瀏覽器屏幕上。

默認狀況下渲染引擎能夠顯示HTML，XML文檔以及圖片。 經過插件（瀏覽器擴展）它能夠顯示其它類型文檔。好比使用PDF viewer插件顯示PDF文件。咱們專一渲染引擎的主要用途——顯示用CSS格式化的HTML與圖片。

各類渲染引擎
咱們提到的Firefox, Safari兩種瀏覽器構建於兩種渲染引擎之上：Firefox使用Gecko —— Mozilla自家的渲染引擎；Safari 和 Chrome 都使用 Webkit。

2.渲染引擎的基本工做流程

解析ＨＴＭＬ
構建ＤＯＭ樹
渲染樹構建
渲染樹佈局
繪製渲染樹

渲染引擎開始於從網絡層獲取請求內容，通常是不超過8Ｋ的數據塊。接下來就是渲染引擎的基本工做流程：

渲染引擎會解析ＨＴＭＬ文檔並把標籤轉換成內容樹中的ＤＯＭ節點。它會解析style元素和外部文件中的樣式數據。樣式數據和ＨＴＭＬ中的顯示控制將共同用來建立另外一棵樹——渲染樹。
渲染樹包含帶有顏色，尺寸等顯示屬性的矩形。這些矩形的順序與顯示順序一致。
渲染樹構建完成後就是」佈局」處理，也就是肯定每一個節點在屏幕上的確切顯示位置。 下一個步驟是」繪製」 —— 遍歷渲染樹並用ＵＩ後端層將每個節點繪製出來。
必定要理解這是一個緩慢的過程，爲了更好的用戶體驗，渲染引擎會嘗試儘快的把內容顯示出來。它不會等到全部ＨＴＭＬ都被解析完才建立並佈局渲染樹。它會在處理後續內容的同時把處理過的局部內容先展現出來。

主要流程示例

Webkit主要流程

 

Mozilla的Gecko渲染引擎主要流程

從上能夠看出，儘管Webkit與Gecko使用略微不一樣的術語，這個過程仍是基本相同的。
Gecko 裏把格式化好的可視元素稱作「幀樹」（Frame tree）。每一個元素就是一個幀（frame）。 Webkit 則使用」渲染樹」這個術語，渲染樹由」渲染對象」組成。Webkit 裏使用」layout」表示元素的佈局，Gecko則稱爲」Reflow」。Webkit使用」Attachment」來鏈接DOM節點與可視化信息以構建渲染樹。一個非語義上的小差異是Gecko在ＨＴＭＬ與ＤＯＭ樹之間有一個附加的層 ，稱做」content sink」，是建立ＤＯＭ對象的工廠。

3.解析

解析一個文檔意味着把它翻譯成有意義的結構以供代碼使用。解析的結果一般是一個表徵文檔的由節點組成的樹，稱爲解析樹或句法樹。

如下是編譯原理知識。這裏只做通常性介紹，爲下面的HTML解析打基礎。

語法

解析是基於文檔所遵循的語法規則——書寫所用的語言或格式——來進行的。每一種能夠解析的格式必須由肯定的語法與詞彙組成。這被稱之爲上下文無關語法。 人類語言並不是此種語言，因此不能用常規的解析技術來解析。
解析器——詞法分析器組合
解析器有兩個處理過程——詞法分析與句法分析。
詞法分析負責把輸入切分紅符號序列，符號是語言的詞彙——由該語言全部合法的單詞組成。
句法分析是對該語言句法法則的應用。
解析器一般把工做分給兩個組件——分詞程序負責把輸入切分紅合法符號序列，解析程序負責按照句法規則分析文檔結構和構建句法樹。詞法分析器知道如何過濾像空格，換行之類的無關字符。

從源文檔到解析樹（文檔，詞法分析，句法分析，解析樹）。
解析過程是交互式的。解析器一般會從詞法分析器獲取新符號並嘗試匹配句法規則。若是匹配成功，就在句法樹上建立相應的節點，並繼續從詞法分析器獲取下一個符號。若是沒有匹配的規則，解析器會內部保存這個符號，並繼續從詞法分析器獲取符號，直到內部保存的全部符號可以成功匹配一個規則。若是最終沒法匹配，解析器會拋出異常。這意味着文檔無效，含有句法錯誤。

轉換

多數狀況下解析樹並不是最終結果。解析常常是爲了從輸入文檔轉換成另一種格式。好比編譯器要把源碼編譯成機器碼，會首先解析成解析樹，再把解析樹轉換成機器碼。

編譯過程（源碼，解析，解析樹，轉換，機器碼）。

咱們說過常規解析器只能解析上下文無關語法的語言。這種語言的一個直覺的定義是它的句法能夠用BNF完整的表達。

解析器的類型
解析器有兩種基本類型——自上而下解析器和自下而上解析器。主觀上能夠認爲自上而下的解析器從上層句法結構開始嘗試匹配句法；自下而上的則從輸入開始，慢慢轉換成句法規則，從底層規則開始，直到上層規則所有匹配。

4.HTML解析器

ＨＴＭＬ解析器的工做是解析ＨＴＭＬ標記到解析樹。

HTML的定義使用DTD文件。這種格式用來定義SGML族語言，它包含對全部容許的元素的定義，包括它們的屬性和層級關係。如咱們前面所說，HTML DTD構不成上下文無關語法。
DTD有幾種不一樣類型。嚴格模式徹底尊守規範，但其它模式爲了向前兼容可能包含對早期瀏覽器所用標籤的支持。

DOM

解析器輸出的樹是由ＤＯＭ元素和屬性節點組成的。DOM的全稱爲：Document Object Model。它是ＨＴＭＬ文檔的對象化描述，也是ＨＴＭＬ元素與外界（如Javascript）的接口。
ＤＯＭ與標籤幾乎有着一一對應的關係，以下面的標籤
<html>
    <body>
        <p>
            Hello World
        </p>
        <div> <img src="example.png"/></div>
    </body>
</html>
會被轉換成如的ＤＯＭ樹：

與HTML同樣，DOM規範也由w3c組織制訂。
當咱們說樹中包含ＤＯＭ節點時，意思就是這個樹是由實現了ＤＯＭ接口的元素組成。這些實現包含了其它一些瀏覽器內部所需的屬性。

HTML解析

如咱們前面看到的，HTML沒法使用自上而下或自下而上的解析器來解析。
理由以下：
語言的寬容特色

瀏覽器須要對無效HTML提供容錯性的事實。
解析過程的反覆。一般解析過程當中源碼不會變化。但在HTML中，script標籤包含」document.write」時能夠添加內容，即解析過程實際上還會改變源碼。

瀏覽器建立了本身的解析器來解析HTML文檔。
HTML5規範裏對解析算法有具體的說明，解析由兩部分組成：分詞與構建樹。
分詞屬於詞法分析部分，它把輸入解析成符號序列。在HTML中符號就是開始標籤，結束標籤，屬性名稱和屬生值。
分詞器識別這些符號並將其送入樹構建者，而後繼續分析處理下一個符號，直到輸入結束。

HTML解析流程 (源自HTML5規範)

分詞算法

算法的輸出是HTML符號。算法能夠用狀態機來描述。 每個狀態從輸入流中消費一個或多個字符，並根據它們更新下一狀態。決策受當前符號狀態和樹的構建狀態影響。這意味着一樣的字符可能會產生不一樣的結果，取決於當前的狀態。用一個例子來看看它的原理。

基礎示例，分析下面的標籤:
<html>
    <body>
        Hello world
    </body>
</html>
初始狀態是」Data state」，當遇到」<「時狀態改成「Tag open state」。吃掉」a-z」字符組成的符號後產生了」Start tag token」，狀態變動爲「Tag name state」。咱們一直保持此狀態，直到遇到」>」。每一個字符都被追加到新的符號名上。在咱們的例子中，解出的符號就是」html」。

當碰到」>」時，當前符號完成，狀態改回「Data state」。」<body>」標籤將會以一樣的方式處理。如今」html」與」body」標籤都完成了，咱們回到「Data state」狀態。吃掉」H」（」Hello world」第一個字母）時會產生一個字符符號，直到碰到」</body>」的」<「符號，咱們就完成了一個字符符號」Hello world」。

如今咱們回到「Tag open state」狀態。吃掉下一個輸入」/」時會產生一個」end tag token」並變動爲「Tag name state」狀態。一樣，此狀態保持到咱們碰到」>」時。這時新標籤符號完成，咱們又回到「Data state」。一樣」</html>」也會被這樣處理。

樹的構建算法

當解析器被建立時，文檔對象也被建立了。在樹的構建過程當中DOM樹的根節點（Documen）將被修改，元素被添加到上面去。每一個分詞器完成的節點都會被樹構建器處理。規範中定義了每個符號與哪一個DOM對象相關。除了把元素添加到DOM樹外，它還會被添加到一個開放元素堆棧。這個堆棧用於糾正嵌套錯誤和標籤未關閉錯誤。這個算法也用狀態機描述，它的狀態叫作」insertion modes」。

讓咱們看看下面輸入的樹構建過程：
<html>
    <body>
        Hello world
    </body>
</html>
樹的構建過程當中，輸入就是分詞過程當中獲得的符號序列。第一個模式叫「initial mode」。接收 html 符號後會變成「before html」模式並從新處理此模式中的符號。這會建立一個HTMLHtmlElement元素並追加到根文檔節點。

而後狀態改變爲「before head」。咱們收到」body」時，會隱式建立一個HTMLHeadElement，儘管咱們沒有這個標籤，它也會被建立並添加到樹中。

如今咱們進入「in head」模式，而後是「after head」，Body會被從新處理，建立HTMLBodyElement元素並插入，而後進入「in body」模式。

字符符號」Hello world」收到後會建立一個」Text」節點，全部字符都被一一追加到上面。

收到body結束標籤後進入 「after body」 模式，收到html結束標籤後進入「after after body」模式。全部符號處理完後將終止解析。

解析結束後的動做

在這一階段瀏覽器會把文檔標記爲交互模式，並開始解析deferred模式的script。」deferred」意味着腳本應該在文檔解析完成後執行。腳本處理完成後將進入」complete」狀態，」load」事件發生。
HTML5規範中包含了完整的算法： http://www.w3.org/TR/html5/syntax.html#html-parser

瀏覽器的容錯

你永遠不會看到HTML頁面語法錯誤。瀏覽器會修正錯誤並繼續。

三.HTML頁面的加載總體流程

從瀏覽器地址欄的請求連接開始，瀏覽器經過DNS解析查到域名映射的IP地址，成功以後瀏覽器端向此IP地址取得鏈接，成功鏈接以後，瀏覽器端將請 求頭信息 經過HTTP協議向此IP地址所在服務器發起請求，服務器接受到請求以後等待處理，最後向瀏覽器端發回響應，此時在HTTP協議下，瀏覽器從服務器接收到 text/html類型的代碼，瀏覽器開始顯示此html，並獲取其中內嵌資源地址，而後瀏覽器再發起請求來獲取這些資源，並在瀏覽器的html中顯示。

用戶輸入網址（假設是個html頁面，而且是第一次訪問），瀏覽器向服務器發出請求，服務器返回html文件；
下載的順序是從上到下，渲染的順序也是從上到下，下載和渲染是同時進行的。
瀏覽器開始載入html代碼，發現<head>標籤內有一個<link>標籤引用外部CSS文件；
瀏覽器繼續載入html中<body>部分的代碼，而且CSS文件已經拿到手了，能夠開始渲染頁面了；
若是遇到語義解釋性的標籤嵌入文件（JS腳本，CSS樣式），下載過程會啓用單獨鏈接進行下載。而且在下載後進行解析，解析過程當中，中止頁面全部往下元素的下載，不能並行下載和解析。樣式表在下載完成後，將和之前下載的全部樣式表一塊兒進行解析，解析完成後，將對此前全部元素（含之前已經渲染的）從新進行渲染。js也不能並行下載和解析
瀏覽器繼續載入html中<body>部分的代碼，而且CSS文件已經拿到手了，能夠開始渲染頁面了；
瀏覽器在代碼中發現一個<img>標籤引用了一張圖片，向服務器發出請求。此時瀏覽器不會等到圖片下載完，而是繼續渲染後面的代碼；
服務器返回圖片文件，因爲圖片佔用了必定面積，影響了後面段落的排布，所以瀏覽器須要回過頭來從新渲染這部分代碼；
瀏覽器發現了一個包含一行Javascript代碼的<script>標籤，趕快運行它；
Javascript腳本執行了這條語句，它命令瀏覽器隱藏掉代碼中的某個<div> （style.display=」none」）。瀏覽器不得不從新渲染這部分代碼；
直到運行到</html>。
還沒完，經過操做頁面運行Javascript代碼，改變了DOM或樣式，瀏覽器從新來過，向服務器請求資源文件，從新渲染頁面。

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

完

轉載需註明轉載字樣，標註原做者和原博文地址。

更多閱讀：

http://jingyan.baidu.com/article/2fb0ba4048e15500f3ec5f7e.html

http://www.jellythink.com/archives/705

http://www.cnblogs.com/jtome/archive/2008/12/04/1347864.html

http://www.cnblogs.com/li0803/archive/2008/11/03/1324746.html

http://www.chinaz.com/news/2012/0509/250601.shtml

http://wenku.baidu.com/link?url=u9QspfeUFh2SDo8sa8k-_VCdEUP-7QFNYEaKTFi_94ZLowEcdUEgVNnl8Or4bfc2XMaM1wHHQ7ddW7StfFJhiRqi9uTmlX6TJIqpF0Uyqpq

http://kb.cnblogs.com/page/130970/