OkHttp 系列一：OkHttp 基本介绍

WAsbry
420 阅读5分钟

OkHttp 基本介绍

  • 本文概述：

    • 文章以OkHttp 4.9.3 为例介绍了请求压缩技术，缓存技术，重点介绍了对不同版本的Http 协议OkHttp 所做的适配调整；

OkHttp是什么：

  • 由Square公司贡献的一个处理网络请求的开源项目，是目前Android使用最广泛的网络框架。从Android4.4开始 HttpURLConnection的底层实现采用的是OkHttp

  • 不同版本说明：

    • 从OkHttp 4.X 起框架源码采用Kotlin 编写，之前版本均采用Java 编写
    • 但OkHttp 不同版本的整体架构与思想是相同的

OkHttp 与 Retrofit 的联系

  • 二者均由同一家公司研发并开源

  • Retrofit 是对OkHttp 的二次封装：使其更加易用

    • Retrofit 并没有网络请求的能力，需要借助与OkHttp

    • Retrofit 在 OkHttp 的基础上增加了线程切换、转化器、适配器

      • 实现数据(JSON,PROB)的序列化、反序列化

基本介绍：

  • 支持Http2.0并允许对同一主机(域名)的所有请求共有一个套接字

  • 对于Http 1.X 通过连接池，减少了请求延迟

  • 默认通过GZip 压缩数据

    • 允许服务端使用GZip 将响应数据压缩后再回传给客户端;
    • 压缩目的：为了让数据量更小，节省处理时间

  • 响应缓存：避免重复的网络请求

    • 业务场景：比如需要去请求一份，基本不会更改的数据

    • 业务逻辑：请求后缓存一份，

    • 需要注意：缓存要符合Http 规范

      • 种类：强制缓存、协商缓存
      • 通过CacheIntercept 进行处理的

    • OkHttp 缓存默认关闭

      • 只支持Get 请求对应的响应缓存

      • 是可以打开的：在实例化OkHttp 的时候配置一下Cache 即可

        • 指定缓存存放的位置路径，缓存大小
        • 打开后，OkHttp 在满足条件时会使用缓存的

  • 请求失败自动重试主机的其他ip ，自动重定向

连接池：兼容Http 1.X

  • Http 1.X 的限制：支持不同请求使用同一个Socket 但是需要保证请求时串形且有序的

  • 连接池是什么：就是一个对象池；

  • 连接池中装的是什么：存放针对不同ip 已经建立好但是没有使用的有效链接对象

  • 有效链接对象是什么：已经向特定网站完成了DNS 解析、TCP 链接建立后的对象；

  • 此时的业务逻辑是什么：

    • 在需要向目标主机发起Http 请求之前，先去查询连接池中有没有现成的对象
    • 有，直接拿过来，开始传输Http 报文

HTTP 2.0 协议：支持数据并行传输

  • 头部压缩：节省资源、提高效率

    • 支持对请求头压缩，使得数据量减少

  • 服务器推送：完善通信链路的双工性

    • 在Http 2.0 之前，只有在客户端发起请求且服务端接收到消息后，服务端才能回传数据
    • 服务端不能主动向客户端推送消息

  • 多路复用：实现数据并行传输

    • 引入二进制数据帧与流的概念，使得不同Http 请求可以并行传输且使用同一Sokect/管道

Http 请求过程：通过域名找到服务器

  • 为什么会出现域名：解决ip 地址记忆困难

    • 主机是由ip 进行标识的

  • 第一步：DNS 解析

    • 域名 ---> ip 地址

  • 第二步：TCP 链接建立(三次握手)

    • 同指定ip 地址建立TCP/IP （Socket）

  • 第三步：构建报文

    • 数据编码成Http 报文，采用Socket 的outPutToString 送到服务端

  • 第四步：响应请求

    • 服务端处理Http 报文并向客户端回传响应
    • 例如：当服务端为浏览器：数据解析、页面渲染

  • 第五步：TCP 链接释放(四次挥手)

Http 请求过程实例

  • 在Http 1.1：引入Keep - Alive(长连接)，并且默认开启

  • 例如使用工具向百度发起Http 请求

    • 业务需求：希望建立长连接

    • 请求头：键值对

      • Key：Connection
      • Value：keep - alive

    • 响应头：包含同样的键值对，表示服务端允许存在长连接

  • 客户端发起长连接请求是不一定会成功的，需要去看服务端的响应头

  • 客户端不希望与服务端建立长连接

    • 客户端请求头：<Connection,close>

  • 服务端不希望与客户端建立长连接：比如去请求高德地图的开发接口

    • 服务端响应头：<Connection,close>

  • 当长连接建立后，第二次链接，直接快进到 ---> 发起Http 请求报文

    • 节省了DNS 解析，与TCP 链接建立，加快了效率

Http 请求过程的优化

  • 传统请求(Http 1.0)的限制：不能重复使用Sokect 业务场景：连续多次请求同一主机

    • 解决手段：在Http 1.1引入长连接并默认开启

  • 长连接的好处：节省资源、提升效率

    • 节省了重复的DNS 解析以及TCP 链接建立操作

  • 长连接的弊端：Http 1.1 的限制 + 业务限制

    • Http 1.1 的限制(请求与响应均需要串形与有序)

      • 还没有得到请求响应是不能发起第二个请求的

      • Http 1.X 的数据(请求与响应)均是基于文本(字符串)格式，那么意味着所有的数据均需要按照顺序传

        • 因为此时接收端并不知道数据应该是什么样子
    • 业务限制：针对的是多次请求同一主机
    • 解决手段：在Http 2.0 引入多路复用技术

  • 多路复用技术：实现数据并行传输

    • 引入二进制数据帧与流的概念，使得不同Http 请求可以并行传输且使用同一Sokect/管道

    • 原理：数据帧中包含原始数据的顺序标识

    • 举例说明：

      • Http 1.X 数据传输示意

         //原始数据信息
 W o r l d
 //客户端向服务端发送的数据信息
 W o r l d
 //服务端接收到的数据信息
 W o r l d

      • Http 2.0 数据传输示意

         //原始数据信息
 W o r l d
 1 2 3 4 5 //原始数据标识
     
 //客户端向服务端发送的数据信息
 r w o d l
 3 1 2 5 4
 ​
 //服务端接收到的数据信息(根据数据标识进行整理)
 W o r l d

\

avatar
文章
阅读
粉丝