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

このトピックに対応： /programming/3613989/what-of-traffic-is-network-overhead-on-top-of-http-s-requests 最大セグメントサイズ（TCPまたはIPヘッダーを含まない）は、通常、レイヤー間でMTUのサイズからヘッダーサイズを引いた値にネゴシエートされます。イーサネットの場合、MTUは通常1500バイトに構成されます。TCPヘッダーは160ビット、つまり20バイトです。IPv4ヘッダーの固定部分は160ビット、つまり20バイトです。... したがって： HTTP over TCP / IPv4の場合 オーバーヘッド= TCP + IP = 40バイト ペイロード= 1500〜40 = 1460バイト オーバーヘッド％= 2％（40 * 100/1460） デフォルトのDebianディストリビューションを使用したTCPモードでの100 Mbitおよび1Gbit iperfの結果は次のとおりです。 [ 5] local 10.0.51.1 port 5001 connected with 10.0.51.20 port 45009 [ 5] 0.0-10.0 sec 112 MBytes 94.1 Mbits/sec [ 4] local 10.0.51.1 port …

9 tcp  bandwidth 

講師のスライドからコピーして貼り付ける： • Receiver indicates the window size is 3000 • Transfer goes ahead • Acknowledge every 3000 bytes • Receiver increases window size to 4000 • 4000 bytes will be transferred before the next acknowledgement したがって、これから、ウィンドウサイズは、ACKを送信する前にレシーバーが収集するバイト数を表すことを収集します。 しかし、これはこのWiresharkのキャプチャで見たものではありません。 （TCPファイル転送からの）スクリーンショットでわかるように、サーバーは約1400バイトごとにACKを送信しています（ACK番号を確認しています）が、同時にウィンドウサイズが100'000 +バイトであることを示していますか？ 私が講師のスライドから理解したことから、サーバーは100'000 +バイトごとにACKする必要がありますか？それよりもはるかに頻繁にACKを送信するのはなぜですか？

9 tcp  protocol-theory  layer4  transport-protocol 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ ネットワークエンジニアリングスタック交換のトピックになるように質問を更新します。 2年前休業。 状況は次のとおりです。 http client ----> corporate firewall ----> http server キープアライブにより、サーバーとクライアントはTCP接続を開いたままにし、クライアントはHTTPリクエストに接続プールを使用します。 ファイアウォールには、1時間後に長期のTCP接続を「強制終了」するルールがあります。問題は、HTTPクライアントがTCP接続が破壊されたことを検出せず、一定期間後にクライアントが「ハング」したように見えた、本質的に無効な接続を再利用しようとしたことです。おそらく新しい接続が確立されたため、要求がハングし、次の要求が機能しました。 ここでの問題は、 HTTPクライアントがTCP接続を検出できなかった方法でファイアウォールがTCP接続を強制終了するメカニズムは何ですか。私はいくつかの方法でこの動作をローカルで再現しようとしました： VyosルーターのTCP接続を強制終了し、クライアント側のWiresharkがTCP FIN-ACKをキャプチャしました。OK WindowsのTCPViewでTCP接続のクライアント側を強制終了し、Wiresharkがクライアント側でTCP RSTを検出しました。OK クライアント側ファイアウォールへの接続が確立された後にポートをブロックすると、ソケットリセット例外が発生しました。OK サーバー側にWiresharkダンプがあり、ファイアウォールがFINまたはRSTを送信しているかどうかを確認しようとしましたip.dst==serverip && (tcp.flags.reset==1 || tcp.flags.fin==1)が、何も表示されませんでした。 さらに、クライアント側のWiresharkキャプチャでは、HTTPリクエストが送信され、その後に数十のTCP再送信が続き、最終的にはどこにも送信されないという問題が示されています。 HTTPクライアントはJavaネイティブおよび/またはJetty HTTPクライアント（両方を試しました）であり、どちらも無効なTCP接続を検出できませんでした。動作をローカルで再現したいのですが、ファイアウォールが接続を強制終了しているので、どのような問題があるのか​​わからないので、考えられる答えを探しています。

8 tcp  firewall 

英国と米国の農場にいくつかの組み込みPCがあります。他の接続の中で、これらは20秒ごとに小さなデータパケット（100〜600バイト）を送信するサーバーと通信します。 DSLではこれで問題ありません。衛星接続では、ほとんどのパケットが失われます。 TCPを使用しており、クライアントのtcpdumpでシーケンスが表示されます。 -> syn (send) <- syn ack (receive) -> ack -> push ack <- ack (spoofed?) -> fin ack <- ack (spoofed?) <- fin ack -> ack ただし、サーバーには次のように表示されます。 <- syn (receive) -> syn ack (send) <- ack <- fin ack -> fin ack <- ack 接続を高速化するために、クライアントが受信する余分なackがサテライトエンドポイントによって偽装されていると私は思う 100を超えるDSLサイトと3つの衛星があります。DSLはすべて問題なく、衛星はすべて同じように壊れています。 データはどうなっていますか？20回に1回ぐらいです。 …

