人に聞けない痔の悩み、これでスッキリ >>

以下の現象が発生して、大変困っております。


<現象>
クライアントからhttpsアクセスをしようとして、
ブラウザに「ページが表示できません」エラーとなることがある。

<調査状況>
クライアント、OS上でWireSharkを仕掛けて、TCPの通信をキャッチしたところ、
問題が発生した通信は「SYN」がOSまでは来ているが、
「SYN/ACK」が返ってきていない。

<環境>
サーバ:windows2003server,Apache
クライアントOS:WindowsXP


<質問内容>
クライアントからの「SYN」要求に対して、「SYN/ACK」を返すのは、具体的に何が返しているのでしょうか。
(windowsのソケットプログラム?)

また、その調査方法があれば教えて頂けないでしょうか。
よろしくお願い致します。

このQ&Aに関連する最新のQ&A

A 回答 (5件)

SYN/ACKは、OSのTCPプロトコル処理プログラムが返送します。


SYNパケットを受信したTCP処理プログラムは、対象ポートを
listenしているアプリケーションがいればSYN/ACKを返却し、
誰もlistenしていなければRST/ACKを返却します。

SYN/ACKもRST/ACKも返却されていない場合、Windowsファイアウォールや
市販のパーソナルファイアウォールソフトがパケットを破棄している
可能性が高いと思います。

SYN/ACKの替わりにRST/ACKが返却されているのであれば、
アプリ(Apache)が指定ポートをListenしていない可能性が高いです。

いずれの場合も、OSのネットワーク処理レベルの話であり、
Apacheに着信は通知されません。
Apacheの着信処理が動作する前になんらかの異常が発生している
と思います。)、

この回答への補足

回答ありがとうございます。

Windowsファイアウォールは切っていますが、
市販のウィルス対策ソフトは入っております。

ただ、ウィルス対策ソフトオフにした状態で、現象が再現したので、
関連性は少ないと思っております。


今の時点では、RST/ACKが返却されている状況は確認できておりません。
となると、Apacheの可能性は低いということですね。。。

補足日時:2010/01/19 13:58
    • good
    • 0

> 問題のある通信の時だけ、サーバ側でポートが閉じているのかどうか、


> 調査することはできるのでしょうか。

ポートが待ち受け状態になっているかどうかは、コマンドラインから"netstat -a"を実行すればわかります。
ただ、ファイアウォール機能を使っている場合はそちらの影響も考える必要があります。

> といったことがあるのかどうか、疑っているのはいるのですが、

実装については素人なので外しているかもですが、基本的にTCPセッションの確立まではOSの仕事です。
Apacheは確立したセッション上でデータの送受信をやっているだけのはずです。

この回答への補足

回答ありがとうございます。

なるほど、netstatですね。
再現テストはできるので、その間のnetstatの状態をログで出力させるようにしてみます。

補足日時:2010/01/19 13:50
    • good
    • 0

サーバ側にSYNが届いていてかつサーバがSYN/ACKを返していないのであれば、問題はサーバ側にあると見て良いでしょう。


ポートが閉じているのかはたまた別の問題なのか、今提示されている情報だけでは何ともいえませんが…

> その通信が、Apache上のアクセスログには出ていないという状況です。

そもそもTCPのセッションが確立していないので、Apacheのログには何も出力されないと思います。

この回答への補足

回答ありがとうございます。

おっしゃるとおり、サーバ側に問題があると思っております。
問題のある通信の時だけ、サーバ側でポートが閉じているのかどうか、
調査することはできるのでしょうか。


>> その通信が、Apache上のアクセスログには出ていないという状況です。
>
>そもそもTCPのセッションが確立していないので、Apacheのログには何も出力されないと思います。

OSのソケットをオープンするのは、Apacheのプロセスだと思うので、
OSまで"SYN"は届いていて、Apacheのプロセスに渡せなかったから
ソケットをオープンできず、"SYN/ACK"が返らなかった。

といったことがあるのかどうか、疑っているのはいるのですが、
その辺りの調査方法がわからず、暗礁に乗り上げております。。。。

補足日時:2010/01/15 20:12
    • good
    • 0

Apacheのアクセスログより、エラーログを調べるべきかと思います。



> httpsアクセスをしようとして、
Windows2003側のポート443開放と、SSLの設定は出来てますか?

この回答への補足

ご回答ありがとうございます。
説明不足で申し訳ございません。

