学长笔记开源了！

大家好，我是小林。

昨晚不是发了一篇读者（车干学长）看图解网络的学习心得嘛：我上 B 站了？

没想到他还做了小笔记，就是他把在面试过程中高频出现的网络面试题做了笔记。

一直有很多同学问我，看书记不住知识怎么办，其实最好的方式就是记笔记，学到的知识用自己语言输出出来，这样影响才会深刻的。

像我平常回答一些读者提问的 TCP 问题，我基本都能秒答，不是我记忆牛逼，是因为我写的太多了，不想记住都难。

我把昨天那位读者学图解网络时记的笔记要过来了，是一个精练版的笔记，适合面试时突击看看。但是不适合小白理解，因为都是文字描述，没有图的方式来讲解，所以小白还是先看图解网络，或者看视频。

这位读者（车干学长）因为找的是前端开发工作，所以他写的笔记都是 HTTP 相关的，而 TCP 的内容就涉及很少。TCP 的内容看我的图解网络就行了。

下面的笔记来源于读者（B站：车干学长）学习图解网络时的笔记，他也补充了一些我没写到的点，比如强制缓存/协商缓存之类的知识。

全文共 1w 字，干货满满！发车！

HTTP 篇

get 与 post的关系

get的含义就是获取网络资源。

post的含义就是发布新的网络资源。

安全、幂等方面，在安全方面，他们都是明文传输不存在安全的问题。然后就是get只是获取服务器的资源，不会对服务器内容进行修改所以说，不存在安全问题。

对于幂等方面，get请求得到的结果都是一样的，但是对于post而言却不是一样的。

HTTP 的特征

优点：

• 良好的跨平台性

不足：

• 明文传输
• 无状态

HTTP/1.1 的特点

1.长链接 connection：keep-alive

2.管道化传输，pipline

3.队头阻塞。

HTTP 与 HTTPS 的区别？

1.HTTP是超文本传输协议，信息是明文传输，存在安全风险。对于https而言就不存在这样的问题，https在tcp和http中使用了ssl/tls来进行数据加密。

2.HTTP的建立过程相对来说简单一些，HTTP在进行了tcp/ip协议的三次握手之后建立了链接就可以进行报文传输了。然而HTTPS在TCP三次握手之后还需要进行TLS/SSL的握手才能进行通信。

3.HTTP的端口号是80，HTTPS的端口号为443.

4.HTTPS需要向CA机构申请数字证书，来保证服务器身份的可信度。

由于HTTP是明文传输所以说在传输过程中主要有以下几个问题：

1. 窃听风险，通过抓包工具就可以获取到http传输过程中的数据内容。
2. 篡改风险，通过抓包工具可以获取到http传输的内容进行修改之后，再发送出去。
3. 冒充风险，由于冒充者可以收到发送方的信息，那么冒充者就可以冒充真正的发送方给接收方发送信息。

HTTPS在HTTP和TCP层之间加入了SSL/TLS协议，可以很好的解决这个问题，一下是SSL/TLS的一些特征。

1. 信息加密，解决的窃听风险。
2. 校验机制，因为https传输中都有校验和，如果被修改了，校验和将无法通过。
3. 身份证书，对于冒充风险而言，利用权威机构发布的CA就可以证明该服务器的身份。

HTTPS如何来解决HTTP的三个问题的呢？

1. 混合加密，首先是HTTPS使用混合加密的方式来解决窃听风险。
2. 摘要算法，摘要算法的方式去实现完整性。他可以使得数据生成独一无二的指纹，指纹用于校验传输数据的完整性，解决了篡改的风险。
3. CA中存放服务器公钥，冒充风险，主要来源于密钥传输的可能存在风险，那么我们就可以直接将公钥放置在证书中，让别人无法去篡改公钥，而后实现加密通信。

下面是以上三个问题的详细展开：

