精华内容
下载资源
问答
  • 确认应答机制
    千次阅读
    2020-03-02 21:26:13

    1. 确认应答机制

    在TCP协议中,发送端将数据发送到接收端,接收端会自动返回一个ACK的应答,告诉发送端我已经接收到数据。TCP会给每个字节的数据赋予序列号,每一个ACK应答都会携带对应的确认序号,也就是字段中的32位确认号,这个确认号用来告诉发送端,你的数据发送到哪里,你下一次发送应该从哪里开始。比如发送端先发送了1 - 1000 的数据到接收端,接收端再返回一个ACK响应,此时携带的确认号就是1001,意思就是我已经接收到1001以前的所有数据,你下次应该从1001继续发送。

    2. 超时重传机制

    发生场景

    由于TCP存在一个确认应答机制,所以每次发送端发送一个数据之后,都应该收到一个ACK应答,如果没有收到,发送端就需要重新发送数据。发送端没有接收到ACK应答有可能是发送时网络拥堵没有发送出去,但也有可能对端发送来的ACK在中途丢失了,这样的话就会导致发送端重新发送重复的数据到接收端。这时TCP协议报中的序列号就起到了至关重要的作用,接收端在接收到数据之后,通过核对序列号可以起到一个去重的效果。

    超时时间

    为了网络传输的效率,TCP肯定希望找到一个最小的时间来确保在这个时间内能够收到ACK应答。但由于网络环境的影响,时间太长效率会低,时间太多又会导致发送重复的数据包。所以TCP就会动态来计算这个最大超时时间。在Linux等一些系统中,超时时间会以500ms作为一个时间单位来进行控制,每次重发的判定时间都是500ms的整数倍。在第一次重发没有收到应答后,发送端会等待1000ms再进行重传,也就是两个500ms。如果仍然没有收到应答,就会等待2000ms再重传,也就是四个500ms,依次累加,每次等待时间会以指数形式递增。但如果累计到一定的重传次数,TCP就会认为是网络或者对端主机出现异常,然后强制关闭连接。

    更多相关内容
  • 一、什么是确认应答机制 收到一条报文后,向发送端发送一条确认ACK,此ACK的作用就是告诉发送端:接收端已经成功的收到了消息,并且希望收到下一条报文的序列号是什么 序列号 一、什么是序列号? TCP会对每个...

    序列号

    一、什么是序列号?

    TCP会对每个字节的数据都进行编号,数据的编号就是数据的序列号,每个字节都有自己独一无二的编号,故序列号具有唯一性

    二、序列号的作用?

    接收端为了区别重复的报文段(报文段也叫帧),接收端有时会收到很多重复的数据,那么TCP协议就需要能够识别出那些是重复的包,并且把重复的丢弃掉,此时就需要使用序列号,来实现去重

    ps:TCP的序列号即表示该报文段从第N个字节开始发送

    确认应答(ACK)机制

    一、什么是确认应答机制

    收到一条报文后,向发送端发送一条确认ACK,此ACK的作用就是告诉发送端:接收端已经成功的收到了消息,并且希望收到下一条报文的序列号是什么

    这里写图片描述

    二、为什么需要确认应答机制

    在TCP连接成功后,发送的每一条数据都可能会丢失,因此需要确认应答,以保证数据的完整性

    三、确认应答的作用

    1.来确认接收端收到数据了
    2.可以知道收到的是哪一条数据

    超时重传机制

    一、什么是超时重传机制

       TCP每发送一个报文段,就会对这个报文段设置一次计时器,只要计时器设置的
    重传时间到,但发送端还没有收到接收端发来的确认,此时就会重传此报文段
       超时重传机制是内核实现实现的,因为超时重传机制是TCP的一部分,而TCP
    又属于内核,所以超时重传机制也就是内核实现的
    

    二、为什么在超时重传机制中,计时器设置的时间为什么要变得越来越长?

        一个报文段可以好几次的超时,就是说呢第一次发此报文段时超时了,发送端
    会重新发,第二次发的时候还是超时了,此时发送端还是会重新发送,但是发送端
    对一个超时的报文段不会一直发,发几次之后,就会丢弃此报文段
        计时器设置的时间在好几次的发送中,为什么要变得越来越长呢?因为在发送
    数据的时候,数据传输可能还没建立好,此时就重传,可能会浪费资源
    
    

    三、超时的时间如何确定?

         最理想的情况下,找到一个最小的时间,保证“确认应答一定能在这个时间内
    返回”,但是这个时间的长短,会随着网络环境的不同,会有差异,如果超时时间
    设置的太长,会影响整体的重传效率,但是如果设置的太短,有可能会频繁的发送
    重复的包
    
        TCP为了保证无论在任何环境下都能比较高性能的通信,会动态的计算这个
    最大超时时间,所以超时时间不是确定的,是TCP动态的计算的
        在Linux(Windows)中,超时以500ms为一个单位进行控制,每次判定超时
    重发的超时时间都是500ms的整数倍
        如果重发一次之后,仍然得不到应答,等待2*500ms后再进行重传,如果还是
    得不到发送端的确认应答,此时就会等待4*500ms进行重传,依次类推,以指数形
    式递增,累计到一定的重传次数,TCP会认为网络或者对端的主机出现异常,强制
    关闭连接
    

    延迟应答

    一、什么是延迟应答?

    数据传输的时候,发送端给接收端发送数据,接收端给发送端发去确认应答信息,这样比较耗时,效率低下,延迟应答就是接收端收到数据之后,稍微等一会再应答,这样可以提高数据的传输效率,因为发送端发好几次数据,接收端只需要一次来确认应答,这样可以降低网络拥塞的概率

    二、所有的包都可以延迟应答吗?

    不是

    数量限制:每隔N个包就必须应答一次
    时间限制:超过最大延迟时间就必须应答一次

    ps:具体的延迟应答数量和超时时间,依操作系统不同也有差异,一般N取2,超时时间取200ms

    捎带应答

    什么是捎带应答?

    虽然有延迟应答,但是客户端和服务器在应用层还是还是”一发一收”,此时就会导致数据传输效率低下,捎带应答就是接收端在给发送端发送数据的时候,捎带着向发送端发去确认应答,应答的内容是接收端已经收到发送端发送的数据

    使用捎带应答之前:

    客户端:你好吗?
    服务器:我收到你发的消息了(接收端的ACK应答)
    服务器:我很好

    使用捎带应答时:

    客户端:你好吗?
    服务器:我很好(接收端给发送端发送的数据),我也收到你发的消息了(接收端的ACK应答)

    使用捎带应答后,ACK就可以搭顺风车了,在接收端给发送端发送数据的时候,ACK就可以捎带着给发送端发送过去

    展开全文
  • TCP协议格式 标红的位置        ...2.确认序号:Ack确认号占32位,客户端和服务器端都可以发送,Ack = Seq + 1。        &

    TCP协议格式

    在这里插入图片描述
    标红的位置
            1.序号:Seq序号占32位,用来标识从计算机A发送到计算机B的数据包的序号,计算机发送数据时对此进行标记。

            2.确认序号:Ack确认号占32位,客户端和服务器端都可以发送,Ack = Seq + 1。

    3.标志位:每个标志位占用1Bit,共有6个,分别为 URG、ACK、PSH、RST、SYN、FIN,具体含义如下:

    • URG:紧急指针(urgent pointer)有效。
    • ACK:确认序号有效。
    • PSH:接收方应该尽快将这个报文交给应用层。
    • RST:重新建立连接; 携带RST标识的称为复位报文段。
    • SYN:请求建立连接; 携带SYN标识的称为同步报文段。
    • FIN:通知对方, 关闭连接, 携带FIN标识的为结束报文段。
      其他位置:
              1). 源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;
              2). 4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部最大长度是15 * 4 = 60
              3).16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分.
              4).16位紧急指针: 标识哪部分数据是紧急数据;
              5).16位窗口大小: 占2字节,表示报文段发送方期望接收的字节数,可接收的序号范围是从接收方的确认号开始到确认号加上窗口大小之间的数据。

    确认应答机制 (保证TCP可靠性核心机制)

    举个例子:
    周末了 张三要约李四出去通宵打游戏

    在这里插入图片描述
    但是这里可能还会遇到一种情况
    假设张三发完第一条消息,紧接着再发一条"要不你请我通宵",
    但是网络传输中,可能会遇到"后发先至"
    本来李四是不想请客的,但是在张三看来是 不去通宵,但是可以请你(导致回复产生歧义)

    在这里插入图片描述
    为了避免这种情况的发生, 这时 我们就引入了 序号和确定序号 , 让消息更好的传输
    在这里插入图片描述
    确认序号是在TCP中表示接下来想要的下一条数据编号是啥,而不是收到的数据编号是啥

    在这里插入图片描述

    详细图解

    发送放收到应答数据的时候, 应答报文中的序号为1001,此时发送方就知道了, 1-1000的数据已经顺利抵达, 并且接来要发送的数据就是从1001开始的~~~
    在这里插入图片描述

    TCP将每个字节的数据都进行了编号. 即为序列号.(具体的编号规则)
    在这里插入图片描述

    超时重传机制

    可靠性,目的就是为了应对丢包~~~
    如果发生丢包情况,就进行重传数据~~
    举个例子:
    依旧使用 张三约李四出去通宵这个例子
    在这里插入图片描述
    但是 丢包是无差别丢包,张三发的消息可能会丢,李四回的消息也可能会丢
    在这里插入图片描述

    这样就会导致数据重复, 这个时候,TCP自身会处理重复的数据
    TCP有一个"接受缓冲区" TCP就会检查缓冲区中有没有重复的数据~
    根据内容去重,如果数据量太大,检查一遍,成本会很高
    所以可以根据序号去重

    超时重传等待时间间隔,不固定,而是逐渐变大
    假如张三给李四发完消息后,李四没有回应
    那么张三会过一段时间再发,仍然没有回应
    张三再过一会再发,如果还没回应, 张三就会以为李四有事,就不再发了
    重传到一定次数,就会断开连接
    假设丢包的概率是固定值,此时连续丢包的概率其实是比较小的
    一旦真的出现连续丢包,大概率是网络出现了问题
    所以TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间

    在这里插入图片描述

    展开全文
  • 确认应答机制 超时重传机制 滑动窗口机制 拥塞控制机制 慢启动 拥塞避免 快重传 快恢复 延时应答机制和捎带应答机制

    Linux:tcp协议——用这组图来了解确认应答机制、超时重传机制、滑动窗口机制、拥塞控制机制、延时应答机制和捎带应答机制

    确认应答机制

    TCP将每个字节的数据都进行了编号,这就是序列号:
    在这里插入图片描述
    在这里插入图片描述
    当主机A向主机B发送数据到主机B时,主机B会返回给主机A一个确认收到数据的信息。每个ACK都有对应的确认信号,意思是告诉发送方已经收到了确认序号之前的数据,下一个数据希望发送方从确认序号开始发送数据。

    超时重传机制

    超时重传有两种情况,一种是发送的数据丢失,另一种是ACK丢失。
    数据丢失
    在这里插入图片描述
    主机A发送数据给主机B,可能因为网络堵塞等原因,数据在传输过程中丢失了,导致其无法到达主机B,如果主机A在一个特定的时间间隔内没有收到B发来的确认应答,就会进行重发。
    ACK丢失
    在这里插入图片描述
    主机A未收到数据B发来的确认应答,也可能是因为ACK丢失了。这个时候主机B会收到很多重复数据,那么TCP协议需要能够识别出那些数据包是重复的包,并且把重复的丢弃(我们可以利用前面我们提到的序列号,做到去重的效果)。

    超时重传的超时时间如何确定的

    知道TCP的超时重传机制是什么意思以后,我们就想知道这个超时重传的时间是如何确定的?
    其实联系实际想一想,这个时间肯定不能太短,因为太短的话会引起很多报文的不必要重传;但是如果这个时间设置的过长,又会使网络的空闲时间增大,降低传输的效率。
    所以,TCP 采用了一种自适应算法,它记录一个报文发出的时间,以及收到相应确认的时间,这两个时间之差就是报文的往返时间(RTT)。
    最理想的情况下,找到一个最小的时间,保证确认应答一定能在这个时间内返回。Linux 中,超时以 500ms 为一个单位进行控制,每次判定超时重发的超时时间都是500ms 的整数倍;如果重发一次仍然得不到应答,等待 2 * 500ms 后再进行重传;如果仍然得不到应答,等待 4 * 500ms 进行重传,依次类推,以指数形式递增;累积到一定的重传次数,TCP 认为网络或者对端主机出现异常,强制关闭连接。
    总结
    RTO:超时重传时间,这个时间是动态变化的,并不是静态的
    RTT:报文往返时间
    RTO = 2*RTT

    滑动窗口机制

    我们在上面已经知道了确认应答机制,但是如果我们对每一个发送的数据段,都要给一个ACK确认应答,收到ACK以后再发送下一个数据段,这样做有一个比较大的缺点,就是性能比较差,尤其是数据往返时间比较长的时候。
    在这里插入图片描述
    既然这样一发一收的方式性能较低, 那么我们一次发送多条数据, 就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)
    在这里插入图片描述
    窗口大小指的是无需等待确认应答而可以继续发送数据的最大值. 上图的窗口大小就是4000个字节(四个段).也就是说,发送前四个段的时候, 不需要等待任何ACK, 直接发送;当收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;
    操作系统内核为了维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;窗口越大, 则网络的吞吐率就越高;
    在这里插入图片描述
    在这里插入图片描述

    那么如果出现了丢包的情况,又如何进行重传呢?这里也分两种情况:
    (1)数据包已经抵达,但是ACK被丢了
    在这里插入图片描述
    这种情况下,部分ACK丢了并不要紧,因为可以通过后续的ACK进行确认。
    (2)数据包丢丢失
    在这里插入图片描述
    这种情况下,当某一段报文丢失之后,发送端会一直收到1001这样的ACK,就像是在提醒发送端“我想要的是1001”一样,如果发送端主机连续3次收到了同样一个1001之后,就会将对应的数据1001-2000重新发送,这个时候接收端收到了1001之后,再次返回ACK的就是7001了(因为2001-9001)接受端其实已经收到了,只是被放到了接收端操作系统内核的接收缓冲区种了。

    注意:滑动窗口不是一成不变的,窗口的大小可能会收到网络因素和接受方缓冲区大小的影响
    窗口探测包:发送方主动向接收方询问,接收方的接受能力,接收方接受了之后,一定要回复大于0或者等于0,等于0(0号窗口)就表示自己接受不了了,不要在发送数据了。

    拥塞控制机制

    使用了滑动窗口之后,虽然能够高效可靠的发送大量的数据,但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题,因为网络上有很多的计算机,可能当前的网络状态就已经比较拥堵,在不清楚当前网络状态下,贸然发送大量的数据是很有可能雪上加霜的。这就和平时堵车是一个道理,如果这条路已经很堵了,而我们继续不停的把车往这条路上开的话,结果只能是越来越堵。

    慢启动

    为了解决上面的问题,TCP引入了慢启动机制,先发少量的数据,探探路,弄清楚当前的网络拥堵状况,在决定按照多大的速度传输数据。
    在这里插入图片描述
    这里我们引入一个概念叫拥塞窗口,发送开始的时候, 定义拥塞窗口大小为1,每次收到一个ACK应答, 拥塞窗口加1,每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;
    像上面这样的拥塞窗口增长速度, 是指数级别的. “慢启动” 只是指初使时慢, 但是增长速度非常快.为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍.此处引入一个叫做慢启动的阈值当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长
    在这里插入图片描述
    当TCP开始启动的时候, 慢启动阈值等于窗口最大值;在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1;少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;
    拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.TCP拥塞控制这样的过程, 就好像 热恋的感觉

    延时应答机制和捎带应答机制

    延时应答:我们知道, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;如果接收数据的主机在收到数据后立即返回ACK,应答,这时候返回的窗口就可能比较小。
    比如我们接受端的缓冲区为1M,一次收到了500K的数据,如果我们立刻应答,返回的窗口就是500K,但实际上可能处理端处理的速度很快,20ms之内就把500K的数据从缓冲区消费掉了,在这种情况下,接收端处理还远没有达到自己的 极限,即使窗口再放大些,也能处理过来,如果接受端稍微等待一会再应答,比如等待200ms再应答,那么这个时候返回的窗口大小就是1M。
    在这里插入图片描述
    注意:不是所有的包都要延时应答,又数量限制和时间限制
    数量限制:每隔N个包应答一次
    时间限制:超过最大延迟时间就应答一次
    具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms;

    捎带应答:在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的. 意味着客户端给服务器说了 “How are you”, 服务器也会给客户端回一个 “Fine, thank you”;那么这个时候ACK就可以搭顺风车, 和服务器回应的 “Fine, thank you” 一起回给客户端
    在这里插入图片描述

    展开全文
  • 确认应答机制 确认应答机制能够保证TCP协议的可靠性。 主机A发送的第一个TCP数据包中的序列号是1,发送的长度是1000个字节,说明1~1000个字节都发送过去了。1001表示小于1001序号的数据都已经到达接收端,接下来...
  • 确认应答机制 在将这部分的内容之前我们应该首先知道的一点就是,在TCP中,TCP将每个字节的数据都进行了编号,即为序列号(对每一个数据的编号)。 由图分析:当主机1给主机2发送了1~1000这么多数据时,主机2...
  • 确认应答(ACK)机制 在TCP中,当发送端的数据到达接受主机时,接受端主机会返回一个已收到消息的通知。这个消息叫做确认应答(ACK)。 TCP通过肯定的确认应答(ACK)实现可靠的数据传输。当发送端将数据发出...
  • TCP 是什么 TCP 为传输控制协议,在传输的过程中,主要保证数据的可靠性 TCP 的三个特点 有连接 可靠性 面向字节流 TCP 协议包 目的端口:解包 4位首部长度:分用 ACK:确认号是否有效 ...确认应答机制 ...
  • TCP协议段格式 TCP报头各部分意义: 16位源端口号和16位目的端口号:(各占两个字节)表示数据从哪个进程来,到哪个进程去 32位序号:占4字节。序号范围是0~2^32-1。...32位确认序号:4个字节...
  • TCP的确认应答(ACK)机制 在TCP中,当发送端的数据达到接收主机时,接收端主机会返回一个已收到消息的通知,这个消息叫做ACK(确认应答,PositiveAcknowlegementPositive AcknowlegementPositiveAcknowlegement) 通常...
  • TCP 确认应答/超时重传机制

    千次阅读 2018-08-16 15:01:27
    确认应答机制(ACK) TCP将每个字节的数据都进行了编号,即为序列号: 每一个ACK都带有对应的确认序列号,意思是告诉发送者,我们已经收到了哪些数据,下一吃发送数据应该从哪里开始。 如上图,主机A给主机B...
  • Kafka 消息确认机制 保证不丢失及手动确认消息 Producer保证消息传输过程中不丢失 事务 Consumer手动确认消息 全局配置 auto.offset.reset值含义解释 spring.kafka.listener.ack-mode 自建``...总结 Producer保证消息...
  • RabbitMQ学习记录(六)-应答机制

    千次阅读 2022-04-07 13:10:37
    RabbitMQ-消费者应答机制 队列持久化 消息持久化
  • Kafka Ack应答机制理解

    千次阅读 2020-09-03 14:59:48
    最近李哥做了kafka的调研,我看了他做的kafka与rabbitmq的对比与性能分析,打算深入了解一下kafka的ack应答机制 1.kafka基础大家可自行学习 2.这里我直接分析下ack应答机制,李哥的压测全部都是用的默认配置,ack...
  • 确认应答机制 TCP首部的确认号是期望收到对方的下一个报文段的数据的第一个字节的序号。TCP默认使用累计确认,即TCP只确认数据流中至第一个丢失字节为止的字节。例如,接收方B收到了发送方A发送的包含字节0-2和6-7...
  • 通过网络抓包来分析TCP到底是如何让传输变的可靠,记录TCP的确认应答机制,超时重传机制,滑动窗口机制,拥塞控制机制,捎带应答机制,延时应答机制
  • TCP协议的十个重要特性TCP报头保证可靠性的机制确认应答(ACK机制,可靠传输的最核心机制)超时重传 TCP是有连接,进行可靠传输,面向字节流的协议 TCP报头 先来分析分析每部分的含义和作用 源端口号/目的端口号: ...
  • Kafka中的ACK应答机制

    千次阅读 2019-11-18 15:16:53
    kafka中的应答机制: 对于一些不太重要的数据,对数据的可靠性要求不是特别高的情况下,能够容忍少量的数据丢失,因此没有必要等待ISR中所有follower全部要接收成功 所以Kafka为用户提供了三种可靠级别设置,可以...
  • CAN总线-ACK应答机制分析

    万次阅读 多人点赞 2019-02-26 19:46:12
    CAN总线-ACK应答机制分析 1:应答场定义 应答场长度为 2 个位,包含应答间隙(ACK SLOT)和应答界定符(ACK DELIMITER)。在应答场里,发送站发送两个“隐性”位。当接收器正确地接收到有效的报文,接收器就会在...
  • 确认应答机制(ACK,通过序列号实现) 超时重传机制 流量控制 拥塞控制 TCP实现可靠性与高效性的机制 确认应答机制 每个TCP数据段都有一个编号,叫做序列号。 在TCP中,当发送端的数据到达接收主机时,接收端主机会...
  • RabbitMQ手动应答机制-案例代码梳理

    千次阅读 2022-01-11 22:44:25
    RabbitMQ手动应答机制-案例代码梳理
  • SpringBoot整合RabbitMQ(六大消息模式、消息手动应答机制
  • RabbitMQ消息确认机制

    2019-09-03 19:26:24
    事务机制2. Confirm模式2.1 生产者2.1.1 普通Confirm模式2.1.2 批量Confirm模式2.1.3 异步Confirm模式2.2 消费者3. 其他 消费者如何确保消息一定能够消费成功呢? 由于在前面工作队列模式里面我们了解了应答模式,...
  • Ack应答机制 对于某些不太重要的数据,对数据的可靠性要求不是很高,能够容忍数据的少量丢失, 所以没必要等 ISR 中的 follower 全部接收成功。 所以 Kafka 为用户提供了三种可靠性级别,用户根据对可靠性和延迟的...
  • 1、消息确认机制(confirm) 为了确保消息能够准确的发送到Broker中,RabbitMQ提供了消息确认机制。 当生产者发送消息之后,如果Borker准确收到消息,则会返回给生产者一个应答。生产者通过接收到的应答判断消息是否...
  • 【RabbitMQ】消息应答--ack机制

    千次阅读 2022-01-30 19:46:44
    消息应答 概念 自动应答 消息应答的方法 Multiple 的解释 手动应答实现 1.准备工具类 2.生产者 3.两个睡眠时间不同的消费者 4.效果展示 消息自动重新入队 效果演示: 消息应答 概念 消费者完成一个...
  • 为了保证消息在发送过程中不丢失,rabbitmq 引入消息应答机制,消息应答就是:消费者在接收到消息并且处理该消息之后,告诉 rabbitmq 它已经处理了,rabbitmq 可以把该消息删除了。 3.2.2 自动应答 消息发送后立即被...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 47,046
精华内容 18,818
关键字:

确认应答机制