整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
最新版的 Canary 和 Dev 預(yù)覽通道中，微軟已經(jīng)開始向部分 Edge 92 瀏覽器用戶推出“自動 HTTPS”功能。顧名思義，該功能可在用戶通過常規(guī)的“超文本傳輸協(xié)議”（HTTP）訪問網(wǎng)站的時候，自動切換到可用的 HTTPS 安全連接選項。其實在 Edge 開發(fā)團(tuán)隊宣布這一消息之前，該公司已在 4 月份的 Microsoft 365 路線圖中有過預(yù)告（或于 7 月正式發(fā)布）。
微軟在博客文章中指出，在極有可能支持更安全協(xié)議的網(wǎng)站上，Automatic HTTPS 功能可將用戶訪問的 HTTP 網(wǎng)站連接自動切換到更安的 HTTPS 。
至于支持 HTTPS 的網(wǎng)站列表，則基于微軟的定期網(wǎng)絡(luò)分析結(jié)果，有助于用戶避免中間人攻擊 / 流量篡改，從而安全的訪問數(shù)十萬計的域名。
通過普通“超文本傳輸協(xié)議”（HTTP）收發(fā)的數(shù)據(jù)（包括密碼、信用卡信息、以及其它敏感信息），也可能導(dǎo)致攻擊者在受感染的用戶計算機上運行惡意程序。
但在給站點服務(wù)器通訊加密之后，就能夠更好地確保用戶在瀏覽網(wǎng)絡(luò)時，始終使用 HTTPS 來保護(hù)傳輸中的數(shù)據(jù)。
此外在惡意攻擊者試圖攔截網(wǎng)絡(luò)流量時，此類行為也很難在不被檢測到的情況下，篡改與互聯(lián)網(wǎng)站點交換的數(shù)據(jù)。
感興趣的朋友，可在瀏覽器地址欄中輸入 edge://settings/privacy 并跳轉(zhuǎn)，然后啟用“Automatic HTTPS”，以自動切換到更安全的網(wǎng)絡(luò)連接。
如果這項實驗性功能未能順利啟用，也可先轉(zhuǎn)到 edge://flags/#edge-automatic-https 并啟用“Automatic HTTPS”標(biāo)記。
默認(rèn)情況下，該功能只會在可能支持 HTTPS 協(xié)議的站點上啟用自動切換，但用戶也可強制所有站點都啟用 HTTPS 連接。不過如果目標(biāo)網(wǎng)站并不支持 HTTPS，則可能會遇到連接錯誤。
段時間在知乎上了看一些網(wǎng)絡(luò)方面的知識，剛好小編自己也是從事這一塊的相關(guān)工作由對網(wǎng)絡(luò)方面有一定的了解。今天我們來講講，當(dāng)你在瀏覽器中輸入本站域名并回車后，這背后到底發(fā)生來什么事情？
（因平臺原因本文中www即為xxx ，com即為zzz，http/ccccc即為cccc/ccccc）
大致總結(jié)歸納了下，發(fā)生的事情如下圖：
看到這里，大部分人都是蒙的。哪怕你有一點網(wǎng)絡(luò)知識的基礎(chǔ)，看起來也是蒙的。為了跟大家生動形象地說明原理，下面，我們用擬人的手法，講述從輸入一個網(wǎng)址，到最終顯示出頁面，這背后所發(fā)生的事情。
某天，小明心血來潮，想去艾西服務(wù)器論壇看一下有沒有更新的博文，于是他打開了chrome瀏覽器，稍微回憶了一下網(wǎng)址，輸入了：27server.zzz，并按下了回車。
一 ，瀏覽器格式化檢查
chrome檢查了一下，嗯？這好像是一個蠻標(biāo)準(zhǔn)的網(wǎng)址。但如果小明輸入的是27server@zzz或者27server.zzz1這樣的，chrome就會無情的拒絕小明的提議，并提示他網(wǎng)址出錯。
所以在第一步，瀏覽器對網(wǎng)址進(jìn)行了格式化檢驗，確定這是一個有效的網(wǎng)址，才會進(jìn)入下一步。但是，在訪問之前，瀏覽器必須知道，用了什么協(xié)議，是http呢，還是https呢？顯然chrome對這種事情已經(jīng)見怪不怪了，他有自己的一套方案，這里小明沒有給定是什么協(xié)議的，于是chrome默認(rèn)用了http協(xié)議，于是將網(wǎng)址修改成了：cccc://27server.zzz
二 DNS分級查詢
在互聯(lián)網(wǎng)上，有一家名叫TCP/IP的快遞公司，專門負(fù)責(zé)運送用戶的包裹。
于是chrome聯(lián)系了TCP/IP快遞公司，但卻被告知：需要知道對方的IP地址，才能把包裹寄給對方！chrome并不是一個灰心的孩子，于是它找到了“黃頁公司”-DNS。
求DNS幫忙查詢下“27server.zzz”的IP地址是多少？DNS于是著手開始查找。首先看了下本地的hosts文件，沒有找到對應(yīng)！然后看了下本地內(nèi)存，也沒有！沒辦法，DNS只好聯(lián)系了村口的一家名叫路由器的公司，192.168.1.1。路由器查看了下，最近村里沒人訪問過這個域名呀，要不你去市里的DNS公司問問？這是市里的DNS公司地址：114.114.114.114
于是DNS又聯(lián)系了市里的DNS公司，卻被告知最近市里最近也沒人訪問過這個域名。但是市里的DNS公司畢竟是專業(yè)的DNS公司，不會隨便推卸責(zé)任，對DNS說，你等一等，我找我的上級查詢下。于是市里的DNS公司聯(lián)系了它的上級，根域名服務(wù)器。這個根域名服務(wù)器可了不得，全球只有13臺，掌控著全球的DNS根域名查詢。市里的DNS公司找到了離他最近的根域名服務(wù)器，說：“老哥，麻煩幫我查下.com頂級域名的服務(wù)器地址。”
沒過一會兒，根域名服務(wù)器回復(fù)道：“你好，你要查詢的地址是1.2.3.4。”
于是市里的DNS公司又聯(lián)系到了1.2.3.4，詢問 27server這個二級域名的域名服務(wù)器地址。
同樣，1.2.3.4回復(fù)給了市里的DNS公司，地址是2.3.4.5。
市里的DNS公司又找2.3.4.5問了下，地址是：27server.zzz.w.kunluncan.zzz。等等，這怎么是一個別名（CNAME）？
于是市里的DNS公司又不厭其煩的重復(fù)了上面的幾個步驟，一級一級地查找了 com > kunluncan > w > com > 27server的域名服務(wù)器地址，一直找到了馳網(wǎng)云的CDN域名服務(wù)器，DNS聯(lián)系了對方，對方回復(fù)道：“查詢到25個IP地址，分別是xxxxxxxx，幫你找到了離你最近的地址，3.4.5.6，已經(jīng)打包，收件人地址：114.114.114.114 發(fā)件人地址：3.3.3.3，已委托TCP/IP快遞公司的UDP小哥發(fā)送給你。”
三，網(wǎng)關(guān) ARP原理
UDP是這一行的老司機，隨手在包裹上寫著：
收件人門牌號：53
發(fā)件人門牌號：56002
因為UDP知道，同一個地址會有很多的門牌號，為了避免混淆，必須要寫。
UDP隨手聯(lián)系了TCP/IP公司的貨車司機，讓他捎帶一下這個包裹。
司機來了，把包裹放進(jìn)了駕駛室，坐上車準(zhǔn)備開車。
司機打開了導(dǎo)航（路由表），發(fā)現(xiàn)要出關(guān)（網(wǎng)關(guān)），但是要知道關(guān)口的編號（mac地址）。但是導(dǎo)航信息里并沒有關(guān)口的編號。于是司機找到了當(dāng)?shù)氐南驅(qū)RP，問這個關(guān)口的編號是多少？ARP吼了一嗓子，關(guān)口回復(fù)說：“我的編號是xxxxx”。司機很快就到達(dá)了關(guān)口，關(guān)口放行，載著快遞，上了Internet高速公路，一路狂奔不止。
四，建立DNS緩存
市里的DNS公司收到結(jié)果后，又通過村口的路由器公司聯(lián)系到了DNS，并把結(jié)果告訴給了對方。同時村口的路由器公司和DNS都在自己的小本本上默默地記下了這個對應(yīng)關(guān)系。
最后，DNS又把結(jié)果告訴給了已經(jīng)等得不耐煩的chrome了。
五 ，TCP的三次握手
知道了27server.zzz的IP地址，chrome又立即聯(lián)系了TCP/IP快遞公司，快遞公司派出了TCP小哥來接洽此時。和UDP小哥不同的是，TCP小哥是一個做事一絲不茍的人，知道chrome想要去拜訪3.4.5.6，就要先和對方聯(lián)系一下，確定在不在，這是通過TCP三次握手實現(xiàn)的。
TCP小哥：在嗎？有人想要去拜訪您。
對方：在啊，隨時歡迎。
TCP小哥：馬上到。
這三次消息，要通過TCP/IP公司的司機來來回回運輸三次。DNS查詢也是同樣的道理，這里就不贅述了。
通過這三次握手，TCP小哥建立起了一條chrome到3.4.5.6的通道。
chrome將http請求消息（我是誰，要找誰等），打包給了TCP小哥，寄件人IP地址：2.2.2.2 門牌號：23755。收件人IP地址：3.4.5.6 門牌號：80
然后TCP小哥聯(lián)系了司機，將包裹送到了3.4.5.6的80門牌號上。
六 Nginx的工作原理
3.4.5.6的80門牌號的門衛(wèi)是nginx老大爺。老大爺一看，是送給家里的27server.zzz的。
路上老大爺看了下nginx.conf里找人的順序：首先找index.php，如果找不到就找index.htm，再找不到就找index.html。
于是敲開了27server.zzz的門，里面只有index.html在家。index.html頭也不回地告訴nginx老大爺，告訴chrome，我們已經(jīng)搬家了，去找ccccc://xxx.27server.zzz（強制跳轉(zhuǎn)）。
七 https加密原理
chrome收到了這個消息，立馬又重復(fù)了上面的所有步驟，聯(lián)系了“黃頁公司”DNS，費了很大一番周折，找到了 xxx.27server.zzz的IP地址。
其實這兩次訪問，整體流程相似，不一樣的地方如下：
查找到 xxx.27server.zzz的IP地址后，chrome這回沒有直接把包裹給TCP小哥，而是聯(lián)系了TLS安保大叔，讓他全權(quán)負(fù)責(zé)包裹的安全問題，確保包裹在運輸過程中的安全，即包裹的內(nèi)容保密，包裹內(nèi)容不能被篡改、替換。
TLS大叔需要先和對方溝通安保措施，溝通的渠道，就是上文三次握手建立的渠道。
TLS大叔先發(fā)言：你好，我支持TLS版本1.2，以及我的認(rèn)證算法、加密算法、數(shù)據(jù)校驗算法，此外還有我的隨機碼，收到請回復(fù)。
TLS服務(wù)器回復(fù)：你好，我也支持1.2版本，那我們就使用xx認(rèn)證算法、xx加密算法、xx數(shù)據(jù)校驗算法，我的隨機碼是xx，來實現(xiàn)安保措施，你看好嗎？
TLS大叔:沒問題啊，能出示一下你的證件(數(shù)字證書)嗎？
TLS服務(wù)器：okay，這是我的證件，請過目。
TLS大叔發(fā)現(xiàn)對方發(fā)過來的證書：
TLS大叔不放心，驗證了下證書，過程如下：
1. 用DigiCert Global Root CA的公鑰解密證書Encryption Everywhere DV的簽名
作為一個權(quán)威CA，已經(jīng)被瀏覽器預(yù)先安裝在可信任根證書列表，那么我們信任該CA的一切，當(dāng)然包括其公鑰，在該證書里包含了明文的公鑰。
解開了，證明是該CA私鑰加密的，由于CA私鑰只有CA知道，證書有效，并信任Encryption Everywhere DV的公鑰。
2. 同樣原理用Encryption Everywhere DV的公鑰解密DigiCert Global Root CA的簽名。
如果上述2個步驟都成功了，就有了27server.zzz的公鑰。
3. 再檢查下證書的有效期，如果沒有過期，那么進(jìn)入下一個步驟。
TLS大叔用“27server.zzz“公鑰加密一段隨機的字符串，發(fā)送給TLS服務(wù)器。
TLS服務(wù)器用自己的私鑰解密，得到明文字符串。
至此，雙方分享了這個神秘的字符串，雙方還有早前分享的隨機碼(nonce)，雙方使用同樣的算法，可以推導(dǎo)出相同的master key，進(jìn)而推導(dǎo)出session key、HMAC key。
Session Key用于加密/解密數(shù)據(jù)， HMAC Key主要用于保護(hù)數(shù)據(jù)的完整性，以防被第三方篡改。
整個TLS溝通過程就算完成了，TLS大叔把瀏覽器扔給自己的包裹，外面加了一層保險箱，密碼鎖（session key）只有TLS大叔、TLS服務(wù)器知道。
然后TLS大叔把包裹給了TCP小哥，TCP小哥看了下包裹，沒啥兩樣，就是收件人的門牌號從80變成了443。
包裹到達(dá)后，443門牌號的門衛(wèi)是TLS服務(wù)器，TLS服務(wù)器用自己的密碼打開了包裹，包裹里有個小紙條，上面寫著“Application Data=http”，知道這是http的東西，于是轉(zhuǎn)手又讓nginx老大爺把包裹送到 xxx.27server.zzz的房間。
八 CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）原理
這回nginx老大爺一看index.php不在家，但是留了個字條，說對方如果要圖片這些靜態(tài)資源，那么直接給他，如果要找我們，請到IP地址：5.6.7.8來找我。沒辦法，nginx老大爺又委托TLS大叔跟對方的服務(wù)器5.6.7.8的TLS對接了下，商量下包裹加密，又TCP/IP快遞公司，把包裹寄到了5.6.7.8的443門牌，送給了index.php。index.php發(fā)現(xiàn)需要主頁，這需要進(jìn)行計算。于是找來了php家族，計算完了又把主頁打包成了html樣式，返回給了chrome。
chrome收到了html樣式的包裹，這是一種標(biāo)記語言，需要經(jīng)過解釋才能把原來的頁面還原出來。
于是chrome又埋頭計算，終于通過里面寫的規(guī)則，把圖片文字拼拼湊湊，拼成了一個完整的頁面，展示給了小明。
小明怎么也不會想到，按下了一次回車，在后臺居然觸發(fā)了這么大的計算量。。。
對于以上的內(nèi)容，這里我們用稍微專業(yè)點的語言解釋一下：
訪問網(wǎng)址，首先通過域名查詢IP地址。
瀏覽器會先查詢hosts文件，然后查詢內(nèi)存中是否有對應(yīng)的DNS緩存。如果電腦連接路由器上網(wǎng)，而DNS又是自動獲取的話，DNS服務(wù)器就會被指定為路由器（局域網(wǎng)網(wǎng)關(guān)），如果局域網(wǎng)中沒人訪問過這個地址，那么在路由器的內(nèi)存中不會存在這條DNS解析記錄。于是又往上查找各層級的DNS服務(wù)器，從家里到區(qū)，到城市的DNS服務(wù)器，能不能找到緩存，取決于這個區(qū)域有沒有人訪問過這個域名。一直查到最上層，如果都沒有找到的話，就會請求根域名服務(wù)器，從找到com域名服務(wù)器地址，再從com上找到27server二級域名服務(wù)器地址….以此類推，最終找到完整域名的服務(wù)器地址。
找到地址后，是一個CNAME形式，解析到了阿里云CDN的DNS服務(wù)器上，阿里云的DNS服務(wù)器又通過用戶的訪問IP判斷出用戶的地理位置，返回最靠近用戶的CDN服務(wù)器地址。CDN通俗點說，就是把你的網(wǎng)站資源鏡像到全國各地的服務(wù)器上，從而實現(xiàn)不同地區(qū)用戶的訪問加速。
用戶通過這兩層DNS查詢后，得到了離自己最近的CDN服務(wù)器地址，訪問這個地址，CDN服務(wù)器根據(jù)配置的緩存規(guī)則，返回了靜態(tài)資源，其他則通過訪問源服務(wù)器進(jìn)行返回（CDN回源）。
因為對應(yīng)27server.zzz這個地址，我只放了一個index.html。訪問這個頁面，會自動跳轉(zhuǎn)到 ccccc://xxx.27server.zzz。瀏覽器訪問27server.zzz后，又繼續(xù)訪問ccccc://xxx.27server.zzz，此時通過兩次DNS查詢，CDN返回圖片，js，css等靜態(tài)資源，然后php的內(nèi)容則通過CDN回源，源服務(wù)器的php計算后，轉(zhuǎn)化為html樣式，返回給訪問者。
你對 27server.zzz的一次訪問，一共觸發(fā)了4次完整的DNS查詢，1次www強行跳轉(zhuǎn)，1次https強行跳轉(zhuǎn)，1次CDN回源，2次CDN地址解析，更有數(shù)不清的資源文件從各個地方被傳輸?shù)搅四愕碾娔X。這些都是通過TCP的三次握手協(xié)議，網(wǎng)關(guān)，ARP，UDP，nginx，CDN，DNS服務(wù)器聯(lián)合工作。
我是艾西，今天的分享就到這里啦希望對有需要的小伙伴有幫助我們下期見
擁有一臺服務(wù)器可以做很多有趣的事情！
是否遇到過這樣的情況： 當(dāng)你打開網(wǎng)頁，地址欄默認(rèn)顯示 / 路徑，但頁面卻一片空白，沒有任何內(nèi)容顯示？
別擔(dān)心，這很可能是因為你的 Vue 路由沒有匹配到對應(yīng)的組件。 為了解決這個問題，我們可以使用 路由重定向 功能，將用戶自動跳轉(zhuǎn)到指定的路徑。
一、路由重定向，讓用戶不再迷茫！
路由重定向的功能，可以讓用戶在訪問一個路徑時，自動跳轉(zhuǎn)到另一個路徑，就像在迷宮中安裝了自動導(dǎo)航系統(tǒng)，指引用戶找到正確的目的地。
二、Vue 路由重定向語法解析：
在 Vue 路由中，我們可以使用 { path: '匹配路徑', redirect: '重定向路徑' } 的語法來實現(xiàn)重定向。
代碼示例：
javascriptconst router=new VueRouter({
routes: [
{ path: '/', redirect: '/home' }, // 訪問根路徑時，重定向到 '/home'
{ path: '/home', component: Home }, // 'home' 路徑對應(yīng)的組件
// ... 其他路由配置
],
});
在這個例子中，當(dāng)用戶訪問 / 路徑時，會自動被重定向到 /home 路徑，并展示 Home 組件。
三、重定向的常見用法：
四、代碼解析：
在 Vue Router 中，redirect 屬性接受一個字符串或者一個函數(shù)。
javascript{ path: '/profile', redirect: to=> {
if (user.isLogged) {
return '/dashboard'; // 用戶已登錄，重定向到儀表盤
} else {
return '/login'; // 用戶未登錄，重定向到登錄頁
}
}
}
五、總結(jié)：
路由重定向功能可以有效地提高 Vue 應(yīng)用的易用性，讓用戶體驗更加流暢。掌握了路由重定向的語法和用法，你就能輕松處理各種頁面跳轉(zhuǎn)問題，讓你的網(wǎng)頁不再迷路！
希望這篇文章對你有幫助，歡迎在評論區(qū)分享你的經(jīng)驗和疑問！
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
