大型网站技术架构 读书笔记2 核心架构要素

网站架构技术的核心架构要素

  本部分是本书的重点，涉及书中第3章到第8章6个章节的内容，占了全书内容的大半篇幅。其中第三章是后面五章的概述和总结，而第四到第八章则分别介绍了性能、可用性、伸缩性、扩展性和安全性这五大核心架构要素。

  对于一个软件系统来说，其单一系统功能需求的实现虽然也不容易，这部分内容可以参照代码大全这本书；但其在系统中的位置及和其他模块的关系更需要注意，设计不好则会大大增加系统的复杂性。好在，在网站架构方面，有大量的模式可以借鉴，参照笔记1。在架构设计过程中，需要注意的另一大因素就是平衡好上述五大核心架构要素的关系以实现需求和架构目标；也可以通过考察这些架构要素来衡量一个软件架构设计的优劣，判断其是否满足期望。

  下面将就五大核心架构要素一一展开说明，每个架构要素都有可能涉及到笔记1中所谈到的模式。这也是本书的一大特点，各个知识点之间耦合度比较高，难以解耦。

  由于本篇内容过多，会在介绍下面五个核心要素前，分别给出这五个部分的超链接，提供独立访问，可选择有兴趣的部分进行阅读，超链接后面再附上所有五个核心要素的全文，共约1万字，个人建议分开阅读。

  笔记2.1：核心架构要素之高性能

  笔记2.2：核心架构要素之高可用

  笔记2.3：核心架构要素之可伸缩

  笔记2.4：核心架构要素之可扩展

  笔记2.5：核心架构要素之安全

---

  下面是全文：

---

一 网站的高性能架构

  主要问题：在用户高并发访问时，会产生很多网站性能问题；所以，网站高性能架构或者说网站性能优化的主要工作是改善高并发访问情况下的网站响应速度。

  网站性能：性能这个词涉及到的面是相当大的。它既有着自己的客观指标，也涉及用户的客观感受；而且，在不同视角下，各方的关注点也不一样。本部分的主要内容就是如何构建一个高性能的网站；通过分析不同层面下的网站优化措施，从而实现在性能测试的前提下进行针对性优化。

---

1.1 不同视角下的网站性能

  在不同视角下，各方的关注点不一样；不同视角下的网站性能标准不同，优化手段也不同。

1 用户视角下的网站性能：

  从用户角度，网站性能就是用户在浏览器上直观感受到的网站响应速度。这里的性能除了与请求的服务，服务端响应速度之外；还与客户端机器、浏览器和网络带宽等有关。

  性能优化：这里的优化主要是优化用户感官。使用前端架构优化手段，使浏览器尽快地显示客户感兴趣的内容、尽可能近地获取页面内容，从而改善客户视角下的网站性能。

2 开发人员视角的网站性能

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

  性能优化：使用缓存加速数据读写；使用集群提高吞吐能力；使用异步消息加快请求响应以及削峰，使用代码优化改善程序性能。

3 运维人员视角的网站性能

  从运维人员角度，网站性能就是基础设施性能的资源利用率。

  性能优化：建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用。

---

1.2 网站性能测试

  性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。

1.2.1 性能测试指标

1. 响应时间

  定义：指应用执行一个操作需要的时间，包括从发出请求开始到受到最后响应的时间。响应时间是系统最重要的性能该指标，直观地反映了系统的快慢。

2.并发数

  定义：指系统能够同时处理请求的数目，反映了系统的负载特性。对于网站而言，并发数即网站并发用户数，即同时提交请求的用户数。

  与人数有关的数据还有网站注册用户数和网站在线用户数，其中

网站注册用户数 >> 网站在线用户数 >> 网站并发用户数

  作用：在网站设计初期，运营团队需要根据自身产品对用户数进行推断，并以此作为系统非功能设计的重要依据。

