1read 100read
2012年09月通信技術261: TCP/IPについてじっくり考えてみなか? (215) TOP カテ一覧 スレ一覧 2ch元 削除依頼
【3hop目】JANOG ML をマターリと観察する人の数 → (828)
自宅サーバー構築中 (409)
日本語.com ドメイン (275)
ネットワークエンジニアになりたいです part5 (810)
Tor: an anonymizing overlay network for TCP (282)
ネットワークエンジニアとセキュリティエンジニア (363)

TCP/IPについてじっくり考えてみなか?


1 :02/02/23 〜 最終レス :2012/04/06
みないか?

2 :
>>1
とりあえずネタ振ってください。

3 :
>>2
そうねえ、ちょっと待ってね。 今考えるから。

4 :
 一応、TCP/IPについて、論理的には理解してるわけだ。 けど、その実装
が全くもって分からないの。 OSと、このTCP、IP、UDP とかのプロトコルの
関係について、詳しい人っていますかね。 TCP、UDP、IP って、1つのプロセス
なの? それともデバイスドライバみたいに、もっと特別な位置ずけがされてるの
でしょうか?

5 :
>>4
プロトコルスタックの話?
実装は当然実装依存。特別な位置づけをしているかどうかはその装置とOSで
特別な位置にTCP/IPプロトコルスタックをおきたいかどうか、というお話。

6 :
この板あんま人いないねェ。 板の回転もマターリしてるし。

7 :
>>5
おお。プロトコルスタックか。 あらたな概念に遭遇したわ。
ちょっとインターネットで、調べてみますね。
 自分としては、デーモンみたいに常にメモリ上に常駐して、サービス
を提供するプロセスをイメージしてたんだけど、違うのね。 OSによって
システム内でのプロトコルの位置ずけは変わるってこと?

8 :
>>7
BSD系やLinuxはカーネル内にいます。
Windows系はドライバだよね。本質的には両者に差はないんだけど。

9 :
>>8
なるほど。 と言う事は、バックグラウンドで常に動作してるプロセスで
はなく、必要に応じてコールされる処理ルーチンって事なの? 

10 :
まぁ、プロトコルの処理自体は別にOSに依存しないので、
OSの都合(組み込み用とではプロセスモデルでないOSなんていっぱいある)と
性能とか多機能併用の都合とかで、どうとでもなると。

11 :
>>10
なるほど。 ってことは、OSや、ハードによって、プロトコル、特にTCPや
IPの位置ずけは違うって事? 自分としては、一般的なコンピュータ(PCとか
ワークステーション)上での実装が知りたいんですが。 色んなHP探したけど、
そういう突っ込んだ部分まで開設したHPって無いんだよね。 表面的な解説ば
っかりで。

12 :
まぁお前1はnetbsdを使えってこった

13 :
>>12
NETBSD? カッコよさそうね。 けど、今は新品のULTRA2でソラリス使って
んの。 遅いけど、やっぱいいねWSわ。 特に臭いが。

14 :
>>11
解説すると本1冊以上になります。
まぁオープンソースなOSのソースを読むのがいいのでは?

15 :
>>14
そうですか。 何かおすすめの書籍など、ありますかね。
やっぱり、RFC読むだけじゃ、理解はできないでしょ?

16 :
ネタスレと思いきや

17 :
*BSDのカーネルソースでも見るのが手っ取り早い。
PPPとかもいるし…

18 :
Solarisもドライバとしての実装だよね、確か

19 :
>>18
ドライバとしての実装って事は、カーネルコードに埋め込まれているって
こと? 間違ってるかもしれないけどドライバって、デバイスドライバで
すよね。 けど、デバイスドライバは、コンピュータに接続されてる周辺
機器に対応するもので、周辺機器から割り込みが発生したり、アプリケーシ
ョンがそのデバイスに対応するスペシャルファイルに入出力すると、OSから
自動的にコールされる処理ルーチンですよね? 

20 :
プログラム板
TCP/IPについて、じっくり考えてみないか?
http://pc.2ch.net/test/read.cgi/tech/1014428594/l50

ム板の者ですが、恥ずかしいですホント…通新技術板のみなさんどうもすみません。

>>1
お前の立てたスレの最後に参考になる書籍と雑誌名を書いといたから。とりあえず
ここで質問する前に「これは読んどけ」スレの過去ログくらい全部読め。話はそれからだ。なっ。

