Запрос задерживается в течение длительного времени в хромированном состоянии

Ajax-запрос иногда долго останавливался в хроме.

Мне, наконец, удалось воспроизвести его и сохранить все связанные данные, необходимые для публикации здесь, если кто-нибудь сможет мне помочь.

Временная шкала из Chrome Dev Tool показывает, что запрос остановился на 42,62 с, как показано на следующем экране:

и в пределах chrome://net-internals/#events (для журнала событий, пожалуйста, пройдите в конец). Я нашел, что наибольшее время - это стоимость двух событий:

+ HTTP_TRANSACTION_READ_HEADERS [dt = 21301]
+ HTTP_TRANSACTION_READ_HEADERS [dt = 21304]

оба получаются ERR_CONNECTION_RESET.

Я думаю, что ошибка является причиной того, что запрос зашел так долго.

Кто-нибудь может объяснить ошибки?

СЛЕДУЮЩИЙ СОБЫТИЙ LOG ДЛЯ ЗАПРОСА, я также экспортирую полные события как json, вы можете получить от здесь, затем восстановить в Chrome chrome://net-internals/#events страница. обратите внимание, что URL-адрес запроса является внутренним, поэтому, возможно, не доступен доступ из общедоступной сети:

193486: URL_REQUEST
http://qa.tieba.baidu.com/release/getReleaseHistory?projectId=fum1.0.593
Start Time: 2015-01-02 17:51:05.323

t=    1 [st=    0] +REQUEST_ALIVE  [dt=42741]
t=    1 [st=    0]    URL_REQUEST_DELEGATE  [dt=0]
t=    1 [st=    0]   +URL_REQUEST_START_JOB  [dt=42740]
                      --> load_flags = 339804160 (BYPASS_DATA_REDUCTION_PROXY | MAYBE_USER_GESTURE | REPORT_RAW_HEADERS | VERIFY_EV_CERT)
                      --> method = "GET"
                      --> priority = "LOW"
                      --> url = "http://qa.tieba.baidu.com/release/getReleaseHistory?projectId=fum1.0.593"
t=    2 [st=    1]      URL_REQUEST_DELEGATE  [dt=0]
t=    2 [st=    1]      HTTP_CACHE_GET_BACKEND  [dt=0]
t=    2 [st=    1]      HTTP_CACHE_OPEN_ENTRY  [dt=0]
t=    2 [st=    1]      HTTP_CACHE_ADD_TO_ENTRY  [dt=0]
t=    2 [st=    1]      HTTP_CACHE_READ_INFO  [dt=0]
t=    2 [st=    1]      URL_REQUEST_DELEGATE  [dt=0]
t=    2 [st=    1]     +HTTP_STREAM_REQUEST  [dt=2]
t=    4 [st=    3]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                          --> source_dependency = 193488 (HTTP_STREAM_JOB)
t=    4 [st=    3]     -HTTP_STREAM_REQUEST
t=    4 [st=    3]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=0]
t=    4 [st=    3]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                          --> GET /release/getReleaseHistory?projectId=fum1.0.593 HTTP/1.1
                              Host: qa.tieba.baidu.com
                              Connection: keep-alive
                              Accept: application/json, text/plain, */*
                              User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
                              Referer: http://qa.tieba.baidu.com/project/
                              Accept-Encoding: gzip, deflate, sdch
                              Accept-Language: en-US,en;q=0.8
                              Cookie: [268 bytes were stripped]
t=    4 [st=    3]     -HTTP_TRANSACTION_SEND_REQUEST
t=    4 [st=    3]     +HTTP_TRANSACTION_READ_HEADERS  [dt=21301]
t=    4 [st=    3]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=21301]
                          --> net_error = -101 (ERR_CONNECTION_RESET)
t=21305 [st=21304]        HTTP_TRANSACTION_RESTART_AFTER_ERROR
                          --> net_error = -101 (ERR_CONNECTION_RESET)
t=21305 [st=21304]     -HTTP_TRANSACTION_READ_HEADERS
t=21305 [st=21304]     +HTTP_STREAM_REQUEST  [dt=3]
t=21307 [st=21306]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                          --> source_dependency = 193494 (HTTP_STREAM_JOB)
t=21308 [st=21307]     -HTTP_STREAM_REQUEST
t=21308 [st=21307]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=3]
t=21308 [st=21307]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                          --> GET /release/getReleaseHistory?projectId=fum1.0.593 HTTP/1.1
                              Host: qa.tieba.baidu.com
                              Connection: keep-alive
                              Accept: application/json, text/plain, */*
                              User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
                              Referer: http://qa.tieba.baidu.com/project/
                              Accept-Encoding: gzip, deflate, sdch
                              Accept-Language: en-US,en;q=0.8
                              Cookie: [268 bytes were stripped]
