前言
上次說到 HTTP基礎 概念相關的問題，這次非常簡單的講解一道超高頻率的面試題。
在瀏覽器輸入
url到頁面展示的過程 ,我主要從網(wǎng)絡相關的層面去講一下。
當你輸入了 https://www.baidu.com 到頁面顯示出來一共發(fā)生了什么？
解析url
首先這個過程肯定是需要涉及到 「 客戶端跟服務端的數(shù)據(jù)傳輸 」 的，數(shù)據(jù)傳輸?shù)那疤峋褪?「 雙方建立連接 」 ，那么這個建立連接的過程是如何建立的呢？
當你敲上網(wǎng)址然后敲了回車之后，瀏覽器就會開始解析這個域名了，其實解析域名最主要的就是 「 把
url網(wǎng)址解析成對應的服務器的IP地址 」 ，而解析成地址的方式有很多種，這里從最外層的瀏覽器一直到路由器再到dns服務器都有。具體流程的話有：
- 檢查瀏覽器緩存中是否緩存過該域名對應的IP地址
- 查看host文件有沒有跟域名對應的規(guī)則（本地主機host文件中一般會存儲經(jīng)常訪問的url到host文件中）。
- 查看路由器里面有沒有緩存。
- 最后才發(fā)出DNS請求到本地DNS(域名分布系統(tǒng))服務器 。本地DNS服務器一般都是你的網(wǎng)絡接入服務器商提供，比如中國電信，中國移動。
建立tcp連接
為什么要建立tcp連接呢？主要就是為了保證兩端能夠進行 「 可靠的傳輸 」 ，可靠的傳輸?shù)幕荆褪莾啥藢?shù)據(jù)的發(fā)送和接收的功能。
ssl / tls 證書
ssl / tls 是什么？大白話來說一下，在我們中國，身份證就是我們個人的專屬身份的標志，同理，在網(wǎng)絡中，為了確定連接那頭的人是不是你要找的人，就會有一個大型的網(wǎng)上認證系統(tǒng)，ssl / tls 其實就是每個人自己服務器的
身份證， 確認了建立連接對面的人是你要的那個人，就是通過 ssl / tls 這個證書來確認的。
所以由于http的 「 明文傳輸 」 ，導致了一次普通的沒有
身份證的http的調(diào)用其實是不不夠安全的，有可能會被惡意修改數(shù)據(jù)或者是截取信息，這個時候https來了，它主要就是通過 ssl / tls 提供驗證服務端的身份，加密處理數(shù)據(jù)等等，只要服務端提前在ca機構注冊好自己的身份證， 就可以做到保證兩端身份的確定性，就進行可靠安全的傳輸了。這里的話不細講具體是如何加密的，簡單說一下流程。
- 客戶端向服務端請求連接，請求頭里面包含了客戶端支持的加密解密類型等等。
- 服務端根據(jù)客戶端可接受的加密類型中，選擇最合適自己的那一個，加密自己的私鑰，并且存在證書里面，連同 「 證書 」 一起發(fā)給客戶端。
- 客戶端收到證書之后，首先向權威 「 ca機構 」 驗證證書的有效性，確認了服務端的身份后，將自己用來對稱加密的公鑰用證書返回的公鑰加密，發(fā)送給服務端。
總的來說，就是確定了雙方同時持有對稱加密使用的公鑰，就可以安全的進行傳輸了。
這里補充一下，假如服務端申請了客戶端未信任的證書機構的話（也有可能自己制作ssl證書），客戶端需要信任（或者直接拒絕訪問了），而且自制的ssl證書容易被偽造的，不咋安全（畢竟沒收到國際認證和電子簽發(fā)許可），所以這也是一種可能被釣魚的情況之一。
三次握手
三次握手的主要目的，就是確定 「 雙方同時具備正常的收和發(fā)功能 」 的功能，需要站在客戶端和服務端的角度來看這個為什么需要三次握手的問題，接下來說一下流程：
- 客戶端發(fā)送連接請求 「 你好服務器兄弟聽得到嗎 」 給服務端，服務端收到。
「 服務端的角度 」
服務端的角度：我服務端收到了客戶端的消息，所以服務端是知道客戶端的發(fā)是正常的，服務端自己的收也是正常的。
| 客戶端 | 服務端 | |
|---|---|---|
| 收 | X | 正常 |
| 發(fā) | 正常 | X |
「 客戶端的角度 」
客戶端的角度：不清楚自己發(fā)出去的服務端收到?jīng)]，也不清楚自己能不能收到服務端的消息。
| 客戶端 | 服務端 | |
|---|---|---|
| 收 | X | X |
| 發(fā) | X | X |
- 服務端發(fā)送 「 聽得到啊，客戶端兄弟聽得到嗎 」 給客戶端，客戶端收到了。
「 服務端的角度 」
服務端的角度:是只能確認自己的收是正常的，但是不確定客戶端有沒有收到自己發(fā)出去的東西。
| 客戶端 | 服務端 | |
|---|---|---|
| 收 | X | 正常 |
| 發(fā) | 正常 | X |
「 客戶端的角度 」
客戶端的角度:客戶端是已經(jīng)可以確認，客戶端的收發(fā)的功能都是正常的，服務端的收發(fā)功能也是正常的。（此時客戶端的角度已經(jīng)確認好了）。
| 客戶端 | 服務端 | |
|---|---|---|
| 收 | 正常 | 正常 |
| 發(fā) | 正常 | 正常 |
- 客戶端發(fā)送 「 我也聽得到 」 給服務端。
這個時候服務端才知道，客戶端收到了，所以就確認了自己可以發(fā)數(shù)據(jù)給客戶端。（此時服務端的角度也確認好了）。
總的來說，照著 「 確定雙方同時具備收和發(fā)的功能 」 這個思路說下去，三次握手就很好理解了。
「 服務端的角度 」
| 客戶端 | 服務端 | |
|---|---|---|
| 收 | 正常 | 正常 |
| 發(fā) | 正常 | 正常 |
「 客戶端的角度 」
| 客戶端 | 服務端 | |
|---|---|---|
| 收 | 正常 | 正常 |
| 發(fā) | 正常 | 正常 |
數(shù)據(jù)傳輸。
連接建立后自然就是發(fā)送數(shù)據(jù)了，這時候客戶端也就可以發(fā)送請求給服務端了，服務端收到對應的請求，（可能有代理）找到自己的對應的服務對應的端口去做相應的處理，并反回數(shù)據(jù)給客戶端（tcp的擁塞機制）。
四次揮手
四次揮手 「 連接終止協(xié)議 」 ，這個很好理解，主要就是確認雙方都沒有數(shù)據(jù)發(fā)送了。
為什么要四次揮手? 主要就是因為上面說到的三次握手，建立的連接是去確定雙方同時具備收和發(fā)的功能來建立的一個通道，那么關閉這個通道肯定也是要雙方去確認的，所以我們可以按照這個思路往下去整理。
- 當客戶端發(fā)起所有需要的請求后，決定關閉連接了，他向服務器發(fā)送了一個 「 我已經(jīng)沒啥要的了 」 。
- 服務器收到后，要給客戶端返回一個 「 收到 」。
其實這樣的話是存在服務器數(shù)據(jù)還沒發(fā)完數(shù)據(jù)的情況的，所以上面的兩次揮手的主要作用只是斷開了客戶端的發(fā)，但服務器還是可以繼續(xù)傳輸沒傳輸完的數(shù)據(jù)。
- 當服務器發(fā)送完所有之后，決定關閉連接了，他向客戶端發(fā)送了一個 「 我也把東西都發(fā)完給你了 」。
- 完了客戶端也要回復一個 「 收到 」。
到此四次揮手就結束了，這里補充一張四次揮手的圖給大家參悟一下。
最后
關于https相關流程可以看看 HTTPS原理及流程。
PS
都結合網(wǎng)上資料加上自己的一些理解，如果有影響到人的地方，可以聯(lián)系我：fzfz2007@163.com
