HTTP知識(shí)整合

HTTP——一、了解Web及網(wǎng)絡(luò)基礎(chǔ)
HTTP——二、簡(jiǎn)單的HTTP協(xié)議
HTTP——三、HTTP報(bào)文內(nèi)的HTTP信息
HTTP——四、返回結(jié)果的HTTP狀態(tài)碼
HTTP——五、與HTTP協(xié)作的Web服務(wù)器
HTTP——六、HTTP首部
HTTP——七、確保Web安全的HTTPS
HTTP——八、確認(rèn)訪問用戶身份的認(rèn)證
HTTP——九、基于HTTP的功能追加協(xié)議
HTTP——十、構(gòu)建Web內(nèi)容的技術(shù)
HTTP——十一、Web的攻擊技術(shù)# 一、使用HTTP協(xié)議訪問Web
你知道當(dāng)我們?cè)诰W(wǎng)頁瀏覽器（Web brower）的地址欄中輸入U(xiǎn)RL時(shí)，Web頁面是如何呈現(xiàn)的嗎？

Web頁面當(dāng)然不能憑空顯示出來。根據(jù)Web瀏覽器地址欄中指定的URL，Web瀏覽器從Web服務(wù)器端獲取文件資源（resourse）等信息，從而顯示出Web頁面。
像這種通過發(fā)送請(qǐng)求獲取服務(wù)器資源的Web瀏覽器等；都可稱為客戶端（client）。

Web使用一種名為HTTP（HyperText Transfer Protocol，超文本傳輸協(xié)議）的協(xié)議作為規(guī)范，完成從客戶端到服務(wù)器端等一系列運(yùn)作流程。而協(xié)議是指規(guī)則的約定?？梢哉f，Web是建立在HTTP協(xié)議上通信的。

二、HTTP的誕生

在深入學(xué)習(xí) HTTP 之前，我們先來介紹一下 HTTP 誕生的背景。了解背景的同時(shí)也能了解當(dāng)初制定 HTTP 的初衷，這樣有助于我們更好地理解。

1、為知識(shí)共享而規(guī)劃Web

1989 年 3 月，互聯(lián)網(wǎng)還只屬于少數(shù)人。在這一互聯(lián)網(wǎng)的黎明期，HTTP 誕生了。

CERN（歐洲核子研究組織）的蒂姆 ? 伯納斯 - 李（Tim BernersLee）博士提出了一種能讓遠(yuǎn)隔兩地的研究者們共享知識(shí)的設(shè)想。

最初設(shè)想的基本理念是：借助多文檔之間相互關(guān)聯(lián)形成的超文本（HyperText），連成可相互參閱的 WWW（World Wide Web，萬維網(wǎng)）。

現(xiàn)在已提出了 3 項(xiàng) WWW 構(gòu)建技術(shù)，分別是：把 SGML（StandardGeneralized Markup Language，標(biāo)準(zhǔn)通用標(biāo)記語言）作為頁面的文本標(biāo)記語言的 HTML（HyperText Markup Language，超文本標(biāo)記語言）；作為文檔傳遞協(xié)議的 HTTP ；指定文檔所在地址的 URL（Uniform Resource Locator，統(tǒng)一資源定位符）。

WWW 這一名稱，是 Web 瀏覽器當(dāng)年用來瀏覽超文本的客戶端應(yīng)用程序時(shí)的名稱?，F(xiàn)在則用來表示這一系列的集合，也可簡(jiǎn)稱為 Web。

2、Web成長(zhǎng)時(shí)代