21 :
しかもIPさらしてるし。恥ずかしいのは自分じゃあ!!…それでは、失礼します。

22 :
>>19
ネットワーク屋なんで、Unixカーネルについてはほとんど無知なんだけど、かってに想像するとこんな感じ。
#激しく間違ってる可能性アリ
NICがフレーム受信→
カーネルのメモリ領域にいるNICのドライバ(L2)がL2ヘッダを削除してIPドライバ(L3)に渡す→
IPドライバがL3ヘッダを削除してTCPドライバ(L4)に渡す(フラグメントがあればパケットを再構成)→
TCPドライバは正常なシーケンスのパケットであれば、パケットをキューイング(異常があればエラー訂正や再送要求)→
RWINが埋まる、もしくはPUSHされるれば、データグラムを再構成してアプリに渡す→
アプリケーションはソケットを作ってデータグラムを処理する→
処理不能(ポートをリッスンしているプロセスが無い等)であればソケットが作れない旨をTCPドライバにかえす(TCPドライバはセッションをRSTする)→
こんな感じでは無いかと、、、
いずれにしてもカーネルメモリに存在しているのでは?
常駐しているユーザプロセスとは大分性格が異なるんでしょうけど、、


23 :

ヤフーオークションで、幻の人気商品、発見!!!
今は無き「コピーガードキャンセラー」↓
http://page.auctions.yahoo.co.jp/jp/auction/42757955
ヤフーオークション内では、現在、このオークション
の話題で、持ちきりです。

24 :
>>22
IPドライバがL3ヘッダを削除してTCPドライバ(L4)に渡す(フラグメントがあればパケットを再構成)→

BSDだと、L3でヘッダーとらないよ、L4でIPアドレス使うから。
いちいち疑似ヘッダーにしたりはしない
送信するときも、L4でIPヘッダーは一応つけるし

25 :
WinPCap は W2K では NDIS の仕様で WAN Apdapter のパケットを
キャプチャ出来ませんが、何か代替策はあるでしょうか?
WinPCap が無理と言うことは他のパケットキャプチャツールでも
無理なんですかね。WinDump も Analyzer も Ethereal もみんな
WinPCap を使っているし.....、何か無いかしら。
そもそも、NDIS の WAN側の制限ってどういう仕組みで発生することなんでしょうか?
W2K のネットワークアーキテクチャに強い方、教えてください。
一応 アプリ - TDI - プロトコルドライバ - NDIS - NIC という流れの
概念は理解しているつもりです。

26 :
age
age

27 :
http://www.geocities.co.jp/Foodpia-Olive/3480/

