當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

《图解HTTP》第一章个人学习思考

發(fā)布時間：2024/3/24 编程问答 67 豆豆

生活随笔收集整理的這篇文章主要介紹了《图解HTTP》第一章个人学习思考小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

第一章了解Web及其網(wǎng)絡(luò)基礎(chǔ)
1.1使用HTTP協(xié)議訪問Web
1.2HTTP的誕生
1.3網(wǎng)絡(luò)基礎(chǔ)TCP/IP
1.4和HTTP相關(guān)協(xié)議：IP\TCP和DNS
1.5負責域名解析的DNS服務(wù)
1.6各種協(xié)議和HTTP協(xié)議的關(guān)系
1.7URI和URL
——————————————————
心得：
HTTP為知識共享而誕生的協(xié)議，屬于TCP/IP協(xié)議族里的協(xié)議之一。
我們?yōu)g覽web時候web是如何實現(xiàn)的？數(shù)據(jù)怎么傳的？網(wǎng)絡(luò)是如何通信的呢？

利用 TCP/IP 協(xié)議族進行網(wǎng)絡(luò)通信時，會通過分層順序與對方進行通信。發(fā)送端從應(yīng)用層往下走，接收端則往應(yīng)用層往上走。
HTTP這個應(yīng)用層協(xié)議和其他層的協(xié)議之間是什么一種關(guān)系？

1.1使用HTTP協(xié)議訪問Web

網(wǎng)頁瀏覽器（Web Browser）的地址里輸入URL，web頁面如何呈現(xiàn)？
根據(jù)web瀏覽器制定的地址欄的url，從瀏覽器向服務(wù)器端獲取文件資源等信息，從而顯示在web頁面。

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

1.2 HTTP誕生

1989 年 3 月，互聯(lián)網(wǎng)還只屬于少數(shù)人。在這一互聯(lián)網(wǎng)的黎明期，HTTP 誕生了。CERN（歐洲核子研究組織）的蒂姆 ? 伯納斯 - 李（Tim BernersLee）博士提出了一種能讓遠隔兩地的研究者們共享知識的設(shè)想。最初設(shè)想的基本理念是：借助多文檔之間相互關(guān)聯(lián)形成的超文本（HyperText），連成可相互參閱的 WWW（World Wide Web，萬維網(wǎng)）。現(xiàn)在已提出了 3 項 WWW 構(gòu)建技術(shù)，分別是：把 SGML（Standard Generalized Markup Language，標準通用標記語言）作為頁面的文本標記語言的 HTML（HyperText Markup Language，超文本標記語言）；作為文檔傳遞協(xié)議的 HTTP ；指定文檔所在地址的 URL（Uniform Resource Locator，統(tǒng)一資源定位符）。
HTTP/0.9
HTTP 于 1990 年問世。那時的 HTTP 并沒有作為正式的標準被建立。現(xiàn)在的 HTTP 其實含有 HTTP1.0 之前版本的意思，因此被稱為HTTP/0.9。
HTTP/1.0
HTTP 正式作為標準被公布是在 1996 年的 5 月，版本被命名為HTTP/1.0，并記載于 RFC1945。雖說是初期標準，但該協(xié)議標準至今仍被廣泛使用在服務(wù)器端。
HTTP/1.1
1997 年 1 月公布的 HTTP/1.1 是目前主流的 HTTP 協(xié)議版本。當初的標準是 RFC2068，之后發(fā)布的修訂版 RFC2616 就是當前的最新版本。

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

TCP/IP 協(xié)議族
計算機與網(wǎng)絡(luò)設(shè)備要相互通信，雙方就必須基于相同的方法。比如，如何探測到通信目標、由哪一邊先發(fā)起通信、使用哪種語言進行通信、怎樣結(jié)束通信等規(guī)則都需要事先確定。不同的硬件、操作系統(tǒng)之間的通信，所有的這一切都需要一種規(guī)則。而我們就把這種規(guī)則稱為協(xié)議（protocol）。
TCP/IP 是互聯(lián)網(wǎng)相關(guān)各類協(xié)議族的總稱
**協(xié)議中存在各式各樣的內(nèi)容。**從電纜的規(guī)格到 IP 地址的選定方法、尋找異地用戶的方法、雙方建立通信的順序，以及 Web 頁面顯示需要處理的步驟，等等。

