ユーザー操作がない場合にリモート接続の切断を克服する

GUIおよびターミナルアプリケーションを使用している場合、ユーザーがリモートアクセスモード（通常はインターネット経由）で作業しているときに、コンピューターを約15分間離れた後、プログラムがクラッシュしたことが戻ってきます。 「サーバーとの接続が失われました」、「[WINSOCK]ホストによる仮想回路のリセット」などのフレーズを含むエラーでアクションに応答します。 これは、プログレスバーまたはインタラクティブ機能の出力が提供されない「長時間にわたる」メソッド（サーバーへの要求）を実行するときにも観察されます。



この問題は、インターシステムズのCachéおよびEnsembleデータベースシステムに基づくGUIおよびターミナルソリューションだけでなく、一般的にTCP / IPを介したクライアント/サーバー相互作用でも一般的です。 通常、アプリケーションレベルで解決されるのは、特別な種類の空のメッセージを定期的に交換することです。これは、アプリケーションが「生きている」ことを示すためだけのものです。



以下は、プログラミングなしでこの問題を解決する方法です。

問題の原因

問題の原因は、TCP / IPプロトコルの性質にあります。 通常、TCP / IPセッションのソースとその受信者は異なるネットワーク上にあり、セッションのパスには複数のルーターがあります。 通常、そのうちの少なくとも1つがNATアドレス変換を実行します。 ルーターのリソースは常に制限されているため、一部のリソースはデッドセッションからNATテーブルをクリーンアップします。 特定の時間間隔でパケットが送信されなかった場合、セッションは「デッド」とみなされます（クリーニング間隔と呼びましょう）。 したがって、「サイレント」セッションは「デッド」セッションと間違えられ、NATテーブルから削除される可能性があります。 同時に、送信元にも受信者にも通知されず（「王室の問題ではない」）、どちらもセッションがまだ「生きている」ことを確信しています（発生時にクライアントまたはサーバーで実行することにより、netstatコマンドで簡単に確認できます）エラー、ただし[OK]をクリックする前）。 エラーメッセージを受け取ったユーザーが[OK]をクリックすると、クライアントはセッションの中断について学習します。 「デッド」セッションがOSを認識すると、サーバープロセスは終了します。



多くのルーターのクリーニング間隔（少なくともフラッシュLinux 2.4 / iptablesの場合）は約10分であることが実験的に確立されています。 データパケットが送信されない場合でも、TCPセッションが自動的にアクティブ状態を維持するようにします。

提案されたソリューション

OSレベルでは、切断されたTCP接続の検出は、tcp_keepaliveメカニズム[1]の動作を制御する次のカーネルパラメーターによって制御されます。

• tcp_keepalive_time-データを含む最後のパケットを送信した時点からの時間間隔。 この期間が過ぎると、接続には検証が必要とマークされます。 検証の開始後、パラメーターは使用されません。

• tcp_keepalive_intvl-テストパケットの間隔（tcp_keepalive_timeの期限が切れた後に送信が開始されます）。

• tcp_keepalive_probes-未確認のテストパケットの数。 このカウンターが使い果たされた後、接続は切断されたと見なされます。



tcp_keepaliveメカニズムには二重の目的があると言わざるを得ません：化合物の活性を人為的に維持することと、壊れた（いわゆる「ハーフオープン」）化合物を検出することの両方に使用できます。 この記事では主に最初のアプリケーションについて説明しますが、2番目のアプリケーションについては、おそらくこのトピックに関する次の記事で説明します。



TCP接続でtcp_keepaliveメカニズムを有効にするには、2つの条件が必要です。

•OSレベルのサポート。 幸いなことに、WindowsとLinuxの両方で利用できます。

•接続の一方の端で、SO_KEEPALIVEパラメーターを使用してソケットを開く必要があります。 判明したように、Cachéサービスはこのパラメーターを使用してソケットを開き、OpenSSHサービスでも同じことを簡単に行うことができます。



