TCP上传文件时的ACK变化？在一个tcp连接中，如果仅仅是客户端一方在一直上传文件，而且另一方的服务器接收到包以后会发送确认ack包，那么这个包的数据内容有长度吗？或者换一种问法，这种情况下客户端对服务器发送的数据包的ack字段变不变？(不是正常的ack和seq依次递增情况)，服务器明明没有数据要发送的，那么客户端的ack字段是可以一直不变的吧。
大家应该知道TCP的ACK含义了，就是给对方发送一个确认消息，以示字节编号 < 确认号(Acknowledge Number)的所有字节数据已经安全抵达目的地。
Alice给Bob发数据，Bob的TCP需要确认Alice的TCP，对吗？题主的问题来了，Alice需要给Bob确认吗？
如果Bob没有数据需要发给Alice，Alice的TCP想ACK对方也没有机会，所以Alice的TCP压根不会发什么ACK，ACK确认号会原地踏步，保持静止。
如果Bob有数据要发给Alice，Alice的TCP同样也要ACK对方，而Alice的确认号也要随着接收到对方字节数据慢慢增长而不断增长，这是水涨船高的对应关系。
接下来看当Alice给向Bob传输文件时，Bob到底有没有数据需要传输给Alice？
使用http传输文件，而http协议使用的是Request/Response的交互，传输文件时，Alice的文件数据切割成N个小段，提交给TCP传输，穿越网络，数据到达Bob的 TCP， TCP确认。稍后数据到达Bob的http，此时Bob仅仅是将数据缓存起来，等待完整的文件数据到来，不要做其它的了吗？
Alice如何在web页面看到自己的文件上传进度条呢？
Bob的http将当前网页的页面更新部分推送给Alice，使得Alice能够实时地知晓自己文件上传进度。于是，Bob的http将更新的网页提交给TCP传输，穿越网络，到达Alice的TCP，需不需要TCP来ACK？
当然需要！
退一步来说，Bob不推送更新的页面给Alice，仅仅是缓存数据，耐心等待接收完整的文件数据。这是Bob的TCP确实没有什么字节数据好发送。写到这里，突然想到一句很有名的广告词：“某某山泉，我们不生产水，我们只是大自然的搬运工”！
用在这里再合适不过，“TCP不产生数据，TCP只是应用层字节数据的搬运工”，数据的源头在应用层(这里为http),而不是TCP!
Okay，Alice很郁闷，连文件上传的进度条也看不到。不一会儿，全部文件到达Bob，知道这个事实的是Bob的http，文件全部传输完毕了，总要通过http response 将文件上传成功的页面推送给Alice。很显然数据就这样产生了，Bob的数据会很快到达Alice的TCP，TCP会立马ACK走起，ACK确认号与对方的字节数据呈现同步增长。
如果题主说，这不是我想要的答案，文件上传使用的是私有协议，文件上传完毕时，接收方什么都不要做，文件上传的一方一旦文件传输完毕，立马关闭连接，Alice的ACK确认号是否一直永恒不变？
No！
假设，双方建立TCP时，Bob的字节原点的序列号(ISN)= 2000，谁占据这个编号呢？
Bob的SYN！
在通信过程中，Alice的ACK号一直为2001，因为Bob一直没有数据传输给Alice。
关闭连接时，Bob的TCP会发FIN关闭连接，Sequence Number = 2001，谁占据这个2001编号？
当然是Bob的FIN了！
Alice怎么ACK确认？
Alice发确认号(Acknowledge Number)= 2002
很显然，Alice的确认号从2001变化到了2002，并不是恒定不变的！
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
