分类 网络技术 下的文章 - 易航博客

浅聊一下XSS和CSRF攻击以及防御方法 XSS攻击XSS，即为（CrossSiteScripting），中文名为跨站脚本，是发生在目标用户的浏览器层面上的，当渲染 DOM 树的过程成发生了不在预期内执行的 JS 代码时，就发生了 XSS 攻击，大多数 XSS 攻击的主要方式是嵌入一段远程或者第三方域上的 JS 代码。实际上是在目标网站的作用域下执行了这段JS代码。XSS防御XSS 防御的总体思路是：对输入(和URL参数)进行过滤，对输出进行编码。也就是对提交的所有内容进行过滤，对 url 中的参数进行过滤，过滤掉会导致脚本执行的相关内容 然后对动态输出到页面的内容进行html编码，使脚本无法在浏览器中执行。虽然对输入过滤可以被绕过，但是也还是会拦截很大一部分的XSS攻击。CSRF攻击CSRF（CrossSiteRequest Forgery，跨站请求伪造），字面理解意思就是在别的站点伪造了一个请求。专业术语来说就是在受害者访问一个网站时，其 Cookie 还没有过期的情况下，攻击者伪造一个链接地址发送受害者并欺骗让其点击，从而形成 CSRF 攻击。CSRF防御防御 CSRF 攻击主要有三种策略：验证HTTP Referer 字段；在请求地址中添加 Token 并验证；在 HTTP 头中自定义属性并验证。

