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

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

4
2つのubuntuサーバーマシン間の低速接続をシミュレートする
次のシナリオをシミュレートしたいと思います。4台のubuntuサーバーマシンA、B、C、Dがあるとします。マシンAとマシンCの間でネットワーク帯域幅を20%、AとBの間で10%削減したいと思います。方法これを行うには、ネットワークシミュレーション/スロットルツールを使用しますか?

1
sysctl tcp_retries1が3に設定されていると、TCPパケットが7回再送信されます-なぜですか?
Ubuntu 12.04 宛先が受信した確認を受信しないときに、TCPがパケットを再送信しようとする回数をよりよく理解しようとしています。tcpのmanページを読んだ後、これがsysctl tcp_retries1によって制御されていることは明らかでした。 tcp_retries1 (integer; default: 3) The number of times TCP will attempt to retransmit a packet on an established connection normally, without the extra effort of getting the network layers involved. Once we exceed this number of retransmits, we first have the network layer update the route …

1
タイムスタンプが有効になっていると、一部のSYNパケットに応答がありません
Ubuntu 12.04.3(カーネル3.8.0-31-generic)を実行しているマシン(「サーバー」)で待機するTCPサーバーがあります。2つの異なるクライアントマシンから接続を受信します。マシンAはUbuntu 12.04.4(3.11.0-17-generic)を実行しており、マシンBはUbuntu 11.10(3.0.0-32-server)を実行しています。 サーバーでTCPタイムスタンプが有効になっている場合(sysctl net.ipv4.tcp_timestamps = 1)、マシンAからのSYNパケットが「無視」されることがあります。サーバーでtcpdumpを使用すると(無差別モードでは)、SYNが正常に到着し、正しいチェックサムが表示されます-応答がないだけです-SYN / ACKもRSTもありません。マシンAは、SYNを何度か再送信してから、あきらめます。マシンAで実行されているクライアントソフトウェア(この場合はwget)はすぐに新しい接続を再試行して成功し、瞬時にSYN / ACKを取得します。 マシンBは同じサーバーで問題はなく、トラフィックは正常に見えます-マシンAと同じTCPオプションを使用しています(キャプチャファイルで確認したところ)。サーバーでTCPタイムスタンプを無効にすると、すべてが正常に機能します。 無視されたSYNパケットのタイムスタンプは私には有効であるように思われるので、なぜそれらが問題を引き起こしているのか、あるいは根本的な原因であるのかどうかはわかりません。 匿名のpcapをここに配置しましたhttps://www.dropbox.com/s/onimdkbyx9lim70/server-machineA.pcap。サーバー(10.76.0.74)で取得され、マシンA(10.4.0.76)がHTTP GET(パケット1〜10)を正常に実行し、1秒後に同じURL(パケット11〜17)を再度フェッチしようとしましたが、代わりにSYNは無視されます。パケット18から27は別の成功です。 これは「サーバーがSYNパケットに応答してSYN / ACKパケットを送信しないのはなぜですか」で説明した問題と同様の問題であり、タイムスタンプを無効にすることが回避策である一方で、何が起こっているのかを理解したいと思います。これは単なるバグですか? 実行中のローカルファイアウォールはありません。サーバーはかなりの数のTCP接続(常に約32K)を処理しますが、十分な空きメモリ/ CPUがあります。pcapに示されたテストの時点では、マシンAとサーバーの間に他のTCP接続はありませんでした。サーバーアプリケーションの受け入れキューが突然いっぱいになる兆候はありません(それ以外に、両方のクライアントに影響するはずです)。サーバーで取得したpcapでパケットが問題ないように見えるので、介在するネットワークデバイスが障害を起こしているようには見えません。 私は最初にこれをubuntuフォーラムに投稿しましたが、後から見ると、これはより適切な場所かもしれません。手がかりのローンを期待しています。
9 tcp  timestamp  syn 

1
「curl:(56)SSL read:errno -5961」エラーの根本的な原因
私はいくつかのSSLの失敗を評価していてcurl、失敗したサイトの1つを使用するとcurl: (56) SSL read: errno -5961、ただし、そのエラーに対するGoogleのクエリでは、opensslの失敗の理由は表示されませんでした。 質問:カールが失敗した場合、どういう意味curl: (56) SSL read: errno -5961ですか? curl以下を完全に含めます... [mpenning@mpenning-lnx ~]$ curl -vk https://192.0.2.168/ * About to connect() to 192.0.2.168 port 443 (#0) * Trying 192.0.2.168... connected * Connected to 192.0.2.168 (192.0.2.168) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * warning: ignoring value of …
9 ssl  tcp  timeout  curl 

