概述
1、在瀏覽器輸入輸入url；
2、域名解析，查找對應(yīng)的ip地址；
3、瀏覽器根據(jù) IP 地址與服務(wù)器建立 socket 連接；
4、瀏覽器與服務(wù)器通信： 瀏覽器請求，服務(wù)器處理請求；
5、瀏覽器與服務(wù)器斷開請求
1、在瀏覽器輸入url
url：統(tǒng)一資源定位器，用于定位互聯(lián)網(wǎng)上的資源。
2、域名解析查找對應(yīng)的ip地址
概念解釋
- ip地址：IP協(xié)議為互聯(lián)網(wǎng)上的每一個(gè)網(wǎng)絡(luò)和每一臺主機(jī)分配一個(gè)邏輯地址。IP地址如同門牌號碼，通過IP地址來確定每一臺主機(jī)的位置。服務(wù)器本質(zhì)也就是一臺主機(jī)，訪問服務(wù)器也必須要知道其所對應(yīng)的IP地址。
- 域名（DN）：全稱網(wǎng)域名稱，是由一串用點(diǎn)分割的名字組成的internet上某一臺計(jì)算機(jī)和計(jì)算機(jī)組的名稱，用在數(shù)據(jù)傳輸時(shí)標(biāo)識計(jì)算機(jī)的電子方位。因?yàn)镮P地址難記憶且不易輸入，所以用域名來代替純數(shù)字的IP地址。
- 網(wǎng)域名稱系統(tǒng)（DNS）：是因特網(wǎng)的一項(xiàng)核心服務(wù)，它作為可以將 域名和IP地址相互映射的一個(gè)分布式數(shù)據(jù)庫。DNS的作用就是把域名解析為相對應(yīng)的IP地址。
域名解析流程
1、瀏覽器緩存，瀏覽器會緩存DNS記錄一段時(shí)間；
2、系統(tǒng)緩存，從hosts文件中查找是否有該域名所對應(yīng)的IP；
3、前兩個(gè)過程無法解析時(shí)，就要用到我們網(wǎng)絡(luò)配置中的"DNS服務(wù)器地址"了。操作系統(tǒng)會把這個(gè)域名發(fā)送給這個(gè)LDNS，也就是本地區(qū)的域名服務(wù)器。大約80%的域名解析到這里就結(jié)束了，所以LDNS主要承擔(dān)了域名的解析工作。
4、如果都沒有找到，則向根域名服務(wù)器查找域名對應(yīng) IP，根域名服務(wù)器把請求轉(zhuǎn)發(fā)到下一級。Name Server域名服務(wù)器會查詢存儲的域名和IP的映射關(guān)系表，在正常情況下都根據(jù)域名得到目標(biāo)IP地址，連同一個(gè)TTL值返回給DNS Server域名服務(wù)器，返回該域名對應(yīng)的IP和TTL值，LDNS會緩存這個(gè)域名和IP的對應(yīng)關(guān)系。把解析的結(jié)果返回給用戶，用戶根據(jù)TTL值緩存在本地系統(tǒng)緩存中，域名解析過程結(jié)束。
建立連接
知道了服務(wù)器的 IP 地址，下面便開始與服務(wù)器建立連接了。
TCP協(xié)議的三次握手：
- 主機(jī)向服務(wù)器發(fā)送一個(gè)建立連接的請求（您好，我想認(rèn)識您）；
- 服務(wù)器接到請求后發(fā)送同意連接的信號（好的，很高興認(rèn)識您）；
- 主機(jī)接到同意連接的信號后，再次向服務(wù)器發(fā)送了確認(rèn)信號（我也很高興認(rèn)識您），自此，主機(jī)與服務(wù)器兩者建立了連接。
TCP 協(xié)議：三次握手的過程采用 TCP 協(xié)議，其可以保證信息傳輸?shù)目煽啃?，三次握手過程中，若一方收不到確認(rèn)信號，協(xié)議會要求
重新發(fā)送信號。
網(wǎng)頁的請求與顯示
1、瀏覽器根據(jù)url生成http請求給到控制器；
2、從模型查找匹配控制器發(fā)來的請求返回給控制器得到數(shù)據(jù)。
3、控制器發(fā)送數(shù)據(jù)給視圖，視圖將數(shù)據(jù)組合成html文件反饋給控制器。
4、控制器將html文件發(fā)送給瀏覽器，在瀏覽器沒有完全接受html網(wǎng)頁前渲染、顯示網(wǎng)頁。
瀏覽器與服務(wù)器斷開鏈接-四次揮手
1、主機(jī)向服務(wù)器發(fā)送一個(gè)斷開連接的請求（不早了，我該走了）；
2、服務(wù)器接到請求后發(fā)送確認(rèn)收到請求的信號（知道了）；
3、服務(wù)器向主機(jī)發(fā)送斷開通知（我也該走了）；
4、主機(jī)接到斷開通知后斷開連接并反饋一個(gè)確認(rèn)信號（嗯，好的），服務(wù)器收到確認(rèn)信號后斷開連接；
補(bǔ)充：
- 為什么服務(wù)器在接到斷開請求時(shí)不立即同意斷開：當(dāng)服務(wù)器收到斷開連接的請求時(shí)，可能仍然有數(shù)據(jù)未發(fā)送完畢，所以服務(wù)器先發(fā)送確認(rèn)信號，等所有數(shù)據(jù)發(fā)送完畢后再同意斷開。
- 第四次握手后，主機(jī)發(fā)送確認(rèn)信號后并沒有立即斷開連接，而是等待了 2 個(gè)報(bào)文傳送周期，原因是：如果第四次握手的確認(rèn)信息丟失，服務(wù)器將會重新發(fā)送第三次握手的斷開連接的信號，而服務(wù)器發(fā)覺丟包與重新發(fā)送的斷開連接到達(dá)主機(jī)的時(shí)間正好為 2 個(gè)報(bào)文傳輸周期。
