概況

HTTP是hypertext transfer protocol（超文本傳輸協(xié)議）的簡寫，它是TCP/IP協(xié)議的一個(gè)應(yīng)用層協(xié)議，用于定義WEB瀏覽器與WEB服務(wù)器之間交換數(shù)據(jù)的過程。

HTTP是一個(gè)屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，由于其簡捷、快速的方式，適用于分布式超媒體信息系統(tǒng)。它于1990年提出，經(jīng)過幾年的使用與發(fā)展，得到不斷地完善和擴(kuò)展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規(guī)范化工作正在進(jìn)行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經(jīng)提出。

主要特點(diǎn)

HTTP協(xié)議的主要特點(diǎn)可概括如下：

• 1.支持客戶/服務(wù)器模式。
• 2.簡單快速：客戶向服務(wù)器請求服務(wù)時(shí)，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。
• 3.靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋?strong>由Content-Type加以標(biāo)記。
• 4.無連接：無連接的含義是限制每次連接只處理一個(gè)請求。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間。
• 5.無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。

---

HTTP協(xié)議

HTTP協(xié)議詳解之URL

http（超文本傳輸協(xié)議）是一個(gè)基于請求與響應(yīng)模式的、無狀態(tài)的、應(yīng)用層的協(xié)議，常基于TCP的連接方式，HTTP1.1版本中給出一種持續(xù)連接的機(jī)制，絕大多數(shù)的Web開發(fā)，都是構(gòu)建在HTTP協(xié)議之上的Web應(yīng)用。

HTTP URL (URL是一種特殊類型的URI，包含了用于查找某個(gè)資源的足夠的信息)的格式如下：

http://host[":"port][abs_path]

http表示要通過HTTP協(xié)議來定位網(wǎng)絡(luò)資源；
host表示合法的Internet主機(jī)域名或者IP地址；
port指定一個(gè)端口號，為空則使用缺省端口80；
abs_path指定請求資源的URI；
如果URL中沒有給出abs_path，那么當(dāng)它作為請求URI時(shí)，必須以“/”的形式給出，通常這個(gè)工作瀏覽器自動幫我們完成。

舉例：
eg: http:192.168.0.1:8080/index.jsp

HTTP協(xié)議詳解之請求

http請求由三部分組成，分別是：請求行、消息報(bào)頭、請求正文

請求行

請求行以一個(gè)方法符號開頭，以空格分開，后面跟著請求的URI和協(xié)議的版本，格式如下：

Method Request-URI HTTP-Version CRLF

其中 ：
Method表示請求方法；
Request-URI是一個(gè)統(tǒng)一資源標(biāo)識符；
HTTP-Version表示請求的HTTP協(xié)議版本；
CRLF表示回車和換行（除了作為結(jié)尾的CRLF外，不允許出現(xiàn)單獨(dú)的CR或LF字符）。

請求方法（所有方法全為大寫）：

• GET　　　 請求獲取Request-URI所標(biāo)識的資源
• POST　　　在Request-URI所標(biāo)識的資源后附加新的數(shù)據(jù)
• HEAD　　　請求獲取由Request-URI所標(biāo)識的資源的響應(yīng)消息報(bào)頭
• PUT　　　 請求服務(wù)器存儲一個(gè)資源，并用Request-URI作為其標(biāo)識
• DELETE　　請求服務(wù)器刪除Request-URI所標(biāo)識的資源
• TRACE　　 請求服務(wù)器回送收到的請求信息，主要用于測試或診斷
• CONNECT　 保留將來使用
• OPTIONS　 請求查詢服務(wù)器的性能，或者查詢與資源相關(guān)的選項(xiàng)和需求

應(yīng)用舉例：

GET方法：在瀏覽器的地址欄中輸入網(wǎng)址的方式訪問網(wǎng)頁時(shí)，瀏覽器采用GET方法向服務(wù)器獲取資源，eg:GET /form.html HTTP/1.1 (CRLF)

