Home产品研发web大型网站技术架构-学习摘要

大型网站技术架构-学习摘要

2021 年 3 月 19 日

[TOC]

《大型网站技术架构 核心原理与案例分析》。 作者：李智慧 贴合工程实践，都是工作中的内容总结，非常实在。

第1篇 概述

1 大型网站架构演化

不同服务器对硬件的要求：

  1. 应用服务器: 需要处理大量业务逻辑，因此需要更快更强大的CPU。
  2. 数据库服务器: 需要快速磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存。
  3. 文件服务器：需要存储大量用户上传的文件，因此需要更大的硬盘。

image-20201227234130151

驱动技术发展的动力是业务发展。

2. 大型网站架构模式

用好模式的关键是对于问题是否真正理解和把握

问题：高并发访问、海量数据处理、高可靠运行。

目标：高性能、高可用、易伸缩、可扩展、安全

解决方案：

  1. 分层。横向分层。应用层 调用 服务层，服务层调用数据层。在网站规模很小时就应该采用分层的架构，这样将来网站做大时才能有更好的应对。

  2. 分割。纵向分开。其实就是对应微服务。包装成高内聚低耦合的模块单元，方便开发维护和扩展。也可以说是单一职责的延伸。

  3. 分布式。主要是单机资源总数有限的，分割后的模块会分布到不同的服务器，通过http或rpc相互调用。这一定会带来以下问题：

    1. 影响性能。通过网络调用肯定比调用本地函数慢很多。
    2. 可用性降低。服务器越多，有机器宕(dang4)机的概率一定增大。
    3. 正确性降低。分布式环境比较难保持数据一致性。这也是分布式环境讲究最终一致性的原因。
    4. 开发管理维护困难。各种服务之间的依赖复杂，比较难管理。

    常见的分布式有：分布式应用和服务、分布式静态资源(cdn)、分布式数据和存储(redis集群)、分布式计算(hadoop,mapreduce)、分布式配置(Apollo)、分布式锁(单机资源竞争用锁，多机资源竞争用这个)、分布式文件系统。

  4. 集群。就是防止单点故障的，同一个功能至少部署2个服务器，挂掉一个服务器，还能对外提供服务。不影响使用。提供高可用性的。

  5. 缓存：为高性能服务。有CDN、反向代理、本地缓存、分布式缓存。

  6. 异步：降低耦合的，有利于扩展新新功能，提高系统可用性，能加快网站响应速度，可以消除并发访问高峰。需要产品设计方面的支持

  7. 冗余：集群其实就是种冗余，也是为了支持高可用的。数据库最好做冷备，也做主从分离，实现热备。

  8. 自动化：发布，监控等。支持高可用的。防止人工失误。

  9. 安全：防XSS攻击，SQL注入,CSRF攻击。

3. 大型网站核心架构要素

1. 性能:

加缓存。合并请求，多域名提高并发度，使用CDN, 多线程，优化内存管理，数据库加索引，SQL优化等等。

2. 可用性:

高可用性设计的目标就是当服务器宕机时，服务或者应用依然可用。有个事实，就是一定会有服务器宕机。

主要手段就是冗余, 还需要软件开发过程中的质量保证。通过预发布验证、自动化测试、自动化发布、灰度发布等手段，减少将故障引入线上环境的可能。

3.伸缩性

就是指可以通过加服务器的方式解决高并发访问和存储海量数据。

对于缓存服务器集群，加入新的服务器可能会导致缓存路由失效，影响网站性能。此时需要改进缓存路由算法保证缓存数据的可访问性。譬如采用一致性哈希算法

关系数据库很难实现大规模的可伸缩性，必须在数据库之外实现，通过路由区分等手段将部署有多个数据库的服务器组成一个集群。也就是分库。

大部分NoSQL数据库产品，本身对伸缩性支持就很好。

4. 扩展性

针对功能需求。网站架构能快速响应需求变化，是可扩展性架构的主要目的。

主要手段是事件驱动架构和分布式服务。

主要指消息队列和微服务。

5. 安全性

保证网站不被恶意访问和攻击，保护网站的重要数据不被窃取。

第2篇 架构

4. 瞬时响应：网站的高性能架构

网站性能测试