1990 年 11 月，CERN 成功研發(fā)了世界上第一臺(tái) Web 服務(wù)器和 Web 瀏覽器。兩年后的 1992 年 9 月，日本第一個(gè)網(wǎng)站的主頁上線了。
1990 年，大家針對(duì) HTML1.0 草案進(jìn)行了討論，因 HTML1.0 中存在多處模糊不清的部分，草案被直接廢棄了。
1993 年 1 月，現(xiàn)代瀏覽器的祖先 NCSA（National Center for Supercomputer Applications，美國國家超級(jí)計(jì)算機(jī)應(yīng)用中心）研發(fā)的 Mosaic 問世了。它以 in-line（內(nèi)聯(lián)）等形式顯示 HTML的圖像，在圖像方面出色的表現(xiàn)使它迅速在世界范圍內(nèi)流行開來。 同年秋天，Mosaic 的 Windows 版和 Macintosh 版面世。使用 CGI 技術(shù)的 NCSA Web 服務(wù)器、NCSA HTTPd 1.0 也差不多是在這個(gè)時(shí)期出現(xiàn)的。
1994 年 的 12 月，網(wǎng)景通信公司發(fā)布了 Netscape Navigator 1.0，1995年微軟公司發(fā)布 Internet Explorer 1.0 和 2.0。
緊隨其后的是現(xiàn)在已然成為 Web 服務(wù)器標(biāo)準(zhǔn)之一的 Apache，當(dāng)時(shí)它以 Apache 0.2 的姿態(tài)出現(xiàn)在世人眼前。而 HTML也發(fā)布了 2.0 版本。那一年，Web 技術(shù)的發(fā)展突飛猛進(jìn)。
時(shí)光流轉(zhuǎn)，從 1995 年左右起，微軟公司與網(wǎng)景通信公司之間爆發(fā)的瀏覽器大戰(zhàn)愈演愈烈。兩家公司都各自對(duì) HTML做了擴(kuò)展，于是導(dǎo)致在寫 HTML頁面時(shí)，必須考慮兼容他們兩家公司的瀏覽器。時(shí)至
今日，這個(gè)問題仍令那些寫前端頁面的工程師感到棘手。
在這場(chǎng)瀏覽器供應(yīng)商之間的競(jìng)爭(zhēng)中，他們不僅對(duì)當(dāng)時(shí)發(fā)展中的各種Web 標(biāo)準(zhǔn)化視而不見，還屢次出現(xiàn)新增功能沒有對(duì)應(yīng)說明文檔的情況。
2000 年前后，這場(chǎng)瀏覽器戰(zhàn)爭(zhēng)隨著網(wǎng)景通信公司的衰落而暫告一段落。但就在 2004 年，Mozilla 基金會(huì)發(fā)布了 Firefox 瀏覽器，第二次瀏覽器大戰(zhàn)隨即爆發(fā)。
Internet Explorer 瀏覽器的版本從 6 升到 7 前后花費(fèi)了 5 年時(shí)間。之后接連不斷地發(fā)布了 8、9、10 版本。另外，Chrome、Opera、Safari 等瀏覽器也紛紛搶占市場(chǎng)份額。

3、駐足不前的HTTP

HTTP/0.9
HTTP于1990年問世。那時(shí)的HTTP并沒有作為正式的標(biāo)準(zhǔn)被建立。現(xiàn)在的 HTTP 其實(shí)含有 HTTP1.0 之前版本的意思，因此被稱為HTTP/0.9。
HTTP/1.0
HTTP 正式作為標(biāo)準(zhǔn)被公布是在 1996 年的 5 月，版本被命名為HTTP/1.0，并記載于 RFC1945。雖說是初期標(biāo)準(zhǔn)，但該協(xié)議標(biāo)準(zhǔn)至今仍被廣泛使用在服務(wù)器端。
HTTP/1.1
1997 年 1 月公布的 HTTP/1.1 是目前主流的 HTTP 協(xié)議版本。當(dāng)初的標(biāo)準(zhǔn)是 RFC2068，之后發(fā)布的修訂版 RFC2616 就是當(dāng)前的最新版本。
可見，作為 Web 文檔傳輸協(xié)議的 HTTP，它的版本幾乎沒有更新。新一代 HTTP/2.0 正在制訂中，但要達(dá)到較高的使用覆蓋率，仍需假以時(shí)日。
當(dāng)年 HTTP 協(xié)議的出現(xiàn)主要是為了解決文本傳輸?shù)碾y題。由于協(xié)議本身非常簡(jiǎn)單，于是在此基礎(chǔ)上設(shè)想了很多應(yīng)用方法并投入了實(shí)際使用。現(xiàn)在 HTTP 協(xié)議已經(jīng)超出了 Web 這個(gè)框架的局限，被運(yùn)用到了各種場(chǎng)景里。

三、網(wǎng)絡(luò)基礎(chǔ)TCP/IP

