programing

때때로 크롬으로 장기간 정지된 요청

instargram 2023. 3. 28. 21:12
반응형

때때로 크롬으로 장기간 정지된 요청

Ajax 요청은 크롬으로 장기간 정지되는 경우가 있습니다.

저는 마침내 그것을 재현하고 누군가 도와주면 여기에 글을 올리는 데 필요한 모든 관련 데이터를 저장할 수 있었습니다.

Chrome Dev Tool 42.62 chrome chromeた 、 Crome Dev Tool 。여기에 이미지 설명 입력

그리고 그 안에서chrome://net-internals/#events) 에서는 가장 이 두 에 의한 을 알 수 있었습니다 (이벤트 로그의 경우)는 두 가지 이벤트입니다.

  • +HTTP_TRANSACTION_READ_헤더 [dt=21301]
  • +HTTP_TRANSACTION_READ_헤더 [dt=21304]

다 받다ERR_CONNECTION_RESET.

여기에 이미지 설명 입력

저는 그 오류가 요청이 오랫동안 지연된 이유라고 생각합니다.

누가 오류를 설명해 줄 수 있나요?

다음은 요청에 대한 이벤트 로그입니다. 여기서 얻을 수 있는 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

EDIT: 관련 문제 문제 447463: Chrome-network: 오래된 소켓에서 RST 메시지가 표시될 때까지의 지연이 길어지면 페이지 로드가 느려집니다.

저도 비슷한 문제를 겪은 적이 있어요.문제의 원인은 모든 브라우저가 서버로의 TCP 접속의 최대수에 제한을 두고 있기 때문입니다.크롬은 6개까지입니다.이 문제는 프록시 서버를 사용하는 경우 모든 요청이 동일한 서버(프록시 서버)로 전송되기 때문에 더욱 두드러집니다.

Chrome에서는 이 제한을 변경할 수 없습니다.사실 그렇지 않아요.이 제한이 존재하는 이유와 다른 브라우저의 제한 사항을 자세히 알아보려면 이 문서를 참조하십시오.

이 제한이 거의 문제가 되지 않는 이유는, 같은 호스트에 대한 복수의 HTTP 요구가, 대부분의 경우, 같은 TCP 접속을 개입시켜 병렬로 송신되는 것이 아니고, 연속적으로 송신되기 때문입니다.

이 문제가 자주 발생하는 경우 그 이유는 다음과 같습니다.

  1. 서버가 영구 TCP 연결을 지원하지 않습니다.특정 서버에 액세스 할 때만 문제가 발생하는 경우는, 병렬 접속으로 Chrome 가 복수의 자원(이미지, CSS 파일등)을 취득하고 있는 것이 원인일 가능성이 있습니다.이 경우 서버가 로컬네트워크에 있기 때문에 서버의 관리자에게 영속적인 TCP 접속에 대한 지원을 추가하도록 요청할 수 있습니다.

  2. 여러 영구 연결이 열려 있습니다.프록시 서버 뒤에서 작업하는 경우 여러 파일을 동시에 다운로드하거나 TCP 연결을 열어 두는 사이트를 여는 것이 문제의 원인일 수 있습니다.이 기능을 없애려면 여러 작업을 동시에 다운로드하지 않는 것(필요한 경우 다른 브라우저에서 다운로드하는 것)만 가능합니다.

PS: 오류 net_error = -101(ERR_CONNECTION_RESET)은 비활성 헤더가 아니라 타임아웃이 원인입니다.서버에 대한 이전 연결이 닫힐 때까지 기다립니다.

여기서도 같은 문제가 발생하는데, 잠시 후 소켓 크롬이 사용하려고 하면 OS에 의해 3분 정도 닫힙니다(아마도).

이것은 크롬 포럼에도 버그로 기재되어 있습니다.일종의 "살아있는" 메커니즘이 부족한 것 같아요.: https://code.google.com/p/chromium/issues/detail?id=447463

에러 메세지는 약간 다르지만, SSL 경유로 콜을 발신하는 애플리케이션 때문일 가능성이 있습니다.chrome://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)로 돌아가면 시간 초과가 나타납니다. t=1572에서 t=11573까지의 시간 경과가 10초입니다.

    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초 간격으로 하트비트 요청을 구현하여 문제가 계속 발생할 수 있는지 확인합니다.결과물이 담긴 업데이트를 올리겠습니다.

갱신:

각 페이지에 로드되는 Javascript에 다음 코드를 추가하였습니다.공용 루트에서 빈 html 문서를 검색하는 중입니다.

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

이것에 의해, 다음의 샘플이 「실제」콜간의 약 6분을 나타내고 있는 경우에서도, 소켓을 열어 두는 것이 도움이 된 것 같습니다.

결과

60초 간격으로 콜당 570B로 ping 콜은 24시간(브라우저 세션당) 대역폭 사용량의 약 800kb를 추가합니다.이로 인해 서버의 CPU 오버헤드가 어느 정도 발생하는지 알 수 없습니다.

비교하기 전에:

변경 전

더 나은 해결책이 있을 텐데 아직 찾지 못했어요.

비슷한 문제가 발생하여 수정되었습니다!

문제는 작은 파일 업로드가 정상인데 큰 파일 업로드가 너무 오래 걸려서 net-log 뷰어에서 실제로 업로드된 파일 데이터의 풀사이즈지만 그 후에 TCP 접속이 자동으로 닫히는 것을 알 수 있었습니다.

https://netlog-viewer.appspot.com/#http 요청은 프록시 서버를 통과해야 합니다.

no-proxy 설정을 사용하여 바이패스한 파이어폭스를 사용하여 다시 테스트했지만 여전히 실패했습니다.firefox about:networking #dns. 실제로 도메인이 웹 서버로 직접 해결되지 않고 다수의 IP 주소로 해결된 것을 알 수 있었습니다.

마지막으로 호스트 설정 포인트를 직접 웹 서버의 IP 주소로 변경했습니다.그 후 문제는 해결되었습니다.그래서 근본 원인을 프록시 서버라고 특정했습니다.그것들은 일종의 디폴트 타임아웃을 가지고 있을지도 모릅니다.

언급URL : https://stackoverflow.com/questions/27740692/request-stalled-for-a-long-time-occasionally-in-chrome

반응형

'programing' 카테고리의 다른 글

WordPress에서 사용자 비밀번호 정보를 삭제하는 방법  (0) 2023.03.28
VueJS SPA for WP 관리 메뉴 페이지가 작동하지 않음  (0) 2023.03.28
"Bean Validation API가 클래스 경로에 있지만 구현을 찾을 수 없습니다"로 인해 부팅이 차단됩니다.  (0) 2023.03.28
JSON - JSONArray를 통해 반복합니다.  (0) 2023.03.23
SQL에서 두 개의 고유한 열이 있는 최신 날짜별로 행 선택  (0) 2023.03.23

'programing'의 다른글

  • 현재글때때로 크롬으로 장기간 정지된 요청

관련글

댓글

티스토리툴바