阅读 1984

iOS 网络基础和网络优化

网络优化

网络优化着手点

  1. NSCache缓存、Last-Modified、ETag
  2. DNS解析
  3. 数据压缩:protobuf,WebP
  4. 失败重发、缓存请求有网发送
  5. 弱网:2G、3G、4G、wifi下设置不同的超时时间
  6. TCP对头阻塞:GOOGLE提出QUIC协议,相当于在UDP协议之上再定义一套可靠传输协议

一、缓存

GET 网络请求缓存

POST请求不能被缓存,只有 GET 请求能被缓存。因为从数学的角度来讲,GET 的结果是幂等的,就好像字典里的 key 与 value 就是幂等的,而 POST 不是幂等 。缓存的思路就是将查询的参数组成的值作为 key ,对应结果作为value。

设置缓存步骤:

  1. 请使用 GET 请求。
  2. 如果你已经使用 了 GET 请求,iOS 系统 SDK 已经帮你做好了缓存。你需要的仅仅是设置下内存缓存大小、磁盘缓存大小、以及缓存路径。甚至这两行代码不设置也是可以的,会有一个默认值。
NSURLCache *urlCache = [[NSURLCache alloc] initWithMemoryCapacity:4 * 1024 * 1024 diskCapacity:20 * 1024 * 1024 diskPath:nil];
[NSURLCache setSharedURLCache:urlCache];
复制代码

文件缓存:借助ETag或Last-Modified判断文件缓存是否有效

控制缓存的有效性一是指定超时时间,二是借助ETag或Last-Modified判断文件缓存是否有效。

Last-Modified

Last-Modified: 是资源最后修改的时间戳,往往与缓存时间进行对比来判断缓存是否过期。

具体分析: 在浏览器第一次请求某一个URL时,服务器端的返回状态会是200,内容是你请求的资源,同时有一个Last-Modified的属性标记此文件在服务期端最后被修改的时间,格式类似这样:Last-Modified: Fri, 12 May 2006 18:53:33 GMT

客户端第二次请求此URL时,根据 HTTP 协议的规定,浏览器会向服务器传送 If-Modified-Since 报头,询问该时间之后文件是否有被修改过: If-Modified-Since: Fri, 12 May 2006 18:53:33 GMT

如果服务器端的资源没有变化,则自动返回 HTTP 304 (Not Changed.)状态码,内容为空,这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时,则重新发出资源,返回和第一次请求时类似。从而保证不向客户端重复发出资源,也保证当服务器有变化时,客户端能够得到最新的资源。

ETag

HTTP 协议规格说明定义ETag为“被请求变量的实体值”。 另一种说法是,ETag是一个可以与Web资源关联的记号(token)。它是一个 hash 值,用作 Request 缓存请求头,每一个资源文件都对应一个唯一的 ETag 值。

通过 ETagIf-None-Match 判断本地缓存数据是否发生变化。如果ETag没改变,则返回状态304然后不返回,和Last-Modified一样。

ETag 是的功能与 Last-Modified 类似:服务端不会每次都会返回文件资源。客户端每次向服务端发送上次服务器返回的 ETag 值,服务器会根据客户端与服务端的 ETag 值是否相等,来决定是否返回 data,同时总是返回对应的 HTTP 状态码。客户端通过 HTTP 状态码来决定是否使用缓存。比如:服务端与客户端的 ETag 值相等,则 HTTP 状态码为 304,不返回 data。服务端文件一旦修改,服务端与客户端的 ETag 值不等,并且状态值会变为200,同时返回 data。

因为修改资源文件后该值会立即变更。这也决定了 ETag 在断点下载时非常有用。

Last-Modified 和 ETag 比较

在官方给出的文档中提出 ETag 是首选的方式,优于 Last-Modified 方式。因为 ETag 是基于 hash ,hash 的规则可以自己设置,而且是基于一致性,是“强校验”。 Last-Modified 是基于时间,是弱校验,弱在哪里?比如说:如果服务端的资源回滚客户端的 Last-Modified 反而会比服务端还要新。

虽然 ETag 优于 Last-Modified ,但并非所有服务端都会支持,而 Last-Modified 则一般都会有该字段。 大多数情况下需要与服务端进行协调支持 ETag ,如果协商无果就只能退而求其次。

