DNS 解析域名

什么是 DNS

我們?cè)L問(wèn)網(wǎng)站的時(shí)候會(huì)輸入域名，而在真實(shí)網(wǎng)絡(luò)中主機(jī)通信是通過(guò) IP 地址進(jìn)行通信的，DNS 服務(wù)器的作用就是將這域名字符串解析為對(duì)應(yīng)的 IP 地址

有哪些 DNS 服務(wù)器

如果說(shuō)每輸入一個(gè)域名都需要去一個(gè) DNS 服務(wù)器解析的話，全世界這么高的訪問(wèn)量，肯定是無(wú)法承載的，所以會(huì)對(duì) DNS 服務(wù)器進(jìn)行按層分級(jí)，不同類型的 DNS 服務(wù)器負(fù)責(zé)解析不同的域名

本地 DNS 緩存：電腦會(huì)將解析到的域名和 IP 地址等緩存到本地上，windows 可以通過(guò) ipconfig /displaydns 查看

本地 DNS 服務(wù)器

如果電腦是自己設(shè)置了 DNS 那么本地 DNS 服務(wù)器就是這個(gè)地址

如果是根據(jù)路由器 DHCP 自動(dòng)分配，那么本地 DNS 服務(wù)器就是路由器的 DNS 地址

路由器會(huì)將請(qǐng)求分發(fā)給上層的網(wǎng)絡(luò)服務(wù)提供商的 DNS

根域名服務(wù)器：根服務(wù)器主要用來(lái)管理互聯(lián)網(wǎng)的主目錄，它包含了頂級(jí)域名服務(wù)器的 IP 地址

.com 頂級(jí)域名服務(wù)器對(duì)應(yīng)的 IP 地址

.cn 頂級(jí)域名服務(wù)器對(duì)應(yīng)的 IP 地址

.net 頂級(jí)域名服務(wù)器對(duì)應(yīng)的 IP 地址

其它

頂級(jí)域名服務(wù)器：在它其中包含了權(quán)威域名的服務(wù)器的 IP 地址

權(quán)威域名服務(wù)器：返回域名對(duì)應(yīng)的目標(biāo)主機(jī) IP

DNS 解析流程

當(dāng)我們輸入 www.abc.com 域名的時(shí)候

首先去本地緩存中查找域名對(duì)應(yīng)的 IP 是否存在，如果存在則直接返回

如果不存在則去本地 DNS 服務(wù)器中查找，如果本地 DNS 服務(wù)器有則直接返回

如果本地 DNS 服務(wù)器中不存在則開(kāi)始遞歸查找

首先查找根域名服務(wù)器發(fā)現(xiàn)訪問(wèn)的是 .com 然后返回給本地 .com DNS 服務(wù)器對(duì)應(yīng)的 IP 地址

然后本地繼續(xù)去請(qǐng)求 .com 這個(gè)頂級(jí)域名服務(wù)器，頂級(jí)域名服務(wù)器查找到了 www.abc.com 對(duì)應(yīng)的 DNS 服務(wù)器的 IP 地址返回給客戶端

然后本地去請(qǐng)求 www.abc.com 對(duì)應(yīng)的 DNS 服務(wù)器解析這個(gè)域名，DNS 服務(wù)器解析后返回對(duì)應(yīng)的主機(jī) IP 地址

在第 6 步驟，DNS 服務(wù)器解析后可以返回多個(gè)對(duì)應(yīng)的主機(jī) IP 地址，那么客戶端訪問(wèn)的時(shí)候可以通過(guò)隨機(jī)或者輪詢等訪問(wèn)做簡(jiǎn)單的負(fù)載均衡處理

上述流程就是一個(gè)沒(méi)有給域名配置 CDN 的流程

CDN 加速靜態(tài)資源訪問(wèn)

什么是 CDN

