sisylocke

@Ericxiaoshuang #90 是通过 yyp 啊，adsense 还不了解

@Ericxiaoshuang 冒昧问一下，能透露下大致播放量吗？我最近在做 YouTube shorts ，但是一个视频播放量才几千，感觉收益遥遥无期啊

安装 custom new tab 这个插件，不用默认的标签页了

你是不是没好好看视频啊，视频从第五分钟开始就在和直驱做对比了啊

而且关于插混，视频的结论是，插混在市区低速就是增程模式，高速亏电动力高于增程同时油耗低于增程，但是结构复杂可靠性略低，如果调教不好有顿挫；这里并没有说插混和增程谁好谁坏，但给我的感觉是插混更优啊，而且视频关于插混和增程的比较总共就这三句话，然后总结出插混相对于增程有两个优点，两个缺点，怎么就成了无限放大一方的优势，缩小另一方的优势......

话说这种配列的键盘，ESC 和~的位置总感觉有点不习惯

不行的，在 stdout 进程结束前终端不能读取 stdin ，你需要的是 readlineSync 之类的工具。

我不同意这是应用层的设计导致的问题，这些差别就是 TCP 协议的不同实现。

首先你的图客户端和服务端是不是弄反了，一般把被动打开的一方称为服务端，主动的一方称为客户端。

在建立 TCP 连接的时候，客户端和服务端各自都需要初始化一个控制块（ TCB ），根据 RFC793 的建议的标准做法，这个连接的初始状态就是 Listen 。但是在具体实现的时候就会发现这一步是多余的。客户端在初始化 TCB 后发送 SYN ，然后状态立即变为 SYNSENT ；服务端接收 SYN 请求，然后初始化一个 TCB 后，状态又立即变为 SYN-RCVD 。所以 Listen 状态是一个很短暂的状态，完全可以一步到位将 TCB 初始化为 SYN 或者 SYNRCVD 状态。

所以在新连接的时候一般不会出现 LISTEN 状态，但是不是说 LISTEN 状态就没用了。当接受到 RST 的时候，并不一定代表对方是关闭连接，所以有的 TCP 实现并不会直接丢弃这个连接，而是重新初始化 TCB 等待重新握手恢复连接，这时的状态就是 LISTEN 。

不可能存在啊，无论怎样表达，都要基于 B 已经发生这一事实。