16-1-26---圖解HTTP（01）

時間 2019-11-12

標籤圖解 http 欄目 HTTP/TCP 简体版

原文原文鏈接

圖解HTTP
1.4.2確保可靠性的HTTP協議
   按層次分，TCP位於傳輸層，提供可靠的字節流服務
   所謂字節流服務，指爲了方便傳輸，將大塊數據分割成以報文爲單位的數據包進行管理，而可靠的傳輸服務是指，可以把數據準確可靠的傳給對方。
   即TCP協議爲了更加容易傳送大數據才把數據分割，並且TCP協議可以確認數據最終是否送達到對方
   爲了確認無誤地將數據送達目標處，TCP協議採用三次握手策略。握手過程使用了TCP的標誌位，SYN（synchronize）和ACK（acknowledgement）

   發送端首先發送一個帶SYN標誌的數據包給對方，接受端收到後，回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息。最後，發送端在回傳一個帶ACK標誌的數據包，以表明「握手」結束。
   若握手過程當中某個階段莫名中斷，TCP協議會再次以相同的順序發送相同的數據包。

   三次握手
   標有syn的數據包發送給你了
                           明白，我收到你給我發送的數據包了（併發送標有syn/ack的數據包）
   明白，發送標有ack的數據包

   除了三次握手，TCP協議還有其餘手段來保證通訊的可靠性

1.5 負責域名解析的DNS服務
   DNS(Domain Name System) 服務是和HTTP協議同樣位於應用層的協議，它提供域名到IP地址之間的解析服務。
   計算機既能夠被賦予IP地址，也能夠被賦予主機名和域名，好比: www.jrange.com

   DNS協議提供域名查找IP地址，或逆向從IP細緻反查域名的服務
   我想訪問www.jrange.com,把他的域名告訴我吧
                                       www.jrange.com對應的IP地址是20x.189.103.xxx
   向 20x.189.103.xxx 發送訪問請求

1.6 各類協議與HTTP協議的關係
   這裏須要補一張圖，《圖解HTTP》P.31
1.7 URI & URL
   URI（Uniform-規定統一的格式方便處理多種不一樣類型的資源，而不用根據上下文環境來識別資源指定的訪問方式，加入新增的協議方案也更加容易
           Resource-定義是「能夠標識任何東西」，除了文檔文件、圖像或服務等能後區別於其餘類型的，所有均可以做爲資源。資源不只能夠是單一的，也能夠是多數的集合體
           Identifier0表示可標識的對象，也稱爲標識符）統一資源標識符
           綜上，URI就是由某個協議方案表示的資源的定位標識符
           協議方案是指訪問資源所使用的協議類型名稱
           採用HTTP協議時，協議方案就是http。除此以外，還有ftp，mailto，telnet，file等。
           URI用字符串標識某一互聯網資源
   URL（）統一資源定位符，表示資源的地點（互聯網上所處的位置，）

   http://user:pass@www.example.jp:80/dir/index.htm?uid=1#ch1
   使用http: 或者 https: 等協議方案名獲取訪問資源時要指定協議類型。不區分大小寫，最後附上一個冒號（:）

   登陸信息（認證）指定用戶名和密碼做爲從服務器端獲取訪問資源時必要的登陸信息（身份認證）
   服務器地址使用絕對URI必須指定待訪問的服務器地址。地址能夠是相似 DNS可解析的名稱，或者是192.168.1.1這類IPv4地址名，也能夠是[0:0:0:0:0:0:0:0:1]這樣的IPv6地址名
   服務器端口號指定服務器鏈接的網絡端口號。用戶省略則自動使用默認端口號
   帶層次的文件路徑指定服務器上的文件路徑來定位特指的資源。與unix系統的文件目錄相似
   查詢字符串針對已經指定的文件路徑內的資源，可使用查詢字符串傳入任意參數
   片斷標識使用片斷標識符一般能夠標記出已獲取資源中的子資源

注意並非全部的應用程序都符合RFC
   一些用來制定HTTP協議技術標準的文檔，他們被稱爲RFC Request for Comments 徵求修正意見書


第二章簡單的HTTP協議

