ios面试准备 - 网络篇
iOS面试准备 - ios篇
ios面试准备 - objective-c篇
ios面试准备 - 网络篇
IOS面试准备 - C++篇
iOS面试准备 - 其他篇
http和https是什么？http和https有什么区别？
HTTP协议是超文本传输协议的缩写，英文是Hyper Text Transfer Protocol。它是从WEB服务器传输超文本标记语言(HTML)到本地浏览器的传送协议。
HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。
HTTPS和HTTP的主要区别：
- https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。
- http信息是明文传输，https则是具有安全性的ssl/tls加密传输协议。
- http和https使用的端口不一样，前者是80，后者是443。
- http的连接很简单，是无状态的；HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
- HTTP 页面响应速度比 HTTPS 快 HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，
- HTTPS 比TTPS要更耗费服务器资源。
HTTPS加密过程
客户端请求服务器获取证书公钥
客户端(SSL/TLS)解析证书（无效会弹出警告）
生成随机值
用公钥加密随机值生成密钥
客户端将秘钥发送给服务器
服务端用私钥解密秘钥得到随机值
将对称加密密钥和随机值混合在一起进行对称加密
将加密的对称加密密钥发送给客户端
客户端用秘钥解密信息
后续服务端和客户端使用对称加密密钥，加密解密信息
加密算法
1.非对称加密，也称为公开秘钥加密，一种密码学算法类型，在这种密码学方法中，需要一对密钥，一个是私人密钥，另一个则是公开密钥。算法有：RSA(一个支持变长密钥的公共密钥算法)、DSA(数字签名算法)、ECC(椭圆曲线密码编码学)
2.对称加密加密,又称共享密钥加密,有如下算法：DES（数据加密标准，速度较快，适用于加密大量数据）、3DES(基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高)
3.对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高；非对称加密使用了一对密钥，公钥和私钥，所以安全性高，但加密与解密速度慢；解决的方法是将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。算法有：DES算法，3DES算法，TDEA算法，
http状态码
1xx 信息响应。 收到并理解的请求。 请求处理将继续。
2xx 成功。 已成功接收、理解和接受该操作。
3xx 重定向。 客户端必须采取进一步操作才能完成请求。
4xx 客户端错误。 可能是客户端导致的错误。 请求包含错误的语法或无法实现。
5xx 服务器错误。 服务器遇到错误，无法满足请求。
| 状态码 | 描述 |
|---|---|
| 200 | 成功 |
| 201 | 请求成功并且服务器创建了新的资源 |
| 204 | 服务器成功处理了请求，但没有返回任何内容。 |
| 206 | 是对资源某一部分的请求，服务器成功处理了部分GET请求（断点续传） |
| 301 | (永久移动) 请求的网页已永久移动到新位置。 |
| 302 | (临时移动) 服务器目前从不同位置的网页响应请求 |
| 304 | 未修改。所请求的资源未修改,并且服务端不会返回东西 |
| 307 | 临时重定向，不会从Post变成Get |
| 400 | (错误请求) 服务器不理解请求的语法 |
| 401 | (未授权) 请求要求身份验证 |
| 403 | (禁止) 服务器理解但是拒绝请求 |
| 404 | (未找到) 服务器找不到请求的网页。 |
| 500 | (服务器内部错误) 服务器遇到错误，无法完成请求 |
| 503 | (服务不可用) 服务器目前无法使用(由于超载或停机维护)。 通常，这只是暂时状态。 |
| 505 | HTTP 版本不受支持 |
Http报文格式
请求报文格式
一个HTTP请求报文组成部分：请求行 、首部行、空行和实体体
响应报文格式
三个部分状态行、首部行、实体体
举例：
网络七层协议
| 名称 | 描述 | 协议 |
|---|---|---|
| 应用层 | 应用程序和网络之间的接口，其功能是直接向用户提供服务 | HTTP、FTP。SMTP |
| 表示层 | 负责数据格式的转换 | SSL/TLS、ASCII |
| 会话层 | 建立、维护以及断开和管理应用程序之间的通信 | ADSP |
| 传输层 | 监控数据传输服务的质量，保证报文的正确传输 | TCP、UDP（RTC和RTCP） |
| 网络层 | 对端到端的包传输进行定义，它定义了能够标识所有结点的逻辑地址，还定义了路由实现的方式和学习的方式。 | ip |
| 数据链路层 | 它定义了在单个链路上如何传输数据。这些协议与被讨论的各种介质有关 | 帧中继，点对点，以太网 |
| 物理层 | 它的主要作用是传输比特流。传输单位是比特 | IEE 802系列 |
TCP的三次握手和四次挥手
https://segmentfault.com/a/1190000039165592
三次握手
刚开始客户端处于 Closed 的状态，而服务端处于 Listen 状态：
1）第一次握手：客户端向服务端发送一个 SYN 报文（SYN = 1），并指明客户端的初始化序列号 ISN(x)，即图中的 seq = x，表示本报文段所发送的数据的第一个字节的序号。此时客户端处于 SYN_Send 状态。
2）第二次握手：服务器收到客户端的 SYN 报文之后，会发送 SYN 报文作为应答（SYN = 1），并且指定自己的初始化序列号 ISN(y)，即图中的 seq = y。同时会把客户端的 ISN + 1 作为确认号 ack 的值，表示已经收到了客户端发来的的 SYN 报文，希望收到的下一个数据的第一个字节的序号是 x + 1，此时服务器处于 SYN_REVD 的状态。
3）第三次握手：客户端收到服务器端响应的 SYN 报文之后，会发送一个 ACK 报文，也是一样把服务器的 ISN + 1 作为 ack 的值，表示已经收到了服务端发来的的 SYN 报文，希望收到的下一个数据的第一个字节的序号是 y + 1，并指明此时客户端的序列号 seq = x + 1（初始为 seq = x，所以第二个报文段要 +1），此时客户端处于 Establised 状态。
服务器收到 ACK 报文之后，也处于 Establised 状态，至此，双方建立起了 TCP 连接。
四次挥手
这是由于 TCP 的半关闭（half-close）特性造成的，TCP 提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。
四次挥手过程：
刚开始双方都处于ESTABLISHED 状态，假设是客户端先发起关闭请求。四次挥手的过程如下：
1）第一次挥手：客户端发送一个 FIN 报文（请求连接终止：FIN = 1），报文中会指定一个序列号 seq = u。并停止再发送数据，主动关闭 TCP 连接。此时客户端处于 FIN_WAIT1 状态，等待服务端的确认。
2）第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。
此时的 TCP 处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待 2）状态，等待服务端发出的连接释放报文段。
3）第三次挥手：如果服务端也想断开连接了（没有要向客户端发出的数据），和客户端的第一次挥手一样，发送 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态，等待客户端的确认。
4）第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答（ack = w+1），且把服务端的序列值 +1 作为自己 ACK 报文的序号值（seq=u+1），此时客户端处于 TIME_WAIT （时间等待）状态。
注意 ！！！这个时候由服务端到客户端的 TCP 连接并未释放掉，需要经过时间等待计时器设置的时间 2MSL（一个报文的来回时间） 后才会进入 CLOSED 状态（这样做的目的是确保服务端收到自己的 ACK 报文。如果服务端在规定时间内没有收到客户端发来的 ACK 报文的话，服务端会重新发送 FIN 报文给客户端，客户端再次收到 FIN 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文给服务端）。服务端收到 ACK 报文之后，就关闭连接了，处于 CLOSED 状态。
TCP传输
TCP协议详解
慢启动：最初建立链接启动，指数级增长
拥塞避免：慢启动超过阈值后启动，线性增长，到拥塞窗口的大小。
快速重传：
当发送端连续收到3个重复的确认报文端段的时候，tcp就认为拥塞发生了。然后会立即重传丢失的报文段
快速恢复：发送端收到第三个重复确认的报文时，会更新ssthresh，把ssthresh设置为cwnd的一半把cwnd再设置为ssthresh的值(具体实现有些为ssthresh+3)；重新进入拥塞避免阶段。
UDP
RTC和RTCP 实现音频视频会议
RTC和RTCP都是基于UDP的协议。他们组合实现音频视频数据传输。虽然他们在传输层，往往在应用层可以直接配置使用。
RTC用于传输数据，有序列号，时间戳，端口号等信息
RTCP进行服务质量的监视与反馈、媒体间的同步。在RTP会话期 间，各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，各参与者可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTCP也是用UDP来传送的，但RTCP封装的仅仅是一些控制信息，因而分组很短，所以可以将多个RTCP分组封装在一个UDP包中。
RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。
会话过程：
当应用程序建立一个RTP会话时，应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成，有两个端口：一个给RTP包，一个给RTCP包，使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口，而对应的控制信号RTCP数据发向相邻的奇数UDP端口（偶数的UDP端口＋1），这样就构成一个UDP端口对。
怎样重组乱序的数据包：
可以根据RTP包的序列号来排序。
怎样获得数据包的时序：
可以根据RTP包的时间戳来获得数据包的时序。
声音和图像怎么同步：
根据声音流和图像流的相对时间（即RTP包的时间戳），以及它们的绝对时间（即对应的RTCP包中的RTCP），可以实现声音和图像的同步。
接收缓冲和播放缓冲的作用：
接收缓冲用来排序乱序了的数据包；播放缓冲用来消除播放的抖动，实现等时播放。
DNS解析过程
查看浏览器有没有缓存
查看本机有没有缓存
请求本地DNS服务器，如果他有缓存直接返回，否则请求根DNS服务器
根DNS服务器告诉本地DNS服务器，域服务器地址
本地DNS服务器请求域服务器，域服务器告诉本地服务器，域名的解析服务器的地址
本地DNS服务器向域名的解析服务器发出请求，这时就能收到一个域名和IP地址对应关系
本地DNS服务器缓存域名和ip关系，然后返回客户端结果。
字节序
Little endian（小端序）：将低序字节存储在起始地址
Big endian（大端序）：将高序字节存储在起始地址
网络字节顺序采用big endian排序方式
不同处理器和操作系统字节序不同，ios是小端序（调用函数NSHostByteOrder）。
两种字节序可以调用socket字节序转换函数进行转换。
Cookie和Session
什么是Cookie
HTTP Cookie是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。
什么是 Session
Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当客户端关闭会话，或者 Session 超时失效时会话结束。
Cookie 和 Session 有什么不同
作用范围不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。
存取方式的不同，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要
好一些。
存储大小不同， 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie。
Cookie 和 Session 联系
使用sessionId标志是同一个彼此。
Cookie里面有什么
Cookie的名称及相对应的值
Cookie的生存期
Web站点上可以访问该Cookie的目录
指定了可以访问该 Cookie 的 Web 站点或域
是否使用HTTPS安全协议发送Cookie
token
token的意思是“令牌”，是服务端生成的一串字符串，作为客户端进行请求的一个标识。
当用户第一次登录后，服务器生成一个token并将此token返回给客户端，以后客户端只需带上这个token前来请求数据即可，无需再次带上用户名和密码。
Http1.1
在1.0上有如下优化：
支持长连接
更多错误响应码
更多缓存处理控制策略
带宽优化及网络连接的使用 ：断点续传 206
Http2
HTTP2新特性：
1.新的二进制格式
HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
2.多路复用
即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
3.header压缩
HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
4.服务端推送
同SPDY一样，HTTP2.0也具有server push功能。目前，有大多数网站已经启用HTTP2.0，例如 YouTuBe，淘宝网等网站，可以利用chrome控制台可以查看是否启用H2
HTTP2的缺点
1.TCP 以及 TCP+TLS建立连接的延时,HTTP/2使用TCP协议来传输的，而如果使用HTTPS的话，还需要使用TLS协议进行安全传输，而使用TLS也需要一个握手过程,在传输数据之前，导致我们需要花掉 3～4 个 RTT。
2.TCP的队头阻塞并没有彻底解决。在HTTP/2中，多个请求是跑在一个TCP管道中的。但当HTTP/2出现丢包时，整个 TCP 都要开始等待重传，那么就会阻塞该TCP连接中的所有请求。
Http3
http3使用基于UDP的QUIC协议，而不是TCP
1.实现了类似TCP的流量控制、传输可靠性的功能。虽然UDP不提供可靠性的传输，但QUIC在UDP的基础之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些TCP中存在的特性
2.实现了快速握手功能。由于QUIC是基于UDP的，客户端第一次建连的握手协商需1-RTT，而已建连的客户端重新建连可以使用之前协商好的缓存信息来恢复TLS连接，仅需0-RTT时间。因此QUIC建连时间大部分0-RTT、极少部分1-RTT，相比HTTPS的3-RTT的建连，具有极大的优势。
3.集成了TLS加密功能。目前QUIC使用的是TLS1.3，相较于早期版本TLS1.3有更多的优点，其中最重要的一点是减少了握手所花费的RTT个数。
4.多路复用，彻底解决TCP中队头阻塞的问题
QUIC
QUIC（Quick UDP Internet Connections）是一种实验性传输层网络协议，提供与TLS/SSL相当的安全性，同时具有更低的连接和传输延迟。QUIC基于UDP，因此拥有极佳的弱网性能，在丢包和网络延迟严重的情况下仍可提供可用的服务。QUIC在应用程序层面就能实现不同的拥塞控制算法，不需要操作系统和内核支持，这相比于传统的TCP协议，拥有了更好的改造灵活性，非常适合在TCP协议优化遇到瓶颈的业务。
其他
为什么 DNS 协议使用 UDP？只使用了 UDP 吗？
https://cloud.tencent.com/developer/article/1818152
不同与http,DNS需要优先解决的快速查询，以及减少对DNS服务器的压力。如果使用TCP查询DNS，需要三次握手＋一次查询RTT＋四次挥手。而用UDP查询，只需要1RTT。当然如果发生超时丢包，应用层上做重传就是了，使用UDP对服务器的压力也小很多。并且TCP丢包的场景，也是需要重传的，只是这部分的功能，被包括在了TCP协议里面。
PS:DNS有时也会用TCP，比如解析到的IP太多了，一个响应的UDP包放不下,这个时候会被截断，(面向报文，最大521字节)。这时的做法是如果客户端收到一个被截断的UDP响应包，用TCP（面向字节流）重新请求一次DNS。
DNS端口号53