Ошибка возврата завихрения 52 или 56 с вызовом API REST, охватывающим больше чем 5 минут
Таким образом, я пытался понять этого приблизительно в течение недели теперь. Вот информация:
Я использую ЗАВИХРЕНИЕ в PHP для получения по запросу данных из API. Поскольку ответ на вызов API становится больше (останавливающийся 15k записи сразу), я заметил, что любому вызову API, который занимает 5 или больше минут (в течение нескольких секунд) не удается возвратиться на моих серверах CentOS и SuSe. Так, я протестировал вызов API от CLI через ЗАВИХРЕНИЕ, и я получаю ту же проблему. Странно, если я выполняю команду CURL через OS X, команда хорошо работает и возвращается приблизительно после ~7 минут.
Вот команда (creds подвергнутый цензуре), я работаю через ЗАВИХРЕНИЕ:
curl -m 0 -k --trace-ascii trace.txt --trace-time -X GET -H "tenant-code: 1cmPx7tqVDVTdN1GSelwycFUmICmASnLCmNQsV72" -H "Authorization: Basic JxHAsXeUiHMRkS8Msiu6pWb3PvY20p6am3QvXCY3knXTAntlxTBS3EyEDgly" -H "Content-Type: application/json" -H "Cache-Control: no-cache" 'https://api.endpoint.com/API/v1/system/users/search?groupid=555' > dump.txt
И вот вывод версии от ЗАВИХРЕНИЯ для каждой платформы:
CentOS (это - то, где мне действительно нужно это для работы) -
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
SuSe -
curl 7.19.7 (x86_64-suse-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8j zlib/1.2.7 libidn/1.10
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
OS X
curl 7.37.1 (x86_64-apple-darwin14.0) libcurl/7.37.1 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz
И это коды ошибок, которые я получаю от Centos:
curl: (56) SSL read: errno -5961
Я не могу найти, что код сослался в документации. https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/SSL_functions/sslerr.html
Я получаю немного отличающуюся ошибку из SuSe:
curl: (52) SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
Ошибка 104 приводит меня полагать, что сервер останавливается/сбрасывает соединение, но серверные журналы не показывают то, чтобы он, был отброшенным и OS X могут вытянуть данные без проблемы. Я даже пытался имитировать Агент пользователя, чтобы удостовериться, что это не было проблемой.
Так, в этой точке я предполагаю, что пакет SSL, SecureTransport делает что-то, что не делают OpenSSL и NSS. Вопрос - то, что и в противном случае какова проблема?
Выполните команду curl на машине MacOSX, но не перенаправляйте вывод, дайте ему поток в окно оболочки. Посмотрите, есть ли какая-нибудь буферизация, IE, получаете ли вы вывод с самого начала, немного за раз, или ничего не получаете в течение 5 минут, а потом поток данных сразу?
Запустите команду curl снова на машине, где она тайм-аут, и сравните поведение. Если ваш вывод буферизируется каким-то фоновым процессом на сервере API, вы можете не получить результатов до тех пор, пока он не завершит свой запрос. Что-то между вашим клиентским приложением, ОС клиента, ОС сервера, REST api сервера, и SSL между ними, скорее всего, имеет тайм-аут значение ненулевое, и если этот таймер не видит никаких данных течет в течение 5 минут, он может закрыть ваше соединение, не говоря уже о том, почему. Я вижу, что это происходит много в HTTP-служб. На perl я обычно ставлю $|=1; вверху кода, чтобы отключить буферизацию вывода на стороне сервера.
Также возможно, что на стороннем устройстве, таком как Cisco ASA, могут быть проблемы с таймингом и срабатыванием правил NAT. У меня эта проблема с резервными копиями AMANDA, которые пытаются читать с клиента на внешней стороне ASA. Если клиент слишком долго возвращает свои оценки размеров через ASA обратно на сервер AMANDA, ASA сбрасывает свое динамическое правило NAT, и резервное копирование выходит из строя. Это предложение стоит исследовать, если MacOSX, который работает, не имеет брандмауэра между собой и сервером API, но у тех, кто не работает, он есть.
Меня не удивит, если MacOSX имеет значение таймаута, установленное где-то в 0 (ждать вечно), где Linux по умолчанию имеет ограничение в 60 или 90 секунд.
.