Java : Nagleアルゴリズムで遅延するの？

Question

初学者です。不十分な知識で僭越ながら質問させてください。よろしくお願いします。

実現したいこと

Javaのソケット通信において, 勉強と動作確認のため, Nagleアルゴリズムによる遅延をわざと発生させたいです.

現在は1sごとに4byteクライアント側から送信しており, クライアント側送信時刻とサーバ側送信時刻をコンソールで見ています.

小さいデータを送信するとNagleバッファに入り, 送信時刻と受信時刻に200ms程の差異が現れると思うのですが, 現在ほぼ時間の差異はありません.

Nagleアルゴリズムによる遅延はどうすれば発生するのでしょうか？ ご教授お願い致します.

該当のソースコード

参照元コード　https://oshiete.goo.ne.jp/qa/7317690.html

サーバ側

public class Server {
	public static ServerSocket ss = null;
	public static Socket soc = null;
	private static InputStream is = null;
	private static OutputStream os = null;

	public static void main(String[] args) {

		try {
			// サーバソケット生成
			ss = new ServerSocket(5000);
			soc = ss.accept();
			is = soc.getInputStream();
			Thread rcvTh = new ServerRcvThread(is);
			rcvTh.start();
			// 10秒スリープ
			try {
				Thread.sleep(10000);
			} catch (Exception e) {
				e.printStackTrace();
			}
			// スレッド停止
			rcvTh.stop();
		} catch (IOException e) {
			e.printStackTrace();
		} finally {
			try {
				is.close();
				soc.close();
				ss.close();
			} catch (IOException e) {
				e.printStackTrace();
			}
		}
	}
}
class ServerRcvThread extends Thread {
	private static InputStream ins = null;

	ServerRcvThread(InputStream is) {
		this.ins = is;
	}

	public void run() {
		DateFormat format = new SimpleDateFormat("yyyy MM dd hh:mm:ss.SSS");
		byte rcvData[] = new byte[16];
		int size = 0;
		try {
			while (true) {
				// データ読込み
				size = ins.read(rcvData);
				System.out.println("size:" + size + "byte" + " 受信時刻 = " + format.format(new Date()));
			}
		} catch (IOException e) {
			e.printStackTrace();
		}
	}
}

クライアント側

public class Client {
	private static Socket soc = null;
	private static OutputStream os = null;
	private static InputStream is = null;

	public static void main(String[] args) {
		try {
			// ソケット生成
			soc = new Socket("127.0.0.1", 5000);
			soc.setTcpNoDelay(false);  //明示的にNagleアルゴリズムオン
			os = soc.getOutputStream();
			Thread sndTh = new ClientSndThread(os);
			sndTh.start();
			// 10秒スリープ
			try {
				Thread.sleep(10000);
			} catch (Exception e) {
				e.printStackTrace();
			}
			// スレッド停止
			sndTh.stop();
		} catch (IOException e) {
			e.printStackTrace();
		} finally {
			try {
				is.close();
				os.close();
				soc.close();
			} catch (IOException e) {
				e.printStackTrace();
			}
		}

	}
}

class ClientSndThread extends Thread {
	private static OutputStream ous = null;

	ClientSndThread(OutputStream os) {
		this.ous = os;
	}

	public void run() {
		DateFormat format = new SimpleDateFormat("yyyy MM dd hh:mm:ss.SSS");
		byte sndData[] = new byte[4];
		sndData[0] = 0x04;
		sndData[1] = 0x03;
		sndData[2] = 0x02;
		sndData[3] = 0x01;
		try {
			while (true) {
				// データ書込み
				ous.write(sndData);
				ous.flush();
				System.out.println("データ送信" + " 送信時刻 = " + format.format(new Date()));
				// 1秒スリープ
				try {
					Thread.sleep(1000);
				} catch (Exception e) {
					e.printStackTrace();
				}
			}
		} catch (IOException e) {
			e.printStackTrace();
		}
	}
}

コード改修(11.22)

サーバ側

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.ServerSocket;
import java.net.Socket;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;

public class Server
{
    public static ServerSocket ss = null;

    public static Socket soc = null;

    private static InputStream is = null;

    private static OutputStream os = null;

