2020 Android 大厂面试(二)网络和安全机制 含 参考答案

2、网络和安全机制html

1.网络框架对比和源码分析
2.本身去设计网络请求框架,怎么作?
3.网络请求缓存处理,okhttp如何处理网络缓存的
4.从网络加载一个10M的图片,说下注意事项
5.TCP的3次握手和四次挥手
6.TCP与UDP的区别
7.TCP与UDP的应用
8.HTTP协议
9.HTTP1.0与2.0的区别
10.HTTP报文结构
11.HTTP与HTTPS的区别以及如何实现安全性
12.如何验证证书的合法性?
13.https中哪里用了对称加密,哪里用了非对称加密,对加密算法(如RSA)等是否有了解?
14.client如何肯定本身发送的消息被server收到?
15.谈谈你对WebSocket的理解
16.WebSocket与socket的区别
17.谈谈你对安卓签名的理解。
18.请解释安卓为啥要加签名机制?
19.视频加密传输
20.App 是如何沙箱化,为何要这么作?
21.权限管理系统(底层的权限是如何进行 grant 的)?
复制代码

参考答案:java

1.网络框架对比和源码分析

blog.csdn.net/github_3713…android

Volleygit

特色:github

  • 基于 HttpURLConnection
  • 封装Url图片加载框架,支持图片加载
  • 有缓存
  • Activity和生命周期的联动,Activity结束时取消在此Activity中调用的全部网络请求

场景:web

  • 适合传输量小,数据请求频繁的的场景
  • 不能进行大量数据操做,如上传下载,由于Volley的Request和Response放到byte[]中

OkHttp算法

特色:数据库

  • 基于 NIO 和 Okio,请求处理速度更快
  • IO 是阻塞式;NIO是非阻塞式;Okio (Square)基于两者的更高效的数据流库

IO 面向流 Steam,NIO 面向缓冲区 Buffer IO 阻塞,NIO 非阻塞segmentfault

NIO状况下,一个线程能够处理多个通道的读取和写入,更充分的利用线程资源。windows

适用场景

  • IO适合于连接数量不大,可是每一个连接须要发送/接收的数据量很大,须要长时间连续处理;

  • NIO更适合于同时存在海量连接,可是每一个连接单次发送/接收的数据量较小的情形.好比聊天服务器.海量连接可是单个连接单次数据较小

"Accept-Encoding","gzip" "Content-Encoding","gzip"

Content-Encoding: gzip:代表body是gzip过的数据
Content-Length:117:表示body gzip压缩后的数据大小,便于客户端使用。
Transfer-Encoding: chunked:分块传输编码
复制代码

Retrofit

特色:

  • 基于OkHttp
  • 经过注解配置请求
  • 性能最好,处理最快
  • 解析数据须要使用统一的Convert
  • 易与其余框架RxJava联合使用

场景:

  • 优先使用,项目中由 RxJava ,后台 API 遵循 Restful 风格

2.本身去设计网络请求框架,怎么作?

github.com/sucese/andr…

OkHttpClient okHttpClient = new OkHttpClient.Builder()
        .build();
Request request = new Request.Builder()
        .url(url)
        .build();
okHttpClient.newCall(request).enqueue(new Callback() {
    @Override
    public void onFailure(Call call, IOException e) {
    }

    @Override
    public void onResponse(Call call, Response response) throws IOException {

    }
});
复制代码

  • 网络配置层 重定向 Header拼接层 Http缓存层 连接层 数据响应层
  • OkHttpClient Call Request RequsetBody Response ResponseBody Interceptor StreamAllocation RouteSelector RouteDatabase

Dispatcher是一个任务调度器,它内部维护了三个双端队列:

readyAsyncCalls:准备运行的异步请求
runningAsyncCalls:正在运行的异步请求
runningSyncCalls:正在运行的同步请求
复制代码

Interceptor将网络请求、缓存、透明压缩等功能统一了起来,它的实现采用责任链模式,各司其职, 每一个功能都是一个Interceptor,上一级处理完成之后传递给下一级,它们最后链接成了一个Interceptor.Chain。它们的功能以下:

RetryAndFollowUpInterceptor:负责重定向。
BridgeInterceptor:负责把用户构造的请求转换为发送给服务器的请求,把服务器返回的响应转换为对用户友好的响应。
CacheInterceptor:负责读取缓存以及更新缓存。
ConnectInterceptor:负责与服务器创建链接。
CallServerInterceptor:负责从服务器读取响应的数据。
复制代码

