タイムアウトと再送信

TCPプロトコルが原因でUnicomとWebサイトをテストするために使用されるページングは​​、問題を通信できませんタイムアウトの問題



Paping Used Test Unicom Website Due Tcp Protocol Can Not Communicate Problems Timeout Problem



今日仕事に行くとき、私は魔法の問題を抱えています。私が素晴らしい理由は、私がこれまでに遭遇したことがないからです。今まで電話をかけたことがなく、電話がかかってきたのですが、突然、回線ができる必要がないことに気づきました。

最初にツールを紹介し、Microsoft Cloudの同僚は、サーバー禁止のPing、icmpパッケージの応答を解決する別の方法を紹介しました。



1.ページングを使用してLinuxプラットフォームの接続をテストします::

wget http://www.updateweb.cn/softwares/paping_1.5.5_x86-64_linux.tar.gz



または

wget https://zhangtaostorage.blob.core.chinacloudapi.cn/share/paping_1.5.5_x86-64_linux.tar.gz

これはzipファイル、解凍方法tar zvxf paping_1.5.5_x86-64_linux.tar.gz



./paping–p 80 -c 500 www.xxx.comの使用方法（このコマンド例は、ターゲットIP 80ポート接続テストの500回を対象としています）

blob.png

2、pspingを使用して接続性winプラットフォームをテストします。

Pspingダウンロードアドレス： http://www.updateweb.cn/softwares/PSTools.zip

または

Pspingダウンロードアドレス： http://technet.microsoft.com/en-us/sysinternals/jj729731

そしてそれをC： Windows system32ディレクトリに置きます

次に、cmdモードで実行します。pspingipaddress：port

例えば：

blob.png

-------------------------------------------------- ---------------------

家に近い：

最初の図は接続タイムアウトプロンプトを示しており、同じネットワーク上の他のマシンが接続されていることがわかります。最初の反応は、ファイアウォールまたはネットワークのブラックリストがブロックされていることです。複数の関係者がそれをチェックした後、この推測は間違っています。の、

最終的な解決策は次のとおりです。

Linuxシステムのカーネルパラメーター構成を確認します。sysctl-a| grep tcp

sysctl -w net.ipv4.tcp_timestamps = 1

sysctl -w net.ipv4.tcp_tw_recycle = 0

Linuxカーネルパラメータへの変更：

sysctl -w net.ipv4.tcp_timestamps = 0

sysctl -w net.ipv4.tcp_tw_recycle = 0

はい、ネットワークはすぐにスムーズになります。

注意：

-------------------------------------------------- -------

PsPingv2.01の使用説明書

マーク・ルシノビッチ

公開日：2014年1月29日

（1.644 KB）

割合：
前書き

PsPingは、Ping機能、TCP ping、遅延、および帯域幅の測定を実装します。次のコマンドラインオプションを使用して、各テストタイプの使用法を表示します。

インストール

コピー PsPing 実行可能パスに。 'psping'と入力すると、その使用構文が表示されます。

PsPingの使用

PsPing Ping機能、TCP ping、遅延、および帯域幅の測定を実装します。次のコマンドラインオプションを使用して、各テストタイプの使用法を表示します。

使用法：psping-？ [i | t | l | b]

-？ ICMP pingのIUsage.-？ TCP pingのTUsage.-？レイテンシーテスト用のLUsage。-？帯域幅テスト用のBUsage。