3. 吞吐量

  定义：指单位时间内系统处理的请求数量，体现系统的整体处理能力。

  衡量指标：TPS——每秒事务数(最常用量化指标)；HPS——每秒HTTP请求数；QPS——每秒查询数。

  并发数、吞吐量、响应时间关系：在系统并发数从小到大过程中，系统吞吐量先逐步上升，响应时间小幅上升；达到一个极限后，吞吐量下降，响应时间快速上升；达到系统奔溃点后，系统资源耗尽，吞吐量为零，系统失去响应。

4.性能计数器

  定义：描述服务器和操作系统性能的一些数据指标。

  指标：系统负载——当前正在被CPU执行和等待被CPU执行的进程数目总和；内存使用、CPU使用

1.2.2 性能测试方法

  分类：性能测试是总称，可细分为性能测试，负载测试，压力测试和稳定性测试。

  定义：性能测试是一个不断对系统增加访问压力(增加并发请求数)，以获得系统性能指标，最大负载能力，最大压力承受能力的过程。

  关键位置：系统最大负载点，系统奔溃点

1.2.3 基于性能测试的性能优化策略

  如果性能测试结果不能安祖设计或业务需求，就需要寻找系统瓶颈，分而治之，逐步优化。

  性能分析：对用户从浏览器发出请求到数据库完成操作事务的整个经历的各个环节进行分析，排查可能出现性能瓶颈的地方，定位问题。

  性能分析手法：1.检查日志，跟预期进行对比；2.检查监控数据，对影响性能的主因进行分析。

  性能优化：定位问题后，就可以针对性地优化。根据网站分层架构，优化可分为Web前端性能优化、应用服务器性能优化和存储服务器性能优化这三块。下面分三节进行讲解。

---

1.3 Web前端性能优化

  Web前端指网站业务逻辑之前的部分，包括浏览器加载、网站视图模型、图片服务和CDN服务等，优化手段分以下三块讲演。

1.3.1 浏览器访问优化

  1. 减少HTTP请求：通过将请求所需的JavaScript和CSS合并成一个文件及图片合并等减少请求数。

  2. 使用浏览器缓存：在客户端本地保存缓存

  3. 启动压缩： 在服务器端对响应内容进行压缩，客户端解压，有效减少通信量。

  4. CSS在最上面，JavaScript在最下面：使得渲染最先进行，JavaScript最后被执行。

  5. 减少Cookie传输：减少Cookie中传输的数据量；并用独立域名部署静态资源，从而避免Cookie传输。

1.3.2 CDN加速

  笔记1中已经简单介绍过CDN，CDN一般缓存被高频访问的静态资源，如图片、文件、CSS、Script脚本、静态网页等。

1.3.3 反向代理

  作用：1. 位于Web服务器之前，建立屏障，有利于安全；2. 通过配置缓存加速Web请求；3. 实现负载均衡的功能。

  机制：当用户第一次访问某资源时，将该资源缓存在反向代理服务器上；这样其他用户就可以直接从反向代理服务器上获取该资源。对于反向代理中的动态内容，通过内部通知机制重新加载并缓存。

---

1.4 应用服务器性能优化

  应用服务器处理网站业务；这里部署了网站的业务代码，是网站开发最复杂，最多变的地方；优化手段主要有缓存、集群、异步等。

1.4.1 分布式缓存

  在网站应用中，缓存几乎无处不在；也近乎无所不能。

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

  缓存的定义和使用前提在笔记1中已经提及：

