关于http等网络相关知识你了解多少？

时间 2019-11-07

原文原文链接

HTTP能够说是前端须要掌握的一块领域，知识点其实不少，写这篇文章的初衷其实也是本身想梳理一下HTTP包含哪些内容，并记录下来，供本身之后学习参考。javascript

一、HTTP是什么？

HTTP被设计于20世纪90年代初期，是一种可扩展的协议，是应用层的协议。HTTP协议（HyperText Transfer Protocol，超文本传输协议）是因特网上应用最为普遍的一种网络传输协议，全部的WWW文件都必须遵照这个标准。HTTP是一个基于TCP/IP通讯协议来传递数据（HTML 文件, 图片文件, 查询结果等）。它是在 Web 上进行数据交换的基础，是一种 client-server 协议。客户端和服务端经过交换各自的消息进行交互。由像浏览器这样的客户端发出的消息叫作 requests，被服务端响应的消息叫作 responses。

二、HTTP的组成及其特色？

HTTP由两部分组成，客户端请求消息和服务端响应消息（请求报文和响应报文） 。客户端发送一个HTTP请求到服务器的请求消息包括如下格式：请求行（request line,包括请求方法、url）、请求头（header）、空行和请求体据(queryString) 四个部分组成。HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。html

特色前端

一、简单快速： 客户向服务器请求服务时，只需传送请求方法和路径（url和method）。因为 HTTP 协议简单，使得 HTTP 服务器的程序规模小，于是通讯速度很快
二、灵活： HTTP 容许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记.
三、无链接：无链接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式能够节省传输时间
四、无状态： HTTP 协议是无状态协议。无状态是指协议对于事物处理没有记忆能力。缺乏状态意味着若是后续处理须要前面的信息，则它必须重传，这样可能会致使每次链接传送的数据量增大。

三、HTTP请求方式？

HTTP 协议中共定义了八种方法来代表对 Request-URI 指定的资源的不一样操做方式，具体介绍以下：

一、OPTIONS：返回服务器针对特定资源所支持的HTTP请求方法。也能够利用向Web服务器发送'*'的请求来测试服务器的功能性。
二、HEAD：向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法能够在没必要传输整个响应内容的状况下，就能够获取包含在响应消息头中的元信息。
三、GET：向特定的资源发出请求。
四、POST：向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会致使新的资源的建立和/或已有资源的修改。
五、PUT：向指定资源位置上传其最新内容。
六、DELETE：请求服务器删除 Request-URI 所标识的资源。
七、TRACE：回显服务器收到的请求，主要用于测试或诊断。
八、CONNECT：HTTP/1.1 协议中预留给可以将链接改成管道方式的代理服务器。

虽然 HTTP 的请求方式有 8 种，可是咱们在实际应用中经常使用的也就是 GET 和 POST，其余请求方式也均可以经过这两种方式间接的来实现。java

下面就来对比一下GET和POST的区别：程序员

应用过程当中的区别（因为HTTP的规定和浏览器/服务器的限制）： 不一样点：web

不一样点	GET	POST
使用目的	通常是信息获取	主要是修改服务器上的资源
字数限制	使用UR传递参数，url的字数限制在2000个字符左右。	发送的信息字数没有限制。
缓存	URL请求记录会被缓存，请求参数会被完整保留在浏览器历史记录里	不会被缓存，参数不会被保留，除非手动设置
后台获取数据方式	Request.QueryString	Request.Form
传值方式	地址栏传值	经过提交表单（body）传值
编码类型	支持更多的编码类型且不对数据类型限制	只接受ASCII字符
浏览器回退	在浏览器回退时是无害的	在浏览器回退时会再次提交请求
安全性	参数直接暴露在URL上，不安全	安全性好
根本区别	GET产生一个TCP数据包，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）	POST产生两个TCP数据包，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）

相同点：正则表达式

一、GET和POST本质上就是TCP连接，并没有差异。算法