2.1 HTTP協議用於客戶端和服務器端之間的通訊
   HTTP協議和TCP/IP協議族內的其餘衆多的協議相同，用於客戶端和服務器之間的通訊
   請求訪問文本或圖像等資源的一端稱爲客戶端，而提供資源響應的一端稱爲服務器端

   HTTP協議規定，請求從客戶端發出，最後服務器端響應該請求並返回。確定是先從客戶端開始創建通訊，服務器端在沒有收到請求以前不會作出反應
   (1)發送請求
               GET / HTTP/1.1
               Host: jrange.com
                           (2)發送響應
                                   HTTP/1.1 200 OK
                                   Date: Tue, 10 Jul 2012 06:50:15 GMT
                                   Content-Length: 362
                                   Content-Type: text/html
                                   <html>
                                   。。。
   GET /index.htm HTTP/1.1
   Host: jrange.com

   起始行開頭的GET表示請求訪問服務器的類型，稱爲方法。隨後的字符串/index.htm指明瞭請求訪問的資源對象，也叫做請求URI（request-URI）.
   這段請求內容的意思是：請求訪問某臺HTTP服務器上的/index.htm的頁面資源
   請求報文是由請求方法、請求URI、協議版本、可選的請求首部字段和內容實體構成。

   POST /form/entry HTTP/1.1
   方法 URI          協議版本

   Host:jrange.com
   Conntection: keep-alive
   Content-Type: application/x-www-form-urlencoded
   Content-Length: 16
   請求首部字段

   name=ueno&age=37
   內容實體

   接收到請求的服務器會將請求內容的處理結果以響應的形式返回。
   HTTP/1.1 200     OK
   協議版本狀態碼狀態碼的緣由短語

   Date: Tue, 10 Jul 2012 06:50:15 GMT
   Content-Length: 362
   Content-Type: text/html
   響應首部字段

   <html>
   ...
   主體

   在起始行開頭的 HTTP/1.1表示服務器對應的HTTP版本。
   緊挨着的200 OK 表示請求的處理結果的狀態碼（status code）和緣由短語（reason-phrase）下一行顯示了建立響應的日期和時間，是首部字段內的一個屬性。
   接着以一空行進行分割，以後的內容稱爲資源實體的主體（entity body）

   響應報文基本上由協議版本、狀態碼（表示請求成功或者失敗的數字代碼）、用以解釋狀態碼的緣由短語、可選的響應首部字段以及實體主體構成。

2.3 HTTP是不保存狀態的協議
   HTTP是一種不保存狀態，即無狀態協議。HTTP協議自身不對請求和響應之間的通訊狀態進行保存。也就是說，在HTTP這個級別，協議對於發送過的請求或響應不作持久化處理
   使用HTTP協議，每當有新的請求發送時，就會有對應的新的響應產生，協議自己不對以前的一切請求或響應進行保存。
   這是爲了更加快速的處理大量事務，確保協議的可伸縮性，特地把HTTP協議設計的如此簡單。

   雖然HTTP/1.1 雖然是無狀態協議，可是爲了實現指望保持的狀態功能，引入Cookie技術
2.4請求URI定位資源
   HTPP協議使用URI定位互聯網上的資源。當客戶端請求訪問資源而發送請求時，URI須要將做爲請求報文中的請求URI包含在內。
   完整的請求URI
       GET http://jrange.com/index.htm HTTP/1.1

       在首部字段host中寫明網絡域名或者IP域名
       GET /index.htm HTTP/1.1
       Host: jrange.com

       除此以外，若是不是訪問特定資源而是對服務器自己發起請求，能夠用一個 * 來代替請求URI。
       OPTIONS * HTTP/1.1

2.5 告知服務器意圖的HTTP方法
GET 獲取資源
   用來請求訪問已被URI識別的資源，指定的資源經服務器端解析後返回響應的內容。也就是說，若是請求的資源是文本，就原樣返回；若是是像是GCI （通用網關接口）那樣的程序，則返回通過執行後的輸出結果
POST 傳輸實體主體
   雖然用GET方法也能夠傳輸實體，可是通常不用GET方法進行傳輸，而是用POST方法。雖然說POST方法的功能和GET方法很類似，可是POST的方法主要目的並非獲取響應的主體實體。
PUT 傳輸文件
   就像FTP協議的文件上傳同樣，要求在請求報文的主題中包含文件內容，而後保存到請求URI指定的位置。
   可是鑑於PUT方法本事不帶驗證機制，任何人均可以上傳文件，存在安全性問題，所以通常WEB網站不用該方法。若配合Web應用程序的驗證機制，或架構設計採用REST標準的同類網站，就可能開放PUT的用法。
