タグ付けされた質問 「tcp」

私のLinuxサーバーは、グローバルカタログサーバーへのLDAPS接続を確立しようとしていますが、接続は（おそらくGC側によって）ドロップされています。 議論のために、1.1.1.1がLinuxサーバーであり、1.2.3.4がグローバルカタログサーバーであるとしましょう。 telnetLinuxボックスから使用しようとすると、次のように表示されます。 [root@foobox ~]# telnet gcfoo.exampleAD.local 3269 Trying 1.2.3.4... Connected to gcfoo.examplead.local. Escape character is '^]'. Connection closed by foreign host. 4行目と5行目の間に遅延はありません。ただちに接続を切断します。 telnet結果は少し誤解を招くかもしれないと思ったので（実際にはどのタイプのセキュアな通信にも適切ではないため）、実際の接続試行のパケットキャプチャをアプライアンスから収集しました（LDAPSを必要とする実際のプログラムを使用）。 私が見るものは次のとおりです（ここでも、IPと送信元ポートは無実の人を保護するために名前が変更されています）： No. Time Source Destination Protocol Length Info 1 0.000000 1.1.1.1 1.2.3.4 TCP 66 27246 > msft-gc-ssl [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SAC_PERM=1 WS=128 2 0.000162 …

14 ldap  tcp  tcpip 

CentOS 6.7（Final）システムを使用ncしています。リスニングモードで実行しようとすると、次のように出力されます。 # nc -l 1234 nc: Protocol not available ポートはバインドされていません。他のポート番号も試しました。このバグは既に報告されているようです：https : //access.redhat.com/solutions/1753753。残念ながら、あまり詳細ではありません。 パッケージ情報： Name : nc Arch : x86_64 Version : 1.84 Release : 24.el6 他に試してみる必要があるものはありますか？

13 linux  centos  tcp  netcat 

たとえば、/ var / program / program.cmdなどのUNIXドメインソケットをTCP経由で公開し、ポート12345で使用できるようにします。これをバックグラウンドでフルタイムで実行することもできます。 これを行う最良の方法は何ですか？関連する場合、システムはUbuntu 12.04.2を実行しています。 また、提案されたソリューションでは、ドメインソケットを削除して再作成しても存続しますか？ 編集 ここに、受け入れられた回答の結果を初期化スクリプトの形式で示します。https： //github.com/Wirehive/haproxy-remote

13 linux  ubuntu  tcp  socket 

Wireshark | ウィンドウズ 特定のアドレス/メッセージのSMTPトラフィックのパケットキャプチャを検索したい。通常、情報列を並べ替えて参照するだけですが、探している特定の文字列に対して検索またはフィルターを実行できると便利です。 Wiresharkでこれを行う方法はありますか？

13 tcp  wireshark  packet-analyzer  packet-capture 

ランダムなポートでTelnetを試行しているときに、次の2種類のシナリオが発生することに気づきました。 $ telnet example.com 3432 Trying 173.252.110.27... $ telnet example.com 3432 Connection Refused. 誰かが2つの違いは何ですか私に説明できますか？

13 networking  tcp 

172.16.11.5および172.16.10.6からsshで接続すると、以下に示すように非対称デュアルブリッジトポロジがありますが、SynProxyが原因で接続できません。 ------- | | ---o--- 172.16.11.5 | | -----o----- 172.16.11.6 | | | | default gw 1.1.1.1 | | 1.1.1.2/30 --o----o--- 2.2.2.2/30 | | | | | | (enp10s0f0) ----o----o----- | | | XXX | | | | br1 br0 | synproxy | | ----o----o----- | | | | | …

12 linux  linux-networking  tcp  tcpdump 

ネットワーク内のマシンのMACアドレスを見つけるにはどうすればよいですか？ BIOSのみがインストールされている（オペレーティングシステムがインストールされていない）場合にのみ使用可能なマシンを検出する必要があります。 そして、稼働中のマシンのMACアドレスを見つける必要があります。

12 networking  tcp  bios  mac-address 

ボックス上のアプリケーションの問題を一般的に推測することを期待して、サーバー上のTCPスタックを監視しています。 私の最初の傾向は、報告されたすべての状態（LISTEN、ESTABLISHED、FIN_WAIT2、TIME_WAITなど）のソケットの数を測定し、いくつかの異常を検出することです。 チームメイトは、「lsof」がTCPスタックの状態を確認するためのより良いツールになると示唆しています。 サーバー障害群衆からの好みや経験のヒントはありますか？

12 linux  unix  tcp  netstat  lsof 

ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 ネットワークの「品質」-遅延、ドロップされたパケットの数などを確認することは一般的なタスクです。しかし、「ping」には多くの欠点があります。-ICMPを使用します。多くのISPはICMPおよびTCPトラフィック用に異なるシェーパーを持っているため、「ping」では10ミリ秒の遅延が表示されますが、TCP接続では1000ミリ秒以上が発生します。-非常に少量のパケットを送信します。デフォルトでは、毎秒1パケット。TCPプロトコルはパケット損失を許容するため（半分のパケットが失われると非常に良好に動作します-正常です）、pingの「30％パケット損失」が接続を切断するのか、それが絶対に正常なのかは明確ではありません。 だから、ICMPの代わりにTCP接続を使用してインターネット接続の品質をチェックするpingの代替手段はありますか？

