HTTP协议和HTTPS协议初探
概況
HTTP是hypertext transfer protocol（超文本傳輸協議）的簡寫，它是TCP/IP協議的一個應用層協議，用于定義WEB瀏覽器與WEB服務器之間交換數據的過程。
HTTP是一個屬于應用層的面向對象的協議，由于其簡捷、快速的方式，適用于分布式超媒體信息系統。它于1990年提出，經過幾年的使用與發展，得到不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規范化工作正在進行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經提出。
主要特點
HTTP協議的主要特點可概括如下：
- 1.支持客戶/服務器模式。
- 2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯系的類型不同。由于HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
- 3.靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
- 4.無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。
- 5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對于事務處理沒有記憶能力。缺少狀態意味著如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
HTTP協議
HTTP協議詳解之URL
http（超文本傳輸協議）是一個基于請求與響應模式的、無狀態的、應用層的協議，常基于TCP的連接方式，HTTP1.1版本中給出一種持續連接的機制，絕大多數的Web開發，都是構建在HTTP協議之上的Web應用。
HTTP URL (URL是一種特殊類型的URI，包含了用于查找某個資源的足夠的信息)的格式如下：
http://host[":"port][abs_path]http表示要通過HTTP協議來定位網絡資源；
host表示合法的Internet主機域名或者IP地址；
port指定一個端口號，為空則使用缺省端口80；
abs_path指定請求資源的URI；
如果URL中沒有給出abs_path，那么當它作為請求URI時，必須以“/”的形式給出，通常這個工作瀏覽器自動幫我們完成。
舉例：
eg: http:192.168.0.1:8080/index.jsp
HTTP協議詳解之請求
http請求由三部分組成，分別是：請求行、消息報頭、請求正文
請求行
請求行以一個方法符號開頭，以空格分開，后面跟著請求的URI和協議的版本，格式如下：
Method Request-URI HTTP-Version CRLF其中 ：
Method表示請求方法；
Request-URI是一個統一資源標識符；
HTTP-Version表示請求的HTTP協議版本；
CRLF表示回車和換行（除了作為結尾的CRLF外，不允許出現單獨的CR或LF字符）。
請求方法（所有方法全為大寫）：
- GET 請求獲取Request-URI所標識的資源
- POST 在Request-URI所標識的資源后附加新的數據
- HEAD 請求獲取由Request-URI所標識的資源的響應消息報頭
- PUT 請求服務器存儲一個資源，并用Request-URI作為其標識
- DELETE 請求服務器刪除Request-URI所標識的資源
- TRACE 請求服務器回送收到的請求信息，主要用于測試或診斷
- CONNECT 保留將來使用
- OPTIONS 請求查詢服務器的性能，或者查詢與資源相關的選項和需求
應用舉例：
GET方法：在瀏覽器的地址欄中輸入網址的方式訪問網頁時，瀏覽器采用GET方法向服務器獲取資源，eg:GET /form.html HTTP/1.1 (CRLF)
POST方法：要求被請求服務器接受附在請求后面的數據，常用于提交表單。
eg：POST /reg.jsp HTTP/ (CRLF)
Accept:image/gif,image/x-xbit,… (CRLF)
…
HOST:XXX.XX.XX (CRLF)
Content-Length:22 (CRLF)
Connection:Keep-Alive (CRLF)
Cache-Control:no-cache (CRLF)
(CRLF) //該CRLF表示消息報頭已經結束，在此之前為消息報頭
user=username&pwd=password//此行以下為提交的數據
HEAD方法與GET方法幾乎是一樣的，對于HEAD請求的回應部分來說，它的HTTP頭部中包含的信息與通過GET請求所得到的信息是相同的。利用這個方法，不必傳輸整個資源內容，就可以得到Request-URI所標識的資源的信息。該方法常用于測試超鏈接的有效性，是否可以訪問，以及最近是否更新。
請求報頭后述
請求正文
HTTP協議詳解之響應
在接收和解釋請求消息后，服務器返回一個HTTP響應消息。
HTTP響應也是由三個部分組成，分別是：狀態行、消息報頭、響應正文
狀態行格式如下
HTTP-Version Status-Code Reason-Phrase CRLF其中：
HTTP-Version表示服務器HTTP協議的版本；
Status-Code表示服務器發回的響應狀態代碼；
Reason-Phrase表示狀態代碼的文本描述。
狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：
- 1xx:信息響應類，表示接收到請求并且繼續處理
- 2xx:處理成功響應類，表示動作被成功接收、理解和接受
- 3xx:重定向響應類，為了完成指定的動作，必須接受進一步處理
- 4xx:客戶端錯誤，客戶請求包含語法錯誤或者是不能正確執行
- 5xx:服務端錯誤，服務器不能正確執行一個正確的請求
常見狀態代碼、狀態描述、說明：
- 200 OK //客戶端請求成功
- 400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解
- 401 Unauthorized //請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用
- 403 Forbidden //服務器收到請求，但是拒絕提供服務
- 404 Not Found //請求資源不存在，eg：輸入了錯誤的URL
- 500 Internal Server Error //服務器發生不可預期的錯誤
- 503 Server Unavailable //服務器當前不能處理客戶端的請求，一段時間后可能恢復正常
eg：HTTP/1.1 200 OK （CRLF）
響應報頭后述
響應正文就是服務器返回的資源的內容
HTTP協議詳解之消息報頭
HTTP消息由客戶端到服務器的請求和服務器到客戶端的響應組成。請求消息和響應消息都是由開始行（對于請求消息，開始行就是請求行，對于響應消息，開始行就是狀態行），消息報頭（可選），空行（只有CRLF的行），消息正文（可選）組成。
HTTP消息報頭包括普通報頭、請求報頭、響應報頭、實體報頭。
每一個報頭域都是由名字+“：”+空格+值 組成，消息報頭域的名字是大小寫無關的。
普通報頭
在普通報頭中，有少數報頭域用于所有的請求和響應消息，但并不用于被傳輸的實體，只用于傳輸的消息。
eg：Cache-Control 用于指定緩存指令，緩存指令是單向的（響應中出現的緩存指令在請求中未必會出現），且是獨立的（一個消息的緩存指令不會影響另一個消息處理的緩存機制），HTTP1.0使用的類似的報頭域為Pragma。
- 請求時的緩存指令包括：no-cache（用于指示請求或響應消息不能緩存）、no-store、max-age、max-stale、min-fresh、only-if-cached;
- 響應時的緩存指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.
eg：為了指示IE瀏覽器（客戶端）不要緩存頁面，服務器端的JSP程序可以編寫如下：
response.setHeader("Cache-Control","no-cache"); //response.setHeader("Pragma","no-cache");作用相當于上述代碼，通常兩者//合用這句代碼將在發送的響應消息中設置普通報頭域：Cache-Control:no-cache
Date普通報頭域表示消息產生的日期和時間
Connection普通報頭域允許發送指定連接的選項。例如指定連接是連續，或者指定“close”選項，通知服務器，在響應完成后，關閉連接.
請求報頭
請求報頭允許客戶端向服務器端傳遞請求的附加信息以及客戶端自身的信息。
常用的請求報頭:
Accept請求報頭域用于指定客戶端接受哪些類型的信息。
舉例：
Accept：image/gif，表明客戶端希望接受GIF圖象格式的資源；
Accept：text/html，表明客戶端希望接受html文本。Accept-Charset請求報頭域用于指定客戶端接受的字符集。
舉例：Accept-Charset:iso-8859-1,gb2312.
如果在請求消息中沒有設置這個域，缺省是任何字符集都可以接受。- Accept-Encoding請求報頭域類似于Accept，但是它是用于指定可接受的內容編碼。
舉例：Accept-Encoding:gzip.deflate.
如果請求消息中沒有設置這個域服務器假定客戶端對各種內容編碼都可以接受。 - Accept-Language請求報頭域類似于Accept，但是它是用于指定一種自然語言。
舉例：Accept-Language:zh-cn.
如果請求消息中沒有設置這個報頭域，服務器假定客戶端對各種語言都可以接受。 - Authorization 請求報頭域主要用于證明客戶端有權查看某個資源。當瀏覽器訪問一個頁面時，如果收到服務器的響應代碼為401（未授權），可以發送一個包含Authorization請求報頭域的請求，要求服務器對其進行驗證。
- Host請求報頭域主要用于指定被請求資源的Internet主機和端口號，它通常從HTTP URL中提取出來的，發送請求時，該報頭域是必需的。
比如 我們在瀏覽器中輸入：http://www.imooc.com/index.jsp
瀏覽器發送的請求消息中，就會包含Host請求報頭域，如下：Host：www.imooc.com
此處使用缺省端口號80，若指定了端口號，則變成：Host：www.imooc.com:指定端口號。 - User-Agent我們上網登陸論壇的時候，往往會看到一些歡迎信息，其中列出了你的操作系統的名稱和版本，你所使用的瀏覽器的名稱和版本，這往往讓很多人感到很神奇，實際上，服務器應用程序就是從User-Agent這個請求報頭域中獲取到這些信息。User-Agent請求報頭域允許客戶端將它的操作系統、瀏覽器和其它屬性告訴服務器。不過，這個報頭域不是必需的，如果我們自己編寫一個瀏覽器，不使用User-Agent請求報頭域，那么服務器端就無法得知我們的信息了。
請求報頭舉例：
響應報頭
響應報頭允許服務器傳遞不能放在狀態行中的附加響應信息，以及關于服務器的信息和對Request-URI所標識的資源進行下一步訪問的信息。
常用的響應報頭
Location響應報頭域用于重定向接受者到一個新的位置。Location響應報頭域常用在更換域名的時候。
Server響應報頭域包含了服務器用來處理請求的軟件信息。與User-Agent請求報頭域是相對應的。下面是Server響應報頭域的一個例子：Server：nginx
WWW-Authenticate響應報頭域必須被包含在401（未授權的）響應消息中，客戶端收到401響應消息時候，并發送Authorization報頭域請求服務器對其進行驗證時，服務端響應報頭就包含該報頭域。
eg：WWW-Authenticate:Basic realm=”Basic Auth Test!” //可以看出服務器對請求資源采用的是基本驗證機制。
實體報頭
請求和響應消息都可以傳送一個實體。一個實體由實體報頭域和實體正文組成，但并不是說實體報頭域和實體正文要在一起發送，可以只發送實體報頭域。實體報頭定義了關于實體正文（eg：有無實體正文）和請求所標識的資源的元信息。
常用的實體報頭：
- Content-Encoding實體報頭域被用作媒體類型的修飾符，它的值指示了已經被應用到實體正文的附加內容的編碼，因而要獲得Content-Type報頭域中所引用的媒體類型，必須采用相應的解碼機制。ContentEncoding這樣用于記錄文檔的壓縮方法，eg：Content-Encoding：gzip
- Content-Language實體報頭域描述了資源所用的自然語言。沒有設置該域則認為實體內容將提供給所有的語言閱讀
者。eg：Content-Language:da - Content-Length實體報頭域用于指明實體正文的長度，以字節方式存儲的十進制數字來表示。
- Content-Type實體報頭域用語指明發送給接收者的實體正文的媒體類型。eg：Content-Type:text/html;charset=ISO-8859-1 Content-Type:text/html;charset=GB2312
- Last-Modified實體報頭域用于指示資源的最后修改日期和時間。
- Expires實體報頭域給出響應過期的日期和時間。為了讓代理服務器或瀏覽器在一段時間以后更新緩存中(再次訪問曾訪問過的頁面時，直接從緩存中加載，縮短響應時間和降低服務器負載)的頁面，我們可以使用Expires實體報頭域指定頁面過期的時間。eg：Expires：Thu，15 Sep 2006 16:23:12 GMT
HTTP1.1的客戶端和緩存必須將其他非法的日期格式（包括0）看作已經過期。eg：為了讓瀏覽器不要緩存頁面，我們也可以利用Expires實體報頭域，設置為0，jsp中程序如下：response.setDateHeader(“Expires”,”0”);
工具類HttpUtil.java
import java.io.IOException; import java.io.UnsupportedEncodingException;import org.apache.http.HttpEntity; import org.apache.http.HttpResponse; import org.apache.http.client.ClientProtocolException; import org.apache.http.client.methods.HttpGet; import org.apache.http.client.methods.HttpPost; import org.apache.http.entity.StringEntity; import org.apache.http.impl.client.DefaultHttpClient; import org.apache.http.params.HttpConnectionParams; import org.apache.http.params.HttpParams; import org.apache.http.util.EntityUtils;public class HttpUtil {public static String httpGet(String httpUrl) {String result = "";DefaultHttpClient httpclient = new DefaultHttpClient();// 創建http客戶端HttpGet httpget = new HttpGet(httpUrl);HttpResponse response = null;HttpParams params = httpclient.getParams(); // 計算網絡超時用HttpConnectionParams.setConnectionTimeout(params, 15 * 1000);HttpConnectionParams.setSoTimeout(params, 20 * 1000);try {response = httpclient.execute(httpget);HttpEntity entity = response.getEntity();// 得到http的內容response.getStatusLine().getStatusCode();// 得到http的狀態返回值result = EntityUtils.toString(response.getEntity());// 得到具體的返回值，一般是xml文件entity.consumeContent();// 如果entity不為空，則釋放內存空間httpclient.getCookieStore();// 得到cookishttpclient.getConnectionManager().shutdown();// 關閉http客戶端} catch (ClientProtocolException e) {e.printStackTrace();} catch (IOException e) {e.printStackTrace();}return result;}public static String httpPost(String httpUrl, String data) {String result = "";DefaultHttpClient httpclient = new DefaultHttpClient();HttpPost httpPost = new HttpPost(httpUrl);// httpclient.setCookieStore(DataDefine.mCookieStore);HttpParams params = httpclient.getParams(); // 計算網絡超時用HttpConnectionParams.setConnectionTimeout(params, 15 * 1000);HttpConnectionParams.setSoTimeout(params, 20 * 1000);httpPost.setHeader("Content-Type", "text/xml");StringEntity httpPostEntity;try {httpPostEntity = new StringEntity(data, "UTF-8");httpPost.setEntity(httpPostEntity);HttpResponse response = httpclient.execute(httpPost);HttpEntity entity = response.getEntity();// 得到http的內容response.getStatusLine().getStatusCode();// 得到http的狀態返回值result = EntityUtils.toString(response.getEntity());// 得到具體的返回值，一般是xml文件entity.consumeContent();// 如果entity不為空，則釋放內存空間httpclient.getCookieStore();// 得到cookishttpclient.getConnectionManager().shutdown();// 關閉http客戶端} catch (Exception e) {e.printStackTrace();} // base64是經過編碼的字符串，可以理解為字符串 // StringEntitytry {httpPostEntity = new StringEntity("UTF-8");} catch (UnsupportedEncodingException e) {// TODO Auto-generated catch blocke.printStackTrace();}return result;} }HTTPS協議
HTTPS協議概述
HTTPS（Hypertext Transfer Protocol over Secure Socket Layer，基于SSL的HTTP協議）使用了HTTP協議，但HTTPS使用不同于HTTP協議的默認端口及一個加密、身份驗證層（HTTP與TCP之間）。這個協議的最初研發由網景公司進行，提供了身份驗證與加密通信方法，現在它被廣泛用于互聯網上安全敏感的通信。HTTPS是一個安全通信通道，用于在客戶計算機和服務器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來說它是HTTP的安全版。它是由Netscape開發并內置于其瀏覽器中，用于對數據進行壓縮和解壓操作，并返回網絡上傳送回的結果。
HTTPS實際上應用了Netscape的安全全套接字層(SSL)作為HTTP應用層的子層。(HTTPS使用端口443，而不是象HTTP那樣使用端口80來和TCP/IP進行通信。)SSL使用40 位關鍵字作為RC4流加密算法，這對于商業信息的加密是合適的。HTTPS和SSL支持使用X。509數字認證，如果需要的話用戶可以確認發送者是誰。
使用HTTPS步驟
客戶端在使用HTTPS方式與Web服務器通信時有以下幾個步驟。
（1）客戶使用https的URL訪問Web服務器，要求與Web服務器建立SSL連接。
（2）Web服務器收到客戶端請求后，會將網站的證書信息（證書中包含公鑰）傳送一份給客戶端。
（3）客戶端的瀏覽器與Web服務器開始協商SSL連接的安全等級，也就是信息加密的等級。
（4）客戶端的瀏覽器根據雙方同意的安全等級，建立會話密鑰，然后利用網站的公鑰將會話密鑰加密，并傳送給網站。
（5）Web服務器利用自己的私鑰解密出會話密鑰。
（6）Web服務器利用會話密鑰加密與客戶端之間的通信。
工具類HttpsUtils.java
import java.io.BufferedReader; import java.io.DataOutputStream; import java.io.InputStreamReader; import java.net.HttpURLConnection; import java.net.URL;import javax.net.ssl.HostnameVerifier; import javax.net.ssl.HttpsURLConnection; import javax.net.ssl.SSLContext; import javax.net.ssl.TrustManager;public class HttpsUtil {static TrustManager[] xtmArray = new MytmArray[] { new MytmArray() };// 創建信任規則列表private final static int CONNENT_TIMEOUT = 15000;private final static int READ_TIMEOUT = 15000;static HostnameVerifier DO_NOT_VERIFY = new HostnameVerifier() {public boolean verify(String hostname, SSLSession session) {return true;}};/*** * 信任所有主機-對于任何證書都不做檢查 Create a trust manager that does not validate ** certificate chains， Android 采用X509的證書信息機制，Install the all-trusting trust* * manager*/private static void trustAllHosts() {try {SSLContext sc = SSLContext.getInstance("TLS");sc.init(null, xtmArray, new java.security.SecureRandom());HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory()); // 不進行主機名確認,對所有主機HttpsURLConnection.setDefaultHostnameVerifier(DO_NOT_VERIFY);} catch (Exception e) {e.printStackTrace();}} // https get方法，返回值是https請求，服務端返回的數據string類型，數據進行xml解析 public static String HttpsGet(String httpsurl) { return HttpsPost(httpsurl, null); }/*** https post方法，返回值是https請求，服務端返回的數據string類型，數據進行xml解析*/public static String HttpsPost(String httpsurl, String data) {String result = null;HttpURLConnection http = null;URL url;try {url = new URL(httpsurl); // 判斷是http請求還是https請求if (url.getProtocol().toLowerCase().equals("https")) {trustAllHosts();http = (HttpsURLConnection) url.openConnection();((HttpsURLConnection) http).setHostnameVerifier(DO_NOT_VERIFY);// 不進行主機名確認} else {http = (HttpURLConnection) url.openConnection();}http.setConnectTimeout(CONNENT_TIMEOUT);// 設置超時時間http.setReadTimeout(READ_TIMEOUT);if (data == null) {http.setRequestMethod("GET");// 設置請求類型http.setDoInput(true);// http.setRequestProperty("Content-Type", "text/xml");if (AppSession.mCookieStore != null)http.setRequestProperty("Cookie", AppSession.mCookieStore);} else {http.setRequestMethod("POST");// 設置請求類型為posthttp.setDoInput(true);http.setDoOutput(true);// http.setRequestProperty("Content-Type", "text/xml");if (AppSession.mCookieStore != null && AppSession.mCookieStore.trim().length() > 0)http.setRequestProperty("Cookie", AppSession.mCookieStore);DataOutputStream out = new DataOutputStream(http.getOutputStream());out.writeBytes(data);out.flush();out.close();} // 設置http返回狀態200（ok）還是403AppSession.httpsResponseCode = http.getResponseCode();BufferedReader in = null;if (AppSession.httpsResponseCode == 200) {getCookie(http);in = new BufferedReader(new InputStreamReader(http.getInputStream()));} elsein = new BufferedReader(new InputStreamReader(http.getErrorStream()));String temp = in.readLine();while (temp != null) {if (result != null)result += temp;elseresult = temp;temp = in.readLine();}in.close();http.disconnect();} catch (Exception e) {e.printStackTrace();}return result;}/** * 得到cookie * */private static void getCookie(HttpURLConnection http) {String cookieVal = null;String key = null;AppSession.mCookieStore = "";for (int i = 1; (key = http.getHeaderFieldKey(i)) != null; i++) {if (key.equalsIgnoreCase("set-cookie")) {cookieVal = http.getHeaderField(i);cookieVal = cookieVal.substring(0, cookieVal.indexOf(";"));AppSession.mCookieStore = AppSession.mCookieStore + cookieVal + ";";}}} }總的來說，http效率更高，https安全性更高。
兩者的區別
- 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 有一個證書。
主要目的是保證server 就是他聲稱的server。這個跟第一點一樣。服務端和客戶端之間的所有通訊，都是加密的。
具體講，是客戶端產生一個對稱的密鑰，通過server 的證書來交換密鑰。 一般意義上的握手過程。加下來所有的信息往來就都是加密的。 第三方即使截獲，也沒有任何意義。因為他沒有密鑰。當然竄改也就沒有什么意義了。
2）少許對客戶端有要求的情況下，會要求客戶端也必須有一個證書。
這里客戶端證書，其實就類似表示個人信息的時候，除了用戶名/密碼， 還有一個CA 認證過的身份。 應為個人證書一般來說上別人無法模擬的，所有這樣能夠更深的確認自己的身份。目前少數個人銀行的專業版是這種做法，具體證書可能是拿U盤作為一個備份的載體。 HTTPS 一定是繁瑣的。
本來簡單的http協議，一個get一個response。由于https 要還密鑰和確認加密算法的需要。單握手就需要6/7 個往返。任何應用中，過多的round trip 肯定影響性能。接下來才是具體的http協議，每一次響應或者請求， 都要求客戶端和服務端對會話的內容做加密/解密。盡管對稱加密/解密效率比較高，可是仍然要消耗過多的CPU，為此有專門的SSL 芯片。 如果CPU 信能比較低的話，肯定會降低性能，從而不能serve 更多的請求。
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 的地方，就盡量不要用。
參考：http://aresxiong.com/2015/11/30/protocol_http_and_https
《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀總結
以上是生活随笔為你收集整理的HTTP协议和HTTPS协议初探的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： .9图片的那点事儿
- 下一篇： WebView完全解读