1. 混合加密：通过混合加密的方式，解决了通信过程中的窃听风险，保证了信息的机密性。HTTPS使用的是对称加密和非堆成加密相结合的混合加密方式。
1. 对称加密只需要使用一个密钥，加解密的速度比较快，但是密钥必须要保密，所以在进行密钥交换的时候就很困难。
2. 非对称加密使用了公钥和密钥，然后公钥可以任意发放，然而密钥却需要自己保存，解决了对称加密的密钥交换问题。
3. 在通讯建立的时候使用非对称加密的方式来沟通密钥。
4. 然后再正常沟通的过程中使用对称加密的方式来进行沟通。
5. 采用混合加密的方式原因如下：
2. 摘要算法：客户端在发送数据之前，就会将自己的数据全部进行一次hash，得出指纹，然后用于校验和，解决了篡改问题。如果在传输过程中数据被修改了那么我们的数据包就不能通过数据校验的过程。
3. 数字证书：客户端先向服务端索取共钥，然后使用公钥进行加密传输，服务端收到信息之后使用自己的私钥进行解密。但是这个时候就会存在问题，如果确保这个公钥是服务端发送过来的，中间的篡改者一样可以发送公钥给客户端，然后和客户端建立联系，然后客户端的信息产生巨大的威胁。所以就需要一个值得信任的第三方机构CA（数字证书认证机构），将服务器的公钥封锁到证书中去。只要证书是可信的，那么公钥就是可信的。因此通过数字证书的方式，保证了服务器公钥的身份，解决了冒充者的问题。

HTTPS是如何建立的，其间经历了什么？

SSL/TLS协议的基本流程为：客户端向服务端索取公钥，然后双方协商会话密钥，然后利用该会话密钥，进行加密通信。一共三步，前两步是SSL/TLS的建立过程，也就是握手阶段。握手阶段进行了四次通信。具体流程如下所示。

1.ClientHello

首先客户端向服务端发起加密通信请求。这一步中主要包含了以下信息。（1）客户端支持的SSL/TLS协议版本版本。（2）客户端生产的随机数（Client Random），后面用于生产「会话秘钥」。（3）客户端支持的加密算法，如RSA加密算法。

2.ServerHello

服务端接受到客户端发送的请求之后，返回给客户端一个回应，主要包含内容为：（1）确认SSL/TLS版本。（2）服务端生成的随机数，以后可以用于生成会话密钥。（3）客户端支持的加密算法，比如说RSA算法。（4）服务器的数字证书。

3.客户端响应

客户端收到服务器的相应之后，首先通过浏览器或者操作系统中的CA公钥，确认服务器的数字公钥的正确性。如果服务器的公钥没有问题，那么我们就会利用该公钥，对发送的内容进行加密。加密的内容主要包含了一下三个方面：（1）客户端随机数，用于会话密钥的生成。（2）服务器握手结束通知，表示服务器的握手阶段已经结束，之后的通信都用会话密钥进行通信。（3）这一项将之前所有的通信内容做一个摘要供服务端校验。

4.服务端响应

（1）加密方式改变通知，（2）服务端握手结束通知，并将之前的通信做一次摘要。

至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

HTTP/1.1、HTTP/2、HTTP/3 演变

首先谈及的是HTTP1.1相对于HTTP1.0提升了什么。

主要（1）HTTP1.1引入了长链接，这样的发送多个HTTP请求就不需要进行多次建立连接了，使用connection：keep-alive来进行控制。（2）就是管道化网络传输（pipline），在没有接受到客户端第一个请求回应的时候，就可以发送第二个网络请求。

HTTP1.1的问题：（1）头部阻塞：在http1.1的管道化传输中，虽然可以同时发送多个请求，但是只有收到第一个请求之后才能接受之后的请求，所以说如果第一个（对头）发生了阻塞，那么我们之后所有的请求都会被阻塞。（2）头部冗长重复：每次发送http都要发送一个冗长的请求，但是绝大部分重复的部分居多。（3）在该过程中，客户端永远都是发起方，服务端永远都是被动方。

HTTP2.0相对于HTTP1.1的性能提升之处：

1. 头部压缩，HTTP/2会压缩头部，对于HTTP1.1中的大量重复冗余的头部而言，可以消除重复的部分。
2. 二进制格式，不再像HTTP1.1中那种纯文本格式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，紧切统称为帧：头信息帧和数据帧。二进制帧的形式，计算机在收到报文之后，不需要转化为二进制，而是直接将该报文解析，这增加了数据传输的效率。
3. 数据流（多路复用）：HTTP/2 中的数据包不是按照顺序发送的，同一个链接中可能包含了多个不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。能够让各个请求都能独立。
4. 服务端推送：HTTP/2还在一定程度上改善了传统的请求-应答机制，服务不再是被动的等待响应，也可以主动给客户端发送消息。

HTTP3相对于HTTP2的提升？

HTTP/2 主要的问题在于，多个HTTP请求在复用一个TCP连接，下层的TCP协议是不转掉有多少个HTTP请求的。所以一旦发送丢包的情况，就会触发TCP的重传机制，这样在一个TCP连接中的所有的HTTP请求都必须要去等待这个丢了的包被重传回来。

1. HTTP/1.1中的管道（pipline）传输中如果有一个请求阻塞了，那么队列后请求也统统会被阻塞住。
2. HTTP/2多个请求服用一个TCP链接，一旦发生了丢包，就会阻塞住所有的HTTP请求。

这些其实都是在TCP传输层出了问题，所以HTTP3的时候就把HTTP下层的TCP更换为了UDP！UDP实现了一个不可靠传输，但是基于 UDP 的 QUIC 协议可以实现类似于 TCP 的可靠传输。

1. QUIC 有自己的一套机制可以保证传输的可靠性。当某一个流发生丢包的时候，只会阻塞这个流，不会影响到其他的流。
2. TLS3 升级到最新的1.3版本，头部压缩变为QPack。
3. HTTPS要建立连接的话，要花费6次交互，先是要建立三次握手，然后是TLS的三次握手。QUIC直接把之前的TCP和TLS/1.3的三次握手合并为了3次，减少了交互的次数。所以说QUIC是一个新的协议，它是一个伪TCP+TLS+HTTP/2的多路复用的协议。

websocket 的特点是什么？

websocket解决了一个HTTP的致命问题：请求只能由客户端发起的问题，即使HTTP2中新增了服务端推送，但是依然是在客户端发起请求之后才新增的。

HTTP协议依然不能向客户端发起推送信息。这种单向推送造成了不少的问题，就是如果说，服务器又连续的状态变化，客户端获知就非常麻烦，只能通过轮询的方法来获取。

其特点为：

• 建立在TCP之上，服务器的实现比较简单
• 与HTTP协议有着良好的兼容性。默认端口为80和443，并且握手阶段采用和HTTP一样的方式。
• 数据格式比较轻巧
• 可以发送文本，也可以放松二进制数据
• 没有同源策略限制
• 标识符号为ws和wss

HTTP/1.1 优化篇

主要有三个思路来优化HTTP1.1协议，比如有三种思路来实现。

• 尽量避免发送HTTP请求
• 在需要发送HTTP请求的时候，考虑如何减少请求次数
• 减少服务器的HTTP响应数据大小

下面就针对这三种思路具体看看有哪些优化的方法。

一、尽量避免发送请求

缓存技术，客户端会把第一次请求以及其响应的数据保存在本地磁盘中，其中可以将通过key:value的形式去保存缓存的数据。

1.1 强制缓存，协商缓存的关系与区别：

浏览器第一次打开一个网页获取资源后，根据返回的header信息来告诉如何缓存资源。浏览器第一次请求。

