问题背景：
游戏上线后偶现这种情况（注意是偶现）：客户端http请求和websocket请求发送给服务器后，服务器收到消息后进行处理并马上返回，这个一来一回的过程超过15秒。经排查网络是没有断开的，服务器负载也很低并没有阻塞请求。
补充：服务端排查是说收客户端发送消息到服务器接收这个过程时间很久，比如客户端是 10点0分0秒准时发的，服务端收到消息已经10点0分20秒了，感觉是网络通信消耗了几十秒。
我们的处理方式：
消息一来一回有顺序，客户端需要收到上一条服务端返回的消息才允许发送下一个请求。发送消息的时候客户端记录时间戳，并且启动定时器，消息回来时重置定时器，如果一条消息发送后15秒未返回就提示网络异常，需要重新登录游戏。但是这种情况游戏体验不是特别好想优化一下。
请教各位大佬：
1）大家的游戏是否有统计或者出现过类似这种情况吗？
2）这种情况的原因是什么？
3）如何解决或优化体验？
能说说 为什么要这么设计规则呢？你确定这是常规的的方式吗 还是你们业务特有的要求？
游戏会涉及到数值肯定要保证顺序的，比如消耗金币不需要等服务端确认吗？收到服务端扣除成功的消息才能接着下一步。
你们完全依赖客户端维护数值，不需要通过服务端确认吗？
超过3秒连接就应该断开了，另外消息全部接收，差哪条消息再让客户重新端发来。
这个不是断线重连就好了吗
我目前只针对websocket长连接游戏才做了断线重连，且明确检测到了网络断开的事件才进行重连。
上面描述的这种情况并没有检测到网络断开，单纯的发了消息 一二十秒没返回。请问你们也会针对这种情况做重连重发吗？
你的意思是不做 一来一回发送吗？
比如 发送了消息 1、2、3， 收到了服务器对应的消息1和3， 客户端消息2等3秒没收到服务端的2客户端就自动断开，然后自动重连再自动发送2，是这样理解吗？
换服务器主机、换机房，这种情况碰到过两次了，，
这样啊，我们遇到的，阿里云、腾讯云都有出现，感觉不是换主机机房能避免的。
我上家公司遇到这个问题和你的有点像，我们当时是这种情况，客户端连续发消息，服务端就会挂起那条消息，然后一直阻塞在他们的队列里，然后15秒定时再发这条消息，否则要等客户端发下一条消息再把之前的消息补送，纯纯是服务端的问题，让他自检
我们服务端排查是说收到客户端消息就很久了，比如客户端是 10点0分0秒准时发的，服务端收到消息已经10点0分20秒了，感觉是网络通信消耗了几十秒。
最好用抓包的方式检测，因为15秒这个时间，听起来真的像逻辑问题，说不定客户端调了发送，实际上逻辑上底层框架有一个队列，在某些特殊情况下卡住不发送也有可能。
另外定时器这个方式，可以改成心跳包的方式，客户端半秒发一个心跳包，服务器立即回复，如果超过n个心跳包还没回复就认为断开了。这样可以对链接保活，而且检测断开会快一点，因为一直在传输数据包。
1、排除了 客户端底层不发送的可能
2、心跳包有发，心跳包也是15秒没返回的
我现在想确认的是，一条消息是否有可能从客户端发送到服务器15秒还没到达，且没有触发网络断开事件（国内的云服务器）。
巧了，我们服务端当时也是这么嘴硬的，他在业务层打的日志！害我调了2天，搞这个问题，我实在觉得不是我的问题，跟他说一定要抓包，打日志也要最底层打，然后他一搞，他的问题
， 意思是从服务器底层数据队列 到 业务消息解析这个过程卡了很久是吗
麻烦告知下 服务器怎么抓包 在最底层打日志呢？谢谢
是的，他们底层对消息做了队列，我们消息连续发送过去的时候（正是这点看起来像偶现），他们会把第二个消息阻塞起来
问我们干毛，这是他们的工作，让他们自己找chat gpt去
霸气，哈哈