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