タグ

networkに関するT-miuraのブックマーク (36)

  • Cookpad TechConf 2017 提供 Wi-Fi の裏側 - クックパッド開発者ブログ

    インフラ部 id:sora_h です。 先週開催された Cookpad TechConf 2017 如何でしたでしょうか。わたしは TechConf において Wi-Fi を担当していて、こちらも好評いただいたようでなによりでした。 というわけで、この記事では TechConf 2017 における Wi-Fi についての詳細を紹介します。 ネットワーク機器設定・サーバー mitamae レシピ等の公開 https://github.com/cookpad/techconf2017-network 今回の紹介する構成のうち、ネットワーク機器およびサーバ側の設定等、ほとんどを GitHub で公開しています。参考までにどうぞ。 TechConf 2017 NOC メンバー 実は外注などはしておらず、社内 IT と SRE グループのメンバーで構成されていました。 メイン (設計・運用・設営)

    Cookpad TechConf 2017 提供 Wi-Fi の裏側 - クックパッド開発者ブログ
  • https://jp.techcrunch.com/2016/07/13/soracom-launches-global-service/

    https://jp.techcrunch.com/2016/07/13/soracom-launches-global-service/
  • プログラマーが「ネットワーク怪しくない?」と思った時に覚えておくと便利なことまとめ - LIVESENSE ENGINEER BLOG

    インフラエンジニアの中西です。 最近プログラマーからこのような話を耳にします。 「ネットワークって難しい/よくわからない」 最近ではAWS,GCPをはじめとするクラウドサービスが充実しているのでWeb界隈のエンジニアはなおさら気にするシーンが少なくなったように思います。 今日は最低限これだけ覚えていたら有事の際にちょっとは役に立ちますよという話が出来たらなと思います。 書式統一のため sudo を省略しています。ご容赦下さい。 コマンド編 ping ping です。疎通確認を行う時のコマンドです。 さすがに分かると聞こえてきそうですね。 例えば、192.168.1.1 というサーバに通信を確認したい場合はこうです。 $ ping 192.168.1.1 繋がる場合はこうなります。 $ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 d

    プログラマーが「ネットワーク怪しくない?」と思った時に覚えておくと便利なことまとめ - LIVESENSE ENGINEER BLOG
  • オンラインゲームの仕組みと工夫

    オンラインゲームの仕組みや工夫を調べてみたのを社内勉強会で発表した。ときのスライド。の公開用。 オンラインゲームの種別とそれぞれの仕組みについての話と、オープンソースになっているQuakeの仕組みの話、という2つの話が主なトピック

    オンラインゲームの仕組みと工夫
  • 「iOS 8」を運んだAppleの独自CDN:Geekなぺーじ

    今年7月に入ってから、Appleが独自CDN(Content Distribution Network)の運用を開始しています(参考)。今回公開されたiOS8も、Apple独自CDNによる大規模配信が行われました。 これまでは、Appleは、他社が提供するCDNのサービスを購入することでOSアップデートなどの大規模配信を行っていましたが、その方針を大きく転換した形です。インターネットの「超巨人(Hyper Giants)」として語られることが多いGoogleAmazonなどと違って、巨人でありつつも自社で世界的な配信網をそこまで強烈な整備をするわけではなかったAppleがついに超巨人になる方向性を示したとも言えそうです。 現時点ではApple独自CDNだけで同社コンテンツを全て配信しているわけではなく、アカマイなどの商用CDNも併用しているようですが、今後は徐々にApple独自CDNのみ

    T-miura
    T-miura 2014/10/06
    appleの通信なんて、インタネットでは相当比重少なそうに思えて、手を出した意味がよくわらん。コストなのか、囲い込み的な話なのか。
  • Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー

    フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web

    Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
    T-miura
    T-miura 2014/09/02
    ドメイン分けるとか、CDNとかそっちの話にはあまりならないのだろうか?
  • BGPルータの512K問題について:Geekなぺーじ

    インターネットでの通信障害を発生させた「BGPルータの512K問題」が一部界隈で話題です。今回は、それがどういった問題で、それが発生する背景がどのようなものであるかを紹介します。 インターネットの仕組みとBGP インターネットは、AS(Autonomous System/自律システム)という単位で運営されていますが、AS同士はBGPという経路をやり取りするプロトコルを利用して互いに接続することで成り立っています。BGPは、伝言ゲームのように「私の隣に○○というASの××というネットワークがある」という情報を伝えて行くものです。世界中のASが伝言ゲームに参加することによって、世界中のASへの到達方法を共有しているのがインターネットなのです。 BGPによって集められた、世界中のASに含まれるネットワークへの経路を全て(もしくは全てと推測される規模の)経路情報は「フルルート(Full Route

    T-miura
    T-miura 2014/08/20
    CAM。マッチングネタ。ハードの力が重要になってくるレイヤーとソフトで頑張るレイヤーと、その辺の境目がよくわからない
  • BGPフルルートは必要か?GREEの事例:Geekなぺーじ

    「インターネットに接続された全てのネットワークへの経路」であるBGPのフルルート(Full Route)を「ネットワークエンジニアの夢」と表現するネットワークエンジニアもいます。INTEROP Tokyo 2014のShowNetでも、あえてフルルートを受け取らないAS運用がテーマのひとつでした。 さて、そんなフルルートですが、「それって当に必要なの?夢とかロマンとか感情的な話じゃなくて、現実問題として必要なの?」といった方向性の議論がコンテンツ事業者などの間で増えつつあります。 今回は、2年前にフルルート運用から脱却したグリー株式会社インフラストラクチャ部の黒河内倫氏に、何故フルルートの運用をやめたのかや、それによって何が変わったのかを伺いました。 フルルートを捨てる決断を促した障害 GREEがフルルートを捨てる決断をしたのは、2年前、2012年の夏に発生した障害が原因でした。当時G

    T-miura
    T-miura 2014/08/12
    BGPが運用としてわからぬ。ドキュメントレベルでは多少わかるが。
  • インタークラウド連携デモ [INTEROP Tokyo 2014]:Geekなぺーじ

    INTEROP Tokyo 2014のShowNetで行われていたインタークラウド連携デモは、複数のクラウドを利用してWebサイトのロードバランシングとDR(Disaster Recovery)用の冗長性確保を行うというものです。 VXLANを活用することで、個々のクラウド事業者の内部ネットワークに依存せずに相互接続が実現されていました。 GSLB このデモでは、幕張メッセ、さくらインターネット、IDCフロンティア、ビットアイルの4クラウド内部に、インターネットから閲覧可能なグローバルIPアドレスでWebサーバが運用されました。 ひとつのFQDNに対して、幕張メッセ、さくらインターネット、IDCフロンティア、ビットアイルの4箇所のIPアドレスが設定され、GSLB(Global Server Load Balancing)が行われていました。 インターネット側からの視点での全体像としては、こ

    T-miura
    T-miura 2014/06/26
    L2的に平らだとおもったら、DCマタギ・・。監視とか、運用とかどうするべきなんだろう?
  • OpenStack、9番目のリリース「Icehouse」公開。仮想マシンのローリングアップデート、DBaaS機能など新機能追加

    OpenStack、9番目のリリース「Icehouse」公開。仮想マシンのローリングアップデートDBaaS機能など新機能追加 オープンソースとして開発されているクラウド基盤ソフトウェア「OpenStack」の9番目のリリース「Icehouse」(コード名)が公開されました。 OpenStackは半年ごとに新バージョンをリリースする方針で、リリースごとにアルファベット順にコード名が付きます。半年前のリリースは「Havana」、1年前のリリースは「Grizzly」でした。そして次のリリースとなる今年の10月には「Juno」が予定されており、来月にはJunoの機能を決めるためのデザインサミットが行われます。 Icehouse最大の新機能は、このリリースからデータベースサービスを実現する「Trove」が正式コンポーネントとして追加されたことです。 TroveはOpenStack上でDatabas

    OpenStack、9番目のリリース「Icehouse」公開。仮想マシンのローリングアップデート、DBaaS機能など新機能追加
  • WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる

    OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO

    WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
  • ネットワークアドレス変換 - Wikipedia

    この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方) 出典検索?: "ネットワークアドレス変換" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2021年3月) プライベートネットワークとインターネットとの間のネットワークアドレス変換 ネットワークアドレス変換(ネットワークアドレスへんかん)、NAT(Network Address Translation)とは、インターネットプロトコルによって構築されたコンピュータネットワークにおいて、パケットヘッダに含まれるIPアドレスを、別のIPアドレスに変換する技術である。 業務用、家庭用を問わず、インターネットに接続するために使用されるルータや無線LANのアクセ

    ネットワークアドレス変換 - Wikipedia
  • 第2回 通信事業者に求められる高いパケット透過性

    キャリア・グレードNATは,収容するエンドユーザーの通信をできるだけ阻害しないようにする必要があります。つまり,NAT制御に高い“透過性”が求められます。ここでいう透過性とは,エンドユーザーが送受信するパケットを,通信事業者の装置でなるべく形を変えずに通過させることです。NATにはさまざまな手法が存在しますが,キャリア・グレードNATではそれらを通信の内容や通信する端末・アプリケーションによって使い分けていくことになるでしょう。今回は,キャリア・グレードNATで使われるNATの手法をいくつかご紹介します。 NATの手法は,「NATセッション・マッピング」と「フィルタリング制限」の二つの処理の内容の違いによって4種類に分けられます。この4種類とは,「フルコーンNAT」,「制限付きコーンNAT」,「ポート制限付きコーンNAT」,「シンメトリックNAT」です(表1)。NATセッション・マッピング

    第2回 通信事業者に求められる高いパケット透過性
  • OpenDaylight

    Web site created using create-react-app

  • DPDK環境の話

    DPDK実験環境を 組んでみた話 Dec 29, 2013 Masaru OKI (@masaru0714)

    DPDK環境の話
    T-miura
    T-miura 2014/01/24
    仮想ルータ周り。仮想ルータをintel使用時に効率化。
  • Ethernet OAM の 効果的な利用形態について

    Ethernet OAM の 効果的な 利用形態について 長谷川 幹人 JANOG27.5 Interim Meeting 2011/4/14 Copyright (C) SII Network Systems Inc., All Rights Reserved. Page 2 目次 はじめに Ethernet OAM って何? どんなケースで使えるの? まとめ Q&A Copyright (C) SII Network Systems Inc., All Rights Reserved. Page 3 はじめに 近年、Ethernet OAM (以降 EOAM) の標準化 が進んだことで、メーカー各社のルーター、スイッチ等 機器への実装が進んでいます 昨年のInterop Tokyo ShowNet では、計12社の 機器にてIEEE 802.1ag CFM を中心とした EOAM 相互

    T-miura
    T-miura 2014/01/23
    大規模ネットワーク監視。OAM
  • マルチキャストのアドレッシング

    マルチキャストアドレス 特定のグループを指定するアドレス ( マルチキャストアドレス ) とは、一体どのようなアドレスなのでしょうか。 マルチキャストアドレスは、クラスDアドレス ( 224.0.0.0 〜 239.255.255.255 ) を使用することになります。 このアドレスは、宛先アドレスとしてのみ使用され、送信元アドレスは常にユニキャストアドレスを使用します。 ※ ちなみにマルチキャストトラフィックはUDPを使用するので、マルチキャストの信頼性はアプリやQoSで管理する必要があります。 マルチキャストIPアドレスの構造 マルチキャストのIPアドレスは、32ビットのうち第一オクテットのトップビット 1110 を使用するのですが、 残りの28ビットはクラスA 〜 C のように階層構造となっておらず、残りはマルチキャストのグループIDを 識別するのに使用されます。例え

  • Windows Server 2008/2008 R2 関連ドキュメント | マイクロソフト 技術情報

    This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support. Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situ

    Windows Server 2008/2008 R2 関連ドキュメント | マイクロソフト 技術情報
  • 第3章 トラフィック管理技術とその比較

    ここまでは,LANアナライザによるパケット・キャプチャでトラフィック情報を収集する前提で話を進めてきました。しかし,ネットワークの世界には,このパケット・キャプチャ以外にもトラフィックに関するさまざまな情報を収集するための技術やプロトコルが存在します。例えば,SNMP RMON,sFlow,NetFlowなどが代表例です。格的にトラフィックを管理しようとすれば,情報を取捨選択するのに労力がかかるLANアナライザによるパケット・キャプチャよりもこれらの利用が便利です。それぞれの詳細は第2部以降で解説することにして,今回はざっくりとこれらの技術の概要を押さえておきましょう。 SNMP RMON SNMP RMON(Remote Monitoring)は,最も古くからあるトラフィック管理技術です。RMONによるトラフィック管理には,専用装置またはLANスイッチなどに内蔵された「RMONプローブ

    第3章 トラフィック管理技術とその比較
  • https://www.janog.gr.jp/meeting/janog23/doc/d2p5.pdf