Q&A
それを知ることでなにかプログラムに違いがあるのでしょうか？
requestsライブラリを用いた際の、connectionタイムアウトについて調べていたのですが、少々疑問な点があり質問させて貰いました。
connect timeoutは相手のサーバーと接続を確立するまでの待機時間であると思います。
サーバーがダウンしている場合は、何度接続を試みても接続が確率することはないかと思いますが、ダウンしていない場合で、接続出来ない場合というのはどのような場合なのでしょうか？
requestsを使用した場合のコネクションタイムアウトの時間を設定する上で、判断材料にしたいと考えております為、ご助言頂けましたら幸いです。
参考にした記事は、こちらになります。
回答1件
0
ベストアンサー
ダウンしていない場合で、接続出来ない場合というのはどのような場合なのでしょうか？
-
通信経路の帯域幅が極端に狭く（単位時間あたりの送受信可能データ数が少ない）、接続が確立するまで時間がかかる。
-
サーバー側、ポートをLISTENしている側のファイアウォールで接続をブロックされている。ルーターかもしれないし、サーバーが稼働しているマシンかもしれない。ブロックの仕方によってはサーバー側からは完全に無応答になるので、やはりタイムアウトになる。
他にもある気はしますが、TCPについて主だって思い付いたものは以上2つ、でした。
投稿2020/10/27 09:36
編集2020/10/27 09:48
総合スコア9183
ご回答ありがとうございます。
ご回答頂きました２点を考慮しますと、requestsを使用した場合のコネクションタイムアウトの時間を設定は長い時間の指定は必要ないという結果になりますでしょうか...?
タグに「HTTPS」がついていたので思い出しましたが、回答で挙げた「帯域幅」の話は実際に以前に経験したことがあります。ある地方部署でダイヤルアップの回線があって、HTTPなら繋がるがHTTPSだとNG、ということがありました。HTTPSだと最初の鍵交換の段階で時間がかかりすぎ、タイムアウトしていた様子です。
> requestsを使用した場合のコネクションタイムアウトの時間を設定は長い時間の指定は必要ないという結果になりますでしょうか...?
ん？ なぜ指定の必要が無いと判断されるのでしょうか。むしろ指定の必要があるような。
おそらく「長い時間の」指定は必要ない、ということじゃないでしょうか。
> 「長い時間の」指定は必要ない、ということ
だとしてもなぜ？ という思いです。
とりあえずTCPの接続の話に限りますが、接続のタイムアウト監視時間の既定値はOSによって異なります。Windowsだと約20秒、Linuxだと約3分だったと思います。（OSのバージョン、設定によっても違うかもしれない）それで短い場合は、プログラム自身で接続のタイムアウト監視時間を適切に指定する必要があります。
少々自分勘違いしてしまっていたかもしれないのですが、
> 通信経路の帯域幅が極端に狭く（単位時間あたりの送受信可能データ数が少ない）、接続が確立するまで時間がかかる。
こちらは、仮に「requests」を使用し、ホストへ接続した場合、ホストのサーバーは関係なく、クライアント側の接続している回線の状態が関係してくるということでしょうか...?
>長い時間の指定は必要ない
こう思った理由につきましては、接続に時間がかかる = ファイヤーウォールなどの問題により、サーバー側に接続がブロックされているなどの現象が発生していると考えました為、その場合どれだけ長く接続を試みても、アクセスできる可能性は低い為、長い時間の指定は必要ないのではないかと思いました
> こちらは、仮に「requests」を使用し、ホストへ接続した場合、ホストのサーバーは関係なく、クライアント側の接続している回線の状態が関係してくるということでしょうか...?
そうですね。実際の回線を含み、プロバイダの利用状態、途中のルーター、ハブの処理および性能、マシン自体のそれなど総合的に関係するでしょう。
> 長い時間の」指定は必要ない
> こう思った理由につきましては、接続に時間がかかる = ファイヤーウォールなどの問題により、サーバー側に接続がブロックされているなどの現象が発生していると考えました為、
時間についてはファイアウォールで接続を阻まれている場合は一定であるはずですが、帯域幅の増減によるものはそうではなくなります。
考え方次第ですが、20秒待機しても接続NGだが30秒だったらOKの割合が増えた、というケースはあり得ます。ですが、OSが既定値で用意しているということは一般的にはその値で充分だろうとの判断から来ているはずなので、それに従って既定値のまま使うのも仕様としてアリだと個人的には思います。
プログラムの機能としてみた場合、万一の場合の救済方法としてタイムアウト値の設定機能を設けておくのは安心材料になり得ます。不特定多数が様々な場所で利用する予定の製品では、そのような策を講じておくことはあります。
ご丁寧にありがとうございます。
どうも知らなかったのですが、requestsはタイムアウトを設定しなかった場合は応答があるまで待ち続けるみたいですし、タイムアウトの時間は設定しておこうと思いますが、何回か自分もrequestsを使用し、テストを行い、設定する時間を決めていきたいと思います。
もし、python/requestsの挙動を正確に調べるのであれば、そのソース自体も確認した方が良いです。OSのソケット関連のシステムコール、WindowsであればWin32API、WinSockなどが関係します。
ありがとうございます。
ライブラリのソースは難解に感じることが多い為、あまり自分でみたりしないのですが、確認することも頭に入れておきたいと思います。
※誤解を生みそうなコメントをしたので自己レスとして補足です。すみません。
[2020/10/27 19:02]の私のコメント:
> HTTPなら繋がるがHTTPSだとNG、ということがありました。HTTPSだと最初の鍵交換の段階で時間がかかりすぎ、タイムアウトしていた様子です。
TCPのconnectシステムコールでのタイムアウトとHTTPSでの鍵交換がうまくいかなかったことによるタイムアウトは層が違うので、ちょっと不適切な取りあげ方でした。Windowsでの話で、使っていたAPIもWinHTTPなので比較するのが不適切でした。失礼しました。回答はあくまでconnectレベルでの話で、内容は変更ありません。
あなたの回答
tips
プレビュー