百度百科：CDN是構(gòu)建在現(xiàn)有網(wǎng)絡(luò)基礎(chǔ)之上的智能虛擬網(wǎng)絡(luò)，依靠部署在各地的邊緣服務(wù)器，通過(guò)中心平臺(tái)的負(fù)載均衡、內(nèi)容分發(fā)、調(diào)度等功能模塊，使用戶就近獲取所需內(nèi)容，降低網(wǎng)絡(luò)擁塞，提高用戶訪問(wèn)響應(yīng)速度和命中率。CDN的關(guān)鍵技術(shù)主要有內(nèi)容存儲(chǔ)和分發(fā)技術(shù)

內(nèi)存存儲(chǔ)

比如說(shuō)我們有個(gè)圖片網(wǎng)站應(yīng)用部署在成都，一開(kāi)始應(yīng)用只在成都當(dāng)?shù)赝茝V本地人使用。后面業(yè)務(wù)發(fā)展出去了，全國(guó)各地的人都在訪問(wèn)了，處于新疆烏魯木齊的用戶發(fā)現(xiàn)圖片加載的速度變得很慢（因?yàn)閳D片這些數(shù)據(jù)需要從成都通過(guò)網(wǎng)線傳輸?shù)綖豸斈君R太遠(yuǎn)了，而且中途可能存在網(wǎng)絡(luò)擁擠等等原因）那么想個(gè)辦法，我們?cè)跒豸斈君R部署一個(gè)緩存服務(wù)器，后續(xù)烏魯木齊的用戶只要訪問(wèn)過(guò)某張圖片就將其緩存到烏魯木齊的服務(wù)器上，后續(xù)的訪問(wèn)就可以變得更快

分發(fā)技術(shù)

比如說(shuō)訪問(wèn)烏魯木齊緩存服務(wù)器沒(méi)有對(duì)應(yīng)的圖片緩存的時(shí)候，這個(gè)時(shí)候可以去訪問(wèn)西北數(shù)據(jù)中心獲取數(shù)據(jù)，西北數(shù)據(jù)中心沒(méi)有再去源數(shù)據(jù)中心獲取，這樣可以盡可能的減少對(duì)源數(shù)據(jù)中心的訪問(wèn)減少源數(shù)據(jù)中心壓力的同時(shí)，加速用戶的訪問(wèn)體驗(yàn)

邊緣結(jié)點(diǎn)：距離用戶最近的數(shù)據(jù)訪問(wèn)中心，比如成都

區(qū)域結(jié)點(diǎn)：如果邊緣結(jié)點(diǎn)中沒(méi)有查找到到對(duì)應(yīng)的緩存可以去區(qū)域結(jié)點(diǎn)中，比如西南區(qū)域

中心節(jié)點(diǎn)：如果區(qū)域結(jié)點(diǎn)數(shù)據(jù)還是沒(méi)有命中則需要回源（訪問(wèn)源數(shù)據(jù)中心節(jié)點(diǎn)）

經(jīng)過(guò)一層一層數(shù)據(jù)中心節(jié)點(diǎn)數(shù)據(jù)訪問(wèn)過(guò)后，數(shù)據(jù)會(huì)依次緩存到對(duì)應(yīng)的數(shù)據(jù)中心節(jié)點(diǎn)中，后續(xù)用戶訪問(wèn)就可以臨近訪問(wèn)了

CDN 可以緩存什么

網(wǎng)頁(yè)、圖片、文件等一些不經(jīng)常改變的數(shù)據(jù)，可以緩存到 CDN 中

CDN 如何更新數(shù)據(jù)

查找的數(shù)據(jù)有可能不存在，也有可能過(guò)期了，如何更新 CDN 緩存呢

拉取模式

推送模式

如果是某份熱點(diǎn)數(shù)據(jù)，一開(kāi)始就近 CDN 緩存中沒(méi)有就向上拉取，如果出現(xiàn)回源，可能導(dǎo)致源數(shù)據(jù)中心壓力會(huì)過(guò)大。

這個(gè)時(shí)候可以采取主動(dòng)推送模式，將熱點(diǎn)數(shù)據(jù)主動(dòng)推送到邊緣結(jié)點(diǎn)。

CDN 帶來(lái)的問(wèn)題

防盜鏈問(wèn)題

請(qǐng)求附帶 refer 標(biāo)示來(lái)源