不同视角下的网站性能

  1. 用户角度的网站性能

    用户感受到的时间，包括用户计算机和网络服务器通信的时间、网站服务器处理的时间、用户计算机浏览器构造请求解析响应数据的时间。

    前端优化手段：

    1. 优化页面html样式
    2. 利用浏览器端的并发和异步特性。(多域名。async, defer)
    3. 调整浏览器缓存策略。http协议
    4. 使用cdn
    5. 使用反向代理
  2. 开发人员角度的网站性能

    开发人员关心的是应用程序本身及其子系统的性能，包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等技术指标。

    主要优化手段：

    1. 加缓存
    2. 使用集群提高吞吐能力
    3. 使用异步消息加快请求响应及实现削峰
    4. 代码优化
  3. 运维人员角度的网站性能

    运维人员关心基础设施性能和资源利用率。

    主要优化手段：

    1. 建设优化骨干网
    2. 使用高性价比定制服务器
    3. 利用虚拟化技术优化资源利用

性能测试指标

  1. 响应时间
操作 响应时间
打开一个网站 几秒
在数据库中查询一条记录(有索引) 十几毫秒
机械磁盘一次寻址定位 4毫秒
从机械磁盘顺序读取1MB数据 2毫秒
从SSD磁盘顺序读取1MB数据 0.3毫秒
从远程分布式缓存Redis读取一个数据 0.5毫秒
从内存中读取1MB数据 十几微秒
Java程序本地方法调用 几微秒
网络传输2KB数据 1微秒

(部分数据来源：http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html)

  1. 并发数

  2. 吞吐量

    TPS: 每秒事务数

    HPS: 每秒http请求数

    QPS: 每秒查询数

    响应时间，并发数，吞吐量，三者之间的关系可以形象地理解为高速公路的同行状况：吞吐量是每天通过收费站的车辆数目（可以换算成收费站收取的高速费），并发数是高速公路上的正在行驶的车辆数目，响应时间是车速。

  3. 性能计数器

    它是描述服务器或操作系统性能的一些数据指标。包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等指标。这些指标也是系统监控的重要参数。

    System Load即系统负载，指当前正在被CPU执行和等待被CPU执行的进程数据总和。System Load=CPU个数是理想值，既不忙，也不空闲。

性能测试方法

性能测试是一个总称，具体可细分为性能测试、负载测试、压力测试、稳定性测试

性能测试是一个不断对系统增加访问压力，以获得系统性能指标、最大负载能力、最大压力承受能力的过程。如图所示：

WechatIMG26

性能测试报告

测试结果报告需要反馈上述测试曲线的规律。

性能优化策略

性能分析: 检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超过预期；然后检查监控数据，分析影响性能的主要因素是内存、磁盘、网络、还是CPU, 是代码问题还是架构设计不合理，或者系统资源确实不足。

性能优化：web前端性能优化、应用服务器性能优化、存储服务器性能优化。

Web前端性能优化

浏览器访问优化

优化方法：

  1. 减少http请求: 合并css,javascript,图片。
  2. 使用浏览器缓存：设置http头中的Cache-Control和Expires属性。 静态文件更新后可通过改名来刷新浏览器的缓存。最好是分批更新, 避免集中更新缓存，造成服务器负载骤增、网络堵塞的情况。
  3. 启用压缩: 可以降低通信传输的数据量。。不过同时会增加cpu消耗。
  4. CSS放在页面最上面、Javascript放在页面最下面： 浏览器下载玩css才会渲染。下载javascript会阻塞整个页面。
  5. 减少Cookie传输： 可以考虑静态资源使用独立域名访问，避免请求静态资源时发送Cookie, 减少Cookie传输的次数。

CDN加速

反向代理

应用服务器性能优化

分布式缓存

网站性能优化第一定律：优先考虑使用缓存优化性能。

  1. 缓存的基本原理。 就是hash表。缓存主要用来存放那些读写比很高、很少变化的数据。
  2. 合理使用缓存
    1. 频繁修改的数据 不适合使用缓存，读写比在2:1以上才有意义
    2. 没有热点的访问 缓存之后不再访问，光占用资源没好处。
    3. 数据不一致与脏读。看业务需求，一般可以容忍一点延迟。不能容忍的话，就得在数据更新时立即更新缓存，这会带来更多的系统开销和事务一致性问题。
    4. 缓存可用性。。缓存丢了，不应该影响业务的正确性。他需要可以从数据库恢复过来。缓存不应该当成一个可靠的数据源来使用。
    5. 缓存预热 可以在缓存系统启动时把热点数据加载好，这叫缓存预热，可以通过模拟业务请求来实现。
    6. 缓存穿透 当缓存不存在时，每次都访问数据库，给数据库制造压力。解决方案是将不存在的数据也缓存起来。
  3. 分布式缓存架构
    1. 一类是jboss cache这类，需要同步更新数据。
    2. 一类是memcached这类，各存各的，不需要同步数据。需要采用一致性Hash算法来避免增减服务器带来的影响。
  4. Memcached
    1. 简单的通信协议 远程通信协议需要考虑2个问题。1是通信协议，TCP/UDP/HTTP 2是通信序列化协议。Memcached使用TCP协议(也支持UDP)通信，序列化协议是一套基于文本的自定义协议。
    2. 丰富的客户端程序。流行的编程语言都支持
    3. 高性能的网络通信 服务端通信模块基于Libevent, 一个支持事件触发的网络通信程序库。
    4. 高效的内存管理 固定空间分配。slab_class -> slab -> chunk 。以chunk为单位分配内存。优点是没内存碎片管理问题，缺点是有内存浪费。
    5. 互不通信的服务器集群架构