最初のパラメーター（ tcp_keepalive_time ）は、非アクティブな接続が（トラフィックの不足という観点から）チェックされる頻度に依存するため、最も重要です。 WindowsとLinuxの両方のデフォルト値は2時間（7200秒）です。 休憩があった後の非活動の典型的な時間は約10分です。 したがって、パラメータ値を5分に設定することをお勧めします。これにより、過剰なトラフィックでネットワークを過負荷にすることなく、TCPセッションのアクティビティを人為的に維持できます（5分は5秒ではありません）。

Windowsサーバーでのtcp_keepaliveオプションの設定

サーバーに対する管理者権限が必要です。 レジストリキー

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \パラメーター

300000（10進数）の値を持つKeepAliveTimeという名前のDWORDパラメーターを作成します。 パラメーターはミリ秒単位で設定されるため、提案されている値は5分です。 次に、Cachéを停止し、サーバーを再起動します。



他の2つのtcp_keepaliveパラメーターについては、Windowsでのデフォルトは次のとおりです。



KeepAliveInterval

キー：Tcpip \パラメーター

値のタイプ：REG_DWORD —ミリ秒単位の時間

有効範囲：0–0xFFFFFFFE

デフォルト：1000（1秒）



KeepAliveProbes

このようなパラメーター（未確認のテストパケットの数を設定する）は、レジストリに存在しません。 [2]によると、Windows 2000 / XP / 2003では、この品質でTcpMaxDataRetransmissionパラメーターの値（デフォルトは5）が使用され、それ以降のバージョンでは[3] -10の固定値が使用されます。 7200 x 300）、2番目のデフォルトを保持して、Windows 2008サーバーは1 * 10 + 300 = 310秒後にTCP接続の切断について学習します。

Linuxサーバーでのtcp_keepaliveオプションの設定

サーバーを再起動せずに、外出先でパラメーター値を変更できます。 ルートとしてログインし、実行します：

echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

可能なサーバーの再起動に関して変更を永続的にするには、カーネルパラメーターファイル/etc/sysctl.confを編集し、それに行を追加するのが最も簡単な方法です（2つの方が良い）：

 # help to prevent disconnects net.ipv4.tcp_keepalive_time = 300
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Windowsとは異なり、パラメーター値は秒単位で設定されることに注意してください。

他の2つのtcp_keepaliveパラメーターについては、Linuxでのデフォルトは次のとおりです。

 net.ipv4.tcp_keepalive_intvl = 75 net.ipv4.tcp_keepalive_probes = 9
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初のパラメーターの値（7200から300）のみを変更し、他の2つのデフォルトを保持する場合、Linuxサーバーは75 * 9 + 300 = 975秒後に切断についてのみ学習します。

CachéDBMS構成でのTCPKeepAliveパラメータの設定

バージョン2008.2以降、Cachéfor WindowsおよびLinuxプラットフォームでは、ソケットレベルでtcp_keepalive_timeを設定できます。これは、オペレーティングシステムの設定の変更を回避できるため便利です。 ただし、「純粋な形で」この機能は、主に独立したソケットサーバー開発者のみが関心を持っています。 幸いなことに、[SQL]セクションのTCPKeepAlive = n構成パラメーターが追加されました。このパラメーターは、システム管理ポータルページの[構成]> [一般SQL設定]から編集できます 。 デフォルト値は300秒です（医師が注文した値）。 パラメータの効果は、SQLだけでなく、ご想像のとおり、％Service_Bindingsによって提供されるCachéへの接続にも拡張されます。 これらには、特にCacheActiveX.Factoryを介したオブジェクトアクセスが含まれるため、アプリケーションがこのプロトコルをトランスポートとして使用できる場合は、この機会を逃さないでください。

OpenSSHサーバー構成でのキープアライブ設定の設定

SSH [4]を使用する場合（シェルモードまたはGUIアプリケーションのトランスポートとして）、...おそらく、OpenSSHサービス（少なくともバージョン5.xで）が行われるため、カーネル構成で十分です。 -defaultは、パラメーターSO_KEEPALIVEでソケットを開きます。



念のため、構成ファイル/ etc / ssh / sshd_configを確認する必要があります。 その中の行を見つける

 #TCPKeepAlive yes
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

見つかった場合、デフォルトのパラメーター値はコメント形式で提供されるため、何もする必要はありません。



