@sampeng 我也说的是真的，4k 的电影本身传输的时候就经过算法压缩了， 例如 MPEG-4 编码等等。 压缩后才只要 2-30G

@sampeng #53L 有没有一种可能， 你传输过来的 4k 电影本身就是压缩过才只要 2-30G

@skies457 #74L
我从未听过 http 协议中用 \n\n 来最为判断文本已经达到的末端。 根据 http 协议 `content-length` 用来判断数据大小是多少， 即使在早期也是 一次请求，一次响应， 用 tcp connection close 来识别的。 请问你说 的 \n\n 是哪个版本？

@ipwx #64

我告诉你粘包是怎么来的


```
Socket socket = new Socket("127.0.0.1", 8000);
OutputStream os = socket.getOutputStream();
os.write("test".getBytes());
os.write("test1".getBytes());
os.write("test3".getBytes());
```

写了三次数据， 然后在调用 read 读取的时候发现写入的数据被一次性读取到了， 所以他 /她认为数据包被粘连在一起了。

“粘包” 无论是否打引号说出这个词就是对 TCP 协议的不理解，想当然的一个词语。 这种本身就应该抵制。"需要自己判断写入的字节什么时候已经达到的末端", 这就很好的解释了这个问题。


@ipwx 我没猜错你对 TCP 协议估计也是一知半解 。你写一次 tun 设备的 三次握手和四次挥手， 你就知道所谓的封包 /拆包 /重传 等等， 都已经做好， 数据已经有序的给你了。 你只要操作 Stream 就可以了。


我在跟你明确一下， 他说的粘包，指的是 代码中 write 两次， 另一端 read 一次的时候就可以读出来。



@ipwx 或则我这么问你， 如果你发现 TCP 有所谓的粘包， 请截图用 wireshark 抓包并且保存截图让我看看， 你能截屏出来， 我给你奖励 1w

@nothingistrue #21 你确定你理解的是楼主所说的问题, TCP 帧在应用层是不关心的。 而所谓的 “判断写入的字节什么时候已经达到的末端” 是需要自己解析的

而且你说的 “分帧取帧”，或者“帧解码”。 是指什么？ 说的是 解析 RFC 793 里面的 `TCP Header Format` 吗？ 很抱歉，在用户使用协议上，没有权限读取对应的 `TCP Header Format` ， 要么使用 tun/tap 等虚拟网卡， 要么使用 pcap/winpcap/npcap 或则 win10 的驱动网络拦截。 但是这些 TCP 协议的操作，往往都不是 TCP 使用用户来进行操作的， 楼主很明显是在使用 TCP 协议， 而不是解析 TCP 协议

当我看到 TCP 粘包的时候，我很震惊， 后面我开始解释 TCP 没有粘包， 只有 “因为是流协议， 所以需要应用自己去判断写入的字节什么时候已经达到的末端。” 后来我渐渐的麻木......

TCP 粘包是啥？ 自己创造一个名词出来？ TCP 从来没有粘包一说， 看你的文章你也是对 TCP 一知半解。 麻烦赶紧删了，免得误人子弟。

我先跟你说，很明确的来说 TCP 没有粘包这一个说法，根本就不存在。


我看你用 Java 写的代码， 那么我就用 Java 代码给你举个例子

```
Socket socket = new Socket("127.0.0.1", 8000);
OutputStream os = socket.getOutputStream();
os.write("test".getBytes());
```

实际上会发生什么？

如果网络延迟，或则发生丢包，那么会超时重传. 然后网络线路没问题， 那么会直接写入系统的 TCP/IP buffer 里面去。

如下


```
Socket socket = new Socket("127.0.0.1", 8000);
OutputStream os = socket.getOutputStream();
os.write("test".getBytes());
os.write("test1".getBytes());
os.write("test3".getBytes());
```

那么我写入三次表示什么？ 很显然根据我上面说的，系统为了性能会缓存对应的 TCP/IP 的数据信息， 那么我可以采用一个很大 buffer 来进行一次性将这两次的请求给直接读取过来。


根据这个理解那么就可以把 TCP 看作流， 通过流来进行运输货物，很显然明显的是 TCP 就是流协议。 流协议何谈封包和拆包？


那如何解决判断 TCP 中这次请求的信息已经是末端了？

很常见的两种方案


1. 一次请求一次响应， 后续关掉 socks
2. 用 4 字节定义一个无符号的整数来定义这个报文的 Length 就好了


所谓的 `特殊分隔符`简直是最愚蠢的做法， 难道我的报文中就不能出现对应的特殊符号吗？ `固定消息长度` 简直是浪费内存和网络开销。完全不可取。


因为是流协议， 所以需要应用自己去判断写入的字节什么时候已经达到的末端。

@whywaoxaks #6L

