分类目录归档:架构

加密传输的一些知识点

提供端到端的加密方案有:

  • 网络层加密
  • 传输层加密
  • 应用层加密

在网络安全加密方案的比较中,最安全的方案一定是暴露用户信息最少的,换句话说:加密的越多,越安全!

所以对底层的网络层加密最安全,最山梗的应用加密层加密最不安全。

网络层加密(IPsec)加密了除IP之外的所有层,包括TCP/UDP及以上,加密用户信息最多。

传输层加密(TLS)加密了除IP/TCP/UDP之外,所有应用层数据,包括 HTTP/FTP/SMTP,加密内容次之

应用层加密,只是加密应用层里敏感的信息,如密码,以及其它需要加密保护的内容,那IP/TCP/HTTP内容都明文暴露在外,加密内容最少。

毫无疑问网络层加密是最安全的,但是IPsec需要预先配置,甚至安装客户端软件,严重影响了它的普及层度。

而基于TLS的安全加密如https,几乎不需要任何预先配置。只要浏览器拥有Root CA证书,或者二级RA签发证书,然后加密是自动进行的,无需用户任何干预。

IPsecTLS的认证加密由一下组成:

1.认证对端合法性(Authentication)

  • Pre-shared Password
  • PKI

2.密钥交换算法(Key Exchange)

  • RSA
  • ECDH

3.加密算法(Encryption)

  • AES
  • 3DES

4.MAC校验算法(Integrity)

  • MD5
  • SHA-1

5.放重放共计(Anti-Replay)

  • 一般使用序列号(Sequence Number)来杜绝重放攻击

虽然上面的方案已趋近于完美,但还是存在最薄弱的环节,认证对方合法性(中间人欺骗)。

如果客户端和服务端都是私有实现的,比如说统一公司开发的后端和前端APP,可以使用下面方案解决。

使用预共享秘钥生成 敏感数据加密 + MAC,将数据HTTP封装,然后由TLS加密,这样即使中间人欺骗,也无法解密应用层加密数据。

参考:https://www.zhihu.com/question/52790301

JSON Web Token

一、简介

JSON Web Token 简称 JWT,是token认证的一种。它是一个开放标准,这个开放标准允许我们使用JWT在用户和服务器之间传递安全可靠的信息。

二、JWT的组成

JWT由三部分组成:
– header(头)
– payload(载体)
– signature(签名)

通常如下所示

xxxxxxx.yyyyyyy.zzzz

2.1、header

header包含2部分信息:令牌的信息,即JWT,以及签名所用的算法,例HMAC SHA256RSA

2.2、payload

payload也称为 JWT Claims,这里放置的是我们需要传输的信息,有多个项目如注册的claim名称,公共claim名称和私有claim名称。

注册claim名称有下面几个部分:

  • iss: token的发行者
  • sub: token的题目
  • aud: token的客户
  • exp: 经常使用的,以数字时间定义失效期,也就是当前时间以后的某个时间本token失效。
  • nbf: 定义在此时间之前,JWT不会接受处理。
  • iat: JWT发布时间,能用于决定JWT年龄
  • jti: JWT唯一标识. 能用于防止 JWT重复使用,一次只用一个token

公共claim名称用于定义我们自己创造的信息,比如用户信息和其他重要信息。

私有claim名称用于发布者和消费者都同意以私有的方式使用claim名称。

下面是JWT的一个案例:

2.3、signature

通过上面两部分信息我们可以得到一个字符串

然后指定的加密算法加上密钥以后可以得到我们的签名。

最后我们将签名凭借到最后我们就可以得到我们需要的JWT

三、适用场景

3.1、信息会暴露

在JWT中,不应该在载荷里面加入任何敏感的数据。像密码这样的内容就不能被放在JWT中了。如果将用户的密码放在了JWT中,那么怀有恶意的第三方通过Base64解码就能很快地知道你的密码了。

3.2、会话凭证