1
WireSharkがこのフレームを再構成されたPDUのTCPセグメントであると考えるのはなぜですか
私の問題を説明する小さなpcapファイルをここで見つけてください。 3方向のTCPハンドシェイクと、それに続く2つのFIXログオンがあります。(FIXは取引で使用されるプロトコルです。)最初のFIXログオン(フレーム4)はWireSharkによって正しく解釈および解析されますが、2番目のログオン(フレーム6)はとして解釈されますTCP segment of a reassembled PDU。 ただし、フレーム6は、再構成されたPDUのTCPセグメントではありません。これには、FIXログオンとして解釈および解析する必要がある完全なTCP PDUが含まれています。シーケンス番号、ACK番号、IP合計長などがすべて良好であることを確認しました。 フレーム6が再構成されたPDUのTCPセグメントとして解釈されるのはなぜですか?
9 tcp  wireshark 

3
大規模なRTTで1GbpsサーバーからのTCPスループットが100Mbpsサーバーよりも低い
インフラストラクチャは、シンガポール、ロンドン、ロサンゼルスなど、世界中のいくつかの主要な場所に分散しています。2つの場所間のRTTは150ms以上です。 最近、すべてのサーバーを1Gbpsリンクを使用するようにアップグレードしました(100Mbpsから)。私たちはさまざまな場所にあるサーバー間でいくつかのTCPベースのテストを実行しており、いくつかの驚くべき結果を見てきました。これらの結果は完全に再現可能です。 ロサンゼルス(100Mbps)からロンドン(100Mbps):〜96Mbpsスループット ロサンゼルス(100Mbps)からロンドン(1Gbps):〜96Mbpsスループット ロサンゼルス(1Gbps)からロンドン(100Mbps):10-40Mbpsスループット(揮発性) ロサンゼルス(1Gbps)からロンドン(1Gbps):10-40Mbpsスループット(揮発性) ロサンゼルス(1Gbps)からロサンゼルス(1Gbps):900Mbpsを超えるスループット 送信側が1Gbpsで実行されている場合は常に、長いリンクではスループットが大幅に低下するようです。 以前のテストアプローチは非常に単純です-私はcURLを使用してターゲットサーバーから1GBのバイナリをダウンロードしています(上記の場合、cURLクライアントはロンドンのサーバーで実行され、LAからダウンロードするため、LAが送信者になります)。 。もちろん、これは単一のTCP接続を使用しています。 iperfを使用してUDPで同じテストを繰り返すと、問題が解消します。 ロサンゼルス(100Mbps)からロンドン(100Mbps):〜96Mbpsスループット ロサンゼルス(100Mbps)からロンドン(1Gbps):〜96Mbpsスループット ロサンゼルス(1Gbps)からロンドン(100Mbps):〜96Mbpsスループット ロサンゼルス(1Gbps)からロンドン(1Gbps):250Mbpsを超えるスループット これは、私の目にあるTCPまたはNIC /ポート構成の問題を直視しています。 両方のサーバーは、TCPキュービックでCentOS 6.xを実行しています。どちらも最大8MBのTCP送受信ウィンドウがあり、TCPタイムスタンプと選択的確認応答が有効になっています。すべてのテストケースで同じTCP構成が使用されます。完全なTCP構成は以下のとおりです。 net.core.somaxconn = 128 net.core.xfrm_aevent_etime = 10 net.core.xfrm_aevent_rseqth = 2 net.core.xfrm_larval_drop = 1 net.core.xfrm_acq_expires = 30 net.core.wmem_max = 8388608 net.core.rmem_max = 8388608 net.core.wmem_default = 131072 net.core.rmem_default = 131072 net.core.dev_weight = 64 net.core.netdev_max_backlog …

1
レイヤー2またはレイヤー3パケットのどこに機密情報を埋め込むことができますか?
Citrix Netscalerには、ホストに送信されるTCPパケットに情報を埋め込むという興味深い特性があります。このプロパティはNetscalerにエコーバックされ、Netscalerがこれを使用して、仮想サーバー、ホスト、およびルートがこれを使用する必要があるかどうかを判断できます。 専有情報をホストにエコーする機能には、興味深いアプリケーションがあります。 Citrix Netscalerはこれをどのようにして達成し(ビットをどこに詰め込むのか)、Netscaler(または同様のデバイス)は理論的にはデータの他のどの場所にデータを詰め込むことができますか? このカスタムデータをそのまま通過させる(または許可しない)デバイスはどれですか?

