请问一个tcp协议累积确认问题-CSDN论坛

论坛帮助

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

请问一个tcp协议累积确认问题 [问题点数：20分，结帖人student2007]

⋅请问一个html问题？ ⋅请问一个ppt2003问题 ⋅请问一个sqlserver2000平台下sql语法问题 更多帖子 关注空间博客 student2007 本版专家分：0 结帖率 70.13%: 请问在tcp协议中什么是累积确认？请举个列子。谢谢

0 2008-09-20 07:52:59

回复数 2 只看楼主引用举报楼主

⋅新写的博客文章在RSS阅读器中看不到 ⋅[已处理]博客新发文章订阅显示不出来了 ⋅[已处理] 在招聘职位版块被封杀什么时候解除啊 更多帖子 关注空间博客 yanghehong 本版专家分：0 蓝花 2010年1月专题开发/技术/项目大版内专家分月排行榜第三 2008年11月专题开发/技术/项目大版内专家分月排行榜第三: 累积确认这个概念应该不只适用于TCP协议，也适用其他层，比如链路层。

一般地讲，如果发送方发了包1，包2，包3，包4；接受方成功收到包1，包2，包3。那么接受方可以发回一个确认包，序号为4(4表示期望下一个收到的包的序号；当然你约定好用3表示也可以)，那么发送方就知道包1到包3都发送接收成功，必要时重发包4。一个确认包确认了累积到某一序号的所有包。而不是对没个序号都发确认包。

具体到TCP，它对字节编号。比如发送方发了包1，包2，包3；包1含字节0到10，包2含字节11到20，包3含字节21到30。接受方成功收到包1，包2。那么接受方发回一个包含确认序号21的包，发送方就知道字节0到20(包1，包2)都成功收到，必要时要重发的只需从字节21开始。

-千里

2 2008-09-20 10:35:34

只看TA 引用举报 #1 得分 20

TCP协议为什么要累积确认，报文段的单独确认不是更高效，可以减少冗余发送？？？如题比如依次三个数据报 A B C，当前接收端收到了A和C，但是都到C时由于使用累积确认，ack是B的首字节序号，所以发送端不知道C已经被成功接收，如果超时，C也会重发，造成了发送冗余。但是单独确认

h1213025294 本版专家分：0: 我懂了谢谢，明天还发表呢

0 2012-04-10 22:52:32

只看TA 引用举报 #2 得分 0

累积确认累积确认这个概念应该不只适用于TCP协议，也适用其他层，比如链路层。一般地讲，如果发送方发了包1，包2，包3，包4；接受方成功收到包1，包2，包3。那么接受方可以发回一个确认包，序号为4(4表示期望下一个收到的包的序号；当然你约定好用3表示也可以)，那么发送方就知道包1到包3都发送接收成功，必要时重发包4。一个确认包确认了累积到某一序号的所有包。而不是对没个序号都发确认包。具体到T

收藏帖子

TCP重传与确认机制: TCP片段重传计时器以及重传队列:TCP按照以下特定顺序工作：1.放置于重传队列中，计时器开始包含数据的片段一经发送，片段的一份复制就放在名为重传队列的数据结构中，此时启动重传计时器。因此，在某些时间点，每一个片段都会放在队列里。队列按照重传计时器的剩余时间来排列，因此TCP软件可追踪那几个计时器在最短时间内超时。2.确认处理如果在计时器超时之前收到了确认信息，则该片段从重传队列中移除。3.重传

超时重传和累积确认是否会冲突？: 超时重传和累积确认是否会冲突？ 累积确认的一个ack会确认累积到某一序列号的所有包，这个过程会不会导致最先到达的那个包的确认超时？

TCP的核心系列 — ACK的处理（一）: TCP发送数据包后，会收到对端的ACK。通过处理ACK，TCP可以进行拥塞控制和流控制，所以 ACK的处理是TCP的一个重要内容。tcp_ack()用于处理接收到的ACK。本文主要内容：TCP接收ACK处理，tcp_ack()的实现。

TCP的工作原理,TCP的流量控制原理，滑动窗口，拥塞窗口，ACK累计确认等: TCP和UDP处在同一层---运输层，但是TCP和UDP最不同的地方是，TCP提供了一种可靠的数据传输服务，TCP是面向连接的，也就是说，利用TCP通信的两台主机首先要经历一个“拨打电话”的过程，等到通信准备结束才开始传输数据，最后结束通话。所以TCP要比UDP可靠的多，UDP是把数据直接发出去，而不管对方是不是在收信，就算是UDP无法送达，也不会产生ICMP差错报文，这一经时重申了很多遍了。

[面试时]我是如何讲清楚TCP/IP是如何实现可靠传输的: 1、概述众所周知，TCP/IP是面向链接的可靠传输协议，但是问题是如何实现可靠传输的呢？在我看来，TCP/IP可靠传输的基础是滑动窗口协议和连续ARQ协议，配合着流量控制和拥塞控制，使得整个传输过程保证：传输信道不产生差错不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据 2、滑动窗口协议和连续ARQ协议2.1、停止等待协议和自动重传请求(ARQ)所谓停止等待协议就是每发送完一个分组

TCP确认ACK与Kafka的ACK相通之处: TCP协议经常利用一个ACK来确认多个报文段，因为ACK是可以累积的。 Kafka消费者一般会隔一段时间提交一次offset，避免占用带宽，异曲同工之妙。

