在这里，我们将给大家分享关于https会话和发布问题的知识，让您更了解https会进行什么处理的本质，同时也会涉及到如何更有效地angularJshttp发布问题：插入数据、fail2banport=
在这里，我们将给大家分享关于https会话和发布问题的知识，让您更了解https会进行什么处理的本质，同时也会涉及到如何更有效地angularJs http发布问题：插入数据、fail2ban port=https,http 只屏蔽 https 不屏蔽 http、HTTP+ 加密 + 认证 + 完整性保护 =HTTPS（HTTPS 安全通信机制）、HTTP/HTTPS/HTTP2/HTTP3/QUIC/WebSocket协议详解的内容。
本文目录一览：- https会话和发布问题（https会进行什么处理）
- angularJs http发布问题：插入数据
- fail2ban port=https,http 只屏蔽 https 不屏蔽 http
- HTTP+ 加密 + 认证 + 完整性保护 =HTTPS（HTTPS 安全通信机制）
- HTTP/HTTPS/HTTP2/HTTP3/QUIC/WebSocket协议详解
https会话和发布问题（https会进行什么处理）
我有一个应用程序，需要能够通过身份验证请求然后向注册请求发布到https。目前，我可以将身份验证请求发布到https，并且工作正常。当我尝试将注册请求发布到https时，我不断收到服务器响应，说我需要进行身份验证。在尝试注册之前，我正在认证。
服务器的管理员说我可能没有保留该会话。
我是第一次使用android和java做东西。我是这个https内容的新手。我想知道是否有人可以在这里帮助我，我不知道这是否是确定的问题，甚至不知道如何在Android中保留https会话。
下面是我的代码，任何建议都将不胜感激！！！！提前致谢！！
//my helper class
public class SmartDBHelper {
private static Context tThis;
private static SmartDBHelper sDBHObject;
private static String macAddress;
private static String ipAddress;
private static HttpsURLConnection https;
/* constructor,private prevents any other class from instantiating */
private SmartDBHelper() {
}
public static synchronized SmartDBHelper getSDBHObject() {
if(sDBHObject == null) {
sDBHObject = new SmartDBHelper();
}
return sDBHObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
public static synchronized void setSmartContext(SmartApp smartApp) {
tThis = (Context) smartApp;
}
private static synchronized void setMACIPAddress() {
WifiManager wifiMan = (WifiManager) tThis.getSystemService (tThis.WIFI_SERVICE);
WifiInfo wifiInf = wifiMan.getConnectionInfo();
macAddress = wifiInf.getMacAddress().replace(':','-');
ipAddress = wifiMan.getDhcpInfo().toString();
int startIndex = ipAddress.indexOf(' ');
int endIndex = ipAddress.indexOf(' ',startIndex + 1);
ipAddress = ipAddress.substring(startIndex + 1,endIndex);
}
/* this function is to authenticate with the database
* it returns the id_subject,if it is greater than 0
* authentication was successful.
*/
public static synchronized int authenticate() throws MalformedURLException,ProtocolException,IOException {
Map<String,String> tempMap = new LinkedHashMap<String,String>();
tempMap.put((String) tThis.getResources().getText(R.string.postAction),(String) tThis.getResources().getText(R.string.postAuthenticate));
tempMap.put((String) tThis.getResources().getText(R.string.authUName),"username");
tempMap.put((String) tThis.getResources().getText(R.string.authPWord),"password");
String tempUrl = "https://ipaddress/health_monitoring/admin.php";
return Integer.parseInt(post(tempUrl,tempMap));
}
/* this function is to register the server to the database
* not sure of return value
*/
public static synchronized int registerServer(String nameOfServer,String description) throws MalformedURLException,IOException {
setMACIPAddress();
Map<String,(String) tThis.getResources().getText(R.string.postAddServer));
tempMap.put((String) tThis.getResources().getText(R.string.addServerName),"Phone");
tempMap.put((String) tThis.getResources().getText(R.string.addServerDescription),"Android");
tempMap.put((String) tThis.getResources().getText(R.string.addServerURL),"");
tempMap.put((String) tThis.getResources().getText(R.string.addServerIPAddress),ipAddress);
tempMap.put((String) tThis.getResources().getText(R.string.addServerMAC),macAddress);
String tempUrl = "https://ipaddress/health_monitoring/admin.php";
return Integer.parseInt(post(tempUrl,tempMap));
}
// always verify the host - dont check for certificate
final static HostnameVerifier DO_NOT_VERIFY = new HostnameVerifier() {
public boolean verify(String hostname,SSLSession session) {
return true;
}
};
/**
* Trust every server - dont check for any certificate
*/
private static void trustAllHosts() {
// Create a trust manager that does not validate certificate chains
TrustManager[] trustAllCerts = new TrustManager[] { new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return new java.security.cert.X509Certificate[] {};
}
public void checkClientTrusted(X509Certificate[] chain,String authType) throws CertificateException {
}
public void checkServerTrusted(X509Certificate[] chain,String authType) throws CertificateException {
}
} };
// Install the all-trusting trust manager
try {
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(null,trustAllCerts,new java.security.SecureRandom());
HttpsURLConnection
.setDefaultSSLSocketFactory(sc.getSocketFactory());
} catch (Exception e) {
e.printStackTrace();
}
}
private static String post(String urlString,Map formParameters)
throws MalformedURLException,IOException {
DataOutputStream ostream = null;
trustAllHosts();
URL tempUrl;
StringBuffer buf = new StringBuffer();
if(formParameters != null) {
Set parameters = formParameters.keySet();
Iterator it = parameters.iterator();
for(int i = 0,paramCount = 0; it.hasNext(); i++) {
String parameterName = (String) it.next();
String parameterValue = (String) formParameters.get(parameterName);
if(parameterValue != null) {
parameterValue = URLEncoder.encode(parameterValue);
if(paramCount > 0) {
buf.append("&");
}
buf.append(parameterName);
buf.append("=");
buf.append(parameterValue);
++paramCount;
}
}
}
urlString = urlString + "?" + buf;
Log.v("smartdbhelper url string",urlString);
tempUrl = new URL(urlString);
https = (HttpsURLConnection) tempUrl.openConnection();
https.setHostnameVerifier(DO_NOT_VERIFY);
Log.v("smartdbhelper adding post parameters",https.toString());
https.setRequestMethod("POST");
https.setDoInput(true);
https.setDoOutput(true);
ostream = new DataOutputStream(https.getOutputStream());
ostream.writeBytes(buf.toString());
if( ostream != null ) {
ostream.flush();
ostream.close();
}
Object contents = https.getContent();
InputStream is = (InputStream) contents;
StringBuffer buf2 = new StringBuffer();
int c;
while((c = is.read()) != -1) {
buf2.append((char)c);
Log.v("smartdbhelper bugger",buf2.toString());
}
//https.disconnect();
return buf2.toString();
}
}
angularJs http发布问题：插入数据
如何解决angularJs http发布问题：插入数据？
我在使用angularJs和Spring Boot插入数据时遇到问题，我已经用邮递员测试了url，并且除使用angular的格式外，其他所有东西都在工作。 角度的控制器
function addCtrl($scope,$state,$http,$window) {
/***ajouter un hotel******/
$scope.AddItem = function AddItem() {
console.log("clik");
var nom = document.getElementById(''nom'').value;
var localisation = document.getElementById(''localisation'').value;
$http({
method: ''POST'',url: ''http://localhost:1001/Hotel'',params: {nom,localisation},})
}
后端服务
@PostMapping(value="/Hotel")public Hotel saveHotel1(@RequestBody Hotel h{h.getNom();h.getLocalisation();return HR.save(h);}
插入结果BECOME
"org.springframework.http.converter.HttpMessageNotReadableException: required request body is missing "
仍然适用于邮递员，但不能与angular一起使用，错误变为：“ POST http：// localhost：1002 / Hotel？localisation = Tunis＆nom = hotel”
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@）
fail2ban port=https,http 只屏蔽 https 不屏蔽 http
您确实覆盖了操作条目中的端口值（并且做错了）：
- action = iptables-ipset-proto6[...,port=https,http,...]
+ action = iptables-ipset-proto6[...,port="https,http" ...]
所以在你的情况下，http 只是另一个参数名称，而且它也无关紧要，你现在直接在 jail 中指定哪些端口。
还有已经为您准备好的正确的）插值变量action和action_（例如参见jail.conf）。
无论如何，如果您不需要它，请不要覆盖它......在您的情况下，像这样设置 banaction 就足够了：
[wordpress]
banaction = iptables-ipset-proto6
顺便说一句，您的正则表达式极其脆弱，最好更精确地重写它，至少消除所有问题.*。
HTTP+ 加密 + 认证 + 完整性保护 =HTTPS（HTTPS 安全通信机制）
前言：HTTP 加上加密处理和认证以及完整性保护后即是HTTPS
如果在 HTTP 协议通信过程中使用未经加密的明文，比如在 Web 页面中输入信用卡号，如果这条通信线路遭到窃听，那么信用卡号就暴露了。另外，对于 HTTP 来说，服务器也好，客户端也好，都是没有办法确认通信方的。因为很有可能并不是和原本预想的通信方在实际通信。并且还需要考虑到接收到的报文在通信途中已经遭到篡改这一可能性。为了统一解决上述这些问题，需要在 HTTP 上再加入加密处理和认证等机制。我们把添加了加密及认证机制的 HTTP 称为 HTTPS（HTTP Secure）。
文章目录
前言：HTTP 加上加密处理和认证以及完整性保护后即是HTTPS一、HTTPS 是身披 SSL 外壳的 HTTP二、相互交换**的公开**加密技术1.共享**加密（对称加密）的困境2.使用两把**的公开**加密（非对称加密）3.HTTPS 采用混合加密机制4.证明公开**正确性的证书（SSL证书）5.用以确认客户端的客户端证书6.由自认证机构颁发的证书称为自签名证书三、 HTTPS 的安全通信机制四、拓展一、HTTPS 是身披 SSL 外壳的 HTTP
HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披SSL 协议这层外壳的 HTTP。
SSL 是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL 是当今世界上应用最为广泛的网络安全技术。
二、相互交换**的公开**加密技术
在了解SSL之前，应该先来了解一下加密方法。SSL 采用一种叫做公开**加密（Public-key cryptography）的加密处理方式。近代的加密方法中加密算法是公开的，而**却是保密的。通过这种方式得以保持加密方法的安全性。
加密和解密都会用到**。没有**就无法对密码解密，反过来说，任何人只要持有**就能解密了。如果**被攻击者获得，那加密也就失去了意义。
1.共享**加密（对称加密）的困境
加密和解密同用一个**的方式称为共享**加密（Common keycrypto system），也被叫做对称**加密。以共享**方式加密时必须将**也发给对方。可究竟怎样才能安全地转交？在互联网上转发**时，如果通信被监听那么**就可能落入攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的**。发送**就有被窃听的风险，但不发送，对方就无法解密。再说，**若能安全送达，那数据也能安全送达，即不需要**了。
2.使用两把**的公开**加密（非对称加密）
公开**加密方式很好地解决了共享**加密的困难公开**加密使用一对非对称的**。一把叫做私有**（private key），另一把叫做公开**（public key）。顾名思义，私有**不能让其他任何人知道，而公开**则可以随意发布，任何人都可以获得。
使用公开**加密方式，发送密文的一方使用对方的公开**进行加密处理，对方收到被加密的信息后，再使用自己的私有**进行解密。利用这种方式，不需要发送用来解密的私有**，也不必担心**被攻击者窃听而盗走。
另外，要想根据密文和公开**，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。退一步讲，如果能对一个非常大的整数做到快速地因式分解，那么密码**还是存在希望的。但就目前的技术来看是不太现实的。
3.HTTPS 采用混合加密机制
HTTPS 采用共享**加密（对称加密）和公开**加密（非对称加密）两者并用的混合加密机制。公开**加密与共享**加密相比，其处理速度要慢。所以应充分利用两者各自的优势，将多种方法组合起来用于通信。在交换**环节使用公开**加密方式，之后的建立通信交换报文阶段则使用共享**加密方式。
4.证明公开**正确性的证书（SSL证书）
但是，公钥加密方式还是存在一些问题的。那就是无法证明公钥本身就是货真价实的公钥。比如，正准备和某台服务器建立公钥加密通信时，如何证明收到的公钥就是原本预想的那台服务器发行的公钥。或许在公钥传输途中，真正的公钥已经被攻击者替换掉了。
为了解决上述问题，可以使用由数字证书认证机构（CA，CertificateAuthority）及其相关机关颁发的公开**证书。数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。
数字证书认证机构的业务流程：首先，服务器的运营人员向数字证书认证机构提出公钥的申请。数字证书认证机构在判明提出申请者的身份之后，会对已申请的公钥做数字签名，然后分配这个已签名的公钥，并将该公钥放入公钥证书后绑定在一起。服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公钥加密方式通信。
接到证书的客户端可使用数字证书认证机构的公钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确服务器的公钥是值得信赖的。此处认证机关的公钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开**。
5.用以确认客户端的客户端证书
HTTPS 中还可以使用客户端证书。以客户端证书进行客户端认证，证明服务器正在通信的对方始终是预料之内的客户端，其作用跟服务器证书如出一辙。但客户端证书仍存在几处问题点。其中的一个问题点是证书的获取及发布。想获取证书时，用户得自行安装客户端证书。但由于客户端证书是要付费购买的，且每张证书对应到每位用户也就意味着需支付和用户数对等的费用。另外，要让知识层次不同的用户们自行安装证书，这件事本身也充满了各种挑战。
现状是，安全性极高的认证机构可颁发客户端证书但仅用于特殊用途的业务。比如那些可支撑客户端证书支出费用的业务。例如，银行的网上银行就采用了客户端证书。在登录网银时不仅要求用户确认输入 ID 和密码，还会要求用户的客户端证书，以确认用户是否从特定的终端访问网银。
客户端证书存在的另一个问题点是，客户端证书毕竟只能用来证明客户端实际存在，而不能用来证明用户本人的真实有效性。也就是说，只要获得了安装有客户端证书的计算机的使用权限，也就意味着同时拥有了客户端证书的使用权限。
6.由自认证机构颁发的证书称为自签名证书
如果使用 OpenSSL 这套开源程序，每个人都可以构建一套属于自己的认证机构，从而自己给自己颁发服务器证书。但该服务器证书在互联网上不可作为证书使用，似乎没什么帮助。独立构建的认证机构叫做自认证机构，由自认证机构颁发的“无用”证书也被戏称为自签名证书。浏览器访问该服务器时，会显示“无法确认连接安全性”或“该网站的安全证书存在问题”等警告消息。
自认证机构能够产生的作用顶多也就是自己对外宣称“我是○○”的这种程度。即使采用自签名证书，通过 SSL加密之后，可能偶尔还会看见通信处在安全状态的提示，可那也是有问题的。因为 就算加密通信，也不能排除正在和已经过伪装的假服务器保持通信。
值得信赖的第三方机构介入认证，才能让已植入在浏览器内的认证机构颁布的公开**发挥作用，并借此证明服务器的真实性。
中级认证机构的证书可能会变成自认证证书多数浏览器内预先已植入备受信赖的认证机构的证书，但也有一小部分浏览器会植入中级认证机构的证书。
对于中级认证机构颁发的服务器证书，某些浏览器会以正规的证书来对待，可有的浏览器会当作自签名证书。
Powered by Ad.Plus
三、 HTTPS 的安全通信机制
步骤 1： 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列（所使用的加密算法及**长度等）。步骤 2： 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。步骤 3： 之后服务器发送 Certificate 报文。报文中包含公钥证书。步骤 4： 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。步骤 5： SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公钥进行加密。步骤 6： 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret **加密（对称加密）。步骤 7： 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。步骤 8： 服务器同样发送 Change Cipher Spec 报文。步骤 9： 服务器同样发送 Finished 报文。步骤 10： 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。步骤 11： 应用层协议通信，即发送 HTTP 响应。步骤 12： 最后由客户端断开连接。断开连接时，发送 close_notify 报文。这步之后再发送 TCP FIN 报文来关闭与 TCP的通信。在以上流程中，应用层发送数据时会附加一种叫做 MAC（MessageAuthentication Code）的报文摘要。MAC 能够查知报文是否遭到篡改，从而保护报文的完整性。
下面是对整个流程的图解。图中说明了从仅使用服务器端的公钥证书（服务器证书）建立 HTTPS 通信的整个过程。
注： CBC 模式（Cipher Block Chaining）又名密码分组链接模式。在此模式下，将前一个明文块加密处理后和下一个明文块做 XOR 运算，使之重叠，然后再对运算结果做加密处理。对第一个明文块做加密时，要么使用前一段密文的最后一块，要么利用外部生成的初始向量（initial vector，IV）。
四、拓展
SSL 速度慢吗HTTPS 也存在一些问题，那就是当使用 SSL 时，它的处理速度会变慢。
SSL 的慢分两种。一种是指通信慢。另一种是指由于大量消耗cpu 及内存等资源，导致处理速度变慢。和使用 HTTP 相比，网络负载可能会变慢 2 到 100 倍。除去和TCP 连接、发送 HTTP 请求 • 响应以外，还必须进行 SSL 通信，因此整体上处理通信量不可避免会增加。另一点是 SSL 必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起 HTTP 会更多地消耗服务器和客户端的硬件资源，导致负载增强。
针对速度变慢这一问题，并没有根本性的解决方案，会使用SSL 加速器这种（专用服务器）硬件来改善该问题。该硬件为SSL 通信专用硬件，相对软件来讲，能够提高数倍 SSL 的计算速度。仅在 SSL 处理时发挥 SSL 加速器的功效，以分担负载。为什么不一直使用 HTTPS
既然 HTTPS 那么安全可靠，那为何所有的 Web 网站不一直使用HTTPS ？
其中一个原因是，因为与纯文本通信相比，加密通信会消耗更多的cpu 及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。
因此，如果是非敏感信息则使用 HTTP 通信，只有在包含个人信息等敏感数据时，才利用 HTTPS 加密通信。特别是每当那些访问量较多的 Web 网站在进行加密处理时，它们所承担着的负载不容小觑。在进行加密处理时，并非对所有内容都进行加密处理，而是仅在那些需要信息隐藏时才会加密，以节约资源。
除此之外，购买证书的开销也是原因之一。要进行 HTTPS 通信，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。证书价格可能会根据不同的认证机构略有不同。通常，一年的授权需要600人民币左右。那些购买证书并不合算的服务以及一些个人网站，可能只会选择采用 HTTP 的通信方式。
HTTP/HTTPS/HTTP2/HTTP3/QUIC/WebSocket协议详解
名词解释
URI结构如下，URL是URI中Web Resource的子集，例如http/ftp协议。
HTTP
HTTP全称Hypertext Transfer Protocol超文本传输协议，主要基于TCP实现的应用层协议，特点有：
- 支持客户端向服务器请求URL资源。
- HTTP是无状态协议。服务器不需要强制保存HTTP session任何信息。
- HTTP authentication特性支持账号密码的传输。
版本变化：
- HTTP/1.0最初实现了可用性。对每个请求都需要TCP三次握手建立单独链路。
- HTTP/1.1优化了传输效率。新增keep-alive特性使多个请求可以复用同一条TCP链路(TCP keep-alive是传输层特性，防止NAT路由断开连接)；新增chunked transfer encoding允许流式传输而不是一次性buffered传输；新增HTTP pipelining可并行请求-响应，避免串行请求-响应的阻塞耗时；新增byte serving只请求部分资源。
TCP握手流程：
三次握手原因。为了避免因传输异常导致包时序问题，一端在发消息时必须要接收到对方的回包确认。例如客户端因网络延迟发了两个SYN，如果没有第三次握手ACK，则服务端会二次建立连接。
四次挥手原因。一端发送FIN是表示自己不发数据，但是还可以接收另一端发送的数据。所以要结束TCP连接，需要双方都FIN+ACK两次RTT。根据wiki也有可以通过三次挥手结束连接，但是需要同时关闭双端。
结束TIME_WAIT需要等待2MSL(最大报文段生存时间)才能到CLOSED状态。一是避免最后的ACK丢白需要重发，二是要确保此次连接的数据包在网络中消失，避免跟下次连接混淆。
请求与响应包：
响应状态码分为1xx临时响应、2xx成功、3xx重定向、4xx请求错误、5xx服务器错误。常见状态码见附录。
WebSocket
WebSocket是基于TCP的全双工通信协议。背景是web app网络通信是基于HTTP协议，每次服务端跟客户端通信都需要建立一次HTTP连接，WebSocket在应用层重新设计，提供机制可以让web网络通信在一个TCP连接中实现多次数据传输。
WebSocket与HTTP的联系
为了兼容HTTP服务，WebSocket握手协议是在HTTP基础上进行扩展。但是WebSocket其他部分与HTTP无关，完全是在TCP之上封装的应用与web的协议，其中包括以下内容：
o 为浏览器添加基于Web Origin标准的安全模型
o 添加了一种寻址和协议命名机制，以支持一个端口上的多种服务和一个IP地址上的多个主机名
o 在TCP之上分层成帧机制，以回到建立TCP的IP数据包机制，但没有长度限制
o 在代理和其他中间人的情况下额外设计一套关闭握手协议
WebSocket URI格式：
ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]
WebSocket握手头部：
RFC: https://tools.ietf.org/html/rfc6455
HTTPS
HTTPS全称Hypertext Transfer Protocol Secure，是在HTTP协议中添加TLS/SSL扩展，支持加密数据传输。
为了确保数据在传输过程中不被读取(加密算法)、篡改(数字签名)、调包(数字证书)，以下对相关术语进行解释。
加密算法
1.对称加密
对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。对称加密有很多种算法，由于它效率很高，所以被广泛使用在很多加密协议的核心当中。不足之处是，交易双方都使用同样钥匙，安全性得不到保证。常见的对称加密有 DES、AES 等。
2.非对称加密
非对称加密使用一对“私钥-公钥”，用私钥加密的内容只有对应公钥才能解开，反之亦然。非对称加密有以下特性：
- 对于一个公钥，有且只有一个对应的私钥。
- 公钥是公开的，并且不能通过公钥反推出私钥。
- 通过私钥加密的密文只能通过公钥能解密，通过公钥加密的密文也只能通过私钥能解密。
非对称加密不需要共享同一份秘钥，安全性要比对称加密高，但由于算法强度比对称加密复杂，加解密的速度比对称加解密的速度要慢。常见的非对称加密有 RSA、ESA、ECC 等。
数字签名
数字签名就是用摘要算法提取出源文件的摘要并用私钥进行加密后的内容。摘要一致则说明文件没有被篡改过，即使摘要被解密也无法还原数据内容。
摘要算法有以下特性：
- 只要源文本不同，计算得到的结果，必然不同（或者说机会很少）。
- 无法从结果反推出源数据。
一般使用摘要算法来校验原始内容是否被篡改。常见的摘要算法有 MD5、SHA 等。
数字证书
数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件，用于认证密匙的有效性。一般会包含公钥、公钥拥有者名称、CA 的数字签名、有效期、授权中心名称、证书序列号等信息。
数字证书如何确保列出的用户就是公钥的拥有者呢？关键点是 CA 的数字签名，CA会用自己的私钥将证书内容的摘要进行加密。因为 CA 的公钥是公开的，任何人都可以用公钥解密出 CA 的数字签名的摘要，再用同样的摘要算法提取出证书的摘要和解密 CA 数字签名后的摘要比对，一致则说明这个证书没有被篡改过，可以信任。
参考：https://www.jianshu.com/p/ffe8c203a471
TLS握手过程：
TLS握手协议分为基础握手协议(Basic TLS handshake)与双向认证协议(Client-authenticated TLS handshake)。双向认证协议是在Basic基础上增加了客户端发送证书的步骤。
- 客户端发送「_ClientHello_」，内容包括：支持的协议版本，比如TLS1.0版，一个客户端生成的随机数Random1（稍后用于生成“会话密钥”），支持的加密算法（如RSA公钥加密）和支持的压缩算法。
- 服务端发送「_ServerHello_」，内容包括：客户端与服务端支持的最高协议版本，一个服务器生成的随机数Random2，CipherSuite与压缩算法（如RSA）。如果是复用session，还会带上session ID。
- 服务端发送「_ServerCertificate_」证书。服务器会将自己的证书下发给客户端，其中Certificates即是证书（除了网站的CA证书外，还一并把该CA证书的中级证书下发，所以是一个证书链），证书内包含公钥。
- (双向认证)服务端发送CertificateRequest。请求客户端证书。
- 服务端发送「_ServerHelloDone_」。完成协商。
- (双向认证)客户端发送Certificate。包含客户端证书以及公钥。
- 客户端发送「_ClientKeyExchange_」。生成随机数Random3，用证书的公钥加密生成PreMasterSecret。服务端用私钥解密PreMasterSecret得到Random3。
- (双向认证)客户端发送CertificateVerify。用客户端证书私钥根据上一个消息生成签名，服务端用客户端公钥解密，确认客户端证书有效。
- 双端根据Random1、Random2、Random3用协商的加密算法生成密钥。
- 客户端发送「_ChangeCipherSpec_」。表示之后数据均以加密方式传输。
- 客户端发送「_Finished_」。发送加密的Finished消息，内容是基于前一次消息生成的hash以及Message Authentication Code (MAC)。服务端验证Finished消息是否有效，无效则关闭连接。
- 服务端发送「_ChangeCipherSpec_」以及「_Finished_」。同上。
- 开始加密数据传输。
基础流程：
公私钥交换流程：
TLS 1.3改进
冷启动握手从2-RTT到1-RTT。
- 客户端将预测的协议版本和key share发给服务端。
- 服务端选择协议并返回key share跟证书(用key share加密)以及Finished。
- 客户端用key share验证证书获取公钥，发送Finished。
Resumption热启动
tls 1.2热启动实现方式是发送ClientHello时带上session ID(缺点是需要每个连接服务器保存session状态)或者session Ticket(序列化的session)，服务端确认后直接返回Finished，然后双端复用Pre-master secret，这样只需要1-RTT即可完成握手。但是存在风险是如果Pre-master secret被破解，则session数据就会泄露。
tls 1.3改进了热启动方式，达到0-RTT。具体实现是在初次握手后通过加密通道传输Pre-Shared Key(用于确认使用者身份，而不是密钥)，客户端热启动时同时传加密数据以及Pre-Shared Key，服务端如果验证Pre-Shared Key有效则直接解密数据。
tls 1.3冷热启动握手图见spec，搜索figure即可。
https://tools.ietf.org/html/rfc8446#section-4.2.11
常见攻击
Downgrade attack。man-in-the-middle攻击的一种，篡改客户端请求向服务端协商旧版本的加密方式，然后通过已知的旧版本漏洞破解加密请求。通常服务端去掉向后兼容性就可以解决问题，但是会牺牲部分可用性。另外tls 1.3标准定义在双端Finished消息中校验之前所有握手消息的MAC，如果存在篡改则关闭连接。
Replay attack。攻击者sniff并录制正常客户端请求，然后向服务端请求同样的内容，从而欺骗服务端获取敏感数据。例如0-RTT的首次数据场景，因为服务端无法验证数据来源，所以最好的方式是首次请求避免敏感信息、状态改变等。
HTTP/2
相比HTTP1.x，2.0在以下方面做了改进：
Streams, messages, and frames
HTTP2在应用层引入Binary framing机制将传输数据从单一请求-响应包细分成更小的部分进行数据传输，从而可以更灵活地控制数据，引入多路复用、优先级、数据流控制等传输策略。
Binary framing引入Stream、message和frame概念。一个TCP连接传输多个bidirectional streams（包含stream id跟priority）；stream由多个messages构成，message是HTTP消息例如一次request或response，包含一个或多个frames；frame包含不同类型的数据，是数据传输最小单位，例如header，body为不同的frame，可以通过stream id进行组装。
multiplexing单TCP连接多路复用
一次TCP连接在HTTP1只能一次请求响应，HTTP2将多次请求响应划分为frames，交替(interleave)传输，最终在对端根据stream id进行组装。
Stream prioritization
客户端给每个stream分配1-256优先级附在header frame中，再根据stream依赖树请求服务器。RFC没有规定服务端的行为，不同的服务提供商可能实现不同的处理策略，例如cloudflare根据客户端优先级将stream划分为多个池，每个池分配一定的带宽传输数据。
cloudflare solution:https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web/
RFC:https://tools.ietf.org/html/rfc7540#page-24
HTTP headers压缩
基本思路是对标准header键值用固定字典编码，自定义键值用动态字典编码，无法用字典情况下用Huffman编码。固定字典是基于RFC标准定义的固定键值字符串排列；动态字典是在一次connection过程中动态更新自定义键值字符串；Huffman编码是用于第一次传输自定义键值，双端解码后在动态字典中更新，第二次传输即可用字典方式编码，Huffman表是RFC基于大量现实header统计的概率表。对自定义头部用预定义字典或动态字典(随一次connection更新)编码。
例子：https://blog.cloudflare.com/hpack-the-silent-killer-feature-of-http-2/
ref:https://tools.ietf.org/html/rfc7541
HTTP/2 Server Push
用于服务端控制资源下发。服务端基于客户端已有的connection，发送PUSH_PROMISE header frame带上资源url以及预留的stream id给客户端，然后传输data frame将资源下发给客户端，期间客户端也可以控制Push参数。与一般客户端请求响应不一样的是，Push需要遵守same-origin policy以及服务端必须是authoritative。
RFC: https://tools.ietf.org/html/rfc7540#page-60
HTTP3
HTTP3是将传输层的TCP替换为基于UDP的QUIC协议，应用层对齐实现HTTP1/2的语法，从而解决TCP建立连接慢、队头拥塞等问题。目前HTTP3与QUIC标准处于Internet-Draft状态，还要经过Proposed Standard、Internet Standard两个阶段才能正式成为标准。客户端Chrome和Firefox仅在主线版本支持，另外也有三方库支持服务端/客户端HTTP3，具体见wiki资料。
wiki: https://en.wikipedia.org/wiki/HTTP/3
QUIC
QUIC最初被提案时是"Quick UDP Internet Connections"的缩写，是基于UDP的多路复用和安全的通用传输层协议。目前客户端有Chrome、Firefox、Opera、Curl支持，服务端有LiteSpeed、Nginx、Cloudflare支持，截至2019年8月，有3.2%的网站使用QUIC。区别于IETF(Internet Engineering Task Force)的标准QUIC，Google QUIC(gQUIC)本意是设计为通用协议在Chromium中支持HTTP(S)，同时也在跟进支持最新的QUIC标准。QUIC具有以下特性：
o Stream multiplexing
o Stream and connection-level flow control
o Low-latency connection establishment
o Connection migration and resilience to NAT rebinding
o Authenticated and encrypted header and payload
QUIC协议内容：
Connection
与服务端的连接。包括握手流程定义，传输协议、加密协议协商。connection ID用于定义endpoints之间的QUIC路由，即使某一端ip或端口改变了，也可以将数据传输中的connection迁移到新的地址，而不需要重新传输已送达的数据。类似IP报头的source/destination address，QUIC数据包Packet的header也包含Source Connection ID(非必须)和Destination Connection ID，这两个ID在双端定义了Packet归属于哪个connection，用于重组数据。ID在QUIC握手时初始化，连接过程中可能被改变。
Stream
用于传输有序字节流数据。分为单向unidirectional和双向bidirectional stream。可以在流程控制(flow control)和限制(stream limits)条件下同时创建任意多个stream传输任意大小的数据，但是不能保证不同stream中传输字节的顺序。发送数据是通过STREAM frames带上stream ID、Offset fields以及data，对端再根据ID和Offset进行重组。
Packet and Frame
- Packet和Frame是QUIC传输的基础单元，有规定的头部和payload。Packet是从功能角度将QUIC协议划分为不同类型的报文，例如Initial Packet是客户端跟服务端握手过程中的第一个初始化包，Retry Packet是服务端通知客户端重试的包。Frame是从数据类型角度将QUIC协议划分为不同类型的数据帧。例如Initial Packet的Payload字段填充的是CRYPTO frame，CRYPTO frame包含cryptographic handshake message, ACK frames, or both。
- QUIC将Stream分为Packet以及Frame传输是为了解决队头拥塞(head-of-line blocking)问题。Stream某个Packet丢失只需要重传这个Packet就可以，其他Packet不会因此阻塞。
- 一个UDP包可以装载多个Packet，一个Packet可以装载多个Frame。
关于Packet：
- Packet分为Long Header Packets和Short Header Packets，LHP用于控制类例如Version Negotiation/Initial/Handshake Packet等固定header较多的Packet。SHP用于建立连接后，用最少的overhead传输数据。
- 除了Version Negotiation和Retry类型，其他所有packet都用AEAD(authenticated encryption with additional data)方式加密保证数据的保密和完整性。
- 应用层可以在Packet中打包尽可能多的frames以减少带宽浪费和CPU消耗，但是等待新的frame可能导致Packet迟迟不发。
握手流程
下图是1-RTT握手流程，每行格式是"{packet_type}[{packet_num}]: {frame_type}[{frame_payload}] {frame_type1}[{frame_payload1}] ..."
1.客户端发送Initial包。包含客户端Source Connection ID(从0开始递增)以及TLS握手帧CRYPTO Frame(Client Hello bytes)。
2.服务端发送UDP包。UDP中包括三类Packet。Initial包，包含CRYPTO Frame(Server Hello bytes)以及ACK(请求的packet_num)；QUIC握手帧HandShake包，包含CRYPTO Frame(证书)；1-RTT encrypted包，包含数据帧STREAM Frame(Stream ID,帧Offset,数据长度以及字节数据)。
3.客户端发送UDP包。UDP中包括三类Packet。Initial包，包含ACK；HandShake包，包含结束的CRYPTO Frame以及ACK；1-RTT encrypted包，包含返回数据帧STREAM Frame以及ACK。
4.服务端发送UDP包。UDP中包括两类Packet。数据包1-RTT encrypted以及握手包HandShake。
下图是QUIC 0-RTT握手流程。与TLS Resumption热启动优化思路类似。具体流程见RFC。
流量控制(Flow Control)
流量控制是对接收方的数据缓冲大小限制，从而避免快速发送方碾压慢速接收方及恶意发送者大量消耗接收方内存的情况。同样，为了限制连接内的并发，QUIC终端控制其对端可以发起的最大累计stream。具体有以下几项：
- 数据流控制(Data Flow Control)。限制单个stream或单个connection接收的字节数。
- 流余额增量(Flow Credit Increments)。RFC未强制规定，只是提供了一些建议。例如服务端通过发送MAX_STREAM_DATA或MAX_DATA帧给客户端动态放水，控制流量。
- Stream取消机制(Handling Stream Cancellation)。当双端对流量控制策略不一致时，需要有取消机制结束或者重置Stream。RESET_STREAM或CONNECTION_CLOSE帧可以重置或关闭Stream。
- Stream总大小(Stream Final Size)。当RESET_STREAM或者有新的STREAM帧到达，如果实际的size跟预定的final size不一致，则发送FINAL_SIZE_ERROR帧。
- 并发控制(Controlling Concurrency)。只有stream ID小于(max_stream * 4 + initial_stream_id_for_type)才能被open。
连接迁移(Connection Migration)
当连接一方的地址发生改变，将旧连接迁移到新的地址上，避免重传已接收的数据。
必要条件：
因为QUIC在握手过程中地址必须不变，所以需要在握手完成之后才能发起连接迁移。
除了服务端使用Preferred Address情况下，迁移只能由客户端发起。
迁移步骤：
1.探测地址是否可达。客户端发送PATH_CHALLENGE帧(包含自定义Data)，服务端响应PATH_RESPONSE(包含请求的自定义Data)。如果发生超时，则地址不可达。同时为了确保服务端有可用的connection ID，客户端可以发送NEW_CONNECTION_ID帧创建新的connection。
2.(可选)初始化新的connection。重置拥塞控制congestion controller以及拥塞通知ECN capability。
3.发起迁移。客户端用新地址发送non-probing帧(除了PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, PADDING以外的帧类型)，服务端回包并且验证客户端地址，即可完成连接迁移。
常见网络攻击以及防御方案
Handshake Denial of Service
攻击方法：其目的在於使目標電腦的網路或系統資源耗盡，使服务暂时中斷或停止，导致其正常用户无法访问。例如针对TCP常见的SYN flood attack，不断发送SYN包要求服务器建立连接，导致所有端口被异常占用。
QUIC防御方案：加密握手完成后，所有包都是加密并且身份验证过，不符合的包会被丢弃。
Amplification Attack
攻击方法：思路是攻击者伪造目标IP向第三方发起请求，第三方返回更多数据给目标导致资源耗尽。针对QUIC攻击的具体实现是攻击者首先连接第三方获得address validation token，然后用此token以及目标IP发起0-RTT请求，伪造目标IP热启动，第三方验证热启动token合法，则发送0-RTT响应给目标IP。
防御方案：限制address validation tokens的使用和生命周期，例如短时间内不接收多个相同token。
Optimistic ACK Attack
攻击方法：增加ACK参数中收到数据长度，欺骗服务端传输比实际带宽要多得多的数据。
防御方案：QUIC在发送Packet时会累加packet numbers，所以服务端通过刻意跳过某些packet numbers刻意检测出客户端是否恶意发包。
Slowloris Attacks
Stream Commitment Attack
攻击方法：客户端创建尽可能多的connection或者stream，持续发送少量心跳数据，导致服务端资源被占用。
防御方案：通过接入层防御，部署QUIC时限制每个IP的连接数、限制长连接等。
Stream Fragmentation and Reassembly Attacks
攻击方法：发送方故意只发送stream部分数据，导致接收方需要创建整个stream大小的buffer或数据结构。或者接收方故意不发送ACK包，导致发送方一直持有并重传发送数据。
防御方案：根据可用内存限制flow control的window大小，防止内存占用超过资源。
Stateless Reset Oracle
攻击方法：思路是攻击者伪造RESET包使服务端正常连接被重置，类似的攻击有TCP reset injection，最常见的例子是访问google出现"The connection was reset"。QUIC的RESET包的stateless reset token是由static key以及connection ID计算得出，攻击者将正常Packet转发到其他共享static key并且没有connection的endpoint，则服务端会误以为connection不存在继而发送RESET包并且重置连接。
防御方案：服务端管理共享static key的endpoint，确保Packet能发送到有connection的endpoint。
Version Downgrade
攻击方法：通过版本协商使用低版本不安全的QUIC。
防御方案：QUIC标准暂无多版本的协商行为。
QUIC RFC: https://tools.ietf.org/html/draft-ietf-quic-transport-24
QUIC with TLS RFC: https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#name-introduction
中文QUIC RFC: http://docs.wxclimb.top/draft-ietf-quic-transport-zh.html#fc-credit
Challenges remaining for QUIC
网络基础设施已经基于TCP存在广泛的优化，但是对UDP是限速甚至是禁止。Google在早期实验中就存在少量连接被拒绝的问题。
Does QUIC make the world faster ?
对于网络耗时，论文[1]对比了HTTP2跟QUIC+SPDY，在不同网络环境下测试网页加载时间/资源请求耗时。结论是：
- QUIC在少量小资源/大资源/弱网情况下占优：QUIC is faster (1.2-4.5X) when pages consist of few small-sized objects. QUIC also performs better when the page consists of large-sized objects. QUIC can achieve faster page loads in poor network conditions of lower bandwidth, high delay and lossy network.
- QUIC在大量小资源情况下不如HTTP2：However, Page load with QUIC is slower (1.1-3.2X) when page consists of many small-sized objects. One possible reason for this is that the QUIC toy server is not optimized to be used efficiently with Chromium browser.
2019年论文[2]对TCP做业界通用的优化，对齐QUIC传输层参数，测试不同网络环境下页面加载/显示时间。结论是QUIC均优于TCP(HTTP2)，弱网环境下优势更明显。
还有资料[3]从实际应用角度提出对QUIC质疑。例如端对端加密限制网络链路的优化，CPU以及内存占用高，拥塞控制(congestion control)可能抢占其他类型的连接带宽等。
[1]P. Biswal, O. Gnawali, "Does QUIC make the Web faster?", Proc. IEEE GLOBECOM, pp. 1-6, Dec. 2016. http://www2.cs.uh.edu/~gnawali/papers/quic-globecom2016.pdf
[2]"A Performance Perspective on Web Optimized Protocol Stacks: TCP+TLS+HTTP/2 vs. QUIC" arXiv:1906.07415v1 [cs.NI] 18 Jun 2019. https://arxiv.org/pdf/1906.07415.pdf
[3]"QUIC and HTTP/3 : Too big to fail?!" https://calendar.perfplanet.com/2018/quic-and-http-3-too-big-to-fail/
https://en.wikipedia.org/wiki/QUIC#cite_note-QUIC_Design_Doc-3
https://blog.cloudflare.com/the-road-to-quic/
https://yucianga.info/?p=819
附录
常用请求码：
1xx（临时响应）
表示临时响应并需要请求者继续执行操作的状态代码。
代码 说明
100 Continue（继续） 请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。
101 Switching Protocols（切换协议） 请求者已要求服务器切换协议，服务器已确认并准备切换。
2xx （成功）
表示成功处理了请求的状态代码。
代码 说明
200 OK（成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
201 Created（已创建） 请求成功并且服务器创建了新的资源。
202 Accepted（已接受） 服务器已接受请求，但尚未处理。
203 Non-Authoritative Information（非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
204 No Content（无内容） 服务器成功处理了请求，但没有返回任何内容。
205 Reset Content（重置内容） 服务器成功处理了请求，但没有返回任何内容。
206 Partial Content（部分内容） 服务器成功处理了部分 GET 请求。
3xx （重定向）
表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。
代码 说明
300 Multiple Choices（多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301 Moved Permanently（永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302 Found（临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303 See Other（查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304 Not Modified（未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305 Use Proxy（使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307 Temporary Redirect（临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
4xx（请求错误）
这些状态代码表示请求可能出错，妨碍了服务器的处理。
代码 说明
400 Bad Request（错误请求） 服务器不理解请求的语法。
401 Unauthorized（未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
403 Forbidden（禁止） 服务器拒绝请求。
404 Not Found（未找到） 服务器找不到请求的网页。
405 Method Not Allowed（方法禁用） 禁用请求中指定的方法。
406 Not Acceptable（不接受） 无法使用请求的内容特性响应请求的网页。
407 Proxy Authentication Required（需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
408 Request Timeout（请求超时） 服务器等候请求时发生超时。
409 Conflict（冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410 Gone（已删除） 如果请求的资源已永久删除，服务器就会返回此响应。
411 Length Required（需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
412 Precondition Failed（未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
413 Request Entity Too Large（请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414 Request-URI Too Long（请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
415 Unsupported Media Type（不支持的媒体类型） 请求的格式不受请求页面的支持。
416 Requested Range Not Satisfiable（请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
417 Expectation Failed（未满足期望值） 服务器未满足"期望"请求标头字段的要求。
5xx（服务器错误）
这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。
代码 说明
500 Internal Server Error（服务器内部错误） 服务器遇到错误，无法完成请求。
501 Not Implemented（尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502 Bad Gateway（错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
503 Service Unavailable（服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504 Gateway Timeout（网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505 HTTP Version Not Supported（HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。
今天关于https会话和发布问题和https会进行什么处理的分享就到这里，希望大家有所收获，若想了解更多关于angularJs http发布问题：插入数据、fail2ban port=https,http 只屏蔽 https 不屏蔽 http、HTTP+ 加密 + 认证 + 完整性保护 =HTTPS（HTTPS 安全通信机制）、HTTP/HTTPS/HTTP2/HTTP3/QUIC/WebSocket协议详解等相关知识，可以在本站进行查询。
本文标签：
![[转帖]Ubuntu 安装 Wine方法（ubuntu如何安装wine）](https://www.gvkun.com/zb_users/cache/thumbs/4c83df0e2303284d68480d1b1378581d-180-120-1.jpg)
