Author: admin

NGINX 的速率限制

NGINX最有用但经常被误解和配置错误的功能之一是速率限制。它允许您限制用户在给定时间内可以发出的HTTP请求数量。请求可以像GET对网站首页的POST请求或登录表单上的请求一样简单。

速率限制可用于安全目的,例如,减慢暴力密码猜测攻击的速度。通过将传入请求速率限制为实际用户的典型值,并(使用日志记录)标识目标URL,它可以帮助防御DDoS攻击。更一般而言,它用于防止上游应用程序服务器同时被太多用户请求所淹没。

在此博客中,我们将介绍NGINX的速率限制基础以及更高级的配置。速率限制在NGINX Plus中的工作方式相同。…

localhost ssl 本地证书

有时,人们希望获得主机名为“localhost”的证书,以用于本地开发或与需要与 Web 应用程序通信的原生应用程序一同分发。Let’s Encrypt 不能为“localhost”提供证书,因为没有人唯一地拥有它,并且它不在“.com”或“.net”等顶级域名下。您可以将您自己的域名设置为解析至“127.0.0.1”,并使用 DNS 验证获取证书。然而,通常情况下这是个坏主意,您其实有更好的选择。…

    

对于未来chrome80 samesite问题的兼容解决方案

未来chrome80会默认(SameSite: lax)在跨域请求的情况下不允许跨域携带cookie给后端,导致所有跨域场景下使用cookie进行鉴权的服务会受到影响。
网站可以选择显式关闭SameSite属性,将其设为None。不过,前提是必须同时设置Secure属性(Cookie 只能通过 HTTPS 协议发送),否则无效。
但是设置了SameSite为None, 很难保证在非chrome浏览器上一定是兼容的,所以基于兼容性考虑有两个方案:
1.采用两套cookie 例如原cookie中已经种入了session-id=xxxxx,可以维持不变,再额外种入另一个cookie session-id-2=xxxxx同时设置特性SameSite为none secure: true。这样可以兼容新旧版的所有浏览器。这样就要求后端取得时候判断session-id不存在,再取cookie session-id-2的值
2.JWT方案,统一把token放在header的authorization,就不存在跨域携带cookie的困扰了
第一个方案主要适配在于后端,前端基本不需要变动,第二个方案需要前后端做一定的改造,视情况而定

    

Head标签里面的dns-prefetch,preconnect,prefetch和prerender

开始

今天突然心血来潮想起前端性能优化的问题,这基本是老生常谈的事情了,面试随便都能说上几个,但是还是有点疑问:就是Head标签了,记忆中Head可是藏龙卧虎,各种技能都有,当然这些不可能都一一记住,太伤脑细胞了,于是打开神奇的Github,来到这个 HEAD项目,翻一翻就会看到今天的主角dns-prefetch,preconnect,prefetch和prerender兄弟了,究竟他们有何区别,是怎样的一家人尼。

    

软件架构编年史

原文:https://herbertograca.com/2017/07/03/the-software-architecture-chronicles/

译者:最早看到的是作者的这篇文章(译文),其中的那副信息图可谓集软件架构之大成。后来发现这是作者学习和思考软件架构发展史的系列文章之一。“以史为鉴,可以知兴替”,阅读历史就是学习的过程。翻译也不例外,我也是通过阅读和翻译来学习软件开发的历史,联系作者获得授权之后便有了这一系列译文。

这是软件架构系列的第一篇文章。我将我对软件架构的学习过程和思考以及我是如何运用这些知识的写成这一系列文章。

我把这一系列文章称为“软件架构编年史”,并不是因为我觉得自己的文笔不错,而是想用一种有趣的方式旧调重弹!😀