实验三 TCP Tahoe与Reno 运行机制对比分析: 1、安装NS22、Tahoe和Reno实验安装部分在虚拟机上安装NS2过程中遇到无数问题，现在将我大致的过程列举如下：步骤一：更新一下系统的安装包sudo apt-get update #更新源列表sudo apt-get upgrade #更新已经安装的包sudo apt-get dist-upgrade #更新软件，升级系统步骤二：安装ns2运行时...

网络基本功（十）：细说TCP确认机制: 网络基本功（十）：细说TCP确认机制转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese 介绍在TCP确认机制中，无法有效处理非连续TCP片段。确认号表明所有低于该编号的sequence number已经被发送该编号的设备接收。如果我们收到的字节数落在两个非连续的范围内，则无法只通过一个

白话讲解Nagle算法和延迟确认: 以前对nagle算法有耳闻，利用TCP_NODELAY选项可以禁止他。然后看到延迟ack时，心想TCP_NODELAY选项与他有没有关系呢。其实没有，TCP_NODELAY只是用来禁用nagle算法的。关于他们之间的关系倒可以好好研究下。有以下一个场景，村东和村西隔着一条大河，有几条船在两岸摆渡。由于每次要求过河的人只有一个，如果来一个人就将那个人摆渡过去（假设船只足够多），那势必运输效率非常低，...

17-TCP 协议（迟到的 ACK —— Windows ）: 1. 引言我们知道，TCP 协议中，需要对接收到 TCP 段进行确认。有两种方式可以减少 TCP 报文段. 一种是累积确认，另一种是捎带确认。 累积确认 有时候，发送方发送速度非常快，接收方一下下接收到了好几个 tcp 段，可以通过累积确认的方式，一次确认好几个 tcp 段，这样减少报文段的传输。捎带确认 有时候，双方互相发送数据，当接收到对方的 tcp 段后，先不着急确认，而是等待一会儿，连同数

TCP——停等ARQ&连续ARQ: 一、停止等待协议 概念：“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。 1、无差错情可以看到在a中是正确的传输。 2、出现差错而在b中的时候，因为M1有错，所以B直接丢弃掉了，然后发送方因为一直没有接收到确认，所以它等待一定的时间后，它就会认为发送超时了，进行超时重传。我们可以看到当A收到B对于M1的确认后，才继续发送M2。 3

TCP 确认应答/超时重传机制: 我们知道TCP协议是传输层协议，它是可靠传输，有连接的传输协议。那么它是依靠什么才能有这个功能的呢？ 确认应答机制（ACK） TCP将每个字节的数据都进行了编号，即为序列号：每一个ACK都带有对应的确认序列号，意思是告诉发送者，我们已经收到了哪些数据，下一吃发送数据应该从哪里开始。如上图，主机A给主机B发送了1-1000的数据，ACK应答，携带了1001序列号。告诉主机A，我已...

6-TCP 协议（序号和确认号）: 转载请注明出处：http://blog.csdn.net/q1007729991/article/details/69261780接下来的内容是学习后续内容的基础，必须先讲清楚。为了方便你回忆 TCP 首部，这里再次把这个图贴出来，以便对照。图1 TCP 首部 1. 序号序号占用 4 字节，即 32 位。它的范围是 [0,232−1][0, 2^{32}-1]，也就是说一共有 4 294

TCP协议可靠性保证（确认应答机制，超时重传机制，流量控制，拥塞窗口）: 上一次我们知道了TCP协议通过连接管理机制保证可靠性，今天我们继续来看一看TCP协议中其他几种保证可靠性的方法。 确认应答机制在将这部分的内容之前我们应该首先知道的一点就是，在TCP中，TCP将每个字节的数据都进行了编号，即为序列号（对每一个数据的编号）。由图分析：当主机1给主机2发送了1~1000这么多数据时，主机2如果收到了就会给主机1应答（ACK报文段，每一个ACK都带有对...

TCP延迟确认机制和SACK: 一 TCP的ACK原理和延迟确认机制 (1)ACK的定义： TCP协议中，接收方成功接收到数据后会回复一个ACK数据包，表示已经确认接收到ACK确认号前面的所有数据。字段长度是32位。 (2)ACK的作用发送方在一定时间内没有收到服务端的ACK确认包后，就会重新发送数据包。发送方收到了ACK，表明接收方已经接收到数据，保证了数据可靠传输。 (3)ACK机制接收方在收到数据后，...

