Requests: 전체 시간 초과

안녕하세요 @emgerner-msft님,

참고로 다음은 이 정확한 기능 요청이 아닌 경우 이 테마의 모든 변형입니다.

• https://github.com/kennethreitz/requests/issues/2327
• https://github.com/kennethreitz/requests/issues/2685
• https://github.com/kennethreitz/requests/issues/1928
• (그리고 나는 더 많은 것이 있다고 확신합니다)

또한 https://github.com/sigmavirus24/requests-toolbelt/issues/51 에서 이에 대해 논의했습니다.

마지막 링크는 요청에 추가하지 않고 이를 처리해야 하는 이 패키지 에 대해 설명합니다. 현실은 다른 패키지가 이미 아주 잘 하고 있을 때 이것을 하도록 요청할 필요가 없다는 것입니다.

참조하는 패키지는 웹 요청을 실행하기 위해 별도의 프로세스를 분기하여 수행합니다. 이는 시간 초과라는 단순한 목표를 달성하는 매우 중요한 방법이며, 제 생각에는 기본 시간 초과 기능이 있는 요청 자체를 어떤 식으로든 대체할 수 없습니다.

@jribbens 쓰레드도 프로세스도 사용하지 않는 방법을 생각해낼 수 있다면 그것은 놀라운 일이 될 것입니다. 그때까지는 벽시계 시간 초과를 원할 경우 현재로서는 가장 안정적인 방법으로 해당 패키지를 사용하는 것이 가장 좋습니다.

@jribbens 가 스레드나 프로세스가 없다고 생각하지 않습니다. 웹 요청당 _프로세스가 과도하다는 것입니다. 많은 언어에는 단일 추가 스레드 또는 프로세스를 공유하는 여러 타이머가 있습니다. 파이썬에서 가장 잘 수행하는 방법을 모르겠습니다.

#1928이 대안에 대해 가장 많이 논의한 것처럼 보이지만 대부분은 많은 주의 사항이 있습니다(이것은 사용 사례 등에서 작동하지 않음). 내 라이브러리에 사용자 정의 코드가 있고 이것이 실제로 요청에 속하지 않는 경우 나만의 사용자 정의 솔루션을 작성하는 것은 괜찮습니다. 우리가 요청을 사용하는 모든 이유는 낮은 수준의 TCP 연결 풀링 논리에서 벗어나기 위한 것이지만 이 사용자 지정 코드를 작성하려면 해당 논리를 알아야 하는 해당 스레드를 읽는 것처럼 보입니다. .

@emgerner-msft가 맞습니다. 스레드나 프로세스를 사용하지 않고 "총 시간 초과"가 발생하는 @sigmavirus24 의 의견은 다소 혼란스럽습니다. 전체 프로세스 시작 시 기한을 계산(예: deadline = time.time() + total_timeout )한 다음 개별 작업에서 시간 제한을 deadline - time.time() 로 설정합니다.

스레드나 프로세스를 사용하지 않고 "총 시간 초과"가 발생하는 것은 매우 보행자처럼 보이며 전혀 "놀랍지" 않습니다.

그리고 귀하의 솔루션은 다소 원시적입니다. _대부분의_ 사람들이 총(또는 벽시계) 시간 초과를 원하는 이유는 읽기가 "중단"되는 것을 방지하기 위한 것입니다. 즉, 다음과 같은 경우입니다.

r = requests.get(url, stream=True)
for chunk in r.iter_content(chunksize):
    process_data(chunk)

iter_content 중간에 각 읽기 시간이 오래 걸리지만 읽기 제한 시간보다 짧은 경우(스트리밍할 때 적용한다고 가정하지만 여전히 적용하지 않는 경우일 수 있음) 지정한 . 확실히 이것은 시계 드리프트와 일광 절약 시간제가 어떻게 작동하는지 기억하고 time.time() 가 비참하게 불충분할 때까지 솔루션 @jribbens 에 의해 단순히 처리되어야 하는 것처럼 보일 것입니다.

마지막으로 Requests의 API가 고정되어 있다는 점을 염두에 두는 것이 중요합니다. 총 시간 제한을 지정하는 데 적합하거나 일관된 API가 없습니다. 그리고 우리가 당신이 제안한 것처럼 시간 초과를 구현했다면 1분 길이의 총 시간 초과를 지정하는 수많은 버그가 있었을 것입니다. 그러나 우리가 마지막으로 확인했을 때 1분 미만이었지만 구성된 읽기 시간 초과가 시간 초과 약 1분 30초 동안 오류가 발생했습니다. 이것은 이것을 찾는 사람들에게 약간 더 나을 _매우_ 거친 벽 시간 초과이지만, 이것을 직접 구현하는 사람과 다르지 않습니다.

