xinyin025/learn.lianglianglee.com
1
0
Fork 0
mirror of https://github.com/zhwei820/learn.lianglianglee.com.git synced 2025-09-17 08:46:40 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity
master
learn.lianglianglee.com/专栏/透视HTTP协议/21 良心中间商：HTTP的代理服务.md.html
周伟 d9c5ffd627 u
2022-05-11 19:04:14 +08:00

703 lines
27 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<!-- saved from url=(0046)https://kaiiiz.github.io/hexo-theme-book-demo/ -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0, user-scalable=no">
<link rel="icon" href="/static/favicon.png">
<title>21 良心中间商：HTTP的代理服务.md.html</title>
<!-- Spectre.css framework -->
<link rel="stylesheet" href="/static/index.css">
<!-- theme css & js -->
<meta name="generator" content="Hexo 4.2.0">
</head>
<body>
<div class="book-container">
<div class="book-sidebar">
<div class="book-brand">
<a href="/">
<img src="/static/favicon.png">
<span>技术文章摘抄</span>
</a>
</div>
<div class="book-menu uncollapsible">
<ul class="uncollapsible">
<li><a href="/" class="current-tab">首页</a></li>
</ul>
<ul class="uncollapsible">
<li><a href="../">上一级</a></li>
</ul>
<ul class="uncollapsible">
<li>
<a href="/专栏/透视HTTP协议/00 开篇词｜To Be a HTTP Hero.md.html">00 开篇词｜To Be a HTTP Hero.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/01 时势与英雄：HTTP的前世今生.md.html">01 时势与英雄：HTTP的前世今生.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/02 HTTP是什么？HTTP又不是什么？.md.html">02 HTTP是什么？HTTP又不是什么？.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/03 HTTP世界全览（上）：与HTTP相关的各种概念.md.html">03 HTTP世界全览（上）：与HTTP相关的各种概念.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/04 HTTP世界全览（下）：与HTTP相关的各种协议.md.html">04 HTTP世界全览（下）：与HTTP相关的各种协议.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/05 常说的“四层”和“七层”到底是什么？“五层”“六层”哪去了？.md.html">05 常说的“四层”和“七层”到底是什么？“五层”“六层”哪去了？.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/06 域名里有哪些门道？.md.html">06 域名里有哪些门道？.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/07 自己动手，搭建HTTP实验环境.md.html">07 自己动手，搭建HTTP实验环境.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/08 键入网址再按下回车，后面究竟发生了什么？.md.html">08 键入网址再按下回车，后面究竟发生了什么？.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/09 HTTP报文是什么样子的？.md.html">09 HTTP报文是什么样子的？.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/10 应该如何理解请求方法？.md.html">10 应该如何理解请求方法？.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/11 你能写出正确的网址吗？.md.html">11 你能写出正确的网址吗？.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/12 响应状态码该怎么用？.md.html">12 响应状态码该怎么用？.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/13 HTTP有哪些特点？.md.html">13 HTTP有哪些特点？.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/14 HTTP有哪些优点？又有哪些缺点？.md.html">14 HTTP有哪些优点？又有哪些缺点？.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/15 海纳百川：HTTP的实体数据.md.html">15 海纳百川：HTTP的实体数据.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/16 把大象装进冰箱：HTTP传输大文件的方法.md.html">16 把大象装进冰箱：HTTP传输大文件的方法.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/17 排队也要讲效率：HTTP的连接管理.md.html">17 排队也要讲效率：HTTP的连接管理.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/18 四通八达：HTTP的重定向和跳转.md.html">18 四通八达：HTTP的重定向和跳转.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/19 让我知道你是谁：HTTP的Cookie机制.md.html">19 让我知道你是谁：HTTP的Cookie机制.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/20 生鲜速递：HTTP的缓存控制.md.html">20 生鲜速递：HTTP的缓存控制.md.html</a>
</li>
<li>
<a class="current-tab" href="/专栏/透视HTTP协议/21 良心中间商：HTTP的代理服务.md.html">21 良心中间商：HTTP的代理服务.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/22 冷链周转：HTTP的缓存代理.md.html">22 冷链周转：HTTP的缓存代理.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/23 HTTPS是什么？SSLTLS又是什么？.md.html">23 HTTPS是什么？SSLTLS又是什么？.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/24 固若金汤的根本（上）：对称加密与非对称加密.md.html">24 固若金汤的根本（上）：对称加密与非对称加密.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/25 固若金汤的根本（下）：数字签名与证书.md.html">25 固若金汤的根本（下）：数字签名与证书.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/26 信任始于握手：TLS1.2连接过程解析.md.html">26 信任始于握手：TLS1.2连接过程解析.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/27 更好更快的握手：TLS1.3特性解析.md.html">27 更好更快的握手：TLS1.3特性解析.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/28 连接太慢该怎么办：HTTPS的优化.md.html">28 连接太慢该怎么办：HTTPS的优化.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/29 我应该迁移到HTTPS吗？.md.html">29 我应该迁移到HTTPS吗？.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/30 时代之风（上）：HTTP2特性概览.md.html">30 时代之风（上）：HTTP2特性概览.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/31 时代之风（下）：HTTP2内核剖析.md.html">31 时代之风（下）：HTTP2内核剖析.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/32 未来之路：HTTP3展望.md.html">32 未来之路：HTTP3展望.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/33 我应该迁移到HTTP2吗？.md.html">33 我应该迁移到HTTP2吗？.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/34 Nginx：高性能的Web服务器.md.html">34 Nginx：高性能的Web服务器.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/35 OpenResty：更灵活的Web服务器.md.html">35 OpenResty：更灵活的Web服务器.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/36 WAF：保护我们的网络服务.md.html">36 WAF：保护我们的网络服务.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/37 CDN：加速我们的网络服务.md.html">37 CDN：加速我们的网络服务.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/38 WebSocket：沙盒里的TCP.md.html">38 WebSocket：沙盒里的TCP.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/39 HTTP性能优化面面观（上）.md.html">39 HTTP性能优化面面观（上）.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/40 HTTP性能优化面面观（下）.md.html">40 HTTP性能优化面面观（下）.md.html</a>
</li>
<li>
<a href="/专栏/透视HTTP协议/结束语 做兴趣使然的Hero.md.html">结束语 做兴趣使然的Hero.md.html</a>
</li>
</ul>
</div>
</div>
<div class="sidebar-toggle" onclick="sidebar_toggle()" onmouseover="add_inner()" onmouseleave="remove_inner()">
<div class="sidebar-toggle-inner"></div>
</div>
<script>
function add_inner() {
let inner = document.querySelector('.sidebar-toggle-inner')
inner.classList.add('show')
}
function remove_inner() {
let inner = document.querySelector('.sidebar-toggle-inner')
inner.classList.remove('show')
}
function sidebar_toggle() {
let sidebar_toggle = document.querySelector('.sidebar-toggle')
let sidebar = document.querySelector('.book-sidebar')
let content = document.querySelector('.off-canvas-content')
if (sidebar_toggle.classList.contains('extend')) { // show
sidebar_toggle.classList.remove('extend')
sidebar.classList.remove('hide')
content.classList.remove('extend')
} else { // hide
sidebar_toggle.classList.add('extend')
sidebar.classList.add('hide')
content.classList.add('extend')
}
}
function open_sidebar() {
let sidebar = document.querySelector('.book-sidebar')
let overlay = document.querySelector('.off-canvas-overlay')
sidebar.classList.add('show')
overlay.classList.add('show')
}
function hide_canvas() {
let sidebar = document.querySelector('.book-sidebar')
let overlay = document.querySelector('.off-canvas-overlay')
sidebar.classList.remove('show')
overlay.classList.remove('show')
}
</script>
<div class="off-canvas-content">
<div class="columns">
<div class="column col-12 col-lg-12">
<div class="book-navbar">
<!-- For Responsive Layout -->
<header class="navbar">
<section class="navbar-section">
<a onclick="open_sidebar()">
<i class="icon icon-menu"></i>
</a>
</section>
</header>
</div>
<div class="book-content" style="max-width: 960px; margin: 0 auto;
overflow-x: auto;
overflow-y: hidden;">
<div class="book-post">
<p id="tip" align="center"></p>
<div><h1>21 良心中间商：HTTP的代理服务</h1>
<p>在前面讲 HTTP 协议的时候，我们严格遵循了 HTTP 的“请求 - 应答”模型，协议中只有两个互相通信的角色，分别是“请求方”浏览器（客户端）和“应答方”服务器。</p>
<p>今天，我们要在这个模型里引入一个新的角色，那就是HTTP 代理。</p>
<p>引入 HTTP 代理后，原来简单的双方通信就变复杂了一些，加入了一个或者多个中间人，但整体上来看，还是一个有顺序关系的链条，而且链条里相邻的两个角色仍然是简单的一对一通信，不会出现越级的情况。</p>
<p><img src="assets/28237ef93ce0ddca076d2dc19c16fdf9.png" alt="img" /></p>
<p>链条的起点还是客户端（也就是浏览器），中间的角色被称为代理服务器（proxy server），链条的终点被称为源服务器（origin server），意思是数据的“源头”“起源”。</p>
<h2>代理服务</h2>
<p>“代理”这个词听起来好像很神秘，有点“高大上”的感觉。</p>
<p>但其实 HTTP 协议里对它并没有什么特别的描述，它就是在客户端和服务器原本的通信链路中插入的一个中间环节，也是一台服务器，但提供的是“代理服务”。</p>
<p>所谓的“代理服务”就是指服务本身不生产内容，而是处于中间位置转发上下游的请求和响应，具有双重身份：面向下游的用户时，表现为服务器，代表源服务器响应客户端的请求；而面向上游的源服务器时，又表现为客户端，代表客户端发送请求。</p>
<p>还是拿上一讲的“生鲜超市”来打个比方。</p>
<p>之前你都是从超市里买东西，现在楼底下新开了一家 24 小时便利店，由超市直接供货，于是你就可以在便利店里买到原本必须去超市才能买到的商品。</p>
<p>这样超市就不直接和你打交道了，成了“源服务器”，便利店就成了超市的“代理服务器”。</p>
<p>在[第 4 讲]中，我曾经说过，代理有很多的种类，例如匿名代理、透明代理、正向代理和反向代理。</p>
<p>今天我主要讲的是实际工作中最常见的反向代理，它在传输链路中更靠近源服务器，为源服务器提供代理服务。</p>
<h2>代理的作用</h2>
<p>为什么要有代理呢？换句话说，代理能干什么、带来什么好处呢？</p>
<p>你也许听过这样一句至理名言：“计算机科学领域里的任何问题，都可以通过引入一个中间层来解决”（在这句话后面还可以再加上一句“如果一个中间层解决不了问题，那就再加一个中间层”）。TCP/IP 协议栈是这样，而代理也是这样。</p>
<p>由于代理处在 HTTP 通信过程的中间位置，相应地就对上屏蔽了真实客户端，对下屏蔽了真实服务器，简单的说就是“<strong>欺上瞒下</strong>”。在这个中间层的“小天地”里就可以做很多的事情，为 HTTP 协议增加更多的灵活性，实现客户端和服务器的“双赢”。</p>
<p>代理最基本的一个功能是<strong>负载均衡</strong>。因为在面向客户端时屏蔽了源服务器，客户端看到的只是代理服务器，源服务器究竟有多少台、是哪些 IP 地址都不知道。于是代理服务器就可以掌握请求分发的“大权”，决定由后面的哪台服务器来响应请求。</p>
<p><img src="assets/8c1fe47a7ca4b52702a6a14956033f7c.png" alt="img" /></p>
<p>代理中常用的负载均衡算法你应该也有所耳闻吧，比如轮询、一致性哈希等等，这些算法的目标都是尽量把外部的流量合理地分散到多台源服务器，提高系统的整体资源利用率和性能。</p>
<p>在负载均衡的同时，代理服务还可以执行更多的功能，比如：</p>
<ul>
<li><strong>健康检查</strong>：使用“心跳”等机制监控后端服务器，发现有故障就及时“踢出”集群，保证服务高可用；</li>
<li><strong>安全防护</strong>：保护被代理的后端服务器，限制 IP 地址或流量，抵御网络攻击和过载；</li>
<li><strong>加密卸载</strong>：对外网使用 SSL/TLS 加密通信认证，而在安全的内网不加密，消除加解密成本；</li>
<li><strong>数据过滤</strong>：拦截上下行的数据，任意指定策略修改请求或者响应；</li>
<li><strong>内容缓存</strong>：暂存、复用服务器响应，这个与[第 20 讲]密切相关，我们稍后再说。</li>
</ul>
<p>接着拿刚才的便利店来举例说明。</p>
<p>因为便利店和超市之间是专车配送，所以有了便利店，以后你买东西就更省事了，打电话给便利店让它去帮你取货，不用关心超市是否停业休息、是否人满为患，而且总能买到最新鲜的。</p>
<p>便利店同时也方便了超市，不用额外加大店面就可以增加客源和销量，货物集中装卸也节省了物流成本，由于便利店直接面对客户，所以也可以把恶意骚扰电话挡在外面。</p>
<h2>代理相关头字段</h2>
<p>代理的好处很多，但因为它“欺上瞒下”的特点，隐藏了真实客户端和服务器，如果双方想要获得这些“丢失”的原始信息，该怎么办呢？</p>
<p>首先，代理服务器需要用字段“<strong>Via</strong>”标明代理的身份。</p>
<p>Via 是一个通用字段，请求头或响应头里都可以出现。每当报文经过一个代理节点，代理服务器就会把自身的信息追加到字段的末尾，就像是经手人盖了一个章。</p>
<p>如果通信链路中有很多中间代理，就会在 Via 里形成一个链表，这样就可以知道报文究竟走过了多少个环节才到达了目的地。</p>
<p>例如下图中有两个代理：proxy1 和 proxy2，客户端发送请求会经过这两个代理，依次添加就是“Via: proxy1, proxy2”，等到服务器返回响应报文的时候就要反过来走，头字段就是“Via: proxy2, proxy1”。</p>
<p><img src="assets/52a3bd760584972011f6be1a5258e2d7.png" alt="img" /></p>
<p>Via 字段只解决了客户端和源服务器判断是否存在代理的问题，还不能知道对方的真实信息。</p>
<p>但服务器的 IP 地址应该是保密的，关系到企业的内网安全，所以一般不会让客户端知道。不过反过来，通常服务器需要知道客户端的真实 IP 地址，方便做访问控制、用户画像、统计分析。</p>
<p>可惜的是 HTTP 标准里并没有为此定义头字段，但已经出现了很多“事实上的标准”，最常用的两个头字段是“<strong>X-Forwarded-For</strong>”和“<strong>X-Real-IP</strong>”。</p>
<p>“X-Forwarded-For”的字面意思是“为谁而转发”，形式上和“Via”差不多，也是每经过一个代理节点就会在字段里追加一个信息。但“Via”追加的是代理主机名（或者域名），而“X-Forwarded-For”追加的是请求方的 IP 地址。所以，在字段里最左边的 IP 地址就客户端的地址。</p>
<p>“X-Real-IP”是另一种获取客户端真实 IP 的手段，它的作用很简单，就是记录客户端 IP 地址，没有中间的代理信息，相当于是“X-Forwarded-For”的简化版。如果客户端和源服务器之间只有一个代理，那么这两个字段的值就是相同的。</p>
<p>我们的实验环境实现了一个反向代理，访问“<a href="http://www.chrono.com/21-1">http://www.chrono.com/21-1</a>”，它会转而访问“<a href="http://origin.io/">http://origin.io</a>”。这里的“origin.io”就是源站，它会在响应报文里输出“Via”“X-Forwarded-For”等代理头字段信息：</p>
<p><img src="assets/c5aa6d5f82e8cc1a35772293972446e7.png" alt="img" /></p>
<p>单从浏览器的页面上很难看出代理做了哪些工作，因为代理的转发都在后台不可见，所以我把这个过程用 Wireshark 抓了一个包：</p>
<p><img src="assets/5a247e9e5bf66f5ac3316fddf4e2b254.png" alt="img" /></p>
<p>从抓包里就可以清晰地看出代理与客户端、源服务器的通信过程：</p>
<ol>
<li>客户端 55061 先用三次握手连接到代理的 80 端口，然后发送 GET 请求；</li>
<li>代理不直接生产内容，所以就代表客户端，用 55063 端口连接到源服务器，也是三次握手；</li>
<li>代理成功连接源服务器后，发出了一个 HTTP/1.0 的 GET 请求；</li>
<li>因为 HTTP/1.0 默认是短连接，所以源服务器发送响应报文后立即用四次挥手关闭连接；</li>
<li>代理拿到响应报文后再发回给客户端，完成了一次代理服务。</li>
</ol>
<p>在这个实验中，你可以看到除了“X-Forwarded-For”和“X-Real-IP”，还出现了两个字段：“X-Forwarded-Host”和“X-Forwarded-Proto”，它们的作用与“X-Real-IP”类似，只记录客户端的信息，分别是客户端请求的原始域名和原始协议名。</p>
<h2>代理协议</h2>
<p>有了“X-Forwarded-For”等头字段，源服务器就可以拿到准确的客户端信息了。但对于代理服务器来说它并不是一个最佳的解决方案。</p>
<p>因为通过“X-Forwarded-For”操作代理信息必须要解析 HTTP 报文头，这对于代理来说成本比较高，原本只需要简单地转发消息就好，而现在却必须要费力解析数据再修改数据，会降低代理的转发性能。</p>
<p>另一个问题是“X-Forwarded-For”等头必须要修改原始报文，而有些情况下是不允许甚至不可能的（比如使用 HTTPS 通信被加密）。</p>
<p>所以就出现了一个专门的“代理协议”（The PROXY protocol），它由知名的代理软件 HAProxy 所定义，也是一个“事实标准”，被广泛采用（注意并不是 RFC）。</p>
<p>“代理协议”有 v1 和 v2 两个版本，v1 和 HTTP 差不多，也是明文，而 v2 是二进制格式。今天只介绍比较好理解的 v1，它在 HTTP 报文前增加了一行 ASCII 码文本，相当于又多了一个头。</p>
<p>这一行文本其实非常简单，开头必须是“PROXY”五个大写字母，然后是“TCP4”或者“TCP6”，表示客户端的 IP 地址类型，再后面是请求方地址、应答方地址、请求方端口号、应答方端口号，最后用一个回车换行（\r\n）结束。</p>
<p>例如下面的这个例子，在 GET 请求行前多出了 PROXY 信息行，客户端的真实 IP 地址是“1.1.1.1”，端口号是 55555。</p>
<pre><code>PROXY TCP4 1.1.1.1 2.2.2.2 55555 80\r\n
GET / HTTP/1.1\r\n
Host: www.xxx.com\r\n
\r\n
</code></pre>
<p>服务器看到这样的报文，只要解析第一行就可以拿到客户端地址，不需要再去理会后面的 HTTP 数据，省了很多事情。</p>
<p>不过代理协议并不支持“X-Forwarded-For”的链式地址形式，所以拿到客户端地址后再如何处理就需要代理服务器与后端自行约定。</p>
<h2>小结</h2>
<ol>
<li>HTTP 代理就是客户端和服务器通信链路中的一个中间环节，为两端提供“代理服务”；</li>
<li>代理处于中间层，为 HTTP 处理增加了更多的灵活性，可以实现负载均衡、安全防护、数据过滤等功能；</li>
<li>代理服务器需要使用字段“Via”标记自己的身份，多个代理会形成一个列表；</li>
<li>如果想要知道客户端的真实 IP 地址，可以使用字段“X-Forwarded-For”和“X-Real-IP”；</li>
<li>专门的“代理协议”可以在不改动原始报文的情况下传递客户端的真实 IP。</li>
</ol>
<h2>课下作业</h2>
<ol>
<li>你觉得代理有什么缺点？实际应用时如何避免？</li>
<li>你知道多少反向代理中使用的负载均衡算法？它们有什么优缺点？</li>
</ol>
<p>欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。</p>
<p><img src="assets/a8122180bd01e05613d75d34962da79f.png" alt="unpreview" /></p>
</div>
</div>
<div>
<div style="float: left">
<a href="/专栏/透视HTTP协议/20 生鲜速递：HTTP的缓存控制.md.html">上一页</a>
</div>
<div style="float: right">
<a href="/专栏/透视HTTP协议/22 冷链周转：HTTP的缓存代理.md.html">下一页</a>
</div>
</div>
</div>
</div>
</div>
</div>
<a class="off-canvas-overlay" onclick="hide_canvas()"></a>
</div>
<script defer src="https://static.cloudflareinsights.com/beacon.min.js/v652eace1692a40cfa3763df669d7439c1639079717194" integrity="sha512-Gi7xpJR8tSkrpF7aordPZQlW2DLtzUlZcumS8dMQjwDHEnw9I7ZLyiOj/6tZStRBGtGgN6ceN6cMH8z7etPGlw==" data-cf-beacon='{"rayId":"70997d0dae423cfa","version":"2021.12.0","r":1,"token":"1f5d475227ce4f0089a7cff1ab17c0f5","si":100}' crossorigin="anonymous"></script>
</body>
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-NPSEEVD756"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag() {
dataLayer.push(arguments);
}
gtag('js', new Date());
gtag('config', 'G-NPSEEVD756');
var path = window.location.pathname
var cookie = getCookie("lastPath");
console.log(path)
if (path.replace("/", "") === "") {
if (cookie.replace("/", "") !== "") {
console.log(cookie)
document.getElementById("tip").innerHTML = "<a href='" + cookie + "'>跳转到上次进度</a>"
}
} else {
setCookie("lastPath", path)
}
function setCookie(cname, cvalue) {
var d = new Date();
d.setTime(d.getTime() + (180 * 24 * 60 * 60 * 1000));
var expires = "expires=" + d.toGMTString();
document.cookie = cname + "=" + cvalue + "; " + expires + ";path = /";
}
function getCookie(cname) {
var name = cname + "=";
var ca = document.cookie.split(';');
for (var i = 0; i < ca.length; i++) {
var c = ca[i].trim();
if (c.indexOf(name) === 0) return c.substring(name.length, c.length);
}
return "";
}
</script>
</html>
Reference in New Issue View Git Blame Copy Permalink