vpn原理

vpn原理

vpn采用的是双向网关结构，外网地址和内网地址，当外网主机a访问内网主机b时候，先进行vpn地址拨号，链接成功后，你访问你所在内网通过内网地址访问，如果访问别的内网通过vpn网络。这样当链接建立成功，所有进行的访问不论写别的内网的内网地址还是外网地址都可以进行访问。vpn就是虚拟专用网络，相当于内网和外网的链接通道。

NAT穿透

NAT是网络地址转换，即是通过少量公有ip地址进行端口映射到内部私有ip地址上，从而实现少量的公有ip地址就能代表较多的私有ip的方式

身份校验

HTTP提供了一套标准的身份验证框架：服务器可以用来针对客户端的请求发送质询(challenge)，客户端根据质询提供身份验证凭证。质询与应答的工作流程如下：服务器端向客户端返回401（Unauthorized，未授权）状态码，并在WWW-Authenticate头中添加如何进行验证的信息，其中至少包含有一种质询方式。然后客户端可以在请求中添加Authorization头进行验证，其Value为身份验证的凭证信息。

Form身份验证思路：（asp.net采用的身份验证方式）
假设用户要浏览需要权限的页面，此时，安全机制先启动，检查当前用户请求是否持有用户票据的Cookie，如此Cookie存在：解析Cookie中的票据信息，获得用户角色，创建用户标识，否则：认为用户无权浏览该页面，跳转至登入页面，登入成功后重定向到所请求页面

HTTP标准验证方案中，比较熟悉的是"Basic"和"Digest"，前者将用户名密码使用BASE64编码后作为验证凭证，后者是Basic的升级版，更加安全，因为Basic是明文传输密码信息，而Digest是加密后传输。还有Oauth验证，cookie验证，token验证。

Basic认证：用户名密码使用BASE64编码后作为验证凭证

Digest认证: 用户名密码使用BASE64编码加密后作为验证凭证
WWW-Authentication：用来定义使用何种方式（Basic、Digest、Bearer等）去进行认证以获取受保护的资源
realm：表示Web服务器中受保护文档的安全域（比如公司财务信息域和公司员工信息域），用来指示需要哪个域的用户名和密码
qop：保护质量，包含auth（默认的）和auth-int（增加了报文完整性检测）两种策略，（可以为空，但是）不推荐为空值
nonce：服务端向客户端发送质询时附带的一个随机数，这个数会经常发生变化。客户端计算密码摘要时将其附加上去，使得多次生成同一用户的密码摘要各不相同，用来防止重放攻击
nc：nonce计数器，是一个16进制的数值，表示同一nonce下客户端发送出请求的数量。例如，在响应的第一个请求中，客户端将发送“nc=00000001”。这个指示值的目的是让服务器保持这个计数器的一个副本，以便检测重复的请求
cnonce：客户端随机数，这是一个不透明的字符串值，由客户端提供，并且客户端和服务器都会使用，以避免用明文文本。这使得双方都可以查验对方的身份，并对消息的完整性提供一些保护
response：这是由用户代理软件计算出的一个字符串，以证明用户知道口令
Authorization-Info：用于返回一些与授权会话相关的附加信息
nextnonce：下一个服务端随机数，使客户端可以预先发送正确的摘要
rspauth：响应摘要，用于客户端对服务端进行认证
stale：当密码摘要使用的随机数过期时，服务器可以返回一个附带有新随机数的401响应，并指定stale=true，表示服务器在告知客户端用新的随机数来重试，而不再要求用户重新输入用户名和密码了

cookie机制：
Cookie认证机制就是为一次请求认证在服务端创建一个Session对象，同时在客户端的浏览器端创建了一个Cookie对象；通过客户端带上来Cookie对象来与服务器端的session对象匹配来实现状态管理的。默认的，当我们关闭浏览器的时候，cookie会被删除。但可以通过修改cookie 的expire time使cookie在一定时间内有效；

token机制：
通过设置token来区分用户，在Authorization中设置token来达到身份验证的功能，所以token支持跨域。

oauth是一套授权机制，它的标准是RFC6749文件。OAuth 引入了一个授权层，用来分离两种不同的角色：客户端和资源所有者。…资源所有者同意以后，资源服务器可以向客户端颁发令牌。客户端通过令牌，去请求数据。
oauth的授权机制有四种，第一个是授权式采用的方法是通过a向b发起一个请求，response_type=code，b同意后返回code，code就是授权码，a用授权码去拿令牌，grant_type=authorization_code，code=AUTHORIZATION_CODE，再发送请求，b再根据redirect_uri返回一个json串，里面的access_token就是令牌。
第二种隐藏式就是response_type=token无授权码环节直接返回令牌access_token，这种是根据用户的用户名和密码登陆后来生成access_token的。
第三种密码式就是a直接发送用户名和密码，然后b把令牌放在json中返回。
第四种凭证式grant_type=client_credentials，a向b发起请求，b返回令牌，此时令牌是针对第三方的不是针对用户，所以会产生多个用户共用一个令牌的现象。

bearer token规范：RFC6750
描述在HTTP访问OAuth2保护资源时如何使用令牌的规范，特点在于令牌就是身份证明，在请求的Authorization中进行定义。

json web token规范：（RFC 7519）jwt.io，用来访问oAuth2保护资源时定义令牌的结构。
Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准[RFC7519(https://tools.ietf.org/html/rfc7519)。该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。
令牌的具体定义方式，规定了令牌由三部分构成 -头。载荷。签名，头包含加密算法 令牌类型等信息，载荷包含用户信息 签发时间和过期时间等信息，签名根据头 载荷及密钥加密得到的哈希串 默认HS256，采用明文，头和载荷base64可以解码，不可以放敏感信息,token可以防篡改。
载荷中的内容：
iss: 该JWT的签发者，是否使用是可选的；
sub: 该JWT所面向的用户，是否使用是可选的；
aud: 接收该JWT的一方，是否使用是可选的；
exp(expires): 什么时候过期，这里是一个Unix时间戳，是否使用是可选的；
iat(issued at): 在什么时候签发的(UNIX时间)，是否使用是可选的；
其他还有：
nbf (Not Before)：如果当前时间在nbf里的时间之前，则Token不被接受；一般都会留一些余地，比如几分钟；，是否使用是可选的；

错误校验

try,catch只能进行一次错误的捕获，当错误较深入时，比如错误中再次出现错误的时候就不能进行捕获，
采用go语法，将错误和值一起返回，如果错误不存在则打印值得操作，if err != nil {},这种情况可以进行较深的错误的捕获，但是重复代码量过多，导致err != nil这句语法重复率过高，而且很容易漏写，如果哪里漏写了，后面的错误也会导致无法捕获
采用promise的catch方法对所有的异常进行一个统一的捕获，不论这个错误是出现在结果还是出现在错误，catch方法会统一返回这个错误，并对于错误执行一个统一的解决方案，缺点在于catch方法绑定在promise的原型上,所以需要返回一个promise实例。