web-dev-qa-db-ja.com

TCPパケット損失なしの重複確認

一部の埋め込みRTOS=を実行しているIP 192.168.2.250上の送信者と、IP 192.168.2.1上のLinux 4.9.xを実行している受信者があります。

受信機はワイヤレスアクセスポイントとして構成され、送信機はWiFiを介して受信機に直接接続されます。

TCP=データ転送中に受信側でtcpdumpを実行しましたが、実際のパケット損失が発生せずに受信側によって送信された重複ACKのかなりの量に気づいています（または少なくともそれは再送信は見られず、ACKは最終的には送信されたシーケンス番号に従っているためです。

wireshark trace tcp duplicate ack

誰かがレシーバーの動作を引き起こしていると思われるアイデアはありますか？

編集：ストリームにデータが欠落していないことを証明するためにオフにしたため、送信者からの高速再送信は表示されていません（これにより、スループットが大幅に増加しました）。 1つの説明は、tcpスタックによってパケットが順不同で表示されることです。 Linuxを順不同のパケットに耐えられるようにできますか？デュックアックをすぐに送信しない場合と同様です。

sysctl net | grep tcpの出力

net.ipv4.tcp_abort_on_overflow=0
net.ipv4.tcp_adv_win_scale=1
net.ipv4.tcp_allowed_congestion_control=cubic reno
net.ipv4.tcp_app_win=31
net.ipv4.tcp_autocorking=1
net.ipv4.tcp_available_congestion_control=cubic reno
net.ipv4.tcp_base_mss=1024
net.ipv4.tcp_challenge_ack_limit=1000
net.ipv4.tcp_congestion_control=cubic
net.ipv4.tcp_delack_seg=1
net.ipv4.tcp_dsack=1
net.ipv4.tcp_early_retrans=3
net.ipv4.tcp_ecn=2
net.ipv4.tcp_ecn_fallback=1
net.ipv4.tcp_fack=1
net.ipv4.tcp_fastopen=1
net.ipv4.tcp_fin_timeout=60
net.ipv4.tcp_frto=2
net.ipv4.tcp_fwmark_accept=0
net.ipv4.tcp_invalid_ratelimit=500
net.ipv4.tcp_keepalive_intvl=75
net.ipv4.tcp_keepalive_probes=9
net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_limit_output_bytes=262144
net.ipv4.tcp_low_latency=0
net.ipv4.tcp_max_orphans=16384
net.ipv4.tcp_max_reordering=300
net.ipv4.tcp_max_syn_backlog=128
net.ipv4.tcp_max_tw_buckets=16384
net.ipv4.tcp_mem=332494433366498
net.ipv4.tcp_min_rtt_wlen=300
net.ipv4.tcp_min_tso_segs=2
net.ipv4.tcp_moderate_rcvbuf=1
net.ipv4.tcp_mtu_probing=0
net.ipv4.tcp_no_metrics_save=0
net.ipv4.tcp_notsent_lowat=4294967295
net.ipv4.tcp_Orphan_retries=0
net.ipv4.tcp_pacing_ca_ratio=120
net.ipv4.tcp_pacing_ss_ratio=200
net.ipv4.tcp_probe_interval=600
net.ipv4.tcp_probe_threshold=8
net.ipv4.tcp_recovery=1
net.ipv4.tcp_reordering=3
net.ipv4.tcp_retrans_collapse=1
net.ipv4.tcp_retries1=3
net.ipv4.tcp_retries2=15
net.ipv4.tcp_rfc1337=0
net.ipv4.tcp_rmem=4096873806291456
net.ipv4.tcp_sack=1
net.ipv4.tcp_slow_start_after_idle=1
net.ipv4.tcp_stdurg=0
net.ipv4.tcp_syn_retries=6
net.ipv4.tcp_synack_retries=5
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_thin_dupack=0
net.ipv4.tcp_thin_linear_timeouts=0
net.ipv4.tcp_timestamps=0
net.ipv4.tcp_tso_win_divisor=3
net.ipv4.tcp_tw_recycle=0
net.ipv4.tcp_tw_reuse=0
net.ipv4.tcp_use_userconfig=0
net.ipv4.tcp_window_scaling=1
net.ipv4.tcp_wmem=4096163844194304
net.ipv4.tcp_workaround_signed_windows=0
tcppacket-capture
3
Mathieu Borderé

何らかの理由で、_.250_はすでに受信したSEQの古い値のACKを送信しています。パケット＃551を参照してください：_.1_状態_SEQ=290541_。パケット＃552では、_.250_は_ACK=267181_を示しています。したがって、_.250_確認番号（267181）は_.1_シーケンス番号（290541）よりも小さいため、_.1_は、＃552と＃の間のすべてのパケットが原因で_.250_が＃551を失ったと見なします558は古い_SEQ=267181_を使用し、受信した各パケットに対して、古いACK番号で別のACKを送信します。

RTOSが損失を報告していない場合、そのスケジューラが確認応答を処理するのではなく、プッシュデータを優先していると想定することができます。

1
PEdroArthur