 |
sisylockeV2EX 第 209100 号会员，加入于 2017-01-04 11:08:51 +08:00 |
sisylocke 最近回复了
17 天前 回复了 ColinZeb 创建的主题 › 哔哩哔哩 › 听说很多 b 站厂商要求 up 做广告是声明不是恰饭，是自购体验 |
你是不是没好好看视频啊，视频从第五分钟开始就在和直驱做对比了啊
而且关于插混，视频的结论是，插混在市区低速就是增程模式，高速亏电动力高于增程同时油耗低于增程，但是结构复杂可靠性略低，如果调教不好有顿挫；这里并没有说插混和增程谁好谁坏，但给我的感觉是插混更优啊，而且视频关于插混和增程的比较总共就这三句话，然后总结出插混相对于增程有两个优点，两个缺点，怎么就成了无限放大一方的优势，缩小另一方的优势......
而且关于插混，视频的结论是，插混在市区低速就是增程模式，高速亏电动力高于增程同时油耗低于增程，但是结构复杂可靠性略低，如果调教不好有顿挫；这里并没有说插混和增程谁好谁坏，但给我的感觉是插混更优啊，而且视频关于插混和增程的比较总共就这三句话，然后总结出插混相对于增程有两个优点，两个缺点，怎么就成了无限放大一方的优势，缩小另一方的优势......
2022-02-19 15:16:49 +08:00 回复了 AllenHua 创建的主题 › 机械键盘 › 我的客制化键盘初体验 |
话说这种配列的键盘，ESC 和~的位置总感觉有点不习惯
2021-12-21 22:44:08 +08:00 回复了 tuduweb 创建的主题 › Bash › 请教一下，怎么把向终端输入的内容重定向一份到文件？ |
不行的，在 stdout 进程结束前终端不能读取 stdin ，你需要的是 readlineSync 之类的工具。
2021-12-19 01:29:10 +08:00 回复了 amiwrong123 创建的主题 › 程序员 › TCP 握手中，怎么理解从 LISTEN 转换到 SYN_SENT？ |
我不同意这是应用层的设计导致的问题，这些差别就是 TCP 协议的不同实现。
首先你的图客户端和服务端是不是弄反了，一般把被动打开的一方称为服务端，主动的一方称为客户端。
在建立 TCP 连接的时候，客户端和服务端各自都需要初始化一个控制块（ TCB ），根据 RFC793 的建议的标准做法，这个连接的初始状态就是 Listen 。但是在具体实现的时候就会发现这一步是多余的。客户端在初始化 TCB 后发送 SYN ，然后状态立即变为 SYNSENT ；服务端接收 SYN 请求，然后初始化一个 TCB 后，状态又立即变为 SYN-RCVD 。所以 Listen 状态是一个很短暂的状态，完全可以一步到位将 TCB 初始化为 SYN 或者 SYNRCVD 状态。
所以在新连接的时候一般不会出现 LISTEN 状态，但是不是说 LISTEN 状态就没用了。当接受到 RST 的时候，并不一定代表对方是关闭连接，所以有的 TCP 实现并不会直接丢弃这个连接，而是重新初始化 TCB 等待重新握手恢复连接，这时的状态就是 LISTEN 。
首先你的图客户端和服务端是不是弄反了，一般把被动打开的一方称为服务端，主动的一方称为客户端。
在建立 TCP 连接的时候，客户端和服务端各自都需要初始化一个控制块（ TCB ），根据 RFC793 的建议的标准做法，这个连接的初始状态就是 Listen 。但是在具体实现的时候就会发现这一步是多余的。客户端在初始化 TCB 后发送 SYN ，然后状态立即变为 SYNSENT ；服务端接收 SYN 请求，然后初始化一个 TCB 后，状态又立即变为 SYN-RCVD 。所以 Listen 状态是一个很短暂的状态，完全可以一步到位将 TCB 初始化为 SYN 或者 SYNRCVD 状态。
所以在新连接的时候一般不会出现 LISTEN 状态，但是不是说 LISTEN 状态就没用了。当接受到 RST 的时候，并不一定代表对方是关闭连接，所以有的 TCP 实现并不会直接丢弃这个连接，而是重新初始化 TCB 等待重新握手恢复连接，这时的状态就是 LISTEN 。
2021-12-18 17:04:53 +08:00 回复了 Biwood 创建的主题 › 中文 › 在中文表述里面，“A 跟 B 一样”这种说法一般会隐含“B 比 A 具有更早发生或有大的影响力”，那有没有一种表述，仅仅是说明说两者一样，没有所谓的影响力大小或者时间先后顺序问题？ |
不可能存在啊，无论怎样表达，都要基于 B 已经发生这一事实。
2021-12-06 15:08:01 +08:00 回复了 eccentric579 创建的主题 › 问与答 › 忘记了 Linux 的用户名，但是还记得密码有救么 |
.bash_history?
Select Language