提示
X
本案例来自tskb,请前往tskb修改源内容:立即前往
'>

基础排查-步骤五:HTTP passive会话保持原理及排障注意事项

|

问题描述

HTTP被动会话保持的原理,借用如下案例来解释:
某客户使用AD发布7层虚拟服务,由于前端做了SNAT转换,不能使用源IP做会话保持,且客户端不支持使用cookie,此时需要做会话保持,只能根据数据包的特性来做,客户反馈服务器使用jsessionid判断此数据包的唯一性。

有效排查步骤

1、根据客户提供的信息抓取对应数据包,同时节点池如下图,两个ip地址不同的端口。


2、测试还是会出现访问不了的情况,按照1中抓取虚拟服务对应的数据包,过滤后端节点http(因为业务是http协议的,发现调度到了两个节点上。


3、进一步分析数据,发现第一个POST请求没有带jsessionid,jsessionid是第一个请求包应答的内容。


也就是说客户端的请求会先POST一个URL,服务器返回一个JSID,后续的请求都会在URI中携带这个JSID。

解决方案

针对该业务系统的特殊性,需要保证前后的POST请求都调度到同一台节点上才会正常,AD上只能做应答被动会话保持实现,并且必须在第一个POST返回的应答中学习会话保持Set-Cookie:头部中的JSESSIONID值,后续的POST请求URI中查找JSESSIONID,设置参数如下:

建议与总结

Http被动可以实现特殊场景下的会话保持,但需要针对实际业务提前分析,尤其是相关参数不能填错,汇总如下:

请求被动:在请求方向学习需要会话保持内容,在请求方向查找后续的数据包是否存在会话保持(调度到相同的节点)。
应答被动:在应答方向学习需要会话保持的内容,在请求方向查找后续的数据包是否存在会话保持(调度到相同节点)。

我要分享
文档编号: 250257
作者: admin
更新时间: 2023-04-20 14:53
适用版本: