日韩在线视频二,免费午夜成人,三级片免费看

URL的發(fā)展歷史：域名、協議和端口

轉帖|行業(yè)資訊|編輯：鄭恭琳|2016-09-12 10:18:07.000|閱讀 338 次

概述：本文介紹了幫你連接到互聯網上某個遠程服務器上的應用程序時所使用的URL及其組成元素。

1982年1月11日，22位計算機科學家聚在一起討論了有關“計算機郵件”（也就是電子郵件）的問題。與會者包括創(chuàng)建了Sun Microsystems公司的家伙，開發(fā)了Zork的家伙，發(fā)明NTP的家伙，以及說服政府需要為Unix付費的家伙。當時他們討論的問題其實很簡單：ARPANET上已經有455臺主機，情況似乎開始有些失控。

當時提到這個問題主要是因為ARPANET即將把最初使用的NCP協議更換為TCP/IP協議，我們現在熟知的互聯網就是在后者基礎上建立的。更換后即將出現很多相互連接的網絡（莫非是傳說中的“互聯…網”）,需要一種“層次”更明確的域名系統(tǒng)，由ARPANET解決自己的域名問題，其他網絡的域名問題也由它們自己解決。

當時其他網絡都使用了一些很不錯的名字，例如“COMSAT”、“CHAOSNET”、“UCLNET”，以及“INTELPOSTNET”，這些網絡由全美國的很多大學和公司自行維護，但他們希望能夠跨網通信，并愿意為此從電話公司租用56k帶寬的線路并購買負責處理通信路由任務的PDP-11s設備。

在ARPANET最初的設計中，由集中的網絡信息中心（NIC）負責維護一份列出網絡上每臺主機的文件。這個文件就是HOSTS.TXT，與當今Linux或OS X系統(tǒng)中的/etc/hosts文件作用類似。針對網絡進行的所有改動都需要由NIC使用FTP（一種誕生于1971年的協議）發(fā)送給網絡中的每臺主機，這對他們的基礎結構造成了極大的負擔。

面對規(guī)模無限大的互聯網，用一個文件列出互聯網上的每臺主機這種做法當然是不可行的。不過他們當時想解決的最大問題是電子郵件，這也是當時最大的挑戰(zhàn)。經研究他們最終決定創(chuàng)建一種層次式的系統(tǒng)，用戶可以通過這個系統(tǒng)查詢外部系統(tǒng)的域名或設置自己需要的域名。換句話說：“通過對這一領域研究他們發(fā)現，目前使用類似‘user@host’這樣的郵箱標識符應該擴展為‘user@host.domain’，其中‘domain’代表域名的層次結構。”就這樣，域名系統(tǒng)誕生了。

這里要打消大家一個很常見的錯覺，當時的這個決定并沒有預見到域名系統(tǒng)的未來發(fā)展。實際上他們選擇這樣的解決方案主要是因為，這種方案“是在現有系統(tǒng)基礎上實現難度最小的。”例如，對于電子郵件地址有一個提議是使用“.@”的形式，如果當時電子郵件的用戶名中不包含“.”字符，那么今天你可能要使用“zack.eager@io”這樣的地址給我發(fā)郵件了。

UUCP和一路的感嘆號

『有種說法認為操作系統(tǒng)的主要功能是為相同的對象定義一系列不同名稱，這樣才能讓操作系統(tǒng)自己忙于追蹤所有這些不同名稱之間的關系。網絡協議在某種程度上似乎也有類似的特征。 -- David D. Clark，1982年』

另一個失敗的提議想使用感嘆號（!）分隔域名的不同組件。例如為了聯系ARPANET上的ISIA主機就需要連接到!ARPA!ISIA，隨后可以使用通配符查詢主機，例如查詢!ARPA!*可以看到ARPANET上的每臺主機。

這種尋址方法與目前使用的標準方法相差并不太多，只是維護方面所做的一次嘗試。這種使用感嘆號的體系會使用1976年發(fā)明的一種名為UUCP的數據傳輸工具傳播有關主機的數據。如果使用OS X或Linux計算機閱讀這篇文章，你也許依然可以在終端中使用uucp。

誕生于1969年的ARPANET很快就變成一個強大的通信工具... 很多大學和政府機構都可以訪問。而我們今天所熟知的互聯網在這之后過了21年，才在1991年被研究機構以外的普通公眾所了解。其實在這之前不同計算機用戶之間早已可以通信了。

