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

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


7
TIME_WAITでソケットを強制的に閉じる方法は?
Linuxで特定のプログラムを実行すると、時々クラッシュします。その後すぐに開くと、最初に行ったように49200ではなくソケット49201でリッスンします。netstatは、49200がTIME_WAIT状態にあることを示しています。 ソケットをTIME_WAIT状態からすぐに強制的に移行するために実行できるプログラムはありますか?
113 linux  networking  unix  tcp  socket 

6
TCPパケット損失をどのように受動的に監視しますか?(Linux)
マシンとの間のTCP接続でのパケット損失を受動的に監視するにはどうすればよいですか? 基本的に、バックグラウンドにあり、TCP ack / nak / re-transmitsを監視して、どのピアIPアドレスが「大きな損失」を経験しているように見えるかのレポートを生成するツールが欲しいです。 私がSFで見つけたこのような質問のほとんどは、iperfなどのツールを使用することをお勧めします。しかし、マシン上の実際のアプリケーションとの接続を監視する必要があります。 このデータはLinux TCPスタックにそのまま存在しますか?

8
pingの試行で「TTLが期限切れになりました」とはどういう意味ですか?
別のネットワークセグメントにあるサーバーにpingを実行しようとすると、「TTLは期限切れです」というメッセージが表示されます。tracertを実行すると、4つのIPアドレスが無期限に繰り返されます。 14 60 ms 59 ms 60 ms xxx.xxx.xxx.2 15 83 ms 81 ms 82 ms xxx.xxx.xxx.128 16 75 ms 80 ms 81 ms xxx.xxx.xxx.249 17 81 ms 78 ms 80 ms xxx.xxx.xxx.250 18 82 ms 80 ms 77 ms xxx.xxx.xxx.2 19 102 ms 101 ms 100 ms xxx.xxx.xxx.128 20 …
55 networking  tcp  ping  ttl 