POST方法：要求被請求服務(wù)器接受附在請求后面的數(shù)據(jù)，常用于提交表單。

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表示消息報(bào)頭已經(jīng)結(jié)束，在此之前為消息報(bào)頭
user=username&pwd=password//此行以下為提交的數(shù)據(jù)

HEAD方法與GET方法幾乎是一樣的，對于HEAD請求的回應(yīng)部分來說，它的HTTP頭部中包含的信息與通過GET請求所得到的信息是相同的。利用這個(gè)方法，不必傳輸整個(gè)資源內(nèi)容，就可以得到Request-URI所標(biāo)識的資源的信息。該方法常用于測試超鏈接的有效性，是否可以訪問，以及最近是否更新。

---

請求報(bào)頭后述

請求正文

---

HTTP協(xié)議詳解之響應(yīng)

在接收和解釋請求消息后，服務(wù)器返回一個(gè)HTTP響應(yīng)消息。

HTTP響應(yīng)也是由三個(gè)部分組成，分別是：狀態(tài)行、消息報(bào)頭、響應(yīng)正文

狀態(tài)行格式如下

HTTP-Version Status-Code Reason-Phrase CRLF

其中：
HTTP-Version表示服務(wù)器HTTP協(xié)議的版本；
Status-Code表示服務(wù)器發(fā)回的響應(yīng)狀態(tài)代碼；
Reason-Phrase表示狀態(tài)代碼的文本描述。

狀態(tài)代碼有三位數(shù)字組成，第一個(gè)數(shù)字定義了響應(yīng)的類別，且有五種可能取值：

• 1xx:信息響應(yīng)類，表示接收到請求并且繼續(xù)處理
• 2xx:處理成功響應(yīng)類，表示動作被成功接收、理解和接受
• 3xx:重定向響應(yīng)類，為了完成指定的動作，必須接受進(jìn)一步處理
• 4xx:客戶端錯(cuò)誤，客戶請求包含語法錯(cuò)誤或者是不能正確執(zhí)行
• 5xx:服務(wù)端錯(cuò)誤，服務(wù)器不能正確執(zhí)行一個(gè)正確的請求

常見狀態(tài)代碼、狀態(tài)描述、說明：

• 200 OK //客戶端請求成功
• 400 Bad Request //客戶端請求有語法錯(cuò)誤，不能被服務(wù)器所理解
• 401 Unauthorized //請求未經(jīng)授權(quán)，這個(gè)狀態(tài)代碼必須和WWW-Authenticate報(bào)頭域一起使用
• 403 Forbidden //服務(wù)器收到請求，但是拒絕提供服務(wù)
• 404 Not Found //請求資源不存在，eg：輸入了錯(cuò)誤的URL
• 500 Internal Server Error //服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤
• 503 Server Unavailable //服務(wù)器當(dāng)前不能處理客戶端的請求，一段時(shí)間后可能恢復(fù)正常
  eg：HTTP/1.1 200 OK （CRLF）

響應(yīng)報(bào)頭后述

響應(yīng)正文就是服務(wù)器返回的資源的內(nèi)容

HTTP協(xié)議詳解之消息報(bào)頭

HTTP消息由客戶端到服務(wù)器的請求和服務(wù)器到客戶端的響應(yīng)組成。請求消息和響應(yīng)消息都是由開始行（對于請求消息，開始行就是請求行，對于響應(yīng)消息，開始行就是狀態(tài)行），消息報(bào)頭（可選），空行（只有CRLF的行），消息正文（可選）組成。

HTTP消息報(bào)頭包括普通報(bào)頭、請求報(bào)頭、響應(yīng)報(bào)頭、實(shí)體報(bào)頭。
每一個(gè)報(bào)頭域都是由名字+“：”+空格+值 組成，消息報(bào)頭域的名字是大小寫無關(guān)的。

普通報(bào)頭

