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