Android面试题（六）2网络与安全机制(1)
八、网络与安全机制
6.1 网络框架对比
volley：
- 功能
基于HttpUrlConnection;封装了UIL图片加载框架，支持图片加载;网络请求的排序、优先级处理缓存;多级别取消请求;Activity和生命周期的联动（Activity结束生命周期同时取消所有网络请求
- 性能
可拓展性好;可支持HttpClient、httpUrlConnection、和okhttp
- 开发者使用
封装行好，简单易用
- 应用场景
合轻量级网络交互：网络请求频繁，传输数据量小;不能进行大数据量的网络操作，比如音频下载文件传输
- 备注
Volley的request和response都是把数据放到byte数组里，不支持输入输出流，把数据放到数组中，如果文件多了，数组就会大，消耗内存
okhttp：
- 功能
高性能Http请求库;可以把它理解成是一个封装之后类似HttpUrlConnection的一个东西，属于同级别并不是基于前者;支持SPDY，共享同一个Socket来处理同一个服务器所有的请求;支持http2.0、websocket;支持同步、异步;封装了线程池、数据转换、参数使用、错误处理等;无缝的支持GZIP来减少数据流量;缓存响应数据来减少重复的网络请求;能从很多常用的连接问题中自动恢复;解决了代理服务器问题和SSL握手失败问题
- 性能
基于NIO和OKio,所以性能更高，请求、处理速度快（io:阻塞式；NIO:非阻塞式；）
- 开发者使用
api调用简单方便；使用需要多封装一层
- 应用场景
重量级网络交互场景：网络请求频繁，传输数据量大
- 备注
Android4.4源码中，HttpUrlConnection已经替换成OkHttp
retrofit：
- 功能
RESRful Api设计风格;支持同步、异步;通过注解配置请求;包括请求方法、请求参数、请求头、返回值等;可以搭配多种Converter将获得的数据解析&序列化;支持Gson(默认)、Jackson、Protobuf等;提供对RxJava的支持
- 性能
简单易用;代码简化;解耦彻底，职责细分;易与和rxjava使用;使用方法较多，原理复杂，
- 开发者使用
简单易用；代码简化；解耦彻底，职责细分；易与和rxjava使用；使用方法较多，原理复杂
- 应用场景
重量级网络交互场景：网络请求频繁，传输数据量大
- 备注
Android4.4源码中，HttpUrlConnection已经替换成OkHttp
6.2 android 设计一个简易的Http网络请求框架
最近项目中需要用到版本升级这一块，需要用到一些基本的数据请求与文件下载功能。之前做项目都是用别人的网络框架，类似retrofit 、 okhttp、 fresco等框架，用的多了，发现这几个网络请求框架，无非都是
按解决以下几个问题为导向的：
1.怎么发请求？
2.Cookie的问题。
3.如何停止请求（好像上面提到的几个框架没有停止请求的概念，因为停止请求常用用SOcket长连接协议中，而http是短连接，只要触发了请求，就失去了控制一样。）
4.请求的并发？
5.如何管理请求的优先级（类似http这种协议请求，几乎可以忽略，请求的优先级常用于socket协议中）
6.3 OkHttp源码分析
简述okhttp的执行流程：
- OkhttpClient 实现了Call.Fctory,负责为Request 创建 Call；
- RealCall 为Call的具体实现，其enqueue() 异步请求接口通过Dispatcher()调度器利用ExcutorService实现，而最终进行网络请求时和同步的execute()接口一致，都是通过 getResponseWithInterceptorChain() 函数实现
- getResponseWithInterceptorChain() 中利用 Interceptor 链条，责任链模式 分层实现缓存、透明压缩、网络 IO 等功能；最终将响应数据返回给用户。
源码分析地址：https://www.jianshu.com/p/cb444f49a777
6.4 从网络加载一个10M的图片，说下注意事项
我们首先获得目标View所需的大小，然后获得图片的大小，最后通过计算屏幕与图片的缩放比，按照缩放比来解析位图。
具体步骤如下：
- 将BitmapFactory.Options的inJustDecodeBounds参数设为true并加载图片
- 从BitmapFactory.Options中取出图片的原始宽高信息，他们对应于outWidth和outHeight参数
- 根据采样率的规律并结合目标View的所需大小计算出采样率inSampleSize
- 将BitmapFactory.Options的inJustDecodeBounds参数设为false,然后重新加载图片
两个方法比较重要，在这里我们进行解析：
options.inJustDecodeBounds：如果给它赋值true，那么它就不会解析图片。使用它的目的是为了获得图片的一些信息，如图片高度和宽度，然后进行下一步工作，也就是计算缩放比。将options.inJustDecodeBounds设置为false，将会加载图片。
options.inSampleSize ：给图片赋予缩放比，当它的值大于1的时候，它就会按照缩放比返回一个小图片用来节省内存。
除了因为图片大小自身的原因之外，还有Android对图片解码的因素在内。
在Android中使用ARGB来展示颜色的，一般情况下使用的是ARGB_8888，每个像素的大小约为4byte。如果对质量不做太大要求，可以使用ARGB_4444或者RGB_565，他们都是2个字节的。
如果图片涉及到放大功能，则也需要注意以下事项：
1.图片分块加载：
图片的分块加载在地图绘制的情况上最为明显，当想获取一张尺寸很大的图片的某一小块区域时，就用到了图片的分块加载，在Android中BitmapRegionDecoder类的功能就是加载一张图片的指定区域。BitmapRegionDecoder类的使用非常简单，API很少并且一目了然，如下：
（1）创建BitmapRegionDecoder实例
（2）获取图片宽高
（3）加载特定区域内的原始精度的Bitmap对象
（4）调用BitmapRegionDecoder类中的recycle（）,回收释放Native层内
2.使用LruCache
继承并使用LruCache，利用其来缓存加载过的图片区域，需要重写一些方法，如sizeOf()、entryRemoved（）等
其中sizeOf()用于处理获取缓存对象的大小，比如缓存Bitmap对象时，可以使用Bitmap的字节数作为Bitmap大小的表示。
entryRemoved()用于回收某个对象时调用，这样当回收Bitmap对象时可以调用Bitmap对象的recycle()方法主动释放Bitmap对象的内存。
3.手势处理：
主要用到两个手势处理类，分别是ScaleGestureDetector和GestureDetector，前者用于处理缩放手势，后者用于处理其余手势，如移动，快速滑动，点击，双击，长按等。
ScaleGestureDetector专门处理缩放手势，其比较重要的方法是onScale(ScaleGestureDetector detector)，当缩放时会不停地回调这个方法，需要注意的一点是detector.getScaleFactor()获取到的缩放比例是相对上一次的
6.5 TCP的3次握手和四次挥手
三次握手过程理解
第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
四次挥手过程理解
1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
常见面试题
【问题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报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
【问题3】为什么不能用两次握手进行连接？
答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
【问题4】如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
6.5 TCP和UDP
1）TCP与UDP的区别
- TCP 是面向连接的，UDP 是面向无连接的
- UDP程序结构较简单
- TCP 是面向字节流的，UDP 是基于数据报的
- TCP 保证数据正确性，UDP 可能丢包
- TCP 保证数据顺序，UDP 不保证
详细介绍：https://blog.csdn.net/zhang6223284/article/details/81414149
2）TCP与UDP的应用
- TCP应用场景
当对网络通信质量有要求时，比如：整个数据要准确无误的传递给对方，这往往对于一些要求可靠的应用，比如HTTP,HTTPS,FTP等传输文件的协议，POP,SMTP等邮件的传输协议。常见使用TCP协议的应用：
1.浏览器使用的：HHTP
2.FlashFXP:FTP
3.Outlook:POP，SMTP
4.QQ文件传输
- UDP 文件传输协议应用场景
对当前网络通讯质量要求不高的时候，要求网络通讯速度尽量的快，这时就使用UDP
日常生活中常见使用UDP协议：
1.QQ语音
2.QQ视频
3.TFTP
6.6 HTTP协议
超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。1960年美国人Ted Nelson构思了一种通过计算机处理文本信息的方法，并称之为超文本（hypertext）,这成为了HTTP超文本传输协议标准架构的发展根基。Ted Nelson组织协调万维网协会（World Wide Web Consortium）和互联网工程工作小组（Internet Engineering Task Force ）共同合作研究，最终发布了一系列的RFC，其中著名的RFC 2616定义了HTTP 1.1。
http协议的作用及特点
HTTP是一个客户端和服务器端请求和应答的标准（TCP）。客户端是终端用户，服务器端是网站。通过使用Web浏览器、网络爬虫或者其它的工具，客户端发起一个到服务器上指定端口（默认端口为80）的HTTP请求。（我们称这个客户端）叫用户代理（user agent）。应答的服务器上存储着（一些）资源，比如HTML文件和图像。（我们称）这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个中间层，比如代理，网关，或者隧道（tunnels）。尽管TCP/IP协议是互联网上最流行的应用，HTTP协议并没有规定必须使用它和（基于）它支持的层。 事实上，HTTP可以在任何其他互联网协议上，或者在其他网络上实现。HTTP只假定（其下层协议提供）可靠的传输，任何能够提供这种保证的协议都可以被其使用。
通常，由HTTP客户端发起一个请求，建立一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端发送过来的请求。一旦收到请求，服务器（向客户端）发回一个状态行，比如"HTTP/1.1 200 OK"，和（响应的）消息，消息的消息体可能是请求的文件、错误消息、或者其它一些信息。HTTP使用TCP而不是UDP的原因在于（打开）一个网页必须传送很多数据，而TCP协议提供传输控制，按顺序组织数据，和错误纠正。
通过HTTP或者HTTPS协议请求的资源由统一资源标示符（Uniform Resource Identifiers）（或者，更准确一些，URLs）来标识。
1.基于请求/响应模型的协议。请求和响应必须成对，先有请求后有响应
2.http协议默认端口:80
3.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
4.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
5.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
6.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
协议功能
HTTP协议（HyperText Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传输协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。
HTTP是客户端浏览器或其他程序与Web服务器之间的应用层通信协议。在Internet上的Web服务器上存放的都是超文本信息，客户机需要通过HTTP协议传输所要访问的超文本信息。HTTP包含命令和传输信息，不仅可用于Web访问，也可以用于其他因特网/内联网应用系统之间的通信，从而实现各类应用资源超媒体访问的集成。
我们在浏览器的地址栏里输入的网站地址叫做URL (Uniform Resource Locator，统一资源定位符)。就像每家每户都有一个门牌地址一样，每个网页也都有一个Internet地址。当你在浏览器的地址框中输入一个URL或是单击一个超级链接时，URL就确定了要浏览的地址。浏览器通过超文本传输协议(HTTP)，将Web服务器上站点的网页代码提取出来，并翻译成漂亮的网页。
http协议的版本
HTTP/1.0,发送请求，创建一次连接，获得一个web资源，连接断开
HTTP/1.1，发送请求，创建一次连接，获得多个web资源，连接断开
Http协议的组成
Http协议由Http请求和Http响应组成，当在浏览器中输入网址访问某个网站时， 你的浏览器会将你的请求封装成一个Http请求发送给服务器站点，服务器接收到请 求后会组织响应数据封装成一个Http响应返回给浏览器。即没有请求就没有响应。
http请求包括:请求行、请求头、请求体
http响应包括:响应行、响应头、响应体
详细介绍：https://blog.csdn.net/weixin_38087538/article/details/82838762
HTTP1.0与HTTP 1.1的主要区别
- 长连接
- 节约带宽
- HOST域
HTTP1.1与HTTP 2.0的主要区别
- 多路复用
- 二进制分帧
- 首部压缩
- 服务器推送
- HTTP2.0只适用于HTTPS的场景
HTTPS是在HTTP和TCP之间增加了一层SSL，即secure socket layer，增加了数据安全传输及客户端和服务器端的身份验证，而HTTP2.0只适用于HTTPS的场景
6.7 HTTP与HTTPS的区别以及如何实现安全性
HTTPS(Secure Hypertext Transfer Protocol)安全超文本传输协议 它是一个安全通信通道，它基于HTTP开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版,是使用 TLS/SSL 加密的 HTTP 协议。
HTTP 协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险，而协议 TLS/SSL 具有身份验证、信息加密和完整性校验的功能，可以避免此类问题。
TLS/SSL 全称安全传输层协议 Transport Layer Security, 是介于 TCP 和 HTTP 之间的一层安全协议，不影响原有的 TCP 协议和 HTTP 协议，所以使用 HTTPS 基本上不需要对 HTTP 页面进行太多的改造
1.Url开头：HTTP 的 URL 以 HTTP:// 开头，而 HTTPS 的 URL 以 HTTPs:// 开头；
2.安全性：HTTP 是不安全的，而 HTTPS 是安全的。HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
3.传输效率：传输效率上 HTTP 要高于 HTTPS ，因为 HTTPS 需要经过加密过程，过程相比于 HTTP 要繁琐一点，效率上低一些也很正常；
4.费用：HTTP 无需证书，而 HTTPS 必需要认证证书；相比于 HTTP 不需要证书来说，使用 HTTPS 需要证书，申请证书是要费用的，HTTPS 这笔费用是无法避免的
5.端口：HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
6.防劫持性：HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。
HTTPS如何校验证书合法性：
//https://blog.csdn.net/jogger_ling/article/details/60576625