浏览器发送请求，无缓存的情况下，请求响应之后，根据响应的头部告诉我们如何进行缓存。1.expires 有效期至什么时候。2 cache-control  3.Etag    4.last-modified

在后续的请求中，在发送之前，会首先检查本地缓存，是否含有该请求的结果。如果有的话，就先去检查其头部是否命中强制缓存（Expires 、cache-control），若命中直接从缓存中获取资源信息，包括缓存header信息，本次请求就不会与服务器进行通信。如果没有命中的话，就会发送网络请求，但是在发送的时候需要带上其头部有关的字段（Etag/If-none-match  和  Last-modified/If-modified-since）由服务器来判断是否命中协商缓存，如果命中的话，就返回一个 304 not modified，那么客户端直接从缓存中获取数据，如果返回了新的数据，那么就在缓存中更新相关的信息。

强制缓存相关字段

Expires策略：

expires是web服务器中响应消息头字段，在响应http请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据，而无需再次请求。Expires设置失效时间，精确到时分秒。不过Expires 是HTTP 1.0的东西，现在默认浏览器均默认使用HTTP 1.1，所以它的作用基本忽略。

Cache-control策略：

cache-control与Expires的作用一致，都是指明当前资源的有效期，控制浏览器是否直接从浏览器缓存拿到数据还是从服务器端去获取数据。只不过Cache-control的选项更多一些，设置更加精细，如果同时设置的话，其优先级高于Expires。

Http协议头：Cache-control 其value可以为 private、 no-cache 、no-store、 no-transform、 must-revalidate 、proxy-revalidate 、max-age

各个消息中的指令含义如下：

1. Public指示响应可被任何缓存区缓存。
2. private指示对于单个用户的整个或者部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述用户的部分响应消息，此相应消息对于其他用户的请求无效。
3. no-cache代表不缓存过期的资源，缓存会向服务器进行有效处理确认之后处理资源，do-not-serve-from-cache-without-revalidation
4. no-store表示全面禁止缓存。
5. max-age指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。

如果cache-control与expires同时存在的话，cache-control的优先级高于expires

协商缓存的相关字段

Last-modified/If-Modified-since 和 Etag/If-None-Match 这两组搭档是成对出现的，也就说第一次请求中出现了Last-modified，那么接下来的请求中就会带上If-Modified-Since字段，如果第一次请求中带有Etag字段的话，那么接下来的请求中就会带有If-None-Match字段。

这两个字段都需要配合Cache-control来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求。

Last-modified/If-Modified-since

• last-modified：标示这个响应资源的最后修改时间。web服务器在响应请求的时候，告诉服务器的请求最终修改时间。
• If-modified-since：当资源过期了，发现响应头中具有last-modified声明，则再次发起请求的时候带上last-modified的时间，服务器收到请求后发现有if-modified-since则与被请求资源的最后修改时间进行对比（Last-Modified）,若最后修改时间较新（大），说明资源又被改过，则返回最新资源，HTTP 200 OK;若最后修改时间较旧（小），说明资源无新修改，响应HTTP 304 走缓存。

Etag/If-None-Match

• Etag：服务器响应时，告诉浏览器当前资源在服务器的唯一标识（生成规则由服务器决定）。Apache中，ETag的值，默认是对文件的索引节（INode），大小（Size）和最后修改时间（MTime）进行Hash后得到的。
• If-None-Match：当资源过期时，浏览器发现响应头里有Etag,则再次像服务器请求时带上请求头if-none-match(值是Etag的值)。服务器收到请求进行比对，决定返回200或304。

Etag和Last-modified两者为何并存？

看上去两者的功能很是相似都是为了实现协商缓存，Etag的出现主要目的是为了解决几个Last-modified不好解决的问题。

因为有的文件是周期性变化的，对于客户端来说意义不大，不需要客户端去检测到它的变化，所以采用大的版本控制的方式去检测就可以了。这时，利用Etag能够更加准确的控制缓存，因为Etag是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符。