传输层: 选择重传协议: 选择重传协议 返回N协议简化了接收方的处理过程.接收方只需跟踪一个变量,并且不需要对失序到达的分组缓存,而是简单地把失序到达的分组它们丢掉.但是如果低下的网络层协议丢失了很多分组,那么返回N协议的效率就会很低.每当一个分组损坏,发送方就需要重传所有待确认的分组,虽然其中有些分组实际上已经完好地被接收了. 选择重传协议(Selective-Repeat, S

网络学习-传输层TCP协议（确认应答与超时重发）: 等待更新

浅析TCP之SACK（选择性确认）: 1、SACK Selective Acknowledgement，选择性确认。 2、功能 TCP收到乱序数据后，会将其放入乱序队列中，然后发送重复ACK给对端。对端如果收到多个重复的ACK，认为发生丢包，TCP会重传最后确认的包开始的后续包。这样原先已经正确传输的包可能会重复发送，降低了TCP性能。为改善这种情况，发展出SACK技术，使用SACK选项可以告知发包方收到了哪些数据，发包方收到这

关于TCP的问题总结: 原地址http://iam42.iteye.com/blog/1703351 一. 什么是TCP TCP 协议是一种面向连接的，为不同主机进程间提供可靠数据传输的协议。TCP 协议假定其所使用的网络栈下层协议（如IP协议）是非可靠的，其自身提供机制保证数据的可靠性传输。在目前的网络栈协议族中，在需要提供可靠性数据传输的应用中，TCP 协议是首选的，有时也是唯一的选择。TCP 协议是在最

运输层协议:(2)Go-Back-N 协议: 返回N协议(GO-Back -N) 为了提高效率填满管道,在发送方等待确认时,应当有多个分组正在传送中.也就是说我们需要让多喝分组处于等待确认的状态,以便在发送方等待确认的同时,信道也能保持忙碌状态. 返回N协议(GO-Back -N GBN) 的关键是发送方能够在收到确认之前发送多个分组,但接收方只能缓存一个分组.发送方为发送出去的分组保留副本,直到来自接收方确认达到.

TCP协议滑动窗口与确认重传机制？: 字节流传输状态分类与滑动窗口的概念：①TCP协议使用以字节为单位的滑动窗口协议，来控制字节流的发送、接收、确认与重传过程。②接收窗口的大小由接收端根据缓存剩余空间的大小，以及应用进程读取数据的速度来决定。发送窗口的大小取决于接收窗口的大小。③发送窗口和接收窗口：发送窗口等于第二类和第三类的字节数之和=9+6=15。可用窗口长度等于第三类的字节数=5。即“尚未发送，但是接收端已经做好接受准备的字节”，

【网络基本功系列十】细说TCP确认机制: 介绍在TCP确认机制中，无法有效处理非连续TCP片段。确认号表明所有低于该编号的sequence number已经被发送该编号的设备接收。如果我们收到的字节数落在两个非连续的范围内，则无法只通过一个编号来确认。这可能导致潜在严重的性能问题，特别是高速或可靠性较差的网络。更多信息还是以下图为例，服务器发送了4个片段并收到1条回复，确认号为201。因

[计算机网络] TCP报文段中的序号和确认号: 本篇内容参考自：《计算机网络自顶向下方法》原书第六版前言序号字段和确认号字段是TCP报文段首部中两个最重要的字段，这两个字段是TCP可靠传输服务的关键部分。TCP把数据看成一个无结构的、有序的字节流。序号是建立在传送的字符流之上的，而不是建立在传送的报文段的序列之上序号一个报文段的序号是该报文段首字节的字节流编号，举个栗子~假设主机A的一个进程想通过一条TCP连接向主机B上的一个进程发送一个数据...

TCP Nagle算法&&延迟确认机制: 【转载链接】https://my.oschina.net/xinxingegeya/blog/485643 TCP Nagle算法 http://baike.baidu.com/view/2468335.htm 百度百科：TCP/IP协议中，无论发送多少数据，总是要在数据前面加上协议头，同时，对方接收到数据，也需要发送ACK表示确认。为了尽可能的利用网络带宽，TCP总是希望尽可能的发

TCP的工作机制详解: TCP的特点及其目的为了通过IP数据报实现可靠性传输，需要考虑很多事情，例如数据的破坏、丢包、重复以及分片顺序混乱等，TCP通过校验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制等实现可靠性传输。通过序列号与确认应答提高可靠性在TCP中，当发送端的数据达到接收主机事，接收机主机会返回一个已收到消息的通知。这个消息叫做确认应答(ACK, Positive Acknowledgement)。

TCP报文送达确认ACK: TCP数据包中的序列号（Sequence Number）不是以报文段来进行编号的，而是将连接生存周期内传输的所有数据当作一个字节流，序列号就是整个字节流中每个字节的编号。一个TCP数据包中包含多个字节流的数据（即数据段），而且每个TCP数据包中的数据大小不一定相同。在建立TCP连接的三次握手过程中，通信双方各自已确定了初始的序号x和y，TCP每次传送的报文段中的序号字段值表示所要传送本报文中的第一

TCP面试要点大全: 重点：三次握手，四次分手，TCP如何保证可靠性，TCP，UDP区别。背景描述通过上一篇中网络模型中的IP层的介绍，我们知道网络层，可以实现两个主机之间的通信。但是这并不具体，因为，真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机，但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信...

TCP的SACK选择确认选项: 1.前言 TCP通信时，如果发送序列中间某个数据包丢失，TCP会通过重传最后确认的包开始的后续包，这样原先已经正确传输的包也可能重复发送，急剧降低了TCP性能。为改善这种情况，发展出SACK(Selective Acknowledgment, 选择性确认)技术，使TCP只重新发送丢失的包，不用发送后续所有的包，而且提供相应机制使接收方能告诉发送方哪些数据丢失，哪些数据重发了，哪些数据已经

TCP的四种计时器: TCP共使用以下四种计时器：重传计时器、持续计时器、保活计时器和时间等待计时器。

TCP内部机制揭秘: TCP内部机制揭秘如需转载请注明出处：http://blog.csdn.net/qingyixiaoxia 微信号：qingyixiaoxia 一 TCP和UDP [一] 传输层概览传输层基本特性： 1. 端到端传输：传输层协议部署于网络边缘的终端节点之上，为应用层提供端到端的数据传输服务。传输层提供的服务呈现为SOCKET接口，通过使用SOCKET接口应用层可以...

什么是2MSL: MSL是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为tcp报文（segment）是ip数据报（datagram）的数据部分，具体称谓请参见《数据在网络各层中的称呼》一文，而ip头中有一个TTL域，TTL是time to live的缩写，中文可以译为“生存时间”，这个生存时间是由源主机设置初始值但不是存的具体时间，而是存储了一个ip数据报可以经过的最大路由数，每经过一个处理他的路由器

2MSL: 【什么是2MSL】　　MSL是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为tcp报文（segment）是ip数据报（datagram）的数据部分，具体称谓请参见《数据在网络各层中的称呼》一文，而ip头中有一个TTL域，TTL是time to live的缩写，中文可以译为“生存时间”，...

为什么TCP的TIME_WAIT状态要保持2MSL?: TIMEWAIT状态也称为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL(Maximum Segment Lifetime)。它是任何报文段被丢弃前在网络内的最长时间。我们知道这个时间是有限的，因为TCP报文段以IP数据报在网络内传输，而IP数据报则有限制其生存时间的TTL字段。 RFC 793 [Postel 1981c] 指出MSL为2分钟。然而

传输层学习之三（TCP数据传输）: TCP提供了可靠的传输服务，这是通过下列方式提供的：应用数据被分割成TCP认为最适合发送的数据块。由TCP传递给IP的信息单位称为报文段或段（segment）当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒TCP将保持它首部和

TCP序列号和确认号详解: TCP序列号和确认号详解在网络分析中，读懂TCP序列号和确认号在的变化趋势，可以帮助我们学习TCP协议以及排查通讯故障，如通过查看序列号和确认号可以确定数据传输是否乱序。但我在查阅了当前很多资料后发现，它们大多只简单介绍了TCP通讯的过程，并没有对序列号和确认号进行详细介绍，结合实例的讲解就更没有了。近段时间由于工作的原因，需要对TCP的序列号和确认号进行深入学习，下面便是我学习后的一些知识点总结

关于网络编程中服务器出现故障的三种情况（TCP协议）: 1 服务器主机崩溃模拟操作：当客户端和服务器成功连接之后，拔掉服务器的网线，此时从客户端发送数据分节。这样同时也模拟了客户端发送的数据不可达服务端的情景（即建立连接后某些中间路由器不工作）。产生后果：客户端会持续重传未收到确认的数据分节（TCP软件负责），持续一段时间后仍未收到确认则放弃（通常是9分钟）。如果是服务器崩溃则本机TCP软件会向用户进程显示套接字错误并置错误码

《计算机网络——自顶向下方法》读书笔记——运输层（UDP、TCP、滑动窗口）: UDP：首部8字节只提供最低限度的服务，多路分解、多路复用和差错检验。多路复用是从不同的套接字收集数据并发送，多路分解是将接收到的数据交付到不同的套接字。UDP的套接字是目的IP和目的端口号的二元组，而TCP的套接字是源、目的IP和端口号的四元组。缺点：没有流量控制和拥塞控制，丢包率高，不可靠；优点：无连接，没有建立连接的时延，首部小。可以在应用层实...

TCP协议的作用？三次握手是通过什么方法来保证通信双方确认的正确？: TCP协议的三次握手 TCP提供的可靠数据传输服务，是依靠接收端TCP软件按序号对收到的数据分组进行逐一确认实现的。这个过程在TCP收发端开始通信时，被称为三次握手初始化。三次握手的目的是使收发端的数据发送和接收同步，协调可以收发的数据量，建立虚连接。双方的TCP协议软件在交换数据时必须首先建立会话连接，然后才能够以数据分组为单位进行通信。接收端T

TCP第四次挥手为什么要等待2MSL: 当客户端进入TIME-WAIT状态的时候(也就是第四次挥手的时候)，必须经过时间计数器设置的时间2MSL(最长报文段寿命)后，才能进入关闭状态，这时为什么呢？？？这最主要是因为两个理由：1、为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传...

TCP为什么要3次握手和4次挥手时等待2MSL: 1.TCP为甚要3次握手？在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”，书中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但ser

TCP协议规定2MSL等待的原因: TCP协议规定主动关闭一方，进入FIN_WAIT_2->TIME_WAIT，必须等待2MSL（MSL为最大报文段生存时间）时间然后才进入CLOSED，删除TCP控制块。在2MSL等待时间内迟到的报文段将被抛弃。原因有二：保证TCP协议的全双工连接能够可靠关闭如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么

TIME_WAIT状态(2MSL)的作用: 主动关闭的Socket端会进入TIME_WAIT状态，并且持续2MSL时间长度，MSL就是maximum segment lifetime(最大分节生命期），这是一个IP数据包能在互联网上生存的最长时间，超过这个时间将在网络中消失。MSL在RFC 1122上建议是2分钟，而源自berkeley的TCP实现传统上使用30秒，因而，TIME_WAIT状态一般维持在1-4分钟。

Linux和Windows系统修改MSL的值: MSL，即Maximum Segment Lifetime，一个数据分片（报文）在网络中能够生存的最长时间，在RFC 793中定义MSL通常为2分钟，即超过两分钟即认为这个报文已经在网络中被丢弃了。对于一个TCP连接，在双方进入TIME_WAIT后，通常会等待2倍MSL时间后，再关闭掉连接，作用是为了防止由于FIN报文丢包，对端重发导致与后续的TCP连接请求产生顺序混乱，具体原理这里就不详

TCP/IP入门(3)---运输层据说是面试最主要的部分~~~: TCP/IP入门(3) --传输层 /** 本篇博客由汗青ZJF整理并发布, 转载请注明出处: http://blog.csdn.net/zjf280441589/article/category/1854365 */ 传输层的主要功能 1)传输层为应用进程之间提供端到端的逻辑通信(网络层是为主机到主机提供逻辑通信)。 2)复用和分用: 复用是指发送方不同的应用进程都可以使用同一个

