OCSP导致https访问特别容易超时

之前网站接口在“微信iOS里的浏览器中”首次打开特别容易超时,然后是各种优化,把能做的优化做完以后,发现首屏打开速度仍然是时好时坏。百思不得其解。

使用微信的开发者工具,网页开发工具用的是chrome,也发现不了问题。顺便吐槽一下,微信开发者工具居然不支持远程调试。

实在没办法,想起来用Charles抓包看看到底怎么回事。

之后看到很多:ocsp.int-x3.letsencrypt.org/75.126.2.43 请求超时

原来,微信内嵌的safari会在线检查 Let’s Encrypt 的证书状态(OCSP),这也是为什么这个现象只发生在微信内的网页。而这个在线服务并不是特别稳定,之前有些时候优化后发现速度快了一点,可能碰巧那段时间OCSP服务比较稳定,而不是因为优化的原因(捂脸)。

之后参考这三篇文章:

https://blog.csdn.net/CUG_ZG/article/details/105508885

https://www.upyun.com/tech/article/338/%E4%B8%8D%E6%98%AF%20HTTPS%20%E6%8B%96%E6%85%A2%E7%BD%91%E7%AB%99%E9%80%9F%E5%BA%A6%EF%BC%8C%E8%80%8C%E6%98%AF%E4%BC%98%E5%8C%96%E5%81%9A%E7%9A%84%E4%B8%8D%E5%A4%9F%E4%BC%98%E7%A7%80.html

https://www.cackui.com/a/zhishi/jianzhan/5165.html

 

开启OCSP(Online Certificate Status Protocal), 在nginx的server{}配置中增加以下配置

  • ssl_stapling on;
  • ssl_stapling_verify on;
  • ssl_trusted_certificate /etc/letsencrypt/live/xxx.xxx.com/fullchain.pem;
  • resolver 8.8.8.8 8.8.4.4 1.1.1.1 valid=60s;
  • resolver_timeout 2s;
  • 然后重启nginx,在ssllab.com验证,OCSP stapling YES

即可。

 

关于微信会员卡和卡包

微信会员卡,这里包括全部卡券、卡包功能。
其实会员卡的本质是很好的,给会员提供不同的权益然后能够将用户持续的“粘住”,也是大多数会员系统的基本目的。
 
但微信毕竟是通信产品的基因,只是由于拥有巨大的流量就开始什么都搞了。
 
本质上微信通过通信(聊天)来切入社交(朋友圈)其实是合乎逻辑的,但是微信的胃口显然是越来越大,切入生活类场景。。。
而且会员卡的本质就和微信的“用完即走”的理念是完全冲突的。
 
好吧,扯的远了。
 
整个微信卡券由以下几部分组成:
  1. 入口:卡包、附近的卡券、以及一些附加的入口如支付成功
  2. 使用场景:主要是支付场景(核销卡券)
 
对商家来说,在小程序之前的时代,可以通过卡券功能直接获取用户的手机号码。但是后来为了推小程序,微信给小程序提供了这个特殊的通道。
同时,商家接入微信“生活圈”的根本目的很单纯(也可以说很不单纯),就是为了获取流量。流量怎么来?微信在这方面倒是始终非常“克制”。
会员卡这种不痛不痒的入口,本身隐藏的深不说,在现实生活场景中一点都不方便。至于附近的卡券,刚刚开始时候还行,最终还是由于太不方便而弃用了。
这么看来,微信的“克制”更多的是对别人,对自己其实并不克制。
 
其实还是本质问题:微信并没有生活圈基因,否则就不是微信了。就算通过人为方法(一定可以)将微信变成生活方式入口,恐怕只会让自己不伦不类。
 
实际操作过程中,商家的会员系统并不能很好地和微信融合,融合也完全是奔着流量和获客来的。促成交易即可,将用户沉淀在自己的系统里才是最终也是最安全的做法。
类似华住,最终还是要通过小程序、公众号、卡券将用户导入到自己的会员体系里,本身就是比较正确的姿势。
至于把自己的整个会员体系架构到微信上的,要么就是小微商家,本质上用excel就可以进行会员管理。中等规模的商家,如果会员系统运营需要有专人来负责,也可以选择很多现成的产品,有赞什么的都可以很好的满足。
 
所以,微信的资源主要是流量,现在大家的主要重心(包括微信自己)也在发掘新的流量红利,因为目前的流量红利已经用完了。(是的,用没用完这件事不是由微信自己决定的)
对小程序的用力过猛也是这个意思。但是微信已经变成了一个大公司了,动起来太多的掣肘。除非拆分。
 