然而，在如下状况中，请使用 POST 请求：sql

一、没法使用缓存文件（更新服务器上的文件或数据库）；
二、向服务器发送大量数据（POST 没有数据量限制）；
三、发送包含未知字符的用户输入时，POST 比 GET 更稳定也更可靠。

四、HTTP状态码

下面列举的是一些可能进程被用到的状态码。

1XX-消息数据库

这一类型的状态码，表明请求已被接受，须要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。

状态码	英文意思	解释
100	Continue	客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者若是请求已经完成，忽略这个响应。
101	Switching Protocols	服务器已经理解了客户端的请求，并将经过Upgrade 消息头通知客户端采用不一样的协议来完成这个请求。只有在切换新的协议更有好处的时候才应该采起相似措施
102	processing	表明处理将被继续执行

2XX-成功

这一类型的状态码，表明请求已成功被服务器接收、理解、并接受。

状态码	英文意思	解释
200	Ok	请求已成功，请求所但愿的响应头或数据体将随此响应返回。出现此状态码是表示正常状态。
201	Created	请求已经被实现，并且有一个新的资源已经依据请求的须要而创建，且其 URI 已经随Location 头信息返回。假如须要的资源没法及时创建的话，应当返回 '202 Accepted'。
202	Accepted	服务器已接受请求，但还没有处理。返回202状态码的响应的目的是容许服务器接受其余过程的请求（例如某个天天只执行一次的基于批处理的操做），而没必要让客户端一直保持与服务器的链接直到批处理操做所有完成。
203	Non-Authoritative Information	服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的肯定集合，而是来自本地或者第三方的拷贝。
204	No Content	服务器成功处理了请求，但不须要返回任何实体内容，而且但愿返回更新了的元信息。因为204响应被禁止包含任何消息体，所以它始终以消息头后的第一个空行结尾。
205	Reset Content	服务器成功处理了请求，且没有返回任何内容。可是与204响应不一样，返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后，当即重置表单，以便用户可以轻松地开始另外一次输入。与204响应同样，该响应也被禁止包含任何消息体，且以消息头后的第一个空行结束。
206	Partial Content	服务器已经成功处理了部分 GET 请求。相似于 FlashGet 或者迅雷这类的 HTTP下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。
207	Multi-Status	表明以后的消息体将是一个XML消息，而且可能依照以前子请求数量的不一样，包含一系列独立的响应代码。

3XX-重定向

这类状态码表明须要客户端采起进一步的操做才能完成请求。一般，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的 Location 域中指明。

状态码	英文意思	解释
300	Multiple Choices	被请求的资源有一系列可供选择的回馈信息，每一个都有本身特定的地址和浏览器驱动的商议信息。用户或浏览器可以自行选择一个首选的地址进行重定向。
301	Moved Permanently	被请求的资源已永久移动到新位置
302	Move Temporarily	请求的资源临时从不一样的 URI响应请求。因为这样的重定向是临时的，客户端应当继续向原有地址发送之后的请求。若是这不是一个 GET 或者 HEAD 请求，那么浏览器禁止自动进行重定向，除非获得用户的确认。只有在Cache-Control或Expires中进行了指定的状况下，这个响应才是可缓存的。
303	See Other	对应当前请求的响应能够在另外一个 URL 上被找到，并且客户端应当采用 GET 的方式访问那个资源。这个方法的存在主要是为了容许由脚本激活的POST请求输出重定向到一个新的资源。这个新的 URI 不是原始资源的替代引用。同时，303响应禁止被缓存。固然，第二个请求（重定向）可能被缓存。
304	Not Modified	若是客户端发送了一个带条件的 GET 请求且该请求已被容许，而文档的内容（自上次访问以来或者根据请求的条件）并无改变，则服务器应当返回这个状态码。304响应禁止包含消息体，所以始终以消息头后的第一个空行结尾。该响应必须包含如下的头信息：Date、ETag 和/或 Content-Location、Expires, Cache-Control，和/或Vary
305	Use Proxy	被请求的资源必须经过指定的代理才能被访问