TCP报文到达确认（ACK）机制: TCP所传输的数据的编号不是以报文段来进行编号的，而是将整个传输数据分成单个的字节流，并将每个字节流进行编号。一个TCP数据包中包括多个字节流的数据，而且每个TCP数据报中的数据大小并不一样。在建立TCP连接的三次握手过程中，通信双方各自已确定了初始的序号x和y,TCP每次传送的

TCP 滑动窗口（已经发出等待对方确认的队列）协议: 滑动窗口协议是TCP使用的一种流量控制方法，该协议允许发送方在停止并等待确认前可以连续发送多个分组。TCP是如何通过滑动窗口协议实现流量控制的?本博文将为您详细介绍该协议及其工作原理。什么是滑动窗口协议? 一图胜千言，看下面的图。简单解释下，发送和接受方都会维护一个数据帧的序列，这个序列被称作窗口。发送方的窗口大小由接受方确定，目的在于控制发送速度，以免接受方的缓存不够大，

TCP延迟确认: 简介 TCP延迟确认是由一些实现采用的技术，努力提高网络性能的传输控制协议 。从本质上讲，几个应答响应可能结合在一起，成一个响应，减少协议开销。然而，在某些情况下，该技术可以降低应用程序的性能。方法和优势 RFC 1122中描述，主机可能延迟发送ACK响应到500毫秒。此外，收到一个完整大小的TCP报文段，就要发送ACK响应。延迟ACK可以给应用程序的机会，一起发送更新的TCP

