系统优化和安全

最新推荐文章于 2024-09-05 13:49:08 发布

人才瘾大

最新推荐文章于 2024-09-05 13:49:08 发布

阅读量851

点赞数 25

文章标签：性能优化安全

本文链接：https://blog.csdn.net/liushuidehao/article/details/140884456

版权

1. 系统优化的思路

从用户发出请求到系统响应提供服务，这之间都能做优化。

思路1. 拆分，大事化小

1亿的流量，用100个能抗1百万流量的服务器去均摊。

思路2.前置处理，提前过滤流量

缓存数据。比如，确实只能抗100万流量，结果来了200万，就可以降级处理，在前端按百分比拒绝服务，友好提示人多。如果是后端其他服务如数据库的瓶颈，也可以前置缓存。

思路3.后置服务，时间换空间

削峰填谷，缓存请求。用消息队列、缓存、数据库等来缓存请求。

思路4.加快处理速度

代码优化，如使用多线程等。

2. 前端优化思路

减少不必要的传输：减少传输次数，减少每次传输的数据量。能前端做的前端做，能前端存的前端存，尽量靠前去处理。

不太经常变化的且不太重要和敏感的数据可以缓存在前端（如app或浏览器）；

前端自己可以计算的工作，让前端自己做，没必要跑到后端去做；

增加其他缓存，如CDN。

2.1. 减少传输

合并http请求，可以减少连接数，如合并js/css/图片等。
使用压缩，在服务端对资源压缩，在客户端解压。前提是网络不够，但cpu够。浏览器一般都支持请求的压缩和解压，客户端请求时在header里添加accept-encoding，服务端响应时在header里加content-encoding。也可以把图片先压缩，如直接转成base64。
减少cookie：静态资源不需要cookie也能访问，一般cookie是跟域名相关的，所以将静态资源放到单独的域名下，这样访问它们的时候就不会带上cookie了。

2.2. 缓存

2.2.1. 前端缓存

前端缓存里不要放敏感数据。

2.2.1.1. http缓存

在http的header里加。

cache-control控制是否允许缓存，可以缓存在所有还是单个用户设备。

缓存时长、缓存版本etag等。

缓存过期怎么办？更改文件名，服务端验证缓存的有效性。

2.2.1.2. 客户端缓存

浏览器里的localstorage（可以长期存储）、sessionstorage（会话结束后就没了）等。

一些android客户端里可以直接用sqlite。

3. DNS/CDN/负载均衡/网关

3.1. DNS优化

域名记录类型：

A地址：域名到ip的记录
cname：域名到域名的记录
NS：域名到DNS的记录

域名服务器的类型：

根域名服务器：全球数量有限，根域名服务器大部分在欧美
一级域名服务器：.com/.net/.org/...
二级域名服务器：.baidu/.qq/...

使用nslookup来查询域名解析。

DNS解析过程（以www.baidu.com为例）：

如果是浏览器发起的请求，会先去看浏览器有没有缓存这个域名解析，如果是其他客户端发起的请求，看看客户端是不是有自己的域名缓存，如果都没有，进入下一步；
查看操作系统有没有缓存该域名，如果没有，进入下一步；
查看hosts文件有没有配置，如果没有，进入下一步；
向LDNS询问域名解析，LDNS上如果缓存了该域名解析就直接使用，否则，进入下一步；
LDNS询问baidu.com二级域名服务器，如果有www.baidu.com的解析就使用，否则，进入下一步；
LDNS询问.com一级域名服务器，如果有就用，否则，进入下一步；
LDNS询问根域名服务器，如果有就用，否则，进入下一步；
找不到域名对应的地址。

dns支持地理位置解析，可帮助访问就近的服务。但dns有时效性问题，且dns一般是集群有多台机器，目标地址变了，需要一段时间才能把最新情况同步到所有服务器上。

一个域名可以配置多个ip，这样就相当于用DNS做了负载均衡了，一般在A记录上配置。

还可以做域名预解析，在html的<meta>标签里配置。一般不推荐用域名预解析，会浪费DNS公共资源。

3.2. CDN

一般缓存静态资源，客户端访问就近的CDN，减少网络延时。

CDN缓存的资源有时效，目的是保持缓存内容的有效性。

CDN一般是通过DNS的cname让用户请求就近访问的。当购买了CDN服务商的服务，在多地部署了CDN服务，用户请求会先到CDN的服务器，当发现是静态资源，就近访问存储了内容的服务器（如果就近服务器没有资源，会到源站去拉取）；当发现是非静态的，就到源站去访问。

