令人心动的HTTP知识点大全

前言

令人心动的http知识点，学习面试，必知必会！（本文较长，也可选择看加重部分哦）

一、TCP/IP协议族

1、定义

所有互联网相关的协议（http/tcp/udp/ip/dns/ftp等）的总称，http协议只是其中一小部分。

2、分层

应用层、传输层、网络层、数据链路层

3、为什么要分层？

分工明确， 各司其职，谁不行就换谁 ，互不影响，互相独立，同时又 互相帮助，共成完成一件大事。

4、每层都有什么职责？

应用层： 向用户提供应用服务时通信的活动 ，基本上我们平时直接接触到的协议大都在这，如 http、ftp、dns 等。

传输层： 负责传输数据的控制 ，传输层为两台主机上的应用程序提供端到端的通信。传输层 只关心通信的起始端和目的端，而不在乎数据包的中转过程 ，传输层是我们的外交官，知道如何与其他国家建立一个安全稳定的链接，以保证数据传输的准确性和安全性， tcp和udp 协议在这层。

网络层：传输层不关心的 中转过程 在这里做，网络层实现数据包的选路和转发，负责在 复杂的计算机、路由、中转服务器等网络设备中选择一条适合的传输路线。 网络层就是一个导航系统，在错综复杂的路中选择一条合适的行进路线，保证外交官能放心的出使。IP协议就在这层。

数据链路层： 负责真实数据的传递。用来处理链接数据的硬件部分 ，包括控制操作系统、驱动、网卡和光纤等。在物理硬件中进行数据传输，使用IP地址是做不到的，必须使用机器的物理地址（MAC地址），那我没有MAC地址怎么办？可以使用ARP协议可以通过目标设备的IP地址，查询目标设备的MAC地址，以保证通信的顺利进行。这里是真正的交通工具，外交官就是在这坐车去出使的。

5、发出一个http请求是如何进行网络流转的？

6、TCP三次握手

什么是三次握手：TCP提供了一种可靠、面向连接、字节流、传输层的服务，为了准确无误地把数据送到目标处，采用三次握手开启一个TCP连接。

何时握手：http信息传到传输层之后，向网络层传递信息之前，先握手，建立稳定的TCP链接，OK了在进行数据传输。

如何握手：由客户端向服务端发送SYN，服务端向客户端发送SYN+ACK响应报文,客户端再向服务端发送一个ACK响应报文，这样就然后建立一个完整的连接。

为什么是三次：至少需要三次握手，才能让客户端和服务器双方都知道自己和对方的发送能力、和接收能力没有问题。

第一次握手：客户端向服务端发送SYN。服务端知道了客户端的发送能力和自己的接收能力没有问题。

第二次握手：服务端向客户端发送SYN+ACK响应报文。客户端知道了自己的发送能力和接收能力、服务端的接收能力和发送能力没有问题。

第三次握手：客户端再向服务端发送一个ACK响应报。服务端知道自己发送能力，客户端的接收能力没有问题。

示意图：

7、TCP四次挥手

什么是四次挥手：TCP连接的关闭需要发送四个包，因此称为四次挥手。

何时挥手：想要关闭TCP链接时，客户端或服务器均可主动发起挥手动作。

如何挥手：

（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送。

（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。

（3） 服务器关闭客户端的连接，发送一个FIN给客户端。

（4） 客户端发回ACK报文确认，并将确认序号设置为收到序号加1。

为什么是四次：由于TCP连接是 全双工 的，因此 每个方向都必须单独进行关闭 。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

二、网络请求方法

GET：获取资源。

HEAD：类似于GET，但是只获取响应头，无数据返回，用于确认URI有效性及资源的更新日期等。

POST：提交数据。（虽然get也可以，但是一般不用get方法提交，安全性不好，可传输的数据容量也比较小）

PUT【不常用】：传输文件。

DELETE【不常用】：删除文件。

CONNECT：改用隧道协议链接代理。

OPTIONS：询问服务器支持的请求方法。

TRACE【不常用】：使用Max-Forards追逐请求通信路径，用于做网络诊断。

三、状态码

1、状态码范围

1XX：信息性状态码

2XX： 成功

3XX： 重定向

4XX：客户端错误

5XX：服务器错误

2、常用14种：

200： 成功

204：成功，但是没有资源返回，一般在只需要客户端向服务器发送信息，而服务器不需要发送新的信息内容的情况下使用。

206：范围请求响应成功，响应头里用content-range指定范围的实体内容。

301：永久重定向，以后这个url我将永远永远地重定向到A页面，如果收藏这个网址了，你可以换成A页面的链接了，以后都用新的了。

302：临时重定向，我临时把你请求的url重定向到A页面了，下次我还可能把这个url重定向到B页面。

303：功能同302，但是303明确表示要用get方法获取资源，这点与302有区别

304：自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。

307：临时重定向。该状态码与302有相同的含义。尽管302标准禁止post变化get，但实际使用时大家不遵守。 307会遵照浏览器标准，不会从post变为get。

400：请求语法错误

401：需要验证

403：禁止访问

404：没有请求的资源，也可以在服务器拒绝访问且不想说明理由时使用，有些时候url写错了也有可能导致404

500：服务器内部错误

503：服务器正忙或者停机维护

四、HTTP首部

1、通用首部字段（请求报文和响应报文都能用）

Cache-Control:通过指定首部字段Cache-Control的指令，就能操作缓存的工作机制。

Connection:控制不在转发给代理的首部字段；管理持久连接。

Data：表明创建HTTP报文的时间和日期。

Pragma:只用在客户端发送的请求中，所有的中间服务器不返回缓存的资源。

Trailer：事先说明报文主体后记录了哪些首部字段。同样可以用在分块传输编码时。

Transfer-Encoding:规定了传输报文主体时采用的编码方式。

Upgrade:用于检测HTTP协议及其他协议是否可以使用更高的版本进行通信。

Via：为了追踪客户端与服务器之间的请求和响应报文的传输路径。

Warning：通常会告知用户一些与缓存相关的问题的警告。

2、请求首部字段

Accept：该字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级。

Accept-Charset:用来通知服务器用户代理支持的字符集及字符集的相对优先顺序，可一次性指定多种字符集。

Accept-Encoding:用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序。

Accept-Language:用来告知服务器用户代理嫩巩固处理的自然语言集（中文或英文等），以及自然语言集的相对优先级。

Authorization:用来告知服务器，用户代理的认证信息。

Expect:客户端使用首部字段Except来告知服务器，期望出现的某种指定行为。

From：用来告知服务器使用用户代理的用户的电子邮件地址。

Host:告知服务器，请求的资源所处的互联网主机名和端口号。Host首部字段在HTTP/1.1规范内是唯一一个必须包含在请求内的首部字段。

If-Match：类似于If-xxx这样的请求首部，可以称为条件请求。

If-Modified-Since:告知服务器若该字段值早于资源的更新时间，则希望能处理该请求。

If-None-Match:该字段值得实体标记值与请求资源的ETag不一致时，它就告知服务器处理该请求。

If-Range：它告知服务器若指定的If-Range字段值和请求资源的ETag值或时间相一致时，则作为范围请求处理。反之则返回全体资源。

If-Unmodified-Since:告知服务器，指定的请求资源只有在字段值内指定的日期时间之后，未发生更新的情况下，才能处理请求。

Max-Forwards：通过TRACE方法或OPTIONS方法，发送包含首部字段Max-Forwards的请求时，该字段以十进制整数形式指定可经过的服务器最大数目。当服务器接收到Max-Forwards值为0的请求时，则不再进行转发，而是直接返回响应。

Proxy-Authorization：客户端会发送包含首部字段Proxy-Authorization的请求，以告知服务器认证所需要的信息。

Range：告知服务器资源的指定范围。

TE：告知服务器客户端能够处理响应的传输编码方式及相对优先级。

User-Agent:将创建请求的浏览器用户代理名称等信息传达给服务器。

3、响应首部字段

Accept-Ranges：用来告知客户端服务器是否能够处理范围请求，以指定获取服务器端某个部分的资源。

Age:告知客户端，源服务器在多久前创建了响应。单位秒。

