タグ

Networkに関するyyamanoのブックマーク (222)

  • IPv4 Multicast Address Space Registry

    Last Updated 2024-01-12 Expert(s) Stig Venaas Note Host Extensions for IP Multicasting [RFC1112] specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. The multicast addresses are in the range 224.0.0.0 through 239.255.255.255. Address assignments are listed below. The range of addresses between 224.0.0.0 and 224.0.0.255, inclusive, is res

  • 再送処理 - truncated binary exponential backoff

    それではイーサネットのCSMA/CD方式における送信処理の詳細について見てみよう。大まかに述べると、送信前にキャリアがないことを確認してから送信を開始し、衝突を検出した場合はランダムな時間だけ待ってから再送信を行うわけであるが、どのステーションにも平等に送信の機会を与え、再送信による衝突などが少なくなるように、さまざまな工夫が行われている。 送信処理 データをイーサネット フレームに加工し、アイドル状態がIFGの間続いたら送信を開始する(CSMA)。送信中もネットワーク媒体を監視し、衝突を検出したら送信を停止してJAM信号を送信する(CD)。JAM信号送信後はランダムな待ち時間待機し、再度送信処理を行う。同じフレームの送信に16回失敗した場合は、エラーとなりフレームを破棄する(バックオフ)。 1.フレーム・データの準備 上位層からのデータをイーサネット・フレームに加工する。フレームのデータ

    再送処理 - truncated binary exponential backoff
  • exponential backoffのメモ

    exponential backoffとは? データ送信処理が失敗して再送信するときに、失敗回数が増えるに連れて再送信するまでの待ち時間を指数関数的に増やす仕組みを exponential backoff という。 有名な例としては Carrier sense multiple access with collision detection (CSMA/CD) や Carrier sense multiple access with collision avoidance(CSMA/CA) といった通信方式で、失敗回数 N に対して、[0, 2^N-1] からランダムな数を選び、その slot time 分だけ待って再送信するようになっている。 ランダムに選んでいるのは、複数の通信が同じタイミングで失敗した時に、また同じタイミングで再送されないようにするため。 また、失敗回数が一定値を超え

    exponential backoffのメモ
  • [PDF]「さくらのクラウド」の舞台裏

    「さくらのクラウド」の舞台裏 さくらインターネット研究所 大久保 修一 ohkubo@sakura.ad.jp 2013/10/23 wakamonog4発表資料 自己紹介 • 1980年10月生まれ • 2003/4~ さくらインターネット入社 バックボーンネットワークの運用 • 2009/7~ さくらインターネット研究所に異動 • 2011/3~ クラウドの開発に携わる – 主にネットワーク、ストレージ担当 (ワカモノではありません Agenda • さくらのクラウドとは? • ストレージの話 • 第2ゾーンの話 • DoSアタック対策の話 さくらのクラウドとは? IaaSの基的なリソースを提供 ネットワーク サーバ ストレージ これらの組み合わせで Software-Defined Data Centerを実現! • 共有グローバルセグメント • 専用グローバルセグメント • スタ

  • SSLデータ転送とボトルネックについて

    カテゴリー DX (2) 一般 (59) 研究会 (6) 働き方 (4) 技術 (352) Edge AI (2) Edge Computing (13) Erlang (1) FIWARE (2) Fog Computing (10) Infiniband (31) Internet of Things (32) Key Value Store (17) Linux (3) Linux KVM (10) Machine Learning (5) RealTime Web (14) SRE (3) Webサービス (42) インフラ (8) コンテナ (4) ストレージ (93) データセンター (7) データベース (47) データ流通 (6) テレプレゼンス (2) ネットワーク (215) 仮想化 (111) 災害コミュニケーション (26) 空間情報 (30) 量子コンピューティン

    SSLデータ転送とボトルネックについて
  • 【JANOG32 Meeting】「10年後のインターネットを支える人にぜひ参加してほしい」JANOG川村氏 

  • ネットワーク仮想化の「オーバーレイ方式」はスケーラブルなのか?

    ネットワーク仮想化の方式の1つであるオーバーレイ方式は、ネットワークのエッジ部分、物理サーバ上のハイパーバイザでOpen vSwitchのような仮想スイッチを利用し、ハイパーバイザ間にトンネルを張ることで仮想的なネットワークを物理ネットワーク上に作り出す技術です。 しかしこのトンネル通信を用いたオーバーレイ方式は、大量の物理サーバが存在するデータセンターでも使えるほどスケーラブルなものなのか? という疑念が一部で持ち上がっています。 Are Overlay Networking Tunnels a Scalability Nightmare? « ipSpace.net by @ioshints その疑念に真っ向から反論するのが、米国でネットワーク構築のコンサルタントや教育を行っているIvan Pepelnjak氏。同氏のブログ「ipSpace.net」にポストされた「ARE OVERLA

    ネットワーク仮想化の「オーバーレイ方式」はスケーラブルなのか?
  • IABによる論評:DNSワイルドカードの使用に関するアーキテクチャ上の懸念について - JPNIC

    IAB Commentary 翻訳文 社団法人日ネットワークインフォメーションセンター 最終更新[2003年10月7日] この文書は2003年9月20日に公開された http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html を翻訳したものです。 JPNICはこの翻訳を参考のために提供しますが、その品質に責任を負いません。 2003年9月19日 IABによる論評: DNSワイルドカードの使用に関するアーキテクチャ上の懸念について DNSの動作に関するアーキテクチャ上の前提条件は、 DNSについて規定するIETF標準文書には明示されておらず、 しかしながら、 インターネットプロトコルやアプリケーションの動作に深く組み込まれているものが多数あります。 これらの前提条件は、 DNSを1つの構成要素とするネットワークアーキテクチ

  • Deprecated Linux networking commands and their replacements

    In my article detailing the command line utilities available for configuring and troubleshooting network properties on Windows and Linux, I mentioned some Linux tools that, while still included and functional in many Linux distributions, are actually considered deprecated and therefore should be phased out in favor of more modern replacements. Specifically, the deprecated Linux networking commands

    yyamano
    yyamano 2013/05/08
    ifconfigとか、netstat、arp、routeがなくなるのか。
  • IPアドレス編 第5回 NATとPATの基本動作を知る

    NATは現在不足しつつあるIPv4グローバルIPアドレス節約し,管理作業を容易にするための技術です。インターネットへの接続台数が大幅に増えた現在では,インターネット接続に必須の技術と言えます。今回はこのNATと,その拡張であるPATを学習しましょう。 IPアドレスの分類 IPアドレスはインターネット上でホストを識別するアドレスです。このため,重複は許されず,ユニークなアドレスが必要になります。ところが,その一方でインターネットの普及に伴い,ユニークなアドレスが不足しつつあります。そこで,RFC1918では「インターネットでルーティングされない」ローカル使用を前提にしたIPアドレス群を規定しています。 クラスA・・・ 10.0.0.0/8 クラスB・・・ 172.16.0.0/12 クラスC・・・ 192.168.0.0/16 上記のクラスAで1つ,クラスBで16,クラスCで256のネット

    IPアドレス編 第5回 NATとPATの基本動作を知る
  • ずんWiki - VRRPでルータの冗長化

    2012-03-21 bash 2012-02-23 TODO/3 2011-10-28 FrontPage 2011-06-30 plum3.x 2011-03-31 vim 2011-03-21 MyMenuBar MySQL GNU Screen VRRPとは? † VRRP とはルータを冗長化するためのプロトコルでその詳細は RFC2338 で定義されています。 複数台のルータで、仮想IP*1を使いまわすことによってルータのダウンタイムを限りなく小さくします。 通常はマスタールータが仮想IPを持っていて、そのルータがなんらかの理由で死んでしまった時には他のルータがそれを検知して仮想IPを自分に付けることにより 全体としては落ちることなく動作し続けるように見えるということを実現するためのプロトコルです。 障害時に利用する経路を切り替えるといったことは OSPF のようなルーティングプ

  • Virtual Router Redundancy Protocol - Wikipedia

    The Virtual Router Redundancy Protocol (VRRP) is a computer networking protocol that provides for automatic assignment of available Internet Protocol (IP) routers to participating hosts. This increases the availability and reliability of routing paths via automatic default gateway selections on an IP subnetwork. The protocol achieves this by the creation of virtual routers, which are an abstract r

  • .inドメイン名停止とwhois公開代行:Geekなぺーじ

    今日(4月30日頃)、一部の人々の間で「うちのWebサイトで使ってる.inの名前解決が出来なくなった!」という悲鳴が聞こえています。 数年前、インドのccTLD(country code Top Level Domain)である「.in」を日国内のWebサービスで使うのが流行しました。 「.in」は「イン」と読めるため語呂が良く、個人が気軽にWebサイトを作ったときに、ドメイン名も同時に登録するというのが流行ったわけですが、そのときにwhoisで世界に向けて連絡先(個人であれば氏名住所電話番号の場合もあり)を公開されるのは嫌だということで、whois情報公開代行サービス(もしくはプライバシー保護サービス)を使うというのが割と一般的に行われていました。 しかし、その.inのレジストリであるINRegistryが、whois情報公開代行サービスを利用しているドメイン名を次々と停止しているよう

  • 「すべてのインテリジェンスはエッジのx86コンピュータに移行する」。VMwareのマーチン・カサド氏が語る、ネットワークの技術トレンド

    Niciraはなぜオーバーレイ型を選択したのでしょうか。Niciraの創業者で、現VMwareネットワークチーフアーキテクトを務めるマーティン・カサド(Martin Casado)氏へのインタビューが、@ITの記事「カサド氏に聞く、VMware NSXはどこまでオープンか」として掲載されています。興味深い発言が続いていますので、@ITの許可を得て引用します。 カサド氏は、ホップ・バイ・ホップ形式で使われるような物理ネットワーク機器をOpenFlowで制御することには取り組まないのか? との質問に対し、物理的なネットワークは単に帯域幅を提供するパイプ役に徹する存在になってきており、「すべてのインテリジェンスはエッジのx86コンピュータに移行する。これがマクロトレンドだ」と言い切りました。 カサド氏の発言。 ネットワーキングに関するマクロなトレンドとして、クラウドやWeb 2.0の大規模デー<

    「すべてのインテリジェンスはエッジのx86コンピュータに移行する」。VMwareのマーチン・カサド氏が語る、ネットワークの技術トレンド
  • ポートスキャンツール「Nmap」を使ったセキュリティチェック | OSDN Magazine

    サーバーの基的なセキュリティ対策の1つとして重要なのが、ネットワーク内のどのマシンがどのポートでサービスを提供しているのかを把握することだ。このために有用なのが、ポートスキャナと呼ばれるツールだ。記事ではポートスキャナとして有名な「Nmap」というソフトウェアを使用し、ポートスキャンを行う方法について解説する。 定番のポートスキャナ「Nmap」とは 対象として指定したホストに対してポート番号を変えながらIPパケットを送信し、その反応を調べることでどのポートが外部からアクセス可能なのかを調査する行為をポートスキャンと呼ぶ。NmapNetwork Mapperの略)は、オープンソース(GPLv2ライセンス)で開発・提供されているポートスキャンツール(ポートスキャナ)だ。NmapではOSが提供するソケット機能を利用するだけでなく、ポートスキャンに使用するパケットを独自に生成することで、高速

    ポートスキャンツール「Nmap」を使ったセキュリティチェック | OSDN Magazine
  • LANケーブル配線.com| データセンターの安定稼動を実現する技術情報サイト

    データセンターやサーバールームの安定稼動を目指すIT管理者様必見!「LANケーブル配線技術ハンドブック」無料プレゼント!ケーブル配線.comはケーブリング・物理インフラの技術情報を提供します。

  • TCP Traceroute

    Did you know you could traceroute over the TCP protocol? The regular traceroute usually uses either ICMP or UDP protocols. Unfortunately, firewalls and routers often block the ICMP protocol completely or disallow the ICMP echo requests (ping requests), and/or block various UDP ports. However, you'd rarely have firewalls and routers drop TCP protocol on port 80 because it's the web port. Check this

    TCP Traceroute
    yyamano
    yyamano 2013/02/25
    traceroute -U とか -Tとか
  • Cloud Security Hinges on IP Addressing

    In the first part of this trilogy, I discussed the importance of automatically provisioned second generation DNS in connection with Software Defined Networking (SDN) and Software Defined Data Centre (SDDC). In the second post, I talked about IP addressing, private enterprise networks, and how DHCP does not meet the requirements of multitenant Infrastructure-as-a-Service (IaaS) cloud environments.

    Cloud Security Hinges on IP Addressing
    yyamano
    yyamano 2013/02/19
    The problem with most IaaS cloud offerings out there today is that their hybrid offering usually relies on public IP addresses. When an IP addressing model described above is merged with a dynamic DNS provisioning engine, the outcome becomes extremely powerful.
  • いま知っておくべきWebサービスのための高速ネットワーク技術(後編)

    いま知っておくべきWebサービスのための高速ネットワーク技術(後編):ボトルネックの解決が新たなボトルネックを顕在化(1/2 ページ) 前編に続き、10GbEやInfinibandといった高速ネットワーク技術のパフォーマンスを探るとともに、次世代Webサービス構築にどのように適用できるのかを考察していきます。

    いま知っておくべきWebサービスのための高速ネットワーク技術(後編)
  • いま知っておくべきWebサービスのための高速ネットワーク技術(前編)

    では、なぜいまWebサービスに高速ネットワーク技術が必要なのでしょうか? 高速ネットワーク技術とサーバ性能の現状を見ながら、その理由を解き明かしていきましょう。 拡大期を迎えるモバイルインターネット 米Morgan Stanleyは2009年に行った調査で、2014年ごろには、モバイル環境からのインターネットユーザー数がデスクトップ環境のそれを追い抜くだろうと予測していました(図3)。この調査から3年が経とうとしている現在、予想はまさに現実のものになろうとしています。モバイルインターネットの利用拡大は目覚ましく、家庭にも個人にも深く浸透してきています。 さて、モバイル環境向けに提供するWebサービスでは、ワイヤレスデータ通信網を考慮して、コンテンツ自体を小さく作るよう心掛けるはずです。これにより、小さなパケットを大量に送受信できるWebサーバの重要性が必然的に増しており、「ネットワーク帯域

    いま知っておくべきWebサービスのための高速ネットワーク技術(前編)