- ベストアンサー
TCPヘッダにある確認応答番号とウィンドウサイズについて
はじめまして。 質問があります。 参考書によると、 送信側のトランスポート層で作られたセグメントを受信側の同層で 受け取ったとき、そのセグメントに付加されているTCPヘッダ内の 確認応答番号と、ウィンドウサイズは、受信側で書き込むらしいの ですが、どういうことなのでしょうか？もしかしたら、受信側が 送信側に送る確認応答のヘッダは、送信側でセグメントに付加した TCPヘッダを使いまわしているという解釈でよろしいのでしょうか？ わけがわかりません。どうかご教授お願いします。
- takeshix100
- お礼率74% (50/67)
- その他（インターネット接続・通信）
- 回答数1
- ありがとう数0
- みんなの回答 （1）
- 専門家の回答
質問者が選んだベストアンサー
＞受信側が送信側に送る確認応答のヘッダは、送信側でセグメントに付加した TCPヘッダを使いまわしているという解釈でよろしいのでしょうか？ 送信側が生成したシーケンス番号に1をプラスした番号を、応答確認番号として受信側は送信側に送り返しますので、そういった部分では「使いまわす」というか基準にしているという事はあります。 しかし、受信側も応答確認番号と共に、受信側で生成したシーケンス番号を送り返し、そのシーケンス番号に1をプラスした番号を応答確認番号として、送信側は受信側に送り返します。 ですから、一方通行ではなく送り手と受けてで、相互に同期と応答が確認できて初めて、コネクションが確立する事になるわけですから、ちょっと解釈が違うと思います。
関連するQ&A
- TCPでのACK確認応答のメカニズム
TCPでの通信では、3ウェイハンドシェイク後、データ送信とACK確認応答の返答をしあい信頼性のある通信を行うと思うのですが、あるテキストによるとネットワークの関係上、順番どおりにTCPセグメントが届かない場合があるとの事でした。 データ受信ホストが発するACK確認応答の中に次の送信のシーケンス番号が指定されているともありましたので、TCPセグメントが順番どおりに来ないと通信が上手くいかないと思うのですが、思い違いでしょうか？ このあたりのやり取りについて、教えて頂けないでしょうか？是非お願いします。
- ベストアンサー
- ネットワーク
- TCPヘッダのヘッダ長について
誰か知っていましたら御教示ください。 TCPヘッダのヘッダ長は，通常5または6を使用するものだと考えてました 7を使用するのは，どのような場合でしょうか？ なぜこのような質問するかは，以下のことをおこなって専用制御装置とPCでTCP/IPの通信が出来なくなっためです。 (1)PC側のOSを winNT→2Kへ変えたところ専用制御装置との通信断となりました。 (2)イーサアナライザで解析したらPCからのSYN送信にてTCPヘッダにおけるヘッダ長がNTの時は，6(24バイト)なのにwin2Kでは，7(28バイト)になった (3)専用制御装置側はTCPヘッダのヘッダ長7は，エラーと判定し通信しない設計になってました (4)PCのアプリはwinsockの単なるソケット通信 そのため，TCPヘッダを書き換えることはできません (5)おそらくOSがwin2Kになったことが原因だと思います。 win2KでwinNTの時のように SYN送信でTCPヘッダのヘッダ長を6にする方法は，あるのでしょうか？ 大変恐縮ですが誰か御回答ください。
- ベストアンサー
- Windows系OS
- IPヘッダの識別番号とTCPヘッダのシーケンス番号の違いってなんですか
ネットワークの勉強を始めたばかりのものです。質問文に不可解な文章があるかもしれませんが、ご了承ください。 私の読んでいる参考書で、識別番号は「MTUによってデータを分割配送する際に使用する」と書いてあり、シーケンス番号は「ある程度データサイズが大きい場合、MMSによってデータを固定長に分割し、分割の組み立てに使用する」とありました。 つまり、送信側がMMSによってデータをA・B・Cの３つに分解し、Aを送信したところ、MTUがAのデータ量以下だったので、Aをパケットで分割して送信し、受信側で組み立てる・・・という見解で合っていますか？ もし合っていた場合、「パケット１つが届いたよー」という確認応答は送信側に送られるのでしょうか？それとも確認応答はパケットの組み立てが終ってから送られるのでしょうか？
- 締切済み
- ネットワーク
- ＴＣＰ ウィンドウサイズ
大学での問題なのですが 「TCPエンティティ（実体）は、相手から教えてもらったウインドウサイズを無視して、大きなデータを送信した。通常このデータはバッファ溢れを起こす（取りこぼし）が、たまたま、相手側のアプリケーションの処理が進み、受信データよりもバッファの空き容量が大きくなった場合は、適切に相手のアプリケーションによって処理してもらえる。」 この記述は正しいか間違いかという問題なのですが、調べてもウィンドウサイズを無視するということに関する資料が見つからず、迷っています。 詳しい方、教えてください。
- ベストアンサー
- その他([技術者向] コンピューター)
- TCPのポート番号とマルチタスク
マルチタスクOSで複数のTCPセッションを同一のポートで開いた場合、 データの混同が起きないのはなぜでしょうか？ たとえば、WINDOWSで、FirefoxとIEを使い、複数のYoutube動画をポート８０で同時に受信できるのですが、なぜデータの混同が起きないのかがわかりません。 TCPヘッダ（もしくはUDPヘッダ）にセッション番号のようなものがあるわけではないので、NICに入ってきた段階では、そのTCPデータがどのタスクが必要としてるのかわからないと思うのですが・・。
- ベストアンサー
- ネットワーク
- 遅延確認応答について教えてください
マスタリングtcp/ipという本で勉強しております。 遅延確認応答において、なぜ２パケット受信してから応答を返せば受信バッファが空くのかわかりません。 > ■遅延確認応答 > データを受信したホストがすぐに確認応答をすると小さなウィンドウを返す可能性があります。 > 受信したばかりのデータで受信バッファがいっぱいになっているからです。 この問題を回避するため、実機では２パケット受信するか0.2秒程度待ってから確認応答を出すようになっているようですが、 ２パケット目を受信して応答を返しても受信バッファはいっぱいになったままではないでしょうか？ 1パケット分ACKを遅延させることによって何が変わるのでしょうか？ # ＡＣＫの数が減ってネットワーク効率が良くなる点は理解しております。
- ベストアンサー
- その他([技術者向] コンピューター)
- icmpヘッダ
icmpヘッダはipヘッダの前についてるとwikiに書いてありました。 ipヘッダの前にあるということはトランスポート層で付加している気もするのですが、 icmpプロトコルはネットワーク層ですよね？ このヘッダはどの層で付加されるのですか？
- 締切済み
- その他([技術者向] コンピューター)
- TCPのプログラミングで質問…というか確認しておきたいことが…
このたびＣ言語でネットワークプログラミング（ＴＣＰ）をしているのですが、気になったことがあったので、2点ほど質問させていただきます。 (1)WSock32のsendで一度に送信できる量は65535バイトと以前学んだのですが、受信側がrecvする前にどんどん65535バイト送信していったら受信側のソケットはどんどんいっぱいになってしまいますよね？その場合、限界はあるのでしょうか？また、一度にrecvできる量も65535バイトが限界なのでしょうか？もしそうだとしたら65535バイト以上データがあると取得しても残ってしまうんですか？ (2)sendで大きなデータなどを送信した場合、受信側でrecvしたときに途中までのデータを受信してしまったりすることってありますか？たとえば、「"abcde"と送信したのに対し、受信側でrecvしたらとりあえず"abc"まで受信し、次のrecvで残りのデータを受信する」様なことってあるんでしょうか？ すべてのデータがちゃんと送信されてからじゃないとrecvで取得することはできなくなっているんでしょうか… とてもとても分かりにくい文章で本当にすみません。 すべてとはいいません、少しでも情報があれば教えていただけませんでしょうか・・・ どうぞよろしくお願いいたしますm(_ _)m
- ベストアンサー
- C・C++・C#
- ＦＡＸの受信時刻を知る方法
通常ＦＡＸを受け取るとヘッダーの部分に、 送信側のＦＡＸ番号、日付、時刻などが印刷されると 思いますが、 これを受信側で付加して印刷することはできないでしょうか？ 要は受信日時を知りたいのです。 送信側がヘッダーを設定していないことも多く、 ヘッダーは白紙になっていたりと困っています。 今使っているのはブラザーなんですが、 いろいろ調べてもこのような機能が付いている ＦＡＸが見当たりません。 無理な話なんでしょうか？ このような機能が付いているＦＡＸなどご存知でしたら、メーカ、型番など教えて下さい。 他にも受信時刻を知る方法があったら教えて下さい。
- 締切済み
- その他（生活家電）
- TCPとEthernetのデータの分割の役割
TCPのウィンドウ/フロー制御とethernetのフレームの分割についてご質問です。 書籍を読んでいると TCPはウィンドウ/フロー制御で、一度に送るセグメントサイズを調整しているとあります。 しかしEthernetもフレーム分割を行うとあります。 そうなると、どちらのプロコトルが主体的にデータを分割するのか本を読んでもいまいちわかりません。 例えば、TCPがウィンドウサイズを4500byteにして一度にデータを送信すると データリンク層のEthernetで、4500byteを1500byteずつに三分割するんでしょうか？ だとすると、4500byteのデータを送った場合、TCP上では1つのセグメントを送信したことになり Ethernet上だと3つのフレームを送信したことになります。 それとも、TCPが4500byteのデータを送る場合 TCPがデータリンク層で一度に送信できるフレーム長を判断して TCP上で4500byteを一度に送信せずに、1500byteに分割してEthernetに送り Ethernetはその1500byteのデータを三回送信することになるんでしょうか？ わかりにくい質問で申し訳ありません。
- ベストアンサー
- ネットワーク
補足
chuhiremon様へ ご回答ありがとうございました。 わかりやすいご説明をありがとうございました。