4XX-请求错误

这类的状态码表明了客户端看起来可能发生了错误，妨碍了服务器的处理。

状态码	英文意思	解释
400	Bad Request	一、语义有误，当前请求没法被服务器理解。二、请求参数有误。
401	Unauthorized	当前请求须要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。
403	Forbidden	服务器已经理解请求，可是拒绝执行它。
404	Not Found	请求失败，请求所但愿获得的资源未被在服务器上发现。
405	Method Not Allowed	请求行中指定的请求方法不能被用于请求相应的资源。
406	Not Acceptable	请求的资源的内容特性没法知足请求头中的条件，于是没法生成响应实体。
407	Proxy Authentication Required	客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。
408	Request Timeout	请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端能够随时再次提交这一请求而无需进行任何更改。
409	Method Not Allowed	因为和被请求的资源的当前状态之间存在冲突，请求没法完成。用户被认为可以解决冲突，而且会从新提交新的请求。
411	Length Required	服务器拒绝在没有定义 Content-Length 头的状况下接受请求。在添加了代表请求消息体长度的有效 Content-Length 头以后，客户端能够再次提交该请求。
413	Request Entity Too Large	服务器拒绝处理当前请求，由于该请求提交的实体数据大小超过了服务器愿意或者可以处理的范围。
414	Request-URI Too Long	请求的URI 长度超过了服务器可以解释的长度，所以服务器拒绝对该请求提供服务。这比较少见，一般的状况包括：一、本应使用POST方法的表单提交变成了GET方法，致使查询字符串（Query String）过长。二、重定向URI “黑洞”，例如每次重定向把旧的 URI 做为新的 URI 的一部分，致使在若干次重定向后 URI 超长。
415	Unsupported Media Type	对于当前请求的方法和所请求的资源，请求中提交的实体并非服务器中所支持的格式，所以请求被拒绝。

5XX-服务器错误

这类状态码表明了服务器在处理请求的过程当中有错误或者异常状态发生，也有多是服务器意识到以当前的软硬件资源没法完成对请求的处理。

状态码	英文意思	解释
500	Internal Server Error	通常来讲，这个问题都会在服务器端的源代码出现错误时出现。
501	Not Implemented	服务器没法识别请求的方法，而且没法支持其对任何资源的请求。
502	Bad Gateway	做为网关或者代理工做的服务器尝试执行请求时，从上游服务器接收到无效的响应。
503	Service Unavailable	因为临时的服务器维护或者过载，服务器当前没法处理请求。注意：503状态码的存在并不意味着服务器在过载的时候必须使用它。某些服务器只不过是但愿拒绝客户端的链接。
504	Gateway Timeout	做为网关或者代理工做的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。
505	HTTP Version Not Supported	服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本
506	Use Proxy	被请求的资源必须经过指定的代理才能被访问

六、HTTP的缓存机制？

缓存机制无处不在，有客户端缓存（cookie、localstorage等），服务端缓存（session），代理服务器缓存等。在HTTP中具备缓存功能的是浏览器缓存。 HTTP缓存做为web性能优化的重要手段，对于从事web开发的朋友有重要的意义。

6.1缓存的分类

缓存分为强制缓存和协商缓存。

