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

1台のマシンが持つことのできるポートの数に制限があり、ソケットが未使用のポート番号にしかバインドできない場合、サーバーはこれをどのように処理しますか？システムを分散させる、つまり、多くのマシンに多くのサーバーを配置するだけで実現できますか？

29 web-server  http  port  tcp  traffic-management 

WindowsのデフォルトのTCP接続タイムアウトはどれですか？それを設定するレジストリキーがありますか、それは動的に設定されていますか？

28 windows  tcpip  tcp 

Webサーバーへのcurl要求が機能しない理由のトラブルシューティングを進める方法を知りたいです。私の環境に依存するヘルプを探しているのではなく、通信のどの部分が失敗しているか、ポート番号などに関する情報を収集する方法を知りたいだけです。 chad-integration:~ # curl -v 111.222.159.30 * About to connect() to 111.222.159.30 port 80 (#0) * Trying 111.222.159.30... connected * Connected to 111.222.159.30 (111.222.159.30) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0 OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10 > Host: 111.222.159.30 > Accept: */* > * Empty reply from …

27 tcp  curl 

多くの管理者は、ServerFaultやその他の場所で、たとえばVPNのようなTCP-over-TCPのアイデアがどれほど悪いかを永続させています。TCPのメルトダウンでなければ、わずかなパケット損失でも少なくとも深刻なスループット低下に悩まされるため、TCP-over-TCPは厳密に回避する必要があります。そして、おそらく2001年にこの記事が書かれた2001年はまだ言及されているが、それはおそらくすべて真実だった。 しかし、それ以来、テクノロジーとプロトコルに大きな進歩が見られました。最近では、ほぼすべての場所で「選択的ACK」が実装されており、ムーアの法則により非常に多くのメモリが提供されており、Gbitアップリンク用に最適化された大きなTCPバッファが付属しています。また、最近では、非無線リンクでのパケット損失の問題ははるかに少なくなっています。これはすべて、TCP-over-TCPの問題を大幅に軽減するはずです。 たとえば、TCPベースのVPNは、UDP / ESPベースのVPNよりも実装および操作が簡単な現実のシナリオがあることに注意してください（以下を参照）。したがって、私の質問： TCP-over-TCPのパフォーマンスは、どのような状況（リンクパケットの損失と遅延）で、SACKサポートと両端の適切なサイズのTCPバッファーを想定して、TCP単独よりも著しく悪化しますか？ TCP-over-TCPおよびTCPのみの場合、（外部接続）パケット損失/遅延と（内部接続）スループット/ジッターとの相関関係を示す測定値を参照してください。この興味深い記事を見つけましたが、それはレイテンシーのみに関心があり、（外部）パケット損失には対処していないようです。 また、TCPとTCP-over-TCPのパフォーマンスのギャップを狭めるための推奨設定（TCPオプション、バッファー設定、MTU / MSSの削減など）はありますか？ 更新：根拠。 この質問は、実際のシナリオでは依然として非常に重要です。たとえば、センサーデータを収集し、それをVPN経由でプラットフォームに送信する大規模な建物に組み込みデバイスを展開します。私たちが直面している問題は、ファイアウォールと不適切に構成されたアップリンクであり、私たちの管理下になく、消極的なIT部門と組み合わされています。ここで説明されている詳細な例を参照してください。 そのような場合の多くでは、非TCPからTCPベースのVPNへの切り替え（私たちのようなOpenVPNを使用している場合は非常に簡単です）は、困難な指先の戦いを回避するための簡単な修正です。たとえば、多くの場合、TCPポート443は一般に許可されます（少なくともプロキシ経由）。または、TCPのMSSオプションを減らすだけでPath-MTUの問題を克服できます。 どのような状況下でTCPベースのVPNが実行可能な代替手段と見なされるかを知っておくとよいでしょう。そのため、いずれかのオプションの長所と短所を上回る情報に基づいた決定を下すことができます。たとえば、非無線リンクではTCP-VPNは問題ないことはわかっていますが、3Gアップリンク上のリモートクライアントはかなりの割合でパケット損失が大きく、待ち時間が長くなっています-TCP-VPNはどのように機能しますか？ それに応じてタイトルと中心的な質問を改善しようとしました。理にかなっているといいのですが。

25 networking  vpn  ip  tcp  network-protocols 

