校内LANの整備は、必然的にインターネットと高専教育を直結させる役割を果たしました。脇山助教授の言葉を借りれば、「校内LAN整備の副作用として、全ての国立高専が自助努力によってインターネットに接続された。｣ということになります。
'95年度「高専LAN調査検討プロジェクト：最終報告書」において、脇山仙台電波高専助教授は「インターネットを利用することで、高専の教育・研究のアクティビティがどのような変化をみせていくのか、非常に興味深いものがある。」と述べています。
前章までの報告で、私たちはインターネットなしでは実効的な高専教育が行えない状況が生まれつつあることを報告してきました。
'97年1月25日、高知高専で行われた「インターネット活用技術研究会」において脇山仙台電波高専助教授は高専のインターネットの状況を 「高専のインターネット接続をめぐる状況と全国高専電子ニュースの運用について(http://majesty.info.sendai-ct.ac.jp/~wakiyama/Kouchi97/Presentation/sld001.html)」の中で「SINET問題」について報告しています。
「SINET問題」とは簡単に言えば、「SINET内は十分速いが一歩外に出ようとすると、とたんに遅くなる」問題のことで、
という問題点のことです。
本プロジェクトは脇山助教授の指摘に沿って、国外的、国内的な問題点を検討しました。この章ではこうした問題点に関して、インターネットと高専教育の実効性についての報告を行います。
沼津高専からWhiteHouseにaccessすると到着するのに、16の経路を通っています。Tracerouteで、目標のURLを入力すると、そこまでの通過経路と時間が表示されます。Tracerouteは「目標のsiteにaccessする経路状況」を調査する場合、利用できます。なお、WindowsNTにはtraceroute機能がついています。
64kbps という回線速度は「最低レベル｣の接続条件です。回線速度の問題は大きなneckになっています。しかし、それでも、条件によりますが、1時間に20MBくらいの情報は動かせます。full speedで、8KB/secですから、まあまあに動くときがあります。
一方、回線速度が上がれば、何もかもウマクいくかというと、そんなことは有り得ません。「早い回線速度を有効に使える能力」が問題です。
| 231 個 | 5,048,554 | |
| 40 個 | 3,279,632 |
即ち、271個のfile(文書fileと画像file;約8MB)を回収し、8:54に回収dataのcheckを終わり、いま報告のmailを書いています。mouseとkeyを動かした回数が、271x3=813回くらいです。まあまあにInternetが動いています。
sinet-admin での話ですと、米国(とそこを経由する)サイトからのファイルの転送に失敗する(ftp や http のコネクションが切れる)のは、パケットロスの多発が原因で起こるといことです。国内では、それほど多くのパケットロスは起きていないはずな ので、国内サイトからの転送が途中で失敗することは稀だと思 います。
現在、SINET の調査では、Sprint-link(SINET日米回線の米国側回線業者)のバックボーンに問題があるということで、原因調査、対策を依頼しているようですが、最近の pingの log をみても、依然として改善されていないようです。
国内の場合に、小さなfileはいいのですが、大きなfileは失敗する確立が高くなります。特に、夕方の時間帯に多いと思います。また、SINETのsite間でのfile回収率は高いのですが、違うNetwork間では遅かったり、回収率が悪いことがあります。
Internetやintranetに幻想を抱かず、着実に現状把握する必要があります。問題は単純に「回線速度」に帰着できるほど単純ではありません。
64Kbpsの改善(回線速度のup)は必須条件ですが、いまの課題として、例えば、file転送が、学内LANの場合にどうなのか、相手に確実に届くようなpage作りの技法・工夫はどうなのか？などなど。具体的な課題として、調査・検討・改良すべきものを明らかにする必要があります。
こちら(UCLA)からたまにですが、沼津高専内の Web サーバにアクセスしたり、telnet で研究室のサーバに入ったりしていますが、日本の日中のアクセスの遅さは酷いものです。これを、少し定量的に調べてみようとふと思いたって、ping というコマンドを利用して、３週間程前からデータを取り始めました。
以下に現在までの統計データを示しますが、数字が続きますので、先に結論を一言で言ってしまうと、多くの方が実感されているように、 「沼津 - 横浜間の回線速度はパンク状態(まともに使える環境にない)で、学外回線速度のアップが急務である。」ということです。
ここでは、横浜国大と沼津間の専用回線の通信が、インターネットへのアクセスに対して、どの程度ボトルネックになっているかを示すために、UCLA から 沼津高専の入口のルータまでと、UCLA から横浜国大にある沼津高専への接続を行っているルータまでの、パケットが行って帰ってくる時間を調査しますた。
以下、統計データを示し、簡単な解説を加えます。
--------------------------
手法： ping コマンドで、１時間に１回 64byte のパケットを 10パケット送り、その応答時間を計測した
サンプリング期間： 10月28日18時(JST) 〜 11月21日9時(JST)
・ UCLA - 沼津高専インターネット接続ルータ間の統計
1 Total statistics
| Mean (ms) | Max (ms) | Min (ms) | Standard Dev.(ms) | Packet loss(%) |
| 714.885 | 9333.025 | 70.601 | 1053.687 | 26.486 |
2 Weekday-Daytime statistics (Mon to Thu, 9:30-20:30)
| Mean (ms) | Max (ms) | Min (ms) | Standard Dev.(ms) |
| 983.034 | 9333.025 | 200.395 | 1372.523 |
3 Weekday-Nighttime statistics (Mon to Thu,21:30-8:30)
| Mean (ms) | Max (ms) | Min (ms) | Standard Dev.(ms) |
| 474.864 | 6089.792 | 122.928 | 679.557 |
4 Holiday-Daytime statistics (Sat and Sun, 9:30-20:30)
| Mean (ms) | Max (ms) | Min (ms) | Standard Dev.(ms) |
| 1105.377 | 9059.717 | 70.601 | 1566.705 |
5 Holiday-Nighttime statistics (Sat and Sun, 21:30-8:30)
| Mean (ms) | Max (ms) | Min (ms) | Standard Dev.(ms) |
| 471.292 | 5254.199 | 199.951 | 724.284 | <
6 Hourly statistics(hour/time(ms))
| 18H/ 855.0 | 19H/ 745.0 | 20H/1238.3 | 21H/ 713.4 | 22H/ 679.0 |
| 23H/ 493.8 | 00H/ 461.3 | 01H/ 512.1 | 02H/ 310.8 | 03H/ 508.0 |
| 04H/ 492.6 | 05H/ 388.8 | 06H/ 372.3 | 07H/ 474.8 | 08H/ 381.4 |
| 09H/1475.0 | 10H/ 705.8 | 11H/ 868.7 | 12H/ 655.5 | 13H/1406.2 |
| 14H/ 692.2 | 15H/ 589.5 | 16H/1464.7 | 17H/1523.0 |
・ UCLA - 横浜国大の(沼津高専への)接続ルータ間の統計
1 Total statistics
| Mean (ms) | Max (ms) | Min (ms) | Standard Dev.(ms) | Packet loss(%) |
| 196.575 | 1091.630 | 60.196 | 101.442 | 24.982 |
注) 時間(hour)はいずれも日本時間です。
----------------
横浜国大までの応答時間は、標準偏差の値からわかるように、その応答時間は時間帯によらずほぼ一定で約 200ms です。したがって、全期間の統計値のみを示しました。(この 200ms という応答時間のほとんどは、SINETの日米回線間の往復に費されています)
一方、沼津高専の全期間の平均は約 700ms で、その間だけで、500ms の時間を要しています。ただし、標準偏差をみてわかるように、応答時間は時間的に非常に激しく変動していることがわかります。
平日(祝日を含む)と土日のデータ(2〜5)では、それほど大きな差はみられませんでした。これはちょっと以外でした。土、日も学生や教官が出て来て結構使っているのかな？
平日、土日に関わらず、昼から夜の時間帯(午前９時から午後８時)でのレスポンスが深夜から早朝(午後９時から午前８時)にかけてと比べて特に悪く、日中の平均応答時間は、ほぼ１秒です。
時間帯毎のデータ(6)から、午前９時以降と午後８時を境にレスポンスタイムが急に悪くなることがわかります。また日中の時間帯でも時間によってかなり応答時間に差があるのがわかります。
パケットロスが、横浜国大までと、沼津高専までとで、いずれも約 25% 発生していますが、これは、sinet-admin で報告されているように、日米回線(正確ににはSprint-link の日米回線をつなぐバックボーン)で発生しているものです。
応答時間とファイルの平均転送速度の関係は以下のようになります。
ping の応答時間とは、相手先のマシンにリモートログインしたときのキーレスポンスの時間にほぼ対応します。この平均１秒の応答時間という数字はとんでもなく悪い数字です。コンピュータのキーをたたいて、１秒待たないとレスポンスがない(画面に打ったキーが表示されない)のですから！
またこの数字は、 WWW で学外のサイトにアクセスしたときの、応答待ちの時間に対応する場合もあります(相手サーバのレスポンスがボトルネックになっていないとき)。
ネットワークの実質的な速さを示す基準に、応答時間とは別に、「ファイルの平均転送速度」があります(Netscape などでファイルをダウンロードするときも表示されるのでこちらの方が馴染み深いかと思いますが) 。
沼津 - 横浜国大の回線速度は、64kbps = 8Kbyte/s ですので、これがこの間のファイルの最大転送速度になります。深夜または明け方、少し大きなファイルをダウンロードしたとき、これに近い数字をみたことだあるのではないかと思いますが、通常はこんな速度はでません。
インターネット上では、ファイルが 50byte 〜 1.5Kbyte に小さく切り刻まれて送られているのですが、その１つのパケットが転送されている瞬間は、ほぼこの最大速度 1.5kbyteで送られています。
それにも関わらず、平均転送速度が 20byte/s(160bps)なんてことがあるのは、そのほとんどを切れ切れにされたパケットを送る「順番待ち」の時間に費されているからです。この切れ切れにされたパケット１個１個の(往復の)順番待ちの時間が、今回示した「応答時間」に相当します。
簡単な計算をしてみます。
20 Kbyte (HomePage の画像データが普通こんな程度でしょうか)のファイルが転送されてくるとします。
この転送に要する正味の時間は、20KB/(6KB/s) = 約 3 秒。
これが 1 Kbyte のパケットに分割されて転送されてきたとする(ftp だと最大1.5KB のパケットになるのですが http は定かなでなく適当です)と、20 個パケットにわけられるので、平均の待ち時間１秒(パケットがちゃんと送れたかどうかを確かめるパケットが帰ってくるのを待つのでこの場合も往復の待ち時間が必要)とすると、待ち時間の合計は、20 秒ということになります。で、合計で、23 秒ということになります。
体感的にこんなもんでしょうか。
それでで、このときの平均転送速度は、20KB/23s で、0.87KB/s ということになります。実際はこの 7〜8 割ぐらいでしょうか。
なお、ここで示したのは、UCLA から沼津高専までと横浜国大までの応答時間の統計ですが、それから示された沼津 - 横浜間のパケットの平均往復時間は、国内のサイトや沼津高専内から行っても基本的に変わらないと思っていただいて結構です(実際、沼津のホストからも同様なデータを取ってしらべています)。
---------------------------
この節での議論は
http://amagi.numazu-ct.ac.jp/info/netstat.html
にて報告しています。
正月にInternet accessしましたが、沼津高専LANはかなり快適に動いていました。要するに、一人で64kbpsを使い、日本のSINET siteが半休止(serverは動いているが、利用者が少ない状態)の場合には、快適な環境です。米国との間のpacket lossは時間帯によっては起こりましたが。現在、通常の場合では、沼津高専で、7時から22時の間に「一人で64kbps」ということはありません。22時から6時くらいの時間帯では、32kbps-64kbps(？)くらいになります。昨年度は、夜中には、かなり確実に64kbpsでましたが。
学内LANを考えるとき、「一人で64kbps」というのが基準だと私は思います。いまは、それが保障されていません。MBONEでは、1.5Mbpsと言われています。その意味では、沼津高専から外線経由で「同時講義」は行えません。
[klan2コメント]以上の症状・数字はちょっと異常です。traceroute でみてみたらバックボーンを越える通信のところで、異常に時間がかかっています。
実は２月１６日（日）あたりから、基幹部分で異様にネットワークが遅くなったようです。いつもの手順で今朝復旧しております。現在ＦＤＤＩインターフェースボードを新しいものと交換しており、恐らくそのせいで完全にはダウンしなかったのではないかと思います。現在ＮＥＣに報告して向こうからのレスポンスを待っているところです。詳しいことがわかり次第、また連絡いたします。
5月の保護者懇談会では3年生の保護者から学生の「外線接続したいと言う要望に、どう対処すればいいのか」と言う相談が3件ありました。4年生のクラスでは準備中の学生まで含めると24%がインターネット接続し、自宅・下宿から学内のNetworkにaccessすることになります。Internetでのボランテア活動やアルバイトを始めた者もいます。既に、「予想を超える(？)世界」に学生は移りつつあります。
ちなみに、一般的な外線接続条件は「1年で24000円、Homepageに8MB、Internetにaccess free」だそうです。
既に、「昼間は講義で顔を合わせ、夜はmailでの交信」という者が何人かいます。こうした学生からは、学内のmail serverにaccessできない。従って、自分のmailを読めないとい苦情があります。
[klan2コメント1］学生がメールサーバにアクセスできなくなるのは管理者のせいではなく、ほとんどの場合使用者側に問題があると思われます。
たとえば、サーバに接続していて、アプリケーションをきちんと終了させずにパソコンの電源を切るだとか、メールのsubujectに特殊記号を使っているとかいった理由だと思います。そういう時は管理者に言っていただければ、.popファイルを削除することでメールは使えるようになるはずです。現に何人かは申し出てきています。
[klan2コメント2]苦情の一番目は、「電子制御工学科の学生用サーバに学生用の何もかもがあり、十分機能できない」ことがあります。そこから出ている「mailerのこと」は、「混んでいる」ということでしょう。言い方を変えれば、「電子制御工学科の学生の要求が高い」のです。既に、「学生用のserverを複数にする」ことは、電子制御工学科内で、処置する方向で話が進んでいます。mailerに関しての二番目は、家・下宿から、mailを読むときの問題です。
「mailが貯まっている状態」で学生用サーバにaccessすると、POP３ serverはどっさりとmailを送るので、詰まってしまうようです。また、その後、「詰まり」が回復できたり、できなかったりしたようです。それが、.popファイルを削除することで、直ったとか直らなかったとか、Al mailだから駄目だったとか、NetscapeMailerならよかったとか駄目だったとか、...と議論(苦情)が続いています。
[klan2コメント3]POP3 serverは、(多分) 最も普及しているものだと思います。しかし、「POP3 serverのmail配送が効果的か？」という問いかけをされた場合、返事に困ります。「dial upでaccessした場合、mailを全部貰う必要はなく、header(subject)を見て、必要なものを読めばよい」というのが学生の発想です。
それに関しては、IMAP serverが、最近、出ています。Netscape4.0では、supportされています。ちゃんとなるには、まだ、時間がかかりそうですが。逆に、IMAP serverにした場合、mailer(client side)でsupportされているかどうかという問題があります。このあたりのことは。卒研で、試験中です。
「苦情」を言っているのは、「'96年9月以来、WWW serverをはじめ、いろんなserverを十数回もset up, version upを繰り返し、MLも作り、...」という学生達です。「進化するInternetの最新level」から見れば、これからも、苦情(課題提起)は絶えないと私は思っています。
強いて言えば、「PCを設置したり、serverを設置したら、何とかなる」という発想では、学生の進歩に対応仕切れないという感想を私は持っています。
[klan2コメント4]学生が校内LANを自宅・下宿から利用する場合には民間プロバイダ経由です。民間プロバイダとSINET間の通信の事情は上のSINET−ADMINの情報のとおりかなり、きついと思います。同じ地区に住んでいながら、SINETにぶら下がった学校と民間プロバイダの自宅・下宿ではネットワーク上の距離が相当離れているという変な感覚ですよね。
インターネット回線を最低でも現在の６倍以上に上げる必要があると思いますが、どんなに高速化しても許容能力以上に情報を流すとパンクしますので、一定の節度というかモラルを考えていかないといけないと思います。この議論はネチケットの一つだと思います。そのうち、学生が学内ＬＡＮに本格的に参入してきますので、今のうちに議論しなければならない課題だとおもいます。
ネチケットにはいろいろありますが、最も基本となるのは、HomePageを発信したとき、どんなブラウザでも発信された情報をきちんと受け取れるようにする、発信者側の姿勢です。
klan2では、HomePageの「文字化け」を起こさないために、ホームページを作った際に＜HEAD＞＜/HEAD＞の間に、＜META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=x-sjis"＞または、＜META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-2022-jp"＞を必ず入れてください。と呼びかけました。本来は、jis-codeを使うのが望ましいのですが、Windows95ではs-jisを採用してしまっているので、s-jisでもやむをえないでしょう。
この呼びかけに対して、沼津高専の公式HomePageですら、すべてが、こうしたネチケットを守っているわけではありません。NetWorkの文化が始まったばかりであるために、こうした当たり前のマナーが実現されていないのです。ネチケットについては、根気強く呼びかけていく必要が有りそうです。
ここではネチケット紹介の一つとして、今使われている漢字codeを使う際に注意すべきこと、と「uni-code」について、簡単に解説します。
インターネット上で標準とされている日本語コードは、ISO-2022-jp,つまり７bit-jisです。
ISO-2022は、各国の標準化団体が作成した文字集合をきちんと分類して共存させ、利用するための仕組みです。ISO-2022-jpはこの規格に沿った日本語の文字コードを意味します。ただ、ISO2022の規格では、複数の言語を使う場合はそれに応じて文字コード表を取り合える必要があります。Netscapeなどで文字化けがおこるのはこのためです。そのため、現在ではヘッダー部にcharset=ISO-2022-jpと明示的に文字コードを書くことによって対処しています。
これとは別の流れで、世界中に存在する文字を全て一元化してまとめてしまおうという試みがあります。これが、Unicodeです。Unicodeが標準化されれば、いちいち文字コード表をとりかえなくてもすべての文字を表現できるようになり、文字化けの心配もなくなります。netscapeやjavaはすでにUnicodeを採用しています。
ところが、Unicodeは大きな問題があります。それは文字を16bitで表現しようとした事です。16bitで表現できる文字数は、65,536個です。そのうちUnicodeで日本語・韓国語・中国語に割り当てられた文字数は、約２万語です。旧字体を含めると日本語だけでこの数字を軽く突破してしまいます。つまり、全く足りません。それをむりやり縮小してしまっているために、中国語と日本語で形が違う漢字が同じ形で表現されてしまったり、旧字体が表現できなかったりとやっかいな問題が起こっています。というわけで、そう簡単には国際標準にはならないでしょうし、そのままでは韓国語・中国語に関しては使い物にならないでしょう。真の文字コードの国際化は32bitを採用した時に、初めて実現しそうです。
現状での文字コード表を以下に示します。
| MIME文字セット | 備考 | |
| 英語 | us-ascii | 米国英語 |
| iso-8859-1 | ラテンアルファベット1 | |
| x-mac-romani | ||
| iso-8859-2 | ラテンアルファベット2 | |
| x-mac-ce | ||
| 日本語 | iso-2022-jp | 日本語(7ビット JIS) |
| x-sjis | 日本語(シフトJIS) | |
| x-euc-jp | 日本語(EUC) | |
| ハングル語(韓国) | euc-kr | |
| iso-2022-kr | ||
| 中国語 | gb2312 | |
| gb_2312-80 | ||
| 中国語 | x-euc-tw | |
| x-cns11643-1 | ||
| x-cns11643-2 | ||
| big5 |