tcp如何保证数据包的顺序传输: 1.发送机在每次发送数据时，会给每个数据包分配一个序列号，并在特定的时间内等待接收机对发送机分配序列号的确认。 2.发送机将已经发送的数据存储在缓存中，如果特定时间内没有收到接收机对发送机分配序列号的确认，则重复发送此数据包，如果在定时器超时之前收到确认，则将数据包占用的缓存释放。 3.接收机收到数据包后按照序列号将数据包按顺序重组，并传给上层使用。

tcp4次挥手时，客户端为何要等2msl: tcp四次挥手最后的2MSL

A为什么等待2MSL，从TIME_WAIT到CLOSE？: 在客户端发送出最后的ACK回复，但该ACK可能丢失.Server如果没有收到ACK，将不断重复发送FIN片段。所以客户不能立即关闭，它必须确认服务器接收到了该ACK.Client会在发送出ACK之后进入到TIME_WAIT状态.Client会设置一个计时器，等待2 MSL的时间。如果在该时间内再次收到FIN，那么客户端会重发ACK并再次等待2 MSL。所谓的2MSL是两倍的MSL（最大段终身）.M...

TCP的2MSL问题: 2MSL (Maximum SegmentLifetime) TIME_WAIT状态的存在有两个理由：让4次挥手关闭流程更加可靠；4次挥手的最后一个ACK是是由主动关闭方发送出去的，若这个ACK丢失，被动关闭方会再次发一个FIN过来。若主动关闭方能够保持一个2MSL的TIME_WAIT状态，则有更大的机会让丢失的ACK被再次发送出去。防止lost dup

TCP四次挥手中,主动关闭方最后为什么要等待2MSL之后才能关闭连接?: 和TCP三次同步握手不一样的是,TCP关闭连接用四次挥手来实现,即A—–>B Fin,B—->A ACK, B—–>A Fin,A—-B ACK Ａ—-B Fin, B—->A ACK，A属于主动关闭方,收到B的ACK之后，A到B的方向连接关闭,即half shutdown，这时不能再发送数据了. 这种状态下B还是可以单向发送数据的,B的数据发送完毕,也可以做关闭动作了, B——>A Fin

TCP的ACK确认系列 — 快速确认: 主要内容：TCP的快速确认、TCP_QUICKACK选项的实现。内核版本：3.15.2 我的博客：http://blog.csdn.net/zhangskd 快速确认模式 (1) 进入快速确认模式设置快速确认模式标志，设置在快速确认模式中可以发送的ACK数量。 static void tcp_enter_quickack_mode (struct sock *sk)

简单说说TCP(2) --- 数据传输: 基本原理TCP提供可靠的数据传输服务。建立连接后，应用程序将数据提交给TCP，TCP将数据放入自己的缓存。TCP会将数据按照MSS的大小进行分段，并为每个分段加上TCP头部后提交给网络层。可靠性保障 确认到达 + 超时重传：防止丢包分组序列号：确保数据包的顺序检验和：防止信道上的bit错误流量控制（滑动窗口）：防止发送方太快而接收方太慢传输效率 “发一个TCP分组，等待一个ACK，再发下

