私は特定の大学の環境科学部門のリモート検出装置を使用しており、待ち時間に問題があります。フィールドには、定期的にアップデートを（POSTとして）Linuxと単純なWebサーバーを実行するボックスに戻すセンサーがあります。このデバイスは、ワイヤレスリピータのデイジーチェーンを介して接続します（市販の携帯電話ネットワークの代わりに短波を試しています）。Webサーバー用のLinuxでチューニング受信ACKタイムアウト
私たちの問題は、いくつかのリンクではレイテンシが高いことが原因です。 20秒に近づいている。当社のセンサーは、サーバーとの接続を確立するために3段階のハンドシェイクを完了できません。 SYNがサーバーに到達し、SYNACKがリモートに戻ってきますが、ACKがリモートからサーバーに到達するまでに、サーバーはすでにRSTを送信しています。
これらのACKを受信するタイムアウトを長くできるように、LinuxのTCPスタックをチューニングする方法はありますか？
タイムアウトはRTOに関連しています。
RFC6298 2.1を参照してください。送信者と受信者の間で送信されたセグメントに対して往復時間（RTT）測定が行われるまで、送信者はRTO < - 1秒を設定すべきである（SHOULD）。
RFC6298 5.5を参照してください。ホストは、RTO <を設定しなければなりません - RTO * 2
私のUbuntu（14.04）の "は、/ proc/sys/net/IPv4の/ tcp_synack_retriesは"、つまり5
に
Server state.
1. SYN/ACK First Send ===> 1 second wait ...
2. SYN/ACK Retransmission ===> 2 second wait ...
3. SYN/ACK Retransmission ===> 4 second wait ...
4. SYN/ACK Retransmission ===> 8 second wait ...
5. SYN/ACK Retransmission ===> 16 second wait ...
6. SYN/ACK Retransmission ===> 32 second wait ...
合計待ち時間を超えた時間が20秒を超えています。
"/ proc/sys/net/ipv4/tcp_synack_retries"を変更してみてください。
興味深い問題ですが、私の給与等級を超えています。おそらく、あなたが 'c'、' C++ '、または??をプログラミングしている言語用のタグを追加するでしょう。プロはあなたのQに気付くでしょう（ 'tcp'タグと' latency'タグの比較的低い「フォロワー」に気づくでしょう）。がんばろう。 – shellter
UDPはこのアプリケーションのためのより良いトランスポートメカニズムでしょうか？その後、すべてのタイムアウト/再送/諦めのメカニズムを完全に制御できます。 –