時(shí)間戳防盜鏈

數(shù)據(jù)過(guò)期問(wèn)題

當(dāng)服務(wù)器數(shù)據(jù)更新后，CDN 數(shù)據(jù)還未更新時(shí)靜態(tài)資源訪問(wèn)可能存在不一致的問(wèn)題

資源都是有設(shè)置過(guò)期時(shí)間的，等到過(guò)期時(shí)間到了就會(huì)回源拉取最新內(nèi)容

主動(dòng)刷新 CDN 緩存，強(qiáng)制性的讓緩存失效全部回源拉取最新數(shù)據(jù)

CDN 解析流程

此時(shí)配置了 CDN 后，不會(huì)直接返回對(duì)應(yīng)的 IP 地址而是返回 CNAME 對(duì)應(yīng)的 CDN 域名 abc.cdn.com

解析 abc.cdn.com 得到對(duì)應(yīng)的 IP 地址后請(qǐng)求該 CDN DNS 服務(wù)器，此時(shí)返回全局負(fù)載均衡域名地址

解析 abc.cdn.gslb.com 得到對(duì)應(yīng)的 IP 地址后請(qǐng)求該全局負(fù)載均衡器，根據(jù)用戶的 IP 地址、所處運(yùn)營(yíng)商、URL 攜帶內(nèi)容以及各 CDN 服務(wù)器的負(fù)載情況選擇最為合適的最近的一臺(tái)或者多態(tài)服務(wù)器的 IP 地址給客戶端

客戶端可以通過(guò)簡(jiǎn)單的隨機(jī)或者輪詢等操作發(fā)起調(diào)用

建立 HTTP 連接

HTTP 協(xié)議通過(guò) TCP 協(xié)議進(jìn)行數(shù)據(jù)傳輸，在傳輸數(shù)據(jù)之前需要建立 TCP 連接

在 HTTP 通信的時(shí)候，建立連接和斷開(kāi)連接分別需要 3 次握手和四次揮手，效率還是很低的在 HTTP/1.0 的時(shí)候每次發(fā)送數(shù)據(jù)都需要建立連接響應(yīng)完成后就需要斷開(kāi)連接。自 HTTP/1.1 開(kāi)始就是長(zhǎng)連接了，除非一端主動(dòng)斷開(kāi)連接，這樣極大的提升了通信的效率。

服務(wù)端負(fù)載均衡處理

服務(wù)端一般采用 Nginx 等服務(wù)器來(lái)做負(fù)載均衡處理，客戶端過(guò)來(lái)的 HTTP 請(qǐng)求會(huì)與 Nginx 建立長(zhǎng)連接后開(kāi)始數(shù)據(jù)傳輸?shù)竭_(dá) Nginx，Nginx 會(huì)維護(hù)到達(dá)不同服務(wù)器的長(zhǎng)連接將數(shù)據(jù)轉(zhuǎn)發(fā)到真實(shí)的后端服務(wù)器

當(dāng)然 nginx 也可以以短連接的方式發(fā)起請(qǐng)求，只是使用長(zhǎng)連接能夠減少 3 次握手和 4 次揮手大大的提升通信效率，減緩網(wǎng)絡(luò)擁擠的情況

長(zhǎng)連接帶來(lái)的問(wèn)題

我們使用長(zhǎng)連接的時(shí)候會(huì)設(shè)置長(zhǎng)連接的超時(shí)時(shí)間，到達(dá)時(shí)候會(huì)釋放連接，那么在連接釋放的時(shí)候，首先服務(wù)端會(huì)發(fā)送 FIN 包到達(dá)客戶端，客戶端還未收到 FIN 包的時(shí)候，發(fā)起了一個(gè) HTTP 請(qǐng)求的話，那么這個(gè)請(qǐng)求就會(huì)響應(yīng) NoHttpResponseException

解決方案：

客戶端重試機(jī)制（指定最多重試的次數(shù)）

定時(shí)提前清理閑置的鏈接，客戶端啟用定時(shí)任務(wù)，在超時(shí)之前主動(dòng)與服務(wù)端斷開(kāi)連接即可