ICMP pingの使用法：psping [[-6] | [-4]] [-h [buckets | 、、 ...]] [-i] [-l [k | m] [-q] [-t | -n] [-w]

-hPrintヒストグラム（デフォルトのバケット数は20です）。
単一の引数を指定すると、それはバケットカウントとして解釈され、ヒストグラムには、値の時間範囲全体をカバーするバケットの数が含まれます。カスタムヒストグラムを作成する時間のコンマ区切りリストを指定します（例：「0.01,0.05,1,5,10」）。-iInterval（秒単位）。高速pingの場合は0を指定します。-lRequestサイズ。キロバイトの場合は「k」を追加し、メガバイトの場合は「m」を追加します-n pingの数、または秒を指定するために「s」を追加します。 '10s' .- qping中に出力しない-tPingはCtrl + Cで停止し、統計情報としてCtrl + Breakと入力する-指定された反復回数でウォームアップ（デフォルトは1）-4IPv4を使用して強制する-6使用を強制するIPv6。

高速pingテストには、-qおよび-i0を使用します。

TCP pingの使用法：psping [[-6] | [-4]] [-h [buckets | 、、 ...]] [-i] [-l [k | m] [-q] [-t | -n] [-w]

-hPrintヒストグラム（デフォルトのバケット数は20です）。
単一の引数を指定すると、それはバケットカウントとして解釈され、ヒストグラムには、値の時間範囲全体をカバーするバケットの数が含まれます。カスタムヒストグラムを作成する時間のコンマ区切りリストを指定します（例：「0.01,0.05,1,5,10」）。-iInterval（秒単位）。高速pingの場合は0を指定します。-lRequestサイズ。キロバイトの場合は「k」を追加し、メガバイトの場合は「m」を追加します-n pingの数、または秒を指定するために「s」を追加します。 '10s' .- qping中に出力しない-tPingはCtrl + Cで停止し、統計情報としてCtrl + Breakと入力する-指定された反復回数でウォームアップ（デフォルトは1）-4IPv4を使用して強制する-6使用を強制するIPv6。

高速pingテストには、-qおよび-i0を使用します。

TCPおよびUDPレイテンシの使用：

サーバー：psping [[-6] | [-4]] [-f]

クライアント：psping [[-6] | [-4]] [-f] [-u] [-h [buckets | 、、 ...]] [-r] [k | m]] [-w]

-f実行中に送信元ファイアウォールポートを開きます。-uUDP（デフォルトはTCP）。-hヒストグラムを印刷します（デフォルトのバケット数は20です）。
単一の引数を指定すると、それはバケットカウントとして解釈され、ヒストグラムには、値の時間範囲全体をカバーするバケットの数が含まれます。カスタムヒストグラムを作成するには、カンマで区切った時間のリストを指定します（例：「0.01,0.05,1,5,10」）。-lRequestサイズ。キロバイトの場合は「k」、メガバイトの場合は「m」を追加します。-n送信/受信の数。 's'を追加して、秒を指定します。例： '10s'-r送信する代わりにサーバーから受信します。-指定された反復回数でウォームアップします（デフォルトは5）。-4IPv4を使用して強制します。-6IPv6を使用して強制します。-sServerリスニングアドレスとポート。

サーバーは遅延テストと帯域幅テストの両方に対応でき、Control-Cでサーバーを終了するまでアクティブのままです。

TCPおよびUDP帯域幅の使用：

サーバー：psping [[-6] | [-4]] [-f]

クライアント：psping [[-6] | [-4]] [-f] [-u] [-h [buckets | 、、 ...]] [-r] [k | m]] [-i] [-w]

-f実行中に送信元ファイアウォールポートを開きます。-uUDP（デフォルトはTCP）。-b帯域幅テスト。-hヒストグラムを印刷します（デフォルトのバケット数は20です）。
単一の引数を指定すると、それはバケットカウントとして解釈され、ヒストグラムには、値の時間範囲全体をカバーするバケットの数が含まれます。カスタムヒストグラムを作成する時間のコンマ区切りリストを指定します（例：「0.01,0.05,1,5,10」）。-i未処理のI / Oの数（デフォルトは16の最小値と2x CPUコア）-lRequestサイズ。キロバイトの場合は「k」、メガバイトの場合は「m」を追加します。-n送信/受信の数。 's'を追加して、秒を指定します。例： '10s'-r送信する代わりにサーバーから受信します。-指定された反復のwWarmup（デフォルトは2x CPUコア）。-4IPv4を使用して強制します。-6IPv6を使用して強制します。-sServerリスニングアドレスとポート。

サーバーは遅延テストと帯域幅テストの両方に対応でき、Control-Cでサーバーを終了するまでアクティブのままです。

例

このコマンドは、3回のウォームアップ反復で10回のICMPpingテストを実行します。
psping -n 10 -w3マークラップ

TCP接続テストを実行するには、ポート番号を指定します。次のコマンドは、ターゲットに対して可能な限り迅速に接続試行を実行し、100回の反復と1回のウォームアップ反復が終了したときにのみ要約を出力します。
psping -n 100 -i 0 -q marklap：80

遅延テストと帯域幅テスト用にサーバーを構成するには、-sオプションと、サーバーがバインドする送信元アドレスとポートを指定するだけです。
psping -s 192.168.2.2:5000

TCP遅延テストを実行するには、バッファサイズが必要です。この例では、8KBパケットをターゲットサーバーに送信し、完了時に100バケットのヒストグラムを出力するラウンドトリップレイテンシを測定します。
psping -l 8k -n 10000 -h 100 192.168.2.2:5000

