八、网络与安全机制

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的执行流程：

1. OkhttpClient 实现了Call.Fctory,负责为Request 创建 Call；
2. RealCall 为Call的具体实现，其enqueue() 异步请求接口通过Dispatcher()调度器利用ExcutorService实现，而最终进行网络请求时和同步的execute()接口一致，都是通过 getResponseWithInterceptorChain() 函数实现
3. getResponseWithInterceptorChain() 中利用 Interceptor 链条，责任链模式 分层实现缓存、透明压缩、网络 IO 等功能；最终将响应数据返回给用户。

源码分析地址： https://www.jianshu.com/p/cb444f49a777

6.4 从网络加载一个10M的图片，说下注意事项

我们首先获得目标View所需的大小，然后获得图片的大小，最后通过计算屏幕与图片的缩放比，按照缩放比来解析位图。

具体步骤如下：

1. 将BitmapFactory.Options的inJustDecodeBounds参数设为true并加载图片
2. 从BitmapFactory.Options中取出图片的原始宽高信息，他们对应于outWidth和outHeight参数
3. 根据采样率的规律并结合目标View的所需大小计算出采样率inSampleSize
4. 将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 不保证

详细介绍：

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响应包括:响应行、响应头、响应体

详细介绍：

HTTP1.0与HTTP 1.1的主要区别 

1. 长连接
2. 节约带宽
3. HOST域

HTTP1.1与HTTP 2.0的主要区别 

1. 多路复用
2. 二进制分帧
3. 首部压缩
4. 服务器推送
5. 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可以有效的防止运营商劫持，解决了防劫持的一个大问题。

网络安全学习路线

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

同时每个成长路线对应的板块都有配套的视频提供：

需要网络安全学习路线和视频教程的可以在评论区留言哦~

最后

• 如果你确实想自学的话，我可以把我自己整理收藏的这些教程分享给你，里面不仅有web安全，还有渗透测试等等内容，包含电子书、面试题、pdf文档、视频以及相关的课件笔记，我都已经学过了，都可以免费分享给大家！

给小伙伴们的意见是想清楚，自学网络安全没有捷径，相比而言系统的网络安全是最节省成本的方式，因为能够帮你节省大量的时间和精力成本。坚持住，既然已经走到这条路上，虽然前途看似困难重重，只要咬牙坚持，最终会收到你想要的效果。

黑客工具&SRC技术文档&PDF书籍&web安全等（可分享）

结语

网络安全产业就像一个江湖，各色人等聚集。相对于欧美国家基础扎实（懂加密、会防护、能挖洞、擅工程）的众多名门正派，我国的人才更多的属于旁门左道（很多白帽子可能会不服气），因此在未来的人才培养和建设上，需要调整结构，鼓励更多的人去做“正向”的、结合“业务”与“数据”、“自动化”的“体系、建设”，才能解人才之渴，真正的为社会全面互联网化提供安全保障。

特别声明：
此教程为纯技术分享！本教程的目的决不是为那些怀有不良动机的人提供及技术支持！也不承担因为技术被滥用所产生的连带责任！本教程的目的在于最大限度地唤醒大家对网络安全的重视，并采取相应的安全措施，从而减少由网络安全而带来的经济损失