    public static void main(String[] args)
    {

        try
        {
            // サーバソケット生成
            ss = new ServerSocket(5000);
            soc = ss.accept();
            soc.setTcpNoDelay(true);
            is = soc.getInputStream();
            os = soc.getOutputStream();

            DateFormat format = new SimpleDateFormat("yyyy MM dd hh:mm:ss.SSS");
            byte sndData[] = new byte[4];
            sndData[0] = 0x01;
            sndData[1] = 0x02;
            sndData[2] = 0x03;
            sndData[3] = 0x04;

            while (true)
            {
                byte rcvData[] = new byte[16];
                int size = 0;
                // データ読込み (受信するまで待つ)
                for (int tmp = 0; tmp <= 1; tmp++)
                {
                    size = is.read(rcvData);
                    System.out.println("データ受信。サイズ : " + size + "byte. 送信時刻 = " + format.format(new Date()));
                    if (size == 8)
                    {
                        break;
                    }
                }
                // clientからの送信が200ms遅延してる. ACK遅延により返答も200ms遅延
                // 上記要因を踏まえて３回目以降のトリガー
                os.write(sndData);
                os.flush();
                System.out.println("データ送信" + " 送信時刻 = " + format.format(new Date()));
            }
        }
        catch (IOException e)
        {
            e.printStackTrace();
        }
        finally
        {
            try
            {
                is.close();
                os.close();
                soc.close();
                ss.close();
            }
            catch (IOException e)
            {
                e.printStackTrace();
            }
        }
    }
}

クライアント側

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.Socket;
import java.net.UnknownHostException;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;

public class Client1 {