こんにちはサーバー障害の住人 約100台のコンピューター、2台のWindowsドメインサーバー、12台のVoIP電話で構成されるLANで、いらいらする問題があります。約1年前、毎週かそこらにインストールしてから、VoIP電話が自動的にリセットされることに気付きました-時々通話の途中です。同時に、コンピューター上の接続が一時的に失われる兆候もしばしば見られます。ネットワーク共有にアクセスしているときにエクスプローラーがフリーズしたり、データベースサーバーへの接続が失われたために管理ソフトウェアにエラーが発生したりします。 VoIP PBXとネットワークの残りの部分との間の接続でWiresharkの監視を行っています。Wiresharkは、電話の再起動を記録するときに、再送信されたTCPパケットの塊を拾います。Wiresharkのログには、1日あたり5パケットから数百件までの約2クラスターの再送信が記録されています。各クラスター内のそれらは主にPBXとVoIP電話のセットの間にありますが、常に同じセットではありません。多くの場合、同時に再送信されるのは同じスイッチに接続された電話ですが、ネットワークの両端にある電話に対して再送信が同時に発生することもあります。通常、クライアントマシンとファイルサーバー間など、TCPトラフィックの受け渡しでいくつかの偶然の再送信があります。 再送信と電話のリセットの急増は、ネットワークの負荷が高い場合とはあまり相関しません。それらは日中にわずかに多く発生するようですが、ほとんどの場合、トラフィックが減少するはずの夜に発生します。ほとんどのコンピューターの電源がオフになっていて、トラフィックを最小限に抑える必要がある夜間にかなり頻繁に発生します。 このような問題の原因を診断するのに役立つアイデアはありますか？まだ試していませんが、そうすべきである1つのことは、すべてのスイッチのファームウェアを更新することです。

25 networking  tcp  voip 

ここで何が求められているかを伝えるのは難しいです。この質問は曖昧、曖昧、不完全、過度に広範、または修辞的であり、現在の形式では合理的に答えることができません。この質問を明確にして、再開できるようにするには、ヘルプセンターに アクセスしてください。 6年前に閉鎖されました。 特定のTCPポートを使用する外部ホストへの接続がブロックされている場所を特定しようとしています。Traceroute for WindowsはICMPのみを使用し、Telnetはポートがどこでではなくブロックされていることのみを通知します。誰もこれを達成するtracerouteに似たWindowsユーティリティを知っていますか？

23 windows  networking  tcp  trace 

ここの表によると、 MTU = 1500バイトであり、ペイロード部分は1500-42バイトまたは1458バイトであると言います（<-これは実際に間違っています！）。さらにその上に、28バイト（20 IP + 8 UDP）のIPv4およびUDPヘッダーを追加する必要があります。これにより、アプリケーションメッセージの最大可能数は1430バイトになります。しかし、インターネットでこの番号を探すと、代わりに1472が表示されます。ここでこの計算を間違っていますか？ 私が知りたいのは、断片化のリスクなしにネットワークを介して送信できる最大のアプリケーションメッセージだけです。フレームヘッダーが含まれているため、確実に1500ではありません。誰か助けてもらえますか？ 混乱は、PAYLOADが実際に1500バイトにもなることがあり、それがMTUであるということです。それでは、1500のペイロードのワイヤ内サイズはどのくらいですか？そのテーブルからは、1542バイトまで大きくなる可能性があります。 したがって、送信できるアプリメッセージの最大数は1472（1500-20（ip）-8（udp））で、ワイヤーサイズは1542で最大です。実際に単純な場合に、事態がどのように複雑になるかは驚きです。また、テーブルに1542と表示されている場合、誰かが1518という数字をどのように思いついたかはわかりません。

22 networking  tcp  ethernet  udp  mtu 

ロックされています。この質問に対するコメントは無効になっていますが、新しい回答やその他の相互作用はまだ受け付けています。詳細をご覧ください。 これはこれに関連しているように見えますが、多少異なります。 2つの企業サイト間にこのWANリンクがあり、1つの非常に大きなファイル（Oracleダンプ、最大160 GB）を転送する必要があります。 完全な100 Mbpsの帯域幅（テスト済み）がありますが、TCPの仕組み（ACKなど）により、単一のTCP接続では最大にならないようです。リンクをiperfでテストし、TCPウィンドウサイズを大きくすると結果が劇的に変化します。基本設定では最大5 Mbpsのスループットが得られ、より大きなWSでは最大で最大45 Mbpsが得られますが、それ以上は得られません。ネットワーク遅延は約10ミリ秒です。 好奇心から、1つ以上の接続を使用してiperfを実行しましたが、4つの接続を実行すると、実際にはそれぞれ〜25 Mbpsの速度に達し、利用可能なすべての帯域幅がいっぱいになることがわかりました。そのため、複数の同時転送を実行することが重要になります。 FTPでは、事態はさらに悪化します。最適化されたTCP設定（高いウィンドウサイズ、最大MTUなど）でも、1回の転送で20 Mbpsを超えることはできません。いくつかの大きなファイルを同時にFTPで送信しようとしましたが、実際には1つのファイルを転送する場合よりもはるかに良くなりました。しかし、その後、犯人はディスクI / Oになりました。これは、同じディスクの4つの大きなファイルの読み込みと書き込みがすぐにボトルネックになるためです。また、少なくとも1つの大きなファイルを小さなファイルに分割してから、少なくとも許容時間内にマージして戻すことはできないようです（明らかに、ファイルのスプライシング/マージバックに相当する時間を費やすことはできません）転送）。 ここでの理想的なソリューションは、ファイルのさまざまなチャンクを同時に転送できるマルチスレッドツールです。eMuleやBitTorrentのようなピアツーピアプログラムのようなものは既にありますが、単一のソースから単一の宛先までです。理想的には、このツールを使用すると、使用する並列接続の数を選択でき、もちろん、ファイルのさまざまなセクション間で狂ったように（あまりにも）ジャンプしないようにディスクI / Oを最適化できます。 誰でもそのようなツールを知っていますか？ または、誰もがより良い解決策や私たちがまだ試みていない何かを提案できますか？ PSすでにテープ/ディスクにバックアップし、宛先に物理的に送信することを考えました。WANがそれを削減しない場合、それは私たちの極端な測定値になりますが、AS Tanenbaumが言ったように、「高速道路を疾走するテープでいっぱいのステーションワゴンの帯域幅を過小評価しないでください」。

21 networking  bandwidth  tcp  file-transfer 

複数の重複したACKレコードを表示している少数のクライアントマシンからのWiresharkキャプチャを確認しています。これにより、再送信パケットとシーケンス外パケットがトリガーされます。 これらは、次のスクリーンショットに示されています。.26はクライアントで、.252はサーバーです。 ACKレコードが重複する原因は何ですか？ それが役立つ場合の背景： 特定のクライアントサイトでのネットワークスループットの問題を調査しています。ユーザーインターフェイスの観点から認識される問題は、1 gbpsのWAN接続が十分に活用されていないにもかかわらず、データがゆっくりと送信されることです。 ほとんどすべてのクライアントマシンに同じ問題があり、20台を超えるマシンでテストされています。問題のない2台のマシンが見つかりました。現在、構成の違いを特定しています。問題のない2台のマシンで、ACKレコードが重複するのは最大で1つしか見られなかったことに気付きました。通常、問題のあるマシンには3つの重複したACKレコードがあります。注目すべき違いの1つは、正常に動作するマシンはすべてネットワーク運用チームのメンバーに属し、他のすべてのマシンは「正社員」用であることです。マシンは標準であるはずですが、ネットワーク管理者はローカルシステムに変更を加えることもできました。これは、私たちが調査しているもう1つの側面です。 サーバーのTcpMaxDupAcks設定を変更しようとしましたが、実際に必要な値は5で、有効な範囲は1〜3のみです。 サーバーはWindows Server 2003です。クライアントはすべてエンタープライズ管理のWindows XPです。2つの正常に動作するクライアントを含むすべてのクライアントに、Symantecアンチウイルスがインストールされています。 これは、この問題を示した数百のクライアントサイトの中で唯一のものです。 pathping 問題のマシンからでも56ms RTTと一貫した0/100パケット損失を示しています。 おかげで、 サム

19 windows-server-2003  windows-xp  tcp  wireshark 