ETag：告知客户端实体标识，它是一种可将资源以字符串形式做唯一标识的方式。

Location:可以将响应接收方引导至某个与请求URI位置不同的资源。

Proxy-Authenticate:把由代理服务器所要求的认证信息发送给客户端。

Retry-After:告知客户端应该在多久之后再次发送请求。

Server：告知客户端当前服务器上安装的HTTP服务器应用程序的信息。

Vary：可对缓存进行控制，源服务器回向代理服务器传达关于本地缓存使用方法的命令。

WWW-Authenticate:用于HTTP访问认证。

4、实体首部字段（约定请求实体）

Allow：用于通知客户端能够支持Request-URI指定资源的所有HTTP方法。

Content-Encoding:告知客户端服务器对实体的主体部分选用的内容编码方式。（gzip/compress/deflate/identity)

Content-Language:告知客户端，实体主体使用的自然语言。（中文或英文等语言）

Content-Length：表明了实体主体部分的大小。

Content-Location:给出与报文主体返回资源对应的URI。

Content-MD5：是一串由MD5算法生成的值，其目的在于检查报文主体在传输过程中是否保持完整，以及确认传输到达。

Content-Range:针对范围请求，返回响应时使用的首部字段，能告知客户端作为相应返回的实体的哪个部分符合范围请求。

Content-Type:说明了实体主体内对象的媒体类型，该字段用type/subtype形式赋值。

Expires：会将资源失效的日期告知客户端。

Last-Modified：指明资源最终修改的时间。

五、浏览器缓存与前端数据存储

1、http缓存：

先强缓存：

浏览器先根据这个资源的 http头信息来判断 是否命中强缓存。如果命中则直接加在缓存中的资源，并 不会将请求发送到服务器 。在chrome控制台的Network选项中可以看到该请求返回200的状态码，并且Size显示from disk cache或from memory cache。

后协商缓存：

如果未命中强缓存，则进行协商缓存，浏览器把请求发到服务器， 服务器判断浏览器本地缓存是否失效 。若可以使用，则服务器并不会返回资源信息，浏览器继续 从缓存加载资源 。如果未命中协商缓存，则服务器会将完整的 资源返回给浏览器 ，浏览器加载新资源，并更新缓存。

强缓存：

利用http的返回头中的 Expires或者Cache-Control 两个字段来控制的，用来表示资源的缓存时间。

1.Expires：缓存过期时间，用来指定资源到期的时间，是服务器端的具体的时间点。也就是说， Expires=max-age + 请求时间 ，需要和 Last-modified 结合使用。Expires是Web服务器响应消息头字段，在响应http请求时 告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据，而无需再次请求 。Expires 是 HTTP/1 的产物，受限于本地时间，如果修改了本地时间，可能会造成缓存失效。

2.Cache-Control：在HTTP/1.1中，Cache-Control是最重要的规则，主要用于控制网页缓存。比如当 Cache-Control:max-age=300 时，则代表在这个请求正确返回时间（浏览器也会记录下来）的 5分钟内再次加载资源，就会命中强缓存 。

Cache-Control 可以在请求头或者响应头中设置，并且可以组合使用多种指令：

3.Expires和Cache-Control区别：没啥大区别，Expires是http1.0产物，

Cache-Control是http1.1的产物，同时存在的话， Cache-Control优先级高于Expires ，Expires是过时的产物，现阶段它的存在只是一种兼容性的写法。

协商缓存：

若未命中强缓存，则浏览器会将请求发送至服务器。服务器根据http头信息中的 Last-Modify/If-Modify-Since或Etag/If-None-Match 来判断是否命中协商缓存。如果命中，则http返回码为304，浏览器从缓存中加载资源。

1.Last-Modify/If-Modify-Since：

①浏览器第一次请求一个资源的时候，服务器返回的header中会加上Last-Modify， Last-modify是一个时间标识该资源的最后修改时间 ，例如Last-Modify: Thu,31 Dec 2037 23:59:59 GMT。

②当浏览器再次请求该资源时，发送的请求头中会包含I f-Modify-Since，该值为缓存之前返回的Last-Modify 。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否命中缓存。

2.ETag/If-None-Match：

