从服务器接收到请求到对应后台接收到请求

本文详细介绍了负载均衡的实现方式及调度算法,并对比了HTTP1.0、HTTP1.1、HTTP2.0和HTTPS的不同之处。同时,还探讨了GET与POST的区别、GZIP压缩的作用、长连接与短连接的特点以及浏览器的本地存储方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

负载均衡
对于大型的项目,由于并发访问量非常大,所以往往一台服务器是吃不消的,一般会有若干台服务器组成一个集群,然后通过配合反向代理实现负载均衡

这里实现负载均衡的方式有很多种,我们以比较熟悉的反向代理负载均衡为例,先来看看它的调度算法:
1.weight(轮询)
​ 接收到的请求按照顺序逐一分配到不同的后端服务器,即使在使用过程中,某一台服务器宕机,nginx会自动将这台服务器剔除队列,请求受理的情况不会受到任何影响。在这种方式下,可以给不同的后端服务器设置一个权重值,用于调整不同的服务器上请求的分配率,权重数据越大,被分配到的几率越大,该权重值主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。
2.ip_hash
每个请求按照发起客户端的ip的hash结果进行匹配,这样的算法保证了下一个固定ip地址的客户端总是会访问到上一次访问的服务器,这也在一定程度上解决了集群服务器环境下session共享问题。
3.fair
动态的根据后端服务器的请求处理到响应的时间进行均衡分配,响应时间短处理效率高的服务器分配到请求的概率高,响应时间长处理效率低的服务器分配到的请求少。默认nginx不支持此算法,需要安装upstream_fair模块。
4.url_hash
​ 按照访问的url的hash结果分配请求,每个请求的url会指向后端的固定服务器,可以在nginx作为静态服务器的情况下提高缓存效率,同样nginx也不支持此算法,需要安装hash包。
**HTTP1.0、HTTP1.1、HTTP2.0和HTTPS

HTTP1.0**
http/1.0最大的问题是连接无法复用,比如浏览器页面中包含很多同一服务器下的图片,那么使用http/1.0协议的话会导致连接无法复用,每次连接都会造成资源的浪费。尤其在高延迟的3次握手阶段以及大文件的慢启动阶段导致用户的体验遭到影响。
HTTP1.1

​ 为了客户http/1.0的缺陷,http/1.1使用长连接的访问机制,即在在过期时间内一个TCP连接中可以传送多个http请求,以此来减少建立和关闭连接的消耗和延迟。
HTTP2.0
​ 相对于http/1.1来说浏览器再同一时间对同一域名的请求是有最大限制的。http/2.0通过多路复用技术,同一个tcp请求可以请求多个资源

以下是http/2.0的新特性:

​ 1.多路复用

​ 2.首部压缩

​ 3.二进制分帧

​ 4.服务器端推送

​ 5.请求优先级设置

HTTPS

​ https就是安全版本的http,譬如一些支付操作就需要用到https协议

下面简述SSL/TLS协议的握手流程

​ 1.浏览器请求建立SSL连接,并向服务端发送一个随机数(Client-Random)和客户端所支持的算法。

​ 2.服务端选出一组算法,并回复一个随机数(Server-Random),并将安全证书(公钥包含其中)发送给浏览器。

​ 3.浏览器收到服务器的证书后,首先会生成第三个随机数(Premaster-secret),并且会验证证书是否合法有效。并通过约定好算法与服务器发送的公钥进行加密这个随机数。

​ 4.服务器使用自己的私钥获取这个随机数的“真面目”。

​ 5.服务器使用约定的算法,以及之前的三个随机数,生成对话密钥(session key),用来加密之后的过程。
GET和POST区别
​ 上文中,我们提到应用层HTTP协议规定的数据的规范**,实际用于传输的协议是TCP/IP协议**。并且针对不同浏览器上GET和POST的实践也有些不同,所以这里我们不讨论传输层或不同浏览器中GET和POST的区别,我们只讨论在语义上两者所带来的区别。

​ GET表达的是一种幂等的,只读的操作。讲通俗一些,就是他只查数据,而不会对数据做任何操作,因此对于大部分GET请求都可以被缓存下来,这能大大减少服务器的压力。

​ POST相对于GET表达的是非幂等的,并且对数据有影响的操作,这些必须通过服务器进行处理

​ 若把GET请求全被换成POST请求,首先所有的CDN全部废掉了,服务器的压力将变得巨大。

GZIP压缩
开启GZIP压缩的好处显而易见,一般文本可以将其压缩至原大小的60%,从而提升请求的效率。如果想要开启GZIP传输的话,需要后端容器进行配置,开启压缩功能。