ニューヨークのデータセンターから、遠く離れた場所への転送のパフォーマンスが低下しています。 速度テストを使用してさまざまな場所をテストすると、ボストンおよびフィラデルフィアへの100メガビットアップリンクを簡単に飽和させることができます。米国またはヨーロッパの西海岸の場所に速度テストを使用すると、約9メガビット/秒しか表示されないことがよくあります。 私の最初の反応は、これがウィンドウスケーリングの問題であることです（帯域幅遅延積）。ただし、西海岸のテストマシンでLinuxカーネルパラメーターを調整し、1秒あたり100メガバイトをサポートするのに十分なサイズにウィンドウがサイズ変更されるまでiperfを使用しましたが、速度はまだ低速です（Captureで検証済み）。また、Nagleアルゴリズムを無効にしようとしました。 LinuxとWindowsの両方からパフォーマンスは低下しますが、Windowsを使用した場合の速度は大幅に低下します（1/3）。 転送の形状（Nagleなし）は次のとおりです。 10秒前後のDipには、重複する〜100個のAckがあります。 時間の経過に伴う受信機の最小ウィンドウサイズの形状は次のとおりです。 ボトルネックを突き止めるために次にどこに行くべきかについてのアイデアはありますか？ 速度テストの結果（speedtest.netを使用してアップロード）： フィラデルフィア：44メガビット（このサイトを使用している人々は残りを使用しています;-)） マイアミ：15メガビット ダラス：14メガビット サンノゼ：9メガビット ベルリン：5メガビット シドニー：2.9 mbit さらに多くのデータ： マイアミ：69.241.6.18 2 stackoverflow-nyc-gw.peer1.net (64.34.41.57) 0.579 ms 0.588 ms 0.594 ms 3 gig4-0.nyc-gsr-d.peer1.net (216.187.123.6) 0.562 ms 0.569 ms 0.565 ms 4 xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65) 0.634 ms 0.640 ms 0.637 ms 5 vlan79.csw2.newyork1.level3.net (4.68.16.126) 4.120 ms …

19 networking  tcp 

明らかにソケットを開くことにより、ファイル記述子が不足しているアプリケーションがありますが、これらのソケットが何をするのか正確にはわかりません。これらはlsof出力に次のように表示されます java 9689 appuser 1010u sock 0,5 263746675 can't identify protocol java 9689 appuser 1011u sock 0,5 263746676 can't identify protocol java 9689 appuser 1012u sock 0,5 263746677 can't identify protocol java 9689 appuser 1014u sock 0,5 263746678 can't identify protocol java 9689 appuser 1015u sock 0,5 263746679 can't identify …

19 linux  networking  tcp  udp  socket 

この質問の最後に追加された新しい詳細。私が原因を突き止めている可能性があります。 UDP OpenVPNベースのVPNをtapモードで設定しています（tapマルチキャストパケットを通過させるためにVPNが必要なため、tunネットワークでは不可能と思われるため）、インターネット上の少数のクライアントを使用しています。VPNで頻繁にTCP接続がフリーズすることがあります。つまり、TCP接続（たとえば、SSH接続ですが、他のプロトコルには同様の問題があります）を確立し、セッション中のある時点で、そのTCPセッションを介したトラフィックの送信が停止するようです。 これはls、SSHセッションでコマンドを実行する場合やcat、長いログファイルを使用する場合など、大量のデータ転送が発生するポイントに関連しているようです。一部のGoogle検索では、Server Faultで次のような多数の回答が表示されます。原因はMTUの問題である可能性が高いことを示しています。トラフィックが多い期間中、VPNは、 VPNエンドポイント。上記のリンクの回答は、次のOpenVPN構成設定を使用して問題を軽減することを提案しています。 fragment 1400 mssfix これにより、VPNで使用されるMTUが1400バイトに制限され、TCPの最大セグメントサイズが修正され、それより大きいパケットが生成されなくなります。これは問題を少し緩和するようですが、それでもフリーズが頻繁に発生します。fragmentディレクティブの引数として、1200、1000、576のサイズをいくつか試しましたが、すべて同様の結果が得られました。このような問題を引き起こす可能性のある、両端間の奇妙なネットワークトポロジは考えられません。VPNサーバーは、インターネットに直接接続されているpfSenseマシンで実行されており、クライアントも別の場所でインターネットに直接接続されています。 パズルのもう1つの奇妙なピース：tracepathユーティリティを実行すると、問題を解決できるようです。サンプルの実行は次のようになります。 [~]$ tracepath -n 192.168.100.91 1: 192.168.100.90 0.039ms pmtu 1500 1: 192.168.100.91 40.823ms reached 1: 192.168.100.91 19.846ms reached Resume: pmtu 1500 hops 1 back 64 上記の実行は、VPN上の2つのクライアント間で行われます：192.168.100.90からの宛先へのトレースを開始しました192.168.100.91。fragment 1200; mssfix;リンクで使用されるMTUを制限しようとして、両方のクライアントが構成されました。上記の結果はtracepath、2つのクライアント間で1500バイトのパスMTUを検出できたことを示唆しているようです。OpenVPN構成で指定されたフラグメンテーション設定のために、それはいくらか小さくなると思います。その結果はやや奇妙だと思いました。 さらに奇妙なことですが、ストール状態のTCP接続（たとえば、途中でフリーズするディレクトリリストを含むSSHセッション）がある場合、上記のtracepathコマンドを実行すると、接続が再び開始されます。なぜそうなるのかについての合理的な説明はわかりませんが、これは最終的に問題を根絶するための解決策を指しているのではないかと感じています。 誰か他のことを試してみるための推奨事項はありますか？ 編集：私は戻ってきて、これをもう少し見てみましたが、もっと混乱する情報しか見つかりませんでした： 上記のように、OpenVPN接続を1400バイトでフラグメント化するように設定しました。次に、インターネット経由でVPNに接続し、Wiresharkを使用して、ストールの発生中にVPNサーバーに送信されたUDPパケットを調べました。指定された1400バイトカウントを超えるものはなかったため、断片化は適切に機能しているようです。 1400バイトのMTUでも十分であることを確認するために、次の（Linux）コマンドを使用してVPNサーバーにpingを実行しました。 ping <host> -s 1450 -M do これは（断片化を無効にした）1450バイトのパケットを送信します（少なくとも1600バイトのような明らかに大きすぎる値に設定すると動作しないことを確認しました）。これらはうまく機能するようです。私は問題なくホストから返信を受け取ります。 …