@sigmavirus24 가 명확하지 않은 경우 사과드립니다. 마치 그것이 문자 그대로의 패치라고 생각하는 것처럼 내 의사 코드 원칙 설명을 비판한 것 같습니다. time.time() 는 당신이 생각하는 방식으로 작동하지 않는다는 점을 지적해야 합니다. 일광 절약 시간제는 관련이 없으며 여기서 말하는 시간 척도의 시계 왜곡도 마찬가지입니다. 또한 설명하는 버그가 발생할 것이라고 생각하면 제안을 오해한 것입니다. 마지막으로 API가 버전 2.9.0만큼 최근에 변경되었기 때문에 Requests API가 "고정"된다는 것이 무엇을 의미하는지 잘 모르겠습니다.

내 토론을 분리하기 위해: 나는 실제로 이것이 쉽다고 주장하는 것이 아닙니다. 그것이 완전히 간단하다면 나는 그것을 쓰고 당신을 괴롭히지 않을 것입니다. :)

내 문제는 다음과 같습니다.
1) 당신이 나열한 스레드의 모든 것은 원숭이 패치였습니다. 괜찮습니다. 하지만 프로덕션 품질 라이브러리에서 이것을 사용하고 있으며 모든 것을 깨뜨리는 내부 변경에 대한 경고를 받아들일 수 없습니다.
2) 당신이 준 링크의 시간 초과 데코레이터는 훌륭하지만 이것이 연결에 어떤 영향을 미치는지 확실하지 않습니다. 시간 초과를 수행하는 유일한 좋은 방법은 많은 스레드를 사용하는 것임을 인정하더라도 이 라이브러리는 소켓이 종료되고 연결이 끊어지는 등을 어떻게 강제합니까? 우리는 많은 연결을 수행하고 있으며 이는 잠재적으로 상당히 누출되기 쉬운. 요청에는 내가 찾을 수 있는 '중단' 방법이 없습니다(잘못된 경우 수정). 연결 종료는 어떻게 발생합니까?

내가 찾고 있는 것은 이 문제를 스스로 해결하는 방법에 대한 명확한 '축복받은' 버전이거나, 완벽한 솔루션이 없는 경우 경고가 포함된 몇 가지 솔루션이 논의된 것입니다. 말이 돼?

@emgerner-msft CPython을 사용한다고 가정하면 요청이 더 이상 계속되지 않으면 연결이 종료됩니다. 이 시점에서 기본 연결에 대한 모든 참조가 손실되고 소켓이 닫히고 폐기됩니다.

@루카사 네, 감사합니다! 라이브러리는 요청이 더 이상 계속되지 않는다고 어떻게 결정합니까? 예를 들어 타임아웃 데코레이터 경로를 사용하고 다운로드 중간에 끊긴 경우 실제로 다운로드가 언제 중지됩니까? 스트리밍 옵션과 관련하여 특별한 작업을 수행해야 합니까?

시간 초과 데코레이터를 사용하는 경우 시간 초과가 발생하면 다운로드가 중지됩니다. 이것은 신호가 syscall을 인터럽트하기 때문입니다. 즉, 소켓에 대한 추가 호출이 없습니다. 요청이 더 이상 범위에 포함되지 않으면(예: 스택이 requests.* 함수 외부로 풀림) 상태: CPython은 연결 개체를 정리하고 연결을 끊습니다. 특별한 스트리밍 옵션이 필요하지 않습니다.

완벽한. 다른 사람들이 더 할 말이 없으면 스레드를 닫는 것이 좋습니다.

사실 죄송합니다. 걱정거리가 하나 더 있습니다. Python Timers(아마도)와 달리 신호를 사용한다고 말했기 때문에 타임아웃 데코레이터 코드를 더 자세히 살펴보았습니다. Windows에서 작동하지 않도록 Python Signal 에 문서화된 SIGALRM으로 신호를 호출 하는 것 같습니다. Unix 및 Windows 환경은 물론 Python 2.7 및 3.3+(요청 자체와 매우 유사)에서 작동하려면 이것이 필요합니다. 조금 더 둘러보고 이것이 실제로 작동하는지 확인하겠습니다.