2
高帯域幅接続用に(非常に)大きなinitcwndを設定することの欠点は何ですか?
Linux(3.5カーネル)でTCPパラメータを実験しています。基本的にこの接続に関して: サーバー:データセンター内のギガビットアップリンク。別のデータセンターからテストした場合、実際の帯域幅(アップリンクの共有による)は約70 MB /秒です。 クライアント:200メガビットファイバーに接続されたギガビットローカルLAN。テストファイルを取得すると、実際には20 MB /秒に達します。 待ち時間:約50ミリ秒の往復。 リモートサーバーは、10〜100 MBの範囲のファイルのファイルサーバーとして使用されます。10のinitcwndを使用すると、これらのファイルの転送時間はTCPスロースタートの影響を大きく受け、10秒の読み込みに3.5秒かかります(最高速度:3.3 MB /秒に達します)。最高速度に達する前に終了します。私の目標は、これらのファイルの最小読み込み時間を調整することです(したがって、生のスループットが最高でも往復遅延が最低でもないので、ファイルを読み込むのにかかる実際の時間を短縮する場合は、両方を犠牲にしてもかまいません)。 そのため、他の接続や他への影響の可能性を無視して、理想的なinitcwndがどうあるべきかを決定するために簡単な計算を試みました。帯域幅遅延積は、200メガビット/秒* 50ミリ秒= 10メガビットまたは1.310.720バイトです。initcwndがMSSの単位で設定されていることを考慮し、MSSが約1400バイトであると仮定すると、1.310.720 / 1400 = 936の設定が必要になります。 この値はデフォルト(Linuxでは10 * MSS、Windowsでは64kb)とは非常に異なるため、このように設定することはお勧めできません。このように構成することの予想される欠点は何ですか?例えば: 同じネットワークの他のユーザーに影響しますか? 他の接続で許容できない輻輳が発生する可能性はありますか? パス上のどこかにルーターバッファーをフラッドしますか? 少量のパケット損失の影響を増やしますか?

2
Mac OS XのTIME_WAITはどこにありますか?
TIME_WAITMac OS Xではなし 通常、TCP接続が閉じられると、close()最初に呼び出された側のソケットはそのTIME_WAIT状態のままになります。 ピアの1つがMac OS X(Lion)マシンである場合、最初にMac側で呼び出されると、MacにTIME_WAITは何も表示さnetstat -anれませんclose()。ただし、実際にソケットはTIME_WAIT状態にあるようです。これは、listen()(ソケットオプションを使用せずに)再度呼び出しSO_REUSEADDRを行うlisten()と失敗するためです。 2 * MSL(によって報告されるMac OS X Lionでの最大セグメント寿命は15秒)を待つと状態がsysctl net.inet.tcp.mslクリアされTIME_WAIT、listen()エラーなしで再度呼び出すことができます。 なぜソケットが見えないのTIME_WAITですか? テスト中 Pythonの2つの簡単なテストプログラムを次に示します。 サーバ #!/usr/bin/env python import socket HOST = '' PORT = 50007 l = socket.socket(socket.AF_INET, socket.SOCK_STREAM) l.bind((HOST, PORT)) l.listen(1) print("Listening on %d" % PORT) (s, _) = l.accept() print("Connected") raw_input("Press <enter> to close...") …

2
フォワーダーDNS要求をTCPモードに強制する
マルチホームサーバーのSLES10(現在は9.6をバインド)にDNSサーバーを設定しました。このサーバーは、すべての内部ネットワークからクエリを実行でき、すべての内部ネットワークに応答を提供します。2つの別個のDNS「マスター」ゾーンがあります。これらの各ゾーンは、いくつかの信頼できるWindows-DNSサーバーによってサービスされています。 現在、私のlinux-serverは、これらのゾーンの1つ(プライベート内部ゾーン)のセカンダリDNSサーバーであり、他のゾーン(パブリック内部ゾーン)のフォワーダーとして機能しています。 最近まで、このセットアップは問題なく機能していました。今私は-パブリック内部ゾーンをクエリすると(例えばhost、Linuxクライアントのコマンドによって)エラーメッセージが表示されます ;; 切り捨て、TCPモードで再試行 Wiresharkダンプが原因を明らかにしました:最初のクエリはUDPモードで送信され、回答はUDPに適合しません(信頼できるNSのリストが長いため)、TCPモードで再試行され、正しい回答が提供されます。 ここで質問: 最初にUDPを試行せずにTCPモードでフォワーダーをクエリするようにバインドを構成できますか? 更新:ASCIIアートを試してみる... +--------------+ +--------------+ +-----------------+ | W2K8R2 DNS | | SLES 10 DNS | | W2K8R2 DNS | | Zone private +---+ All internal +---+ Zone public | | internal 2x | | Zones | | internal 30+ x | +--------------+ +-+----------+-+ +-----------------+ …

