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

今月の関連人気記事
(集計単位:1ヶ月)
1: 02/02/23 11:06 ID:y/UaIt4f
みないか?

2: 名無しさん 02/02/23 11:06 ID:???
>>1
とりあえずネタ振ってください。

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

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

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

8: 名無しさん 02/02/23 11:26 ID:???
>>7
BSD系やLinuxはカーネル内にいます。
Windows系はドライバだよね。本質的には両者に差はないんだけど。

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

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

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

17: anonymous@ ntkngw030197.adsl.ppp.infoweb.ne.jp 02/02/23 14:18 ID:???
*BSDのカーネルソースでも見るのが手っ取り早い。
PPPとかもいるし…

18:   02/02/23 16:16 ID:???
Solarisもドライバとしての実装だよね、確か

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

22: 18 02/02/23 21:59 ID:???

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

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

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

24: 24 02/02/24 02:17 ID:???

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

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

37: pod 02/06/04 20:23 ID:ywr9ech9

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

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

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

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

38: anonymous@ FLA1Aac138.kng.mesh.ad.jp 02/06/04 21:55 ID:???

41: pod 02/06/04 23:03 ID:uyWBEBfh

>>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スキャン」と言われたが、実際にブラウザが
バラけたパケットを最終的にきちんと組み立てたのかどうかは不明です。

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

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

62: ほぷきん 02/09/14 19:19 ID:???
>>54
mcaster.exe
で検索してみな。
時々変な振る舞いをすることはあるが
テストには使えるよ。

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

58:   02/09/14 00:44 ID:???

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

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

68: 発掘人 03/01/31 02:44 ID:VG1/88JB

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

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

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

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

69: 発掘人 03/01/31 02:52 ID:VG1/88JB

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

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

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

72: anonymous@ eAc9Aaa056.tky.mesh.ad.jp 03/01/31 18:21 ID:???

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

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

131: anonymous@ 221.186.136.116 04/06/30 15:15 ID:fd0zTYqI

TCPでのコネクション確立時、いわゆる3ウェイハンドシェイクのときに、
SYN ->
<- SYN、ACK
ACK ->
の最後のACKのデータ部分に実際の送信データを格納して接続してくる
クライアントがいるんですが、この部分のデータで有効なんですかね?

最後のACKにはデータ部分をつけちゃダメなような気がしてたまらんが。。。

133: sage 04/07/02 20:56 ID:???

>>131
有効。
いたって普通の処理だと思うが。

T/TCP使えばSYNにもデータのせることができる。
実際プロセスが読むのはコネクションが確立してからだけど。

165: 165 2005/07/20(水) 01:11:53 ID:5XQIpU5A

フローコントロール(802.3x)が付いてない糞鯖がここにある。
2MbpsのCANを通したらパケットロスしまくり(?)で激遅。
鯖のNICを半二重にしたらHUBのバックプレッシャーで改善。

でもさ、TCPってスロースタートで輻輳制御してるんじゃないの?
もしかして、ルータを介さない宛先にはスロースタートしないで
いきなりガンガン送りつけちゃうのかな?

166: _ 2005/07/20(水) 09:00:24 ID:???
>>165
TCPはスロースタートというのは正しい。
ただしパケットロスしまくると過度に輻輳制御して
速度を大幅に落としてくれる素晴らしい作りなんだ。

230: anonymous@fusianasan 2021/08/19(木) 20:27:43.22 ID:???
20年で200レスか

管理人からひと言

10年後に再度見てみるかな(´・ω・`)

引用元

TCP/IPについてじっくり考えてみなか?
スポンサー

シェアする

フォローする