爲什麼沒法使用 ip 訪問網站？

猶記得很早之前本身搭建我的博客（如今的博客是 python-online.cn）的時候，那時候開始學習編程，什麼東西都很陌生。建站成功後，我激動不已，還特意發了一個朋友圈得瑟。那是個人第一個 web 項目。

回顧一下，流程差很少是這樣的。

一、到雲廠商那裏購買一個服務器；

二、將本身的網站服務部署到服務器；

三、購買一個本身喜歡的域名；

四、雲解析這個域名指向你的服務器ip；

五、最後就能夠經過域名訪問我的網站了。

若是你不想花錢購買域名，固然也能夠直接使用 服務器ip 進行訪問，和使用域名訪問並不會有任何區別。

此次建站成功，也讓我產生一種錯覺（當時真的菜，畢竟還沒工做），一個服務器對應一個網站，咱們只要能夠經過域名訪問，也就能夠經過ip訪問。

可事實有可能並非這樣的。

這裏用博客園爲例，分析一下。

我用nslookup工具 對home.cnblogs.com作一個解析

$ nslookup home.cnblogs.com
Server:        172.20.10.1
Address:    172.20.10.1#53

Non-authoritative answer:
Name:    home.cnblogs.com
Address: 116.62.82.159

獲得服務器ip地址：116.62.82.159，將這個 ip 敲入 chrome 地址欄，回車。

發現並沒有法訪問。

這和咱們想象的徹底不同呀？

再找一個子域名看看，說不定能夠呢。

再次用 nslookup 工具 對news.cnblogs.com 作一個解析

$ nslookup news.cnblogs.com
Server:        172.20.10.1
Address:    172.20.10.1#53

Non-authoritative answer:
Name:    news.cnblogs.com
Address: 116.62.82.159

什麼狀況？這個ip和上面的那個ip竟是同一個。

這下明朗了，一個ip對應着多個域名。服務器哪裏會知道咱們要訪問哪一個域名呢？

這就像你在大街上，大喊一聲「帥哥」，全部男的都回過頭來看着你，可是他們並非知道你叫的究竟是誰。

帶着這個問題，咱們來稍微深刻一下，這種一個ip對應多個域名是如何實現的？（今天的主題）

常見的大概有兩種：

1.  虛擬主機技術

首先是虛擬主機技術，使得在一個服務器上能夠提供多個 web 站點的訪問服務。

具體的實現過程是這樣的，首先經過配置域名解析，將多個域名都解析到同一個服務器ip，而後咱們在該主機上經過配置來讓主機能夠未來自不一樣域名的請求轉發給不一樣的網站程序去處理。主機會截獲到請求的請求頭信息，而後獲取到host這個請求頭的值，這個值也就是該請求的來源域名。主機根據所配置的域名與網站程序的對應關係，未來自不一樣的域名的請求轉發給不一樣的程序去處理。

舉個例子，當咱們訪問 news.cnblogs.com 時

一、會先作DNS解析，獲得服務器ip地址：116.62.82.159

二、與服務器經過三次握手創建鏈接後，發送站點訪問請求。

3、服務器接收到請求後，Apache 會取到報文中的 Host news.cnblogs.com 和本身的配置文件進行匹配獲得站點的根目錄

四、到對應的站點目錄中尋找相關的內容並返回。

這裏假想 Apache 的配置文件以下（虛構）

<VirtualHost *:80>
DocumentRoot /var/www/home
ServerName home.cnblogs.com
</VirtualHost>
<VirtualHost *:80>
DocumentRoot /var/www/news
ServerName news.cnblogs.com
</VirtualHost>
<VirtualHost *:80>
DocumentRoot /var/www/jobs
ServerName jobs.cnblogs.com
</VirtualHost>

這對於比較小的我的網站，是一套行之有效的方案。它的侷限性就在，全部站點的服務都在一臺服務器上，並無考慮到災備與高可用。

• 當服務器因某種緣由，致使機器宕機，全部的站點也將癱瘓。

• 當服務器的硬盤損壞，假若沒法恢復，全部的數據都將丟失。

• 當有一天訪問量突增，單臺壓力過大，站點也沒法正常訪問。

在企業的生產環境中，通常都不會使用這種方案了吧？

2. 反向代理技術

有反向代理，必然有正向代理。

在這裏摘錄 @劉志軍（Python之禪） 博客的一段比喻作爲說明：

正向代理

正在創業之路摸爬滾打的 A 同窗，目前他遇到的最大的一個問題就是啓動資金，因而他決定去找馬雲爸爸借錢，可想而知，最後碰一鼻子灰回來了，情急之下，他想到一個辦法，只能找關係開後門。

通過一番消息打探，原來A同窗的大學老師王老師是馬雲的同窗，因而A同窗找到王老師，託王老師幫忙去馬雲那借500萬過來，固然最後事成了。

不過馬雲並不知道這錢是A同窗借的，馬雲是借給王老師的，最後由王老師轉交給A同窗。這裏的王老師在這個過程當中扮演了一個很是關鍵的角色，就是代理，也能夠說是正向代理，王老師代替 A同窗 辦這件事，這個過程當中，真正借錢的人是誰，馬雲是不知道的，這點很是關鍵。

反向代理

當你撥打 10086 客服電話，一個地區的 10086 客服有幾個或者幾十個，你永遠都不須要關心在電話那頭的是哪個，叫什麼，男的，仍是女的，漂亮的仍是帥氣的，你都不關心，你關心的是你的問題能不能獲得專業的解答，你只須要撥通了 10086 的總機號碼，電話那頭總會有人會回答你，只是有時慢有時快而已。

那麼這裏的 10086 總機號碼就是咱們說的反向代理。客戶不知道真正提供服務的人是誰。

簡單的說

• 正向代理，是向服務端隱藏真實的客戶端，代理的對象是客戶端；

• 而反向代理，是向客戶端隱藏真實的服務端，代理的對象是服務端。

將正向代理和反向代理用一張圖來解釋,能夠看下邊，左邊是正向代理，右邊是反向代理。

當咱們訪問 news.cnblogs.com 時，反向代理服務器會幫咱們把請求轉發到提供真實計算的服務器那裏去，Nginx 就是性能很是好的反向代理服務器，它能夠用來作負載均衡。

使用了反向代理，完美地解決了上邊 虛擬主機技術 我提出的三個問題。

• 某臺機器宕機後，反向代理服務器會請求轉發到仍然存活的節點上繼續提供服務；

• 硬盤故障後，因爲同一份數據在多個節點都會備份，不會有什麼問題

• 當訪問量突增時，能夠彈性增長計算節點，來分流分壓，當訪問量恢復正常後再減小節點數量。

今天的內容大概就是這些，寫得比較淺顯易懂，但願對你有所幫助。

若是以爲寫得還能夠，還請點下右下角的好看支持一下！