其他
  • 值得注意的一点是: 如果借助了 Last-Modified 和 ETag,那么缓存策略则必须使用 NSURLRequestReloadIgnoringCacheData 策略,忽略缓存,每次都要向服务端进行校验。

  • 一些建议: 如果是 file 文件类型,用 Last-Modified 就够了。即使 ETag 是首选,但此时两者效果一致。九成以上的需求,效果都一致。

如果是一般的数据类型--基于查询的 get 请求,比如返回值是 data 或 string 类型的 json 返回值。那么 Last-Modified 服务端支持起来就会困难一点。因为比如 你做了一个博客浏览 app ,查询最近的10条博客, 基于此时的业务考虑 Last-Modified 指的是10条中任意一个博客的更改。那么服务端需要在你发出请求后,遍历下10条数据,得到“10条中是否至少一个被修改了”。而且要保证每一条博客表数据都有一个类似于记录 Last-Modified 的字段,这显然不太现实。 如果更新频率较高,比如最近微博列表、最近新闻列表,这些请求就不适合,更多的处理方式是添加一个接口,客户端将本地缓存的最后一条数据的的时间戳或 id 传给服务端,然后服务端会将新增的数据条数返回,没有新增则返回 nil 或 304。

二、HttpDNS 优化

HttpDNS主要解决三类问题

  1. LocalDNS劫持
  2. 平均访问延迟下降
  3. 用户连接失败率下降
  • 预防DNS劫持
    DNS劫持指的是改变DNS请求的返回结果,将目的ip指向另一个地址。一般有两种方式,一是通过病毒的方式改变本机配置的DNS服务器地址,而是通过攻击正常DNS服务器而改变其行为。不管是哪种方式,都会影响app本身的业务请求。如果遇到恶意的攻击还会衍生出各种安全问题。客户端自己做DNS与ip地址的映射就跨过了解析,让劫持者无从下手。

运营商DNS劫持和故障实例图:

  • 很多三四级运营商会把运营解析指向他们的缓存服务器上,并把网页里面的广告替换成他们自己的,或者内嵌他们自己的广告。运营商DNS流量劫持,具体表现在你的H5网页莫名其妙的被加了广告(关于这个问题,也可以做域名白名单,非本域名资源禁止请求,或者H5方面做处理)
  • DNS服务商解析出现故障造成的大批量用户无法正常使用App,按天计算。。
  • DNS解析延迟过高造成的加载超时导致用户体验差

使用HttpDNS优化DNS解析和缓存

  App内用域名发送请求都要经过DNS解析出ip,然后再根据ip去拿对应的资源,这个过程中,如果LocalDNS中存在这个域名对应的ip,就会直接返回这个ip,类似于App内做缓存。如果不存在,才会去权威DNS查询改访问哪个ip,然后查询到的ip会在LocalDNS中做缓存。

HTTPDNS的实现,根据各自团队的情况可以选择自建或者第三方SDK的方案。根据目前DNS劫持和故障的严重程度,以及实现方案的成本对比。 HTTPDNS集成整体简图:

  • HttpDNS原理:
    A、客户端直接访问HttpDNS接口,获取业务在域名配置管理系统上配置的访问延迟最优的IP。(基于容灾考虑,app内肯定是需要保留使用运营商LocalDNS解析域名方式的。)
    B、客户端向获取到的IP后就向直接往此IP发送业务协议请求。以Http请求为例,通过在header中指定host字段,向HttpDNS返回的IP发送标准的Http请求即可。
    总的来说,采用HttpDNS来解析域名,就绕过了三四级运营商解析域名会出现的问题,在HttpDNS返回了正确的ip之后,我们是直接采用ip去进行http请求,只需要关注通信内容的安全即可。

HttpDNS 实际使用

接口层

接口层主要为了对外提供简洁的接口,降低使用者的接入成本,提高开发效率,如接口层提供的部分接口如下:

