继续创作，加快成长！这是我参与「日新方案 10 月更文应战」的第3天，点击查看活动详情

1. 前言: 作为一个有自我修养的iOS工程师, 对网络的了解体现在开发中的方方面面

  • 假如你是个科班毕业的iOS开发者, 对计算机网络的基础知道或许是经过<<计算机网络>>这本教材.
    iOS老司机的网络相关Tips
  • 假如你是个其他专业转向iOS的开发者, 对计算机网络的知道或许来自于这本很多大佬安利的<<图解HTTP>>
    iOS老司机的网络相关Tips
  • 下面就由咱们来结合iOS开发日常工作中的方方面, 来一起对iOS中常用的网络相关知识做一个不成系统的梳理, 抛砖引玉, 如在阅读进程中发现过错, 请及时在谈论区沟通纠正:)

2. iOS开发中的网络相关基操Tips

2.1 HTTP的恳求方法有哪些?

iOS老司机的网络相关Tips

  • GET、POST、PUT、DELETE、HEAD、OPTIONS
  • 其实咱们在开发进程中用的最多的恳求方法的是GET和POST, 对其他的⽅式使⽤的很少, 在有些公司采⽤restful⻛格的时分会⽤PUT来做更新, DELETE做删除.

2.1.1 GET和POST的差异

  • 从用法来说, GET首要是用来获取资源的, 语义上具有安全性、幂等性、可缓存性;
  • 从用法来说, POST首要是用来修改资源的, 语义上具有不安全性、非幂等性、不行缓存性;
    • 安全性, 指的是是否能引起server端的变化.
    • 幂等性, 指的是单次恳求和屡次恳求的成果是否共同.
    • 可缓存性, 指的是恳求是否能够被缓存.

2.2 关于HTTP的耐久衔接的了解

  • 随着咱们要处理的资源越来越多, 假如仍是采⽤非耐久衔接的⽅式就会很浪费资源, 因为会牵扯到⼤量的衔接的建⽴和毁掉.
  • 所以为了处理这种问题, 提出了耐久衔接来改善.
  • 便是在衔接建⽴今后, 处理完使命不是⽴即毁掉, ⽽是有⼀个等候时刻, 在这段时刻范围内能够对同⼀服务的恳求进⾏复⽤, 减少衔接的创建和毁掉次数.

2.3 怎样判别一个HTTP恳求是否现已完结了?

  • 判别⼀个恳求是否完结的⽅式有两种.
  • 第⼀种: 经过呼应报⽂中的content-length字段来判别接纳的数据是否现已接纳完毕了, 假如接纳完 毕了就表明本次恳求完结了.
  • 第⼆种: 在POST恳求中会存在屡次呼应, 在最终⼀次呼应的报⽂中会包括⼀个空的chunck, 咱们能够以此来判别恳求是否完结了.

2.4 HTTP衔接进程中的三次握手和四次挥手

2.4.1 三次握手

  • 发送⼀个http恳求要先建⽴衔接.
  • ⾸先server端要监听端⼝, 此时server端处于LISTEN状况.
  • client端发送⼀个SYN同步包到server端, 并将⾃⼰（client端）的状况置为SYN_SENT
  • server端收到client的syn, 会回传⼀个ACK承认信息, 以及⼀个SYN同步包, 赞同建⽴衔接, 将server 端状况置为SYN_RCVD.
  • client端收到服务端的SYN包后, 发送⼀个ACK给server端. 并将⾃⼰的状况改为ESTABLISHED.
  • server端接纳到ACK信息后, 会将状况改为ESTABLISHED.
  • 这样就完结了三次握⼿, 就能够进⾏数据的传递了.

2.4.2 四次挥手

  • 关于断开衔接的四次挥⼿的流程, 首要是因为全双工通道的机制.
  • client端发送⼀个FIN信号给server端, 并进⼊FIN_WAIT_1状况.
  • server端接纳到音讯后会回来⼀个ACK承认, 并进⼊CLOSE_WAIT状况.
  • client端接纳到ACK承认信息后, 将状况改为FIN_WAIT_2. 此时现已完结了半封闭状况.
  • 当server端要传输的数据也完结今后, 就会发送⼀个FIN信号给client端, 并将状况置为LAST_ACK.
  • client端接纳到FIN信号后会回来⼀个ACK给server端, 并将状况置为TIME_WAIT.
  • server端在收到ACK承认信息后, 会进⼊CLOSE状况.
  • client端会在等候2MSL(报⽂最⼤⽣存时刻)的时刻后进⼊CLOSE状况.

2.4.3 为什么要等候2MSL?

  • 为了确保牢靠封闭.
  • 假如server没有收到最终⼀个ACK, 那么就会重发FIN.
  • 为了防止端⼝重⽤带来的数据混杂, 假如client直接进⼊CLOSE状况, ⼜⽤相同的端⼝建⽴⼀个衔接, 上⼀次衔接的部分数据在⽹络中延迟抵达server, 数据就有或许发⽣混杂.