在互聯網誕生前的時代里，計算機之間最常見的通信方式是使用直接點對點撥號連接。舉例來說，如果你想給我發(fā)送一個文件，需要用你的調制解調器呼叫我的調制解調器，隨后就能傳輸文件了。為了將這種方式形成某種形式的網絡，人們發(fā)明了UUCP。

在UUCP系統(tǒng)中，每臺計算機上都用一個文件列出了自己所知道的主機，以及對方的電話號碼和主機上的用戶名與密碼。隨后即可借助多臺知道該如何與周圍主機建立聯系的主機，從自己的計算機建立到目標計算機的“通路”：

sw-hosts!digital-lobby!zack

這個地址不僅提供了向我發(fā)送文件或直接連接我計算機的方法，而且可以用作我的電子郵件地址。在“郵件服務器”誕生之前，如果我的計算機關機了你將無法給我發(fā)送郵件。

雖然當時ARPANET只能被最頂尖的大學使用，但UUCP實際上為普通人建立了一個私下的互聯網。隨后UUCP也成為新聞組和BBS系統(tǒng)的基礎。

DNS

最終，我們直到今天還在使用的DNS系統(tǒng)是在1983年提出的。今天在進行DNS查詢時，例如使用dig工具查詢，你可能會看到類似下面這樣的回應：

;; ANSWER SECTION:
google.com.   299 IN  A 172.217.4.206

這些信息是在告訴我們google.com可以通過172.217.4.206訪問。你可能已經知道，A是指這是一條將域名映射到相應IPv4地址的“地址（Address）”記錄。299是“存活時間”，可以告訴我們這條記錄的有效時間還剩多少秒，過期后需要重新進行查詢。但IN是什么意思？

IN代表“Internet”。類似這樣的字段可以追溯至有多種相互競爭的計算機網絡需要交互的時代。其他類似的字段還有代表CHAOSNET的CH，以及代表Athena system所提供的名稱服務Hesiod的HS。CHAOSNET早已關閉，但目前MIT的很多學生還在使用改進版的Athena。IANA網站列出了完整的DNS類清單，不過毫無疑問只有一個值在今天依然被廣泛使用。

頂級域名

『已經完全不可能再需要創(chuàng)建其他頂級域名了。 — John Postel，1994年』

當上文提到的那些牛人們決定應該讓域名帶有層次結構后，還需要決定這種層次結構的“根”是什么。這個根通常是使用一個“.”代表的。實際上讓所有域名以“.”結尾從語義上來說是正確的，并且瀏覽器絕對支持這種做法：google.com.。

世界上出現的第一個頂級域名（TLD）是.arpa，用戶可以借助這個頂級域名在過渡期內對傳統(tǒng)的ARPANET主機名進行尋址。舉例來說，如果我的計算機之前曾注冊為hfnet，那么我的新地址就是hfnet.arpa。但這只是暫時的，在過渡期內服務器管理員需要做一個重要的選擇：共五個頂級域名，自己到底要用哪個？“.com”、“.gov”、“.org”、“.edu”，還是“.mil”？

之前說DNS有層次結構時，實際是指需要用到一系列根DNS服務器并讓它們承擔重要的任務，例如將.com指向.com名稱服務器，由后者負責告訴用戶如何到達google.com。互聯網的根DNS區(qū)域由13個DNS服務器集群組成，一共只有13個服務器集群，因為這是一個UDP數據包可以容納的上限。在歷史上DNS是通過UDP數據包運作的，這意味著請求的回應不能超過512字節(jié)。