error.log、ssl_request.logは調査しておりますが、エラーは検知できておりません。

Windows2003側のポート443開放と、SSLの設定は出来ております。
通常、https通信が出来ておりますが、
1回/1時間程度、「ページが表示されません」と出てしまうことがあります。

補足日時:2010/01/15 19:53
    • good
    • 0

"SYN"に対して"SYN/ACK"を返すのは、"SYN"を受信したホストです。


クライアントが"SYN"を送っているのに"SYN/ACK"が返ってこないのであれば、
(1) SYNがサーバに届いているのか
(2) サーバはSYN/ACKを返しているのか
をまず調べないと始まりません。

サーバ側にWiresharkを仕込むなり「ネットワークモニタ」(2003に標準付属)を追加インストールするなりして調べるのが良いでしょう。

あとは、どこで通信がブロックされているかをしらみつぶしに調べていくことになります。

この回答への補足

回答ありがとうございます。
説明不足で申し訳ございません。

サーバ側にWireSharkを仕掛けた結果、
サーバ側のNickまでは"SYN"が届いていることは確認できております。

その通信が、Apache上のアクセスログには出ていないという状況です。

補足日時:2010/01/15 15:05
    • good
    • 0

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人はこんなQ&Aも見ています

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

QwiresharkでパケットモニタするとRetransmissionが多発しているという意味は?

現在、自分で作成したパケット送信クライアントプログラムをテストしており、3秒に1回のタイミングでインターネット上にあるサーバのグローバルipアドレスに対し、TCPパケットを発信させて受信するというテストを行っています。
しかし、3秒に一回データを送っているはずなのに、その間隔10秒とか20秒とか間隔が開いてしまう時があります。

wiresharkというパケットモニタソフトで送信側、受信側共にパケットモニタを行ってみたところ、”Retransmission”が多発しているということがわかりました。(tcp.analysis.retransmissionというフィルタ設定で検索)この現象はある時とない時があります。テストして10日ぐらい経つのですが、このパケットが確認されるのはお昼の12時頃と夕方の6時頃が多いのですが、このことからどのようなことが起こっていると考えられますか?

わかる方いらっしゃいましたらご教授よろしくお願いいたします。

Aベストアンサー

簡単に言うと「トラフィック過多によるパケットの再送が多発している」です。

噛み砕いて言えば「回線が混雑していて、送信したパケットが、他の誰かが送信したパケットと衝突(コリジョンが発生)してパケットが消えた。なので、もう一度、送り直した」と言う事。

>このパケットが確認されるのはお昼の12時頃と夕方の6時頃が多いのですが、このことからどのようなことが起こっていると考えられますか?

「お昼休み、終業時間の6時になると、みんな、メールをチェックしたり、個人的にインターネットを閲覧し、トラフィック過多が起き、回線が異常に混雑する」と言う事が起きていると考えられます。

解消するには以下の方法があります。
・「休み時間も、終業時間後も、プライベートでネットを使うな!」と言う「通達」を全社に出す
・社内LANを、トラフィック過多によるコリジョンが起きないよう高速で帯域のあるネットワークカード、LANハブ、ルーターに変える
・受信側と送信側を、社内LANから(電気的、アドレス的に)独立した別のLANにする

要は「混んでる時間帯なので仕方が無い」って事です。

簡単に言うと「トラフィック過多によるパケットの再送が多発している」です。

噛み砕いて言えば「回線が混雑していて、送信したパケットが、他の誰かが送信したパケットと衝突(コリジョンが発生)してパケットが消えた。なので、もう一度、送り直した」と言う事。

>このパケットが確認されるのはお昼の12時頃と夕方の6時頃が多いのですが、このことからどのようなことが起こっていると考えられますか?

「お昼休み、終業時間の6時になると、みんな、メールをチェックしたり、個人的にインターネットを...続きを読む

Qpingでポートの指定

pingでIPアドレスを指定して、通信できるかどうかというのは
よく使いますが、pingでポートを指定して応答するかどうかは調べられるのでしょうか?

よろしくお願いします

Aベストアンサー

pingを含むICMPというプロトコルは、OSIの7レイヤで言うところのL2(同一セグメント内通信)とL3(IPルーティングされた通信)の両方にまたがる、ちょっと珍しいプロトコルです。