為了理解 HTTP，我們有必要事先了解一下 TCP/IP 協(xié)議族。
通常使用的網(wǎng)絡(luò)（包括互聯(lián)網(wǎng)）是在 TCP/IP 協(xié)議族的基礎(chǔ)上運(yùn)作的。而 HTTP 屬于它內(nèi)部的一個(gè)子集。
接下來，我們僅介紹理解 HTTP 所需掌握的 TCP/IP 協(xié)議族的概要。若想進(jìn)一步學(xué)習(xí)有關(guān) TCP/IP 的知識(shí)，請(qǐng)參考其他講解 TCP/IP 的專業(yè)書籍。

1、TCP/IP協(xié)議族

計(jì)算機(jī)與網(wǎng)絡(luò)設(shè)備要相互通信，雙方就必須基于相同的方法。比如，如何探測(cè)到通信目標(biāo)、由哪一邊先發(fā)起通信、使用哪種語言進(jìn)行通信、怎樣結(jié)束通信等規(guī)則都需要事先確定。不同的硬件、操作系統(tǒng)之間的通信，所有的這一切都需要一種規(guī)則。而我們就把這種規(guī)則稱為協(xié)議（protocol）。

圖：TCP/IP 是互聯(lián)網(wǎng)相關(guān)的各類協(xié)議族的總稱
協(xié)議中存在各式各樣的內(nèi)容。從電纜的規(guī)格到 IP 地址的選定方法、尋找異地用戶的方法、雙方建立通信的順序，以及 Web 頁面顯示需要處理的步驟，等等。
像這樣把與互聯(lián)網(wǎng)相關(guān)聯(lián)的協(xié)議集合起來總稱為 TCP/IP。也有說法認(rèn)為，TCP/IP 是指 TCP 和 IP 這兩種協(xié)議。還有一種說法認(rèn)為，TCP/IP 是在 IP 協(xié)議的通信過程中，使用到的協(xié)議族的統(tǒng)稱。

2、TCP/IP的分層管理

TCP/IP 協(xié)議族里重要的一點(diǎn)就是分層。TCP/IP 協(xié)議族按層次分別分為以下 4 層：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層。
把 TCP/IP 層次化是有好處的。比如，如果互聯(lián)網(wǎng)只由一個(gè)協(xié)議統(tǒng)籌，某個(gè)地方需要改變?cè)O(shè)計(jì)時(shí)，就必須把所有部分整體替換掉。而分層之后只需把變動(dòng)的層替換掉即可。把各層之間的接口部分規(guī)劃好之后，每個(gè)層次內(nèi)部的設(shè)計(jì)就能夠自由改動(dòng)了。
值得一提的是，層次化之后，設(shè)計(jì)也變得相對(duì)簡(jiǎn)單了。處于應(yīng)用層上的應(yīng)用可以只考慮分派給自己的任務(wù)，而不需要弄清對(duì)方在地球上哪個(gè)地方、對(duì)方的傳輸路線是怎樣的、是否能確保傳輸送達(dá)等問題。
TCP/IP 協(xié)議族各層的作用如下：

• 應(yīng)用層
  應(yīng)用層決定了向用戶提供應(yīng)用服務(wù)時(shí)通信的活動(dòng)。
  TCP/IP 協(xié)議族內(nèi)預(yù)存了各類通用的應(yīng)用服務(wù)。比如，F(xiàn)TP（File Transfer Protocol，文件傳輸協(xié)議）和 DNS（Domain Name System，域名系統(tǒng)）服務(wù)就是其中兩類。HTTP 協(xié)議也處于該層。
• 傳輸層
  傳輸層對(duì)上層應(yīng)用層，提供處于網(wǎng)絡(luò)連接中的兩臺(tái)計(jì)算機(jī)之間的數(shù)據(jù)傳輸。
  在傳輸層有兩個(gè)性質(zhì)不同的協(xié)議：TCP（Transmission Control Protocol，傳輸控制協(xié)議）和 UDP（User Data Protocol，用戶數(shù)據(jù)報(bào)協(xié)議）。
• 網(wǎng)絡(luò)層（又名網(wǎng)絡(luò)互連層）
  網(wǎng)絡(luò)層用來處理在網(wǎng)絡(luò)上流動(dòng)的數(shù)據(jù)包。數(shù)據(jù)包是網(wǎng)絡(luò)傳輸?shù)淖钚?shù)據(jù)單位。該層規(guī)定了通過怎樣的路徑（所謂的傳輸路線）到達(dá)對(duì)方計(jì)算機(jī)，并把數(shù)據(jù)包傳送給對(duì)方。
  與對(duì)方計(jì)算機(jī)之間通過多臺(tái)計(jì)算機(jī)或網(wǎng)絡(luò)設(shè)備進(jìn)行傳輸時(shí)，網(wǎng)絡(luò)層所起的作用就是在眾多的選項(xiàng)內(nèi)選擇一條傳輸路線。