BridgeInterceptor方法主要是针对Header作了一些处理,这里主要提一下"Accept-Encoding", "gzip",关于它有如下几点须要注意:

开发者没有添加Accept-Encoding时,自动添加Accept-Encoding: gzip
自动添加Accept-Encoding,会对request,response进行自动解压
手动添加Accept-Encoding,不负责解压缩
自动解压时移除Content-Length,因此上层Java代码想要contentLength时为-1
自动解压时移除Content-Encoding
自动解压时,若是是分块传输编码,Transfer-Encoding: chunked不受影响。
复制代码

CacheInterceptor

读取候选缓存,具体如何读取的咱们下面会讲。
建立缓存策略,强制缓存、对比缓存等,关于缓存策略咱们下面也会讲。
根据策略,不使用网络,又没有缓存的直接报错,并返回错误码504。
根据策略,不使用网络,有缓存的直接返回。
前面两个都没有返回,继续执行下一个Interceptor,即ConnectInterceptor。
接收到网络结果,若是响应code式304,则使用缓存,返回缓存结果。
读取网络结果。
对数据进行缓存。
返回网络读取的结果。
复制代码

ConnectInterceptor用来完成链接。而真正的链接在RealConnect中实现,链接由链接池ConnectPool来管理,链接池最多保 持5个地址的链接keep-alive,每一个keep-alive时长为5分钟,并有异步线程清理无效的链接。

整个流程以下:

查找是否有完整的链接可用:
    Socket没有关闭
    输入流没有关闭
    输出流没有关闭
    Http2链接没有关闭
链接池中是否有可用的链接,若是有则可用。
若是没有可用链接,则本身建立一个。
开始TCP链接以及TLS握手操做。
将新建立的链接加入链接池。
复制代码

cleanup()整个方法的流程以下所示:

查询此链接内部的StreanAllocation的引用数量。
标记空闲链接。
若是空闲链接超过5个或者keepalive时间大于5分钟,则将该链接清理掉。
返回此链接的到期时间,供下次进行清理。
所有都是活跃链接,5分钟时候再进行清理。
没有任何链接,跳出循环。
关闭链接,返回时间0,当即再次进行清理。
复制代码

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拦截器

读取候选缓存,具体如何读取的咱们下面会讲。
建立缓存策略,强制缓存、对比缓存等,关于缓存策略咱们下面也会讲。
根据策略,不使用网络,又没有缓存的直接报错,并返回错误码504。
根据策略,不使用网络,有缓存的直接返回。
前面两个都没有返回,继续执行下一个Interceptor,即ConnectInterceptor。
接收到网络结果,若是响应code式304,则使用缓存,返回缓存结果。
读取网络结果。
对数据进行缓存。
返回网络读取的结果。
复制代码

4.从网络加载一个10M的图片,说下注意事项

blog.csdn.net/github_3713…

Bitmap.Options inJustDecodeBounds inSampleSize

ARGB_4444 RGB_565

补图

分块加载

使用LruCache

sizeOf()、entryRemoved()

手势处理

ScaleGestureDetector GestureDetector

前者用于处理缩放手势,后者用于处理其他手势,如移动,快速滑动,点击,双击,长按等。

ScaleGestureDetector专门处理缩放手势,其比较重要的方法是onScale(ScaleGestureDetector detector),当缩放时会不停地回调这个方法,须要注意的一点是detector.getScaleFactor()获取到的缩放比例是相对上一次的

5.TCP的3次握手和四次挥手

blog.csdn.net/whuslei/art…

SYN--SYN ACK-ACK

SYN=1 seq=client_isn
SYN=1 seq=server_isn ack=client_isn+1
SYN=0 seq=client_isn+1 ack=server_isn+1

seq 为自身序列 ack 为对方序列+1
复制代码

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的区别

blog.fundebug.com/2019/03/22/…

UDP TCP
是否链接 无链接 面向链接
是否可靠 不可靠传输,不使用流量控制和拥塞控制 可靠传输,使用流量控制和拥塞控制
链接对象个数 支持一对一,一对多,多对一和多对多交互通讯 只能是一对一通讯
传输方式 面向报文 面向字节流
首部开销 首部开销小,仅8字节 首部最小20字节,最大60字节
适用场景 适用于实时应用(IP电话、视频会议、直播等) 适用于要求可靠传输的应用,例如文件传输

