- - PR -
プロトコル
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-10-24 19:50
初めて書き込みします。
プロトコルの種類によって、優先的に処理を行うことがあると聞いたのですが ftpなどは、優先されずに処理をすると言うのは何かで読んだことがあるのですが 他のプロトコルはどうなっているのでしょうか？ 下の階層に行くほど優先処理されるのしょうか？ 知っている方、ご返答よろしくお願いします。 | ||||||||
|
投稿日時: 2002-10-24 23:09
「優先」というのは「HTTPはFTPよりも優先的にサービスを受けやすい」とかそういう意味でしょうか？多分、規格的にはプロトコル間での優先度はないと思います。RFCとかでも「このプロトコルはXXXプロトコルよりも優先される」なんて記述はまだ見たことないですねぇ。
ただサーバーアプリケーションやハードウェアによっては、HTTPアクセスを優先的に受けるなどの「配慮」をするのはあるみたいですね。
とはどう意味でしょうか？階層と言うのはOSIモデルのことですか？ | ||||||||
|
投稿日時: 2002-10-25 09:24
あとは、ルーターやスイッチになると、QoSの設定をして、プロトコルによって優先度を（設定者側が）変えるということができるので、そういうことかも知れませんねぇ・・。
（これは、プロバイダやネットワーク管理者の運用ポリシーによりますが） | ||||||||
|
投稿日時: 2002-10-25 13:31
お返事ありがとうございます。
言葉不足で申し訳ございませんでした。 >「HTTPはFTPよりも優先的にサービスを受けやすい」とかそういう意味でしょうか そのような意味です。 ことの発端としては、pingによってネットワークの状態を観察しようと 思ったのですが、ICMPを優先的に処理をされてはしっかりとしたデータ がでないのではないかと思い、ご質問させていただきました。 「ルータは優先プロトコル制御を行っているので、同時に２つの通信が流れてきた場合、 プライオリティの高いプロトコルを優先して処理します。 リアルタイム処理のプロトコルとバッチ処理のプロトコルでは、当然、前者が優先です。 要するに、ＦＴＰなどは後回しにされてしまうわけです」 以上のことは調べた結果わかっているのですが、その他のプロトコルは どうなっているのかと思いました。 階層のことですが、OSI階層のことです。 ご返答よろしくお願いいたします。 | ||||||||
|
投稿日時: 2002-10-25 16:14
１．
まず、アプリケーション層でのプロトコル(HTTP・FTP・SMTPなどなど)では仕様的な優先は無いと思います。途中のProxy(アプリケーション層)やゲートウェイ・ルータ（インターネット層）などで、Junbowさんの言われるように優先度を設定することは可能ですが、そういうものは管理者の設定によるか個々のハード・ソフトによる特殊な実装でしょう。
これは、はじめの一歩さんが使用しているルータの特殊な実装ではないでしょうか？後学のため、引用元を教えていただけると嬉しいのですが・・・。 ２． 確かにインターネット層において、ICMPデータ(Pingから)の方がTCP・UDPデータ(アプリケーション層プロトコルから)よりも優先的に扱われるような気がします。教科書を読んでみたのですが、優先度のことに関してはあまり言及していませんでしたので確認はとれませんが・・・。 ただ、ICMPのデータは通常TCP・UDPデータよりも小さい場合が多いと思うのでルータレベルでのパケットの分割・再構築が行われないため、優先的に扱われなくてもルータがさっさと送ってしまう可能性はあります。実際はどうなんでしょうねぇ。
どいうデータが欲しいか、どれだけの頻度でICMPデータを送り出すのか、各ICMPデータサイズなどなどによると思いますがそれほどの誤差がでるとは思いません。 ＃ネットワークの専門家ではないので間違っているかもしれません。「違うぞぉ」等あれば指摘してもらえると幸いです。 | ||||||||
|
投稿日時: 2002-10-26 13:58
ご返答ありがとうございました
引用元なのですが http://www.sandi.co.jp/saiyo/trouble/trouble_a.html です。プロトコルの優先で検索をかけて見つけました。 これに書いてあることからある程度判断しました。 何か意見がありました、ご指摘よろしくお願いします >どいうデータが欲しいか、どれだけの頻度でICMPデータを送り出すのか、 >各ICMPデータサイズなどなどによると思いますがそれほどの誤差がでるとは思いません。 レスポンスタイムで、トラフィックの測定を行おうと思っています。 pingのレスポンスで、確かなデータが取れると思いますか？ ご意見よろしくお願いします。 | ||||||||
|
投稿日時: 2002-10-27 06:35
「レスポンスタイムで、トラフィックの測定」と書かれていますが、 これは技術的には、何を測定したいといっているのでしょうか？ pingで分かるのは、送出したICMPのecho要求が相手のノードまで届き、 それが返送されてくるまでの時間です。回線の（平均的な）利用可能な帯域幅は、 データサイズをより大きくすれば、なんとなくは分かるようになりますが、 常に正確な値を知るというのは不可能だと思われます（データサイズが 大きくなると、何がどうなるのか、なぜ誤差が小さくなるのか、 どの程度の誤差があるのか、そもそもpingはどうやって動いているのか、 などを正しく理解してからお使いください）。 当方でも、インターネット回線の混雑の「目安」にするため（そしてプロバイダ に文句をいうため ^^;;）に、pingのデータを集めていたことがあります（今でも、 回線が遅いようならば、実行してますが）。 NTTのOCNエコノミーを使っていたときは、ある固定長のパケットサイズで、 www.ocn.ad.jp までのpingの応答時間を10分に一回程度測定し続けていました（ARPの誤差などを 除くために、複数回測定していました）。最短だと、たしか30msec 以下で応答が返ってきていましたが、ネットワークが混雑してくると（いわゆるテレ ホーダイタイムでは）、数百msecとか、それ以上（タイムアウト）になっていました。 このようなデータを何日分か溜めてからOCNに文句を言うと、そのうち上流の増速工事 が行われたりしていました。使い方によっては、このように役に立つと思われます。 （ただしこれで回線の正確な（利用可能な）帯域幅が分かるわけではありません。あくまでも 目安です。どのくらいの数値になると、どのような使い勝手になるのか、などが 分かっている場合にお使いください）。 ところで、以下の話は（他人事だから！？）面白いですね。
64kbpsのフレームリレー回線なのに、FTPで実測20kbpsしか出ていない、 調べると再送が多発している、原因はウィンドウサイズが大きすぎるかららしい、 対策としてウィンドウサイズを小さくした、という話ですよね（けれども本質的 解決には至っていないらしい）。 64Kbpsといえば、一般的な（普通はもっと速い？）インターネット接続回線 です。 この程度のFTP転送で、（たぶんTCPの）再送が多発するというのは ちょっと変だと思います。TCP/IPは、回線が遅ければそれにあわせてACKや タイムアウト値なども自動的に調整するので、再送が多発することはないので。 だから、原因はたぶん、「だれかが」勝手にIPパケットを捨てているから、というのが 本当のところではないでしょうか。だれかとは、（これまた推測ですみませんが）、 本社側のフレームリレーのルータ（とFTPホスト、もしくはそれらの間の回線のどこか にある、ルータやハブなどのネットワーク機器）ではないかと思われますが （要するに、処理しきれないほどのパケットが集中して、あふれた分が捨てられている）、 当事者じゃないので、詳細は分かりません。 この中に出てくる「ルータは優先プロトコル制御を行っているので……」ですが、 ルータにそのような設定をしていれば確かにそうですが、そうでなければ、間違いですね。 「ＦＴＰなどは後回しにされてしまうわけですね」ともありますが、これも設定次第 ですので、どのルータにでも普遍的に適用できる話ではないでしょう。 だいたい、FTPしか使ってないはずなのに、何に「後回しにされてしまう」のでしょうかねぇ。 ルータで言う「優先度」とは、パケットの処理を後回しにするのではなくて、 プロトコル別に使用できる帯域をあらかじめ決めておく、というのが一般的なはずです。 例えばリアルタイム通信は常に回線の30%以上確保し、それ以外はその残りを使う とか（この数値は適当です）。それを超えると、（通常の場合と同じように） 捨てられてたりするだけなので、後回しという言い方はちょっと変かも。 | ||||||||
|
投稿日時: 2002-10-27 14:24
皆さんありがとうございました。
おかげで、問題解決に至りました。 またなにかありましたら、よろしくお願いします | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。