将包括会员卡、商家、城市服务、小程序这些功能拆分到一个独立的平台,甚至为了解决基因问题应该用一个独立的公司来运营。但是,在大公司里,谁敢呢? 

关于Vue动态更新版本的一些问题记录

最近开始用Vue升级了之前的一些项目(没办法,开始写前端了。相比较后端逻辑那种冥思苦想,前端写起来更加“视觉系”)

很自然地,觉得前端也应该和之前写服务器端页面一样,只要文件更新了,用户端自然就更新了,然后很自然地,踩到了坑里。

一开始也是通过学习别人的代码,在router的beforeEach钩子函数里,通过检查版本文件来决定是否应该重新加载页面。

由于有些js文件在bundle中被按需加载。当更新代码时(我用的方式就是简单粗暴地替换dist中的所有文件到服务器),由于某些之前没有加载到的文件已经不存在了,会报:’Loading chunk ” + xx + ” failed’。

但是之前的疏忽,没有在检查版本文件时增加随机数来避免文件被缓存,结果用户端的缓存中,依然是旧版本的代码、以及旧版本的“版本检查代码”。所以单纯的在新代码中增加随机数,并不能确保用户端能够获取到新的版本文件。

这个时候只能通过在nginx中,增加对版本文件单独的禁用缓存配置:

location ~ /version\.json {
    expires 0;
    add_header Cache-Control 'no-store, no-cache, must-revalidate, proxy-revalidate';
}

这样可以确保之前的用户浏览器再次获取版本文件时拿到的是最新的,但是还是怀疑某些浏览器不会做这个检查,这种情况只能寄希望于缓存过期了。

同时,给index.html也加上禁用缓存的配置。确保index.html每次都获取最新的。

不过,这种配置貌似对PWA有影响,因为PWA的一个最重要的特性就是缓存所有的逻辑,改天研究一下。

好看数学 – Pretty Math

作为数学的一个分支,开创性地扩大了传统数学的应用领域。并且将数学和我们的生活连接的更加紧密。

但由于主要受众的原因,好看数学仅包含传统数学教育中初等教育的部分。

颜色,虽然称为“好看”数学,但实际上主要的颜色使用为2个颜色:红色 – 代表好看的部分,灰色(或者透明色) –  代表不好看的部分。

几何,主要以一元一次线性为主,并且斜率为正(但不能过大,因为会看起来太假)

其重要分支有:好看几何、好看统计、好看概率等

应用举例:

1. 我们今年的营业额增长是11%,比去年增长10%。成本数据暂未统计。

2. 我们今年的成本控制得力,仅比去年增加8%,营业额数据暂未统计。

人性虚无感

有时候在想,我们有时候观察到的那种”冷漠“ — 这种”冷漠“有时恰恰表现的是忙忙碌碌 — 其实是一种无意识的人性虚无感。

多少年的奴隶、贱民,再加上集体主义的浸泡,最终发现自己那么渺小那么无助,早就了这种”冷漠“。

而另一个极端,稍有权柄,就无法驾驭自己。也许就是虚无感太强太长时间获得的短暂释放吧。

“抛开剂量谈毒性就是耍流氓”这句话的理解

今天想起了这句话,其实因为想要比较两个php框架,后来发现比较来比较去,还是要根据实际的场景来决定。

随手google一下这句话,发现有一篇批判这句话的文章很火 – 大概的观点是:有毒就是有毒,有毒就是不能吃,不要谈剂量,谈剂量的都是坏人。

看完发现,其实任何事情或者说任何“断言”不都是可以套用这句话的框架的吗?

这句话的本质在于:不考虑背景、阈值、程度就去做出真假的判断,就是耍流氓。剂量就是程度和阈值,而毒性就是最终的判断。

这个思维“公式”本质是没错的,至少比“xxx是真/假”这种“激情”公式靠谱。

而这句话“抛开剂量谈毒性就是耍流氓”本身,也可以套用这个公式。

 

“忙”是一种精神状态

并不是客观存在。

不会取舍,总有“重要”的事情,“重要的”事情越来越多,总有一些变得非常紧急。搞得精神焦虑不堪。

其实,很多事情不做也不会怎样,也不需要马上去做,“酝酿”一下,也许都不用做了。

找到真正有意义的事才是最重要的。

然而,从存在的角度来看,人做的大多数事情不过是为了让自己有存在感。

一个人,如果不需要存在感的“支撑”,恐怕真的就是圣人了吧!或者普通人已经完全无法理解了。

laravel在vagrant环境中nginx的权限问题

由于有很多遗留项目,所以在引入laravel时候就没有使用homestead,而是直接使用已有的vagrant环境。

