月刊少女野崎君のBlog

202⅘ 过去这一年转眼都2025年3月了，掰着手指头算算，大学毕业快四年，社畜生涯也满四年了。2024年真是跌宕起伏的一年…最近总在复盘自己的得与失，干脆把这一年的故事都写下来。 一、菜鸟起飞的日子（2021-2023）记得2021年元宵节刚过，我就拖着行李箱杀到深圳找实习。那时候真是又菜又爱玩，整个人还带着学生气。没想到撞上互联网最后的好光景，三八节当天居然入职了家独角兽公司，第一天还蹭了半天妇女节假期。 公司确实挺香：茶水间随便喝的进口牛奶、女生专属生理假、CTO是腾讯T12的大佬，团队里遍地海归硕士。我这个二本小菜鸡坐在工位上，连给MacBook装开发环境都要偷偷百度。 带我的mentor是个说话带刺的人，没想到两个月后mentor被调岗，新来的前端老大成了我职场贵人。有次因为接口参数大小写的问题和后端小哥撕逼到凌晨，被怼哭后躲在家抹眼泪，他打电话开导我到凌晨。工作上对我很多帮助，一直记到现在。 二、十字路口的迷茫（2023-2024）到2023年底，公司三年只调2次薪，连老大都说想跑路。我开始偷偷刷题准备跳槽，面了几家发现行情急转直下。最接近成功的一次，五一前终面完HR说 ...

背景静态资源的快速加载和高可用性对用户体验至关重要。随着 CDN 的推行，单一云服务商在遇到特殊情况时（如网络中断、服务故障等），会导致静态资源加载失败，从而影响用户体验和业务连续性。 所以，单靠一个云服务商已经不能满足我们的需求了，我们需要更强的容灾能力。需要对资源进行多云自动切换。 我们的最终目标是“多CDN架构”，具体实现方式如下 在源站上配置多个CDN域名，每个CDN域名对应一个CDN服务提供商的节点。这样，不同的CDN节点可以通过不同的域名访问同一个源站。 基于这种 “多 CDN 架构 ” 来应对单个云厂商在遇到特殊情况时 可以对资源进行自动切换，以保证网站的正常运行。 如何实现静态资源的分类静态资源可以大致分为两种类型： 同步静态资源 跟随页面组合好之后一起返回 ｜ 接口返回的cdn地址 特点：能够灵活控制资源cdn域名 异步静态资源 由前端打包工具，建立关联关系后，构建工具异步拉取 特点：由前端在构建时，根据不同的环境写死的cdn域名，在构建时已经确定，无法在运行时动态替换 原理所以我们的实现主要分为三部分： 如何自动获取加载失败的静态资源（同步加载的 < ...

关于一次上传密钥泄露引发的网站奔溃…某天，雪碧正准备下班回家，心想哎呀呀，还有几天就可以回家过年了。这时，突然来了个电话：雪碧，雪碧，网页突然打不开了，快看看，用户要炸锅了。 雪碧内心一惊，这么吓人，打开了刚放进包里的电脑，打开公司业务网站一看 嗯？找不到服务器 ip 地址，那是 DNS 解析出现问题了，雪碧细品下就抓起电话开始摇人。 联系到运维查看 DNS 解析，发现所有 DNS 解析都是空的，又查看 WHOIS 后，发现 Domain 状态被 clientHold了，这是为啥呢？ 登录云厂商网站一看，发现云厂商发了封公告【违规域名暂停解析并禁止转移通知】。这是为啥，俺们可都是21世纪好公民。 通知里提供了违规的 URL，是个上传到 cos 的 pdf 文件，打开一看，嘿，不是个pdf文件，是个欺诈网页。有人利用漏洞上传文件，篡改成 html 网页 到处散播。 同时看到在 cos 图床中还发现不止这一个文件，这怎么行，流传出去可要祸害不少人呐，赶紧先采取了紧急措施，将所有关联文件写设置了私有读写先，并关闭上传源头的 cos 上传，然后加急联系云厂商同事，帮忙解封域名。 事后复盘原因 ...

