iOS 面试全方位剖析 -- 网络篇
这节涉及到的内容
- HTTP 协议
- HTTPS 与网络安全
- TCP / UDP
- DNS 解析
- Session / Cookie
HTTP 协议
对 HTTP 的理解?
超文本传输协议,要讲的内容
- 请求/响应报文
- 连接建立流程
- HTTP的特点
请求/响应报文
一般在回答面试官什么是 HTTP 的时候，第一点要回答的就是 请求/响应报文的组成结构
- 请求报文的格式
三个部分 ， 请求行
请求头，都是以 key-value形式组成
实体主体 ， GET 请求一般不带有实体主体
-
响应报文的格式
三个部分 ， 响应行
请求头，都是以 key-value形式组成
实体主体
GET 和 POST 方式的区别
比较初级的回答方式是下面这样
- GET 请求参数以 ? 分割拼接到 URL 后面 ，POST请求参数在 Body里面
- GET 参数长度限制 2048 个字符 ， POST一般没有该限制
- GET 请求不安全 ， POST请求比较安全
比较高逼格的回答是这样的
从语义的角度来回答
GET 获取资源 ,安全的 , 幂等的 , 可缓存的
POST 处理资源 ，非安全的 ,非幂等的 , 非可缓存的
- 安全性 : 不应该引起 Server 端的任何状态变化
- 幂等行 : 同一个请求方法执行多次和执行一次的效果完全相同
- 请求是否可以被缓存
状态码
都有哪些状态码，他们的含义是什么?
2xx : 比如 200 ，响应成功
3xx : 比如301，302 一些网络的重定向
4xx : 比如 401， 404 客户端的请求本身存在某些问题
5xx : 比如501 ，502 Server 端本身存在异常
连接建立流程
比较经典的三次握手,四次挥手
HTTP 的特点
无连接, 每次请求有一个建立连接和释放连接的过程
我们可以通过 HTTP的持久连接方案来进行 HTTP 无连接的一个补偿
-
非持久连接，在 Client 和 Server 的交互中，打开一个 TCP 连接，进行网络数据的传输，然后关闭这条 TCP 连接. 之后发送第二个请求的时候可能需要重新打开一个 TCP 的连接 。 也就是说每次请求接口都需要重新建立一个 TCP 连接，经历 三次握手 四次挥手.
-
持久连接 , 打开一条 TCP 通道，之后可能在一定时间内, 多个 HTTP 请求可能会在同一条链路上进行请求和响应的传递
持久连接涉及到 HTTP 的哪些头部字段呢?
- Connection : keep-alive 客户端期许采用持久连接
- time : 20 多长时间有效
- max : 10 最多可以发生多少个 HTTP 请求和响应对
怎样判断一个请求是否结束?
在同一条 TCP上产生了多次 HTTP 请求，怎样判断前一个请求的结束
- Content-length : 1024 , 发送一个请求的时候,Server 端会携带响应数据的大小,通过 Content-length 来标识，客户端可以根据所接受数据的字节数是否到达 Content-length 的值，到达了就说明全部接受完毕，既 HTTP 请求结束
- 还有一种情况, 当使用 POST 端进行请求的时候 , 往往 Server 端需要多次响应来返回给客户端数据, 我们可以通过 HTTP 响应报文当中的头部字段叫 chunked 来判断请求是否结束，当有多个块通过 HTTP 的 TCP连接传输给客户端的时候，每一个报文都会带有chunked 这个字段， 最后一个块会带有一个空 chunked，这样就可以判断前一个网络请求是否结束了.
无状态
对 HTTP 协议无状态特点的补偿. Cookie / Session
cookie
主要用来记录用户状态，区分用户, 状态保存在客户端。
客户端发送的 Cookie 在 http 请求报文的 Coolie首部字段中
服务器端设置 http 响应报文的 Set-Cookie 首部字段
如何保证 Cookie的安全
- 对 Cookie 进行加密处理
- 只在https 上携带 Cookie
- 设置 Cookie 为httpOnly，防止跨站脚本攻击
Session
主要用来记录用户状态，区分用户, 状态保存在服务器端。
Session 需要依赖于Cookie 机制
看一下 Session 的工作流程图
HTTPS 与网络安全
HTTPS = HTTP + SSL/TLS
HTTPS 连接的建立流程是怎样的?
我们看一幅时序图
会话秘钥 = random S + random C + 预主秘钥
HTTPS都使用了哪些加密手段?为什么?
- 连接建立过程中使用非对称加密，很耗时
- 后续通信过程中使用对称加密
非对称加密
对称加密
TCP/UDP
传输层协议
- TCP, 传输控制协议
- UDP,用户数据报协议 无连接，尽最大努力交付
TCP特点
面向连接，可靠传输，面向字节流，流量控制，拥塞控制
面向连接
数据传输开始之前，需要建立连接(三次握手)。 数据传输结束之后，需要释放连接(四次挥手)
可靠传输
TCP如何保证可靠传输呢?
- 无差错
- 不丢失
- 不重复
面向字节流
不管发送方一次性提交给 TCP 的缓冲是多大的数据，对于TCP本身来说它会根据实际的情况来进行划分，比如发送方发送10字节，TCP 并不是一次性传递10字节数据，它可能是拆分成3个字节和7个字节分俩次发送给接收方
流量控制
基于滑动窗口协议实现.
什么是滑动窗口协议? (新浪微博三面面试真题)
对照上图，现在假如发送窗口是客户端，接收窗口是服务端。当我们现在要继续发送数据的时候，可能由于接收方的接收窗口没有那么大，而发送方的发送窗口非常大，就会以更快的速率往后发，需要由接收窗口通过向TCP的报文首部字段中去更改窗口值去调整发送方的发送窗口大小。
拥塞控制
- 慢开始，拥塞避免
- 快恢复，快重传
横轴代表 APP 交互或者轮循次数，纵轴代表窗口值的大小
上图中，一开始我们可以先发送一个报文，如果没有发生网络拥塞，就继续发送 2 个报文，依然没有发生网络拥塞，就继续翻倍，直到 16 个报文，这就是慢开始算法
当到达 16 报文数的时候，会采用拥塞避免的策略来进行发送报文的一个数量的线性增长。
当报文数到 24 的时候，就会发生网络拥塞，采用拥塞避免的乘法减小到值发送 1 一个报文，来减少对网络层面带来的压力，然后再重新开始 慢开始算法增长，同时限定一个新的门限值.
DNS 解析
DNS 解析是怎么的一个过程? (大厂常问的一个问题)
域名到IP地址的映射,DNS解析请求采用UDP数据报，且明文
客户端通过 DNS 协议向 DNS 服务器去请求相应域名的解析，然后 DNS 服务器把解析结果的IP 地址返回给客户端，再由客户端向 IPServer进行相应的网络请求
DNS 解析查询方式
- 递归查询
- 迭代查询
DNS 解析存在哪些常见的问题 (重点)
- DNS 劫持问题
- DNS 解析转发问题
DNS 劫持
由于 DNS 解析过程采用 UDP 数据报明文传输，就会涉及到一个窃听的问题。 假如现在有一个钓鱼 DNS 服务器，就会劫持到对应的一个 DNS 解析的请求， 然后钓鱼服务器返回给我们一个错误的IP地址，此时拿这个错误的IP地址去访问的时候就是一个错误的网站
DNS 劫持与 HTTP的关系是怎样的?
这里给出明确的回答， 俩者是没有关系的 ，完全是俩回事
DNS 解析发生在 HTTP 建立连接之前
DNS 解析请求使用 UDP 数据报，端口号 53
怎样解决 DNS 劫持
-
长连接
网络篇面试总结
- HTTP 中的GET和POST方式有什么区别 ?
- HTTPS 连接建立流程是怎样的 ?
- TCP 和 UDP 有什么区别 ?
- 简述 TCP 的慢开始过程 ?
- 客户端怎样避免 DNS 劫持 ?
转载请标明出处