このコマンドは、ターゲットIPアドレスで10秒間リッスンしているPsPingサーバーへの帯域幅をテストし、100バケットのヒストグラムを生成します。ヒストグラムを生成するには、ウォームアップ後少なくとも1秒間テストを実行する必要があることに注意してください。 -uを追加するだけで、PsPingにUDP帯域幅テストを実行させることができます。
psping -b -l 8k -n 10000 -h 100 192.168.2.2:5000

---------------------------

添付資料2：

Tcp_tw_recycleとtcp_timestampsは接続障害を引き起こします

最近、いくつかの接続障害の問題が次々と現れています。分析とテストの後、最終確認はprocパラメーターtcp_tw_recycle / tcp_timestampsに関連します。
現象
最初の現象：モジュールAはNATゲートウェイを介してサービスSに正常にアクセスし、モジュールBはNATゲートウェイを介してサービスSにアクセスします。接続障害が見つかりました。パケットキャプチャは、サービスSがsynパケットを受信したが、synackに応答していないことを示しています。モジュールAはtcpタイムスタンプをオフにし、モジュールBはtcpタイムスタンプをオンにします
2番目の現象：異なるホスト上のモジュールC（タイムスタンプ上）がNATゲートウェイ（1出力IP）を介して同じサービスSにアクセスし、ホストC1接続が成功し、ホストC2接続が失敗する

2.分析
この現象によると、上記の問題は明らかにtcptimestmapに関連しています。Linux2.6.32のソースコードを表示し、tcp_tw_recycle / tcp_timestampsがすべて有効になっていることを確認します。60秒以内に、同じソースIPホストのソケット接続要求のタイムスタンプが必要です。インクリメントされます。
ソース関数：tcp_v4_conn_request（）、これはtcpレイヤーの3ウェイハンドシェイクsynパケットの処理関数（サーバー）です。
ソースコードフラグメント：
if（tmp_opt.saw_tstamp &&
tcp_death_row.sysctl_tw_recycle &&
（dst = inet_csk_route_req（sk、req））！= NULL &&
（peer = rt_get_peer（（struct rtable *）dst））！= NULL &&
peer-> v4daddr == saddr）{
if（get_seconds（）tcp_ts_stamp + TCP_PAWS_MSL &&
（s32）（peer-> tcp_ts-req-> ts_recent）>
TCP_PAWS_WINDOW）{
NET_INC_STATS_BH（sock_net（sk）、LINUX_MIB_PAWSPASSIVEREJECTED）
goto drop_and_release
}
}
Tmp_opt.saw_tstamp：このソケットはtcp_timestampをサポートします
Sysctl_tw_recycle：ネイティブシステムはtcp_tw_recycleオプションをオンにします
TCP_PAWS_MSL：60秒、条件は、ソースIPの最後のtcp通信が60秒以内に発生したと判断します。
TCP_PAWS_WINDOW：1、条件は、ソースIPの最後のtcp通信のタイムスタンプがこのtcpより大きいと判断します

分析：ホストclient1とclient2は、NATゲートウェイ（1 IPアドレス）を介してserverNにアクセスします。タイムスタンプ時刻はシステム起動からの現在時刻であるため、上記のsynパッケージ処理ソースコードにより、tcp_tw_recycleとtcp_timestampsでclient1とclient2のタイムスタンプが異なります。同時に、タイムスタンプの大きいホストがserverNに正常にアクセスします。 、およびタイムスタンプが小さいホストは失敗します。

パラメータ：/ proc / sys / net / ipv4 / tcp_timestamps-タイムスタンプオプションのオン/オフを制御します
/ proc / sys / net / ipv4 / tcp_tw_recycle-timewaitソケットリリースのタイムアウトを減らします

3.解決策
エコー0> / proc / sys / net / ipv4 / tcp_tw_recycle
Tcp_tw_recycleはデフォルトでオフになっています。かなりの数のサーバーがあります。パフォーマンスを向上させるために、このオプションが有効になっています。
上記の問題を解決するには、tcpタイムスタンプがオフの状態ではtcp_tw_recycleが機能しないため、タイムスタンプの代わりにtcp_tw_recycleオプションをオフにすることをお勧めします。tcpタイムスタンプは独立して開始および機能できます。
ソース関数：tcp_time_wait（）
ソースコードフラグメント：
if（tcp_death_row.sysctl_tw_recycle && tp-> rx_opt.ts_recent_stamp）
recycle_ok = icsk-> icsk_af_ops-> Remember_stamp（sk）
……。

