概况
HTTP是hypertext transfer protocol（超文本传输协议）的简写。它是TCP/IP协议的一个应用层协议，用于定义WEB浏览器与WEBserver之间交换数据的过程。
HTTP是一个属于应用层的面向对象的协议，因为其简捷、高速的方式，适用于分布式超媒体信息系统。它于1990年提出。经过几年的使用与发展。得到不断地完好和扩展。眼下在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，并且HTTP-NG(Next Generation of HTTP)的建议已经提出。
主要特点
HTTP协议的主要特点可概括例如以下：
- 1.支持客户/server模式。
- 2.简单高速：客户向server请求服务时，仅仅需传送请求方法和路径。
请求方法经常使用的有GET、HEAD、POST。每种方法规定了客户与server联系的类型不同。因为HTTP协议简单。使得HTTPserver的程序规模小，因而通信速度非常快。
- 3.灵活：HTTP同意传输随意类型的数据对象。
正在传输的类型由Content-Type加以标记。
- 4.无连接：无连接的含义是限制每次连接仅仅处理一个请求。server处理完客户的请求，并收到客户的应答后，即断开连接。採用这样的方式能够节省传输时间。
- 5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着假设兴许处理须要前面的信息。则它必须重传，这样可能导致每次连接传送的数据量增大。
还有一方面，在server不须要先前信息时它的应答就较快
。
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 请求server存储一个资源。并用Request-URI作为其标识
- DELETE 请求server删除Request-URI所标识的资源
- TRACE 请求server回送收到的请求信息，主要用于測试或诊断
- CONNECT 保留将来使用
- OPTIONS 请求查询server的性能，或者查询与资源相关的选项和需求
应用举例：
GET方法：在浏览器的地址栏中输入网址的方式訪问网页时，浏览器採用GET方法向server获取资源。eg:GET /form.html HTTP/1.1 (CRLF)
POST方法：要求被请求server接受附在请求后面的数据，经常使用于提交表单。
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协议具体解释之响应
在接收和解释请求消息后。server返回一个HTTP响应消息。
HTTP响应也是由三个部分组成，各自是：状态行、消息报头、响应正文
状态行格式例如以下
HTTP-Version Status-Code Reason-Phrase CRLF
当中：
HTTP-Version表示serverHTTP协议的版本号；
Status-Code表示server发回的响应状态代码；
Reason-Phrase表示状态代码的文本描写叙述。
状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：
- 1xx:信息响应类，表示接收到请求并且继续处理
- 2xx:处理成功响应类，表示动作被成功接收、理解和接受
- 3xx:重定向响应类，为了完毕指定的动作。必须接受进一步处理
- 4xx:client错误。客户请求包括语法错误或者是不能正确运行
- 5xx:服务端错误，server不能正确运行一个正确的请求
常见状态代码、状态描写叙述、说明：
- 200 OK //client请求成功
- 400 Bad Request //client请求有语法错误，不能被server所理解
- 401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
- 403 Forbidden //server收到请求，可是拒绝提供服务
- 404 Not Found //请求资源不存在，eg：输入了错误的URL
- 500 Internal Server Error //server发生不可预期的错误
- 503 Server Unavailable //server当前不能处理client的请求，一段时间后可能恢复正常
eg：HTTP/1.1 200 OK （CRLF）
响应报头后述
响应正文就是server返回的资源的内容
HTTP协议具体解释之消息报头
HTTP消息由client到server的请求和server到client的响应组成。请求消息和响应消息都是由開始行（对于请求消息，開始行就是请求行，对于响应消息。開始行就是状态行），消息报头（可选），空行（仅仅有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浏览器（client）不要缓存页面，server端的JSP程序能够编写例如以下：
response.setHeader("Cache-Control","no-cache");
//response.setHeader("Pragma","no-cache");作用相当于上述代码，通常两者//合用
这句代码将在发送的响应消息中设置普通报头域：Cache-Control:no-cache
Date普通报头域表示消息产生的日期和时间
Connection普通报头域同意发送指定连接的选项。
比如指定连接是连续，或者指定“close”选项，通知server，在响应完毕后。关闭连接.
请求报头
请求报头同意client向server端传递请求的附加信息以及client自身的信息。
经常使用的请求报头:
Accept请求报头域用于指定client接受哪些类型的信息。
举例：
Accept：image/gif，表明client希望接受GIF图象格式的资源。
Accept：text/html。表明client希望接受html文本。Accept-Charset请求报头域用于指定client接受的字符集。
举例：Accept-Charset:iso-8859-1,gb2312.
假设在请求消息中没有设置这个域，缺省是不论什么字符集都能够接受。- Accept-Encoding请求报头域相似于Accept。可是它是用于指定可接受的内容编码。
举例：Accept-Encoding:gzip.deflate.
假设请求消息中没有设置这个域server假定client对各种内容编码都能够接受。 - Accept-Language请求报头域相似于Accept，可是它是用于指定一种自然语言。
举例：Accept-Language:zh-cn.
假设请求消息中没有设置这个报头域，server假定client对各种语言都能够接受。 - Authorization 请求报头域主要用于证明client有权查看某个资源。当浏览器訪问一个页面时。假设收到server的响应代码为401（未授权），能够发送一个包括Authorization请求报头域的请求，要求server对其进行验证。
- Host请求报头域主要用于指定被请求资源的Internet主机和端口号。它通常从HTTP URL中提取出来的。发送请求时。该报头域是必需的。
比方 我们在浏览器中输入：http://www.imooc.com/index.jsp
浏览器发送的请求消息中，就会包括Host请求报头域。例如以下：Host：www.imooc.com
此处使用缺省端口号80。若指定了端口号，则变成：Host：www.imooc.com:指定端口号。 - User-Agent我们上网登陆论坛的时候，往往会看到一些欢迎信息。当中列出了你的操作系统的名称和版本号。你所使用的浏览器的名称和版本号，这往往让非常多人感到非常奇妙，实际上，server应用程序就是从User-Agent这个请求报头域中获取到这些信息。
User-Agent请求报头域同意client将它的操作系统、浏览器和其它属性告诉server。
只是。这个报头域没必要的。假设我们自己编写一个浏览器，不使用User-Agent请求报头域。那么server端就无法得知我们的信息了。
请求报头举例：
响应报头
响应报头同意server传递不能放在状态行中的附加响应信息，以及关于server的信息和对Request-URI所标识的资源进行下一步訪问的信息。
经常使用的响应报头
Location响应报头域用于重定向接受者到一个新的位置。Location响应报头域经常使用在更换域名的时候。
Server响应报头域包括了server用来处理请求的软件信息。与User-Agent请求报头域是相相应的。下面是Server响应报头域的一个样例：Server：nginx
WWW-Authenticate响应报头域必须被包括在401（未授权的）响应消息中，client收到401响应消息时候，并发送Authorization报头域请求server对其进行验证时，服务端响应报头就包括该报头域。
eg：WWW-Authenticate:Basic realm=”Basic Auth Test!” //能够看出server对请求资源採用的是基本验证机制。
实体报头
请求和响应消息都能够传送一个实体。一个实体由实体报头域和实体正文组成。但并非说实体报头域和实体正文要在一起发送。能够仅仅发送实体报头域。实体报头定义了关于实体正文（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实体报头域给出响应过期的日期和时间。为了让代理server或浏览器在一段时间以后更新缓存中(再次訪问曾訪问过的页面时。直接从缓存中载入，缩短响应时间和减少server负载)的页面。我们能够使用Expires实体报头域指定页面过期的时间。eg：Expires：Thu，15 Sep 2006 16:23:12 GMT
HTTP1.1的client和缓存必须将其它非法的日期格式（包括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();// 创建httpclient
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();// 得到cookis
httpclient.getConnectionManager().shutdown();// 关闭httpclient
} 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();// 得到cookis
httpclient.getConnectionManager().shutdown();// 关闭httpclient
} catch (Exception e) {
e.printStackTrace();
} // base64是经过编码的字符串，能够理解为字符串 // StringEntity
try {
httpPostEntity = new StringEntity("UTF-8");
} catch (UnsupportedEncodingException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return result;
}
}HTTPS协议
HTTPS协议概述
HTTPS（Hypertext Transfer Protocol over Secure Socket Layer。基于SSL的HTTP协议）使用了HTTP协议。但HTTPS使用不同于HTTP协议的默认端口及一个加密、身份验证层（HTTP与TCP之间）。这个协议的最初研发由网景公司进行，提供了身份验证与加密通信方法，如今它被广泛用于互联网上安全敏感的通信。HTTPS是一个安全通信通道，用于在客户计算机和server之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版。
它是由Netscape开发并内置于其浏览器中，用于对数据进行压缩和解压操作。并返回网络上传送回的结果。
HTTPS实际上应用了Netscape的安全全套接字层(SSL)作为HTTP应用层的子层。(HTTPS使用端口443。而不是象HTTP那样使用端口80来和TCP/IP进行通信。)SSL使用40 位关键字作为RC4流加密算法，这对于商业信息的加密是合适的。HTTPS和SSL支持使用X。509数字认证。假设须要的话用户能够确认发送者是谁。
使用HTTPS步骤
client在使用HTTPS方式与Webserver通信时有下面几个步骤。
（1）客户使用https的URL訪问Webserver，要求与Webserver建立SSL连接。
（2）Webserver收到client请求后。会将站点的证书信息（证书中包括公钥）传送一份给client。
（3）client的浏览器与Webserver開始协商SSL连接的安全等级，也就是信息加密的等级。
（4）client的浏览器依据两方同意的安全等级，建立会话密钥，然后利用站点的公钥将会话密钥加密，并传送给站点。
（5）Webserver利用自己的私钥解密出会话密钥。
（6）Webserver利用会话密钥加密与client之间的通信。
工具类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");// 设置请求类型为post
http.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）还是403
AppSession.httpsResponseCode = http.getResponseCode();
BufferedReader in = null;
if (AppSession.httpsResponseCode == 200) {
getCookie(http);
in = new BufferedReader(new InputStreamReader(http.getInputStream()));
} else
in = new BufferedReader(new InputStreamReader(http.getErrorStream()));
String temp = in.readLine();
while (temp != null) {
if (result != null)
result += temp;
else
result = 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的连接非常easy，是无状态的 ，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议 ，要比http协议安全。
HTTPS解决的问题：
1、信任主机的问题。
採用https 的server 必须从CA 申请一个用于证明server用途类型的证书。
该证书仅仅实用于相应的server 的时候，客户度才信任此主机。所以眼下全部的银行系统站点。关键部分应用都是https 的。 客户通过信任该证书。从而信任了该主机。事实上这样做效率非常低，可是银行更側重安全。 这一点对我们没有不论什么意义，我们的server，採用的证书无论自己issue 还是从公众的地方issue。 client都是自己人，所以我们也就肯定信任该server。
2、通讯过程中的数据的泄密和被窜改。
1）一般意义上的https。 就是 server 有一个证书。
主要目的是保证server 就是他声称的server。
这个跟第一点一样。
服务端和client之间的全部通讯。都是加密的。
具体讲。是client产生一个对称的密钥。通过server 的证书来交换密钥。 一般意义上的握手过程。
加下来全部的信息往来就都是加密的。
第三方即使截获，也没有不论什么意义。因为他没有密钥。当然窜改也就没有什么意义了。
2）少许对client有要求的情况下。会要求client也必须有一个证书。
这里client证书，事实上就相似表示个人信息的时候，除了用户名/密码， 还有一个CA 认证过的身份。
应为个人证书一般来说上别人无法模拟的，全部这样能够更深的确认自己的身份。
眼下少数个人银行的专业版是这样的做法。具体证书可能是拿U盘作为一个备份的载体。 HTTPS 一定是繁琐的。
本来简单的http协议。一个get一个response。因为https 要还密钥和确认加密算法的须要。单握手就须要6/7 个往返。不论什么应用中，过多的round trip 肯定影响性能。
接下来才是具体的http协议，每一次响应或者请求。 都要求client和服务端对会话的内容做加密/解密。
虽然对称加密/解密效率比較高，可是仍然要消耗过多的CPU，为此有专门的SSL 芯片。 假设CPU 信能比較低的话。肯定会减少性能。从而不能serve 很多其它的请求。
SSL的简单介绍
SSL是Netscape公司所提出的安全保密协议。在浏览器(如Internet Explorer、Netscape Navigator)和Webserver(如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在发送方把原始数据进行加密，然 后在接受方进行解密，加密和解密须要发送方和接受方通过交换共知的密钥来实现，因此，所传送的数据不easy被网络黑客截获和解密。
然而。加密和解密过程须要耗费系统大量的开销，严重减少机器的性能，相关測试数据表明使用HTTPS协议数据传输的工作效率仅仅有使用HTTP协议传输的十 分之中的一个。
假如为了安全保密，将一个站点全部的Web应用都启用SSL技术来加密，并使用HTTPS协议进行传输，那么该站点的性能和效率将会大大减少。并且没有这个必要。因为一般来说并非全部数据都要求那么高的安全保密级别。所以，我们仅仅需对那些涉及机密数据的交互处理使用HTTPS协议，这样就做到鱼与熊掌兼得。总之不须要用https 的地方，就尽量不要用。