在普通報(bào)頭中，有少數(shù)報(bào)頭域用于所有的請求和響應(yīng)消息，但并不用于被傳輸?shù)膶?shí)體，只用于傳輸?shù)南ⅰ?/p>

eg：Cache-Control 用于指定緩存指令，緩存指令是單向的（響應(yīng)中出現(xiàn)的緩存指令在請求中未必會出現(xiàn)），且是獨(dú)立的（一個(gè)消息的緩存指令不會影響另一個(gè)消息處理的緩存機(jī)制），HTTP1.0使用的類似的報(bào)頭域?yàn)镻ragma。

• 請求時(shí)的緩存指令包括：no-cache（用于指示請求或響應(yīng)消息不能緩存）、no-store、max-age、max-stale、min-fresh、only-if-cached;
• 響應(yīng)時(shí)的緩存指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.

eg：為了指示IE瀏覽器（客戶端）不要緩存頁面，服務(wù)器端的JSP程序可以編寫如下：

response.setHeader("Cache-Control","no-cache"); //response.setHeader("Pragma","no-cache");作用相當(dāng)于上述代碼，通常兩者//合用

這句代碼將在發(fā)送的響應(yīng)消息中設(shè)置普通報(bào)頭域：Cache-Control:no-cache
Date普通報(bào)頭域表示消息產(chǎn)生的日期和時(shí)間
Connection普通報(bào)頭域允許發(fā)送指定連接的選項(xiàng)。例如指定連接是連續(xù)，或者指定“close”選項(xiàng)，通知服務(wù)器，在響應(yīng)完成后，關(guān)閉連接.

請求報(bào)頭

請求報(bào)頭允許客戶端向服務(wù)器端傳遞請求的附加信息以及客戶端自身的信息。

常用的請求報(bào)頭:

• Accept請求報(bào)頭域用于指定客戶端接受哪些類型的信息。
  舉例：
  Accept：image/gif，表明客戶端希望接受GIF圖象格式的資源；
  Accept：text/html，表明客戶端希望接受html文本。

• Accept-Charset請求報(bào)頭域用于指定客戶端接受的字符集。
  舉例：Accept-Charset:iso-8859-1,gb2312.
  如果在請求消息中沒有設(shè)置這個(gè)域，缺省是任何字符集都可以接受。

• Accept-Encoding請求報(bào)頭域類似于Accept，但是它是用于指定可接受的內(nèi)容編碼。
  舉例：Accept-Encoding:gzip.deflate.
  如果請求消息中沒有設(shè)置這個(gè)域服務(wù)器假定客戶端對各種內(nèi)容編碼都可以接受。
• Accept-Language請求報(bào)頭域類似于Accept，但是它是用于指定一種自然語言。
  舉例：Accept-Language:zh-cn.
  如果請求消息中沒有設(shè)置這個(gè)報(bào)頭域，服務(wù)器假定客戶端對各種語言都可以接受。
• Authorization 請求報(bào)頭域主要用于證明客戶端有權(quán)查看某個(gè)資源。當(dāng)瀏覽器訪問一個(gè)頁面時(shí)，如果收到服務(wù)器的響應(yīng)代碼為401（未授權(quán)），可以發(fā)送一個(gè)包含Authorization請求報(bào)頭域的請求，要求服務(wù)器對其進(jìn)行驗(yàn)證。
• Host請求報(bào)頭域主要用于指定被請求資源的Internet主機(jī)和端口號，它通常從HTTP URL中提取出來的，發(fā)送請求時(shí)，該報(bào)頭域是必需的。
  比如 我們在瀏覽器中輸入：http://www.imooc.com/index.jsp
  瀏覽器發(fā)送的請求消息中，就會包含Host請求報(bào)頭域，如下：Host：www.imooc.com
  此處使用缺省端口號80，若指定了端口號，則變成：Host：www.imooc.com:指定端口號。
