用戶在瀏覽器輸入URL回車以後，瀏覽器都作了什麼

在直接列出執行的步驟以前先來普及幾個知識，相信瞭解完這些知識以後會對先後端的交互有更深刻的理解。

一、TCP鏈接

TCP：Transmission Control Protocol， 傳輸控制協議，是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議。
說的這麼專業，有啥用呢？
先來舉個栗子吧
還記得小時候咱們作的紙杯電話麼？兩個紙杯用一條繩子連到一塊兒，兩個各拿一個紙杯把線拉直，一個對着紙杯講，一個用耳朵對着紙杯聽。

這其實就是一種最簡單的鏈接通訊，兩人經過一根線鏈接起來，聲音從這邊的紙杯發出經過線傳輸到另外一個紙杯接收，擴展到如今家家戶戶都有的固定電話也是如此，它的通訊也是創建在雙方可接受而且信任的基礎上進行，如：

1. A拿起電話，撥通0775-6532122，開始呼叫B
2. B聽到電話聲響起，拿起電話，此時A收到B已經拿起電話的聲音
3. 雙方開始講話

回到咱們的tcp協議，其實它和上面所說的電話協議差很少，只不過電話的協議是服務於電話通訊，而tcp是服務於網絡通信的一種協議，相似的，通信雙方創建一次tcp鏈接，也須要通過三個步驟（握手）。

1. 客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認。
2. 服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態。
3. 客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。

上面的字母意思以下：

SYN:synchronous   創建聯機
ACK:acknowledgement  確認
SYN_SENT:請求鏈接  
SYN_RECV:服務端被動打開後,接收到了客戶端的SYN而且發送了ACK時的狀態。再進一步接收到客戶端的ACK就進入ESTABLISHED狀態。

值得注意的是：tcp在握手過程當中並不攜帶數據，(就像你打電話給酒店訂房時，在確認對方是酒店客服人員以前，你也不會立刻把身份證號碼報給他吧？)，而是在三次握手完成以後，纔會進行數據傳送。

至於它的應用場景，實際上是根據它自己的特色而定的，好比對網絡通信質量有要求，須要保證數據準確性時，就須要用到TCP協議了，如HTTP、ftp等文件傳輸協議、或一些郵件傳輸協議（SMTP、pop等）

二、UDP鏈接

UDP ：User Datagram Protocol 用戶數據報協議
相比於TCP的面向鏈接須要反覆確認的繁瑣步驟，UDP是一中性格特立獨行而且主觀性超強的非面向鏈接的協議，使用udp協議常常通訊並不須要創建鏈接，它只是負責把數據儘量快的發送出去，簡單粗暴，而且不可靠，而在接收端，UDP把每一個消息斷放入隊列中，接收端程序從隊列中讀取數據。

有人會說，UDP協議這麼不可靠，爲啥還會造出來呢？

話說回來，天底下沒有無用之人，只有你不懂用的人而已，雖然UDP不可靠，可是它的傳輸速度快，效率高，在一些對數據準確性要求不高的場景，UDP就變得頗有用了，好比qq語音、qq視頻。

三、嵌套字Socket

爲何要說嵌套字？
那是由於就像前面說的，TCP或UDP都是一種協議，也就是計算機網絡通訊中在傳輸層的一種協議，簡單地說，就是一種約定，就像合做雙方的合同同樣，而後合同是死的，只有履行合同纔是實質性的行動，所以不管是TCP仍是UDP要產生做用，都須要有實際的行爲去執行才能體現協議的做用，
那麼，有什麼辦法讓這些協議做用呢？
這就要說到socket了。

socket：也叫嵌套字 ，是一組實現TCP/UDP通訊的接口API，也就是說不管TCP仍是UDP，經過對scoket的編程，均可以實現TCP/UCP通訊，做爲一個通訊鏈的句柄，它包含網絡通訊必備的5種信息：

1. 鏈接使用的協議
2. 本地主機的IP地址
3. 本地進程的協議端口
4. 遠地主機的IP地址
5. 遠地進程的協議端口