异步操作

消息队列

使用集群

代码优化

  1. 多线程： 使用多线程的原因主要是两个： IO阻塞与多CPU。

启动线程数 = CPU个数比较好

编程上解决线程安全的主要手段有如下几个：

  1. 将对象设计为无状态对象
  2. 使用局部对象
  3. 并发访问资源时使用锁
  1. 资源复用: 两种模式： 单例模式 和 对象池。
  2. 数据结构： 比较好的字符串Hash散列算法有Time33 算法。hash(i) = hash(i-1) * 33 + str[i] 更好的方式是 原始字符串-> md5 -> Time33.
  3. 垃圾回收 理解编程语言的垃圾回收机制可以写出更好的代码。

存储性能优化

机械硬盘 vs 固态硬盘

WechatIMG27

机械硬盘由于访问数据需要移动磁头臂，不利于随机访问数据。

固态硬盘，没有机械装置，数据存储在可持久化记忆的晶体硅上，性能比机械硬盘高很多，但出了故障不能修复数据。

B+树 vs LSM树

B+树是一种专门针对磁盘存储而优化的N叉排序树。

目前数据库多采用两级索引的B+树，树的层次最多3层。因此可能需要5次磁盘访问才能更新一条记录(三次磁盘访问获得数据索引及行ID, 然后再进行一次数据文件读操作及一次数据文件写操作。)

目前许多NoSQL 产品采用 LSM 树做为主要数据结构。LSM树可以看作是一个N阶合并树。

RAID vs HDFS

WechatIMG28

hdfs 通过软件层面做了备份。

5. 万无一失：网站的高可用架构

网站可用性的度量和考核

网站可用性度量

网站故障时间 = 故障修复时间点-故障发现时间点

2个9，年度不可用时间<88小时；

3个9，年度不可用时间<9小时；

4个9，年度不可用时间<53分钟；

5个9，年度不可用时间<5分钟；

网站可用性考核

可用性指标是网站架构设计的重要指标，对外是服务承诺，对内是考核指标。

image-20210312084534395

高可用的网站架构

网站设计通常是分层设计，分为应用层，服务层，数据层。

高可用的应用

  1. 通过负载均衡进行无状态的失效转移
  2. 应用服务器集群的Session管理。可参考session vs jwt

高可用的服务

  1. 分级管理: 按重要程度分级，重要的用更好的硬件，出故障优先处理。部署时部署必要的隔离，重要的基础的服务使用单独的硬件。
  2. 超时设置: 在应用程序中设置服务调用的超时时间，一旦超时，通用框架就抛出异常，应用程序根据服务调度策略，可选择继续重试或将请求转移到提供相同服务的其他服务器上。
  3. 异步调用：非关键业务可通过消息队列的异步方式完成，避免一个服务失败导致整个应用请求失败的情况。
  4. 服务降级: 流量过大时可流量降级，有两种方式：拒绝服务和关闭服务。这个和分级管理有关联。需要定义服务级别。
    1. 拒绝服务： 拒绝低优先级应用的调用，减少服务调用并发数，确保核心应用正常使用；或者随机拒绝部分请求。
    2. 关闭服务：关闭不重要的服务，或服务内部关闭不重要的功能。
  5. 幂等性设计: 服务重复调用是无法避免的。因此必须在服务层保证服务重复调用和调用一次产生的结果相同，即服务具有幂等性。

高可用数据

可用手段就是数据备份和失效转移机制。

CAP原理

数据持久性: 保证数据可持久存储，在各种情况下都不会出现数据丢失问题。 需要备份 –P