• User-Agent我們上網(wǎng)登陸論壇的時(shí)候，往往會看到一些歡迎信息，其中列出了你的操作系統(tǒng)的名稱和版本，你所使用的瀏覽器的名稱和版本，這往往讓很多人感到很神奇，實(shí)際上，服務(wù)器應(yīng)用程序就是從User-Agent這個(gè)請求報(bào)頭域中獲取到這些信息。User-Agent請求報(bào)頭域允許客戶端將它的操作系統(tǒng)、瀏覽器和其它屬性告訴服務(wù)器。不過，這個(gè)報(bào)頭域不是必需的，如果我們自己編寫一個(gè)瀏覽器，不使用User-Agent請求報(bào)頭域，那么服務(wù)器端就無法得知我們的信息了。

請求報(bào)頭舉例：

---

響應(yīng)報(bào)頭

響應(yīng)報(bào)頭允許服務(wù)器傳遞不能放在狀態(tài)行中的附加響應(yīng)信息，以及關(guān)于服務(wù)器的信息和對Request-URI所標(biāo)識的資源進(jìn)行下一步訪問的信息。

常用的響應(yīng)報(bào)頭
Location響應(yīng)報(bào)頭域用于重定向接受者到一個(gè)新的位置。Location響應(yīng)報(bào)頭域常用在更換域名的時(shí)候。
Server響應(yīng)報(bào)頭域包含了服務(wù)器用來處理請求的軟件信息。與User-Agent請求報(bào)頭域是相對應(yīng)的。下面是Server響應(yīng)報(bào)頭域的一個(gè)例子：Server：nginx
WWW-Authenticate響應(yīng)報(bào)頭域必須被包含在401（未授權(quán)的）響應(yīng)消息中，客戶端收到401響應(yīng)消息時(shí)候，并發(fā)送Authorization報(bào)頭域請求服務(wù)器對其進(jìn)行驗(yàn)證時(shí)，服務(wù)端響應(yīng)報(bào)頭就包含該報(bào)頭域。
eg：WWW-Authenticate:Basic realm=”Basic Auth Test!” //可以看出服務(wù)器對請求資源采用的是基本驗(yàn)證機(jī)制。

實(shí)體報(bào)頭

請求和響應(yīng)消息都可以傳送一個(gè)實(shí)體。一個(gè)實(shí)體由實(shí)體報(bào)頭域和實(shí)體正文組成，但并不是說實(shí)體報(bào)頭域和實(shí)體正文要在一起發(fā)送，可以只發(fā)送實(shí)體報(bào)頭域。實(shí)體報(bào)頭定義了關(guān)于實(shí)體正文（eg：有無實(shí)體正文）和請求所標(biāo)識的資源的元信息。

常用的實(shí)體報(bào)頭：

• Content-Encoding實(shí)體報(bào)頭域被用作媒體類型的修飾符，它的值指示了已經(jīng)被應(yīng)用到實(shí)體正文的附加內(nèi)容的編碼，因而要獲得Content-Type報(bào)頭域中所引用的媒體類型，必須采用相應(yīng)的解碼機(jī)制。ContentEncoding這樣用于記錄文檔的壓縮方法，eg：Content-Encoding：gzip
• Content-Language實(shí)體報(bào)頭域描述了資源所用的自然語言。沒有設(shè)置該域則認(rèn)為實(shí)體內(nèi)容將提供給所有的語言閱讀
  者。eg：Content-Language:da