Etag和last-modified同时存在的时候Etag的优先级更高

二、尽量减少HTTP请求次数

• 尽量减少重定向次数
• 合并请求
• 延迟发送请求

尽量减少重定向次数

减少重定向次数，服务器上的一个资源可能由于迁移、维护等原因从url转移到url2后，而客户端并不知道，客户端此时并不会不会简单粗暴的返回错误，而是通过302响应码和Location头部，告诉客户端该资源已经迁移到url2上了，于是客户端需要再次发送url2请求以获取到服务器资源。那么如果重定向的次数过多了，每次客户端都要多次发起HTTP请求，每一次的HTTP请求得经过网络，这无疑会降低网络性能。

301: Moved Permanently  资源永久重定向到另外一个URI

302: Found/Moved Temporarily 资源临时重定向到另外一个URI中

合并请求

可以将多个小文件的请求合并为一个大的请求，虽然传输的总资源是一定的，但是减少了请求的次数，这就意味着减少了重复发送HTTP头部。

延迟发送请求

图片懒加载等等。

三、减小HTTP响应的数据大小

减少HTTP响应数据的大小，从而提高网络传输的效率。对数据进行压缩。

HTTPS RSA 篇

TLS握手过程

HTTP由于是明文传输，也就是说客户端与服务端通信的信息都是肉眼可见的，随意使用一个抓包工具都是可以截获通信的内容。

窃听风险、篡改风险、冒充风险这三种风险。

SSL/TLS是通过，信息加密：HTTP交互的信息被加密之后，第三方就无法窃听。校验机制：校验信息传输过程中是否有被第三方篡改过，如果被篡改过，则会有警告提示。身份验证，证明真的是该网站。

通常经过【四个消息】就可以完成TLS握手，也就说需要两个RTT的时延，然后通信就是建立了TLS连接。事实上不同的密钥交换算法，TLS的握手过程可能会有不同，在该文章中，我们只介绍RSA密钥交换算法，来看看它的TLS握手过程。

TLS第一次握手：

客户端与服务端在进行完毕TCP/IP协议的三次握手之后，发送一个Hello Server消息，TLS版本信息，支持的密码套件等信息。注意此处包含三个信息，一：随机数，二：密码套件（加密算法等等），三，TLS版本信息

TLS第二次握手：

当服务端收到客户端的消息之后，就会确认TLS版本号是否支持，从密码套件列表中选择一个密码套件，以及生成随机数，之后还会返回证书，来证明自己的身份。值得注意的是，在此处，我们注意到一共发送了四个内容，分别为：TLS版本号，密码套件，随机数，还有证书。其中客户端验证证书是需要通过证书链来进行验证的。

TLS第三次握手：

客户端验证完证书之后，认为可信则继续往下走。接着，客户端就会生成一个新的随机数，用服务器的RSA公钥对该随机数进行加密，服务端收到随机数之后，用之前的三个随机数合并成为一个会话密钥。他是对称密钥，用于对后续的HTTP请求/响应的数据进行加密。客户端将所有的之前的数据做一个摘要，以供服务端验证。通知服务端该用新的对称加密方式。

TLS第四次握手：

同样的操作，服务端也通知客户端改变加密方式。

RSA算法的缺陷：

RSA密钥协商算法最大的问题再约不支持 前向保密。因为客户端传递随机数给服务端时候使用公钥进行加密，服务端收到之后会使用私钥进行解密。一旦服务端的私钥泄漏了，过去被第三方截获的所有TLS通信密文都会被破解。

于是就有了DH密钥协商算法，服务端和客户端个字会生成随机数，并一次作为私钥，然后根据公开的DH计算出各自的公钥，通过TLS握手双方的公钥和自己的私钥算出一个随机数。这个随机数的值就可以作为后续堆成加密算法的密钥。

客户端验证证书：

数字证书和CA机构：

在说校验数字证书是否可信的过程前，我们先来看看数字证书是什么，一个数字证书通常包含了：

