video.dit.mos.ru/window
このリソースの注目すべき点は、内蔵プレーヤーを介してビデオ監視カメラへのパブリックアクセスを提供することです 。
この記事では、「塩」、砂糖、健康なものはありません
プレーヤーがそのリソースで使用するリンクのリスト:
http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18_axis_media_media.amp/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.22:2033/rtsp___10.208.1.186_axis_media_media.amp/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.22:2033/rtsp___10.208.0.50_axis_media_media.amp/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.22:2033/rtsp___10.208.41.134_axis_media_media.amp/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.23:2033/rtsp___10.194.23.9_axis_media_media.amp/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.30.24:2033/rtsp___10.208.14.78_axis_media_media.amp_camera_4/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.30.33:2033/rtsp___10.208.14.117_axis_media_media.amp_camera_2/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.26.150:2033/rtsp___10.232.0.121_live_h264/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.26.150:2033/rtsp___10.232.0.1_live_h264/live http://videoproxy2.echd.ru:41025/rtsplive/10.200.26.153:2033/rtsp___10.232.0.113_live_h264/live
プログラマーのロジックを「 緩め! 」オンにします。
-
videoproxy2.echd.ru:41025/rtsplive
videoproxy2.echd.ru:41025/rtsplive
はプロキシです -
10.200.30.33:2033
これはキャッシングサーバーです -
rtsp___10.208.14.117_axis_media_media.amp_camera_2/live
これはサーバー上のカメラからのストリームへのリンクです。
作業リンク:
-
videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18_axis_media_media.amp/live
-
videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18_axis_media_media.amp
壊れたリンク:
-
videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18
-
videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:80
-
videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:81
-
videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:8080
-
videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:8081
-
videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:[_rtsp_ wiki, 7020 27020]
検索の自動化
理論:
- 1つのプロキシのみ( videoproxy2.echd.ru:41025/rtsplive/ )
- キャッシュサーバーのポートは変更されていません( :2033 )
- ポニーテール_axis_media_media.amp / live
- ポニーテール_live_h264 / live
次に、_camera_4など。 「10.200.30.24:2033/rtsp___10.208.14.7 8 _axis_media_media.amp_camera _4 / live」があり、「10.200.30.24:2033/rtsp ___ 10.208.14.7 7 _axis_media_media.amp_camera _3 / live」がないため、考慮されません。しかし、ロジックに従って、 "_ axis_media_media.amp / live"が存在する必要があります-これが私たちが探しているものです。
キャッシングサーバーのIPリスト:
- 10.200.21.21
- 10.200.21.22
- 10.200.21.23
- 10.200.30.24
- 10.200.30.33
- 10.200.26.150
- 10.200.26.153
理想的には、範囲として10.200.21.1--10.200.30.254を選択します。
カメラのIPアドレスのリスト:
- 10.194.1.7
- 10.194.23.9
- 10.208.0.50
- 10.208.1.186
- 10.208.14.117
- 10.208.41.134
- 10.232.0.113
- 10.232.0.121
範囲(再び完璧)として、 10.200を除く10.194.0.1〜10.2.232.255.254のアドレスを使用します。*。* 、私のロジックでは(私がしたように)これらはキャッシュサーバーです。
結果として、クエリのテンプレートは次のとおりです。
-
videoproxy2.echd.ru:41025/rtsplive/10.200.
ip13 ip14 :2033 / rtsp ___ 10。 ip22 。 ip23 。 ip24 _axis_media_media.amp / live -
videoproxy2.echd.ru:41025/rtsplive/10.200.
ip13 ip14 :2033 / rtsp ___ 10。 ip22 。 ip23 。 ip24 _live_h264 /ライブ
- ip13-21..30
- ip14-0..254
- ip22-194..232
- ip23-0..255
- ip24-1..254
50億のアドレスとリクエスト...実際には、リクエストの数ははるかに少なく、10〜15秒のスクリプトダウンタイムで903kのリクエストを保存することもできます...(詳細は以下を参照)。
成功:
- 成功した場合、サーバーはContent-type x-flvに戻すか、逆条件がNOT textです。
- 成功した場合、サーバーは1〜3秒かかります。
失敗:
- サーバーは、 Content-typeに テキストがある200〜400ミリ秒を担当します 。
- サーバーは 、「存在しない」キャッシュサーバーに要求を送信すると長い間考えます。この場合、このサーバーでの解析を停止し、「上位」のIPにジャンプする必要があります。
解析時間を最小限に抑えるために、接続タイムアウトを10000ミリ秒に設定し、リクエストの前とリクエストの後に(サーバーが応答したとき、またはクライアントでタイムアウトが働いたとき)、時間値を保存します。 次に、2番目から1番目を減算し、9500ミリ秒以上が経過すると、1 IP高くなります(キャッシュサーバーの場合)。これにより、 903,224リクエストまたは上記の10秒間の104日間の待機が節約されます。
また、カメラリンクは円で実行されることを理解する必要があり、前の記事で述べたように、約140,000台のカメラがあります。 サーバーは毎秒10件のリクエストを落ち着いて送信するため、すでに140,000台のカメラが見つかった場合、今後それらを検索する必要はありません。
しかし、非常に多くのアドレスの解析には永遠に時間がかかり、私たちはまだマトリックスにいません!
練習する
検索を減らす:
- 10.200.21.21-24、カメラ10. [194、208、232] .0-255.1-254
- 10.200.30.21-34、チャンバー10. [194、208、232] .0-255.1-254
- 10.200.26.150-153、カメラ10.232.0-255.1-254
プロキシはスレッドごとに10個のリクエストを冷静に処理します... 8スレッド、16スレッド... 16で十分です1秒あたり合計160個のリンクと2〜3メガビットのレベルのストリームで、ネットワークに負荷をかけません。
サーバーからの応答:
video / x-flv-サーバーを介してカメラからストリームを受信した場合、text / html-エラーメッセージの場合 プログラムでは、x-flvを見つけるのではなく、テキストがないという条件を作成する必要があります。 カメラが横たわっている場合、サーバーはただdrれているだけで、何も得られませんが、カメラはあります。
その結果、 608台のカメラが見つかりました。
IP | .21.23 | .21.22 | .21.21 | .26.150 | .26.151 | .30.21 | .26.152 | .30.24 | .26.153 | .30.23 | .30.25 | .21.24 | .30.22 |
数 | 193 | 176 | 171 | 31 | 10 | 7 | 4 | 4 | 3 | 3 | 3 | 2 | 1 |
- 540台のカメラ_axis_media_media.amp / live
- 68台のカメラ_live_h264 /ライブ
通知:
- 1月27日の正午に、1時間後、ライダーの個人がメールを見るために手紙を@ditに送信しました。 手紙はそれが何をどのように機能するかを説明した。
- 1月28日、正午-dit-video @への新しい手紙。彼はすでにdit @に書いており、回答がなかったことに言及しました(各手紙は私がニュースを待っていることを示していました)
「ニュース」:
- この例のカメラリンクは27日、静かに静かに閉じられました。
この公開後、 videoproxy2のチェックを導入して、「window」プロジェクトのカメラのみを配布することを希望します。 他のカメラ/すべてのカメラの場合、 blablaproxy2を上げることができます 。これはどこにも輝きませんし 、 https経由で動作します 。
関連リンク:
プレイヤーのページ || mysql形式のダンプ (コメント内のフィールドの説明)。