HTTP協議是什么？

簡單來說，就是一個基于應用層的通信規范：雙方要進行通信，大家都要遵守一個規范，這個規范就是HTTP協議。

HTTP協議能做什么？

很多人首先一定會想到：瀏覽網頁。沒錯，瀏覽網頁是HTTP的主要應用，但是這并不代表HTTP就只能應用于網頁的瀏覽。HTTP是一種協議，只要通信的雙方都遵守這個協議，HTTP就能有用武之地。比如咱們常用的QQ，迅雷這些軟件，都會使用HTTP協議(還包括其他的協議)。

HTTP協議如何工作？

大家都知道一般的通信流程：首先客戶端發送一個請求(request)給服務器，服務器在接收到這個請求后將生成一個響應(response)返回給客戶端。

在這個通信的過程中HTTP協議在以下4個方面做了規定：

1.???????? Request和Response的格式

Request格式：

HTTP請求行
（請求）頭
空行
可選的消息體

注：請求行和標題必須以<CR><LF> 作為結尾（也就是，回車然后換行）。空行內必須只有<CR><LF>而無其他空格。在HTTP/1.1 協議中，所有的請求頭，除Host外，都是可選的。

?

實例：

GET / HTTP/1.1

Host: gpcuster.cnblogs.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

If-Modified-Since: Mon, 25 May 2009 03:19:18 GMT

Response格式：

HTTP狀態行
（應答）頭
空行
可選的消息體

?

實例：

HTTP/1.1 200 OK

Cache-Control: private, max-age=30

Content-Type: text/html; charset=utf-8

Content-Encoding: gzip

Expires: Mon, 25 May 2009 03:20:33 GMT

Last-Modified: Mon, 25 May 2009 03:20:03 GMT

Vary: Accept-Encoding

Server: Microsoft-IIS/7.0

X-AspNet-Version: 2.0.50727

X-Powered-By: ASP.NET

Date: Mon, 25 May 2009 03:20:02 GMT

Content-Length: 12173

?

-消息體的內容（略）

?

?????? 詳細的信息請參考：RFC 2616。

?????? 關于HTTP headers的簡要介紹，請查看：Quick reference to HTTP headers

2.???????? 建立連接的方式

HTTP支持2中建立連接的方式：非持久連接和持久連接(HTTP1.1默認的連接方式為持久連接)。

1)???????? 非持久連接

讓我們查看一下非持久連接情況下從服務器到客戶傳送一個Web頁面的步驟。假設該貝面由1個基本HTML文件和10個JPEG圖像構成，而且所有這些對象都存放在同一臺服務器主機中。再假設該基本HTML文件的URL為：gpcuster.cnblogs.com/index.html。

下面是具體步騾:

1.HTTP客戶初始化一個與服務器主機gpcuster.cnblogs.com中的HTTP服務器的TCP連接。HTTP服務器使用默認端口號80監聽來自HTTP客戶的連接建立請求。

2.HTTP客戶經由與TCP連接相關聯的本地套接字發出—個HTTP請求消息。這個消息中包含路徑名/somepath/index.html。

3.HTTP服務器經由與TCP連接相關聯的本地套接字接收這個請求消息，再從服務器主機的內存或硬盤中取出對象/somepath/index.html，經由同一個套接字發出包含該對象的響應消息。

4.HTTP服務器告知TCP關閉這個TCP連接(不過TCP要到客戶收到剛才這個響應消息之后才會真正終止這個連接)。

5.HTTP客戶經由同一個套接字接收這個響應消息。TCP連接隨后終止。該消息標明所封裝的對象是一個HTML文件。客戶從中取出這個文件，加以分析后發現其中有10個JPEG對象的引用。

6.給每一個引用到的JPEG對象重復步騾1-4。

上述步驟之所以稱為使用非持久連接，原因是每次服務器發出一個對象后，相應的TCP連接就被關閉，也就是說每個連接都沒有持續到可用于傳送其他對象。每個TCP連接只用于傳輸一個請求消息和一個響應消息。就上述例子而言，用戶每請求一次那個web頁面，就產生11個TCP連接。

2)???????? 持久連接

非持久連接有些缺點。首先，客戶得為每個待請求的對象建立并維護一個新的連接。對于每個這樣的連接，TCP得在客戶端和服務器端分配TCP緩沖區，并維持TCP變量。對于有可能同時為來自數百個不同客戶的請求提供服務的web服務器來說，這會嚴重增加其負擔。其次，如前所述，每個對象都有2個RTT的響應延長——一個RTT用于建立TCP連接，另—個RTT用于請求和接收對象。最后，每個對象都遭受TCP緩啟動，因為每個TCP連接都起始于緩啟動階段。不過并行TCP連接的使用能夠部分減輕RTT延遲和緩啟動延遲的影響。

