iOS HTTP与 HTTPS

iOS HTTP/HTTPS

HTTPS 知识图总览

TCP三次握手与四次挥手

网络连接是需要三次握手才可以连接上。

建立连接（tcp三次握手）：我知道你知道我知道了

断开连接（四次挥手）：我确定了你确定要关闭

注："我"指服务器，但是每次都是由客户端发起

详细过程参考：TCP的三次握手与四次挥手理解及面试题（很全面）

TCP 三次握手

TCP 四次挥手

常见面试问题

为什么要三次握手、四次挥手？

答：为了确认要连接和确认要断开连接。并简述三次握手、四次挥手流程。

为什么不能用两次握手进行连接？

答：3次握手完成两个重要的功能，要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

死锁示例现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

各层协议之间关系图

HTTP是应用层协议，定义的是传输数据内容的规范；而TCP是底层通讯协议，定义的是数据传输和连接方式的规范。

Https 增加安全层

HTTP与 HTTPS

HTTP的特性是明文传输，因此在传输的每一个环节，数据都有可能被第三方窃取或者篡改。

具体来说，HTTP数据经过TCP层，然后经过WIFI路由器、运营商和目标服务器，这些环节中都有可能被中间人拿到数据并进行篡改，也就是我们常说的中间人攻击

为了防范这样一类攻击，我们不得已引入新的加密方案，即HTTPS

HTTPS协议是有HTTP协议和SSL协议构建的可进行加密传输和身份认证的网络协议，比HTTP协议的安全性更高

最后一个字母S指的是SSL/TLS协议，它位于HTTP协议与TCP/IP协议中间

加密方案

对称加密

共用统一密钥加解密

简单说就是有一个密钥，它可以加密一段信息，也可以对加密后的信息进行解密，和我们日常生活中用的钥匙作用差不多。

示例

DES（Data Encryption Standard）: 速度快，适合大量数据加密
3DES（Triple DES）: 基于 DES, 对一块数据进行三个不同的密钥进行三次加密，安全性更高
AES (Advanced Encryption Standard) ：高级加密标准，新一代加密算法，速度快，安全性高,。有128、192、256位的，苹果系统钥匙串采用这种算法。

非对称加密

简单说就是有两把密钥，通常一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。

特点：效率低

示例

RSA: RSA公司的加密算法，最有影响力的非对称加密算法。

摘要算法

通过加密之后得到固定大小的唯一 hash 值

作用是防止数据被篡改，不可逆（不能获得加密前内容），常用于配合加密算法进行签名 MD5+RSA 或者 SHA+RSA

示例

MD5 ：常常配合 MD5 + 加盐使用，系统内 iOS5 后怎么使用

SHA :

Base64是一种编码方式，使其不被明文

常见面试问题

Https 是用对称加密还是非对称加密？

这个问题本身就是一个坑，

证书验证阶段使用非对称加密，

内容传输使用的是对称加密。

为什么数据传输是用对称加密？

非对称解密效率非常低
在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密

CA签名/数字证书

CA：Certificate Authority证书颁发机构，主要作用就是验证客户端拿到的公钥是不是对应 host 的，即身份认证。

权威机构会跟主流的浏览器或操作系统合作，将他们的公钥内置到浏览器或操作系统环境中，所以可以进行安全验证（所以可以避免中间人操作）。

https协议中身份认证的部分是由CA数字证书完成的，证书由公钥、证书主体、数字签名等内容组成。在客户端发起SSL请求后，服务端会将数字证书发给客户端，客户端会对证书进行验证（验证这张证书是否是伪造的？也就是公钥是否是伪造的），如果证书不是伪造的，客户端就获取用于对称密钥交换的非对称密钥（获取公钥）

常见面试问题

为什么需要证书？

防止”中间人“攻击，同时可以为网站提供身份证明

SSL 认证过程（HTTP 请求过程）

SSL(Secure Sockets Layer 安全套接字协议),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层与应用层之间对网络连接进行加密

