インターネットの形を変えてしまうかも知れないDPI
The document contains various URLs related to SSL security issues, including references to Digicert and British Telecom. It mentions a court ruling regarding a SOPA-style blackout affecting music sites. Additionally, it discusses network information related to bandwidth and Japanese Internet service providers.
Nagle アルゴリズムと遅延 ACK - Web/DB プログラミング徹底解説
パケットの解析をする上で、TCP/IP の基礎知識が必要であることはもちろんです。 また、Nagle アルゴリズムと遅延 ACK、及びそれらによる (有名な) 問題を理解していないと、 パケットを読む上で説明できない事柄が増えてしまいます。 ここでは、Nagle アルゴリズムと遅延 ACK をとりあげます。 Nagle アルゴリズム は 1984 年に John Nagle 氏が提案したアルゴリズムで、 RFC 896 に既定されています。このアルゴリズムにより、 ネットワークの輻輳を引き起こす、タイニーグラムの氾濫を防ぎます。 Nagle アルゴリズムは、データをできるだけまとめて送信することにより、 通信の効率を向上させるためのアルゴリズムです。 ルールは次の通り: TCP の送信バッファ中に送達が確認されていないデータがある場合、TCP はバッファ中の 全てのデータの送達が確認される
DNS誕生までの経緯をおさえよう (1/2)
覚えにくいIPアドレスを名前で ネットワークを経由して通信するには、ユーザーもしくは通信アプリケーションが宛先のコンピュータを指定しなければならない。このときに必要になる情報が「IPアドレス」だ。TCP/IPがベースのネットワークでは、コンピュータの識別にIPアドレスを用いるからである。 ただ、IPアドレスは「192.168.1.1」といった具合に4つの数字の羅列※1なので、非常に覚えにくい。そこで、英数字を組み合わせた「ホスト名」という名前を付け、その名前を宛先に使用する方法が考えられた。 ※1：4つの数字の羅列 コンピュータ内部では、32桁の0と1の組み合わせで処理されている。普段我々が目にしているIPアドレスは、これを8桁ずつ4つに分割したものである。 ただ、このホスト名を付けるという行為は人間の都合で考えたものなので、何とかしてコンピュータが扱いやすいIPアドレスに変換しなければな
Internet
インターネット崩壊について考えるためのページ インターネットの理想は90年代半ばに崩壊した。現在のインターネットは共同幻想である。 その幻想としてのインターネット（もはやインターノットと呼ぼう）も化けの皮が剥がれて崩壊する日は近い。 心配すべきはインターノットではなく、インターノットに依存した社会である。 T.Suzuki関係 毒入れ関連 DNSSEC はなぜダメなのか Forged Delegation Injection into Empty Non-Terminal with NSEC3 DNS 毒入れの真実(Oct 24, 2015 @DNS温泉補講) Blog: 開いたパンドラの箱: 長年放置されてきた DNS の恐るべき欠陥が明らかに 解説: キャッシュポイズニングの開いたパンドラの箱 -1- 解説: キャッシュポイズニングの開いたパンドラの箱 -2- 頂上は如何に攻略されたか
TCP-IPポート番号一覧
Last update 2008.03.20 TCP/IP のポート番号一覧です。IANA提供の資料を抜粋&加工しましたしました。 TCP、UDPのポート番号は大きく３種類に分かれています。 1.よく知られているポート(WELL KNOWN PORT NUMBERS) 0-199 200-499 500-1023 2.予約済みポート(REGISTERED PORT NUMBERS) 1024-1499 1500-1699 1700-1999 2000-2499 2500-3299 3300-4999 5000-9999 10000-49151 3.動的／プライベートポート(DYNAMIC AND/OR PRIVATE PORTS) 49152〜65535 ☆サービス順にソートしてみました Reserved or Unassigned 数字-B C-C D-E F-
おそらくはそれさえも平凡な日々: Akamaiが想像以上に物凄かった件 in Akamai勉強会
続きというか、お詫びを書きました。 文章を多少修正しました。技術的な点は色々誤りがあると思いますので、あまり信用しないでください。詳しくはgeekpageさんがじきに書いてくださるはずです。 入口にあった、Akamaiサーバーがリアルタイムに捌いているトラフィックを可視化した地球儀が映ったモニター。アメリカが早朝なのでトラフィックは850Gbpsと少な目(笑) それでもアメリカのバーの長さは凄い やすゆきさんという方が、Blogでひっそりと告知していたのが、IT勉強会カレンダーに載っていて、それを目ざとく見つけて行ってきた次第。募集枠5人とかだったので、焦って申し込んだら、実際そんなに募集は来なかったみたいで意外。僕なんか「Akamai」って書いてあっただけで飛びついたのに。内輪に近いノリだったてのもあると思うけど、案外「Akamai」には訴求力が無いのかね。まあ、インターネットの裏の支配
意外と知らない？NICを冗長化するボンディング（bonding） - うさぎ文学日記
割と長い間ネットワークに携わってる人と話していて、その人がボンディングの存在を知らなかったので、もしかして知られていないのではないかと思ったので紹介してみます。 Linuxでは、ボンディング（bonding）を使うことでNICの冗長化、負荷分散ができます。ケーブルが断線したり、間違えて抜いてしまったなんてことがあったとしても大丈夫です。 このボンディングはNICを複数束ねて使うことで、1個のチャンネルにすることができます。異なるベンダーのNICとかでも大丈夫ですよ。（bondingは機能の名称で、束ねることはteamingとも言うらしい） 異なるスイッチ（更に、その上に異なるルーターとか）なんかにつなぐと、更に冗長化ですよ。 当たり前ですが、NICは2個以上消費します。 /etc/sysconfig/network-scripts/ifcfg-bond0 を作成 DEVICE=bond0
ＤＮＳのＲＦＣ
ＤＮＳのＲＦＣ 基本的なＤＮＳの仕様(Standards) RFC 1034「ドメイン名－概念と機能」（日本語訳） RFC 1035「ドメイン名－実装と仕様書」（日本語訳） ＤＮＳといえば、この２つが標準になります。 ＤＮＳができる前のインターネットでは、ネットワーク情報センター(NIC)で管理していたHOST.TXTファイルに、 ホスト名とＩＰアドレスの対応を書いて、これを各ホストに配っていました。 このやり方は配布に時間がかかるなど、いろいろ問題がありました。 この解決のため、様々な方法の提案と実装されました （RFC 799, RFC 810, RFC 811, RFC 819, RFC 830, RFC 882, RFC 883, RFC 953など）。 最終的に決まったドメインネームシステムの内容を記述したのがこの２つのＤＮＳ仕様書になります。 ＤＮＳの考え方、ＤＮＳでよく使われ
RFC1035 ドメイン名－実装と仕様書
この文書はRFC1035の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。 Network Working Group P. Mockapetris Request for Comments: 1035 ISI November 1987 Obsoletes: RFCs 882, 883, 973 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION ドメイン名 － 実装と仕様書 1. STATUS OF THIS MEMO 1. この文書の状態 This RFC describes the
RFC1034 ドメイン名－概念と機能
この文書はRFC1034の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。 1. STATUS OF THIS MEMO この文書の状態 2. INTRODUCTION はじめに 2.1. The history of domain names ドメイン名の歴史 2.2. DNS design goals ＤＮＳ構想の目標 2.3. Assumptions about usage 利用に関する仮定 2.4. Elements of the DNS ＤＮＳの要素 3. DOMAIN NAME SPACE and RESOURCE RE
NetBSD 絹の日記
最近、やっと気が付いたこと。 (そうしていくつか自分で間違えていたこと)。 自分一人だけで作っているもので ある程度進んでから cvs に入れたため、まとめて import した時に verdor branch として例えば MAIN とかしてしまって co -r MAIN などとすると 1.1.1 側の枝で作業をしてしまう やはり 1 の側の幹で作業した方が気分がいい とは言うものの co -r MAIN なんてするかなぁ。 <csimport user="../frame1.data/Components/top.html" occur="29"></csimport> GoLive FAQ より CS は CyberStudio の接頭辞です。"Adobe GoLive JavaScript Library" と いうファイルのことで、中身は JavaScript の関数の集まりです
第14回 TCPとUDP
前回は，現在のネットワークの基盤をなすネットワーク・プロトコルであるIP（Internet Protocol）と，LinuxカーネルのIPプロトコル・スタックについて解説しました。 IPというプロトコルでは，2点間のデータ通信の方法しか定義していません。例えば，送信元が送ったデータが送信先に届いていなくてもIPでは関知しません。あくまで，このホストからこのホストにデータを送るにはこうすればいい，ということだけ規定してあるのです。つまり，細かい通信の制御や信頼性確保などは別のレイヤー（トランスポート層）で実施することになります。 IPネットワークで利用される代表的なトランスポート層プロトコルが，「TCP」（Transmission Control Protocol）と「UDP」（User Datagram Protorol）です＊1。 UDPは，IPをほとんどそのまま利用するだけのプロトコル
トランスポート層 - Wikipedia
トランスポート・プロトコルは、トランスポート層（第四層）の通信プロトコルである。インターネットにおける2大トランスポート・プロトコルとして、コネクション型の「TCP」（Transmission Control Protocol）と、コネクションレス型の「UDP」（User Datagram Protocol）がある。その他、Datagram Congestion Control Protocol（DCCP）やStream Control Transmission Protocol（SCTP）が有る。 トランスポート層は通常はホストコンピュータのオペレーティングシステム上のプロセスに制御され、ルータやスイッチには制御されない。通常トランスポート層は、ネットワーク層（第三層）によって提供された信頼性が低く極めて基本的なサービスを、より強力な物へ転換する。 TCP/IPモデルでは、トランスポート
UDP を使ってみよう (1)
UDP とは UDP とは、User Datagram Protocol の略です。 TCP (Transmission Control Protocol) は信頼性を提供するプロトコルですが、 UDP はそうではありません。 これまで HTTP・POP3・FTP などのプロトコルを使ってきましたが、 これらは全て TCP を利用していました。送信したいときは print SOCKET "hoge\n"; と書き、受信したいときは $buf = <SOCKET>; としていました。しかし陰では OS が TCP を使って信頼性を保証するためのさまざまなチェックが行なっていたのです。 OS はいったい何をやっていてくれたのでしょうか? それは以下のようなことです。 データの送り先が存在するかどうかのチェック データ化けの修正 データの順序の保証 データ損失時の再送信 相手がデータを受信したか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Photo Tourism: Microsoft Research, Interactive Visual Media Group
Practical, Visual, Three-Dimensional Pedagogy for Internet Protocol Packet Header Control Fields
「BIND 10」をC++とPythonで書く狙いとは JPRSに聞く、次期DNSソフト開発の意義＜後編＞
3 Minutes Networking No.62
Cloud Data Integration for Data Engineering
Linux と Unix のセキュリティ機能