28 :
おおもりよしはる=ロリペドオタ、アニオタ、モーツアルトオタ、ベートーベンオタ、ブルックナーオタ、セガ信者
ひまわりとRのすじRに異様な執着心を燃やしているロリペド絵描き
2浪して九州大学歯学科に進むがプロのイラストレーターになるために大学を中退、
同人活動とUOに専念する日々を送るが、その生活は苦しいらしい(藁
自らを画家と呼び、ともすれば不真面目なものと見られかねないアニメ絵
それも、無毛のすじRすらも「芸術」の域にまで高めようとしている(らしい)。
心の支えは自分の描いたひまわりの絵らしい(ぷ
マスコミ(西日本新聞)で写真付きで取り上げられたこともあるらしい。
最強のネットゲーUOではIzumoでKanae、SASAWOというキャラを使用。
http://yasai.2ch.net/test/read.cgi/doujin/1021463865/
@さぽーる
http://www.sub-all.com/test/read.cgi/dojin/019473696/
@MEGABBS
http://203.138.109.168/cgi-bin/megabbs/readres.cgi?bo=Baby&vi=1020753024
関連スレ
【すじ】 ようじょのすじ  【すじ】
http://www2.bbspink.com/test/read.cgi/erog/1017041827/
【抱き枕】すじ丸出し抱き枕ってどうよ?
http://mentai.2ch.net/test/read.cgi/otaku/1016198191/
■■■ロリ絵?おおもりよしはる■■■
http://www2.bbspink.com/test/read.cgi/erodoujin/1016297545/
48: 柳さんトコの抱き枕カバーとかって・・・2枚買
http://comic.2ch.net/test/read.cgi/sakura/1019402459/
29 :あぼーん:あぼーん
あぼーん

30 :
お互い、DF bit 立てて通信している状況下で
片側がフラグメントさせてパケットを送ってきた場合、
受け取った側のノードは、
・ICMP Destination Unreachable(fragmentation needed and DF set)
 を返してパケットを受信しない。
・黙って破棄
・それ以外
のどれが正しいんでしょうか?

31 :
>>30
ああ微妙だねえ。要するに DF ビットが立った fragment が届いたって
ことだよね。fragment のヘッダは基本的に fragment 前の
オリジナルパケットのヘッダからDFフラグも含め
そのままコピーされる(RFC791)から
(check sumとか一部のヘッダフィールドは変化するけど)、
本来ならば DF が立っている fragment は存在し得ないわけだ。
しかし、エンドノードが reassemby を行う条件としては
DFビットは関係しない。少なくとも漏れの知る限り。
古き良き時代: 送信者は保守的に、受信者はリベラルに。
世知辛い現代: 疑わしきは逝ってヨシ。
ってとこかな。

32 :
>>32
> ああ微妙だねえ。要するに DF ビットが立った fragment が届いたって
> ことだよね。
そうなんです。
たちの悪い事に、fragment したパケットを出しているのが
自社のサーバだったりします。^^;
お家の環境は、「逝ってよし」なポリシーなので
自社のサーバにアクセスできなくなりました。^^;;;
NetScreen が間抜けなのか、設定者が間抜けなのか・・・。(鬱)

33 :
fragment化はルータの仕事だから、
サーバ自体の問題ではないと思う。
DFビットが立ってるパケットをfragment化する
変なルータがあるってことでしょ。

34 :
で、fragment化が起こるのは普通はMTUが変化するところだから、
たとえばVPNのエンドポイントとか、ADSLの入り口とか、
疑うべき点はサーバ以外にいろいろあると思われ

35 :
IOSでもIPsecとかやるときにDFビットを無視するオプションあるね

36 :
>>35
IPsecのとき、オリジナルIPパケットのDFビットを無視してIPsecパケットを
フラグメントすることはできるけど、そのときのouterヘッダにはDFビットを
立てないんじゃありませんでしたっけ。
だから、DFビットが立ったままフラグメントという状況は普通は無いはずなんですが
どうでしたっけね。手元にIPsec動作するのが無いのでうろ覚えですが。

37 :
便乗質問させてください。
普通のLinuxサーバはMTU1500になってますが、
BフレッツPPPOE,unnumberdでコレガのルータかまして、内部の(グローバル)
Linuxサーバを公開しているんですが、別のネットワークのクライアントで
到着パケットをみると「フラグメント」しているみたいなんです。
(1466+82という2つのパケットに分かれてます。)
LinuxはMAX1500のパケットを送り出しているが、コレガのルータが
それを分割してクライアントに送りつけるということでよろしいのでしょうか?
この状態はとくに異常なものではないのでしょうか?
その2番目の後続フラグメントパケットにはIPヘッダはついているけど、
TCPヘッダはついていません。つまり全部フラグが0と見られてしまうし、
送信先、送信元ポート番号もないので、この後続フラグメントパケットだけみると
「Nullスキャン」という解釈がされてしまうと思うのですが、どうでしょう?
識者の方、ご教授願います。
(おまえんとこからNullスキャン受けたと抗議殺到でマジで困ってます。)

38 :
>>37
http://www.ntt-east.co.jp/flets/opt/faq_03.html
ここのQ5

39 :
>>37
>その2番目の後続フラグメントパケットにはIPヘッダはついているけど、
>TCPヘッダはついていません。
IP層では、TCPヘッダーも単なるデータにすぎません。フラグメントパケットは
destinationにて組み立てられるから大丈夫よ。組み立てられてから、
IPヘッダーを取り除いてTCPパケットの中身を見るわけやね。
# ここって名前になにもいれないとダメなのね。

40 :
>>37
>(おまえんとこからNullスキャン受けたと抗議殺到でマジで困ってます。)
その侵入検知システムはフラグメントオフセットが0でないかどうかを、ちゃんと検査していないのかも
しれませんね。ところで、1466+82 の82の方のIPヘッダーのフラグメントオフセットは1446になってる?
(1446 = 1466 - IPヘッダーのバイト数)
あと、1466と82のIPヘッダーの識別子は同じになってる?

41 :
>>38
Q5.フレッツ接続ツール以外のPPPoEクライアントソフトウェア、
A5.ルータ等を使用するときに注意することはありますか?
フレッツ接続ツール以外でPPPoEクライアント機能を使用するとき、
MTUを1454Byte以下(MSSを1414Byte以下)に設定していただく必要があります。
MTU、MSSを上記の値以上に設定すると閲覧できないHP等がございます。
また、PPPoE対応のルータは、最新のファームウェアを使用することをお勧めします。
最新のファームウェアはお買い求めのメーカのHPにてダウンロードしてください
(ルータの場合はお買い求めのメーカのサポート窓口等にお問合せください)。
これでしょ?サーバ側って最初のsynでクライアントのmssを教えてもらうから、
それをもとに応答パケットを作成すると。しかし、サーバ側のPPPOEルータの関係
から、Linuxのデフォルト1500だと、もし、クライアントのmssが3000とか成っていた
として、んじゃ3000いっとく?という感じで、応答パケットを作成すると、
サーバがわのルータで分割されちゃいますよね。その前にサーバで1500ずつに分解
するかどうかはしらんが。
でもコレガ以外のルータだと、同じデータを要求しても、「IPフラグメント」には
なっていないんですよ。これってルータがうまくやってるってことだと思ってます。
具体的にはノートンインターネットセキュリティという製品なんだけど、
これを待機させて、パケットアナライザも待機させて、いざデータ要求すると、
パケットアナライザでは「フラグメントパケット」のほうは、「IPフラグメント」
と認識して、ノートンのほうでは、「断片化されたパケット」がうんたら
かんたら・・・挙句の果てに、Nullスキャンを受けましたというメッセージ。
>>39
なるほど
>>40
イッコメの正常なやつは、1466で、データ長1452、識別子36792、もちろん後続
フラグメントビットたってます。
2個目のフラグメントされたやつはデータ長48、識別し36792、後方フラグなし、
フラグメントオフセット1432ってなってます。
整理すると、
イッコメ1466=MAC(12)+ETHER(2)+IP(20)+TCP(20)+DATA(1412)
ニコメ  82=MAC(12)+ETHER(2)+IP(20)+DATA(48)
です。オフセットは1432でいいと思うんだが・・・・
ノートンには「NULLスキャン」と言われたが、実際にブラウザが
バラけたパケットを最終的にきちんと組み立てたのかどうかは不明です。
役場、病院、警察からも電話かかってくるし・・・(泣)

42 :
>>41
TCPの3ハンドシェイクで、クライアントとサーバーはSYNパケットのオプションに
それぞれ自分のMSS値をのせて、ネゴシエーションして、小さいほうの値を
採用するわけですが、世の中の PPPoE サーバは、inboundまたはoutbound
SYNパケットのMSSオプション値を変更する機能を持っています。
この機能を使うことで、ローカルPCのMTU値を変更しなくても、自動的にTCPの
MSS値が PPPoE に適合した値(フレッツならば 1414バイト)になるということです。
そうすると、コレガのルーターがIPフラグメントしているということは、このMSS変換機能が
ちゃんと働いていない感じがしますね。ルーターの設定で MTU が 1454以下バイトに
なっていないか・・・、他にも可能性はありそうですね。

43 :
>>42
>採用するわけですが、世の中の PPPoE サーバは、inboundまたはoutbound
「PPPoE サーバ」⇒「PPPoE ルーター」の間違いです。スマソ

44 :
>>42,43
corega BAR SW-4P Proなんだが、MTU変更できないんすよね。
だからデフォルトでどうなってるのかわかんないです。

45 :
>>44
http://www.iij.ad.jp/service/system/router.html
ここの検証結果のC(非NAT時)を見ると、非NAT時にはMSS変換しないようなので、
Linuxサーバ側でMSSを1414バイト以下に設定しないといけないみたいですね。でも、テストしたファームが古いね。

46 :
>>45
おお!これだ!これが見たかったんだよ。
情報thanx!!たぶんファームは新しいのでも変換してないよ!
ということはLinuxでMTU1454ということだね。
一応29ビットの内部のサーバには全部施しました。
ちょっとはましになったかも。

47 :
ソケットをclose()するとき、通常はclose()はすぐに返ってきて、
裏でFIN処理が行われますよね。
これをFIN処理が終わるまで、つまり、TCPコネクションが切れ
てからclose()が戻るようなソケットオプションってあります?
OSは問いません。こういう実装があるかどうか知りたいので・・・

48 :
>>47
SO_LINGER ソケットオプションかな
「UNIX ネットワークプログラミング Vol.1」
に詳しく書います

49 :
IPに著作権保護機能はあるのか?
できればあったほうがいいが、
素人ですまんが。

50 :
>>49 それはアプリケーションの仕事でわ?

51 :
素人ですまないがいろいろな著作権問題が出るからソフトだけの著作権保護では不安なのではないだろうか、
流れを司るTCP/IPまでその機能をつけない限りは。
まあこれはJASRACに言ったほうがいいのでは。

52 :
>>51
そんなこと言ったら、ケーブルにも著作権保護機能が必要になるんかい?
IPはデータグラムの中身を全く参照しないのに、どうやって著作権を意識するんだい?
とりあえず、何のためのレイヤ3なのか解らない人はこの板で発言しないでくれ。

53 :
1

54 :
マルチキャストの勉強をしようと思ってるんですが、テストにはどんなアプリを使っていますか?
ユニキャストなら、HTTP、POPなどいくらでもあるんだけど・・。
動画配信サーバーとか作らないとダメでしょうか。

55 :
ところで「詳説TCP/IP Vol2」の邦訳版はいったい何時になったらでるんだ?
原書を生で読め!とかお約束の突っ込みはなしNe

56 :
こっちでも話題振ってくれ。下がりすぎ。
これは読んどけ!ネットワーク必読書
http://pc.2ch.net/test/read.cgi/network/954649325/

57 :
回線速度を計るのにFTPとか使ってるんだけどフリーウェアでなんかいいのある?
FTPだとハードディスクの読み書きとかで正しい数値が得られないようなきがする。

58 :
>>57
FTPで正確に測れないのは確かだが
まともなFTPクライアントを使っている限りは、そういう問題ではない
アプリさえ受け取れていればディスクに書くのなんて
通信が終わってからだってかまわないんだから
というか"回線速度"だったらFTPで十分だ
対向のサーバか回線がボトルネックで無い限りは

59 :
>>57

ttcp とか netperf あたりを使ってみれば。

60 :
>>58
最近のxDSLやFTTHでは、TCPでの転送なのが災いしてFTPでは
うまく計れなくなってきた。
帯域幅が広がったのに対して遅延があまり小さくならないから
ACK待ちが多くなって転送速度が頭打ちになっちゃう。
ウィンドウサイズをサイズを大きくすることで変わるけど、
個人的にはできればUDPベースとかでスループットが簡単に測れるのがいいね。

61 :
>>60
UDPだと逆に落ちたパケットと原因が特定しづらくならない?
TFTPみたいにL5以上でACKを実装してるUDPのプロトコルもあるけど
TCP以上にオーバーヘッドがあるからな
まあ、機器の性能とかではなくて単純にLinkの限界を拾うのであれば
UDPの方がいいかもしれないね
#測定する両端が自分の管理下ならnetperfで十分だと思うけど、>>57はちがうだろうからなあ

62 :
>>54
mcaster.exe
で検索してみな。
時々変な振る舞いをすることはあるが
テストには使えるよ。

63 :
>>61
>TFTPみたいにL5以上でACKを実装してるUDPのプロトコルもあるけど
>TCP以上にオーバーヘッドがあるからな
本気で言っていますか?

64 :
>>63
TFTPのACKの数がどんだけかあるか知らないのか?

65 :
TCP VegasとかNew Renoとかを実装したWinsockとかって無いですかね?
66 :あぼーん:あぼーん
あぼーん

67 :
(^^)

68 :
pingを実装しているんですが、今まで気にも止めなかった疑問が続々と・・
自作pingで米yahooに打ち続ける (遅延は150ms程)
と同時にWindows標準のping.exeで日本yahoo(遅延16ms)にも打ち始める。
すると、たまに米yahooに打っているはずの自作pingのレスポンスが
16msと表示される。www.yahoo.co.jpからの応答を受け取ってしまって
いるのだろうか。。
TCPの場合、port番号でセッションというかプロセス空間を区別
してますよね?ICMPの場合はどうなっているんだろう。
どうやって、「他のpingプログラムではなく」自分宛ての応答
だと認識するんでしょう。

69 :
とりあえずRFC792(ICMP)をちらちら読んでみると
「Sequence Number」というフィールドがあるとのこと。
エコーリクエストとエコーリプライを対応させるために
使われるとあるので、これがportに該当するものだろうか。。
だけど実装するときって、いったいどういう値を使えばいいんだろう。
16ビットあるんだけど、01から適当にインクリメントしていけば
いいのかな・・
その辺、詳しい人いませんか?

70 :あぼーん:あぼーん
あぼーん
71 :あぼーん:あぼーん
あぼーん

72 :
>>69
FreeBSD の場合、ID に"process ID & 0xFFFF"した値を突っ込んで
使っているみたい。
seq no はどの echo request に対する reply かを識別する為に
使ってるらしい。duplicate した reply の検知とかにも。
Windows Me だと ID は固定で、seq number がユニークになっている。
どうやって seq number をユニークにしているのかは知らん。
FreeBSD の ping だと ID で TCP でいうポート相当の事をしていて、
seq number でセッション管理的な事をしている。
WindowsMe の ping は seq number で両方行っている。
という感じかなぁ・・・。

73 :
久々に書き込んだら fusianasan になっちまった。
鬱氏

74 :
Windows 標準の ping.exe との併用を考えるのなら、
まずは、発掘人さんの環境の Windows に付いてくる ping.exe が
どんな sequence number と ID を付与しているか調べて、
それにならって実装されてみては良いのでは?

75 :
>>72-74貴重な情報どうも。
うちは2000です。IDってもしかして0400になってます?
とりあえずtcpdump流しっぱなしで放置して、seq numberがどういう動き
するのか観察する予定・・。
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/examples/rawping.html
ここにはC++とwinsockを使った実装がのってるんですが、この実装でも
受信パケットのseq numberが異なったら無視する仕様みたいです。


76 :
etherealで見る限り0x0400固定になってます。
自作pingではIDを0x0400以外にして、IDが0x0400な
echo reply パケットは無視すればとりあえず、
windowsのping.exeへの reply パケットを拾う事は
なくなりそうですね。

77 :
TCPヘッダのオプションフィールドについて質問です。
SunOS4.1ではSYNパケットのオプションが"0000 0204 05B4" で、
Solaris8では同じくSYNパケットのオプションは"0000 0101 0402 0204 05B4"
となっていました。
ものの本によると"0204 05B4"の部分はMSSを指定と書いてありましたが
それ以外の部分の意味が分かりません。
ご存知の方がいたら教えて下さい。
ついでに、なぜSunOSとSolarisで違っているのかもよろしくお願いします。


78 :
自己レスです。
解決しました。
TCPのオプションでは"00"および"01"はパディング
"02xx xxxx"がMSSの指定
"04xx"はSelective Ackの指定だそうです。
Selective Ack のオプションは新しめのSolarisでの追加機能だそう。
$ndd -set /dev/tcp tcp_sack_permitted 0 (or 1)
#defaultでは2
でこのオプションを付けないように変更できました。

79 :
>でこのオプションを付けないように変更できました。
パケロスある環境なら、SACKで効率改善できるよ

80 :
バーチャルコンカチネーションがよくわからねぇ(死

81 :
あのー、ルータ使っててLAN側でサーバ公開してるんですが、
特定のクライアントがインターネット越しにそのサーバにアクセスしようとすると、
ルータが弾いちゃって通信できないんですよ。
ルータのlog見ると、「tcp syn res set」ってなってんですが、誰かこの意味判りますか?

82 :
(^^)
83 :あぼーん:あぼーん
あぼーん
84 :あぼーん:あぼーん
あぼーん
85 :あぼーん:あぼーん
あぼーん

86 :
アプリケーションの質問ここでしていいですか?
DATEサーバってプロトコルって何ですか?
87 :あぼーん:あぼーん
あぼーん

88 :
質問です。IPアドレスにおいて、
「0」で始まるならクラスA、
「10」ならクラスB、
「110」ならクラスC、
「1110」ならクラスD(マルチキャスト用)
では「1111」で始まるアドレスは何?使用されるの?
初歩的な質問ですまん。いくつか本を当たったのだがみつからんかったので。

89 :
自宅にいるときも、会社の鯖が生きてるか死んでるのか心配です。
複数のサーバの複数のポートに対して
TCP のセッションを開始できるかどうかを常時検査して、
それをグラフィカルに表示してくれるようなWindowsのソフトって無いでしょうか?

90 :
ちなみに、普段会社では UNIX 系の OS で
nmap などで検査しています。
その結果を集計して、nagios などの監視ツールでまとめて監視しています。

91 :
会社では ICMP パケットをを通さないルータが要所要所にあります。
なのでいわゆる普通の ping は使えません。
(まぁ同じフロア内程度なら通るのですが)
nmap などのいわゆるポートスキャン用ツールだと、
ICMP パケットではなくていわゆる TCP Ping が使えるので重宝しています。

92 :
ちなみに自宅にはショボイ Windows パソコンが一台あるだけなので、
そいつのタスクトレイなんかにひっそりと隠れて監視してくれるとありがたいです。

93 :
big brotherっていうポーリングとMRTGを統合した
視覚的な監視ツール使うのが一般的なんだって

94 :
ttp://bb4.com/
これ

95 :
>>89
>自宅にいるときも、会社の鯖が生きてるか死んでるのか心配です。
強迫神経症の疑いがあります。精神科へ

96 :
>>93
ネーミングがキモイよ

97 :
物理層がADSLだと、TCP checksum errorが出るようだ
すなわち通信エラーが、L1からL3までの誤り検出を素通りして
検出されていないことになる。
IPv6では誤り検出のオーバーヘッドを削減するために
TCP層でしかエラー検出を行わないが、
CRCなど強力な検出方法をとっているのだろうか?


98 :
L2 での誤り検出は、そのリンクにおける誤りの検出にしか使えないわけで、
どこかで誤り検出を行わないリンクがあったらそれで終わり。
でも L3 の、つまりend-to-end での誤り検出に引っかからないのはどうしてだろうね。
まぁすべての誤りが検出できるわけではないから、
L3 で検出できない誤りが TCP で検出されたとしてもおかしくはないけど。
ところで、パケットスケジューラとかトラフィックシェーパーの話題ってどこのスレッドに行けばいいの?

99 :
>>97
>物理層がADSLだと、TCP checksum errorが出るようだ
他の物理層では、OKだったのでしょうか?
その物理層は、何でしょうか?

100read 1read
1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼
元junetユーザのつぶやき (268)
名無しさん@ネットワーク (270)
【IP携帯】WiMAXって知ってる?【次世代通信】 (370)
CCNA (311)
お前らの使ってるスイッOハブ教えろ (601)
韓国がインターネットを制する? (342)
--log9.info------------------
【横浜】■■■CLUB B■■■【元町】 (383)
広島のクラブ事情を語るスレ (931)
【骨董通り】青山 fai 6本目?【φ】 (201)
クラブ文化は、これからどうなるのか?★2 (313)
大沢伸一a.k.aDJ MURPHY 2 (562)
Soulseek vol.4 (960)
【大阪】studio candy【東心斎橋】 (470)
【断腸?】レコード・CDの処分について【邪魔?】 (363)
【福岡】今日のキースフラック【イケメン】 (240)
★DJ KENSEIを語るスレ★ (269)
anjunabeats (670)
一人でクラブ行けますか? (248)
DJ○○ って名乗りたいから考えてくれ (298)
名古屋のレコード屋 (466)
名古屋のオゾン2 (781)
トランス3大DJについて語るスレ (454)
--log55.com------------------
【ブルームバーグ】 日韓専門家が警告 「経済戦争への道を歩み始めている。非常に危険だ」
【輸出優遇除外】『ホワイト国』除外なら1100個の先端素材および部品調達に支障★2
【いつものアレ】徐敬徳教授「日本は約束履行していない」…軍艦島の世界遺産撤回を要求「世界遺産登録を撤回するのが望ましい」[7/4]
【韓国への経済制裁】 在日韓国人企業や日本に進出した韓国企業を相手にさまざまな形で金融関連制裁も
【対韓輸出規制】 日本政府、電子部品も検討か
【オーストラリア当局】スマートフォンの誇大広告でサムスンを提訴[7/4]
【伝統無くとも韓国伝統の濁り酒】マンゴー・ピーチ味のマッコリ 日本で新発売へ=ハイト真露 現地市場攻略を強化する[7/4]
【携帯電話中国連盟】韓国は昨年の日韓関係悪化時点から対策を準備[07/04]