t=21311 [st=21310]     -HTTP_TRANSACTION_SEND_REQUEST
t=21311 [st=21310]     +HTTP_TRANSACTION_READ_HEADERS  [dt=21304]
t=21311 [st=21310]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=21304]
                          --> net_error = -101 (ERR_CONNECTION_RESET)
t=42615 [st=42614]        HTTP_TRANSACTION_RESTART_AFTER_ERROR
                          --> net_error = -101 (ERR_CONNECTION_RESET)
t=42615 [st=42614]     -HTTP_TRANSACTION_READ_HEADERS
t=42615 [st=42614]     +HTTP_STREAM_REQUEST  [dt=12]
t=42627 [st=42626]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                          --> source_dependency = 193498 (HTTP_STREAM_JOB)
t=42627 [st=42626]     -HTTP_STREAM_REQUEST
t=42627 [st=42626]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=2]
t=42627 [st=42626]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                          --> GET /release/getReleaseHistory?projectId=fum1.0.593 HTTP/1.1
                              Host: qa.tieba.baidu.com
                              Connection: keep-alive
                              Accept: application/json, text/plain, */*
                              User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
                              Referer: http://qa.tieba.baidu.com/project/
                              Accept-Encoding: gzip, deflate, sdch
                              Accept-Language: en-US,en;q=0.8
                              Cookie: [268 bytes were stripped]
t=42629 [st=42628]     -HTTP_TRANSACTION_SEND_REQUEST
t=42629 [st=42628]     +HTTP_TRANSACTION_READ_HEADERS  [dt=112]
t=42629 [st=42628]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=112]
t=42741 [st=42740]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                          --> HTTP/1.1 200 OK
                              Date: Fri, 02 Jan 2015 09:51:48 GMT
                              Content-Type: application/json; charset=UTF-8
                              Transfer-Encoding: chunked
                              Connection: keep-alive
                              Cache-Control: no-cache
                              tracecode: 31079600320335034634010217
                              tracecode: 31079600320537995786010217
                              Server: Apache
t=42741 [st=42740]     -HTTP_TRANSACTION_READ_HEADERS
t=42741 [st=42740]      HTTP_CACHE_WRITE_INFO  [dt=0]
t=42741 [st=42740]      HTTP_CACHE_WRITE_DATA  [dt=0]
t=42741 [st=42740]      HTTP_CACHE_WRITE_INFO  [dt=0]
t=42741 [st=42740]      URL_REQUEST_DELEGATE  [dt=0]
t=42741 [st=42740]   -URL_REQUEST_START_JOB
t=42741 [st=42740]    URL_REQUEST_DELEGATE  [dt=0]
t=42741 [st=42740]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=42741 [st=42740]    HTTP_CACHE_WRITE_DATA  [dt=0]
t=42741 [st=42740]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=42741 [st=42740]    HTTP_CACHE_WRITE_DATA  [dt=0]
t=42742 [st=42741] -REQUEST_ALIVE

Ответ 1

Однажды я столкнулся с аналогичной проблемой. Причиной проблемы является то, что каждый браузер имеет ограничение на максимальное количество соединений TCP с сервером. Для хром предел равен шести. Проблема более заметна, когда вы используете прокси-сервер, потому что все запросы идут на одном сервере (прокси-сервер).

Chrome не позволяет вам изменять этот предел. На самом деле этого не должно быть. Если вы хотите узнать больше о том, почему этот предел существует и каковы ограничения для других браузеров, вы можете прочитать эту статью.

Причина, по которой этот предел редко возникает, заключается в том, что несколько HTTP-запросов к одному и тому же хосту в основном отправляются последовательно, а не параллельно, предпочтительно по одному и тому же TCP-соединению.

Если эта проблема возникает у вас часто, причиной может быть:

Сервер не поддерживает постоянное TCP-соединение: Если проблема возникает только при обращении к определенному серверу, причиной может быть то, что хром извлекает несколько ресурсов (например, изображения, файлы CSS, и т.д.) при параллельных соединениях. Поскольку в вашем случае сервер находится в вашей локальной сети, вы можете попросить администратора сервера добавить поддержку постоянных соединений TCP.
Открыты несколько постоянных подключений:. Если вы работаете за прокси-сервером, загрузка нескольких файлов одновременно или открытие сайтов, поддерживающих соединение TCP, может стать причиной вашей проблемы. Чтобы избавиться от него, все, что вы можете сделать, - это не загружать много вещей одновременно (или загружать в другой браузер, если вам нужно).

PS: Ошибка net_error = -101 (ERR_CONNECTION_RESET) не связана с недопустимыми заголовками, это из-за таймаута, ожидающего какого-либо предыдущего подключения к серверу закрыть.

Ответ 2

Аналогичная проблема возникает, и выяснилось, что через некоторое время, примерно через 3 минуты, попытка использования сокета хром закрывается (я предполагаю) ОС.

Это указано как ошибка в форуме хрома. Я предполагаю, что у меня нет какого-то механизма "keep-alive": https://code.google.com/p/chromium/issues/detail?id=447463

Мое сообщение об ошибке несколько отличается, но это может быть связано с тем, что мое приложение совершает вызовы через SSL. Вот что я вижу в хроме://net-internals:

Первый chrome находит существующий сокет и связанный с ним запрос (HTTP_STREAM_JOB):

    t=1572 [st=0]    HTTP2_SESSION_POOL_FOUND_EXISTING_SESSION
                     --> source_dependency = 1347215 (HTTP2_SESSION)
    t=1572 [st=0]    HTTP_STREAM_JOB_BOUND_TO_REQUEST
                     --> source_dependency = 1348612 (URL_REQUEST)
    t=1572 [st=0] -HTTP_STREAM_JOB

Затем снова в (URL_REQUEST) вы увидите тайм-аут, обратите внимание на 10-секундный промежуток времени от t = 1572 до t = 11573:

    t= 1572 [st=    0]  HTTP2_SESSION_SEND_DATA
                        --> fin = true
                        --> size = 48
                        --> stream_id = 3
    t= 1572 [st=    0]  HTTP2_SESSION_UPDATE_SEND_WINDOW
                        --> delta = -48
                        --> window_size = 2147483551
    t=11573 [st=10001]  HTTP2_SESSION_CLOSE
                        --> description = "Failed ping."
                        --> net_error = -352 (ERR_SPDY_PING_FAILED)

Ясно, что тайм-аут, когда хром пытается настроить размер окна в существующем сокете. Я предполагаю, что это происходит из-за неактивности сокета.

Я собираюсь попытаться выполнить какой-то запрос на пульс, возможно, через 60 секунд, чтобы узнать, сохраняется ли проблема. Я опубликую обновление с результатами.

UPDATE:

Добавлен следующий код в javascript, который загружается на каждую страницу. Это извлекает пустой html-документ из открытого корня:

    $(document).ready(function() {
        $.keepalive =     
                setInterval(function() {
                   $.ajax({
                      url: '/ping.html',
                      cache: false
                   });         
                }, 60000);    
    });

Это, похоже, помогло открыть розетку даже с образцом ниже, показывающим примерно 6 минут между "настоящими" вызовами:

При 570B за звонок через 60 секунд, вызов ping будет добавлять около 800 кбит/с использования полосы пропускания за 24 часа (за сеанс браузера). Я не уверен, сколько издержек процессора на сервере это вызовет.

Для сравнения, ПЕРЕД:

Должно быть лучшее решение, но я еще не смог его найти.