if（timeo時間= RTO

if（recycle_ok）{
tw-> tw_timeout = rto
} そうしないと {
tw-> tw_timeout = TCP_TIMEWAIT_LEN
if（state == TCP_TIME_WAIT）
timeo = TCP_TIMEWAIT_LEN
}

inet_twsk_schedule（tw、＆tcp_death_row、timeo、
TCP_TIMEWAIT_LEN）

タイムスタンプとtw_recycleの両方が有効になっている場合、timewait状態のソケットリリースのタイムアウト期間はrtoに関連します。それ以外の場合、タイムアウト期間はTCP_TIMEWAIT_LEN、つまり60秒です。

カーネルのドキュメントこのパラメータの概要は次のとおりです。
tcp_tw_recycle-ブール値
TIME-WAITソケットの高速リサイクルを有効にします。デフォルト値は0です。
技術者のアドバイス/リクエストなしに変更しないでください
専門家。

元のリンク：http：//blog.sina.com.cn/u/2015038597

-----------------------------

添付資料2：

I.状況は次のとおりです

1.会社のイントラネット上のサイトへのhttpアクセス：

Linuxホストの障害：curlおよびパケットキャプチャ分析で、サーバーがLinuxクライアントの要求に応答しないことが判明し、TCP接続を確立できず、ブラウザが「サーバーに接続できません」を返します。

Windowsホストは正常です

2.httpアクセス品質の低下：

基調講演は、新しいアーキテクチャが開始された後、主に次のように訪問の質が低下することを示しています

2.1。アクセスプロンプト「サーバーに接続できません」

2.2。このような障害に遭遇した人はごくわずかであり、日中は毎回発生するわけではありませんが、発生した場合は良いか悪いかです。

第二に、プロセス

グーグル検索キーワードで直接「サーバーはTCP接続を確立できません。」

数ページめくった後。

見てみると、当社のイントラネットのパフォーマンスはまったく同じですが、さまざまな問題があります（1はこの点で弱く、2はこの構成を確認する時間がありません）

それからこの問題は長い間続きました...私はいつもそれが内部の装置の問題であると思っていました。

後で、私はもうそれを作ることができませんでした。この行でこのパラメーター「net.ipv4.tcp_timestamps = 0」を大胆に有効にしました。次のテストを行った後、障害が取り除かれたことがわかりました。元の故障したマシンは、訪問するたびに正常でした！

ただし、NATインターネットアクセスのユーザー（他のユーザーとエクスポートIPアドレスを共有する）と同じように、同じことを理解するだけで、原則についてはまだ不明です。タイムスタンプが他のユーザーよりも小さい場合、サーバーは応答しません。 TCPリクエストは、この項目を無視して、net.ipv4.tcp_timestamps = 0（/etc/sysctl.conf）になります。

概要

後の研究で、私はより詳細なブログを見ました。それは非常に詳細で、新しい問題を紹介しました：

======チートシート======

実際、Linuxサーバーは元々タイムスタンプ（タイムスタンプ）を開きません。 Linuxが有効かどうかは、tcp_timestampsとtcp_tw_recycleによって異なります。これは、tcp_timestampsがデフォルトで有効になっているため、tcp_tw_recycleをオンにすると、この動作が実際にアクティブ化されたためです。

Net.ipv4.tcp_tw_recycleは別の方法で、基本的にTIME_WAIT接続である回復パラメーターを検索します

net.ipv4.tcp_timestampsが設定されておらず（デフォルトが有効）、net.ipv4.tcp_tw_recycleもオンになっている場合、この落とし穴エラーが発生しますが、これはNATネットワーク環境でのみ発生することに注意してください。さらに、ほとんどのブロガーと一部の大きな牛は、net.ipv4.tcp_tw_recycleを開きたいと言っています...

======チートシート======

4.未完成事項

1.（未確認）タイムスタンプを閉じた後、tw_recycle関数が無効になります

2.（未確認）TIME_WAIT接続を解決する新しい方法：net.ipv4.tcp_max_tw_buckets = 10000最大値を設定しますが、欠点は、システムログで次のプロンプトが表示されることです。TCP：待機バケットテーブルのオーバーフロー

転載：https：//www.cnblogs.com/sysk/p/6427804.html