IPアドレスは指定できますが、別サブネットに属するIPアドレスに到達できればL3通信、できなければゲートウェイと呼ばれる同一サブネットに属する中継装置からの回答を得るという点でL2(MAC通信ではなく、同一セグメント内通信という意味)通信です。

ポート番号はL4で使用されるアドレスですから、L4機能の疎通確認はping(を含むICMP)ではできません。

FTPの疎通確認であれば、クライアントからサーバに対するTCP/21通信(FTP-CMD)が可能であること(サーバからクライアントへのTCP/21からの応答を含む)+サーバからクライアントに対するTCP/20通信(FTP-DATA)が可能であること(クライアントからサーバへのTCP/21からの応答を含む)が必要でしょう。

監視ソフトによるものであれば、
・クライアントからサーバへのログイン(TCP/21)
・クライアントからサーバへのlsの結果(TCP/20)
で確認すればよいでしょう。

pingを含むICMPというプロトコルは、OSIの7レイヤで言うところのL2(同一セグメント内通信)とL3(IPルーティングされた通信)の両方にまたがる、ちょっと珍しいプロトコルです。

IPアドレスは指定できますが、別サブネットに属するIPアドレスに到達できればL3通信、できなければゲートウェイと呼ばれる同一サブネットに属する中継装置からの回答を得るという点でL2(MAC通信ではなく、同一セグメント内通信という意味)通信です。