/// 开启HTTPDNS服务
- (void)startHTTPDNS;
/// 白名单列表,如果设置了白名单,则只有在白名单内域名走httpdns服务
@property (nonatomic, copy) NSArray *whiteDomainList;
/// 黑名单列表,如果设置了黑名单,黑名单内域名都不走httpdns,黑名单的优先级最高
@property (nonatomic, copy) NSArray *blackDomainList;
/// 是否允许缓存ip,允许缓存的情况下,在通过第三方服务无法获取ip的情况下,允许使用上次解析成功的ip进行请求,默认YES
@property (nonatomic, assign) BOOL enableCachedIP;
复制代码
策略层
  • 容灾策略:SDK内部优先使用HTTPDNS服务,当HTTPDNS服务不可用时,即无法获得有效ip时,服务自动降级为运营商的LocalDNS服务,确保不受HTTPDNS服务不可用时导致系统故障无法发出网络请求。注:目前阶段没有接入内置ip策略,后续会考虑。
  • 黑白名单策略:APP内的网络请求域名众多,目前并不是所有的网络请求都走HTTPDNS服务,设置了白名单或者黑名单后,会根据黑白名单中的域名去执行HTTPDNS,如果设置了白名单,则只有白名单内的域名走HTTPDNS服务;如果设置了黑名单,黑名单内的域名不走HTTPDNS服务,黑名单的优先级高于白名单。
  • 缓存策略:缓存策略除了基础服务层中腾讯云HTTPDNS SDK提供的基于TTL的缓存策略外,我们自己封装的接入层SDK中还存在一份内存缓存和本地化持久缓存,持久化缓存主要用来解决启动APP时无法获取HTTPDNS中的IP的问题,内存缓存主要为查询策略提供服务。当某个基于HTTPDNS的IP地址导致请求失败后,会清除当前域名和IP的缓存数据。同时外部可控制是否使用缓存。
  • 查询策略:查询策略主要是为了解决,短时间内同一个域名多次调用基础服务层的域名查询服务,当状态是正在查询中时,后来者不再调用查询服务,直接从缓存策略中的内存缓存中读取可用的IP,如果缓存内也无可用的IP,则直接降级为运营商的LocalDNS查询。查询策略可在确保服务可用的同时,有效减少和HTTPDNS服务器交互的次数。

最佳实践小结
因此,如果你对性能有这很高的要求,同时又需要处理SNI场景的问题,我建议不要直接主动使用HTTPDNS,而是在运营商LocalDNS获取的IP请求失败的情况下,可以在底层直接使用基于CFNetwork的网络请求进行重试,这样就能在请求DNS劫持和性能中间得到一个平衡,既能保证在运营商的LocalDNS解析出现问题时能够走HTTPDNS,保证成功率和可用性;同时又能够在运营商的LocalDNS可用时,使用基于NSURLSession的请求,享受系统实现的HTTP2.0特性带来的性能提升。

基于HttpDNS扩展

HttpDNS部署等有难度,替代方案:APP内置severs IP list,ping出最合适的Sever address。省去DNS查询时间。

  1. 在App内维护一个Serve IP List。把每次App从HttpDNS取到的ip存储进入该数组,并设置权重,理论上来说从HttpDns解析下来的ip权重是最大的。这个List可以在App启动的时候,进行更新,同时取出本地缓存的Serve IP List的权重最大的ip进行数据的初始化操作(如果第一次启动,没有该List的话,就使用LocalDNS进行解析)。 Serve IP List里面的权重设置机制,很明显的一点就是从DNS解析出来的ip具有最大的权重,每次从List里面取ip应该要取权重最大的ip。列表中的ip也是需要可以动态更新配置的,根据连接或者服务的成功失败来进行动态调整,这样即使DNS解析失败,用户在一段时间后也会取到合适的ip进行访问。
  2. 对ip进行数据统计。在所有app内统计每个ip进行请求所需平均时间、最长时间、最短时间、请求成功次数、失败次数,需要注意的是,要区分网络环境进行统计,Wifi、4G、3G,对在不同的网络环境下数据优秀的ip进行存储,下发到App里面使用起来。这样每次启动App时可以对收集起来的ip根据不同的网络环境进行测速,选择最好的ip进行请求。需要注意的是,在网络环境切换的时候,必须要重新进行速度测试。做到这一步,可以节约DNS解析时间,以及劫持的问题。
  3. 将图片、音频等资源放到单独的服务器里面,与其他资源分开。 第一个是多个域名可以增加并行下载条数,因为客户端对同一个域的域名下载条数是有限制的,所以多个域就会增加并行下载条数,从而加快加载速度。当然二级域名也不能使用太多,因为太多要考虑到dns的解析花费的时间。 第二个是方便管理,一般来说,图片在站点的加载中是最占带宽的,可以用独立服务器方便后期管理;还可以使用异步加载的方式,增强用户体验。同时是图片多是静态内容,可以更好的使用CDN加速。 第三是如果使用了独立服务器的话,在安全设置上可以有差别的针对设置,很是方便。
  4. 在防止劫持这一块,需要注意把资源的后缀名去掉,比如说.mp3.json这样的后缀,以免击中运营商的拦截。

