888888888.png
网络和安全机制
888888888.png
1.网络框架对比和源码分析
Volley
特点：
- 基于 HttpURLConnection
- 封装Url图片加载框架，支持图片加载
- 有缓存
- Activity和生命周期的联动，Activity结束时取消在此Activity中调用的所有网络请求
场景：
- 适合传输量小，数据请求频繁的的场景
- 不能进行大量数据操作，如上传下载，因为Volley的Request和Response放到byte[]中
OkHttp
特点：
- 基于 NIO 和 Okio，请求处理速度更快
- IO 是阻塞式；NIO是非阻塞式；Okio （Square）基于二者的更高效的数据流库
IO 面向流 Steam，NIO 面向缓冲区 Buffer IO 阻塞，NIO 非阻塞
NIO情况下，一个线程可以处理多个通道的读取和写入，更充分的利用线程资源。
适用场景
-
IO适合于链接数量不大,但是每个链接需要发送/接收的数据量很大,需要长时间连续处理;
-
NIO更适合于同时存在海量链接,但是每个链接单次发送/接收的数据量较小的情形.比如聊天服务器.海量链接但是单个链接单次数据较小
888888888.png
Retrofit
特点：
•基于OkHttp
•通过注解配置请求
•性能最好，处理最快
•解析数据需要使用统一的Convert
•易与其他框架RxJava联合使用
场景：
•优先使用，项目中由 RxJava ，后台 API 遵循 Restful 风格
2.自己去设计网络请求框架，怎么做？
888888888.png
d5371aa715d99e26.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
•网络配置层 重定向 Header拼接层 Http缓存层 链接层 数据响应层
•OkHttpClient Call Request RequsetBody Response ResponseBody Interceptor StreamAllocation RouteSelector RouteDatabase
Dispatcher是一个任务调度器，它内部维护了三个双端队列：
888888888.png
Interceptor将网络请求、缓存、透明压缩等功能统一了起来，它的实现采用责任链模式，各司其职， 每个功能都是一个Interceptor，上一级处理完成以后传递给下一级，它们最后连接成了一个Interceptor.Chain。它们的功能如下：
888888888.png
BridgeInterceptor方法主要是针对Header做了一些处理，这里主要提一下"Accept-Encoding", "gzip"，关于它有以下几点需要注意：
888888888.png
ConnectInterceptor用来完成连接。而真正的连接在RealConnect中实现，连接由连接池ConnectPool来管理，连接池最多保 持5个地址的连接keep-alive，每个keep-alive时长为5分钟，并有异步线程清理无效的连接。
整个流程如下：
888888888.png
Expires Http 1.0 绝对过期时间
Cache-Control Http 1.1 相对过期时间
If-Modified-Since 请求 header
Last-Modified 响应 header 作为下次的 If-Modified-Since
If-None-Match 请求 header
ETag 响应 header 作为下次的 If-None-Match
3.网络请求缓存处理，okhttp如何处理网络缓存的
CacheInterceptor
OKHttp3(支持Retrofit)的网络数据缓存Interceptor拦截器
888888888.png
4.从网络加载一个10M的图片，说下注意事项
Bitmap.Options inJustDecodeBounds inSampleSize
ARGB_4444 RGB_565
补图
分块加载
使用LruCache
sizeOf()、entryRemoved()
手势处理
ScaleGestureDetector GestureDetector
前者用于处理缩放手势，后者用于处理其余手势，如移动，快速滑动，点击，双击，长按等。
ScaleGestureDetector专门处理缩放手势，其比较重要的方法是onScale(ScaleGestureDetector detector)，当缩放时会不停地回调这个方法，需要注意的一点是detector.getScaleFactor()获取到的缩放比例是相对上一次的
5.TCP的3次握手和四次挥手
SYN--SYN ACK-ACK
888888888.png
FIN--ACK--FIN-ACK
【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？ 答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
6.TCP与UDP的区别
888888888.png
7.TCP与UDP的应用
区别
面向连接VS无连接
TCP建立一个连接需要3次握手IP数据包，断开连接需要4次握手。 另外断开连接时发起方可能进入TIME_WAIT状态长达数分钟（视系统设置，windows一般为120秒），在此状态下连接（端口）无法被释放。 UDP不需要建立连接，可以直接发起。
可靠VS不可靠
888888888.png
888888888.png
面向报文
面向报文的传输方式是应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。
因此，应用程序必须选择合适大小的报文。若报文太长，则IP层需要分片。
UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。
这也就是说，应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。（一个upd的最大报文长度2^16-1-20-8，20是ip报文头，8是udp报文头）
面向字节流
面向字节流的话，虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序看成是一连串的无结构的字节流。
TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。
如果应用程序一次只发送一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去。
tcp有流量控制，udp没有
tcp的头部比20bytes，udp8byres
TCP应用场景：
效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。
举几个例子：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。
UDP应用场景：
效率要求相对高，对准确性要求相对低的场景。
举几个例子：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）。
8.HTTP协议
9.HTTP1.0与2.0的区别
888888888.png
带宽：出视频应用以外，带宽基本不是问题
延迟： 浏览器阻塞 HOL Blocking DNS查询 DNS Lookup 建立连接 Initial Connection
Http1.0 & 1.1
888888888.png
2012 google SPDY
888888888.png
HTTP 2.0 性能惊人
大约 4 倍
HTTP2.0和SPDY的区别：
HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS
888888888.png
<main class="container main-container" data-v-6a3e47cf="">
<article class="article" data-v-3c33b992="" itemtype="http://schema.org/Article" itemscope="itemscope">
网友评论