7.TCP与UDP的应用

blog.csdn.net/leewccc/art… www.cnblogs.com/liangyc/p/1…

TCP Transmission Contral Protocol UDP User Datagram Protocol

www.cnblogs.com/liangyc/p/1…

区别

面向链接VS无链接

TCP创建一个链接须要3次握手IP数据包,断开链接须要4次握手。 另外断开链接时发起方可能进入TIME_WAIT状态长达数分钟(视系统设置,windows通常为120秒),在此状态下链接(端口)没法被释放。 UDP不须要创建链接,能够直接发起。

可靠VS不可靠

TCP利用握手、ACK和重传机制,udp没有。
1,校验和(校验数据是否损坏);
2,定时器(分组丢失则重传);
3,序列号(用于检测丢失的分组和重复的分组);
4,确认应答ACK(接收方告知发送方正确接收分组以及指望的下一个分组);
5,否认确认(接收方通知发送方未被正确接收的分组);
6,窗口和流水线(用于增长信道的吞吐量)。(窗口大小:无需等待确认应答而能够继续发送数据的最大值)
复制代码

有序性

TCP利用seq序列号对包进行排序,udp没有。
复制代码

面向字节流vs面向报文

面向报文
    面向报文的传输方式是应用层交给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协议

hit-alibaba.github.io/interview/b…

juejin.im/post/5ad446…

9.HTTP1.0与2.0的区别

juejin.im/entry/5981c…

http 0.9 1991
http 1.0 1996
http 1.1 1999
http 2.0 2015
复制代码

带宽:出视频应用之外,带宽基本不是问题

延迟: 浏览器阻塞 HOL Blocking DNS查询 DNS Lookup 创建链接 Initial Connection

Http1.0 & 1.1

缓存处理
    HTTP1.0中主要使用header里的If-Modified-Since,Expires来作为缓存判断的标准
    HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match
    
带宽优化及网络链接的使用
    1.1 支持 range 206 Partial Content

错误通知的管理
    1.1 新增 24 个错误码,409 Conflict 410 Gone

Host头处理

长链接
    长链接 PersistentConnection
    流水线 Pipelining
复制代码

2012 google SPDY

下降延迟 多路复用 multiplexing 经过多个请求stream共享一个tcp连接
请求优先级 request prioritization
header压缩
基于https的加密传输
服务端推送 server push
复制代码

HTTP 2.0 性能惊人

http2.akamai.com/demo

大约 4 倍

HTTP2.0和SPDY的区别:

HTTP2.0 支持明文 HTTP 传输,而 SPDY 强制使用 HTTPS

HTTP2.0 消息头的压缩算法采用 HPACK http://http2.github.io/http2-spec/compression.html,
而非 SPDY 采用的 DEFLATE http://zh.wikipedia.org/wiki/DEFLATE
复制代码

10.HTTP报文结构

zhuanlan.zhihu.com/p/44938050

11.HTTP与HTTPS的区别以及如何实现安全性

blog.fundebug.com/2019/04/26/…

方法1. 对称加密

没有密钥就没法对密码解密,反过来讲,任何人只要持有密钥就能解密了。
复制代码

方法2. 非对称加密

私有密钥不能让其余任何人知道,而公开密钥则能够随意发布,任何人均可以得到。
复制代码

方法3. 对称加密+非对称加密(HTTPS采用这种方式)

在交换密钥环节使用非对称加密方式,以后的创建通讯交换报文阶段则使用对称加密方式。
发送密文的一方使用对方的公钥进行加密处理“对称的密钥”,而后对方用本身的私钥解密拿到“对称的密钥”,
这样能够确保交换的密钥是安全的前提下,使用对称加密方式进行通讯。
复制代码

12.如何验证证书的合法性?

yiqingfeng.github.io/2019/04/01/…

证书的安全性

  • 证书存在的目的就是避免中间人攻击,避免发生经典的传令兵问题
  • 由CA组织承认的根证书Root签发的
  • DV Digital Verification、OV Organization Verification、EV Extended Verification
  • 证书是须要预装的,特别是根证书。