部署后发现有各种权限问题,在网上也没有发现靠谱的方法。后来还是找到了相对复杂一些,但一劳永逸的方法。

首先vagrant会自动将我们映射的文件夹所有的文件权限设置为 vagrant:vagrant,即使我在vagrant中如何将文件夹内的所有内容chmod 777或775,都无济于事。

很自然地,既然无法修改文件的用户组,就考虑将fpm的用户组修改为vagrant:

sudo vi /etc/php/7.2/fpm/pool.d/www.conf

将原来的:

user = www-data

group = www-data

修改为:

user = vagrant

group = vagrant

即可。

另一种方法原理相同,修改Vagrantfile文件:

config.vm.synced_folder “.”, “/vagrant/”,owner: “www-data”, group: “www-data”

也就是直接修改同步文件夹的owner和group为www-data。

注意:第二种方法由于改变了工作目录的默认用户组(vagrant -> www-data),在执行composer相关命令时会出现问题,由于vagrant默认的登录用户是vagrant,此时执行composer的也是vagrant用户,同样会出现permission denied的问题。这么看来还是第一种办法更好一些。

PS. 如果修改了/etc/php/7.2/fpm/pool.d/www.conf 中的 listen.owner = vagrant  listen.group = vagrant,那么需要/etc/nginx/nginx.conf中的user为vagrant,否则nginx默认的用户www-data会没有权限连接fpm。并且,由于我的error.log和access.log配置在项目文件夹内,而这个文件是nginx创建的,所以也要配置nginx.conf的user为vagrant。

PS. 有的人也建议在vagrant环境中将vagrant用户加入www-data组,试了一下貌似也不行。至少还需要将文件夹内容设置为665以上。

增长七武器 – 券

总结一下常用的增长工具,原本想的是很多“虚”的、方法论的东西,但是貌似这种东西写出来大家都不感兴趣。尝试一下用具体的工具来“说教”一番。

定义

什么是券?当我们想要穷尽券的本质时,发现不得不限定它的范围。否则真是无从说起。我将券的定义追溯为“凭证”,所以,在我的系统里,券叫voucher。

所谓“凭证”,就是:你可以有偿或者无偿地获得它,当你拥有它的时候,可以将它换成其他的东西。这句话貌似是“废话”。

从增长的角度来说,券可以在获客(新客送券)、激活(随机发券、短信发券)、留存(生日券、特权券)方面发挥重要作用,而且很重要的一点,券是“可控”的,总数量、每人可获取的数量、一段时间可以使用的数量、过期时间。这些东西都是已经每个用户都很清楚的事情,不需要额外的用户学习成本。

类型

打折券、立减券 – 很好理解,在结账(场景)时,将它变成相应的折扣金额。

抵用券 – 类似的,在结账时,将它变成账单中的某N件商品的金额

实物领取券 – 需要到店领取的礼品或者商品

团购券 – 这里主要是限定了场景和条件 – 团购,只是流程不太一样,需要先付款,然后根据成团情况决定订单是否能够确认。在使用时和打折、立减、抵用类似,只是有一个时间差来判断是否成团。不过在实际中,大多数情况下都是容易成团的,团购只是个噱头。

充值券 – 有一个开卡(自助核销)的动作,之后根据券的规则给账户充一笔钱。

生命周期

核销 <- 获取 -> 过期

获取,可以免费领取、购买

核销,即券从一个号码变成另一个东西的那个动作

过期,建议所有用户的券、积分都要设置过期时间

财务核算

大多数单店都其实不需要考虑财务问题。但是多店或者有不同财务结构的情况时就需要考虑财务归属的问题了。

发券本质是一种营销行为,就会产生成本。有了营销成本,就要考虑是谁来承担以及承担多少的问题。

这也是为什么有时候没办法做充值返金额的原因,因为在A店的充值、返的金额可能是无法在B店消费的。因为A、B可能是财务独立的加盟店。有一种是简单的操作是一种独立的账户来挂营销费用,然后所有店均摊,但同样存在复杂的情况和不均的情况,比如A店送的100块钱,用户在B店消费了10块,在C店消费了50块,账户里还有40块没消费。就会很麻烦。最保险的方法就是将A送出的100元挂账,然后定期从A的收入中扣除掉,然后相应的分给B或者C,剩余的一直挂着。

这时候用券就方便多了,限定使用场景、甚至门店类型、次数(发送多张)。并且券的使用是方便统计的

软剑工程师

爸爸,你是做什么工作的?

工程师。

什么工程师?

软件工程师。

世界上真的有软件吗?

有啊!

蛇精就是用软剑把三娃绑住的。

……