13. 如何理解 HTTP 代理？

相应的，对于 CSRF 攻击的预防，也有SameSite属性。

SameSite可以设置为三个值，Strict、Lax和None。

1. 在Strict模式下，浏览器完全禁止第三方请求携带Cookie。比如请求sanyuan.com网站只能在

sanyuan.com域名当中请求才能携带 Cookie，在其他网站请求都不能。

1. 在Lax模式，就宽松一点了，但是只能在 get 方法提交表单况或者a 标签发送 get 请求的情况下可

以携带 Cookie，其他情况均不能。

1. 在None模式下，也就是默认模式，请求会自动携带上 Cookie。

Cookie 的缺点

1）容量缺陷。Cookie 的体积上限只有4KB，只能用来存储少量的信息。

2）性能缺陷。Cookie 紧跟域名，不管域名下面的某一个地址需不需要这个 Cookie，请求都会携带上完整的 Cookie，这样随着请求数的增多，其实会造成巨大的性能浪费的，因为请求携带了很多不必要的

内容。但可以通过Domain和Path指定作用域来解决。

3）安全缺陷。由于 Cookie 以纯文本的形式在浏览器和服务器中传递，很容易被非法用户截获，然后进行一系列的篡改，在 Cookie 的有效期内重新发送给服务器，这是相当危险的。另外，在HttpOnly为

false 的情况下，Cookie 信息能直接通过 JS 脚本来读取。

1. 如何理解 HTTP 代理？

我们知道在 HTTP 是基于请求-响应模型的协议，一般由客户端发请求，服务器来进行响应。

当然，也有特殊情况，就是代理服务器的情况。引入代理之后，作为代理的服务器相当于一个中间人的角色，对于客户端而言，表现为服务器进行响应；而对于源服务器，表现为客户端发起请求，具有双重

身份。

那代理服务器到底是用来做什么的呢？

功能

1）负载均衡。客户端的请求只会先到达代理服务器，后面到底有多少源服务器，IP 都是多少，客户端是不知道的。因此，这个代理服务器可以拿到这个请求之后，可以通过特定的算法分发给不同的源服务

器，让各台源服务器的负载尽量平均。当然，这样的算法有很多，包括随机算法、轮询、一致性hash、 LRU (最近最少使用)等等，不过这些算法并不是本文的重点，大家有兴趣自己可以研究一下。

2）保障安全。利用心跳机制监控后台的服务器，一旦发现故障机就将其踢出集群。并且对于上下行的数据进行过滤，对非法 IP 限流，这些都是代理服务器的工作。

3）缓存代理。将内容缓存到代理服务器，使得客户端可以直接从代理服务器获得而不用到源服务器那里。下一节详细拆解。

代理服务器需要标明自己的身份，在 HTTP 传输中留下自己的痕迹，怎么办呢？

通过Via字段来记录。举个例子，现在中间有两台代理服务器，在客户端发送请求后会经历这样一个过程:

客户端 -> 代理1 -> 代理2 -> 源服务器

在源服务器收到请求后，会在请求头拿到这个字段:

Via: proxy_server1, proxy_server2

而源服务器响应时，最终在客户端会拿到这样的响应头:

Via: proxy_server2, proxy_server1

可以看到，Via中代理的顺序即为在 HTTP 传输中报文传达的顺序。

X-Forwarded-For

字面意思就是为谁转发, 它记录的是请求方的IP地址(注意，和Via区分开，X-Forwarded-For记录的是请求方这一个IP)。

X-Real-IP

是一种获取用户真实 IP 的字段，不管中间经过多少代理，这个字段始终记录最初的客户端的IP。

相应的，还有X-Forwarded-Host和X-Forwarded-Proto，分别记录客户端(注意哦，不包括代理)的域名和协议名。

X-Forwarded-For产生的问题

前面可以看到，X-Forwarded-For这个字段记录的是请求方的 IP，这意味着每经过一个不同的代理，这个字段的名字都要变，从客户端到代理1，这个字段是客户端的 IP，从代理1到代理2，这个字段就变

为了代理1的 IP。

但是这会产生两个问题:

1）意味着代理必须解析 HTTP 请求头，然后修改，比直接转发数据性能下降。

2）在 HTTPS 通信加密的过程中，原始报文是不允许修改的。

由此产生了代理协议，一般使用明文版本，只需要在 HTTP 请求行上面加上这样格式的文本即可:

// PROXY + TCP4/TCP6 + 请求方地址 + 接收方地址 + 请求端口 + 接收端口 PROXY TCP4 0.0.0.1 0.0.0.2 1111 2222

GET / HTTP/1.1