摘要：從輸入到發送請求經歷了一些事情，今天我們來總結一下。在傳輸層有兩個性質不同的協議，分別是，傳輸控制協議和，用戶數據報協議網絡層網絡層用來處理在網絡上流動的數據包。

從輸入url到發送請求經歷了一些事情，今天我們來總結一下。 簡單來說，共有以下幾個過程

DNS域名解析
發起TCP連接
發送HTTP請求
服務器處理請求并返回HTTP報文
瀏覽器解析渲染頁面
連接結束

什么是域名解析

域名系統（英文：DomainNameSystem，縮寫：DNS）是互聯網的一項服務。它作為將域名和IP地址相互映射的一個分布式數據庫，能夠使人更方便地訪問互聯網

域名解析過程

系統會檢查瀏覽器緩存中有沒有這個域名對應的解析過的 IP 地址，如果緩存中有，這個解析過程就將結束。瀏覽器緩存是受這個域名的失效時間和緩存的空間大小控制的。
如果用戶的瀏覽器緩存中沒有，瀏覽器會查找操作系統緩存中即為本地的 Host 文件
路由器也可能會有緩存。
操作系統將域名發送至本地域名服務器， 本地域名服務器查詢自己的 DNS 緩存，查找成功則返回結果，失敗則發起一個迭代 DNS 解析請求

1、本地域名服務器 向 根域名服務器，其雖然沒有每個域名的的具體信息，但存儲了負責每個域，如 com、net、org等的解析的頂級域名服務器的地址）發起請求，此處，根域名服務器 返回 com 域的頂級域名服務器的地址；

2、本地域名服務器  向 com 域的頂級域名服務器發起請求，返回 baidu.com 域名服務器地址；

3、本地域名服務器向 baidu.com 域名服務器發起請求，得到 www.baidu.com 的 IP 地址；
本地域名服務器 將得到的 IP 地址返回給操作系統，同時自己也將 IP 地址緩存起來；
操作系統將 IP 地址返回給瀏覽器，同時自己也將 IP 地址緩存起來；
至此，瀏覽器已經得到了域名對應的 IP 地址。

TCP/IP 五層協議

應用層：決定向用戶提供應用服務時通信的活動。TCP/IP 協議族內預存了各類通用的應用服務。比如：FTP、DNS、HTTP 協議。
傳輸層：傳輸層對上層應用層，提供處于網絡連接中的兩臺計算機之間的數據傳輸。在傳輸層有兩個性質不同的協議，分別是 TCP (Transmission Control Protocol，傳輸控制協議) 和 UDP (User Data Protocol，用戶數據報協議)
網絡層：網絡層用來處理在網絡上流動的數據包。數據包是網絡傳輸的最小數據單位。該層規定了通過怎樣的路徑到達對方計算機，并把數據包傳送給對方。與對方計算機通過多臺計算機或網絡設備進行傳輸時，網絡層所起的作用就是在眾多的選項內選擇一條傳輸路線。
數據鏈路層: 在物理層提供比特流服務的基礎上，建立相鄰結點之間的數據鏈路，通過差錯控制提供數據幀 (Frame)在信道上無差錯的傳輸，并進行各電路上的動作系列。數據的單位稱為幀 (frame)
物理層：物理層建立在物理通信介質的基礎上，作為系統和通信介質的接口，用來實現數據鏈路實體間透明的比特 (bit) 流傳輸。只有該層為真實物理通信，其它各層為虛擬通信。

TCP協議

TCP協議全稱是傳輸控制協議是一種面向連接的、可靠的、基于字節流的傳輸層通信協議，由 IETF 的RFC 793定義。TCP 是面向連接的、可靠的流協議。流就是指不間斷的數據結構，你可以把它想象成排水管中的水流。

TCP連接過程（三次握手)

1、第一次握手：客戶端發送syn包(Seq=x)到服務器，并進入SYN_SEND狀態，等待服務器確認；
2、第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=x+1），同時自己也發送一個SYN包（Seq=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
3、第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=y+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。
握手過程中傳送的包里不包含數據，三次握手完畢后，客戶端與服務器才正式開始傳送數據。理想狀態下，TCP連接一旦建立，在通信雙方中的任何一方主動關閉連接之前，TCP 連接都將被一直保持下去。

為什么會采用三次握手，若采用二次握手可以嗎？ 四次呢？