• 鏈路層（又名數(shù)據(jù)鏈路層，網(wǎng)絡(luò)接口層）
  用來處理連接網(wǎng)絡(luò)的硬件部分。包括控制操作系統(tǒng)、硬件的設(shè)備驅(qū)動(dòng)、NIC（Network Interface Card，網(wǎng)絡(luò)適配器，即網(wǎng)卡），及光纖等物理可見部分（還包括連接器等一切傳輸媒介）。硬件上的范疇均在鏈路層的作用范圍之內(nèi)。

3、TCP/IP 通信傳輸流

利用 TCP/IP 協(xié)議族進(jìn)行網(wǎng)絡(luò)通信時(shí)，會(huì)通過分層順序與對(duì)方進(jìn)行通信。發(fā)送端從應(yīng)用層往下走，接收端則往應(yīng)用層往上走。
我們用 HTTP 舉例來說明，首先作為發(fā)送端的客戶端在應(yīng)用層（HTTP 協(xié)議）發(fā)出一個(gè)想看某個(gè) Web 頁面的 HTTP 請(qǐng)求。
接著，為了傳輸方便，在傳輸層（TCP 協(xié)議）把從應(yīng)用層處收到的數(shù)據(jù)（HTTP 請(qǐng)求報(bào)文）進(jìn)行分割，并在各個(gè)報(bào)文上打上標(biāo)記序號(hào)及端口號(hào)后轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層。
在網(wǎng)絡(luò)層（IP 協(xié)議），增加作為通信目的地的 MAC 地址后轉(zhuǎn)發(fā)給鏈路層。這樣一來，發(fā)往網(wǎng)絡(luò)的通信請(qǐng)求就準(zhǔn)備齊全了。
接收端的服務(wù)器在鏈路層接收到數(shù)據(jù)，按序往上層發(fā)送，一直到應(yīng)用層。當(dāng)傳輸?shù)綉?yīng)用層，才能算真正接收到由客戶端發(fā)送過來的 HTTP請(qǐng)求。

發(fā)送端在層與層之間傳輸數(shù)據(jù)時(shí)，每經(jīng)過一層時(shí)必定會(huì)被打上一個(gè)該層所屬的首部信息。反之，接收端在層與層傳輸數(shù)據(jù)時(shí)，每經(jīng)過一層時(shí)會(huì)把對(duì)應(yīng)的首部消去。
這種把數(shù)據(jù)信息包裝起來的做法稱為封裝（encapsulate）。

四、與HTTP關(guān)系密切的協(xié)議：IP、TCP和DNS

下面我們分別針對(duì)在 TCP/IP 協(xié)議族中與 HTTP 密不可分的 3 個(gè)協(xié)議（IP、TCP 和 DNS）進(jìn)行說明。

1、負(fù)責(zé)傳輸?shù)?IP 協(xié)議

