技术宅的结界

 找回密码
 立即注册→加入我们

QQ登录

只需一步,快速开始

搜索
热搜: 下载 VB C 实现 编写
查看: 58|回复: 1
收起左侧

【翻译】【TCP】关闭连接的讲究

[复制链接]

1020

主题

2262

帖子

5万

积分

用户组: 管理员

一只技术宅

UID
1
精华
201
威望
271 点
宅币
17264 个
贡献
34495 次
宅之契约
0 份
在线时间
1635 小时
注册时间
2014-1-26
发表于 7 天前 | 显示全部楼层 |阅读模式

欢迎访问技术宅的结界,请注册或者登录吧。

您需要 登录 才可以下载或查看,没有帐号?立即注册→加入我们

x
原文网址:https://developer.att.com/video- ... closing-connections
译者:0xAA55

介绍

移动应用通常在完成数据传输、不再需要连接后,依然保持连接状态,即使已经不需要使用这个TCP连接了。这样的问题通常由于连接的关闭过程没有被正确进行(比如关闭连接的时候遭遇丢包、高延迟等),而关闭一个连接本应是通讯的一个重要环节。这个连接最终由于超时而被关闭。这是一个非常低效的方式来关闭一个TCP连接。

最好在传输数据后尽快关闭连接,以防止无线电信道不必要地保持打开状态。

下图(图1)说明了无效关闭的连接问题。该图显示了AT&T视频优化器诊断工具的“诊断”选项卡中的“跟踪”图表。视频优化工具从应用程序收集跟踪数据,根据建议的最佳实践对其进行评估,并生成分析结果。

BestPractice4.png
图1:跟踪结果显示连接延迟终止。

在上图的“Bursts”行里,第10到40秒左右的红色和绿色部分表示数据传输。第80秒附近有一条蓝色的细线表示连接关闭。

在“Bursts”行下面的“RRC States”行,表示的是无线电传输设备的运行状态,可以理解为功耗。它有个高供能状态、低供能状态和关闭状态。可以看出,设备在传输数据之后就进入了空闲状态,然后设备进入低供能状态并关闭。然而,在第80秒处,设备为了发送一条TCP关闭连接的报文,它需要被重新开启,然后发送数据,再进入高供能、低供能状态并关闭,造成能量浪费。而如果你在完成数据的传输后就立即关闭连接的话,就能省下这些事,让无线电设备不用被再次唤醒。

刚才的实践充分证明了及时并有效地关闭TCP连接的重要性,并且能更直观地看出不这么做带来的功耗损失。

背景知识

在通常的操作情况下,传输的两端都在同时进行传输和接收数据的过程。连接的终止通常由其中一端主动发出信号来表明自己想要关闭连接,但要正常关闭连接需要多个步骤进行来保证连接能被优雅地关闭。

要了解这些要求,记住两个TCP标志很重要:
  • ACK  - 表示确认。 客户端发送的初始SYN数据包之后的所有数据包都应设置此标志。
  • FIN  - 表示发送方将不再发送数据。


当TCP会话的任一侧完成发送数据时,它可以发送FIN信号以关闭连接。当对方收到FIN时,它必须通知应用程序对方正在关闭传输。发送FIN通常是应用程序关闭套接字的结果,另一方通过ACK确认。

即使使用三次握手(SYN,SYN-ACK,ACK)建立TCP连接,也可以通过各种方式终止它,包括以下内容:
  • 其中一方发送FIN数据包,另一方发送ACK,然后开始四次握手来终止整个TCP会话。四次握手结束后,两边在真正关闭连接之前等待一段时间。这段时间里,相同的端口不能发起新连接。它可以防止延迟传递的数据包引起后续的同端口新连接的混淆。
  • 当其中一方发送FIN,另一方发送FIN & ACK,然后自己再发送ACK,可以完成一场三次握手终结连接的过程。
  • 当双方同时发送FIN & ACK的时候,就可以完成一场两次握手终结连接的过程。

无论使用哪种方法终止TCP连接,重要的是要注意它们都是主动进行的终止连接的过程。

问题

如果没有主动关闭TCP连接,则会出现此问题。如果连接未按设计关闭,则可能会因超时而关闭,作为连接的管理的一部分。

TCP协议为了解决这样的问题而制造了“超时”的概念。服务器通常会在一个连接处于空闲的状态下对其进行计时,超时后就会将其关闭。如果一个连接本来已经结束了它的传输,但如果其中一方没有收到另一方的主动关闭连接的请求,它就会一直等待对方的通信直到超时。这是不必要的资源消耗。

如果一个携带了数据的终止传输的报文没有被接收端正确处理(只接收了数据,没有判断它是否为终止连接的请求),这就会导致服务端一直等待客户端(咕咕咕)直到超时。对于无线传输而言,这通常会引起无线网卡设备被启动用于终止连接。根据图1,可以看到无线电设备先进入高供电状态,再进入低供电状态,最后关闭。

这会让使用电池的设备浪费更多的电能。

最佳实践建议

那就是在数据完成传输后迅速关闭TCP连接。这可以防止设备只为了关闭连接而重启无线网卡设备,使其不需要等到TCP超时机制后再发送一个断开连接的报文。这能节约计算机的算力和内存,以及电池的电量,免得让空闲状态被关闭的无线网卡又要被唤醒,然后只发送一个断开连接请求的报文,再重新变得空闲并关闭。

1020

主题

2262

帖子

5万

积分

用户组: 管理员

一只技术宅

UID
1
精华
201
威望
271 点
宅币
17264 个
贡献
34495 次
宅之契约
0 份
在线时间
1635 小时
注册时间
2014-1-26
 楼主| 发表于 7 天前 | 显示全部楼层
这篇AT&T的文章真是废话繁多,就好像是写给一个不懂服务器运维,并且手撸TCP报文的物联网玩家看的。

对于我们平时使用socket来进行TCP通信的情况下而言,我认为更需要去注意的是自己使用TCP进行数据传输的逻辑。不管是阻塞型IO还是非阻塞型、自制状态机方式的IO,有一个坑是需要注意的,那就是shutdown()把关闭连接的请求加入发送缓冲区队列的尾部,并让你的socket进入FIN_WAIT1状态——在某些平台上,如果你的发送缓冲区满了,它就不会发出关闭连接的请求,却让你的socket进入FIN_WAIT1的状态。在关闭连接的时候,需要务必确保所有的数据都发出去了,或者发送缓冲区空,或者使用别的方法丢弃需要发送的数据然后强行关闭——这个办法虽然会引起对方无法收到关闭的请求。

本版积分规则

QQ|申请友链|Archiver|手机版|小黑屋|技术宅的结界 ( 滇ICP备16008837号|网站地图

GMT+8, 2019-2-18 16:11 , Processed in 0.094175 second(s), 39 queries , Gzip On.

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表