@emgerner-msft 답답하네요. =(

@Lukasa 예, 기본 사용 스니펫 을 시도했지만 Windows에서 작동하지 않습니다. 코드/예제를 좀 더 읽고 만지작거리며 신호를 사용하지 않으면 패키지가 작동할 수 있지만 모든 것이 선택 가능해야 하는데 이는 내 애플리케이션의 경우가 아닙니다. 내가 말할 수있는 한 시간 초과 데코레이터는 내 문제를 해결하지 못합니다. 다른 아이디어가 있습니까?

@emgerner-msft Windows 전용 신호가 적합하지 않다고 확신하십니까?

@Lukasa 솔직히 말해서, 나는 단순히 모릅니다. 나는 전에 신호를 사용하지 않았으며, 당신이 그들이 요청을 방해할 것이라고 말할 때까지 깨닫지 못한 것처럼 무엇이 적절한지 잘 모르겠습니다. 나는 또한 이것을 Windows에서 작동시키려고 하지 않습니다. 완전한 크로스플랫폼 지원(Windows 및 Unix)과 Python 2 및 Python 3 지원이 모두 필요합니다. 너무 많은 신호가 플랫폼에 따라 다르게 나타나서 나를 던지고 있습니다. Timer 는 내가 보고 있던 솔루션 중 하나로서 덜 낮은 수준으로 보이므로 제약을 처리할 수 있지만 연결을 어떻게 닫을 수 있는지 잘 모르겠습니다. 더 많은 것을 읽을 수는 있지만 이것이 여러분으로부터 추가 지침을 얻고자 하는 이유입니다. :)

그래서 이곳은 정말 까다로운 곳입니다.

현실은 기본적으로 신호인 인터럽트를 제외하고 스레드를 죽이는 크로스 플랫폼 방법이 거의 없다는 것입니다. 즉, 신호가 플랫폼 간에 이 작업을 수행하는 데 필요한 유일한 경로라고 생각합니다. 나는 Windowsy Pythony 전문가에게 ping을 시도하는 경향이 있습니다: @brettcannon , 여기에 좋은 제안이 있습니까?

흥미롭게도 구현 및 테스트에 작업이 필요한 것 외에 요청에 "총 시간 초과"를 구현하지 않을 이유가 있습니까? 내 말은, 그것을 구현하는 패치가 오늘날 마술처럼 나타난다면 이론적으로 거부되거나 받아들여질까요? "불필요한 복잡성 제거" 관점에 감사하고 동의하지만 "별도의 프로세스를 분기하여 수행할 수 있다"는 것이 제 생각에는 이 기능을 불필요하게 만드는 것은 아닙니다.

@jribbens 여기에는 몇 가지 문제가 있습니다.

파트 1은 그러한 패치의 복잡성이 매우 높다는 것입니다. 올바르게 작동하려면 소켓 수준에서 시간 초과를 반복적으로 변경해야 합니다. 이것은 우리가 원하는 것보다 더 많은 패치를 이미 패치한 httplib를 통해 패치를 널리 전달해야 함을 의미합니다. 기본적으로 이 기능적 변경을 달성하려면 httplib에 도달하고 더 복잡한 메서드의 약 50%를 다시 구현해야 합니다.

파트 2는 그러한 패치의 유지 관리가 상대적으로 부담된다는 것입니다. 이를 성공적으로 수행하려면 httplib의 병렬 포크(현재로서는 더 적절하게는 http.client)를 유지 관리하기 시작해야 할 것입니다. 또는 이러한 종류의 변경에 더 적합한 다른 HTTP 스택의 유지 관리 부담을 떠맡아야 합니다. 이 부분은 그러한 기능을 갖고자 하는 사람들이 흔히 놓치는 부분이라고 생각합니다. 구현 비용은 높지만 모든 플랫폼에서 해당 기능을 지원하는 지속적인 유지 관리 비용에 비하면 그것은 _아무것도_ 아닙니다.

3부에서는 그런 패치의 장점이 불분명하다. 전체 타임아웃 패치를 원하는 대부분의 사람들이 자신이 원하는 것에 대해 완전히 명확하게 생각하지 않는다는 것이 제 경험이었습니다. 대부분의 경우 총 시간 초과 매개변수는 아무 이유 없이 완벽하게 양호한 요청을 종료하는 효과를 가집니다.

예를 들어 파일을 다운로드하는 약간의 코드를 설계했으며 중단을 처리하려고 한다고 가정합니다. 처음에는 균일한 총 시간 제한을 설정하고 싶지만("요청은 30초 이상 걸릴 수 없습니다!") 이러한 시간 제한은 요점을 놓칩니다. 예를 들어 파일 크기가 30MB에서 30GB로 변경되면 다운로드가 완전히 정상일지라도 그러한 파일은 그런 종류의 시간 간격으로 _절대_ 다운로드할 수 없습니다.