证书的校验

  • 证书是否为值得信任的有效证书。是否为信任根(浏览器内置有信任的根证书)或信任根的二级证书机构颁发的。是否为信任根(浏览器内置有信任的根证书)或信任根的二级证书机构颁发的。
  • 对方是否持有证书对应的私钥。验证方式有两种:
    • 对方签名,浏览器用证书对签名进行验证。
    • 使用证书做为信封,判断对方是否可以解开。

校验证书是否已被吊销须要和 CA 关联,其余都可由浏览器完成。验证证书是否吊销能够采用CRL黑名单方式或者OCSP方式。

CRL黑名单就是按期从CA下载一个名单列表,里面有吊销的证书序列号,本身在本地比对一下就行。
优势是效率高。缺点是不实时。
OCSP是实时链接CA去验证,优势是实时,缺点是效率不高。
复制代码

www.google.com 为例:

  • 浏览器发现协议为 https,握手拿到 google 的证书,先从系统(window)或浏览器内置(Firefox)检查证书链是否正确。
  • 若是验证失败则会拦截。
  • 浏览器尝试查CRL(证书吊销列表)和OCSP(在线证书检查)。 注意:
    • CA不会直接暴露到外网的,若是须要访问CA服务器须要使用硬件Token而且多人在场录像,且只能远程访问。OCSP至关于证书数据库的备份而已经是直接暴露在外网的能够经过HTTP或者HTTPS访问。
    • OCSP是一种新技术。部分客户端可能不支持,仅支持 CRL。
  • 若是发现证书并无被吊销或者过时则浏览器对EV证书会显示为绿色,对OV证书则是经过放行。不然弹出通知,该网站不可信。

检查流程:

  • 客户端发送信息,带上支持的SSL或者TLS版本(不一样浏览器支持程* * 度不一样)。
  • 服务器返回确认使用的加密通讯协议版本以及加密随机数和CA证书。
  • 浏览器验证证书(存在双向验证和单项验证) -> OCSP或者CRL * 结合自带truststore。
  • 检查CA证书的根证书颁发机构是否受浏览器信任。
  • 检查CA证书中的证书吊销列表,检查证书是否被吊销。
  • 检查CA证书是否在有效期内。
  • 检查部署CA证书的网站域名与证书颁发的域名是否一致。
  • 浏览器核对该网站是否存在于欺诈网站数据库中。

13.https中哪里用了对称加密,哪里用了非对称加密,对加密法(如RSA)等是否有了解?

www.cnblogs.com/xishuai/p/h…

segmentfault.com/a/119000001…

DES Data Encryption Standard
3DES Triple DES
AES Advanced Encryption Standard
复制代码

我国国密局也制定了本身的对称加密算法,叫国密算法,SM1(至关于AES),和SM4(至关于3DES)。

RSA RSA是1977年由罗纳德·李维斯特(Ron Rivest)、阿迪·萨莫尔(Adi Shamir)和伦纳德·阿德曼(Leonard Adleman)一块儿提出的。
DSA Digital Signture Algorithm
ECC Elliptic Curves Cryptography

MD5 Message-Digest 5 1992
SHA1 NISTNSA 设计,SHA-1是由美国标准技术局(NIST)颁布的国家标准,是一种应用最为普遍的Hash函数算法
HMAC Hash-based Message Authentication Code
复制代码

AES加密算法的详细介绍与实现

AES的基本结构

AES为分组密码,每组长度相等,每次加密一组数据,直到加密完整个明文。在AES标准规范中,分组长度只能是128位,每一个分组为16个字节(每一个字节8位)。密钥的长度可使用128位、192位或256位。密钥的长度不一样,推荐加密轮数也不一样,以下表所示:

AES 密钥长度(32位比特字) 分组长度(32位比特字) 加密轮数
AES-128 4 4 10
AES-192 6 4 12
AES-256 8 4 14

AES的加密公式为C = E(K,P)

1、字节代换

AES定义了一个S盒和一个逆S盒。
1.字节代换操做
2.字节代换逆操做
复制代码

2、行移位

1.行移位操做 2.行移位的逆变换

3、列混合 1.列混合操做 2.列混合逆运算

4、轮密钥加

一文搞懂 RSA 算法

第一步:生成密钥对,即公钥和私钥

  • 两个随机质数 P Q,数越大越安全
好比 P = 67 ,Q = 71。计算他们的乘积 n = P * Q = 4757 ,转化为二进为 1001010010101,该加密算法即为 13 位,
实际算法是 1024 位 或 2048 位,位数越长,算法越难被破解。
复制代码
  • 计算 n 的欧拉函数 φ(n)
