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 流式传输

事情起因是周五例行阅读阮一峰的《科技爱好者周刊》第 277 期，其中有一部分介绍 Apple 使用 iPhone15 Pro Max 拍摄宣传视频的文章。

本来这种事情苹果不是第一次做，依稀记得 iPhone 7 plus 第一次上双摄像头时，苹果也拍了类似的宣传视屏，只不过当时舔的人居多，而且本来就一个广告，大部分人也没太多较真其使用的专业设备中，iPhone 反而是最便宜的。

但这次，阮一峰在自己的文章中又拿 Apple 这件事鞭尸，感觉 Apple 这种作秀方式已经引起了大家的反感。

早期大家都认为 Apple 是创新标杆，它做的一定是未来。但随着这两年 Apple 的创新不足，加上国内手机厂商的崛起，人们看待 Apple 的滤镜逐渐消失，渐渐地发现 Apple 现在也只是一个普通公司了。

十几年前，没人会认为 Nokia 的手机业务会没落，就跟二十年前没人认为 Motorola 会没落一样，本质上就是创新不足，被颠覆性的事物给取代了。

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

1. 技术选型

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

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

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

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人员手工测试。

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

平时工作生活中基本都会接触到各种代理，nginx反向代理、v2ray正向代理，还有openwrt中FQ常说的透明代理。至于这三者有什么区别，下面逐一进行简单的介绍。

1. 正向代理(Forward Proxy)

首先，无特殊说明的情况下，正向代理 一般就是我们平时说的 代理。

正向代理服务器位于客户端与服务端之间，用于转发客户端请求，因此客户端需要做特殊配置。