与Last-Modify/If-Modify-Since不同的是， Etag/If-None-Match返回的是一个校验码 （ETag: entity tag）。ETag可以保证每一个资源是 唯一 的，资源变化都会导致ETag变化。 ETag值的变更则说明资源状态已经被修改。 服务器根据浏览器上发送的If-None-Match值来判断是否命中缓存。

3.Etag的出现解决了Last-Modified的什么问题：

① Last-Modified标注的最后修改只能精确到秒级，如果某些文件在1秒钟以内，被修改多次的话，它将不能准确标注文件的修改时间

②如果某些文件会被定期生成，当有时内容并没有任何变化，但Last-Modified却改变了，导致文件没法使用缓存

③有可能存在服务器没有准确获取文件修改时间，或者与代理服务器时间不一致等情形

Etag是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符，能 够更加准确的控制缓存。 Last-Modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304。

4.总结：

对于强缓存，服务器通知浏览器一个缓存时间，在缓存时间内，直接用缓存，不在时间内，执行协商缓存策略。

对于协商缓存，将缓存信息中的Etag和Last-Modified通过请求发送给服务器，由服务器校验，返回304状态码时，浏览器直接使用缓存，否则返回资源。

第一次请求

再次请求：

5.用户行为对缓存的影响：

2、前端数据存储

3、如何根据不同场景设计缓存方案？

1.服务端缓存策略-不常变化的资源：长时间强缓存。为了让缓存发挥最大效率，你要做的并不是更改文件的内容，而是应该更改资源的URL（通过版本控制让强缓存失效）。(常用)

Cache-Control: max-age=31536000 // 设置缓存时间为1年

2.服务端缓存策略-经常变化的资源：协商缓存。首先需要使用Cache-Control: no-cache 使浏览器每次都请求服务器，然后配合 ETag 或者 Last-Modified 来验证资源是否有效。这样的做法虽然不能节省请求数量，但是能显著减少响应数据大小。(常用)

Cache-Control: no-cache

3.客户端-主动记录简单状态、参与http通信、4K以内、浏览器行为跟踪：使用cookie。(常用)

4.客户端-主动存储一些不参与http通信的数据、5M以内、持久化存储、关闭对话仍然存在：使用localstorage。(常用)

5.客户端-主动存储一些不参与http通信的数据、5M以内、持久化存储、关闭对话清除：使用sessionstorage。(不常用)

6.客户端-主动存储大量结构化的数据、浏览器端数据库：使用indexdb。(不常用)

六、HTTPS

HTTPS = HTTP + SSL二者合二为一，威力无比

1、http存在的问题

通信使用明文，不验证通信方的身份，无法验证报文的完整性。

2、https是什么

https并不是一种新的协议，只是HTTP通信接口部分用SSL和TLS协议代替而已。https = http+加密+认证+完整性保护。

通常，HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了。简言之，所谓HTTPS，其实就是身披SSL协议这层外壳的HTTP。

HTTPS 协议的主要功能基本都依赖于 TLS/SSL 协议，TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

3、http与https的差距

1.HTTP 是明文传输协议，HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。

2.HTTPS比HTTP更加安全，对搜索引擎更友好，利于SEO,谷歌、百度优先索引HTTPS网页;

3.HTTPS需要用到SSL证书，而HTTP不用;

4.HTTPS标准端口443，HTTP标准端口80;

5.HTTPS基于传输层，HTTP基于应用层;

6.HTTPS在浏览器显示绿色安全锁，HTTP没有显示;

4、https加密方式

1.对称加密

这种方式加密和解密同用一个密钥。加密和解密都会用到密钥。 没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。

以对称加密方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落人攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。

2.非对称加密

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。顾名思义， 私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。

使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

3.https加密方式：对称加密+非对称加密

使用对称密钥的好处是解密的效率比较快，使用非对称密钥的好处是可以使得传输的内容不能被破解，因为就算你拦截到了数据，但是没有对应的私钥，也是不能破解内容的。就比如说你抢到了一个保险柜，但是没有保险柜的钥匙也不能打开保险柜。那我们就将对称加密与非对称加密结合起来,充分利用两者各自的优势， 在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。