ポート番号はL4で使用されるアドレスですから、L4機能の疎通確認はping(を含む...続きを読む

QFINパケット、RSTパケットが返却される理由?

アパッチのヘルスチェックにて、パケットをみました。
シーケンス番号を追っていきましたが、下記のような
通常ではない動作がありました。

<ケース1>
(1)サーバからのHTTPのGETに対して、クライアントがFIN.ACKパケットを返却する。
(2)サーバがFIN.ACKパケットをクライアントに送る。
(3)クライアントからRSTパケットが返却される。
※RSTパケット内にて、broken tcpとの記載あり

<ケース2>
(1)サーバからのFIN.ACKパケットに対して、クライアントからRST.ACKパケットが返却される。


・質問1
それぞれについて、正常な動作とはおもえないのですが、
異常でしょうか?

・質問2
FIN.ACKパケット又はRSTパケットが返却されるのはどんな場合が想定されるのでしょうか?

・質問3
FIN.ACKパケット→RST.ACKパケットは異常な動作でしょうか?

よろしくお願いします。

Aベストアンサー

おつかれさまです。

質問1
ケース1というのはおかしいですね。
サーバからのHTTPのGETというのはありえません。
GETはクライアントから送信されるものです。
言葉のアヤでGETの応答電文がサーバから送信
されている間にFINがクライアンから来るという
ことであってもおかしくないと思います。

ケース2のRSTパケットについてもおかしくありません。
よくブラウザ上で通信途中(画面が全部表示されない)
で次のページへ移動することなどありますよね。
またサーバもクライアントも、keepaliveという
機能があります。一連のやりとりが終わっても、
次の通信のために一定期間コネクションを保持する
機能です。これは意外とおせっかい機能で時間が
たつと勝手にRSTを発行したりします。

質問2
FINは一連の通信が終わった時です。
上述のkeepaliveの機能も一応決まりがあって、
httpヘッダにカウンドダウンする数字があって
もうこの通信で終わりですよって1まで来たら
FINが発行されます。
またはkeepaliveのtimeout時間が過ぎると
RSTが出ます。
他のケースとしては通信不良で再送リトライ
オーバとなった場合とか、通信不良で通信の
シーケンスが合わなくなった場合とかに
RSTが出ることはあります。

質問3
FIN→RST クライアントがFINを出してコネクションを
開放した後に、FINをサーバが返してきたら、もう
コネクションはないのでサーバ側も開放してねと
RSTを投げるケースはあるでしょうね。

とにかく、
ケース1(1)以外はよくあることです。
クライアント(PCのブラウザだと思いますが...)は
人が操作しているので、ブラウザを×するとか
F5キー押すとか、いろんなことをやるでしょう。
WindowsやIEのそのあたりの動きは結構アバウトな
作りであることは確かですが....

いかがでしょう?

おつかれさまです。

質問1
ケース1というのはおかしいですね。
サーバからのHTTPのGETというのはありえません。
GETはクライアントから送信されるものです。
言葉のアヤでGETの応答電文がサーバから送信
されている間にFINがクライアンから来るという
ことであってもおかしくないと思います。

ケース2のRSTパケットについてもおかしくありません。
よくブラウザ上で通信途中(画面が全部表示されない)
で次のページへ移動することなどありますよね。
またサーバもクライアントも、keepaliveという
機能があり...続きを読む

Qポートの80と443

こちらのサービス(https://secure.logmein.com/)を利用すると、インターネットを見られるサーバーのポートの80と443が空いていればルータやファイアウォールに特段の設定なく外部からサーバーを操作できるそうですが、逆にサーバーのポートの80や443を空けることには何か危険性があるのでしょうか。

Aベストアンサー

ポート80は一般的なHTTP、ポート443はHTTPSです。
この2つのポートがあいていなければインターネット接続(WEBブラウジング)は出来ません。
ですから、ほとんどのファイアウォールでこのポートは開いています。(インターネット接続を制限している社内LANでは当然閉じていますが)

ちなみに、よく使うポートとしてはFTPで20、21、SMTP(送信メール)で25、受信メールPOP3で110あたりです。セキュリティポリシー上、この辺は制限される事も多いですが、HTTP 80、HTTPS(暗号化用)443は通常閉じません。


危険性?
WEBプロトコルを使ってFTP的なファイル転送(WebDAV)やVPN等も出来るようになっています。当然そこにはある種の危険はつきものですが、WEBブラウジングに伴う危険と大きく変わりません。ウィルス等に感染していればこの2つのポートだけでも相当危険でしょうね。

参考まで。

Qsocket: recvはいつ,どれだけ受け取るのか?

 現在,参考書にしたがってC++でソケットプログラミングを書いています.

 sendとrecvを非同期にするために,本では select関数やWSAAsyncSelect関数などを利用していて,実際,本のとおりに書いて上手く動いています.

 ここで伺いたいのですが,recvは,どうやって「データが届いたか」を知るのでしょうか.

 同期ならば,トランシーバでの会話のように送信側が「どうぞ」といって送受信を交代させることができますが,非同期ならばそれができません.

 NICとかが,プログラムに「届いたぞ!( or これから届くぞ!)」と教えてくれるのでしょうか.あるいは逆に,プログラムがNICに「届いてる?」と聞いているのでしょうか.仮に,ここに書いたような方法で届いたことが分かったとしても,どれくらい受け取ればいいかは分かりません(それも併せて教えてもらっているのでしょうか.データを送るときには,どれだけ送ればいいか分かりますよね.受信するときはどうしてるのかを知りたいと思っています).

Aベストアンサー

Linux しか知らないので Linux で説明をします。

NIC が通信パケットを受け取ると割り込みが発生し、CPU は割り込みを受け付けて、対応するデバイスドライバを起動します。この時、ドライバはソケットバッファと呼ばれる構造体にパケットの中身をコピーして、Linux カーネルの本体に渡し、そこで TCP 等の上位プロトコル処理が行われます。

一方、ユーザプログラムの方は、 select() なり read() で待っている訳ですが、OS はもちろんプロセスが何を待っているかを知っているので、対応する待ちの条件が満たされると、この場合は select() や read() が、抜けてくる(return する)訳です。

という事で、ユーザのプログラムは select() なり read() なりで受信データを「待つ」ことが必要です。もちろん select() や read() が呼ばれた時点で既に受信しているのならば、それらは直ぐに帰ってきます。read() や recv() はデータが届いた事を知る、というよりは、届いているかチェックして、まだ届いていなければ届くまで待つ(read() が抜けてこない)という処理になります。また NIC とユーザプログラムが直接やり取りをするのではなく、間にバッファがあって、対応するソケットのデータがある(受信済み)/ないか(未受信)、という問い合わせを行っているだけです。

ソケットの場合、データの送受信は非同期であり、送受信のタイミングのずれは(ソケット)バッファである程度吸収されます。もちろん、送受信バッファが満杯になった場合は流量制御が働いて、結果的に送信側の write() や send() が待ちに入ることになります。

Linux (Unix) のソケットの受信では、read() 等で指定されたバッファが常に満杯で返されるとは限らない設計になっています。つまり、その時に受信しているデータを返すだけなので、read() で返されたバイト数を必ず見ないと間違った動きになるので注意してください。

Linux しか知らないので Linux で説明をします。

NIC が通信パケットを受け取ると割り込みが発生し、CPU は割り込みを受け付けて、対応するデバイスドライバを起動します。この時、ドライバはソケットバッファと呼ばれる構造体にパケットの中身をコピーして、Linux カーネルの本体に渡し、そこで TCP 等の上位プロトコル処理が行われます。

一方、ユーザプログラムの方は、 select() なり read() で待っている訳ですが、OS はもちろんプロセスが何を待っているかを知っているので、対応する待ちの条件が満...続きを読む

QSYNFlood攻撃を回避する方法を教えてください!

SYNFlood攻撃を回避する方法を教えてください!

ネットワーク初心者です。

会社で運用しているサーバが先日アクセス不可になりました。
FWのログが得られなかったため、詳細は分からないのですが、おそらくSYNFlood
だったのでは?との結論に至っており、今後の対策を進めているところです。

その中で、(1)上記の結論が正しいのか、(2)打てる対策は他にないのか、について
何かアドバイスをいただければと思い、質問させていただきます。


サーバ構成としては、下記のようになっております。
FW ⇒ LB ⇒ WEB
事故以降に調査した結果、LB側でセッションがたまった状況になったためではと考
えています。(★)
根拠としては、(1)FW側のSYNFloodProtectionのThresholdの設定が200ppsだ
ったので、当時は大量にSYNパケットがLBに送られていた、(2)最大同時セッション
数についても、FW側が128でLB側が100となっており、LB自体がセッションを受け
入れられない状況だった、(3)FWのタイムアウト値が5分なのに対し、LBの無応答
タイムアウト値が61分となっていた、ことなどからです。

そこで、対策として下記の対応をしてます。
(1)FW側のSYNFloodProtectionのThresholdの設定を1ppsに変更
(2)同時セッション数についてもFWは256、LBを384に変更

しかしながら、(1)の設定でも1パケット/秒がLBに送られる事になりますので、
LBの無応答タイムアウト値をFWに合わせて変更できないと、無用なセッションが
滞留することには変わりがありません。

メーカーに確認すると、LBのタイムアウト値は61分固定で変更不可とのことで、
数値の根拠はブラウザ(IE5,6)のタイムアウトが60分だったから(IE7,8では
30秒になっていますが…)だそうです。

FWがタイムアウトになった際にRSTをLBに送信してくれれば問題ないのですが、
それも仕様上不可とのこと。

現状では、SYNパケットは1/sはLB側に送られる状況であり、万一攻撃を受けた
際は、そのセッションが滞留する事になります。LBのタイムアウト値61分から
算出すると、LBの同時接続数を3660に設定しておかないと、SYNFloodに対抗
できない事となり、その設定をしたとしても実際のところLBのサーバの性能上
受け切れるのか、また、WEBサーバ自身もさばき切れるのか、など現実味のあ
る対応とは思えません。

そこで、セッション監視スクリプトでも作ってLB側に設置し、最大同時接続数
に達した場合は、LBを強制再起動させるしかないのでは、と考えています。(★)

そこで質問なのが、上記★を付けた部分が正しいかどうか、という点です。

また、FW側がRSTを送信してくれないのは、一般的なFWの仕様なのか、たまた
ま利用しているFW(外部サービスです)の仕様の問題なのでしょうか?

何かご存じのことがあればご教授いただけると助かります。

どうぞよろしくお願いします。

SYNFlood攻撃を回避する方法を教えてください!

ネットワーク初心者です。

会社で運用しているサーバが先日アクセス不可になりました。
FWのログが得られなかったため、詳細は分からないのですが、おそらくSYNFlood
だったのでは?との結論に至っており、今後の対策を進めているところです。

その中で、(1)上記の結論が正しいのか、(2)打てる対策は他にないのか、について
何かアドバイスをいただければと思い、質問させていただきます。


サーバ構成としては、下記のようになっております。
FW ⇒ LB ⇒ WE...続きを読む

Aベストアンサー

 追加補足(3)拝見しました。解釈されている通りかと存じます。Unixサーバでのiptables記述でのTCPアクセス制限ですね。L3スイッチやL2スイッチ、ルーターでのQOS、VLAN等での帯域制限はレスポンスの低下効果がありますので、総合的な判断をしますと何とも言えませんが、レスポンスと可用性等も考えると、専用セキュリティ・ゲートウェイでの運用ですね。

QWEBサーバがFINを返さないようのですが…

FW-LB-Web×2台 の構成でサーバ構築、運用しています。

WebサーバはApacheです。
バージョンは今正確にわかりませんが、2.2だったように記憶しています。

Webサーバのログに200ステータスとして記録されている通信において、
LBからのFINに対してWebサーバがFINを返さないケースは何に起因する
と考えられるでしょうか。
また、その原因を調べる方法は何かありますでしょうか。
tcpdumpを使ってもWebサーバにはLBのIPが残らないので、問題究明
に時間がかかりそうで、他にも方法がないのか、と質問させていただ
いています。

質問の背景は下記のとおりです。
サイト監視サービスでエラーが発生するのでその原因を調査しています。
その中で、通信終了後にLBからFINを受けたWEBサーバがLBにFINを
返さないケースがある事がわかりました。
ただし、監視サービスからのアクセスに対しては毎回FINを返していない
ようですので、上記問題の原因ではないと思っています。

また、監視サービスからのHTTP1.1アクセスに対してのみFINが返って
いないようで、一般的なアクセス(ブラウザからの)の場合は返している
ようなのです。

監視サービスでは、GETコマンドをつかって直接(ブラウザを使わず)
アクセスしているようです。


以上何かお気づきの点があれば教えていただければと思います。

FW-LB-Web×2台 の構成でサーバ構築、運用しています。

WebサーバはApacheです。
バージョンは今正確にわかりませんが、2.2だったように記憶しています。

Webサーバのログに200ステータスとして記録されている通信において、
LBからのFINに対してWebサーバがFINを返さないケースは何に起因する
と考えられるでしょうか。
また、その原因を調べる方法は何かありますでしょうか。
tcpdumpを使ってもWebサーバにはLBのIPが残らないので、問題究明
に時間がかかりそうで、他にも方法がないのか、と質問させていた...続きを読む

Aベストアンサー

こんちす
乙です

ロードバランサはBIG-IPとALTEONとIP-COMの
三機種実務経験あります。

(1)WebサーバにはLBのIPが残らないので
これは見方を変えた方がいいです。
Webサーバの通信は全てLBが送信・受信しています。

(2)Apacheに不具合があるとは思えません(多分)

(3)LBの設定が誤っている

(4)LBの設定は正しいがLBにバグがある

(5)理由は明確にはないですが、Webサーバを
 1台停止させて、同じ現象が起きるか
 見てみる

QWiresharkでみるときの、1回のパケット

Wiresharkでみるときの、1回のパケットを追う方法を探してます。

TCP通信にて、通信確立後にデータのやり取りをしている通信を数時間tcpdumpにて取得し、
Wiresharkで流れをみています。そのときに、1回のデータのやり取りと見るために方法を教えてください。


クライアントからのリクエストとサーバからのレスポンスで、

1回目クライアントからデータ送信し、
複数かいやり取りして、終了(200 OKを返却して)

2回目クライアントからデータ送信し、
複数かいやり取りして、終了(200 OKを返却して)

という動作を繰り返してますが、

この1回目がここからここまでのパケット、2回目がここからここまでのパケットと知りたいのです。

なんとなくみると、ストリームNoなどもありますが、
ストリームNoが1回の通信後とのNoかとおもったら、
ストリームNoでフィルタしたら、
1回目5回目8回目・・と複数回のものが同じストリームNoであり、
どうゆうことだとうと疑問になってます。

詳しい方よろしくお願いします。

Aベストアンサー

No1です。
>TCPストリーム単位でも複数のやりとりがあるのか?わからなくて悩んでます。

昔のHTTP/0.9というプロトコルでは、リクエストに対してレスポンスがあればそれでストリームを終わらせてましたが、現在のHTTP/1.1では1つのTCPストリームで複数のリクエストーレスポンスを行うのが普通です。
また、レスポンスを待たずに複数のレスポンスを続けて投げることも可能です。

Qpingのポート番号

毎々お世話になっております。
サウナマンです。

会社の同僚(プログラマー)に
ねーねーPingのポート番号っていくつだっけ?
ときかれました。
よく、ポートのことを理解していない上での
質問だと思いますが、いったい何番にリクエスト
されるのでしょうか?
ご存知でしたらご教授、参考URLなど
いただけますでしょうか。
よろしくお願いいたします。

Aベストアンサー

単刀直入に回答しますと。

PINGには、ポート番号はありません。
ICMPプロトコルを使って、
「おーーーい、お茶」
じゃなかった
「おーい、300.300.300.300のぱそこーーーーん!!」
(IPアドレスは存在できないものを表記しています)
または
「おーーーーい、mail.exsample.comーーーーーー」
という風に呼びかけるために使います。

よく会社では上司が部下に対して
「○○君・・ちょっと」
というシーンがありますが、
そんな感じです。

で、ポート番号とはなんぞや
という話なんのですが、
いわゆる扉のようなものです。
複数のパソコンが、臨機応変に識別できるように
番号をつけるわけです。
ブラウジングとかメールを見たりするかと思うのですが、
まさにその時に活躍します。

TCP/IP版
パソコン「あ、メールを見る指示がでた。えーと、僕は2012番の扉から
     相手の110番の扉に、指示書を送ればいいのか」
メールサーバ「ん?、パソコンの2012番から俺の110番あてに何かきた
       ん?、通路を作ってほしい。ふむふむ、よし。」
(ここで、バーチャルサーキットという架空の道が結ばれ、この通路で
 通信が確立される)
パソコン「えー、ユーザ名・パスワードはこちらです」
メールサーバ「はい。OKです。データを送ります」
等の会話が行われます。
電話のようなものですね^^;

こんなメールソフト聞いたことありませんが(笑)
UCP/IP版
パソコン「はい、俺は2012番あけるから、110番で受け取って」
サーバ「ん、あい・・って、ちょっと」
パソコン「はい、ユーザ名とパスワードはこれ」
サーバ「って、おいおい・・・」
というすごいたとえが悪いですけど・・・・
はがき、郵便物のような感じです。

Pingにはポート番号使いませんし、
ポート番号を使う場合は
ブラウザやメールソフトなどの、
データを流す、受け取る作業が必要な
アプリケーションが、仕事を確実に行うために
ポート番号というもので、見分けます。

単刀直入に回答しますと。

PINGには、ポート番号はありません。
ICMPプロトコルを使って、
「おーーーい、お茶」
じゃなかった
「おーい、300.300.300.300のぱそこーーーーん!!」
(IPアドレスは存在できないものを表記しています)
または
「おーーーーい、mail.exsample.comーーーーーー」
という風に呼びかけるために使います。

よく会社では上司が部下に対して
「○○君・・ちょっと」
というシーンがありますが、
そんな感じです。

で、ポート番号とはなんぞや
という話なんのですが、
...続きを読む

QTCPヘッダのチェックサム算出方法

TCPヘッダのチェックサム算出方法について
1.算出方法はIPヘッダと一緒か?

2.一緒なら
unsigned short CalcCheckSum(unsigned short*lpData,/* (in)チェックサム算出文字列の先頭アドレス */
intiDataLen)/* (in)チェックサム算出文字列長 */
{
unsigned longlCheckSum = 0;

while(iDataLen > 1)
{
lCheckSum += *lpData++;
iDataLen -= 2;
}

if(iDataLen)
{
lCheckSum += *(unsigned char *)lpData;
}

lCheckSum = (lCheckSum & 0xFFFF) + (lCheckSum >> 16);
lCheckSum = (lCheckSum & 0xFFFF) + (lCheckSum >> 16);

return((unsigned short)~lCheckSum);
}
でまちがいないか?

3.オプションが追加されるときはそこも算出対象になるのか?教えていただけないでしょうか?
よろしくお願いします。

TCPヘッダのチェックサム算出方法について
1.算出方法はIPヘッダと一緒か?

2.一緒なら
unsigned short CalcCheckSum(unsigned short*lpData,/* (in)チェックサム算出文字列の先頭アドレス */
intiDataLen)/* (in)チェックサム算出文字列長 */
{
unsigned longlCheckSum = 0;

while(iDataLen > 1)
{
lCheckSum += *lpData++;
iDataLen -= 2;
}

if(iDataLen)
{
lCheckSum += *(unsigned char *)lpData;
}

lCheckSum = (lCheckSum & 0xFFFF) + (lCheckSum >> 16);
lCheckSum = (lCheck...続きを読む

Aベストアンサー

これ参考になりませんか。

参考URL:http://www.f4.dion.ne.jp/~adem/rfc/rfc793.euc.txt


このQ&Aを見た人がよく見るQ&A

人気Q&Aランキング