2.5 TCP和UDP的差异

  • TCP是传输操控协议, 它的特点是: ⾯向衔接的、牢靠的、⾯向字节省的, 流量操控、拥塞操控.
  • UDP是⽤户数据报协议, 它的特点是: ⽆衔接、尽最⼤或许交付、⾯向报⽂的, 不确保数据的完整 性.

2.5.1 TCP是怎样确保传输进程的牢靠性的?

  • TCP在确保传输的牢靠性⽅⾯首要有以下机制
  • 校验和: 发送⽅在发送数据之前计算校验和, 接纳⽅收到数据后相同计算, 假如不⼀致, 那么传输有 误.
  • 承认应对: TCP进⾏传输时数据都进⾏编号, 每次接纳⽅回来ACK都有承认序列号.
  • 超时重传: 假如发送⽅发送数据⼀段时刻后没有收到ACK, 那么就重发数据.
  • 关于超时重传的情况有两种
    • ⼀种是客户端发送到服务端的数据超时了, 那么服务端或许会收到两份数据, 服务端会丢掉重复的数据.
    • 还有⼀种是服务端承认信息超时了, 那么客户端在收到承认信息的时分什么都不做.

2.5.2 TCP的流量操控与拥塞操控

iOS老司机的网络相关Tips

  • TCP的流量操控是经过滑动窗⼝协议来实现的. TCP协议报⽂头包括16位的窗⼝⼤⼩, 接纳⽅在回来ACK时会把⾃⼰的即时窗⼝填⼊, 发送⽅就根据报⽂中窗⼝的⼤⼩来操控发送的速度.
  • 拥塞操控是为了处理⽹络中涌⼊⼤量数据包的⼀种机制.
  • 这⾥首要使⽤慢开端, 拥塞防止和快康复, 快重传两种策略.
    • 慢开端是指刚开端发送数据的时分, 拥塞窗⼝是1, 今后每次收到ACK后, 将拥塞窗⼝的值依照指数级增⻓, 当增⻓达到了拥塞窗⼝的⻔限值的时分, 就会以线性⽅式增⻓, 来操控发送数据的速度.
    • 当发送⽹络拥塞的时分, 就会将拥塞窗⼝值改为1, 重新开端慢开端的流程. 一起将拥塞窗⼝的⻔限值改为拥塞时的⼀半.
    • 快康复快重传是根据慢开端的, 在发⽣⽹络拥塞的时分, 是把拥塞窗⼝的⼤⼩调到拥塞值的⼀半, 然后以线性⽅式增⻓.

2.6 DNS域名解析相关

iOS老司机的网络相关Tips

  • DNS是做域名解析的, 咱们在经过域名拜访服务器的时分, ⾸先会经过DNS进⾏域名解析, 得到服务器的IP地址, 然后再进⾏拜访.
  • 域名解析使⽤的UDP的⽅式进⾏明⽂传输的. 采⽤udp是因为它的速度更快.
  • 可是因为传输的明⽂, 所以简单遭到绑架.
  • 所以在处理DNS绑架的时分首要有两种⽅式, ⼀种是httpDNS, ⼀种是⻓衔接.
    • httpDNS是指经过发送⼀个http恳求来解析域名. 因为一般的DNS绑架是根据UDP的, 所以咱们经过 httpDNS是采⽤TCP的⽅式, 能够防⽌.
    • ⻓衔接的⽅式是指咱们建⽴⼀个⻓衔接服务器, 让client与中间服务器建⽴⻓衔接, 并将⻓衔接与域名解析服务器经过内⽹专线的⽅式进⾏衔接, 以此来防止DNS的绑架.

2.7 怎么确保Cookie的安全

iOS老司机的网络相关Tips

  • 对cookie内容进⾏加密处理, 这种⽅式的缺点是不能防止脚本攻击.
  • 在https下传输cookie, 这也是咱们使⽤最多的⽅式.
  • 设置cookie为httpOnly来防⽌跨站脚本攻击.

2.8 关于HTTPS

  • HTTPS是在HTTP的基础上增加了安全模块（TLS/SSL）.

2.8.1 HTTPS的衔接建立流程

iOS老司机的网络相关Tips

  1. ⾸先client端将当时⽀持的TLS版别号, 以及⽀持的加密算法, 并⽣成⼀个随机数C⼀起发送给server端.
  2. server端收到音讯后会挑选⼀套加密算法, 并⽣成⼀个随机数S, 连同server证书回来给client端
  3. client端先校验server证书, 然后根据预主秘钥+C+S组装会话秘钥. 并经过server证书将预主秘钥加密发送给server端.
  4. server端⽤私钥进⾏解码, 得到预主秘钥后, 组装会话秘钥, 然后加密握⼿音讯.