数据可访问性: 在有多份数据副本时，如果一个数据存储设备损坏，就需要将数据访问切换到另一个数据存储设备上，如果这个过程不能很快完成（终端用户几乎没有感知），或者在完成过程中需要停止终端用户访问数据，那么这段时间数据就是不可访问的。–A

数据一致性: 在数据有多份副本的情况下，如果网络、服务器或软件出现故障，会导致部分副本写入成功，部分副本写入失败。这就会造成各个副本之间的数据之间的数据不一致，数据内容冲突。–C

CAP原理认为，一个提供数据服务的存储系统无法同时满足数据一致性(Consistency)、数据可用性(Availibility)、分区耐受性(Partition Tolerance, 系统具有跨网络分区的伸缩性)这三个条件。

image-20210317083943339

一般都是选择保证A和P,而在某种程度上放弃一致性(C)。

应用系统需要对分布式数据处理系统的数据不一致性有所了解并进行某种意义上的补偿和纠错，以避免出现应用系统数据不正确。

数据一致性又可分为如下几点：

数据强一致 各个副本的数据在物理存储中总是一致的。

数据用户一致：即数据在物理存储中的各个副本中的数据可能是不一致的，但是终端用户访问时，通过纠错和校验机制，可以确定一个一致的且正确的数据返回给用户。

数据最终一致:存储中的数据可能是不一致的，终端用户访问到的数据可能也是不一致的，但系统经过一段时间（通常是一个比较短的时间）的自我恢复和修正，数据最终会达到一致。

数据备份

早期是冷备：定期将数据复制到某种存储介质。优点是简单和廉价，成本和技术难度都较低。缺点是不能保证数据最终一致。由于恢复数据的时间较长，也不能保证数据可用性。

数据热备可分为两种：异步热备方式和同步热备方式。

异步热备：写操作只更新主存储服务器，异步第写其他副本。

同步热备：多份数据副本的写入操作同时完成。多线程写，时间为写入较慢的那台服务器。性能和异步热备差不多。

失效转移

失效转移操作由3部分组成：失效确认、访问转移、数据恢复。

  1. 失效确认： 2种手段：心跳检测和应用程序访问失败报告。
  2. 访问转移: 将数据读写访问重新路由到其他服务器上。如果存储是不对等的，那么就需要重新计算路由，选择存储服务器。
  3. 数据恢复: 因为某台服务器宕机，所以数据存储的副本数目会减少，必须将副本的数目恢复到系统设定的值，否则，再有服务器宕机时，就可能出现无法访问转移（所有服务器都宕机了），数据永久丢失的情况。

高可用网站的软件质量保证

网站发布

网站的发布过程事实上和服务器宕机效果相当，其对系统可用性的影响也和服务器宕机类似。

image-20210317142845913

自动化测试

Web自动化测试，主要是用Selenium。

预发布验证

就是在线上选台服务器，不放到负载均衡里面，通过host配置访问，得到和线上一样的环境。

测试通过再正式上线。

代码控制

  1. 主干开发，分支发布
  2. 分支开发，主干发布。 主干开发、分支发布方式，主干代码反应目前整个应用的状态，一目了然，便于管理和控制，也利于持续继承（适合团队小）。 分支开发，主干发布方式，各个分支独立进行，互不关扰，可以使不同发布周期的开发在同一应用中进行，适合并行开发。（团队较大，产品复杂）

自动发发布

可以减少人为错误

灰度发布

这种手段也被称为AB测试。

不整体发布发布，一部分一部分发布，出问题时方便回滚。

网站运行监控

监控数据采集

  1. 用户行为日志收集
    1. 服务器端日志收集： 就是nginx日志
    2. 客户端浏览器日志收集：嵌入javascript脚本。通过js收集。
  2. 服务器性能监控：系统load、内存占用、磁盘IO、网络IO等
  3. 运行数据报告：业务相关的，譬如缓存命中率，api平均响应时间等。需要程序统计。

监控管理

  1. 系统报警
  2. 失效转移
  3. 自动优雅降级

6. 永无止境：网站的伸缩性架构

网站架构的伸缩性设计

一般来说，网站的伸缩性设计可分为两类，一类是根据功能进行物理分离实现伸缩，一类是单一功能通过集群实现伸缩。

不同功能进行物理分离实现

纵向分层：抽离基础服务。基础服务用单独的服务器。

横向分层（业务分割后分离）：不同的业务放到不同的服务器上。