在持久連接情況下，服務器在發出響應后讓TCP連接繼續打開著。同一對客戶/服務器之間的后續請求和響應可以通過這個連接發送。整個Web頁面(上例中為包含一個基本HTMLL文件和10個圖像的頁面)自不用說可以通過單個持久TCP連接發送:甚至存放在同一個服務器中的多個web頁面也可以通過單個持久TCP連接發送。通常，HTTP服務器在某個連接閑置一段特定時間后關閉它，而這段時間通常是可以配置的。持久連接分為不帶流水線(without pipelining)和帶流水線(with pipelining)兩個版本。如果是不帶流水線的版本，那么客戶只在收到前一個請求的響應后才發出新的請求。這種情況下，web頁面所引用的每個對象(上例中的10個圖像)都經歷1個RTT的延遲，用于請求和接收該對象。與非持久連接2個RTT的延遲相比，不帶流水線的持久連接已有所改善，不過帶流水線的持久連接還能進一步降低響應延遲。不帶流水線版本的另一個缺點是，服務器送出一個對象后開始等待下一個請求，而這個新請求卻不能馬上到達。這段時間服務器資源便閑置了。

HTTP/1.1的默認模式使用帶流水線的持久連接。這種情況下，HTTP客戶每碰到一個引用就立即發出一個請求，因而HTTP客戶可以一個接一個緊挨著發出各個引用對象的請求。服務器收到這些請求后，也可以一個接一個緊挨著發出各個對象。如果所有的請求和響應都是緊挨著發送的，那么所有引用到的對象一共只經歷1個RTT的延遲(而不是像不帶流水線的版本那樣，每個引用到的對象都各有1個RTT的延遲)。另外，帶流水線的持久連接中服務器空等請求的時間比較少。與非持久連接相比，持久連接(不論是否帶流水線)除降低了1個RTT的響應延遲外，緩啟動延遲也比較小。其原因在于既然各個對象使用同一個TCP連接，服務器發出第一個對象后就不必再以一開始的緩慢速率發送后續對象。相反，服務器可以按照第一個對象發送完畢時的速率開始發送下一個對象。

3.???????? 緩存的機制

HTTP/1.1中緩存的目的是為了在很多情況下減少發送請求，同時在許多情況下可以不需要發送完整響應。前者減少了網絡回路的數量；HTTP利用一個“過期（expiration）”機制來為此目的。后者減少了網絡應用的帶寬；HTTP用“驗證（validation）”機制來為此目的。

HTTP定義了3種緩存機制：

l Freshness allows a response to be used without re-checking it on the origin server, and can be controlled by both the server and the client. For example, the Expires response header gives a date when the document becomes stale, and the Cache-Control: max-age directive tells the cache how many seconds the response is fresh for.

l Validation can be used to check whether a cached response is still good after it becomes stale. For example, if the response has a Last-Modified header, a cache can make a conditional request using the If-Modified-Since header to see if it has changed.

l Invalidation is usually a side effect of another request that passes through the cache. For example, if URL associated with a cached response subsequently gets a POST, PUT or DELETE request, the cached response will be invalidated.

關于web緩存方面的內容可以參考：Caching Tutorial for Web Authors and Webmasters（英文版）（中文版）

4.???????? 響應授權激發機制

這些機制能被用于服務器激發客戶端請求并且使客戶端授權。

詳細的信息請參考：RFC 2617: HTTP Authentication: Basic and Digest Access

5.??????? 基于HTTP的應用

1 HTTP代理

原理

分類

透明代理

非透明代理

反向代理

2 多線程下載

?

下載工具開啟多個發出HTTP請求的線程

每個http請求只請求資源文件的一部分：Content-Range: bytes 20000-40000/47000

合并每個線程下載的文件

3 HTTPS傳輸協議原理

兩種基本的加解密算法類型

對稱加密：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等

非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等

HTTPS通信過程

優點

?

客戶端產生的密鑰只有客戶端和服務器端能得到

加密的數據只有客戶端和服務器端才能得到明文

客戶端到服務端的通信是安全的

4 開發web程序時常用的Request Methods

HEAD

（Head方法）要求響應與相應的GET請求的響應一樣，但是沒有的響應體（response body）。這用來獲得響應頭（response header）中的元數據信息（meta-infomation）有（很）幫助，（因為）它不需要傳輸所有的內容。

TRACE

（Trace方法告訴服務器端）返回收到的請求。客戶端可以（通過此方法）察看在請求過程中中間服務器添加或者改變哪些內容。

OPTIONS

返回服務器（在指定URL上）支持的HTTP方法。通過請求“*”而不是指定的資源，這個方法可以用來檢查網絡服務器的功能。

CONNECT

將請求的連接轉換成透明的TCP/IP通道，通常用來簡化通過非加密的HTTP代理的SSL-加密通訊（HTTPS）。

5 用戶與服務器的交互

?

身份認證

cookie

帶條件的GET

6 基于Socket編程編寫遵循HTTP的程序