다시 말해, 총 시간 초과는 매력적인 골칫거리입니다. 문제를 해결하는 것처럼 보이지만 효과적으로 해결하지는 못합니다. 제 생각에 더 유용한 접근 방식은 stream=True 및 iter_content 와 결합된 소켓별 작업 제한 시간을 활용하고 데이터 청크에 대한 제한 시간을 할당하는 것입니다. iter_content 가 작동하는 방식으로 제어 흐름은 다소 규칙적인 간격으로 코드에 반환됩니다. 즉, 소켓 수준 제한 시간(예: 5초)을 설정한 다음 상당히 작은 청크(예: 1KB 데이터)에 대해 iter_content 를 설정할 수 있으며 적극적으로 공격을 받지 않는 한 서비스 거부가 발생하지 않는다고 비교적 확신할 수 있습니다. 여기에서 가능합니다. 서비스 거부가 정말 걱정된다면 소켓 수준 제한 시간을 훨씬 더 낮게 설정하고 청크 크기를 더 작게(0.5초 및 512바이트) 설정하여 정기적으로 제어 흐름을 다시 받을 수 있도록 하십시오.

이 모든 것의 결과는 총 시간 초과가 이와 같은 라이브러리의 오작동이라고 생각한다는 것입니다. 가장 좋은 종류의 시간 제한은 큰 응답을 허용하여 평화롭게 다운로드할 수 있도록 조정된 것이며 이러한 시간 제한은 소켓 수준 시간 제한 및 iter_content 에 의해 가장 잘 제공됩니다.

아마도 @zooba 는 Windows가 어떻게 작동하는지 실제로 알고 있기 때문에 아이디어를 가지고 있을 것입니다. :)

(관련 없이 내가 가장 좋아하는 일 중 하나는 GitHub 문제에서 전문가의 데이지 체인을 설정하는 것입니다.)

하하, 이미 @zooba 와 @brettcannon을 알고 있습니다. 이 문제에 대한 해결책이 그들에게도 도움이 될 것이므로 여기 또는 내부적으로 그들과 논의할 수 있습니다.

@emgerner-msft 그럴 수도 있을 거라 생각했지만, 그렇게 생각하고 싶지는 않았습니다. MSFT는 큰 조직입니다!

@Lukasa 방금 위에 쓴 텍스트 벽을 읽는 것만으로도-재미있습니다! stream=True 및 iter_content에서 다운로드 시간에 대한 논의에서 대용량 업로드를 처리하는 동일한 방법은 무엇입니까?

_PS_: 위의 'Put another way,..'로 시작하는 단락은 내가 문서에서 찾던 일종의 지침입니다. 최대 시간 초과에 대한 요청 수(및 수행하지 않는 유효한 이유)를 감안할 때 가장 좋은 방법은 시간 초과 문서 에 해당 정보를 추가하는 것입니다.

lol @lukasa 유지보수에 대한 당신의 요점은 이미 마음속에 품고 있었지만 "특징 대 오작동"에 대해서는 당신과 완전히 반대입니다. 총 시간 초과를 원하지 않는 사람은 원하는 것이 무엇인지 명확하게 생각하지 않고 있으며 "30MB 다운로드가 30GB로 변경되어 실패합니다"라는 버그로 설명하는 상황을 상상하는 데 어려움이 있습니다. 사실 유익한 기능입니다!

stream=True 를 사용하여 약간 비슷한 작업을 수행할 수 있지만(총 시간 초과의 대부분의 이점이 없는 것으로 의심됨) 요청의 요지는 그것이 당신을 위해 처리했다는 것입니다...

나는 그것이 당신을 위해 일을 처리한다는 요청의 요점이라고 생각했습니다.

그것은 당신을 위해 HTTP를 처리합니다. 우리가 이미 연결 및 읽기 시간 초과를 처리하고 몇 년 동안 기능 정지에 대한 몇 가지 면제를 받았다는 사실은 유용성, 바람직함, 일관성(여러 플랫폼에서) 및 유지 관리 가능성에 대한 논의와 관련이 있습니다. 귀하의 피드백과 의견에 감사드립니다. 새로운 정보를 알려주시면 감사하겠습니다.

