AFNetworking：负载平衡/服务器托管/重定向的奇怪处理

Posted 2023-02-24

【中文标题】AFNetworking：负载平衡/服务器托管/重定向的奇怪处理

【英文标题】：AFNetworking: Strange dealing with load balancing / server hosting / redirecting

【发布时间】：2017-01-11 18:25:28

【问题描述】：

所以，这个问题很难简单描述，我觉得我应该先在这里问一下，然后再在 AFNetworking github 上提出问题。故事是这样的：

// Definition for words in the story.

Characters:
- APP: Our ios app, which POST requests to a URL's API (has user input from a UITextField)
       APP's networking connection using framework AFNetworking 3.0
- DEV: Us developers, who created the iOS app.
- CUST: The troublesome customer, who live far from DEV.
        CUST used app before, then one day it doesn't work anymore (S1 has died).

Server:
- S1: The CUST's primary server (died for some reasons). This has the IP address = ip1
- S2: The CUST's secondary server (works fine). This has the IP address = ip2
- URL: The domain URL point to both server (using load balancing or something like that, I dunno).

// End-of-definition

故事开始：

CUST使用app，输入URL，连接失败。 CUST在iPad浏览器中输入URL，正常访问。 CUST 询问 DEV 检查发生了什么。 DEV在app中输入URL，连接正常。当时DEV不知道CUST有2台服务器。

CUST 和DEV 都感到绝望，挣扎了好一阵子。 CUST 尽其所能（使用https / http，添加/删除www，删除应用程序并重新安装）。 DEV 被不合理的原因分散了注意力（连接器错误，api 错误......）。然后CUST 记住他有两台服务器。 CUST 分享了 IP addresses 供 DEV 检查。这时候DEV 发现S1 已经死了，而S2 还没有死。

所以，DEV 得到了CUST 无法使用APP 访问URL 的原因：S1 已经死了。 但是，对于 SO，真正的问题是：

为什么它在我们这边有效，而在CUST 那边却不行？为什么APP（在DEV 的手中）转到S2 但在CUST 的手中，它转到S1（并死了）？但是为什么CUST可以正常使用iPad的浏览器访问URL呢？

这和 DNS 有关系吗？虚拟专用网？负载均衡？我很想为这个问题找个理由。

感谢阅读。随意编辑这个问题，因为我也努力尽可能简单地描述这个问题。

更新 1：

作为James Jayson 询问APP 如何连接到URL，它使用AFNetworking 3.0 和AFHTTPSessionManager 并进行一些设置：

self.sessionManager = [[AFHTTPSessionManager alloc] initWithBaseURL:baseUrl sessionConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration]];
self.sessionManager.securityPolicy.allowInvalidCertificates = YES;
self.sessionManager.securityPolicy.validatesDomainName = NO;
self.sessionManager.requestSerializer.timeoutInterval = timeout;
self.sessionManager.requestSerializer = [AFJSONRequestSerializer serializer];

// Call API:
[self.sessionManager POST:path parameters:dictParams progress:nil success:^(NSURLSessionTask *task, id responseObject)  
    // success block
 failure:^(NSURLSessionTask *task, NSError *error) 
    // failure block

更新 2：

所以，现在我有了一些新的东西：CUST 使用 iOS 9.3.5，DEV 使用 iOS 10.x。 DEV尝试在iOS 9.3.5设备上调试，出现CUST的错误，错误信息类似于this（几乎相同，仅URL不同）。

日志： 错误域=NSURLErrorDomain 代码=-1004 “无法连接到服务器。” UserInfo=NSErrorFailingURLStringKey=APIURL, _kCFStreamErrorCodeKey=-2200, NSErrorFailingURLKey=APIURL, NSLocalizedDescription=无法连接到服务器。, _kCFStreamErrorDomainKey=4, NSUnderlyingError=0x16146990 错误域=kCFErrorDomainCFNetwork 代码=-1004 "(null)" UserInfo=_kCFStreamErrorDomainKey=4, NSErrorPeerAddressKey=length = 16, capacity = 16, bytes = 0x100201bb253ce7160000000000000000，_kCFStreamErrorCodeKey=-2200

现在DEV 正在努力解决如何处理此错误。请帮忙。

【参考方案1】：

在不知道应用程序是什么以及它是如何工作的情况下，我猜测它是状态完整的，并且可能是由于当前死服务器上的会话处于活动状态，启动会话的开发人员通过以下方式定向到服务器 2负载均衡器。

【讨论】：

但是CUST 甚至删除了应用程序并重新安装。即使在删除之后，状态完整的东西也会保留这样的东西吗？

再次在不知道应用程序如何连接的情况下，如果它使用浏览器进行连接，那么浏览器可能会记住会话，但是由于会话在配置后过期，30 分钟后应该不会发生这种情况时间量（通常默认为 30 分钟）

您想了解有关应用程序连接方式的哪些信息？我可以分享一些东西。它通常向 URL 发布请求并获得响应。另外，浏览器访问了正确的服务器S2，那么应用程序不应该也访问S2吗？

我要问的部分是应用程序如何发送 url，如果它通过浏览器发送 url，那么即使在应用程序被删除后浏览器也会记住。使用浏览器的开发人员不会遇到此问题，因为他的会话将在第一台服务器关闭后开始，因此即使服务器 1 重新联机，他仍将保持与服务器 2 的连接。只是要绝对清楚，这是我唯一的想法，可能是错误的，但这是一种可能性。

应用程序请求 URL 使用 AFNetworking 3.0，通过 @SEL AFHTTPSessionManager POST:parameters:progress:success:failure:。就这么简单。我会更新关于那部分的问题。