在进行完三次握手建立连接后，Https 需要进行 TLS 四次握手

流程图

常见问题回答

iOS 加密过程？

iOS HTTPS请求配置

导入 cer 证书

配置相关网络层证书认证

比如 Moya 设置 SSL

let serverTrustManager = ServerTrustManager(evaluators: ["example.com": PinnedCertificatesTrustEvaluator()]) // 设置域名证书let session = Session(configuration: configuration, startRequestsImmediately: false, serverTrustManager: serverTrustManager
)let provider = MoyaProvider<MyTarget>(session: session)

iOS 加密算法？

编码方式	摘要算法	对称算法	非对称算法
Base64	MD5、SHA	EDS、3EDS、AES	RSA

如何避免被抓包？

会被抓包，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。但是我们可以利用证书锁定来避免抓包。
通过 SSL Pinning (证书锁定)：通过将证书内置，发起请求的时候通过对比内置证书和服务端证书来验证。
证书锁定又分为：

证书锁定（Certificate Pinning ）：[证书过期，需要发包更新]APP代码内置仅接受指定域名的证书，而不接受操作系统或浏览器内置的CA根证书对应的任何证书，通过这种授权方式，保障了APP与服务端通信的唯一性和安全性，因此我们移动端APP与服务端（例如API网关）之间的通信是可以保证绝对安全。
公钥锁定（Public Key Pinning ）：[无需更改证书]提取证书公钥内置在应用中，通过对比公钥值来验证合法性。证书续费不会导致公钥变化。

Socket是什么？

即套接字，是应用层与 TCP/IP 协议族通信的中间软件抽象层，表现为一个封装了 TCP / IP协议族的编程接口（API）
成对出现，一对套接字：

Socket ={(IP地址1:PORT端口号)，(IP地址2:PORT端口号)}
复制代码

一个 Socket 实例唯一代表一个主机上的一个应用程序的通信链路

HTTP 请求头有哪些字段？

w3官网参考

Requests部分

Header	解释	示例
Accept	指定客户端能够接收的内容类型	Accept: text/plain, text/html
Accept-Charset	浏览器可以接受的字符编码集。	Accept-Charset: iso-8859-5
Accept-Encoding	指定浏览器可以支持的web服务器返回内容压缩编码类型。	Accept-Encoding: compress, gzip
Accept-Language	浏览器可接受的语言	Accept-Language: en,zh
Accept-Ranges	可以请求网页实体的一个或者多个子范围字段	Accept-Ranges: bytes
Authorization	HTTP授权的授权证书	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control	指定请求和响应遵循的缓存机制	Cache-Control: no-cache
Connection	表示是否需要持久连接。（HTTP 1.1默认进行持久连接）	Connection: close
Cookie	HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。	Cookie: $Version=1; Skin=new;
Content-Length	请求的内容长度	Content-Length: 348
Content-Type	请求的与实体对应的MIME信息	Content-Type: application/x-www-form-urlencoded
Date	请求发送的日期和时间	Date: Tue, 15 Nov 2010 08:12:31 GMT
Expect	请求的特定的服务器行为	Expect: 100-continue
From	发出请求的用户的Email	From: user@email.com
Host	指定请求的服务器的域名和端口号	Host: www.zcmhi.com
If-Match	只有请求内容与实体相匹配才有效	If-Match: “737060cd8c284d8af7ad3082f209582d”
If-Modified-Since	如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码	If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
If-None-Match	如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变	If-None-Match: “737060cd8c284d8af7ad3082f209582d”
If-Range	如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag	If-Range: “737060cd8c284d8af7ad3082f209582d”
If-Unmodified-Since	只在实体在指定时间之后未被修改才请求成功	If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT
Max-Forwards	限制信息通过代理和网关传送的时间	Max-Forwards: 10
Pragma	用来包含实现特定的指令	Pragma: no-cache
Proxy-Authorization	连接到代理的授权证书	Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range	只请求实体的一部分，指定范围	Range: bytes=500-999
Referer	先前网页的地址，当前请求网页紧随其后,即来路	Referer: http://www.zcmhi.com/archives/71.html
TE	客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息	TE: trailers,deflate;q=0.5
Upgrade	向服务器指定某种传输协议以便服务器进行转换（如果支持）	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
User-Agent	User-Agent的内容包含发出请求的用户信息	User-Agent: Mozilla/5.0 (Linux; X11)
Via	通知中间网关或代理服务器地址，通信协议	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning	关于消息实体的警告信息	Warn: 199 Miscellaneous warning

Responses 部分

Header	解释	示例
Accept-Ranges	表明服务器是否支持指定范围请求及哪种类型的分段请求	Accept-Ranges: bytes
Age	从原始服务器到代理缓存形成的估算时间（以秒计，非负）	Age: 12
Allow	对某网络资源的有效的请求行为，不允许则返回405	Allow: GET, HEAD
Cache-Control	告诉所有的缓存机制是否可以缓存及哪种类型	Cache-Control: no-cache
Content-Encoding	web服务器支持的返回内容压缩编码类型。	Content-Encoding: gzip
Content-Language	响应体的语言	Content-Language: en,zh
Content-Length	响应体的长度	Content-Length: 348
Content-Location	请求资源可替代的备用的另一地址	Content-Location: /index.htm
Content-MD5	返回资源的MD5校验值	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range	在整个返回体中本部分的字节位置	Content-Range: bytes 21010-47021/47022
Content-Type	返回内容的MIME类型	Content-Type: text/html; charset=utf-8
Date	原始服务器消息发出的时间	Date: Tue, 15 Nov 2010 08:12:31 GMT
ETag	请求变量的实体标签的当前值	ETag: “737060cd8c284d8af7ad3082f209582d”
Expires	响应过期的日期和时间	Expires: Thu, 01 Dec 2010 16:00:00 GMT
Last-Modified	请求资源的最后修改时间	Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
Location	用来重定向接收方到非请求URL的位置来完成请求或标识新的资源	Location: http://www.zcmhi.com/archives/94.html
Pragma	包括实现特定的指令，它可应用到响应链上的任何接收方	Pragma: no-cache
Proxy-Authenticate	它指出认证方案和可应用到代理的该URL上的参数	Proxy-Authenticate: Basic
refresh	应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持）	Refresh: 5; url=http://www.zcmhi.com/archives/94.html
Retry-After	如果实体暂时不可取，通知客户端在指定时间之后再次尝试	Retry-After: 120
Server	web服务器软件名称	Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Set-Cookie	设置Http Cookie	Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
Trailer	指出头域在分块传输编码的尾部存在	Trailer: Max-Forwards
Transfer-Encoding	文件传输编码	Transfer-Encoding:chunked
Vary	告诉下游代理是使用缓存响应还是从原始服务器请求	Vary: *
Via	告知代理客户端响应是通过哪里发送的	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning	警告实体可能存在的问题	Warning: 199 Miscellaneous warning
WWW-Authenticate	表明客户端请求实体应该使用的授权方案	WWW-Authenticate: Basic

Conncetion: keep-alive

HTTP的keep-alive也称为HTTP的长连接它通过重用一个TCP连接来发送/接收多个HTTP请求，来减少创建/关闭多个TCP连接的开销

该属性在HTTP/1.0协议种添加的，如果请求头中包含

Connection: keep-alive

则代表开启了keep-alive，而服务端的返回保文头中，也会包含相同的内容

默认是开启的，除非显式地关闭它：

Connection: close

通常还需要配合Keep-Alive使用，决定过期时间（timeout）和最大接受请求次数（max），但是服务器并不能保证保持连接。

Keep-Alive: timeout=60, max=100

这个就表示TCP通道可以保持60s，max=100表示这个长连接最多接收100次请求就断开

参考

计算机网络基本知识