WebRTCにおけるNAT越えの課題へのアプローチ - Qiita
WebRTCは、音声映像メディアやデータをP2Pで通信する能力をブラウザに提供します。しかし、既存のインターネットの世界ではNATが広く用いられており、容易にP2Pを利用することはできません。この記事では、NATに対してどのような課題がWebRTCに存在し、どのようなアプローチで解決を試みているかについて解説します。 インターネットの世界におけるNATの存在 今日のインターネットにおいて、エンドユーザが用いるホストのほとんどは何らかのNATデバイスの配下に設置されています。これはWebに携わるエンジニアの間では広く知られている事実でしょう。全世界に広がった広大なインターネットの世界に対応するためにIPv6が新たなインターネットプロトコルとして発案されてかなりの時刻が経過しました。にもかかわらず、古いインターネットプロトコルであるIPv4が一般的に用いられており、しかもそのアドレスは既にとっ
tjun月１日記
コロナウイルスが流行する前の2020年1月上旬、中国の杭州に行ってきたのでその記録を書いておく。 はじめに 自分はこれが中国へ行くの5回目。それなりに慣れている方だと思うけど、中国人と一緒に行ったほうが圧倒的に楽です。 数年前にキャッシュレスが普及して、その後も規制が変わったりして行くたびに状況が変わっています。なので、ここで書いてあることは半年後には参考にならないかも。 事前にやっておくこと WeChatPayのアカウントを作る、可能なら本人確認とチャージをやっておく Alipayのアカウントを作って、可能なら本人確認とチャージをやっておく 中国で使える香港SIMを買う WeChatPayとAlipayのアカウントは、外国人でも作れるときと作れないときがある。またお金もチャージできるときとできないときがある。 事前にググってできるかどうか試しておくのが重要。 また、中国はいわゆるGrea
WebRTCにおけるNAT越えの課題へのアプローチ - 鈴木うどんの横須賀おもしろ生活
WebRTCにおけるNAT越えの課題へのアプローチ - Qiita に移転しました。
NATやファイアウォールの向こうへデータをお届けする fluent-plugin-pull_forward を書いた - たごもりすメモ
Fluentdにおけるネットワークごしデータ転送プラグインといえば forward が組み込みであるし、通信路を暗号化したければ secure-forward がある。 しかしこれらFluentdのネットワーク転送プラグインは基本的に全て送信元から送信先に対してプッシュする形になっており、ネットワーク接続も送信元から送信先に対して行うことになっている。このため送信先のFluentdがNAT下にある場合やファイアウォールで保護された場所にある場合、もしくはダイヤルアップ接続……は、まあ今は無いだろうけど、例えば移動するデバイス上にある場合など、こういったときにはうまくデータの転送を行う構成がとれない。 なぜこういう状況、つまりプッシュ型で転送を行うプラグインばかりなのかというと、FluentdのBuffer pluginの仕組みによる。細かく設計上の話をあれこれしてもアレだし面倒くさいので省
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