또한 이 프로젝트에서 거부된 기능 요청의 수와 사용자에 대한 공통 사용 패턴(요청 도구 벨트)을 구현하는 별도의 프로젝트가 있다는 사실에 의해 요청이 모든 것을 처리하지 않는다는 것을 알 수 있습니다. 총 시간 초과가 어디에나 속한다면 거기에 있을 것이지만 다시 말하지만 Windows, BSD, Linux 및 OSX에서 우수한 테스트 범위와 유지 관리에 대한 악몽 없이 작동해야 합니다.

stream=True 및 iter_content에서 다운로드 시간에 대한 논의에서 대용량 업로드를 처리하는 동일한 방법은 무엇입니까?

업로드를 위한 생성기를 정의하고 data 에 전달합니다. 또는 청크 인코딩이 당신에게 유리하지 않다면 마법 같은 read 메소드를 사용하여 파일류 객체를 정의하고 _that_ 을 data 에 전달하십시오.

조금 자세히 설명하겠습니다. 생성기를 data 에 전달하면 요청이 이를 반복하고 각 청크를 차례로 보냅니다. 즉, 데이터를 보내려면 각 청크에 대해 코드에 대한 제어 흐름을 반드시 전달해야 합니다. 이렇게 하면 요청을 완전히 중단하기 위한 예외 throw를 포함하여 그 시간에 원하는 모든 작업을 수행할 수 있습니다.

어떤 이유로 업로드에 청크 전송 인코딩을 사용할 수 없는 경우(아마도 문제의 서버가 실제로 나쁜 경우 가능), 길이가 있는 파일과 같은 객체를 만든 다음 다음을 수행하여 동일한 작업을 수행할 수 있습니다. read 호출에서 마법을 사용합니다. 이 호출은 8192바이트 청크에 대해 반복적으로 호출됩니다. 다시 말하지만, 이렇게 하면 제어 흐름이 간헐적으로 코드를 통과하여 고유한 논리를 사용할 수 있습니다.

추신: 위의 'Put another way,..'로 시작하는 단락은 내가 문서에서 찾던 일종의 지침입니다. 최대 시간 초과에 대한 요청 수(및 이를 수행하지 않는 유효한 이유)를 감안할 때 가장 좋은 방법은 시간 초과 문서에 해당 정보를 추가하는 것입니다.

나는 _추측한다_. 그러나 일반적으로 말해서 나는 문서에 다소 방어적인 텍스트를 넣는 것에 대해 항상 긴장하고 있습니다. FAQ에 들어갈 수 있을 것 같지만, 왜 우리에게 무언가가 없는 _없는_ 이유를 설명하는 텍스트는 문서에서 거의 유용하지 않습니다. 문서의 공간은 뭔가를 하기 위한 레시피에 의해 더 잘 제공될 것이라고 생각합니다.

총 시간 초과를 원하지 않는 사람은 원하는 것이 무엇인지 명확하게 생각하지 않고 있다고 생각합니다. 그리고 "30MB 다운로드가 30GB로 변경되어 실패합니다"라는 버그로 설명하는 상황을 상상하는 데 어려움이 있습니다. 사실 유익한 기능!

허, 난 아니야:

• 패키지 관리자(예: 요청을 사용하는 pip), 여기서 패키지는 데이터 크기가 크게 다를 수 있습니다.
• 크기가 매우 다양한 여러 사이트에 대해 실행될 수 있는 웹 스크레이퍼
• 매우 다양한 수준의 호스트에서 로그 파일을 다운로드하는 로그 수집기(따라서 로그 파일 크기)
• 비디오 다운로더(비디오는 크기가 크게 다를 수 있음)

실제로 개발자가 처리할 파일 크기를 10배 이내로 알고 있는 경우는 드문 경우라고 생각합니다. 대부분의 경우 개발자는 전혀 모릅니다. 그리고 일반적으로 이러한 크기에 대해 가정하는 것은 현명하지 않다고 말하고 싶습니다. 다운로드 크기에 대한 제약이 있는 경우 코드는 암시적으로 인코딩하고 다른 사람들이 읽을 수 있도록 사용자 네트워크의 대역폭과 혼합하기보다는 이러한 가정(예: 콘텐츠 길이 확인의 형태로)을 의도적으로 인코딩해야 합니다. 코드는 그것들을 명확하게 볼 수 있습니다.

하지만 요청의 요지는 그것이 당신을 위해 일을 처리하는 것이라고 생각했습니다 ...

요청은 매우 의도적으로 사용자를 위해 모든 것을 처리하지 않습니다. 모든 것을 하려고 하는 것은 불가능한 일이며, 그렇게 하는 좋은 라이브러리를 구축하는 것도 불가능합니다. 우리는 정기적으로 사용자에게 무언가를 달성하기 위해 urllib3으로 드롭다운하라고 말합니다.