什么是HTTPS： HTTPS（Secure Hypertext Transfer Protocol）安全超文本傳輸協議 它是一個安全通信通道，它基于HTTP開發，用于在客戶計算機和服務器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來說它是HTTP的安全版。 它是由Netscape開發并內置于其瀏覽器中，用于對數據進行壓縮和解壓操作，并返回網絡上傳送回的結果。HTTPS實際上應用了Netscape的安 全全套接字層（SSL）作為HTTP應用層的子層。（HTTPS使用端口443，而不是象HTTP那樣使用端口80來和TCP/IP進行通信。）SSL使 用40 位關鍵字作為RC4流加密算法，這對于商業信息的加密是合適的。HTTPS和SSL支持使用X.509數字認證，如果需要的話用戶可以確認發送者是誰。 HTTPS和HTTP的區別： https協議需要到ca申請證書，一般免費證書很少，需要交費。 http是超文本傳輸協議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議 http和https使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。 http的連接很簡單,是無狀態的 HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議 要比http協議安全 . HTTPS解決的問題： 1 . 信任主機的問題. 采用https 的server 必須從CA 申請一個用于證明服務器用途類型的證書. 改證書只有用于對應的server 的時候,客戶度才信任次主機. 所以目前所有的銀行系統網站,關鍵部分應用都是https 的. 客戶通過信任該證書,從而信任了該主機. 其實這樣做效率很低,但是銀行更側重安全. 這一點對我們沒有任何意義,我們的server ,采用的證書不管自己issue 還是從公眾的地方issue, 客戶端都是自己人,所以我們也就肯定信任該server. 2 . 通訊過程中的數據的泄密和被竄改 1. 一般意義上的https, 就是 server 有一個證書. a) 主要目的是保證server 就是他聲稱的server. 這個跟第一點一樣. b) 服務端和客戶端之間的所有通訊,都是加密的. i. 具體講,是客戶端產生一個對稱的密鑰,通過server 的證書來交換密鑰. 一般意義上的 握手過程. ii. 加下來所有的信息往來就都是加密的. 第三方即使截獲,也沒有任何意義.因為他沒有???????????????????????????????????? 密?????????????????? 鑰.?? 當然竄改也就沒有什么意義了. 2. 少許對客戶端有要求的情況下,會要求客戶端也必須有一個證書. a) 這里客戶端證書,其實就類似表示個人信息的時候,除了用戶名/密碼, 還有一個CA 認證過的身份. 應為個人證書一般來說上別人無法模擬的,所有這樣能夠更深的確認自己的身份. b) 目前少數個人銀行的專業版是這種做法,具體證書可能是拿U盤作為一個備份的載體. HTTPS 一定是繁瑣的. a) 本來簡單的http協議,一個get一個response. 由于???? https 要還密鑰和確認加密算法的需要.單握手就需要6/7 個往返. i. 任何應用中,過多的round trip 肯定影響性能. b) 接下來才是具體的http協議,每一次響應或者請求, 都要求客戶端和服務端對會話的內容做加密/解密. i. 盡管對稱加密/解密效率比較高,可是仍然要消耗過多的CPU,為此有專門的SSL 芯片. 如果CPU 信能比較低的話,肯定會降低性能,從而不能serve 更多的請求.? ii. 加密后數據量的影響. 1. 這個我用128bit 的RC2 測試了一下,加密后數量跟加密前基本相同 符：????????????????????????????? SSL的簡介： SSL是Netscape公司所提出的安全保密協議，在瀏覽器（如Internet Explorer、Netscape Navigator）和Web服務器（如Netscape的Netscape Enterprise Server、ColdFusion Server等等）之間構造安全通道來進行數據傳輸，SSL運行在TCP/IP層之上、應用層之下，為應用程序提供加密數據通道，它采用了RC4、MD5 以及RSA等加密算法，使用40 位的密鑰，適用于商業信息的加密。同時，Netscape公司相應開發了HTTPS協議并內置于其瀏覽器中，HTTPS實際上就是SSL over HTTP，它使用默認端口443，而不是像HTTP那樣使用端口80來和TCP/IP進行通信。HTTPS協議使用SSL在發送方把原始數據進行加密，然 后在接受方進行解密，加密和解密需要發送方和接受方通過交換共知的密鑰來實現，因此，所傳送的數據不容易被網絡黑客截獲和解密。 然而，加密和解密過程需要耗費系統大量的開銷，嚴重降低機器的性能，相關測試數據表明使用HTTPS協議傳輸數據的工作效率只有使用HTTP協議傳輸的十 分之一。??????????????? 假如為了安全保密，將一個網站所有的Web應用都啟用SSL技術來加密，并使用HTTPS協議進行傳輸，那么該網站的性能和效率將會大大降低，而 且沒有這個必要，因為一般來說并不是所有數據都要求那么高的安全保密級別，所以，我們只需對那些涉及機密數據的交互處理使用HTTPS協議，這樣就做到魚 與熊掌兼得。總之不需要用https 的地方,就盡量不要用。

轉載于:https://www.cnblogs.com/tuyile006/archive/2011/02/22/1961679.html

總結

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

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