TCP/IP分層管理
TCP/IP 協(xié)議族按層次分別分為以下 4 層：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層。

TCP/IP 層次化是有好處的。

如果互聯(lián)網(wǎng)只由一個協(xié)議統(tǒng)籌，某個地方需要改變設(shè)計時，就必須把所有部分整體替換掉。而分層之后只需把變動的層替換掉即可。把各層之間的接口部分規(guī)劃好之后，每個層次內(nèi)部的設(shè)計就能夠自由改動了。

設(shè)計網(wǎng)絡(luò)時候，從各個層逐一設(shè)置。

應(yīng)用層：
應(yīng)用層決定了向用戶提供應(yīng)用服務(wù)時通信的活動。TCP/IP 協(xié)議族內(nèi)預(yù)存了各類通用的應(yīng)用服務(wù)。比如，FTP（File Transfer Protocol，文件傳輸協(xié)議）和 DNS（Domain Name System，域名系統(tǒng)）服務(wù)就是其中兩類。HTTP 協(xié)議也處于該層。

傳輸層：
傳輸層對上層應(yīng)用層，提供處于網(wǎng)絡(luò)連接中的兩臺計算機之間的數(shù)據(jù)傳輸。在傳輸層有兩個性質(zhì)不同的協(xié)議。TCP（Transmission Control Protocol，傳輸控制協(xié)議）和 UDP（User Data Protocol，用戶數(shù)據(jù)報協(xié)議）。

網(wǎng)絡(luò)層（網(wǎng)絡(luò)互連層）：
網(wǎng)絡(luò)層用來處理在網(wǎng)絡(luò)上流動的數(shù)據(jù)包。數(shù)據(jù)包是網(wǎng)絡(luò)傳輸?shù)淖钚?shù)據(jù)單位，該層規(guī)定了通過怎樣的路徑（所謂的傳輸路線）到達對方計算機，并把數(shù)據(jù)包傳送給對方。
和對方計算機之間通過多臺計算機或網(wǎng)絡(luò)設(shè)備進行傳輸時，網(wǎng)絡(luò)層所起的作用就是在眾多的選項內(nèi)選擇一條傳輸路線。

鏈路層（又名數(shù)據(jù)鏈路層，網(wǎng)絡(luò)接口層）
用來處理連接網(wǎng)絡(luò)的硬件部分。包括控制操作系統(tǒng)、硬件的設(shè)備驅(qū)動、NIC（Network Interface Card，網(wǎng)絡(luò)適配器，即網(wǎng)卡），及光纖等物理可見部分（還包括連接器等一切傳輸媒介）。硬件上的范疇均在鏈路層的作用范圍之內(nèi)。

利用 TCP/IP 協(xié)議族進行網(wǎng)絡(luò)通信時，會通過分層順序與對方進行通信。發(fā)送端從應(yīng)用層往下走，接收端則往應(yīng)用層往上走。

HTTP舉例
1、作為發(fā)送端的客戶端在應(yīng)用層（HTTP協(xié)議）發(fā)出想看某個Web頁面的HTTP請求。
2、在傳輸層（TCP協(xié)議）（HTTP請求報文）進行分割，并在各個報文上打上標記序號及端口號轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層。
3、在網(wǎng)絡(luò)層（IP協(xié)議），增加作為通信目的地的MAC地址后轉(zhuǎn)發(fā)給鏈路層。
4、接收端的服務(wù)器在鏈路層接收到數(shù)據(jù)，按順序往上層發(fā)送，一直到應(yīng)用層，當傳輸?shù)綉?yīng)用層，才真正接收到由客戶端發(fā)送來的HTTP請求。

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

協(xié)議及其對應(yīng)的層：
HTTP協(xié)議/DNS協(xié)議，應(yīng)用層
TCP協(xié)議，傳輸層
IP協(xié)議，網(wǎng)絡(luò)層