运输层——TCP协议: 一、TCP协议概述 TCP协议——传输控制协议，可靠性连接协议。使用于一对一的可靠性传输数据的应用，比如打电话，电子邮件等等，基于http协议的web服务器，底层用的就是TCP协议，可见TCP协议的重要性。二、TCP的主要特点 a、TCP协议是面向连接的运输层协议。应用层在TCP连接之前必须建立TCP连接（三次握手），在传输完数据后要释放连接（四次挥手）。 b、TCP协议针对一对

TCP的ACK原理和延迟确认机制: 一、ACK定义 TCP协议中，接收方成功接收到数据后，会回复一个ACK数据包，表示已经确认接收到ACK确认号前面的所有数据。 ACK字段长度为32位，能表示0~2^32-1之间的值。二、ACK作用发送方在一定时间内没有收到服务端的ACK确认包后，就会重新发送TCP数据包。发送方收到了ACK，表明接收方已经接收到数据，保证了数据的可靠达到。三、ACK机制接收方在接收到...

浅谈TCP/IP协议栈(九)初始TCP协议: 上一节介绍了传输层的UDP协议，这一节开始介绍它的兄弟——TCP协议，通常计算机网络中最常见的一个名词就是TCP/IP协议栈，我们已经介绍过了IP协议，也知道IP协议是整个网络转发的基石，而TCP协议竟然还能排在IP之前，可见其重要性，因此我们会用较多的篇幅来介绍TCP协议。接触活血益一个协议之间，先弄清楚该协议的作用和特点，可以让我们很快上手，先来看看TCP协议的官方介绍： TCP（Transm

为什么TIME_WAIT状态还需要等2MSL才能返回CLOSED状态: （1）可靠的实现TCP全双工链接的终止。这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报

TCP 连接关闭的 TIME_WAIT (2MSL) 状态，及 TCP 连接状态图: 上学时画的 TCP 连接状态图，本来是为了搞清楚 socket 编程时的一个问题：客户端通常不绑定（bind()） inet 地址结构，而采用随机的端口建立连接 socket（connect()）。如果客户端绑定一个指定端口的 inet 地址，一般在运行完第一次客户端后，紧接着第二次运行客户端，就会出现客户端 socket 无法绑定先前的 inet 地址了，程序也就无法继续运行，大概过上几分钟后再运行客户端，绑定过程又恢复正常了。当时我知道一般客户端是不 bind() 地址的，因为这样就无法在一台主机上同时

居然很少有人质疑： 2MSL的TIME_WAIT时间真的足够保证旧连接上的所有包都消失吗？: 看了不少TIME_WAIT方面的书籍和网络文章，很多地方不过是在人云亦云的拷贝别人的说法和思想而已，看得让人颇为无趣。对于TIME_WAIT, 言必称2MSL, 当然，如果是笔试面试，我也会这么答，因为这就是所谓的标准答案啊。然而， 2MSL的TIME_WAIT时间真的足够保证旧连接上的所有包都消失吗？我最近一直在思考这个问题。从理论上来讲，这是扯淡。

25. 为什么客户端在TIME-WAIT状态必须等待2MSL的时间？: 1）为了保证客户端发送的最后一个ACK报文段能够达到服务器。这个ACK报文段可能丢失，因而使处在LAST-ACK状态的服务器收不到确认。服务器会超时重传FIN+ACK报文段，客户端就能在2MSL时间内收到这个重传的FIN+ACK报文段，接着客户端重传一次确认，重启计时器。最好，客户端和服务器都正常进入到CLOSED状态。如果客户端在TIME-WAIT状态不等待一段时间，而是再发送完ACK报文后立