HEAD 得到報文首部
   HEAD方法和GET方法同樣，只是不返回報文的主體部分。用於確認URI的有效性及資源更新的日期時間等。
   返回資源有關的響應首部
DELETE 刪除文件
   用來刪除文件，與PUT相反的方法。一樣是不帶驗證機制，因此通常也不開通。
OPTIONS 詢問支持的方法
   用來查詢針對請求URI指定的資源支持的方法（返回服務器支持的方法，如GET、POST、HEAD、OPTIONS）
TRACE 追蹤路徑
   讓服務器端將以前的請求通訊環回給客戶端的方法
   發送請求時，在Max-Forwards首部字段中填入數值，每通過一個服務器該數字就減一，當數值恰好減到0時，就中止繼續傳輸，最後接受到請求的服務器則返回狀態碼 200 OK 的響應。
   TRACE通常不經常使用，並且容易引起XST（跨站追蹤）攻擊，因此就更加不經常使用了（！！從代理服務器路由中轉時，原請求可能被篡改！！）
CONNECT 要求用隧道協議鏈接代理
   方法要求自代理服務器通訊時創建隧道，實現用隧道協議進行TCP通訊。主要用SSL（Secure Sockets Layer 安全套接層）和TLS（Transport Layer Security 傳輸層安全）協議把通訊內容加密後經網絡隧道傳輸。
   CONNECT 代理服務器名：端口號 HTTP版本
   例子：
   request
       CONNECT proxy.jrange.com HTTP/1.1
       Host: proxy.jrange.com
   response
       HTTP/1.1 200 OK(以後進入隧道)
2.6 使用方法下達命令
向請求URI指定的資源發送請求報文是，採用稱爲方法的命令。方法的做用在於，能夠指定請求的資源定期望產生某種行爲。
2.7持久鏈接節省通訊流量
HTTP協議的初始版本中，每進行一次HTTP通訊就要斷開一次TCP鏈接。
   TCP創建鏈接
       SYN
               SYN/ACK
       ACK
       HTTP請求
               HTTP響應
               FIN
       ACK
       FIN
               ACK
               斷開TCP鏈接
   2.7.1持久鏈接
       爲了解決上述TCP鏈接的問題，HTTP/1.1 和一部分的 HTTP/1.0   想出了持久鏈接（HTTP Persistent Connections 也稱爲HTTP keep-alive 或者 HTTP connection reuse）
       持久的特色是，沒有哪一端提出斷開鏈接，則保持TCP鏈接狀態。
       優勢：減小了TCP鏈接的重複創建和斷開形成的額外開銷，減輕了服務器端的負載。另外，減小開銷的那部分時間，是HTTP請求和響應可以更早地結束，這樣WEB頁面的顯示速度也就相應提升
       毫無疑問，除了服務器端，客戶端也須要支持持久化鏈接
   2.7.2 管線化
       持久鏈接使得多數請求以管線化方式發送成爲可能。從前發送請求後，須要等待並接受到響應才能發送下一個請求，如今不用等待響應即發送請求
       這樣就能夠並行發送多個請求，不須要一個接一個地等待響應了。
2.8   使用Cookie的狀態管理
   Cookie技術經過請求和響應報文中寫入Cookie信息來控制客戶端的狀態。
   Cookie會根據服務器段發送的響應報文內的一個叫作Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入Cookie值後發送回去。
   服務器端發現客戶端發送過來的Cookie後，回去檢查到底是從哪一個客戶端發送來的鏈接請求，而後對比服務器上的記錄，最後獲得以前的狀態信息。

第三章 HTTP報文內的HTTP信息
3.1HTTP報文
   用於HTTP協議交互的信息被稱爲HTTP報文，請求端的HTTP報文叫作請求報文，響應端的報文叫作響應報文。
   HTTP報文是由多行（用CR+LF作換行符）數據構成的字符串文本
3.2請求報文及響應報文的結構
   請求行包含請求的方法，請求URI和HTTP版本
   狀態行包含代表響應結果的狀態碼，緣由短語和HTTP版本
   首部字段包含請求和響應的各類條件和屬性的各種首部   通常有4種首部字段，通訊首部、請求首部、響應首部、實體首部
   其餘。可能包含HTTP的RFC裏未定義的首部（Cookie等）
