分类目录归档：架构

加密传输的一些知识点

2018年8月6日 chen

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

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

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

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

安全性： 网络层加密 > 传输层加密 > 应用层加密

1 2	安全性：网络层加密 > 传输层加密 > 应用层加密

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

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

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

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

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

IPsec与TLS的认证加密由一下组成：

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

2018年7月15日 chen

一、简介

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

二、JWT的组成

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

通常如下所示

xxxxxxx.yyyyyyy.zzzz

2.1、header

header包含2部分信息：令牌的信息，即JWT，以及签名所用的算法，例HMAC SHA256或RSA。

{
  "alg": "HS256",
  "typ": "JWT"
}

{

"alg": "HS256",

"typ": "JWT"

}

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的一个案例：

{
    "iss": "example JWT",
    "iat": 1442593502,
    "exp": 1442594722,
    "aud": "www.example.com",
    "sub": "pangou@example.com",
    "from_user": "B",
    "target_user": "A"
}

{

"iss": "example JWT",

"iat": 1442593502,

"exp": 1442594722,

"aud": "www.example.com",

"sub": "pangou@example.com",

"from_user": "B",

"target_user": "A"

}

2.3、signature

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

var encodedString = base64UrlEncode(header) + "." + base64UrlEncode(payload);

var encodedString = base64UrlEncode(header) + "." + base64UrlEncode(payload);

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

HMACSHA256(encodedString, 'secret');

1 2	HMACSHA256(encodedString, 'secret');

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

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

1 2	eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

三、适用场景

3.1、信息会暴露

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

3.2、会话凭证

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

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

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

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

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

服务B你好, 服务A告诉我，我可以操作<JWT内容>, 这是我的凭证（即JWT）

1 2	服务B你好, 服务A告诉我，我可以操作<JWT内容>, 这是我的凭证（即JWT）

架构

web认证机制

2018年7月12日 chen

1、 HTTP Basic Authentication认证

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

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

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

# nginx 设置basic 认证

# 1、设置密码
$ printf "pangou:$(openssl passwd -crypt 123456)\n" >> conf.d/passwd
$ cat conf.d/passwd 
pangou:OdA8ID7CAMqcA

# 2、nginx配置
$ vim test.api.com.conf

location /
{
    auth_basic "Hello World";
    auth_basic_user_file conf.d/passwd; 
    autoindex on;
}

# 3、重启nginx

# nginx 设置basic 认证

# 1、设置密码

$ printf "pangou:$(openssl passwd -crypt 123456)\n" >> conf.d/passwd

$ cat conf.d/passwd

pangou:OdA8ID7CAMqcA

# 2、nginx配置

$ vim test.api.com.conf

location /

{

auth_basic "Hello World";

auth_basic_user_file conf.d/passwd;

autoindex on;

}

# 3、重启nginx

浏览器访问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_user_file conf.d/passwd; 
auth_digest "Hello World";
auth_digest_timeout 60s; 
auth_digest_expires 10s;
auth_digest_replays 20;

auth_digest_user_file conf.d/passwd;

auth_digest "Hello World";

auth_digest_timeout 60s;

auth_digest_expires 10s;

auth_digest_replays 20;

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

2015年3月15日 chen

