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

TCPはTransmission Control Protocolの略で、インターネットプロトコルスイートのコアプロトコルの1つです。TCPはインターネットプロトコル(IP)を補完するため、スイート全体は一般にTCP / IPと呼ばれます。

2
Linuxの最新バージョンでのより高いTCPレイテンシ
私の研究グループでは、最近、マシンのOSをRed Hat 6.2からDebian 8.3にアップグレードし、マシン間の統合Intel 1G NICを介したTCPラウンドトリップ時間が約110µsから220µsに倍増したことを観察しました。 最初は構成の問題だと思ったので、tcp_low_latency=1アップグレードされていないRed HatマシンからDebianマシンにすべてのsysctl構成(など)をコピーしましたが、問題は解決しませんでした。次に、これはLinuxディストリビューションの問題であると考え、マシンにRed Hat 7.2をインストールしましたが、往復時間は約220µsのままでした。 最後に、Debian 8.3とRed Hat 7.2の両方がカーネル3.xを使用していて、Red Hat 6.2がカーネル2.6を使用していたため、問題はLinuxカーネルバージョンにあると考えました。これをテストするために、Linuxカーネル2.6とビンゴでDebian 6.0をインストールしました。時間は再び110µsで速くなりました。 他の人も、最新バージョンのLinuxでこれらの高いレイテンシを経験しましたか?既知の回避策はありますか? 最小作業例 以下は、レイテンシのベンチマークに使用できるC ++アプリケーションです。メッセージを送信し、応答を待ってから、次のメッセージを送信することにより、レイテンシを測定します。100バイトのメッセージでこれを100,000回行います。したがって、クライアントの実行時間を100,000で割ると、往復の待ち時間が得られます。これを使用するには、まずプログラムをコンパイルします。 g++ -o socketpingpong -O3 -std=c++0x Server.cpp 次に、ホストでアプリケーションのサーバー側バージョンを実行します(たとえば、192.168.0.101)。IPを指定して、よく知られているインターフェイスでホストしていることを確認します。 socketpingpong 192.168.0.101 そして、Unixユーティリティtimeを使用して、クライアントの実行時間を測定します。 time socketpingpong 192.168.0.101 client 同一のハードウェアを備えた2つのDebian 8.3ホスト間でこの実験を実行すると、次の結果が得られます。 real 0m22.743s user 0m0.124s sys 0m1.992s Debian 6.0の結果は real 0m11.448s user 0m0.716s sys …

2
Squidを「TLS終了プロキシ」として使用して、クライアント証明書を使用してTCP接続を暗号化できますか?
概要 複数のクライアントからインターネット上の単一のポートへの暗号化されたTCP接続が必要です。これはSquidで実現できますか? 具体的な状況 私たちは、LANとVPNを介してアクセスできる社内の監視およびクライアント管理ソリューションを使用しています。これで、会社のVPNを使用しない外部ノートブックからアクセスできるはずです。通信は暗号化する必要があります(TLS)。クライアント認証では、クライアント証明書を使用する必要があります。通信はクライアントによって開始され、単一のTCPポートを使用します。 私の調査結果 NGINX Plusはこの機能を提供しているようですが、管理者はSquidまたはApacheを好みます。イカのwikiで私はそれを発見しました:機能:HTTPS暗号化が言及されているHTTPS(HTTPセキュアまたはHTTP over SSL / TLS)。しかし、私はこの警告も見つけました: CONNECTを介して渡されるプロトコルは、Squidが通常処理するものに限定されないことに注意することが重要です。文字通り、双方向のTCP接続を使用するものなら何でも、CONNECTトンネルを通過できます。これが、SquidのデフォルトACLが拒否CONNECT!SSL_Portsで始まる理由であり、その上に任意のタイプの許可ルールを配置する十分な理由があるはずです。 同様の質問 この質問SSLを使用したSquidフォワードプロキシによるクライアント接続の暗号化は同様ですが、リバースプロキシ/ TLS終了プロキシは扱いません。 知っておくべきこと 私はその技術についての基本的な知識しか持っておらず、私たちの管理者が一般的な実現可能性について私に尋ねました。 Squidを使用してTCP接続の暗号化を保存できますか? これは、クライアント証明書による認証を使用して実現できますか? または、HTTPS接続にのみ使用する必要がありますか?

1
予期せず縮小したウィンドウ
主要なメディアのアップロード/ダウンロードサイトを運営していますが、次のことに気づきました。 これはファイルサイズが大きいために深刻なノイズですか、それともバックグラウンドノイズですか?/etc/sysctl.confに追加して問題を改善および防止するための微調整はありますか? [8822139.804040] TCP: Peer 177.47.116.196:53829/80 unexpectedly shrunk window 2513116350:2513136117 (repaired) [8822140.944041] TCP: Peer 177.47.116.196:53829/80 unexpectedly shrunk window 2513116350:2513136117 (repaired) [8822143.224052] TCP: Peer 177.47.116.196:53829/80 unexpectedly shrunk window 2513116350:2513136117 (repaired) [8822147.776079] TCP: Peer 177.47.116.196:53829/80 unexpectedly shrunk window 2513116350:2513136117 (repaired) [8822156.896049] TCP: Peer 177.47.116.196:53829/80 unexpectedly shrunk window 2513116350:2513136117 (repaired) [8822175.136049] TCP: Peer …