缓存：将数据放在举例计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段。
缓存的两大前提：1. 数据访问热点不均匀；2. 数据在某个时间段内有效

  缓存优势：1. 访问速度快；2. 无需重复计算，直接访问结果

  缓存的存储：缓存的本质是一个内存Hash表，数据缓存以一对Key、Value的形式存储在内存Hash表中；其读写复杂度均为O(1)。

  缓存用途：存放读写比很高、变化少的数据。

  缓存虽好，也不能滥用，以下是使用缓存需要注意的一些方面：

  1. 对于频繁修改的数据和没有热点的访问，不要使用缓存；

  2. 数据不一致与脏读：对于缓存数据会设置失效时间，则在这个时间内更新数据会存在数据不一致，但会保证最终一致；使用缓存立即更新策略可以解决该问题，但会带来更多问题。

  3. 缓存可用性：在稳定访问情况下，缓存会负载大部分数据库访问压力；若缓存服务器大量崩溃可能导致数据器访问压力过大而宕机，导致网站整体不可用。

  4. 缓存预热：对新启动的缓存服务器在启动前直接加载好热点数据，而不是使用LRU算法进行更新淘汰，提高系统性能。

  5. 缓存穿透：保存不存在的数据，防止对不存在的业务或不存在的数据进行高并发访问，使得数据库压力很大。

  分布式缓存：缓存部署在多个服务器组成的集群中，以集群的方式提供缓存服务。

  分布式缓存架构JBoss Cache：在集群中所有服务器中保存相同的缓存数据，更新时同步更新。受限于单台服务器内存空间，且同步代价较大。

  分布式缓存架构Memcached：缓存与应用独立部署。memcached客户端部署在应用服务器上，并通过一致性hash等路由算法选择memcached缓存服务器对缓存数据进行远程访问，缓存服务器之间不通信，集群规模可以轻松扩容，伸缩性好。其内存管理使用固定空间分配，以chunk为单位，避免内存碎片。

1.4.2 异步操作

  操作：通过消息队列将调用异步化，以改善网站的性能。1. 在用户数据写入时，消息队列服务器在获取数据后直接返回响应，再写入数据；2. 在短时间高并发时，将事务缓存在消息队列中，从而实现削峰——有点像地铁换乘时设计的换乘通道。

1.4.3 使用集群

  操作：使用负载均衡技术为一个应用构建一个由多态服务器组成的服务器集群，将高并发的访问分发到多台服务器上进行处理。

1.4.4 代码优化

  代码优化的主要手段：

  1. 多线程：充分利用CPU计算能力和多核性能，要注意线程安全问题，参考笔记ch13 线程安全和锁优化

  2. 资源复用：通过单例和对象池减少对开销很大的系统资源的创建和销毁。

  3. 数据结构：如Hash表等。

  4. 垃圾回收：参考博客深入理解Java虚拟机 ch3 垃圾回收器和内存分配策略 读书笔记 理解GC有助于程序优化和参数调优。

---

1.5 存储性能优化

  本节主要涉及三个方案对比，没有绝对的优劣之分，视应用情形而定。

  硬盘选择：机械硬盘 vs 固态硬盘：固态硬盘随机访问性能好，但可靠性、性价比有待提高。

  数据结构选择：B+树 vs LSM树

  集群方式选择：RAID vs HDFS

---

二 网站的高可用架构

  可用性：描述网站可有效访问的特性，最为基本。

  可用性度量：使网站故障时间尽可能短。

故障时间 = 故障修复时间点 - 故障报告时间点
网站年度可用性指标 = ( 1 - 年度故障时间 / 年度总时间 ) * 100%

  下面从多个角度进行可用性保证说明。

---

2.1 高可用网站架构

  前因：互联网公司一般采用PC级服务器、开源数据库和操作系统，这些廉价设备降低了系统可用性。

  高可用架构设计目标：保证服务器出现硬件故障时服务依然可用、数据依然能被读写。

  高可用架构手段：数据和服务的冗余备份和失效转移。

  在笔记1中，介绍了网站典型的分层模型；此外，还有不同业务的分割处理并进行独立服务器集群布置。这样的设计导致不同的层次有不同的可用性特点，下面对三个层次分别进行可用性方案设计。

---

2.2 高可用的应用

  应用层主要处理网站应用的业务逻辑，也称业务逻辑层，其典型特点是无状态。

  无状态：指应用服务器不保存业务的上下文信息，仅根据每次请求提交的数据进行相应的业务逻辑处理，这样，服务器之间完全对等。

  在实际设计时，因为无状态，则只需考虑使用负载均衡提高整个应用服务器集群的负载能力及某个服务器出现问题时的失效转移即可；另一方面，请求往往是有状态的，还需要进行额外的状态管理。这就是下面两小节的内容。

