前言

网络模块是 App 应用最基础最核心的模块， 稳定高效的网络处理是良好用户体验的基本保障。 本文介绍日常开发中常用的网络协议以及使用方法。

目录

• http 协议
• http 的问题以及优化策略
• 安全处理策略
• WebSocket 协议解析
• Http2 协议简介

Http 协议

先看一下网络请求传输的过程：

核心步骤主要是以下几步：

1. DNS 解析， 获取服务器的 ip 地址列表
2. TCP/IP 链接到服务器
3. 在 TCP/IP 上构建协议规则
4. 服务器收到请求，通过通道返回响应
5. Client 收到响应后关闭通道

Http 协议分为 Request， Response 两部分。 客户端发起一个 Request； 服务器处理后，返回一个 Response。

Request

看一下 Request 的构成：

上半部分为请求头， 下半部分为请求体。

第一行描述请求的方式，请求的路径， http 的协议版本。 之后每一行描述一个请求头字段。 请求头和请求体之间以两个换行分割。

常用的请求头字段：

• Content-Type： 表示请求内容的类型。 一般 api 请求主要使用

application/json
application/x-www-form-urlencoded
multipart/form-data

• Content-Length: 请求体大小。 服务器根据这个值才能获取完整的请求数据
• User-Agent: 客户端可以随意设置的一个值， 用来描述客户端的信息
• Connection: 链接类型。 上图中 Keep-Alive 表示服务器收到请求号保持链接不要关闭。
• Accept-Encoding: gzip 表示当前客户端接受 gzip 编码的响应内容

Response

Response 同样分为头和体两部分。

响应码： 请求是否成功根据响应码判断。 每种响应码都对应各自的含义。详细参考 wiki

常用的响应头：

• Connection: keep-alive. 表示响应未关闭， 客户端实现上同样需要保持链接未关闭
• Cache-Control: 协议的缓存策略
• Content-Encoding: gzip 表示当前返回的内容采用的 gzip 编码。 解析数据时使用 gzip 解码
• Content-Type：返回数据的内容格式

Cookie

cookie 是随着 Response 返回的键值对数据， 保存在本地。 下次再访问同一个域时， 将 Cookie 的 kvs 随着 Request 带到 Server。 后台开发人员可以根据业务的需求设置对应的 Cookie。

Http 的问题

对于 App 的场景来说， 使用 http 协议处理网络请求是一种最简单， 但不是最高效的方式(个人观点)

1. 最大的问题， 延迟。 App 的请求都很分散， 大部分发起的请求都需要重新构建整个链接， 延迟问题很严重。
2. 无效数据重复提交。 每次请求都会将同样的 headers 提交到服务器。
3. 单向数据通道。 服务器属于被动响应模式， 无法做到主动推送数据。

Http 优化策略

Http耗时

如上图， Http 请求的耗时主要由四部分组成。 围绕这四部分分析优化策略。

1. Cache

最快的请求是不发起请求。 不仅在协议层处理网络的缓存， 还需要在业务层处理数据的缓存。 在不必要的情况下， 尽量不发起网络请求， 直接使用缓存中的数据。

2. DNS

系统都有 Dns 解析的实现。 默认情况下直接调用系统 API 执行 Dns 查询操作。

• Dns 优化策略一
  实现 Dns 二级缓存。 当执行请求时，需要调用 Dns 查询。 将 ips 结果缓存起来， 下次再请求同样的域名时，直接从缓存内取出结果， 而不需要再次调用系统查询

• Dns 优化策略二
  使用第三方 HttpDns 服务。 系统默认的 dns 服务在不同的设备不同的 os 上实现、速度、缓存策略可能都不太一样。可以使用第三方的 HttpDns 服务查询 IPs， 绕开系统层的实现。 然后自己实现结果缓存策略。 例如, 使用腾讯的 DnsPod 查询百度的 IPs：
  http://119.29.29.29/d?dn=www.baidu.com

3. 链接复用

http 1.1 默认是设置 Connection:Keep-Alive。 就是表示请求完成后并不马上关闭， 后续相同的请求通过链路的复用， 节省 tcp 链接建立的耗时。

4. 请求

在带宽固定的情况下， 减少提交的数据包大小， 降低数据传输的耗时。

• 策略一
  选择合理的数据提交方式。 一般常用的 post 数据提交格式有

1. JSON Content-Type: application/json
2. UrlEncode Content-Type:application/x-www-form-urlencoded
3. formdata Content-Type:application/form-data

相对来说 json 和 urlEncode 的格式占用比较小。 formdata 比较大， 一般是上传文件时使用。

• 策略二
  对提交的内容进行压缩。 同时设置 Content-Encoding。

5. 响应

原理同上， 减小数据包的大小， 降低数据传输的耗时。

• 策略一
  服务器返回数据时将数据做压缩处理。
• 策略二
  使用 webp 格式的图片资源。 app 的流量消耗的大头在于图片， 使用 webp 格式的图片能够减少 40%+ 的流量消耗。

安全

安全处理策略有两个方面。 一种是在使用上增加安全校验， 一种是在协议上使用安全协议，如 Https。

请求防篡改

前后端交互常规做法的一种。 对请求的参数的某些值连在一块， 再通过加盐算 MD5 值生成一个签名。 将签名值附加到请求参数中。 后端收到请求后同样需要验证这个签名， 不一致的话说明请求参数已经被篡改了， 不予通过。

signature = md5(value1+value2+value3+solt);

稍微更严格一点的方式是，对所有请求参数根据 key 值做自然排序， 再用上述方法算一遍签名。

这种方式主要是为了防止参数被篡改， 并不能防止被拦截。

Https

使用 Https 能从协议上解决安全问题。全面升级到 Https 是目前业界的趋势。 下图是 Https 的处理过程简图：

WebSocket 协议

Http 协议是一种被动式的处理消息的方式。 app 很多场景下需要由服务器主动将数据推送到客户端。 使用 WS 协议维持客户端到服务器的长连接是一种很好的解决方案。 目前在 IM 或直播的场景下应用b
比较广泛。

WS 请求 WS 响应

上面两张图为 ws 协议请求和响应。

1. 客户端发起一个 http 的 get 请求。
2. 请求头中表示链接方式为升级(Connection: Upgrade) 到 websocket协议（Upgrade: websocket）
3. Sec-WebSocket-Key: 为客户端生成的随机字符串(掩码值)
4. Sec-WebSocket-Version： 13 表示使用 ws 1.3 版本。
5. 响应码 101 表示协议切换成功, 协议升级到 websocket (Upgrade:websocket)

在看一下 ws 协议下的每帧数据组成：

每帧数据都包含 2byte 的头信息。
FIN 表示是否为最后一帧
RSV1/2/3 为扩展字段。客户端与服务器可以通过约定这几个字段的值实现协议上的附加操作， 比如是否开启数据压缩。
OP Code 为每一帧的操作类型。 比如当前帧是操作帧还是数据帧
MASK 0/1 表示是否设置了掩码
LENGTH 为数据包长度

在 2byte 头信息之后带上整个帧的真实数据。

Http2 协议

下一代 http 协议。 解决了诸多 http 下的问题， 被越来越广泛的应用。 我总结的也不太好， 详细参见另一篇博客HTTP 2.0的那些事

App 下的理想网络模型特点

App 的网络场景要比 pc 上复杂很多， 也不稳定的多。 对于 app 来说， 理想的网络模型特点应该要有：

• 低延时
• 安全
• 双向数据通道

在不同的场景下使用不同的工具去解决问题， 重点是要熟悉每种协议的特点，以及如何使用。

广告： 基于 OkHttp 实现的网络工具库BJNetwork