1.IP 協議、TCP 協議和 DNS 服務在使用

HTTP 協議的通信過程中各自發揮了哪些作用

2.HTTP 是無狀態協議

它不對之前發生過的請求和響應的狀態進行管
理。 也就是說， 無法根據之前的狀態進行本次的請求處理。

保留無狀態協議這個特征的同時又要解決類似的矛盾問題， 于是引入
了 Cookie 技術。 Cookie 技術通過在請求和響應報文中寫入 Cookie 信
息來控制客戶端的狀態。
Cookie 會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的
首部字段信息， 通知客戶端保存 Cookie。 當下次客戶端再往該服務器
發送請求時， 客戶端會自動在請求報文中加入 Cookie 值后發送出
去。
服務器端發現客戶端發送過來的 Cookie 后， 會去檢查究竟是從哪一
個客戶端發來的連接請求， 然后對比服務器上的記錄， 最后得到之前
的狀態信息。

3.告知服務器意圖的 HTTP 方法

GET ： 獲取資源
GET 方法用來請求訪問已被 URI 識別的資源。 指定的資源經服務器
端解析后返回響應內容。 也就是說， 如果請求的資源是文本， 那就保持原樣返回； 如果是像 CGI（ Common Gateway Interface， 通用網關接口） 那樣的程序， 則返回經過執行后的輸出結果

POST： 傳輸實體主體
POST 方法用來傳輸實體的主體。
雖然用 GET 方法也可以傳輸實體的主體， 但一般不用 GET 方法進行
傳輸， 而是用 POST 方法。 雖說 POST 的功能與 GET 很相似， 但
POST 的主要目的并不是獲取響應的主體內容

PUT： 傳輸文件
PUT 方法用來傳輸文件。 就像 FTP 協議的文件上傳一樣， 要求在請
求報文的主體中包含文件內容， 然后保存到請求 URI 指定的位置。
但是， 鑒于 HTTP/1.1 的 PUT 方法自身不帶驗證機制， 任何人都可以上傳文件 , 存在安全性問題， 因此一般的 Web 網站不使用該方法。 若配合 Web 應用程序的驗證機制， 或架構設計采用REST（ REpresentational State Transfer， 表征狀態轉移） 標準的同類
Web 網站， 就可能會開放使用 PUT 方法。

HEAD： 獲得報文首部
HEAD 方法和 GET 方法一樣， 只是不返回報文主體部分。 用于確認
URI 的有效性及資源更新的日期時間等。

DELETE： 刪除文件
DELETE 方法用來刪除文件， 是與 PUT 相反的方法。 DELETE 方法按請求 URI 刪除指定的資源。
但是， HTTP/1.1 的 DELETE 方法本身和 PUT 方法一樣不帶驗證機
制， 所以一般的 Web 網站也不使用 DELETE 方法。 當配合 Web 應用程序的驗證機制， 或遵守 REST 標準時還是有可能會開放使用的。

4.請求報文及響應報文的結構

5.通信數據轉發程序 ： 代理、 網關、 隧道

代理
有多種使用方法， 按兩種基準分類。 一種是是否使用緩存， 另一種是是否會修改報文。
(1)緩存代理
代理轉發響應時， 緩存代理（ Caching Proxy） 會預先將資源的副本
（ 緩存） 保存在代理服務器上。當代理再次接收到對相同資源的請求時， 就可以不從源服務器那里獲取資源， 而是將之前緩存的資源作為響應返回。
(2)透明代理
轉發請求或響應時， 不對報文做任何加工的代理類型被稱為透明代理
（ Transparent Proxy） 。 反之， 對報文內容進行加工的代理被稱為非透明代理。

隧道
可按要求建立起一條與其他服務器的通信線路， 屆時使用 SSL等
加密手段進行通信。 隧道的目的是確?？蛻舳四芘c服務器進行安全的
通信。
隧道本身不會去解析 HTTP 請求。 也就是說， 請求保持原樣中轉給之
后的服務器。 隧道會在通信雙方斷開連接時結束。

6.HTTP 的缺點

到現在為止， 我們已了解到 HTTP 具有相當優秀和方便的一面， 然而HTTP 并非只有好的一面， 事物皆具兩面性， 它也是有不足之處的。HTTP 主要有這些不足， 例舉如下。
(1)通信使用明文（ 不加密） ， 內容可能會被竊聽
(2)不驗證通信方的身份， 因此有可能遭遇偽裝
(3)無法證明報文的完整性， 所以有可能已遭篡改

這些問題不僅在 HTTP 上出現， 其他未加密的協議中也會存在這類問
題。除此之外， HTTP 本身還有很多缺點。 而且， 還有像某些特定的 Web服務器和特定的 Web 瀏覽器在實際應用中存在的不足（ 也可以說成是脆弱性或安全漏洞),另外,用 Java 和 PHP 等編程語言開發的
Web 應用也可能存在安全漏洞。

HTTP 加上加密處理和認證以及完整性保護后即是HTTPS
如果在 HTTP 協議通信過程中使用未經加密的明文， 比如在 Web 頁
面中輸入信用卡號， 如果這條通信線路遭到竊聽， 那么信用卡號就暴露了。另外， 對于 HTTP 來說， 服務器也好， 客戶端也好， 都是沒有辦法確認通信方的。 因為很有可能并不是和原本預想的通信方在實際通信。并且還需要考慮到接收到的報文在通信途中已經遭到篡改這一可能性。為了統一解決上述這些問題， 需要在 HTTP 上再加入加密處理和認證等機制。 我們把添加了加密及認證機制的 HTTP 稱為 HTTPS(HTTPSecure).

總結

以上是生活随笔為你收集整理的图解HTTP--笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。