我一直在学习计算机网络方面的书(这不是作业题)其中一个问题比较了基于ACK和NAK的数据传输协议(protocol)，重点是对于基于NAK的协议(protocol)，当接收到第(x+1)个数据包时，接收方可以检测到数据包x的丢包.但是，我的问题是，如果接收方发送的NAK在到达发送方之前丢失了，会发生什么情况？发件人不会意识到错误，也不会重新传输。此外，如果数据包是序列中的最后一个数据包怎么办？(没有后续数据包可以测试)我看不出只有NAK的协议(protocol)如何可靠(以正确的顺序传送每个数据包) 最佳答案 我怀疑书中描述的理论背

我有一个应用程序使用TCP套接字来交换字节数组，这些数组在大多数情况下包含JSON字符串数据。我遇到的是，对于较大的消息和不太理想的网络条件，使用NetworkStream.DataAvailable似乎不是检测消息结束的可靠方法。似乎在某些情况下DataAvailable被设置为false，即使只有部分消息已被对等方传输(使用TcpClient.GetStream().Write(data,0,data.Length)。这会导致不完整的数据被传回应用程序，在JSON消息的情况下，这意味着反序列化失败。我尝试了两种表现出相同问题的实现:实现1:byte[]Data;byte[]buff

我现在正在学习网络类(class)，并试图了解这三种协议(protocol)的用处。我知道他们正在努力使不可靠的链路层(IP)变得可靠。它们实际上在任何地方实现吗？TCP是否实现了其中的任何一个？就此而言，除了TCP和UDP之外，还有其他协议(protocol)在传输层上运行吗？我正在使用Kurose&Ross的《ComputerNetworking》一书。非常感谢任何帮助! 最佳答案 “三个协议(protocol)用在什么地方，我理解他们是在努力让不可靠的链路层(IP)变得可靠。”首先，不要将RDT与GBN和SR混淆，因为GBN和

我无法弄清楚一件事。RFC2616in4.4.5声明消息长度可以“通过服务器关闭连接。”确定。这意味着，服务器响应(例如返回大图像)是有效的，响应中没有Content-Lengthheader，但客户端应该保持获取直到连接关闭，然后假设所有数据都已下载。但是客户端如何确定连接是服务器故意关闭的呢？服务器应用程序可能在发送数据的过程中崩溃，服务器的操作系统很可能会发送FIN数据包以正常关闭与客户端的TCP连接。 最佳答案 你是对的，那个机制是完全不可靠的。这包含在RFC7230中:Sincethereisnowaytodistingu

我一直在编写服务器-客户端应用程序。服务器是用c#编写的，客户端代码是用java编写的。通信协议(protocol)是TCP。使用tcp传输文件时，可能会发送丢失的数据。换句话说，tcp是否保证数据正确到达。(我是否应该发送此文件的header信息以检查错误，如文件大小、哈希等) 最佳答案 可靠的tcp传输os的包排序。例如，您的tcp消息分为三个包A、B和C。您的客户端收到A，包B丢失，然后客户端收到C。在流中，您将仅获得包A，包C被存储，一旦包B被您的客户端重新传输和接收，在流中您将获得包B，然后是C。如果包B通过另一种方式路由

有没有一种方法可以使用java.net.*中的JavaTCP/IP库进行可靠的通信(发送方获知它发送的消息已被接收方接收)？我知道TCP相对于UDP的优势之一是它的可靠性。然而，我无法在下面的实验中得到这种保证:我创建了两个类:1)echoserver=>总是发回它接收到的数据。2)client=>定期向回显服务器发送“Helloworld”消息。它们在不同的计算机上运行(并且运行良好)。在执行过程中，我断开了网络连接(拔下了LAN电缆)。断开连接后，服务器仍在等待数据，直到几秒钟过去(最终引发异常)。同样，客户端也一直发送数据，直到几秒钟过去(引发异常)。问题是，objectOutp

很难说出这里要问什么。这个问题模棱两可、含糊不清、不完整、过于宽泛或夸夸其谈，无法以目前的形式得到合理的回答。如需帮助澄清此问题以便重新打开，visitthehelpcenter.关闭10年前。作为个人项目的一部分，我正在制作一个可靠的应用程序级协议(protocol)(封装在UDP中)。为了实现可靠性，我必须跟踪我发送了哪些数据包，以及在另一端接收了哪些数据包。这是在滑动窗口的帮助下完成的，它还保持了流量控制。除了标准的滑动窗口/流量控制技术之外，是否还有其他方法可以实现可靠性。如果否，是否有人会分享他的经验/设计原理/代码并在这篇文章中进行讨论。如果是，您是否已实现它，或者您是否知

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visitthehelpcenter指导。关闭9年前。虽然TCP是一个提供重传和确认机制的可靠协议(protocol)，但我认为它不是100%可靠的，因为send()的成功返回并不能确保数据已经到达目标端点，只意味着数据是复制到内核缓冲区。有没有什么机制让应用知道数据是否成功到达目的地？一种可能的解决方案是在应用层中建立某种确认机制？

许多游戏开发者选择在应用程序级别中制作UDP可靠。TCP不正是为此而生的吗？我制作了一个API，可以使用UDP和TCP数据包启用客户端-服务器通信。我应该将ReliableUDP添加到列表中吗？为什么？如果我使用TCP会有问题吗？我只是想知道RUDP是否比TCP有任何优势，以便我可以选择是否添加RUDP支持。 最佳答案 简短回答:TCP没有针对延迟进行优化(根本没有)；结果-它有几个属性，这些属性是游戏的延迟killer(尽管它们只有在数据包丢失时才会发挥作用)。特别是，线头阻塞和指数退避对于快节奏游戏来说往往非常烦人。对延迟影响最

速度、优化和可伸缩性是Udp和Tcp协议(protocol)之间的典型比较。Tcp吹捧可靠性，缺点是有一点额外的开销，但速度非常好。一旦Tcp套接字被实例化，保持套接字打开需要一些开销。但与经常描述的Udp负担相比，究竟哪个协议(protocol)的开销更大？我还听说Tcp存在可伸缩性问题……但是互联网(网页/服务器)在Tcp上运行-那么Tcp是什么抑制了可伸缩性？好的...所以Udp不需要保持连接打开的开销。但是，它需要您编写额外的方法来确保所有数据包都到达那里，希望按照您希望的顺序接收。如果没有收到完整的数据包，则必须告诉客户端或服务器重新发送。并且您还必须为部分数据包保留某种消息