HTTP1.1 如何解决 HTTP 的队头阻塞问题？ 什么是 HTTP 队头阻塞？HTTP 传输是基于请求-应答的模式进行的，报文必须是一发一收，但值得注意的是，里面的任务被放在一个任务队列中串行执行，一旦队首的请求处理太慢，就会阻塞后面请求的处理。这就是著名的HTTP队头阻塞问题。 并发连接对于一个域名允许分配多个长连接，那么相当于增加了任务队列，不至于一个队伍的任务阻塞其它所有任务。在RFC2616规定过客户端最多并发 2 个连接，不过事实上在现在的浏览器标准中，这个上限要多很多，Chrome 中是 6 个。 但其实，即使是提高了并发连接，还是不能满足人们对性能的需求。 域名分片一个域名不是可以并发 6 个长连接吗？那我就多分几个域名。 比如 content1.monthly.com 、content2.monthly.com。 这样一个monthly.com域名下可以分出非常多的二级域名，而它们都指向同样的一台服务器，能够并发的长连接数更多了，事实上也更好地解决了队头阻塞的问题。

上一节介绍了浏览器解析的过程,其中包含构建DOM、样式计算和构建布局树。 接下来就来拆解下一个过程——渲染。分为以下几个步骤: 建立图层树(Layer Tree) 生成绘制列表 生成图块并栅格化 显示器显示内容 一、建图层树如果你觉得现在DOM节点也有了，样式和位置信息也都有了，可以开始绘制页面了，那你就错了。 因为你考虑掉了另外一些复杂的场景，比如3D动画如何呈现出变换效果，当元素含有层叠上下文时如何控制显示和隐藏等等。 为了解决如上所述的问题，浏览器在构建完布局树之后，还会对特定的节点进行分层，构建一棵图层树(Layer Tree)。 那这棵图层树是根据什么来构建的呢？ 一般情况下，节点的图层会默认属于父亲节点的图层(这些图层也称为合成层)。那什么时候会提升为一个单独的合成层呢？ 有两种情况需要分别讨论，一种是显式合成，一种是隐式合成。 显式合成下面是显式合成的情况: 一、 拥有层叠上下文的节点。 层叠上下文也基本上是有一些特定的CSS属性创建的，一般有以下情况: HTML根元素本身就具有层叠上下文。 普通元素设置position不为static并且设置了z-index属性， ...

完成了网络请求和响应，如果响应头中Content-Type的值是text/html，那么接下来就是浏览器的解析和渲染工作了。 首先来介绍解析部分，主要分为以下几个步骤: 构建 DOM树 样式计算 生成布局树(Layout Tree) 构建 DOM 树由于浏览器无法直接理解HTML字符串，因此将这一系列的字节流转换为一种有意义并且方便操作的数据结构，这种数据结构就是DOM树。DOM树本质上是一个以document为根节点的多叉树。 那通过什么样的方式来进行解析呢？ HTML文法的本质首先，我们应该清楚把握一点: HTML 的文法并不是上下文无关文法。 这里，有必要讨论一下什么是上下文无关文法。 在计算机科学的编译原理学科中，有非常明确的定义: 若一个形式文法G = (N, Σ, P, S) 的产生式规则都取如下的形式：V->w，则叫上下文无关语法。其中 V∈N ，w∈(N∪Σ)* 。 其中把 G = (N, Σ, P, S) 中各个参量的意义解释一下: N 是非终结符(顾名思义，就是说最后一个符号不是它, 下面同理)集合。 Σ 是终结符集合。 P 是开始符，它必须属于 N ...

