【2018/11/16 追記】 本記事は、2016 年 4 月に Google Public DNS サーバに実装された、実験的な DNS over HTTPS プロトコルについて紹介しています。DNS over HTTPS プロトコルはその後 IETF の doh ワーキンググループにて標準化が進められ、2年半後の 2018 年 10 月に RFC8484 として出版されました。本記事で紹介したプロトコルは RFC8484 に規定されたプロトコルとはいくつもの点で異なっていることにご注意ください。 Google Inc. が公開 DNS サーバを運営していることはご存知でしょうか? Google Public DNS と呼ばれるこの公開 DNS サーバは、”8.8.8.8″ という特徴的な IP アドレスで全世界のインターネットユーザに対して無料の DNS サーバ(フルレゾルバ)を提供し
What is Open vSwitch? Open vSwitch is a production quality, multilayer virtual switch licensed under the open source Apache 2.0 license. It is designed to enable massive network automation through programmatic extension, while still supporting standard management interfaces and protocols (e.g. NetFlow, sFlow, IPFIX, RSPAN, CLI, LACP, 802.1ag). In addition, it is designed to support distribution
2008年7月に公開された、RFC5227 [IPv4 アドレス競合検出]の日本語訳です。同一ネットワーク上で、複数ホストに同一の IP アドレスがアサインされないようにするための技術、ならびに、万一アサインした場合にどうすればよいか、等を規定する標準です。 原文は、http://www.ietf.org/rfc/rfc5227.txt をご参照下さい。邦訳の誤りにお気づきの場合、ページ最下部のメールアドレスまでご連絡いただければ幸いです。 なお、可読性向上のため、ページのヘッダ・フッタを省略し、原文には無い改行を、適宜挿入しております。ご了承下さい。 Network Working Group S. Cheshire Request for Comments: 5227 Apple Inc. Updates: 826 July 2008 Category: Standards Track
ほぼデフォルト設定状態の RHEL6 系 OS で通信オフロード設定の有効/無効によって、通信の転送速度がどれほど差異があるか検証してみました。検証環境の概要は下記のとおりです。 さくらのクラウドで仮想サーバを2台用意して、サーバ間をスイッチで接続して速度測定。 測定対象サーバには Sientific Linux 6.5 をインストール。 対向サーバには Ubuntu 14.04.0 をインストール。 各サーバの NIC の理論回線速度は公称 1000Mbps。(最大実効速度は500Mbps 程度) サーバ間を結ぶスイッチの回線速度は無制限。(概ね NIC の実効速度に依存することになる) 速度測定には iperf を使用。 今回、変更対象となる通信オフロード設定は、仮想NIC (Network Interface Card) の TSO (TCP Segmentation Offload
ウオヘラ † TSO(TCP Segmentation Offload)、ネ、マ。「TCPトフソョ、ホコン、ヒ・サ・ー・皈ネハャウ茹ソ・ケ・ッ、ホス靉、PU、ォ、餒IC、ヒーワエノ、ケ、�オサスム、ホ、ウ、ネ、ヌ、「、�。」ヘマタナェ、ヒ、マTSO、ヒ、隍鶺CPトフソョ、ホス靉、PU、ネNIC、ヒハャサカ、オ、サ。「CPU、ホス靉、IC、ヒクェツ螟�、熙オ、サ、�、ウ、ネ、ヒ、隍�ノ筅、、ソCPU・�・ス。シ・ケ、ュク嵭靉ム、キ、隍ヲ、ネ、、、ヲケヘ、ィハ、ヌ、「、�。」 、キ、ォ、キ、ハ、ャ、鬘「エトカュ、ヒ、隍テ、ニ、マ、ウ、ホオ。ヌス、ヒ、隍�トフソョ、ホホス、茹、・ソ。シ・ユ・ァ・、・ケ、ヒイ睨魎ル、ャ、ォ、ォ、テ、ソコン、ヒトフソョ、ャナモタレ、�、�。「・ム・ア・テ・ネ・愠ケ、ャネッタク、ケ、�、ハ、ノ、ホノヤカ遉ャネッタク、ケ、�イトヌスタュ、ャ、「
参考資料 ・Predictable Network Interface Names 何の話かというと RHEL7では、NICのネーミングルールが変わっています。RHEL6では、DELL製のハードウェアの場合だけネーミングルールが変わるという謎のudevルール(biosdevname)がありましたが、RHEL7では、さらにまた仕組みが変わって、systemdがNICのネーミングを行うようになりました。 まとめると次のようになります。 バージョン ハードウェア ネーミングルール RHEL5 すべて 古典的な「eth0」「eth1」など RHEL6 一般のマシン 古典的な「eth0」「eth1」など RHEL6 DELL製のハードウェア biosdevnameによる「em1」「em2」「p1p1」など RHEL7 一般のマシン Predictable Network Interface Name
なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは
最近知ったんだけど、かなり便利くね?もしかして常識? http://ngrep.sourceforge.net/ http://www.atmarkit.co.jp/fsecurity/rensai/securitytips/027ngrep.html installにはlibpcapがいる。 http://downloads.sourceforge.net/libpcap/ もしくはepelリポジトリからyumでinstallする。 # yum install -y --enablerepo=epel ngrep 追記 今更知ったけど、ASCIIで表示するだけならtcpdump -s0 -A だけで良いので(ngrep -W byline とほぼ同じ?)、grep 的なことしないならtcpdump で十分な気がする。 man tcpdump -A Print each packet (m
id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない>DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン
大規模サイトではL4スイッチをDSR(Direct Server Return)構成で組むことはもはや常識です。しかし国内には大規模サイトが少ないためかDSR構成についての情報が不足しているのが現状です。L4スイッチを扱っているベンダーさんもDSR構成でネットワークを構築したという例をほとんど聞かないとのことです。そこで今回はDSR構成の紹介とメリット&デメリットをご紹介します。 【一般的な構成とDSR構成の違い】 一般的な構成ではスイッチとサーバの間にL4スイッチを挟み込む構成を取ります。それに対してDSR構成ではスイッチに直接L4スイッチを接続します。 これを踏まえてパケットの流れを見てみましょう。一般的な構成では行きのパケットがL4スイッチを流れサーバに到達し、帰りのパケットもL4スイッチを流れていきます。それに対してDSR構成では行きのパケットはL4スイッチを通りますが、帰りのパケ
Bandwidth Monitor NG is a small and simple console-based live network and disk io bandwidth monitor for Linux, BSD, Solaris, Mac OS X and others. It is licensed under GPL2. supports /proc/net/dev, netstat, getifaddr, sysctl, kstat, /proc/diskstats /proc/partitions, IOKit, devstat and libstatgrab unlimited number of interfaces/devices supported interfaces/devices are added or removed dynamically fr
Why ZeroMQ? ZeroMQ (also known as ØMQ, 0MQ, or zmq) looks like an embeddable networking library but acts like a concurrency framework. It gives you sockets that carry atomic messages across various transports like in-process, inter-process, TCP, and multicast. You can connect sockets N-to-N with patterns like fan-out, pub-sub, task distribution, and request-reply. It's fast enough to be the fabric
この項目では、Pythonによるフレームワークについて説明しています。アラジンのパロディであるミュージカルについては「Twisted(英語版)」をご覧ください。 Twisted は Python で記述されたイベント駆動型のネットワークプログラミングフレームワークで、MIT License でライセンスされている。 Twisted プロジェクトはTCP、UDP、SSL/TLS、IPマルチキャスト、UNIXドメインソケットをサポートし、また、多数のプロトコル (HTTP、NNTP、IMAP、SSH、IRC、FTP など) をサポートしている。 Twisted は論理的なプロトコル(通常 HTTP や POP3などのストリームベースのコネクションに依存している)と、そうしたストリームベースのセマンティクス[要曖昧さ回避]をサポートした物理的なトランスポート層(ファイル、ソケット、SSL ライブ
ソケットの概要 ソケットとはアプリケーションをインターネットに接続するための機構です。 インターネット通信をサポートするサーバーやクライアントには必ずソケットが必要になります。 以下では、ソケットの実際的な使い方を、 サーバーを作成する場合とクライアントを作成する場合とに分けて解説します。 なお、ここで説明する内容は、開発環境がWindowsであることを想定しています。 Unixでソケットを使いたい場合は別の文献を参照してください。 また、ソケットを使う際に注意するべきことがあるので、「注意!」にまとめました。 プログラミングの際には必ず一読してください。 サーバーの作成法(TCP) ここではTCP通信をベースとしたサーバーの構成法について解説します。 図1にサーバー作成での基本的な操作の流れを示しました。 この章では初期設定に必要なsocket, bind, li
ATI Stream テクノロジー/Nvidia CUDA/OpenCLを駆使し、WPA/WPA2-PSKを突破するために必要となる巨大なデータベースを事前に作成することによって極めて高速にパスワードを解析できるのがフリーのオープンソースソフト「Pyrit」です。厳密なライセンスはGNU GPL v3となっています。 pyrit - WPA/WPA2-PSK and a world of affordable many-core platforms - Google Project Hosting http://code.google.com/p/pyrit/ 事前に巨大なデータベースを作成しておくため、ハードディスクの容量は割と必要となりますが、それとトレードオフで解析速度を高速化しようというアプローチになっており、FreeBSD・MacOS X・Linux上で動作し、MinGWを使うこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く