CDN和注册中心有点像，都是访问一个服务时，先去一个统一的地方查该服务的地址，然后再访问真实的服务地址。

3.3. 代理

正向代理和反向代理，这个正反是站在用户角度说的。

用户访问服务：

正向代理是代理用户请求，帮用户买东西，在用户端配置；

反向代理是代理服务响应，帮服务卖东西，在服务端配置。

3.4. 路由转发的几种方式

路由转发的几种方式：

http重定向：应用层的。
ip层负载均衡：网络层的。一般用SNAT，即源地址转换。负载均衡器将收到的请求通过ip转发给目标服务器，转发时将源ip地址更改为负载均衡器的ip地址，这样目标服务器响应的时候就可以把响应发给负载均衡器，由它转发给源请求方。
数据链路层负载均衡（三角模式）：一般用LVS。负载均衡器和目标服务器对外的ip都是一样的，请求发到负载均衡器上，负载均衡器将包转给目标服务器，同时修改包的mac地址改为目标服务器的地址，这样，目标服务器的响应就可以不通过负载均衡器，直接发给源请求方。

3.5. 负载均衡算法

一般在发送心跳的时候，把自己的负载也一起上报。

平均轮询round robin
加权轮询
随机轮询
最小链接数
源地址散列

3.6. 网关

3.6.1. 网关的作用

协议转换
路由转发
负载均衡
安全

3.6.2. 网关安全

1. xss攻击

跨站点脚本攻击。通过注入脚本的方式，比如注入js脚本到前端页面。

对付的方式：

对特殊符号做转义，比如前端对接受到的将<script>转为&ltscript&gt，但这个可能会误杀；
使用带有HttpOnly的Cookie，让脚本不能读取带有HttpOnly的cookie，防止本地敏感信息被窃取。

2. SQL注入

一般泄露数据库信息通过以下两种方式：始终来源软件，代码是可以被看到的；错误提示没做好，把代码或堆栈等打印出来，被猜出来某些数据库结构。

对付的方式：

不要泄露数据库结构；
参数绑定，始终参数化查询，将用户输入作为参数，而不是直接拼装用户传入的值；
转义特殊字符；
使用白名单，只能传入预定义的一组值。

#{}：参数占位符，即预编译，可防止sql注入
${}：字符串替换符，即SQL拼接，可导致sql注入。

3. CSRF

CSRF是跨站点请求伪造。XSS是跨站点脚本攻击，利用站点内的信任用户，而CSRF则通过伪装成受信任用户请求受信任的网站。

CSRF的过程

客户端访问网站A，并从A得到了认证标识，比如cookie；
客户端未退出A，打开了网站B，网站B访问网站A（浏览器会自动带上A的cookie）。

Cookie不能跨域获取，但在发起对应域名请求的时候，浏览器会自动带上对应域名的Cookie。

举个例子：

超市门口，你（用户）把包暂存在柜子A里，柜子吐了一张带条码的纸给你，你把这张纸放到旁边桌子上，又打开柜子B，柜子B里爬出来一个贞子，她看不到纸上的内容，但可以拿着桌子上的纸打开柜子A，取走了你的包。你就被柜子B里的贞子CSRF攻击了。

要抵御 CSRF关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。

所以解决办法就是别把纸放在贞子能拿到的地方，或者加一些贞子无法获取的信息来验证。

解决的办法有几个

你打开B前，先把A打开，取走里面的东西。相当于是要求用户在访问B网站前，每次都要记得先退出A网站。这是要求用户做事，不太可行。
把你的手放到那个纸上，那个纸上只能放一个手，要么是你的，要么是贞子的，当放的是你的时候，A可以开门，当放的是贞子或没放的时候开不了门。对应的实现就是用referer的值，这种一般都是浏览器自己加的，而且加的就是当前浏览的域名。但是如果某些浏览器有漏洞，这个值就可能被篡改。
如果贞子爬到你的手上，她也可以直接打开柜子。这就是同源发起CSRF攻击，比如攻击者有权在某些论坛上发布的评论。
柜子A打开时，除了给你一张纸条，还会在你手心里写个密码，下次开门需要这两个东西都对得上。所以只要你不把手心给贞子看到，你的柜子还是安全的。对应的实现就是第一次访问A网站时，A网站生成一个token，这个token就不要放在不安全的cookie上了，而是写在它html的dom树上的每个链接上，下次这个页面发起请求的时候就会带上这个token，这个token跟服务端做校验即可。
柜子A要打开，除了要用到那个纸，还会发个验证码给你的手机，你需要输入这个验证码才行。