SSH v.2プロトコルには、たとえば、OpenSSHサービス設定ClientAliveIntervalおよびClientAliveCountMaxを構成するなど、セッションアクティビティを監視する代替手段があります。

これらのパラメーターを使用すると、TCPKeepAliveとは異なり、KeepAlive要求は安全なSSHチャネルを介して送信され、置換できません。 KeepAliveパケットを分析してDoS攻撃を組織化する危険がある[5] 、従来のTCPKeepAliveメカニズムよりも代替ツールが安全であることを認めなければなりません。

 ClientAliveInterval 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

タイムアウトを秒単位で設定します。その後、クライアントから情報が受信されない場合、sshdは安全なチャネルを介して応答要求を送信します。 デフォルト値は0です。これは、そのような要求がクライアントに送信されないことを意味します。

 ClientAliveCountMax 3
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クライアントへの応答を受信せずにsshdによって送信できるクライアントへの要求の数を設定します。 制限に達すると、sshdはクライアントとの接続を切断し、セッションを終了します。 デフォルト値は3です。ClientAliveIntervalパラメーターを60に設定し、ClientAliveCountMaxを変更しない場合、約180秒後に応答しないsshクライアントが切断されます。 この場合、設定してTCP KeepAliveメカニズムを無効にします

 TCPKeepAlive no
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

常に機能しますか？

説明されたアプローチが効果的でないネットワーク問題のカテゴリがあります。



そのうちの1つは、ネットワークサービスの品質が低いために、通信が短時間で物理的に消える場合に発生します。 セッションがアイドル状態で、クライアントまたはサーバーが互いに何かを送信しようとする前に接続が一時的に失われ、復元された場合、それらは何も「通知」せず、TCPセッションは保存されます。 TCPKeepAliveの定期的なチェックの場合、接続が一時的に失われると、サーバーがクライアントに接続する可能性が高くなり、TCP接続が強制的に切断される可能性があります。 この状況では、一時的なネットワークの問題が自動的に解決されることを期待して、最大再試行回数10でKeepAliveIntervalサーバーを60〜75秒（Windowsのデフォルトは1秒）に増やすことができます。 確かに、再送信の時間が長すぎると、

KeepAliveTime +（KeepAliveInterval *再試行回数）> 10分

TCPセッションは、すべての努力にもかかわらず、「デッド」と間違えられ、NATテーブルからクリアされる可能性があります。



問題の別のカテゴリは、KeepAliveを含むパケットが輻輳中に失われる可能性がある場合に使用されるルーターや通信チャネルの帯域幅が不十分であることに関連しています。 ルーターの場合、このような問題はファームウェアを変更することで解決される場合があります（たとえば、Acorp ADSL XXXXを無効にするのに役立ちました）。最悪の場合は、より効率的なモデルに置き換えます。 「狭すぎる」通信チャネルの場合、それらを拡張する以外にやることはありません。

おわりに

提案されたアプローチにより、TCP / IPセッションのアクティビティを人為的に維持することができます。現在、アプリケーションコードを変更することなく、システムレベルでのみデータを送信します。 現在、Cachéfor UNIX（Red Hat Enterprise Linux 5 for x86-64）2010.1.4（Build 803）、Cachéfor Windows（x86-64）2010.1.4（Build 803）などでテストされ、正常に使用されていますそれ以降のバージョン。



ネットワーク接続が物理的に安定している場合に効果的に機能し、非アクティブなセッションを中断することに加えて、他のネットワークの問題がないことを認識してください。



アグレッシブな環境（リモートアクセス、分散システムなど）にアプリケーションをデプロイする場合は、TCPレベルではなく、より高いレベルの安全なプロトコルのレベルでKeepAliveを実装することを検討してください。 SSHは良い候補です。

文学

[1]ファビオ・ブサト。 TCPキープアライブHOWTO

[2] Windows Server 2003でサービス拒否攻撃に対してTCP / IPスタックを強化する方法

[3] Microsoft Windows VistaおよびWindows Server 2008のTCP / IPレジストリ値

[4]システムマニュアルを表示するための対話型システム（mans）

[5] OpenSSH：sshdのインストールと構成