10
Windows TCP Window Scalingプラトーが早すぎる
シナリオ:多数のWindowsクライアントが、大規模なファイル(FTP / SVN / HTTP PUT / SCP)を約100〜160ms離れたLinuxサーバーに定期的にアップロードしています。オフィスには1Gbit / sの同期帯域幅があり、サーバーはAWSインスタンスであるか、米国DCで物理的にホストされています。 最初のレポートは、新しいサーバーインスタンスへのアップロードが、可能な限りはるかに遅いというものでした。これは、テストと複数の場所で発生しました。クライアントは、Windowsシステムからホストへの安定した2-5Mbit / sを確認していました。 私はiperf -s、AWSインスタンスで、次にオフィスのWindowsクライアントから始めました。 iperf -c 1.2.3.4 [ 5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185 [ 5] 0.0-10.0 sec 6.55 MBytes 5.48 Mbits/sec iperf -w1M -c 1.2.3.4 [ 4] local 10.169.40.14 port 5001 connected with 1.2.3.4 …


9
サーバーがSYNパケットに応答してSYN / ACKパケットを送信しないのはなぜですか
最近、当社のWebサイトを閲覧するMacおよびLinuxユーザーに限定されているTCP接続の問題に気づきました。 ユーザーの観点からは、Webサイトへの非常に長い接続時間(> 11秒)として表示されます。 私たちはこの問題の技術的な特徴を追跡することができましたが、なぜそれが起こっているのか、どうやってそれを修正するのかがわかりません。 基本的に、クライアントのマシンはSYN接続を送信してTCP接続を確立し、Webサーバーはそれを受信しますが、SYN / ACKパケットで応答しません。クライアントが多くのSYNパケットを送信した後、サーバーは最終的にSYN / ACKパケットで応答し、接続の残りの部分はすべて問題ありません。 そして、もちろん、問題のキッカー:それは断続的であり、常に発生するわけではありません(ただし、10〜30%の時間で発生します) OSとしてFedora 12 Linuxを使用し、WebサーバーとしてNginxを使用しています。 Wireshark分析のスクリーンショット 更新: クライアントでウィンドウスケーリングをオフにすると、問題が発生しなくなりました。今、私はちょうどサーバー側の解像度が必要です(すべてのクライアントがこれを行うことはできません) 最終更新: 解決策は、公開されているサーバーでTCPウィンドウのスケーリング と TCPタイムスタンプの両方をオフにすることでした。
46 linux  tcp  web-server 

11
UDPとTCPの違いは何ですか?
ルーターには、ポート転送を設定するときに選択できる2つのプロトコル(および「両方」のオプション)があります:UDPとTCP。これら2つのプロトコルの違いは何ですか?また、ポートフォワーディングでいつ他のプロトコルを選択しますか?
46 networking  router  tcpip  tcp  udp 

5
TCPパケットとUDPパケットを分割できますか?
TCPパケットは分割して受信者に届きますか? たとえば、TCPプロトコルを使用して20バイトを送信する場合、10バイトではなく、10バイトではなく、正確に20バイトを一度に受信することを100%確信できますか? UDPプロトコルについても同じ質問です。 UDPは信頼性が低く、パケットがまったく到着しない、または異なる順序で到着することはありませんが、単一のパケットはどうですか?到着した場合、それが断片ではなく完全なパケットであることを確認できますか?
41 networking  tcp  udp 


4
コマンドラインからcURLにキープアライブを使用させるにはどうすればよいですか?
実行しているTomcat Webサーバーとの通信中にHTTP持続接続が使用されていることを確認しようとしています。現在、ブラウザ(Chromeなど)からサーバー上のリソースを取得し、netstatを使用して接続が確立されていることを確認できます。 # visit http://server:8080/path/to/resource in Chrome [server:/tmp]$ netstat -a ... tcp 0 0 server.mydomain:webcache client.mydomain:55502 ESTABLISHED ただし、curlを使用すると、netstatでサーバー上の接続が表示されません。 [client:/tmp]$ curl --keepalive-time 60 --keepalive http://server:8080/path/to/resource ... [server:/tmp]$ netstat -a # no connection exists for client.mydomain また、次のcurlコマンドを使用してみました。 curl -H "Keep-Alive: 60" -H "Connection: keep-alive" http://server:8080/path/to/resource クライアントマシンのcurlバージョンは次のとおりです。 [server:/tmp]$ curl -V curl 7.19.5 (x86_64-unknown-linux-gnu) …
36 http  tcp  curl  netstat  keepalive 

1
特定のWebサイトでランダムなTCP RSTが発生していますが、どうなっていますか?
短いバージョン:特定のWebサイトに接続すると、ネットワーク上の1台のWindows Server 2012マシンが持続的だが断続的なTCP RSTを取得します。ダンノはどこから来たのか。私の分析と質問については、wiresharkログをご覧ください。 ロングバージョン: サーバーの1つでキャッシングWebプロキシを実行して、小規模オフィスにサービスを提供します。同僚から、特定のサイトへの接続時に「接続のリセット」または「ページを表示できません」というエラーが大量に発生することが報告されましたが、通常は更新すると修正されます。 ブラウザーの動作を確認し、サーバー自体でプロキシ化されていないブラウザーを試して、さらに直接確認しました。しかし、厄介なサイトへのpingとtracerouteで問題が発生することはありません。問題はtcp接続に限定されているようです。 次に、cURLを介してHTTP HEADリクエストを直接送信し、成功する頻度を確認することにより、影響を受けるサイトをテストするスクリプトを作成しました。典型的なテストは次のようになります:(これはプロキシされておらず、不良サーバーで直接実行されています) C:\sdk\Apache24\htdocs>php rhTest.php Sending HTTP HEAD requests to "http://www.washingtonpost.com/": 20:21:42: Length: 0 Response Code: NULL (0%) 20:22:02: Length: 0 Response Code: NULL (0%) 20:22:22: Length: 0 Response Code: NULL (0%) 20:22:42: Length: 0 Response Code: NULL (0%) 20:23:02: Length: 3173 Response Code: …

4
DNSクエリは常にUDPを経由しますか?
私はこのトピックの調査に少し時間を費やしましたが、正確な答えを見つけることができないようですので、重複していないと確信しています。私の質問はセキュリティのニーズに基づいていますが、まだ安全だと思いますここで質問しますが、セキュリティコミュニティに移動する必要があるかどうかを教えてください。 基本的に、DNSクエリはTCPを使用しますか(使用している場合、どのようなシナリオが発生する可能性がありますか)?繰り返しますが、私は単にクエリについて話しているだけです。TCPを介して旅行することは可能ですか?ドメインの最大長が253バイトで、UDPパケットのサイズが512バイトの場合、クエリは常にUDPとして送信されませんか?解決可能なクエリは、TCPの使用を必要とするほど大きくなるとは思わなかった。DNSサーバーが253バイトを超えるドメインのリクエストを受け取った場合、サーバーはそれをドロップするか、解決しようとしませんか?ここでいくつかの誤った仮定をしたことは確かです。 いくつかのコンテキストでは、セキュリティグループと協力してDNSクエリをセキュリティ監視ツールに組み込み、さまざまな理由で、DNSサーバーおよびドメインコントローラーでの標準パケットキャプチャを介してこのトラフィックをキャプチャすることを決定しました。コア要件は、すべてのDNSクエリをキャプチャして、特定のドメインを解決しようとしたクライアントを特定できるようにすることです。この要件に基づいて、DNS応答やゾーン転送などの他のトラフィックをキャプチャする必要はありません。これは、ログボリュームを可能な限り制限する必要があるという事実によっても引き起こされます。そのため、DNSサーバー宛てでUDP経由で送信されるDNSクエリのみをキャプチャすることを計画しています。より多くのコンテキスト(ここに忍び寄る質問の種類)については、セキュリティを拡張する必要があるかもしれないということが明らかになりました。可視性により、DNSを介して実行される隠れチャネルなどのアクティビティを監視できます(DNS応答、さらにはTCPトラフィックもキャプチャする必要があります)。しかし、そのようなシナリオでさえ、アウトバウンドDNSトラフィックはルックアップ/クエリの形式であり、悪意のあるソースからのものであっても、これらは常にUDP経由であると考えました(最初の段落の私の理由のため)。そのため、次の追加の質問が表示されます。 少なくとも、私が説明したアプローチで会話の半分をキャプチャすることになるでしょうか?または、クライアントはクエリの形式ではないDNSトラフィックを送信するでしょうか?(DNSサーバーの応答に対する何らかの応答のようであり、TCPを介して送信される可能性があります) TCPを使用するようにDNSクエリを変更できますか?DNSサーバーは、TCP経由のDNSクエリを受け入れて応答しますか? 関連性があるかどうかはわかりませんが、DNSリクエストを許可されたDNSサーバーに制限し、ポート53経由のその他すべてのトラフィックをブロックします。私は間違いなく新人なので、質問が準拠していない場合は申し訳ありません。変更方法。

3
SYN_RECV接続の数が少ないにもかかわらず、ログに「可能なSYNフラッディング」
最近、SYNフラッディングのために非常に遅い応答をするApacheサーバーがありました。これの回避策は、tcp_syncookies(net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf)を有効にすることでした。 あなたがより多くの背景が必要な場合、私はこれに関する質問をここに投稿しました。 syncookiesを有効にした後、約60秒ごとに/ var / log / messagesに次のメッセージが表示されるようになりました。 [84440.731929] possible SYN flooding on port 80. Sending cookies. Vinko Vrsalovicは、これがsynバックログがいっぱいになっていることを通知してくれたので、tcp_max_syn_backlogを4096に上げましたsysctl -w net.ipv4.tcp_synack_retries=3。これを行った後、頻度は低下しているようで、メッセージの間隔は約60〜180秒の間で変化しました。 次に、を発行しましたがsysctl -w net.ipv4.tcp_max_syn_backlog=65536、まだログにメッセージが記録されています。 このすべてを通して、(実行watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'することによって)SYN_RECV状態の接続の数を監視してきましたが、それが約240を超えることはなく、バックログのサイズよりはるかに低くなりません。それでも、約512個のRed Hatサーバーがあります(このサーバーの制限はデフォルトの1024です)。 バックログのサイズを制限する他のtcp設定はありますか、または間違ったツリーを起動していますか?SYN_RECV接続の数はnetstat -tuna、バックログのサイズに相関する必要がありますか? 更新 ここで合法的な接続を処理していると言えば、netstat -tuna|wc -l5000前後です。今日これを調査していて、last.fmの従業員からのこの投稿を見つけました。 また、syncookiesが有効になっている場合、tcp_max_syn_backlogは効果がないことも発見しました(このリンクのとおり) そのため、次のステップとして、sysctl.confで以下を設定します。 net.ipv4.tcp_syn_retries = 3 # default=5 net.ipv4.tcp_synack_retries = 3 …
30 linux  tcp  kernel  flooding 

3
iSCSIストレージの調整
これは、参考として使用できるiSCSI に関する標準的な質問です。 iSCSIは、SCSIコマンドをペイロードとしてTCPネットワークパケットに入れるプロトコルです。そのため、ファイバチャネルなどとは異なる一連の問題が発生します。たとえば、リンクが混雑し、スイッチのバッファがいっぱいになった場合、デフォルトでは、イーサネットはホストに減速を指示する代わりにフレームをドロップします。これにより、再送信が発生し、ストレージトラフィックのごく一部の待ち時間が長くなります。 クライアントのオペレーティングシステムに応じて、ネットワーク設定の変更など、この問題の解決策があります。次のOSのリストでは、最適なiSCSIクライアント構成はどのように見えますか?スイッチの設定を変更する必要がありますか?ストレージはどうですか? VMWare 4および5 Windows Hyper-V 2008および2008r2 ベアメタル上のWindows 2003および2008 ベアメタル上のLinux AIX VIO あなたが偶然関連すると思う他のOS

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