2
開いているポートが不足しているワニス、多数のSYN_SENT接続
最近、Varnish(3x)-> Apache(3x)のセットアップで問題が発生し、SYN_SENT接続が急増しました。 スパイク自体は、サイトにヒットする新しいトラフィックの量が原因であり(どのような種類のDDOSでもありません)、ワニスマシンがバックエンドサーバーにトラフィックを転送するときに問題が発生しているようです(Apacheトラフィックのドロップは、ワニスのスパイクと相関しています) )、使用可能なポートプールをで輻輳させますSYN_SENT。 キープアライブはApache(15s)で有効になっています。 どちらの側に障害がありますか?トラフィック量は重要ですが、そのようなセットアップ(3x Varnishフロントエンドマシン、3xバックエンドApacheサーバー)が停止することは決してありません。 助けてください。 ファイアウォールを介した接続のMuninス​​クリーンショットはこちらです。 ワニス ~$ netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c 9 CLOSE_WAIT 12 CLOSING 718 ESTABLISHED 39 FIN_WAIT1 1714 FIN_WAIT2 76 LAST_ACK 12 LISTEN 256 SYN_RECV 6124 TIME_WAIT /etc/sysctl.conf(ワニス) net.ipv4.netfilter.ip_conntrack_max = 262144 net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60 net.ipv4.ip_local_port_range = 1024 65536 net.core.rmem_max = 16777216 net.core.wmem_max …

1
HTTP、TCP、UDP、コネクションレス
最近、HTTPと少し混乱しています。 いくつかの事実は、TCPがコネクション指向またはコネクションレスで動作できることです。これは理解しています。ただし、TCPはコネクション型ですが、UDPはコネクションレスであり、メッセージ自体が単一のメッセージに収まる場合に使用されます。 質問: HTTPがTCPを使用し、TCPが複数のメッセージ交換に信頼できる接続を提供し、HTTPがコネクションレスであると言われている場合、これはどのようにして可能ですか? TCPはコネクション型ですか?では、HTTPコネクションレスはどうですか????
8 http  tcp  tcpip  udp 

4
特定のTCPポートで現在開いている接続の数を確認するにはどうすればよいですか?
私はいくつかの彗星のベンチマークを行っています、そして私が持っているオープンコネクションの数を知りたいです。 実際、私はnetstatを使用しています: netstat -ant | grep 8080 | grep EST | wc -l しかし、数をリストするのに約4〜6分必要です。リアルタイムで表示できるツールはありますか?開いている接続の数は100'000〜250'000です。

5
TCP / IP用語で、オフィスのダウンロード速度リミッターはどのように機能しますか?
人々のオフィスを想定し、他のトラフィックをブロックしないように、HTTPダウンロードをインターネット接続速度の最大40%の帯域幅に制限したいと考えています。 「ファイアウォールではサポートされていません」とあり、「以前はNetgear / DLink / DrayTekでそれを行うことができました」という不可避の行があります。 考えてみると、ダウンロードは次のようになります。 HTTP GET request Server sends file data as TCP packets Client acknowledges receipt of TCP packets Repeat until download finished. 速度は、サーバーがデータを送信する速度と、データを確認する速度によって決まります。 したがって、ダウンロード速度を制限するには、2つの選択肢があります。 1)サーバーにデータをゆっくり送信するように指示します。TCPまたはHTTPでそれを要求するプロトコル機能はないと思います。 2)アップロード速度を制限することで、パケットの確認速度を遅くし、アップロード速度を台無しにします。 デバイスはどのようにこの制限を行いますか?標準的な方法はありますか?
8 networking  tcp 

1
カーネル2.6.33でIW10を利用するにはどうすればよいですか?
2.6.33以降でカスタムcwndを設定できることを確認しました。 IWがデフォルトで10の場合(すべてのディストリビューションの場合、一部のみですか?) 特定のコンパイル済みカーネルで現在のIWがどうなっているのかをどのように表示しますか? 参照: http://monolight.cc/2010/12/increasing-tcp-initial-congestion-window/ http://www.igvita.com/2011/10/20/faster-web-vs-tcp-slow-start/
8 linux  http  tcp  kernel 

