【案例】如何解决SSL访问缓慢问题

共计 1479 字 | 建议阅读时间 3 分钟

问题描述

故障背景

某银行用户反映银行网银系统有时访问较慢，主要现象为打开登录界面需很长时间，严重影响了用户体验和企业形象。

网络拓扑

网银系统的网络环境示意图如下：

图?1

客户端访问网银系统外网地址，然后经过F5负载均衡设备转发数据，直接访问SSL加密设备，再通过SSL设备转发给网银系统WEB服务器。

本案例选择在网络出口以及SSL加密设备出口进行部署科来网络回溯系统进行数据分析。

分析方案设计

分析思路

结合网银系统网络拓扑及数据的走向，网银系统访问较慢的原因有以下几点：

网银系统访问流量太大，出口链路拥塞；
网络响应延时较大；
网络设备转发故障；
网银服务器本身响应较慢。

整体流量分析

对1小时内网银系统外网出口流量进行统计，总流量为919MB，峰值流量为5Mbps，平均流量为2.2Mbps。如下图：

图?2

网络延时分析

在TCP的连接过程中，客户端和服务器端在网络中共传输三个数据包，俗称三次握手，这三个数据包都是小包，没有实际有效数据载荷。服务器端对客户端TCP SYN的请求在系统底层响应，响应非常快，该响应同数据包在网络中传输的延迟比可忽略，同时由于都是小包，网络传输延迟非常小，因此在数据包分析中可以通过三次握手数据包的时间间隔来确定网络的传输延迟，如图所示：

图?3

如上图所示，当我们在客户端和服务端的网络中某一点捕获到客户端同服务端的TCP三次握手数据包时，三个数据包在流量分析设备捕获到的时间分别为T1,T2,和T3，这种情况下T2-T1的值可以认为是数据包从捕获点网络传送到服务器然后服务器在传回捕获点的RTT（Round Trip Time）,而T3-T2的值为数据包从捕获点传送到客户端然后从客户端传送回捕获点的RTT，T3-T1的值可以认为是从客户端到服务器的RTT。

随机选择系统外网出口多个完整的TCP会话，通过对TCP三次握手时间进行分析，发现服务端在收到客户端的链接请求后，都在1ms以内给予了响应。说明网银系统内部网络正常，不存在延时。如图：

图?4

网银系统性能分析

对外网出口流量进行分析，重点分析持续时间较长的TCP会话，发现部分会话存在异常。如下图：

图?5

通过TCP交易时序图可以看出，服务端在对客户端的第一个请求进行确认后，经过了7秒才发出了响应数据包。这段时间应该就是导致客户端访问网银系统缓慢的直接原因。

为了确定这个延迟产生的具体原因，分析SSL加密设备进出数据，找出相同源IP的TCP会话数据进行对比，发现在SSL加密设备出口处同样出现服务器端在很长时间后才发出响应数据。如图：

图?6

外网出口出现的故障现象在SSL加密设备出口同样存在，证明这段延迟不是在SSL加密设备之前产生，F5到SSL加密设备之间的网络正常。

进一步分析SSL加密设备和网银服务器交互数据，由于这部分数据是没有进行加密传输的，因此无法准确定位到之前分析的同一个TCP会话。而通过对大量TCP会话的对比分析，发现SSL加密设备和网银服务器之间的数据传输很快，所有会话都是在1S之内完成，基本不存在响应延时情况。如图：

图?7

通过以上的分析，基本可以判定由于SSL加密设备造成了网银系统访问缓慢的原因。而SSL加密设备在进行数据加密之前，会进行一个密钥的协商，具体过程如下图：

图?8

结合故障数据包分析，可以发现出现延时的数据包是由SSL加密设备向客户端响应的Server hello数据包，因此更加可以肯定SSL加密设备就是造成故障的根本原因。

分析结论

通过以上信息，我们可以做出如下判断：

链路流量值不大，流量趋势稳定，没有明显的递增或递减趋势，监控链路不存在持续性拥塞问题；
网银系统内部网络正常，网络延时很小；
网银系统访问缓慢，应该是由于SSL加密设备和客户端进行密钥交互时，SSL加密设备响应延迟导致。

分析价值

通过网络分析对流量的监控，可以从网络性能、服务器性能、应用性能多视角进行统一分析，快速定位到应用故障时的故障节点。

- END-

延伸阅读

【案例】如何找出伪造数据的内网主机?

【案例】如何分析门户网站内容遭恶意篡改过程?

【案例】如何分析门户网站遭WEB攻击的过程？

(在对话框回复“案例汇总”，可查看往期精彩案例)

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。