19 vpn  openvpn  tcp  mtu 

DebianベースのルーターでSnortのパフォーマンスを調整しようとしています。私は次のようなものを見ていました： snort packet recv contents failure: No buffer space available だから私はバッファを8Mに引き上げましたが、それがうまくいかなかったとき、http：//fasterdata.es.net/fasterdata/host-tuning/linux/のチューニングガイドに従って16Mを試しました： #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In …

19 linux  tcp  linux-networking 

サーバーフォールトで回答できるため、 この質問はStack Overflowから移行されました。 10年前に移行され ました。 CentOSを実行している比較的新しい8コアボックスがあります。TCPを使用する統計サーバーを開発したいと思います。これは非常に単純で、TCP接続を受け入れ、カウンターをインクリメントし、接続を閉じます。キャッチは、少なくとも1秒に1万リクエストでこれを行う必要があるということです。CPU /メモリは問題ないだろうと思っていますが、この種のボリュームを許可するためにサーバーで設定する必要があるかもしれない人為的な制限（ハーフオープン接続など）の方が心配です。だから、これは可能ですか？どの設定に注意する必要がありますか？NICはそれを処理できませんか？

18 linux  networking  java  tcp  high-volume 

私は古い質問だと確信していることの助けを探しています。ネットワークスループットをより明確に理解することを切望している状況にありますが、「クリック」する情報を見つけることができないようです。 地理的に分散したいくつかのサーバーがあり、さまざまなバージョンのWindowsを実行しています。常に1つのホスト（デスクトップ）をソースとして使用すると仮定すると、そのホストから全国の他のサーバーにデータをコピーする場合、速度のばらつきが大きくなります。場合によっては、12MB / sでデータを一貫してコピーできる場合もあれば、0.8MB / sである場合もあります。8つの宛先をテストした後、0.6〜0.8 MB /秒または11〜12 MB /秒のいずれかであることに注意してください。主に関心のある建物では、ISPへのOC-3接続があります。 さまざまな変数が存在することは知っていますが、ここの専門家がいくつかの基本的な質問に答えて、理解を深める助けになることを望んでいたと思います。 1.）Windows XP、サーバー2003などを実行し、100 Mbpsのイーサネットカードと72ミリ秒の一般的な待機時間を備えた古いマシンの場合、0.8 MB / sの音はまったく妥当ですか？または、問題を示すのに十分遅いと思いますか？ 2.）「スループット= TCPウィンドウ/レイテンシ」の古典的な「数学的な最速速度」は、この場合、0.8 MB / s（64Kb / 72 ms）に計算されます。私の理解では、それは上限です。その速度を超えることは言うまでもなく、（オーバーヘッドのために）決して到達するとは思わないでしょう。ただし、場合によっては、12.3 MB / sの速度が見られます。ネットワークの周りに散在するSteelheadアクセラレーターがありますが、それらはそのような高い転送速度を説明できますか？ 3.）SMBとSMB2を使用すると、速度の違いを説明できることが示唆されています。実際、予想通り、パケットキャプチャは、予想されるように、プレイ中のOSバージョンに応じて両方が使用されていることを示しています。SMB2が使用されているかどうかを判断する理由はわかりますが、SMB2でどのようなパフォーマンスの向上が期待できるかを知りたいです。 私の問題は、経験の不足、さらに重要なことには、合理的なネットワーク速度とは何かという観点から見た視点にあるようです。誰もが来るコンテキスト/視点を伝えるのを助けることができますか？

18 windows  networking  tcp  wide-area-network  network-speed