HTTP協議主要應用是在服務器和客戶端之間，客戶端接受超文本。
服務器按照一定規則，發送到客戶端（一般是浏覽器）的傳送通信協議。與之類似的還有文件傳送協議(file transfer protocol,FTP)，簡單郵件傳送協議(simple mail ttransfer protocol,SMTP)等。
HTTP是在七層網絡模型中的應用層的協議，由發送請求和接受響應構成，是一個標准的客戶端服務器模型。與此同時，HTTP是一個無狀態的協議。也就是說，不能通過一個狀態判斷連接的狀態，因此有時候，計算機之間通信需要通過其他協議來協同工作，一起提供支持。
相對於其他網路傳輸協議，HTTP有著自己的特點，這也支撐了HTTP協議的基本職能。
（1）基於B/S 模式，即客戶/服務器模式。同時可以提供登陸認證和網間安全傳輸，例如HTTP下加入SSL層，可以提供安全的HTTPS服務。
（2）通信開銷小，簡單快速，傳輸成本低。服務器請求某些一定的服務時，浏覽者通常只需在請求報文中添加請求路徑和方法。最一般的情形，例如GET、HEAD、POST等，這也是我們使用最多的。
每一種請求方法都有自己的適用范圍，在請求報文的內部，通過一些規則，說明了用戶與Web服務器之間溝通的類型。同時，HTTP協議規則較為簡單，因此使用HTTP服務器的系統，代碼和程序規模都會比較輕量級，但是通信的速度卻效率較高。
（3）使用靈活：超文本協議，允許服務器和客戶端傳輸任意類型或者任意數據結構的數據對象。而且，通過一個簡單的頭信息，例如將正在傳輸的類型由Content-Type加以標記，於是可以區分開。
（4）節省傳輸時間：最初版本的HTTP協議使用非持續連接，只允許發送並處理一個連接，當請求響應完成，也就是服務器完成客戶端的請求，同時收到了客戶端浏覽器的應答後，連接會立即斷開。有了這種特點，通信方式節省了大量用於數據傳輸和等待應答的時間，時間成本變得非常小。
同時，高版本HTTP協議，HTTP 1.1支持持續連接：多個對象可以通過一個連接可傳送，不需要每次傳輸一個web對象就去創建一個新的連接。
（5）可能影響傳輸效率，無狀態：HTTP協議是無狀態協議。無狀態，如果協議對於事務處理沒有記憶的機制，不能存儲處理進度，此時，如果後續的操作需要前面的處理信息，就需要重新發送對象即必須重傳，這樣的後果是，可能多次連接才能完成操作，數據量會因此變大。“在服務器端，每個HTTP請求都要啟動獨立的線程去處理，減少Http請求的數目可以有效提高訪問性能（《大型網站技術架構》·李智慧）”。
通常情況下，HTTP協議的工作原理很好理解，用戶通過客戶端向服務端發起一個請求，創建一個TCP連接，指定端口號，默認是80，然後連接到服務器工作。在那個端口監聽浏覽器請求。一旦監聽到客戶端請求，分析請求類型後，服務器會向客戶端返回一個響應狀態，比如"HTTP/1.0 404 OK"，同時會返回特定的數據內容，如請求的資源，錯誤代碼，其它狀態信息等等。
當浏覽器向服務器發送一個請求到Web服務器,它發送一個數據塊,或請求信息,
HTTP請求信息包括3部分:
請求方法URI協議/版本；
請求頭(Request Header)；
請求正文；
下面是一個HTTP請求的示例：
GET/test.jsp HTTP/1.1
Accept:image/test.image/jpeg,*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:222.35.232.103
User-Agent:Mozila/5.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=linuxidc&password=linuxidc
（1）請求方法URI協議/版本
請求的第一行是“方法/內容 URL協議/協議版本名稱”：
GET/test.jsp HTTP/1.1
上面的代碼中，“GET”說明請求方法，“/test.jsp”表示網絡資源，中間空格，最後說明協議和協議的版本。
根據HTTP標准，HTTP請求可以使用多種不同的請求方法。例如：HTTP1.1允許支持七種請求方法（也叫“動作”）：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。日常開發中， GET和POST是最常用的方法，主要在相關的Web開發中。
URL路徑指定了要訪問的網絡資源。一般來說，我們需要的是相對路徑，因為確定資源位置，知道網絡資源相對於服務器的根目錄的路徑就可以，所以以“/”開頭。在頭信息結束時，聲明了通信過程中HTTP協議版本的使用版本。
需要注意，方法名稱很重要的一點是嚴格區分大小寫。有些時候，某個請求所針對的資源可能不支持對應的請求方法，會通過不同的狀態碼給出響應。例如,服務器將返回一個狀態碼405(方法不允許),當請求服務器或方法不理解不支持相應的時間,返回一個狀態碼501(沒有實現)。
（2）請求頭(Request Header)
請求頭包含了一些客戶環境和請求的內容信息。例如,請求頭可以聲明浏覽器內核和語言使用,請求的長度等。
Accept:image/test.image/jpeg.*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:222.35.232.103
User-Agent:Mozila/5.0(compatible:MSIE5.01:Windows NT5.0)
Accept-Encoding:gzip,deflate.
（3）請求正文
請求正文和請求頭要有空行。這個空行必須存在，說明結束請求頭傳輸，開始傳輸正文請求。請求正文中一般包含很多信息，例如用戶提交的用戶名和密碼之類的登陸信息：userlogin=linuxidc¤tpwd=linuxidc
在真實應用中，協議的請求正文可以包含大量的信息,而不是如示例的HTTP請
求中一樣，請求正文只有簡單的一行數據。
和請求報文類似，HTTP響應主要也是3個部分構成：
（1）協議狀態版本代碼描述
（2）響應頭(Response Header)
（3）響應正文
下面是一個HTTP響應的示例：
HTTP/1.1 200 OK
Server:Apache Tomcat/7.0.1
Date:Mon,6Oct2014 13:23:42 GMT
Content-Length:102
<html>
<head>
<title>HTTP響應文件<title>
</head>
<body>
這是HTTP響應文件！
</body>
</html>
客戶端向服務器發送請求，和請求報文類似，服務器會以狀態行響應。
響應報文包括：HTTP協議的版本、結果編碼以及其他的必要信息，如實體信息等。響應類別不同，響應報文裡可以包含或者不含實體內容。
HTTP響應報文的首先是以狀態行開始，這些可以參考示例的代碼。
響應頭也就是報文首部，和請求頭首部一樣，包含重要的信息，例子中我們可以看到，比如日期時間和服務器類型以及內容長度和數量等。
Https是一種基於SSL/TLS的Http協議，所有的http數據都是在SSL/TLS協議封裝之上傳輸的。
Https協議在Http協議的基礎上，添加了SSL/TLS握手以及數據加密傳輸，也屬於應用層協議。
——>HTTP協議運行在TCP之上，所有傳輸的內容都是明文，客戶端和服務器端都無法驗證對方的身份。
——>HTTPS是運行在SSL/TLS之上的HTTP協議，SSL/TLS運行在TCP之上。所有傳輸的內容都經過加密，加密采用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。
TLS/SSL中使用了非對稱加密，對稱加密以及HASH算法。
握手過程的簡單描述如下：
1.浏覽器將自己支持的一套加密規則發送給網站。
2.網站從中選出一組加密算法與HASH算法，並將自己的身份信息以證書的形式發回給浏覽器。證書裡面包含了網站地址，加密公鑰，以及證書的頒發機構等信息。
3.獲得網站證書之後浏覽器要做以下工作：
a) 驗證證書的合法性（頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），如果證書受信任，則浏覽器欄裡面會顯示一個小鎖頭，否則會給出證書不受信的提示。
b) 如果證書受信任，或者是用戶接受了不受信的證書，浏覽器會生成一串隨機數的密碼，並用證書中提供的公鑰加密。
c) 使用約定好的HASH計算握手消息，並使用生成的隨機數對消息進行加密，最後將之前生成的所有信息發送給網站。
4.網站接收浏覽器發來的數據之後要做以下的操作：
a) 使用自己的私鑰將信息解密取出密碼，使用密碼解密浏覽器發來的握手消息，並驗證HASH是否與浏覽器發來的一致。
b) 使用密碼加密一段握手消息，發送給浏覽器。
5.浏覽器解密並計算握手消息的HASH，如果與服務端發來的HASH一致，
此時握手過程結束，之後所有的通信數據將由之前浏覽器生成的隨機密碼並利用對稱加密算法進行加密。
這裡浏覽器與網站互相發送加密的握手消息並驗證，目的是為了保證雙方都獲得了一致的密碼，並且可以正常的加密解密數據，為後續真正數據的傳輸做一次測試。
HTTPS一般使用的加密與HASH算法如下：
非對稱加密算法：RSA，DSA/DSS
對稱加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256
其中非對稱加密算法用於在握手過程中加密生成的密碼，對稱加密算法用於對真正傳輸的數據進行加密，而HASH算法用於驗證數據的完整性。
由於浏覽器生成的密碼是整個數據加密的關鍵，因此在傳輸的時候使用了非對稱加密算法對其加密。
非對稱加密算法會生成公鑰和私鑰，公鑰只能用於加密數據，因此可以隨意傳輸，而網站的私鑰用於對數據進行解密，所以網站都會非常小心的保管自己的私鑰，防止洩漏。
TLS握手過程中如果有任何錯誤，都會使加密連接斷開，從而阻止了隱私信息的傳輸。
