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

みないか？

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

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

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

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

この板あんま人いないねェ。　板の回転もﾏﾀーリしてるし。

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

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

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

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

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

まぁお前１はnetbsdを使えってこった

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

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

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

ネタスレと思いきや

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

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

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

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

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

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

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

>>19
ネットワーク屋なんで、Unixカーネルについてはほとんど無知なんだけど、かってに想像するとこんな感じ。
#激しく間違ってる可能性アリ

NICがフレーム受信→
カーネルのメモリ領域にいるNICのドライバ(L2)がL2ヘッダを削除してIPドライバ(L3)に渡す→
IPドライバがL3ヘッダを削除してTCPドライバ(L4)に渡す(フラグメントがあればパケットを再構成)→
TCPドライバは正常なシーケンスのパケットであれば、パケットをキューイング(異常があればエラー訂正や再送要求)→
RWINが埋まる、もしくはPUSHされるれば、データグラムを再構成してアプリに渡す→
アプリケーションはソケットを作ってデータグラムを処理する→
処理不能(ポートをリッスンしているプロセスが無い等)であればソケットが作れない旨をTCPドライバにかえす(TCPドライバはセッションをRSTする)→

こんな感じでは無いかと、、、
いずれにしてもカーネルメモリに存在しているのでは？
常駐しているユーザプロセスとは大分性格が異なるんでしょうけど、、

ヤフーオークションで、幻の人気商品、発見！！！

今は無き「コピーガードキャンセラー」↓
http://page.auctions.yahoo.co.jp/jp/auction/42757955

ヤフーオークション内では、現在、このオークション
の話題で、持ちきりです。

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

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

WinPCap は W2K では NDIS の仕様で WAN Apdapter のパケットを
キャプチャ出来ませんが、何か代替策はあるでしょうか？
WinPCap が無理と言うことは他のパケットキャプチャツールでも
無理なんですかね。WinDump も Analyzer も Ethereal もみんな
WinPCap を使っているし.....、何か無いかしら。

そもそも、NDIS の WAN側の制限ってどういう仕組みで発生することなんでしょうか？
W2K のネットワークアーキテクチャに強い方、教えてください。

一応 アプリ - TDI - プロトコルドライバ - NDIS - NIC という流れの
概念は理解しているつもりです。

age
age

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

おおもりよしはる＝ロリペドオタ、アニオタ、モーツアルトオタ、ベートーベンオタ、ブルックナーオタ、セガ信者
ひまわりと幼女のすじまんこに異様な執着心を燃やしているﾛﾘﾍﾟﾄﾞ絵描き
２浪して九州大学歯学科に進むがプロのイラストレーターになるために大学を中退、
同人活動とＵＯに専念する日々を送るが、その生活は苦しいらしい（藁
自らを画家と呼び、ともすれば不真面目なものと見られかねないアニメ絵
それも、無毛のすじまんこすらも「芸術」の域にまで高めようとしている（らしい）。
心の支えは自分の描いたひまわりの絵らしい（ぷ
マスコミ（西日本新聞）で写真付きで取り上げられたこともあるらしい。
最強のネットゲーＵＯでは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/

あぼーん

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

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

古き良き時代: 送信者は保守的に、受信者はリベラルに。
世知辛い現代: 疑わしきは逝ってヨシ。

ってとこかな。

>>32
> ああ微妙だねえ。要するに DF ビットが立った fragment が届いたって
> ことだよね。

そうなんです。

たちの悪い事に、fragment したパケットを出しているのが
自社のサーバだったりします。^^;

お家の環境は、「逝ってよし」なポリシーなので
自社のサーバにアクセスできなくなりました。^^;;;

NetScreen が間抜けなのか、設定者が間抜けなのか・・・。（鬱）

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

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

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

>>35
IPsecのとき、オリジナルIPパケットのDFビットを無視してIPsecパケットを
フラグメントすることはできるけど、そのときのouterヘッダにはDFビットを
立てないんじゃありませんでしたっけ。

だから、DFビットが立ったままフラグメントという状況は普通は無いはずなんですが
どうでしたっけね。手元にIPsec動作するのが無いのでうろ覚えですが。

便乗質問させてください。
普通のLinuxサーバはMTU1500になってますが、
BフレッツPPPOE,unnumberdでコレガのルータかまして、内部の（グローバル）
Linuxサーバを公開しているんですが、別のネットワークのクライアントで
到着パケットをみると「フラグメント」しているみたいなんです。
（1466＋82という2つのパケットに分かれてます。）

LinuxはMAX1500のパケットを送り出しているが、コレガのルータが
それを分割してクライアントに送りつけるということでよろしいのでしょうか？

