iOS网络高级编程

1.网络功能介绍

  • Cocoa Foundation

    • NSURL: NSURLConnection / NSURLSession
    • Bonjour 零配置网络(zeroconf)
    • GameKit 提供了点到点的网络, 无网络时,可以使用蓝牙组件点到点
    • NSStream: 对CFNetwork的封装,OC语音,作为 NSURLConnection 的基础,还支持STMP or telnet 等 NSURLConnection 不支持的功能。
      • ex: WiFi Camera 项目
  • 底层网络

    • CFNetwork:对BSD Socket简单封装,可以激活无线电,通过VPN,因此,几乎所有场景都推荐使用。在 Core Foundation 中
    • BSD Socket:Apple不推荐使用,原因:不会自动打开WiFi或蜂窝网络,会被关闭。移植过来的网络库可以使用。 在 OS 这一层

2. 设计服务架构

  • Facade 模式 的 WebService
    降低系统的复杂度,增加灵活性,将一些业务逻辑放到服务端。

  • 服务版本化,多版本API

    • 加入版本检查逻辑,检查最小支持版本,知道用户升级为止 - 不好,需要强制升级,有差评
    • 主动方式:WebService接收到客户端当前版本,然后选择正确的端点 - 最简单
    • 被动方式:版本化的服务硬编码到客户端代码当中 - 更灵活,两个版本的API出参入参相同,实现不同,可以实现切换。
    • [例子](http://www.tuicool.com/articles/qiMNjiR
  • 服务定位器

    • 动态检测远程API端点的工具。解决API不存在的问题。
    • 核心是:APP启动时,下载这个配置文件(文件包括:服务URL,版本号,名称等)

5. 错误处理

1. 理解错误源

  • OS操作系统错误, 数据包没有到达预定目标导致的,ex. 没有网络,timeout, 无法路由到主机
  • HTTP错误, 由HTTP请求,HTTP服务器,API程序的问题导致的,例如:404错误,500错误,200成功等。
  • 应用错误, 由运行在服务器上的API程序造成的,通常是:业务逻辑上错误(如:密码错误),或代码异常(如:数组为空)

2. 错误处理

  • 错误状态可能不正确: 如:超时,并不能知道请求是否成功。
  • 有时请求是成功的,但返回的数据是不正确的,需要验证。
  • 总是检查NSError, 判断是否出现错误
  • 使用一致的方法处理错误
  • 总是设置超时

3. 优雅地处理网络错误

6. 保护网络传输

1. 验证服务器通信 - 确保用户只与期望的服务器进行通信。

  • 最佳实践是使用 NSURLProtectionSpace 验证应用与期望的服务器进行通信,NSURLProtectionSpace 表示需要认证的服务器或域,是所有进来的 NSURLAuthenticationChallenge 的一个属性。
  • 请求API时,服务器返回401(访问拒绝)进行响应,NSURLConnection 接收到该响应,并立刻发送 challenge. willSendRequestForAuthenticationChallenge:可以检查 challenge, 验证保护空间。
  • 这种特定验证会确保应用只与指定的服务器进行通信。缺点是当Web Service变化后,就无法工作了,需要考虑备份的服务器。当然也可以只认证某些属性。

2. HTTP认证

  • Http Basic、Http Digest、NTLM认证

    • NSURLConnection 处理了所有的认证方法和哈希算法,APP只需要以 NSURLCredential 对象的形式指定认证信息就可以了。
    • Http Basic、Http Digest、NTLM认证的响应逻辑是相同的。
  • 客户端证书认证

    • 在认证的时候存储服务器返回的证书
    • 以后所有的请求都是通过客户端证书进行认证

3. 确保消息完整性 - 应用必须保证传输的数据在传输过程中是安全且未被修改过的。

  • 数据传输的结构: {“mac”:”消息认证码”, “iv”:”初始向量”, “payload”:”被加密的部分”}

  • IV (Initialization Vector 初始向量)

    • 用来对数据进行加密,并且会随着加密的数据一起发送给服务端,用于服务端的解密。但是只用IV是无法解密的。
    • 使用 SecRandomCopyBytes() 函数 生成 IV
  • MAC (Message Authentication Code 消息认证码)

    • 属于hash的一种,它更安全,多了一个加密KEY(M-Key)
    • 实现方式:对获得的数据生产Hash值,然后与数据一同过来的MAC值进行比较,如果相同,表示消息没有被修改过。
    • 使用 CCHmac() 函数进行加密,HMAC(基于哈希的消息验证码),
    • 由于两端都需要保存加密KEY,因此需要预先规划好修改KEY方案。
  • Hash(哈希,散列)

    • 常用于跟踪文件变更、验证数据的完整性、数据库存储、下载校验等。
    • CommonCrypto库,提供了MD5, SHA1, SHA256等哈希算法。
    • 对应函数:CC_MD5、CC_SHA1、CC_SHA256
    • 不可逆算法
  • 加密

    • 公钥密码学的非对称加密:应该在预先定义好的时间内下载公钥。
    • 数据加密标准(DES):执行3次独立加密过程,不适合移动加密
    • 高级加密标准 (AES): 只需要一步就能完成加密,设计时就考虑了速度,iOS4.3开始,超过1024个字节可以被硬件加速。
    • 使用CCCrypt() 函数进行加密,参数包括:IV,E-Key(加密Key)

4. 设备上安全地存储认证信息 - 保存到Keychain中

- 首先需要检查手机是否被越狱,如果越狱就可以使用了。

7. 优化请求性能

1.度量网络性能

  • 网络带宽 , 共享带宽,网速取决于通信路径上最慢的链路
  • 网络延迟,两个端点之间一次往返所需要的时间
  • 设备电量

2. 优化网络操作

  • 减少请求带宽

    • 使用合适的数据格式:目前基本都用JSON
    • 使用预先压缩的数据:音频、视频、图片
    • 压缩每一个请求与响应:压缩文本,减少带宽,但不影响原来的代码。纯文本数据压缩比在10%
    • 注意:响应压缩和请求压缩,不应该压缩”预先压缩过的数据”,如果预先压缩的数据使用Base64进行传输,就可以使用压缩,压缩比在30%
  • 响应压缩

    • 响应压缩会对响应体进行数据压缩,但Header不会压缩。在服务端压缩,客户端解压。
    • iOS默认开启了响应压缩,每个请求头都有:Accept-Encoding:gzip, deflate, 表示:客户端可以接收压缩后的数据
    • NSURLConnection 收到数据会自动解压,并以最初的格式呈现。
    • 响应压缩只要服务器支持压缩,就可以工作了。
  • 请求压缩

    • 即需要服务端压缩,也需要客户端压缩。客户端将Request发送给服务端之前,需要进行数据压缩。
    • Web浏览器对请求压缩支持不好,iOS应用首先查询服务器是否支持压缩,然后再决定是否对请求进行压缩
    • 请求压缩对移动应用非常好
    • Http Header 中带有 Content-Encoding:gzip 的请求,到达服务器端,服务器就会尝试解压请求。
  • 降低请求延迟

    • HTTP 请求集群
    • HTTP 管道
  • 避免网络请求 - 使用缓存

11. 应用间通信

  • URL Scheme
  • 感知其他应用的存在: 知道URL Scheme以后,调用 UIApplication 的 canOpenURL 就可以判断APP是否存在了。
  • 实现H5打开APP,并带上参数。
  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值