HTTP协议SSL协议HTTPS协议
文章目錄
- 1、HTTP協(xié)議
- 1.1、HTTP 簡介
- 1.2、HTTP 消息結(jié)構(gòu)
- 1.3、HTTP 請求方法
- 1.4、HTTP 響應(yīng)頭信息
- 1.5、HTTP 狀態(tài)碼
- 1.6、HTTP協(xié)議的優(yōu)點與缺點
- 2、SSL
- 2.1、SSL簡介
- 2.2、SSL提供服務(wù)
- 2.3、SSL的體系結(jié)構(gòu)
- 3、HTTPS
- 3.1、HTTPS簡介
- 3.2、HTTPS協(xié)議采用的加密技術(shù)
- 3.3、HTTPS的安全通信機制
- 3.4、HTTPS的證書機制
- 3.5、關(guān)于客戶端證書
- 3.6、為什么還有很多網(wǎng)站不使用Https
1、HTTP協(xié)議
1.1、HTTP 簡介
HTTP協(xié)議是Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫，是用于從萬維網(wǎng)（WWW:World Wide Web ）服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。
HTTP是一個基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)（HTML 文件, 圖片文件, 查詢結(jié)果等）
HTTP 工作原理
- HTTP協(xié)議工作于客戶端-服務(wù)端架構(gòu)之上。瀏覽器作為HTTP客戶端通過URL向HTTP服務(wù)端（即WEB服務(wù)器）發(fā)送所有請求
- Web服務(wù)器有：Apache服務(wù)器，IIS服務(wù)器（Internet Information Services）等
- Web服務(wù)器根據(jù)接收到的請求后，向客戶端發(fā)送響應(yīng)信息
- HTTP默認端口號為80，也可以改為8080或者其他端口
HTTP注意事項：
- HTTP是無連接的 ：無連接的含義是限制每次連接只處理一個請求。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間
- HTTP是媒體獨立的 ：這意味著，只要客戶端和服務(wù)器知道如何處理的數(shù)據(jù)內(nèi)容，任何類型的數(shù)據(jù)都可以通過HTTP發(fā)送。客戶端以及服務(wù)器指定使用適合的MIME-type內(nèi)容類型
- HTTP是無狀態(tài)的 ：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時它的應(yīng)答就較快
以下圖表展示了HTTP協(xié)議通信流程：
1.2、HTTP 消息結(jié)構(gòu)
HTTP是基于客戶端/服務(wù)端（C/S）的架構(gòu)模型，通過一個可靠的鏈接來交換信息，是一個無狀態(tài)的請求/響應(yīng)協(xié)議。
一個HTTP"客戶端"是一個應(yīng)用程序（Web瀏覽器或其他任何客戶端），通過連接到服務(wù)器達到向服務(wù)器發(fā)送一個或多個HTTP請求的目的。
一個HTTP"服務(wù)器"同樣也是一個應(yīng)用程序（通常是一個Web服務(wù)，如Apache Web服務(wù)器或IIS服務(wù)器等），通過接收客戶端的請求并向客戶端發(fā)送HTTP響應(yīng)數(shù)據(jù)。
HTTP使用統(tǒng)一資源標識符（Uniform Resource Identifiers, URI）來傳輸數(shù)據(jù)和建立連接
一旦建立連接后，數(shù)據(jù)消息就通過類似Internet郵件所使用的格式[RFC5322]和多用途Internet郵件擴展（MIME）[RFC2045]來傳送。
客戶端請求消息
客戶端發(fā)送一個HTTP請求到服務(wù)器的請求消息包括以下格式：請求行（request line）、請求頭部（header）、空行和請求數(shù)據(jù)四個部分組成
下圖給出了請求報文的一般格式
服務(wù)器響應(yīng)消息
HTTP響應(yīng)也由四個部分組成，分別是：狀態(tài)行、消息報頭、空行和響應(yīng)正文。
實例
下面實例是一典型的使用GET來傳遞數(shù)據(jù)的實例：
客戶端請求：
GET /hello.txt HTTP/1.1User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3Host: www.example.comAccept-Language: en, mi服務(wù)端響應(yīng):
HTTP/1.1 200 OKDate: Mon, 27 Jul 2009 12:28:53 GMTServer: ApacheLast-Modified: Wed, 22 Jul 2009 19:15:56 GMTETag: "34aa387-d-1568eb00"Accept- Ranges: bytesContent-Length: 51Vary: Accept- EncodingContent-Type: text/plain輸出結(jié)果：
Hello World! My payload includes a trailing CRLF.1.3、HTTP 請求方法
根據(jù)HTTP標準，HTTP請求可以使用多種請求方法
HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
1.4、HTTP 響應(yīng)頭信息
HTTP請求頭提供了關(guān)于請求，響應(yīng)或者其他的發(fā)送實體的信息
| Allow | 服務(wù)器支持哪些請求方法（如GET、POST等） |
| Content-Encoding | 文檔的編碼（Encode）方法。只有在解碼之后才可以得到Content-Type頭指定的內(nèi)容類型。利用gzip壓 縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進行g(shù)zip壓縮，但只有Unix上的 Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet應(yīng)該通過查看Accept-Encoding頭（即request.getHeader(“Accept- Encoding”)）檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經(jīng)gzip壓縮的HTML頁面，為其他瀏覽器返回普通頁面。 |
| Content-Length | 表示內(nèi)容長度。只有當瀏覽器使用持久HTTP連接時才需要這個數(shù)據(jù)。如果你想要利用持久連接的優(yōu)勢，可以把輸出文檔寫入 ByteArrayOutputStram，完成后查看其大小，然后把該值放入Content-Length頭，最后通過 byteArrayStream.writeTo(response.getOutputStream()發(fā)送內(nèi)容。 |
| Date | 當前的GMT時間。你可以用setDateHeader來設(shè)置這個頭以避免轉(zhuǎn)換時間格式的麻煩 |
| Expires | 應(yīng)該在什么時候認為文檔已經(jīng)過期，從而不再緩存它？ |
| Last-Modified | 文檔的最后改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件 GET，只有改動時間遲于指定時間的文檔才會返回，否則返回一個304（Not Modified）狀態(tài)。Last-Modified也可用setDateHeader方法來設(shè)置。 |
| Location | 表示客戶應(yīng)當?shù)侥睦锶ヌ崛∥臋n。Location通常不是直接設(shè)置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設(shè)置狀態(tài)代碼為302。 |
| Refresh | 表示瀏覽器應(yīng)該在多少時間之后刷新文檔，以秒計。除了刷新當前文檔之外，你還可以通過setHeader(“Refresh”, “5; URL=http://host/path”)讓瀏覽器讀取指定的頁面。注 意這種功能通常是通過設(shè)置HTML頁面HEAD區(qū)的＜META HTTP-EQUIV=“Refresh” CONTENT=“5;URL=http://host/path"＞實現(xiàn)，這是因為，自動刷新或重定向?qū)τ谀切┎荒苁褂肅GI或Servlet的 HTML編寫者十分重要。但是，對于Servlet來說，直接設(shè)置Refresh頭更加方便。注意Refresh的意義是"N秒之后刷 新本頁面或訪問指定頁面”，而不是"每隔N秒刷新本頁面或訪問指定頁面"。因此，連續(xù)刷新要求每次都發(fā)送一個Refresh頭，而發(fā)送204狀態(tài)代碼則可 以阻止瀏覽器繼續(xù)刷新，不管是使用Refresh頭還是＜META HTTP-EQUIV=“Refresh” …＞。注意Refresh頭不屬于HTTP 1.1正式規(guī)范的一部分，而是一個擴展，但Netscape和IE都支持它。 |
| Server | 服務(wù)器名字。Servlet一般不設(shè)置這個值，而是由Web服務(wù)器自己設(shè)置 |
| Set-Cookie | 設(shè)置和頁面關(guān)聯(lián)的Cookie。Servlet不應(yīng)使用response.setHeader(“Set-Cookie”, …)，而是應(yīng)使用HttpServletResponse提供的專用方法addCookie。參見下文有關(guān)Cookie設(shè)置的討論。 |
| WWW-Authenticate | 客戶應(yīng)該在Authorization頭中提供什么類型的授權(quán)信息？在包含401（Unauthorized）狀態(tài)行的 應(yīng)答中這個頭是必需的。例如，response.setHeader(“WWW-Authenticate”, “BASIC realm=＼“executives＼””)。注意Servlet一般不進行這方面的處理，而是讓Web服務(wù)器的專門機制來控制受密碼保護頁面的訪問（例如.htaccess） |
1.5、HTTP 狀態(tài)碼
當瀏覽者訪問一個網(wǎng)頁時，瀏覽者的瀏覽器會向網(wǎng)頁所在服務(wù)器發(fā)出請求。當瀏覽器接收并顯示網(wǎng)頁前，此網(wǎng)頁所在的服務(wù)器會返回一個包含HTTP狀態(tài)碼的信息頭（server header）用以響應(yīng)瀏覽器的請求。
HTTP狀態(tài)碼的英文為HTTP Status Code。
下面是常見的HTTP狀態(tài)碼：
- 200 - 請求成功
- 301 - 資源（網(wǎng)頁等）被永久轉(zhuǎn)移到其它URL
- 404 - 請求的資源（網(wǎng)頁等）不存在
- 500 - 內(nèi)部服務(wù)器錯誤
HTTP狀態(tài)碼分類
HTTP狀態(tài)碼由三個十進制數(shù)字組成，第一個十進制數(shù)字定義了狀態(tài)碼的類型，后兩個數(shù)字沒有分類的作用。HTTP狀態(tài)碼共分為5種類型
1.6、HTTP協(xié)議的優(yōu)點與缺點
HTTP協(xié)議的優(yōu)點
- 效率高
限制每個連接只有一個請求的無連接狀態(tài)，在服務(wù)器處理完客戶的請求，并收到客戶的反應(yīng)，即斷開，通過這種方式可以節(jié)省傳輸時間
- 簡單快速
當服務(wù)器客戶端請求服務(wù)時，只需傳送請求方法和路徑。請求方法常用的GET，HEAD，POST。每種方法規(guī)定了客戶端與服務(wù)器聯(lián)系的是不同的類型。因為簡單的 HTTP 協(xié)議，通信速度很快
- 靈活
HTTP 允許任何類型的數(shù)據(jù)對象的傳輸，輸入被傳輸?shù)膬?nèi)容類型進行標記
- 無狀態(tài)
HTTP 協(xié)議是無狀態(tài)的協(xié)議，沒有一個國家是沒有協(xié)議的事務(wù)處理和存儲能力。如果該狀態(tài)是指由于缺乏必要前述信息的后續(xù)處理中，它必須被重傳，這可能導致在數(shù)據(jù)傳輸增加了每個連接。另一方面，當不需要在服務(wù)器上的快速響應(yīng)的先驗信息
HTTP協(xié)議的缺點
有被竊聽的風險，HTTP通信使用明文,傳輸過程中沒有任何的保證措施，可能會被竊聽
在傳輸過程中，不驗證通信方的身份，這中間就有可能被遭遇偽裝
HTTP只是對報文進行了解析，并沒有對其進行完整的校驗，所以無法驗證報文的完整性，可能被遭篡改
2、SSL
2.1、SSL簡介
SSL(Secure Sockets Layer 安全套接字協(xié)議),及其繼任者傳輸層安全（Transport Layer Security，TLS）是為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。TLS與SSL在傳輸層與應(yīng)用層之間對網(wǎng)絡(luò)連接進行加密
2.2、SSL提供服務(wù)
- 認證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務(wù)器
- 加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊取
- 維護數(shù)據(jù)的完整性，確保數(shù)據(jù)在傳輸過程中不被改變
2.3、SSL的體系結(jié)構(gòu)
SSL的體系結(jié)構(gòu)中包含兩個協(xié)議子層
- 底層是SSL記錄協(xié)議層（SSL Record Protocol Layer）
- 高層是SSL握手協(xié)議層（SSL HandShake Protocol Layer）
SSL的協(xié)議棧如圖所示，其中陰影部分即SSL協(xié)議
SSL記錄協(xié)議層的作用是為高層協(xié)議提供基本的安全服務(wù)
SSL記錄協(xié)議針對HTTP協(xié)議進行了特別的設(shè)計，使得超文本的傳輸協(xié)議HTTP能夠在SSL運行
記錄封裝各種高層協(xié)議，具體實施壓縮解壓縮、加密解密、計算和校驗MAC等與安全有關(guān)的操作
SSL握手協(xié)議層包括
- SSL握手協(xié)議（SSL HandShake Protocol）
- SSL密碼參數(shù)修改協(xié)議（SSL Change Cipher Spec Protocol）
- 應(yīng)用數(shù)據(jù)協(xié)議（Application Data Protocol）
- SSL警告協(xié)議（SSL Alert Protocol）
握手層的這些協(xié)議用于SSL管理信息的交換，允許應(yīng)用協(xié)議傳送數(shù)據(jù)之間相互驗證，協(xié)商加密算法和生成密鑰等
SSL握手協(xié)議的作用是協(xié)調(diào)客戶和服務(wù)器的狀態(tài)，使雙方能夠達到狀態(tài)的同步
3、HTTPS
3.1、HTTPS簡介
- HTTPS （全稱：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全為目標的 HTTP 通道
- 在HTTP的基礎(chǔ)上通過傳輸加密和身份認證保證了傳輸過程的安全性
- HTTPS 在HTTP 的基礎(chǔ)下加入SSL，HTTPS 的安全基礎(chǔ)是 SSL，因此加密的詳細內(nèi)容就需要 SSL
- HTTPS 存在不同于 HTTP 的默認端口及一個加密/身份驗證層（在 HTTP與 TCP 之間）
- 這個系統(tǒng)提供了身份驗證與加密通訊方法
- 它被廣泛用于萬維網(wǎng)上安全敏感的通訊，例如交易支付等方面
HTTPS的通信端口由SSL和TSL代替了，它是一種應(yīng)用層協(xié)議
一般情況下HTTP直接和TCP進行通信，當使用了SSL之后，就會變成先和SSL通信，SSL再和TCP進行通信，原理圖如下：
當采用了SSL協(xié)議之后，HTTP協(xié)議就具備了加密、證書、完整性保護三大功能，SSL是獨立于HTTP存在的，是現(xiàn)存的廣泛使用的網(wǎng)絡(luò)安全技術(shù)
3.2、HTTPS協(xié)議采用的加密技術(shù)
SSL采用的加密技術(shù)叫做 “共享密鑰加密”，也叫作 “對稱密鑰加密”
比如客戶端向服務(wù)器發(fā)送一條信息，首先客戶端會采用已知的算法對信息進行加密，比如MD5或者Base64加密，接收端對加密的信息進行解密的時候需要用到密鑰，中間會傳遞密鑰，（加密和解密的密鑰是同一個），密鑰在傳輸中間是被加密的。
這種方式看起來安全，但是仍有潛在的危險，一旦被竊聽，或者信息被挾持，就有可能破解密鑰，而破解其中的信息。因此“共享密鑰加密”這種方式存在安全隱患
非對稱密鑰加密
“非對稱加密”使用的時候有兩把鎖，一把叫做“私有密鑰”，一把是“公開密鑰”
使用非對稱加密的加密方式，服務(wù)器首先告訴客戶端按照自己給定的公開密鑰進行加密處理，客戶端按照公開密鑰加密以后，服務(wù)器接受到信息再通過自己的私有密鑰進行解密，這樣做的好處就是解密的鑰匙根本就不會進行傳輸，因此也就避免了被挾持的風險。就算公開密鑰被竊聽者拿到了，它也很難進行解密，因為解密過程是對離散對數(shù)求值，這可不是輕而易舉就能做到的事
3.3、HTTPS的安全通信機制
非稱加密方式的缺點
公開密鑰加密固然比共享密鑰加密的方式提升了一個檔次，但是它也存在兩個問題：
如何保證接收端向發(fā)送端發(fā)出公開秘鑰的時候，發(fā)送端確保收到的是預(yù)先要發(fā)送的，而不會被挾持。只要是發(fā)送密鑰，就有可能有被挾持的風險
非對稱加密的方式效率比較低，它處理起來更為復(fù)雜，通信過程中使用就有一定的效率問題而影響通信速度
HTTPS采用混合機制的加密方式
HTTPS則綜合了公開密鑰加密和共享密鑰加密的兩種方式，充分利用兩者的優(yōu)勢，在最初連接的時候使用非對稱密鑰的加密方式保證連接的安全性，之后穩(wěn)定的通訊采用對稱加密的方式
穩(wěn)定的通訊是指確保交換的密鑰是安全的
3.4、HTTPS的證書機制
非對稱加密的缺點，其中第一個就是公鑰很可能存在被挾持的情況，無法保證客戶端收到的公開密鑰就是服務(wù)器發(fā)行的公開密鑰。此時就引出了公開密鑰證書機制
數(shù)字證書認證機構(gòu)是客戶端與服務(wù)器都可信賴的第三方機構(gòu)。證書的具體傳播過程如下：
服務(wù)器的開發(fā)者攜帶公開密鑰，向數(shù)字證書認證機構(gòu)提出公開密鑰的申請，數(shù)字證書認證機構(gòu)在認清申請者的身份，審核通過以后，會對開發(fā)者申請的公開密鑰做數(shù)字簽名，然后分配這個已簽名的公開密鑰，并將密鑰放在證書里面，綁定在一起
服務(wù)器將這份數(shù)字證書發(fā)送給客戶端，因為客戶端也認可證書機構(gòu)，客戶端可以通過數(shù)字證書中的數(shù)字簽名來驗證公鑰的真?zhèn)?#xff0c;來確保服務(wù)器傳過來的公開密鑰是真實的。一般情況下，證書的數(shù)字簽名是很難被偽造的，這取決于認證機構(gòu)的公信力。一旦確認信息無誤之后，客戶端就會通過公鑰對報文進行加密發(fā)送，服務(wù)器接收到以后用自己的私鑰進行解密。
3.5、關(guān)于客戶端證書
客戶端證書是進行客戶端認證的，證明服務(wù)器正在通信的客戶端是安全的。但是使用客戶端證書使用存在以下幾個問題：
使用客戶端證書，客戶得自己安裝證書，客戶端證書是需要進行付費購買的，且每張證書對應(yīng)到用戶意味著需要支付用戶數(shù)量對等的費用，這給用戶帶來了間接的問題
客戶端證書存在另一個問題是，客戶端證書只能證明客戶端的存在，而不能證明用戶本人的真實有效
3.6、為什么還有很多網(wǎng)站不使用Https
Https既然如此安全可靠，為什么還有很多WEB網(wǎng)站不使用Https的協(xié)議？這其中的原因有以下幾點：
加密通信會消耗一定的cpu和服務(wù)器資源,如果每次通信都加密，就會消耗更多的資源
如果所有的信息都采用HTTPS加密，這無疑是一種浪費。非敏感信息就算被竊取了，也無傷大雅。可以在其傳輸敏感信息的時候，采用HTTPS協(xié)議進行加密
購買證書的開銷也是一筆很大的費用。向認證機構(gòu)購買證書，證書價格會根據(jù)不同的認證機構(gòu)略有不同，而一般的授權(quán)需要折合人民幣600多元。
【參考鏈接1】
【參考鏈接2-Https協(xié)議簡介】
【百度百科-HTTPS】
總結(jié)
以上是生活随笔為你收集整理的HTTP协议SSL协议HTTPS协议的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： TCP/IP的基本介绍
- 下一篇： 运维的基本知识点及分类工作