有了HTTP，为什么还要RPC？ 有了HTTP，为什么还要RPC？RPC：Remote Procedure Call，远程过程调用一直以来都没有深究过RPC和HTTP的区别，不都是写一个服务然后在客户端调用么？HTTP和RPC最本质的区别，就是 RPC 主要是基于 TCP/IP 协议的，而 HTTP 服务主要是基于 HTTP 协议的。我们都知道 HTTP 协议是在传输层协议 TCP 之上的，所以效率来看的话，RPC 当然是要更胜一筹啦！HTTP和RPC的相同点是，底层通讯都是基于socket，都可以实现远程调用，都可以实现服务调用服务HTTP 的本质首先你要明确 HTTP 是一个协议，是一个超文本传输协议。HTTP 它是协议，不是运输通道。它基于 TCP/IP 来传输文本、图片、视频、音频等。重点来了。HTTP 不提供数据包的传输功能，也就是数据包从浏览器到服务端再来回的传输和它没关系。这是 TCP/IP 干的。那 HTTP 有啥用？我们来分析一波。我们上网要么就是获取一些信息来看，要么就是修改一些信息。比如你用浏览器刷微博就是获取信息，发微博就是修改信息。所以说浏览器需要告知服务器它需要什么，这次的请求是要获取哪些信息？发怎么样的微博。这就涉及到浏览器和服务器之间的通信交互。而交互就需要一种格式。像你我之间的谈话就用中文，你要突然换成俄语我听不懂那不就 GG 了。所以说 HTTP 它规定了一种格式，一种通信格式，大家都用这个格式来交谈。这样不论你是什么服务器、什么浏览器都能顺利的交流，减少交互的成本。就像全世界如果都讲中文，那我们不就不需要学英文了，那不就较少交互的成本了。不像现在我们还得学英文，不然就看不懂文档等等。万一之后俄语又起来了，咱还得对接俄文，这交互成本是不是就上来了。而网络世界还好，咱们现在的 Web 交互基本上就是 HTTP 了。其实 HTTP 协议的格式很像我们信封，有个固定的格式。左上角写邮编，右上角贴邮票，然后地址姓名啥的依次来。因为计算机是很死板的，不像我们人一样有一种立体扫描感，所以要规定先写头、再写尾。你要是先写尾，再写头计算机就认不出来了。所以 HTTP 就规定了请求先搞请求行、再搞请求报头、再搞请求体。响应就状态行、响应报头、响应体。所以 HTTP 的本质是什么？就是客户端和服务端约定好的一种通信格式。HTTP 和 RPC 的关系HTTP 和 RPC 其实是两个维度的东西， HTTP 指的是通信协议。而 RPC 则是远程调用，其对应的是本地调用。RPC 的通信可以用 HTTP 协议，也可以自定义协议，是不做约束的。像之前的单体时代，我们的 service 调用就是自己实现的方法，是本地进程内的调用。public User getUserById(Long id) { return userDao.getUserById(id); // 这叫本地调用 }现在都是微服务了，根据业务模块做了不同的拆分，像用户的服务不用我这个小组负责，我这小组只要写订单服务就行了。但是我们服务需要用到用户的信息，于是我们需要调用用户小组的服务，于是代码变成了以下这种public User getUserById(Long id) { return userConsumer.getUserById(id); // 这是远程调用，逻辑是用户小组的服务实现的。 }把之前的用户实现拆分出来弄了一个用户服务，订单相关的也拆成了订单服务，都单独部署。这样订单相关的服务要获取用户的信息就需要远程调用了。可以看到 RPC 就是通过网络进行远程调用，订单服务其实就是客户端，而用户服务是服务端。这又涉及到交互了，所以也需要约定一个格式，至于要不要用 HTTP 这个格式，就是大家自己看着办。至此相信你对 HTTP 是啥也清楚了。RPC 和 HTTP 的之间的关系也清楚了。那为什么要有 RPC？可能你常听到什么什么之间是 RPC 调用的，那你有没有想过为什么要 RPC， 我们直接 WebClient HTTP 调用不行么？其实 RPC 调用是因为服务的拆分，或者本身公司内部的多个服务之间的通信。服务的拆分独立部署，那服务间的调用就必然需要网络通信，用 WebClient 调用当然可行，但是比较麻烦。我们想即使服务被拆分了但是使用起来还是和之前本地调用一样方便。所以就出现了 RPC 框架，来屏蔽这些底层调用细节，使得我们编码上还是和之前本地调用相差不多。并且 HTTP 协议比较的冗余，RPC 都是内部调用所以不需要太考虑通用性，只要公司内部保持格式统一即可。所以可以做各种定制化的协议来使得通信更高效。比如规定 yes 代表 yes的练级攻略，你看是不是更高效了，少传输的 5 个字。就像特殊行动的暗号，高效简洁！所以公司内部服务的调用一般都用 RPC，而 HTTP 的优势在于通用，大家都认可这个协议。所以三方平台提供的接口都是通过 HTTP 协议调用的。所以现在知道为什么我们调用第三方都是 HTTP ，公司内部用 RPC 了吧？上面这段话看起来仿佛 HTTP 和 RPC 是对等关系，不过相信大家看了之前的解析心里应该都有数了。下面来具体说一说 RPC 服务和 HTTP 服务的区别。OSI 网络七层模型在说 RPC 和 HTTP 的区别之前，我觉得有必要了解一下 OSI 的七层网络结构模型它可以分为以下几层：（从上到下）第一层：应用层。定义了用于在网络中进行通信和传输数据的接口。第二层：表示层。定义不同的系统中数据的传输格式，编码和解码规范等。第三层：会话层。管理用户的会话，控制用户间逻辑连接的建立和中断。第四层：传输层。管理着网络中的端到端的数据传输。第五层：网络层。定义网络设备间如何传输数据。第六层：链路层。将上面的网络层的数据包封装成数据帧，便于物理层传输。第七层：物理层。这一层主要就是传输这些二进制数据。实际应用过程中，五层协议结构里面是没有表示层和会话层的。应该说它们和应用层合并了。我们应该将重点放在应用层和传输层这两个层面。因为 HTTP 是应用层协议，而 TCP 是传输层协议。好，知道了网络的分层模型以后我们可以更好地理解为什么 RPC 服务相比 HTTP 服务要 Nice 一些！RPC 服务从三个角度来介绍 RPC 服务，分别是：RPC 架构同步异步调用流行的 RPC 框架RPC 架构先说说 RPC 服务的基本架构吧。我们可以很清楚地看到，一个完整的 RPC 架构里面包含了四个核心的组件。分别是：ClientServerClient StubServer Stub（这个Stub大家可以理解为存根）分别说说这几个组件：客户端（Client），服务的调用方。服务端（Server），真正的服务提供者。客户端存根，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法。RPC 主要是用在大型企业里面，因为大型企业里面系统繁多，业务线复杂，而且效率优势非常重要的一块，这个时候 RPC 的优势就比较明显了。比如我们有一个处理订单的系统服务，先声明它的所有的接口，然后将整个项目打包，服务端这边引入，然后实现相应的功能，客户端这边也只需要引入就可以调用了。为什么这么做？主要是为了减少客户端这边的包大小，因为每一次打包发布的时候，包太多总是会影响效率。另外也是将客户端和服务端解耦，提高代码的可移植性。同步调用与异步调用什么是同步调用？什么是异步调用？同步调用就是客户端等待调用执行完成并返回结果。异步调用就是客户端不等待调用执行完成返回结果，不过依然可以通过回调函数等接收到返回结果的通知。如果客户端并不关心结果，则可以变成一个单向的调用。流行的 RPC 框架目前流行的开源 RPC 框架还是比较多的。下面重点介绍三种：①gRPC 是 Google 最近公布的开源软件，基于最新的 HTTP2.0 协议，并支持常见的众多编程语言。我们知道 HTTP2.0 是基于二进制的 HTTP 协议升级版本，目前各大浏览器都在快马加鞭的加以支持。这个 RPC 框架是基于 HTTP 协议实现的，底层使用到了 Netty 框架的支持。②Thrift 是 Facebook 的一个开源项目，主要是一个跨语言的服务开发框架。它有一个代码生成器来对它所定义的 IDL 定义文件自动生成服务代码框架。用户只要在其之前进行二次开发就行，对于底层的 RPC 通讯等都是透明的。不过这个对于用户来说的话需要学习特定领域语言这个特性，还是有一定成本的。③Dubbo 是阿里集团开源的一个极为出名的 RPC 框架，在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是及其鲜明的特色。HTTP 服务通常，我们的开发模式一直定性为 HTTP 接口开发，也就是我们常说的 RESTful 风格的服务接口。的确，对于在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的 HTTP 协议进行传输。平时的工作主要就是进行接口的开发，还要写一大份接口文档，严格地标明输入输出是什么？说清楚每一个接口的请求方法，以及请求参数需要注意的事项等。比如下面这个例子：POST http://blog.bri6.cn/接口可能返回一个 JSON 字符串或者是 XML 文档。然后客户端再去处理这个返回的信息，从而可以比较快速地进行开发。但是对于大型企业来说，内部子系统较多、接口非常多的情况下，RPC 框架的好处就显示出来了，首先就是长链接，不必每次通信都要像 HTTP 一样去 3 次握手什么的，减少了网络开销。其次就是 RPC 框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。小结RPC 服务和 HTTP 服务还是存在很多的不同点的，一般来说，RPC 服务主要是针对大型企业的，而 HTTP 服务主要是针对小企业的，因为 RPC 效率更高，而 HTTP 服务开发迭代会更快。很多RPC框架包含了重试机制，路由策略，负载均衡策略，高可用策略，流量控制策略等等。如果应用进程之间只使用HTTP协议通信，显然是无法完成上述功能的。总之，选用什么样的框架不是按照市场上流行什么而决定的，而是要对整个项目进行完整地评估，从而在仔细比较两种开发框架对于整个项目的影响，最后再决定什么才是最适合这个项目的。一定不要为了使用 RPC 而每个项目都用 RPC，而是要因地制宜，具体情况具体分析。

无违规封v群 准备一个黄鸟或者蓝鸟随便找个群，我们点投诉。然后选择不适当信息。然后色情，然后提交审核，然后要选择一个聊天记录，随便都行，图片尽量别选，我怕那个特么你们不会改，记住，是随便选一条记录哦，我们选完之后点完成，这时候就要用到抓包的了然后我们点提交哦，点提交前打开抓包。我们找到110这个包，我们点进去看下，如果会做了可以直接下一步，这一步就不用了我们现在需要长安这个包，点击编辑重发，然后到最下面，点，然后选择在线编辑接着来我们要把那个聊天记录删了，重新写点瑟瑟违规词进去之后就能看到我们选择的那个聊天记录等他发成功然后我们一直点右上角在然后我们把那个第一个长安高级重发像这样，重发3次。然后就是等结果了就这个样子，他给你返回的结果会返回4个，第一个是没违规，然后后面是警告，在就是封禁，然后我们去群里面看，就会发现上面的一行字 :$(斜眼笑) :$(斜眼笑) 现在知道了吧封v群就这么简单

HTTP(S)状态码详解教程 导读：当浏览者访问一个网页时，浏览者的浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前，此网页所在的服务器会返回一个包含HTTP状态码的信息头（server header）用以响应浏览器的请求。HTTP状态码常见于网站日志分析（1）、HTTP状态码的英文为 HTTP Status Code。下面是常见的HTTP状态码:200 – 请求成功301 – 资源（网页等）被永久转移到其它URL404 – 请求的资源（网页等）不存在500 – 内部服务器错误（2）、HTTP状态码的分类HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用。HTTP状态码共分为5种类型：1** 信息，服务器收到请求，需要请求者继续执行操作2** 成功，操作被成功接收并处理3** 重定向，需要进一步的操作以完成请求4** 客户端错误，请求包含语法错误或无法完成请求5** 服务器错误，服务器在处理请求的过程中发生了错误一、（1**）开头的状态码详解100：客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。101：服务器已经理解了客户端的请求,并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade 消息头中定义的那些协议。例如，切换到新的HTTP 版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。102：由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。二、（2**）开头的状态码详解200：请求已成功，请求所希望的响应头或数据体将随此响应返回。实际的响应将取决于所使用的请求方法。在GET请求中，响应将包含与请求的资源相对应的实体。在POST请求中，响应将包含描述或操作结果的实体。201：请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话，应当返回 ‘202 Accepted’。202：服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了。返回202状态码的响应的目的是允许服务器接受其他过程的请求（例如某个每天只执行一次的基于批处理的操作），而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息，以及指向处理状态监视器或状态预测的指针，以便用户能够估计操作是否已经完成。203：服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。204：服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。响应可能通过实体头部的形式，返回新的或更新后的元信息。如果存在这些头部信息，则应当与所请求的变量相呼应。如果客户端是浏览器的话，那么用户浏览器应保留发送了该请求的页面，而不产生任何文档视图上的变化，即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。由于 204 响应被禁止包含任何消息体，因此它始终以消息头后的第一个空行结尾。205：服务器成功处理了请求，且没有返回任何内容。但是与204响应不同，返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后，立即重置表单，以便用户能够轻松地开始另一次输入。206：服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。207：由 WebDAV(RFC 2518)扩展的状态码，代表之后的消息体将是一个XML消息，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码。三、（3**）开头的状态码详解300：被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。301：被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。302：请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。303：对应当前请求的响应可以在另一个 URI 上被找到，而且客户端应当采用 GET 的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的 URI 不是原始资源的替代引用。同时，303响应禁止被缓存。304：如果客户端发送了一个带条件的GET请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。305：被请求的资源必须通过指定的代理才能被访问。Location 域中将给出指定的代理所在的 URI 信息，接收者需要重复发送一个单独的请求，通过这个代理才能访问相应资源。只有原始服务器才能建立305响应。306：在最新版的规范中，306状态码已经不再被使用。307：请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。四、（4**）开头的状态码详解400：1、语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。2、请求参数有误。401：当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的Authorization头信息的请求。如果当前请求已经包含了 Authorization证书，那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展示响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。402：该状态码是为了将来可能的需求而预留的。403：服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。404：请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。405：请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。406：请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。407：与401响应类似，只不过客户端必须在代理服务器上进行身份验证。408：请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。409：由于和被请求的资源的当前状态之间存在冲突，请求无法完成。410：被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。411：服务器拒绝在没有定义Content-Length头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length头之后，客户端可以再次提交该请求。412：服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。413：服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。414：请求的URI 长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。415：对于当前请求的方法和所请求的资源，请求中提交的实体并不是服务器中所支持的格式，因此请求被拒绝。416：如果请求中包含了Range请求头，并且Range中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义 If-Range 请求头，那么服务器就应当返回416状态码。417：在请求头 Expect中指定的预期内容无法被服务器满足，或者这个服务器是一个代理服务器，它有明显的证据证明在当前路由的下一个节点上，Expect 的内容无法被满足。421：从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。423：请求格式正确，但是由于含有语义错误，无法响应。424：由于之前的某个请求发生的错误，导致当前请求失败，例如 PROPPATCH。425：在WebDav Advanced Collections 草案中定义，但是未出现在《WebDAV 顺序集协议》（RFC 3658）中。426：客户端应当切换到TLS/1.0。449：由微软扩展，代表请求应当在执行完适当的操作后进行重试。五、（5**）开头的状态码详解500：服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器的程序码出错时出现。501：服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。502：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。503：由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。注意：503状态码的存在并不意味着服务器在过载的时候必须使用它。某些服务器只不过是希望拒绝客户端的连接。504：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。505：服务器不支持，或者拒绝支持在请求中使用的HTTP版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。506：由《透明内容协商协议》（RFC 2295）扩展，代表服务器存在内部配置错误：被请求的协商变元资源被配置为在透明内容协商中使用自己，因此在一个协商处理中不是一个合适的重点。507：服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV (RFC 4918)509：服务器达到带宽限制。这不是一个官方的状态码，但是仍被广泛使用。510：获取资源所需要的策略并没有没满足。（RFC 2774）

一文搞懂HTTP和HTTPS的通信过程及区别 一、两者的区别端口： http 端口号是80， https 端口号是443传输协议： http 是超文本传输协议，属于明文传输；https 是安全的超-文本传输协议，是经过 SSL 加密后的传输协议安全性： https 使用了 TLS/SSL 加密，比 http 更加的安全证书： https 需要申请 ca 证书二、HTTP的通信过程理解： 作为标准的 C/S 模型， http 协议总是由客户端发起，服务端进行响应。DNS 解析，域名系统 DNS 将域名解析成IP地址建立 TCP 连接，进行 TCP 的三次握手客户端发送请求服务端响应客户端，向客户端发送数据通信完成， TCP 连接关闭三、HTTPS的通信过程理解： https 通信是建立在 ssl 连接层之上的请求和响应，客户端将加密组件发送到服务端，服务端进行匹配后将数字证书等信息发送到客户端，客户端进行证书验证，验证通过后使用非对称加密对数据的密钥进行协商，协商后得到对称的加密密钥，然后使用对称算法进行 TCP 链接，然后与客户端进行三次握手后，进行数据传输，传输完成后，四次挥手，断开链接，通信结束。客户端和服务端通过 TCP 建立连接，并发送 https 请求。服务端响应请求，并将数字证书发送给客户端，数字证书包括 公共秘钥、域名、申请证书的公司 。客户端收到服务端的数字证书之后，会验证数字证书的合法性。如果公钥合格，那么客户端会生成 client key ，一个用于进行对称加密的密钥，并用服务端的公钥对客户端密钥进行非对称加密。客户端会再次发起请求，将加密之后的客户端密钥发送给服务端。服务端接收密文后，会用私钥对其进行非对称解密，得到客户端秘钥。并使用客户端秘钥进行对称加密，生成密文并发送。客户端收到密文，并使用客户端秘钥进行解密，获取数据。四、HTTPS通信过程介绍图

CC攻击介绍 关于CC攻击（ChallengeCoHapsar，挑战黑洞）CC攻击是DDOS攻击的一种常见类型，攻击者借助代理服务器生成指向受害主机的合法请求，实现DDOS和伪装。CC攻击是一种针对Http业务的攻击手段，该攻击模式不需要太大的攻击流量，它是对服务端业务处理瓶颈的精确打击。攻击目标大量数据运算、数据库访问、大内存文件等，攻击者控制某些主机不停地发大量数据包给对方服务器造成服务器资源耗尽，一直到岩机崩溃。最简单的理解，3000台电脑同时访问你的网站开三个浏览器按住F5是一种什么样的体验，有点特点的，死循环请求搜索接口，批量访问大文件等等！比如这个URL就是一个搜索接口，我测试的时候还没有做频率限制，和分页限制，100并发压测直接就凉了，随后直接加上了频率限制！特征被攻击服务器，一瞬间会带宽飙升，随后CPU，内存，io，随着飙升！特点就是攻击方式简单，隐藏性高，量大！缺点需要持续压制直至攻击服务器岩机，如果在中途停止了压测，一般情况下服务器很快就能恢复，或者宕机服务自动重启，恢复业务正常运行！