其他

  • 备选LocalDNS原因

如果之前访问api.weibo.cn的是联通用户,现在新用户使用电信来访问api.weibo.cn,由于localDNS缓存的存在,不会去查询新浪的权威DNS,这样返回的ip是联通这个运营商的ip,从而会使得用户出现访问变慢等状况。缓存还会导致一点就是,当权威DNS将域名与ip的映射发生改变之后,由于LocalDNS缓存没有及时改变,用户就会访问到错误的服务器,或者直接访问不到资源。

三、失败重发、缓存请求有网发送

百分百送达服务器

对于百分百送达服务器的请求,第一步并不是直接发送,而是存入本地数据库中,一旦存入了数据库,即使是杀掉进程、断电、重启等极端操作,请求数据也依旧存在,我们只需要在App重启或者进入该业务界面时,还原请求数据到内存中,重新进行发送即可。

失败重发

一般开发的时候会和后台确定一些错误码,根据错误码的类型判断是否需要重发会更合理些。一般3次的重试基本可以排除网络抖动的情况。三次失败之后即可认为请求失败,通过产品交互告知用户。

RequestManager 的封装

RequestManager文件里面是进行request调度的主题逻辑,也没有进行复杂的算法,不按照优先级别,只是一个先入先出队列来进行调用的。里面有两个dispatch_queue:

//这个串行队列用来控制任务有序的执行
@property (nonatomic, strong) dispatch_queue_t taskQueue;
//添加、删除队列,维护添加与删除request在同一个线程
@property (nonatomic, strong) dispatch_queue_t addDelQueue;
复制代码

taskQueue主要是用来处理调度队列的,也就是requestQueue,让它在子线程进行循环查询、处理request,然后再并发进行网络请求,这样可以防止请求很多的情况下,卡住主线程。 addDelQeueu主要是用来处理requestQueue里面的requset增加与删除的。在添加和删除的时候,采用的方案都是串行+同步,主要是避免数据竞争。(因为在AFN发送request要删除requestQueue里面的request的时候,是并发状态) 在处理最大并发数的时候,我使用的是dispatch_semaphore_t(信号量),设置最大并发数是4。 逻辑并不复杂,需要注意的是,如何避免数据竞争,如何尽可能的不消耗主线程资源。

四、弱网优化

www.52im.net/thread-2479…

五、资源优化

资源优化基本就是尽可能的缩小传输数据的大小,首先是图片大小的解决方案。

方案: 在一定程度上使用webp来代替jpg、png图片

需要注意的是,webp的图片要通过解析才能成为可用的jpg图片,在iOS开发中,可以使用SDWebImage框架进行解析,webp->NSData->Image,app内解析是肯定需要花费一定时间和性能的。 在wifi条件下,超过300300的图片使用webp图片,解析时间+下载时间是比直接使用jpg\png图片要快的,并且在流量方面也是消耗很小。低于300300的可以直接下载使用jpg\png图片。在4G条件下,用户可能会对流量比较敏感,建议都走webp图片。

网络基础

一、HTTP2.0 新特性浅析

HTTP2.0 新特性

二进制分帧 首部压缩 多路复用 服务器推送 请求优先级

HTTP2.0 的优势

