3.12周报-爱代码爱编程
周报
代码行数:
周一 | 575 |
周二 | 584 |
周三 | 593 |
周四 | 583 |
周五 | 602 |
周六 | 632 |
周日 | 564 |
遇到的问题:
定义时间戳时,用·long接参,但总是超出范围,但明明没有
解决:在数字后面加“L”
用到sha256
SHA256是SHA-2下细分出的一种算法
SHA-2,名称来自于安全散列算法2(英语:Secure Hash Algorithm 2)的缩写,一种密码散列函数算法标准,由美国国家安全局研发,属于SHA算法之一,是SHA-1的后继者。
SHA-2下又可再分为六个不同的算法标准
包括了:SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA-512/256。
这些变体除了生成摘要的长度 、循环运行的次数等一些微小差异外,算法的基本结构是一致的。
回到SHA256上,说白了,它就是一个哈希函数。
哈希函数,又称散列算法,是一种从任何一种数据中创建小的数字“指纹”的方法。散列函数把消息或数据压缩成摘要,使得数据量变小,将数据的格式固定下来。该函数将数据打乱混合,重新创建一个叫做散列值(或哈希值)的指纹。散列值通常用一个短的随机字母和数字组成的字符串来代表。
对于任意长度的消息,SHA256都会产生一个256bit长的哈希值,称作消息摘要。
这个摘要相当于是个长度为32个字节的数组,通常用一个长度为64的十六进制字符串来表示
来看一个例子:
干他100天成为区块链程序员,红军大叔带领着我们,fighting!
这句话,经过哈希函数SHA256后得到的哈希值为:
A7FCFC6B5269BDCCE571798D618EA219A68B96CB87A0E21080C2E758D23E4CE9
用到的浮点数有点不听使唤,总是自己换计数方式,在数据类型转换时总是给我添堵,
jsonObject不能直接转换成double要先转换成string
遇到的问题:double类型总是自己变成x.xxxxEx的计数方式,在转字符串时不会自己变回来,
所以在储存double时都会转换成bigdecmal,解决格式错误问题
用JsonObject存了一个数组,不能直接取出到数组中,要先转换为jsonarry,然后通过遍历来完成转换。
知识点:
了解grpc
gRPC是rpc框架中的一种,是rpc中的大哥
是一个高性能,开源和通用的RPC框架,基于Protobuf序列化协议开发,且支持众多开发语言。
面向服务端和协议端,基于http/2设计,带来诸如双向流,流控,头部压缩,单TCP连接上的多路复用请求等特性。这些特性使得其在移动设备上表现的更好,更省电和节省空间。
在gPRC里客户端可以向调用本地对象一样直接调用另一台不同机器上服务端应用的方法,使得您能够更容易地创建分布式应用和服务。
与许多RPC系统类似,gRPC也是基于以下理念:定义一个服务,指定其能够被远程调用的方法(包含参数和返回类型)。在服务端实现这个接口。并运行一个gRPC服务器来处理客户端调用。在客户端拥有一个存根能够向服务端一样的方法。
补充一个知识点(HTTP/2 与HTTP1.X的区别)
用于数据传输的二进制分帧
HTTP/2采用二进制格式传输协议,而非HTTP/1.x的文本格式。
多路复用
HTTP/2支持通过同一个连接发送多个并发的请求。
而HTTP/1.x虽然通过pipeline也能并发请求,但多个请求之间的响应依然会被阻塞。
服务端推送
服务端推送是一种在客户端请求之前发送数据的机制。在HTTP/2中,服务器可以对客户端的一个请求发送多个响应。而不像HTTP/1.X一样,只能通过客户端发起request,服务端才产生对应的response。
减少网络流量的头部压缩。
HTTP/2对消息头进行了压缩传输,能够节省消息头占用的网络流量。至于如何压缩的,可以查看这篇:HPACK: Header Compression for HTTP/2[1]
2.gRPC大致请求流程
1.客户端(gRPC Stub)调用A方法,发起RPC调用
2.对请求信息使用Protobuf进行对象序列化压缩(IDL)
3.服务端(gPRC Server)接收到请求后,解码请求体,进行业务逻辑处理并返回。
4.对响应结果使用Protobuf进行对象序列化压缩(IDL)
5.客户端接受到服务端响应,解码请求体。回调被调用的A方法,唤醒正在等待响应(阻塞)的客户端调用并返回响应结果
3.gRPC的优势
性能
gRPC消息使用一种有效的二进制消息格式protobuf继续宁序列化。Protobuf在服务器和客户机上的序列化非常快。Protobuf序列化之后的消息体积很小,能够有效负载,在移动应用程序等有限宽带场景中显得很重要。与采用文本格式的json相比,采用二进制格式的protobuf在速度上可以达到前者的5倍
代码生成
所有gRPC框架都为代码生成提供了一流的支持。gRPC的开发核心是*.proto文件,它定义了gRPC服务和消息的约定。根据这个文件,gRP框架将生成服务基类,消息和完整的客户端代码。
通过在服务器和客户端之间共享*.proto文件,可以从端到端生成消息和客户端代码。客户端的代码生成消除了客户端和服务器上的重复消息,并为您创建了一个强类型的客户端。无需编写客户端代码,可在具有许多服务和应用程序中节省大量开发时间。
严格的规范
不存在具有JSON的HTTP API的正事规范。开发人员不需要讨论URL,HTTP动词和响应代码的最佳格式。(不需要考虑用post还是get,get还是put)
该gRPC规范是规定有关gPRC服务必须遵循的格式。gRPC消除了争论并节省了开发人员的时间,因为gRPC在各个平台上和实现之间是一致的
流
gRPC服务支持所有流组合:
一元(没有媒体流):最简单的rpc调用,一个请求对象对应一个返回对象。客户端发起一次请求客户端相应一个数据,即标准的RPC通信。
服务器到客户端流:客户端流式rpc客户端传入多个请求对象。服务端返回一个响应结果。应用场景:物联网终端向服务器报送数据。
客户端到服务器流:服务端流式rpc一个请求对象,服务端可以传回多个结果对象。服务端流PRC下,客户端发出一个请求,但不会立即得到一个响应,而是在服务器与客户端之间建立一个单向的流,不断获取响应直到流关闭。应用场景举例:典型的例子是客户端向服务端发送一个股票代码,服务端就把该股票的实时数据源源不断的返回客户端
双向流媒体:双向流式RPC结合客户端流式RPC和服务端流式RPC,可以传入多个对象,返回多个响应对象。应用场景:聊天应用
截至时间/超时和取消
gRPC允许客户端指定他们愿意等待RPC完成时间。该期限被发送到服务端,服务端可以决定在超出了期限时采取什么行动,例如,服务器可能会在超时时取消正在进行的gPRC/HTTP/数据库请求
通过子gRPC调用截至时间和取消操作有助于实施资源使用限制
4.gRPC的劣势
浏览器支持有限
当下,不能从浏览器调用gRPC服务 ,
gRPC Web是gRPC团队的一项附加技术,它在浏览器中提供有限的gRPC支持。gRPC Web由两部分组成:支持所有现代浏览器的JavaScript客户端和服务器上的gRPC Web代理。gRPC Web客户端调用代理,代理将在gRPC请求上转发到gRPC服务器。
gRPC Web并非支持所有gRPC功能。不支持客户端和双向流,并且对服务器流的支持有限。
不是人类可读的
HTTP API请求以文本形式发送,可以由人读取和创建。
默认情况下,gRPC消息使用protobuf编码。虽然protobuf的发送和接收效率很高,但它的二进制格式是不可读的。protobuf需要在.proto文件中指定的消息接口描述才能正确反序列化。需要额外的工具来分析线路上的Protobuf有效负载,并手工编写请求。
存在诸如服务器反射和gRPC命令行工具等功能,以帮助处理二进制protobuf消息。另外,Protobuf消息支持与JSON之间的转换。内置的JSON转换提供了一种有效的方法,可以在调试时将Protobuf消息转换为可读的形式。
5.使用场景
建议使用的场景:
微服务:gRPC设计为低延迟和高吞吐量通信,非常适用效率至关重要的轻型微服务
点对点实时通信:gRPC可以实时推送消息而无需轮询
多语言混合开发环境:支持所有流行开发语言
网络受限环境:使用Protobuf(一种轻量级消息格式)序列化gRPC消息。gRPC消息始终小于等效的JSON消息
不建议使用场景:
浏览器可访问的API:浏览器不支持gRPC,gRPC-Web有局限性而且还引入了服务器代理
广播实时通信
进程间通信
一,什么是websocket
WebSocket是HTML5下一种新的协议(websocket协议本质上是一个基于tcp的协议)
它实现了浏览器与服务器全双工通信,能更好的节省服务器资源和带宽并达到实时通讯的目的
Websocket是一个持久化的协议
二,websocket的原理
websocket约定了一个通信的规范,通过一个握手的机制,客户端和服务器之间能建立一个类似tcp的连接,从而方便它们之间的通信
在websocket出现之前,web交互一般是基于http协议的短连接或者长连接
websocket是一种全新的协议,不属于http无状态协议,协议名为"ws"
三,websocket与http的关系
相同点:
都是基于tcp的,都是可靠性传输协议
都是应用层协议
不同点:
WebSocket是双向通信协议,模拟Socket协议,可以双向发送或接受信息
HTTP是单向的
WebSocket是需要浏览器和服务器握手进行建立连接的
而http是浏览器发起向服务器的连接,服务器预先并不知道这个连接
联系:
WebSocket在建立握手时,数据是通过HTTP传输的。但是建立之后,在真正传输时候是不需要HTTP协议的
总结(总体过程):
首先,客户端发起http请求,经过3次握手后,建立起TCP连接;http请求里存放WebSocket支持的版本号等信息,如:Upgrade、Connection、WebSocket-Version等;
然后,服务器收到客户端的握手请求后,同样采用HTTP协议回馈数据;
最后,客户端收到连接成功的消息后,开始借助于TCP传输信道进行全双工通信。
四,websocket解决的问题
1.http存在的问题
http是一种无状态协议,每当一次会话完成后,服务端都不知道下一次的客户端是谁,需要每次知道对方是谁,才进行相应的响应,因此本身对于实时通讯就是一种极大的障碍
http协议采用一次请求,一次响应,每次请求和响应就携带有大量的header头,对于实时通讯来说,解析请求头也是需要一定的时间,因此,效率也更低下
最重要的是,需要客户端主动发,服务端被动发,也就是一次请求,一次响应,不能实现主动发送
2.long poll(长轮询)
对于以上情况就出现了http解决的第一个方法——长轮询
基于http的特性,简单点说,就是客户端发起长轮询,如果服务端的数据没有发生变更,会 hold 住请求,直到服务端的数据发生变化,或者等待一定时间超时才会返回。返回后,客户端又会立即再次发起下一次长轮询
优点是解决了http不能实时更新的弊端,因为这个时间很短,发起请求即处理请求返回响应,实现了“伪·长连接”
张三取快递的例子,张三今天一定要取到快递,他就一直站在快递点,等待快递一到,立马取走
从例子上来看有个问题:
假如有好多人一起在快递站等快递,那么这个地方是否足够大,(抽象解释:需要有很高的并发,同时有很多请求等待在这里)
总的来看:
推送延迟。服务端数据发生变更后,长轮询结束,立刻返回响应给客户端。
服务端压力。长轮询的间隔期一般很长,例如 30s、60s,并且服务端 hold 住连接不会消耗太多服务端资源。
3.Ajax轮询
基于http的特性,简单点说,就是规定每隔一段时间就由客户端发起一次请求,查询有没有新消息,如果有,就返回,如果没有等待相同的时间间隔再次询问
优点是解决了http不能实时更新的弊端,因为这个时间很短,发起请求即处理请求返回响应,把这个过程放大n倍,本质上还是request = response
举个形象的例子(假设张三今天有个快递快到了,但是张三忍耐不住,就每隔十分钟给快递员或者快递站打电话,询问快递到了没,每次快递员就说还没到,等到下午张三的快递到了,but,快递员不知道哪个电话是张三的,(可不是只有张三打电话,还有李四,王五),所以只能等张三打电话,才能通知他,你的快递到了)
从例子上来看有两个问题:
假如说,张三打电话的时间间隔为10分钟,当他收到快递前最后一次打电话,快递员说没到,他刚挂掉电话,快递入库了(就是到了),那么等下一次时间到了,张三打电话知道快递到了,那么这样的通讯算不算实时通讯?很显然,不算,中间有十分钟的时间差,还不算给快递员打电话的等待时间(抽象的解释:每次request的请求时间间隔等同于十分钟,请求解析相当于等待)
假如说张三所在的小区每天要收很多快递,每个人都采取主动给快递员打电话的方式,那么快递员需要以多快的速度接到,其他人打电话占线也是问题(抽象解释:请求过多,服务端响应也会变慢)
总的来看,Ajax轮询存在的问题:
推送延迟。
服务端压力。配置一般不会发生变化,频繁的轮询会给服务端造成很大的压力。
推送延迟和服务端压力无法中和。降低轮询的间隔,延迟降低,压力增加;增加轮询的间隔,压力降低,延迟增高
4.websocket的改进
一旦WebSocket连接建立后,后续数据都以帧序列的形式传输。在客户端断开WebSocket连接或Server端中断连接前,不需要客户端和服务端重新发起连接请求。在海量并发及客户端与服务器交互负载流量大的情况下,极大的节省了网络带宽资源的消耗,有明显的性能优势,且客户端发送和接受消息是在同一个持久连接上发起,实现了“真·长链接”,实时性优势明显。
WebSocket有以下特点:
是真正的全双工方式,建立连接后客户端与服务器端是完全平等的,可以互相主动请求。而HTTP长连接基于HTTP,是传统的客户端对服务器发起请求的模式。
HTTP长连接中,每次数据交换除了真正的数据部分外,服务器和客户端还要大量交换HTTP header,信息交换效率很低。Websocket协议通过第一个request建立了TCP连接之后,之后交换的数据都不需要发送 HTTP header就能交换数据,这显然和原有的HTTP协议有区别所以它需要对服务器和客户端都进行升级才能实现(主流浏览器都已支持HTML5)