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雙放在各電路上的動作系列。 |
屬於物理層定義的典型規范代表包括：EIA/TIA RS-232、EIA/TIA RS-449、V.35、RJ-45等。 |
| 第二層：數據鏈路層（DataLinkLayer) | 在物理層提供比特流服務的基礎上，建立相鄰結點之間的數據鏈路，通過差錯控制提供數據幀（Frame）在信道上無差錯的傳輸，並進行各電路上的動作系列。 |
數據鏈路層協議的代表包括：SDLC、HDLC、PPP、STP、幀中繼等。 |
| 第三層是網絡層(Network layer) | 在計算機網絡中進行通信的兩個計算機之間可能會經過很多個數據鏈路，也可能還要經過很多通信子網。網絡層的任務就是選擇合適的網間路由和交換結點， 確保數據及時傳送。網絡層將數據鏈路層提供的幀組成數據包，包中封裝有網絡層包頭，其中含有邏輯地址信息- -源站點和目的站點地址的網絡地址。 如果你在談論一個IP地址，那么你是在處理第3層的問題，這是“數據包”問題，而不是第2層的“幀”。IP是第3層問題的一部分，此外還有一些路由協議和地址解析協議（ARP）。有關路由的一切事情都在第3層處理。地址解析和路由是3層的重要目的。網絡層還可以實現擁塞控制、網際互連等功能。 |
網絡層協議的代表包括：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報文。
1、 客戶端的最后一個ACK報文在傳輸的時候丟失，服務器並沒有接收到這個報文。這個候。
服務器就會超時重傳這個FIN消息，然后客戶端就會重新返回最后一個ACK報文，等待兩個時間周期，完成關閉。如果不等待這兩個時間周期，服務器重傳的那條消息就不會收到。服務器就因為接收不到客戶端的信息而無法正常關閉。
2、 預防上一次在三次握手中提到的失效的報文干擾。兩個時間周期過去之后，所有的報文都會在網絡中消失，保證下一次重新連接的時候有亂七八糟的報文影響。
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時，必須以“/”的形式給出，通常這個工作瀏覽器自動幫我們完成。
如：
1、輸入：www.guet.edu.cn
瀏覽器自動轉換成：http://www.guet.edu.cn/
2、http:192.168.0.116:8080/index.jsp
HTTP協議之請求
http請求由三部分組成，分別是：請求行、消息報頭、請求正文
Request 消息分為3部分，第一部分叫請求行， 第二部分叫http header, 第三部分是body. header和body之間有個空行， 結構如下圖
請求行以一個方法符號開頭，以空格分開，后面跟着請求的URI和協議的版本，格式如下：
Method Request-URI HTTP-Version CRLF
請求方法（所有方法全為大寫）有多種，各個方法的解釋如下：
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
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來獲取參數.
建議：
1、get方式的安全性較Post方式要差些，包含機密信息的話，建議用Post數據提交方式；
2、在做數據查詢時，建議用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