谈到HTTPS, 就不得不谈到与之相对的HTTP。HTTP的特性是明文传输，因此在传输的每一个环节，数据都有可能被第三方窃取或者篡改，具体来说，HTTP 数据经过 TCP 层，然后经过WIFI路由器、运营商和目标服务器，这些环节中都可能被中间人拿到数据并进行篡改，也就是我们常说的中间人攻击。 为了防范这样一类攻击，我们不得已要引入新的加密方案，即 HTTPS。 HTTPS并不是一个新的协议, 而是一个加强版的HTTP。其原理是在HTTP和TCP之间建立了一个中间层，当HTTP和TCP通信时并不是像以前那样直接通信，直接经过了一个中间层进行加密，将加密后的数据包传给TCP, 响应的，TCP必须将数据包解密，才能传给上面的HTTP。这个中间层也叫安全层。安全层的核心就是对数据加解密。 接下来我们就来剖析一下HTTPS的加解密是如何实现的。 对称加密和非对称加密概念首先需要理解对称加密和非对称加密的概念，然后讨论两者应用后的效果如何。 对称加密是最简单的方式，指的是加密和解密用的是同样的密钥。 而对于非对称加密，如果有 A、 B 两把密钥，如果用 A 加密过的数据包只能用 B 解密，反之，如 ...

HTTP 特点HTTP 的特点概括如下: 灵活可扩展，主要体现在两个方面。一个是语义上的自由，只规定了基本格式，比如空格分隔单词，换行分隔字段，其他的各个部分都没有严格的语法限制。另一个是传输形式的多样性，不仅仅可以传输文本，还能传输图片、视频等任意数据，非常方便。 可靠传输。HTTP 基于 TCP/IP，因此把这一特性继承了下来。这属于 TCP 的特性，不具体介绍了。 请求-应答。也就是一发一收、有来有回， 当然这个请求方和应答方不单单指客户端和服务器之间，如果某台服务器作为代理来连接后端的服务端，那么这台服务器也会扮演请求方的角色。 无状态。这里的状态是指通信过程的上下文信息，而每次 http 请求都是独立、无关的，默认不需要保留状态信息。 HTTP 缺点无状态所谓的优点和缺点还是要分场景来看的，对于 HTTP 而言，最具争议的地方在于它的无状态。 在需要长连接的场景中，需要保存大量的上下文信息，以免传输大量重复的信息，那么这时候无状态就是 http 的缺点了。 但与此同时，另外一些应用仅仅只是为了获取一些数据，不需要保存连接上下文信息，无状态反而减少了网络开销 ...

HTTP 报文结构是怎样的？对于 TCP 而言，在传输的时候分为两个部分:TCP头和数据部分。 而 HTTP 类似，也是header + body的结构，具体而言: 1起始行 + 头部 + 空行 + 实体 由于 http 请求报文和响应报文是有一定区别，因此我们分开介绍。 起始行对于请求报文来说，起始行类似下面这样: 1GET /home HTTP/1.1 也就是方法 + 路径 + http版本。 对于响应报文来说，起始行一般张这个样: 1HTTP/1.1 200 OK 响应报文的起始行也叫做状态行。由http版本、状态码和原因三部分组成。 值得注意的是，在起始行中，每两个部分之间用空格隔开，最后一个部分后面应该接一个换行，严格遵循ABNF语法规范。 头部展示一下请求头和响应头在报文中的位置: 不管是请求头还是响应头，其中的字段是相当多的，而且牵扯到http非常多的特性，这里就不一一列举的，重点看看这些头部字段的格式： 字段名不区分大小写 字段名不允许出现空格，不可以出现下划线_ 字段名后面必须紧接着: 空行很重要，用来区分开头部和实体。 问: 如 ...

CORS跨域资源共享，是基于 HTTP 上一个用来解决跨域的方法，需要服务端和浏览器端同时支持 CORS 分为简单请求和非简单请求简单请求：简单请求只要满足以下两大条件就是简单请求 请求方法只能是 GET、POST、HEAD 请求头中不超出以下几个字段 accept， accept-language， context-type, 其中 content-type 只能是 application/x-www-form-urlencoded、text/plain、multipart/form-data， Last-Event-ID 否则就视为非简单请求，浏览器对于两种请求处理是不一样的 简单请求流程对于简单请求，浏览器直接发出 CORS 请求。具体来说，就是在头信息之中，增加一个 origin 字段，用来标识是哪个源（协议 + 域名 + 端口）。服务器根据这个值，决定是否同意这次请求 12345GET/cors HTTP/1.1Origin: http://baidu.comHost: baidu.comAccept-Language: en-USConnection: keep-ali ...