• Content-Length實(shí)體報(bào)頭域用于指明實(shí)體正文的長度，以字節(jié)方式存儲的十進(jìn)制數(shù)字來表示。
• Content-Type實(shí)體報(bào)頭域用語指明發(fā)送給接收者的實(shí)體正文的媒體類型。eg：Content-Type:text/html;charset=ISO-8859-1 Content-Type:text/html;charset=GB2312
• Last-Modified實(shí)體報(bào)頭域用于指示資源的最后修改日期和時(shí)間。
• Expires實(shí)體報(bào)頭域給出響應(yīng)過期的日期和時(shí)間。為了讓代理服務(wù)器或?yàn)g覽器在一段時(shí)間以后更新緩存中(再次訪問曾訪問過的頁面時(shí)，直接從緩存中加載，縮短響應(yīng)時(shí)間和降低服務(wù)器負(fù)載)的頁面，我們可以使用Expires實(shí)體報(bào)頭域指定頁面過期的時(shí)間。eg：Expires：Thu，15 Sep 2006 16:23:12 GMT
  HTTP1.1的客戶端和緩存必須將其他非法的日期格式（包括0）看作已經(jīng)過期。eg：為了讓瀏覽器不要緩存頁面，我們也可以利用Expires實(shí)體報(bào)頭域，設(shè)置為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();// 創(chuàng)建http客戶端HttpGet httpget = new HttpGet(httpUrl);HttpResponse response = null;HttpParams params = httpclient.getParams(); // 計(jì)算網(wǎng)絡(luò)超時(shí)用HttpConnectionParams.setConnectionTimeout(params, 15 * 1000);HttpConnectionParams.setSoTimeout(params, 20 * 1000);try {response = httpclient.execute(httpget);HttpEntity entity = response.getEntity();// 得到http的內(nèi)容response.getStatusLine().getStatusCode();// 得到http的狀態(tài)返回值result = EntityUtils.toString(response.getEntity());// 得到具體的返回值，一般是xml文件entity.consumeContent();// 如果entity不為空，則釋放內(nèi)存空間httpclient.getCookieStore();// 得到cookishttpclient.getConnectionManager().shutdown();// 關(guān)閉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(); // 計(jì)算網(wǎng)絡(luò)超時(shí)用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的內(nèi)容response.getStatusLine().getStatusCode();// 得到http的狀態(tài)返回值result = EntityUtils.toString(response.getEntity());// 得到具體的返回值，一般是xml文件entity.consumeContent();// 如果entity不為空，則釋放內(nèi)存空間httpclient.getCookieStore();// 得到cookishttpclient.getConnectionManager().shutdown();// 關(guān)閉http客戶端} catch (Exception e) {e.printStackTrace();} // base64是經(jīng)過編碼的字符串，可以理解為字符串 // StringEntitytry {httpPostEntity = new StringEntity("UTF-8");} catch (UnsupportedEncodingException e) {// TODO Auto-generated catch blocke.printStackTrace();}return result;} }

HTTPS協(xié)議

HTTPS協(xié)議概述

HTTPS（Hypertext Transfer Protocol over Secure Socket Layer，基于SSL的HTTP協(xié)議）使用了HTTP協(xié)議，但HTTPS使用不同于HTTP協(xié)議的默認(rèn)端口及一個(gè)加密、身份驗(yàn)證層（HTTP與TCP之間）。這個(gè)協(xié)議的最初研發(fā)由網(wǎng)景公司進(jìn)行，提供了身份驗(yàn)證與加密通信方法，現(xiàn)在它被廣泛用于互聯(lián)網(wǎng)上安全敏感的通信。HTTPS是一個(gè)安全通信通道，用于在客戶計(jì)算機(jī)和服務(wù)器之間交換信息。它使用安全套接字層(SSL)進(jìn)行信息交換，簡單來說它是HTTP的安全版。它是由Netscape開發(fā)并內(nèi)置于其瀏覽器中，用于對數(shù)據(jù)進(jìn)行壓縮和解壓操作，并返回網(wǎng)絡(luò)上傳送回的結(jié)果。

HTTPS實(shí)際上應(yīng)用了Netscape的安全全套接字層(SSL)作為HTTP應(yīng)用層的子層。(HTTPS使用端口443，而不是象HTTP那樣使用端口80來和TCP/IP進(jìn)行通信。)SSL使用40 位關(guān)鍵字作為RC4流加密算法，這對于商業(yè)信息的加密是合適的。HTTPS和SSL支持使用X。509數(shù)字認(rèn)證，如果需要的話用戶可以確認(rèn)發(fā)送者是誰。