	public static void main(String[] args) {

		Thread client = new ClientThread();
		client.start();
		try {
			//Thread.sleep(1000);
			client.join();
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}

class ClientThread extends Thread{
	private static Socket soc = null;
	private static OutputStream os = null;
	private static InputStream is = null;

	public void run() {
		try {
			// ソケット生成
			soc = new Socket("172.23.56.83", 5000);
			soc.setTcpNoDelay(false);
			is = soc.getInputStream();
			os = soc.getOutputStream();

			DateFormat format = new SimpleDateFormat("yyyy MM dd hh:mm:ss.SSS");
			byte sndData[] = new byte[4];
			sndData[0] = 0x04;
			sndData[1] = 0x03;
			sndData[2] = 0x02;
			sndData[3] = 0x01;

			for (int cnt = 0; cnt <10; cnt++) {
				// １回目送信（即送信される）
				os.write(sndData);
				os.flush();
				System.out.println("データ送信" + " 送信時刻 = " + format.format(new Date()));
				// 0.01秒スリープ
				try {
					Thread.sleep(10);
				} catch (Exception e) {
					e.printStackTrace();
				}
				// ２回目送信（１回目のACKが遅延ACKにより200ms遅延)
				// 加えてNagleにより送信も200ms遅延
				os.write(sndData);
				os.flush();
				System.out.println("データ送信" + " 送信時刻 = " + format.format(new Date()));

				byte rcvData[] = new byte[16];
				int size = 0;
				// データ読込み
				size = is.read(rcvData);
				System.out.println("データ受信。サイズ : " + size + "byte. 送信時刻 = " + format.format(new Date()));
			}
		} catch (UnknownHostException e1) {
			e1.printStackTrace();
		} catch (IOException e1) {
			e1.printStackTrace();
		} finally {
			try {
				is.close();
				os.close();
				soc.close();
			} catch (IOException e) {
				e.printStackTrace();
			}
		}
	}
}

結果

Nagleオンの場合
データ受信。サイズ : 4byte. 送信時刻 = 2019 11 22 01:05:20.537
データ受信。サイズ : 4byte. 送信時刻 = 2019 11 22 01:05:20.584
データ送信 送信時刻 = 2019 11 22 01:05:20.584
データ受信。サイズ : 4byte. 送信時刻 = 2019 11 22 01:05:20.584
データ受信。サイズ : 4byte. 送信時刻 = 2019 11 22 01:05:20.631
データ送信 送信時刻 = 2019 11 22 01:05:20.631
データ受信。サイズ : 4byte. 送信時刻 = 2019 11 22 01:05:20.631
データ受信。サイズ : 4byte. 送信時刻 = 2019 11 22 01:05:20.678
データ送信 送信時刻 = 2019 11 22 01:05:20.678
データ受信。サイズ : 4byte. 送信時刻 = 2019 11 22 01:05:20.678
データ受信。サイズ : 4byte. 送信時刻 = 2019 11 22 01:05:20.724
...

Nagleオフの場合
データ受信。サイズ : 8byte. 送信時刻 = 2019 11 22 01:22:21.897
データ送信 送信時刻 = 2019 11 22 01:22:21.897
データ受信。サイズ : 4byte. 送信時刻 = 2019 11 22 01:22:21.900
データ受信。サイズ : 4byte. 送信時刻 = 2019 11 22 01:22:21.901
データ送信 送信時刻 = 2019 11 22 01:22:21.901
データ受信。サイズ : 4byte. 送信時刻 = 2019 11 22 01:22:21.901
データ受信。サイズ : 4byte. 送信時刻 = 2019 11 22 01:22:21.917
データ送信 送信時刻 = 2019 11 22 01:22:21.917
...

環境

OS : win10
JDK : 1.8
IDE : eclipse

サーバとクラインアントは同一ホストで行なってました。

Comments

[dameo]

試してないので適当なこと言いますが、同一ホストでもわざわざ遅延させたりするのです？
それとも実際に試すときにはIP変えているのでしょうか？

[Rai_Feit]

Nagleがどのように機能して、どのように遅延を発生させるのか知りたいです。

テストコードを実験してる時は、同一ホストで行なっておりました。
同一ホストで通信させる場合、遅延は発生しないのでしょうか

[dameo]

環境も書いてないし、細かいところは知りません。内容そのものは理解して実施しているのでしょうか？

[Rai_Feit]

環境を追記しました。足りなければご教授願います。

調べた上で、MSS以下且つjavaのデフォルトバッファサイズ以下なら遅延が発生すると考えていました。

[dameo]

元々の目的が1バイトを送信するのに必要な通信オーバーヘッドを減らす目的なので、実際には回線上の通信が発生しない同一ホスト間の通信では、これらの遅延を発生させる理由がないと思いますよ。実際に起こるはずの遅延が見られないのであれば、同一ホストではないと考えていいのではないでしょうか？

ただし、ロジックが正しければの話ですが…

[Rai_Feit]

なるほどですね。
同一ホストでは、遅延させる意味もないのでOS側？が自動で最適化してくれている可能性に気付きませんでした。ご丁寧にありがとうございます。

回線上での通信を発生させる検証をした上で、報告いたします。

[dameo]

本当は実際にやってみるまで黙っていたかったのですが、こちらの時間の都合もあるので、先に懸念点だけ伝えておきます。
(1)クライアント側で送信間隔を1000msで待っているが、元のコードでは10msで待っている。NagleアルゴリズムではACK未受信の送信パケットがあった場合バッファされるが、1000msもACK未受信のケースなんてあるのだろうか？
なお、普通WindowsのTCP遅延ACKのタイムアウトは200msで、LinuxのTCP遅延ACKのタイムアウトは40ms。
(2)最大フレームはどうせ十分長いとはいえ、連続して送ればそれなりに貯まるケースもあり、事前に計算したりしているのかも不安。
ちなみにクライアントは全部送信にしなくても、2回送信して1回受信とかのシーケンスにすれば最大フレームを確実に越えないように実装出来る。
(3)現状送信時刻と受信時刻を比較する想定になっているが、異なるマシンで時間がそこまで正確には一致しないので、同じマシンで送信時刻の間隔か、受信時刻の間隔で遅延を確認すべき。

ご報告お待ちしています。

[Rai_Feit]

懸念点感謝いたします。
知識不足なりに上記懸念点を私の可能な限り考慮したうえで再実験してみました。
コードの変更点は下記で付け焼き刃なので, これから調整するつもりですが, 取り急ぎ報告させていただきます。
(1), (2)クライアント、サーバそれぞれ送受信対応
(1), (2)クライアント側の送信間隔1000ms →10ms, サーバ側送信間隔200ms
ACKを200ms間隔で返すことにより送信バッファのクリアかつNagleアルゴリズム発生条件のうちの”ACK未受信なし”を回避するためある程度ACK未受信を溜める
(3)受信側の受信間隔と受信サイズで確認
を加えたうえで検証しました。

On
size:4byte 受信時刻 = 2019 11 21 11:44:30.674
size:12byte 受信時刻 = 2019 11 21 11:44:30.714
size:16byte 受信時刻 = 2019 11 21 11:44:30.774
size:8byte 受信時刻 = 2019 11 21 11:44:30.821
size:12byte 受信時刻 = 2019 11 21 11:44:30.874

OFF
OFF
size:8byte 受信時刻 = 2019 11 21 11:42:13.963
size:4byte 受信時刻 = 2019 11 21 11:42:14.000
size:4byte 受信時刻 = 2019 11 21 11:42:14.016
size:4byte 受信時刻 = 2019 11 21 11:42:14.032
size:4byte 受信時刻 = 2019 11 21 11:42:14.047

Nagleバッファに入ってまとめて送られてきているのと少しの遅延を確認できています。
今後追加でコードの編集と確認を行いたいと思います。

[dameo]

「サーバ側送信間隔200ms」がなんなんだろうと気になってしまいますが、とりあえずコードをお待ちしますね。
こちらは急いでるわけではなくて、単にまとまった時間が取れないときがあるので、問答が多くなると回答に時間がかかってしまうことになり、質問者さんの作業進捗に影響すると思い、事前に伝えただけのことです。つまり「急がなくていいので、質問者さんのペースで進めてください」ということです。

[Rai_Feit]

ご配慮感謝いたします。
「「サーバ側送信間隔200ms」がなんなんだろうと気になってしまいます」とご指摘いただいた通り, 実際にコードを編集する中で理解が浅い部分があります。
そこで, この質問タイトルとは関係ないと思い質問をためらっていたのですがご教授ください。
懸念点（２）で「ちなみにクライアントは全部送信にしなくても、2回送信して1回受信とかのシーケンスにすれば最大フレームを確実に越えないように実装出来る。」と仰っていたのは, どういうことでしょうか？受信すればそこにACKが乗ってくるから、送信バッファがクリアされるということでしょうか？

[dameo]

wikipediaからの引用です。
https://ja.wikipedia.org/wiki/Nagle%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0
Nagleアルゴリズムは以下の条件がどれか1つでも成立するまで送信を遅延させる。
・未送信データが最大セグメントサイズ以上になる
・過去の送信パケットで ACK が未受信の物がなくなる（TCP遅延ACKに注意）
・タイムアウトになる

です。今回のプログラムでnagleでバッファリングされるのはクライアント側です。
一回目の送信はこれらの条件を満たさないので必ず送信されます。
二回目の送信からバッファリングされますよね。
なので、一回目の送信パケットに対するACKを受信してしまうか、タイムアウトする(多分200ms)か、バッファリング分の送信量が最大セグメントサイズを越える場合は、出てしまうわけです。遅延を見る際には最大限遅延してほしいので、クライアント側では2回目以降の送信で、タイムアウトする前に最大セグメントサイズを越えたくないわけです。もし、10msごとに送信する場合は、200msでタイムアウトする間に最大19回ほど送信できるわけで、およそ1452バイトだと仮定すれば十分なのですが、一回の通信バイト数と通信環境に依存する部分なので、確実にと考えると3回目以降を送らない方が確実です。では3回目をどうやって待つか？というと、サーバ側からのデータ受信待ちが一番合理的です。
サーバ側でクライアント側からの2回目のデータを受信してから、一度データを送信してあげることにすれば、nagleの条件がタイムアウトで満たされて2回目のデータをクライアント側が送信してくれた後にデータを返すことが出来ます。

すると、
クライアントが2回送信
サーバが1回送信
クライアントが2回送信
サーバが1回送信
...
というシーケンスを繰り返すことが一番合理的なクライアント側のnagleによる遅延確認方法だと思ったということです。
「最大フレーム」はうっかり使ってしまった用語ミスで、「最大セグメントサイズ」が正しいです。最大フレームは逆に長いデータを一気に送りたいときに考慮するものなので。

[dameo]

なお、2番目の条件である、
・過去の送信パケットで ACK が未受信の物がなくなる（TCP遅延ACKに注意）
は、サーバー側のACK送信がどれだけ待たされるか？に依存しています。
この遅延時間がクライアント側のnagleのタイムアウトより短いと、200ms待てないのですが、サーバ側がWindowsであれば、多分200msなのではないかと踏んでいます。数字の部分はネットで調べた値なので、未確認です。

[Rai_Feit]

質問にご丁寧に回答をくださりありがとうございます。
昨日の回答を受けたうえで実験してみたコードと結果を本文に載せました。
Nagleは40~50ms程機能しているように思えますが, 200msとはなりません。
僭越ながら間違いがあればご指摘お願いいたします。
個人的には, サーバー側のACK遅延が40ms程なのではないかと疑っております。

[dameo]

そうですね。そんな感じに見えます。
他の質問でパケットキャプチャも提案されてましたよね？
この際鯖側のACKがいつ来てるのか確認されてみてはどうでしょう？

[Rai_Feit]

ありがとうございます。
まだ使い慣れないですが、おそらくこれが証拠になると思います↓
The RTT to ACK the segment was: 0.042699000 seconds

[dameo]

前後もう少し長めに欲しかったけど、キャプチャ開始から43msくらいであれば間違いないですね。
ということは、WindowsでもTCP遅延ACKのタイムアウトは40msなんですね。
あとはお時間のあるときにご自分で回答を書いて頂き、自己解決しちゃいましょう。
おめでとうございます。

[Rai_Feit]

本当に丁寧にお付き合いいただきありがとうございました。
感謝してもしきれません。問答も多くなってしまい申し訳なかったです。
バッジなどあまり興味はないのですが, これ以上お手を煩わせないように後で自分で書いてcloseしておきますね。

ありがとうございました。

[dodox86]

> Nagleは40~50ms程機能しているように思えますが, 200msとはなりません。
200m秒と決まっているわけではなくて、最大200m秒(規格上は500m秒)だからではないでしょうか。そういう話ではなくて？でしょうか。

[dodox86]

回答を一部、書いていたのですが、既に検証をされていて一定の結果を得られていたようでしたので、回答をやめました。大意としては「JavaだとInputStreamやOutputStreamでバッファリングされてしあい、細かくコントロールしづらいので、C言語でsend, readなどのシステムコールを直接使い、setsockoptでTCP_NODELAYを操作して試した方が良いのでは？」と言う程度のものでした。結論は得られたようですので、忘れてください。

[dodox86]

あと、ほぼ終わったところに今更恐縮ですが、タグの「Socket.IO」はNode.jsのものです。

[Rai_Feit]

dodoxさん別の質問でもお世話になりました。次いで考えてくださっていてありがとうございます。当方エンジニア歴一ヶ月のど素人ですかので、正しい情報ならいかなる情報もありがたいのです。Socket.IOはタグから消しました、ご指摘感謝します。

> 200m秒と決まっているわけではなくて、最大200m秒(規格上は500m秒)だからではないでしょうか。そういう話ではなくて？でしょうか。

ご教授頂いたWireSharkで、The RTT to ACK the segment was: 0.042699000 secondsとなっていたのでwin10のACK遅延が40msだということで腹落ちしましたが、初めて利用したので見方が間違っていた可能性もあるかなと思います。

Nagleのタイムアウトが一般的に200msで、環境によっては40msだったりする場合もあるのでしょうか？

[dodox86]

遅延が200msとまではならず、40msと短くて済んだ、ということなのではないかな、と思いました。

[dodox86]

エンジニア歴たった1ヶ月でこういったことに興味と疑問を抱き、かつ、調べられて一定の結果を出されることに感嘆しました。（すごい）

[Rai_Feit]

なるほどそういう見方もあるのですね。確かにソース元が日本語など言語(今回はwikiなど)である以上本来の意味は少なからず矮小化されるため人にとっては解釈の仕方が違ってくるのは当然のことですよね。
個人的には、ack遅延が40msをwiresharkで確認したためそちらが有力ですが、dodoxさんの説も否定できる材料はないのでclient側の送信をキャプチャするなどして追加検証の余地があります。(あいにく直ぐには検証できる環境に無いので、回答自体は前述の通り自己解決して一旦締めさせていただきますね)

>（すごい）
dodoxさんの足元にも及びません。
今後も何処かで見かけましたら助けてください！

Answer 1

端的に。同一ホスト間など通信回線を通さないsocket通信では、アプリケーションより下位層の働きでNagleアルゴリズムは機能しないので通信回線を通す。