​ 浏览器发送请求给Web服务器,request中有Accept-Encoding:gzip,deflate。这里表示浏览器支持GZIP压缩,请服务器帮忙压缩后再进行相应

​ 服务器通过LZ77算法和哈夫曼编码对其response进行压缩后发送给浏览器。浏览器再对其进行解码,再将其展示在页面上。

​ 需要注意的是,GZIP对于压缩图片这部分会大大增加服务器的CPU压力,并且压缩效果也不好,所以不太推荐针对图片进行压缩
长连接与短连接
在HTTP/1.0中默认使用短连接。也就是说,客户端和服务器每进行一次HTTP操作,就会建立一次连接,任务结束就中断连接。

​ 而从HTTP/1.1开始,默认使用长连接,用以保持连接活性。使用长连接,会在响应头加入这行代码。

Connection: keep-alive

在使用长连接的的情况下,当一个网页打开完成后,客户端与服务器之间用于传输HTTP数据的TCP连接不会关闭,客户端再次访问这个服务器时,会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接,它有一个过期时间,可以在不同的服务器软件中设定这个时间。

​ 实现长连接需要客户端和服务端都支持长连接,HTTP长连接和短连接实际上是TCP协议的长连接和短连接。
浏览器本地存储方案
Cookie

​ 1.大小受限制,cookie大小被限制在4KB

​ 2.cookie的实现是通过扩展HTTP协议实现,cookie存储的内容将保留在请求头中。并且对于同源的请求中,每次cookie都在浏览器和服务器中传输,这样会造成不必要的资源浪费。一般优化的方案是通过拆分服务器域名,将静态资源,请求多的服务器和使用cookie的服务器进行分离.

​ 3.对于服务器来说处理cookie非常方便,但是通过js处理cookie虽然有很多很棒的库帮忙,但是本质上还是通过正则表达式来进行分割处理。

SessionStorage

​ 1.大小为5M,可以存储较多的数据。

​ 2.sessionStorage与服务器的session类似,它是会话级别的缓存,关闭浏览器后将被清除。

​ 3.不同窗口不可以共享sessionStorage。

​ 4.他非常方便的API。

LocalStorage

​ 1.大小为5M,同sessionStorage。

​ 2.他是一种持久化方案,如果说不手动清除得话,数据是不会过期的。

​ 3.不同窗口,非跨域情况可以共享。

总结
上文说到,服务器已经接受到了通过tcp/ip协议发送过来的数据了,此时这台服务器如果是反向代理服务器的话,还会根据负载均衡将请求派发到具体的容器中。对应容器又会将请求转交到后台接口中,此时如果涉及到权限验证,跨域验证等没有通过的话,将直接根据对应的http协议返回响应结果,拒绝请求。只有通过了验证才能进行访问数据库等操作,等程序执行完毕后,将返回一个http响应包,重复上文的过程,完成交互。