使用HTTPS步驟

客戶端在使用HTTPS方式與Web服務(wù)器通信時(shí)有以下幾個(gè)步驟。
（1）客戶使用https的URL訪問Web服務(wù)器，要求與Web服務(wù)器建立SSL連接。
（2）Web服務(wù)器收到客戶端請求后，會將網(wǎng)站的證書信息（證書中包含公鑰）傳送一份給客戶端。
（3）客戶端的瀏覽器與Web服務(wù)器開始協(xié)商SSL連接的安全等級，也就是信息加密的等級。
（4）客戶端的瀏覽器根據(jù)雙方同意的安全等級，建立會話密鑰，然后利用網(wǎng)站的公鑰將會話密鑰加密，并傳送給網(wǎng)站。
（5）Web服務(wù)器利用自己的私鑰解密出會話密鑰。
（6）Web服務(wù)器利用會話密鑰加密與客戶端之間的通信。

工具類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() };// 創(chuàng)建信任規(guī)則列表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;}};/*** * 信任所有主機(jī)-對于任何證書都不做檢查 Create a trust manager that does not validate ** certificate chains， Android 采用X509的證書信息機(jī)制，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()); // 不進(jìn)行主機(jī)名確認(rèn),對所有主機(jī)HttpsURLConnection.setDefaultHostnameVerifier(DO_NOT_VERIFY);} catch (Exception e) {e.printStackTrace();}} // https get方法，返回值是https請求，服務(wù)端返回的數(shù)據(jù)string類型，數(shù)據(jù)進(jìn)行xml解析 public static String HttpsGet(String httpsurl) { return HttpsPost(httpsurl, null); }/*** https post方法，返回值是https請求，服務(wù)端返回的數(shù)據(jù)string類型，數(shù)據(jù)進(jìn)行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);// 不進(jìn)行主機(jī)名確認(rèn)} else {http = (HttpURLConnection) url.openConnection();}http.setConnectTimeout(CONNENT_TIMEOUT);// 設(shè)置超時(shí)時(shí)間http.setReadTimeout(READ_TIMEOUT);if (data == null) {http.setRequestMethod("GET");// 設(shè)置請求類型http.setDoInput(true);// http.setRequestProperty("Content-Type", "text/xml");if (AppSession.mCookieStore != null)http.setRequestProperty("Cookie", AppSession.mCookieStore);} else {http.setRequestMethod("POST");// 設(shè)置請求類型為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();} // 設(shè)置http返回狀態(tài)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安全性更高。

兩者的區(qū)別

• https協(xié)議需要到ca申請證書，一般免費(fèi)證書很少，需要交費(fèi)。
• http是超文本傳輸協(xié)議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協(xié)議
• http和https使用的是完全不同的連接方式用的端口也不一樣：前者是80，后者是443。
• http的連接很簡單，是無狀態(tài)的 ，HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議 ，要比http協(xié)議安全。

HTTPS解決的問題：

