八、网络与安全机制
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的执行流程:
源码分析地址:https://www.jianshu.com/p/cb444f49a777
6.4 从网络加载一个10M的图片,说下注意事项
我们首先获得目标View所需的大小,然后获得图片的大小,最后通过计算屏幕与图片的缩放比,按照缩放比来解析位图。
具体步骤如下:
两个方法比较重要,在这里我们进行解析:
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的区别
详细介绍:https://blog.csdn.net/zhang6223284/article/details/81414149
2)TCP与UDP的应用
当对网络通信质量有要求时,比如:整个数据要准确无误的传递给对方,这往往对于一些要求可靠的应用,比如HTTP,HTTPS,FTP等传输文件的协议,POP,SMTP等邮件的传输协议。常见使用TCP协议的应用:
1.浏览器使用的:HHTP
2.FlashFXP:FTP
3.Outlook:POP,SMTP
4.QQ文件传输
对当前网络通讯质量要求不高的时候,要求网络通讯速度尽量的快,这时就使用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的主要区别
HTTP1.1与HTTP 2.0的主要区别
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