单一功能通过集群规模实现伸缩

  1. 应用服务器集群伸缩性
  2. 数据服务器集群伸缩性
    1. 缓存数据服务器集群
    2. 存储数据服务器集群

应用服务器集群的伸缩性设计

HTTP重定向负载均衡

就是服务器返回302重定向的新的地址。

优点是比较简单。

缺点：

  1. 浏览器需要两次请求服务器才能完成一次访问，性能较差。
  2. 重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限
  3. 使用HTTP302响应码重定向，有可能使搜索引擎判断为SEO作弊，降低搜索排名。

由于以上缺点，很少使用。

DNS域名解析负载均衡

在DNS服务器中配置多个A记录，如: www.mysite.com IN A 114.100.80.1、 www.mysite.com IN A 114.100.80.2、 www.mysite.com IN A 114.100.80.3

每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回，这样A记录中配置的多个服务器就构成一个集群，并可以实现负载均衡。

优点：

  1. DNS负责负载均衡，省掉了网站管理员维护负载均衡服务器的麻烦
  2. 许多DNS支持基于地理位置的解析，可以返回距离用户最近的IP, 提升性能。

缺点:

  1. 由于DNS是多级的，各级都有缓存，修改后，并不能及时更新下线的A记录，导致用户访问已经失效的IP地址，方式失败。
  2. 对应优点1， 就是自己没法管理

实际使用： DNS做为一级负载均衡。指向的IP地址是二级负载均衡地址。

反向代理负载均衡

经典的如nginx。需要配置双网卡和内网外网两套IP地址。

由于反向代理服务器转发请求在HTTP协议层面，因此也叫应用层负载均衡。

优点：

部署简单

缺点：

反向代理服务器是所有请求和响应的中转站，其性能可能会成为瓶颈。

IP负载均衡

在网络层通过修改请求目标地址进行负载均衡

image-20210318081550714

2种方式：

  1. 负载均衡服务器在修改目的IP地址的同事修改源地址，将数据包设为自身的IP, 即源地址转换(SNAT)
  2. 负载均衡服务器同时作为网关服务器。

优点：

IP负载均衡在内核进程上完成数据分发，性能更高

缺点：

所有响应都要经过IP负载均衡服务器，集群的最大响应数据吞吐量不得不受制于负载均衡服务器网卡带宽。

数据链路层负载均衡

数据链路负载均衡是指在通信协议的数据链路层修改mac地址进行负载均衡。

image-20210318082251266

这种数据传输方式又称做三角传输模式，可将相应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。

使用三角传输模式的链路层负载均衡是目前使用最广的一种负载均衡手段。最好的开源产品是LVS 源码

负载均衡算法

  1. 轮询(Round Robin, RR) 适合硬件资源相同的场景
  2. 加权轮询(Weighted Round Robin, WRR) 适合硬件资源不同的场景，硬件越好，权值越大。
  3. 随机(Random): 简单实用。即使硬件资源不同，也可以加权随机。
  4. 最少连接(Least Connections): 记录每个应用服务器正在处理的连接数，将新到的请求分发到最少连接的服务器上，这是最符合负载均衡定义的算法。最少连接算法也可以实现加权最小连接。
  5. 源地址散列(Source Hashing): 根据请求的IP地址进行Hash计算，这样来自同一个IP地址的请求总会在同一个服务器上处理，可以实现会话粘滞。

分布式缓存集群的伸缩性设计

Memcached分布式缓存集群的访问模型

Memcached分布式缓存集群的伸缩性挑战

分布式缓存的一致性Hash算法

具体可以参考一致性Hash算法

经验值：1个物理服务器虚拟成150个节点。

数据存储服务器集群的伸缩性设计

数据存储服务器必须保证数据的可靠存储，任何情况下都必须保证数据的可用性和正确性。

关系数据库集群的伸缩性设计

分库分表。分库的制约条件是跨库的表不能进行join操作。

比较成熟的支持数据分片的分布式关系数据库产品主要有Ameoba 和 Cobar

NoSQL数据库的伸缩性设计

一般而言，NoSQL数据库产品放弃了关系数据库的两大重要基础：以关系代数为基础的结构化查询语言(SQL)和事务一致性保证(ACID)。

7 随需应变：网站的可扩展架构

扩展性:

指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以做到敏捷响应。它是系统架构方面的开闭原则(对扩张开放，对修改关闭)

伸缩性:

指系统能够通过增加（减少）自身资源规模的方式增强（减少）自己计算处理事务的能力。

