タグ

networkに関するnobu666のブックマーク (45)

  • ソフトバンク回線のパケットロスがひどいというので、ほんとーーにそうなのか確かめてみた | [ bROOM.LOG ! ]

    比較のためWi-Fi(回線はフレッツ光)も付記している。 まず第一に流れている話通り、PM9時台では確かにロス率は70%から最大90%にも達している。まさしく通常はあり得ないレベルだと言ってもいいだろう。 しかしもう一点注目すべきなのは、ラウンドトリップに関しては、実はドコモのそれと遜色ない、若しくは場合により上回っている場合もあるということだ。 次にAM2時台となるとロス率は格段に改善されている。ほぼ問題無いレベルと言ってもいいだろう。しかしその反面ラウンドトリップは極端に落ち込み、特にmax値は10倍以上遅延しているケースもあった。また平均偏差も非常に大きくなっている点にも注目したい。これはネットワーク状態が安定していないことを示している。 果たしてこれらは何を意味しているのか。 ここから憶測にすぎないが、テストケース1において、恐らくソフトバンクのバックボーンネットワークの性能自体は

    ソフトバンク回線のパケットロスがひどいというので、ほんとーーにそうなのか確かめてみた | [ bROOM.LOG ! ]
  • 6月8日にフレッツ光接続だと遅くなる理由とその対策 - モーグルとカバとパウダーの日記

    (追記) 実際に6/8〜9を終えて、想定していたようなトラブル問い合わせは(少なくとも自分のところでは)ほぼありませんでした。 利用しているルータの設定条件がいろいろ揃わないと起きないのですが、ある程度対応が進んだということだと思います。あとやはり、大手のところはAAAAフィルタ利用していたところあったので、それで問題が起きなかったというのもあると思います。 でも、もっと多くの人に影響出るように思ってそう書いてしまっていたので、申し訳ありませんでした。 (/追記) ちょうど1週間後、2011年6月8日の9:00〜9日の9:00までの24時間、World IPv6 Dayという、インターネット関連の会社が多数参加するIPv6対応の実証実験が行われます。 これはGoogleYahoo!、Facebook等々の大手のWebサービス各社が、6月8日という時限的にIPv6での接続が出来るようにする

    6月8日にフレッツ光接続だと遅くなる理由とその対策 - モーグルとカバとパウダーの日記
  • さよなら、僕が知っていたイーサネット

    20年ほど前にイーサネットを学び始めた頃、イーサネットの2つの大きな特徴を教わりました。1つは、イーサネットでは複数のノードがケーブルを共有しているため、信号の衝突(コリジョン)が発生すること。もう1つはネットワーク構造には決してループとなる部分があってはならない、ということです。 しかしこの2つの特徴は、イーサネットの進化とともに消え去ろうとしています。イーサネットは僕の知っている昔の姿から大きく変わろうとしているのです。 コリジョンはなくなった イーサネットの大きな特徴の1つが、CSMA/CD(キャリアセンスマルチプルアクセス/コリジョンデテクト)です。ネットワークに複数の機器が接続されている場合、同時に通信を開始するとネットワーク上で信号が衝突するコリジョンが発生、コリジョンの発生が検出された場合には、それぞれの機器はランダムな時間だけ待って再送する、という仕組みです。 これによりイ

    さよなら、僕が知っていたイーサネット
  • メッシュネットワーク B.A.T.M.A.N. を試す - 言語ゲーム

    まず、BATMAN がどのような物かについて簡単にご説明します。BATMAN とは、パソコンに付いている無線 LAN インタフェースだけを使い、無線ルータ無しで大きなネットワークを作る仕組みです。無線 LAN インタフェースには、元々アドホックモードという、隣の端末と直接通信する仕組みがあるのですが、直接電波が届く狭い範囲でしか使う事が出来ません。BATMAN を使うと、直接電波が届かなくても、中間地点に端末があればバケツリレー式にデータを運び、遠い距離の端末同士が通信出来るようになります。これをメッシュネットワークと呼びます。 BATMAN は既存のネットワーク上に仮想的にネットワークを構築します。メッシュネットワークがどんなに複雑でもユーザーからは一つの LAN ネットワークのように見えます。BATMAN 自体はそれ以上の複雑なサービスを提供していませんが、既存の DHCPDNS

    メッシュネットワーク B.A.T.M.A.N. を試す - 言語ゲーム
  • TSOが原因でさくらVPSへのウェブアクセスが異常に遅くなるトラブルに遭遇 - 橙工房 Atelier Laranjeiras

    自宅のネット環境から都道府県別統計とランキングで見る県民性 [とどラン]を運営している、さくらVPSへのアクセスが異常に遅くなるトラブルに遭遇した。 現象としては ブラウザ経由のアクセス、ftpクライアント経由のアクセス速度が異常に遅くなる。(数バイト/秒程度) 小さいパケットだと問題ないので、pingやtracerouteでは異常が発見されない。 自宅ネット環境はDHCPでIPがふられているが、特定のIP,ゲートウェイのセットでのみ発生する。 職場の別回線ではそのようなトラブルは一切発生しない。 複数のWindowsXPで発生したが、Linuxデスクトップ(Debian)では発生しない。 この件について自宅のプロバイダともやりとりをしたが、原因が見つからなかった。そこでさくらインターネットに問い合わせたところ、すぐに対策法が送られてきて問題は解決した。 サーバー側でTSO(TCP Seg

    TSOが原因でさくらVPSへのウェブアクセスが異常に遅くなるトラブルに遭遇 - 橙工房 Atelier Laranjeiras
  • Dropboxを使うな、とまでは言いませんが

    あんまりにもひどいなぁ、と思うので、エントリーとして書いておく。 さくらのVPSでサーバ立てたのは、既に書いたとおりなのだけど、iptablesでパケットフィルタリングかけて、fwanalogでその状況をチェックしていると、大量のUDPパケットをブロックしているのがわかったので、ちょっと調べてみたらところ、 i wondering about the broadcast on port 17500 (udp) in our network. Why broadcasting on udp 17500? « Dropbox Forums どうやら、Dropboxが同一LAN内にいるDorpboxとのsyncをするために、ブロードキャストに向けてUDPパケットをバラ撒いて、その存在を見つけようとしているらしい・・・。 「適当なサーバにDorpbox入れておけば、外出先でも自宅でも会社でも、ネッ

    Dropboxを使うな、とまでは言いませんが
  • パケット解析で何がわかる?

    Copyright © 2004-2024 Impress Corporation. An Impress Group Company. All rights reserved.

    nobu666
    nobu666 2011/03/22
    [tcp/ip]
  • rcdn.info: 短縮URL + CDN = 効率的な情報共有

    この URL 短縮サービスを使うと,ブラウザからのリクエストが CDN (コンテンツ配信ネットワーク) へと転送されるようになるため,サーバへのアクセス集中を緩和できます. Twitter で情報が広まりすぎてサーバにアクセスできなくなった経験をお持ちの方は,ぜひ使ってみてください. (もっと詳しく) 便利な使い方 つぶやくたびにURLを短縮しにココに来るのは面倒なので,便利な使い方を紹介します (PCユーザのみ). 夜フクロウ をお使いの方 環境設定 - 詳細 URL簡略化サービス: カスタム APIのURL: http://rcdn.info/api/shorten?longUrl=%@&format=txt フォーマット: テキスト TweetDeck for Desktop をお使いの方 Preferences - Services Shorten URLs (上から2番目):Ot

  • サーバとL2スイッチの接続を冗長化する設計の基本 - GeekFactory

    インフラを設計する上で冗長化による信頼性向上は避けて通れない道です。サーバとL2スイッチの接続を冗長化する設計については意外と情報が少ないのでまとめてみました。変なこと書いてたらご指摘ください。 インフラ設計の基は単一障害点(SPOF)を取り除くことです。構成要素のうち1つが故障してもサービスを維持できるように設計します。構成要素は以下のものが挙げられます: CPU マザーボード メモリ ローカルディスク 電源 FC-HBA NIC LANケーブル L2スイッチ ・・・ ただし、これらすべての故障に備えようとすると費用対効果が割に合わないので、ローカルディスクから下を冗長化する構成が一般的と思います。絶対に止まってはいけないサービスは別ですけどね。 冗長化の種類 サーバを冗長化するにはクラスタを組みます。クラスタはActive-ActiveとActive-Standby(HA)の二種類に

    サーバとL2スイッチの接続を冗長化する設計の基本 - GeekFactory
  • ネットワークの遅延について真面目に書く - たごもりすメモ

    遅延(レイテンシ)とはなにか? - はてなポイント3万を使い切るまで死なない日記 この記事に果てしなくテキトーなことが書いてあってこれを真っ向から信じられると大変迷惑なので、こと細かに真面目に書くことにする。 ……つもりだったが、なんか果てしなくめんどくさくなったのでテキトーに書き散らすことにした。大学の教科書にそのへん詳しいのがいくらでもあったのに、見付からねーし。どこいったんだ。 信号の伝送速度について まず光速度 3.0*10^8 m/s というのは真空中の値*1であって、光ファイバや電線の信号伝送速度はもっと遅い。一般的には光ファイバが 2.0*10^8 m/s 程度とか言われていて、電線についてもモノによってあれこれある。詳しくは波長短縮率とかの単語でググれ。ざっくりとでも30万キロとか恥ずかしいことは言うな。 またどんな距離の都市間でも直接接続できるわけではない。500kmくら

    ネットワークの遅延について真面目に書く - たごもりすメモ
  • 2010年11月25日 6つのFreeBSD TCP輻輳制御アルゴリズムモジュール実装プロジェクト、始動 | gihyo.jp

    FreeBSD Daily Topics 2010年11月25日6つのFreeBSD TCP輻輳制御アルゴリズムモジュール実装プロジェクト、始動 2010Q3 FreeBSD Status Reportが公開されました。報告されている中から興味深い話題を紹介します。 Five New TCP Congestion Control Algorithms for FreeBSD FreeBSD Foundationが支援を開始した新しい取り組みとして、新しく5つのTCP輻輳制御アルゴリズムモジュールを実装する取り組みが紹介されています。既存のNewRenoをTCP輻輳制御アルゴリズムモジュールにするほか、新しくHTCP、CUBIC、Vegas、HD、CHDの5つのアルゴリズムをTCP輻輳制御アルゴリズムモジュールとして実装すると説明があり、最終的に6つのTCP輻輳制御アルゴリズムモジュールが登

    2010年11月25日 6つのFreeBSD TCP輻輳制御アルゴリズムモジュール実装プロジェクト、始動 | gihyo.jp
  • エフセキュアブログ : 「Firesheep」:複雑だったことを容易にするツール

    「Firesheep」:複雑だったことを容易にするツール 2010年10月25日23:12 ツイート mikko_hypponen ヘルシンキ発  by:ミッコ・ヒッポネン 暗号化されていないHTTP接続でWebをサーフィンすることは安全ではない。特にあなたが、暗号化されていないWi-Fi接続を介してサーフィンしている場合は。同じホットスポットを使用している他の誰でも、あなたのトラフィックをモニタするための特別なツールを使用することができるからだ。 暗号化されたHTTPS接続によりWebをサーフィンする方がはるかに良い。強力な暗号化(WPA2)を使用したホットスポットの利用も安全だ。しかし、これらのオプションは通常、エンドユーザが決められることではない。大部分のオープンなホットスポットは、まったく暗号化していないし、多くのポピュラーなサイトは、たとえあったとしても、ログイン手続きにHTTP

    エフセキュアブログ : 「Firesheep」:複雑だったことを容易にするツール
  • バックボーンの容量が頭打ち:Geekなぺーじ

    ビデオとインターネットに関する話題では、長距離通信での転送容量が頭打ちになっているのも、不安要因の一つだろうと思われます。 この先、ビデオトラフィックの増加はどこまでいくのか予想が付かない反面、コストに見合うレベルで回線速度を増強する勢いが停滞しそうであることが既に見えてしまっています。 現在、多くのインターネット通信事業者がバックボーンネットワークで利用しているのが10Gbpsの10ギガビットイーサネット(以降、10GbE)です。 10Gbps以上の容量が必要な場所では、10GbEを複数束ねるリンクアグリーゲーション機能を活用して、仮想的に40Gbpsの通信インターフェースとする運用は様々な場所で使われることもあります。 (余談ですが、10GbEは最近低価格化しているので、これからはISPやキャリアの中だけではなく、一般用途でも普及していきそうです。) 100ギガビットイーサネット 10

  • agilecatcloud.com

    This domain may be for sale!

    agilecatcloud.com
  • DNS Rebinding | 鳩丸ぐろっさり (用語集)

    用語「DNS Rebinding」についてDNS Rebinding (でぃーえぬえす りばいんでぃんぐ)話題 : セキュリティ DNS の情報を再読込させることで「同ドメインだが IP アドレスが違う」という状況を作り出し、same originポリシーを破ろうとする攻撃手法。攻撃者は有効なドメイン名をもち、その DNS サーバを管理している必要があります。 たとえば、攻撃者が bakera.jp ドメインを管理していて、218.219.246.132 という IP アドレスを持っていたとします。そして、以下のようにしておきます。 攻撃者は、自身の管理するDNSに、bakera.jp → 218.219.246.132 という情報を登録しておく。このとき、TTLの値を非常に短いものにしておき、情報がキャッシュされないようにしておく。攻撃者は、スクリプトを含む罠のWebページを http:

  • Cosmic っていうネットワークストレージを作り始めた - kazuhoのメモ置き場

    GitHub - kazuho/cosmic: fail-safe management tools for network-based software RAID, using mdadm + iSCSI 概要 (というか近場の目標) は、以下のとおり。 fail-safe な network RAID 多重マウントが発生しないプロトコルを実装 RAID だから DRBD や MySQL の async replication のような lost updates 問題がない software RAID + NBD を使用 (NBD は遅いから iSCSI 対応するかも) RDBMS レベルのレプリケーションや DRBD と異なり、高可用性のあるブロックデバイスを提供するソフトウェアレイヤとして機能 様々なストレージミドルウェアを統一的に管理可能なので、管理コストが低い バックアップとかも

    Cosmic っていうネットワークストレージを作り始めた - kazuhoのメモ置き場
  • 未割り振りのIPv4アドレスが残り10%を切って見えたこと

    最近、「まだ割り振られていないIPv4アドレスが残り10%を切った」というニュースに触れた方がいるかもしれない。これ実は、「IPv4アドレス枯渇」といわれる問題に関連した話題である。パソコンやルーターなどインターネットにつながる端末には、グローバルIPv4アドレスと呼ぶ一意のIPアドレスを割り当てる。この在庫の大元はIANA(Internet Assigned Numbers Authority)という組織にあるのだが、ここの在庫が10%未満になってしまったのだ(関連記事)。 IPv4アドレスの枯渇は、インターネット接続サービスを手掛けるプロバイダー(ISP)だけの問題ではない。インターネットでビジネスをするデータセンターやASP、あるいはネットビジネスを手掛ける企業も無関係ではない。「ビジネスを拡大してIPv4アドレスを追加でもらおうとしたが入手しづらい」「1個のIPv4アドレスを複数ユ

    未割り振りのIPv4アドレスが残り10%を切って見えたこと
  • ネットでよく見る伝言ゲームで根拠のない情報が本当のように語られる現象 - 空中の杜

    「安全ピンで耳にピアスの穴開けたら白い糸が出てきた。それを引いたら目が見えなくなった」という都市伝説を聞いたことのある人はかなり多いのではないでしょうか。私はこれを中学生時代に聞いたのですが、その時に語った人(たしか女の子)は「友達から聞いて、その友達が実際にそうなった」と言っていた気がします。しかしこれを聞いた時に「それが神経なら耳が千切れたら神経が切断されるから目が見えなくなるはずだよな。なら何で『耳なし芳一』とか他にも実際に耳が千切れた人は目が見えるの?」と思いついて言いましたが、「当にそうなんだから」と押し切られた記憶があります。まあ私の当時からの空気の読まなさはともかくとして、ここでは何故か「伝聞」が「真実」として語られていたわけです。 このテの「うわさ話がいつのまにか真実になっていた」ということは、都市伝説ではよくありますね。小学生の頃には「高橋名人がバネを使っていて警察に捕

    ネットでよく見る伝言ゲームで根拠のない情報が本当のように語られる現象 - 空中の杜
  • 公式ページ

    2018年11月15日 【12/7】「クラウド大航海時代のセキュリティ&リスクコントロール講座」を開催 2018年11月15日 【12/5】「あらためて学びたい“オンプレとクラウドの違い”まるわかり講座」を開催 2018年11月8日 【大阪】「今から始める!マルチクラウド移行の運用まるごと解消セミナー」を開催 2018年11月1日 サービス品質保証制度(SLA)の対象サービスを拡充しました 2018年10月24日 Ubuntu18.04を提供開始 2018年10月24日 Microsoft Windows Server 2016+RDS+Office Stdを提供開始 2018年10月4日 「vFORUM 2018」(2018年11月13日~14日)へ出展します。 2018年9月28日 脆弱性診断サービス Powered by イエラエセキュリティを提供開始 2018年9月27日 Micr

    公式ページ
  • iptablesのownerモジュールでクローラを安全に運用する話 - kazuhoのメモ置き場

    RSSリーダーとかブックマークサービスとかアクセス統計サービスとかを作っていると、クローラの運用は必須。クローラは保護したいから、当然DMZに設置する。でもクローラがDMZ内にある他のホストにアクセスできちゃうとまずいわけで。 で、クローラからのアクセス先を制限する方法として、自分はいままで、squid なのでプロキシを立てて、クローラは必ずプロキシを使うように設定し、かつ、プロキシの設定で DMZ 内へのアクセスを弾くようにしていた。でも DNS Pinning 系の攻撃とかも考えて設定するのは面倒なわけで。 もっと楽な方法がないのかなと irc で聞いたら、id:hirose31 さんが iptables の owner モジュールでできるよ、と教えてくれた。ありがとうございます。 たとえばクローラを uid:crawler で動かすなら、 # sbin/iptables -A OUT

    iptablesのownerモジュールでクローラを安全に運用する話 - kazuhoのメモ置き場