為什麼域名能夠訪問網站，而直接使用IP不可以
背景介紹
在訪問杭電官網杭電官網的時候，直接在瀏覽器上，輸入域名是可以得到訪問結果的。因此，產生了一種猜測，既然網路中實際上是根據域名轉換的IP來直接訪問伺服器的，那麼我直接通過IP來訪問杭電官網是否可以？？
通過nslookup 解析出杭電官網的ip地址，然後在瀏覽器中手動輸入相關ip地址，結果並不能得到訪問結果，為什麼？
解析到的ip地址有兩個
218.75.123.182
218.75.123.181
初步懷疑可能是用這兩個IP地址做了高可用
當其中某一個Ip地址訪問不到的時候，另外一個ip地址可以訪問到。
繼而，我決定換個網站來試一下，看能否直接訪問杭電OJ，高潮來了,驚訝的發現杭電OJ和杭電官網，這兩個網站對應的IP地址是同一個。
提出問題
由於上面的情況，我內心中充滿了疑問，主要有兩點。
- 1.為什麼我直接訪問
www.hdu.edu.cn是能夠訪問到網站的，而當我輸入218.75.123.182卻訪問不到？ - 2.為什麼
www.hdu.edu.cn和acm.hdu.edu.cn這兩個網站使用dns解析出來的ip地址是一樣的？
分析原因
查閱眾多資料後，基本能夠分析出以上兩個問題的原因所在。
只輸入ip地址訪問不到域名的原因：
使用nslookup對多個杭電下的網站進行解析，發現很多站點的ip地址是相同的，都是218.75.123.182，218.75.123.181這兩個。如下圖所示，杭電網站cloud.hdu.edu.cn和www.hdu.edu.cn以及杭電oj系統.www.hdu.edu.cn對應的是同一個公網ip地址（不知道公網ip和私網ip的，可以查一下百度）
這麼多站點對應同一個ip地址，你只輸入ip地址，瀏覽器當然不知道你到底要訪問哪一個站點，這就是為什麼你不能夠使用ip地址去訪問的原因所在。
多個站點對應一個ip地址的問題
理論上來說，一個ip對應一個站點，這是很正常的，那為什麼會出現上文中所描述的那樣,一個ip地址對應多個站點的情況呢？
有兩種技術可以實現描述的問題
- 1.虛擬主機技術
- 2.反向代理技術
虛擬主機技術
虛擬主機技術是apache，nginx等伺服器所特有的一種功能，也就是實現多個站點在同一臺伺服器上放置。假如說杭電是使用虛擬主機技術實現的一個IP對應多個web站點的話，那麼實際情況應該是這個樣子：
比如我現在有一臺伺服器，我可以在伺服器裡面描述這樣一種站點和實際路徑的關係:
那麼這樣這三個站點就能夠在同一臺伺服器上共存了，當你訪問acm.hdu.edu.cn的時候,主要有這麼幾個步驟
- 1.dns做域名解析，然後得到解析後的結果，假如說是218.75.123.182。
- 2.瀏覽器開始與目標ip地址為218.75.123.182的伺服器進行三次握手操作，建立TCP連線
- 3.瀏覽器開始構建HTTP請求報文，報文的頭部格式為
Accept
*/*
Accept-Encoding
gzip, deflate
Accept-Language
zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Connection
keep-alive
Cookie
PHPSESSID=v103qj5emvgv5j8hd85d2aro33
Host
acm.hdu.edu.cn
Referer
http://acm.hdu.edu.cn/
User-Agent
Mozilla/5.0 (Windows NT 10.0; …) Gecko/20100101 Firefox/62.0
只需要關注這個報文頭部的這麼一段
Host
acm.hdu.edu.cn
通過這個報文可以知道，瀏覽器要訪問ip地址為218.75.123.182的伺服器的哪一臺HOST（這裡有一個概念，伺服器上面可以有一個站點，也可以由多個站點，有一個站點的話，伺服器上就只有一個HOST，如果有多個站點的話，伺服器上面就會有多個虛擬HOST）
- 4.伺服器接受到這個報文之後，會進行分析，apache伺服器會根據報文中的host，來匹配自己的配置檔案。假設，伺服器中的配置檔案是這樣寫的：
<VirtualHost *:80>
DocumentRoot /var/www/acm
ServerName acm.hdu.edu.cn
</VirtualHost>
<VirtualHost *:80>
DocumentRoot /var/www/html
ServerName www.hdu.edu.cn
</VirtualHost>
<VirtualHost *:80>
DocumentRoot /var/www/cloud
ServerName cloud.hdu.edu.cn
</VirtualHost>
那麼當請求報文中的HOST是acm.hdu.edu.cn的時候，apache伺服器就會根據自己的配置檔案所寫的那樣，去/var/www/acm目錄下尋找站點內容。
- 5.伺服器處理請求，構建響應報文，傳送響應報文到客戶端
反向代理技術
當我以為我已經接近了事實真相的時候，意外的發現了另外一個問題，我登入到校園網，然後繼續使用nslookup進行域名解析，發現了一個驚訝的事情，解析之後,上文中所提到的那三個站點的ip完全不一樣。也就是說實際上這三個站點完全放在了不同的伺服器上，即不可能是使用的虛擬主機技術（如果使用虛擬主機技術，這幾個站點肯定是在同一臺伺服器上的）。
如下圖所示
內網、外網解析文中所述三個站點的情況如下表所示
| 網站域名 | 外網解析 | 內網解析 |
|---|---|---|
| 218.75.123.182,218.75.123.181 | 192.168.102.19 | |
| 218.75.123.182,218.75.123.181 | 192.168.102.6 | |
| 218.75.123.182,218.75.123.181 | 10.1.18.137 |
既有192.168開頭的私網ip地址，又有10.1開頭的私網ip地址，這種特殊的網路結構是由於杭電的網路規劃造成的，一開始杭電使用的是192.168開頭的私網ip地址，後來發現不夠了，繼而進行擴充套件，使用10.1開頭的私網ip地址。這裡對於這一部分內容不做深究
由此，我們基本可以推斷出，杭電實際的網路結構是下圖所示的樣子。而不是上文中，我所推測的虛擬主機。
當我在外網訪問acm.hdu.edu.cn的時候，主要經歷了這麼幾個步驟。
通過dns解析獲得acm.hdu.edu.cn的反向代理ip地址 218.75.123.181。
1.客戶端傳送報文到ip地址為218.75.123.181的伺服器上，中間要經過NAT路由器,做NAT轉化，把私網IP地址轉化為公網IP地址。
2.資料包在因特網中進行路由準發
3.資料包最終到達218.75.123.181的apache伺服器，這個伺服器實際上並不承擔web站點任務，主要是作為一個WEB網站的閘道器角色（反向代理角色）。
4.請求報文中的HOST是acm.hdu.edu.cn,因此，反向代理伺服器會將請求報文轉發至域名為acm.hdu.edu.cn的主機上。acm主機處理完請求之後，會將處理後的結果返回至客戶端。
小結
本文主要講了兩方面：
- 1.直接使用ip地址訪問不了站點的原因
原因就在於該ip地址可能對應著多個web站點，單單依靠ip地址是不知道如何匹配到哪個web站點的。但是通過域名，我們就能夠知道具體要訪問哪一個HOST。如果使用虛擬主機，直接找到相關virtual HOST即可，如果使用反向代理，那麼通過代理找到HOST的實際私網地址也可以。
- 2.只有一個公網ip如何實現多個WEB站點的訪問
有兩種辦法可以實現，其一是虛擬主機，其二就是反向代理。通過目前來看，虛擬主機的實現方式已然不多，更多的企業或者學校使用的是反向代理技術
針對本案例（杭電若干網站），這若干網站經過DNS解析後對應的是同一個ip218.75.123.182或者218.75.123.181,使用者請求接入到這個公網ip的時候，該伺服器會進行反向代理，根據請求報文中的HOST名字，將請求報文轉發至具體的區域網內部的主機進行處理，然後再將處理結果進行返回。