2.2.1 负载均衡

  负载均衡：部署服务器集群应对高并发请求时，使用负载均衡技术进行服务器可用状态实时监测和自动转移失败任务。前者通过合理安排，可提高集群的负载能力；后者则提高了可用性保障。

2.2.2 Session管理(状态管理)

  Session:多次请求修改使用的上下文对象。用以保存和更改请求的状态。

  Session管理：在单机状态，可以直接使用服务器上的Web容器(如JBoss)管理；在使用负载均衡时，由于涉及服务器集群，Session管理会很复杂。

  下面介绍在集群环境下，Session管理的几种手段：

  1. Session复制：应用服务器开启Web容器的Session复制功能，在集群的所有服务器中同步Session对象，每台服务器保存所有用户的Session信息。优点：简单易实现；缺点：易达到上限，通信较多，只适合于小型集群。

  2. Session绑定：使用负载均衡算法(Hash算法等)，将同一IP(或使用Cookie信息)的请求总是分发到同一台服务器上，也叫会话粘滞。

  3. 利用Cookie记录Session：使用Cookie将Session记录在客户端，请求时用Cookie将Session传递给服务器，再经服务器修改返回。优点：Cookie本身简单易用；缺点：与Cookie绑定，受Cookie功能大小影响。

  4. Session服务器：利用独立部署的Session服务器集群统一管理，应用服务器每次读写时，都访问Session服务器——即将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器。这种方案，除了要多花钱配置，哪哪都挺好的。

---

2.3 高可用的服务

  可复用的服务模块为业务产品提供基础公共服务；在大型系统中，通常都独立分布式部署，由应用远程调用。下面介绍几种高可用的服务策略：

  1. 分级管理：在运维上将服务器分级管理，核心应用和服务使用更好的硬件；在服务部署上进行必要的隔离——低优先级服务启动不同线程或部署在不同虚拟机上；高优先级服务部署在不同物理机上，核心服务和服务部署在不同地域的数据中心。

  2. 超时设置：在应用程序中设置服务调用的超时时间，一旦超时，通信框架抛出异常，并使用服务调度策略重试。

  3. 异步调用：应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情形。不可用情形——1.获取用户信息类；2.必须确认调用成功才能进行下一步操作的应用。

  4. 服务降级：在访问高峰期高并发情形下，通过对服务降级保障核心功能和应用的正常运行。主要措施：拒绝服务和关闭服务。

  5. 幂等性设计：在服务层保证服务重复调用的结果相同。

---

2.4 高可用的数据

  重要性：数据是网站最宝贵的物质财产，失去了便不可恢复，保护数据就是保护命脉。而且现在的机器学习等手段可以利用大数据进行很多极有价值的数据分析和预测。

  数据存储高可用手段：数据备份和失效转移机制。

  缓存服务的高可用：可以使整个网站共享同一分布式缓存集群，这样对于大型网站，单台缓存服务器宕机影响较小。

  CAP原理：根据CAP原理——存储系统无法同时满足数据可用性、伸缩性和一致性这三个条件。在系统设计时，往往会通过牺牲数据一致性来获取其他两个特性。

2.4.1 数据备份

  分类：分为冷备和热备。

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

  异步方式：应用服务器在收到数据服务系统的写操作成功响应时，只写成功了一份，存储系统将会异步地写其他副本(该过程可能失败)

  同步方式：多份数据副本写入操作同时完成。

2.4.2 失效转移

  失效转移操作分为三步：失效确认、访问转移和数据恢复。

  1 失效确认：即判断服务器宕机，有两种方式——心跳检测和应用程序访问失败报告。

  2 访问转移：在确认数据存储服务器宕机后，需要将数据读写访问重新路由至其他服务器上。对于对等服务器，可以直接切换；对于不对等服务器，则需要重新计算路由。

  3 数据恢复：服务器宕机后，该服务器上存储数据的副本便减少一份；需要从健康的服务器赋值数据，将数据副本数目恢复到设定值。

