会社でフルリモート体制が築かれるにつれ、各スタッフの自宅の回線などについての相談を受けることが増えてきました。ということで、筆者 sorah の見解として 2020 年の NTT フレッツ光網について、主に通信速度や輻輳についての問題を理解するための背景と仕組みを説明しようと思います。 理解が間違っていたら教えてください。なるべく総務省や NTT の資料からソースを集めてきた上で説明していますが、出典不明の情報も混ざっているかもしれません。できるだけ具体的な出典を文単位で示していますが、複数の資料に渡る複雑なトピックに関しては文末に纏める形になっています。 技術的な意味での細かい解説よりも複雑な事情や背景の説明が中心です。フレッツ光とか NGN とか IPoE とか IPv6 とか v6 プラス・アルファみたいな言葉を聞いて、なんでそんな難しいんだと思った人も多いんじゃないでしょうか。エン
まずは何が起きたか復習しよう いまや、私たちにとってインターネットサービスは「インフラ」と化している。ビジネスで利用する多種多様なデータ通信からリアルタイムメッセージによるコミュニケーション、ビデオ会議、そして個人で利用する動画、音楽をカバーするストリーミングコンテンツにオンラインショッピング、ソーシャルゲームまで、あらゆるものでネットを使っている。 人はいつでもどこでもインターネットに接続できる環境を熱望し、今では飛行機や外洋を航行する船、人工衛星からもインターネットに接続できるようになった。逆にいえば、現代人はもはや、どこまでも追いかけてくるメールやメッセージ、SNSの呪縛から逃れられなくなっている。 と、思っていたら。 昨日まで当たり前のように使っていたインターネットが、長期間使えなくなった地域があった。平成から令和に切り替わるころ、日本の東京都で。 場所は伊豆諸島の新島、式根島、神
本連載の背景と目的 近年、LTEなどの高速なネットワークの展開とスマートフォンや様々なクラウドサービスの普及により、インターネットを流れるデータ量は急激に増大しています。今後も、新たなスマートデバイスやIoTサービスの普及、5Gサービスの商用展開などに従い、私たちの生活においてインターネットへの接続は不可欠なものとなっていくと考えられます。そのインターネットにおいて広く利用されているプロトコルがTCP/IPです。TCP/IPは1980年頃にその基本形が完成して以来、インターネットの普及とともに広まり、発展を続けてきました。 本連載では、TCP/IPの中でも初学者にとって難しいプロトコルであるTCPに着目します。TCPは通信の信頼性を担保するための様々な機能を備えています。特に、ネットワークの状況に応じて効率的にデータを転送するための輻輳制御アルゴリズムは、今日にいたるまで様々な手法が提案、
翻訳ステータス: このページは en:ArchWiki:Archive の翻訳バージョンです。最後の翻訳日は 2020-07-12 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。 このページはアーカイブされたページのリダイレクト先です。 記事を見ようとしてこのページに飛ばされた場合、そのページはアーカイブされています: このページのタイトルの下にある「〜から転送」のリンクを辿ってから、転送ページの履歴を開くことで改訂を閲覧できます。 アーカイブページのリストはカテゴリ:アーカイブや特別:リンク元/ArchWiki:アーカイブを見てください。 アーカイブされたページについて、既存の記事にリダイレクトするほうが好ましいと思ったときは、そうしてください。 ページをアーカイブする方法 ページをアーカイブする前に、既存の記事へリダイレクトすることができないか確かめてください。
はじめに Linux Advent Calendar 10 日目の記事です。 運用や研究開発の現場では、ソフトウェアの実験、または機器のテストや選定などのために、ベンチマークツールや自前のアプリケーションでコンピュータ間の通信速度を計測する機会が多々あると思います。一方で10Gbpsや40Gbpsといった昨今の高速ネットワークにおいては、これらの計測結果はアプリケーションの通信API部分の実装、カーネルパラメータまたはコンパイルオプションによって大きく変わってしまうため、正確な計測を行うためにはこれらを正しく設定/理解する必要があります。この記事では、ネットワーク周りのカーネルとアプリケーションの動作の概要と、その中の重要なポイントを理解することを目的にします。 ネットワークプログラミングのおさらい まず最初に、TCPを使う今時のサーバプログラムがどのようにできているか簡単におさらいします
こんにちわ。 寒気きびしき折柄、皆様いかがお過ごしですか。 ブログ書くのも1年ぶりなんですが、開発合宿でHaconiwa + flannelを試してみたので、メモのように書き残しておこうと思います。 今回使ったHaconiwaですが、udzuraさんというスーパーエンジニアの方が作ったmruby製コンテナエンジンで、ロリポップマネージドクラウドというサーバーサービスでも利用されています。 flannelは、LinuxのVXLAN機能を用いてオーバーレイネットワークを実現するツールで、Kubernetesと組み合わせて利用されています。 今回この2つを組み合わせて実現するのはこのようなネットワークです。 検証環境 ゲストOS: Ubuntu 16.04.5 LTSVirtualBox 5.1.18Vagrant 2.1.5 まずは、vagrantを使って検証するためのVMを作成していきます。
iptablesの課題を解消し、高速で安全な通信を実現するCiliumとはなにか？ KubeConでのプレゼンテーションをベースに解説する。 コンテナを用いたクラウドネイティブなシステムに移行しようとすると、従来の仮想マシンベースのシステムよりも粒度の細かいコンテナワークロードをオーケストレーションする必要がある。昨今Kubernetesが注目されているのは、そのためだ。その際にコンテナ間のネットワークをどのように構成するのか？ は、インフラストラクチャーエンジニア、ネットワークエンジニア双方にとって頭が痛い問題である。特に多くのコンテナが連携するシステムであれば、コンテナ間のトラフィックを遅延なく通信させることが重要になる。 またIstioのように、サービスメッシュとしてPodの中にProxyをサイドカーモードで構成する場合、コンテナとProxyの間にも通信が発生し、ますますオーバーヘッ
やっと形になってきました。 github.com 「データベースのクエリログを取得したい」 例えば、データベース（RDBMS）のクエリログを取得したいとき一番確実な方法は、そのRDBMSに備わっているログ機構を利用することです。 一方で、全てのクエリログを出力するとなるとそれなりにIO負荷がかかることが予想されるので、負荷状況によってはクエリログ出力（のIO負荷）を別サーバに分離したくなります。 では、どうすればよいかというと、例えば アプリケーションサーバとデータベースサーバの間にプロキシサーバを挟んでそこで記録することでIO負荷を分離する アプリケーションサーバ側で（notアプリケーションで）記録することで（大抵、サーバ台数の多い）アプリケーション側にIO負荷を分散する というような方法を思いつきます。 そこで、「もし、TCPコネクション上に流れている（例えば）クエリログを解析してログ
Table of Contents1. 献辞2. はじめに2.1. 免責およびライセンス2.2. 事前に必要な知識2.3. Linux にできること2.4. この文書の管理についてのメモ2.5. 取得、CVS およびアップデートの投稿2.6. メーリングリスト2.7. この文書の構成3. iproute2 入門3.1. なぜ iproute2 なのか?3.2. iproute2 の概略3.3. 事前の必要条件3.4. 現在の設定を調べてみる3.5. ARP4. Rules - ルーティングポリシーデータベース4.1. 簡単なソースポリシールーティング4.2. 複数のアップリンク/プロバイダに対するルーティング5. GRE トンネル、その他のトンネル5.1. トンネルに関する一般的な事柄5.2. IP in IP トンネリング5.3. GRE トンネリング5.4. ユーザランドのトンネル6.
はじめまして、hatです。 EC2上にてCentOSのマシンを稼動させ、複数のIPを持たせる必要があり作業をしたときのことです。 NWに詳しい方は想定できるかもしれませんが、備忘録をかねて作業内容を書いていきたいと思います。 環境情報 ・EC2インスタンス (CentOS5.4を利用) ・ENIを2つ追加し、複数のIPアドレスを追加 ・IFのセグメントはすべて同一(eth0,eth1,eth2) eth0:10.6.3.92 eth1:10.6.3.96 eth2:10.6.3.100 最初にAWSコンソールにてログインし、EC2インスタンスのネットワークインターフェースの追加し、 それぞれのインターフェースにEIPを割り当てました。それではsshにてアクセスしてみます。 結果は下記のようになりました。 eth0 → sshアクセス可能 eth1 → 応答なし eth2 → 応答なし あ
例えば VPC 設計をするときなど，IP アドレスとサブネットの計算をしたり，ネットワークアドレスを確認したくなる場面がたまーにある．便利なサイトも多くあるけど，コマンドですぐ確認できると便利で，僕は sipcalc コマンドを使っている（ipcalc コマンドよりも便利）．近々チームメンバーに「VPC 入門」を教える機会があるため，ネタの1個としてザッとまとめておく． ipcalc コマンド ipcalc は IP アドレスの計算を行うことができるコマンドで，Amazon Linux など RHEL 系ならすぐに使える． $ which ipcalc /bin/ipcalc 例えば，CIDR からネットワークアドレスを確認する場合，以下のように --network もしくは -n を使う． $ ipcalc --network 172.31.10.20/24 NETWORK=172.31
富士通総研がこのほどWebサイトで公開した、「インターネットは社会を分断するのか？」と題したレポートが話題になっている。ネット上では左右に過激な意見が目立ちやすく、それによって社会が分断される「分極化」が起きていることが米国ではデータによって裏付けられているが、日本で調査したところ、意見の過激度に最も影響を与えているのは年齢であり、TwitterやFacebookの利用が政治的な意見を過激化させているという証左は得られなかったという。 レポートは、慶応義塾大学経済学部の田中辰雄教授と、富士通総研経済研究所研究主幹の浜屋敏氏によるもの。 ネットが社会を分断しているか調べるためにまず、2017年8月、ネットユーザーにアンケート調査を実施した。「憲法9条を改正する」「社会保障支出をもっと増やすべきだ」「原発は直ちに廃止する」など政治的な争点を10個用意し、賛否を「強く賛成」から「強く反対」まで7
最近 ParallelServer というライブラリを作ったのですが、その最中に奇妙な状態になってる TCP ポートを見つけたので、メモっておきます。 Ruby では TCP サーバーは次のような感じで作ることができます。お手軽ですね。 require 'socket' Socket.tcp_server_loop(12345) do |socket, client_addr| socket.puts "Your IP address: #{client_addr.ip_address}" name = socket.gets socket.puts "Hello, #{name}" socket.close end これは 12345 ポートでクライアントからの接続を待ち、接続されたらクライアントのIPアドレスとクライアントからの入力をクライアントに送信して切断するだけの簡単なプログラム
ネットワークスタックの高速化手法についてまとめました。 これらの手法が提案された背景には、10Gb NIC 等の高性能なハードウェアの値段が下がり、汎用化が進んだ一方で、汎用 OS のネットワークスタック実装では、それらの性能を十分引き出せないという問題があります。 特に、小さいパケットをやりとりするワークロードや、短い TCP コネクションをたくさん処理するようなワークロードで、10Gb, 40Gb のラインレートを達成するのが難しく、様々な解決策が提案されています。 システムコールバッチング システムコールは、ユーザー空間とカーネル空間のコンテキスト切り替えのための処理を必要とし、Web サーバーやキャッシュサーバー等の高速なメッセージの送受信が必要なシステムにおいて、性能劣化の原因となることが問題として指摘されています。 以下の論文では、システムコールバッチングをこの問題の解決策とし
OpenStack仮想ネットワークの基本動作を体験してみたいと思います。 ■ やってみたこと OpenStaxk仮想ネットワークで、試してみたことは、 サーバ機器２台を、HUB接続する サーバ機器に、IPアドレスを付与する サーバ機器の間で、ping通信してみる という、非常にシンプルな内容です。 ■ OpenStack実験環境 "Nested KVM環境でのNewton版OpenStack構築メモ"で作成したOpenStack環境を使用します。 nova仮想マシン一覧 [root@newton ~(keystone_demo)]# nova list +--------------------------------------+---------+--------+------------+-------------+----------------------------------
先日netdev 1.2に参加してみたところ，XDP(eXpress Data Path)の話題で持ち切りといった感じだった． というわけで，XDPについて一通り調べつつ，実際に触ってみた． XDPとは何か？ 誤解を恐れずに一言で言うと，「Intel DPDKのような高速パケット処理基盤をLinuxカーネル自身が用意したもの」であると理解している．このスライドでは A programmable, high performance, specialized application, packet processor in the Linux networking data path と言っている． DPDKはユーザランドアプリケーションがNICを直接叩く(=カーネルのネットワークスタックをバイパスする)ことで高速処理を実現している．一方XDPは，カーネル内の最もNICドライバに近い場所でフッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