1.4.1 負責傳輸?shù)腎P協(xié)議

IP（Internet Protocol，因特網(wǎng)協(xié)議），網(wǎng)際協(xié)議位于網(wǎng)絡(luò)層。TCP/IP協(xié)議族里的IP指的就是網(wǎng)際協(xié)議，“IP”和“IP 地址”別搞混，“IP”其實是一種協(xié)議的名稱。
**IP協(xié)議作用——把各種數(shù)據(jù)包傳送給對方。保證確實傳送到對方那里。 **

問題：如何做到正確的傳輸給對方它所需要的數(shù)據(jù)呢？

第一個條件：IP地址

第二個條件：MAC地址（Media Access Control Address）

IP地址指明節(jié)點被分配到的地址，MAC地址是指網(wǎng)卡所屬的固定地址。IP地址和MAC地址進行配對。IP地址可變換，但是MAC地址基本上不改變。（使用 ARP 協(xié)議憑借 MAC 地址進行通信）

**IP間的通信依賴MAC地址。**在網(wǎng)絡(luò)上，通信的雙方在同一局域網(wǎng)（LAN）內(nèi)的情況是很少的，通常是經(jīng)過多臺計算機和網(wǎng)絡(luò)設(shè)備中轉(zhuǎn)才能連接到對方。而在進行中轉(zhuǎn)時，會利用下一站中轉(zhuǎn)設(shè)備的 MAC地址來搜索下一個中轉(zhuǎn)目標。這時，會采用 ARP 協(xié)議（AddressResolution Protocol）。ARP 是一種用以解析地址的協(xié)議，根據(jù)通信方的 IP 地址就可以反查出對應(yīng)的 MAC 地址。

在到達通信目標前中轉(zhuǎn)過程里，計算機和路由器等網(wǎng)絡(luò)設(shè)備獲悉傳輸路線的機制稱為路由選擇。（routing） 幫助記憶：寄件人發(fā)件，快遞公司收件到貨物集散中心然后派件中轉(zhuǎn)，達到收件人所在區(qū)域在層層分發(fā)直到到達地址。

1.4.2 確保可靠性的TCP協(xié)議
按層次分，TCP 位于傳輸層，提供可靠的字節(jié)流服務(wù)。
字節(jié)流服務(wù)（Byte Stream Service）是指，為了方便傳輸，將大塊數(shù)據(jù)分割成以報文段（segment）為單位的數(shù)據(jù)包進行管理。而可靠的傳輸服務(wù)是指，能夠把數(shù)據(jù)準確可靠地傳給對方。一言以蔽之，TCP 協(xié)議為了更容易傳送大數(shù)據(jù)才把數(shù)據(jù)分割，而且 TCP 協(xié)議能夠確認數(shù)據(jù)最終是否送達到對方。

如何實現(xiàn)數(shù)據(jù)包傳輸?shù)秸_的目標呢？

字節(jié)流服務(wù)方便傳輸

三次握手（three-way handshaking）策略。
用 TCP 協(xié)議把數(shù)據(jù)包送出去后，TCP不會對傳送后的情況置之不理，它一定會向?qū)Ψ酱_認是否成功送達。握手過程中使用了 TCP 的標志（flag） —— SYN（synchronize）和ACK（acknowledgement）。

其他手段

發(fā)送端首先發(fā)送一個帶 SYN 標志的數(shù)據(jù)包給對方。接收端收到后，回傳一個帶有 SYN/ACK 標志的數(shù)據(jù)包以示傳達確認信息。最后，發(fā)送端再回傳一個帶 ACK 標志的數(shù)據(jù)包，代表“握手”結(jié)束。若在握手過程中某個階段莫名中斷，TCP 協(xié)議會再次以相同的順序發(fā)送相同的數(shù)據(jù)包。

1.5 負責域名解析的DNS服務(wù)

DNS(Domain Name System)服務(wù)是和HTTP協(xié)議一樣位于應(yīng)用層的協(xié)議，是提供域名到IP地址時間的解析服務(wù)。

