CSDN论坛 > 网络与通信 > 网络通信

usb的数据包要求接收方返回一个ACK,这个ACK要driver发送吗? [问题点数:0分]

Bbs1
本版专家分:0
结帖率 50%
CSDN今日推荐
Bbs1
本版专家分:0
匿名用户不能发表回复!
其他相关推荐
TCP发送端收到ACK后对传输队列的4次扫描
TCP如果收到ACK后,不管是顺序ACK还是重复ACK(可能带有SACK选项),都可能对传输队列进行4次扫描,它们先后顺序分别是:1.第一遍扫面,分别做以下事情:1.1.标记被SACK的数据包1.2.标记哪些已经重传的包可能丢失1.3.更新网络乱序度reordering整个故事如下图所示:如果UNA向前推进了,我们就不多说了,如果没有推进UNA,而且有SACK标记(请注意,FACK并不是一种特殊的
TCP连接建立系列 — 客户端接收SYNACK和发送ACK
主要内容:客户端接收SYNACK、发送ACK,完成连接的建立。 内核版本:3.15.2 我的博客:http://blog.csdn.net/zhangskd   客户端主动建立连接时,发送SYN段后,连接的状态变为SYN_SENT。 此时如果收到SYNACK段,处理函数为tcp_rcv_state_process()。
TCP三次握手第三次握手时ACK丢失怎么办
当Client端收到Server的SYN+ACK应答后,其状态变为ESTABLISHED,并发送ACK包给Server; 如果此时ACK在网络中丢失,那么Server端该TCP连接的状态为SYN_RECV,并且依次等待3秒、6秒、12秒后重新发送SYN+ACK包,以便Client重新发送ACK包。 Server重发SYN+ACK包的次数,可以通过设置/proc/sys/ne
Linux 内核网络协议栈 ------ tcp_ack 函数处理接收到的ACK包之后
注意 tcp_ack 是来处理接收到的ACK的,那么到底怎么去做呢?看下面: 先还上把tcp_sock的结构放在这里,下面一些数据的分析需要用到: struct tcp_sock { /* inet_connection_sock has to be the first member of tcp_sock */ struct inet_conn
17-TCP 协议(迟到的 ACK —— Windows )
1. 引言我们知道,TCP 协议中,需要对接收到 TCP 段进行确认。有两种方式可以减少 TCP 报文段. 一种是累积确认,另一种是捎带确认。 累积确认 有时候,发送方发送速度非常快,接收方一下下接收到了好几个 tcp 段,可以通过累积确认的方式,一次确认好几个 tcp 段,这样减少报文段的传输。 捎带确认 有时候,双方互相发送数据,当接收到对方的 tcp 段后,先不着急确认,而是等待一会儿,连同数
TCP重发机制
TCP协议是一个可靠的协议。它通过重新发送(retransmission)来实现TCP片段传输的可靠性。简单的说,TCP会不断重复发送TCP片段,直到片段被正确接收。 TCP片段丢失   TCP头部的checksum 接收方(receiver)可以通过校验TCP片段头部中checksum区域来检验TCP片段是否出错。我们已经接触过了IP协议详解的checksum算法
TCP的ACK确认系列 — 发送状态转换机
主要内容:TCP的ACK发送方式,以及ACK发送状态转换机的实现。 内核版本:3.15.2 我的博客:http://blog.csdn.net/zhangskd   概述   TCP采用两种方式来发送ACK:快速确认和延迟确认。 在快速确认模式中,本端接收到数据包后,会立即发送ACK给对端。 在延迟确认模式中,本端接收到数据包后,不会立即发送ACK给对端,而是等待一段时间,如果在此
流量整形,延迟以及ACK丢失对TCP发送时序的影响
TCP是一个连续不断的涓涓细流或者滚滚长江,但这只是理想情况!经过诸多中间网络设备,最终一个TCP流到达接收端的时候,将可能不再保持一个流的形式,而变成了一阵阵的突发...这些突发产生的ACK反过来反馈到发送端,进而对发送端的发送时序产生影响,也就是说对发送端的数据流进行整形,这真是一个典型的涡轮增压反馈系统,根本不是通常认为的那样不可控或者说另一个极端,仅仅是端到端!想驾驭它其实不是那么难,如果
四-网络性能排查之TCP重传与重复ACK
TCP错误恢复功能: TCP的错误恢复功能是定位,诊断及修复网络延时的最佳工具。延时可以在单程也可以往返方向测量。高延时是网络管理员的头号大敌。本节我们讨论TCP高延时是如何导致序列号和确认号乱序的。 TCP重传: 主机报文重传是TCP最基本的错误恢复功能,它的目的是防止报文丢失。 报文丢失的可能因素有很多种,包括应用故障,路由设备过载,或暂时的服务宕机。报文级别速度是很高
TCP的接收缓冲区满了,收到数据后会向发送方发送ACK吗?该怎么解决
TCP的接收缓冲区满了,收到数据后会向发送方发送ACK吗? TCP的发送缓冲区中的数据,如果收不到接收方的ACK就不会删除,导致发送缓冲区溢出。如果接收方的缓冲区满了,收到数据后会不会向发送方发ACK呢?如果不发ACK,那么就没有接收缓冲区溢出的概念了,只要控制住发送方,就不会丢包;如果发ACK,那发送方就没办法控制是否继续发送了,接收缓冲区就会造成溢出,导致丢包。事实是怎样的呢?我这样理解正确
关闭
关闭