우리는 대부분의 사용자가 할 수 있는 것보다 더 잘하거나 더 깔끔하게 할 수 있는 경우에만 요청에 코드를 넣습니다. 그렇지 않으면 가치가 없습니다. 특히 사용자 기반 전체에서 집계될 때 상대적으로 한계 유틸리티로 인식되는 점을 감안할 때 총 시간 초과가 그러한 것들 중 하나라는 점에서 저는 아직 매도하지 않았습니다.

즉, 나는 내가 틀렸다고 확신할 수 있습니다. 나는 아직 그것에 대한 설득력 있는 주장을 보지 못했습니다. 몇 가지 이유를 제공해야합니다!).

@sigmavirus24

총 시간 초과가 어디에나 속한다면 거기에 있을 것이지만 다시 말하지만 Windows, BSD, Linux 및 OSX에서 우수한 테스트 범위와 유지 관리에 대한 악몽 없이 작동해야 합니다.

동의!

@lukasa 내 생각은 내가 그것을 원할 뿐만 아니라 실제로 거의 모든 사용자가 그것에 대해 생각하면(또는 이미 존재하지 않는다는 것을 깨닫지 못한다면) 원할 것이라는 것입니다. 피해야 한다고 말한 위의 사용 시나리오 중 절반은 중요하다고 말하고 싶습니다(웹 스크레이퍼 및 로그 수집기) - 다른 두 가지는 다음과 같은 경우 수동으로 다운로드를 취소할 수 있는 결과를 기다리는 사용자가 있을 가능성이 있으므로 덜 필요합니다. 그들은 원한다. UI 없이 백그라운드에서 실행되고 전체 시간 제한을 사용하지 않는 모든 것은 내 보기에 버그가 있습니다!

내 생각은 내가 그것을 원할 뿐만 아니라 실제로 거의 모든 사용자가 그것에 대해 생각하면(또는 이미 존재하지 않는다는 것을 깨닫지 못한다면) 원할 것이라는 것입니다.

@jribbens 우리는 사용자 요구 사항을 이해하고 대화하는 데 몇 년(우리 세 사람의 경험을 합치면 10년 이상)이 있습니다. 거의 모든(최소 98%) 사용자에게 필요한 것은 연결 및 읽기 시간 초과였습니다. 우리는 사용자의 목소리가 매우 작은 소수가 전체 시간 초과를 원한다는 것을 이해합니다. 해당 기능에 대한 잠재적 사용자 그룹의 규모와 해당 기능이 필요하지 않은 사용자의 잠재적 규모 및 기능의 유지 관리 및 개발의 복잡성으로 추정할 수 있는 사항을 감안할 때 실제로는 우리가 하려는 일이 아닙니다. 할 것.

공유할 _새로운_ 것이 있다면 우리는 그것을 듣고 싶습니다. 그러나 지금까지 말씀하신 것은 전체 시간 제한 없이 요청을 사용하는 모든 것이 버그가 있다는 것입니다. 그들의 디자인 결정이 버그가 있다는 당신의 주장에 화를 낼 것입니다. 따라서 사용자의 지성을 모욕하는 것은 삼가해 주십시오.

@sigmavirus24 이 스레드 전체에서 당신은 불필요하게 모욕적이고 선동적이며 무례했습니다. 정중하게 부탁하는 바입니다. 제발 그만해 주세요.

@Lukasa 스트리밍 업로드 및 다운로드 및 이러한 주제에 대한 문서를 읽는 방법에 대한 귀하의 제안을 자세히 살펴보았습니다. 내 가정/질문을 확인할 수 있다면 좋을 것입니다.

1. 스트리밍 다운로드의 경우 읽기 제한 시간 '(예: 5s) 및 상당히 작은 청크(예: 1KB 데이터)'에 대한 iter_content'를 사용하는 경우 요청 라이브러리가 1KB의 각 읽기에 대해 5초 제한 시간을 적용하고 만약 그렇다면 제한 시간을 적용합니다. 5초 이상 걸립니다. 옳은?
2. 스트리밍 업로드의 경우 데이터 청크를 반환하는 객체와 같은 파일을 사용하고 읽기 제한 시간을 5초로 설정하면 요청 라이브러리가 반환하는 각 청크에 대해 5초 제한 시간을 적용하고 더 오래 걸리는 경우 제한 시간을 적용합니다. 옳은?
3. 업로드를 위해 생성기를 사용하지 않고 단순히 바이트를 직접 전달하는 경우 요청 라이브러리에서 내가 설정한 읽기 제한 시간을 적용하기로 결정하는 방법은 무엇입니까? 예를 들어 크기가 4MB인 청크와 5초의 읽기 제한 시간을 전달하면 해당 읽기 제한 시간이 정확히 언제 적용됩니까?
4. iter_content를 사용하지 않고 읽기 제한 시간이 5초인 요청으로 모든 콘텐츠를 직접 다운로드하도록 요청하는 경우 해당 읽기 제한 시간이 정확히 언제 적용됩니까?

