Loading...

ChatGPT 刚出来时，各类的 GPT 客户端层出不穷，交互秒杀官方网页版，我本人也几乎不用官方页面。直到某一天，所有的第三方客户端都无法显示 GPT 的回复了，网上一查，说是 OpenAI 升级了页面，数据管道从原来的 EventSource 升级成了 WebSocket，这才造成几乎所有的第三方客户端全部阵亡的情况。 虽然大家很快跟进了修改，但是作为开发者，我们还是有必要了解下，为什么 OpenAI 要进行升级，WebSocket 有什么优势吗？

ChatGPT 的网页应用就是一个标准的聊天应用，信息交互比较频繁。但是，这个频繁只是相对的，首先我们与 ChatGPT 主要数据是文本，其次 ChatGPT 只会在我们发出消息后才会回复消息，不会主动向我们发送消息，所以官方一开始就选用了单向数据推送、传输数据为文本的 EventSource 作为消息管道。

但随着 OpenAI 的政策变化，网页版 ChatGPT 功能越来越强，现在已经支持文件上传，各种数据类型已经不是 EventSource 能承载得了了。可能你会想，文件上传就使用 HTTP 协议实现一个新的接口不就好了？增加一个功能就要增加接口，随着页面功能越来越多，ChatGPT 的 HTTP 连接会非常多，连接建立也是会消耗时间造成延迟，在聊天类应用上不合适；而且浏览器对于同一个网址的 HTTP 连接是有数量限制的，Chrome 的限制是 6 个，也就是同一个网址，只能同时存在 6 个 HTTP 连接，后续一律等待，直到前面的连接有断开。这对基于 HTTP 的 EventSource 简直就是灾难。基于数据类型、网络性能、浏览器限制等种种考虑，OpenAI 进行了升级，将 EventSource 替换成了 WebSocket。

虽然 ChatGPT 已经使用了 WebSocket 了，但是这不妨碍我们学习它的打字机效果的实现，下面将通过三种方式实现。

1. Stream 流式传输

研究这个事情的起因是产品的一个需求，要求对远程的接口抓包进行实时展示。一般做法都是通过 tcpdump 进行抓包，然后使用 Wireshark 进行可视化展示，但是产品要求是要“实时”，也就不能通过生成 pcap 文件下载让用户手动打开 Wireshark 的方式了。

1. 技术选型

接到这个需求后，我们就开始了技术选型。主要就两个方向，一个是前端做数据展示，另一个是通过调用 Wireshark 做数据展示。

前端实现的话，单单靠 JavaScript 是没法达到要求的，首先没有现成的 pcap 解析库，从头开始造轮子太耗时间，而且 JavaScript 的性能瓶颈在那，首先就排除了 JavaScript 实现的可能。

虽然 JavaScript 可能达不到性能要求，但是现代浏览器已经支持 WebAssembly （简称 WASM ），可以使用别的语言实现最消耗性能的部分。经过一番搜索，找到了一个开源的工具库： @goodtools/wiregasm ，一个将 Wireshark 的包分析器编译成 WASM 的库，NICE！

在现代 JavaScript 开发中，单元测试是保证代码质量的重要手段。通过单元测试，你可以对代码进行自动化测试，确保其在不同情况下的表现符合预期。 Mocha 是一个流行的测试框架，而 Chai 是一个功能强大的断言库。本文将带你快速入门 Mocha 和 Chai，并展示如何编写简单的单元测试。

1. 什么是 Mocha 和 Chai

Mocha： Mocha 是一个功能丰富、灵活的 JavaScript 测试框架，支持异步测试和多种测试风格（BDD、TDD）。 Chai： Chai 是一个断言库，它与 Mocha 配合使用，支持多种风格的断言，包括 expect 、 should 和 assert 。

2. 安装 Mocha 和 Chai

首先，你需要在项目中安装 Mocha 和 Chai：

公司关于代码提交流程一直都很规范，大家一直都遵守规则，平时也没过多关注这方面的细节，知道前一阵子需要生成 changelog，这才注意到协同开发中不仅仅要有代码规范，git commit同样很重要，所以写一篇文章记录下。

1. Commit 规范

关于 commit 规范，业内实践有很多，我们这次主要讨论 angular 方案。而自动生成 commit 方法有很多，这里介绍两种，一种是 git commit.template 提供提交模板，一种是通过 commitizen 这类工具自动生成。

1.1 Commit Template

这种方式比较简单，就是提供一份模板，然后通过 git config commit.template <模板文件> 设置 commit 模板，这样每次执行 git commit 后，默认的 commit message 就会显示成设置的模板。