8 tcp  packet-loss 

ここでネットワーキングの初心者。私はコンピュータネットワーキング（第3版）の本を読んでおり、セクション3.2では、UDPとTCPの両方の多重化/逆多重化について説明しています。 UDPプロトコルでは、ソケットは送信元IPと送信元ポートによって一意に識別されます。 TCPプロトコルでは、ソケットは送信元IP、送信元ポート、宛先IP、および宛先ポートによって一意に識別されます。TCPプロトコルがセグメントを正しく逆多重化して正しいプロセスに送信するために、受信ホストが2つの追加情報を必要とするのはなぜですか？ これが必要な理由を私が考えることができる唯一の理由は、クライアントが常にTCPセグメントを接続要求セグメントと同じポートに送信する場合です。たとえば、サーバーが別のポートでそのセッション専用のTCPソケットを確立していても、ブラウザは常にデータをサーバーのポート80に送信します。その場合、TCPは送信元IPと送信元ポートの情報を使用して、正しいソケットに逆多重化する必要があります。単一のホストが複数のセッションを確立できるため、ソースIP情報だけに依存することはできませんが、各セッションは異なるポート上にある必要があります。 UDPにこの問題がない理由は、UDPには要求に対する複数の新しいソケットの「発生」がないため、宛先IP /ポートコンボが要求を処理するプロセスが接続されているソケットを識別するためです。 これは正しいですか、それとも間違った結論に達しましたか？

8 tcp  protocol-theory  udp  layer4  transport-protocol 

TCPウィンドウサイズは64KB以上に拡大できることは知っていますが、次のようなイーサネットパケットデータグラムを見てください。 レイヤー2パケットのサイズはそれよりもはるかに小さいように制限されているようです。単一のTCP要求が複数のネットワーク要求をレシーバーでアセンブルする必要がある場合、ACKはTCPレイヤーでどのように機能しますか？

8 ethernet  tcp  layer4  transport-protocol 

NATの背後にあるノードにアクセスできる必要があるP2Pアプリケーションを構築しています。このNATはインバウンド接続を許可しないため、ネットワーク外部のノードは、NATの背後にあるノードに到達できません。 この問題に対する私の解決策は、NATの背後にあるノードが外部のノードに到達し、外部のノードが時間の準備ができたら、事前に確立されたTCP接続を使用して、NATの内部にあるノードに接続することです。この接続はNAT内のノードによって確立されるため、NATによってブロックされることはありません。 これが私の質問です。下線が引かれた解釈のうちどれが正しいのか、または両方が間違っているのかはわかりません。 解釈＃1 そこで効果的にTCP接続、チューブの概念は、およびNATの内側のノードが外の世界に何かを要求する際に、そのチューブが開き、応答がそれに入れられ、そしてチューブは永遠に閉じます。 結果：そのチューブが閉じた後、NATは外部ノードからクライアントへのそれ以上のTCP接続を許可しません。 解釈＃2 TCP接続などはありませんが、TCP送信です。TCP接続はlocal ip:port、およびとして定義されているため、remote ip:portNATの背後のノードが外部のノードを呼び出した後、外部のノードは、クライアントが要求を行ったのと同じポートを使用してコールバックでき、同じTCPとして「カウント」されます。接続によるもので、NATによる一方的な呼び出しではありません。 結果： NATは、この接続が、NAT内のノードが履歴レコードを調べることによって要求したものに対する応答であったかどうかを効果的に推測します。NATの背後にあるノードが最初のコールアウトを行ったので、外部のノードは同じクライアントポートを使用してコールバックでき、機能します。 私のメンタルモデルは＃1に近かったのですが、Wiresharkで接続を調べたところ、それらは個別のTCP接続として、または少なくとも個別のエンティティとして表示されました。 ＃1、または＃2に近いですか、それとも混乱してしまいますか？

7 tcp  nat  layer4 

こんにちは！誰かがタイムアウトで何が起こるか説明してくれませんか？その後、ウィンドウサイズは完全に減少します。タイムアウト時には、3つの重複ACKと同じことが起こると思いました。cwndの半分で、加法的に増加します。これらの混雑の指標の扱い方に違いはありますか？

7 tcp  protocol-theory  layer4  transport-protocol  congestion 