具体做法是： 发送密文的一方使用对方的公钥进行加密处理“对称的密钥”，然后对方用自己的私钥解密拿到“对称的密钥”，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信。 所以，HTTPS采用对称加密和非对称加密两者并用的混合加密机制。

5、https工作流程

1.Client发起一个HTTPS（比如https://juejin.im/user/5a9a9cdcf265da238b7d771c）的请求，根据RFC2818的规定，Client知道需要连接Server的443（默认）端口。

2.Server把事先配置好的公钥证书（public key certificate）返回给客户端。

3.Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书）。如果验证通过则继续，不通过则显示警告信息。

4.Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给Server。

5.Server使用自己的私钥（private key）解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。

6.Server使用对称密钥加密“明文内容A”，发送给Client。

7.Client使用对称密钥解密响应的密文，得到“明文内容A”。

8.Client再次发起HTTPS的请求，使用对称密钥加密请求的“明文内容B”，然后Server使用对称密钥解密密文，得到“明文内容B”。

七、Web安全

1、XSS

什么是XSS：XSS (Cross Site Script)，跨站脚本攻击，因为缩写和 CSS (Cascading Style Sheets) 重叠，所以只能叫 XSS。

原理：恶意攻击者往 Web 页面里插入恶意可执行网页脚本代码，当用户浏览该页之时，嵌入其中 Web 里面的脚本代码会被执行，从而可以达到攻击者盗取用户信息或其他侵犯用户安全隐私的目的。

分类：非持久型 XSS、持久型 XSS、基于字符集的 XSS、基于 Flash 的跨站 XSS

非持久型 XSS：

①攻击方式：非持久型 XSS 漏洞，也叫反射型 XSS 漏洞，一般是通过给别人发送带有恶意脚本代码参数的 URL，当 URL 地址被打开时，特有的恶意代码参数被 HTML 解析、执行。

②攻击实例：

正常url：http://www.test.com/message.html?from=Hello,World

前端获取url中from参数渲染到dom中，没问题

非正常url：http://www.test.com/message.html?from=

前端获取url中from参数渲染到dom中，恶意操作的代码就会被执行

③防守策略：

1 . Web 页面渲染的所有内容或者渲染的数据都必须来自于服务端。

2 . 尽量不要从 URL，document.referrer，document.forms 等这种 DOM API 中获取数据直接渲染。

3 . 尽量不要使用 eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，

innerHTML，document.creteElement() 等可执行字符串的方法。

4 . 如果做不到以上几点，也必须对涉及 DOM 渲染的方法传入的字符串参数做 escape 转义。

5 . 前端渲染的时候对任何的字段都需要做 escape 转义编码。

持久型 XSS：

①攻击方式：持久型 XSS 漏洞，也被称为存储型 XSS 漏洞，一般存在于 Form 表单提交等交互功能，如发帖留言，提交文本信息等，黑客利用的 XSS 漏洞，将内容经正常功能提交进入数据库持久保存，当前端页面获得后端从数据库中读出的注入代码时，恰好将其渲染执行。

②攻击满足条件：

1 . POST 请求提交表单后端没做转义直接入库。

2 . 后端从数据库中取出数据没做转义直接输出给前端。

3 . 前端拿到后端数据没做转义直接渲染成 DOM。

③防守策略：

1 . 后端在入库前应该选择不相信任何前端数据，将所有的字段统一进行转义处理。

2 . 后端在输出给前端数据统一进行转义处理。

3 . 前端在渲染页面 DOM的时候应该选择不相信任何后端数据，任何字段都需要做转义处理。

基于字符集的 XSS：

①攻击方式：其实现在很多的浏览器以及各种开源的库都专门针对了 XSS 进行转义处理，尽量默认抵御绝大多数 XSS 攻击，但是还是有很多方式可以绕过转义规则，让人防不胜防。比如「基于字符集的 XSS 攻击」就是绕过这些转义处理的一种攻击方式，比如有些 Web 页面字符集不固定，用户输入非期望字符集的字符，有时会绕过转义过滤规则。