可見，socket包含了通訊本方和對方的ip和端口以及鏈接使用的協議（TCP/UDP）。通訊雙方中的一方（暫稱：客戶端）經過scoket（嵌套字）對另外一方（暫稱：服務端）發起鏈接請求，服務端在網絡上監聽請求，當收到客戶端發來的請求以後，根據socket裏攜帶的信息，定位到客戶端，就相應請求，把socket描述發給客戶端，雙方確認以後鏈接就創建了。
所以套接字之間的鏈接過程有三個步驟：

1. 服務器監聽:服務器實時監控網絡狀態等待客戶端發來的鏈接請求
2. 客戶端請求:客戶端根據遠程主機服務器的IP地址和協議端口向其發起鏈接請求
3. 鏈接確認:服務端收到套接字的鏈接請求以後，就響應請求，把服務端套接字描述發給客戶端，客戶端收到後一旦確認，則雙方創建鏈接，進行數據交互。

一般狀況下socket鏈接就是TCP鏈接，所以socket鏈接一旦創建,通信雙方開始互發數據進行通訊，直到其中一方或雙方斷開鏈接爲止。

socket在即時通信（qq等各類聊天軟件）等應用上應用普遍。

四、HTTP協議

HTTP協議：Hypertext Transfer Protocol 也叫超文本傳送協議 ，它是一種基於TCP/IP協議棧、在表示層和應用層上的協議（TCP在傳輸層的協議），通俗一點說就是：

• TCP/IP是位於傳輸層上的一種協議，用於在網絡中傳輸數據；
• HTTP協議是應用層協議，基於TCP協議，用於包裝數據，程序使用它進行通訊，能夠簡單高效的處理通訊中數據的傳輸和識別處理

而在如今應用很是普遍的HTTP鏈接則是創建在HTTP協議上的、處於應用層中的一種具體應用。
上面說到socket鏈接一旦創建就保持鏈接狀態，而HTTP鏈接則不同，它基於tcp協議的短鏈接，也就是客戶端發起請求，服務器響應請求以後，鏈接就會自動斷開，不會一直保持。

五、URL

前面講了tcp、udp、http…等等都是爲了講一個具體問題而作的知識點鋪墊，那就是：咱們開發的web應用中請求的發起和響應，是一個怎樣的底層原理。
咱們都知道，web應用絕大部分都是經過HTTP來進行請求的，而URL則是HTTP用來作鏈接創建和傳輸數據的一種具體實現，所以在此要簡單講一下URL。

URL：Uniform Resource Locator 統一資源定位符。說白了就是網絡上用來標識具體資源的一個地址，包含了用戶查找該資源的信息，HTTP使用它來傳輸數據和創建鏈接
一個URL有如下組成部分：

1. 協議
2. 服務器地址（域名或IP+端口）
3. 路徑
4. 文件名

好比：https://www.baidu.com/index.html
其中

• https://是一種協議 固然，HTTP也是 ftp也是…
• www.baidu.com是服務器地址，固然你知道百度的IP也能夠,例如我用ping命令獲得百度的ip14.215.177.39，那麼我能夠用http://14.215.177.39打開百度
• index.html包含了路徑和文件名，固然一般index.html是能夠省略的，因此你打開百度時，並無看到這個。

六、DNS

DNS:Domain Name Server，域名服務器。
是進行域名(domain name)和與之相對應的IP地址 (IP address)轉換的服務器。DNS中保存了一張域名(domain name)和與之相對應的IP地址 (IP address)的表，以解析消息的域名。
在平時咱們進行開發時，後端提供的接口地址一般是有IP地址加上端口號（8080什麼鬼的）組成的，可是當咱們把網站發佈出去時，一般都須要把IP改爲用域名。
爲何呢？
你想一想哦，好比谷歌的地址是89.12.21.221:9090,百度的地址是132.21.33.221:8766。。。
這麼一看你根本沒有慾望是記住這些亂七八糟的數字吧？
可是域名就不同了，好比谷歌的google.com，百度的baidu.com 是否是一遍就記住了呢？
因此爲了處理這個問題，就須要用域名去映射IP地址，達到易記易用的目的。