---

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

  首先说明，在网站运维中，导致系统可用性风险的不仅有网络、服务器等硬件故障；还有各种软件相关问题，尤其是软件发布时。下面介绍一些软件质量保证手段。

2.5.1 网站发布

  影响：由于应用的不断发布，用户需要面对周期性的宕机故障。

  解决方式：使用发布脚本进行分批发布。

2.5.2 自动化测试

  作用：使用自动测试工具完成一键测试部署、测试数据生成、测试执行、测试报告生成等全部测试过程。

2.5.3 预发布验证

  起因：经过严格测试后，软件部署还是会出现各种问题——测试环境和线上环境不同，特别是依赖关系，也就是无法完全仿真真实市场环境。

  解决手段：在软件正式发布前，使用预发布机器进行预发布验证，执行一些典型的业务流程，确认无误后再正式发布。

2.5.4 代码控制

  起因：大型网站的核心应用系统和共用业务模块涉及许多团队和工程师，需要对相同的代码库进行共同开发和维护。因此需要进行代码管理——保证代码发布版本的稳定正确，保证不同团队间开发互不影响。

  主流工具：Git和SVN。Git教程可以看廖雪峰老师的教程。

2.5.5 自动化发布

  基于规则驱动的火车发布模型。

2.5.6 灰度发布

  方式：将集群服务器分为若*分，每天只发布一部分并进行运行观察；逐步发布。若发现问题，则进行回滚操作。

---

2.6 网站运行监控

  在网站运行过程中进行监控，根据监控信息进行管理，从而保证网站可靠性，规避风险。

2.6.1 监控数据采集

  1 用户行为日志收集：通过服务器端和用户客户端进行收集，可以用实时计算框架Storm进行日志统计与分析。

  2 服务器性能监控：收集服务器运行指标，将故障扼杀在萌芽阶段。

  3 运行数据报告：监控一些与具体业务场景相关的技术和业务指标。

2.6.2 监控管理

  作用：监控数据收集后，除了用作系统性能评估、集群规模收缩性预测等，还可根据实时监控数据进行风险预警，对服务器进行失效转移，自动负载调整等。可以实现自适应管理。

---

三 网站的伸缩性架构

  伸缩性：不改变网站的软硬件设计，仅通过改变部署的服务器数量就可以扩大或缩小网站的服务处理能力。主要方式就是分布式部署和集群。

  集群作用与使用条件：使用服务器集群，通过增加服务器数量来增强整个集群的处理能力。前提是在技术上实现集群中服务器数量与处理能力的线性关系。

  网站架构的伸缩性设计：网站架构的伸缩性设计分为两种：根据功能进行物理分离实现伸缩；单一功能通过集群实现伸缩。在网站发展初期，使用前者；对于大型网站，主要使用后者。

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

  应用服务器是无状态的，其通过负载均衡实现其伸缩性设计，将用户请求进行分发，下面介绍几种负载均衡技术：

  1.HTTP重定向负载均衡：使用HTTP重定位服务器接收用户HTTP请求，计算得到真实Web服务器地址，并发送HTTP重定向响应返回给客户浏览器。缺点：1.需要两次请求才能完成一次访问；2. HTTP重定向服务器可能成为瓶颈。

  2. DNS域名解析负载均衡：利用DNS处理域名解析请求的同时进行负载均衡处理。缺点：解决1中问题的同时引入新缺点——控制权位于域名服务商，DNS解析记录更改缓慢。该方式一般用于大型网站的第一级负载均衡手段。

  3.反向代理负载均衡：利用反向代理服务器提供缓存的同时提供负载均衡功能。这里Web服务器仅在内部被反向代理访问，无需外部IP地址；而反向代理服务器则具有双网卡和内外两套IP地址；该方法作用于HTTP协议层面，也称为应用层负载均衡。

  4.IP负载均衡：在网络层通过修改请求目标地址失效负载均衡，与3中一样，负载均衡服务器为中介。

  5.数据链路层负载均衡：在4的情形下，由Web服务器直接返回响应给客户端，通过在数据链路层修改mac地址实现此时机房中所有服务器IP地址一致，仅mac地址不同。该方式也称三角传输方式，大型网站中最为常用。

  6. 负载均衡算法

  负载均衡服务器的实现分为两步：首先根据负载均衡算法和Web服务器列表计算得到集群中一台Web服务器的地址；然后将请求数据发送到该地址对应的Web服务器上。对于后者，前面已经讲了5种方法。下面介绍下前者。负载均衡算法分类：1.轮询；2.加权轮询；3.随机；4.最少连接；5.原地址散列。

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

  设计目标：在加入新的缓存服务器后，整个集群中原有的缓存数据尽可能还能被访问到。

  算法实现：使用分布式缓存的一致性Hash算法——使用一致性Hash环实现KEY到缓存服务器的Hash映射。这块可以直接点击超链接，不再累述。

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

  同样是数据存储，数据存储服务器集群相比缓存服务器对数据的持久性和可用性有更高的要求。下面分别从关系数据库和NoSQL数据库说明数据存储服务器集群的伸缩性设计。

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

  主要采用读写分离——主从模式，分库——业务分割，还有分片。这里以Cobar为例，这个给个超链接：阿里开源Mysql分布式中间件：Cobar