②攻击实例：utf-7 是可以将所有的 unicode 通过 7bit 来表示的一种字符集 (但现在已经从 Unicode 规格中移除)。这个字符集为了通过 7bit 来表示所有的文字, 除去数字和一部分的符号,其它的部分将都以 base64 编码为基础的方式呈现。

可以形成「基于字符集的 XSS 攻击」的原因是由于浏览器在 meta 没有指定 charset 的时候有自动识别编码的机制，所以这类攻击通常就是发生在没有指定或者没来得及指定 meta 标签的 charset 的情况下。

③防守策略：

1 . 记住指定

2 . XML 中不仅要指定字符集为 utf-8，而且标签要闭合

基于 Flash 的跨站 XSS：

①攻击方式：基于 Flash 的跨站 XSS 也是属于反射型 XSS 的一种，虽然现在开发 ActionScript 的产品线几乎没有了，但还是提一句吧，AS 脚本可以接受用户输入并操作 cookie，攻击者可以配合其他 XSS（持久型或者非持久型）方法将恶意 swf 文件嵌入页面中。主要是因为 AS 有时候需要和 JS 传参交互，攻击者会通过恶意的 XSS 注入篡改参数，窃取并操作cookie。

③防守策略：

1 . 严格管理 cookie 的读写权限

2 . 对 Flash 能接受用户输入的参数进行过滤 escape 转义处理

2、CSRF

什么是CSRF：CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

示意图：

CSRF 攻击必须要有三个条件：

1 . 用户已经登录了站点 A，并在本地记录了 cookie

2 . 在用户没有登出站点 A 的情况下（也就是 cookie 生效的情况下），访问了恶意攻击者提供的引诱危险站点 B (B 站点要求访问站点A)。

3 . 站点 A 没有做任何 CSRF 防御

CSRF防御策略：

1. 验证 HTTP Referer 字段

根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。只需要在最后给所有安全敏感的只需要统一增加一个拦截器来检查 Referer 的值就可以。特别是对于当前现有的系统，不需要改变当前系统的任何已有代码和逻辑，没有风险，非常便捷。 然而，这种方法并非万无一失。对于某些浏览器，目前已经有一些方法可以篡改 Referer 值。而且，用户自己可以设置浏览器使其在发送请求时不提供 Referer。所以这种方式并不是万无一失。

2. 在请求地址中添加 token 并验证

CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开。跟验证码类似，只是用户无感知。

①服务端给用户生成一个token，加密后传递给用户

②在提交请求时，需要携带这个token

③服务端验证token是否正确

3. 在 HTTP 头中自定义属性并验证

这种方法也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。

3、 SQL 注入

什么是SQL 注入：SQL 注入漏洞（SQL Injection）是 Web 开发中最常见的一种安全漏洞。可以用它来从数据库获取敏感信息，或者利用数据库的特性执行添加用户，导出文件等一系列恶意操作，甚至有可能获取数据库乃至系统用户最高权限。

SQL攻防策略：

造成 SQL 注入的原因是因为程序没有有效的转义过滤用户的输入 ，使攻击者成功的向服务器提交恶意的 SQL 查询代码，程序在接收后错误的将攻击者的输入作为查询语句的一部分执行，导致原始的查询逻辑被改变，额外的执行了攻击者精心构造的恶意代码。

很多 Web 开发者没有意识到 SQL 查询是可以被篡改的，从而把 SQL 查询当作可信任的命令。殊不知，SQL 查询是可以绕开访问控制，从而绕过身份验证和权限检查的。更有甚者，有可能通过 SQL 查询去运行主机系统级的命令。

4、点击劫持

什么是点击劫持：点击劫持是一种视觉欺骗的攻击手段。攻击者将需要攻击的网站通过 iframe 嵌套的方式嵌入自己的网页中，并将 iframe 设置为透明，在页面中透出一个按钮诱导用户点击。

攻击方式：

用户在登陆 A 网站的系统后，被攻击者诱惑打开第三方网站，而第三方网站通过 iframe 引入了 A 网站的页面内容，用户在第三方网站中点击某个按钮（被装饰的按钮），实际上是点击了 A 网站的按钮。

防守策略：

