QoSレベル1がMQTTに設定されている場合、PUBACK再送信の理由は何ですか？

MQTTをテストするために、ブローカーはモスキートを使用しました。パブリッシャーとサブスクライバーはpahoライブラリーを使用しました。

パブリッシャからブローカまで、ペイロードサイズが1000バイトのメッセージを連続して送信する実験は、に進んでいます。

パブリッシャーでQoSレベルを1に設定し、ブローカーにデータを送信したときに、wiresharkを介してデータをチェックすることについて質問がありました。

enter image description here

上の写真は、wiresharkのをキャプチャします。（354）PUBLISHメッセージに応答して、ブローカは（355）PUBLISH ACKメッセージを送信する。その後、ブローカーは355などの（356）再送信メッセージを送信します。

パブリッシュackがTCPのピギーバックackフォームで発生することを確認しましたが、なぜ356が発生しているのかわかりません。

なぜ356が発生するのですか？私は、TCP問題であれば、ピギーバックされたACKで再送のメカニズムを知らない。

2017-07-05 김성진

ブローカが再送信を送信していないため、ブローカをホストしているマシンのTCPスタックが、要求されたタイムアウト（https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Timeout_based_retransmission）でオリジナルのTCP sync応答を受信しなかったため送信しました。

それはRTOでピギーバックACKのためのACKを受信しないので、あなたが356の実際の内容を確認した場合もしそうなら、それは355

2017-07-05 09:04:56 hardillb

とまったく同じである必要があり、再送されたピギーバックACKのですか？ –

MQTT側を完全に無視すると、TCPパケット全体がクライアント側で受信できないように見えるので、ブローカのTCPスタックが再送信します。 – hardillb

ありがとうございます。それは本当に役立ちます。 –

答えて