12 networking  tcp 

約4000接続でTCP枯渇の問題に直面しているサーバーアプリケーションがあります。これは3週間または4週間ごとに発生します（およそ）。このサーバーアプリケーションを作成したベンダーは、netstat -bの出力を調べた後、クライアントがドロップしても一部の接続が開いたままであることを通知します。 特定のクライアントアプリケーションがTCP接続を適切に閉じない理由を調査するタスクが与えられました。私は、クライアントコンピューターがシャットダウンした場合、そのクライアントとのTCP接続がまだ確立されていることをサーバーから報告することはできないと考えています。残念ながら、自分の見解を検証するための情報を見つけることができません。問題になる可能性があるとは思わない潜在的な問題を調査するのにこれ以上時間を無駄にしたくありません。 tldr; サーバーは、オフになっているコンピューターへの確立された接続を報告できますか？

12 windows-server-2008  tcp 

私のファイアウォールには、次のようなiptablesルールがいくつかあります。 iptables -A zone_lan_forward -p tcp -d 1.2.3.0/24 -j ACCEPT iptables -A zone_lan_forward -p udp -d 1.2.3.0/24 -j ACCEPT すべてのアドレスに対して、tcp用とudp用の2つのルールを設定するためのショートカットはありますか？私はこのようなことをすることができます： iptables -A zone_lan_forward -p tcp,udp -d 1.2.3.0/24 -j ACCEPT

12 iptables  firewall  tcp  udp 

Kubernetesの一部であるkube-proxyと呼ばれる長命のプロセスに問題があります。 問題は、時々接続がFIN_WAIT2状態のままになることです。 $ sudo netstat -tpn | grep FIN_WAIT2 tcp6 0 0 10.244.0.1:33132 10.244.0.35:48936 FIN_WAIT2 14125/kube-proxy tcp6 0 0 10.244.0.1:48340 10.244.0.35:56339 FIN_WAIT2 14125/kube-proxy tcp6 0 0 10.244.0.1:52619 10.244.0.35:57859 FIN_WAIT2 14125/kube-proxy tcp6 0 0 10.244.0.1:33132 10.244.0.50:36466 FIN_WAIT2 14125/kube-proxy これらの接続は時間の経過とともに積み重ねられ、プロセスが誤動作します。既にKubernetesバグトラッカーに問題を報告しましたが、そのような接続がLinuxカーネルによって閉じられない理由を理解したいと思います。 そのドキュメント（tcp_fin_timeoutの検索）によると、FIN_WAIT2状態の接続はX秒後にカーネルによって閉じられるはずです。Xは/ procから読み取ることができます。私のマシンでは、60に設定されています。 $ cat /proc/sys/net/ipv4/tcp_fin_timeout 60 正しく理解できれば、そのような接続は60秒で閉じられるはずです。しかし、これはそうではありません、彼らは何時間もそのような状態のままになります。 また、FIN_WAIT2接続は非常に珍しいことも理解していますが（これは、ホストが接続のリモートエンドからのACKを待っていることを意味します。 。 何かできることはありますか？ 関連プロセスの再起動は最後の手段であることに注意してください。

11 linux-networking  tcp  kernel  connection 

これについてはSEに関する質問がかなりあることは知っていますが、ここまで来る前に重要な質問をたくさん読んだと思います。 「サーバー側TIME_WAIT」とは、サーバー側でclose（）が開始されたサーバー側ソケットペアの状態を意味します。 私はしばしば私には矛盾しているように見えるこれらの声明を見ます： サーバー側TIME_WAITは無害です クライアントがclose（）を開始するようにネットワークアプリを設計する必要があります。したがって、クライアントに TIME_WAIT 私がこの矛盾を見つける理由はTIME_WAIT、クライアント上で問題が発生する可能性があるためです-クライアントは利用可能なポートを使い果たす可能性があるため、本質的には、上記のTIME_WAIT問題は、クライアント側に問題がある可能性がある負荷をそれは問題ではないサーバー側。 クライアント側TIME_WAITはもちろん、限られた数のユースケースでのみ問題になります。ほとんどのクライアントサーバーソリューションには、1台のサーバーと多数のクライアントが関係します。クライアントは通常、問題になるほど十分な量の接続を処理しません。SO_LINGERタイムアウトが0の場合や、tcp_tw sysctlを調整するのとは対照的に）TIME_WAITあまりにも多くの接続を作成しすぎないようにして、クライアント側と戦います。しかし、たとえば次のようなアプリケーションのクラスでは、常に実行可能であるとは限りません。 監視システム 負荷発生器 代理人 反対に、サーバー側TIME_WAITがどのように役立つかさえもわかりません。理由TIME_WAITはそこにもありTCPます。それは、もはや属していないストリームに古いフラグメントを注入することを防ぐためです。クライアント側TIME_WAITではip:port、この古い接続が持つことができたのと同じペアで接続を作成することを単に不可能にすることで達成されます（使用されたペアはによってロックアウトされますTIME_WAIT）。しかし、サーバー側の場合、ローカルアドレスには受け入れポートがあり、常に同じであり、サーバーは（私の知る限り、経験的証明しかありません）接続を拒否できないため、これを防ぐことはできません着信ピアは、ソケットテーブルにすでに存在する同じアドレスペアを作成します。 サーバー側のTIME-WAITが無視されることを示すプログラムを作成しました。さらに、テストは127.0.0.1で行われたため、カーネルには、サーバー側かクライアント側かを示す特別なビットが必要です（そうでなければ、タプルは同じになるため）。 ソース：http : //pastebin.com/5PWjkjEf、Fedora 22でテスト、デフォルトのネット設定。 $ gcc -o rtest rtest.c -lpthread $ ./rtest 44400 s # will do server-side close Will initiate server close ... iterates ~20 times successfully ^C $ ss -a|grep 44400 tcp TIME-WAIT 0 …

