189 8069 5689
HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。
在迭部等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供网站建设、做网站 网站设计制作按需开发,公司网站建设,企业网站建设,品牌网站制作,营销型网站,外贸营销网站建设,迭部网站建设费用合理。
即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。 它是一个URI scheme（抽象标识符体系），句法类同http:体系。用于安全的HTTP数据传输。
https: URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。
一、https协议需要到ca申请证书，一般免费证书很少，需要交费。
二、http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
三、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
四、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
1）HTTPS的主要思想是在不安全的网络上创建一安全信道，并可在使用适当的加密包和服务器证书可被验证且可被信任时，对窃听和中间人攻击提供合理的保护。
2）HTTPS的信任继承基于预先安装在浏览器中的证书颁发机构（如VeriSign、Microsoft等）（意即“我信任证书颁发机构告诉我应该信任的”）。
3）因此，一个到某网站的HTTPS连接可被信任，如果服务器搭建自己的https 也就是说采用自认证的方式来建立https信道，这样一般在客户端是不被信任的。
4）所以我们一般在浏览器访问一些https站点的时候会有一个提示，问你是否继续。
1 客户端打包请求 。
其中包括URL、端口、账号和密码等。使用账号和密码登陆应该用的是POST方式，所以相关的用户信息会被加载到body中。这个请求应该包含3个方面：网络地址、协议和资源路径。注意：这里用的是HTTPS，即HTTP+SSL/TLS，在HTTP上又加了一层处理加密信息的模块（相当于加了一个锁）。这个过程相当于客户端请求钥匙。
2 服务器端接受请求。
一般客户端的请求会先被发送到DNS服务器中。DNS服务器负责将网络地址解析成IP地址，这个IP地址对应网上的一台计算机。这其中可能发生Hosts Hijack和ISP failure的问题。过了DNS这一关，信息就到服务器端，此时客户端和服务端的端口之间会建立一个socket连接。socket一般都是以file descriptor的方式解析请求的。这个过程相当于服务器端分析是否要想客户端发送钥匙模板。
3 服务器端返回数字证书。
服务器端会有一套数字证书（相当于一个钥匙模板），这个证书会先被发送个客户端。这个过程相当于服务端向可独断发送钥匙模板。
4 客户端生成加密信息。
根据收到的数字证书（钥匙模板），客户端就会生成钥匙，并把内容锁起来，此时信息已经被加密。这个过程相当于客户端生成钥匙并锁上请求。
5 客户端方发送加密信息 。
服务器端会收到由自己发送的数字证书加密的信息。这个时候生成的钥匙也一并被发送到服务端。这个过程相当于客户端发送请求。
6 服务端解锁加密信息。
服务端收到加密信息后，会根据得到的钥匙进行解密，并把要返回的数据进行对称加密。这个过程相当于服务器端解锁请求，生成、加锁回应信息。
7 服务器端向客户端返回信息。
客户端会收到相应的加密信息。这个过程相当于服务器端向客户端发送回应信息。
8 客户端解锁返回信息。
客户端会用刚刚生成的钥匙进行解密，将内容显示在浏览器上。
以上内容摘自《iOS面试之道》一书，感谢作者。
Cocoa框架里，无论是用OS层基于 C 的BSD socket还是用对BSD socket进行了轻量级的封装的CFNetwork，对于我这种C语言不及格的同学，那都是极其痛苦的体验，因此我们就用CocoaAsyncSocket来进行socket连接，完全OC风格，非常愉快。
.h文件里没有什么内容只是暴露了一个供外界调用的请求接口，后面介绍，主要是.m文件里的扩展属性：
GCDAsyncSocketDelegate代理的实现：
这里重点说一下sendData这个属性的拼接（很重要，这里的格式决定了你发送的请求数据是否被服务器认可，并给你返回信息，相当于NSURLRequest的作用,其实就是拼接一个http协议）：
以上就是建立HTTP连接收发数据的全部内容，如果不需要支持https的话，这个GET请求已经可以完成，下面介绍进行https连接需要进行的设置(在.m文件里实现)：（上面提到的[self doTLSConnect:sock]这个方法）
至此发送HTTPS GET请求并且用body传递参数就实现了，是不是很神奇。下面封装一个对外调用的接口（在.h文件中把这个接口暴露出去就行了）：
** 其中的DCNetCache类用来暂存网络请求的参数，它是这样子滴：**
这样子就大功告成了，注意把上面的host换成自己的，这里还有许多不完善的地方，我只是实现了简单的GET请求并暂存请求参数，至于你需要其他的功能自己加上就是了。
附一篇讲GCDAsyncSocket的干货文章，非常值得一读
苹果公司在iOS9以后开启了HTTPS请求，并且在2017年开始强制HTTPS，我们也可以利用白名单来设置部分域名http请求，下面根据两种情况为大家分别介绍客户端需要做的。
2、请求网络时候进行加密验证（引用上面方法）
解决方案：我们可以通过NSExceptionDomains设置白名单的方式来针对特定的域名开放HTTP内容来通过审核。可以简单理解成，把不支持https协议的接口设置成http的接口。
操作：
1）在项目info.plist中添加一个Key：App Transport Security Settings，类型为
Dictionary;
2）在其内添加一个Key: Exception Domains，类型为Dictionary;
3）在Exception Domains内添加要支持的域，其中域作为Key，类型为Dictionary;
4）每个域下面需要设置3个属性：类型为Boolean;
NSIncludesSubdomains YES
NSExceptionRequiresForwardSecrecy NO
NSExceptionAllowsInsecureHTTPLoads YES
注意：每个需添加的域都需要设置此三个属性。如果请求的网络图片是HTTP，也是需要设置的图片的域。
网上有太多教程教你如何使用charles调试，但是一到Https，大部分教程只是让你可以启用ssl代理，但是没有说明如何才能通过charles来真正查看https加密后的数据，这里我给出一个完整的教程来指导大家如何启用https后任然可以查看加密请求内容。在讲解让charles实现查看https请求内容之前，先简单讲解一下代理实现的原理。
HTTP 代理存在两种形式，分别简单介绍如下：
第一种是 RFC 7230 - HTTP/1.1: Message Syntax and Routing （即修订后的 RFC 2616，HTTP/1.1 协议的第一部分）描述的普通代理。这种代理扮演的是「中间人」角色，对于连接到它的客户端来说，它是服务端；对于要连接的服务端来说，它是客户端。它就负责在两端之间来回传送 HTTP 报文。
第二种是 Tunneling TCP based protocols through Web proxy servers （通过 Web 代理服务器用隧道方式传输基于 TCP 的协议）描述的隧道代理。它通过 HTTP 协议正文部分（Body）完成通讯，以 HTTP 的方式实现任意基于 TCP 的应用层协议代理。这种代理使用 HTTP 的 CONNECT 方法建立连接，但 CONNECT 最开始并不是 RFC 2616 - HTTP/1.1 的一部分，直到 2014 年发布的 HTTP/1.1 修订版中，才增加了对 CONNECT 及隧道代理的描述，详见 RFC 7231 - HTTP/1.1: Semantics and Content 。实际上这种代理早就被广泛实现。
第一种 Web 代理原理特别简单：
下面这张图片来自于《HTTP 权威指南》，直观地展示了上述行为：
[图片上传失败...(image-615be4-1570502309613)]
客户端请求先发送到代理服务器，代理再和真实服务器进行请求，对于web服务器来说，代理就是客户端。服务器完全察觉不到真正客户端的存在，这实现了隐藏客户端 IP 的目的。当然代理也可以修改 HTTP 请求头部，通过 X-Forwarded-IP 这样的自定义头部告诉服务端真正的客户端 IP。但服务器无法验证这个自定义头部真的是由代理添加，还是客户端修改了请求头，所以从 HTTP 头部字段获取 IP 时，需要格外小心。
还有一种情况是访问网站时，实际上访问的是代理，代理收到请求报文后，再向真正提供服务的服务器发起请求，并将响应转发给浏览器。这种情况一般被称之为反向代理，它可以用来隐藏服务器 IP 及端口。一般使用反向代理后，需要通过修改 DNS 让域名解析到代理服务器 IP，这时浏览器无法察觉到真正服务器的存在，当然也就不需要修改配置了。反向代理是 Web 系统最为常见的一种部署方式，例如本博客就是使用 Nginx 的 proxy_pass 功能将浏览器请求转发到背后的 Node.js 服务。两者的区别在于代理服务器是由谁配置的，如果是客户端配置的代理，就是前置代理，如果是服务器配置的代理访问，一般都是反向代理。
第二种 Web 代理的原理也很简单：
下面这张图片同样来自于《HTTP 权威指南》，直观地展示了上述行为：
[图片上传失败...(image-8ec42b-1570502309613)]
假如我通过代理访问A网站，浏览器首先通过 CONNECT 请求，让代理创建一条到 A 网站的 TCP 连接；一旦 TCP 连接建好，代理无脑转发后续流量即可。所以这种代理，理论上适用于任意基于 TCP 的应用层协议，HTTPS 网站使用的 TLS 协议当然也可以。这也是这种代理为什么被称为隧道的原因。对于 HTTPS 来说，客户端透过代理直接跟服务端进行 TLS 握手协商密钥，所以依然是安全的。
步骤一：将Charles的根证书(Charles Root Certificates)安装到Mac上。
步骤二：Mac信任Charles的根证书。
打开系统钥匙串应用，在我的证书中找到刚安装的Charles的Root证书：
这时候会弹出一个框，在移动设备的浏览器输入弹框中提供的URL就可以安装Charles证书(这时候需要移动设备已经设置代理)。
在移动设备的浏览器中输入上面的URL后会弹出一个确认框，点击“允许”跳转到“设置”页面，安装描述文件即可。
步骤五：接下来就可以在charles中启用https代理了：
指定地址和443端口就可以了，还可以支持通配符。
到了这一步，网上大部分教程就结束了，实际上还是会遇到虽然看到了https请求通过了代理，但是还是看不到任何内容。出现下面的提示：
SSLHandshake: Remote host closed connection during handshake
You may need to configure your browser or application to trust the Charles Root Certificate. See SSL Proxying in the Help menu.
这个时候就比较懵逼了，我已经安装了Charles Root Certificate为什么还是提示这个错误，也让我查找了很久。这里我们先回到开头的代理原理，我们可以看到代理有两种模式，其中第二种模式隧道代理模式，是直接将数据转发，数据内容还是加密状态，自然不能查看。那第一种简单代理模式可以满足我们的需求么？
可以也不可以，为什么这么说？Https最重要的特性就是加密防止信息窥探和劫持，使用第一种模式其实是加入了中间人，而且中间人需要被客户端和服务器两端同时信任，并且可以解析加密内容进行转发。我上一篇文章也讲到，IOS下Https对连接进行校验有多种模式，校验证书，校验域名，校验证书链。为了支持charles分析Https请求内容，我们需要构造条件让charles成为受信任的中间人。还记得我们刚刚安装了charles的Root证书么？为了让charles成为受信任的代理中间人，我们在客户端也需要设置信任charles的Root证书。
方法如下：
1、Charles菜单中选择Help SSLProxying View Generated SSL Certificates Keystore Password，将显示的密码记下来。这个是在每个Charles安装的时候自动生成的，和你本机的Charles Root Certificates相对应。
5、重新编译你的App，这个时候在charles中就可以看到你的加密内容了。