您的 .75 机器（客户端）发送“加密警报”消息。如果它这样做了，那么这台机器在那个时候认为连接仍在运行，服务器将能够接收到警报消息，尤其是解密它。否则，发送该消息有什么意义？因此，很可能在收到此警报后，已经发送了来自服务器的 FIN 消息。很可能，客户端发送一个触发连接关闭的警报，服务器通过关闭传输介质（FIN 数据包）做出反应。

请注意，在正常的握手中，服务器将等待Finished收到来自客户端的消息（在 之后的“加密握手消息” Change Cipher Spec），然后再发送它自己的Change Cipher Specand Finished。我们在这里看到，因此服务器能够处理Finished来自客户端的消息，包括解密、MAC 验证和消息内容。

假设两种实现都符合标准，“加密警报”消息不是close_notify警告。Aclose_notify是一条警告消息，它警告接收者发送者有意终止连接。然后，接收者必须用close_notify它自己的 a 来回复，表明它接受了这个事实。在这里，客户端发送了一条警报消息，但服务器没有发送警报消息作为响应，因此我们可能会推测我们没有目睹一对close_notify. 最有可能的是，客户的警报是致命的警报，它告诉服务器有什么不对劲，并且连接注定要失败。然后服务器只能关闭传输介质，因为此时它无能为力。

没有迹象表明是什么困扰了客户端足以使其发送警报；但是，有相当决定性的迹象表明所有加密操作都进行得很顺利。

您可能希望在两个系统上运行两次网络捕获，以便您可以获得所有数据包的精确计时；它有助于重建事件的实际顺序。