HTTP/2 主要是 HTTP/1.x 在底层传输机制上的完全重构,相比 HTTP/1.x,HTTP/2 在底层传输做了很大的改动和优化:

  1. HTTP/2 采用二进制格式传输数据,而非 HTTP/1.x 的文本格式。二进制格式在协议的解析和优化扩展上带来更多的优势和可能。
  2. HTTP/2 对消息头采用 HPACK 进行压缩传输,能够节省消息头占用的网络的流量。而 HTTP/1.x 每次请求,都会携带大量冗余头信息,浪费了很多带宽资源。头压缩能够很好的解决该问题。
  3. 多路复用,直白的说就是所有的请求都是通过一个 TCP 连接并发完成。HTTP/1.x 虽然通过 pipeline 也能并发请求,但是多个请求之间的响应会被阻塞的,所以 pipeline 至今也没有被普及应用,而 HTTP/2 做到了真正的并发请求。同时,流还支持优先级和流量控制。
  4. Server Push:服务端能够更快的把资源推送给客户端。例如服务端可以主动把 JS 和 CSS 文件推送给客户端,而不需要客户端解析 HTML 再发送这些请求。当客户端需要的时候,它已经在客户端了。

二、HTTP、TCP、UDP、IP

HTTP

HTTP,超文本传输协议。是一个基于请求与响应模式的、无状态的、应用层的协议,常基于TCP的连接方式。由于其简捷、快速的方式,适用于分布式超媒体信息系统,是现今在WWW上应用最多的协议。

  • HTTP 由来 我们在传输数据时,可以只使用(传输层)TCP/IP协议,但是那样的话,如果没有应用层,便无法识别数据内容,如果想要使传输的数据有意义,则必须使用到应用层协议,应用层协议有很多,比如HTTP、FTP、TELNET等,也可以自己定义应用层协议。WEB使用HTTP协议作应用层协议,以封装HTTP文本信息,然后使用TCP/IP做传输层协议将它发到网络上。

  • HTTP 协议的作用 HTTP 的全称是 Hypertext Transfer Protocol,超文本传输协议。 规定客户端和服务器之间的数据传输格式。 让客户端和服务器能有效地进行数据沟通。

  • HTTP请求的方法 发送HTTP请求的方法在HTTP/1.1协议中,定义了8种发送http请求的方法 :GET、POST、OPTIONS、HEAD、PUT、DELETE、TRACE、CONNECT、PATCH

  • HTTP协议的主要特点可概括如下:

    1. 支持客户/服务器模式。
    2. 简单快速:客户向服务器请求服务时,只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单,使得HTTP服务器的程序规模小,因而通信速度很快。
    3. 灵活:HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
    4. 无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。
    5. 无状态:HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。
  • Http 常见状态码
    200:请求成功
    400:客户端请求语法的错误,服务器无法解析
    404:服务器无法通过客户端的请求找到资源
    500:服务器内部错误无法完成请求

  • POST、GET PUT 的区别

    • GET 方法
      GET 方法提交数据不安全,数据置于请求行,客户端地址栏可见;
      GET 方法提交的数据大小有限,不过因为浏览器不同,一般限制在2~8K之间
      GET 方法不可以设置书签
      GET 请求能够被缓存
    • POST 方法
      POST 方法提交数据安全,数据置于消息主体内,客户端不可见
      POST 方法提交的数据大小没有限制。靠服务器限制。
      POST 方法可以设置书签
      POST 请求不能够被缓存
    • PUT方法
      PUT
      1. 文件大小无限制
      2. 可以覆盖文件
      POST
      1. 通常有限制2M
      2. 新建文件,不能重名

HTTP、TCP、UDP 三者的关系

都是通信协议,也就是通信时所遵守的规则,只有双方按照这个规则“说话”,对方才能理解或为之服务。 TCP/IP是个协议组,可分为四个层次:网络接口层、网络层、传输层和应用层。主要解决数据如何在网络中传输。 在网络层有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议。 在传输层中有TCP协议与UDP协议。 在应用层有FTP、HTTP、TELNET、SMTP、DNS等协议。 因此,HTTP本身就是一个协议,是从Web服务器传输超文本到本地浏览器的传送协议。HTTP协议是基于TCP连接的。主要解决如何包装数据。

TCP连接的三次握手