1、信任主機(jī)的問題。 采用https 的server 必須從CA 申請一個(gè)用于證明服務(wù)器用途類型的證書。
該證書只有用于對應(yīng)的server 的時(shí)候，客戶度才信任此主機(jī)。所以目前所有的銀行系統(tǒng)網(wǎng)站，關(guān)鍵部分應(yīng)用都是https 的。 客戶通過信任該證書，從而信任了該主機(jī)。其實(shí)這樣做效率很低，但是銀行更側(cè)重安全。 這一點(diǎn)對我們沒有任何意義，我們的server，采用的證書不管自己issue 還是從公眾的地方issue， 客戶端都是自己人，所以我們也就肯定信任該server。
2、通訊過程中的數(shù)據(jù)的泄密和被竄改。
1）一般意義上的https， 就是 server 有一個(gè)證書。
主要目的是保證server 就是他聲稱的server。這個(gè)跟第一點(diǎn)一樣。服務(wù)端和客戶端之間的所有通訊，都是加密的。
具體講，是客戶端產(chǎn)生一個(gè)對稱的密鑰，通過server 的證書來交換密鑰。 一般意義上的握手過程。加下來所有的信息往來就都是加密的。 第三方即使截獲，也沒有任何意義。因?yàn)樗麤]有密鑰。當(dāng)然竄改也就沒有什么意義了。
2）少許對客戶端有要求的情況下，會要求客戶端也必須有一個(gè)證書。
這里客戶端證書，其實(shí)就類似表示個(gè)人信息的時(shí)候，除了用戶名/密碼， 還有一個(gè)CA 認(rèn)證過的身份。 應(yīng)為個(gè)人證書一般來說上別人無法模擬的，所有這樣能夠更深的確認(rèn)自己的身份。目前少數(shù)個(gè)人銀行的專業(yè)版是這種做法，具體證書可能是拿U盤作為一個(gè)備份的載體。 HTTPS 一定是繁瑣的。
本來簡單的http協(xié)議，一個(gè)get一個(gè)response。由于https 要還密鑰和確認(rèn)加密算法的需要。單握手就需要6/7 個(gè)往返。任何應(yīng)用中，過多的round trip 肯定影響性能。接下來才是具體的http協(xié)議，每一次響應(yīng)或者請求， 都要求客戶端和服務(wù)端對會話的內(nèi)容做加密/解密。盡管對稱加密/解密效率比較高，可是仍然要消耗過多的CPU，為此有專門的SSL 芯片。 如果CPU 信能比較低的話，肯定會降低性能，從而不能serve 更多的請求。

SSL的簡介

SSL是Netscape公司所提出的安全保密協(xié)議，在瀏覽器(如Internet Explorer、Netscape Navigator)和Web服務(wù)器(如Netscape的Netscape Enterprise Server、ColdFusion Server等等)之間構(gòu)造安全通道來進(jìn)行數(shù)據(jù)傳輸，SSL運(yùn)行在TCP/IP層之上、應(yīng)用層之下，為應(yīng)用程序提供加密數(shù)據(jù)通道，它采用了RC4、MD5 以及RSA等加密算法，使用40 位的密鑰，適用于商業(yè)信息的加密。
同時(shí)，Netscape公司相應(yīng)開發(fā)了HTTPS協(xié)議并內(nèi)置于其瀏覽器中，HTTPS實(shí)際上就是SSL over HTTP，它使用默認(rèn)端口443，而不是像HTTP那樣使用端口80來和TCP/IP進(jìn)行通信。HTTPS協(xié)議使用SSL在發(fā)送方把原始數(shù)據(jù)進(jìn)行加密，然 后在接受方進(jìn)行解密，加密和解密需要發(fā)送方和接受方通過交換共知的密鑰來實(shí)現(xiàn)，因此，所傳送的數(shù)據(jù)不容易被網(wǎng)絡(luò)黑客截獲和解密。
然而，加密和解密過程需要耗費(fèi)系統(tǒng)大量的開銷，嚴(yán)重降低機(jī)器的性能，相關(guān)測試數(shù)據(jù)表明使用HTTPS協(xié)議傳輸數(shù)據(jù)的工作效率只有使用HTTP協(xié)議傳輸?shù)氖?分之一。
假如為了安全保密，將一個(gè)網(wǎng)站所有的Web應(yīng)用都啟用SSL技術(shù)來加密，并使用HTTPS協(xié)議進(jìn)行傳輸，那么該網(wǎng)站的性能和效率將會大大降低，而且沒有這個(gè)必要，因?yàn)橐话銇碚f并不是所有數(shù)據(jù)都要求那么高的安全保密級別，所以，我們只需對那些涉及機(jī)密數(shù)據(jù)的交互處理使用HTTPS協(xié)議，這樣就做到魚與熊掌兼得。總之不需要用https 的地方，就盡量不要用。

參考：http://aresxiong.com/2015/11/30/protocol_http_and_https

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。