小红有 3 支笔， 小强有 5 块橡皮, 橡皮一般用在铅笔上， 所以小红拿的 3 支笔应该是铅笔。 那么铅笔一般用在什么？ 小学课本上或者是素描上。 如果是素描，那么名字不会叫小红， 所以排除素描美术，那么剩下的就只有一种可能，那就是小学课本上， 那么上小学年纪是多少？ 年满 6 周岁以上 12 岁左右。3 支笔表和 5 块橡皮,表示作业很多，考试很多，那么肯定就排除 1,2,3,4,5 年级。 也就是说小红和小强的是 6 年级 12 岁左右。 那么小明也应该是 12 岁左右。 所以小明是 12 岁

@qrobot 最后发现 嗯，eventloop 真香. 我跟你举个例子。

我是不是可以使用多线程来执行代码？ 嗯， 是的可以用多线程，来进行共享内存

Yes ， 我写了一个多线程来来操作内存，但是我发现内存会被其他的进行修改， 我感觉很苦恼
Yes ， 我写了一个 Lock 可以锁住这一块内存， 来控制多线程访问的问题，但是我发现了速度很慢
Yes, 我写了一个 Lock-Free 大幅度提高了锁的性能问题，但是我发现不停的创建线程，销毁线程。 这样消耗很大
Yes ， 我写了一个线程池来解决了线程销毁和创建的问题, 但是我发现，如果 IO 很慢的情况下， 线程就会被占用，导致一个请求就一个 IO 这样程序太慢了。
Yes, 我写了一个微任务解决了这个问题， 这样我可以在一个线程上执行多个任务， 这样线程就不会被 IO 阻塞了，我很开心的解决了这个问题， 并且设计出来了， 我给他取了一个好听的名字叫做 Microtask, 和 Microtask queue 。并且给了一个 Work 来单独的执行其他线程的问题。 但是 Work 的开销太大了， 并且没有多线程，共享内存
YEs, 我写了一个多线程来来操作内存，但是我发现内存会被其他的进行修改， 我感觉很苦恼

@fulvaz 然后你换个其他语言，写到最后发现 嗯，JavaScript 真香

@fulvaz 如果是为了构建 fiber 树，例如做 react 或则 vue 这种框架，本身的 eventloop 性能完全足够. 共享内存本身就是一个非常错误的一种解决方案， 共享内存就存在 lock 的问题。其次日志的问题难道不应该先记录到 indexdb 之后在空闲的时候上传到服务器


performance 就能很好的分析内存泄漏的原因， 通过记录用户的操作方式就可以正确的复现出来对应的内存泄漏问题。 如果一直都复现不出来问题， 建议直接联系客服

其次你要是真的觉得 js 的性能你不满意， 欢迎来到

1. (C/C++) Emscripten
2. Rust
3. Go
4. Kotlin
5. Swift
6. D
7. Pascal
8. Zig
9. Grain
10. C#
11. F#
12. gtk

你会其中一门语言就可以达到你说的， 支持多线程，没有瘸腿的异步任务管理。 这些都是可以运行在浏览器端的

@fulvaz 你这明显没黑到点子上

你说的不支持多线程， 在 web 上本来就有 WebWorker 和 webassembly, 基于 eventloop 来说， 对单线程利用率最高，基本上不存在性能问题， 除非是音频和视频解码和编码，或则需要并发计算的，否则基本上在项目中 eventloop 就够用了， 如果真的很大 WebWorker 就能满足了， 至于你说的 IPC 通信需要时间， 我给你科普一下，在大部分场景下，多线程慢单线程， 因为单线程无需上下文切换， 而多线程会切换上下文

多线程下会消耗以下资源


1. 切换页表全局目录
2. 切换内核态堆栈
3. 切换硬件上下文（进程恢复前，必须装入寄存器的数据统称为硬件上下文）
ip(instruction pointer)：指向当前执行指令的下一条指令
bp(base pointer): 用于存放执行中的函数对应的栈帧的栈底地址
sp(stack poinger): 用于存放执行中的函数对应的栈帧的栈顶地址
cr3:页目录基址寄存器，保存页目录表的物理地址
......

4. 刷新 TLB
5. 系统调度器的代码执行


其次在异步任务管理上， 是可以看到这些代码执行了多久， 打开 f12 选择 performance 即可. OOM 和 卡死的问题直接就可以 通过 performance 查看就好了


你这个黑点完全没黑到地方。 要是我黑肯定是


1. 大多数浏览器不符合 W3C 的标准， 例如以前 sort 的返回值
2. css 在不同浏览器上差异太过于明显
3. 不支持并发计算
4. 没有内置好的时间处理函数
5. 没有内置常见的例如 sha rsa ecc base64 等常用加密算法, 例如 btoa 就不能加密中文， 目前都还没解决这个问题
6. 没有好的布局方式 grid 和 flex 等等布局都不是很满意，因为嵌套太深，andoird LinearLayout 似乎不错

@des 这个问题非常好查， 看一下代码就好了。nodejs Queue 导致的情况无非就几种情况