3.3編碼提高傳輸速率
經過在傳輸時編碼，能有效地處理大量的訪問請求，可是，編碼的操做須要計算機來完成，所以會消耗更多的CPU資源。
   3.3.1報文主體和實體主體的差別
   報文
       是HTTP通訊中的基本單位，有8位字節流組成（octet sequence 其中octet爲8個比特）組成，經過HTTP通訊傳輸
   實體
       做爲請求或者響應的有效載荷數據（補充項）被傳輸，其內容是有實體首部和實體主體構成。
   3.3.2 壓縮傳輸的內容編碼
       內容編碼是指明應用在實體內容上的編碼格式，並保持實體信息原樣壓縮。內容編碼後的實體由客戶端接收並負責解碼。
       經常使用的內容編碼有如下幾種
           gzip GUN zip
           compress UNIX系統的標準編碼
           deflate zlib
           identity 不進行編碼
   3.3.3 分割發送的分塊傳輸編碼
       在HTTP通訊中，請求的編碼實體資源還沒有所有傳輸完成以前，瀏覽器沒法顯示請求桌面。在傳輸大容量數據時，經過把數據分割成多塊，可以讓瀏覽器逐步顯示頁面
       這種把實體主體分塊的功能稱爲分塊傳輸編碼（Chunked Transfer Coding）
       使用分塊編碼的實體主體會有接受客戶端負責解碼，恢復到編碼前的實體主體
3.4 發送多種數據的多部分對象集合
       發送郵件時，咱們能夠在郵件裏寫入文字並添加多分附件。這是由於採用了MIME（Multipurpose Internet Mail Extensions 多用途因特網郵件擴展機制），它容許郵件處理文本、圖片、視頻等多個不一樣類型的數據。
       相應的，HTTP協議也採納了多部分對象集合，發送一份報文主體能夠包含多種類型實體，一般是在圖片或文本文件等上傳時使用。
       多部分對象集合包含的對象以下：
           multipart/form-data
               在web表單文件上傳時使用
           multipart/byteranges
               狀態碼206（Partial Content，部份內容）響應報文包含了讀個範圍的內容時使用。
           在HTTP報文中使用了多部分對象集合時，須要在首部字段里加上Content-type
           使用boundary字符串來劃分多部分對象集合指明的各種實體。在boundary字符串指定的各個實體的起始行以前插入「--」標記，而在多部分對象集合對應的字符串的最後插入「--」標記做爲結束。
3.5獲取部份內容的範圍請求
要實現該功能須要指定下載實體的範圍。像這樣指定範圍發送的請求叫作範圍請求Range Request
   GET /tip.jpg HTTP/1.1
   Host: www.jrange.com
   Range: bytes = 5001-10000

   Range: bytes = 5001-
   Range: bytes = -3000l, 5000-7000
   針對範圍請求，響應會返回狀態碼爲206 的響應報文。應爲，對於多重範圍的範圍請求，響應會在首部字段Content-Type 代表multipart/byteranges後返回響應報文
   若是服務器端沒法響應範圍請求，則會在狀態碼200 OK 和完整的實體內容
3.6 內容協商返回最合適的內容
當瀏覽器的默認語言爲英文時，訪問相同的URI的WEB頁面時，則會顯示對應的英文版的WEB頁面，這樣的機制稱爲內容協商。
內容協商機制是指客戶端和服務器端就響應的資源內容進行交涉，而後提供給客戶端最爲合適的資源。內容協商會以響應資源的語言，字符集、編碼方式等做爲判斷標準。
   Accept
   Accept-Charset
   Accept-Encoding
   Accept-Language
   Content-Language
   服務器驅動協商（Server-driven Negotiation）
       由服務器端進行內容協商，以請求的首部字段爲參考，在服務器端自動處理。
   客戶端驅動協商（Agent-driven Negotiation）
       有客戶端進行內容協商的方式，用戶從瀏覽器顯示的可選項列表中手動選擇。還能夠利用JavaScript腳本在Web頁面上自動進行選擇。
   透明協商（Transparent Negotiation）
       服務器端和客戶端驅動結合體，是由服務器端和客戶端各自進行內容協商的一種方法。html

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。