Uber API 随机超时
Uber API randomly timeout
自几个月以来,我们在 Uber 估计 API 上面临很多超时。我们正在使用 curl 发出请求,这是我的测试服务器超时时打印的详细输出内容
curl -v \
-H 'Authorization: Token [my token]' \
-H 'Accept-Language: fr_FR' \
-H 'Content-Type: application/json' \
'https://api.uber.com/v1.2/estimates/price? start_latitude=48.8676689&start_longitude=2.3677804&end_latitude=48.8791163&end_longitude=2.3560725'
* Trying 104.36.195.168...
当 curl 在连接上停止时,我尝试同时在 443 端口上进行 nc
nc -vz 104.36.195.157 443
也没有回应
几秒钟后,相同的 nc 命令响应成功,但 curl 调用仍然停止。
几分钟后 curl 将超时并重试,它最终会在这里工作是 curl 输出
* Trying 104.36.194.191...
* TCP_NODELAY set
* connect to 104.36.194.191 port 443 failed: Connection timed out
* Trying 104.36.195.168...
* TCP_NODELAY set
* After 85223ms connect time, move on!
* connect to 104.36.195.168 port 443 failed: Connection timed out
* Trying 104.36.195.165...
* TCP_NODELAY set
* Connected to api.uber.com (104.36.195.165) port 443 (#0)
在 curl 连接成功后,我收到了 API 的响应。
有时 curl 调用会直接工作并响应正确的 API 结果。
此外,当我 ping api.uber.com 时,它有时没有响应
$ dig api.uber.com
; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> api.uber.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12152
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL:
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;api.uber.com. IN A
;; ANSWER SECTION:
api.uber.com. 60 IN CNAME frontends.uber.com.
frontends.uber.com. 59 IN CNAME frontends-dca1.uber.com.
frontends-dca1.uber.com. 8 IN A 104.36.195.158
frontends-dca1.uber.com. 8 IN A 104.36.194.159
frontends-dca1.uber.com. 8 IN A 104.36.194.134
frontends-dca1.uber.com. 8 IN A 104.36.195.165
frontends-dca1.uber.com. 8 IN A 104.36.195.162
;; Query time: 44 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Jan 17 12:33:30 CET 2019
;; MSG SIZE rcvd: 174
$ ping 104.36.195.158
PING 104.36.195.158 (104.36.195.158) 56(84) bytes of data.
^C
--- 104.36.195.158 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2047ms
$ ping 104.36.194.159
PING 104.36.194.159 (104.36.194.159) 56(84) bytes of data.
64 bytes from 104.36.194.159: icmp_seq=1 ttl=48 time=86.0 ms
64 bytes from 104.36.194.159: icmp_seq=2 ttl=48 time=85.6 ms
64 bytes from 104.36.194.159: icmp_seq=3 ttl=48 time=85.6 ms
^C
--- 104.36.194.159 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 85.639/85.772/86.031/0.183 ms
我的测试服务器是 AWS EC2 上的 Ubuntu 18。
我试图在我的本地环境(Mint 18.3 Sylvia Ubuntu 16.04)上重现这个问题,但它总是有效!
当测试服务器在 Ubuntu 16.04 上时,我们似乎也没有遇到问题。我现在的测试环境有问题吗?
有人遇到同样的行为吗?
感谢您的宝贵时间!
几天前,我没有采取任何措施,问题自行解决了。
自几个月以来,我们在 Uber 估计 API 上面临很多超时。我们正在使用 curl 发出请求,这是我的测试服务器超时时打印的详细输出内容
curl -v \
-H 'Authorization: Token [my token]' \
-H 'Accept-Language: fr_FR' \
-H 'Content-Type: application/json' \
'https://api.uber.com/v1.2/estimates/price? start_latitude=48.8676689&start_longitude=2.3677804&end_latitude=48.8791163&end_longitude=2.3560725'
* Trying 104.36.195.168...
当 curl 在连接上停止时,我尝试同时在 443 端口上进行 nc
nc -vz 104.36.195.157 443
也没有回应
几秒钟后,相同的 nc 命令响应成功,但 curl 调用仍然停止。
几分钟后 curl 将超时并重试,它最终会在这里工作是 curl 输出
* Trying 104.36.194.191...
* TCP_NODELAY set
* connect to 104.36.194.191 port 443 failed: Connection timed out
* Trying 104.36.195.168...
* TCP_NODELAY set
* After 85223ms connect time, move on!
* connect to 104.36.195.168 port 443 failed: Connection timed out
* Trying 104.36.195.165...
* TCP_NODELAY set
* Connected to api.uber.com (104.36.195.165) port 443 (#0)
在 curl 连接成功后,我收到了 API 的响应。
有时 curl 调用会直接工作并响应正确的 API 结果。
此外,当我 ping api.uber.com 时,它有时没有响应
$ dig api.uber.com
; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> api.uber.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12152
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL:
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;api.uber.com. IN A
;; ANSWER SECTION:
api.uber.com. 60 IN CNAME frontends.uber.com.
frontends.uber.com. 59 IN CNAME frontends-dca1.uber.com.
frontends-dca1.uber.com. 8 IN A 104.36.195.158
frontends-dca1.uber.com. 8 IN A 104.36.194.159
frontends-dca1.uber.com. 8 IN A 104.36.194.134
frontends-dca1.uber.com. 8 IN A 104.36.195.165
frontends-dca1.uber.com. 8 IN A 104.36.195.162
;; Query time: 44 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Jan 17 12:33:30 CET 2019
;; MSG SIZE rcvd: 174
$ ping 104.36.195.158
PING 104.36.195.158 (104.36.195.158) 56(84) bytes of data.
^C
--- 104.36.195.158 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2047ms
$ ping 104.36.194.159
PING 104.36.194.159 (104.36.194.159) 56(84) bytes of data.
64 bytes from 104.36.194.159: icmp_seq=1 ttl=48 time=86.0 ms
64 bytes from 104.36.194.159: icmp_seq=2 ttl=48 time=85.6 ms
64 bytes from 104.36.194.159: icmp_seq=3 ttl=48 time=85.6 ms
^C
--- 104.36.194.159 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 85.639/85.772/86.031/0.183 ms
我的测试服务器是 AWS EC2 上的 Ubuntu 18。 我试图在我的本地环境(Mint 18.3 Sylvia Ubuntu 16.04)上重现这个问题,但它总是有效!
当测试服务器在 Ubuntu 16.04 上时,我们似乎也没有遇到问题。我现在的测试环境有问题吗?
有人遇到同样的行为吗?
感谢您的宝贵时间!
几天前,我没有采取任何措施,问题自行解决了。