3
TCPホストからのトラフィックを簡単に「編集」する方法(Linux)
接続を処理するプロセスがストリームを取得する前に、既知のtcp host:portからの着信トラフィックに小さな変更を加える必要があります。 たとえば、192.168.1.88をWebサーバーを実行するリモートホストとします。 ローカルホストのプロセスが192.168.1.88:80(例:ブラウザー)からデータを受信すると、データはまず次のようにに置き換えtext-Aられて変更されtext-Bます。 127.0.0.1:...は192.168.1.88:80に接続します 127.0.0.1:...は192.168.1.88:80に送信します。 GET / 192.168.1.88:80は127.0.0.1に送信します:...: HTTP/1.0 200 OK Content-Type: text/plain Some text-A, some other text そのデータはシステムによっていくらか傍受され、出力が次のようなプログラムに渡されます。 HTTP/1.0 200 OK Content-Type: text/plain Some text-B, some other text システムは、変更されたデータを、192.168.1.88:80からのように、127.0.0.1:...を処理するプロセスに渡します。 ストリームベースの方法でこの変更を行う(sedたとえば、使用する)と仮定すると、着信tcpストリームを前処理する最も簡単な方法は何ですか? これにはが含まれると思いますが、iptables私はあまり得意ではありません。 アプリケーションは元のホストを処理するように感じる必要があるため、プロキシの設定はおそらく解決策ではないことに注意してください。

4
自動的に再接続するTCPトンネル
2台のマシン間に信頼性の低いネットワーク接続があります。制御できない理由でアクティブなTCP接続が切断されることがあります。2台のマシン間に信頼できるTCP接続を確立したい。 ネットワークが信頼できる場合はssh -L 1234:localhost:1234 remotehost、サーバーをポート1234でリッスンしてを実行し、remotehostクライアントをに向けlocalhost:1234ます。しかし、ssh接続が停止すると、転送された接続も停止します。クライアントとサーバー間の接続を自動的に復元するようにするにはどうすればよいですか? 非解決策: これはインタラクティブアプリケーション用ではないため、画面は適用されません。 これは、SSHトンネルを自動的に再接続することだけではありません。 la autossh。新しいトンネル接続を開始するのではなく、同じトンネルTCP接続を引き続き使用したい。 原則として、VPNが有効です。しかし、TCP接続が1つだけ必要な場合はやり過ぎに思われます。どちらの側にもroot権限がない場合でも機能する解決策が欲しいです。 私はrocksそれをやったというプログラムの薄暗い記憶を持っていますが、それはウェブの顔から落ちたようです。私は主に両側のLinuxに関心があります(ただし、このレベルのプログラムは他のuniceに移植できることを期待しています)が、QNXとVMSの間で動作するプログラムを知っている場合は、さらに良いでしょう。
9 ssh  unix  tcp  tunneling 


2
NICの多くのドロップされたパケット
CentOS 5.3で実行されているサーバーがあります(コメットチャットサーバー、多数のTCP接続があります)。最近、それが非常に遅い(httpサービスおよびssh)ことがわかったので、「ifconfig」コマンドを使用して何が起こったかを理解しました。 eth0 Link encap:Ethernet HWaddr 00:1C:C0:B5:D5:EA inet addr:10.0.0.61 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::21c:c0ff:feb5:d5ea/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:871861 errors:0 dropped:489662344145 overruns:0 frame:0 TX packets:639044 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:207239658 (197.6 MiB) TX bytes:169416201 (161.5 MiB) Interrupt:225 Base address:0x6000 lo Link encap:Local Loopback …
9 linux  networking  centos  tcp  nic 

4
新しいTCP接続を作成するのが高価であると見なされるのはなぜですか?
新しいTCP接続の作成が高価なタスクと見なされる理由がわかりません。基本的に、新しい接続のセットアップとは、TCPの3ウェイハンドシェイクを実行することを指します。つまり、2つのパケットを送信し、1つを受信して​​います。数千の(データ)パケットが続くことを考えると、ハンドシェイクは高価な部分にはなり得ません。それをできる?
9 networking  tcp 

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