この状態はとくに異常なものではないのでしょうか？
その2番目の後続フラグメントパケットにはIPヘッダはついているけど、
TCPヘッダはついていません。つまり全部フラグが０と見られてしまうし、
送信先、送信元ポート番号もないので、この後続フラグメントパケットだけみると
「Nullスキャン」という解釈がされてしまうと思うのですが、どうでしょう？

識者の方、ご教授願います。
（おまえんとこからNullスキャン受けたと抗議殺到でマジで困ってます。）

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

>>37
>その2番目の後続フラグメントパケットにはIPヘッダはついているけど、
>TCPヘッダはついていません。

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

>>37
>（おまえんとこからNullスキャン受けたと抗議殺到でマジで困ってます。）

その侵入検知システムはフラグメントオフセットが０でないかどうかを、ちゃんと検査していないのかも
しれませんね。ところで、1466+82 の82の方のＩＰヘッダーのフラグメントオフセットは1446になってる？
（1446 = 1466 - ＩＰヘッダーのバイト数）
あと、1466と82のIPヘッダーの識別子は同じになってる？

>>38
Q5.フレッツ接続ツール以外のPPPoEクライアントソフトウェア、

A5.ルータ等を使用するときに注意することはありますか？
フレッツ接続ツール以外でPPPoEクライアント機能を使用するとき、
MTUを1454Byte以下（MSSを1414Byte以下）に設定していただく必要があります。
MTU、MSSを上記の値以上に設定すると閲覧できないHP等がございます。
また、PPPoE対応のルータは、最新のファームウェアを使用することをお勧めします。
最新のファームウェアはお買い求めのメーカのHPにてダウンロードしてください
（ルータの場合はお買い求めのメーカのサポート窓口等にお問合せください）。
これでしょ？サーバ側って最初のsynでクライアントのmssを教えてもらうから、
それをもとに応答パケットを作成すると。しかし、サーバ側のPPPOEルータの関係
から、Linuxのデフォルト1500だと、もし、クライアントのmssが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スキャン」と言われたが、実際にブラウザが
バラけたパケットを最終的にきちんと組み立てたのかどうかは不明です。

役場、病院、警察からも電話かかってくるし・・・（泣）

>>41
ＴＣＰの３ハンドシェイクで、クライアントとサーバーはSYNパケットのオプションに
それぞれ自分のMSS値をのせて、ネゴシエーションして、小さいほうの値を
採用するわけですが、世の中の PPPoE サーバは、inboundまたはoutbound
SYNパケットのMSSオプション値を変更する機能を持っています。
この機能を使うことで、ローカルＰＣのMTU値を変更しなくても、自動的にTCPの
MSS値が PPPoE に適合した値（フレッツならば 1414バイト）になるということです。

そうすると、コレガのルーターがＩＰフラグメントしているということは、このMSS変換機能が
ちゃんと働いていない感じがしますね。ルーターの設定で MTU が 1454以下バイトに
なっていないか・・・、他にも可能性はありそうですね。

>>42
>採用するわけですが、世の中の PPPoE サーバは、inboundまたはoutbound

「PPPoE サーバ」⇒「PPPoE ルーター」の間違いです。スマソ

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

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

>>45
おお！これだ！これが見たかったんだよ。
情報thanx！！たぶんファームは新しいのでも変換してないよ！

ということはLinuxでMTU1454ということだね。
一応２９ビットの内部のサーバには全部施しました。
ちょっとはましになったかも。

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

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

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

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

素人ですまないがいろいろな著作権問題が出るからソフトだけの著作権保護では不安なのではないだろうか、
流れを司るＴＣＰ／ＩＰまでその機能をつけない限りは。
まあこれはＪＡＳＲＡＣに言ったほうがいいのでは。

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

1

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

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

こっちでも話題振ってくれ。下がりすぎ。

これは読んどけ！ネットワーク必読書
http://pc.2ch.net/test/read.cgi/network/954649325/

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

>>57
FTPで正確に測れないのは確かだが
まともなFTPクライアントを使っている限りは、そういう問題ではない
アプリさえ受け取れていればディスクに書くのなんて
通信が終わってからだってかまわないんだから

というか"回線速度"だったらFTPで十分だ
対向のサーバか回線がボトルネックで無い限りは

>>57

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

>>58
最近のxDSLやFTTHでは、TCPでの転送なのが災いしてFTPでは
うまく計れなくなってきた。

帯域幅が広がったのに対して遅延があまり小さくならないから
ACK待ちが多くなって転送速度が頭打ちになっちゃう。

