Last update
ネットワークまわりをわけてみました。
ここでは、プロトコル解説が中心、のはずです。ネットワークの基礎的な説明はまだまだ不十分ですね。
インストール系は、Linux設定メモの方へまとめています。
おしながき
情報をどこから取ってくるか、どこへ送るか
情報家電と言われていますが、ピントはずれの機能ばかりがそろってきています。
何が必要で、何が必要ではないのでしょうか。ネットワークデバイス認証は、現在いくつかの実装がありますが、実用段階まで普及しているとはいえません。
情報家電でも、人との関係では操作するリモコン側、そして本体側というふうに分けることができます。
家電同士の接続は、AVケーブルの置き換えのような役割が主なところになると思います。
ネットワークに対応するには、人に対応する操作端末となるものが必要です。これは、PCや携帯電話となりますが、Webによる操作にするなどしても、共通のプロトコルが必要となります。Java Appletのように操作ソフトを家電からダウンロードし、Bluetoothのように個別の機器を認証して操作するという形体が最も考えられる形体です。そこまでできなければ、誰も興味を引くことはないでしょう。
複数の機器を操作するには、メッセンジャー形式がよいのかもしれません。相手が人ではなく家電製品になります。
Webサーバを備えるのか?
通信するには、ソフトウェアをクライアントとなるハードウェアに供給する機能が必要です。
通信には、相手が複数ある場合、1対1の場合などがあります。TCP/IPは、複数対複数の例です。RS-232Cなどは1対1の例です。複数対複数の中には、1対1の接続を作り出すためのプロトコルが存在します。
Google Talk などで採用されているらしいオープンな規格? XMLを使って通信だ。IETFにより標準化されている。
標準時にあわせるプロトコルです。
標準時は何種類かあります。
原子時計の時間と標準時。
標準時は、UTCとかGMTとかJSTとかいうあれです。
原子時計の時間(TAI)は世界標準時と少し違うようです。
協定世界時(UTC) = 国際原子時(TAI) + うるう秒(GMTにあわせるため)
グリニッジ標準時(GMT) = 協定世界時(UTC) ±1秒
日本標準時 = 世界協定時(UTC) + 9時間
緯度経度の計測方法をGPSにあわせたので、日本の子午線の位置が移動している。今まで正しくなかったのかのか?
RFC 1305
参考
メールの受信のときに使うプロトコルですね。
SMTPサーバを作ったので、ついでにこちらも実装してしまいましょう。
参考
RDFとかRSSとかいうものをWeb上で見るようになりました。これは、XMLで書かれています。
ドメインは、DNSサーバを指定して、そこから検索してきますが、その先はどうなっているのでしょう。
プロバイダに加入すると設定内容として資料に書かれているDNSサーバは、キャッシュDNSサーバというものです。
このほかに、各種役割を持ったDNSサーバがあります。
Javaから使うには、[JNDI]を利用します。
ドメインをクライアントから自動更新できる仕組み。Javaでは標準ではサポートされていない。
参考
Last update 2003.06.24
正式な日本語ドメイン(国際化ドメイン名)の仕様が決まりました。
Internationalizing Domain Names In Application (IDNA) というらしいです。
UNICODEをいろいろクライアント側で変換し、従来のASCII文字列としてDNSに問い合わせを行う方法。
半角を全角にしたりいろいろされた後、punycode だとかなんかという方法でACEエンコードされるそうです。
Mozilla では正式サポートされていない? Opera では古いRACE形式がサポートされています。
いろいろ複雑なようです。
RACEエンコードの場合はprefix といしてbq-- というのが使われていましたが、Punycode ではxn--がつくことになりました。
Punycode
英数字は変換なし。
http://もじら組.dev.jp/ というのを用意してみました。http://もじら組.jp/ もあります。
手順?
メールではクライアントがドメイン名をPunycode化するのでせう? サーバがDNSを引くときにはじめて変換するのでいいのかな?
Webでは? リンクURLはそのまま記述し、ブラウザが変換してHost:でも使うのかな・・・やDNS検索で使用でしょうね。
HTTPのhost: ヘッダなどは Punycode で記述しなければならないのかな?
Punycode は、UTF32 に対応しているのかな? RACEはUTF16だったからだめだったのかな。
参考
次世代ネットワーク機器の選び方をハード部屋に書いてみましょうか。
IPv6を使うためには、一部ハードウェアの対応と、OSの対応(APIの整備)、基幹ソフトウェア(サーバ類)の対応、アプリケーションの対応というようにさまざまな条件があります。
さて・・・各OSの対応状況なんていうのから見ないといけないですね・・・・。
Windows 2000 てくのろじーぷれびゅーで対応 (Windows2000 SP1必要)
SP3を入れてしまったあとにインストールしたいときにはどうすればいいのか謎
WindowsXPはSP1で正式対応?
Linux kernel 2.2 で対応 ? USAGI Project のツール等々が必要なようです。
RFC 4291,4864あたり。2005年以前のものは古い説明か。
EUI-64
下位64bitはMacアドレスを拡張したり。
24bit で2つに区切り、FFFFFFFE
アドレス
| IPv6 | bit | IPv4 | ||
| 未指定アドレス | 0:0:0:0:0:0:0:0/128 | 0.0.0.0 | ||
| ループバックアドレス | ::1/128 | 127.0.0.0/8 | ||
| グローバルユニキャストアドレス | 2000::/3 - E000::/3 (FF00::/8除く) | 001 | グローバル | |
| IANA 割り当て中 | 2001::/16 | |||
| 技術文書、記事、各種資料のための | 2001:0DB8::/32 | |||
| 一意ローカルIPv6ユニキャストアドレス | FC00::/7 | RFC 4193 | ||
| 管理組織による割り当てを実施する領域 | FC00::/8 | |||
| 独自割り当て領域 | FD00::/8 | 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 |
企業内などルータ超えてもローカル | |
| リンクローカルユニキャストアドレス | FE80::/10 | 169.254.0.0/16 | ルータを超えない | |
| サイトローカルアドレス | FEC0::/10 | 廃止 | ||
| マルチキャストアドレス | FF00::/8 | |||
| 既知 | FF00::/12 | |||
| インターフェースローカル | FF01::/16 | |||
| リンクローカル | FF02::/16 | |||
| サブネットローカル | FF03::/16 | |||
| アドミンローカル | FF04::/16 | |||
| 組織 | FF08::/16 | |||
| グローバル | FF08::/16 | |||
| 一時的 | FF10::/12 |
RFC 4864
ローカルアドレスは?
リンクローカルアドレス
fe80::
逆引きはできるのか?
ルールが初期の頃から変わってしまったようです。
勝手に生成されるらしい。その仕組みは?
上位数ビットがプロバイダから割り当てられます。
下位ビットは、各機器がMacアドレスなどを元にして自動生成します。
上位ビットの配布形式等々も決まっているような感じです。上位アドレスを配布するために従来のDHCPに相当するものがルータ等々で1つ必要なのですね。
Vine Linux で使うには
Vine Linux では、Module 形式で IPv6 サポートが組み込まれているようです。
ここが参考になるかな?
# insmod -s ipv6
で使えるようになります。
IPv6 FAQ
Linux
IPv6 FAQ/HOWTO
IPv6start.net (日経BP社)
IPv6 Related
Specifications
USAGI Project (LinuxのIPv6実装)
Kame Project (BSDでIPv6)
TAHI Project
Linux IPv6 Users
Group JP
FreeBSDは3.4以降のカーネルでサポートしているらしい?
Discovery Stage で認証等接続処理を行い
PPP Session Stage で通信をおこなう
参考
| データ | 解説 |
| パケット長 | パケットタイプ以降の合計の長さ |
| padding | padding からチェックバイトまでで8の倍数長になるようにランダムな値を詰める。 暗号化されていない場合は 0 |
| パケットタイプ | データの種類を示す。いろいろある。 SSH_MSG_NONE = 0 SSH_MSG_DISCONNECT=1 SSH_SMSG_PUBLIC_KEY=2 SSH_CMSG_SESSION_KEY=3 などなど |
参考
SIPは、IP電話などで使われている
Javaで200行程度のHTTPプロキシサーバを作ってみました。HTTPは、1.0と1.1があり、RFCにまとめられています。
プロキシと、通常のHTTP接続との違いは、URLにプロトコル、サーバ名が含まれるか含まれないかの違いだけです。プロキシ無しリクエストの一行目
GET /~siisise/ HTTP/1.0プロキシありリクエストの一行目
GET http://www.bekkoame.ne.jp:80/~siisise/ HTTP/1.0GETの部分は、GET/POST/DELETE 等があります。それぞれ、HTTPサーバに対するコマンドですが、普段はGETとPOSTぐらいしか使われていません。FTP等をプロキシするときは、DELETE等も使うのでしょう。
バージョンアップの要望がないようなので、内部で使おう・・・。
これを元にしてかどうかわかりませんが、Servletエンジンを開発します。
Last update 2000.2.3
FTPには、ファイルを途中から転送するというきのうがあり。
ライブラリ化すると便利なのかな・・・しなくても標準で使えるような。
インターフェイスはまだまだ工夫が足りない気がするかも。
TCP/IPは、インターネットで使われているプロトコルです。しかし、1つのプロトコルではなく、複数のプロトコルの集合だということか、大抵の解説書のはじめの方に書かれています。
TCPとIP,
UDPが主なところで、その上にhttpだとかftpだとかがあるわけですが、プログラムを作ろうとした時点で見えてくるのがSocketという関数やクラスにまとまったTCP層です。(UDPも使えますが)
| OSI的な分類(一部不一致) | |||
| アプリケーション層 | HTML等 | BIND/ICQ等 | |
| プレゼンテーション層 | HTMLやhttp | ||
| セッション層 | Proxy等 | http/ftp etc | DNS etc |
| プログラム的なつながり | API | Socket等 | |
| トランスポート層 | 接続プロトコル | TCP | UDP |
| ネットワーク層 | ルータ等/NAT/ドメイン? | IP/ICMP | |
| データリンク層 | スイッチングHUB等 | DIX/Macアドレス | PPP/HDLC |
| ソフト的つながり | デバイスドライバ | ||
| 物理層 | ハードウェア | Ethernet | モデム/ISDN等 |
まぁ、この図は、右と左を別々にみてください。正しい関係ではないですが、こんな感じになってます。
トランスポート層からデータリンク層までが、主にOSが担当する機能です。
Socketで相手マシンと接続すると、RS-232Cのように、無手順双方向通信が可能になります。それも、一つのバスで同時に複数のマシンとの通信が可能です。
ということで、IPがデータの固まりに付けられたアドレスを基に、マシン別にデータを送信します。TCPはさらにポート番号で同じマシン間の通信を多重化しています。エラー訂正や順序整理もTCPがこなします。
UDPは、トランスポート層的な機能をあまりもっていないので、ほんとうはネットワーク層的プロトコルです。
PCには、1台1台IPアドレスが割り振られていますが、このIPアドレスはネットワークを特定する部分と機器を特定する部分の2つに分けることができます。それぞれ、ネットワーク層、データリンク層と関係してきます。
ネットワークアドレスは、ネットワーク単位につけられる番号です。そして、ホスト番号は、マシンごとにつけられる番号です。これはネットマスクで分けることができます。
しかし、相手側のネットマスクなどは、わかりません。とりあえず、自分のネットワークのネットマスクだけがわかればいいです。ネットワーク内で、他のネットワークへの接続方法を知っているルータがありますので、自分のネットワーク以外のときは、そのルータに問い合わせたりします。デフォルト・ゲートウェイという指定をしているアドレスの機器がそれにあたります。PC内部でも、そういう情報を管理できます。
IPアドレス別に送信する相手を指定したものは、ルーティング・テーブルといいます。
IPのパケット | 送信元IP | 送信先IP | データ |
IPのパケットはネットワーク層を通ります。IPのパケットは、送信元のコンピュータから送信先のコンピュータまで、そのまま伝えられていきます。
ルータ、ルーティングテーブルなどなどは、ネットワーク層とデータリンク層を結びつけるものです。
データリンク層では、Ethernetの場合はIPのパケットに送信元、送信先のMacアドレスが付加されます。
Ethernetのパケット | 送信元Macアドレス | 送信先Macアドレス | IPのパケット |
ここで送信元、送信先に指定できるのは、LAN内(同じネットワーク内)のアドレスだけです。同じネットワーク内に対応するIPアドレスがない場合には、ルータなどにパケットを送ります。このとき送信先MacアドレスがルータのMacアドレスとなりますが、送信先IPアドレスは変わりません。
ルータまでパケットが届くと、ルータは送信先IPアドレスに対応する次の送信先を探し、送信先Macアドレスを書き換えます。送信元Macアドレスはルータのものになります。このときも、NATなどを使用していなければIPアドレスは変わりません。
接続経路はルータが決めるのですが、Unixや最近のWindowsなどではPCの中にも、ルータと同じようなルーティングテーブルを持っています。このため、最初にPC内のルーティング・テーブルを参照して、見つからなかったときにデフォルト・ゲートウェイで指定されたルータにおまかせをします。ルータが、別のルータを指定してくることもあります。この時の情報は、可変のルーティングテーブルに持たせます。このルーティングテーブルは、PPPなどで相手が1つではなく、LANのように複数の機器が接続されているような場合には、実装の程度は違っても、一応どの機器にもあるはずです。
PCがAネットワークとBネットワークに接続されており、AネットワークにA1Cルータ、A2Dルータがあり、Cネット、Dネットへとつながっています。BネットワークにB1Eルータ、B2Fルータがあり、Eネット、Fネットへとつながっていました。さてどのように経路を決めるでしょう。
最初にPC内のルーティングテーブルで、一致する物があるかどうかを探します。このルーティングテーブルには、AネットからFネットまでのルーティングテーブルすべてを登録しておくこともできますが、直接接続されていないネットワークの設定は、各ルータに任せることもできます。
PC内のルーティングテーブルに情報がみつかれば、対応するルータに対してパケットを送ります。見つからない場合は、デフォルト・ゲートウェイとして指定されたルータにパケットを送ります。
そのルータがパケットを中継可能であった場合は、そのまま中継を行います。他のルータが適しているという情報をルータが持っていた場合には、送信元のPCにその情報を伝え、PCが別のルータに情報を再度送ります。
PPPは、RS-232CやISDNといったところにIPパケット他イーサネット上のプロトコルを流すプロトコルで、rfc1661/rfc1662などを参考にするといいようで。
イーサネットからはじまったTCP/IP
現在では、PPP接続でモデムやTA/ルータでも使えているTCP/IPは、イーサネット(Ethernet)
複数のネットワークアドレスの混在
192.168.0.XXXと、192.168.10.XXXを同一Ethernet上に作ってみたり・・・。同じネットワークアドレス内では問題なく通信可能。
| Flag | Address | Control | Protocol | Information | Padding | FCS | Flag |
| 7Eh | FFh | 03h | 16bit | 16bit | 7Eh |
| プロトコル番号 | プロトコル |
| 0021h | Internet Protocol (IP) |
| 8021h | Internet Protocol Control Protocol (IPCP) |
| c021h | Link Control Protocol (LCP) |
あるPPPパケットの例 (LCPが含まれている)
ADDR +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F 0000 7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 34 7D 22 0010 7D 26 7D 20 7D 20 7D 20 7D 20 7D 25 7D 26 30 4D 0020 E4 4A 7D 27 7D 22 7D 28 7D 22 DB 7D 2A 7E
参考
参考文献
RFC1661 The Point to Point Protocol(
和訳もあるようです)
RFC1662 PPP in HDLC-like Framing( 和訳もあるようです)