建立連接的過程是利用客戶服務器模式，假設主機A為客戶端，主機B為服務器端。
采用三次握手是為了防止失效的連接請求報文段突然又傳送到主機B，因而產生錯誤。失效的連接請求報文段是指：主機A發出的連接請求沒有收到主機B的確認，于是經過一段時間后，主機A又重新向主機B發送連接請求，且建立成功，順序完成數據傳輸?？紤]這樣一種特殊情況，主機A第一次發送的連接請求并沒有丟失，而是因為網絡節點導致延遲達到主機B，主機B以為是主機A又發起的新連接，于是主機B同意連接，并向主機A發回確認，但是此時主機A根本不會理會，主機B就一直在等待主機A發送數據，導致主機B的資源浪費。

采用兩次握手不行，原因就是上面說的失效的連接請求的特殊情況。而在三次握手中， client和server都有一個發syn和收ack的過程， 雙方都是發后能收， 表明通信則準備工作OK.

為什么不是四次握手呢？ 大家應該知道通信中著名的藍軍紅軍約定， 這個例子說明， 通信不可能100%可靠， 而上面的三次握手已經做好了通信的準備工作， 再增加握手， 并不能顯著提高可靠性， 而且也沒有必要。

TCP協議的特點

面向連接

面向連接，是指發送數據之前必須在兩端建立連接。建立連接的方法是“三次握手”，這樣能建立可靠的連接。建立連接，是為數據的可靠傳輸打下了基礎。

僅支持單播傳輸

每條TCP傳輸連接只能有兩個端點，只能進行點對點的數據傳輸，不支持多播和廣播傳輸方式。

面向字節流

TCP不像UDP一樣那樣一個個報文獨立地傳輸，而是在不保留報文邊界的情況下以字節流方式進行傳輸。

可靠傳輸

對于可靠傳輸，判斷丟包，誤碼靠的是TCP的段編號以及確認號。TCP為了保證報文傳輸的可靠，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然后接收端實體對已成功收到的字節發回一個相應的確認(ACK)；如果發送端實體在合理的往返時延(RTT)內未收到確認，那么對應的數據（假設丟失了）將會被重傳。

提供擁塞控制

當網絡出現擁塞的時候，TCP能夠減小向網絡注入數據的速率和數量，緩解擁塞

TCP提供全雙工通信

TCP允許通信雙方的應用程序在任何時候都能發送數據，因為TCP連接的兩端都設有緩存，用來臨時存放雙向通信的數據。當然，TCP可以立即發送一個數據段，也可以緩存一段時間以便一次發送更多的數據段（最大的數據段大小取決于MSS）

UDP協議

UDP協議全稱是用戶數據報協議，在網絡中它與TCP協議一樣用于處理數據包，是一種無連接的協議。在OSI模型中，在第四層——傳輸層，處于IP協議的上一層。UDP有不提供數據包分組、組裝和不能對數據包進行排序的缺點，也就是說，當報文發送之后，是無法得知其是否安全完整到達的。

UDP協議的特點

面向無連接

首先 UDP 是不需要和 TCP一樣在發送數據前進行三次握手建立連接的，想發數據就可以開始發送了。并且也只是數據報文的搬運工，不會對數據報文進行任何拆分和拼接操作。具體來說就是：

在發送端，應用層將數據傳遞給傳輸層的 UDP 協議，UDP 只會給數據增加一個 UDP 頭標識下是 UDP 協議，然后就傳遞給網絡層了
在接收端，網絡層將數據傳遞給傳輸層，UDP 只去除 IP 報文頭就傳遞給應用層，不會任何拼接操作

有單播，多播，廣播的功能

UDP 不止支持一對一的傳輸方式，同樣支持一對多，多對多，多對一的方式，也就是說 UDP 提供了單播，多播，廣播的功能。

UDP是面向報文的

發送方的UDP對應用程序交下來的報文，在添加首部后就向下交付IP層。UDP對應用層交下來的報文，既不合并，也不拆分，而是保留這些報文的邊界。因此，應用程序必須選擇合適大小的報文

不可靠性

首先不可靠性體現在無連接上，通信都不需要建立連接，想發就發，這樣的情況肯定不可靠。
并且收到什么數據就傳遞什么數據，并且也不會備份數據，發送數據也不會關心對方是否已經正確接收到數據了。
再者網絡環境時好時壞，但是 UDP 因為沒有擁塞控制，一直會以恒定的速度發送數據。即使網絡條件不好，也不會對發送速率進行調整。這樣實現的弊端就是在網絡條件不好的情況下可能會導致丟包，但是優點也很明顯，在某些實時性要求高的場景（比如電話會議）就需要使用 UDP 而不是 TCP。UDP只會把想發的數據報文一股腦的丟給對方，并不在意數據有無安全完整到達。