当用户登录成功后,我们将JWT返回给客户端。之后客户端每次请求将JWT传给后端,后端通过解码就可以得到用户的相关信息。

3.3、最适合的应用场景[开票]或者[签字]

1)邮箱确认。用户注册成功后,发送邮件到注册邮箱。然后用户点击链接跳转验证服务器,确认邮箱有效。

2)好友关注。在A用户关注了B用户的时候,系统发信息给B用户,并且附有一个链接“点此关注A用户”。B点击连接后添加关注A。

有上面2个例子,我们会发现一些相似性,如下:

web认证机制

1、 HTTP Basic Authentication认证

Basic 认证是HTTP 中非常简单的认证方式,因为简单,所以不是很安全。

客户端向服务端请求时,如果没有进行认证,会返回401状态码,要求客户端输入用户名密码。

当用户输入完用户名和密码后,用户名和密码会经过BASE64加密附加到请求信息中再次请求HTTP服务器,HTTP服务器会根据请求头携带的认证信息,决定是否认证成功及做出相应的响应。

浏览器访问test.api.com/1.html,请求会pedding住,等待输入用户密码。成功后可以访问内容。

request头信息中可以看到Authorization: Basic cGFuZ291OjEyMzQ1Ng==base64解码后就是pangou:123456。、

参考:https://segmentfault.com/a/1190000004694935

2、Digest Authentication (摘要式身份认证)

摘要式身份认证解决了基础认证的明文传输问题。

实现方案主要通过服务端返回nonce,然后客户端混淆用户名密码进行加密。

服务端可以进行配置nonce的过期时间。

auth_digest模块需要额外安装。

参考:https://www.nginx.com/resources/wiki/modules/auth_digest/

3、OAuth2

oauth2其实是一个授权系统。不过他可以通过扩展openid connect进行认证。

oauth2主要有一下几种流程:

  • 授权码模式(authorization code)最为严谨,用于常见的第三方应用。
  • 简化模式(implicit)常用于单页应用
  • 密码模式(resource owner password credentials)因为需要用户提供账号密码敏感信息,通常用于客户端与服务端(授权系统)为同一公司的情况下。
  • 客户端模式(client credentials)可用于企业内部服务之间的授权。比如A服务是否有权限访问B服务

参考:https://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

4、Cookie Auth

即传统cookie-session模式

5、Token Auth

Token Auth的优点

  • 支持跨域访问: Cookie是不允许垮域访问的,这一点对Token机制是不存在的,前提是传输的用户认证信息通过HTTP头传输.
  • 无状态:Token机制在服务端不需要存储session信息,因为Token 自身包含了所有登录用户的信息,只需要在客户端的cookie或本地介质存储状态信息.
  • 更适用CDN: 可以通过内容分发网络请求你服务端的所有资料(如:javascript,HTML,图片等),而你的服务端只要提供API即可.
  • 去耦: 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成,只要在你的API被调用的时候,你可以进行Token生成调用即可.
  • 更适用于移动应用: 当你的客户端是一个原生平台(iOS, Android,Windows 8等)时,Cookie是不被支持的(你需要通过Cookie容器进行处理),这时采用Token认证机制就会简单得多。
  • CSRF:因为不再依赖于Cookie,所以你就不需要考虑对CSRF(跨站请求伪造)的防范。
  • 性能: 一次网络往返时间(通过数据库查询session信息)总比做一次HMACSHA256计算 的Token验证和解析要费时得多.
  • 不需要为登录页面做特殊处理: 如果你使用Protractor 做功能测试的时候,不再需要为登录页面做特殊处理.
  • 基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库(.NET, Ruby, Java,Python, PHP)和多家公司的支持(如:Firebase,Google, Microsoft).

参考:https://juejin.im/entry/593522150ce463005728585a

RPC服务 —— http

[toc]

1、什么是RPC

RPC(Remote Procedure Call Protocol)——远程过程调用协议,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在,如TCP或UDP,为通信程序之间携带信息数据。在OSI网络通信模型中,RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