소켓/TCP 프로토콜/등에 대한 일반적인 이해가 있지만 urllib가 낮은 수준에서 이러한 개념과 어떻게 작동하는지 또는 요청이 값을 전달하는 것 외에 특별한 작업을 수행하는지 정확히 알지 못합니다. 단순히 제어 흐름을 다시 가져오고 스레드 종료와 관련된 크로스플랫폼 문제를 감안할 때 자체 제한 시간 체계를 적용하는 것이 작동하지 않기 때문에 제한 시간이 어떻게 적용되는지 정확히 이해하고 싶습니다. 내 질문에 답할 수 있는 추가 읽기 자료가 있으면 언제든지 저를 참조하십시오! 어쨌든 이것이 나의 마지막 질문이 되기를 바랍니다. :)

지금까지 도와주셔서 감사합니다.

@emgerner-msft 확인:

1. 아니요. 슬프게도 그보다 더 복잡합니다. 논의된 바와 같이 각 시간 초과는 _소켓 호출당_ 적용되지만 주어진 청크에 얼마나 많은 소켓 호출이 있는지 보장할 수 없습니다. 이에 대한 매우 복잡한 이유는 표준 라이브러리가 백업 소켓을 버퍼 객체(보통 io.BufferedReader 와 같은 것)에 래핑하기 때문입니다. 충분한 데이터를 제공할 때까지 필요한 만큼의 recv_into 호출을 수행합니다. 그것은 0만큼 적거나(버퍼에 충분한 데이터가 이미 있는 경우) 원격 피어가 한 번에 한 바이트를 드립-피드(drip-feed)하는 경우 수신한 바이트 수만큼 정확할 수 있습니다. 이에 대해 우리가 할 수 있는 일은 거의 없습니다. 이러한 버퍼링된 개체에 대한 read() 호출의 특성으로 인해 각 recv_into 호출 간에 제어 흐름을 다시 얻지 못합니다.

즉, n초 이상 기다리지 않도록 하는 _유일한_ 방법은 1 iter_content 를 수행하는 것입니다. 이것은 파일을 다운로드하는 터무니없이 비효율적인 방법이지만(Python 코드에서 너무 많은 시간을 소비함) 원하는 보장을 얻을 수 있는 유일한 방법입니다.

1. 나는 또한 그것에 대한 대답이 아니오라고 믿습니다. 현재 _send_ 시간 초과에 대한 개념이 없습니다. 하나를 얻는 방법은 socket.setdefaulttimeout 를 사용하는 것입니다.
2. 읽기 제한 시간은 읽기에만 적용되므로 본문을 전달하는 방법은 중요하지 않습니다.
3. 읽기 시간 초과는 iter_content 경우와 동일한 문제를 겪습니다. 모든 것을 다운로드하라는 요청이 있는 경우 본문을 다운로드하는 데 필요한 만큼의 recv_into 호출을 내보내고 시간 초과가 적용됩니다. 차례대로 각자에게.

여기서 핵심 문제에 부딪히게 됩니다. 요청이 정확히 원하는 것을 달성할 수 있을 만큼 소켓에 충분히 가까워지지 않습니다. 보내기 시간 초과를 추가할 수 있습니다. 이는 고려 중인 기능 요청 작업이며 읽기 시간 초과와 같은 문제를 겪지 않지만 다른 모든 경우에는 httplib 가 스와핑을 (올바르게) 주장하기 때문에 멈춥니다. 버퍼링된 소켓 표현으로 변경하고 나머지 httplib 는 버퍼링된 표현을 사용합니다.

@루카사

아, 엉망이야, 하하. 그럴 수도 있다고 생각했지만 사실은 내가 틀렸기를 바랐다.

먼저 send timeout이 절실히 필요합니다. 사용자에게 업로드가 무한정 중단될 수 있으며 문제를 해결할 계획이 없다고 말할 수 없습니다. :/

