Re: socket多线程编程的问题

水木社区手机版

主题:Re: socket多线程编程的问题
楼主|wallyz|2022-10-21 20:58:10|展开
看来你真不懂，但是你好像很喜欢批别人

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，没有几页
: 美国电话网的的协议
--
FROM 123.168.94.*
1楼|wallyz|2022-10-22 16:01:20|展开
我想就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的一个案例
: ...................
--
FROM 123.168.94.*
2楼|wallyz|2022-10-23 14:01:02|展开
不是我挑毛病，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了
: 。
: ...................
--
FROM 123.168.94.*