X-FRAME-OPTIONS：这是一个 HTTP 响应头，在现代浏览器有一个很好的支持。这个 HTTP 响应头 就是为了防御用 iframe 嵌套的点击劫持攻击。

该响应头有三个值可选，分别是

DENY：表示页面不允许通过 iframe 的方式展示

SAMEORIGIN：表示页面可以在相同域名下通过 iframe 的方式展示

ALLOW-FROM：表示页面可以在指定来源的 iframe 中展示

八、HTTP/2和HTTP/3

1、HTTP/2简介

2015 年，HTTP/2 发布。HTTP/2 是现行 HTTP 协议（HTTP/1.x）的替代，但它不是重写，HTTP 方法/状态码/语义都与 HTTP/1.x 一样。HTTP/2 基于 SPDY3，专注于性能，最大的一个目标是在用户和网站间只用一个连接（connection）。

2、HTTP/2 新特性

1.二进制传输

HTTP/2 采用二进制格式传输数据，而非 HTTP 1.x 的文本格式，二进制协议解析起来更高效。 HTTP / 1 的请求和响应报文，都是由起始行，首部和实体正文（可选）组成，各部分之间以文本换行符分隔。HTTP/2 将请求和响应数据分割为更小的帧，并且它们采用二进制编码。

2.多路复用

在 HTTP/2 中引入了多路复用的技术。多路复用很好的解决了浏览器限制同一个域名下的请求数量的问题，同时也接更容易实现全速传输，毕竟新开一个 TCP 连接都需要慢慢提升传输速度。

3. Header压缩

在 HTTP/1 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千的字节。

为了减少这块的资源消耗并提升性能， HTTP/2 对这些首部采取了压缩策略。

4.服务器推送

HTTP/2新增的一个强大的新功能，就是服务器可以对一个客户端请求发送多个响应。服务器向客户端推送资源无需客户端明确的请求。

3、HTTP/3简介

虽然 HTTP/2 解决了很多之前旧版本的问题，但是它还是存在一个巨大的问题，主要是底层支撑的 TCP 协议造成的。

上文提到 HTTP/2 使用了多路复用，一般来说同一域名下只需要使用一个 TCP 连接。但当这个连接中出现了丢包的情况，那就会导致 HTTP/2 的表现情况反倒不如 HTTP/1 了。

因为在出现丢包的情况下，整个 TCP 都要开始等待重传，也就导致了后面的所有数据都被阻塞了。但是对于 HTTP/1.1 来说，可以开启多个 TCP 连接，出现这种情况反到只会影响其中一个连接，剩余的 TCP 连接还可以正常传输数据。

那么可能就会有人考虑到去修改 TCP 协议，其实这已经是一件不可能完成的任务了。因为 TCP 存在的时间实在太长，已经充斥在各种设备中，并且这个协议是由操作系统实现的，更新起来不大现实。

基于这个原因，Google 就更起炉灶搞了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上，HTTP/3 之前名为 HTTP-over-QUIC，从这个名字中我们也可以发现，HTTP/3 最大的改造就是使用了 QUIC。

QUIC 虽然基于 UDP，但是在原本的基础上新增了很多功能，接下来我们重点介绍几个 QUIC 新功能。

4、QUIC 新特性

1.大大缩短连接建立时间

由于建立在 UDP 的基础上，同时又实现了 0RTT 的安全握手，所以在大部分情况下，只需要 0 个 RTT 就能实现数据发送，在实现前向加密的基础上，并且 0RTT 的成功率相比 TLS 的会话记录单要高很多。

2.改进的拥塞控制

使用UDP，不存在 TCP 队头阻塞

3.无线头阻塞的多路复用

虽然 HTTP/2 支持了多路复用，但是 TCP 协议终究是没有这个功能的。QUIC 原生就实现了这个功能，并且传输的单个数据流可以保证有序交付且不会影响其他的数据流，这样的技术就解决了之前 TCP 存在的问题。

4.前向纠错

QUIC 协议有一个非常独特的特性，称为向前纠错 (Forward Error Correction，FEC)，每个数据包除了它本身的内容之外，还包括了部分其他数据包的数据，因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。

九、其他问题

