また、質問は止まらないため、ここで回答できます。
ビデオが遅延しているのはなぜですか？
このトピックに関するブログにはすでに2つの記事（ 1、2 ）があり、ビデオを使用している場合はそれらをお読みください。ここで、短く包括的な答えを示します。
現代のインターネットストリーミングはHLSプロトコルです 。 時々DASHですが、どちらもセグメント化されているため、これは重要ではありません。
どのように機能しますか？ ストリーミングビデオは小さなファイルに「カット」され（コンテンツのダイナミクスに応じて通常2〜8秒）、3〜10個のセグメントが特別なプレイリストによって蓄積および記述されます。古いセグメントが削除され、新しいセグメントが追加されると自動的に更新されます とても簡単です。 より多くのセグメント-より長い遅延、各セグメントのより長い期間-より長い遅延。 10〜20秒が正常です。
なぜこれが必要なのですか？ ビデオサーバーに多数のビデオを蓄積するのはなぜですか？ セグメンテーションにより、プレーヤーはインターネット接続の不安定性に反応せず、Wi-Fiネットワークからモバイル接続に切り替えるときにビデオを中断することができません。 ビデオが事前に準備されておらず、個別のファイルにパックされていなかった場合、わずかなグリッチや帯域幅の不足があれば、画面にビデオのアーティファクトがあり、セグメンテーションはプレーヤーの接続を復元して新しいデータをロードするためにプレーヤーに約4-20秒を与えます。
遅延なくビデオが必要な場合はどうしますか？ Webチャットの手配、インターネット経由でのヘリコプターの制御、IPビデオカメラの視聴を行う場合は、別のプロトコルを選択してください。 次に例を示します。WebRTC、MSE-LD、RTMP。
ビデオを保護する方法は？ サイトにのみ貼り付け
タスクは非常に簡単です-サイトの動画は他のサイトに挿入されないように保護する必要があります。他の人のトラフィックに対して誰も支払いたくないため、動画のトラフィックは高価です。 また、動画は非公開にすることができ、個人アカウントを超えてはなりません。
このようなリクエストには常に1つの答えがあります。サイトでSecurelinkを設定する必要があります。 コンテンツ保護は一方的には不可能です-サイト自体がリンクを生成する必要があります。サイトへの静的リンクを取得して挿入することはできません。
Securelinkは、古くて非常に効果的なリンク保護テクノロジーです。 多くのhabruchitelはNginxの特別なモジュール-ngx_http_secure_link_moduleについて知っています。 Nginxは使用していませんが、同様の効率的な実装があり、唯一の違いはパラメーターの順序です。
どのように機能しますか？ このサイトは、ユーザーデータに基づいて一意のワンタイムリンクを生成します。 また、Webサーバーはクライアントについて何を知っていますか？ そうです、これはIPアドレス、ユーザーエージェント、Cookie、要求されたURLです。 クライアントが承認されている場合、セッション変数で他の情報、たとえばサービスデータベース内の一意のクライアントID、またはたとえばサブスクリプションの有効期間を取得できます。
パラメーターを1行で収集し、お気に入りのアルゴリズム（SHA1など）でハッシュします。 役に立たない文字のセットが判明します。 たとえば、文字列「127.0.0.1Habr」のハッシュは70ebe94671dd21bd65f4a00dfd988adc83fe6bdaになります。
このラインはビデオストリーマーに送信され、そのタスクは、リンクがサイトによって生成されたものであり、「腐敗」していないこと、第三者に渡されていないことを確認することです。 サイトからのフィードバックがないため、ビデオストリーマは、Webサイトが使用したのと同じデータを使用してハッシュを生成する必要があります。 ビデオストリーマは、クライアントのIPアドレス、要求されたコンテンツも知っていますが、ユーザーIDまたはリンクの有効期間を知ることはできません。 このデータをリンクに直接転送し、秘密キーを使用して、誰もが自分でリンクを生成できないようにする必要があります。
「127.0.0.1Habr1540327100SECRET」という行を取得し、SHA1 99fe961672c52aa3033b98b545ec2cdec93bf515を取得し、次の形式のリンクを作成します。
example.com/Habr/index.m3u8?token=99fe961672c52aa3033b98b545ec2cdec93bf515-1540327100
example.comはビデオサーバー、Habrは要求されたビデオ、index.m3u8はHLSプレイリストの標準名、valueトークンは生成したWebサーバーからの文字列です。
ビデオストリーマは、同じハッシュを取得するために必要なすべてをこのデータから簡単に抽出します。IPアドレスはWebサーバー変数から読み取られ、要求されたコンテンツはURLから、ライフタイムはトークンパラメーターから、不足しているのは秘密キーだけです。構成ファイルに登録して、秘密を守ってください。
このようなリンクを友人に送信したり、別のブラウザで開いたりすることはできません。ハッシュ式にIPアドレスが含まれているため、ライフタイムを置き換えることができません。ハッシュは一致しません。
落とし穴
私は本当に2つの段落で説明したかったのですが、要するにうまくいきませんでした。 これが最初の問題です。静的リンクを挿入する方がはるかに簡単なので、誰もがそのような詳細を掘り下げる準備ができているわけではありません。 私たちのサイトには既製のサンプルがありますので、問題はないはずです。
サイトとWebサーバーがクライアントのIPアドレスを誤って決定することがよくあります。これは、CloudFlareなどのCDNネットワークが使用されている場合は正常です。 この場合、正しいヘッダーからIPアドレスを取得する必要があります。CDNプロバイダーの助けが必要な場合があります。 たとえば、CloudFlareにはCF-Connecting-IPがあります。
間違った時間。 いずれかのサーバーでの時間の間違いと、リンクの寿命を最小化する試みとの組み合わせが、リンクの破損につながることがよくあります。 また、ユーザーがタブを数時間開いたままにし、寿命が短いためにビデオを再生できないこともあります。
リンクの有効期間は3〜24時間です。これは正常であり、とにかく保護されており、同時表示の数を制限する方法があります。
合計ではなく
このリンク保護メカニズムを回避する方法をコメントで教えてください。