当我们对网站进行SOA化时,我们就需要通过RPC服务来保持服务与服务之间的通信。RPC的实现包括客户端和服务端。服务端提供服务,客户端进行调用。现在比较常见有2种方式的RPC服务,一个是基于HTTP协议的RPC服务,另外一个是基于TCP协议的RPC服务。本文将介绍一下基于HTTP协议的RPC服务。

2、基于HTTP的RPC服务

HTTP是基于TCP之上的一个协议,所以其相对TCP协议比较稳定,但是相对性能也稍差一些。

2.1、服务端

在php中,使用基于HTTP的PRC服务,那么就需要借助于nginx/apache来作为服务器。

服务端,我们可以使用上面的目录结构。
index.php 作为一个入口,并且做一些初始化的动作。
Api目录下存放所有提供服务的文件。
当然这只是一个比较简单目录结构,我们可以根据自己的项目去改造、去变化。

下面是简单实现代码。

2.2、客户端

客户端我们可以php的curl库来完成。

总结

当然上面是一个最简单的例子。在做架构中,我们需要对其扩充,比如安全验证、序列化等等的功能扩展。

网站架构模式

为了解决高并发访问、海量数据处理、高可靠运行等一系列问题,实现高性易伸缩、可扩展、安全。可以使用以下各种方式进行架构网站。

1、 分层

分层是一种常见的架构模式,将系统在横向维度上切分成几个部分,每个部分负责一部分相对比较单一的职责,然后通过上层对下层的依赖和调用组成的一个完整系统。
分层结构无处不在,比如网络的7蹭通信协议等。我们可以将网站分为应用层服务层数据层

  • 应用层:负责具体业务和视图展示。如网站首页、商品详情页等。
  • 服务层:为应用层提供服务支持。如用户管理服务、购物车服务、支付服务等。
  • 数据层:提供数据存储访问服务。如数据库、缓存、文件、搜索引擎等。

通过分层,可以将一个网站切分不同的部分,便于分工合作开发维护,职责清晰。每层之间具有一定的独立性,他们之间也需要严格遵循一定官则,如禁止跨层访问、逆向调用。

在具体开发中,大的分层基础上还可以继续分层。如应用层可以在细分为视图层和业务逻辑层;服务层也可以分为数据接口层和逻辑处理层等。

2、 分割

分层是对系统进行横向切分,那么分割就是将系统进行竖向切分。

网站越大,功能越复杂,服务和数据处理的种类也越多,将不同的功能和服务分割开来,包装成高内聚低耦合的模块,便于分布式部署,提高网站并发处理能力和功能扩展能力。

在应用层,将不同的业务进行分割。比如将购物、论坛、搜索、广告分成不同的模块,由独立的团队负责。
同分层一样,在大的分割基础上还可以继续进行分割。比如购物模块可以进一步分割为机票酒店业务、3C业务等更细小的颗粒度。这些模块不管在逻辑上还是物理部署上都是独立的,相应的服务层也可以更具需要将服务分割成适合的模块。

3、 分布式

分层和分割的主要目的就是为了切分后的模块便于分布式部署。分布式之后就意味着拥有更多的cpu、内存、磁盘存储资源,也就是能够更好的处理高并发和大数据。

但是相对的也会带来其他问题。首先,分布式意味着服务之间调用必须使用网络,这就可能会对性能造成一定影响。其次,服务器越多,服务器宕机概率也就越大。另外,数据在分布式环境中保持一致性也越困难,分布式事务也难以保证,对网站业务的正确性和业务流程有可能造成很大的影响。最后,分布式还导致网站依赖错综复杂,开发管理维护困难性提高。

因此分布式设计要根据具体的情况量力而行,切莫为了分布式而分布式,但是对于大型网站来说,分布式是必须走的路。

常用的分布式方案有以下几种:

  • 分布式应用和服务
  • 分布式静态资源
  • 分布式数据和存储
  • 分布式计算
  • 当然还有分布式配置、分布式锁、分布式文件系统等。

