描述
我有一个运行Python应用程序的AWS ec2实例(Ubuntu16)。在其中,我调用了一些Facebook帐户工具包API,以及Google。在我两周前重新启动实例之前,它们都非常正常。
重新启动后,请求需要超过5分钟才能完成,这是完全不能接受的。为了让请求完成,我必须手动将超时设置为10分钟以上。
这个问题只发生在我的一台服务器上,我在另一台服务器上运行相同的环境,在不到1秒的响应时间内运行非常好。
临时修正
为了暂时解决这个问题,我使用代理服务器来完成请求。
Situations
requests
尝试了python环境,响应时间非常糟糕,超过5分钟。{'Connection' : 'keep-alive' }
,则第二个请求将是正常的。
电流码
响应时间慢的请求。
url_get_access_token = "https://graph.accountkit.com/v1.3/access_token?grant_type=authorization_code&code=%s&access_token=AA|%s|%s"
url_get_access_token = url_get_access_token % (token, self.facebook_app_id, self.facebook_account_kit_scert)
response = requests.get(url_get_access_token)
body = response.json()
上面提到的代理服务器是同一子网中的另一个实例,但我使用DNS服务器进行调用。
response = requests.get("https://proxyserver.com/somepath", params={})
因为它只影响其中一个服务器,这是DNS问题还是AWS配置?帮帮忙,谢谢。
更新
由于时间卷曲的结果,使用iPv6调用似乎需要更多的时间。
$ time curl -4 -s https://graph.accountkit.com/v1.3
$ time curl -6 -s https://graph.accountkit.com/v1.3
iPv4
real 0m0.665s
user 0m0.068s
sys 0m0.020s
iPv6
real 2m7.180s
user 0m0.008s
sys 0m0.000s
发布于 2019-07-07 12:58:06
想到了两件事。
DNS
调试时:
$ cat /etc/resolv.conf
$ time dig aaaa graph.accountkit.com
您可能列出了多个名称服务器,而且并不是所有的名称服务器都是响应的,因此您需要进行长时间查找,因为它会超时于死的名称服务器。
TCP
调试时:
$ time curl -4 -s https://graph.accountkit.com/v1.3
$ time curl -6 -s https://graph.accountkit.com/v1.3
它会说“无效的OAuth 2.0访问令牌”,是的,是的,很好。我们感兴趣的是连接、发送GET和检索web文档所需的时间。
此域提供A和AAAA地址。如果IPv6传输已经结束,那么requests.get()
可能需要一段时间才能将故障转移到IPv4。
编辑
有人把你的IPv6运输机弄坏了。这在现代互联网上是不可接受的。丢包超时很可能导致127秒的时间过去.像traceroute6
和ping6
这样的工具可以帮助您或网络专业人员诊断损失在哪里。可能ACL太紧了,正在丢弃它不该丢弃的IPv6数据包。丢弃ICMP将是特别糟糕的。要使TCP正确工作,必须传递ICMP。
tcpdump
(或Wireshark)数据包跟踪将有助于准确地识别出向南移动的信息。你有可能患上了PMTUD黑孔。看看这是否显示任何“数据包太大”ICMP报告:
$ sudo tcpdump -tvvvni eth0 icmp6 and ip6[40+0]==2
只要看一看出站端口443的时间,TCP重传就能解释为什么事情会在两分钟内失败,然后比特就会突然开始流动。
https://stackoverflow.com/questions/56920375
复制相似问题