Cisco ASAファイアウォールを通過する必要があるTCP接続を設定するためにトラフィックジェネレータを使用しています。 私のトポロジは次のようになります。 +------------------+ | CISCO ASA | +------------+ | | | Client +-------+Outside | | 10.1.202.1| |10.1.202.254 | | | | | +------------+ +------------+ | Inside| |Server | | 10.1.102.254+--------+10.1.102.19 | | | | | +------------------+ +------------+ 外部ネットワーク（10.1.202.1/24）の1つのホストから内部ネットワーク（10.1.102.19/24）のサーバーへの接続を確立する必要があります。 SYNがファイアウォール（10.1。（1/2）02.254）を通過し、SYN-ACKが通過せずにドロップされることがWiresharkでわかります（キャプチャを参照してください：内部インターフェイスと外部インターフェイス）。 からshow asp drop、次の理由でフレームがドロップされることが通知されます。 TCP failed 3 way handshake (tcp-3whs-failed) ARPは使用していませんが、デフォルトゲートウェイであるファイアウォールインターフェイスのMACアドレスを使用しています。 …

7 cisco-asa  firewall  tcp 

IPパケットヘッダーには、「次のレベルのプロトコル」を保持する8ビットのプロトコルフィールド（オフセット9）があり、割り当てられた番号はRFC 790で指定されています。たとえば、TCPは6です。私の質問は、なぜIPなのかです。レイヤーはネットワークスタックの上位レイヤーを認識していますか？

7 ipv4  tcp  layer3  layer4  rfc 

私はWiresharkで遊んでいて、2つのフィルターに気づきました：tcp.lenとtcp.data。2つの違いは何ですか？私の知る限り、tcp.len（長さ）フィールドは、セグメント内を移動するデータのバイト数を示しています。 前もって感謝します ：）

7 tcp  wireshark 

インターネットプロトコルスタックには実際には3つの層があることを知っています。アプリケーション、インターネット、トランスポートです。アプリケーション層のHTTPがトランスポート層のTCPに変換され、TCPがインターネット層のIPに変換されるとしましょう。 しかし、実際にはインターネットからネットワークトラフィックをキャプチャしようとしたとき、HTTPレイヤーしか理解できず、TCPとIPの内容を理解できません。 ネットワークトラフィックのキャプチャにWiresharkを使用しています。 プロセスを説明するか、このための簡単な例を提供してください。

7 ipv4  tcp  ipv6  internet 

私たちのF5ロードバランサーはバージョン10.2.4を実行します。Catalyst 6500のCiscoロードバランサーカードから移行し、15分後にセッションが停止することなく、xtermセッションをsolarisおよびlinuxサーバーに実行できるようになりました。 私たちの上司は、F5 tcpプロファイルで900秒の数値を上げることを恐れています。別の会社では彼がこれを行っていたため、F5のすべてのリソースがハングした接続から使い果たされたためです。 タイムアウトを変更せずにセッションがリセットされないようにする別の方法はありますか？これは私たちの設定です profile fastL4 fwd_fastL4_15m { defaults from fastL4 idle timeout 900 } virtual route_outbound { destination any:any mask none ip forward profile fwd_fastL4_15m }

7 ipv4  tcp  f5  load-balancer 

ホスト間の2つのリンクの助けを借りて、ルート障害検出のための時間遅延なしに、TCP接続のフォールトトレランスを実現するテクノロジーを探しています。このようなもの： link1 packet1copy1-> -------------------------- packet1-> / \ packet1copy1/packet1copy2-> host1--------router1 router2 ------------------------host2 \ link2 packet1copy2-> / -------------------------- host1とhost2を介して接続されているrouter1とrouter2、それらの間に2つのリンクで。各ルーターは、ホストからのすべてのパケットを複製してから、両方のリンクに同時に転送します。次に、ピアルーターまたは宛先ホストIPスタックのいずれかが、冗長パケットの除去を処理します。 編集： これは実際には、TCP（IP）トランスポート用のレプリケーションによる汎用のフォールトトレランスソリューションの検索です。ソリューションは、BGP / OSPF / Cisco IP SLAなどの適度に高速なリカバリアプローチとは対照的に、リカバリが不要なタイプである必要があります。一部の独自仕様のパケット冗長ソリューションは、あまり知られていませんが、すでに知られています。特に、Engage CommunicationはVoIP用のIP Tube Protectorを提供しています。残念ながら、このソリューションは、1）標準テクノロジーよりも多くの機器であり、2）VoIPドメインのみに限定されています。ジュニパーパケット冗長テクノロジーも注目に値するかもしれませんが、冗長リンクではなく単一リンクのみに限定されているように見えます。 なぜCiscoから同様のものが見つからないのでしょうか...標準または少なくとも汎用のテクノロジーはこれに対処しますか？

7 tcp  redundancy  failover  architecture  packet-loss