2.9 ISO模型的七层架构(应表会传网数物)

  • 七层架构分别是: 应⽤层、表明层、会话层、传输层、⽹络层、数据链路层、物理层.
  • 应⽤层: 最⾼层, 直接⾯对⽤户.
  • 表明层: ⽤来将数据转换成别的⼀种格局, ⽐如⽂字、视频、图⽚等.
  • 会话层: 负责建⽴和断开衔接.
  • 传输层: TCP、UDP都属于这⼀层的协议.
  • ⽹络层: 定义了IP和⼦⽹掩码, ⽤来承认⽹段, 经过路由器和交换机进⾏传输. IP协议便是属于⽹络层的协议.
  • 数据链路层: 把⽐特流封装成数据帧的格局.
  • 物理层: 经过⽹线, 光缆等这种物理⽅式将电脑衔接起来, 传递的是⽐特流.

2.10 什么是BIO/NIO/AIO?

  • BIO: 同步堵塞IO, 每⼀个客户端衔接, 服务端都会对应⼀个处理线程, 关于没有分配到处理线程的连 接就会被堵塞或者拒绝. 相当于⼀个衔接⼀个线程.

iOS老司机的网络相关Tips

  • NIO: 同步⾮堵塞IO, 根据Reactor模型, 客户端和channel进⾏通信, channel能够进⾏读写操作. 经过多路复⽤器seletor来轮询注册在其上的channel, ⽽后再进⾏IO操作. 这样的话, 在进⾏IO操作的时分再⽤⼀个线程去处理就好. 也便是⼀个恳求⼀个线程.

iOS老司机的网络相关Tips

  • AIO: 异步⾮堵塞IO, 相⽐NIO更进⼀步, 完全有操作系统来完结恳求的处理, 然后告诉服务端敞开线 程进⾏处理, 因此是⼀个有效恳求⼀个线程.

2.11 浅谈一下对HTTP的了解

iOS老司机的网络相关Tips

  • ⾸先http是超⽂本传输协议, 它是根据TCP协议的应⽤层传输协议.
  • 它的特点首要有两个, ⽆衔接和⽆状况
    • 关于⽆衔接是指约束每次衔接只处理⼀个恳求. 服务器处理完客户端的恳求, 并收到客户端的应对后 就断开衔接. 这是早期采⽤的⽅式, 为了追求快, 传输的资源少. 可是随着咱们要处理的资源增多, 就提出了耐久衔接的⽅式, 来复⽤衔接, 经过设置⼀个时刻, 在这段时刻内都能够复⽤此次衔接, 只要在超越这个时刻后才会断开衔接.
    • 关于⽆状况是指每次恳求不会记载状况, 为了处理这种⽆状况的问题, 提出了cookie和session机制. cookie和session都是⽤来记载⽤户状况, 区分⽤户的. 首要的差异在于cookie是保存在客户端, session是存储在服务端的. session的实现也是根据cookie机制的.
  • 别的咱们在发送⼀个http恳求的时分还首要恳求报⽂和呼应报⽂.
    • 关于恳求报⽂首要包括恳求⾏, 在恳求⾏⾥包括了恳求⽅式是GET仍是POST, 还有URL, 以及当时协议的版别是http1.0仍是1.1.
    • 除了恳求⾏还有恳求的头部字段, 这⾥是以key-value的方式存在, 包括多个键值对
    • 还有便是实体主体, 在get恳求时没有这⼀块, 在POST恳求时有.
    • 关于呼应报⽂也包括呼应⾏、头部字段、以及实体主体. 在呼应报⽂的呼应⾏中存在着当时的版别、状况码、短语, 也便是描绘信息.

2.12 常见的状况码

  • 1xx: 现在是协议的中间状况, 还需要后续恳求
    • 100: 恳求者应当继续发送恳求, 服务端回来100表明已收到恳求的第一部分, 正在等候剩下部分.
    • 101: 切换恳求协议, 客户端已要求服务端切换协议, 服务端已承认并准备切换. 如从HTTP切换到WebSocket
  • 2xx: 表明恳求成功
    • 200: 恳求成功, 有呼应体, 服务器成功回来数据
    • 204: 服务端成功处理了恳求, 但没有回来任何内容(无内容)
    • 205: 服务端成功处理了恳求, 但没有回来任何内容(重置内容)
  • 3xx: 表明重定向状况, 需要重新恳求
    • 301: 永久重定向, 会缓存
    • 302: 临时重定向, 不会缓存
    • 304: 协商缓存命中
  • 4xx: 表明客户端恳求报文过错
    • 400: 恳求过错, 服务端不了解恳求的语法
    • 403: 服务器禁止拜访, 拒绝恳求
    • 404: 资源未找到, 恳求的网页不存在
  • 5xx: 表明服务端过错
    • 503: 服务器繁忙(服务不行用, 因为超载或停机保护, 通常仅仅暂时状况)
    • 504: 服务端作为网关或署理, 可是没有及时从上游服务器收到恳求.(网关超时)

发文不易, 喜爱点赞的人更有好运气 :), 定时更新+关注不迷路~

ps：欢迎加入笔者18年建立的研究iOS审核及前沿技术的三千人扣群：662339934，坑位有限，备注“网友”可被群管经过~