第一次握手:客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认;
第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。
握手过程中传送的包里不包含数据,三次握手完毕后,客户端与服务器才正式开始传送数据。理想状态下,TCP连接一旦建立,在通信双方中的任何一方主动关闭连接之前,TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求,断开过程需要经过“四次握手”(过程就不细写了,就是服务器和客户端交互,最终确定断开)

TCP和UDP的区别

TCP:TransmissionControl Protocol 传输控制协议TCP是一种面向连接(连接导向)的、可靠的、基于字节流的运输层(Transport layer)通信协议,由IETF的RFC 793说明(specified)。当客户和服务器彼此交换数据前,必须先在双方之间建立一个TCP连接,之后才能传输数据。TCP提供超时重发,丢弃重复数据,检验数据,流量控制等功能,保证数据能从一端传到另一端。
UDP 是User DatagramProtocol的简称, 中文名是用户数据包协议,是OSI 参考模型中一种无连接的传输层协议,提供面向事务的简单不可靠信息传送服务,IETF RFC 768是UDP的正式规范。UDP不提供可靠性,它只是把应用程序传给IP层的数据报发送出去,但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接,且没有超时重发等机制,故而传输速度很快 。
面向连接:是指通信双方在通信时,要事先建立一条通信线路,其有三个过程:建立连接、使用连接和释放连接。电话系统是一个面向连接的模式,拨号、通话、挂机;TCP协议就是一种面向连接的协议
面向无连接:是指通信双方不需要事先建立一条通信线路,而是把每个带有目的地址的包(报文分组)送到线路上,由系统自主选定路线进行传输。邮政系统是一个无连接的模式,天罗地网式的选择路线,天女散花式的传播形式;IP、UDP协议就是一种无连接协议。

三、socket