φ(n) 表示在小于等于 n 的正整数之中,与 n 构成互质关系的数的个数。
例如:在 1 到 8 之中,与 8 造成互质关系的是一、三、五、7,因此 φ(n) = 4。 
若是 n = P * Q,P 与 Q 均为质数,则 φ(n) = φ(P * Q) = φ(P - 1)φ(Q - 1) = (P - 1)(Q - 1) 。 
本例中 φ(n) = 66 * 70 = 4620,这里记为 m, m = φ(n) = 4620
复制代码
  • 随机选一个整数 e ,条件是 1 < e < m ,且 e 与 m 互质
公约数只有 1 的两个整数,叫作互质整数,这里咱们随机选择 e = 101 
请注意不要选择 4619,若是选这个,则公钥和私钥将变得相同。
复制代码
  • 有一个整数d,可使得 e * d 除以 m 的余数为 1
即找一个整数 d,使得 (e * d ) % m = 1。 等价于 e * d + 1 = y * m ( y 为整数) 找到 d ,实质就是对下面二元一次方程求解。 
e * x - m * y = 1 ,其中 e = 101,m = 4620,101x - 4620y = 1 这个方程能够用"扩展欧几里得算法"求解,此处省略具体过程。

总之算出一组整数解(x,y) = (1601,35),即 d = 1601。 到此密钥对生成完毕。
不一样的 e 生成不一样的 d,所以能够生成多个密钥对。

本例中公钥为 (n,e) = (4757 , 101),私钥为 (n,d) = (4757 ,1601) ,仅 (n,e) = (4757 , 101) 是公开的,其他数字均不公开。
能够想像若是只有 n 和 e,如何推导出 d,目前只能靠暴力破解,位数越长,暴力破解的时间越长。
复制代码

第二步:加密生成密文

好比甲向乙发送汉字“中”,就要使用乙的公钥加密汉字 "中", 以 utf-8 方式编码为 [e4 b8 ad],转为 10 进制为 [228,184,173]。
要想使用公钥(n,e) = (4757 , 101)加密,要求被加密的数字必须小于 n,被加密的数字必须是整数,字符串能够取 ascii 值或unicode值,
所以将“中”字折为三个字节 [228,184,173],分别对三个字节加密。 
假设 a 为明文,b 为密文,则按下列公式计算出 b
复制代码
  • a ^ e % n = b

    计算 [228,184,173]的密文:

    228^101 % 4757 = 4296

    184^101 % 4757 = 2458

    173^101 % 4757 = 3263

    即 [228,184,173]加密后获得密文 [4296,2458,3263] ,若是没有私钥 d ,神仙也没法从 [4296,2458,3263]中恢复 [228,184,173]。

解密生成明文。

乙收到密文 [4296,2458,3263],并用本身的私钥 (n,d) = (4757 ,1601) 解密。解密公式以下: 假设 a 为明文,b 为密文,则按下列公式计算出 a
复制代码
  • a ^ d % n = b

    密文 [4296,2458,3263]的明文以下:

    4296^1601% 4757 = 228

    2458^1601% 4757 = 184

    3263^1601% 4757 = 173

    即密文 [4296,2458,3263] 解密后获得 [228,184,173] 将[228,184,173] 再按 utf-8 解码为汉字 "中",至此解密完毕。

目前已经破解的最大整数:

1230186684530117755130494958384962720772853569595334792197322452151726400507263657518745202199786469389956474942774063845925192557326303453731548268507917026122142913461670429214311602221240479274737794080665351419597459856902143413
=
33478071698956898786044169848212690817704794983713768568912431388982883793878002287614711652531743087737814467999489
x
36746043666799590428244633799627952632279158164343087642676032283815739666511279233373417143396810270092798736308917
复制代码

即(232个十进制位,768个二进制位),目前被破解的最长RSA密钥就是768位。实际应用中 RSA 的密钥长度为 1024 位,重要场合 2048 位,将来半个世纪不可能破解。 (完)

漫画:什么是MD5算法?

MD5算法底层原理

处理原文,

原文长度(bit)对512求余的结果,若是不等于448,就须要填充原文到等于448。
填充的方法是第一位填充1,其他位填充0。

