遅延確認応答について教えてください
- 遅延確認応答について教えてください
- 遅延確認応答において、なぜ２パケット受信してから応答を返せば受信バッファが空くのかわかりません。
- この問題を回避するため、実機では２パケット受信するか0.2秒程度待ってから確認応答を出すようになっているようですが、2パケット目を受信して応答を返しても受信バッファはいっぱいになったままではないでしょうか？1パケット分ACKを遅延させることによって何が変わるのでしょうか？
- ベストアンサー
遅延確認応答について教えてください
マスタリングtcp/ipという本で勉強しております。 遅延確認応答において、なぜ２パケット受信してから応答を返せば受信バッファが空くのかわかりません。 > ■遅延確認応答 > データを受信したホストがすぐに確認応答をすると小さなウィンドウを返す可能性があります。 > 受信したばかりのデータで受信バッファがいっぱいになっているからです。 この問題を回避するため、実機では２パケット受信するか0.2秒程度待ってから確認応答を出すようになっているようですが、 ２パケット目を受信して応答を返しても受信バッファはいっぱいになったままではないでしょうか？ 1パケット分ACKを遅延させることによって何が変わるのでしょうか？ # ＡＣＫの数が減ってネットワーク効率が良くなる点は理解しております。
- その他([技術者向] コンピューター)
- 回答数4
- ありがとう数2
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
aha51 補足です ＞＞ パケット２つを受け取る時間＞＞＞受信バッファを処理し空きを作る時間 とするならば理解できるのですが・・・まったくわかりません。 パケットの時間は処理時間に比べると、気の遠くなるような長い時間です。 これ以上は実機にロジアナをつないで検証してください。
その他の回答 (3)
- acha51
- ベストアンサー率41% (436/1042)
acha51 補足です １．ACKを読んだ次のパケットを読み取った後、受信バッファーをクリアする。 ２．リングカウンター方式として一定数、たとえば0から31（DEC)をまわし 31の次は0に戻す、を繰り返し、ACKを読んだ次のパケットを読み取る 受信バッファーは一定値をぐるぐる回っている。 でしょうかね
補足
パケット２つを受け取る時間＞＞＞受信バッファを処理し空きを作る時間 とするならば理解できるのですが・・・まったくわかりません。
- acha51
- ベストアンサー率41% (436/1042)
acha51補足です 受信は不要データは読み捨てればよくバッファには最新のデータのみです。
補足
1パケット目受信 2パケット目受信（ACKを返す） 3パケット目受信 4パケット目受信（ACKを返す） １パケットおきにＡＣＫを返しても受信バッファはあふれたままではないでしょうか。 まったくわかりません・・・。
- acha51
- ベストアンサー率41% (436/1042)
２パケット目というのは受診側が確実に待ち受けになったと見るからでしょう。 実機で0.2秒は回線速度、受信側の処理能力や必要なタイミングを計って決めますが おおむね0.2としているのでしょう、機械ものが相手のときは、もっと待つことがあります。
補足
うーん、よくわかりません・・・ １パケット受信ごとにACKを返そうと、2パケット受信ごとに返そうと受信バッファは「パケットを受信したばかりでいっぱい」ではないのでしょうか。
関連するQ&A
- TCPでのACK確認応答のメカニズム
TCPでの通信では、3ウェイハンドシェイク後、データ送信とACK確認応答の返答をしあい信頼性のある通信を行うと思うのですが、あるテキストによるとネットワークの関係上、順番どおりにTCPセグメントが届かない場合があるとの事でした。 データ受信ホストが発するACK確認応答の中に次の送信のシーケンス番号が指定されているともありましたので、TCPセグメントが順番どおりに来ないと通信が上手くいかないと思うのですが、思い違いでしょうか？ このあたりのやり取りについて、教えて頂けないでしょうか？是非お願いします。
- ベストアンサー
- ネットワーク
- ソケット通信の送受信遅延-02 その後
前回のNo.1031658 「ソケット通信の送受信遅延」に追加させてもらいます その後、プロトコルアナライザで現状調査を行い以下の現象を確認しました ◇正常時 サーバがメッセージ送信 TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓ 0.2msec前後で クライアントが 返信 TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓ 10msecで サーバが送信 TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓ 0.2msec前後で クライアントが 返信 TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓ 以下繰り返り ◇不具合時 サーバがメッセージ送信 TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓ 0.2msec前後で クライアントが 返信 TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓ 10msecで サーバが送信 TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓ 約130msec前後で クライアントが 返信 TCPヘッダ内フラグ ACK:1, PSH:0 + 返信データなし ↓ 約250msec前後で クライアントが 返信 TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓ といった状況です どう解釈すれば良いのでしょうか 遅延の原因はソケットなのかそれ以外なのでしょうか？是非アドバイスをおねがいします。
- 締切済み
- C・C++・C#
- 情報通信の問題なのですが・・・
情報通信の問題なのですが・・・ 回線速度Ｃ（ビット/秒）の専用全２重回線を用いて、ホストＡからホストＢへ固定長ＬＤ（ビット）のパケットを stop-and-wait ARQプロトコルと呼ばれる以下の手順に従い伝送することを考える。 ホストＡはパケットを一つ送信した後、ホストＢからのＡＣＫを持つ。 もし、送信後、タイムアウト時間Ｔ（秒）以前にＡＣＫを受信すれば、直ちに次のパケットの送信を行う。 一方、送信後、タイムアウト時間ＴまでにＡＣＫを受信しなければ、送信は失敗したとみなし、再送する。 ホストＡは先行するパケットに対するＡＣＫを受信するまで後続のパケットの送信を開始しないことに注意する。 他方、ホストＢはパケットを正しく受信した場合、直ちにホストＡへ固定長ＬＡ（ビット）のＡＣＫを送信する。 また、受信したパケットに誤りがある場合はそれを破棄する（ＮＡＫは送信しない） なお、誤り検査に必要な時間は無視できると仮定する。 ホストＡとホストＢの間の往復伝播遅延をＲ（秒）とする。 ホストＡから送信された任意のパケットに対するＡＣＫをホストＡが受信する確率を1-ｐ（0＜ｐ＜1）として、以下の問いに答えよ。 （i）ホストＡがパケット送信後、タイムアウトが起こる前に、送信したパケットに対するＡＣＫを受信したとする。 このとき、ホストＡがこのパケットの最初のビットを送信してからＡＣＫの最後のビットを受信するまでの時間Ｓ（秒）を求めよ。 Ｔ＞Ｓと仮定する。 （ii）ホストＡが一つのパケットの送信を開始してから最終的にＡＣＫを受け取るまでに必要な時間の平均Ｈ（秒）を、 Ｓ、ｐならびに以下で求められるＦを用いて表せ。 Ｆ＝ＬＤ/Ｃ+Ｔ （iii）ホストＡには常に送信待ちパケットがあると仮定する。 このとき達成される最大スループットθをＨを用いて表せ。 ただし、スループットとは１秒当たりの平均送信成功パケット数を指す。 どなたかご解答をよろしくお願いします
- ベストアンサー
- 情報処理技術者
- CR遅延回路について
CR遅延回路について お世話になります。遅延回路について質問があります。CMOSのイネーブルバスバッファ(4列)のイネーブル端子にCR遅延回路を入れています。C=2.2[μF],R=10[kΩ]にしており、バッファの電源5[V]からRとCを接続してイネーブル端子に入力しています。その状態でバッファの電源,イネーブル端子,出力信号を確認したところスパイク状のノイズのようなものが確認されました。スパイクノイズは0.5～1[V]程度となっており、電源が立ち上がった直後の位置に確認しました。遅延回路を入れない状態ではこのような現象は現れていませんでした。何が原因と考えられるのでしょうか?バッファICのラッチアップ現象なのでしょうか?また、どうすれば回避することができるのでしょうか(遅延回路を入れた状態で回避する方法)?ご回答お願いします。
- ベストアンサー
- 物理学
- TCPヘッダにある確認応答番号とウィンドウサイズについて
はじめまして。 質問があります。 参考書によると、 送信側のトランスポート層で作られたセグメントを受信側の同層で 受け取ったとき、そのセグメントに付加されているTCPヘッダ内の 確認応答番号と、ウィンドウサイズは、受信側で書き込むらしいの ですが、どういうことなのでしょうか？もしかしたら、受信側が 送信側に送る確認応答のヘッダは、送信側でセグメントに付加した TCPヘッダを使いまわしているという解釈でよろしいのでしょうか？ わけがわかりません。どうかご教授お願いします。
- ベストアンサー
- その他（インターネット接続・通信）
- パケットロスと遅延について
(1)パケットロスって何でしょうか？ (2)パケットロスが10%でも、回線品質は良くないのでしょうか？WAN間でも必ずパケットロスは0％でないと品質は良いとは言えないのでしょうか？ (3)パケットロスが発生しても、データは遅くても完全に届くものでしょうか？それともパケットロス分のみ捨てられて、相手に届くのでしょうか？ (4)パケットロスが発生すると、遅延も必ず起きているのでしょうか？ (5)パケットロスと遅延がネットワーク側に問題があると判明した場合、どのような措置を講ずるのでしょうか？ (6)TCPパケットはパケットロスがあると再送しますが、UDPパケットは再送しないで破棄されるのでしょうか？ 以上、ネットワークに精通されておる方、お願い申し上げます。
- ベストアンサー
- その他([技術者向] コンピューター)
- ネットワーク遅延について
お世話になります。 ご面倒かけますが、ご回答頂ければ助かります。 状況を説明させて頂きますと あるプログラム（計算して結果を出力）をネットワーク上で共有フォルダにアクセスして 実行しております。 (1)スタンドアローンで実行（自分のＰＣにプログラムを保存）すると、実行時間が1～2分 (2)ネットワークの共有フォルダにアクセスして実行した場合 5分～10分かかります。 ※できるだけマスタ配布のような業務が入る為、スタンドアローンでは利用しない方針です なぜこんなに実行時間に差がでるのかという質問を頂いてます。 ネットワーク上のプログラムを実行しているのですから、ある程度遅くなるのは 当たり前です。とは回答しているのですが、理解してもらえません。 ＷｉｒｅＳｈａｒｋを利用して、パケットを拾ったのですが ・ TCP Dup ACK ・ TCP Retransmission ・ TCP Previous segment lost 上記のようなパケットを拾いましたが、パケットを分割や再送信を行っているので 遅くなっていると話をしましたが、これがネットワークの問題なのかプログラムの問題か 確認（考え方）するにはどうしたらいいでしょうか？ 参考程度でも結構ですので、お願いいたします。
- ベストアンサー
- ネットワーク
- ｆｔｐ遅延
Windows2003サーバーの標準ftpからJP1/ftpサーバーへ、VPNを介して最大2MB程度のファイルを100～200個mput転送しています。2,3ヶ月に1回程度、転送遅延が発生します。Wiresharkでパケットキャプチャして調査したところJP1/FTPからのウインドウサイズが通常時32768バイトから1024バイトになっていました。さらに1024になった後、ftpクライアント側がACK受信後に5秒間waitしてから次のパケットを送信するような動きになっています。計ったように5秒ぴったりです。Windowsのftpクライアントがデータ転送を遅らせるような設定、仕様はないとの認識ですが何が原因として考えられるでしょうか？またどのような調査が有効でしょうか？ちなみにftpクライアント側のPCにはVPNクライアントやアンチウィルスソフトは稼動していません。
- 締切済み
- ネットワーク
- ping の結果を解説願います
192.168.101.101 に ping を送信しています 32 バイトのデータ: 192.168.101.4 からの応答: 宛先ホストに到達できません。 192.168.101.4 からの応答: 宛先ホストに到達できません。 192.168.101.4 からの応答: 宛先ホストに到達できません。 192.168.101.4 からの応答: 宛先ホストに到達できません。 192.168.101.101 の ping 統計: パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、 損失０％ってところも受信４ってところも意味が分かりません。宛先ホストに到達できないのなら損失１００％でないですか？ 解説お願いします。
- ベストアンサー
- ルーター・ネットワーク機器
お礼
連続でパケットを２つ受け取る場合でもバッファ処理時間の方が速い、もしくはそのような確率は低いので問題にならないのでしょうか。 入門本としてはそれなりの評価があるこの本にも、Googleで検索しても誰も言及すらしてないので、言わずともわかって当然な事なのでしょうか。自信がなくなります。