<think>嗯,用户问的是微信服务号开发中服务器配置成功后收不到消息的问题。这个问题挺常见的,可能有很多原因。首先,我需要回忆一下微信服务号的配置流程,以及消息推送的机制。 首先,服务器配置成功可能意味着Token验证通过了,但实际接收消息的时候可能还有其他问题。可能用户完成了URL和Token的配置,但消息没有正确处理。这时候要分步骤排查。 可能的步骤包括检查服务器配置是否正确,比如URL是否可访问,是否有处理GET和POST请求。然后,检查服务器的日志,看看是否有收到来自微信服务器请求。如果没有日志,可能是网络问题,比如防火墙或者安全组设置,导致微信服务器无法访问用户的服务器。 另外,微信的消息加密方式可能有问题,比如启用了加密模式但没有正确解密消息。这时候需要检查EncodingAESKey是否配置正确,以及服务器端是否有对应的解密逻辑。 还有可能是消息处理后的响应不符合微信的要求,比如没有返回正确的XML结构或者没有及时响应(5秒内),导致微信服务器重试,而用户可能没注意到重复请求的处理。 另外,服务号的权限问题,比如没有开通接收消息的接口权限,或者公众号类型不支持,比如订阅号可能权限不足。不过用户提到的是服务号,所以权限应该没问题,但还是要确认一下。 还有可能是消息类型处理的问题,比如用户发送的消息类型服务器端没有正确处理,比如事件推送或者文本消息,导致虽然收到消息但未正确解析。需要检查代码中的消息类型判断逻辑。 还可能服务器配置的URL路径处理有问题,比如在web框架中路由配置错误,导致虽然验证通过,但实际处理消息的路径没有被正确路由到处理函数。 另外,微信服务器可能因为某些原因被暂时屏蔽,比如频繁错误响应导致被微信服务器加入黑名单,需要检查服务器是否稳定,是否有大量错误日志。 可能的解决方案包括:检查服务器日志,确认是否有请求进入;使用工具如Postman模拟微信的POST请求,测试服务器的响应;检查代码中的加密解密逻辑;确认服务器处理消息后返回正确的响应格式;检查网络配置,确保80或443端口开放,并且没有安全策略拦截;确认公众号后台配置的Token、URL和EncodingAESKey与代码一致。 总结下来,需要从配置、网络、代码逻辑、日志排查等多个方面来检查。可能还需要分步骤指导用户如何逐步排查,比如先检查日志,再模拟请求,再检查代码逻辑等。</think>微信服务号开发中,服务器配置成功后无法接收消息可能由多种原因导致。以下是常见问题及排查步骤: --- ### **一、基础配置检查** 1. **服务器地址(URL)有效性** - 确保URL能通过公网访问(可用浏览器或 `curl` 测试)。 - 确认服务器支持 **GET**(验证)和 **POST**(接收消息)请求。 - 检查是否配置了SSL证书(必须使用 **HTTPS**)。 2. **Token/EncodingAESKey 一致性** - 公众号后台填写的 `Token` 和 `EncodingAESKey` 必须与代码中的配置完全一致。 - 若启用加密模式,需在代码中实现消息解密逻辑(如使用微信提供的SDK)。 --- ### **二、网络与服务器问题** 1. **防火墙/安全组** - 确认服务器的 **80/443端口** 对微信服务器IP开放(微信服务器IP列表需定期更新,[官方文档](https://developers.weixin.qq.com/doc/offiaccount/Basic_Information/Get_the_WeChat_server_IP_address.html))。 - 检查云服务商(如阿里云、腾讯云)的安全组规则。 2. **服务器日志监控** - 查看服务器访问日志,确认是否收到微信的POST请求。 - 若未收到请求,可能是网络拦截或微信服务器未推送。 --- ### **三、代码逻辑排查** 1. **消息处理响应格式** - 微信要求 **5秒内** 返回响应,超时会导致重试(可能重复推送)。 - 响应内容必须是合法的XML格式(如文本消息需返回 `<xml>...</xml>` 结构)。 2. **加密模式兼容性** - 检查代码是否处理了加密模式: - **明文模式**:直接接收明文XML。 - **兼容/安全模式**:需解密 `POST` 请求中的 `Encrypt` 字段。 3. **消息类型处理** - 确保代码能识别不同消息类型(如 `text`、`event`)和事件类型(如关注事件 `subscribe`)。 - 事件消息需特殊处理(如用户关注、菜单点击)。 --- ### **四、微信后台设置** 1. **服务器配置状态** - 登录公众号后台,确认服务器配置为 **“启用”** 状态。 - 若修改过配置,需重新保存并等待生效。 2. **接口权限与账号类型** - 服务号需认证后才能使用高级接口。 - 确认当前账号类型为“服务号”(订阅号部分接口受限)。 --- ### **五、测试工具与调试** 1. **模拟请求测试** - 用 `curl` 或 Postman 向服务器发送模拟消息,检查是否能正确处理并返回XML。 - 示例请求体(明文模式): ```xml <xml> <ToUserName><![CDATA[公众号ID]]></ToUserName> <FromUserName><![CDATA[用户OpenID]]></FromUserName> <CreateTime>1640995200</CreateTime> <MsgType><![CDATA[text]]></MsgType> <Content><![CDATA[测试消息]]></Content> <MsgId>1234567890</MsgId> </xml> ``` 2. **微信开发者工具** - 使用公众号后台的 **“开发者工具” -> “在线接口调试工具”** 发送测试消息。 --- ### **六、常见错误案例** - **案例1**:代码未处理 `POST` 请求,仅验证了 `GET` 请求。 - **案例2**:未解析微信的XML数据,直接返回了错误格式(如JSON)。 - **案例3**:服务器使用了反向代理(如Nginx),但未正确转发请求体。 - **案例4**:EncodingAESKey 在后台修改后,代码未同步更新。 --- ### **总结步骤** 1. 检查服务器日志,确认是否收到消息请求。 2. 验证代码是否能解析XML和加密消息。 3. 用工具模拟请求,缩小问题范围。 4. 对比官方示例代码(如[Python](https://github.com/wechat-python-sdk/wechat-python-sdk)或[Node.js](https://github.com/node-webot/wechat)),检查逻辑差异。 若仍无法解决,建议提供具体的代码片段、日志信息和网络环境,以便进一步定位问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值