iOS探索：网络相关
HTTP
超文本传输协议
-
请求报文
WX20181228-104135@2x.png
我们来看一下请求报文的格式，首先是请求行，请求行包括方法、URL、协议文本，方法常见的有GET/POST，URL就是我们的请求地址，协议文本一般是HTTP1.1版本
然后再看一下请求头，头部字段都是以key：value的形式组合在一起的，由多个首部字段名构成首部字段区域
之后是我们的实体主体，一般在GET请求中没有实体主体，而在POST请求中一般会带有实体主体
- 响应报文
WX20181228-105115@2x.png
首先是版本，然后是状态码，还有状态码的描述，我们称之为短语，然后下面跟请求报文一致，由此组成响应报文
HTTP的请求方式
-
GET
-
POST
-
HEAD
-
PUT
-
DELETE
-
OPTIONS
GET和POST方式的区别
一般大家都知道的是：
-
GET请求参数是以？分割拼接到URL后面的，POST请求参数实在Body里面的
-
GET参数长度限制2048个字符，POST一般没有该限制
-
GET请求不太安全，POST请求比较安全
但是从语义的角度来比较的话，是这样的：
-
GET：获取资源，是安全的、幂等的、可缓存的
-
POST：处理资源，是非安全的、非幂等的、不可缓存的
对应的解释
1、安全性：不应该引起Server端的任何状态变化，比如说我们用GET请求多次去Server端去获取数据，不会引起Server的一个状态变化，安全性的请求包括：GET、HEAD、OPTIONS
2、幂等性：同一个请求方法执行多次和执行一次的效果完全相同，比如说我们用GET请求多次去Server端去获取数据，执行的效果是完全相同的，这里需要注意的是执行的效果，幂等性的请求包括：GET、PUT、DELETE
3、可缓存性：请求是否可缓存，我们一般在发起一个HTTP请求的过程中，传递的链路我们是不确定的，虽然说实在一条TCP连接上，但是网络路径在接触或者通过网关包括一些代理到达我们的Server端，在这上面会涉及到方方面面的内容，往往对于一些代理服务器会有缓存，而这种缓存性是官方的一种规范，即可以遵守也可以不遵守，大多数情况会遵守，所以在GET请求会有相对应的缓存，可缓存性的请求包括：GET、HEAD
状态码
1XX：通知
2XX：成功
3XX：重定向
4XX：客户端错误
5XX：服务端错误
连接建立流程
三次握手
-
首先是客户端发送一个SYN的请求报文给服务端，请求建立连接
-
当服务端收到报文后，服务端会返回给客户端一个同步ACK的报文
-
当客户端收到报文后，会返回给服务端一个ACK报文，完成三次握手
四次挥手
-
如果是客户端发起主动断开，客户端会发送一个FIN终止报文给服务端
-
服务端会返回给客户端一个ACK确认报文，这时客户端与服务端的连接就断开了，但是服务端到客户端这个方向，可能还会传递数据，在一个合适时机，服务端会向客户端请求断开连接
-
服务端想要断开连接的时候，会向客户端发送FIN终止报文
-
然后客户端会回给服务端一个确认报文，此时完成服务端与客户端的连接断开
HTTP的特点
-
无连接，补偿方案为HTTP的持久连接
-
无状态，补偿方案为Cookie/Session
HTTPS与网络安全
HTTPS = HTTP + SSL/TLS
HTTPS就是在原有HTTP基础上，在应用层下面，传输层上面插入了一个SSL/TLS协议中间层，为我们实现一个安全的网络机制，也就是说HTTPS是安全的HTTP
HTTPS连接建立流程
-
首先由客户端向服务端发送一个报文，这个报文包括三部分，一个是客户端支持的TLS版本，客户端支持的加密算法，以及一个随机数C
-
然后服务端返回一个握手报文消息，包括一个商定的加密算法，随机数S还有一个服务端的证书
-
客户端收到这条报文后，首先会验证证书，之后会组装会话秘钥，这个秘钥主要通过前面的随机数C和随机数S以及一个预主秘钥进行会话秘钥的组装
-
然后客户端会通过服务端的公钥对预主秘钥进行加密传输，之后服务端通过私钥解密得到预主秘钥，最后服务端会通过前面的随机数C、随机数S以及解密得到的预主秘钥组装会话秘钥
-
之后再由客户端向服务端发送一个加密的握手消息，服务端发送一个加密的握手消息，来验证是否加密完成
TCP/UDP
传输层协议
TCP：传输控制协议
UDP：用户数据报协议
UDP（用户数据报协议）
特点：
1、无连接
2、尽最大努力交付
3、面向报文，既不合并，也不拆分
功能包括：
1、复用
2、分用
3、差错检测
TCP（传输控制协议）
特点：
1、面向连接
2、可靠传输（无差错，不丢失，不重复，按序到达）
3、面向字节流
4、流量控制
5、拥塞控制
DNS解析
域名到IP地址的映射，DNS解析请求是采用UDP数据报，且明文
WX20181228-163845@2x.png
DNS解析查询方式
-
递归查询 （一层一层的查询）
-
迭代查询 （返回结果找对应查询）
DNS劫持问题
当客户端发送域名去DNS服务器去查询时，由于是UDP数据包并且明文，就会被窃听，这时如果有一个钓鱼服务器劫持了这次查询，返回给你一个错误的IP，这时你就会访问到一个错误的网页
这里还需要注意一个点：就是DNS劫持和HTTP是完全没有关系的，因为DNS解析是发生在HTTP建立连接之前，并且DNS解析请求使用的事UDP数据报，端口号53
那么如何解决DNS劫持问题呢？
-
httpDNS：DNS解析请求使用的事UDP数据报，端口号53，解决方案是使用HTTP协议向DNS服务器的80端口进行请求，不会产生正常的DNS解析，也就不会出现DNS的劫持问题
-
长连接：在客户端和服务端之间建立一个长连服务，也就是一个代理服务器，在客户端和代理服务器之前建立长连通道，然后再代理服务器和服务端之间通过内网专线进行内网DNS解析，然后进行请求
DNS解析转发问题
简单一句话，就是我们客户端发送请求时，我们的DNS服务器可能为了节省资源等原因，会转发给其他的DNS服务器，会出现跨网访问，可能会慢一点
Session/Cookie
HTTP协议无状态特点的补偿
Cookie
主要是用来记录用户状态，区分用户；状态保存在客户端，客户端发送的Cookie在http请求报文的Cookie首部字段中，服务端设置http响应报文的Set-Cookie首部字段
修改Cookie
-
新Cookie覆盖旧Cookie
-
覆盖规则：name、path、domain等需要与原Cookie保持一致
删除Cookie
-
新Cookie覆盖旧Cookie
-
覆盖规则：name、path、domain等需要与原Cookie保持一致
-
设置Cookie的expires = 过去的一个时间点，或者maxAge = 0
怎样保证Cookie的安全性
-
对Cookie进行加密处理
-
只在https上携带Cookie
-
设置Cookie为httpOnly，防止跨站脚本攻击
Session
也是用来记录用户状态，区分用户；状态保存在服务端
Session需要依赖于Cookie机制
至此iOS基础相关的内容暂时告一段落，写的可能并不是特别详细，也会有很多的瑕疵，也多谢各位对文章问题的指出，接下来会写一些数据结构与算法相关的内容，届时希望大家可以共同探讨，共同进步
iOS探索系列
iOS探索：UI视图之事件传递&视图响应
iOS探索：UI视图之卡顿、掉帧及绘制原理
iOS探索：Runtime之基本数据结构
iOS探索：Runtime之消息转发及动态添加方法
iOS探索：Block解析浅谈
iOS探索：RunLoop本质、数据结构以及常驻线程实现
iOS探索：网络相关