强制缓存：当本地缓存中含有请求的数据且（及缓存时间还未过时）时，客户端直接从本地缓存中获取数据。当本地缓存没有所请求的数据时，客户端的才会从服务端获取数据。
对于强制缓存，服务器响应的header中会用两个字段来代表——Expires和Cache-Control。
一、Expires
Exprires的值为服务端返回的数据到期时间。当再次请求时的请求时间小于返回的此时间，则直接使用缓存数据。但因为服务端时间和客户端时间可能有偏差，这也将致使缓存命中的偏差，另外一方面，Expires是HTTP1.0的产物，故如今大多数使用Cache-Control替代。 二、Cache-Control
```
Cache-Control有不少属性，不一样的属性表明的意义也不一样。 
  private：客户端能够缓存  
  public：客户端和代理服务器均可以缓存  
  max-age=t：缓存内容将在t秒后失效  
  no-cache：须要使用协商缓存来验证缓存数据  
  no-store：全部内容都不会缓存。  
  must-revalidate：缓存在考虑使用一个陈旧的资源时，必须先验证它的状态，已过时的缓存将不被使用
复制代码
```
协商缓存：又称对比缓存，客户端会先从本地缓存中获取到一个缓存数据的标识(ETag)，而后服务器检查该ETag证是否失效，若是没有失效服务端会返回304，此时客户端直接从缓存中获取所请求的数据，若是标识失效，服务端会返回更新后的数据。
协商缓存又分两种状况。

状况1：根据Last-Modified来进行协商缓存

Last-Modified： 服务器在响应请求时，会告诉浏览器资源的最后修改时间。

if-Modified-Since: 浏览器再次请求服务器的时候，请求头会包含此字段，后面跟着在缓存中得到的最后修改时间。服务端收到此请求头发现有if-Modified-Since，则与被请求资源的最后修改时间进行对比，若是一致则返回304和响应报文头，浏览器只须要从缓存中获取信息便可。
从字面上看，就是说：从某个时间节点算起，是否文件被修改了。
一、若是真的被修改：那么开始传输响应一个总体，服务器返回：200 OK。
二、若是没有被修改：那么只需传输响应header，服务器返回：304 Not Modified（没有响应体）。