[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来作为服务器。

wwwroot/
        index.php
        Api/
            Hello.php

wwwroot/

index.php

Api/

Hello.php

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

下面是简单实现代码。

# index.php
<?php 

spl_autoload_register('autoload');

function autoload($class) {

    $filename = 'Api/' . $class . '.php';
    if( file_exists($filename) ) {
        include $filename;
    }  else {
        echo 'class not exists';
        exit();
    }

}


$class = $_REQUEST['class'];
$func = $_REQUEST['func'];
$params = $_REQUEST['params'];

$obj = new $class;
call_user_func(array($obj, $func), $params);

# index.php

<?php

spl_autoload_register('autoload');

function autoload($class) {

$filename = 'Api/' . $class . '.php';

if( file_exists($filename) ) {

include $filename;

} else {

echo 'class not exists';

exit();

}

$class = $_REQUEST['class'];

$func = $_REQUEST['func'];

$params = $_REQUEST['params'];

$obj = new $class;

call_user_func(array($obj, $func), $params);

# Api/Hello.php
<?php 


class Hello {
    public function say() {
        echo "hello world!!!";
    }
}

# Api/Hello.php

<?php

class Hello {

public function say() {

echo "hello world!!!";

}

2.2、客户端

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

# http_client.php

<?php

$data = request( 'Hello', 'say' );

function request($class, $func, $params = []){
    $ci = curl_init();
    $s = array(
        CURLOPT_URL => 'http://http.rpc.com',
        CURLOPT_TIMEOUT => 3,
        CURLOPT_ENCODING => 'gzip',
        CURLOPT_RETURNTRANSFER => 0,
        CURLOPT_HEADER=>0,
        CURLOPT_POST=>1,
        CURLOPT_FOLLOWLOCATION => 1,
        CURLOPT_POSTFIELDS=>array(
            'class'  => $class,
            'func'   => $func,
            'params' => json_encode( $params ),
        ),
    );
    curl_setopt_array($ci,$s);
    $r = curl_exec($ci);
    curl_close($ci);
    return $r;
};

# http_client.php

<?php

$data = request( 'Hello', 'say' );

function request($class, $func, $params = []){

$ci = curl_init();

$s = array(

CURLOPT_URL => 'http://http.rpc.com',

CURLOPT_TIMEOUT => 3,

CURLOPT_ENCODING => 'gzip',

CURLOPT_RETURNTRANSFER => 0,

CURLOPT_HEADER=>0,

CURLOPT_POST=>1,

CURLOPT_FOLLOWLOCATION => 1,

CURLOPT_POSTFIELDS=>array(

'class' => $class,

'func' => $func,

'params' => json_encode( $params ),

);

curl_setopt_array($ci,$s);

$r = curl_exec($ci);

curl_close($ci);

return $r;

};

总结

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

大型网站技术架构

网站架构模式

2015年2月28日 chen

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

1、分层

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

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

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

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

2、分割

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

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

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

3、分布式

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

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

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

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

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

4、缓存

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

CDN
即内容分发网络，将某些资源（如静态资源）部署在距离终端用户最近的网络服务商，当用户请求到达网络服务商这里时，这些资源就会立刻返回给用户，减去了大量长距离网络传输的性能消耗。
反向代理
反向代理属于网站前端架构的一部分，部署在网站的前端，当用户请求到达反向代理服务器时，这里缓存的静态资源可以直接返回给用户。当然反向代理不仅仅是这点功能而已。
本地缓存
不多说了这个，本地访问的数据～～～～
分布式缓存
大型网站数据量非常庞大，及时是一小部分的缓存，也不是单机能够承受的。

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

5、异步

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

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

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

6、冗余

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

冗余可以实现高可用。

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

7、自动化

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

8、安全

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

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

老陈是一个普通的文艺二逼青年

分类目录归档：架构

加密传输的一些知识点

JSON Web Token

一、简介

二、JWT的组成

2.1、header

2.2、payload

2.3、signature

三、适用场景

3.1、信息会暴露

3.2、会话凭证

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

web认证机制

1、 HTTP Basic Authentication认证

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

3、OAuth2

4、Cookie Auth

5、Token Auth

RPC服务 —— http

1、什么是RPC

2、基于HTTP的RPC服务

2.1、服务端

2.2、客户端

总结

网站架构模式

1、分层

2、分割

3、分布式

4、缓存

5、异步

6、冗余

7、自动化

8、安全

For The Dream

一、简介

二、JWT的组成

2.1、header

2.2、payload

2.3、signature

三、适用场景

3.1、信息会暴露

3.2、会话凭证

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

1、 HTTP Basic Authentication认证

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

3、OAuth2

4、Cookie Auth

5、Token Auth

1、什么是RPC

2、基于HTTP的RPC服务

2.1、服务端

2.2、客户端

总结

1、 分层

2、 分割

3、 分布式

4、 缓存

5、 异步

6、 冗余

7、 自动化

8、 安全

For The Dream

1、分层

2、分割

3、分布式

4、缓存

5、异步

6、冗余

7、自动化

8、安全