用剩余的位置(512-448=64位)记录原文的真正长度,把长度的二进制值补在最后。
这样处理后的信息长度就是512*(N+1)。
复制代码

设置初始值,

MD5的哈希结果长度为128位,按每32位分红一组共4组。
这4组结果是由4个初始值A、B、C、D通过不断演变获得。
MD5的官方实现中,A、B、C、D的初始值以下(16进制):
复制代码

A=0x01234567

B=0x89ABCDEF

C=0xFEDCBA98

D=0x76543210

循环加工,每一次循环都会让旧的ABCD产生新的ABCD,原文长度是M

主循环次数 = M / 512

每一个主循环中包含 512 / 32 * 4 = 64 次 子循环。

这张图所表达的就是单次子循环的流程:

1.绿色F

图中的绿色F,表明非线性函数。官方MD5所用到的函数有四种:
F(X, Y, Z) =(X&Y) | ((~X) & Z)
G(X, Y, Z) =(X&Z) | (Y & (~Z))
H(X, Y, Z) =X^Y^Z
I(X, Y, Z)=Y^(X|(~Z))
在主循环下面64次子循环中,F、G、H、I 交替使用,第一个16次使用F,第二个16次使用G,第三个16次使用H,第四个16次使用I。
复制代码

2.红色“田”字

很简单,红色的田字表明相加的意思。

4.Ki

一个常量,在64次子循环中,每一次用到的常量都是不一样的。

拼接结果。

最终产生的A,B,C,D四个值拼接在一块儿,转换成字符串便可。
复制代码

5.黄色的<<<S

左移S位,S的值也是常量。
“流水线”的最后,让计算的结果和B相加,取代原先的B。新ABCD的产生能够概括为:

新A = 原d
新B = b+((a+F(b,c,d)+Mj+Ki)<<<'s)
新C = 原b
新D = 原c
复制代码

www.cnblogs.com/foxclever/p…

juejin.im/post/5ce6b8…

14.client如何肯定本身发送的消息被server收到?

blog.csdn.net/github_3713…

增长 ack QoS

15.谈谈你对WebSocket的理解

blog.csdn.net/github_3713…

WebSocket 是相似 Socket 的 TCP 长链接的通信模式,一旦 WebSocket 链接创建后,后续数据都以帧序列的形式传输。在客户端断开 WebSocket 链接或 Server 端断掉链接前,不须要客户端和服务端从新发起链接请求。

  1. WebSocket是双向通讯协议,模拟Socket协议,能够双向发送或接受信息。HTTP是单向的。

  2. WebSocket是须要握手进行创建链接的。

16.WebSocket与Socket的区别

juejin.im/post/5c9748…

为了解决 Web 端即时通信的需求就出现了 WebSocket

WebSocket 与 Socket 的区别

Socket 是传输控制层的接口。用户能够经过 Socket 来操做底层 TCP/IP 协议族通讯。
WebSocket 是一个完整应用层协议。
Socket 更灵活,WebSocket 更易用。
二者都能作即时通信
复制代码

www.jianshu.com/p/59b5594ff…

ARPANET(Advanced Research Projects Agency)

最先的时候一个Socket指的是一个40位的数字(RFC33中说明了此用法,但在RFC36中并无明确地说使用40位数字来标识一个地址),其中前32为指向的地址(socket number,大体至关于IP),后8位为发送数据的源(link,大体至关于端口号)
后来(RFC433,Socket Number List)socket number被明确地定义为一个40位的数字,其中后8位被用来制定某个特定的应用使用(好比1是Telnet)。
复制代码

Hixie(Ian Hickson),他是WHATWG组织的发言人,曾供职于Netscape、Opera、Google。Hixie说了一句「我看WebSocket这个名字就很适合嘛」。 mcarter(Michael Carter )在Comet Daily中发表了文章Independence Day: HTML5 WebSocket Liberates Comet From Hacks,后来随着各大浏览器对WebSocket的支持,它变成了实际的标准,IETF也沿用了这个名字

www.jianshu.com/p/0e5b94688…

Meteor

HTTP和WebSocket协议的RFC文档(RFC2616 和 RFC6455)

HTTP1.1的链接默认使用持续链接(persistent connection),持续链接指的是,有时是客户端会须要在短期内向服务端请求大量的相关的资源,若是不是持续链接,那么每一个资源都要创建一个新的链接,HTTP底层使用的是TCP,那么每次都要使用三次握手创建TCP链接,将形成极大的资源浪费。

持续链接能够带来不少的好处:

使用更少的TCP链接,对通讯各方的压力更小。 可使用管道(pipeline)来传输信息,这样请求方不须要等待结果就能够发送下一条信息,对于单个的TCP的使用更充分。 流量更小 顺序请求的延时更小。 不须要从新创建TCP链接就能够传送error,关闭链接等信息。

www.jianshu.com/p/f666da1b1…

GET /chat HTTP/1.1            //1
Host: server.example.com   //2
Upgrade: websocket            //3
Connection: Upgrade            //4
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==            //5
Origin: http://example.com            //6
Sec-WebSocket-Protocol: chat, superchat            //7
Sec-WebSocket-Version: 13            //8
复制代码

帧类型 帧类型是由一个4位长的叫Opcode的值表示,任何WebSocket的通讯方收到一个位置的帧类型,都要以链接失败的方式断开此链接。 RFC6455中定义的帧类型以下所示:

Opcode == 0 继续

表示此帧是一个继续帧,须要拼接在上一个收到的帧以后,来组成一个完整的消息。因为这种解析特性,非控制帧的发送和接收必须是相同的顺序。

Opcode == 1 文本帧

Opcode == 2 二进制帧

Opcode == 3 - 7 将来使用(非控制帧)

Opcode == 8 关闭链接(控制帧) 此帧可能会包含内容,以表示关闭链接的缘由。 通讯的某一方发送此帧来关闭WebSocket链接,收到此帧的一方若是以前没有发送此帧,则须要发送一个一样的关闭帧以确认关闭。若是双方同时发送此帧,则双方都须要发送回应的关闭帧。 理想状况服务端在确认WebSocket链接关闭后,关闭相应的TCP链接,而客户端须要等待服务端关闭此TCP链接,但客户端在某些状况下也能够关闭TCP链接。

Opcode == 9 Ping 相似于心跳,一方收到Ping,应当当即发送Pong做为响应。

Opcode == 10 Pong 若是通讯一方并无发送Ping,可是收到了Pong,并不要求它返回任何信息。Pong帧的内容应当和收到的Ping相同。可能会出现一方收到不少的Ping,可是只须要响应最近的那一次就能够了。

Opcode == 11 - 15 将来使用(控制帧)

0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-------+-+-------------+-------------------------------+
 |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
 |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
 |N|V|V|V|       |S|             |   (if payload len==126/127)   |
 | |1|2|3|       |K|             |                               |
 +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
 |     Extended payload length continued, if payload len == 127  |
 + - - - - - - - - - - - - - - - +-------------------------------+
 |                               |Masking-key, if MASK set to 1  |
 +-------------------------------+-------------------------------+
 | Masking-key (continued)       |          Payload Data         |
 +-------------------------------- - - - - - - - - - - - - - - - +
 :                     Payload Data continued ...                :
 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
 |                     Payload Data continued ...                |
 +---------------------------------------------------------------+
复制代码

www.cnblogs.com/jiangzhaowe…

17.谈谈你对安卓签名的理解

blog.csdn.net/github_3713…

www.jianshu.com/p/24af47abc…

  • Android 使用标准的 Java 工具 Keytool & Jarsigner 来生成数字证书,并给应用包签名
  • 使用 zipalign 优化程序

调试模式 debug.keystore 发布模式 release.keystore

1)经过命令来对APK签名。 2)使用ADT Export Wizard进行签名

18.请解释安卓为啥要加签名机制?

blog.csdn.net/github_3713…

为何要签名

  • 发送者的身份认证:
  • 保证信息传输的完整性:
  • 防止交易中的抵赖发生:

给apk签名能够带来如下好处

  • 应用程序升级:
  • 应用程序模块化:
  • 代码或者数据共享:

签名的说明

  • 全部的应用程序都必须有数字证书:
  • Android 程序包使用的数字证书能够是自签名的:
  • 使用一个合适的私钥生成的数字证书来给程序签名:
  • 数字证书都是有有效期的:

19.视频加密传输

blog.csdn.net/qq_24636637…

20.App 是如何沙箱化,为何要这么作?

blog.csdn.net/github_3713…

21.权限管理系统(底层的权限是如何进行 grant 的)?

blog.csdn.net/github_3713…

相关文章
相关标签/搜索