TCP协议ACK延时确认时间的修改: 在系统中TCP协议的ACK发送有默认条件：2个包发送一次或者200ms发送一次这会导致在高性能条件下的数据延迟，下面我们将修改ack延时修改为0一、Linuxlinux下比较简单，在c语言中可以通过设置socket来实现 int quickack = 1; /* 启用快速确认，如果赋值为0表示使用延迟确认 */ setsockopt(fd, SOL_TCP, TCP_QUICKACK,

29-tcp可靠传输——选择确认选项（SACK）: 0. 为什么会有选择确认 前面讲的ARQ协议和滑动窗口协议确实保障了数据的可靠传输，随之而来的问题就是通信效率不高。因为在tcp通信时，计算机在传输连续数据第1，2，3，4分组时，中间的第2分组数据在网络中丢失了，tcp会重传最后确认的第2分组和后面的第3，4分组，导致第3，4分组被重复发送，降低了tcp性能，于是根据这种情况发展出了选择确认。 1. 什么是选择确认 关于选择确认...

TCP数据流—滑动窗口，拥塞窗口，慢启动，Nagle算法，经受时延的确认等: (1).窗口机制滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。下面举一个例子（假设

TCP可靠传输的实现原理: （这一节提到的可靠传输协议并不是TCP采用的，在这里提到只是为了对后面的TCP可靠传输的讲解起到铺垫的作用）我们知道，TCP发送的报文段是交给IP层传送的。但IP层只能提供尽最大努力服务，也就是说，TCP下面的网络所提供的是不可靠的传输。因此，TCP必须采用适当的措施才能使两个运输层之间的通信变得可靠。理想的传输条件有以下两个特点： 1）传输信道不产生差错。...

滑动窗口协议与慢启动: 滑动窗口协议:滑动窗口协议（Sliding Window Protocol），属于TCP协议的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输，提高网络吞吐量。（1）发送方不必发送一个全窗口大小的数据。（2）来自接收方的一个报文段确认数据并把窗口向右边滑动，这是因

为什么TIME_WAIT的时间是2MSL: MSL指的是任何IP数据报能够在因特网上存活的最长时间。 TIME_WAIT的状态是为了等待连接上所有的分组的消失。单纯的想法，发送端只需要等待一个MSL就足够了。这是不够的，假设现在一个MSL的时候，接收端需要发送一个应答，这时候，我们也必须等待这个应答的消失，这个应答的消失也是需要一个MSL，所以我们需要等待2MSL。（更多的内容参考《UNIX 网络编程》第3版 2.7 节）

《TCP/IP详解卷1：协议》笔记--2MSL等待状态: TCP的状态变迁图如下：其中的TIME_WAIT状态也成为2MSL等待状态。每个具体的TCP实现必须选择一个报文段最大生存时间MSL（maximum segment lifetime）。它是任何报文段被丢弃前在网络内的最长时间。我们知道这个时间是有限的，因为TCP报文段以IP 数据报在网络内传输，而IP数据报则有限制其生存时间的TTL字段。在RFC793指出MSL为2分钟，然

TCP四次挥手中的2MSL是什么？: MSL是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为tcp报文（segment）是ip数据报（datagram）的数据部分，具体称谓请参见《数据在网络各层中的称呼》一文，而ip头中有一个TTL域，TTL是time to live的缩写，中文可以译为“生存时间”，这个生存时间是由源主机设

深入浅出TCP协议的2MSL TIME_WAIT状态: 2MSL TIME_WAIT状态存在的理由： TIME_WAIT状态的存在有两个理由：（1）让4次握手关闭流程更加可靠；4次握手的最后一个ACK是是由主动关闭方发送出去的，若这个ACK丢失，被动关闭方会再次发一个FIN过来。若主动关闭方能够保持一个2MSL的TIME_WAIT状态，则有更大的机会让丢失的ACK被再次发送出去。（2）防止lost duplicate对后续新建正常链接的传输造成破

TCP释放连接时为什么time_wait状态必须等待2MSL时间(阅读笔记)？: 为什么上图中的A在TIME-WAIT状态必须等待2MSL时间呢？第一，为了保证A发送的最后一个ACK报文能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后就立即

TCP三次握手和漏洞解决: tcp三次握手一：TCP建立过程 1.服务器先创建TCB(传输控制块),准备接受客户端的连接请求，然后服务器处于listen状态 2.客户端创建TCB，准备发送请求连接报文段，此时首部的同步位syn=1(syn不携带数据，所以要消耗一个序列号)，选择一个初始序号seq=x,然后这时候，客户端从closed状态->syn-sent(同步已发送)状态。 3.服务器接收

必须掌握的协议-TCP: 网络层次模型，以及TCP头部格式

TCP/IP差错控制-确认和重传: 差错控制-确认和重传：一、发送端发送的数据帧由数据和检错码组成二、接收端用检错码判别数据帧是否出错三、如果数据没有出错，接收端向发送段发送确认应答（ACK）帧，发送端只有在接收到ACK帧后，才能确认数据帧正确地传输。四、如果数据出错了，那么接收端不发送ACK帧。发送端在规定时间内没有接收到ACK帧，再次发送数据帧。（但是ACK帧在传输过程可能丢失，...

运输层之 TCP 概述与可靠传输的原理: 每篇一句：生活需要平滑，但也需要一个方向，不能总是回到起点。——《三体 II：黑暗森林》 TCP 概述 TCP 介绍 TCP 最主要的特点： TCP 是面向连接的运输层协议。应用程序在使用 TCP 协议之前，必须先建立连接。在传输完数据后，必须释放已经建立的 TCP 连接每一条 TCP 连接只能有两个端点，每一条 TCP 连接只能是点对点的( 一对一 ) TCP 提供可靠交付的服务。通过 TCP 连...

TCP之拥塞处理详解: 网络拥塞现象是指到达通信网络中某一部分的分组数量过多，使得该部分网络来不及处理，以致引起这部分乃至整个网络性能下降的现象。拥塞控制是处理网络拥塞现象的一种机制。拥塞控制是一种用来调整传输控制协议（TCP）连接上单次发送的分组数量的算法，通过增减单次发送量逐步调整，使之逼近当前网络的承载量。

Time-wait状态(2MSL)一些理解: 1. 编写TCP/SOCK 服务时，SO_REUSEADDR到底是什么意思？这个套接字选项通知内核，如果端口忙，但TCP状态处于TIME_WAIT，可以重用端口。如果端口忙，TCP状态处于其他状态，重用端口时依旧指明“地址已经在使用中”。如果你的服务程序停止后向立刻重启，而新套接字依旧使用同一个端口，此时SO_REUSEADDR选项非常有用。但是必须意识到，此时任何非期望数据到达，都可能导致服

10、使用TCP协议完成一个客户端一个服务器。客户端从键盘输入读取一个字符串，发送到服务器。服务器接收客户端发送的字符串，反转之后发回客户端。客户端接收并打印。: /**10、使用TCP协议完成一个客户端一个服务器。客户端从键盘输入读取一个字符串，发送到服务器。服务器接收客户端发送的字符串，反转之后发回客户端。客户端接收并打印。 * 客户端*/ import java.io.*; import java.net.*; public class Test10_Client { public static void ma

捎带确认(piggybacking): 在计算机通信中，当一个数据帧到达的时候，接收方并不是立即发送一个单独的控制帧，而是抑制一下自己并且开始等待，直到网络层传递给它下一个分组。然后，确认信息被附在往外发送的数据帧上（使用帧头中的ask域）。实际上，确认报文搭了下一个外发数据帧的便车。这种“将确认暂时延迟以便可以钩到下一个外发数据帧”的技术称为捎带确认(piggybacking)。

HDLC协议介绍: 高级数据链路控制（High-Level Data Link Control或简称HDLC），是一个在同步网上传输数据、面向比特的数据链路层协议，它是由国际标准化组织(ISO)根据IBM公司的SDLC(Synchronous Data Link Control)协议扩展开发而成的.七十年代初，IBM公司率先提出了面向比特的同步数据链路控制规程SDLC（Ｓynchronous Ｄata Ｌink Ｃontrol）。随后，ANSI和ISO均采纳并发展了SDLC，并分别提出了自己的标准：A

TCP（传输控制协议详解）详解: TCP协议的特点（1）TCP协议是面向连接的运输层协议在数据传输前必须建立连接，数据传输之后释放连接。（2）TCP提供可靠交付的服务所谓可靠是指在传输过程中无重复，无丢失，无错误。但是同时会增加开销。（3）每一条连接都是点对点连接（一对一）（4）面向字节流所谓字节流指的是以传输过程中流入进程和流出进程的字节序列，虽然传输过程中是一个一个数据报，但这只是为了方便传输，之后在目的端重新装配。（5）TC...

TCP协议中的窗口机制------滑动窗口详解: 一、窗口机制的分类在TCP协议当中窗口机制分为两种：1.固定的窗口大小2.滑动窗口二、固定窗口存在的问题如下图所示：我们假设这个固定窗口的大小为1，也就是每次只能发送一个数据，只有接收方对这个数据进行了确认后才能发送第二个数据。在图中我们可以看到，发送方每发送一个数据接收方就要给发送方一个ACK对这个数据进行确认。只有接收了这个确认数据以后发送方才能传输下个数据。存在的问题：如果窗口过小，当传输比...

理解TCP序列号（Sequence Number）和确认号（Acknowledgment Number）: 原文见：http://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers/ 如果你正在读这篇文章，很可能你对TCP“非著名”的“三次握手”或者说“SYN,SYN/ACK,ACK”已经很熟悉了。不幸的是，对很多人来说，对TCP的学习就仅限于此了。尽管年代久远，TCP仍是一个相当复杂并且值得研...

TCP数据的编号与确认: TCP所传输的数据的编号不是以报文段来进行编号的，而是将整个传输数据分成单个的字节流，并将每个字节流进行编号。一个TCP数据包中包括多个字节流的数据，而且每个TCP数据报中的数据大小并不一样。在建立TCP连接的三次握手过程中，通信双方各自已确定了初始的序号x和y,TCP每次传送的报文段中的序号字段值表示所要传送本报文中的第一个字节的序号。 TCP的确认是对接收到的数据的最高序号的确认，

了解TCP的拥塞控制: 了解TCP拥塞控制的四种算法，即慢开始（slow-start）、拥塞避免（congestion avoidance）、快重传（fast retransmit）和快恢复（fast recovery）.说明本文基于《计算机网络》（第6版）进行总结

TCP 延时应答/捎带应答: 延时应答我们知道TCP中，有确认应答机制以保证数据的可靠传输。但是是不是接受方接受到数据就立即返回ACK应答呢？如果是这样，这时候的缓冲区中接收区的数据还没能够处理，缓存区的剩余大小就是窗口大小。但是如果我们延迟一会，等待缓存区中数据被处理，那么剩余的缓存区就会大些——这就是延时应答。 ps:假设接收端缓存区大小为1M，一次接收到了500K的数据，现在缓存区中剩余大小为500。但如果我们...

Tool哥第十八部力作_linux下的集群系统LVS和Heartbeat4nbbk1291下载: Tool哥第十八部力作_linux下的集群系统LVS和Heartbeat4nbbk1291 相关下载链接：[url=//download.csdn.net/download/lxyfish111/2009033?utm_source=bbsseo]//download.csdn.net/download/lxyfish111/2009033?utm_source=bbsseo[/url]

UNIX基本命令手册下载: UNIX基本命令，对于初学者是个很好的东西。相关下载链接：[url=//download.csdn.net/download/alan442/2099684?utm_source=bbsseo]//download.csdn.net/download/alan442/2099684?utm_source=bbsseo[/url]

数据结构C++版－－栈的实现及基本操作下载: 数据结构C++版－－栈的实现及基本操作程序代码是自己写的，但算法及思想都来源于网上…… 相关下载链接：[url=//download.csdn.net/download/catokat/2184461?utm_source=bbsseo]//download.csdn.net/download/catokat/2184461?utm_source=bbsseo[/url]

文章热词设计制作学习机器学习教程 Objective-C培训交互设计视频教程颜色模型
相关热词 mysql关联查询两次本表 native底部 react extjs glyph 图标 java tcp协议学习区块链协议

我们是很有底线的