2
Linux TCPでのウィンドウスケーリングの問題の修正
海外にあるサーバーのスループットを改善しようとしています。サーバーとホームコンピューター間の転送をWiresharkで監視したところ、ウィンドウサイズに問題があると確信しています。 FTP転送の場合、受信ウィンドウサイズは14720です。 Window size value: 115 Calculated window size: 14720 Window size scaling factor: 128 私の送信ウィンドウは、私が設定したものに似ています: Window size value: 65335 Calculated window size: 261340 Window size scaling factor: 4 では、どうすればrwindowを修正できますか?サーバーのLinux TCP設定を確認しましたが、すべて正常です。タイムスタンプはオン、syncookiesはオフ、スケーリングはオン、sackはオン、キュービックは輻輳制御メソッド、最大受信および送信ウィンドウサイズは3MBです。デフォルトのtcp_wmemとtcp_rmemの値を変更してみましたが、何も起こりません。 編集: サーバーで自動チューニングやウィンドウスケーリングをオフにすると、ウィンドウは14600に縮小します。これは基本的にMSSの10倍です。 5337 4.268584 2.2.2.2 1.1.1.1 FTP 106 Response: 227 Entering Passive Mode (2,2,2,2,240,15). 5338 4.268640 1.1.1.1 2.2.2.2 TCP …

5
「高遅延ネットワーク」でのTCPパフォーマンスの向上
Linuxマシン間の「高遅延ネットワーク」を介してTCPスループットを改善しようとしています。 私はセットtcp_mem、tcp_wmemおよびtcp_rmem「8192 7061504 7061504」へ。 私が設定しrmem_max、wmem_max、rmem_defaultおよびwmem_default「7061504」へ。 私はセットnetdev_max_backlogとtxqueuelen10000への Iセットtcp_congestion_control「スケーラブル」へ。 「nist」(cnistnet)を使用して100ミリ秒の遅延をシミュレートしています。到達する帯域幅は約200 mbpsです(遅延なしでは約790 mbpsに到達します)。 テストを実行するためにiperfを使用し、結果を分析するためにTCPTraceを使用しています。 受信側: 最大勝利adv:5294720バイト 平均勝利adv:5273959バイト 送信されたsack pkts:0 送信側: 実際のデータバイト:3085179704 rexmtデータバイト:9018144 最大owin:5294577バイト 平均owin :3317125バイト RTT最小:19.2 ms RTT最大:218.2 ms RTT平均:98.0 ms なぜ200mbpsしか到達しないのですか?「owin」は何かと関係があると思いますが、よくわかりません(これらの結果は2分のテストの結果です。1分のテストの「avg owin」は1552900でした)… 遅延が100ミリ秒であっても、スループットがほぼ790 Mbpsであると誤解していますか? (私はウィンドウ構成でより大きな数を使用しようとしましたが、効果がないようです)

3
TCP / IPセッションを60秒未満で実行できますか?
私たちのサーバーはTCP / IPセッションで過負荷になっています。それらのほとんどはTIME_OUT状態でハングしています。TIME_OUT状態の接続は、60秒のタイムアウトが経過するまでソケットを占有していることがわかります。 問題は、サーバーが応答しなくなり、多くのクライアントがサービスを受けられないことです。 簡単なテストを行いました。InternetExplorer 8.0を使用してサーバーからXMLファイルをダウンロードします。ダウンロードはほんの一瞬で完了します。しかし、TCP / IP接続がTIME_OUT状態で60秒間ハングしていることがわかります。 TIME_OUTの待機を解消する方法、または新しい接続用にソケットを解放する方法を減らす方法はありますか? TCP / IP接続がTIME_OUT状態になる理由はわかりますが、XMLファイルのダウンロードが終了した後、Internet Explorerが接続を閉じない理由はわかりません。 詳細。 私たちのサーバーは、Perl(mod-perl)で記述されたWebサービスを実行します。このサービスは、気象データをクライアントに提供します。クライアントはFlashアプリケーション(実際にはWindowsアプリケーションに埋め込まれたFlash ActiveXコントロール)です。 OS:Ubuntu Apacheの「Keep Alive」オプションが0に設定されている

1
Windows 2008サーバーで最大接続バックログ制限を増やす方法
Windows 2008 Serverを使用しています。最大接続バックログ制限(TCP)は200です。この制限をより高い値(1000または2000など)に増やす方法はありますか? で、この記事で、あなたは、このキーの下のレジストリの変更へのパラメータの説明があります: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ AFD \ Parameters 関連する値は次のとおりです。 EnableDynamicBacklog(DWORD) MinimumDynamicBacklog(DWORD) MaximumDynamicBacklog(DWORD) DynamicBacklogGrowthDelta(DWORD) 私は次のような異なる値のセットを使用してみました EnableDynamicBacklog = 1 MinimumDynamicBacklog = 250 MaximumDynamicBacklog = 20000 DynamicBacklogGrowthDelta = 100 そして EnableDynamicBacklog = 1 MinimumDynamicBacklog = 20 MaximumDynamicBacklog = 1000 DynamicBacklogGrowthDelta = 10 しかし、私が何をしても、未処理の接続数は200に制限されます。(そして、はい、設定変更の間にサーバーを再起動しました。) 何か案は?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.