ウィンドウサイズをサイズを大きくすることで変わるけど、
個人的にはできればUDPベースとかでスループットが簡単に測れるのがいいね。

>>60
UDPだと逆に落ちたパケットと原因が特定しづらくならない？
TFTPみたいにL5以上でACKを実装してるUDPのプロトコルもあるけど
TCP以上にオーバーヘッドがあるからな

まあ、機器の性能とかではなくて単純にLinkの限界を拾うのであれば
UDPの方がいいかもしれないね

#測定する両端が自分の管理下ならnetperfで十分だと思うけど、>>57はちがうだろうからなあ

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

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

本気で言っていますか？

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

TCP VegasとかNew Renoとかを実装したWinsockとかって無いですかね？

あぼーん

（＾＾）

pingを実装しているんですが、今まで気にも止めなかった疑問が続々と・・

自作pingで米yahooに打ち続ける (遅延は150ms程)
と同時にWindows標準のping.exeで日本yahoo(遅延16ms)にも打ち始める。

すると、たまに米yahooに打っているはずの自作pingのレスポンスが
16msと表示される。www.yahoo.co.jpからの応答を受け取ってしまって
いるのだろうか。。

TCPの場合、port番号でセッションというかプロセス空間を区別
してますよね？ICMPの場合はどうなっているんだろう。
どうやって、「他のpingプログラムではなく」自分宛ての応答
だと認識するんでしょう。

とりあえずRFC792(ICMP)をちらちら読んでみると
「Sequence Number」というフィールドがあるとのこと。
エコーリクエストとエコーリプライを対応させるために
使われるとあるので、これがportに該当するものだろうか。。

だけど実装するときって、いったいどういう値を使えばいいんだろう。
16ビットあるんだけど、01から適当にインクリメントしていけば
いいのかな・・

その辺、詳しい人いませんか？

あぼーん

あぼーん

>>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 で両方行っている。
という感じかなぁ・・・。

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

鬱氏

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

>>72-74貴重な情報どうも。

うちは2000です。IDってもしかして0400になってます？
とりあえずtcpdump流しっぱなしで放置して、seq numberがどういう動き
するのか観察する予定・・。

http://www.kt.rim.or.jp/~ksk/wskfaq-ja/examples/rawping.html
ここにはC++とwinsockを使った実装がのってるんですが、この実装でも
受信パケットのseq numberが異なったら無視する仕様みたいです。

etherealで見る限り0x0400固定になってます。

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

TCPヘッダのオプションフィールドについて質問です。

SunOS4.1ではSYNパケットのオプションが"0000 0204 05B4" で、
Solaris8では同じくSYNパケットのオプションは"0000 0101 0402 0204 05B4"
となっていました。

ものの本によると"0204 05B4"の部分はMSSを指定と書いてありましたが
それ以外の部分の意味が分かりません。
ご存知の方がいたら教えて下さい。

ついでに、なぜSunOSとSolarisで違っているのかもよろしくお願いします。

自己レスです。
解決しました。

TCPのオプションでは"00"および"01"はパディング
"02xx xxxx"がMSSの指定
"04xx"はSelective　Ackの指定だそうです。

Selective Ack のオプションは新しめのSolarisでの追加機能だそう。
$ndd -set /dev/tcp tcp_sack_permitted 0 (or 1)
#defaultでは2
でこのオプションを付けないように変更できました。

＞でこのオプションを付けないように変更できました。

パケロスある環境なら、SACKで効率改善できるよ

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

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

（＾＾）

あぼーん

あぼーん

あぼーん

アプリケーションの質問ここでしていいですか？

DATEサーバってプロトコルって何ですか？

あぼーん

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

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

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

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

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

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

ttp://bb4.com/
これ

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

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

物理層がADSLだと、TCP checksum errorが出るようだ

すなわち通信エラーが、L1からL3までの誤り検出を素通りして
検出されていないことになる。

IPv6では誤り検出のオーバーヘッドを削減するために
TCP層でしかエラー検出を行わないが、
CRCなど強力な検出方法をとっているのだろうか？

L2 での誤り検出は、そのリンクにおける誤りの検出にしか使えないわけで、
どこかで誤り検出を行わないリンクがあったらそれで終わり。

でも L3 の、つまりend-to-end での誤り検出に引っかからないのはどうしてだろうね。
まぁすべての誤りが検出できるわけではないから、
L3 で検出できない誤りが TCP で検出されたとしてもおかしくはないけど。

ところで、パケットスケジューラとかトラフィックシェーパーの話題ってどこのスレッドに行けばいいの？

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

いやTCPでエラー出たのADSLぐらいだし

PPPoE のせい？