DNS協(xié)議提供通過域名查找IP地址，或者逆向從IP地址反查域名的服務(wù)。

計算機可以被賦予IP地址，也可以被賦予主機名和域名。**用戶通常使用主機名或域名來訪問對方的計算機，**而不是直接通過 IP地址訪問。因為與 IP 地址的一組純數(shù)字相比，用字母配合數(shù)字的表示形式來指定計算機名更符合人類的記憶習(xí)慣。計算機通常通過純數(shù)字的IP地址來訪問

1.6 各種協(xié)議和HTTP協(xié)議的關(guān)系

IP 協(xié)議、TCP 協(xié)議和 DNS 服務(wù)在使用HTTP 協(xié)議的通信過程中各自發(fā)揮了哪些作用？

1.7 URI和URL

URI，統(tǒng)一資源標識符
URL，統(tǒng)一資源定位符
URI是用字符串標識的某一互聯(lián)網(wǎng)資源，URL表示資源的地點（互聯(lián)網(wǎng)上所處的位置），URL是URI的子集。

1.7.1 URI——Uniform Resource Identifier
Uniform：規(guī)定統(tǒng)一的格式可方便處理多種不同類型的資源，而不是根據(jù)上下文環(huán)境來識別資源指定的訪問方式。
Resource：定義“可識別的任何東西”，除了文檔文件、圖像或服務(wù)（如當天天氣預(yù)報）外可以區(qū)別于其他類型的，全都可作為資源。
Identifier：表示可標識的對象，也稱為標識符。
URI 就是由某個協(xié)議方案表示的資源的定位標識符。協(xié)議方案是指訪問資源所使用的協(xié)議類型名稱。

1.7.2 URI格式
表示指定的URI，要使用涵蓋全部必要信息的絕對URI、絕對URL以及相對URL.
相對URL是指從瀏覽器中基本URI處指定的URL，如/image/logo.gif。

http: 或 https: 等協(xié)議方案名獲取訪問資源時要指定協(xié)議類型。不區(qū)分字母大小寫，最后附一個冒號（:）。
1、登入信息（認證）指定用戶名和密碼作為從服務(wù)端獲取資源時必要的登入信息（身份認證）
2、服務(wù)器地址：使用絕對URI必須指定訪問的服務(wù)器地址。地址可以是類似hackr.jp 這種 DNS 可解析的名稱，或是 192.168.1.1 這類 IPv4 地址名，還可以是 [0:0:0:0:0:0:0:1] 這樣用方括號括起來的 IPv6 地址名。
3、服務(wù)器端口號：
指定服務(wù)器連接的網(wǎng)絡(luò)端口號。是可選項，用戶省略則自動使用默認端口號。
4、帶層次的文件路徑：
指定服務(wù)器上的文件路徑來定位特指的資源。
5、查詢字符串：
針對已指定的文件路徑內(nèi)的資源，可以使用查詢字符串傳入任意參數(shù)，此項可選。
6、片段標識符
使用片段標識符通常可標記處已獲取資源里的子資源（文檔內(nèi)的某個位置）。但在 RFC 中并沒有明確規(guī)定其使用方法。該項也為可選項。

RFC（Request for Comments，征求修正意見書）

通常，應(yīng)用程序會遵照由 RFC 確定的標準實現(xiàn)。可以說，RFC 是互聯(lián)網(wǎng)的設(shè)計文檔，要是不按照 RFC 標準執(zhí)行，就有可能導(dǎo)致無法通信的狀況。比如，有一臺 Web 服務(wù)器內(nèi)的應(yīng)用服務(wù)沒有遵照RFC 的標準實現(xiàn)，那 Web 瀏覽器就很可能無法訪問這臺服務(wù)器了。
由于不遵照 RFC 標準實現(xiàn)就無法進行 HTTP 協(xié)議通信，所以基本上客戶端和服務(wù)器端都會以 RFC 為標準來實現(xiàn) HTTP 協(xié)議。但也存在某些應(yīng)用程序因客戶端或服務(wù)器端的不同，而未遵照 RFC 標準，反而將自成一套的“標準”擴展的情況。