1、对于连接方式Long-Polling, Websockets, SSE(Server-Sent Event), WebRTC 之间的区别？

1.普通的http

①客户端从服务器端请求网页

②服务器作出相应的反应

③服务器返回相应到客户端

2.AJAX Polling：

①客户端使用普通的http方式向服务器端请求网页

②客户端执行网页中的JavaScript轮询脚本，定期循环的向服务器发送请求（例如每5秒发送一次请求），获取信息

③服务器对每次请求作出响应，并返回相应信息，就像正常的http请求一样

3.Long-Polling：

①客户端使用普通的http方式向服务器端请求网页

②客户端执行网页中的JavaScript脚本，向服务器发送数据、请求信息

③服务器并不是立即就对客户端的请求作出响应，而是等待有效的更新

④当信息是有效的更新时，服务器才会把数据推送给客户端

⑤当客户端接收到服务器的通知时，立即会发送一个新的请求，进入到下一次的轮询

4.HTML5 Server Sent Events (SSE) / EventSource:

①客户端使用普通的http方式向服务器端请求网页

②客户端执行网页中的JavaScript脚本，与服务器之间建立了一个连接

③当服务器端有有效的更新时，会发送一个事件到客户端

5.HTML5 Websockets:

①客户端使用普通的http方式向服务器端请求网页

②客户端执行网页中的JavaScript脚本，与服务器之间建立了一个连接

③服务器和客户端之间，可以双向的发送有效数据到对方

6.WebRTC:

WebRTC是一种点对点类型的传输方式，它支持多种传输协议，如：UDP、TCP甚至是抽象层的协议。设计它时同时考虑到了允许使用可靠和不可靠的两种方式传输数据。这种技术一般应用在传输数据量较大的内容，比如音、视频等流媒体的传输。

7.Comet:

Comet是一种用于web的推送技术，能使服务器实时地将更新的信息传送到客户端，而无须客户端发出请求，目前有两种实现方式，长轮询和iframe流。如果你想了解更多，可以参考维基百科或者IBM

2、为什么利用多个域名来提供网站资源更有效？

1.CDN缓存更方便

动静分离，提高效率

2.突破浏览器并发限制，浏览器一次能发送的http请求是有限的

不同浏览器同一域名一般建立的链接不超过6个

3.节约cookie带宽

同域每次请求都要带上cookie，占用带宽

4.减少主域名的连接数，优化页面响应速度

节约主域名的连接数，从而提高客户端网络带宽的利用率，优化页面响应。因为老的浏览器（IE6是典型），针对同一个域名只允许同时保持两个HTTP连接。将图片等资源请求分配到其他域名上，避免了大图片之类的并不一定重要的内容阻塞住主域名上其他后续资源的连接（比如ajax请求）。

5.防止不必要的安全问题

对于UGC的内容和主站隔离，防止不必要的安全问题(用户上传js窃取主站cookie之类的)。正是这个原因要求用户内容的域名必须不是自己主站的子域名，而是一个完全独立的第三方域名。

（PS：关于多域名，也不是越多越好，虽然服务器端可以做泛解释，浏览器做dns解释也是耗时间的，而且太多域名，如果要走https的话，还有要多买证书和部署的问题，时间也会慢，一般不超过3个。域名发散和域名收敛之间会有一个折中的最优解，等你去探索吧！）

3、如何进行HTTP性能优化？

1.合理设置 HTTP缓存，可以大大的减少请求。

2.CSS Sprites，合并小图片，减少请求。

3.资源合并与压缩，减少请求，节省空间。

4.Inline Images

5.减少重定向，规避301（url最后文件夹不写/）

萌在最后

OK，that's all. 本期就到这里了，喜欢点个关注吧~!

参考链接

1. 《图解http》

2.https://blog.fundebug.com/2019/03/07/understand-http2-and-http3/

3.https://github.com/ljianshu/Blog/issues/56

4.https://github.com/ljianshu/Blog

5.https://www.cnblogs.com/laiqun/p/5478435.html

6.https://www.jianshu.com/p/303206ae2471

7.https://www.cnblogs.com/ranyonsue/p/8918908.html

8.https://www.cnblogs.com/lizhengtan/p/5494089.html