所以，當用戶在瀏覽器輸入https://www.baidu.com回車時，它經歷瞭如下步驟：

1. 瀏覽器根據地址去自己緩存中查找dns解析記錄，若是有，則直接返回IP地址，不然瀏覽器會查找操做系統中（hosts文件）是否有該域名的dns解析記錄，若是有則返回。
2. 若是瀏覽器緩存和操做系統hosts中均無該域名的dns解析記錄，或者已通過期，此時就會向域名服務器發起請求來解析這個域名。
3. 請求會先到LDNS（本地域名服務器），讓它來嘗試解析這個域名，若是LDNS也解析不了，則直接到根域名解析器請求解析
4. 根域名服務器給LDNS返回一個所查詢餘的主域名服務器（gTLDServer）地址。
5. 此時LDNS再向上一步返回的gTLD服務器發起解析請求。
6. gTLD服務器接收到解析請求後查找並返回此域名對應的Name Server域名服務器的地址，這個Name Server一般就是你註冊的域名服務器（好比阿里dns、騰訊dns等）
7. Name Server域名服務器會查詢存儲的域名和IP的映射關係表，正常狀況下都根據域名獲得目標IP記錄，連同一個TTL值返回給DNS Server域名服務器
8. 返回該域名對應的IP和TTL值，Local DNS Server會緩存這個域名和IP的對應關係，緩存的時間有TTL值控制。
9. 把解析的結果返回給用戶，用戶根據TTL值緩存在本地系統緩存中，域名解析過程結束。

七、HTTP請求發起和響應

在一個web程序開發中，通常都有前端和後端之分，前端負責向後端請求數據和展現頁面，後端負責接收請求和作出響應發回給前端，他們之間的協做的橋樑是什麼呢？
是API
API是什麼？不就是一個URL嗎？
URL又是啥呢？上面說到就是HTTP鏈接的一種具體的載體
所以，
不管對於前端或者是後端，理解HTTP，不管是對自身對編程的理解，仍是和同事協做，都是好處大大的，
下面，根據上面各個知識點的理解，咱們來整理一下並解決一下上面提到的第一個問題：
從用戶輸入URL，到瀏覽器呈現給用戶頁面，通過了什麼過程

1. 用戶輸入URL，瀏覽器獲取到URL
2. 瀏覽器(應用層)進行DNS解析（若是輸入的是IP地址，此步驟省略）
3. 根據解析出的IP地址+端口，瀏覽器（應用層）發起HTTP請求，請求中攜帶（請求頭header（也可細分爲請求行和請求頭）、請求體body）；header包含：（1）請求的方法（get、post、put..）（2）協議（http、https、ftp、sftp…）（3）目標url（具體的請求路徑已經文件名）（4）一些必要信息（緩存、cookie之類）body包含：請求的內容
4. 請求到達傳輸層，tcp協議爲傳輸報文提供可靠的字節流傳輸服務，它經過三次握手等手段來保證傳輸過程當中的安全可靠。經過對大塊數據的分割成一個個報文段的方式提供給大量數據的便攜傳輸。
5. 到網絡層， 網絡層經過ARP尋址獲得接收方的Mac地址，IP協議把在傳輸層被分割成一個個數據包傳送接收方。
6. 數據到達數據鏈路層，請求階段完成
7. 接收方在數據鏈路層收到數據包以後，層層傳遞到應用層，接收方應用程序就得到到請求報文。
8. 接收方收到發送方的HTTP請求以後，進行請求文件資源（如HTML頁面）的尋找並響應報文
9. 發送方收到響應報文後，若是報文中的狀態碼錶示請求成功，則接受返回的資源（如HTML文件），進行頁面渲染。

 

文章轉自：https://mp.weixin.qq.com/s/G8cx8G-VhUtC6XA1PIysCg，感謝做者