HLS（HTTP Live Streaming）とは？概要・仕組み・課題など｜Agora Go Real｜オンラインイベント・ウェビナー・Web会議ブイキューブ
HLSとは HLSはHTTP Live Streamingの略であり、Apple社が独自に開発した規格です。iOSだけでなく、Android（ネイティブ）や多くのWebブラウザで再生可能であり、AbemaTVのようなライブ配信サービスにも採用されています。 HLSの概要 HLSの特徴として以下のようなポイントが挙げられます。 また、HLSはインデックスファイルとセグメントファイルとに分かれて構成されている点も特徴のひとつ。インデックスファイルはm3u8プレイリストと呼ばれ、セグメントファイルの場所や再生時間、再生順序などを定義したメタデータです。 一方のセグメントファイルはtsファイルと呼ばれており、MPEG2 Transport Stream形式で細かく分割された複数の動画データファイル形式で配信されます。 mp4との違い 動画ファイルで使われているmp4との違いですが、mp4をストリー
第1回 HTTPプロトコルとは
本入門連載では、システム管理者やシステムエンジニアの方々を主な対象として、IT業界でよく使われる技術や概念、サービスなどの解説をコンパクトにまとめておく。 Webの基本プロトコル、HTTPとは？ Webブラウザを使ってWebサイト（Webサーバ）にアクセスする場合、そこでは「HTTP（Hypertext Transfer Protocol）」というネットワークプロトコルが利用されている。Webブラウザのアドレスバーに「http://www.atmarkit.co.jp/」などと入力した場合の、「http:」の部分のことである。これはHTTPというプロトコル＊1を使って、サイトwww.atmarkit.co.jpにアクセスせよ、という指令である。 Webサーバというと、Webブラウザを使ってアクセスするものと考えるかもしれないが、現在ではさまざまなサービスでWebサーバやHTTPプロトコルが
RESTful API の設計のキホン
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
「HTTP」の仕組みをおさらいしよう（その1）
「HTTP」の仕組みをおさらいしよう（その1）：リトライ！ 触って学ぶTCP/IP（2）（1/3 ページ） 第2回では、まず、コンピューター同士が行う通信の種類について説明します。その後、Webにおいて広く利用されている「HTTP」の仕組みについて、ツールを使って実際の動作を確認しながら学びます。 連載目次 まずは通信の全体像から この連載は「コンピューター同士の通信」をテーマにしているわけですが、ここでいうコンピューター同士の通信とは、いったいどんなことを指すのでしょうか？ シンプルにいえば、「あるコンピューターから別のコンピューターに、何らかの情報を伝える」ことだといえます。 もちろん実際にコンピューター同士の通信を成し遂げるには、各コンピューターをネットワークにつなぎ、ネットワークの構成を行い……と、さまざまな準備が必要なのですが、取りあえずそんな細かいことは全て忘れて、誰かが通信に
「HTTP」の仕組みをおさらいしよう（その2）
「HTTP」の仕組みをおさらいしよう（その2）：リトライ！ 触って学ぶTCP/IP（3）（1/3 ページ） ネットワークの基礎を支えるTCP/IPを基本から学び直す本連載。第3回では、前回に引き続き、HTTP通信の仕組みをおさらいします。前回は「HTTPリクエスト」について学びましたので、今回はWebサーバーがクライアントに返送する「HTTPレスポンス」について解説します。 連載目次 前回は、HTTP通信において、クライアントからWebサーバーに送信する「HTTPリクエスト」について学習しました。今回は引き続き、Webサーバーがクライアントに返送する「HTTPレスポンス」の内容について見ていきましょう。 HTTPレスポンスの中身 ブラウザーなどからWebサーバーにリクエストを送ると、Webサーバーは受け取ったリクエストを処理して、その結果を「レスポンス」として返します。例えば、「HTMLフ
「HTTP」の仕組みをおさらいしよう（その3）
「HTTP」の仕組みをおさらいしよう（その3）：リトライ！ 触って学ぶTCP/IP（4）（1/4 ページ） ネットワークの基礎を支えるTCP/IPを基本から学び直す本連載。第4回では、HTTPのリクエストやレスポンスのヘッダについて、さらに詳しく解説していきます。実際の通信内容を見ながら、理解を深めましょう。 連載目次 新サンプルサイトを用意しました！ HTTPでのやりとりを見るサンプルとして、前回までは＠ITのWebサイトを取り上げてきましたが、より細かいやりとりを確認できるように、筆者が独自に新たなサンプルサイトを用意しました。今回からは、このサンプルサイトも使いながらHTTPの動作確認を進めましょう。 新しいサンプルサイトのサーバ名は「ait-sample.list.jp」です。また、GETする対象の位置は「/rtcp/p00/」などに変わります。Webサーバに対するリクエストの方式
「HTTP」の仕組みをおさらいしよう（その4）
連載目次 TCP/IPの仕組みについて、“目で見て触って”学ぶ本連載。第5回では、「認証」の仕組みを見ていきます。プロトコルビュワー（※）での実行結果とブラウザの動作を見比べながら、HTTPへの理解をさらに深めましょう。 ※「プロトコルビュワー」について 本連載では、筆者が作成した「プロトコルビュワー」というツールを使い、実際のリクエスト／レスポンスの内容を見ながら学習を進めていきます。プロトコルビュワーのインストール方法や使い方については、前回を参考にしてください（記事冒頭やや下「『プロトコルビュワー』差し替えのお願い」を参照） 認証とは？――実際のアクセスの流れ 認証とは、「Webへのアクセスに際してユーザー名とパスワードを求め、それらがあらかじめ登録してあるものと合致したときだけ、リクエストされた内容を送り返す仕組み」のことです。認証を利用することで、ユーザー名とパスワードを知ってい
リアルタイム通信で利用されるプロトコルと手法 - tech.guitarrapc.cóm
NOTE: 本記事はすでに内容が古く、今読んでも役に立つ度合いはほぼないです。 本記事は、先日社内勉強会のために準備した、Webサービスのリアルタイム通信周りのまとめシリーズ の1つを転載して公開するものです。 まだまだわかっていないことが多いので、ぜひぜひ間違っている点などにご指摘いただければと思い公開します。 ぜひぜひ優しくマサカリをいただけると泣いて喜びます！ 目次 目次 はじめに プロトコルと手法 前世代のやり方であるComet について Polling 系 Streaming 系 過渡期といわれてる手法 将来有望といわれてる手法 Polling メリット デメリット 向いているシーン Long Polling (Comet) Polling の発展版 メリット デメリット LongPolling 自体は双方向通信ではない 接続が閉じられるケース 向いているシーン Server S
あたらしいHTTPの話をしよう
あたらしいHTTP/1.1、RFC7230-7239のざっくりしたまとめ http://blog.hmm.jp/entry/new-http1.1-rfcs
たかが URI の設計、されど URI の設計 | システム設計日記
関心事オブジェクトの「現在の状態」を利用者に提供するパターンのひとつが、REST スタイルの GET 方式。 GET /リソースの識別名(URI) をサーバーにリクエストすると、「現在の状態 ( current state )」の表現 ( Representation ) がかえってくる、というやつですね。 ドメインモデリングのパターンとして、私は、「リソース」を「関心事オブジェクト」、「ＵＲＩ」を「識別キー」という言葉にしている。 実際に、HTTP を使うかどうかは別として、 ◎ リソース（＝関心事オブジェクト）の ◎ URI (＝識別キー) を指定して ◎ 現在の状態(current state)を入手する というのは、エンタープライズアプリケーションの基本価値のひとつですね。 「関心のあることを知る」という業務の基本ニーズ。 このニーズに応えるための GET 方式のモデリング・設計は
次世代プロトコルはどう作られる？HTTP/2.0相互接続試験参加レポート（標準化作業編）
次世代プロトコルはどう作られる？HTTP/2.0相互接続試験参加レポート（標準化作業編） 大津 繁樹（株式会社インターネットイニシアティブ） 先日私はドイツで行われた第1回目のHTTP/2.0接続試験に参加してきました。今回、この接続試験を通じて次世代プロトコルがどのように作られていくのか、HTTP/2.0の仕様策定作業の最前線の様子を少しご紹介したいと思います。 はじめに 先日公開された小松健作さんの記事「変わるWebプロトコルの常識（SPDY, HTTP2.0編）」で解説されている通り、Webを支えるプロトコルHTTPをバージョン1.1から2.0に大幅に改訂する作業が、現在急ピッチで進められています。10数年ぶりに改訂されるHTTPの仕様は、現状のインターネット環境に適応できるよう、これまで以上にWeb表示の高速化・効率化が実現できることを目的としています。 HTTP/2.0標準化作業
HTTPリクエストを減らすために【終章】我々には1000msの猶予しか残されていない
このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ＆ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 最終日は、我々フロントエンドデベロッパーに課せられた理想と現実のはざまについて冷静と情熱のあいだらへんで考えていく。まずは下記のブログを読んでもらいたい。 Google ウェブマスター向け公式ブログ: スマートフォンサイトの読み込み速度を改善するために まぁ読まなくてもいいのだが、ここで述べられている重要なことは2つ。 モバイルの平均読み込み時間は7秒 しかし、ユーザーは1秒未満を求めている 平均読み込み時間の7秒とい
HTTPリクエストを減らすために【DataURI編】遅延ロードでレンダリングブロックを回避 - MOL
このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ＆ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 4日目は、本ブログでも何回か話題にしているインライン画像についてです。 データURIスキーム CSS Sprite画像はDataURI画像にすべきか？ Data URI画像のテスト結果について 以前の記事で私は以下のように述べましたが、これはいやらしい表現だ。 DataURIの画像は、通常の画像に比べて6倍遅いとかゆう記事もある このような『xxx倍高速化』、『xxx倍遅い』と言った表現は、わかりやすい反面、本質を見失
HTTPリクエストを減らすために【WebFont編】ドラッグ＆ドロップしてコマンド叩いてウェーイ - MOL
このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ＆ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 3日目は、スマホ環境であればHTTPリクエストを減らすためにWebフォントの採用を考慮しても、やぶさかではないだろう。 まずは下記の画像をご覧頂きたい。 これはプロジェクトで私が使用していたスプライト画像だが（実際は縦にして使用）、このような単純な形状、単色のアイコンであれば、Webフォント化したほうがなにかと都合がよい。 このスプライトであれば、カラー × 矢印の向き × シャドウの有無 パターンの可能性があり、スプ
HTTPリクエストを減らすために【序章】HTTPリクエストは甘え - MOL
このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ＆ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 1日目は、HTTPリクエストの概要について説明する。 例えに、私のポートフォリオページ（t32k.me）が表示されるまでの流れを見ていく。まず、検索からでも方法はなんでもよいが、ブラウザのURLバーにt32k.meと打ち込んでアクセスする。そのページを見にいくということは、つまりt32k.meに対してHTTPスキームでリクエストするということを意味している。 クライアントであるブラウザは入力されたURLを判断して、リソ
HTTP/2.0 Initial Draft Released
The first implementable draft of HTTP/2.0 was released on July 8th by the HTTPbis working group of the IETF. The 2.0 version of HTTP is based on the SPDY protocol developed by Google — in fact, the initial draft was a copy of the SPDY specification as a base for diffs. HTTP/2.0 is intended as an alternative to HTTP/1.1, rather than deprecating the old version. There is good reason for this: The ne
Released Plack::Middleware::Deflater version 0.10 / Benchmark - blog.nomadscafe.jp
I released Plack::Middleware::Deflater version 0.10. cpan: https://metacpan.org/release/Plack-Middleware-Deflater github: https://github.com/miyagawa/Plack-Middleware-Deflater In version 0.10. I replaced IO::Compress::(Gzip|Deflate) with new encoder implementation PM::Deflater::Encoder. IO::Compress::(Gzip|Deflate)->new is bit slowly. PM::Deflater::Encoder use Compresss::Zlib directory. Throughput
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「http://」も暗号化通信する仕様へ？ HTTPの「高速化」や「日和見暗号」の標準化議論【IETFトピックス2016-17】
Sending a HTTP request using Qt 5 framework
Microsoft supported products on Q&A