;       This file holds the information on root name servers needed to
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  .  "
;       configuration file of BIND domain name servers).
;
;       This file is made available by InterNIC 
;       under anonymous FTP as
;           file                /domain/named.cache
;           on server           FTP.INTERNIC.NET
;       -OR-                    RS.INTERNIC.NET
;
;       last update:    March 23, 2016
;       related version of root zone:   2016032301
;
; formerly NS.INTERNIC.NET
;
.                        3600000      NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:ba3e::2:30
;
; FORMERLY NS1.ISI.EDU
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     192.228.79.201
B.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:84::b
;
; FORMERLY C.PSI.NET
;
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
C.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2::c
;
; FORMERLY TERP.UMD.EDU
;
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A     199.7.91.13
D.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2d::d
;
; FORMERLY NS.NASA.GOV
;
.                        3600000      NS    E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
;
; FORMERLY NS.ISC.ORG
;
.                        3600000      NS    F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
F.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2f::f
;
; FORMERLY NS.NIC.DDN.MIL
;
.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
;
; FORMERLY AOS.ARL.ARMY.MIL
;
.                        3600000      NS    H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000      A     198.97.190.53
H.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:1::53
;
; FORMERLY NIC.NORDU.NET
;
.                        3600000      NS    I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
I.ROOT-SERVERS.NET.      3600000      AAAA  2001:7fe::53
;
; OPERATED BY VERISIGN, INC.
;
.                        3600000      NS    J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000      A     192.58.128.30
J.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:c27::2:30
;
; OPERATED BY RIPE NCC
;
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129
K.ROOT-SERVERS.NET.      3600000      AAAA  2001:7fd::1
;
; OPERATED BY ICANN
;
.                        3600000      NS    L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000      A     199.7.83.42
L.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:9f::42
;
; OPERATED BY WIDE
;
.                        3600000      NS    M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33
M.ROOT-SERVERS.NET.      3600000      AAAA  2001:dc3::35
; End of file

根DNS服務器放置在上鎖機柜中的保險箱里，保險箱上還放置了一個表，這是為了確保監(jiān)控視頻不被篡改并循環(huán)播放。尤其是考慮到DNSSEC的實施實在是進展緩慢，對這些服務器中的任何一臺進行攻擊都會使得攻擊者對全部或部分互聯網用戶的流量進行重定向。這些措施確保了最天馬行空的高科技犯罪電影也未曾“染指”根DNS服務器。

可想而知，頂級TLD的名稱服務器實際上并不需要經常更改。根DNS服務器收到的所有請求中有98%是錯誤導致的，大部分源自未能對結果進行恰當緩存的有故障或瑕疵的客戶端。這種情況造成的后果越來越嚴重，以至于很多根DNS的運營人員計劃逐漸部署多臺特殊的服務器，這些服務器的作用僅僅是跟想要對本地IP地址進行反向DNS查詢的人說一句話：“走開”。

TLD名稱服務器由全球不同公司和政府部門管理（Verisign負責管理.com）。每次你購買.com域名時，其中約有會付給，另外7.85會付給Verisign。

Punycode

現實中我們開發(fā)者為新項目想的那些愚蠢的名字很少會直接用于最終公開發(fā)布的產品。我們可能會將公司使用的數據庫命名為Delaware（因為所有公司都是在這里注冊的），但幾乎可以確定的是，在用于生產環(huán)境時肯定會使用類似CompanyMetadataDatastore這樣的名字。但是機緣巧合的情況下，天上星星排成排，老板外出度假時，疏忽就這么不經意地產生了。

Punycode系統(tǒng)可供我們將Unicode字符編碼為域名。這套系統(tǒng)所解決的問題很簡單：如果整個互聯系統(tǒng)都是圍繞ASCII字母表建立的，其中包含最多的外文字符都是腭化符號，你該怎樣寫出“比薩.com”？

這個問題并不是簡單地將域名切換為使用Unicode就能解決的。決定域名系統(tǒng)規(guī)范的原始文檔明確要求域名要使用ASCII編碼，過去四十年來生產的所有網絡硬件，包括在你查看本頁過程中為你提供服務的Cisco和Juniper路由器都是基于這一規(guī)范生產的。

網絡本身從不是只允許使用ASCII的。其實最開始網絡講的是ISO 8859-1語言，其中不僅包含所有ASCII字符，而且額外增加了一些特殊字符，例如“¼”和帶有特殊標記的字母，例如“ä”。然而其中并不包含任何非拉丁語系的字符。

HTML中有關這個問題的限制最終于2007年取消，同年Unicode成為網絡上最受歡迎的字符集。但域名依然只能使用ASCII。

