約 3,837,697 件
https://w.atwiki.jp/atyou/pages/29.html
WebLogic Server の管理ドメインは、WebLogic Server リソースの論理的に関連したグループです。 ドメインには、管理サーバと呼ばれる特殊な WebLogic Server インスタンスが含まれます。 管理サーバでは、ドメイン内のすべてのリソースを一元的にコンフィグレーションおよび管理します。 通常は、管理対象サーバと呼ばれる WebLogic Server インスタンスも含めてドメインをコンフィグレーションします。 Web アプリケーション、EJB、その他のリソースは管理対象サーバにデプロイし、 管理サーバはコンフィグレーションや管理の目的にのみ使用します。 複数の管理対象サーバをクラスタにグループ化することができます。 それによって、重要なアプリケーションでロード バランシングとフェイルオーバを利用できると同時に、 1 つの管理サーバを使用することで、管理対象サーバ インスタンスの管理が容易になります。 http //www.beasys.co.jp/e-docs/wls/docs91/domain_config/understand_domains.html
https://w.atwiki.jp/nyabecch/pages/34.html
17 インターネットのルーツ（後編） (^ー^) ここから、今日の「ネットワーク」という概念が生まれます。 分散されている各々のコンピューターが、幾つかのルートでそれぞれ他のコンピューターと連絡を取れるような形態にしておけば、特定のコンピューターや特定の回線が攻撃その他の障害によって破壊された場合でも、ネットワークそのものは機能し続ける事になります。 こうしてアメリカ空軍は、某機関に「分散されたネットワーク」の開発を依頼する事になり、様々な試行錯誤や紆余曲折の末にパケット通信による、世界初のネットワークとなる「ARPANET」を築き上げたのでした。 厳密に言えば、ここで開発されたものは今日のインターネットの形態とはやや異なるものであったとも言われますが、今日企業や組織などどこでも当たり前のように見られる「クライアント・サーバ型＝client server（クラサバ型）network」のルーツとして、フレームワーク的にはこれがインターネットの原型になっていると考えて、ほぼ間違いではないでしょう。 そうして睨み合って来た米ソの対立も「ソ連崩壊」によって冷戦が終わりを告げると、一極支配の主役となったアメリカとしては最早「ソ連の脅威」に備える必要がなくなりました。 無論、ソ連の脅威がなくなったとはいえ「世界の警察官」をもって自認するアメリカであるからには、地球上のあらゆる脅威に対して常に備えを万全にしておかなければなりませんが、その頃にはアメリカの技術力は既に格段の進歩を遂げており最早、冷戦時代に活用していた技術はアメリカ軍にとっては「不要となった、古い技術」に過ぎませんでした。 そこで大学などの研究機関や、やがては民間企業などに払い下げられる事となり、次第に形を換えながら今日我々世界中の人々が享受している「インターネット」へと、発展していく事になったのでした (*￣▽￣*) 名前 コメント すべてのコメントを見る 16 インターネットのルーツ（前編） (^ー^) インターネットの歴史は、1960年代に遡ります。 当時は、第二次世界大戦以降の「米ソ冷戦時代」の真っ只中という時代でした。 それに先立つ1957年に、ソ連が世界で初の人工衛星の打ち上げに成功した事にショックを受けたアメリカ（スプートニク・ショック＝sputnik shock）は、国家としての威信をかけて本格的な科学技術の発展に取り組む事となり、国防総省に高等研究計画局（ARPA）という組織を設立しました。 当時の二大強国とはいえ、軍事力ではソ連に対しても圧倒的な優位に立っていたアメリカは、ソ連に対して先制攻撃を仕掛ける事はせずに、ソ連が先制攻撃を仕掛けて来るのを待って余裕を持って反撃する・・・というシナリオを描いていました。 より具体的に言えば、ソ連の核攻撃によって首都ワシントンが壊滅しても直後の反撃によって、アメリカは余裕を持ってソ全体を壊滅出来るという戦略です。 アメリカにとって最も重要な課題は、言うまでもなく重要な機密情報をいかにして守っていくかという点であり、そのためにはワシントンやニューヨークといった、標的にされやすい大都市ばかりに情報を一極集中させておくのは危険である、との結論に達した事は言うまでもありません。 そこで、こうした重要な国家機密を複数の地理的に離れた場所に分散しておく事で、万一どこかが核攻撃を受けた場合でも直ぐに元の状態に復旧する事の出来る準備をしておく体制を整えておく必要がある、という結論に達します。 さらに考えを勧めていくと、ただ単に同じ情報を保管しておくのみならず、それら何ヶ所もの遠く離れた場所にあるコンピューターで共有されている同じ情報に新たな情報が加わったり、古い情報が変更された場合にネットワークで結ばれている総てのコンピューターにも、リアルタイムで同じ内容の情報が送られなければなりません。 名前 コメント すべてのコメントを見る 15 Pingの使い方 さらにこのDNSにおいて、ネームサーバにホスト名を通知してIPアドレスの検索を依頼したり、その逆を依頼したりするクライアント側のプログラムの事を「リゾルバ（resolver）」、または「逆引きリゾルバ」と言います。 ちなみにURLからIPアドレスを調べる方法は簡単で、前回ご紹介したホスト名に対して 「pingを飛ばす」 だけです。 （例を挙げるとわかりやすいのですが、相手のサーバに負荷がかかってしまう事を避けるため、ここでは具体的な例は省略します。 また本来、名前問い合わせには「nslookup」という正式なコマンドがありますが、話がややこしくなるためここでは省略します） pingの飛ばし方は、Ms-Dos（コマンドプロンプト）の画面を開き 「ping ドメイン名」 とコマンドを入力すると、pingがネットワーク上に送信される経過とともに、対象となる相手のIPアドレスが還ってきます。 pingの流れは、まずコマンド（ツール）が発行されると応答IPアドレスを含んだ「ICMP(Internet Control Message Protocol)エコー要求パケット」というものが、目標のマシンに送信されます。 目標のマシンがTCPパケットを受信した場合、クライアントからのping要求に認証の応答を返す仕組みです。 この「ping試験」は、本来は特定のサイトと通信できなかったり障害の疑いがある場合に、ネットワーク管理者が経路上にあるどのサーバがダウンしているかを調べるため（疎通確認）に使っていたツールでしたが、何にでも悪用をしたがる困ったバカモノがいて、これを嫌がらせに悪用する事を思い付きました。 言うまでもなくpingは、ネットワーク上にある総てのマシンのIPブロードキャストアドレス全体に向けて発行される（それでなくては意味がない）ため、これを無闇矢鱈と続けて何度も発行するとネットワーク上の総てのマシンがpingパケットの対応処理に追われる事態が出来し、その結果総ての標的となったマシンに過重な負荷がかかり、回線速度の低下やサーバのダウンを招く事になってしまいます。 言ってみれば「悪戯電話」や「偽の出前」などと同じような概念です。 これを「ping攻撃」、または「Dos攻撃（Denial of Services）」、または「Smurf攻撃（Dosツールの一種）」などと呼びますが、そうした悪意がなくとも知らずにpingを連発してしまったりすれば、相手の方では「アタック（攻撃）して来た」と思うのは当然であり、こうした行為はレッキとした「犯罪」と見なされますので注意が必要です。 こうして標的のマシンに過重負荷をかける事を目的とした行為を行う事も、クラッカー（cracker）の端くれと言えます。 名前 コメント すべてのコメントを見る 14 ドメインの読み方（後） ＼(-_- ) では、同じ要領で「２ちゃんねる」のURLを見ていきましょう。 http //www.2ch.net/ トップレベル・ドメインは net で、こちらは国名ではなく「ネットワーク機関」に所属している事を表し、サブドメインでは 2ch という、サイト名を表しています。 2ch.net の部分がドメイン名であり、ホスト名（WWW）を含めた全体を表現する時は「完全修飾ドメイン名＝FQDN（Fully Qualified Domain Name）」と言い表わされるという事は前回記述した通りです。 このように本来はまずIPアドレスがあり、それをドメインに変換したものがURLですが、人間の覚えやすいのは意味のない（ように見える）数字の羅列よりは意味付けのし易い文字の羅列の方なので、寧ろURLの方が主流になっています。 例えば http //www.2ch.net/ というURLを見れば、直ぐに「２ちゃんねる」とわかりますが 01000000.01000111.10010001.00101011 或いは 64.71.145.43 というIPアドレスだけを見ても、直ぐにはどこのサイトを表したものなのかはわからないのが普通です。 こうして、コンピューターがIPアドレスを元にドメイン名に変換（逆引き参照ゾーン）したり、ドメイン名をIPアドレスに変換（正引き参照ゾーン）するのがDNS（domain name systemまたはdomain name service）の働きで、この変換の事を「（IPドレスをドメイン名に、または逆に）マッピング＝mapping（する）」と呼びます。 通常「ＹＡＨＯＯ！」や「ＭＳＮ」など、よく使うサイトはお気に入りに登録しておいて開いた方が手っ取り早いのでわざわざアドレスを手入力する人は稀でしょうが、例えば 211.14.15.5 64.71.145.43 と入力しても http //www.yahoo.co.jp/ http //www.2ch.net/ と同じように「ＹＡＨＯＯ！」や「２ちゃんねる」が、それぞれ表示される事は言うまでもありません。 また本 10ちゃんねる (*￣ー￣)y-~~~~ が、上記のような固定のIPアドレス（正式名）を持たず http //www23.atwiki.jp/nyabecch/pages/16.html というドメイン名でしか表示させる事が出来ないのは、以前にも記述した通り専用のサーバではなくwikiサーバの中の、特定のセグメントを借りているに過ぎないためで、正式なホスト名はやはり http //www23.atwiki.jp となります。 (注)これを書いた後で確認したら「２ちゃんねる」のIPアドレスが、既に変わっておりました (^^ゞ 名前 コメント すべてのコメントを見る 13 ドメインの読み方（前） ＼(-_- ) 元々、コンピューターが理解できるのは二進数のみです。 例えば『YAHOO！ JAPAN』（以下 「YAHOO！」と記述）のIPアドレスはコンピューター上では二進数の 11010011.00001110.00001111.00000101 として処理されますが、これでは人間の記憶力では覚えるのが大変なので 211.14.15.5 といった具合に、一般的には10進数で表記されます。 しかしこれでも二進数よりは憶えやすくなったとはいえ、依然としてこうした数字の羅列だけでは人間の頭では覚え難い。 一つや二つくらいなら問題ないですが、幾つも数があると憶えるのには限度があります。 そこでURL（Uniform Resource Locator＝資源などの格納されている一定の場所、といった意）というものが登場して来ました。 「YAHOO！」や「２ちゃんねる」のような、不特定多数のユーザーが自由に利用できるWebサイトのIPアドレスがコロコロと変わっていては、ユーザーが常に目的のサイトまで辿り着く事が出来ませんので、当然の事ながらこうしたWebサイトは総て固定（fix）のIPアドレスが使われる事になります。 例えば「YAHOO！」 http //www.yahoo.co.jp/ というのが一般的に馴染みの深いURLですが、これは人間の頭で理解し易いように文字列に置き直したもので、正式には（コンピューター上）は 11010011.00001110.00001111.00000101（211.14.15.５） として処理されます。 これを http //www.yahoo.co.jp/ と置き換えるために、DNS（domain name system）という技術が登場します。 http //www.yahoo.co.jp/ というのは 11010011.00001110.00001111.00000101（211.14.15.5） という正式名に対する「ドメイン名」（より正確には「完全修飾ドメイン名＝FQDN＝Fully Qualified Domain Name）」）というもので、ドメインは「.（ドット）」で区切ったツリー構造（コンピューターのデータ管理方法で、図にすると次々に枝分かれしていく木のように見えるところから、こう呼ばれる。 ローカルPCの「エクスプローラ」などでもお馴染み）の階層で表されます。 ドメインの読み方はメールアドレスも総て同じで、常に後ろの方から最も外側の（大きな）階層を表していきます。 この場合は jp の部分からで、この部分は「JPRS（Japan Registry Service＝日本レジストリサービス）の略」国や機関を表す「トップレベル・ドメイン」と呼ばれます。 次に yahoo.co 「株式会社YAHOO！」の部分で、一般的には会社名（または組織名）などを表し、これを「サブ・ドメイン」と呼びます。 先頭の www はホスト名で、ここまで総てを含めた全体を前述した「完全修飾ドメイン名（ＦＱＤＮ）」と表現し、wwwを除いた yahoo.co.jp だけを表わす時は、単に「ドメイン名」と言います。 (注)文中にある「YAHOO！」のIPアドレスは、記事を書いた当時のものです。 名前 コメント すべてのコメントを見る 12 DDNS（ダイナミックDNS）の特徴 今回は、ダイナミックDNS（DDNS）の特徴に触れていきます。 ダイナミックDNSとは、サーバーとして同一ドメインでの常時接続を維持するため、インターネット接続・切断時に変動するIPアドレスと登録ドメインの対応関係を動的に結びつけるシステムの事です。 以前にも何度か触れてきたように、プロバイダからデフォルトで割り当てられるグローバルアドレスはDHCPアドレスのため、接続する都度に毎回IPアドレスが変わる事になります。 これは喩えて言えば、折角魅力的な店を構えてながら年中引っ越してばかりいるのと同じ事で、これでは折角興味を持ってくれた固定客ですら店の場所が特定する事が出来ず、次第に客足が遠のいていく結果となります。 そこで商用などの目的で利用したいユーザーとしては、固定IPを取得して自らサーバを立ち上げる必要が出てくるわけです。 以前まではこうした環境を整えるためには、以下に示すような幾つかの面倒な条件をクリアしなければなりませんでした（以下、某プロバイダのＷｅｂページを参照しています） 1.「独自ドメイン」を取得する必要性。 この取得や維持には、時間と費用がかかる事は言うまでもありません。 2.「DNSサーバー」を自宅で構築する必要性。 プライマリDNS、セカンダリDNSの２台のパソコンをサーバー用途で準備する必要がある（セカンダリDNSサーバーは無償で貸し出ししているサービスがありますが、プライマリDNSはユーザー自身で準備する事になります） 3.固定IPアドレスが取得出来る、プロバイダーへの加入の必要性。 この場合、一般的には通常のプロバイダーよりは高価な月額料金がかかる事になる。 ところが、最近プロバイダなどの提供している「ダイナミックDNSサービス」では、DHCPなど固定IPアドレスを持たない接続環境でも、サーバーを立てることが可能となっています。 ダイナミックDNS（DDNS）のメリットは、自分だけのオリジナル・ドメイン（ただし、サブ・ドメインまでに限定されます）を使用出来る点です。 例を挙げれば http //www.nyabecch（ユーザーが取得したドメイン名）.co.jp/ というアドレスで自らのＷｅｂページにアクセス出来るようになり、同様に info@ nyabecch（ユーザーが取得したドメイン名）.co.jp というようなメールアドレスが使えるようにもなります。 プロバイダなどの提供するダイナミックDNSには、以下の特徴があります。 自分で「ドメイン」を取得（申請）する必要がない。 ドメインを取得しないのでDNSサーバーを自宅で構築する必要がない。 動的IPアドレスでも使用出来る。 但し、プロバイダのサーバを借りている事に変わりはないので サブ・ドメイン名までしか使えない という点が、デメリットとして挙げられます。 名前 コメント すべてのコメントを見る 11 ポートという概念 さらに固定IPの利点を挙げるために「ポート」について触れまなければなりません。 インターネットのサーバ上にある「TCP/IP（Transmission Control Protocol/Internet Protocol）」や「UDP（User Datagram Protocol）」のプロトコル（protocol）やネットワーク・アプリケーションは「ポート（port）番号」で管理されており、このポート番号はアプリケーションを識別するために使用されます。 ポート番号の代表的な例 ポート20 FTP（ファイル転送用） ポート21 FTP（ファイル制御用） ポート23 telnet（Telnet） ポート25 SMTP（メール送信用） ポート53 DNS（Domain Name System） ポート80 www（http） ポート110 POP（メール受信用） IPアドレスが世界共通の住所のようなものであるのに対し、６万５５３５種類からなるポート番号は宛先の名前に相当するものです。 またポートによっては、クラッカーなど悪意の第三者から虱潰しに標的にされやすいようなセキュリティに脆弱性のあるものがあり、プロバイダではそうした危険性の高いと認められる特定のポートを運用上の理由から塞いで（アクセスできなくして）いるケースも見られます。 そうしたアクセス制限を設けられた特定のポートにも、通常は固定IPを使えば自由に出入りする事が可能となるため、脆弱性が高くアクセスを規制されている事の多いネットワークゲームなどを好むユーザーが固定IPを使用しているケースは、少なくありません。 ただし当然の事ながら物事総てがそうであるように、メリットの裏には同じ分だけデメリットが伴う事は避けられないところです。 腕さえあれば豪華絢爛かつ自由自在にＷｅｂページを飾る事が出来る反面、自分のIPアドレス（またはドメイン＝domain）をWeb上で明らかにしなければなりませんし、メールサーバを立てていれば送信するメールのヘッダーにはやはり必ずドメインが自動的に開示される事になるわけで、少しオーバーに表現するなら名札をぶら下げて百鬼夜行の世界を歩いて廻っているようなものです。 したがって悪意の第三者からは、IPアドレスやドメインを狙い打ちにされやすいというデメリットは避けられない事になり、それだけに不正アクセスやクラッカー（cracker）の標的になり易くなり、場合によってはPC内のデータの閲覧や改ざんといった被害を受けるに止まらず、 知らない間に他のパソコンやサイトへ攻撃を行う「踏み台」として利用される危険性さえも考えられます。 名前 コメント すべてのコメントを見る 10 Fix（固定ＩＰ）のメリット（後編） 例えば、ワタクシのWebページのURLは http //www23.atwiki.jp/nyabecch/ で、ご存じの通り http //atwiki.jp/ が、WikiというサイトのURLです。 この中で /www23 がワタクシのHPに割り当てられている、Webサーバの中の位置を示すアドレスで /nyabecch/ が上記のサーバの中で「nyabecch」なるＩＤを持つ、ワタクシに割り当てられた特定のスペースとなります。 わかり易く例に取るために「@Wiki」を大きなマンションに喩えるとすれば、ID以降のドメインの部分がユーザーそれぞれの部屋番号と見る事が出来ます。 Wikiは例外ですが、通常の無料サイトやプロバイダのＷｅｂページのサーバ上で割り当てられるスペースでは容量制限が設けられていますが、これは個人で使用しているPCにもディスクの容量に限りがあるのと同じように、ハイエンドなサーバ機といえどその容量や処理能力には限界があるためです。 従って本格的に自分用のWebページを創りたい場合などは、プロバイダの容量制限ではかなりの限界がありますが、自分のPCをサーバにする事で容量の制限などを気にする必要がなくなるだけでなく、CGI（Common Gateway Interface）等のプログラムの設置や、音楽や映像のストリーミング機能といった様々な拡張を自由に展開する事が可能となるため、本格的なWebページを創る事が出来ます。 また、同じようにメールサーバを運用する事によって、フリーメールのような容量制限を気にする必要がなくなるので、デジカメ画像など巨大な添付ファイルが含まれるメールの受信等も容易になります。 このほか出先でのモバイル環境から、PCを特定してデータベース等へアクセスしたり、固定ＩＰアドレスである事が条件付けられているような「IP電話機」といった様々なソフトウェアを利用する事が可能となるなど、Fixにより齎される利点は実に多岐に渡ります。 名前 コメント すべてのコメントを見る 9 Fix（固定ＩＰ）のメリット（前編） さて、前回までにＩＰアドレスが「DHCP」と「Fix（固定）」の２種類に分類されるという事に何度か触れて来ながら、接続の都度ＩＰアドレスが変わる、DHCPの安全性を記述して来ました。 これまでを読んで 「では何故、わざわざリスクを伴う「Fix」を使用する（しかも大抵の場合は、わざわざオプション料金を払ってまで）必要があるのか？」 と、疑問に思われた方も多い事でしょう。 これには勿論それ相応の理由があり、ＩＰアドレスを固定にするメリットを挙げていけば、実はここには書ききれないくらいに沢山あります。 この場合、常に同じＩＰアドレスが保持されているという事は 「総てのインターネット上の通信機器から、PCを特定して接続する事が可能になる」 というところがポイントとなります。 一般的に良く使われるのがユーザー自身が自分で「サーバを立てる」場合で、具体的な例としては自分のWebページの公開やメールサーバの運用等がそれに当たります。 言うまでもなく、WEBページというのは、Webサーバに格納されています。 Webページというのは、言ってみれば２４時間営業の商店のようなもので、誰かがアクセスした時に常に閲覧出来るような状態でなくては、意味がありません。 通常Webページを作るには、特定の開発言語（一般的にはhtmlやjavaなどスクリプト（script）と呼ばれる簡易言語が使用されます）の知識が必要になるところですが、無料サイトやプロバイダの提供している簡易Webページでは「Wiki」のように殆んどこれらがデフォルトで組み込みとなっているために、ユーザー環境ではツールを使うだけで、Webページを作るのに特別な知識は必要としないケースが殆んどです。 最も身近な例では、プロバイダに加入した時点で無料Webページのスペースが付与される事になります。 無料サイトやプロバイダのWebページは、その企業の所有しているサーバの中の特定のスペースが、加入者毎に割り当てられる仕組みです。 ここで、わかり易く「Wiki」を例にあげて説明しましょう。 名前 コメント すべてのコメントを見る 8 ブロードキャストを理解する（後編） 全ネットワークに流れるデータは通信用語で「ブロードキャスト」と言いますが、これは「データリンク層＝レイヤ２」のみで起こる現象であり、その上位の階層となり「パケット通信」（パケット＝packetとは小包、ヘッダー＝headerは荷札という意味。パケットは、別名として「データグラム」と言われる場合もあります）が基本である「ネットワーク層＝レイヤ３」では、ブロードキャストは総て遮断される事になります。 したがって、個人情報がおおっぴらに流れる事はありません。 ルータというのは元々複数のネットワークを繋ぐための機器で、企業などではルータを使用してＮＩＣから割り当てられた限られたＩＰアドレスの範囲の中で「サブネット（sub network）」という技術を使い、グローバルアドレスの配下に内部ネットワーク（ＬＡＮ）だけで遣り取りをするためのプライベート空間を作っているのが一般的です。 「sub network」とは文字通り、大きな（Gloval＝外部に直接開かれた＝ＷＡＮ）ネットワークの中の小さな（Private＝ローカル内だけで通用する＝ＬＡＮ）ネットワークであり、ルータの配下に存在するホスト（ＰＣ）は「サブネットマスク（マスキング）subnet mask(ing）」という技術で、管理者によって任意のプライベートアドレスを割り振られる事になります（サブネット化の説明をすると、とても１０回程度のシリーズには収まりきらず、また企業や公共施設など大規模なネットワークの管理者には必須の技術ですが、個人ユーザーには殆んど不要のため、ここでは敢えて触れません） サブネットマスクの「マスク＝mask」とは、顔を覆う仮面などと同じ「外部から見えないように隠す」というような意味合いです。 今日、家庭環境の個人ユーザーにもブロードバンドが主流になるにつれ、これらの技術を応用して必要最小限の簡易機能を備えた「パーソナル・ルータ（ブロードバンドルータ）」が次々に登場しています。 ルータには非常に様々な働きがありますが、それを説明する前に・・・ まずは、もう少し身近なテーマから触れていきましょうか (￣ー￣)ﾆﾔﾘｯ 名前 コメント すべてのコメントを見る 7 ブロードキャストを理解する（前編） こんなものよりも、実は最も怖いのはＤＨＣＰの遣り取りが行われる一連の流れの中で、個人のプロファイルを覗かれる可能性がある点です。 ＤＨＣＰによって、ＰＣにＩＰアドレスが割り当てられる仕組みは、前回も述べたようにまず電源を入れたＰＣにネットワークの設定がしてあれば自動で、プロバイダのＤＨＣＰサーバーのスコープへＩＰを取りに行く事になりますが、その際に該当のＰＣがその正しいＤＨＣＰサーバー（加入しているプロバイダで設定されている）を見に行っているかの「端末の認証」が必要となるため、「ＤＨＣＰリクエスト（ＤＨＣＰ request）というものを出します。 その際に該当ＰＣに設定してある、各種の必要なデータを「カプセル化」してネットワーク全体に「ブロードキャスト（アナウンス）」します（ネットワーキングにおける「broadcast」とは、接続されている総ての端末に対し、相手を特定せずにデータを送る事を意味しています） その、カプセル化されたデータの先頭には「ヘッダー」という情報が入っており、そこにはＰＣに登録してある「個人プロファイル」と呼ばれるユーザーの色々な情報が入っていて、そのヘッダー情報の部分を読み取ってＤＨＣＰサーバーがリクエストを出してきたホストに対し、ＩＰを割り当てる対象か否かの判断する仕組みです。 こうして、世界中に開かれたネットワーク上をブロードキャスト（流されていく）データの中の個人情報は「ＯＳＩ 階層モデル（Open System Interconnection reference model＝開放型システム間相互接続）」で言うところの「レイヤ（layer）２」＝データリンク層＝となるため、通信の都度全ネットワークにデータが流れてしまう事になり、同じネットワークにいる第三者から読み取られてしまう危険性を孕んでいます。 このようにして流れていく個人情報をどうしても読み取られるのが嫌な場合は、これを防ぐ手立てとして「ＯＳＩ 階層モデル」の上位層である「レイヤ３」＝ネットワーク層＝を代表する機器である「ルータ」若しくは「ファイアウォール（fire wall）などを導入する必要が出てきます。 名前 コメント すべてのコメントを見る 6 「グローバルアドレス」と「プラーベートアドレス」（後編） 各ＰＣには、ネットワークカードに「ＭＡＣアドレス（Media Access Control Address）」という、固有のアドレスが付いています。 このＭＡＣアドレスの表記形式は、３バイト（24ビット）のベンダーコードと、３バイト（24ビット）のベンダーが任意で付けた管理コードとを併せた６バイト（48ビット）からなるアドレスで、管理者が自由に割り振る事の出来る「ｌogical（論理）アドレス」のＩＰアドレスに対し、ＭＡＣアドレスはいわば固有の製品番号のようなもので「physical（物理）アドレス」と呼ばれます。 ＭＡＣアドレスは、一般的には 00：11：22：AA：B9：C8 というように表記され（他の表記の仕方もあります）、ここから特定できる情報は精々ベンダー情報くらいのものでしょう。 これだけを見て端末を特定するのは、ＰＣ固有の型番から特定していくのと同じくらいに難作業といえ、一般的にはまずは不可能と言えます。 こんなものよりも、実は最も怖いのは・・・（次回へと続く） #自分が使用しているＰＣのネットワークカードに付いているＭＡＣアドレスの見方 「MS-DOSプロンプト」の画面から「ipconfig/all」（「config」はconfiguration＝構成の略）というコマンドを入力すると physical（物理）アドレス（または「アダプタ・アドレス」と表示される場合もあります） として ＩＰアドレス サブネットマスク デフォルトゲートウェイ ＤＨＣＰサーバ などの情報と一緒に表記されます #ＮＴＴの接続ツールなどをインストールしている場合やWindows98ME以前のＯＳのヴァージョンの場合は 「MS-DOSプロンプト」、またはスタートメニューの「ファイル名を指定して実行」から「winipcfg」を入力すると、「MS-DOSプロンプト」または接続ツールで表示されるなど、表記のされ方が異なる場合もあります） 名前 コメント すべてのコメントを見る 5 「グローバルアドレス」と「プラーベートアドレス」（前編） さて、前回も触れたように「ＩＰアドレスを抜く」方法としては「ping」というツール（コマンド）を使う事で、素人でも比較的簡単に対象のホストを特定する事が可能です。 もっとも、こうして行った特定自体が実効性を挙げるのは、対象が固定ＩＰ（fix）として使用している場合で、ＤＨＣＰの場合は前にも記述したように、接続を切る都度やプロバイダの設定しているリース期間が切れる度に、以前とは違うＩＰアドレスが割り当てられているため、あまり実効性があるとは言えません。 グローバルアドレスの場合は、前回も述べたように世界中のネットワーク上に共通する特定の住所のようなものであり、従って世界中のどこからでもpingを飛ばす事によって、ルート上にあるホスト等を経由して対象のＩＰを特定する事が出来るのに対し、プラーベートアドレスの方は特定のセグメント上だけのプライベート空間に存在するものなので、Proxy Sever（代理サーバ）やＮＡＴ（Network Address Translation＝ネットワークアドレス変換装置）といった、セキュリティ機器の配下に隠されていて外部からは見る事は出来ません（但しサブネットなど、同一セグメント上に繋がっているユーザーからは、見る事が可能です） このように一般ユーザーレベルでの端末の特定はまず不可能ですが、実際には通信の記録自体は総てプロバイダのサーバには残っていますので、例えば名誉毀損などの犯罪紛いの書き込みなどをして、警察権力が介入してくるところまで行けば、該当する時間帯に使用されていた、該当するＩＰアドレスのログを調べる事により端末の特定まで可能な事は、かつてしばしば話題になっていた「２ちゃんねる裁判」などでもお馴染みです。 しかし当然の事ながら、プロバイダにしろモデムなどを提供しているＮＴＴにしろ、こうしたログやユーザー情報の管理は厳重に行っているため、これら公権力以外の外部に個人の情報が漏れる事は、まずないものと考えてよいでしょう。 実際のところ、ＩＰアドレスそのものを特定したところで、それにマッピングされているホスト（端末）名がわからなければ何の実害もありませんし、またプロバイダがそういった顧客情報を無闇に第三者に開示するわけもありません。 以上のような事から 「ＩＰを抜くぞ・・・」 などと息巻いて悦んでいるヤツなどは、大して恐れるには足りないと言えるでしょう。 それに比べれば 「端末を特定するぞ・・・」 という方が、脅し文句としてはまだしも幾分かは実効性があります。 では「端末を特定する」とは、どういう事でしょうか・・・？ 名前 コメント すべてのコメントを見る 4 ＩＰアドレスの「読み方」（後編） ＩＰアドレスの「.（ドット）」で区切られた単位は、それぞれ「オクテッド」と呼ばれます。 「１０.０.０.０」と表記されるＩＰv4のアドレスは「ドット付きオクテッド表記」と言われ、先頭から「第一オクテッド」～「第四オクテッド」と呼びます。 その名からも凡その見当は付くでしょうが、「グローバルアドレス」の方は世界共通の住所のようなものなのに対し、「プライベートアドレス」というものはグローバルアドレスの配下にある、ローカル（LAN＝Local Area Network内）なセグメント（segment＝一定の範囲、管理単位）だけでやりとりを行うためのアドレスです。 一般ユーザーが、プロバイダから割り当てられるＩＰアドレスはグローバルアドレスの方で、何故かと言えばＬＡＮ内だけでしか通用しないプライベートアドレスでは、インターネットなどに代表される外部（WAN＝Wide Area Network）へのアクセスが出来ないためです。 グローバルアドレスの方は、世界のインターネット上に共通する独自のアドレスであるため、理論的には世界中のユーザーが同じネットワークを共有しているインターネット上に晒されている事になります。 しかしながら、ＩＰアドレスだけを特定できたとしても、そこから分析できる情報は精々プロバイダと（プロバイダがドメインに地名などを使っている場合は）、大まかな地域くらいのものです。 そうしたＩＰアドレスの見方は先に述べた「クラス分け」を元にしており、先頭からの一オクテッド毎の数字の羅列からネットワークアドレスとホストアドレスを識別しながらプロバイダなどを特定していくわけですが、それを見分けるためには、そもそもＩＰアドレスを一括して管理しているNIC（Network Information Center）という機関（NICの大元は米国にあり、日本ではNIC配下のJP-NICが管理しています）から、どのプロバイダにどういった範囲のネットワークアドレスが申請されているのかを知っている必要があります。 さらに特定のプロバイダが（ＡＤＳＬなどであれば）、回線を提供しているＮＴＴ局単位といった地域毎にアドレスを纏めて割り振っているなどの条件を備えた上で、なおかつ同じプロバイダの加入者などでそれらに関する知識があれば大まかな地域の特定までは出来なくもないでしょうが、実際にはプロバイダ内部の人間以外にはそこまではまずわからないでしょう。 では、前回にも触れた「ＩＰアドレスを抜く」方法としては・・・ 名前 コメント すべてのコメントを見る 3 ＩＰアドレスの「読み方」（前編） ＩＰアドレスには「クラスＡ」から「クラスＥ」までの、５つの「クラス」（実際には、マルチキャスト用のクラスＤとテスト用のクラスＥは、特殊な用途以外では使用する事はありません）に分けられており、少し知識があればＩＰアドレスを見て、どのクラスのどの程度の規模のネットワークに属しているのか、或いは「グローバルアドレス」か「プライベートアドレス」かの違いくらいは、瞬時に見分ける事が出来ます。 プロバイダから割り当てられるグローバルＩＰアドレスがどのクラスに属するかは、以下の通りで識別出来ます。 ☆クラスＡのＩＰアドレス １.×.×.× から １２７.×.×.× ☆クラスＢのＩＰアドレス １２８.０. ×.× から １９１.２５５.×.× ☆クラスＣのＩＰアドレス １９２.０.０.× から ２２３.２５５.２５５．× グローバルアドレスが、世界共通の固有のアドレス（static＝静的アドレス）なのに対し、プライベートアドレスの方は管理者が自由に割り振ったり付け替えたりする事が可能な、動的（dynamic）なアドレスです。 プライベートアドレスは管理者が自由に付けることの出来るアドレスですが、グローバルアドレスとの重複を避けるため、プライベートアドレス専用で使用が可能なアドレスの範囲は、各クラスで以下の通りにあらかじめ予約されています。 ☆クラスＡ １０.０.０.０ から １０.２５５.２５５.２５５ ☆クラスＢ １７２.１６.０.０ から １７２.３１.２５５.２５５ ☆クラスＣ １９２.１６８.０.０ から １９２.１６８.２５５.２５５ このうち、ホストアドレスの末尾が総て「０」のアドレスは、どのネットワークかを示す「ネットワークアドレス」、またホストアドレスの末尾が総て「２５５」のアドレスは「ブロードキャスト（用）アドレス」として予約されているため、端末のＩＰアドレスとして割り振る事は出来ません。 「ネットワークアドレス」と「ホストアドレス」の見分け方は以下の通りです。 ☆クラスＡ（最も大規模なネットワーク） ネットワーク.ホスト. ホスト. ホスト（ホスト数最大１億６７７７万７２１４台） ☆クラスＢ（中規模のネットワーク） ネットワーク. ネットワーク. ホスト. ホスト（ホスト数最大６万５５３４台） ☆クラスＣ（最も小規模のネットワーク） ネットワーク. ネットワーク. ネットワーク. ホスト（ホスト数最大２５４台） 名前 コメント すべてのコメントを見る 2 ＩＰ入門講座（後編） ( ￣∇￣)ノ インターネットの掲示板などを見ていると 「ＩＰを抜くぞ！」 「ＩＰアドレスを調べて、端末を特定できるんだぞ！」 といった脅し文句をちょくちょくと目にする事がありますが、まず結論から言ってしまうとそうした行為は技術的には大して難しくはありませんが、あまり実効性はありません。 そもそもインターネットをするためには、加入しているプロバイダを通じてＩＰアドレスが端末に割り振られる訳ですが、大まかに言ってＩＰアドレスには「固定ＩＰ（Ｆix）」と「ＤＨＣＰ（Dynamic Host Configuration Protocol）」の２通りがあり、プロバイダから割り当てられるのはＤＨＣＰという形式の方です。 Ｆixというのは「固定（静的）ＩＰアドレス」という名称が示す通り、プロバイダから特定のＩＰアドレスを割り当てて貰い、接続の時には毎回その同じアドレスを使用して通信を行うのに対し、ＤＨＣＰの方は「動的ホスト構成（割り当て）プロトコル」という名称が示す通り、こちらはインターネットに接続する都度（より正確には、ネットワークの設定がしてある端末では電源を入れる都度）、ランダムなアルゴリズムによって、プロバイダのＤＨＣＰサーバに設定されている「ＤＨＣＰスコープ」と呼ばれる範囲の中から、ＩＰアドレスが自動的に割り当てられる仕組みとなっています。 従って通常はＰＣを再起動したり、電源を落としてしまえば次の起動時には前とは別のＩＰアドレスがＤＨＣＰサーバーから割り当てられる事になります（理論的には前と同じアドレスが割り当てられる可能性もあります。 その確率はプロバイダの規模などによっても異なるため、一概には言えませんが常識的には同じアドレスが割り振られる事はごく稀である、と見積もって差し支えないでしょう） このため、頻繁に接続を切っていればＩＰアドレスが特定が出来たとしても、設定されているリース期間切れによって直ぐに違うアドレスに変わっている事になりますが、最近は多くのユーザーがブロードバンドに代表される常時接続の環境で長時間接続を維持している事から、ダイアルアップ時代に比べればＩＰアドレスの特定がされやすくなっている事自体は事実とは言えます。 では、そもそもＩＰアドレスとは何かと言えば・・・ 名前 コメント すべてのコメントを見る 1 ＩＰ入門講座（前編） ( ￣∇￣)ノ 『10ちゃんねる』は、ワタクシの趣味を元にした10のちゃんねるで構成されていますが、元々ワタクシの専門分野はインフラ系の通信技術であり、ＩＴ王国アメリカでもその方面では最も有名なシスコシステムズ（Cisco Systems）社認定とマイクロソフト（Microsoft）社認定プロフェッショナルの肩書きなどを複数所有しています。 そうした事から、一時は 《Mr.にゃべっちのNetworkingグ入門講座》 といった、新たなちゃんねるを増設する事も考えましたが『10ちゃんねる』は趣味の場としてあくまで仕事とは切り離しておきたかった事と、そうしたカテゴリには常連さんを始め、ユーザーの関心があまり向かないのではないかという推測から、増設は見送る事にしました。 ところがある日、我が『10ちゃんねる』（別館）常連にして向学心旺盛な学生さんから、ＩＰアドレスに関連した質問のような書き込みがあり、それに対する返答のレスがかなり長文になってしまった事から、冗談で 「この返事だけで、充分『10ちゃんねる』１本分のボリュームがあるな・・・」 と言ってみたところ 「こういう話は結構、興味を持つ人って多いんじゃないの・・・？」 という返事が返ってきて、訊いてみると彼女の友人で 「ＩＰを抜くぞ！」 といった脅しに恐れをなして、某SNSを退会してしまった人がいるとの事でした。 ＩＴ業界とは別世界の住人たちにそうした認識が浸透しているとしたら残念な事で、そんな歪んだ先入観を一掃出来ればという思いと同時に、いつものように片手間で掲示板のレスを書いていたがために、改めて読み直してみるとかなりいい加減な説明をしている事に気付いたというような経緯によって、瓢箪から駒のようにして出来上がったのがこの一文です。 例によって、書いているうちに長くなってしまったために複数回に分割しての配信となりますが、これでも必要最小限の情報のみに抑えてあるつもりです。 内容的には通信技術の基本ばかりなので、その分野で仕事をしている方々には些か退屈な内容かと思われますが、それ以外の一般userの方々にはいずれも知っておいて損はないでしょうし、また基本知識として知っているつもりでもどこかに新しい発見があろうかと思われます。 名前 コメント すべてのコメントを見る -
https://w.atwiki.jp/asato/pages/252.html
There are many things that make software development complex. But the heart of this complexity is the essential intricacy of the problem domain itself. If you re trying to add automation to complicated human enterprise, then your software cannot dodge this complexity -- all it can do is control it. Domain Driven Design?, p. xvii ドメインは、限定されたエリア、もしくは関心のある領域のことを言う。 マルチパラダイムデザイン?, p.10 モデル 古典的なドメインエンジニアリングのモデルは、一般的には、SCV、すなわち、スコープ（scope）、共通性（commonality）、可変性（variability）に基づいている。本書では、これにドメイン間の関係（relationship）という次元を追加して、モデルを汎用的なものにする（SCV+R）。このことにより、可変パラメータ（parameters of variation）が汎化される。すなわち、可変パラメータは従来パラメータ化やマクロ置換を必要とするモデルに対するものであったが、それを完全性のより高いモデルに対して意味を持つものにするのである。 マルチパラダイムデザイン?, p. 3
https://w.atwiki.jp/scaled-wurm/pages/31.html
甲鱗ドメイン インベイジョン・ブロック構築で活躍した５色基本地形デッキ。 緑と青を中心に、様々なコントロール要素のカードを使用し、甲鱗のワームで勝利する。
https://w.atwiki.jp/playaholic/pages/20.html
携帯ドメイン docomo.ne.jp ezweb.ne.jp t.vodafone.ne.jp d.vodafone.ne.jp h.vodafone.ne.jp c.vodafone.ne.jp k.vodafone.ne.jp r.vodafone.ne.jp n.vodafone.ne.jp s.vodafone.ne.jp q.vodafone.ne.jp
https://w.atwiki.jp/0x0b/pages/88.html
PERSISTENT CLIENT STATE HTTP COOKIES CGIスクリプトのようなサーバ側コネクションにより、クライアント側に情報を保存させ、そしてそれを受け取るのに使うことができる一般的な構造 単純で永続的なクライアント側の状態を加えることによって、ウェブベースのクライアント／サーバアプリケーションの能力が大きく広がります。 概要 サーバは、クライアントにHTTPオブジェクトを返す際、クライアントに保持してもらいたい状態情報を送ることができます。"状態オブジェクト"には、その状態が有効であるURLの範囲の記述が含まれています。その範囲に入るクライアントからの以後のHTTPリクエストは、クライアントからサーバに戻る状態オブジェクトの現在値の転送を含むでしょう。"状態オブジェクト"は、クッキーと呼ばれます。クッキーという名には、これといって大きな理由があるわけではありません） この簡易的なメカニズムは、ウェブベースの環境のためにパワフルな新ツールを提供します。それは、新しいタイプのアプリケーションのホストに実装されることを可能にします。ショッピングアプリケーションでは、その時点で選択されている商品に関する情報を溜めることができます。料金サービスでは、ユーザーの登録情報を送り返すことができ、ユーザーは次に接続するときには、ユーザーＩＤを再度打ち直す必要がありません。また、クライアントにユーザーごとの好みを溜めることができ、サイトに接続するたびごとに、ユーザーの好みを表示させることができます。 仕様 HTTPヘッダーの一部としてSet-Cookieヘッダーを含めることによって、クッキーをクライアントに設定することができます。主に、CGIスクリプトによって生成されることになるでしょう。 Set-Cookie HTTP 応答ヘッダーの文法 これは、CGIスクリプトが、クライアントに設定したい新しいデータを、HTTPヘッダーに加えるのに使うフォーマットです。この設定したデータを今後、サーバ側で読み取ります。 Set-Cookie NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure NAME=VALUE ここには、セミコロン、カンマ、スペースを排除した文字列が入ります。セミコロン、カンマ、スペースが含まれるようなデータを設定する必要がある場合には、URLエンコードのような何かしらのエンコードが推奨されます。ただし、エンコード自体は、まったく定義されているわけではありませんし、要求されるものではありません。（日本語を扱う場合には、URLエンコードをする必要があります。） Set-Cookieヘッダーには、この属性は必ず必要です。その他の属性は必須ではありません。 expires=DATE expires属性には、クッキーの有効期限を定義する日付の文字列を設定します。一度、有効期限に達すると、クッキーはクライアントに保存されません。もしくはクライアントからサーバに送信されません。 日付文字列のフォーマットは以下のとおりです。 Wdy, DD-Mon-YYYY HH MM SS GMT これは、RFC 822, RFC 850, RFC 1036, RFC 1123に基づいています。ただし、法定タイムゾーンは、GMTのみです。また日付の各要素間は、ダッシュ（「-（ハイフン）」のこと）で区切られなければいけません。 注意 Netscape Navigator version 1.1 以前ではバグがあります。クッキーに、path属性が明示的に"/"と設定されないと、セッション間で、expires属性が適切に保存されません。 domain=DAMAIN_NAME クッキーリストから有効なクッキーを探す際、リクエストするURLのホストのドメイン名を使って、クッキーのdomain属性の比較が行われます。もし、ドメインが後方一致した場合には、pathマッチングを行い、クッキーを送信すべきかを判別します。"後方一致"とは、domain属性が、ホストの完全修飾ドメイン名（Fully Qualified Domain Name）の尾部に対して一致したということです。たとえば、"acme.com"のdomain属性は、"anvil.acme.com"というホスト名に一致しますし、"shipping.crate.acme.com"も同様に一致します。 特定されたドメイン内のホストだけは、一つのドメインに対してクッキーを設定することができます。そして、ドメインは、".com", ".edu", "va.us"のような形式のドメインを除いて、ドメイン名の中に少なくとも２つか３つのピリオドを含んでいなければいけません。以下に示す７つの特別なトップレベルドメインに含まれないドメインのうち、いくつかは２つのピリオドが必要となり、それ以外のドメインは、少なくとも３つ必要です。７つの特別なトップレベルドメインは、次のとおりです。："COM", "EDU", "NET", "ORG", "GOV", "MIL", "INT"（Cookieの仕様が作成された時代は、7つのドメインだけでしたが、現在は、汎用ドメインも使われるようになり、この限りではありません。） domainのデフォルト値は、クッキー応答を生成したサーバのホスト名です。 path=PATH path属性は、クッキーが有効なドメインのURLのサブセットを特定するのに使われます。クッキーがあるdomainにマッチすると、URLのパス名の要素がpath属性と比較されます。そして、一致したなら、クッキーは有効とみなされ、URLリクエストと一緒に送られます。"/foo"というパスは、"/foobar", "/foo/bar.html"に一致します。"/"というパスは、もっとも一般的なパスです。 もし、pathが特定されていない場合は、クッキーを含んでいるヘッダによって記述されているドキュメントと同じパスとみなされます。 secure もしクッキーがsecureとマークされていたなら、そのクッキーは、ホストとの通信チャネルが安全なチャネルの場合にのみ送られます。現在においては、secureクッキーは、HTTPS(HTTP over SSL)サーバのみに送られる場合を意味します。 もし、secure指定がない場合には、クッキーは安全とみなされ、安全でないチャネルを通して明文で送られます。 Cookie HTTP Request Headerの文法 ブラウザーは、HTTPサーバからURLを要求する際に、保持しているすべてのクッキーに対してそのURLを検索します。そして、もし一致したなら、すべての一致したクッキーの name/valueペアーを含む１行をHTTPリクエストに含めます。フォーマットは以下のとおりです。 Cookie NAME1=OPAQUE_STRING1; NAME2=OPAQUE_STRING2 ... 補足 一つのサーバ応答に対して、複数のSet-Cookieヘッダーを発行することができます。 同じパスと名前のインスタンスは、優先する最後のインスタンスにお互い上書きされます。パスが同じで名前が異なるインスタンスは、付加マッピングを追加します。 上位層にパスを設定すると、他の下位層のパスマッピングを上書きしません。もし与えられたクッキー名に対して複数一致しても、パスが異なれば、すべての一致したクッキーが送られます。（例を参照） expiresヘッダーによって、クライアントは、マッピングのパージ（浄化）がいつ安全になるのかを判別します。しかし、クライアントは、そうすることを要求されません。 もしクッキーの数が限界を超える場合においても、有効期限に達する前にクッキーを削除するかもしれません。 サーバにクッキーを贈る際に、下位層まで指定されたパスのクッキーは、その上位層までしか指定されていないパスのクッキーより先に送られなければいけません。たとえば、"name1=foo"で、パスが"/"のクッキーは、"name1=foo2"でパスが"/bar"のクッキーの後に送られるべきです。 クライアントが一度に溜めておくことができるクッキーの数には限界が存在します。これは、クライアントが受け取り保存するために用意されるべきクッキーの最小数の仕様です。 クッキーの数は、トータルでで300まで。 一つのクッキーにつき4KBまで。name と OPAQUE_STRING は、4KBまでの形式に結合されます。. サーバもしくはドメインごとに、クッキーの数は20まで。 （特定されたホストやドメインは、別々のエンティティーとして扱われ、各々（結合されたものではない）クッキーの数は20までということに注意してください。） サーバは、クライアントに、これらの限界を超えることがありうることを期待すべきではありません。300クッキー限度や20クッキー／サーバ限度を超えた場合、クライアントは、もっとも過去に使われたクッキーを削除すべきです。4KBを超えるクッキーに出くわした場合には、クッキーは、フィットするように切り取られるべきです。しかし、名前は、クッキーが4KB以下である限り、手を加えるべきではありません。 もし、CGIスクリプトからクライアントのクッキーを削除したい場合には、同じ名前で、過去の有効期限を持ったクッキーを返すことによって実現できます。パスと名前は、有効なクッキーを満了したクッキーに置き換えるために、正確にマッチしなければいけません。この仕様により、クッキーの発信元でなければ、クッキーを削除することが難しくなります。 proxyサーバがHTTPを受け取る場合、Set-cookie応答ヘッダーは、決して受け取るべきではありません。 もし、proxyサーバがSet-Cookieヘッダーを含んだ応答を受け取った場合には、たとえ、応答が304(Not Modified)か、200(OK)かどうかに関わらず、Set-Cookieヘッダーをクライアントに伝達すべきです。 同様に、もしクライアント要求がCookieヘッダーを含んでいる場合、クライアント要求は、proxyをスルーしてしまわなければいけません。たとえ、条件付のIf-modified-since 要求が作られたとしても。 例 クッキーの利用を説明するために、いくつかのやりとりの例を挙げます。 以下に掲載している例は、原文そのままですが、「有効期限」の西暦が下２桁となっています。しかし、実際には、４桁で定義する必要があります。たとえば、2001年であれば、「01」ではなく、「2001」とします。 例１ クライアントがサーバにドキュメントを要求し、サーバから以下のレスポンスを受け取る。 Set-Cookie CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23 12 40 GMT 次に、クライアントがこのサーバ上のパス"/"のURLを要求するとき、クライアントは以下のCookie情報をサーバに送る。 Cookie CUSTOMER=WILE_E_COYOTE 再度、クライアントがサーバにドキュメントを要求し、サーバから以下のレスポンスを受け取る。 Set-Cookie PART_NUMBER=ROCKET_LAUNCHER_0001; path=/ 次に、クライアントがこのサーバ上のパス"/"のURLを要求するとき、クライアントは以下のCookie情報をサーバに送る。 Cookie CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001 次にクライアントが、サーバから以下のCookie情報を受け取ったとする。 Set-Cookie SHIPPING=FEDEX; path=/foo クライアントがこのサーバ上のパス"/"のURLを要求するとき、クライアントは以下のCookie情報をサーバに送る。 Cookie CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001 クライアントがこのサーバ上のパス"/foo"のURLを要求するとき、クライアントは以下のCookie情報をサーバに送る。 Cookie CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001; SHIPPING=FEDEX 例２ 例１からのすべてのCookie情報のマッピングは、クリアされたと仮定します。 クライアントがサーバから以下のCookie情報を受け取ります。 Set-Cookie PART_NUMBER=ROCKET_LAUNCHER_0001; path=/ クライアントがこのサーバ上のパス"/"のURLを要求するとき、クライアントは以下のCookie情報をサーバに送る。 Cookie PART_NUMBER=ROCKET_LAUNCHER_0001 次に、クライアントがサーバから以下のCookie情報を受け取ったとする。 Set-Cookie PART_NUMBER=RIDING_ROCKET_0023; path=/ammo クライアントがこのサーバ上のパス"/ammo"のURLを要求するとき、クライアントは以下のCookie情報をサーバに送る。 Cookie PART_NUMBER=RIDING_ROCKET_0023; PART_NUMBER=ROCKET_LAUNCHER_0001 注意 "/ammo"マッピングに加えて"/"マッピングの継承によって、"PART_NUMBER"と名づけられた二つの name/value のペアーが存在します。
https://w.atwiki.jp/whois/pages/20.html
ムームードメインでドメインを取得しよう! ムームードメイン ムームードメイン ドメイン業者を紹介しています。 『 ムームードメイン 』では、世界で一つしかないあなたのドメインを年額580円～の低価格で提供させていただきます。 初心者の方にも安心してドメイン管理ができるように、よくある質問やお問い合わせフォームも用意しております。 一番安いドメインだと年間５８０円から！ 全２８種類のドメインからあなたにぴったりのドメインが見つかるはずです。 自動更新機能あり まとめて移管機能あり ドメイン 取得料金 備考欄 co 2,880 / 年 us 580 / 年 co.uk 693 / 年 org.uk 693 / 年 com 950 / 年 net 950 / 年 org 950 / 年 biz 950 / 年 info 950 / 年 mobi 1890 / 年 in 1,950 / 年 me 2,290 / 年 cc 2,880 / 年 bz 2,880 / 年 nu 2,880 / 年 com.cn 2,880 / 年 net.cn 2,880 / 年 org.cn 2,880 / 年 cn 2,880 / 年 ws 2,940 / 年 jp 2,980 / 年 tv 3,480 / 年 vc 4,180 / 年 la 4,180 / 年 cx 4,880 / 年 日本語.jp 1,250 / 年 日本語.com 950 / 年 日本語.net 950 / 年 日本語.biz 950 / 年 この機会に是非、ムームードメインで独自ドメインを取得してみてはいかがでしょうか！ ドメイン取得費用と移管費用は異なります。 ホームページ上の情報の内容の正当性、有効性、正確性について保証するものではありません。 当該情報に基づいて被ったいかなる損害についても、ドメインナビは一切の責任を負いかねます。 データベース 比較 格安 価格表
https://w.atwiki.jp/nether/pages/17.html
【wiz】ネザードメインpart1【wiz】 【wiz】ネザードメインPart2【voda/docomo】 【wiz】ネザードメインPart3【voda/docomo】 【wiz】ネザードメインPart4【voda/docomo】 【wiz】ネザードメインPart5【voda/docomo】 【wiz】ネザードメインPart6【voda/docomo】 【wiz】ネザードメインPart7【SoftBank/DoCoMo】
https://w.atwiki.jp/nino-add-up/pages/64.html
ドメイン取得 目的 自分のホームページアドレスをわかりやすいＵＲＬにしたり，メールアドレスを好きなように設定したりすること． 取得方法 基本的には，仲介業者がいくつか存在するのでそこから選択することになる． ただし，レンタルサーバと同時に扱っているものも多く，同時に申し込めば割引もあるようなので総合的に検討が必要． 個人でのサーバ管理は面倒なようなので，今回は無視． ドメイン取得業者 お名前.com ＝ インフォシークドメイン ムームードメイン VALUE DOMAIN バリュードメイン Yahoo!ドメイン gonbei.jp スマイルサーバ SAKURA Internet ジャパンレジストリ どめいん屋ねっと DanRegister RegisterAPI Network Solutions Register.com dotster などなど，まだまだ多くの業者があります・・・． 業者の選択 多くの業者がある中で，選ぶポイントはやっぱり値段．てことでバリュードメインかな～という感じです．ドメイン取得（http //ドメイン取得.ws/）（ -リンクが貼れない・・・）というサイトには，代表的な国内業者の比較が行われているが，やはりバリュードメインが安そうなのでこれでほぼ決定？ ＵＲＬの候補 ＵＲＬは，ブラウザ開いてとりたいＵＲＬを入力するのではなくて業者のサイトに検索窓があるのでそれを利用する．例えば，お名前.comであれば，検索窓にほしいＵＲＬを入力して検索するだけ．結果で○が出れば取得可能． [PR] メールフォーム
https://w.atwiki.jp/sevenlives/pages/1926.html
クロスドメイン・アクセス? Same-Originポリシー 非同期通信? XMLHttpRequest