if-Unmodified-Since: 从字面上看, 就是说: 从某个时间点算起, 是否文件没有被修改。
一、若是没有被修改:则开始`继续'传送文件: 服务器返回: 200 OK。
二、若是文件被修改:则不传输,服务器返回: 412 Precondition failed (预处理错误) 。

Last-Modified也有不足之处，若是实在服务器上，一个资源被修改了，但其实际内容并无发生改变，会由于Last-Modified时间匹配不上而返回整个实体给客户端（即便客户端缓存里有一个如出一辙的资源。为了解决这个问题，因此HTTP1.1推出了ETag）。

状况2：根据ETag（HTTP1.1产物）来进行协商缓存

Etag： ETag 是URL的Entity Tag，用于标示URL对象是否改变，区分不一样语言和Session等等。具体内部含义是服务器控制的，就像Cookie那样。ETag由服务器端生成，而后服务器经过响应头发送给客户端。
客户端使用**（If-Match/If-None-Match）** 这个条件判断请求来验证资源是否修改。
第一次请求
1.客户端发起 HTTP GET 请求一个文件；
2.服务器处理请求，返回文件内容和一堆Header，固然包括ETag(例如"2e681a-6-5d044840")(假设服务器支持ETag生成和已经开启了ETag)，状态码200。
第二次请求
一、客户端发起 HTTP GET 请求一个文件，注意这个时候客户端同时发送一个If-None-Match头，这个头的内容就是第一次请求时服务器返回的Etag：2e681a-6-5d0448402。
二、服务器检查该ETag，并判断出该页面自上次客户端请求以后是否被修改，所以If-None-Match为False，即没有被修改，则响应header和空的body，浏览器直接从缓存中获取数据信息。返回状态码304。若是ETag被修改了，说明资源被改动过，则响应整个资源内容，返回状态码200。
可是实际应用中因为Etag的计算是使用算法来得出的，而算法会占用服务端计算的资源，全部服务端的资源都是宝贵的，因此就不多使用Etag了。

6.二、若是服务器同时设置了Cache-Control:max-age和Expires以及ETag(If-None-Match)、If-Modified-Since（Last Modified）时，怎么办？
具体判断过程以下所示。

当发送一个服务器请求时，浏览器首先会进行缓存过时判断。浏览器根据缓存过时时间判断缓存文件是否过时。
情景一(Cache-Control等浏览器本地判断)：
若没有过时，则不向服务器发送请求，直接使用缓存中的结果，此时咱们在浏览器控制台中能够看到 200 OK(from cache) ，此时的状况就是彻底使用缓存，浏览器和服务器没有任何交互的。
情景二(服务器端判断)：
若已过时，则向服务器发送请求，此时请求中会带上设置的文件修改时间和ETag，而后进行资源更新判断。这要分两种情形进行判断。
情形一： 若两种判断的结论都是文件没有被修改过，则服务器就不给浏览器发index.html的内容了，直接告诉它，文件没有被修改过，你用你那边的缓存吧—— 304 Not Modified， 此时浏览器就会从本地缓存中获取index.html的内容。
情形二： 若文件修改时间和ETag判断有任意一个没有经过，则服务器会受理这次请求。并从服务器加载数据。

总结： 两类缓存机制能够同时存在，强制缓存的优先级高于协商缓存，当执行强制缓存时，若是expire字段对应的时间还未过时，则直接使用本地缓存数据，过时了再进行缓存协商。总而言之，先在浏览器端判断缓存是否过时，没有过时则使用本地缓存（状态码为200 from cache）。过时了再进行协商缓存，若是经过判断ETag和文件最后修改时间，发现请求文件都没被修改过，则直接从本地缓存中获取数据（状态码为304 Not Modified）。若是有一个修改了都会从服务器从新加载数据（状态码为200 Ok）

七、HTTP是如何基于TCP/IP通讯的？

为了准确无误地把数据送达目标处，TCP协议采用了三次握手策略。用TCP协议把数据包送出去后，TCP不会对传送后的状况置之不理，它必定会向对方确认是否成功送达。握手过程当中使用了TCP的标志：SYN和ACK。
一、发送端首先发送一个带SYN标志的数据包给对方。（发送端发数据包）
二、接收端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息。(接收端表示知道)
三、最后，发送端再回传一个带ACK标志的数据包，表明"握手"结束。若在握手过程当中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包。 (接收端回传数据包)

断开一个TCP链接则须要“四次挥手”：

一、第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不会再给你发数据了(固然，在FIN包以前发送出去的数据，若是没有收到对应的ACK确认报文，主动关闭方依然会重发这些数据)，可是，此时主动关闭方还能够接受数据。（主动关闭方将不会发送数据）
二、第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方。(被动关闭方知道将不会收到数据)
三、第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，个人数据也发送完了，不会再给你发数据了。(被动关闭方将不会发送数据)
四、第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方至此，完成四次挥手。(主动关闭方知道将不会收到数据)

八、TCP与UDP的区别?

TCP（Transmission Control Protocol，传输控制协议）是基于链接的协议，也就是说，在正式收发数据前，必须和对方创建可靠的链接。一个TCP链接必需要通过三次“对话”才能创建起来。
UDP（User Data Protocol，用户数据报协议）是与TCP相对应的协议。它是面向非链接的协议，它不与对方创建链接，而是直接就把数据包发送过去。udp实时性比较好，可是质量就不敢保证了。UDP适用于一次只传送少许数据、对可靠性要求不高的应用环境。

九、常见web安全及防御原理?

一、XSS(Cross Site Scripting)

跨站脚本攻击。恶意攻击者往Web页面里插入恶意的Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。分为存储型和反射型两类。

存储型XSS： 存储型XSS，持久化，代码是存储在服务器中的，如在我的信息或发表文章等地方，加入代码，若是没有过滤或过滤不严，那么这些代码将储存到服务器中，用户访问该页面的时候触发代码执行。这种XSS比较危险，容易形成蠕虫，盗窃cookie。

反射型XSS： 非持久化，须要欺骗用户本身去点击连接才能触发XSS代码（服务器中没有这样的页面和内容），通常容易出如今搜索页面。

常见攻击手段：
一、攻击者在论坛中放一个看似安全的连接，骗取用户点击后，窃取cookie中的用户私密信息；
二、或者攻击者在论坛中加一个恶意表单，当用户提交表单的时候，却把信息传送到攻击者的服务器中，而不是用户本来觉得的信任站点。

常见防护手段：
一、代码里对用户输入的地方和变量都须要仔细检查长度和对"<",">",";","’"等特殊字符作过滤(长度限制及特殊字符判断)；
二、任何内容写到页面以前都必须加以encode，避免不当心把html tag弄出来（encode解密）。
三、首先，避免直接在cookie中泄露用户隐私，例如email、密码等等。其次，经过将cookie和系统ip绑定来下降cookie泄露后的危险。这样攻击者获得的cookie没有实际价值，不可能拿来重放。最后，若是网站不须要在浏览器端对cookie进行操做，能够在Set-Cookie末尾加上HttpOnly来防止javascript代码直接获取cookie(cookie)。
四、尽可能采用POST而非GET提交表单。

二、CSRF(Cross-site request forgery)

跨站请求伪造。也被称为“One Click Attack”或者Session Riding。攻击经过在受权用户访问的页面中包含连接或者脚本的方式工做。与XSS的区别在于：XSS是获取信息，不须要提早知道其余用户页面的代码和数据包。CSRF是代替用户完成指定的动做，须要知道其余用户页面的代码和数据包。与XSS攻击相比，CSRF攻击每每不大流行和难以防范，因此被认为比XSS更具危险性。

要完成一次CSRF攻击，受害者必须依次完成两个步骤：
一、登陆受信任网站A，并在本地生成Cookie。
二、在不登出A的状况下，访问危险网站B。

常见攻击手段 ：一个网站用户Bob可能正在浏览聊天论坛，而同时另外一个用户Alice也在此论坛中，而且后者刚刚发布了一个具备Bob银行连接的图片消息。设想一下，Alice编写了一个在Bob的银行站点上进行取款的form提交的连接，并将此连接做为图片src。若是Bob的银行在cookie中保存他的受权信息，而且此cookie没有过时，那么当Bob的浏览器尝试装载图片时将提交这个取款form和他的cookie，这样在没经Bob赞成的状况下便受权了此次事务。

CSRF的防护手段
一、服务端的CSRF方式方法不少样，但总的思想都是一致的，就是在客户端页面增长伪随机数。
二、经过验证码的方法。
三、对于web站点，将持久化的受权方法（例如cookie或者HTTP受权）切换为瞬时的受权方法（在每一个form中提供隐藏field）。一种相似的方式是在form中包含秘密信息、用户指定的代号做为cookie以外的验证。

三、sql注入（来自百度百科）

就是经过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来讲，它是利用现有应用程序，将（恶意的）SQL命令注入到后台数据库引擎执行。

防护方法：
1.永远不要信任用户的输入。对用户的输入进行校验，能够经过正则表达式，或限制长度；对单引号和双"-"进行转换等
2.永远不要使用动态拼装sql，可使用参数化的sql或者直接使用存储过程进行数据查询存取。
3.永远不要使用管理员权限的数据库链接，为每一个应用使用单独的权限有限的数据库链接。
4.不要把机密信息直接存放，加密或者hash掉密码和敏感的信息。
5.应用的异常信息应该给出尽量少的提示，最好使用自定义的错误信息对原始错误信息进行包装
6.sql注入的检测方法通常采起辅助软件或网站平台来检测，软件通常采用sql注入检测工具jsky，网站平台就有亿思网站安全平台检测工具。MDCSOFT SCAN等。采用MDCSOFT-IPS能够有效的防护SQL注入，XSS攻击等。

参考文档：
一、HTTP----HTTP缓存机制
 二、程序员都该懂点 HTTP
三、HTTP 缓存
 四、LTTP缓存-MDN
五、99%的人都理解错了HTTP中GET与POST的区别