你可能會猜到Punycode最初的提議并非為了解決這個問題。其實你可能聽說過UTF-8，這是一種將Unicode編碼為字節(jié)的主要方式（名稱中的“8”代表一個字節(jié)中包含的8個比特）。2000年，互聯網工程任務組的多個成員提出了UTF-5，他們的想法在于將Unicode編碼為五比特的塊。隨后將每五比特映射為可以在域名中使用的字符（A-V和0-9）。那么如果我建立了一個學習日語的網站，我的網站“日本語.com”會將域名顯示為“M5E5M72COA9E.com”。

這種編碼方式有很多局限。例如A-V和0-9會顯示在編碼后的輸出結果中，這意味著如果你想要真正在自己的域名中包含上述任何一個字符，依然需要將這個字符像其他內容一樣進行編碼。這就使得十分長的域名會遇到一個嚴重的問題，域名的每個片段最多只能使用63個字符。緬甸文的域名最多將只能使用15個字符。不過這個提議依然給出了一個有趣的建議，通過UTF-5使得Unicode能借助摩斯電碼或電報傳輸。

另外還有個問題需要考慮：如何讓客戶端知道這個域名是編碼后的，這樣客戶端才能用相應的Unicode字符在地址欄顯示域名，而不是顯示為類似“M5E5M72COA9E.com”這樣。對于這個問題曾經有多個建議，建議之一是在DNS的回應中使用未使用的“位”。當時“回應報頭只剩下最后一個未使用的‘位’”，然而負責DNS的那幫人“對于放棄這個‘位’顯得非常猶豫”。

另一個建議是讓所有域名使用ra--打頭的編碼方法。在當時（2000年4月中旬）沒有任何域名是恰好以這個特殊字符打頭的。而我恰恰就知道在這個提議剛剛發(fā)布后，立刻有人蓄意注冊了一個ra--域名。

2003年終于有了最終定論，大家決定采用一種名為Punycode的格式，在這種格式中通過一種形式的差值壓縮（Delta compression）大幅縮短編碼后的域名。差值壓縮是個很棒的想法，因為巧就巧在域名中的所有字符都位于Unicode的通用區(qū)域內。例如，波斯文中的兩個字符要比一個波斯文字符和一個印度語字符更為接近。這到底是怎么回事？我們用一個無意義的詞組來看看：

???

在未壓縮的格式中，上述詞組會保存為三個字符[1610, 1584, 1597]（基于它們的Unicode碼點）。要壓縮這串詞組，首先需要按照數值對其排序（同時記錄原始字符的位置）并獲得：[1584, 1597, 1610]。隨后存儲最小值（1584），以及這個值與下一個字符的差值（13），并繼續(xù)存儲與下一個值的差值（23），這樣需要傳輸和存儲的內容就少很多了。

隨后Punycode會用（非常）高效的方式將這些整數編碼為域名中可以使用的字符，并在開頭處插入一個xn--，借此讓客戶知道這是個編碼后的域名。你會發(fā)現所有Unicode字符會一起顯示在域名末尾。Punycode不僅會編碼相應的值，而且會對要插入到域名ASCII部分的位置進行編碼。例如“熱狗sales.com”這個網站會變成xn--sales-r65lm0e.com。在瀏覽器的地址欄輸入基于Unicode的域名都會這樣編碼。

上述轉換過程應該是透明的，但這樣會造成一個重要的安全問題。所有類型的Unicode字符打印出來會與現有ASCII字符完全相同。例如你可能看不出西里爾文小寫字母a（“а”）與拉丁文小寫字母a（“a”）之間的區(qū)別。如果我注冊了西里爾文的аmazon.com（xn--mazon-3ve.com）并騙你訪問，你很難知道自己訪問了錯誤的網站。因此當你訪問x.ws時，瀏覽器反而會在地址欄顯示xn--vi8hiv.ws。

協議

URL中顯示的第一部分內容是訪問所用的協議。最常見的協議是http，Tim Berners-Lee發(fā)明的這種簡單文檔傳輸協議驅動著今天的整個互聯網。但可用協議不光這一個。一些人認為我們應該只使用Gopher。除了常規(guī)用途外，Gopher明確針對類似于文件樹結構的結構化數據傳輸進行了考慮。

舉例來說，如果請求/Cars端點，可能返回下列內容：

1Chevy Camaro             /Archives/cars/cc     gopher.cars.com     70
iThe Camero is a classic  fake                  (NULL)              0
iAmerican Muscle car      fake                  (NULL)              0
1Ferrari 451              /Factbook/ferrari/451  gopher.ferrari.net 70