按層次分，IP（Internet Protocol）網(wǎng)際協(xié)議位于網(wǎng)絡(luò)層。Internet Protocol 這個(gè)名稱可能聽起來有點(diǎn)夸張，但事實(shí)正是如此，因?yàn)閹缀跛惺褂镁W(wǎng)絡(luò)的系統(tǒng)都會(huì)用到 IP 協(xié)議。TCP/IP 協(xié)議族中的 IP 指的就是網(wǎng)際協(xié)議，協(xié)議名稱中占據(jù)了一半位置，其重要性可見一斑?？赡苡腥藭?huì)把“IP”和“IP 地址”搞混，“IP”其實(shí)是一種協(xié)議的名稱。
IP 協(xié)議的作用是把各種數(shù)據(jù)包傳送給對(duì)方。而要保證確實(shí)傳送到對(duì)方那里，則需要滿足各類條件。其中兩個(gè)重要的條件是 IP 地址和 MAC地址（Media Access Control Address）。
IP 地址指明了節(jié)點(diǎn)被分配到的地址，MAC 地址是指網(wǎng)卡所屬的固定地址。IP 地址可以和 MAC 地址進(jìn)行配對(duì)。IP 地址可變換，但 MAC地址基本上不會(huì)更改。
使用 ARP 協(xié)議憑借 MAC 地址進(jìn)行通信 IP 間的通信依賴 MAC 地址。在網(wǎng)絡(luò)上，通信的雙方在同一局域網(wǎng)（LAN）內(nèi)的情況是很少的，通常是經(jīng)過多臺(tái)計(jì)算機(jī)和網(wǎng)絡(luò)設(shè)備中轉(zhuǎn)才能連接到對(duì)方。而在進(jìn)行中轉(zhuǎn)時(shí)，會(huì)利用下一站中轉(zhuǎn)設(shè)備的 MAC地址來搜索下一個(gè)中轉(zhuǎn)目標(biāo)。這時(shí)，會(huì)采用 ARP 協(xié)議（Address Resolution Protocol）。ARP 是一種用以解析地址的協(xié)議，根據(jù)通信方的 IP 地址就可以反查出對(duì)應(yīng)的 MAC 地址。
沒有人能夠全面掌握互聯(lián)網(wǎng)中的傳輸狀況在到達(dá)通信目標(biāo)前的中轉(zhuǎn)過程中，那些計(jì)算機(jī)和路由器等網(wǎng)絡(luò)設(shè)備只能獲悉很粗略的傳輸路線。這種機(jī)制稱為路由選擇（routing），有點(diǎn)像快遞公司的送貨過程。想要寄快遞的人，只要將自己的貨物送到集散中心，就可以知道快遞公司是否肯收件發(fā)貨，該快遞公司的集散中心檢查貨物的送達(dá)地址，明確下站該送往哪個(gè)區(qū)域的集散中心。接著，那個(gè)區(qū)域的集散中心自會(huì)判斷是否能送到對(duì)方的家中。
我們是想通過這個(gè)比喻說明，無論哪臺(tái)計(jì)算機(jī)、哪臺(tái)網(wǎng)絡(luò)設(shè)備，它們都無法全面掌握互聯(lián)網(wǎng)中的細(xì)節(jié)。

2、確?？煽啃缘腡CP協(xié)議

按層次分，TCP 位于傳輸層，提供可靠的字節(jié)流服務(wù)。
所謂的字節(jié)流服務(wù)（Byte Stream Service）是指，為了方便傳輸，將大塊數(shù)據(jù)分割成以報(bào)文段（segment）為單位的數(shù)據(jù)包進(jìn)行管理。而可靠的傳輸服務(wù)是指，能夠把數(shù)據(jù)準(zhǔn)確可靠地傳給對(duì)方。一言以蔽之，TCP 協(xié)議為了更容易傳送大數(shù)據(jù)才把數(shù)據(jù)分割，而且 TCP 協(xié)議能夠確認(rèn)數(shù)據(jù)最終是否送達(dá)到對(duì)方。
確保數(shù)據(jù)能到達(dá)目標(biāo)
為了準(zhǔn)確無誤地將數(shù)據(jù)送達(dá)目標(biāo)處，TCP 協(xié)議采用了三次握手（three-way handshaking）策略。用 TCP 協(xié)議把數(shù)據(jù)包送出去后，TCP不會(huì)對(duì)傳送后的情況置之不理，它一定會(huì)向?qū)Ψ酱_認(rèn)是否成功送達(dá)。
握手過程中使用了 TCP 的標(biāo)志（flag） —— SYN（synchronize） 和ACK（acknowledgement）。
發(fā)送端首先發(fā)送一個(gè)帶 SYN 標(biāo)志的數(shù)據(jù)包給對(duì)方。接收端收到后，回傳一個(gè)帶有 SYN/ACK 標(biāo)志的數(shù)據(jù)包以示傳達(dá)確認(rèn)信息。最后，發(fā)送端再回傳一個(gè)帶 ACK 標(biāo)志的數(shù)據(jù)包，代表“握手”結(jié)束。
若在握手過程中某個(gè)階段莫名中斷，TCP 協(xié)議會(huì)再次以相同的順序發(fā)送相同的數(shù)據(jù)包。

除了上述三次握手，TCP 協(xié)議還有其他各種手段來保證通信的可靠性。

五、負(fù)責(zé)域名解析的DNS服務(wù)