4、 缓存

缓存是改善系统性能的第一手段,在现代网站架构中缓存无处不在,下面介绍几种常用的缓存手段。

  • CDN
    即内容分发网络,将某些资源(如静态资源)部署在距离终端用户最近的网络服务商,当用户请求到达网络服务商这里时,这些资源就会立刻返回给用户,减去了大量长距离网络传输的性能消耗。

  • 反向代理
    反向代理属于网站前端架构的一部分,部署在网站的前端,当用户请求到达反向代理服务器时,这里缓存的静态资源可以直接返回给用户。当然反向代理不仅仅是这点功能而已。

  • 本地缓存
    不多说了这个,本地访问的数据~~~~

  • 分布式缓存
    大型网站数据量非常庞大,及时是一小部分的缓存,也不是单机能够承受的。

使用缓存有2个条件,一个是数据访问热点不均衡,某些数据会被更频繁的访问,这些数据应该放到缓存中。
第二个是某段时间内不会过期的数据。

5、 异步

大型网站中系统解耦的手段除了分层、分割,还有一个重要的手段 —— 异步。异步架构是典型的生产者消费者模式,两者间不存在直接调用,只要保持数据结构不变化,彼此功能实现可以随意变化而互不影响,这对网站扩展非常便利。
异步消息有几点很重要好的特性:

  • 提高系统可用性
    消费者服务器发生故障,数据仍旧会保存在消息队列服务用,生产者服务器依旧可以处理业务请求,只需要等待消费者服务器正常后继续工作。
  • 加快网站相应速度
    某些业务可以延时处理,减少生产者响应时间
  • 消除并发访问高峰
    消息队列可以消峰填谷这点非常重要,比如网站出小活动,造成网站并发陡增,这可能造成玩网站负载过重,响应延迟,甚至宕机。消息队列可以将数据保存在队列中,等待消费者服务器依次处理,就不会对网站造成太大压力。

需要注意的是,异步方式会对业务处理造成影响,需要网站产品设计方面支持。

6、 冗余

现在互联网公司都是7×24小时连续运行,但是服务器随时可能出现故障,特别是服务器规模较大时,出现某台服务器宕机是必然的事情。如果我们对服务器进行了冗余,那么就可以不受宕机影响,网站依然可以运行,不丢失数据。

冗余可以实现高可用

数据库除了定期备份,存档保存,实现冷备份外、为了业务高可用,还需要对数据库进行主从分离,实时同步热备份。甚至为了抵御地震、海啸等不可抗力,需要在全球范围部署容灾数据中心。

7、 自动化

  • 自动化部署 不对说了
  • 自动化监控 对服务进行心跳检测,并监控其各项性能指标和应用程序的关键数据指标
  • 自动化报警 通过自动话监控发现异常,就需要向相关人员发送警报信息
  • 自动化失效转移 将失效服务器从集群中移除
  • 自动化失效恢复 故障消除后,将服务器自动添加入集群,同步数据保证一致性
  • 自动化降级 当网站遇到访问高峰时,超出网站最大处理能力,为了保证整个网站的可用性,拒绝或关闭部分无关紧要的服务,保证网站主要流程能够运行流畅,将系统负载降至安全水平。
  • 自动化分配资源 当网站遇到访问高峰时,已经自动化降级的同时,必要时,可以通过将空闲资源分配给重要服务,扩大其部署规模

8、 安全

互联网的开放特性,使得其从诞生起就面对巨大的安全挑战,网站在安全架构方面也积累了许多模式:

  • 通过密码和手机校验码进行身份认证
  • 登录、交易等操作需要对网络进行加密,其他敏感信息也需要进行加密
  • 为了防止机器人滥用网络资源攻击,网站使用验证码识别
  • 对于常见的攻击手段xss攻击、sql注入,对表单提交做相应的编码转换处理
  • 对垃圾信息、敏感信息做相应的屏蔽
  • 对交易转账等重要操作,根据交易模式和交易信息进行风险控制