• 公钥
• 持有者信息
• CA机构的信息
• 证书认证机构（CA）的信息
• CA对此份文件的数字签名以及使用的算法
• 证书有效期等

为了让服务端的公钥能被大家信任，服务端的证书都是由CA机构签名的，CA就是网络世界中的公安局，具有极高的可信度，所以由他来给各个公钥签名，信任的一方签发的证书，必定也是可信任的。之所以要签名，是因为签名的作用可以避免中间人在获取证书时对证书内容进行篡改。

数字证书的签发和验证流程：

CA签发证书的过程中，如上图左侧部分：首先CA会把持有者的公钥、用途、颁发者、有效期等等信息打成一个包，然后对这些信息进行Hash计算，得到一个Hash值。然后使用自己的私钥对该Hash值进行加密，生成一个Certificate Signature，也就是对证书做了一个签名。最后将其添加到证书中。

证书的验证过程。客户端会使用同样的Hash算法获取该证书的Hash值H1，然后浏览器和操作系统中集成了CA的公钥来解密Certificate Signature内容来得到一个Hash2，将二者进行比较。

如果相同则证明该证书是可信的，如果不相同，则证明是不可信的。

证书链：

事实上，证书的验证过程中还存在一个证书信任链的问题，因为我们向CA申请的证书一般来说都不是根证书签发的，二是由中间证书签发的。

服务端收到 baidu.com 的证书之后，发现这个证书的签发者不是根证书，就无法根据本地已有的证书中的公钥去验证 baidu.com 的证书是否可信。于是，客户端根据 baidu.com 证书中的签发者，找到该证书的签发机构是 "GlobalSign Organization Validation CA -SHA-256-G2"，然后向CA请求该中间证书。

请求到证书后发现 "GlobalSign Organization Validation CA -SHA-256-G2" 证书是由根CA 签发的，由于根CA没有再上级的机构，应用软件就会检查该证书是否已经加载在根证书清单中。如果有，用根证书公钥去验证"GlobalSign Organization Validation CA -SHA-256-G2"的证书，如果验证通过，那么就信任该中间公钥的是可信，中间证书可信之后，再根据中间证书的公钥去获取最底层的证书公钥。

HTTPS ECDHE 篇

HTTPS常用的密钥协商算法有两种分别为RSA和ECDHE。其中RSA是比较传统的密钥交换算法，不具备前向安全的性质，因此现在很少浏览器使用的。而ECDHE算法具有前向安全，所以被广泛使用。（我在上一篇文章中已经讲述了RSA的握手过程）

ECDHE算法是从DH算法演变而来的，所以我们先从DH算法说起。DH算法是非对称加密算法，因此他可以用于密钥交换，该算法的核心数学思想就是离散对数。

首先科普一下对数的基本知识（算了吧，下面的推倒和证明的东西都有在小林的图解网络中说明了，我就不讲了。。）

TCP 篇

什么是 TCP？

TCP是面向连接的、可靠的、基于字节流的传输层通信协议。这里面有三个关键词，分别为面向连接的、可靠的、基于字节流

面向连接的：指的是一对一的连接方式、不能像 UDP 那样可以一个主机同时向多个主机发送消息，也就是说一对多是无法实现的。

可靠的：无论网络状况出现了怎样的链路变化，TCP 都能保证一个报文一定能够到达接收端。

字节流：消息是没有边界的，所以无论我们消息有多大都可以进行传输。并且消息是有序的，当前一个消息没有收到的时候，即使他先收到后面的字节，那么也不能扔给应用层去处理，同时对于重复的报文会自动丢弃。

TCP 和 UDP 的区别

连接方面：

• TCP 是面向连接的传输层协议传输之前首先要建立连接。

• UDP 是不需要建立连接的，即可传输数据。

服务对象：

1. TCP是一对一的两点服务，即一条连接只有两个端点。
2. UDP支持一对一、一对多、多对多的交通通信。