頭部開銷小，傳輸數據報文時是很高效的。

UDP 頭部包含了以下幾個數據：

兩個十六位的端口號，分別為源端口（可選字段）和目標端口
整個數據報文的長度
整個數據報文的檢驗和（IPv4 可選 字段），該字段用于發現頭部信息和數據中的錯誤

TCP和UDP的比較

HTTP

HTTP（超文本傳輸協議） 是一種用于分布式、協作式和超媒體信息系統的應用層協議。HTTP 是互聯網數據通信的基礎。它是由萬維網協會（W3C）和互聯網工程任務組（IETF）進行協調制定了 HTTP 的標準，最終發布了一系列的 RFC，并且在1999年6月公布的 RFC 2616，定義了 HTTP 協議中現今廣泛使用的一個版本——HTTP 1.1。

HTTP 訪問過程

HTTP 屬于 TCP/IP 模型中的應用層協議，當瀏覽器與服務器進行互相通信時，需要先建立TCP 連接，之后服務器才會接收瀏覽器的請求信息，當接收到信息之后，服務器返回相應的信息。最后瀏覽器接受對服務器的信息應答后，對這些數據進行解釋執行（下圖http 1.0 請求模式）

HTTP 1.0 時，瀏覽器每次訪問都要多帶帶建立連接，這會造成資源的浪費。

后來HTTP 1.1管線化(pipelining)理論，客戶端可以同時發出多個HTTP請求，可以在一次連接中處理多個請求，并且將多個請求重疊進行

注意：這個pipelining僅僅是限于理論場景下，大部分桌面瀏覽器仍然會選擇默認關閉HTTP pipelining！

所以現在使用HTTP1.1協議的應用，都是有可能會開多個TCP連接的！

HTTP Pipelining其實是把多個HTTP請求放到一個TCP連接中一一發送，而在發送過程中不需要等待服務器對前一個請求的響應；只不過，客戶端還是要按照發送請求的順序來接收響應！

在HTTP1.0中，發送一次請求時，需要等待服務端響應了才可以繼續發送請求。

在HTTP1.1中，發送一次請求時，不需要等待服務端響應了就可以發送請求了，但是回送數據給客戶端的時候，客戶端還是需要按照響應的順序來一一接收

所以說，無論是HTTP1.0還是HTTP1.1提出了Pipelining理論，還是會出現阻塞的情況。從專業的名詞上說這種情況，叫做線頭阻塞（Head of line blocking）簡稱：HOLB

SPDY：HTTP1.x的優化

2012年google如一聲驚雷提出了SPDY的方案，優化了HTTP1.X的請求延遲，解決了HTTP1.X的安全性。具體如下：

降低延遲 針對HTTP高延遲的問題，SPDY優雅的采取了多路復用（multiplexing）。多路復用通過多個請求stream共享一個tcp連接的方式，解決了HOL blocking的問題，降低了延遲同時提高了帶寬的利用率。

請求優先級（request prioritization） 多路復用帶來一個新的問題是，在連接共享的基礎之上有可能會導致關鍵請求被阻塞。SPDY允許給每個request設置優先級，這樣重要的請求就會優先得到響應。比如瀏覽器加載首頁，首頁的html內容應該優先展示，之后才是各種靜態資源文件，腳本文件等加載，這樣可以保證用戶能第一時間看到網頁內容。

header壓縮 前面提到HTTP1.x的header很多時候都是重復多余的。選擇合適的壓縮算法可以減小包的大小和數量。

基于HTTPS的加密協議傳輸 大大提高了傳輸數據的可靠性

服務端推送（server push） 采用了SPDY的網頁，例如我的網頁有一個sytle.css的請求，在客戶端收到sytle.css數據的同時，服務端會將sytle.js的文件推送給客戶端，當客戶端再次嘗試獲取sytle.js時就可以直接從緩存中獲取到，不用再發請求了。SPDY構成圖：

HTTP2

HTTP/2（超文本傳輸協議第2版，最初命名為HTTP 2.0），是HTTP協議的的第二個主要版本，使用于萬維網。HTTP/2是HTTP協議自1999年HTTP 1.1發布后的首個更新，主要基于SPDY協議（是Google開發的基于TCP的應用層協議，用以最小化網絡延遲，提升網絡速度，優化用戶的網絡使用體驗）

HTTP2.0和SPDY的區別：