DNS（Domain Name System）服務(wù)是和 HTTP 協(xié)議一樣位于應(yīng)用層的協(xié)議。它提供域名到 IP 地址之間的解析服務(wù)。
計(jì)算機(jī)既可以被賦予 IP 地址，也可以被賦予主機(jī)名和域名。比如www.hackr.jp。
用戶通常使用主機(jī)名或域名來訪問對(duì)方的計(jì)算機(jī)，而不是直接通過 IP地址訪問。因?yàn)榕c IP 地址的一組純數(shù)字相比，用字母配合數(shù)字的表示形式來指定計(jì)算機(jī)名更符合人類的記憶習(xí)慣。
但要讓計(jì)算機(jī)去理解名稱，相對(duì)而言就變得困難了。因?yàn)橛?jì)算機(jī)更擅長(zhǎng)處理一長(zhǎng)串?dāng)?shù)字。
為了解決上述的問題，DNS 服務(wù)應(yīng)運(yùn)而生。DNS 協(xié)議提供通過域名查找 IP 地址，或逆向從 IP 地址反查域名的服務(wù)。

六、各種協(xié)議與HTTP協(xié)議的關(guān)系

學(xué)習(xí)了和 HTTP 協(xié)議密不可分的 TCP/IP 協(xié)議族中的各種協(xié)議后，我們?cè)偻ㄟ^這張圖來了解下 IP 協(xié)議、TCP 協(xié)議和 DNS 服務(wù)在使用HTTP 協(xié)議的通信過程中各自發(fā)揮了哪些作用。

七、URI和URL

與 URI（統(tǒng)一資源標(biāo)識(shí)符）相比，我們更熟悉 URL（Uniform Resource Locator，統(tǒng)一資源定位符）。URL正是使用 Web 瀏覽器等訪問 Web 頁面時(shí)需要輸入的網(wǎng)頁地址。比如，下圖的 http://hackr.jp/就是 URL。

1、統(tǒng)一資源標(biāo)識(shí)符

URI 是 Uniform Resource Identifier 的縮寫。RFC2396 分別對(duì)這 3 個(gè)單詞進(jìn)行了如下定義。
Uniform
規(guī)定統(tǒng)一的格式可方便處理多種不同類型的資源，而不用根據(jù)上下文環(huán)境來識(shí)別資源指定的訪問方式。另外，加入新增的協(xié)議方案（如http: 或 ftp:）也更容易。
Resource
資源的定義是“可標(biāo)識(shí)的任何東西”。除了文檔文件、圖像或服務(wù)（例如當(dāng)天的天氣預(yù)報(bào)）等能夠區(qū)別于其他類型的，全都可作為資源。另外，資源不僅可以是單一的，也可以是多數(shù)的集合體。
Identifier
表示可標(biāo)識(shí)的對(duì)象。也稱為標(biāo)識(shí)符。
綜上所述，URI 就是由某個(gè)協(xié)議方案表示的資源的定位標(biāo)識(shí)符。協(xié)議方案是指訪問資源所使用的協(xié)議類型名稱。
采用 HTTP 協(xié)議時(shí)，協(xié)議方案就是 http。除此之外，還有 ftp、mailto、telnet、file 等。標(biāo)準(zhǔn)的 URI 協(xié)議方案有 30 種左右，由隸屬于國際互聯(lián)網(wǎng)資源管理的非營(yíng)利社團(tuán) ICANN（Internet Corporation for Assigned Names and Numbers，互聯(lián)網(wǎng)名稱與數(shù)字地址分配機(jī)構(gòu)）的IANA（Internet Assigned Numbers Authority，互聯(lián)網(wǎng)號(hào)碼分配局）管理頒布。
URI 用字符串標(biāo)識(shí)某一互聯(lián)網(wǎng)資源，而 URL表示資源的地點(diǎn)（互聯(lián)網(wǎng)上所處的位置）。可見 URL是 URI 的子集。
RFC3986：統(tǒng)一資源標(biāo)識(shí)符（URI）通用語法”中列舉了幾種 URI 例子，如下所示。

2、URI格式

表示指定的 URI，要使用涵蓋全部必要信息的絕對(duì) URI、絕對(duì) URL以及相對(duì) URL。相對(duì) URL，是指從瀏覽器中基本 URI 處指定的 URL，形如 /image/logo.gif。
讓我們先來了解一下絕對(duì) URI 的格式。

