検索条件
全24件
(2/3ページ)
2018/06/02(土)IPv６の基礎(5) - 機器設定時に必要と思われる知識
2018/06/06 17:10
今回はもうちょっと細かい部分を示します。理解しておかないと、この先益々チンプンカンプンになる可能性がありますので、是非一度眺めてください。
・ユニキャストアドレス
一言で「ユニキャストアドレス」と言っても主なものだけでもこれだけの種類があります。
このうち、3) と 4) は、2018年６月現在では既に廃止されているため、古い機器の設定や古い文献を参照する場合は注意です。
廃止時点で既にこの世に出回っている機器で廃止された機能を使うことは妨げないことになっていますが、結局、近い将来に新しい機器との相性問題になるため、廃止された機能等は使わないようにするべきです。
このうち、ユニークローカルユニキャストアドレスは、IPv4における「プライベートＩＰアドレス」と同じように使用できるアドレス領域として規定されています。
以前は、似たような目的で「サイトローカルユニキャストアドレス」というのが規定されていたのですが、これは「ユニークローカルユニキャストアドレス」に置き換えることとなっています。
・エニーキャストアドレス
エニーキャストアドレスは専用のアドレス領域が割り当てられておらず、プレフィックス以外の部分のアドレス表現で、ユニキャストアドレスと区別されるようになっています。
例示は、よく使われるプレフィックス長 /64 の場合ですが、インタフェースＩＤの部分（IPv6 アドレスの後ろ半分）が fdff:ffff:ffff:ff80 ～ fdff:ffff:ffff:ffff のアドレスと、0000:0000:0000:0000 はエニーキャストアドレスとして解釈されるので、ユニキャストアドレスとして使用することができません。こういった部分に注意する必要があります。
・マルチキャストアドレス
IPv6においては、先頭が ff～ で始まるＩＰアドレスは、マルチキャストアドレスと規定されており、仕様で定められているマルチキャストアドレス以外は、ユーザが自由に割り当てることもできます。
IPv6は、IPv4にあった「ブロードキャスト」が仕様として存在しないため、代わりに「マルチキャストアドレス」を使うように置き換えされています。
例示は、必要不可欠で必須的に使われている２つのマルチキャストアドレスを示しています。
2018/06/01(金)IPv６の基礎(4) - 機器設定時に必要と思われる知識
2018/06/06 16:18
今回は、今後の説明の理解に必要な基礎的内容になります。
実は、これらは IPv4 にも存在する概念ではありますが、IPv4 には明確に示している既存資料があまり見当たりません。
そう大きな相違は無いのですが、明示してみることにします。
・ユニキャストアドレス
ネットワーク通信の大半がこの形態です。「ユニキャスト」とは「単一の相手」という意味で、一対一で対向通信を行う目的で、通信端点（通信装置）毎に異なるアドレスを付与します。
「ＩＰアドレス」と単に示す場合、殆どの場合この「ユニキャストアドレス」を指します。
・エニーキャストアドレス
あまり見慣れないと思いますが、IPv4 では、192.88.99.0/24 が 6to4 と言われるIPv6ネットワークとの相互接続において主に利用されています。
技術的には IPv4 でも IPv6 でもエニーキャスト自体は可能です。(「IPv4 ではエニーキャストはできない」と書いている諸氏が散見されるが、それは間違い）
エニーキャストとは、複数のサーバに同じIPアドレスを予め付与しておき、そのアドレスに向けて発信した際に、最も早く応答した相手（通常は対応可能で最も近い相手）と一対一で対向通信を行います。
・マルチキャストアドレス
「複数相手への同報通信」がマルチキャストです。
エニーキャストアドレスとマルチキャストアドレスが発信元ＩＰアドレスには絶対になりません。返信が必要な場合、各ホストやルータに割り当てられている本来のユニキャストアドレスを発信元として返信を行います。
IPv4では後から追加された仕様ということで、あまり普及していませんが、
IPv6では「ブロードキャスト」の概念に代わり、「マルチキャスト」に置き換わっています。
2018/05/15(火)FreeBSD で大量のファイルを一度に消去する
2018/05/15 24:25
今般、サーバのＨＤＤ使用残量が変に圧迫していて、不要なファイルを削除する、というメンテナンスを行う必要性が出たのですが、削除対象ファイルがざっと 200万 ～ 300万個あり(計算上)、普通に削除しようとすると、下記のようになります：
これは、コマンドラインで '*.jpg' のようにワイルドカード指定すると、処理を始める前段階で、全ての対象ファイル名をリストにするからで、そのリストサイズは現行 FreeBSD の場合、262144 バイトに制限されており、数が多いと収まりきらないためです。そのため「引数のリストが長すぎる」というエラーになるのです。
このような時は、標準入出力をパイプで連結する、という手法をとります。
xargs コマンドが肝になる部分で、このコマンドは、標準入力に与えられた長いリストをエラーにならない範囲で分割し、所定のコマンドを実行するものです。
これで、削除には15時間ほどかかりましたが、無事に削除完了できました。
2018/04/13(金)〔テスト〕adiary アップデート 3.13a → 3.14a
2018/04/13 1:21
今まで標準モードで投稿が出来なかったのは、動作環境のせいだとおもって諦めていたが・・・
どうも Perl 5.26 では上手く動作しないというバグだったらしい。
半年前に adiary を 2.xx から 3.13a にアップデートした時にどうしても上手く出来ずに、試行錯誤の途上でデータの一部を誤って壊してしまい....
だったのですが、既に Perl を 5.26 にしていたことと、 「Perl 5.26 では不具合がある」という情報が一切無かったので、「adiary自体を疑う」という発想には及ばなかった自分でした。
まぁ「動作環境のせい」ではありますね。
コメントスパムが酷いものの、制作元で対策が一向にされないもうひとつのブログシステムを adiary にしようかどうか迷っていたところですが、これで踏ん切りつきそうです。
2018/04/10(火)IPv６の基礎(3) - 機器設定時に必要と思われる知識
2018/04/10 14:04
IPv6 アドレスは記述自体が長くなるため、一定の省略記述ルールが決められています。
しかしながら、必ずしも省略記述をする必要はありません。
むしろ、慣れないうちは敢えて省略記述をしない方がよいのです。
ですが、実際には先駆者によって多用されているので、ここでは省略記述ルールを紹介します。
「省略記述」は全て、数字の'0' (ゼロ) を省略するルールが定義されています。
先ず、「各フィールドの上位桁の'0'は省略可能」です。ただし、'0000' だけは全てを省略せずに'0'を記述します。
次に、「'0000' のフィールドが連続する場合は、該当部分を '::'(ダブルコロン)で省略可能」です。
但し、これが使えるのは１回だけです。
また、'::'(ダブルコロン)は、最も長く省略できる部分に適用すべき、と規定されました。
なので、厳密には上記例の３番目も×です。
２番目の 2001:db8:0:3::1 のみが正解となります。
更に、IPv6 表記でしか設定できない環境下で、IPv4を表記する場合の記述法も定義されています。
現在は、「IPv4 射影アドレス」の記法が
ただし、「IPv4 組み込みアドレス」もたまにみかけるので、知っておくとよいです。
2018/03/28(水)IPv6 の基礎(2) - ネットワーク機器類の取扱説明書を見る時、得意になれそうな知識
2018/03/28 2:52
今さら誰にも聞けないレベルになりつつある内容ですが、この「備忘録」が役立てば幸いということで。。
今後、従来からのＩＰプロトコルは、IPv6 と区別するために IPv4 と称することにします。
世の中での表記区別がそうなっているため、それらに倣うことにしました。
今回はIPv6 アドレスの形式です。
IPv4 では当初、クラスＡ，クラスＢ、クラスＣ、クラスＤ、クラスＥ というカテゴリ分けで、ＩＰアドレスブロックの割り当てがされ、サブネットマスクは固定でした。
以下のような感じです：
クラスＡ 1 ～ 126 で始まるＩＰアドレス (サブネットマスク 255.0.0.0)
クラスＢ 128 ～ 191 で始まるＩＰアドレス (サブネットマスク 255.255.0.0)
クラスＣ 192 ～ 223 で始まるＩＰアドレス (サブネットマスク 255.255.255.0)
クラスＤ 224 ～ 239 で始まるＩＰアドレス (サブネットマスク 255.255.255.255)
クラスＥ 240 ～ 254 で始まるＩＰアドレス
このうち、クラスＤはマルチキャスト通信専用で使われており、クラスＥは各種実験・特殊用途向けで一般利用はできないことになっています。
０と255で始まるIPv4 アドレスは仕様的に使用不可、127で始まるIPv4アドレスは、ループバック専用で、これは用途が仕様として強制されています。
クラスＤにサブネットマスクの概念そのものがなく、クラスＥには、サブネットマスクの規定はありません。
＃なので、クラスＥの領域は実際は「IPv4 枯渇を無視して割り当てされずに温存されて」います。
クラスＡ，クラスＢ、クラスＣのサブネットマスクは、1992年６月に RFC1338 で初めて CIDR（「サイダー」と称する模様） と言うクラス分けをバッサリと捨てる概念（＝クラスレス化）が提唱され、 1993年９月の RFC1519 を経て、2006年８月に RFC4632 で現行のものになりました。
さて、IPv4 は、アドレスが４オクテット（４バイト）固定長で構成されます。
１オクテットずつ、ドット区切りの10進数で表記するのが通例です。
１オクテットで表現できる１０進数の整数は０～255 なので、各ドット間の数字は必ず０～255の範囲になります。
これに対して、IPv6 は、アドレスが16オクテット（16バイト）固定長で構成されます。
実にIPv4アドレス総数(約43億)の ２32倍 × ２32倍 × ２32倍 ＝ ２128 個(約340澗 ≒3.4 ×1038) になり、『これだけあればアドレス枯渇問題は将来に亘ってほぼ皆無だろう』ということになっています。
アドレス表記も16進数表記です。これはエンジニアの間では常識ですが、16進数のほうがディジタル機器のあらゆる整数数値において親和性が非常に高いためです。
16進数表記の a ～ f は、基本的に小文字を使うように規定されています。[RFC5952, 2010年８月]
「16進数」がわからない方は、google などを使って各自調べてください。
合わせて「２進数と16進数」の関連を知ることで、何故16進数の方が親和性が非常に高いかが理解できるかもしれません。
IPv6 のアドレスは、２オクテット（２バイト）毎にコロンで区切って表記します。
そして、コロンで区切った各々の部分は「フィールド」と呼称します。
このフィールドは、省略表記（別記事にて後述）しない限り、桁数は４桁固定で必ず８個になります。
IPv6 には「サブネットマスク」という概念がありません。
その代わり、IPv4 のクラスレス化で導入した CIDR の考え方を踏襲して、「プレフィックス」「プレフィックス長」という概念が導入されました。
IPv6 における「プレフィックス」とは IPv4 で言うところの「ネットワークアドレス」、
この長さをビット長で示したものが「プレフィックス長」になります。
2018/03/25(日)やっと使えるレベルになった - IPv6 対応
2018/03/25 4:48
昨年12月にこの制御ボードの IPv6 対応を決めてから、対応作業に結構キツイ４ヶ月でした。
３月に入ってすぐに色々あって、作業自体が専門知識を要する佳境に入っていたため、１週間ほど寝る時間があまり無かったorz..
あとはこの１～２週間で安定性向上と、取扱い説明書改訂などを行って完了です。
ここ最近、『働き方改革』と称してその中に「高度プロフェッショナル制度」という勤務時間ではなく、成果主義に基づく勤務体系が通常国会などで議論されていましたが、そんな言葉が無い時代から筆者自身の服務がそんな感じだったので、一言くらい物申すことが出来ると思うのですが・・（笑）
ハッキリ言いますと、勤務時間は減りません。
「勤務時間」という観点だけで言えばむしろ「増える」のですよ。
だが、短所だけを誇張して、「全て悪」みたいな印象操作は違和感をものすごく感じます。
実際、筆者のような研究・開発職は「労働時間」「出勤時間」「退勤時間」で一般職のように規制されると却って作業そのものがやりずらい上に作業効率が上がらない。
ハッキリ言って、夕方出勤・深夜退勤みたいな柔軟性が欲しい。
安倍総理が言っているのはこういう部分だと思うのですがね。
これが普通の日本人の感性からして「だらしない奴」とレッテル張りしたがるので、そういうことも違和感たっぷりですよ。
問題は過労死を助長する企業風土であったり、職場環境であり、
「カネのことや作業計画の点は面倒みるから、何日か休みなさい」
と（上司や責任者が）言える風土創りが最も必要なのです。ちょっと国会の論戦はズレているのだよね。。
つまらないことで、安倍政権叩きする暇があったら、北朝鮮と支那国の対応、地方疲弊対策を真剣にやってほしいと思ってしまいます。
2018/02/21(水)Windows版 の Chrome でmp4 動画がまともに観れなくなった時の対処・・
2018/02/21 2:39
つい最近まで Chrome でのサイト埋め込み mp4 動画が再生できていたのに、軒並みまともに再生しなくなってしまったようで、、
google が積年の恨みでも果たしたのだろうか・・(数年前から google が推進中の webm 形式動画普及攻勢・・・）
こうなってしまうようになったのです ↓
音声は出るが、映像が全く駄目、、、しかし、Firefox では特段問題がありません。
もしかして、前述のとおり google が chrome で問題が出るように何かやからしたのではないか、と勘繰り、webm 動画形式の対応状況をオンライン調査で再確認します。。
もう webm ≫ mp4 という感じなんですね。動画サイトの大御所 Youtube が webm 形式(VP8,VP9) を本格採用したことの影響が想像以上に大きいようです。
不具合を起こしている mp4 形式動画を webm 形式にエンコードして、アップロード。
動画を表示する部分の HTML を以下のようにしてみました：
<video width="800" height="490" controls>
<source src='20170427_15.webm' type='video/webm; codecs="vp8,vorbis"'>
<source src='20170427_15.mp4' type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
<p>動画を再生するには、videoタグをサポートしたHTML5対応ブラウザが必要です。</p>
</video>
こうすることで、以下のように Chrome での動画再生が復活しました ↓
各所で言及されているとおり、同内容の動画であれば、ファイルサイズは mp4 形式より小さくなるようです。３割減は結構大きいですね。
ここで、avi 形式のファイルサイズが少し小さいのは、音声トラックが入っていないためです。
問題は、エンコードにエラく時間かかるところですね。
当方のＰＣでは概ね動画再生時間の３～４倍かかります。３０分動画なら２時間弱かかってしまう。。。
〔2018/02/22 追記〕 Libre office の更新インストールと共に、Microsoft Visual C++ 2015 Redistributable(x64) - 14.0.24215.1 というものがインストールされたのですが、これで上記の不可解な現象は直った模様。。
2018/02/20(火)IPv6 の基礎(1) - ネットワーク機器類の取扱説明書を見る時、得意になれそうな知識
2018/02/20 5:09
あくまでも「備忘録」です。はい。
筆者がかねてから想像していたとおり、今まで嗜んできたIPv4 とは毛色が違うし、似て似つかないものがあります。なので、初心者から「志を持って」（何のだ・・）猛勉強中です。
そんな中、各種のネットワーク機器を家電量販店やＩＣＴ機器専門店などで買うときや、買った後で知っておくと、
IPv4 は、軍事・学術研究から行き当たりばったりで進化してきた技術ですが、
IPv6 は最初から民生用途が意図されていて、万人共通の定義づけがいくつかあります。
ここがまず IPv4 と違う世界ですね。
IPv6 の世界で先ず使われる用語の基礎用語として、以下があります：
■ ノード
IPv6 通信機能を持った機器全てを指す。
具体的には、パソコン、ネットワークプリンタ、ルータ、サーバを指し、ハブやスイッチングハブなどはノードに含みません。
図示していませんが、スマートフォン、タブレットも「ノード」です。
ノードは「ルータ」と「ホスト」の２つに区別されます。
■ リンク
ハブやスイッチングハブ、無線ＬＡＮアクセスポイントなどを介して、ルータ超えしないで直接イーサネットやＷｉＦｉで通信可能な装置間接続を指します。
ルータ同士の通信も「リンク」です。
ルータ超えの通信は「リンク」ではありません。
■ サイト
１つ以上のリンクからなるＬＡＮを指します。
ルータが複数あっても、インターネットに出ていかずに別のリンクと接続するＬＡＮは、接続ルータ先のリンクもまとめて「サイト」になります。
ただ、この概念は古い IPv6 の資料には出てくるのですが、現在は使いません。
古い IPv6 の資料を読むときに必要となります。
■ ルータ
ノードのうち、リンク外部との通信中継・リンク内部通信の取りまとめを行う機器を指します。
インターネット接続には不可欠な装置になります。
■ ホスト
ノードのうち、ルータ以外の全ての機器を指します。
受信時、自ホスト宛は処理できるが、他ホストへ転送出来ない機器全てがホストです。
パソコン、ネットワークプリンタ、サーバ、スマートフォン、タブレットなどは、典型的なホストの一例です。
リンク内でも他ホストへの送信は、基本的にルータが取りまとめて処理します。
■ 近隣ノード
リンク内で通信が直接到達可能なノード全てを指します。
これらは概念として理解しておくと、後々 IPv6 の理解が楽になります。
2018/02/17(土)IPv6非対応回線に IPv6導入(6to4接続)
2018/02/17 6:12
＃ 正確には対応していたはずだが、ＩＳＰ経営統合でそのあたりの対応が立ち消え状態・・・
よって、IPv4 で IPv6 を包み込んで通信する「トンネル接続」と一般的に称する手法を用います。
筆者はこの「トンネル接続」は嫌いなんですが・・・
通信自体が遅くなる上に、不安定要素を自ずと抱えるからです。どのくらい遅くなるのか、実験で示してみましょう。
先ずは、IPv6 ネイティブ接続(いわゆる IPoE 接続) 回線で通信到達時間を図ってみます。
最初の10回がトンネル接続回線への通信到達時間。これは若干速い方です。日本国内だからあたりまえか。。
次の10回は google IPv6回線 Webサーバなんですが、最初の10回よりも２倍速いです。
このサーバはどうやらオーストラリアに設置されているようです。
外国へ通信するほうが速い・・・orz
次に トンネル接続な回線からの通信到達時間計測。最初の10回は、互いに同じサーバ同士での実験です。
ほぼ同じ程度なのは当然の結果です。
次の10回は、ホスト名指定だと接続の度にＩＰアドレスが変わってしまうようなので、試験条件を同じにするために、ＩＰアドレスを直接入力しています。
さすがに最初の10回と約２倍の差はありますが、IPv6 ネイティブ接続と比較すると、約３倍かかっている。。
単位はミリ秒(1000分の１秒)単位なので、大したことないだろと思う方居られるかもしれませんが、その考えは大きな間違いで、この差が積もり積もってそのまま体感アクセス速度の差になるのです。
やっぱりネイティブ接続が断然いいですね。。