HTTP2.0 支持明文 HTTP 傳輸，而 SPDY 強制使用 HTTPS
HTTP2.0 消息頭的壓縮算法采用 HPACK http2.github.io/http2-spec/… SPDY 采用的 DEFLATE zh.wikipedia.org/wiki/DEFLAT…

HTTP1.0 、HTTP1.1和HTTP2.0的對比

HTTP 協議特點

簡單、快速、靈活：當用戶想服務器發送請求時，只需傳送請求方法和路徑即可，HTTP 允許傳輸任意類型的數據對象。并且HTTP協議簡單易用，HTTP 服務器規模小，保證了網絡通信的速度；
無連接、無狀態：HTTP協議限制每次連接只處理單個請求，當服務器收到用戶請求后就會斷開連接，保證了傳輸時間的節省。同時HTTP協議對事務處理沒有記憶能力，如果后續的請求需要使用前面的信息就必須重傳數據；
管線化和內容編碼：隨著管線化技術的出現，HTTP 請求比持久性連接速度更快，并且當某些報文的內容過大時，為了減少傳輸的時間，HTTP 會采取壓縮文件的方式；
HTTP 支持客戶/服務器模式

從 HTTP 到 HTTPS

HTTP 協議由于其簡單快速、占用資源少，一直被用于網站服務器和瀏覽器之間進行數據傳輸。但是在數據傳輸的過程中也存在很明顯的問題，由于 HTTP 是明文協議，不會對數據進行任何方式的加密。當黑客攻擊竊取了網站服務器和瀏覽器之間的傳輸報文的時，可以直接讀取傳輸的信息，造成網站、用戶資料的泄密。因此 HTTP 不適用于敏感信息的傳播，這個時候需要引入 HTTPS（超文本傳輸安全協議）。

HTTPS

HTTPS（Hypertext Transfer Protocol Secure ）是一種以計算機網絡安全通信為目的的傳輸協議。在HTTP下加入了SSL/TLS層，從而具有了保護交換數據隱私和完整性和提供對網站服務器身份認證的功能，簡單來說它就是安全版的 HTTP 。

HTTPS 訪問過程

HTTPS在進行數據傳輸之前會與網站服務器和Web瀏覽器進行一次握手，在握手時確定雙方的加密密碼信息。具體過程如下：

1、Web 瀏覽器將支持的加密信息發送給網站服務器
2、網站服務器會選擇出一套加密算法和哈希算法，將驗證身份的信息以證書（證書發布CA機構、證書有效期、公鑰、證書所有者、簽名等）的形式發送給Web瀏覽器；
3、當 Web 瀏覽器收到證書之后首先需要驗證證書的合法性，如果證書受到瀏覽器信任則在瀏覽器地址欄會有標志顯示，否則就會顯示不受信的標識。當證書受信之后，Web 瀏覽器會隨機生成一串密碼，并使用證書中的公鑰加密。之后就是使用約定好的哈希算法握手消息，并生成隨機數對消息進行加密，再將之前生成的信息發送給網站；
4、當網站服務器接收到瀏覽器發送過來的數據后，會使用網站本身的私鑰將信息解密確定密碼，然后通過密碼解密Web瀏覽器發送過來的握手信息，并驗證哈希是否與Web瀏覽器一致。然后服務器會使用密碼加密新的握手信息，發送給瀏覽器；
5、最后瀏覽器解密并計算經過哈希算法加密的握手消息，如果與服務發送過來的哈希一致，則此握手過程結束后，服務器與瀏覽器會使用之前瀏覽器生成的隨機密碼和對稱加密算法進行加密交換數據。

HTTPS 加密算法

為了保護數據的安全，HTTPS 運用了諸多加密算法：

1、對稱加密：有流式、分組兩種，加密和解密都是使用的同一個密鑰。

例如：DES、AES-GCM、ChaCha20-Poly1305 等。
2、非對稱加密：加密使用的密鑰和解密使用的密鑰是不相同的，分別稱為：公鑰、私鑰，公鑰和算法都是公開的，私鑰是保密的。非對稱加密算法性能較低，但是安全性超強，由于其加密特性，非對稱加密算法能加密的數據長度也是有限的。

例如：RSA、DSA、ECDSA、 DH、ECDHE 等。
3哈希算法：將任意長度的信息轉換為較短的固定長度的值，通常其長度要比信息小得多，且算法不可逆。