网页(网址以http://开头)都是http协议传输到你的浏览器的, 而http是基于socket之上的。socket是一套完成tcp,udp协议的接口。

  • 什么是socket?

    1. Socket是一个针对TCP和UDP编程的接口,你可以借助它建立TCP连接等等。而TCP和UDP协议属于传输层 。而http是个应用层的协议,它实际上也建立在TCP协议之上。 (HTTP是轿车,提供了封装或者显示数据的具体形式;Socket是发动机,提供了网络通信的能力。)
    2. Socket是对TCP/IP协议的封装,Socket本身并不是协议,而是一个调用接口(API),通过Socket,我们才能使用TCP/IP协议。Socket的出现只是使得程序员更方便地使用TCP/IP协议栈而已,是对TCP/IP协议的抽象,从而形成了我们知道的一些最基本的函数接口。
  • socket连接和http连接的区别? http连接:http连接就是所谓的短连接,即客户端向服务器端发送一次请求,服务器端响应后连接即会断掉; socket连接:socket连接就是所谓的长连接,理论上客户端和服务器端一旦建立起连接将不会主动断掉;但是由于各种环境因素可能会是连接断开,比如说:服务器端或客户端主机down了,网络故障,或者两者之间长时间没有数据传输,网络防火墙可能会断开该连接以释放网络资源。所以当一个socket连接中没有数据的传输,那么为了维持连接需要发送心跳消息,具体心跳消息格式是开发者自己定义的。

  • 利用Socket建立网络连接的步骤: 建立Socket连接至少需要一对套接字,其中一个运行于客户端,称为ClientSocket ,另一个运行于服务器端,称为ServerSocket 。

套接字之间的连接过程分为三个步骤:服务器监听,客户端请求,连接确认。

  1. 服务器监听:服务器端套接字并不定位具体的客户端套接字,而是处于等待连接的状态,实时监控网络状态,等待客户端的连接请求。
  2. 客户端请求:指客户端的套接字提出连接请求,要连接的目标是服务器端的套接字。为此,客户端的套接字必须首先描述它要连接的服务器的套接字,指出服务器端套接字的地址和端口号,然后就向服务器端套接字提出连接请求。
  3. 连接确认:当服务器端套接字监听到或者说接收到客户端套接字的连接请求时,就响应客户端套接字的请求,建立一个新的线程,把服务器端套接字的描述发给客户端,一旦客户端确认了此描述,双方就正式建立连接。而服务器端套接字继续处于监听状态,继续接收其他客户端套接字的连接请求。

四、URL

  • 什么是URL URL 的全称是 Uniform Resource Locator(统一资源定位符)。 通过1个URL,能找到互联网上唯一的1个资源。 URL 就是资源的地址、位置,互联网上的每个资源都有一个唯一的URL。

  • URL 的基本格式 = 协议://主机地址/路径 协议:不同的协议,代表着不同的资源查找方式、资源传输方式 主机地址:存放资源的主机的IP地址(域名) 路径:资源在主机中的具体位置

  • URL 中常见的协议 http 协议是在网络开发中最常用的协议 超文本传输协议,访问的是远程的网络资源,格式是 http:// file 访问的是本地计算机上的资源,格式是 file://(不用加主机地址) mailto 访问的是电子邮件地址,格式是 mailto: FTP 访问的是共享主机的文件资源,格式是 ftp://

五、其他

  • 如果在网络数据处理过程中,发现一处比较卡,一般怎么解决?
    1. 检查网络请求是否被放在主线程了
    2. 看看异步请求的数量是否太多了(子线程的数量)
    3. 数据量是否太大?如果太大,先清除一些不必要的对象(看不见的数据、图片)
    4. 手机的CPU使用率和内存问题
  • iOS 网络编程层次结构分为三层: Cocoa 层: NSURL,Bonjour,Game Kit,WebKi。这层是最上层的基于 Objective-C 的 API,比如 URL访问,NSStream,Bonjour,GameKit等,这是大多数情况下我们常用的 API。Cocoa 层是基于 Core Foundation 实现的。(可触摸层) Core Foundation 层: 基于C的CFNetwork和CFNetServices。因为直接使用 socket 需要更多的编程工作,所以苹果对 OS 层的 socket 进行简单的封装以简化编程任务。该层提供了 CFNetwork 和 CFNetServices,其中 CFNetwork 又是基于 CFStream 和 CFSocket。(核心服务层) OS 层: 基于 C 的 BSD socket。(核心操作系统层)

数据安全

网络数据加密

加密对象:隐私数据,比如密码、银行信息 加密方案:

  1. 提交隐私数据,必须用POST请求
  2. 使用加密算法对隐私数据进行加密,比如MD5
  3. 加密增强:为了加大破解的难度 对明文进行2次MD5 : MD5(MD5(pass))先对明文撒盐,再进行MD5MD5(pass)) 先对明文撒盐,再进行MD5 : MD5(pass.$salt)

本地存储加密

加密对象:重要的数据,比如游戏数据

代码安全问题

现在已经有工具和技术能反编译出源代码:逆向工程

  • 反编译出来的都是纯C语言的,可读性不高
  • 最起码能知道源代码里面用的是哪些框架

解决方案:发布之前对代码进行混淆

  • 混淆之前
@interface HMPerson :NSObject
- (void)run;
- (void)eat;
@end
复制代码
  • 混淆之后
@interface A :NSObject
- (void)a;
- (void)b;
@end
复制代码

BASE 64

BASE 64是网络传输中最常用的编码格式,用来将二进制的数据编码成字符串的编码方式。 BASE 64的用法:

  1. 能够编码,能够解码。
  2. 被很多的加密算法作为基础算法。

文件解压缩

技术方案

  1. 第三方框架:SSZipArchive
  2. 依赖的动态库:libz.dylib

压缩方法

  1. 第一个方法

zipFile :产生的zip文件的最终路径 directory : 需要进行的压缩的文件夹路径 [SSZipArchive createZipFileAtPath:zipFile withContentsOfDirectory:directory];

  1. 第一个方法

zipFile :产生的zip文件的最终路径 files : 这是一个数组,数组里面存放的是需要压缩的文件的路径 files = @[@"/Users/apple/Destop/1.png", @"/Users/apple/Destop/3.txt"] [SSZipArchive createZipFileAtPath:zipFile withFilesAtPaths:files];

解压缩

zipFile :需要解压的zip文件的路径 dest : 解压到什么地方 [SSZipArchive unzipFileAtPath:zipFile toDestination:dest];

参考文章

APP网络优化之DNS优化实践 APP域名容灾方案