從中可以看出有兩輛車，此外還有一些有關車的元數據以及訪問哪里可以了解更詳細信息。隨后客戶端需要將這些信息解析為更易用的形式，并將不同條目與目標頁面鏈接在一起。

誕生于1971年的FTP是第一個廣受歡迎的協議，該協議可以列出并下載遠程計算機上的文件。Gopher是該協議的一種邏輯擴展，可以提供類似的列表功能并讀取不同條目的元數據。這意味著可以將Gopher用于更廣泛的用途，例如新聞源或簡單的數據庫。然而在自由度和簡單程度上不如HTTP和HTML出色。

HTTP是一種非常簡單的協議，相比其他類似協議，例如FTP甚至最近逐漸開始流行的HTTP/2協議依然顯得非常簡單。首先，HTTP是完全基于文本的，不包含任何定制的二進制內容（因此顯得更為高效）。Tim Berners-Lee準確地察覺到使用基于文本的格式可以讓一代代程序員更容易地開發(fā)和調試基于HTTP的應用程序。

HTTP幾乎完全無需考慮你要傳輸的內容是什么。盡管在發(fā)明之初這個協議就是明確用于處理HTML語言的，但你可以為自己的內容指定任何類型（使用MIME Content-Type，在當時這也是個新發(fā)明）。這個協議本身也相當簡單：

下面這樣的請求：

GET /index.html HTTP/1.1
Host: www.example.com

可以得到下列回應：

如果想要更形象地理解，可以將互聯網所用網絡系統(tǒng)的起點想做是IP（Internet協議）。IP負責在不同計算機之間搬運小數據包（每個數據包大約1500字節(jié)）。在這之上是TCP，負責搬運更大的數據塊，例如整個文檔和文件，并通過很多IP數據包以可靠的方式發(fā)送。在這之上我們實施了諸如HTTP或FTP等協議，這些協議決定了在通過TCP（或UDP等）協議發(fā)送數據時所要使用的格式。就這么簡單好理解。

換句話說，TCP/IP只負責將一整批字節(jié)發(fā)送給其他計算機，由協議決定這些字節(jié)是什么，有什么含義。

如果愿意你也可以開發(fā)自己的協議，按照自己喜歡的方法將字節(jié)裝配成你自己的TCP消息。但唯一需要注意的是任何你希望與之聯系的人必須說和你一樣的語言。因此這些協議有必要實現標準化。

當然還有很多不那么重要的協議可以使用。例如有Quote of The Day協議（17端口），有Random Characters協議（19端口）。這些協議今天看起來似乎有些好笑，但也證明了像HTTP這樣常規(guī)用途文檔傳輸格式的重要性。

端口

Gopher和HTTP的時間先后也可以從它們各自的默認端口號看出來。Gopher是70，HTTP是80。HTTP端口是在接到Tim Berners-Lee在1990年和1992年之間某個時間提出的請求后分配的（很可能是由IANA的Jon Postel負責分配）。

這種“注冊端口號”的概念誕生時間甚至早于互聯網。在最初用于驅動ARPANET的NCP協議中，遠程地址是通過40比特數值識別的。其中前32比特用于確定遠程主機，這一點類似于目前的IP地址。后面8比特則是AEN（代表“Another Eight-bit Number”），遠程計算機將其用于類似今天端口號的作用，借此可以區(qū)分發(fā)給不同進程的信息。換句話說，地址決定了信息要發(fā)給哪臺計算機，AEN（或端口號）可以告訴遠程計算機要將這條信息交給哪個應用程序。

為了限制可能產生的沖突，他們很快就要求用戶注冊這些“套接字（Socket）編號”。當TCP/IP將端口號擴展為16比特之后依然需要進行這這樣的注冊。

雖然每個協議都有默認端口，但為了方便本地開發(fā)和在同一臺計算機上托管多個服務，依然有必要允許用戶手工指定要使用的端口。給網站使用www.前綴的基本依據也是基于相同的邏輯。當時幾乎沒有人可以訪問自己域名的根，只能托管“實驗性”的網站。但如果你告訴別人自己某一計算機的主機名（例如dx3.cern.ch），如果要更換計算機將會造成不小的麻煩。通過使用通用子域（例如www.cern.ch），就可以在需要時更改該子域指向的計算機。