☆─────────────────────────────────────☆
hengcuiyuan (远航) 于 (Tue Oct 18 21:34:08 2022) 提到:
问一个初级问题：socket在多线程的环境下，是怎么区分哪个数据包是给哪个进程的？或者说，从网络上到来的杂乱无章的数据包，这些数据包是怎么重新组合成一个完整的应答报文的？
☆─────────────────────────────────────☆
hollyczy (哈哈) 于 (Tue Oct 18 22:07:01 2022) 提到:
从程序员的角度，socket就不能是多线程的吧。
☆─────────────────────────────────────☆
z16166 (Netguy) 于 (Tue Oct 18 22:30:14 2022) 提到:
tcp/udp的通信是四元组<src ip, src port，dst ip, dst port>决定的
socket可以和上述四元组中的本地ip/port绑定（不讨论raw socket）
☆─────────────────────────────────────☆
hengcuiyuan (远航) 于 (Tue Oct 18 23:06:28 2022) 提到:
即便是1对1的通信，在多线程环境下，如果多个读数据的请求发出去了，回复过来的数据也可能是杂乱无章的，1个请求的答复被分成多个应答报文，这些应答报文的顺序也可能是乱的，怎么组合？
【 在 z16166 的大作中提到: 】
: tcp/udp的通信是四元组<src ip, src port，dst ip, dst port>决定的
: socket可以和上述四元组中的本地ip/port绑定（不讨论raw socket）
☆─────────────────────────────────────☆
hengcuiyuan (远航) 于 (Tue Oct 18 23:06:54 2022) 提到:
真的吗？
【 在 hollyczy 的大作中提到: 】
: 从程序员的角度，socket就不能是多线程的吧。
☆─────────────────────────────────────☆
z16166 (Netguy) 于 (Tue Oct 18 23:22:41 2022) 提到:
这是OS的网络栈干的事情，从应用层到内核层。
1、收到的每个数据包有dst ip、dst port，根据ip/port可以反查到对应的socket，而socket句柄归哪个进程持有，OS是知道的。
2、通过socket出去的每个数据包有dst ip、dst port，OS的路由层根据系统的路由设定知道从哪个网卡接口把包发出去。
至于大包拆成符合MTU的小包，以及反过来的小包组合成大包，这是kernel干的，应用层一般无需关心。
TCP包是有序列号的，OS拆包、组包时要用的。
【 在 hengcuiyuan 的大作中提到: 】
: 即便是1对1的通信，在多线程环境下，如果多个读数据的请求发出去了，回复过来的数据也可能是杂乱无章的，1个请求的答复被分成多个应答报文，这些应答报文的顺序也可能是乱的，怎么组合？
:
☆─────────────────────────────────────☆
hengcuiyuan (远航) 于 (Wed Oct 19 07:42:34 2022) 提到:
我用网络数据包侦测软件查看的时候，发现有的时候在应用层，第一次回复的数据长度短了，被放到了第二次答复里面去了，类似于沾包，而且如果两次数据请求的时间特别短，链路就堵塞了，客户端会关闭网络端口不再响应。是不是可以让两次通信的时间足够长，就可以规避这个问题？我把两次数据请求的时间间隔提到200ms就很少出现问题，但是实时性就差很多了，而且也不是可以确保每次都通信正常，偶尔有问题。
【 在 z16166 的大作中提到: 】
: 这是OS的网络栈干的事情，从应用层到内核层。
: 1、收到的每个数据包有dst ip、dst port，根据ip/port可以反查到对应的socket，而socket句柄归哪个进程持有，OS是知道的。
: 2、通过socket出去的每个数据包有dst ip、dst port，OS的路由层根据系统的路由设定知道从哪个网卡接口把包发出去。
: ...................
☆─────────────────────────────────────☆
JulyClyde (我的月份又来了) 于 (Wed Oct 19 08:56:54 2022) 提到:
首先，tcp没有“报文”，tcp是“流”
其次，udp乱就乱了，本来就不保证顺序，乱了活该
【 在 hengcuiyuan 的大作中提到: 】
: 即便是1对1的通信，在多线程环境下，如果多个读数据的请求发出去了，回复过来的数据也可能是杂乱无章的，1个请求的答复被分成多个应答报文，这些应答报文的顺序也可能是乱的，怎么组合？
☆─────────────────────────────────────☆
JulyClyde (我的月份又来了) 于 (Wed Oct 19 08:57:27 2022) 提到:
粘包是一种编程错误
tcp是流！！！流！！！
【 在 hengcuiyuan 的大作中提到: 】
: 我用网络数据包侦测软件查看的时候，发现有的时候在应用层，第一次回复的数据长度短了，被放到了第二次答复里面去了，类似于沾包，而且如果两次数据请求的时间特别短，链路就堵塞了，客户端会关闭网络端口不再响应。是不是可以让两次通信的时间足够长，就可以规避这个问题？
: 野蚜酱问萸肭蟮氖奔浼涓籼岬200ms就很少出现问题，但是实时性就差很多了，而且也不是可以确保每次都通信正常，偶尔有问题。
☆─────────────────────────────────────☆
e729 (Dreamroom) 于 (Wed Oct 19 09:56:32 2022) 提到:
你究竟是要问多线程还是多进程啊？
【 在 hengcuiyuan 的大作中提到: 】
: 问一个初级问题：socket在多线程的环境下，是怎么区分哪个数据包是给哪个进程的？或者说，从网络上到来的杂乱无章的数据包，这些数据包是怎么重新组合成一个完整的应答报文的？
☆─────────────────────────────────────☆
z16166 (Netguy) 于 (Wed Oct 19 10:00:04 2022) 提到:
所以你问了半天，其实是绕了个大圈子，就好比我被苹果砸了一下头，我要问这个宇宙是怎么运转的、牛顿和爱因斯坦的理论能不能给我讲清楚，但其实你要解决的就是怎么避免被苹果砸头，哈哈
不如直接把你的问题摆出来描述清楚让人帮忙分析就行了
【 在 hengcuiyuan 的大作中提到: 】
: 我用网络数据包侦测软件查看的时候，发现有的时候在应用层，第一次回复的数据长度短了，被放到了第二次答复里面去了，类似于沾包，而且如果两次数据请求的时间特别短，链路就堵塞了，客户端会关闭网络端口不再响应。是不是可以让两次通信的时间足够长，就可以规避这个问题？我把两次数据请求的时间间隔提到200ms就很少出现问题，但是实时性就差很多了，而且也不是可以确保每次都通信正常，偶尔有问题。
:
☆─────────────────────────────────────☆
cybereagle (2/3的沉默@XMUCSD) 于 (Wed Oct 19 10:07:49 2022) 提到:
你自己如果多个线程复用了同一个连接那你就应该自己分配返回的数据
操作系统是不会知道你应用层数据应该怎么处理的
【 在 hengcuiyuan 的大作中提到: 】
: 即便是1对1的通信，在多线程环境下，如果多个读数据的请求发出去了，回复过来的数据也可能是杂乱无章的，1个请求的答复被分成多个应答报文，这些应答报文的顺序也可能是乱的，怎么组合？
☆─────────────────────────────────────☆
dormouseBHU (dormouseBHU) 于 (Wed Oct 19 11:03:11 2022) 提到:
socket就不应该多个线程去读。一个线程负责读，解析出内容，发送给对应的工作线程去处理。
【 在 hengcuiyuan 的大作中提到: 】
: 问一个初级问题：socket在多线程的环境下，是怎么区分哪个数据包是给哪个进程的？或者说，从网络上到来的杂乱无章的数据包，这些数据包是怎么重新组合成一个完整的应答报文的？
☆─────────────────────────────────────☆
wenzhongzi (没人比我更懂灌水！) 于 (Wed Oct 19 12:54:31 2022) 提到:
port与进程是绑定的
【 在 hengcuiyuan 的大作中提到: 】
:
: 问一个初级问题：socket在多线程的环境下，是怎么区分哪个数据包是给哪个进程的？或者说，从网络上到来的杂乱无章的数据包，这些数据包是怎么重新组合成一个完整的应答报文的？
#发自zSMTH@PBAM00
☆─────────────────────────────────────☆
hgoldfish (老鱼) 于 (Wed Oct 19 13:02:58 2022) 提到:
是的。正解。socket 可以一个线程写，一个线程读。本身也是线程安全的。
但是多线程读的时候，会出现一部分数据给这个线程，另一部分数据给另一个线程。这种情况一般不符合现实场景。
【 在 dormouseBHU 的大作中提到: 】
: socket就不应该多个线程去读。一个线程负责读，解析出内容，发送给对应的工作线程去处理。
☆─────────────────────────────────────☆
deadlylight (黑洞中的量子) 于 (Wed Oct 19 15:04:19 2022) 提到:
12楼正解，应该把io thread和worker thread分开。
收包流程，read thread会不停的调recv，收到一个完整的包之后创建一个request，push request queue里去，然后worker thread会pop request queue去处理。
发包流程，当一个worker thread处理好了request产生了response，就会push到response queue里去，然后write thread会pop response queue去send。
每个request和response里，都包含了data和fd信息，所以send的时候就知道对应的fd是哪个。
☆─────────────────────────────────────☆
yytree (yytree) 于 (Wed Oct 19 16:46:54 2022) 提到:
看源码啊
推荐看lwip源码
MAC层收到物理包
IP层根据四元组路由到不同socket队列
乱序的TCP包收到后重新排序拼接，里面有序号的，一次拼接成一个大包，一次应答这个大包的字节数
看源码太清楚了
自己读吧，这个协议栈比较小，好读，socket，多线程，拼接包，路由到对应线程......你想知道的细节全都有
协议栈源码：
[upload=1][/upload]
【 在 hengcuiyuan 的大作中提到: 】
: 问一个初级问题：socket在多线程的环境下，是怎么区分哪个数据包是给哪个进程的？或者说，从网络上到来的杂乱无章的数据包，这些数据包是怎么重新组合成一个完整的应答报文的？
☆─────────────────────────────────────☆
hengcuiyuan (远航) 于 (Wed Oct 19 17:54:15 2022) 提到:
我现在用的就是TCP，怎么处理粘包问题
【 在 JulyClyde 的大作中提到: 】
: 粘包是一种编程错误
: tcp是流！！！流！！！
☆─────────────────────────────────────☆
hengcuiyuan (远航) 于 (Wed Oct 19 17:58:06 2022) 提到:
多谢，抽空研究一下
【 在 yytree 的大作中提到: 】
: 看源码啊
: 推荐看lwip源码
: MAC层收到物理包
: ...................
☆─────────────────────────────────────☆
cybereagle (2/3的沉默@XMUCSD) 于 (Wed Oct 19 18:04:10 2022) 提到:
不存在这个问题
TCP粘包是生造出来的概念
你有一个字节流
你可以 read(fd)
每次read到的东西大小没有保证，跟另一端怎么 send 没有关系
仅此而已
协议层不会管你业务上每段数据从哪到哪
你自己定义协议去识别
【 在 hengcuiyuan 的大作中提到: 】
: 我现在用的就是TCP，怎么处理粘包问题
☆─────────────────────────────────────☆
hengcuiyuan (远航) 于 (Wed Oct 19 18:08:11 2022) 提到:
对的，如果应用层协议里面有序列号，是容易处理这个问题的，但是我用的协议是别人定义的，如附件所示。它的应用层数据里面是没有报文的标识的，我头大的就是这里，如果把收到的数据胡乱的塞进一个队列里面，我可以按照头部标识来区分一个完整的报文，但是我不知道这个报文是给哪一次请求的答复。
【 在 deadlylight 的大作中提到: 】
: 12楼正解，应该把io thread和worker thread分开。
: 收包流程，read thread会不停的调recv，收到一个完整的包之后创建一个request，push request queue里去，然后worker thread会pop request queue去处理。
: 发包流程，当一个worker thread处理好了request产生了response，就会push到response queue里去，然后write thread会pop response queue去send。
: ...................
[upload=1][/upload][upload=2][/upload]
☆─────────────────────────────────────☆
hengcuiyuan (远航) 于 (Wed Oct 19 18:10:08 2022) 提到:
这样我理解您说的TCP是流，这个概念的意思了
【 在 cybereagle 的大作中提到: 】
: 不存在这个问题
: TCP粘包是生造出来的概念
: 你有一个字节流
: ...................
☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Wed Oct 19 18:11:10 2022) 提到:
那就开多个socket，答复之前此socket不发新的请求。http就是这样。
【 在 hengcuiyuan 的大作中提到: 】
: 对的，如果应用层协议里面有序列号，是容易处理这个问题的，但是我用的协议是别人定义的，如附件所示。它的应用层数据里面是没有报文的标识的，我头大的就是这里，如果把收到的数据胡乱的塞进一个队列里面，我可以按照头部标识来区分一个完整的报文，但是我不知道这个报文是
: 囊淮吻肭蟮拇鸶础
: [upload=1][/upload][upload=2][/upload]
: ...................
☆─────────────────────────────────────☆
z16166 (Netguy) 于 (Wed Oct 19 18:25:07 2022) 提到:
TCP一般就是靠里面的长度字节来决定收到的数据是否完整了，没收完整，就一直收。
你这个协议里面看着是有个长度字段的。
一般限制长度的最大值，防止被人耗尽资源或者导致死等。
【 在 hengcuiyuan 的大作中提到: 】
: 对的，如果应用层协议里面有序列号，是容易处理这个问题的，但是我用的协议是别人定义的，如附件所示。它的应用层数据里面是没有报文的标识的，我头大的就是这里，如果把收到的数据胡乱的塞进一个队列里面，我可以按照头部标识来区分一个完整的报文，但是我不知道这个报文是给哪一次请求的答复。
:
: [upload=1][/upload][upload=2][/upload]
☆─────────────────────────────────────☆
hengcuiyuan (远航) 于 (Wed Oct 19 18:26:39 2022) 提到:
噢，还可以这么操作的吗？我就是很奇怪，这个协议是三菱设计的，我一直纳闷他们怎么搞这么奇葩的协议。感谢感谢！
【 在 canper 的大作中提到: 】
: 那就开多个socket，答复之前此socket不发新的请求。http就是这样。
☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Wed Oct 19 19:15:59 2022) 提到:
正常啊，就是把协议设计成socket是线程独占的，需要并发多个请求就开多个socket呗。大部分能即时返回结果的协议都是这样，http，ftp等等。
【 在 hengcuiyuan 的大作中提到: 】
: 噢，还可以这么操作的吗？我就是很奇怪，这个协议是三菱设计的，我一直纳闷他们怎么搞这么奇葩的协议。感谢感谢！
☆─────────────────────────────────────☆
colorado (rockymt) 于 (Wed Oct 19 21:04:32 2022) 提到:
每个socket在整个操作系统中都是唯一的，这是操作系统内核通过端口号，协议，IP地址来保证的；在多线程环境下，对一个socket操作，也就是对一个全局变量同步的问题；至于多进程操作同一个socket，那是不可能发生的，如果一个端口号被其他进程的socket使用了，其他进程还想用这个端口号去创建socket，会返回错误，此端口号已被占用。
【 在 hengcuiyuan 的大作中提到: 】
: 问一个初级问题：socket在多线程的环境下，是怎么区分哪个数据包是给哪个进程的？或者说，从网络上到来的杂乱无章的数据包，这些数据包是怎么重新组合成一个完整的应答报文的？
☆─────────────────────────────────────☆
clutch (burnt out!) 于 (Wed Oct 19 22:25:33 2022) 提到:
应用层的问题，在应用层解决。
远端ip：端口不同还好办一些。 相同的话，只能自己写代码解决。
【 在 hengcuiyuan (远航) 的大作中提到: 】
: 问一个初级问题：socket在多线程的环境下，是怎么区分哪个数据包是给哪个进程的？或者说，从网络上到来的杂乱无章的数据包，这些数据包是怎么重新组合成一个完整的应答报文的？
: --
:
:
☆─────────────────────────────────────☆
hengcuiyuan (远航) 于 (Wed Oct 19 23:31:00 2022) 提到:
学习了！
【 在 colorado 的大作中提到: 】
: 每个socket在整个操作系统中都是唯一的，这是操作系统内核通过端口号，协议，IP地址来保证的；在多线程环境下，对一个socket操作，也就是对一个全局变量同步的问题；至于多进程操作同一个socket，那是不可能发生的，如果一个端口号被其他进程的socket使用了，其他进程还想用这个端口号去创建socket，会返回错误，此端口号已被占用。
:
☆─────────────────────────────────────☆
jinggangshan (jinggangshan) 于 (Wed Oct 19 23:42:50 2022) 提到:
标准 reactor模型
【 在 deadlylight 的大作中提到: 】
:12楼正解，应该把io thread和worker thread分开。:收包流程，read thread会不停的调rec
- 来自 水木社区APP v3.5.6
☆─────────────────────────────────────☆
leadu (leadu) 于 (Thu Oct 20 00:55:40 2022) 提到:
你遇到的那个问题国内有一些人叫粘包，不过有些旧时代的老古董喜欢用tcp是流的概念教训新手，他们不喜欢粘包这个名字，认为出现这个名字就是tcp知识不扎实。
但实际上谁说流就不能收发对应的？中间非得别人插个缓存改速才叫流么？
这个问题对于网络协议设计来说很烦人，属于tcp设计失误，导致每个tcp上的协议都得再设计一个长度表示。
新的主流协议比如quic都抛弃网络拆包流这种设计的了
好像ipv6也把网络拆包扔了，不过这个需要核实，我记不清了。
多年以后基本不会再有你这个问题了
【 在 hengcuiyuan 的大作中提到: 】
: 这样我理解您说的TCP是流，这个概念的意思了
:
☆─────────────────────────────────────☆
jfgao (小高) 于 (Thu Oct 20 08:21:30 2022) 提到:
【 在 hengcuiyuan 的大作中提到: 】
: 真的吗？
应该是笔误，socket不能是多进程，socket可以是多线程。
楼主的问题是在同一个socket读多进程的数据包，显然是不可能的。同一个socket只能读一个进程的数据包，不能读其他进程的数据包。
线程是进程内的一个执行单元。一个socket只能对应一个进程，但可以使用多线程发送和接受数据包，就是楼上网友说的，一个线程发送数据包，一个线程接收数据包。
☆─────────────────────────────────────☆
JulyClyde (我的月份又来了) 于 (Thu Oct 20 08:53:06 2022) 提到:
错
有序列号的前提是你每次读到“一整个”包
但tcp是流，根本没有包的概念，也就不存在所谓一整个的概念
【 在 hengcuiyuan 的大作中提到: 】
: 对的，如果应用层协议里面有序列号，是容易处理这个问题的，但是我用的协议是别人定义的，如附件所示。它的应用层数据里面是没有报文的标识的，我头大的就是这里，如果把收到的数据胡乱的塞进一个队列里面，我可以按照头部标识来区分一个完整的报文，但是我不知道这个报文是
: 囊淮吻肭蟮拇鸶础
: [upload=1][/upload][upload=2][/upload]
: ...................
☆─────────────────────────────────────☆
JulyClyde (我的月份又来了) 于 (Thu Oct 20 08:54:56 2022) 提到:
【 在 leadu 的大作中提到: 】
: 你遇到的那个问题国内有一些人叫粘包，不过有些旧时代的老古董喜欢用tcp是流的概念教训新手，他们不喜欢粘包这个名字，认为出现这个名字就是tcp知识不扎实。
: 但实际上谁说流就不能收发对应的？中间非得别人插个缓存改速才叫流么？
: 这个问题对于网络协议设计来说很烦人，属于tcp设计失误，导致每个tcp上的协议都得再设计一个长度表示。
你也知道是tcp之上需要加长度啊，而不是tcp本身需要加长度
: 新的主流协议比如quic都抛弃网络拆包流这种设计的了
quic是udp的吧，根本就没有流
: 好像ipv6也把网络拆包扔了，不过这个需要核实，我记不清了。
IPv6是网络层吧，根本就没有流
: 多年以后基本不会再有你这个问题了
多年以前你网络课考及格吗？
☆─────────────────────────────────────☆
bihai (new half life) 于 (Thu Oct 20 11:49:30 2022) 提到:
7-8年前吧，用asio实现了一个自定义的协议，传送json, 为了简单起见，最后加上一个ascii 127表示结束，要不然程序写起来麻烦，得处理{}的匹配才知道结束了。有了结束符，我可以简单告诉asio的一个函数等待这个字符就结束。
【 在 leadu 的大作中提到: 】
: 你遇到的那个问题国内有一些人叫粘包，不过有些旧时代的老古董喜欢用tcp是流的概念教训新手，他们不喜欢粘包这个名字，认为出现这个名字就是tcp知识不扎实。
: 但实际上谁说流就不能收发对应的？中间非得别人插个缓存改速才叫流么？
: 这个问题对于网络协议设计来说很烦人，属于tcp设计失误，导致每个tcp上的协议都得再设计一个长度表示。
: ...................
☆─────────────────────────────────────☆
iMx (围城) 于 (Thu Oct 20 12:11:26 2022) 提到:
unicode的话，中间可能有ascii 127
【 在 bihai 的大作中提到: 】
: 7-8年前吧，用asio实现了一个自定义的协议，传送json, 为了简单起见，最后加上一个ascii 127表示结束，要不然程序写起来麻烦，得处理{}的匹配才知道结束了。有了结束符，我可以简单告诉asio的一个函数等待这个字符就结束。
☆─────────────────────────────────────☆
hgoldfish (老鱼) 于 (Thu Oct 20 12:43:37 2022) 提到:
不应该在最前面加四个字节头表示长度？加后面很奇怪，需要不断判断。
【 在 bihai 的大作中提到: 】
: 7-8年前吧，用asio实现了一个自定义的协议，传送json, 为了简单起见，最后加上一个ascii 127表示结束，要不然程序写起来麻烦，得处理{}的匹配才知道结束了。有了结束符，我可以简单告诉asio的一个函数等待这个字符就结束。
☆─────────────────────────────────────☆
adamhj (淘气阿丹) 于 (Thu Oct 20 13:52:48 2022) 提到:
现实里基于特定符号的流协议也有很多啊，比如http里chunked的encoding，前面加长度还是后面加符号主要是更具具体需求场景定的
【 在 hgoldfish 的大作中提到: 】
: 不应该在最前面加四个字节头表示长度？加后面很奇怪，需要不断判断。
☆─────────────────────────────────────☆
adamhj (淘气阿丹) 于 (Thu Oct 20 13:55:02 2022) 提到:
你但凡知道TCP/IP层设计上为什么会出现重分包这种场景就不会产生这种理解，还设计失误都出来了
【 在 leadu 的大作中提到: 】
: 你遇到的那个问题国内有一些人叫粘包，不过有些旧时代的老古董喜欢用tcp是流的概念教训新手，他们不喜欢粘包这个名字，认为出现这个名字就是tcp知识不扎实。
: 但实际上谁说流就不能收发对应的？中间非得别人插个缓存改速才叫流么？
: 这个问题对于网络协议设计来说很烦人，属于tcp设计失误，导致每个tcp上的协议都得再设计一个长度表示。
: ...................
☆─────────────────────────────────────☆
JulyClyde (我的月份又来了) 于 (Thu Oct 20 14:28:04 2022) 提到:
chunked encoding应该是基于预先声明长度的吧
【 在 adamhj 的大作中提到: 】
: 现实里基于特定符号的流协议也有很多啊，比如http里chunked的encoding，前面加长度还是后面加符号主要是更具具体需求场景定的
☆─────────────────────────────────────☆
adamhj (淘气阿丹) 于 (Thu Oct 20 14:47:30 2022) 提到:
https://en.wikipedia.org/wiki/Chunked_transfer_encoding
Chunked transfer encoding allows a server to maintain an HTTP persistent connection for dynamically generated content. In this case, the HTTP Content-Length header cannot be used to delimit the content and the next HTTP request/response, as the content size is not yet known.
【 在 JulyClyde 的大作中提到: 】
: chunked encoding应该是基于预先声明长度的吧
☆─────────────────────────────────────☆
hgoldfish (老鱼) 于 (Thu Oct 20 14:49:54 2022) 提到:
chunked 那个太恶。。文本加回车。浪费字节。
【 在 adamhj 的大作中提到: 】
: 现实里基于特定符号的流协议也有很多啊，比如http里chunked的encoding，前面加长度还是后面加符号主要是更具具体需求场景定的
☆─────────────────────────────────────☆
adamhj (淘气阿丹) 于 (Thu Oct 20 14:51:10 2022) 提到:
实际看你每个chunk多大决定浪费多不多，http协议那么大一个头不也照用，一个长连接chunk怎么也比拆成一堆http request强吧
【 在 hgoldfish 的大作中提到: 】
: chunked 那个太恶。。文本加回车。浪费字节。
☆─────────────────────────────────────☆
JulyClyde (我的月份又来了) 于 (Thu Oct 20 16:24:32 2022) 提到:
这事吧，我觉得你还是先看看RFC，多学习学习再发言
【 在 adamhj 的大作中提到: 】
: 标 题: Re: socket多线程编程的问题
: 发信站: 水木社区 (Thu Oct 20 14:47:30 2022), 站内
:
:
https://en.wikipedia.org/wiki/Chunked_transfer_encoding: Chunked transfer encoding allows a server to maintain an HTTP persistent connection for dynamically generated content. In this case, the HTTP Content-Length header cannot be used to delimit the content and the next HTTP request/response, as the content si
: ze is not yet known.
:
: 【 在 JulyClyde 的大作中提到: 】
: : chunked encoding应该是基于预先声明长度的吧
:
: --
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 59.63.138.*]
☆─────────────────────────────────────☆
hgoldfish (老鱼) 于 (Thu Oct 20 16:56:17 2022) 提到:
出现 chunked encoding 的时候，既可以有 Content-Length 头，也可以不需要。
所以 chunked encoding 可以作为 websocket 出现前的廉价替代。
django 就是很典型的例子，如果返回 StreamingHttpResponse，此时 HTTP 不发送 Content-Length，程序员可以用 python 的 iterator 慢慢地生成数据发送给客户端。
【 在 JulyClyde 的大作中提到: 】
: chunked encoding应该是基于预先声明长度的吧
☆─────────────────────────────────────☆
hgoldfish (老鱼) 于 (Thu Oct 20 16:56:50 2022) 提到:
阿当发的 wikipedia 没错的啊。
【 在 JulyClyde 的大作中提到: 】
: 这事吧，我觉得你还是先看看RFC，多学习学习再发言
: si
☆─────────────────────────────────────☆
cybereagle (2/3的沉默@XMUCSD) 于 (Thu Oct 20 16:57:43 2022) 提到:
Content-Length 头不适用而已
每个 chunk 是有长度声明的
【 在 adamhj 的大作中提到: 】
:
https://en.wikipedia.org/wiki/Chunked_transfer_encoding: Chunked transfer encoding allows a server to maintain an HTTP persistent connection for dynamically generated content. In this case, the HTTP Content-Length header cannot be used to delimit the content and the next HTTP request/response, as the content si
: ze is not yet known.
: ...................
☆─────────────────────────────────────☆
JulyClyde (我的月份又来了) 于 (Thu Oct 20 16:59:19 2022) 提到:
啊？不能有吧？如果冲突咋办
【 在 hgoldfish 的大作中提到: 】
: 出现 chunked encoding 的时候，既可以有 Content-Length 头，也可以不需要。
: 所以 chunked encoding 可以作为 websocket 出现前的廉价替代。
: django 就是很典型的例子，如果返回 StreamingHttpResponse，此时 HTTP 不发送 Content-Length，程序员可以用 python 的 iterator 慢慢地生成数据发送给客户端。
: ...................
☆─────────────────────────────────────☆
JulyClyde (我的月份又来了) 于 (Thu Oct 20 16:59:36 2022) 提到:
每一个chunk有自己的长度声明
【 在 hgoldfish 的大作中提到: 】
: 阿当发的 wikipedia 没错的啊。
☆─────────────────────────────────────☆
adamhj (淘气阿丹) 于 (Thu Oct 20 17:54:56 2022) 提到:
啊，那是我忘了，举例不对
【 在 cybereagle 的大作中提到: 】
: Content-Length 头不适用而已
: 每个 chunk 是有长度声明的
: si
: ...................
☆─────────────────────────────────────☆
hgoldfish (老鱼) 于 (Thu Oct 20 18:46:21 2022) 提到:
可以有啊。但是要求一致。如果不一致的话。。按说是以 content-length 为准——我的 http client 是这么实现的，反正看客户端怎么搞。
【 在 JulyClyde 的大作中提到: 】
: 啊？不能有吧？如果冲突咋办
☆─────────────────────────────────────☆
bihai (new half life) 于 (Fri Oct 21 08:13:32 2022) 提到:
不需要不断判断，asio这样用
class TCP_Session : public std::enable_shared_from_this<TCP_Session> {
static const char EndChar = 0x7F;
void start_read() {
// Set a deadline for the read operation.
input_deadline_.expires_from_now(readTimeout_); // std::chrono::seconds(30)
// Start an asynchronous operation to read a newline-delimited message.
asio::async_read_until(
socket_, input_buffer_, EndChar,
std::bind(&TCP_Session::handle_read, shared_from_this(), std::placeholders::_1));
}
void handle_read(const asio::error_code& ec){
...
if (!ec) {
...
start_read();
} ...
}
【 在 hgoldfish 的大作中提到: 】
: 不应该在最前面加四个字节头表示长度？加后面很奇怪，需要不断判断。
:
☆─────────────────────────────────────☆
bihai (new half life) 于 (Fri Oct 21 08:26:02 2022) 提到:
utf-8
【 在 iMx 的大作中提到: 】
: unicode的话，中间可能有ascii 127
:
☆─────────────────────────────────────☆
JulyClyde (我的月份又来了) 于 (Fri Oct 21 08:50:00 2022) 提到:
4.4 Message Length
3.If a Content-Length header field (section 14.13) is present, its
decimal value in OCTETs represents both the entity-length and the
transfer-length. The Content-Length header field MUST NOT be sent
if these two lengths are different (i.e., if a Transfer-Encoding
header field is present). If a message is received with both a
Transfer-Encoding header field and a Content-Length header field,
the latter MUST be ignored.
你这客户端不合规
【 在 hgoldfish 的大作中提到: 】
: 可以有啊。但是要求一致。如果不一致的话。。按说是以 content-length 为准——我的 http client 是这么实现的，反正看客户端怎么搞。
☆─────────────────────────────────────☆
qlogic (戒网了) 于 (Fri Oct 21 10:30:32 2022) 提到:
sctp了解一下 stream control transmissiion protocol
【 在 JulyClyde 的大作中提到: 】
: 你也知道是tcp之上需要加长度啊，而不是tcp本身需要加长度
: quic是udp的吧，根本就没有流
: IPv6是网络层吧，根本就没有流
: ...................
☆─────────────────────────────────────☆
z16166 (Netguy) 于 (Fri Oct 21 12:21:46 2022) 提到:
这是asio内部帮你不断判断定界符了
切分数据包，无非就是长度、定界符两个办法
【 在 bihai 的大作中提到: 】
: 不需要不断判断，asio这样用
: class TCP_Session : public std::enable_shared_from_this<TCP_Session> {
: static const char EndChar = 0x7F;
: ...................
☆─────────────────────────────────────☆
bihai (new half life) 于 (Fri Oct 21 12:24:52 2022) 提到:
长度不也得内部循环判断吗
【 在 z16166 的大作中提到: 】
: 这是asio内部帮你不断判断定界符了
: 切分数据包，无非就是长度、定界符两个办法
:
☆─────────────────────────────────────☆
z16166 (Netguy) 于 (Fri Oct 21 12:55:48 2022) 提到:
我没否认这个啊
【 在 bihai 的大作中提到: 】
: 长度不也得内部循环判断吗
:
☆─────────────────────────────────────☆
hgoldfish (老鱼) 于 (Fri Oct 21 14:10:53 2022) 提到:
这样啊。。那看来是我弄错了。
【 在 JulyClyde 的大作中提到: 】
: 4.4 Message Length
: 3.If a Content-Length header field (section 14.13) is present, its
: decimal value in OCTETs represents both the entity-length and the
: ...................
☆─────────────────────────────────────☆
hgoldfish (老鱼) 于 (Fri Oct 21 14:11:19 2022) 提到:
asio::async_read_until() 内部肯定是读一下，判断一下啊。
【 在 bihai 的大作中提到: 】
: 不需要不断判断，asio这样用
: class TCP_Session : public std::enable_shared_from_this<TCP_Session> {
: static const char EndChar = 0x7F;
: ...................
☆─────────────────────────────────────☆
JulyClyde (我的月份又来了) 于 (Fri Oct 21 14:12:38 2022) 提到:
这个我不懂……
【 在 qlogic 的大作中提到: 】
: sctp了解一下 stream control transmissiion protocol
☆─────────────────────────────────────☆
leadu (leadu) 于 (Fri Oct 21 14:31:39 2022) 提到:
这缺陷是公认的，随便一搜
https://www.rfwireless-world.com/Terminology/Advantages-and-Disadvantages-of-TCP-IP.htmlhttps://www.tutorialspoint.com/Advantages-and-Disadvantages-of-the-TCP-IP-Model
手写二进制协议比较多的话，每次都需要从代码和内存上处理一下这个问题，添麻烦。
反正各大公司都在从数据中心和互联网上去tcp，这玩意也撑不了多少年了。
简中互联网每次讨论起tcp粘包拆包的时候，总让人有种猴子高压水枪实验的既视感：
奥地利维也纳大学进化生物学家William Tecumseh Sherman Fitch III主导了一场实验：把5只猴子关进一个挂有香蕉的笼子里，所有猴子蠢蠢欲动，其中一只伸手去拿了香蕉，结果高压水枪惩罚了所有五只猴子，最后没有一只敢去动香蕉。后来，科学家把其中一只拿走，换成了对这个规则毫不知情的猴子A，A想要去拿香蕉，但是其他四只猴子把它狠狠的K了一顿，结果它老实了，又过了一段时间，A以外的另一只猴子被换成了不知道规则的B，B想要伸手去够香蕉，被其他四只猴子海扁了一顿，A打的最凶，接着猴子们被一一换掉，所有的猴子都不是当初被高压水枪惩罚的猴子了，但是却没有猴子再敢触碰香蕉。
【 在 JulyClyde 的大作中提到: 】
: 你也知道是tcp之上需要加长度啊，而不是tcp本身需要加长度
: quic是udp的吧，根本就没有流
: IPv6是网络层吧，根本就没有流
: ...................
☆─────────────────────────────────────☆
adamhj (淘气阿丹) 于 (Fri Oct 21 14:37:03 2022) 提到:
缺点和缺陷是两个概念
你一个玻璃杯子不保温这叫缺点
你一个玻璃杯子底下破了个洞漏水这叫缺陷
【 在 leadu 的大作中提到: 】
: 这缺陷是公认的，随便一搜
https://www.rfwireless-world.com/Terminology/Advantages-and-Disadvantages-of-TCP-IP.html:
https://www.tutorialspoint.com/Advantages-and-Disadvantages-of-the-TCP-IP-Model: 手写二进制协议比较多的话，每次都需要从代码和内存上处理一下这个问题，添麻烦。
: ...................
☆─────────────────────────────────────☆
leadu (leadu) 于 (Fri Oct 21 14:42:13 2022) 提到:
本来不想回复你，段位差太多讨论不起来的
连http chunk开始是长度，自己贴个文档（
https://en.wikipedia.org/wiki/Chunked_transfer_encoding）都不带看完的大哥，那来的底气和别人讨论协议设计
【 在 adamhj 的大作中提到: 】
: 缺点和缺陷是两个概念
: 你一个玻璃杯子不保温这叫缺点
: 你一个玻璃杯子底下破了个洞漏水这叫缺陷
: ...................
☆─────────────────────────────────────☆
leadu (leadu) 于 (Fri Oct 21 14:46:16 2022) 提到:
你读一下呗，主协议rfc4960，没有几页
美国电话网的的协议
【 在 JulyClyde 的大作中提到: 】
: 这个我不懂……
☆─────────────────────────────────────☆
PaoloMaldini (solo con te) 于 (Fri Oct 21 14:52:07 2022) 提到:
啥叫哪个数据包是给哪个进程的？
你得讲明白问题
【 在 hengcuiyuan 的大作中提到: 】
: 标 题: socket多线程编程的问题
: 发信站: 水木社区 (Tue Oct 18 21:34:08 2022), 站内
:
: 问一个初级问题：socket在多线程的环境下，是怎么区分哪个数据包是给哪个进程的？或者说，从网络上到来的杂乱无章的数据包，这些数据包是怎么重新组合成一个完整的应答报文的？
: --
:
: ※ 来源:·水木社区
http://www.mysmth.net·[FROM: 113.69.195.*]
☆─────────────────────────────────────☆
PaoloMaldini (solo con te) 于 (Fri Oct 21 14:53:27 2022) 提到:
先理解TCP是流，没有包
【 在 hengcuiyuan 的大作中提到: 】
: 我现在用的就是TCP，怎么处理粘包问题
☆─────────────────────────────────────☆
JulyClyde (我的月份又来了) 于 (Fri Oct 21 14:55:53 2022) 提到:
主要是我没实际用过sctp
单看文档没办法对照实际产品去理解
【 在 leadu 的大作中提到: 】
: 你读一下呗，主协议rfc4960，没有几页
: 美国电话网的的协议
☆─────────────────────────────────────☆
leadu (leadu) 于 (Fri Oct 21 15:04:10 2022) 提到:
sctp协议设计的不错，当年有人建议取代tcp的，可惜败给了惯性。
quic作者特意提到和sctp的比较，并说参考了sctp的实现。
这个协议差不多20年了吧
另外国内电话网现在是啥协议？美国那边换了sctp，中国这边自己搞了一个新的么？
【 在 JulyClyde 的大作中提到: 】
: 主要是我没实际用过sctp
: 单看文档没办法对照实际产品去理解
☆─────────────────────────────────────☆
JulyClyde (我的月份又来了) 于 (Fri Oct 21 15:18:29 2022) 提到:
国内电话用SIP吧？
之前听说还有些H.323但是后来都弃用了
【 在 leadu 的大作中提到: 】
: sctp协议设计的不错，当年有人建议取代tcp的，可惜败给了惯性。
: quic作者特意提到和sctp的比较，并说参考了sctp的实现。
: 这个协议差不多20年了吧
: 另外国内电话网现在是啥协议？美国那边换了sctp，中国这边自己搞了一个新的么？
☆─────────────────────────────────────☆
hgoldfish (老鱼) 于 (Fri Oct 21 16:37:18 2022) 提到:
话说这么讲。但实际工作中，又需要把流切成一个个的包。
TCP 的几个特性：顺序、拥塞控制、差错检测，有时候我们只需要拥塞控制、差错检测两个特性就够了。目前貌似没有一个协议是满足的。
【 在 PaoloMaldini 的大作中提到: 】
: 先理解TCP是流，没有包
☆─────────────────────────────────────☆
adoal (阿豆) 于 (Fri Oct 21 16:38:17 2022) 提到:
那就是业务层协议设计了
【 在 hgoldfish 的大作中提到: 】
: 话说这么讲。但实际工作中，又需要把流切成一个个的包。
☆─────────────────────────────────────☆
qlogic (戒网了) 于 (Fri Oct 21 16:38:49 2022) 提到:
说粘包没错，但是总有人拿stream来装13
【 在 hgoldfish 的大作中提到: 】
: 话说这么讲。但实际工作中，又需要把流切成一个个的包。
☆─────────────────────────────────────☆
cybereagle (2/3的沉默@XMUCSD) 于 (Fri Oct 21 16:54:03 2022) 提到:
其实是应用中需要一个报文的概念
然后字节顺序必须要有
但是报文间的顺序在多路复用的时候你不关心
当年设计的时候可能觉得中间还有两层能再加点协议干这事
结果应用层直接拿TCP撸自然就显得有点不好使
至于谈什么粘包的都是把应用逻辑的报文和TCP传输的数据包混为一谈了
【 在 hgoldfish 的大作中提到: 】
: 话说这么讲。但实际工作中，又需要把流切成一个个的包。
: TCP 的几个特性：顺序、拥塞控制、差错检测，有时候我们只需要拥塞控制、差错检测两个特性就够了。目前貌似没有一个协议是满足的。
☆─────────────────────────────────────☆
PaoloMaldini (solo con te) 于 (Fri Oct 21 16:54:31 2022) 提到:
切包是上层协议，那就不是TCP的事儿了
【 在 hgoldfish 的大作中提到: 】
: 话说这么讲。但实际工作中，又需要把流切成一个个的包。
: TCP 的几个特性：顺序、拥塞控制、差错检测，有时候我们只需要拥塞控制、差错检测两个特性就够了。目前貌似没有一个协议是满足的。
☆─────────────────────────────────────☆
PaoloMaldini (solo con te) 于 (Fri Oct 21 16:55:29 2022) 提到:
发现不理解协议分层的人还挺多
【 在 qlogic 的大作中提到: 】
: 说粘包没错，但是总有人拿stream来装13
☆─────────────────────────────────────☆
qlogic (戒网了) 于 (Fri Oct 21 17:01:53 2022) 提到:
粘包是现象，你发两个4字节的包，结果一次read 6个字节，一次2个字节
这就是粘包，没错吧
【 在 PaoloMaldini 的大作中提到: 】
: 发现不理解协议分层的人还挺多
☆─────────────────────────────────────☆
hgoldfish (老鱼) 于 (Fri Oct 21 17:10:49 2022) 提到:
上层协议有些不需要顺序性啊。比如 bt 节点向其它节点发送文件块时。
但 tcp 强制了顺序性。此时就尴尬了。因为流要保证顺序性，有一个块出差错后面所有的块都没法提交给应用层。
【 在 PaoloMaldini 的大作中提到: 】
: 切包是上层协议，那就不是TCP的事儿了
☆─────────────────────────────────────☆
DreamDreams (光风霁月) 于 (Fri Oct 21 17:22:05 2022) 提到:
不要顺序的，用udp+重传不就行了，为啥用tcp呀
【 在 hgoldfish 的大作中提到: 】
: 标 题: Re: socket多线程编程的问题
: 发信站: 水木社区 (Fri Oct 21 17:10:49 2022), 站内
:
: 上层协议有些不需要顺序性啊。比如 bt 节点向其它节点发送文件块时。
:
: 但 tcp 强制了顺序性。此时就尴尬了。因为流要保证顺序性，有一个块出差错后面所有的块都没法提交给应用层。
:
: 【 在 PaoloMaldini 的大作中提到: 】
: : 切包是上层协议，那就不是TCP的事儿了
:
: --
: 灭绝人性啊
:
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 120.33.8.*]
☆─────────────────────────────────────☆
adamhj (淘气阿丹) 于 (Fri Oct 21 17:56:36 2022) 提到:
我是没看完，前面老鱼说分隔符标志结尾的协议，我就想起来了chunked encoding是个不定长的流协议就提了一嘴，当然确实协议的细节和我的记忆有偏差是我不仔细
然后虽然每个chunk之前会发个长度，但是实际上那行长度也是个不定长串，识别这行长度还是靠分隔符来进行的，发长度也只是为了让这个chunk里可以有\r\n而不需要转义
你要说随便提一嘴的话里面存在疏漏是段位问题，那我还奇怪你前面讲传输层协议的时候为什么会把ipv6带进来呢，ipv6上跑的不也是tcp和udp？
无论你上层协议怎么搞，链路层上分包的需求是客观存在的，你最多把应用层的一些实现下移到传输层实现，但是这也不现实，这么多在网设备认的都是tcp/udp，你想搞个新的传输层协议一堆设备直接不兼容，搞个毛线？quic为什么是基于udp而不是直接基于ip？
tcp的设计本来就是给你个最基本的保证数据顺序可靠的中间层，udp则是给你觉得tcp束手束脚的时候能让你自由发挥的另外一个更接近链路层的替代品，你想用tcp就用tcp，觉得tcp不够好就去拿udp自己轮去，有什么问题？为什么要分层，不就是要给你上下层隔离么？自己非要用tcp又发明个粘包的概念还自以为是的说tcp这不好那不好，说明你一开始就没搞懂别人为什么要这么设计，你的段位还停留在具体实现上
【 在 leadu 的大作中提到: 】
: 本来不想回复你，段位差太多讨论不起来的
: 连http chunk开始是长度，自己贴个文档（
https://en.wikipedia.org/wiki/Chunked_transfer_encoding）都不带看完的大哥，那来的底气和别人讨论协议设计
☆─────────────────────────────────────☆
a0123456789q (a0123456789q) 于 (Fri Oct 21 18:12:25 2022) 提到:
UDP?
【 在 hgoldfish 的大作中提到: 】
: 话说这么讲。但实际工作中，又需要把流切成一个个的包。
: TCP 的几个特性：顺序、拥塞控制、差错检测，有时候我们只需要拥塞控制、差错检测两个特性就够了。目前貌似没有一个协议是满足的。
:
☆─────────────────────────────────────☆
hgoldfish (老鱼) 于 (Fri Oct 21 18:14:36 2022) 提到:
UDP 没有拥塞控制啊。狂发 UDP 会丢包。
【 在 DreamDreams 的大作中提到: 】
: 不要顺序的，用udp+重传不就行了，为啥用tcp呀
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Fri Oct 21 20:23:45 2022) 提到:
sctp
【 在 hgoldfish 的大作中提到: 】
: 话说这么讲。但实际工作中，又需要把流切成一个个的包。
: TCP 的几个特性：顺序、拥塞控制、差错检测，有时候我们只需要拥塞控制、差错检测
: 两个特性就够了。目前貌似没有一个协议是满足的。
☆─────────────────────────────────────☆
wallyz (哦) 于 (Fri Oct 21 20:58:10 2022) 提到:
看来你真不懂，但是你好像很喜欢批别人
TCP的粘包本质上是Nagle算法，为了让链路的利用率更高，而不至于被一帮袖珍负载拖着大包头充斥，不知道什么人创造了粘包这种称呼，这个称呼本质上就是不理解TCP的基本理念，也不明白网络各个层的权责
SCTP是电信网络里面应用很广泛的协议，跟美国不美国没关系
中国的M3UA也是得在SCTP上跑，Diameter也极有可能是在SCTP上跑
不过SCTP被互联网抛弃了，所以TCP的拥塞控制算法有好几种，SCTP至今还停留在最初的那一种，当初写进RFC里面的那种，所以SCTP对包的时序和时延的耐受比TCP还脆弱
SCTP设计的时候是挺好的，multi-homing, multi-stream，可惜只有电信行业在用，基本上是养在深闺人未识
今天的QUIC也是多流，也引入了connection-id从而变相实现了multi-homing
但是QUIC的多流和SCTP的多流并不一样，QUIC的流是动态生成动态关闭的，本质上是为了考虑HTTP并发的request，而SCTP的多流是在连接建立阶段就确定的，
多宿也是如此，QUIC的结点可以动态更换地址，比如从5G转换到WIFI，但是SCTP的多宿却是要在INIT里面携带的，虽然连接过程中可以切换path，但是这些path本身的地址都是实现就知道的，而不是后面动态宣告的
【 在 leadu 的大作中提到: 】
: 你读一下呗，主协议rfc4960，没有几页
: 美国电话网的的协议
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sat Oct 22 00:37:18 2022) 提到:
【 在 wallyz 的大作中提到: 】
: 看来你真不懂，但是你好像很喜欢批别人
: TCP的粘包本质上是Nagle算法，为了让链路的利用率更高，而不至于被一帮袖珍负载拖
: 着大包头充斥，不知道什么人创造了粘包这种称呼，这个称呼本质上就是不理解TCP的
: 基
: 本理念，也不明白网络各个层的权责
显然不对，粘包和nagle算法没关系，你开不开启nagle算法，发送两个长度为10字节的包
，可能对端第一次read就只能收到长度8个或者12个字节的数据包。
: SCTP是电信网络里面应用很广泛的协议，跟美国不美国没关系
: ...................
☆─────────────────────────────────────☆
zhangyanfei (理想很丰满) 于 (Sat Oct 22 05:16:21 2022) 提到:
看下《深入理解Linux网络》就知道了
【 在 hengcuiyuan 的大作中提到: 】
: 问一个初级问题：socket在多线程的环境下，是怎么区分哪个数据包是给哪个进程的？或者说，从网络上到来的杂乱无章的数据包，这些数据包是怎么重新组合成一个完整的应答报文的？
: --
:
发自「今日水木 on iPhone 12」
☆─────────────────────────────────────☆
adamhj (淘气阿丹) 于 (Sat Oct 22 08:18:00 2022) 提到:
不能吧？现在常见的OS和网络环境下，发俩10，收到的要么就是俩10，要么是20，什么情况下才会出现8或者12？
【 在 iwannabe 的大作中提到: 】
: 显然不对，粘包和nagle算法没关系，你开不开启nagle算法，发送两个长度为10字节的包
: ，可能对端第一次read就只能收到长度8个或者12个字节的数据包。
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sat Oct 22 09:38:15 2022) 提到:
你觉得协议栈把包这样重组图个啥？或者某种实现或者算法出于什么原因，才会把一个10字节的拆开，先发8字节出去？
【 在 iwannabe 的大作中提到: 】
:
: 显然不对，粘包和nagle算法没关系，你开不开启nagle算法，发送两个长度为10字节的包
: ，可能对端第一次read就只能收到长度8个或者12个字节的数据包。
: ...................
☆─────────────────────────────────────☆
bihai (new half life) 于 (Sat Oct 22 09:39:11 2022) 提到:
是一个字节一个字节吗？那太傻了，而且好像会读入多余的，要自己判断。那还是前面加长度吧。
【 在 hgoldfish 的大作中提到: 】
: asio::async_read_until() 内部肯定是读一下，判断一下啊。
:
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sat Oct 22 09:53:02 2022) 提到:
你大概没有真正用过SCTP，只是道听途说
SCTP第一个字是Stream，如果顺序都没了，谈什么Stream？
实际上，SCTP的拥塞控制算法一直停留在类TCP Reno的阶段，没有人提出改进，造成它对网络扰动的耐受更低，很容易将拥塞窗口减半进入快速重传，从而快速降低传输速率，而窗口的恢复则依赖于MSS和RTT，对于时延长的网络，恢复起来很慢，所以这种情况下SCTP的性能很差。
【 在 iwannabe 的大作中提到: 】
: sctp
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sat Oct 22 10:51:19 2022) 提到:
不是协议栈，是网络传输导致的，tcp不负责server发了10个字节，client就能一次收到
10个字节。写过底层网络协议都知道要在用户端来处理这种
10字节个太极端，换成mtu大小你能理解吗？
这些和neagle协议一毛钱关系没有。
不然你猜为什么标准c接收n个字节要这么写？
while (r < n){
r+=read(xxx);
}
这个在非阻塞模式下处理更麻烦。一般用preactor模式来保证收到n个包再交给worker去
处理。
【 在 wallyz 的大作中提到: 】
: 你觉得协议栈把包这样重组图个啥？或者某种实现或者算法出于什么原因，才会把一个
: 10字节的拆开，先发8字节出去？
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sat Oct 22 10:52:36 2022) 提到:
sctp可以无序传输，你不清楚吗？
SCTP allows for unordered data delivery and since it has multiple streams,
only the one affected is temporarily blocked. As in the diagram below, SCTP
would process the messages in the order they arrived, not waiting for them to
be numerically ordered.
【 在 wallyz 的大作中提到: 】
: 你大概没有真正用过SCTP，只是道听途说
: SCTP第一个字是Stream，如果顺序都没了，谈什么Stream？
: 实际上，SCTP的拥塞控制算法一直停留在类TCP Reno的阶段，没有人提出改进，造成它
: 对网络扰动的耐受更低，很容易将拥塞窗口减半进入快速重传，从而快速降低传输速率
: ，
: 而窗口的恢复则依赖于MSS和RTT，对于时延长的网络，恢复起来很慢，所以这种情况下
: SCTP的性能很差。
: ...................
☆─────────────────────────────────────☆
hgoldfish (老鱼) 于 (Sat Oct 22 10:52:43 2022) 提到:
一般是每次读内核缓冲区里面所有数据到自己的缓冲区，使用字节串匹配算法匹配某个特征。这个开销太大了。
换一种思路，在发送数据前，先固定用 4 个字节发送数据长度。于是用户层就可以申请好缓冲区大小并把地址传到内核，内核直接复制数据，这种 zero-copy 相比前面那种做法省下很多 CPU 时间。
【 在 bihai 的大作中提到: 】
: 是一个字节一个字节吗？那太傻了，而且好像会读入多余的，要自己判断。那还是前面加长度吧。
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sat Oct 22 11:00:58 2022) 提到:
你谈多个流里面的无序，这就是诡辩了，
实际上SCTP一个连接开几个流，在连接建立阶段就得确定好，
对于正常的应用设计，不同的session或者连接，每个都会只常驻一个流，而不会这个消息用这个流，下一个用另外一个流，否则就是自寻烦恼
你能说下，你实际上用SCTP设计过什么应用，或者你见过什么应用，会同一个session跨流乱序传输吗？
1.5.2. Sequenced Delivery within Streams
The term "stream" is used in SCTP to refer to a sequence of user
messages that are to be delivered to the upper-layer protocol in
order with respect to other messages within the same stream. This is
in contrast to its usage in TCP, where it refers to a sequence of
bytes (in this document, a byte is assumed to be 8 bits).
【 在 iwannabe 的大作中提到: 】
: sctp可以无序传输，你不清楚吗？
: SCTP allows for unordered data delivery and since it has multiple streams,
: only the one affected is temporarily blocked. As in the diagram below, SCTP
: ...................
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sat Oct 22 11:02:28 2022) 提到:
首先sctp无序可以实现，一个stream不行就多个stream，对吧
不用自己错了，强行掰直。
【 在 wallyz 的大作中提到: 】
: 你谈多个流里面的无序，这就是诡辩了，
: 实际上SCTP一个连接开几个流，在连接建立阶段就得确定好，
: 对于正常的应用设计，不同的session或者连接，每个都会只常驻一个流，而不会这个
: 消息用这个流，下一个用另外一个流，否则就是自寻烦恼
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sat Oct 22 11:03:39 2022) 提到:
我一开始就提袖珍负载，链路利用率，所以要组装小包，不然每个小包带着个相对尺寸更大的包头，造成包头喧宾夺主，
你谈MTU？你的意思是因为MTU造成把10字节拆成8字节？你是什么链路，MTU只有8个字节？
【 在 iwannabe 的大作中提到: 】
: 不是协议栈，是网络传输导致的，tcp不负责server发了10个字节，client就能一次收到
: 10个字节。写过底层网络协议都知道要在用户端来处理这种
: 10字节个太极端，换成mtu大小你能理解吗？
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sat Oct 22 11:04:28 2022) 提到:
不和你这种人吵架
【 在 iwannabe 的大作中提到: 】
: 首先sctp无序可以实现，一个stream不行就多个stream，对吧
: 不用自己错了，强行掰直。
:
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sat Oct 22 11:06:42 2022) 提到:
我告诉你tcp不保证你发10个字节，客户一次read就能接收到10个字节，这个和neagle算
法
没啥关系，mtu是其中一种情况，其他情况包括网络拥塞，系统负载大
你写过netty，epoll libevent之类的网络程序你就知道了。
【 在 wallyz 的大作中提到: 】
: 我一开始就提袖珍负载，链路利用率，所以要组装小包，不然每个小包带着个相对尺寸
: 更大的包头，造成包头喧宾夺主，
: 你谈MTU？你的意思是因为MTU造成把10字节拆成8字节？你是什么链路，MTU只有8个字
: 节？
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sat Oct 22 11:08:04 2022) 提到:
https://docs.oracle.com/cd/E95619_01/html/esbc_ecz810_configuration/GUID-AB031
B53-8C69-4B73-BBBC-081742853093.htm#GUID-B23CF5FD-B001-4F58-8873-B8BF1C7846BD
给你举一个sctp unorder transmission的一个案例
别想当然。
当年某为linux内核支持sctp的case，我参与过。需要的话，我给你贴邮件来往。
【 在 wallyz 的大作中提到: 】
: 不和你这种人吵架
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sat Oct 22 11:23:44 2022) 提到:
不用用“我告诉你”这种口头禅开头
select, poll, epoll，libev，asio我都正儿八经的写过
sctp也写过，上面我提的sctp的拥塞控制存在的问题也都是实践中遇到的问题
读写次数不保证一致，这是tcp的byte流的体现，
提neagle算法，是为了说所谓沾包这个事情，所谓沾是什么意思？就是沾在一起，沾在一起为什么？为了小包变大包，设置NO_DELAY之后，所谓沾包现象就消失，所以本身neagle是在不违反byte流的前提下，对传输做的优化，我认为这个解释没有问题
【 在 iwannabe 的大作中提到: 】
: 我告诉你tcp不保证你发10个字节，客户一次read就能接收到10个字节，这个neagle算法
: 没啥关系，mtu是其中一种情况，其他情况包括网络拥塞，系统负载大
: 你写过netty，epoll libevent之类的网络程序你就知道了。
: ...................
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sat Oct 22 11:29:28 2022) 提到:
那是你理解能力的问题，网络上说的粘包就是我说的这种情况
有些人认为我发了n个字节的包，客户端只要 read(fd,buf,n)就能读到n个，发现这种很
多情况下读不到n个，或者 head/body/head/body这样的流，居然body不完整，然后就开
始吐槽了。
不管存不存在neagle算法，上述情况都存在。
【 在 wallyz 的大作中提到: 】
: 不用用“我告诉你”这种口头禅开头
: select, poll, epoll，libev，asio我都正儿八经的写过
: sctp也写过，上面我提的sctp的拥塞控制存在的问题也都是实践中遇到的问题
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sat Oct 22 11:29:40 2022) 提到:
贴呗
好像提到内核就显得自己世外高人了似的，只是参与个讨论就不得了？
至于你贴的oracle的例子，它可没说它一个sip dialog里面的消息会用多个流乱序传输
【 在 iwannabe 的大作中提到: 】
:
https://docs.oracle.com/cd/E95619_01/html/esbc_ecz810_configuration/GUID-AB031: B53-8C69-4B73-BBBC-081742853093.htm#GUID-B23CF5FD-B001-4F58-8873-B8BF1C7846BD
: 给你举一个sctp unorder transmission的一个案例
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sat Oct 22 11:32:14 2022) 提到:
反正沾包也是个民间概念，你决定是啥就是啥呗
【 在 iwannabe 的大作中提到: 】
: 那是你理解能力的问题，网络上说的粘包就是我说的这种情况
: 有些人认为我发了n个字节的包，客户端只要 read(fd,buf,n)就能读到n个，发现这种很
: 多情况下读不到n个，或者 head/body/head/body这样的流，居然body不完整，然后就开
: ...................
☆─────────────────────────────────────☆
adamhj (淘气阿丹) 于 (Sat Oct 22 11:35:22 2022) 提到:
nagle算法也是其中的一种情况啊
影响分片的因素无非是nagle算法、链路最小MTU、收发端的缓冲区剩余大小、window剩余大小，还有收端应用层调用socket read的时机
虽然说不能说所谓“粘包”一定是nagle算法造成的，但是说“粘包和nagle算法没关系”也不对啊？
【 在 iwannabe 的大作中提到: 】
: 我告诉你tcp不保证你发10个字节，客户一次read就能接收到10个字节，这个和neagle算
: 法
: 没啥关系，mtu是其中一种情况，其他情况包括网络拥塞，系统负载大
: 你写过netty，epoll libevent之类的网络程序你就知道了。
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sat Oct 22 11:36:10 2022) 提到:
呵呵，一说反例偷偷把范围越缩越小
sctp不支持乱序传输---sctp不支持在一个流乱序传输---没人在一个session里用sctp乱
序传输
sip里的unorder delivery是传输oob数据的，这样你懂了吧。不懂oob去查一下unp。
说讨论是我谦虚，蹬鼻子上脸就没意思了。
【 在 wallyz 的大作中提到: 】
: 贴呗
: 好像提到内核就显得自己世外高人了似的，只是参与个讨论就不得了？
: 至于你贴的oracle的例子，它可没说它一个sip dialog里面的消息会用多个流乱序传输
: ...................
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sat Oct 22 11:36:56 2022) 提到:
TCP的粘包本质上是Nagle算法
【 在 adamhj 的大作中提到: 】
: nagle算法也是其中的一种情况啊
: 影响分片的因素无非是nagle算法、链路最小MTU、收发端的缓冲区剩余大小、window剩
: 余大小，还有收端应用层调用socket read的时机
: 虽然说不能说所谓“粘包”一定是nagle算法造成的，但是说“粘包和nagle算法没关系
: ”也不对啊？
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sat Oct 22 11:39:40 2022) 提到:
我觉得按照你的语气，你还是贴你的所谓的讨论的邮件，才能更见显得你高大上
【 在 iwannabe 的大作中提到: 】
: 呵呵，一说反例偷偷把范围越缩越小
: sctp不支持乱序传输---sctp不支持在一个流乱序传输---没人在一个session里用sctp乱
: 序传输
: ...................
☆─────────────────────────────────────☆
adamhj (淘气阿丹) 于 (Sat Oct 22 11:41:52 2022) 提到:
嗯，他这句也不对
我觉得这个事情其实没必要争太细，本来粘包这种山寨概念也没个具体定义
【 在 iwannabe 的大作中提到: 】
: TCP的粘包本质上是Nagle算法
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sat Oct 22 11:42:17 2022) 提到:
你难道是两个人？
一个批判我说沾包和nagle没关系，一个说沾包本质是nagle算法
这是啥事情？
发信人: iwannabe (I wanna be), 信区: Programming
标 题: Re: socket多线程编程的问题
发信站: 水木社区 (Sat Oct 22 00:37:18 2022), 站内
显然不对，粘包和nagle算法没关系，你开不开启nagle算法，发送两个长度为10字节的包
，可能对端第一次read就只能收到长度8个或者12个字节的数据包。
【 在 iwannabe 的大作中提到: 】
: TCP的粘包本质上是Nagle算法
:
☆─────────────────────────────────────☆
adamhj (淘气阿丹) 于 (Sat Oct 22 11:42:45 2022) 提到:
他那句是引用你说的
【 在 wallyz 的大作中提到: 】
: 你难道是两个人？
: 一个批判我说沾包和nagle没关系，一个说沾包本质是nagle算法
: 这是啥事情？
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sat Oct 22 11:45:23 2022) 提到:
我没觉得这个话有啥问题，因为日常发现所谓沾包的人，都不是因为buffer满，或者对方窗口满，或者部分重传的情况下
而是小包没及时发，和别的包“粘”在了一起，这种情况就是nagle algorithm
【 在 adamhj 的大作中提到: 】
: 他那句是引用你说的
:
☆─────────────────────────────────────☆
adamhj (淘气阿丹) 于 (Sat Oct 22 11:56:26 2022) 提到:
这话我没法答，因为我也不知道这些发现“粘包”的人，遇到的实际是哪种情况，可能A是这种情况，B是那种情况，需要具体情况具体分析；脱离具体案例争这个没有意义
【 在 wallyz 的大作中提到: 】
: 我没觉得这个话有啥问题，因为日常发现所谓沾包的人，都不是因为buffer满，或者对方窗口满，或者部分重传的情况下
: 而是小包没及时发，和别的包“粘”在了一起，这种情况就是nagle algorithm
☆─────────────────────────────────────☆
adamhj (淘气阿丹) 于 (Sat Oct 22 12:04:31 2022) 提到:
还有一种可能，他先send两次小包，之后再来调recv，不需要有nagle，也会出现所谓粘包，毕竟也是一次读直接把两次写的内容一起读出来了嘛
所以你看争这个毫无意义，你不知道那些讨论粘包的人到底遇到的是什么情况
【 在 wallyz 的大作中提到: 】
: 我没觉得这个话有啥问题，因为日常发现所谓沾包的人，都不是因为buffer满，或者对方窗口满，或者部分重传的情况下
: 而是小包没及时发，和别的包“粘”在了一起，这种情况就是nagle algorithm
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sat Oct 22 12:08:08 2022) 提到:
好吧，反正这个也是个民间概念
【 在 adamhj 的大作中提到: 】
: 还有一种可能，他先send两次小包，之后再来调recv，不需要有nagle，也会出现所谓粘包，毕竟也是一次读直接把两次写的内容一起读出来了嘛
: 所以你看争这个毫无意义，你不知道那些讨论粘包的人到底遇到的是什么情况
:
☆─────────────────────────────────────☆
smthwang00 (smthwang) 于 (Sat Oct 22 12:20:32 2022) 提到:
多线程也不能一堆线程处理一个session啊
【 在 hengcuiyuan 的大作中提到: 】
:问一个初级问题：socket在多线程的环境下，是怎么区分哪个数据包是给哪个进程的？或者说，从网络上到来的杂乱无章的数据包
- 来自 水木社区APP v3.5.6
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sat Oct 22 16:01:20 2022) 提到:
我想就SCTP是否真的无序再多说几嘴：
虽然SCTP有Stream Sequence Number，有U flag，但是实际上，这些做的，都仅仅是让到达的数据包提早进入用户层的手段，
而实际上，SCTP的拥塞控制算法，非常强烈的依赖于传输的顺序，如果chunk在传输过程中出现了乱序，后发的先到，则先发的后到，则当后发先至收到的那一刻起，先发而尚未到（即使马上就会到）的这个"洞"就会被判定为丢包，会触发GAP report，而一个TSN被三次GAP report指认，则会进入Fast Retransmit，而这个名字看上去Fast，实际上一点都不Fast，前头我已经讲过了。而且它的恢复也强烈依赖于RTT，对于长距离多路径的网络，乱序是很常见的，而乱序之后导致的降速，因为RTT大，恢复非常慢，这意味着SCTP的连接非常脆弱，很容易降速，并很难恢复。
https://www.rfc-editor.org/rfc/rfc4960#section-7.2.4
In the absence of data loss, an endpoint performs delayed
acknowledgement. However, whenever an endpoint notices a hole in the
arriving TSN sequence, it SHOULD start sending a SACK back every time
a packet arrives carrying data until the hole is filled.
Whenever an endpoint receives a SACK that indicates that some TSNs
are missing, it SHOULD wait for two further miss indications (via
subsequent SACKs for a total of three missing reports) on the same
TSNs before taking action with regard to Fast Retransmit.
这里因为乱序导致的降速，无论你是用多个流，还是set U flag，都不能豁免，所以即使你把一个"洞"之后的包提交给用户层，这个洞却会引发SCTP本身一系列的反应
所以本质上，我可以这么讲，SCTP其实非常非常依赖于顺序并对失序非常脆弱
TCP虽然要求顺序，但是它的拥塞控制算法进化了好多次了，Reno，Vegas，BIC，New-Reno，BBR，所以它对于失序的耐受程度要比SCTP好得多
虽然我对SCTP并不是滚瓜烂熟，但是至少我也是debug过现实问题的，rfc 4960的某些章节也是仔细读过的
至于你说的内核，我从来不都觉得内核就怎么高大上了，debug问题最后发现问题在内核，给内核打个patch，这虽然不是每天都发生，但也不是什么高深的东西
至于你又是扯某为，又是沾Oracle的，我都不知道你真的读过RFC没
顺便说一句，无论是某为还是Oracle，在我眼里都是普通的公司，没有光环
【 在 iwannabe 的大作中提到: 】
:
https://docs.oracle.com/cd/E95619_01/html/esbc_ecz810_configuration/GUID-AB031: B53-8C69-4B73-BBBC-081742853093.htm#GUID-B23CF5FD-B001-4F58-8873-B8BF1C7846BD
: 给你举一个sctp unorder transmission的一个案例
: ...................
☆─────────────────────────────────────☆
hgoldfish (老鱼) 于 (Sat Oct 22 18:44:19 2022) 提到:
突然想到一个问题。TCP 的 OOB 数据是有序的吗？
【 在 iwannabe 的大作中提到: 】
: sctp可以无序传输，你不清楚吗？
: SCTP allows for unordered data delivery and since it has multiple streams,
: only the one affected is temporarily blocked. As in the diagram below, SCTP
: ...................
☆─────────────────────────────────────☆
qlogic (戒网了) 于 (Sat Oct 22 22:55:53 2022) 提到:
看到你说了sctp只能有序传输这个错误开始拼命找补，言语开始不善起来了
【 在 wallyz (哦) 的大作中提到: 】
: 我想就SCTP是否真的无序再多说几嘴：
:
: 虽然SCTP有Stream Sequence Number，有U flag，但是实际上，这些做的，都仅仅是让到达的数据包提早进入用户层的手段，
:
☆─────────────────────────────────────☆
hgoldfish (老鱼) 于 (Sat Oct 22 23:19:33 2022) 提到:
我建议大家发点有信息含量的帖子。就算结论是错的，只要给出的信息是对的，仍然是有价值的。而没有信息含量的论断，就算是对的，我认为价值度也较低。
【 在 qlogic 的大作中提到: 】
: 看到你说了sctp只能有序传输这个错误开始拼命找补，言语开始不善起来了
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sat Oct 22 23:31:16 2022) 提到:
把rfc都抄过来也掩盖不了错误啊
那哥们一来就是你不懂blablabla的，然后被指出错误就开始疯狂贴rfc，然后贬低别人，
这样都不能掩盖自己的错误。
【 在 hgoldfish 的大作中提到: 】
: 我建议大家发点有信息含量的帖子。就算结论是错的，只要给出的信息是对的，仍然是
: 有价值的。而没有信息含量的论断，就算是对的，我认为价值度也较低。
☆─────────────────────────────────────☆
z16166 (Netguy) 于 (Sun Oct 23 00:53:54 2022) 提到:
我去，你们吵这些，帮楼主解决了问题没
☆─────────────────────────────────────☆
xuzong (XZ) 于 (Sun Oct 23 10:01:10 2022) 提到:
tcp面相链接，先建立连接再传书
udp可以通过from to找到对象，向指定对象发IP加端口
如果多线程处理一个来源的数据，单独做一个传书线程，然后把数据分配到各个处理线程，多用户数据这种一般会用线程池
【 在 hengcuiyuan 的大作中提到: 】
:问一个初级问题：socket在多线程的环境下，是怎么区分哪个数据包是给哪个进程的？或者说，从网络上到来的杂乱无章的数据包
- 来自 水木社区APP v3.5.6
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 10:58:30 2022) 提到:
这么说吧，如果SCTP真的既...，又...，那么它怎么被互联网抛弃了呢？
QUIC要解决的其中一个问题就是HOL blocking，这也是无序传输的一个优点，
如果SCTP已经能做到了，那直接启用SCTP就行了，为什么又要发明QUIC这个包在UDP里面的轮子？
有人说因为很多网络设备不支持SCTP，那把SCTP放在UDP里面tunnel就行了，放着现成的不用，为什么要创造一个QUIC出来呢？
前面的帖子你说我言语不善，我认，因为我回的第一帖那位本身就在教训人，所以我的语气也不好，
至于这位，上来就神秘兮兮的抛下一个sctp，好像自己拥有了什么高深的秘密，
又什么“某为linux内核支持sctp的case，我参与过”，
我就见不得这种装，lksctp定型的代码里面，比如3.10 kernel里面，一个某为的字眼都没有，不知道你参与的是啥？据我所知，现在的lksctp的维护者一个也没有某为的，如果有错请纠正我
比如下面这种信息，某为何在？那位自称参与的仁兄又何在？难道是升级一下某为产品里面的kernel，或者修改一下menuconfig一下启用sctp模块，叫参与？
/* SCTP kernel implementation
* (C) Copyright IBM Corp. 2001, 2004
* Copyright (c) 1999-2000 Cisco, Inc.
* Copyright (c) 1999-2001 Motorola, Inc.
* Copyright (c) 2001-2002 Intel Corp.
* Copyright (c) 2002 Nokia Corp.
*
关于SCTP面上的无序传输，我还是得说，用跨Stream说无序，我还是认为是诡辩，因为SCTP的stream和QUIC不一样，SCTP是开头就定死了几个就是几个，如果这几个都已经HOL blocking了，你没办法按需启用新的stream
我承认我开始遗漏了U flag，但是启用U flag不会对SCTP的行为有本质影响，它对包的乱序敏感的对RTT长脆弱的毛病不会因为你设置了U flag而有任何改善，不信你可以试试看
【 在 qlogic 的大作中提到: 】
: 看到你说了sctp只能有序传输这个错误开始拼命找补，言语开始不善起来了
:
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 11:21:40 2022) 提到:
贴RFC，贴其它标准文本, 对于技术人员来说，就像律师贴法律条款，是非常自然非常得体的职业行为，你不该用疯狂来描述
我刚刚的帖子承认，我忽略了U flag，所以我的逻辑不严密，
如果你上来贴的是
https://www.rfc-editor.org/rfc/rfc4960#section-6.6 而不是用多个流来诡辩无序，那才真的证明你懂，
实际上你一会跨流，一会oracle，一会某为的，到现在也没见你贴最有说服力的材料
其实至于U flag，它的无序是为SCTP-to-ULP这个路径的无序，并不是SCTP传输过程的无序，我一直在说的SCTP强烈依赖包的顺序，这个论断我认为没问题，所以用SCTP做无序传输来解决TCP的问题，行不通
【 在 iwannabe 的大作中提到: 】
: 把rfc都抄过来也掩盖不了错误啊
: 那哥们一来就是你不懂blablabla的，然后被指出错误就开始疯狂贴rfc，然后贬低别人，
: 这样都不能掩盖自己的错误。
: ...................
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sun Oct 23 13:33:27 2022) 提到:
我理解你，犯了一个错误要用更多的只是展示自己多nb的心情
可是sctp支持unorder transmission且有实际使用场景，这个你承认吧，别的就不用bb了
。
【 在 wallyz 的大作中提到: 】
: 这么说吧，如果SCTP真的既...，又...，那么它怎么被互联网抛弃了呢？
: QUIC要解决的其中一个问题就是HOL blocking，这也是无序传输的一个优点，
: 如果SCTP已经能做到了，那直接启用SCTP就行了，为什么又要发明QUIC这个包在UDP里
: 面的轮子？
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 14:01:02 2022) 提到:
不是我挑毛病，unorder transmission这个词一出来，我才知道，你可能从来也没明白unodered 这个词在SCTP里面是什么意思
SCTP的U flag提供的是unordered delivery，delivery是指的SCTP到Upper Layer Protocol (ULP)这个位置，仅仅指SCTP收到了消息之后，可以不用重排序提交给ULP，这是在接收方内部的事情，
从一个SCTP endpoint到另一个SCTP endpoint，这叫做transmission，从来都强烈依赖order，说unorder transmission，这肯定是错的
不信你去kernel里面搜SCTP_DATA_UNORDERED，你看看它出现的地方，哪个地方与transmission有关系？
下面三个和statistic有关：
if (chunk->chunk_hdr->flags & SCTP_DATA_UNORDERED)
SCTP_INC_STATS(net, SCTP_MIB_OUTUNORDERCHUNKS);
if (chunk->chunk_hdr->flags & SCTP_DATA_UNORDERED)
asoc->stats.ouodchunks++;
if (chunk->chunk_hdr->flags & SCTP_DATA_UNORDERED) {
SCTP_INC_STATS(net, SCTP_MIB_INUNORDERCHUNKS);
if (chunk->asoc)
chunk->asoc->stats.iuodchunks++;
下面这段是PR-SCTP扩展里面的，但是也和unordered transmission打不着关系，因为PR-SCTP本身就是ordered：
if (TSN_lte(tsn, asoc->adv_peer_ack_point+1)) {
asoc->adv_peer_ack_point = tsn;
if (chunk->chunk_hdr->flags &
SCTP_DATA_UNORDERED)
continue;
skip_pos = sctp_get_skip_pos(&ftsn_skip_arr[0],
nskips,
chunk->subh.data_hdr->stream);
ftsn_skip_arr[skip_pos].stream =
chunk->subh.data_hdr->stream;
ftsn_skip_arr[skip_pos].ssn =
chunk->subh.data_hdr->ssn;
if (skip_pos == nskips)
nskips++;
if (nskips == 10)
break;
} else
下面这两个和跳过stream sequence number的设置有关：
if (sinfo->sinfo_flags & SCTP_UNORDERED) {
flags |= SCTP_DATA_UNORDERED;
dp.ssn = 0;
if (lchunk->chunk_hdr->flags & SCTP_DATA_UNORDERED) {
ssn = 0;
下面两个就是和ULP直接相关：
if (chunk->chunk_hdr->flags & SCTP_DATA_UNORDERED) {
event->flags |= SCTP_UNORDERED;
event->cumtsn = sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map);
}
/* Check if this message needs ordering. */
if (SCTP_DATA_UNORDERED & event->msg_flags)
return event;
所以，无论是你找RFC，还是扒kernel的code，你看哪里能提供unordered transmission?
【 在 iwannabe 的大作中提到: 】
: 我理解你，犯了一个错误要用更多的只是展示自己多nb的心情
: 可是sctp支持unorder transmission且有实际使用场景，这个你承认吧，别的就不用bb了
: 。
: ...................
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sun Oct 23 14:18:48 2022) 提到:
太逗了，同学，sctp unorder transmission，用这个词去google搜，你会搜到n多的文章
提及，比如
https://d-nb.info/1230322620/34
In contrast to SCTP, QUIC does not support unreliable nor
unordered transmissions.
为了弥补自己这么个错误，浪费那么多脑细胞洗地，何必呢。
【 在 wallyz 的大作中提到: 】
: 不是我挑毛病，unorder transmission这个词一出来，我才知道，你可能从来也没明白
: unodered 这个词在SCTP里面是什么意思
: SCTP的U flag提供的是unordered delivery，delivery是指的SCTP到Upper Layer
: Protocol (ULP)这个位置，仅仅指SCTP收到了消息之后，可以不用重排序提交给ULP，这
: 是在接收方内部的事情，
: 从一个SCTP endpoint到另一个SCTP endpoint，这叫做transmission，从来都强烈依赖
: order，说unorder transmission，这肯定是错的
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 14:45:57 2022) 提到:
我还真跟你较真了，
你放着SCTP的权威的RFC不看，放着SCTP的权威实现不看，你去看一个野鸡大学的论文？这个人的用词，你就拿来引经据典了？
纵使如此，你有没有巴拉巴拉这个论文里面的unordered, 指的是啥呢？指的还是set U flag，unordered，指的还是to ULP，这叫做unordered delivery, 不叫unordered transmission
PS，这个大学德国排名79世界排名1328，我叫它野鸡不为过吧？
【 在 iwannabe 的大作中提到: 】
: 太逗了，同学，sctp unorder transmission，用这个词去google搜，你会搜到n多的文章
: 提及，比如
:
https://d-nb.info/1230322620/34: ...................
☆─────────────────────────────────────☆
qlogic (戒网了) 于 (Sun Oct 23 15:57:34 2022) 提到:
那篇rfc讲了delivery和transmission的区别？看你钻牛角尖看不下去了。
我相信在中文语境下，delivery和transmission没有任何区别。
【 在 wallyz (哦) 的大作中提到: 】
: 我还真跟你较真了，
:
: 你放着SCTP的权威的RFC不看，放着SCTP的权威实现不看，你去看一个野鸡大学的论文？这个人的用词，你就拿来引经据典了？
:
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 16:28:06 2022) 提到:
这个可不是民间术语，这也不是我咬文嚼字，而事实也并不以你的相信与否而转移：
https://datatracker.ietf.org/doc/rfc3286/
SCTP accomplishes multi-streaming by creating
independence between
data transmission and data delivery. In particular, each payload
DATA "chunk" in the protocol uses two sets of sequence numbers, a
Transmission Sequence Number that governs the transmission of
messages and the detection of message loss, and the Stream ID/Stream
Sequence Number pair, which is used to determine the sequence of
delivery of received data.
如果你说你觉得是一回事，那说明你是错的而已
【 在 qlogic 的大作中提到: 】
: 那篇rfc讲了delivery和transmission的区别？看你钻牛角尖看不下去了。
: 我相信在中文语境下，delivery和transmission没有任何区别。
☆─────────────────────────────────────☆
qlogic (戒网了) 于 (Sun Oct 23 16:56:44 2022) 提到:
恭喜你，抓到对方词语上的不严谨，成功实现反杀。呵呵
【 在 wallyz (哦) 的大作中提到: 】
: 这个可不是民间术语，这也不是我咬文嚼字，而事实也并不以你的相信与否而转移：
:
:
https://datatracker.ietf.org/doc/rfc3286/ :
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 17:08:36 2022) 提到:
你就不要酸溜溜了
我看出来了，你和那位，只知道SCTP大概是个啥，却没有用过，
所以你丢下了一个SCTP全称，他丢下了一个SCTP的简称，因为别的你们也不知道，对SCTP的认知也停留在别人的blog的只言片语的程度，从来没有读过RFC，也从来没有看过SCTP的实际实现
实际上用过SCTP的，都知道SCTP的每个data chunk里面有一个TSN，TSN是什么？
Transmission Sequence Number
凡是了解到这个程度的，便不会再在SCTP的范畴内提unordered transmission
你见过UDP有sequence number吗？
至于U flag，我也只是想严密一点，所以我认可，我忽略了SCTP->ULP的unorder delivery这点，
但后面的讨论，清楚的表明，你们根本不理解这个U flag是个啥，和你们讨论这个，大概是白瞎了
【 在 qlogic 的大作中提到: 】
: 恭喜你，抓到对方词语上的不严谨，成功实现反杀。呵呵
☆─────────────────────────────────────☆
qlogic (戒网了) 于 (Sun Oct 23 17:41:03 2022) 提到:
en，我往上翻了一下，人家把乱序传输翻译成unorder transmission，犯了两个错误，首先应该是unordered，其次应该是delivery。
所以你是对的。
【 在 wallyz (哦) 的大作中提到: 】
: 你就不要酸溜溜了
:
: 我看出来了，你和那位，只知道SCTP大概是个啥，却没有用过，
:
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sun Oct 23 19:46:45 2022) 提到:
我觉得你真nb，从sctp支不支持无序传输，转进到unordered transmission和delivery的
区别了。
就问你两个问题：
sctp 支不支持无序传输
有没有人这么干过，在sctp里使用无序传输
这才是最根本的问题，别扯其他没用的。
【 在 wallyz 的大作中提到: 】
: 我还真跟你较真了，
: 你放着SCTP的权威的RFC不看，放着SCTP的权威实现不看，你去看一个野鸡大学的论文
: ？这个人的用词，你就拿来引经据典了？
: 纵使如此，你有没有巴拉巴拉这个论文里面的unordered, 指的是啥呢？指的还是set
: U flag，unordered，指的还是to ULP，这叫做unordered delivery, 不叫unordered
: transmission
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 20:12:50 2022) 提到:
就对SCTP的理解，我是比你nb一点点，
你都分不清什么是transmission，什么是delivery，我还跟你讨论什么？
【 在 iwannabe 的大作中提到: 】
: 我觉得你真nb，从sctp支不支持无序传输，转进到unordered transmission和delivery的
: 区别了。
: 就问你两个问题：
: ...................
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sun Oct 23 20:22:08 2022) 提到:
无序传输 要求是transmission还是delivery，嘴硬同学
【 在 wallyz 的大作中提到: 】
: 就对SCTP的理解，我是比你nb一点点，
: 你都分不清什么是transmission，什么是delivery，我还跟你讨论什么？
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 20:23:56 2022) 提到:
不用人身攻击，你来定义
【 在 iwannabe 的大作中提到: 】
: 无序传输 要求是transmission还是delivery，嘴硬同学
:
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sun Oct 23 20:26:22 2022) 提到:
在应用层面的数据传输，是用transmission还是delivery？
应用层面数据无序传输 sctp是否能够实现？是否有人这么干？
【 在 wallyz 的大作中提到: 】
: 不用人身攻击，你来定义
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 20:34:33 2022) 提到:
SCTP层的任何一个data chunk都有统一的TSN，即使它们来自不同的stream，也包括带U flag的，
你说这叫有序还是无序？
【 在 iwannabe 的大作中提到: 】
: 在应用层面的数据传输，是用transmission还是delivery？
: 应用层面数据无序传输 sctp是否能够实现？是否有人这么干？
:
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sun Oct 23 20:35:51 2022) 提到:
在应用层呢？我想使用sctp无序传输，可以实现吗？
【 在 wallyz 的大作中提到: 】
: SCTP层的任何一个data chunk都有统一的TSN，即使它们来自不同的stream，也包括带
: U flag的，
: 你说这叫有序还是无序？
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 20:39:04 2022) 提到:
你的stream1的包导致出现了TSN失序，结果stream 2的包的传输也受到影响，哪怕你set U flag了也一样不能豁免，你觉得是有序还是无序？
你见过UDP的包里面带序号的吗？
【 在 iwannabe 的大作中提到: 】
: 在应用层呢？我想使用sctp无序传输，可以实现吗？
:
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sun Oct 23 20:41:44 2022) 提到:
Due to the very nature of networks not all packets may travel across the
exact same path. If there is a time-delay using one path over another, the
original messages could be out of order when received. Unordered data
delivery allows for this instance and can correct the issue by reordering the
messages correctly. Using TCP’s reliable data transfer feature requires that
packets be processed in order. If one is missing or out of order, the packet
must be reordered before processing can continue. For example, in the diagram
below, if we were using TCP, once Message 3 was received all processing would
stop, and wait for Message 2, it would be processed and then Message 3 would
be processed. SCTP allows for unordered data delivery and since it has
multiple streams, only the one affected is temporarily blocked. As in the
diagram below, SCTP would process the messages in the order they arrived, not
waiting for them to be numerically ordered. With SCTPs reliable transfer,
many networked disk solutions already provide ordering service; SCTP’s
ability to simply pass the data on relieves the server of the unnecessary
overhead of reordering.
https://www.f5.com/services/resources/white-papers/introduction-to-the-stream-
control-transmission-protocol-sctp-the-next-generation-of-the-transmission-con
trol-protocol-tcp
这个怎么解释？
【 在 wallyz 的大作中提到: 】
: 你的stream1的包导致出现了TSN失序，结果stream 2的包的传输也受到影响，哪怕你
: set U flag了也一样不能豁免，你觉得是有序还是无序？
: 你见过UDP的包里面带序号的吗？
☆─────────────────────────────────────☆
leadu (leadu) 于 (Sun Oct 23 20:55:57 2022) 提到:
我完整的看了一遍此主题，你输出观点暴多且话痨，并且大段话之间逻辑很差，搞不清楚你在说啥。
比如你回复的帖子，我在和别人说新协议逐渐抛弃tcp拆包粘包设计，比如看一下sctp再来讨论tcp这个设计的优略。
你回复的这一堆啰嗦话是在说什么？无法推出任何相关逻辑。
另外回答你提到的部分问题：
1.批别人。实事求是带数据的负面批评是正常的。adamhj 情况稍微特殊一些，他第一个帖子就不是很客气，所以我没有回复:
发信人: adamhj (淘气阿丹), 信区: Programming
标 题: Re: socket多线程编程的问题
发信站: 水木社区 (Thu Oct 20 13:55:02 2022), 站内
你但凡知道TCP/IP层设计上为什么会出现重分包这种场景就不会产生这种理解，还设计失误都出来了
我对他的后续批评其实也是有理有据的，但是估计adamhj不会希望被当众带论据的分析，不管他觉得对不对的怕是都不会希望。
所以这个事情就此打住吧，我俩都没有再讨论你就别出来添油加醋了
2.sctp相关。你表现出要争论的样子，但我没有搞清楚你想具体争论的是什么。
比如sctp没有人说到它的stream问题啊？你突然提到stream数目受限是为什么？
就算讨论这个，stream受限不就是因为init包里面写了么，协议reserve了那么一大堆chunk type，回头加一个改这个不就行了。
sctp本身扩展性还是很强的，比如甚至还有unreliable的扩展draft-ietf-sigtran-usctp-01.txt。改个i/o stream num更不是事情。
3.”有人说因为很多网络设备不支持SCTP，那把SCTP放在UDP里面tunnel就行了，放着现成的不用，为什么要创造一个QUIC出来呢？ “
别太懒，自己搜，Google有文档说这个事情，有和connection id相关的情况，而且他有简化的情况。
【 在 wallyz 的大作中提到: 】
: 看来你真不懂，但是你好像很喜欢批别人
: TCP的粘包本质上是Nagle算法，为了让链路的利用率更高，而不至于被一帮袖珍负载拖着大包头充斥，不知道什么人创造了粘包这种称呼，这个称呼本质上就是不理解TCP的基本理念，也不明白网络各个层的权责
: SCTP是电信网络里面应用很广泛的协议，跟美国不美国没关系
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 20:57:34 2022) 提到:
这个的意思是，
你的包如果经过多路径到达，比如网卡多队列没有启用五元组哈希，导致一个连接走了几个队列，再比如用链路聚合的时候，没有用合适的哈希算法，导致一个连接走了多个链路，诸如此类原因，造成后发的包先至，
这种情况下，如果一个失序的包带了U flag，则接收方的SCTP层会跳过基于SSN （Stream Sequence Number）的steam内的排序，而直接生成socket readable事件，比如EPOLLIN，所以这里的失序，实际上指的是stream内的失序，
但是，stream内的失序，本身也意味着TSN的失序，
TSN失序的包们在SCTP层导致了什么事情：TSN失序，会在SCTP的整个连接层面导致一系列负面事件，而这些事件的影响，会波及所有的stream，包括后面携带的U flag的包
这些问题，不实际debug过问题，只是道听途说，不会有真实的认知
【 在 iwannabe 的大作中提到: 】
: Due to the very nature of networks not all packets may travel across the
: exact same path. If there is a time-delay using one path over another, the
: original messages could be out of order when received. Unordered data
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 21:20:50 2022) 提到:
我确实是有几个不同的出发点在讲，
第一个出发点，我看你说“美国电话网的的协议”，“另外国内电话网现在是啥协议？美国那边换了sctp，中国这边自己搞了一个新的么”，我觉得你这样讲就让人感觉很奇怪，SCTP是SIGTRAN协议栈里面唯一传输层协议，协议栈的分层怎么还分美国中国了？
第二个出发点，“简中互联网每次讨论起tcp粘包拆包的时候，总让人有种猴子高压水枪实验的既视感”，这有一种话让人觉得象是要搞个意见领袖的感觉
第三个出发点，针对的是“quic作者特意提到和sctp的比较，并说参考了sctp的实现”，这个部分我认为我的文字没有情绪，我只是想说SCTP没有粗看的那么好，基本没有演进，实际网络环境下的表现不好，另外一部分的内容是，我认为QUIC的多流和SCTP的不一样，QUIC的connection-id的概念和SCTP的multi-home也不一样，QUIC的这两个都是动态的，SCTP的是连接初始阶段就得确定的。我为什么要提stream和multi-home呢？因为这是SCTP的卖点，也是QUIC的卖点
至于你说要扩展，那就属于没得谈的问题了，理论上，万物皆可扩展
【 在 leadu 的大作中提到: 】
: 我完整的看了一遍此主题，你输出观点暴多且话痨，并且大段话之间逻辑很差，搞不清楚你在说啥。
: 比如你回复的帖子，我在和别人说新协议逐渐抛弃tcp拆包粘包设计，比如看一下sctp再来讨论tcp这个设计的优略。
: 你回复的这一堆啰嗦话是在说什么？无法推出任何相关逻辑。
: ...................
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sun Oct 23 21:24:03 2022) 提到:
看oracle这篇文档，ssn被忽略，不是什么大不了的事情
Delivery Modes SCTP supports two delivery modes, ordered and unordered.
Delivery mode is specified by the U bit in the DATA chunk header — if the
bit is clear (0), ordered delivery is specified; if the bit is set (1),
unordered delivery is specified. Within a stream, an SCTP endpoint must
deliver ordered DATA chunks (received with the U bit set to 0) to the upper
layer protocol according to the order of their Stream Sequence Number. Like
the U bit, the Stream Sequence Number is a field within the DATA chunk
header, and serves to identify the chunk’s position with the message stream.
If DATA chunks arrive out of order of their Stream Sequence Number, the
endpoint must delay delivery to the upper layer protocol until they are
reordered and complete. Unordered DATA chunks (received with the U bit set to
1) are processed differently. When an SCTP endpoint receives an unordered
DATA chunk, it must bypass the ordering mechanism and immediately deliver the
data to the upper layer protocol (after reassembly if the user data is
fragmented by the sender). As a consequence, the Stream Sequence Number field
in an unordered DATA chunk has no significance. The sender can fill it with
arbitrary value, but the receiver must ignore any value in field. When an
endpoint receives a DATA chunk with the U flag set to 1, it must bypass the
ordering mechanism and immediately deliver the data to the upper layer (after
reassembly if the user data is fragmented by the data sender). Unordered
delivery provides an effective way of transmitting out-of-band data in a
given stream. Note also, a stream can be used as an unordered stream by
simply setting the U bit to 1 in all DATA chunks sent through that stream.
【 在 wallyz 的大作中提到: 】
: 这个的意思是，
: 你的包如果经过多路径到达，比如网卡多队列没有启用五元组哈希，导致一个连接走了
: 几个队列，再比如用链路聚合的时候，没有用合适的哈希算法，导致一个连接走了多个链
: 路，诸如此类原因，造成后发的包先至，
: 这种情况下，如果一个失序的包带了U flag，则接收方的SCTP层会跳过基于SSN （
: Stream Sequence Number）的steam内的排序，而直接生成socket readable事件，比如
: EPOLLIN，所以这里的失序，实际上指的是stream内的失序，
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 22:00:37 2022) 提到:
Linux kernel SCTP，U flag的chunk的SSN = 0，这个在我下午贴出来的kernel的代码里面有，
rfc4960里面也说了，如果有U flag则可以随便设SSN，但是设了也没用
The 'Stream Sequence Number' field in a DATA chunk with U flag set to
1 has no significance. The sender can fill it with arbitrary value,
but the receiver MUST ignore the field.
所以U flag的chunk的SSN本来就是被忽略的，
但你也看到了，Oracle这段文字，通篇都在谈从SCTP到upper layer protocol的delivery，而不是两个SCTP节点之间的传输，
如果认为有了U flag，SCTP的网络传输可以无序，比如，启用多队列或者链路聚合，却没有合适的哈希让一条path限定在一个队列或者链路，则会面临和TCP一样的局面，在RTT大的网络上，局面甚至比TCP还糟
【 在 iwannabe 的大作中提到: 】
: 看oracle这篇文档，ssn被忽略，不是什么大不了的事情
: Delivery Modes SCTP supports two delivery modes, ordered and unordered.
: Delivery mode is specified by the U bit in the DATA chunk header — if the
: ...................
☆─────────────────────────────────────☆
leadu (leadu) 于 (Sun Oct 23 22:16:22 2022) 提到:
第二个，简中的每次讨论到tcp的粘包拆包的都是这德性。
每次讨论这个总出来一堆人pua新手”你懂不懂啊这是流“。这事好多年了。
新手真这么理解了指不定搭成一个什么样的奇观知识体系。
这个问题答案其实就一句，当年设计的太匆忙后面不好改了，就得了。
我从第一个回复开始讨论的就是协议设计，我认为需要让新手知道，tcp现在是这个样子，但这个样子是有设计问题的，没有满足需求。
我并不认可一堆人讨论的所谓流，甚至这些人连流的定义都无法给出。stream本身就是技术上的一个粗糙的concept，是无法用数学或哲学的标准去审视的
一代代不怎么写协议的人把缺陷pua下去说是流，你不觉得像猴子和高压水枪么？像不像使劲拼白酒的传承
剩下的都是你新开的讨论情况了，和原有讨论无关。
第一个，中美，你不知道业界现在啥情况啊，随便搜了俩别的例子
https://www.zhihu.com/question/342338693
https://www.zhihu.com/question/560633294
【 在 wallyz 的大作中提到: 】
: 我确实是有几个不同的出发点在讲，
: 第一个出发点，我看你说“美国电话网的的协议”，“另外国内电话网现在是啥协议？美国那边换了sctp，中国这边自己搞了一个新的么”，我觉得你这样讲就让人感觉很奇怪，SCTP是SIGTRAN协议栈里面唯一传输层协议，协议栈的分层怎么还分美国中国了？
: 第二个出发点，“简中互联网每次讨论起tcp粘包拆包的时候，总让人有种猴子高压水枪实验的既视感”，这有一种话让人觉得象是要搞个意见领袖的感觉
: ...................
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sun Oct 23 22:29:30 2022) 提到:
laf, 难道不是看应用能不能享受unordered delivery的便利吗？
难道不是sip产品利用sctp的特性，享受到了unordered delivery的便利吗？
【 在 wallyz 的大作中提到: 】
: Linux kernel SCTP，U flag的chunk的SSN = 0，这个在我下午贴出来的kernel的代码
: 里面有，
: rfc4960里面也说了，如果有U flag则可以随便设SSN，但是设了也没用
: The 'Stream Sequence Number' field in a DATA chunk with U flag set to
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 22:40:58 2022) 提到:
你可以这样认为，SCTP的unordered delivery是一个半成品，只存在于SCTP协议层到上层协议层或者应用之间，
SCTP节点之间，强烈依赖传输的序列，每个data chunk都有统一编号的TSN，这与它是归属于哪个stream无关，也与它在stream内的顺序无关，这点，SCTP和TCP并无二致，和真的对顺序无要求的协议，比如UDP，完完全全不一样
unordered transmission会影响整个连接，所以一旦出现顺序颠倒的包，这个包如果有U flag，它自己可以爽，因为它享受到了SCTP层到上层的unordered delivery，后面的都会不爽，哪怕后面的也有U flag，因为整个连接的传输都强烈的依赖于包的前后顺序
【 在 iwannabe 的大作中提到: 】
: laf, 难道不是看应用能不能享受unorder delivery的便利吗？
:
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Sun Oct 23 22:52:37 2022) 提到:
我今天特意查了，至少iscsi，sip和文件服务器等很多应用都用了sctp的unordered
delivery特性
绝对不是你说的半成品。
【 在 wallyz 的大作中提到: 】
: 你可以这样认为，SCTP的unordered delivery是一个半成品，只存在于SCTP协议层到上
: 层协议层或者应用之间，
: SCTP节点之间，强烈依赖传输的序列，每个data chunk都有统一编号的TSN，这与它是
: 归属于哪个stream无关，也与它在stream内的顺序无关，这点，SCTP和TCP并无二致，
: 和
: 真的对顺序无要求的协议，比如UDP，完完全全不一样
: unordered transmission会影响整个连接，所以一旦出现顺序颠倒的包，这个包如果有
: U flag，它自己可以爽，因为它享受到了SCTP层到上层的unordered delivery，后面的
: 都
: 会不爽，哪怕后面的也有U flag，因为整个连接的传输都强烈的依赖于包的前后顺序
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 23:02:03 2022) 提到:
那你有没有确认一下，它们用unordered delivery的时候，它们的网卡多队列或者链路聚合的哈希，是类UDP的可以一个path走多个队列或者链路的？还是类TCP的，一个path只能限定在一个队列或者链路？
【 在 iwannabe 的大作中提到: 】
: 我今天特意查了，至少iscsi，sip和文件服务器等很多应用都用了sctp的unordered
: delivery特性
: 绝对不是你说的半成品。
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Sun Oct 23 23:18:50 2022) 提到:
我应该这么讲，
unordered delivery本身是针对（偶然的）丢包的而提供获益的，而不是为了让SCTP可以像UDP一样脱离传输顺序约束
unordered delivery，是在SCTP的传输已经出现了丢包的情况下，可以让U flag的包跳过流内顺序重排，早点递交给上层，而不需要等待丢失的包重传之后，再按顺序组装之后再递交给上层，
unordered delivery并不意味着SCTP的传输可以无序，SCTP的传输如果无序，比如单path经过多队列/链路同时传输，我前面说了，SCTP在这种情况下的表现比TCP还糟糕
【 在 iwannabe 的大作中提到: 】
: 我今天特意查了，至少iscsi，sip和文件服务器等很多应用都用了sctp的unordered
: delivery特性
: 绝对不是你说的半成品。
: ...................
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Mon Oct 24 00:25:17 2022) 提到:
你理解错了
了解一下，Head of line blocking(HoLB)
https://pdfs.semanticscholar.org/3fe7/7f193c30dde01ce3d54e3cff00a9e6d51c57.pdf
【 在 wallyz 的大作中提到: 】
: 标 题: Re: socket多线程编程的问题
: 发信站: 水木社区 (Sun Oct 23 23:18:50 2022), 站内
:
: 我应该这么讲，
:
: unordered delivery本身是针对（偶然的）丢包的而提供获益的，而不是为了让SCTP可
: 以像UDP一样脱离传输顺序约束
:
: unordered delivery，是在SCTP的传输已经出现了丢包的情况下，可以让U flag的包跳
: 过流内顺序重排，早点递交给上层，而不需要等待丢失的包重传之后，再按顺序组装之后
: 再递交给上层，
:
: unordered delivery并不意味着SCTP的传输可以无序，SCTP的传输如果无序，比如单
: path经过多队列/链路同时传输，我前面说了，SCTP在这种情况下的表现比TCP还糟糕
:
: 【 在 iwannabe 的大作中提到: 】
: : 我今天特意查了，至少iscsi，sip和文件服务器等很多应用都用了sctp的unordered
: : delivery特性
: : 绝对不是你说的半成品。
: : ...................
:
: --
:
: ※ 来源:·水木社区
http://www.mysmth.net·[FROM: 123.168.94.*]
☆─────────────────────────────────────☆
lambdai (lambdai) 于 (Mon Oct 24 02:26:13 2022) 提到:
> 新的主流协议比如quic都抛弃网络拆包流这种设计的了
你这太扯了。quic标准的提供面向流的transport和tcp stream并没有本质区别
只有扩展协议quic masque才提供了像是udp packet类似的抽象
【 在 leadu 的大作中提到: 】
: 你遇到的那个问题国内有一些人叫粘包，不过有些旧时代的老古董喜欢用tcp是流的概念教训新手，他们不喜欢粘包这个名字，认为出现这个名字就是tcp知识不扎实。
: 但实际上谁说流就不能收发对应的？中间非得别人插个缓存改速才叫流么？
: 这个问题对于网络协议设计来说很烦人，属于tcp设计失误，导致每个tcp上的协议都得再设计一个长度表示。
: ...................
☆─────────────────────────────────────☆
lambdai (lambdai) 于 (Mon Oct 24 02:32:22 2022) 提到:
> 所以 chunked encoding 可以作为 websocket 出现前的廉价替代。
不太行。
websocket明确规定是全双工的。
chunked encoding虽然取消了事先知道contet-length的设定，但是没有规定httpserver（尤其是proxy）是不是应该读完请求再发response。
【 在 hgoldfish 的大作中提到: 】
: 出现 chunked encoding 的时候，既可以有 Content-Length 头，也可以不需要。
: 所以 chunked encoding 可以作为 websocket 出现前的廉价替代。
: django 就是很典型的例子，如果返回 StreamingHttpResponse，此时 HTTP 不发送 Content-Length，程序员可以用 python 的 iterator 慢慢地生成数据发送给客户端。
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Mon Oct 24 10:30:11 2022) 提到:
我真服了你，你自己从来都没认真的读过RFC，也没有debug过实际的SCTP的问题，更不用说读过SCTP的实现代码，就凭搜来的各种只言片语，加上你自己的解读，你哪来的自信的说别人错了？
你先搞清楚什么是transmission，再来谈对错吧
【 在 iwannabe 的大作中提到: 】
: 你理解错了
: 了解一下，Head of line blocking(HoLB)
:
https://pdfs.semanticscholar.org/3fe7/7f193c30dde01ce3d54e3cff00a9e6d51c57.pdf: ...................
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Mon Oct 24 10:57:54 2022) 提到:
你看看，一说到你的理解能力，就开始急了，人身攻击开始了。
sctp一个stream需要order，但是不代表他不能实现无序传输，而且有使用的案例。
你在这里大谈如果用了无序，就咋咋咋的，真的很搞笑，像极那些嘴硬的角色。
【 在 wallyz 的大作中提到: 】
: 我真服了你，你自己从来都没认真的读过RFC，也没有debug过实际的SCTP的问题，更不
: 用说读过SCTP的实现代码，就凭搜来的各种只言片语，加上你自己的解读，你哪来的自信
: 的说别人错了？
: 你先搞清楚什么是transmission，再来谈对错吧
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Mon Oct 24 11:22:03 2022) 提到:
【 在 wallyz 的大作中提到: 】
: 标 题: Re: socket多线程编程的问题
: 发信站: 水木社区 (Sun Oct 23 23:18:50 2022), 站内
:
: 我应该这么讲，
:
: unordered delivery本身是针对（偶然的）丢包的而提供获益的，而不是为了让SCTP可
: 以像UDP一样脱离传输顺序约束
:
: unordered delivery，是在SCTP的传输已经出现了丢包的情况下，可以让U flag的包跳
: 过流内顺序重排，早点递交给上层，而不需要等待丢失的包重传之后，再按顺序组装之后
: 再递交给上层，
这里就表明你对unordered delivery一点都不了解，这个机制不是异常处理机制，而是一
个feature，它并不是以丢包为触发条件的。另外，你这里的逻辑也有问题，作为服务端
，他们是先知道丢包呢还是先设置U Flag呢？sctp是可靠连接，丢包会重传，重传超过阈
值，链路就断开abort了。另外，retransmission需要tsn，，而你设置了u flags， tsn
就失效了，这个逻辑你明白吗？从这里可以看出来，你为了圆自己的错误，暴露出更多的
逻辑错误，我很怀疑你就是拿sctp写过简单的server client代码吧。
说个我看到的unordered delivery的场景，文件服务器，我sctp有两个stream，来做文件
发送，一个发送控制指令，需要保证barrier顺序，一个发送u flag的数据信息，客户端
接受unorder的数据，就直接写到对应文件块，这样就无需按照顺序等待了，实现了类似
于udp的速度。
这是sctp相对于tcp的一大优势，就是解决holb问题，估计你就没有听过。
:
: unordered delivery并不意味着SCTP的传输可以无序，SCTP的传输如果无序，比如单
: path经过多队列/链路同时传输，我前面说了，SCTP在这种情况下的表现比TCP还糟糕
:
: 【 在 iwannabe 的大作中提到: 】
: : 我今天特意查了，至少iscsi，sip和文件服务器等很多应用都用了sctp的unordered
: : delivery特性
: : 绝对不是你说的半成品。
: : ...................
:
: --
:
: ※ 来源:·水木社区
http://www.mysmth.net·[FROM: 123.168.94.*]
☆─────────────────────────────────────☆
wallyz (哦) 于 (Mon Oct 24 11:29:02 2022) 提到:
你真能胡掰扯
看到这句话，我都懒得看其它的了，错的离谱
“而你设置了u flags， tsn就失效了，这个逻辑你明白吗”
【 在 iwannabe 的大作中提到: 】
: 这里就表明你对unordered delivery一点都不了解，这个机制不是异常处理机制，而是一
: 个feature，它并不是以丢包为触发条件的。另外，你这里的逻辑也有问题，作为服务端
: ，他们是先知道丢包呢还是先设置U Flag呢？sctp是可靠连接，丢包会重传，重传超过阈
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Mon Oct 24 11:34:25 2022) 提到:
人身攻击我是外行，看看你的贴子数和你的积分，我自愧不如
谈论SCTP，你是外行
【 在 iwannabe 的大作中提到: 】
: 你看看，一说到你的理解能力，就开始急了，人身攻击开始了。
: sctp一个stream需要order，但是不代表他不能实现无序传输，而且有使用的案例。
: 你在这里大谈如果用了无序，就咋咋咋的，真的很搞笑，像极那些嘴硬的角色。
: ...................
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Mon Oct 24 11:42:30 2022) 提到:
U — If set, this indicates that this data is an unordered chunk and the
stream sequence number is invalid. If an unordered chunk is fragmented, then
each fragment has this flag set.
你去搜sctp的kernel实现，看看restransmission的时候，有设置u flags吗
对了，你前面也贴了这段吧，自己忘了？
【 在 wallyz 的大作中提到: 】
: 你真能胡掰扯
: 看到这句话，我都懒得看其它的了，错的离谱
: “而你设置了u flags， tsn就失效了，这个逻辑你明白吗”
: ...................
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Mon Oct 24 11:44:28 2022) 提到:
我的积分是我自己霍霍的，因为zz立场，我当版主，捐积分建版面的时候，自己去bm版查
一下
抓住一切可以贬低别人的地方来圆自己，不正说明了你心虚吗
【 在 wallyz 的大作中提到: 】
: 人身攻击我是外行，看看你的贴子数和你的积分，我自愧不如
: 谈论SCTP，你是外行
☆─────────────────────────────────────☆
javaboy (喝了咖啡就话多-_-;) 于 (Mon Oct 24 11:48:00 2022) 提到:
这个主题欢迎每人再发表两贴总结一下自己的观点，超过两贴删了哦。
【 在 hengcuiyuan 的大作中提到: 】
: 问一个初级问题：socket在多线程的环境下，是怎么区分哪个数据包是给哪个进程的？或者说，从网络上到来的杂乱无章的数据包，这些数据包是怎么重新组合成一个完整的应答报文的？
☆─────────────────────────────────────☆
wallyz (哦) 于 (Mon Oct 24 11:48:20 2022) 提到:
TSN在SCTP里面是用来做loss detection的，乱序会导致判定loss，loss会触发重传，重传会触发拥塞控制，压制整个连接的传输
重传的包的TSN和原包是一样的，不然怎么能知道重传的是谁？
咱们这样吧，你出示一个wireshark的pcap吧，你看看你能不能找出一个包，满足你说的条件：
“而你设置了u flags， tsn就失效了，这个逻辑你明白吗”
【 在 iwannabe 的大作中提到: 】
: U — If set, this indicates that this data is an unordered chunk and the
: stream sequence number is invalid. If an unordered chunk is fragmented, then
: each fragment has this flag set.
: ...................
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Mon Oct 24 11:51:57 2022) 提到:
在重传的过程中，有u flags packet啥事儿吗？同学
【 在 wallyz 的大作中提到: 】
: TSN在SCTP里面是用来做loss detection的，乱序会导致判定loss，loss会触发重传，
: 重传会触发拥塞控制，压制整个连接的传输
: 重传的包的TSN和原包是一样的，不然怎么能知道重传的是谁？
: 咱们这样吧，你出示一个wireshark的pcap吧，你看看你能不能找出一个包，满足你说
: 的条件：
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Mon Oct 24 11:52:48 2022) 提到:
你出示pcap吧，多了不叨叨
【 在 iwannabe 的大作中提到: 】
: 在重传的过程中，有u flags packet啥事儿吗？同学
:
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Mon Oct 24 11:54:21 2022) 提到:
难道不是谁举张谁举证吗？
你说u flags的包是用在重传中的，难道不是你要举证吗？
【 在 wallyz 的大作中提到: 】
: 你出示pcap吧，多了不叨叨
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Mon Oct 24 11:58:13 2022) 提到:
The 'Stream Sequence Number' field in a DATA chunk with U flag set to
1 has no significance.
rfc 4960 6.6
自己去找吧。
【 在 wallyz 的大作中提到: 】
: TSN在SCTP里面是用来做loss detection的，乱序会导致判定loss，loss会触发重传，
: 重传会触发拥塞控制，压制整个连接的传输
: 重传的包的TSN和原包是一样的，不然怎么能知道重传的是谁？
: 咱们这样吧，你出示一个wireshark的pcap吧，你看看你能不能找出一个包，满足你说
: 的条件：
: ...................
☆─────────────────────────────────────☆
wallyz (哦) 于 (Mon Oct 24 11:58:26 2022) 提到:
你不出示，我可要指出你的错误了
“而你设置了u flags， tsn就失效了，这个逻辑你明白吗”
你说这句话的时候，你有没有注意到，你根本没分清楚 Stream Seqence Number 和 Transmission Sequence Number它们不是一回事呢？
我终于明白你这句奇怪的话的源头是什么了，你是从我沾得下面的文字现学现卖得出的啊，可是你现学现卖，也得看明白啊
拜托你，看清楚，这里说的失效的，是
stream sequence number，不是TSN
U — If set, this indicates that this data is an unordered chunk and the
stream sequence number is invalid. If an unordered chunk is fragmented, then
each fragment has this flag set.
【 在 iwannabe 的大作中提到: 】
: 难道不是谁举张谁举证吗？
: 你说u flags的包是用在重传中的，难道不是你要举证吗？
:
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Mon Oct 24 12:05:56 2022) 提到:
好吧，这个是我看错了
但是我的结论没问题，unordered delivery 不是restransmission里的异常处理机制
对吧。
【 在 wallyz 的大作中提到: 】
: 你不出示，我可要指出你的错误了
: “而你设置了u flags， tsn就失效了，这个逻辑你明白吗”
: 你说这句话的时候，你有没有注意到，你根本没分清楚 Stream Seqence Number 和
: Transmission Sequence Number它们不是一回事呢？
: ...................
☆─────────────────────────────────────☆
iwannabe (I wanna be) 于 (Mon Oct 24 12:08:15 2022) 提到:
回到我的问题
1、sctp支持无序传输
2、sctp有使用无序传输的实际使用场景
【 在 iwannabe 的大作中提到: 】
: 好吧，这个是我看错了
: 但是我的结论没问题，unordered delivery 不是restransmission里的异常处理机制
: 对吧。
: ...................
☆─────────────────────────────────────☆
chunhui (北瓜) 于 (Mon Oct 24 14:07:18 2022) 提到:
没错。tcp现在很多被诟病为缺陷缺点的地方，正说明它当初设计的优秀。
人家本来设计一个tcp适用范围是a b c。然后人们一顿乱用，竟然把 c d e f。。。也用上tcp了，最后用的w的时候，发现tcp有了不适应的情况，所以开始觉得tcp有缺点。。。
最后用到x的时候，实在不行了。开始想办法取代。其实在用到ef的时候就应该开始考虑新设计了。
【 在 adamhj 的大作中提到: 】
: 我是没看完，前面老鱼说分隔符标志结尾的协议，我就想起来了chunked encoding是个不定长的流协议就提了一嘴，当然确实协议的细节和我的记忆有偏差是我不仔细
: 然后虽然每个chunk之前会发个长度，但是实际上那行长度也是个不定长串，识别这行长度还是靠分隔符来进行的，发长度也只是为了让这个chunk里可以有\r\n而不需要转义
: 你要说随便提一嘴的话里面存在疏漏是段位问题，那我还奇怪你前面讲传输层协议的时候为什么会把ipv6带进来呢，ipv6上跑的不也是tcp和udp？
: ...................
FROM 123.168.94.*