IPsec - NATトラバーサルとは（仕組み）
◆ IPsec - NAT Traversal NATトラバーサルとは、NAT/NAPTを使用しているネットワーク環境においてIPsec通信を問題なく実現する IPsecの拡張技術のことです。下図の通り、ESPパケットをUDPでカプセル化することにより、この付加された UDPヘッダは暗号化の対象となっていないことから、NAPT機器でポート番号の書き換えを可能にしています。 ◆ UDPのカプセル化の判断は誰が行うのか それはIKEが自動的に行います。ISAKMPメッセージをやりとりする際にネットワーク上にNAPTデバイスが 存在するかどうかを検出し、NAPT機器が存在すればUDPでのカプセル化を行うようネゴシエーションします。
サーバ管理者日誌 nstx - Tunnel IP over DNS
otsuneさんとこ[http://www.otsune.com/diary/2004/05/29.html#200405291] から。 TCP over DNS[http://www.nantoka.com/~kei/diary/?200311a&to=200311041#T200311041] とかいうネタを以前書いたのですが、実装がある様ですね。 できない[http://61.203.92.65/~fkz/daiary/200406.html#d011952] っていう指摘を頂いていまして( RinRin王国[http://www.pluto.dti.ne.jp/~rinou/saji/200405.html] 経由)、説明不足だなと思ったりもしたんですが、この場合TTLを気にする必要はありません *1 し、あるドメイン名のAを引いてそいつが実はCNAMEだった場合は、当然そのCN
Geekなぺーじ : TCP vs RTP：何故RTPが必要なのか？
インターネットを流れるトラフィックのほとんどがTCP(Trasmission Control Protocol)によるものです。 TCPは、全てのデータが正しく相手に伝わることを保証するため品質の高いデータ通信が実現できます。 また、どのパケットが受け取れなくて、どれが受け取れたかなどをわざわざ考えなくても良いので、プログラムを書くのも簡単です。 では、何故、わざわざRTPというものが必要だったのでしょうか？ ここでは、まず最初に何故RTPはTCPではなく、UDPの上に存在しているのかを説明したいと思います。 （もちろん、TCPの上に作ることはRTPの規約上は可能ですが、現実的にはUDPの上でしか実装がないと思います。） その後、何故、UDPの上に共通のRTPというものを構築したのかを説明したいと思います。 RTPは、名前にもある通り、「リアルタイム」なデータを転送するためのプロトコルです
DNSでの「浸透」は家電の文脈における「マイナスイオン」と同じような言葉だから使うのやめよう！ - mura日記 (halfrack)
「後は DNS の浸透を待つだけ」とかよく聞きますが、 DNS という技術に「浸透」という単語は存在しません。 それどころか、以下の点において、理工系の人間なら誰でも血圧が上がる「マイナスイオン」と同等です。お近くにいる DNS エンジニアの血圧が上がるので使うの止めましょう！*1 定義が無い 技術的にツッコミどころ満載 専門家ではない人たちが雰囲気で使っている 「DNS はインフラ」ならともかく、多少なりとも DNS で飯食ってるエンジニアは使うのを止めよう！ 「浸透」の正確な定義 DNS 関連 RFC のどこにも浸透という単語は出てこないですし、浸透という単語の定義についてまともに解説してる Web ページがあったら教えてほしいです。 「DNS 浸透」でぐぐってるだけで血圧上がってきますよ、うわぁぁぁぁ！ 定義がない用語なので「浸透」を使うのはやめよう！ 「浸透」の巷での定義 巷でよく
さよなら、僕が知っていたイーサネット
20年ほど前にイーサネットを学び始めた頃、イーサネットの2つの大きな特徴を教わりました。1つは、イーサネットでは複数のノードがケーブルを共有しているため、信号の衝突（コリジョン）が発生すること。もう1つはネットワーク構造には決してループとなる部分があってはならない、ということです。 しかしこの2つの特徴は、イーサネットの進化とともに消え去ろうとしています。イーサネットは僕の知っている昔の姿から大きく変わろうとしているのです。 コリジョンはなくなった イーサネットの大きな特徴の1つが、CSMA/CD（キャリアセンスマルチプルアクセス／コリジョンデテクト）です。ネットワークに複数の機器が接続されている場合、同時に通信を開始するとネットワーク上で信号が衝突するコリジョンが発生、コリジョンの発生が検出された場合には、それぞれの機器はランダムな時間だけ待って再送する、という仕組みです。 これによりイ
DSAS開発者の部屋:こんなに簡単！ Linuxでロードバランサ (1)
DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
高木浩光＠自宅の日記 - Bluetoothで山手線の乗降パターンを追跡してみた , ユビキタス社会の歩き方(6) Bluetoothの「デバイスの公開」「検出可能にする」..
■ Bluetoothで山手線の乗降パターンを追跡してみた この日記を書き始めてからもう6年になろうとしている。書き始めたきっかけは、RFIDタグのプライバシー問題が理解されないことに焦りを感じたからだった。当時の空気では、RFIDタグは5年後くらいに普及し、しだいにRFIDの埋め込まれた日用品で溢れかえるようになり、10年後くらいにプライバシー問題が顕在化すると目されていた。しかし、6年経った現在、私の靴にRFIDタグは埋め込まれていない。 当時の議論で描かれていたRFIDタグの問題は、無線LANやBluetoothにも共通することであり（MACアドレスがユニークIDとなる）、それらの方が先に普及するかもしれないという予感はあったが、現時点でも、無線LAN機器を持ち歩いている人はごく一部の人に限られている。しかし、Bluetoothはどうだろうか。これまでにも何度か、最近のBluetoo
Geekなぺーじ : 今朝、インターネットが壊れました
今朝０１時２３時JST頃から１時間弱、インターネットが世界的に壊れていたようです。 ほどなくして収束していったようですが、ISP同士のBGP接続が切れて通信が出来ないという状況が局所的に発生していたようです。 3/11 (invalid or corrupt AS path) anyone else seeing very long AS paths? [janog:08731] long AS Path incident] JANOGメーリングリスト 世界中で影響があったようですが、国内では上流網の一部でBGPのpeerが切れて国際的な通信が不通になっていた瞬間があったようです。 ただし、繋がったり切れたりという箇所もあったようです。 「壊れた」原因 NANOGでの情報によると、以下のようなログがルータに残されていたようです。 255以上という異常に長いAS pathが原因のようです。
IBM - TCP/IP チュートリアルおよび技術解説書
TCP/IP の基礎概念、アプリケーション・プロトコルについての概説、ネットワーキングにおける拡張概念とインフラストラクチャーの傾向について説明しています。
DDoSを受けても動くWebサイトとは - pekeqのブログ
参考：WILLCOMストアが遅いのはなぜ？ 今回のWILLCOMストア祭りで、昨日書いた「停止→戻る→進む→Submit」というやり方が「DDoSと同じなんじゃない？」という話があった。DDoSに近いリクエストが来た場合どうしたらいいんだろう。アプリや設定側ではどうやって備えればいいんだろう？ 自宅のサーバと、玄箱にtomcatを入れて試してみるかな… （以下は思いつきなので、これをやればOKというわけじゃないです。念のため） DDoS F5攻撃 SYN Flood 今回はSYNだけのパケットが連発するわけじゃないからなぁ… doPost/doGet doPost実行中にコネクションが切られたのをどう処理するか DoSで一番滞留しそうなのがここではないだろうか。Servletで処理していて、レスポンスを返そうとしたらもう切れてる、というパターン 普通は、処理が終わってServletOutp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[ケータイ用語の基礎知識]第511回：Bluetooth Low Energy とは
ggsoku.com
http://blogging.from.tv/wp/2010/11/07/4405