<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>MTU on Ingenboy.inc</title>
    <link>https://blog.ingenboy.com/tags/mtu/</link>
    <description>Recent content in MTU on Ingenboy.inc</description>
    <image>
      <title>Ingenboy.inc</title>
      <url>https://blog.ingenboy.com/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E</url>
      <link>https://blog.ingenboy.com/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E</link>
    </image>
    <generator>Hugo -- 0.152.2</generator>
    <language>en</language>
    <lastBuildDate>Fri, 19 Jan 2024 19:52:32 +0900</lastBuildDate>
    <atom:link href="https://blog.ingenboy.com/tags/mtu/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title> ロングファットパイプ、TCPダンプ</title>
      <link>https://blog.ingenboy.com/post/mtu_and_window_size/</link>
      <pubDate>Fri, 19 Jan 2024 19:52:32 +0900</pubDate>
      <guid>https://blog.ingenboy.com/post/mtu_and_window_size/</guid>
      <description>&lt;h1 id=&#34;事始め&#34;&gt;事始め&lt;/h1&gt;
&lt;p&gt;例のシステムで、tcコマンドでネットワークレイテンシーを増加させたんですけどね。
そしたら、たったの100msの遅延だったんですけど、64MiBのデータを送信するときに、
アプリから見た時の遅延の時間がなんと1sくらいまで伸びてしまったんですよね。これ、めちゃめちゃ面白い話で、深堀りする価値があるんです。
もしかしたら、ロングファットパイプ問題についても、わかるかもしれないね。&lt;/p&gt;
&lt;p&gt;まず、TCPの基礎、どうやって動いているのかを理解する必要がある。
が、せっかくなので、もう一回上からやろうか。
アプリケーションレイヤーから、どうやってデータが通信相手まで伝わるのか、ってのをもう一回確認して、
本題のTCPレイヤーのMTU,MSS,windowサイズについて話した後、tcpダンプの使い方を調べ、最後に実際にTCPダンプをして、
例のシステムにおいて、サーバ・クライアント間で100msの遅延が生じているときのデータのやり取りについてみてみましょう。&lt;/p&gt;
&lt;h1 id=&#34;osiモデルプロトコルスタックについて確認&#34;&gt;OSIモデル、プロトコルスタックについて確認&lt;/h1&gt;
&lt;p&gt;まず、プロトコルスタックとは「コンピュータネットワーク用のプロトコルの階層」のことです。
OSIモデル(7層) で見ていくのが大事そうですね。上から、アプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、データリンク層、物理層。&lt;/p&gt;
&lt;p&gt;アプリケーション層では、具体的なサービスを提供。HTTPとか、websocketとか、FTPとか、SSHとか、その他いろいろ。&lt;/p&gt;
&lt;p&gt;プレゼンテーション層は、データのフォーマットを定義する？そうですね。エンコードの方法とか。これはおそらくまだOSレイヤーの話ではない。&lt;/p&gt;
&lt;p&gt;ここからがOSの世界の話。
セッション層は、connect(sockdrp,IP)で、コネクションを確立したときに、コネクションの相手を覚えておく層、だと思っていい。
つまり、ソケットのことです。ソケットが通信相手の情報を覚えておきます。
ソケットは、OSによってプログラムのされ方が違うらしいです。それでも異なるOS同士ど通信ができるのは、トランスポート層で規定されているプロトコルにすべてのOSが準拠しているからです。&lt;/p&gt;
&lt;p&gt;トランスポート層 (L4) が、TCP / UDP です。TCPでは、アプリケーションからもらったデータを小分けにして、通し番号を付けて、
小分けにしたデータをちょっとづつ送ります。小分けにされたデータが、いわゆる「パケット」です。
再送とかもする。信頼性が高いのです。その代わりスループットは悪くなります。
一方、UDPはデータを投げっぱなしにします。信頼性は低いですが、スループットは高くなります。VoIPなどに使われますね。
L4ではまだ、IPは指定しません。&lt;/p&gt;
&lt;p&gt;その下、ネットワーク層が、IPです。ルーティングを決めてくれます。&lt;/p&gt;
&lt;p&gt;その下、データリンク層が、イーサネットですね。L2TPとかをするVPN、ありますよね。あれはね、このレイヤーで動いているんですよね。&lt;/p&gt;
&lt;p&gt;その下、もう物理層です。L1です。&lt;/p&gt;
&lt;h1 id=&#34;l4トランスポート層のtcpについてもう少し詳しく見ていく&#34;&gt;L4、トランスポート層のTCPについてもう少し詳しく見ていく&lt;/h1&gt;
&lt;p&gt;まずは、TCPヘッダーのフォーマットを見てみましょう。&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;送信元ポート番号：16bit
送信先ポート番号：16bit
シーケンス番号：32bit
ACK番号：32bit
データオフセット：4bit
未使用：6bit
コントロールビット：6bit
ウインドウ：16bit
チェックサム：16bit
緊急ポインタ：16bit
オプション：可変長
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;いろいろありますが、ここでまず注目したいのは、通信相手のIPアドレスがないってことですね。
なぜなら、それはL3が担当するからです。
その他、自分的にまだ理解が完ぺきではないけど大事そうなのは、シーケンス番号、ACK番号、コントロールビット、
ウィンドウの、４つですね。それぞれについて説明していきます。&lt;/p&gt;
&lt;h2 id=&#34;シーケンス番号&#34;&gt;シーケンス番号&lt;/h2&gt;
&lt;p&gt;「このパケットの先頭のデータが送信データの何バイト目にあたるのか送信側から受信側に伝えるためのもの」
TCPではデータを小分けにして送りますね。パケットです。で、何バイト目か？って話ですね。32bitしかないってことは、
2^32/1024/1024/1024 = 4GiBしか一回で送れないってこと？まじ？？まあいいや。そんなことはないと思うけどね。&lt;/p&gt;
&lt;h2 id=&#34;ack番号&#34;&gt;ACK番号&lt;/h2&gt;
&lt;p&gt;「データが何バイト目まで受信側に届いたのか、受信側から送信側に伝えるためのもの。」だそうです。&lt;/p&gt;
&lt;h2 id=&#34;コントロールビット&#34;&gt;コントロールビット&lt;/h2&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;URG:緊急ポインタ
ACK:データが正しく受信側に届いたことを意味する
PSH:FLUSH動作によって送信されたデータである
RST:接続を強制的に終了：異常終了
SYN:送信側と受信側で連番を確認しあう。これで接続どうさを表す
FIN:切断
&lt;/code&gt;&lt;/pre&gt;&lt;h2 id=&#34;ウィンドウ&#34;&gt;ウィンドウ&lt;/h2&gt;
&lt;p&gt;「受信側から、送信側にウィンドウサイズ (受信確認を待たずにまとめて送信可能なデータ量) を通知するために使う。」
これが16bitであるのが、もんだいなんですよ！！&lt;/p&gt;
&lt;p&gt;以上を念頭に次に進みます。&lt;/p&gt;
&lt;h2 id=&#34;tcpが接続を開始してデータを送信し切断するまで&#34;&gt;TCPが接続を開始して、データを送信し、切断するまで&lt;/h2&gt;
&lt;p&gt;はい。一言でいうと、
「TCPはスループットを犠牲に、信頼性を高めた通信プロトコル」です。
信頼性を高めるために、されている工夫が２つあるんですね。それが、
3ウェイハンドシェイクと、パケット送信時の受け取り確認です。
（UDPはスリーウェイハンドシェイクも、受け取り確認もしない）&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