현재로서는 불가능한 상황인 것 같습니다. 총 시간 초과에 대한 라이브러리 지원이 없습니다(이를 이해합니다). 기존 시간 제한이 다양한 청크 크기에서 어떻게 작동하는지 정확히 보장할 수 없습니다. 만약 있다면 시간을 요약할 수 있습니다: 연결 시간 초과 + 읽기 시간 초과 * 청크 크기. 스트림 모드와 생성기로 흐름을 중단할 수 있는 것은 좋지만 크로스 플랫폼 방식으로 스레드를 실제로 중단하는 솔루션이 없기 때문에 이것도 도움이 되지 않습니다. 앞으로 나아갈 다른 옵션이 있습니까? 다른 사용자들은 이러한 문제를 해결하기 위해 무엇을 하고 있습니까?

먼저 send timeout이 절실히 필요합니다. 사용자에게 업로드가 무한정 중단될 수 있으며 문제를 해결할 계획이 없다고 말할 수 없습니다. :/

따라서 요청에 사용되는 시간 초과 논리는 기본적으로 urllib3의 논리이므로 변경을 수행하기에 충분해야 합니다. 자유롭게 기능 요청을 열면 변경을 통해 도움을 드릴 수 있습니다. 그리고 단기적으로는 setdefaulttimeout 를 사용하여 자유롭게 조사하십시오.

앞으로 나아갈 다른 옵션이 있습니까? 다른 사용자들은 이러한 문제를 해결하기 위해 무엇을 하고 있습니까?

여기에 있는 옵션은 특정 제약 조건에 따라 다릅니다.

결정적 타임아웃이 _반드시_ 있어야 하는 경우(즉, 요청이 _n_초 이상 걸리지 않도록 보장할 수 있어야 하는 경우) 오늘날 존재하는 Python 표준 라이브러리로 쉽게 그렇게 할 수 없습니다. Python 2.7에서는 각 recv 호출에 대해 순차적인 시간 제한을 실행할 수 있도록 socket._fileobject 를 패치해야 하지만 Python 3에서는 구현된 클래스에 패치해야 하기 때문에 훨씬 더 어렵습니다. C( io.BufferedReader )에 있습니다. 이것은 악몽이 될 것입니다.

그렇지 않으면 표준 라이브러리에서 버퍼링을 _해제_ 해제하는 것이 유일한 방법입니다. 그것은 httplib와 그 위에 있는 모든 패치를 깨뜨릴 것입니다. 소켓에서 read 시스템 호출처럼 동작하지 않고 대신 $#처럼 동작하는 read(x) 호출을 할 수 있다고 가정합니다 read 파일에 대한 시스템 호출(즉, 결정적 길이를 반환).

다시 말해, 결정적 타임아웃이 _필요하면_ 엄청난 수의 라이브러리가 이를 제공할 수 없다는 것을 알게 될 것입니다. 기본적으로 httplib 또는 socket.makefile 를 사용하면 운이 나쁠 것입니다. 반복적으로 발행하는 길이를 제외하고 정의된 시간에 제어가 사용자에게 반환되도록 보장할 수 있는 확실한 방법은 없습니다. -1 읽습니다. 당신은 _할 수_ 있지만, 당신의 성과에 해를 끼칠 것입니다.

따라서 여기에 절충안이 있습니다. 결정적 시간 제한을 원할 경우 Python 표준 라이브러리(및 요청에서)에서 버퍼링이 구현되는 방식은 이를 사용할 수 없게 만듭니다. 버퍼링을 비활성화하고 코드를 다시 작성하여 이를 다시 얻을 수 있지만 시간 초과를 확인하는 방식으로 버퍼링을 다시 구현하지 않는 한 잠재적으로 성능이 상당히 나빠질 수 있습니다.

BufferedReader 클래스의 Python 표준 라이브러리에 필요한 코드를 구현하는 것을 목표로 할 수 있습니다. Python 사용자에게 관심이 있는지 확실히 물어볼 수 있습니다. 그러나 나는 숨을 참지 않을 것입니다.

따라서 요청에 사용되는 시간 초과 논리는 기본적으로 urllib3의 논리이므로 변경을 수행하기에 충분해야 합니다. 자유롭게 기능 요청을 열면 변경을 통해 도움을 드릴 수 있습니다. 그리고 단기적으로는 setdefaulttimeout을 사용하여 자유롭게 조사하십시오.

urllib3 또는 여기에서 기능 요청? 최대한 빨리 하나(또는 둘 다)를 열 것입니다.

urllib3의 기능 요청: 요청에서 새로운 것을 노출할 필요가 없습니다.