android请求网络,android原生网络请求

Android网络请求知识（三）授权，TCP/IP，HTTPS建立过程

由身份或持有的令牌确认享有的权限，登录过程实质上的目的也是为了确认权限。

Cookie是客户端给服务器用的，setCookie是服务器给客户端用的。cookie由服务器处理，客户端负责存储

客户端发送cookie：账户和密码

服务端收到后确认登录setCookie：sessionID=1，记下sessionID

客户端收到sessionID后记录，以后请求服务端带上对比记录下sessionID，说明已经登录

会话管理：登录状态，购物车

个性化：用户偏好，主题

Tracking：分析用户行为

XXS：跨脚本攻击，及使用JavaScript拿到浏览器的cookie之后，发送到自己的网站，以这种方式来盗用用户Cookie。Server在发送Cookie时，敏感的Cookie加上HttpOnly，这样Cookie只能用于http请求，不能被JavaScript调用

XSRF:跨站请求伪造。Referer 从哪个网站跳转过来

两种方式：Basic和Bearer

首先第三方网站向授权网站申请第三方授权合作，拿到授权方颁发的client_id和client_secret（一般都是appid+appkey的方式）。

在这就过程中申请的client_secret是服务器持有的，安全起见不能给客户端，用服务端去和授权方获取用户信息，再传给客户端，包括④，⑤的请求过程也是需要加密的。这才是标准的授权过程。

有了access_token之后，就可以向授权方发送请求来获取用户信息

步骤分析就是上面的内容，这里把第4,6,8请求的参数分析一下

第④步参数：

response_type：指授权类型，必选，这里填固定值‘code’

client_id：指客户端id，必选，这里填在平台报备时获取的appid

redirect_uri：指重定向URI，可选

scope：指申请的权限范围，可选

state：指客户端当前状态，可选，若填了，则认证服务器会原样返回该值

第⑥步参数：

grant_type：指使用哪种授权模式，必选，这里填固定值‘authorization_code’

code：指从第⑤步获取的code，必选

redirect_uri：指重定向URI，必选，这个值需要和第④步中的redirect_uri保持一致

client_id：指客户端id，必选，这里填在平台报备时获取的appid

client_secret：指客户端密钥，必选，这里填在平台报备时获取的appkey

第⑧步参数：

access_token：指访问令牌，必选，这里填第⑦步获取的access_token

token_type：指令牌类型，必选，大小写不敏感，bearer类型 / mac类型

expires_in：指过期时间，单位秒，当其他地方已设置过期时间，此处可省略该参数

refresh_token：指更新令牌，可选，用即将过期token换取新token

scope：指权限范围，可选，第④步中若已申请过某权限，此处可省略该参数

我们在上面的第八步中会有refresh_token的参数，这个在实际操作中也比较常见

有时候我们在自己的项目中，将登陆和授权设计成类似OAuth2的过程，不过去掉Authorization code。登陆成功返回access_token，然后客户端再请求时，带上access_token。

我们常常会说到TCP/IP，那到底是什么呢。这就需要讲到网络分层模型。TCP在传输层，IP在网络层。那为什么需要分层？因为网络不稳定，导致需要重传的问题。为了提高传输效率我们就需要分块，在传输层中就会进行分块。TCP还有两个重要的内容就是三次握手，四次分手。

HTTPS 协议是由 HTTP 加上TLS/SSL协议构建的可进行加密传输、身份认证的网络协议，主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护

1.客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件列表（所使用的加密算法及密钥长度），客户端随机数，hash算法。

2.服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件，服务端随机数。服务器的加密组件内容是从接收到客户端加密组件内筛选出来的。

3.之后服务器发送Certificate报文。报文中包含公开密钥证书。一般实际有三层证书嵌套，其实像下面图二直接用根证书机构签名也是可以的，但是一般根证书机构比较忙，需要类似中介的证书机构来帮助。

4.最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。

5.SSL第一次握手结束后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密。

6.接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密。

7.客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密报文作为判定标准。

8.服务器同样发送Change Cipher Spec报文。

9.服务器同样发送Finished报文。

10.服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP响应。

11.应用层协议通信，即发送HTTP响应。

12.最后由客户端断开连接。断开连接时，发送close_notify报文。这步之后再发送TCP FIN报文来关闭与TCP的通信。

利用客户端随机数，服务端随机数，per-master secret随机数生成master secret，再生成客户端加密密钥，服务端加密密钥，客户端MAC secert，服务端MAC secert。MAC secert用于做报文摘要，这样能够查知报文是否遭到篡改，从而保护报文的完整性。

Android网络请求知识（一）HTTP基础概念

Android网络请求知识（二）对称和非对称加密、数字签名，Hash，Base64编码

Android网络请求知识（三）授权，TCP/IP，HTTPS建立过程

