import sys from PySide6 import QtGui from PySide6.QtWidgets import QWidget,QApplication,QMessageBox class Message(QWidget): def __init__(self): # 如果希望窗口内嵌于其他部件,可添加parent参数 super(Message, self).__init__() # 调用初始化方法 self.initUI() def initUI(self): # 设置窗口的所在位置,以左上角为原点,x轴300, y轴300, 宽250, 长150 self.setGeometry(300, 300, 250, 150) # 给窗口一个标题名,你将会在标题栏看到这个名字 self.setWindowTitle('Message box') def closeEvent(self, event): # message为窗口标题 # Are you sure to quit?窗口显示内容 # QtGui.QMessageBox.Yes | QtGui.QMessageBox.No窗口按钮部件 # QtGui.QMessageBox.No默认焦点停留在NO上 reply = QMessageBox.question(self, 'Message', "Are you sure to quit?", QMessageBox.Yes | QMessageBox.No, QMessageBox.No) # 判断返回结果处理相应事项 if reply == QMessageBox.Yes: event.accept() else: event.ignore() def main(): # 创建qt的主应用 app = QApplication(sys.argv) # 实例化自己写的类 ex = Message() ex.show() # 应用关闭时返回0,sys关闭进程 sys.exit(app.exec_()) if __name__ == '__main__': main()
原因:sock断开的问题
存在的问题:
效果
通过抓包来验证猜想:
sock 在客户端进程关闭的时候,没有资源释放会导致服务端怎么样?
看下文心的解释:
当客户端进程关闭而其占用的 socket 资源没有正确释放时,这可能会对服务端产生以下影响: 资源泄露:服务端可能继续为已关闭的客户端连接保留资源,如文件描述符、内存等。如果这种情况频繁发生,随着时间的推移,这些未释放的资源可能会累积,最终导致服务端资源耗尽。 性能下降:服务端需要管理更多的“僵尸”连接,这可能会增加其处理开销,导致性能下降。 连接限制:大多数操作系统都有限制单个进程可以打开的文件描述符数量。如果客户端不释放 socket,服务端可能会达到这个限制,无法接受新的连接。 错误处理:服务端可能需要实现额外的逻辑来检测和处理这些“僵尸”连接,增加了复杂性和潜在的错误风险。 不稳定性和崩溃:在极端情况下,如果资源泄露足够严重,服务端进程可能会变得不稳定,甚至崩溃。 为了避免这些问题,建议: 正确关闭连接:确保客户端在关闭时正确关闭和释放所有 socket 资源。 服务端检测:在服务端实现心跳检测或其他机制,以识别和关闭不活动的或已关闭的客户端连接。 资源限制:设置合理的资源限制,如文件描述符的数量,并在达到限制时采取适当的行动,如拒绝新的连接或关闭最旧的连接。 日志和监控:实现日志记录和监控机制,以便及时发现和处理资源泄露问题。
进行实验测试:
1、服务器是telnet,将telnet 服务器设置为单链接状态
2、客户端使用自己写的telnet 进行连接,但是关闭主窗口的时候,不进行telnet sock的释放。
3、预测结果,telnet客户端关闭后,telnet服务器无法在进行登录,但是使用wireshark抓包可以看到tcp/ip连接的发起。
一、第一次正常的连接抓包显示,是正常的登录和交互:
二、对客户端进行不释放任何资源的关闭:
可以观察到 抓包软件中是没有任何报文交互的,没有tcp的四次挥手离开。这样对于telnet的服务来说,客户端是凭空消失了,并且服务器不知道客户端已经消失了。
三、在次发起telnet 客户端的连接,查看报文交互
在客户端断开一段时间后,tcp./ip进行了交互
四、在重复一下实验,在tcp没有自挥手前,进行tcp的连接
此时连接就会出现问题
五、等待一下,需要多久 telnet服务器可以恢复过来。
目前实验结果是符合猜想的,现在停止连接连接的过程,查看服务器主动释放在什么时候。
在大概四分钟的时候,服务器主动进行了资源的释放
接下来:需要查看telent服务器的设计,进行一个问题的总结