11 tcp 

iperf3クライアントとして使用するLinuxボックスがあり、2台の同じ装備のWindows 2012 R2サーバーボックスとBroadcom BCM5721、1Gbアダプターをテストしています（2つのポート、ただしテストに使用したのは1つだけです）。すべてのマシンは、単一の1Gbスイッチを介して接続されます。 300MbitなどでのUDPのテスト iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192 送信されたすべてのパケットの14％が失われます（まったく同じハードウェアを備えた他のサーバーボックスの場合、古いNICドライバーの場合、損失は約2％です）が、それほど深刻ではありませんが、50Mbitでも損失が発生します。同等の設定を使用したTCPパフォーマンス： iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192 報告された再送信なしで800Mbitの北の伝送速度をもたらします。 サーバーは常に次のオプションを使用して起動されます。 iperf3 -sB192.168.30.161 誰のせいですか？ Linuxクライアントボックス（ハードウェア？ドライバー？設定？）？ 編集： Windowsサーバーボックス間でテストを実行したところ、300MbitのUDPパケット損失はさらに大きく、22％でした Windowsサーバーボックス（ハードウェア？ドライバー？設定？）？ すべてのテストマシンを接続する（単一の）スイッチですか？ ケーブル？ 編集： 今、私は別の方向を試してみました：Windows-> Linux。結果：パケット損失は常に0ですが、スループットは約で最大になります 840Mbit -l8192、つまりフラグメント化されたIPパケット 250Mbit for -l1472、断片化されていないIPパケット フロー制御はスループットを制限し、パケット損失を防ぐと思います。特に後者の、断片化されていない数値はTCPスループットに近いところにありません（断片化されていないTCPは断片化されたTCPと同様の数値をもたらします）が、パケット損失の点でLinux-> Windowsをはるかに上回る改善です。 そして、どうやって見つけるのですか？ サーバーのドライバー設定に関する通常のアドバイスに従ってパフォーマンスを最大化し、有効化/無効化/最大化/最小化/変更を試みました 割り込みモデレーション フロー制御 受信バッファー RSS ウェイクオンLAN すべてのオフロード機能が有効になっています。 編集私も有効/無効にしようとしました イーサネット@ワイヤスピード …

11 performance  tcp  udp  packetloss  iperf 

スイッチへの10GbE接続を備えたサーバーと、それぞれ同じスイッチへの1GbE接続を備えた10個のクライアントがあります。 各クライアントでnuttcpを並行して実行すると、10のTCPストリームのデータをワイヤスピードに近い速度で同時にサーバーにプッシュできます（つまり、10のクライアントすべてからわずか100メガバイト/秒）。 ただし、方向を逆にしてサーバーからクライアントにデータを送信すると（つまり、各クライアントに1つのTCPストリームが10回）、TCP再送信が急増し、パフォーマンスが1秒あたり30、20、または10メガバイトにまで低下しますクライアントごと。このトラフィックパターンは、私が関心を持っている特定のアプリケーションの代表であるため、これらの数値を上げたいと思います。 同様のサーバーへの10GbE接続で同じ実験を実行することにより、サーバーが10GbEリンクを飽和できることを確認しました。ポートにエラーがないことを確認しました。 最後に、受信者のTCPウィンドウサイズを強制的にクランプ（制限）すると、帯域幅を多少高くすることができます（30〜40メガバイト/秒）。そして、非常に低くクランプすると、再送信をゼロにできます（帯域幅はばかげて低くなります）。 したがって、スイッチのバッファをオーバーランさせており、輻輳によるパケット損失が発生していると確信しています。ただし、TCPの輻輳制御はこれをうまく処理し、最終的にワイヤ速度の50％を超える値で安定するはずであると考えました。 したがって、私の最初の質問は非常に単純です：どのTCP輻輳制御アルゴリズムが私の状況に最適でしょうか？たくさんありますが、ほとんどは損失の多いネットワーク、高帯域幅、高遅延のネットワーク、またはワイヤレスネットワークをターゲットにしているようです。いずれも私の状況には当てはまりません。 2番目の質問：他に試すことができるものはありますか？

11 linux  networking  tcp