3.3.2 NoSQL数据库的伸缩性设计

  NoSQL：主要指非关系的、分布式的数据库设计模式；是关系数据库的补充而不是替代。NoSQL数据库产品一般都放弃了关系型数据库的两大重要基础——以关系代数为基础的结构化查询语句和事务一致性保证(ACID)。这里，使用最广泛的是HBase：Hbase原理、基本概念、基本架构

---

四 网站的可扩展架构

  可扩展：在对现有系统影响最小的情况下，系统功能可持续扩展及提升的能力；因此，模块化是设计网站可扩展架构的核心。要注意其与可伸缩性之间的区别。

  难度：在软件系统中，如何分解系统的各个模块、如何定义各个模块的接口、如何复用组合不同的模块，非常难以设计。软件架构师的一大能力就是将一个大系统分解为多个低耦合的子模块。

  内容：本部分的内容是介绍模块分布式部署后的聚合方式——分布式消息队列和分布式服务，另外还介绍了可扩展数据结构——ColumnFamily以及网站生态圈——第三方扩展。

4.1 分布式消息队列——降低系统耦合

  事件驱动架构：通过在低耦合的模块之间传输时间消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作，典型的就是生产者消费者模式。实现方式就是分布式消息队列*。

  分布式消息队列：将队列这种FIFO的数据结构部署到独立服务器上，应用程序通过远程访问接口使用分布式消息队列，进行消息存取，进而实现分布式的异步调用。

4.2 分布式服务——打造可复用业务平台

  分布式服务：分布式消息队列通过消息对象降低系统的耦合性，不同子系统处理同一消息；分布式服务则通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用。

  降低大型系统复杂度：使用纵向拆分——将大应用拆分为多个小应用；横向拆分——将复用的业务拆分；最终实现模块独立部署。

  分布式服务框架——阿里的Dubbo：Dubbo架构设计详解

4.3 可扩展的数据结构

  这里指NoSQL使用的ColumnFamily。其在创建表的时候无需指定字段，只需指定ColumnFamily的名字；因此其字段可以随意扩展。

4.4 平台生态圈

  第三方扩展：这里指大型软件为开发更多增值服务，会将内内部服务封装成一些调用接口开放出去，成立开放平台，供第三方开发者开发。包括Facebook、微信、苹果等大企业都有大量的第三方开发者。

---

五 网站的安全架构

  网站的安全威胁——各种Web攻击和消息泄露。下面介绍一些典型的攻击和防攻击技术。

5.1 网站攻击与防御