使用 http: 或 https: 等協(xié)議方案名獲取訪問資源時(shí)要指定協(xié)議類型。不區(qū)分字母大小寫，最后附一個(gè)冒號(hào)（:）。
也可使用 data: 或 javascript: 這類指定數(shù)據(jù)或腳本程序的方案名。
登錄信息（認(rèn)證）
指定用戶名和密碼作為從服務(wù)器端獲取資源時(shí)必要的登錄信息（身份認(rèn)證）。此項(xiàng)是可選項(xiàng)。
服務(wù)器地址
使用絕對(duì) URI 必須指定待訪問的服務(wù)器地址。地址可以是類似hackr.jp 這種 DNS 可解析的名稱，或是 192.168.1.1 這類 IPv4 地址名，還可以是 [0:0:0:0:0:0:0:1] 這樣用方括號(hào)括起來的 IPv6 地址名。
服務(wù)器端口號(hào)
指定服務(wù)器連接的網(wǎng)絡(luò)端口號(hào)。此項(xiàng)也是可選項(xiàng)，若用戶省略則自動(dòng)使用默認(rèn)端口號(hào)。
帶層次的文件路徑
指定服務(wù)器上的文件路徑來定位特指的資源。這與 UNIX 系統(tǒng)的文件目錄結(jié)構(gòu)相似。
查詢字符串
針對(duì)已指定的文件路徑內(nèi)的資源，可以使用查詢字符串傳入任意參數(shù)。此項(xiàng)可選。
片段標(biāo)識(shí)符
使用片段標(biāo)識(shí)符通?？蓸?biāo)記出已獲取資源中的子資源（文檔內(nèi)的某個(gè)位置）。但在 RFC 中并沒有明確規(guī)定其使用方法。該項(xiàng)也為可選項(xiàng)。

并不是所有的應(yīng)用程序都符合 RFC
有一些用來制定 HTTP 協(xié)議技術(shù)標(biāo)準(zhǔn)的文檔，它們被稱為RFC（Request for Comments，征求修正意見書）。
通常，應(yīng)用程序會(huì)遵照由 RFC 確定的標(biāo)準(zhǔn)實(shí)現(xiàn)。可以說，RFC 是互聯(lián)網(wǎng)的設(shè)計(jì)文檔，要是不按照 RFC 標(biāo)準(zhǔn)執(zhí)行，就有可能導(dǎo)致無法通信的狀況。比如，有一臺(tái) Web 服務(wù)器內(nèi)的應(yīng)用服務(wù)沒有遵照RFC 的標(biāo)準(zhǔn)實(shí)現(xiàn)，那 Web 瀏覽器就很可能無法訪問這臺(tái)服務(wù)器了。
由于不遵照 RFC 標(biāo)準(zhǔn)實(shí)現(xiàn)就無法進(jìn)行 HTTP 協(xié)議通信，所以基本上客戶端和服務(wù)器端都會(huì)以 RFC 為標(biāo)準(zhǔn)來實(shí)現(xiàn) HTTP 協(xié)議。但也存在某些應(yīng)用程序因客戶端或服務(wù)器端的不同，而未遵照 RFC 標(biāo)準(zhǔn)，反而將自成一套的“標(biāo)準(zhǔn)”擴(kuò)展的情況。
不按 RFC 標(biāo)準(zhǔn)來實(shí)現(xiàn)，當(dāng)然也不必勞心費(fèi)力讓自己的“標(biāo)準(zhǔn)”符合其他所有的客戶端和服務(wù)器端。但設(shè)想一下，如果這款應(yīng)用程序的使用者非常多，那會(huì)發(fā)生什么情況？不難想象，其他的客戶端或服務(wù)器端必然都不得不去配合它。
實(shí)際在互聯(lián)網(wǎng)上，已經(jīng)實(shí)現(xiàn)了 HTTP 協(xié)議的一些服務(wù)器端和客戶端里就存在上述情況。說不定它們會(huì)與本書介紹的 HTTP 協(xié)議的實(shí)現(xiàn)情況不一樣。文章來源地址http://www.zghlxwxcb.cn/news/detail-614395.html

到了這里，關(guān)于HTTP——一、了解Web及網(wǎng)絡(luò)基礎(chǔ)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！