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
blog.csdn.net/github_3713…android
Volleygit
特色:github
场景:web
OkHttp算法
特色:数据库
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
特色:
场景:
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 {
}
});
复制代码
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
CacheInterceptor
OKHttp3(支持Retrofit)的网络数据缓存Interceptor拦截器
读取候选缓存,具体如何读取的咱们下面会讲。
建立缓存策略,强制缓存、对比缓存等,关于缓存策略咱们下面也会讲。
根据策略,不使用网络,又没有缓存的直接报错,并返回错误码504。
根据策略,不使用网络,有缓存的直接返回。
前面两个都没有返回,继续执行下一个Interceptor,即ConnectInterceptor。
接收到网络结果,若是响应code式304,则使用缓存,返回缓存结果。
读取网络结果。
对数据进行缓存。
返回网络读取的结果。
复制代码
Bitmap.Options inJustDecodeBounds inSampleSize
ARGB_4444 RGB_565
补图
分块加载
使用LruCache
sizeOf()、entryRemoved()
手势处理
ScaleGestureDetector GestureDetector
前者用于处理缩放手势,后者用于处理其他手势,如移动,快速滑动,点击,双击,长按等。
ScaleGestureDetector专门处理缩放手势,其比较重要的方法是onScale(ScaleGestureDetector detector),当缩放时会不停地回调这个方法,须要注意的一点是detector.getScaleFactor()获取到的缩放比例是相对上一次的
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报文。
blog.fundebug.com/2019/03/22/…
UDP | TCP | |
---|---|---|
是否链接 | 无链接 | 面向链接 |
是否可靠 | 不可靠传输,不使用流量控制和拥塞控制 | 可靠传输,使用流量控制和拥塞控制 |
链接对象个数 | 支持一对一,一对多,多对一和多对多交互通讯 | 只能是一对一通讯 |
传输方式 | 面向报文 | 面向字节流 |
首部开销 | 首部开销小,仅8字节 | 首部最小20字节,最大60字节 |
适用场景 | 适用于实时应用(IP电话、视频会议、直播等) | 适用于要求可靠传输的应用,例如文件传输 |
blog.csdn.net/leewccc/art… www.cnblogs.com/liangyc/p/1…
TCP Transmission Contral Protocol UDP User Datagram Protocol
区别
面向链接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聊天、在线视频、网络语音电话(即时通信,速度要求高,可是出现偶尔断续不是太大问题,而且此处彻底不可使用重发机制)、广播通讯(广播、多播)。
复制代码
hit-alibaba.github.io/interview/b…
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 性能惊人
大约 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
复制代码
blog.fundebug.com/2019/04/26/…
方法1. 对称加密
没有密钥就没法对密码解密,反过来讲,任何人只要持有密钥就能解密了。
复制代码
方法2. 非对称加密
私有密钥不能让其余任何人知道,而公开密钥则能够随意发布,任何人均可以得到。
复制代码
方法3. 对称加密+非对称加密(HTTPS采用这种方式)
在交换密钥环节使用非对称加密方式,以后的创建通讯交换报文阶段则使用对称加密方式。
发送密文的一方使用对方的公钥进行加密处理“对称的密钥”,而后对方用本身的私钥解密拿到“对称的密钥”,
这样能够确保交换的密钥是安全的前提下,使用对称加密方式进行通讯。
复制代码
yiqingfeng.github.io/2019/04/01/…
证书的安全性
证书的校验
校验证书是否已被吊销须要和 CA 关联,其余都可由浏览器完成。验证证书是否吊销能够采用CRL黑名单方式或者OCSP方式。
CRL黑名单就是按期从CA下载一个名单列表,里面有吊销的证书序列号,本身在本地比对一下就行。
优势是效率高。缺点是不实时。
OCSP是实时链接CA去验证,优势是实时,缺点是效率不高。
复制代码
以 www.google.com 为例:
检查流程:
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标准规范中,分组长度只能是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、轮密钥加
第一步:生成密钥对,即公钥和私钥
好比 P = 67 ,Q = 71。计算他们的乘积 n = P * Q = 4757 ,转化为二进为 1001010010101,该加密算法即为 13 位,
实际算法是 1024 位 或 2048 位,位数越长,算法越难被破解。
复制代码
φ(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
复制代码
公约数只有 1 的两个整数,叫作互质整数,这里咱们随机选择 e = 101
请注意不要选择 4619,若是选这个,则公钥和私钥将变得相同。
复制代码
即找一个整数 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算法底层原理
处理原文,
原文长度(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
复制代码
增长 ack QoS
WebSocket 是相似 Socket 的 TCP 长链接的通信模式,一旦 WebSocket 链接创建后,后续数据都以帧序列的形式传输。在客户端断开 WebSocket 链接或 Server 端断掉链接前,不须要客户端和服务端从新发起链接请求。
WebSocket是双向通讯协议,模拟Socket协议,能够双向发送或接受信息。HTTP是单向的。
WebSocket是须要握手进行创建链接的。
为了解决 Web 端即时通信的需求就出现了 WebSocket
WebSocket 与 Socket 的区别
Socket 是传输控制层的接口。用户能够经过 Socket 来操做底层 TCP/IP 协议族通讯。
WebSocket 是一个完整应用层协议。
Socket 更灵活,WebSocket 更易用。
二者都能作即时通信
复制代码
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也沿用了这个名字
Meteor
HTTP和WebSocket协议的RFC文档(RFC2616 和 RFC6455)
HTTP1.1的链接默认使用持续链接(persistent connection),持续链接指的是,有时是客户端会须要在短期内向服务端请求大量的相关的资源,若是不是持续链接,那么每一个资源都要创建一个新的链接,HTTP底层使用的是TCP,那么每次都要使用三次握手创建TCP链接,将形成极大的资源浪费。
持续链接能够带来不少的好处:
使用更少的TCP链接,对通讯各方的压力更小。 可使用管道(pipeline)来传输信息,这样请求方不须要等待结果就能够发送下一条信息,对于单个的TCP的使用更充分。 流量更小 顺序请求的延时更小。 不须要从新创建TCP链接就能够传送error,关闭链接等信息。
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 ... |
+---------------------------------------------------------------+
复制代码
调试模式 debug.keystore 发布模式 release.keystore
1)经过命令来对APK签名。 2)使用ADT Export Wizard进行签名
18.请解释安卓为啥要加签名机制?
为何要签名
给apk签名能够带来如下好处
签名的说明
19.视频加密传输