可靠性：

• TCP是可靠交付数据的，数据可以无差别、不丢失、不重复、按需到达。

• UDP是尽最大可能交付，不保证可靠交付数据。

拥塞控制、流量控制：

• TCP有拥塞控制和流量控制机制，考证数据传输的安全性。

• UDP则没有，即使网络非常拥堵了，也不会影响UDP的发送速率。

首部开销：

• TCP手部长度较长，会有一定的开销，收不在没有使用【选项】字段有20个字节，如果使用了【选项】字段会更长。

• UDP首部只有8个字节，并且是固定不变的、开销较小。

传输方式：

• TCP是流式传输、没有边界，但保证顺序和可靠。

网络安全篇

XSS

xss（cross-site script）

• 反射型XSS：<非持久化> 攻击者事先制作好攻击链接, 需要欺骗用户自己去点击链接才能触发XSS代码（服务器中没有这样的页面和内容），一般容易出现在搜索页面。比如说将script脚本放置在请求参数中，然后页面中需要用到请求参数，就会直接执行该script标签。
• 存储型XSS：<持久化> 代码是存储在服务器中的，如在个人信息或发表文章等地方，加入代码，如果没有过滤或过滤不严，那么这些代码将储存到服务器中，每当有用户访问该页面的时候都会触发代码执行，这种XSS非常危险，容易造成蠕虫，大量盗窃cookie（虽然还有种DOM型XSS，但是也还是包括在存储型XSS内）。同上面的情况类似，入侵者将script标签写到了数据库中，然后每次发送请求之后，每次打开页面之后都会执行script标签。

防御：

• 标签转译：分为黑名单转译，将所有的<,>,/,都给转译为其他字符。">"为">" "<"为"<".白名单的话就是使用xss库。可以把输入的文字都给部分转译一下。

• 应为xss主要的目的是为了获取你的cookie，然后那么我只需要设置在cookie中设置，http-only，就可以了，因为xss是要先从document中获取到cookie，然后再发送出去，实际上呢我们将其设置为只有在发送http请求的时候才能带上cookie。

• CSP 内容安全策略（CSP）是一个额外的安全层，用于检测并削弱某些特定类型的攻击，包括跨站脚本和数据注入攻击等。无论是数据盗取、网站内容污染还是散发恶意软件，这些都是主要的手段。我们可以通过CSP来尽量减少XSS攻击，CSP本质上也是建立白名单，规定了浏览器只能够执行特定来源的代码。通常我们可以通过HTTP Header中的Content-Security-Policy来开启CSP

• 只允许加载本站资源

  Content-Security-Policy: default-src 'self'
  

• 只允许加载HTTPS协议图片

  Content-Security-Policy: img-src https://*
  

• 允许加载任何来源

  Content-Security-Policy:child-src 'none'
  

CSRF

CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。

它主要就是利用你的浏览器保存了你的登陆信息，通过另外一个网址，在该网址中发送一个跨站请求，携带者你的身份认证，这样就可以成功的对你的账号进行操作了。

防御方式：

1. reference check，但是很多时候，reference是可以修改的。
2. cookie hash的方法，在表单中植入md5密码，虽然md5的安全性不太行，但是还是应对此问题已经够用了，因为每个表单中的随机数都是不一样的。
3. 手机验证码
4. sameSite：可以对Cookie进行设置，Samesite属性。该属性设置Cookie不随着跨域请求发送，该属性可以很大程度上减少CSRF的攻击。

点击劫持

这是一种视觉欺骗的方式，让你以为在点击一个正确的按钮的时候发送了一个别的请求。将该网站放置在一个iframe中，然后造成视觉的误差。

防御：

X-Frame-Options：deny

请求劫持

DNS劫持（DNS解析被劫持）

HTTP劫持（使用HTTPS）

DDOS（distributed denial of service）

syn flood http flood

完！