Axios 的“拦截器”想必大家都已经熟练使用了，通过“拦截器”，我们对发送请求前的 config 进行修改，对得到响应的结果进行处理，具体使用场景我今天不做讨论，单纯讨论下 Axios 拦截器实现请求重发的问题。 因为在我们公司中，页面请求使用的是我开发的一个请求库，其中也有类似于“拦截器”的接口，我称之为“中间件”(对，就是 NodeJS 框架中常说的中间件)，使用的洋葱模型，实现请求重发相当简单。 但又一次，有人问我：Axios 的拦截器不能实现请求重发么？唉，问得好。先说结论，肯定是可以，但又不是完全可以，下面我们来详细说说。

1. 拦截器实现

因为我们的场景是请求重发，所以我们应该针对“非正常响应”进行响应拦截，根据响应状态码进行判断。流程图如下：

下面是代码示意：

虽然之前写的评论系统也有楼中楼的实现，但是因为账户并不是对接的第三方网站，用户评论还需要手动添加邮箱用户名什么的，也无法验证是否真实。 最关键的是，我还要注意 XSS 漏洞，写个博客还要花精力在 Web 安全上面，有点不值得。 所以想想，还是使用第三方的评论系统吧。市面上看了看，感觉就 giscus 的风格跟我现在的博客风格类似，那就决定是你了。

1. 什么是 giscus？

giscus 由 GitHub Discussions 驱动的评论系统，详细介绍大家看官网就行，我使用它的原因主要就下面两个：

开源免费。这个很重要? 使用 Github Discussion 作为存储后端，无需自行建立存储。

2. 配置 giscus

一般在用 OpenSSH 服务器的系统上进行 ssh 免密登录时，我们只需要在本地生成密钥对，将私钥留在本地，将公钥上传到目标服务器上的 .ssh/authorized_keys 就可以了。 然而 OpenWrt 上的 ssh 服务器却用的 Dropbear ，它是一种在较低内存和处理器资源的嵌入式系统中替代 OpenSSH 的软件，因此使用起来用诸多的不同。

1. 免密登录到 OpenWrt

如果本地是用 ssh-keygen 生成的密钥对，那么只需要将公钥上传到路由器的 /etc/dropbear/authorized_keys 中就行了：

cat ~/.ssh/id_rsa.pub | ssh root@192.168.1.1 'cat >> /etc/dropbear/authorized_keys'

2. 从 OpenWrt 登录到其他机器

原文地址： https://blog.tinned-software.net/change-ssh-port-in-centos-with-selinux/

Since version 4 of CentOS, SELinux is providing an additional layer of security to the Linux distribution. CentOS describes it like this: “Security-Enhanced Linux (SELinux) is a mandatory access control (MAC) security mechanism implemented in the kernel.” In other words, it controls with rules what a user or process is allowed to do.

从 CentOS 4 开始，SELinux 针对 Linux 发行版提供了一个额外的安全层。CentOS 描述其为：Security-Enhanced Linux(SELinux)是一种在内核中实现的强制访问控制(MAC)安全机制。换句话说，它通过规则控制用户或进程能都被允许做什么。

In my experience, keeping SSH on the default port 22 is a bad idea, as you will notice a lot of login attempts shortly after your server goes online. One of the actions (of course not the only one) to secure the server is to just change this port.

根据我的经验，让 SSH 服务使用默认的 22 端口是一个糟糕的主意，因为在你的服务器上线后不久你就会注意到非常多的尝试登录的记录。其中一种保护服务器安全的方式就是更换默认的 22 端口（当然你不止这一种方式）。

这道题曾经是谷歌的一道面试题，因为太过于经典，以至于谷歌取消了这道面试题。。。

1. 题目描述

给你 k 枚相同的鸡蛋，并可以使用一栋从第 1 层到第 n 层共有 n 层楼的建筑。

已知存在楼层 f ，满足 0 <= f <= n ，任何从 高于 f 的楼层落下的鸡蛋都会碎，从 f 楼层或比它低的楼层落下的鸡蛋都不会破。

每次操作，你可以取一枚没有碎的鸡蛋并把它从任一楼层 x 扔下（满足 1 <= x <= n）。如果鸡蛋碎了，你就不能再次使用它。如果某枚鸡蛋扔下后没有摔碎，则可以在之后的操作中 重复使用 这枚鸡蛋。

页面作为一种特殊的GUI软件，在前端工程中，很少提到自动化测试，业内也基本没有相对成熟的方案。 究其原因，主要是产品迭代速度实在太快，导致测试脚本无法跟上UI的快速变化，再加上人力原因，导致页面基本不做自动化测试。 虽然在产品快速迭代期，自动化测试无法落地，但是一旦进入稳定期，引入自动化测试还是能帮助较少开发成本。

1. 什么是测试？

测试其实就是在已经开发完成的软件之上采用人工或非人工的方式验证软件是否符合预期，是否会造成损失等潜在问题的一种方式。

多数情况下，前端代码都是研发手工自测，或是提测后由QA人员手工测试。

手工测试当然也是没有问题的，但是通过自动化的测试工具，可以更加快速高效且准确定位问题所在。