构建可扩展的网站架构

低耦合的系统更容易扩展，低耦合的模块更容易复用，一个低耦合的系统设计也会让开发过程和维护变得更加轻松和容易管理。

利用分布式消息队列降低系统耦合性

事件驱动架构

通过在低耦合的模块之间传输时间消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间的合作，典型的EDA(event driven architecture)架构就是常见的生产者-消费者模式。发布–订阅模式 可以1对多。

分布式消息队列

分布式消息队列可以很复杂，不如支持ESB(企业服务总线)、支持SOA(面向服务的架构)。

也可以很简单，譬如利用mysql实现。

利用分布式服务打造可服用的业务平台

就是值切分服务，微服务。

web service 与企业级分布式服务

过时的技术。

缺点：

  1. 臃肿的注册与发现机制
  2. 低效的XML序列化手段，
  3. 开销相对较高的HTTP远程通信。
  4. 复杂的部署与维护手段。

替代技术是restful api / rpc

大型网站分布式服务的需求与特点

除了服务注册与发现，服务调用等标准功能，还需要支持如下特性：

  1. 负载均衡
  2. 失效转移
  3. 高效的远程通信 grpc、hession
  4. 整合异构系统 多语言。通过api通信
  5. 对应用最少侵入
  6. 版本管理 需要支持多版本，都升完级之后才能关闭老接口。 go-zero 自动生成接口不错，很容易升级。
  7. 实时监控 支持Prometheus

分布式服务框架设计

可以学习go-zero

可扩展的数据结构

使用NoSQL, 支持变化的需求。

利用开放平台建设网站生态圈

image-20210319212222767

说明：

API接口： 是开放平台暴露给开发者使用的一组API, 其形式可以是RESTful、Webservice、RPC等各种形式。

协议转换：将各种API输入转换成内部服务可以识别的格式，并将服务内部的返回封装成API的格式。

安全：除了一般应用需要的身份识别、权限控制等安全手段，开放平台还需要分级的访问带宽限制。

审计：记录第三方应用的访问情况，并进行监控、计费等。

路由：将开放平台的各种访问路由映射到具体的内部服务。

流程：将一组离散的服务组织成一个上下文相关的新服务，隐藏服务细节，提供统一接口供开发者调用。

8 固若金汤：网站的安全架构

道高一尺魔高一丈的网站应用攻击与防御

XSS攻击

XSS攻击即跨站点脚本攻击(cross site script)。采用XSS攻击，偷取用户Cookie、密码等重要数据，进而伪造交易、盗窃用户财产、窃取情报。

一种是反射型： 引导用户点击嵌入恶意脚本的链接。

一种是持久性攻击： 就是发布的内容里嵌入了恶意脚本。

处理手段：

  1. 消毒。就是转移'<‘,’>’为html实体。
  2. HttpOnly: 加了后cookie 只能用于http传输，js无法访问。可以防止窃取Cookie。

注入攻击

注入攻击有SQL攻击和OS注入攻击。

SQL注入攻击就是利用漏洞构造sql语句，让服务器执行。 此攻击需要对数据库接口有所了解才行。

获取表结构的渠道有：

  1. 开源的系统 表结构是公开的。
  2. 错误回显 报错了。简单的处理就是不输出sql错误。
  3. 盲注: 利用不同输入产生不同输出来猜测验证。

处理手段：

  1. 消毒: 过滤请求中可能注入的SQL,
  2. 参数绑定: 使用预编译手段，绑定参数是最好的防SQL注入方法。 ORM框架基本都会支持。

CSRF攻击

CSRF(Cross Site Request Forgery, 跨站点请求伪造)，攻击者通过跨站请求，以合法用户的身份进行非法操作。其核心是利用浏览器Cookie或服务器Session策略，盗取用户身份。

防御手段：

  1. 表单Token 表单中加入随机的token，服务端验证token的有效性，验证失败说明是伪造的请求。
  2. 验证码 简单有效，但是影响用户体验。简单的验证码容易机器识别。
  3. Referer check: 验证refer, 一般用于防盗链。

其他攻击和漏洞

Error Code

HTML注释

文件上传

得验证文件类型，别让可执行文件传上去了。

路径遍历

办法：b将JS、CSS等资源文件部署在独立服务器、使用独立域名。

网站应用防火墙

ModSecurity

网站安全漏洞扫描

扫描工具定期扫描

Related Posts

About The Author

bjmayor

程序员，码农，php,python,ios,android,go，产品经理，创业。