5.1.1. XSS攻击

  定义：指跨站点脚本攻击，指黑客通过篡改网页，注入恶意HTML脚本，在用户浏览网页时，控制用户浏览器进行恶意操作。

  分类：分为两种，反射型——使用钓鱼网站引诱用户点击，从而扩散攻击；持久型——将恶意脚本请求提交到Web服务器站点中，形成持久攻击。

  防攻击手段：主要有消毒和HttpOnly。

  消毒：对客户请求中的某些html危险字符进行转义，从而起到消除恶意脚本的目的。

  HttpOnly：浏览器禁止页面JavaScript访问带有HttpOnly属性的Cookie。用以防止XSS攻击者窃取Cookie信息。

5.1.2 注入攻击

  分类：主要分为SQL注入和OS注入

  SQL注入：在Http请求中注入恶意SQL命令，当其被执行时起到破坏作用。SQL注入攻击需要攻击者对数据库结构有所了解才行。

  SQL注入攻击方式：1. 开源——其数据库结构公开；2.错误回显——通过试错得到错误回显信息猜测结构；3.盲注——这个比较6，攻击者在得不到错误回显的情况下，根据页面变化情况判断SQL语句执行情况从而猜测其数据库表结构。

  防SQL注入攻击：1.消毒——同上一节，对请求参数进行消毒，简单粗暴有效；2.参数绑定——最好的防SQL注入方法，使用预编译手段。

  OS注入：与SQL注入相似，只不过注入的是OS命令。应对方法也相似。

5.1.3 CSRF攻击

  CSRF：跨站点请求伪造，攻击者通过夸张请求，以合法用户的身份进行非法操作。其主要手段是跨站请求，核心是利用浏览器Cookie或服务器Session，盗取客户身份。

  防御手段：主要是识别请求者身份。1.表单Token——在请求参数中增加随机数来组织攻击者获得所有请求参数；2.验证码——简单有效，用户体验不好，但在安全性要求高的情况下一般都使用验证码；3.Referer check——记录请求来源，以供检验。

5.1.4 其他攻击

  HTML注释：获取网站的注释，了解信息

  文件上传：通过上传可执行程序进行攻击；防御——设置文件白名单，只允许指定文件类型

  路径遍历：在请求中使用相对路径进行遍历。

5.1.5 Web防火墙

  作用：能处理掉大部分网络攻击，还可不断升级

5.1.6 网站安全漏洞扫描

  模拟网站攻击，从而进行查漏补缺。

5.2 信息加密技术与**安全管理**

  前因：为保护网站的敏感数据，需要对这些数据进行加密处理。

  信息加密技术分类：单向散列加密、对称加密和非对称加密。

5.2.1 单向散列加密

  思路：通过对不同输入长度的信息进行散列计算，得到固定长度的输出；为加强安全性，可在散列算法中加盐。

  操作：用户登录时进行密码验证，计算得到输入密码的密文，并与数据库中密文对比，进行验证。

  算法：MD5，SHA等。

5.2.2 对称加密

  定义：加密和解密使用同一个**(或可以互相推算)。

  问题：如何安全的传输**

  算法：DES算法、RC算法。

5.2.3 非对称加密

  定义：加密和解密使用不同**；一个为公钥，公开；一个为私钥，只有所有者可知。

  算法：RSA算法等。

  应用：实际应用中，一般使用非对称加密技术传输对称加密的**；再使用对称加密技术进行信息解密与交换。

  5.2.4 **安全管理

  前言：**的安全是安全保密的前提。**安全管理手段分两种。

  1. 将**和算法放在一个独立的服务器上，由专人维护。缺点：成本高，远程调用开销大。

  2. 将加解密系统放在应用系统中，**放在独立服务器中。

5.3 信息过滤与反垃圾

  信息过滤和反垃圾的几个手段：

  1. 文本匹配：由网站维护一个敏感词列表，对敏感词进行过滤——转移或拒绝发表。敏感词匹配方式——正则表达式，Trie树或多级Hash表。

  2. 分类算法：使用贝叶斯分类算法进行分类和辨识。

  3. 黑名单：实现方式——Hash表或布隆过滤器。