iOS⾯试备战-⽹络篇
计算机⽹络是计算机科学与技术专业的必修课，也是移动端，前端，后端都会涉及并⽤到的知识点，可想⽽知它的重要性。所以它也成为了iOS⾯试中经常被问及的问题。准备⾯试的话，⽹络相关的知识点⼀定不能错过。这⾥总结了⼀些我认为有⽤的和最近⾯试遇到的⽹络相关知识点。
去年写过⼀篇的⽂章，也可以对着看下。
计算机⽹络是如何分层的
⽹络有两种分层模型，⼀种是ISO（国际标准化组织）制定的OSI（Open System Interconnect）模型，它将⽹络分为七层。⼀种是
TCP/IP的四层⽹络模型。OSI是⼀种学术上的国际标准，理想概念，TCP/IP是事实上的国际标准，被⼴泛应⽤于现实⽣活中。两者的关系可以看这个图：
注：也有说五层模型的，它跟四层模型的区别就是，在OSI模型中的数据链路层和物理层，前者将其作为两层，后者将其合并为⼀层称为⽹络接⼝层。⼀般作为⾯试题的话都是需要讲出OSI七层模型的。
各个分层的含义以及它们之间的关系⽤这张图表⽰：
Http协议
http协议特性
HTTP 协议构建于 TCP/IP 协议之上，是⼀个应⽤层协议，默认端⼝号是 80
灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
⽆状态：⽆连接的含义是限制每次连接只处理⼀个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。
⽆状态：HTTP协议是⽆状态协议。⽆状态是指协议对于事务处理没有记忆能⼒。缺少状态意味着如果后续处理需要前⾯的信息，则它必须重传。
请求⽅法
GET：请求获取Request-URI标识的资源，请求参数附加在url上，明⽂展⽰。
POST：在Request-URI所标识的资源后附加新的数据，常⽤于修改服务器资源或者提交资源到服务器。POST请求体是放到body中的，可以指定编码⽅式，更加安全。
HEAD：请求获取由Request-URI所标识的资源的响应消息报头。
PUT：请求服务器存储⼀个资源，并⽤Request-URI作为其标识。
DELETE：请求服务器删除Request-URI所标识的资源。
TRACE：请求服务器回送收到的请求信息，主要⽤于测试或诊断。
OPTIONS：请求查询服务器的性能，或者查询与资源相关的选项和需求。
请求和响应报⽂
以该链接为例：
在Chrome查看其请求的Headers信息。
General
这⾥标记了请求的URL，请求⽅法为GET。状态码为304，代表⽂件未修改，可以直接使⽤缓存的⽂件。远程地址为
185.199.111.153:443，此IP为Github 服务器地址，是因为我的博客是部署在GitHub上的。
除了304还有别的状态码，分别是：
200 OK 客户端请求成功
301 Moved Permanently 请求永久重定向
302 Moved Temporarily 请求临时重定向
304 Not Modified ⽂件未修改，可以直接使⽤缓存的⽂件。
400 Bad Request 由于客户端请求有语法错误，不能被服务器所理解。
401 Unauthorized 请求未经授权。这个状态代码必须和WWW-Authenticate报头域⼀起使⽤
403 Forbidden 服务器收到请求，但是拒绝提供服务。服务器通常会在响应正⽂中给出不提供服务的原因
404 Not Found 请求的资源不存在，例如，输⼊了错误的URL
500 Internal Server Error 服务器发⽣不可预期的错误，导致⽆法完成客户端的请求。
503 Service Unavailable 服务器当前不能够处理客户端的请求，在⼀段时间之后，服务器可能会恢复正常。
Response Headers：
content-encoding：⽤于指定压缩算法
content-length：资源的⼤⼩，以⼗进制字节数表⽰。
content-type：指⽰资源的媒体类型。图中所⽰内容类型为html的⽂本类型，⽂字编码⽅式为utf-8
last-modified：上次内容修改的⽇期，为6⽉8号
status：304 ⽂件未修改状态码
注：其中content-type在响应头中代表，需要解析的格式。在请求头中代表上传到服务器的内容格式。
Request Headers：
:method：GET请求
:path：url路径
:scheme：https请求
accept：通知服务器可以返回的数据类型。
accept-encoding：编码算法，通常是压缩算法，可⽤于发送回的资源
accept-language：通知服务器预期发送回的语⾔类型。这是⼀个提⽰，并不⼀定由⽤户完全控制：服务器应该始终注意不要覆盖⽤户的显式选择(⽐如从下拉列表中选择语⾔)。
cookie：浏览器cookie
user-agent：⽤户代理，标记系统和浏览器内核
更多请求头的字段含义可以参考这⾥：
TCP三次握⼿和四次挥⼿的过程以及为什么要有三次和四次
在了解TCP握⼿之前我们先看下TCP的报⽂样式：
其中控制位（Control Flag）标记着握⼿阶段的各个状态。
TCP三次握⼿
⽰意图如下：
三次握⼿是指建⽴⼀个TCP连接时，需要客户端和服务器总共发送3个数据包。
1、第⼀次握⼿（SYN=1, seq=x）
客户端发送⼀个 TCP 的 SYN 标志位置1的包，指明客户端打算连接的服务器的端⼝，以及初始序号 X，保存在包头的序列号(Sequence Number)字段⾥。
发送完毕后，客户端进⼊ SYN_SEND 状态。
2、第⼆次握⼿（SYN=1, ACK=1, seq=y, ACKnum=x+1）
服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为1。服务器端选择⾃⼰ ISN 序列号，放到 Seq 域⾥，同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加1，即X+1。 发送完毕后，服务器端进⼊ SYN_RCVD 状态。
3、第三次握⼿（ACK=1, ACKnum=y+1）
客户端再次发送确认包(ACK)，SYN 标志位为0，ACK 标志位为1，并且把服务器发来 ACK 的序号字段+1，放在确定字段中发送给对⽅，并且在数据段放写ISN的+1
发送完毕后，客户端进⼊ ESTABLISHED 状态，当服务器端接收到这个包时，也进⼊ ESTABLISHED 状态，TCP 握⼿结束。
问题⼀：为什么需要三次握⼿呢？
在谢希仁著的《计算机⽹络》⾥说，『为了防⽌已失效的连接请求报⽂段突然⼜传送到了服务端，因⽽产⽣错误』。怎么理解呢，我们假设⼀种情况，有⼀个建⽴连接的第⼀次握⼿的报⽂段因为滞留到⽹络中过了较长时间才发送到服务端。这时服务器是要做ACK应答的，如果只有两次握⼿就代表连接建⽴，那服务器此时就要等待客户端发送建⽴连接之后的数据。⽽这只是⼀个因滞留⽽废弃的请求，是不是⽩⽩浪费了很多服务器资源。
从另⼀个⾓度看这个问题，TCP是全双⼯的通信模式，需要保证两端都已经建⽴可靠有效的连接。在三次握⼿过程中，我们可以确认的状态是：
第⼀次握⼿：服务器确认⾃⼰接收OK，服务端确认客户端发送OK。
第⼆次握⼿：客户端确认⾃⼰发送OK，客户端确认⾃⼰接收OK，客户端确认服务器发送OK，客户端确认服务器接收OK。
第三次握⼿：服务器确认⾃⼰发送OK，服务器确认客户端接收OK。
只有握⼿三次才能达到全双⼯的⽬的：确认⾃⼰和对⽅都能够接收和发送消息。
TCP四次挥⼿
⽰意图如下：
四次挥⼿表⽰要发送四个包，挥⼿的⽬的是断开连接。
1、第⼀次挥⼿（FIN=1, seq=x）
假设客户端想要关闭连接，客户端发送⼀个 FIN 标志位置为1的包，表⽰⾃⼰已经没有数据可以发送了，但是仍然可以接受数据。
发送完毕后，客户端进⼊ FIN_WAIT_1 状态。
2、第⼆次挥⼿（ACK=1，ACKnum=x+1）
服务器端确认客户端的 FIN 包，发送⼀个确认包，表明⾃⼰接受到了客户端关闭连接的请求，但还没有准备好关闭连接。
发送完毕后，服务器端进⼊ CLOSE_WAIT 状态，客户端接收到这个确认包之后，进⼊ FIN_WAIT_2 状
态，等待服务器端关闭连接。
3、第三次挥⼿（FIN=1，seq=y）
服务器端准备好关闭连接时，向客户端发送结束连接请求，FIN 置为1。
发送完毕后，服务器端进⼊ LAST_ACK 状态，等待来⾃客户端的最后⼀个ACK。
4、第四次挥⼿（ACK=1，ACKnum=y+1）
客户端接收到来⾃服务器端的关闭请求，发送⼀个确认包，并进⼊ TIME_WAIT状态，等待可能出现的要求重传的 ACK 包。
服务器端接收到这个确认包之后，关闭连接，进⼊ CLOSED 状态。
客户端等待了某个固定时间（两个最⼤段⽣命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是⾃⼰也关闭连接，进⼊ CLOSED 状态。
问题⼀：为什么挥⼿需要四次呢？为什么不能将ACK和FIN报⽂⼀起发送？
当服务器收到FIN报⽂时，很可能并不会⽴即关闭SOCKET，所以只能先回复⼀个ACK报⽂，告诉客户端『你发的FIN我收到了』。只有等到服务端所有的报⽂都发送完了，才能发FIN报⽂，所以要将ACK和FIN分开发送，这就导致需要四次挥⼿。
问题⼆：为什么TIMED_WAIT之后要等2MSL才进⼊CLOSED状态？
MSL是TCP报⽂的最⼤⽣命周期，因为TIME_WAIT持续在2MSL就可以保证在两个传输⽅向上的尚未接收到或者迟到的报⽂段已经消失，同时也是在理论上保证最后⼀个报⽂可靠到达。假设最后⼀个ACK丢失，那么服务器会再重发⼀个FIN，这是虽然客户端的进程不在了，但是TCP连接还在，仍然可以重发LAST_ACK。
HTTPS的流程
HTTPS = HTTP + TLS/SSL，它使⽤的端⼝默认为443，它的建⽴可以⽤下图表⽰：
1、客户端⾸次请求服务器，告诉服务器⾃⼰⽀持的协议版本，⽀持的加密算法及压缩算法，并⽣成⼀个随机数（client random）告知服务器。
2、服务器确认双⽅使⽤的加密⽅法，并返回给客户端证书以及⼀个服务器⽣成的随机数（server random）
3、客户端收到证书后，⾸先验证证书的有效性，然后⽣成⼀个新的随机数（premaster secret），并使⽤数字证书中的公钥，加密这个随机数，发送给服务器。
4、服务器接收到加密后的随机数后，使⽤私钥进⾏解密，获取这个随机数（premaster secret
5、服务器和客户端根据约定的加密⽅法，使⽤前⾯的三个随机数（client random, server random, premaster secret），⽣成『对话密钥』（session key），⽤来加密接下来的整个对话过程（对称加密）。
有⼀篇由浅⼊深介绍HTTPS的⽂章可以阅读⼀下：
问题⼀：为什么握⼿过程需要三个随机数，⽽且安全性只取决于第三个随机数？
前两个随机数是明⽂传输，存在被拦截的风险，第三个随机数是通过证书公钥加密的，只有它是经过加密的，所以它保证了整个流程的安全性。前两个随机数的⽬的是为了保证最终对话密钥的『更加随机性』。
问题⼆：Charles如何实现HTTPS的拦截？
Charles要实现对https的拦截，需要在客户端安装Charles的证书并信任它，然后Charles扮演中间⼈，在客户端⾯前充当服务器，在服务器⾯前充当客户端。
问题三：为什么有些HTTPS请求（例如）抓包结果仍是加密的，如何实现的？
我在聊天过程中并没有抓到会话的请求，在⼩程序启动的时候到是抓到了⼀个加密内容。我⼿动触发该链接会下载⼀个加密⽂件，我猜测这种加密是内容层⾯的加密，它的解密是由客户端完成的，⽽不是在HTTPS建⽴过程完成的。
另外在研究这个问题的过程中，⼜发现了⼀些有趣的问题：
1、图中所⽰的三个https请求分别对应三个不同类型的图标，它们分别代表什么意思呢？
这些问题暂时没有确切的答案，希望了解的⼩伙伴告知⼀下哈。
DNS解析流程
DNS（Domain name system）域名系统。DNS是因特⽹上作为域名和IP地址相互映射的⼀个分布式数据库，能够使⽤户通过域名访问到对应的服务器（IP地址）。具体的解析流程是这样的：
1、浏览器中输⼊想要访问的⽹站域名，操作系统会检查本地hosts⽂件是否有这个⽹址的映射关系，如果有就调⽤这个IP地址映射，完成域名解析。没有的话就⾛第⼆步。
2、客户端回向本地DNS服务器发起查询，如果本地DNS服务器收到请求，并可以在本地配置区域资源中查到该域名，就将对应结果返回为给客户端。如果没有就⾛第三步。
3、根据本地DNS服务器的设置，采⽤递归或者迭代查询，直⾄解析完成。
其中递归查询和迭代查询可以⽤如下两图表⽰。
递归查询
如图所⽰，递归查询是由DNS服务器⼀级⼀级查询传递的。
迭代查询
如果所⽰，迭代查询是到指定DNS服务器，由客户端发起查询。
DNS劫持
DNS劫持发⽣在DNS服务器上，当客户端请求解析域名时将其导向错误的服务器（IP）地址。
常见的解决办法是使⽤⾃⼰的解析服务器或者是将域名以IP地址的⽅式发出去以绕过DNS解析。
Cookie和Session的区别
HTTP 是⽆状态协议，说明它不能以状态来区分和管理请求和响应。也就是说，服务器单从⽹络连接上⽆从知道客户⾝份。
可是怎么办呢？就给客户端们颁发⼀个通⾏证吧，每⼈⼀个，⽆论谁访问都必须携带⾃⼰通⾏证。这样服务器就能从通⾏证上确认客户⾝份了。这就是Cookie的⼯作原理。
session数据错误是什么意思
Cookie：Cookie是客户端保存⽤户信息的⼀种机制，⽤来记录⽤户的⼀些信息，实际上Cookie是服务器在本地机器上存储的⼀⼩段⽂本，并随着每次请求发送到服务器。Cookie技术通过请求和响应报⽂中写⼊Cookie信息来控制客户端的状态。
Session：Session机制是⼀种服务器端的机制，服务器使⽤⼀种类似于散列表的结构来保存信息。当有⽤户请求创建⼀个session 时，服务器会先检查这个客户端⾥是否已经包含了⼀个Session标识（session id），如果有就通过session id把session检索出来。
如果没有就创建⼀个对应此Session的session id。这个session id会在本次响应中返回给客户端。
两者有以下区别：
1、存储位置：Cookie存放在客户端上，Session数据存放在服务器上。
2、Session 的运⾏依赖 session id，⽽ session id 是存在 Cookie 中的，也就是说，如果浏览器禁⽤了 Cookie ，同时 Session 也会失效
3、安全性：Cookie存在浏览器中，可能会被⼀些程序复制，篡改；⽽Session存在服务器相对安全很多。
4、性能：Session会在⼀定时间内保存在服务器上，当访问增多，会对服务器造成⼀定的压⼒。考虑到减轻服务器压⼒，应当使⽤Cookie CDN是⼲什么⽤的
CDN（Content Delivery Network），根本作⽤是将⽹站的内容发布到最接近⽤户的⽹络『边缘』，以提⾼⽤户访问速度。概括的来说：CDN = 镜像（Mirror） + 缓存（Cache） + 整体负载均衡（GSLB）。
⽬前CDN都以缓存⽹站中的静态数据为主，如CSS、JS、图⽚和静态⽹页等数据。⽤户在从主站服务器请求到动态内容后再从CDN上下载这些静态数据，从⽽加速⽹页数据内容的下载速度，如淘宝有90%以上的数据都是由CDN来提供的。
CDN⼯作流程

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。