相关问答

Q1: Android 9.0 无法请求网络问题

手机版本升级到9.0后，发现App一直请求网络失败，特奇怪...以为是手机出毛病了，后来发现原来是android 9.0系统已经默认不支持http请求了，这个可以让后台改成https就行，不过我们还是没解决我们移动端的问题。目前有两个方法处理：

1.把targetSdkVersion 改成27或者以下

2.在res目录添加一个xml文件夹和network_security_config.xml：

xml内容是：

然后再在AndroidManifest.xml的application里加入

这样就行了。

Q2: Android网络请求库【OkHttp4.9.3】基本用法与原理分析

OkHttp是一套处理 HTTP 网络请求的依赖库，由 Square 公司设计研发并开源，目前可以在 Java 和 Kotlin 中使用。对于 Android App 来说，OkHttp 现在几乎已经占据了所有的网络请求操作，Retrofit + OkHttp实现网络请求似乎成了一种标配。因此它也是每一个 Android 开发工程师的必备技能，了解其内部实现原理可以更好地进行功能扩展、封装以及优化。

OkHttp的高效性体现在：

第一步：创建OkHttpClient，创建OkHttpClient有两种方式：

OkHttpClient提供了丰富的配置方法，例如添加拦截器、指定连接池、设置请求超时等等。

第二步：创建请求

使用Request.Builder() 构建Request实例

第三步：发起网络请求

OkHttp支持同步和异步两种请求方式

OkHttp的使用方法非常简单，三步操作就可以发起一个简单的同步或异步请求。我们也可以很轻松地对网络请求进行配置，例如添加请求头、设置请求方式、设置请求超时等等，这些配置参数会在源码分析过程中详细介绍。

现在我们已经学会了三步操作发起网络请求，接下来以这三个步骤为切入点，深入到源码中学习OkHttp的实现原理，废话少说马上开车。

OkHttpClient创建方式有两种，我们看看两种方式有什么区别。

第一种直接使用默认构造函数，内部依然是使用建造者模式

第二种使用建造者模式

两种方式最终都是调用构造函数OkHttpClient(builder:Builder)，由参数builder负责所有的参数配置工作。

当您创建单个OkHttpClient实例并将其用于所有 HTTP 调用时，OkHttp 性能最佳。 这是因为每个OkHttpClient都拥有自己的连接池和线程池，重用连接和线程可减少延迟并节省内存。 相反，为每个请求创建一个客户端会浪费空闲池上的资源。

Request同样使用建造者模式来创建，这里贴上部分重要源码，很简单就不细说了。

OkHttp发起网络请求分为同步请求和异步请求两种方式，我们只分析异步请求流程，因为只要理解了异步请求过程，基本上也就明白同步请求是怎么一回事了。

RealCall是连接应用层与网络层的桥梁，负责处理连接、请求、响应和数据流。

Dispatcher维护着一套异步任务执行策略，分析策略之前先介绍几个重要概念：

client.dispatcher.enqueue(AsyncCall(responseCallback)) 执行步骤为：

AsyncCall实现了Runnable接口，因此一旦被线程池中的线程处理就会调用它的run()方法：

话休絮烦，我们开始分析拦截器责任链：

责任链执行流程：首先获取当前拦截器interceptor，并且调用interceptor.intercept(next)执行拦截器操作。这里的next表示的是index+1后的责任链对象，拦截器的intercept()方法内部会调用next.proceed(request)方法再次进入到责任链，由于此时index已经加1，所以处理的是下一个拦截器。

如此循环往复，直到处理完责任链上最后一个拦截器为止。

注意除最后一个拦截器CallServerInterceptor不会调用chain.proceed(request)方法之外，其他拦截器都应该至少调用一次chain.proceed(request)方法。

为了验证上面的结论，我们进入到RetryAndFollowUpInterceptor的intercept()方法一探究竟：

可以看到注释1处重新进入责任链处理下一个拦截器。

有兴趣可以自行查看最后一个拦截器CallServerInterceptor源码，此处只给出本人阅读源码后得出的结论：

以上就是拦截器责任链的工作流程，我们再通过流程图仔细感受一下。

分析完拦截器责任链，我们继续分析AsyncCall#run()方法：

我们看到，如果getResponseWithInterceptorChain()方法成功获得服务端返回的数据，则调用responseCallback.onResponse(this@RealCall, response)方法完成异步回调；如果服务端数据获取失败（请求异常），则调用responseCallback.onFailure(this@RealCall, canceledException)方法完成异步回调

需要注意的是，responseCallback回调是在子线程中完成的，所以如果想把数据显示到UI上，需要切换回主线程进行UI操作。

OkHttp发起网络请求全过程：

【知识点】OkHttp 原理 8 连问