例如：MD5、SHA-1、SHA-2、SHA-256 等
4、數字簽名：簽名就是在信息的后面再加上一段內容（信息經過 hash 后的值），可以證明信息沒有被修改過。hash 值一般都會加密后（也就是簽名）再和信息一起發送，以保證這個 hash 值不被修改。

從 HTTPS 到 HSTS

但是當網站傳輸協議從 HTTP 到 HTTPS 之后，數據傳輸真的安全了嗎？

由于用戶習慣，通常準備訪問某個網站時，在瀏覽器中只會輸入一個域名，而不會在域名前面加上 http:// 或者 https://，而是由瀏覽器自動填充，當前所有瀏覽器默認填充的都是http://。一般情況網站管理員會采用了 301/302 跳轉的方式由 HTTP 跳轉到 HTTPS，但是這個過程總使用到 HTTP 因此容易發生劫持，受到第三方的攻擊。

這個時候就需要用到 HSTS（HTTP 嚴格安全傳輸）

HSTS

HSTS是國際互聯網工程組織 IETF 正在推行一種新的 Web 安全協議，網站采用 HSTS 后，用戶訪問時無需手動在地址欄中輸入 HTTPS，瀏覽器會自動采用 HTTPS 訪問網站地址，從而保證用戶始終訪問到網站的加密鏈接，保護數據傳輸安全。

HSTS原理

HSTS 主要是通過服務器發送響應頭的方式來控制瀏覽器操作：

1、首先在服務器響應頭中添加 HSTS 響應頭： Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload] 此響應頭只有在 https 訪問返回時才生效，其中[ ]中的參數表示可選 2、設置 max-age 參數，時間設置不宜過長，建議設置時間為 6 個月；

3、當用戶下次使用 HTTP 訪問，客戶端就會進行內部跳轉，并且能夠看到 307 Redirect Internel 的響應碼；

4、網站服務器變成了 HTTPS 訪問源服務器。

開啟 HSTS 后網站可以有效防范中間人的攻擊，同時也會省去網站 301/302 跳轉花費的時間，大大提升安全系數和用戶體驗。

發送 HTTP 請求

發送HTTP請求的過程就是構建HTTP請求報文并通過TCP協議中發送到服務器指定端口 請求報文由請求行，請求頭，請求體組成

請求行（Request Line）分為三個部分：請求方法、請求地址和協議及版本，以CRLF(rn)結束。 HTTP/1.1 定義的請求方法有8種：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE,最常的兩種GET和POST，如果是RESTful接口的話一般會用到GET、POST、DELETE、PUT。

請求頭

HTTP代理原理

普通代理

HTTP 客戶端向代理發送請求報文，代理服務器需要正確地處理請求和連接（例如正確處理 Connection: keep-alive），同時向服務器發送請求，并將收到的響應轉發給客戶端。

客戶端通過代理訪問 A 網站，對于 A 來說，它會把代理當做客戶端，完全察覺不到真正客戶端的存在，這實現了隱藏客戶端 IP 的目的。當然代理也可以修改 HTTP 請求頭部，通過 X-Forwarded-IP 這樣的自定義頭部告訴服務端真正的客戶端 IP。但服務器無法驗證這個自定義頭部真的是由代理添加，還是客戶端修改了請求頭，所以從 HTTP 頭部字段獲取 IP 時，需要格外小心。
對于客戶端來說，實際上訪問的是代理，代理收到請求報文后，再向真正提供服務的服務器發起請求，并將響應轉發給瀏覽器。這種情況一般被稱之為反向代理，它可以用來隱藏服務器 IP 及端口。一般使用反向代理后，需要通過修改 DNS 讓域名解析到代理服務器 IP，這時瀏覽器無法察覺到真正服務器的存在，當然也就不需要修改配置了。反向代理是 Web 系統最為常見的一種部署方式。

隧道代理

HTTP 客戶端通過 CONNECT 方法請求隧道代理創建一條到達任意目的服務器和端口的 TCP 連接，并對客戶端和服務器之間的后繼數據進行盲轉發。

客戶端通過代理訪問 A 網站，瀏覽器首先通過 CONNECT 請求，讓代理創建一條到 A 網站的 TCP 連接；一旦 TCP 連接建好，代理無腦轉發后續流量即可。所以這種代理，理論上適用于任意基于 TCP 的應用層協議，HTTPS 網站使用的 TLS 協議當然也可以。這也是這種代理為什么被稱為隧道的原因。對于 HTTPS 來說，客戶端透過代理直接跟服務端進行 TLS 握手協商密鑰，所以依然是安全的