タグ付けされた質問 「transport-protocol」

トランスポートプロトコルまたはOSIレイヤー4に関する、またはこれに関する質問について。たとえば、TCP / IPの最もよく知られているトランスポートプロトコルは、伝送制御プロトコル（TCP）です。

4
TCP / IPで通信遅延を定式化するにはどうすればよいですか？
TCP / IPを使用して通信する2つのノード間のラウンドトリップレイテンシを推定するための数学モデル/方程式を導出するのは困難です。ノードは、HTTPプロトコルに基づいてデータを交換しています。このモデルでは、調査する最も重要な要因は、ネットワーク内の2つのノード間の物理距離、中間ホップの数、帯域幅、各ホップでの処理遅延です。Webを検索しましたが、この意味では何も見つかりませんでした。むしろ、回線交換ネットワークとUDPプロトコルについて何かを見つけました。TCPに合わせてカスタマイズできますか？
2
インターネット以外のグローバルネットワークはありますか？
私はこのグローバルネットワークの定義を見つけました。 現在、インターネット以外にグローバルネットワークはありますか？誰かがいくつかの例を引用できますか？または、グローバルではありませんが、国全体の規模（おそらくATMネットワーク）ですか？ 他のすべてのWANネットワークが「エンタープライズネットワーク」のカテゴリに分類されるわけではありませんか？ インターネット以外のグローバルネットワークはありますか？ また、この行が私の目を引いたとき、私はトランスポート層プロトコルについて読んでいました： ネットワークアプリケーションでは、複数のトランスポート層プロトコルを使用できる場合があります。たとえば、インターネットにはTCPとUDPの2つのプロトコルがあります。これらの各プロトコルは、アプリケーションを呼び出すためのトランスポート層サービスの異なるセットを提供します より具体的には、この行： For example, the internet has two protocols -TCP and UDP 非インターネットのトランスポート層プロトコルのいくつかの例は何ですか？ この本はTelephone network、WAN（インターネットを除く）として簡単に説明されています。しかし、それは実装されましたcircuit-switched network。それらがトランスポート層プロトコルさえ持っていたとは思えません。それで、提供する他のネットワークはありますTransport-Layer servicesか？
3
TCPによる確認は、データが配信されたことを保証するものではありません
RFC 793には、TCPセグメントの確認応答に関する部分があります。 TCPがデータを含むセグメントを送信すると、TCPはコピーを再送信キューに入れ、タイマーを開始します。そのデータの確認が受信されると、セグメントはキューから削除されます。タイマーが切れる前に確認応答が受信されない場合、セグメントは再送信されます。 TCPによる確認は、データがエンドユーザーに配信されたことを保証するものではなく、受信側のTCPが配信を担当したことを保証するだけです。 さて、これは面白いです。私たちのNOCでは、ネットワークと外部クライアントネットワーク間の接続の問題をトラブルシューティングすることがよくあります。ファイアウォールでトラフィックをスニッフィングし、両方向で送受信されるSYNおよびACKビットを確認するときはいつでも、接続が確立され、問題には何もないと仮定しますネットワークで行います。 しかし今、このRFCは私に考えさせました-TCP接続が確立されているのに、ユーザーがまだ接続の問題を経験している場合、他に何を確認する必要がありますか（Wiresharkをセットアップせずに）？
1
ATMはまだトランスポートプロトコルとして使用されていますか？
新しい資料を読むことに加えて、どこから来たのか、おそらくはどこに向かっているのかを見るために、古いネットワーキングブックを読むことを楽しんでいます。現在、私はCisco LANスイッチングと呼ばれる本を読んでいます。これは、CCIE Professional Developmentシリーズの一部として1999年に発行されました。この本は、ネットワークバックボーンでのATMの使用についてかなり触れており、今日のネットワークエンジニアリングでは、ATMについてほとんど何も見たことがないことに気付きました。 現在、ATMは使用されていますか、それとも他のテクノロジーにほとんど置き換えられていますか？
1
TCPサーバーは65535クライアントに制限されていますか？
これは、単一のコンピューター/アプリケーションが維持できるクライアントの数に厳しい制限を課すと考えるかもしれません。 1つはWebサーバーを監視していて、最大65,000接続を超えると予測される使用レベルにまで拡張できることを確認する必要があります。 ソフトウェアの場合、特定の考慮事項があります（/programming/1575453/how-many-socket-connections-can-a-web-server-handle）
2
TCPの最大セグメントサイズ（MSS）はIPv6と互換性がありますか？
IPv4では、TCP MSSの「クランプ」（TCPヘッダーのMSS値を編集するネットワークデバイス）が、パスの最大転送単位の検出が機能していない場合に役立ちます。（たとえば、ICMPがパスのどこかでブロックされている場合。）IPv6にはフラグメンテーションがないため、ICMPv6の「パケットが大きすぎて」元のエンドポイントに信号を送ることができません。 特にIPv6を介してTCP MSSをクランプすることについてのガイダンスはありますか？
4
プロトコルがTCPまたはUDPのどちらを使用しているかを知る方法
まあ、それは馬鹿げた質問に聞こえるかもしれませんし、私の経験が積み重なって、プロトコルについてどんどん学んでいくにつれて、最も適切な答えは私が言うことができるようになると思います。 しかし、私は学生であり、現場での経験はあまりありません。どのプロトコルでもグーグルできますが、経験則があるかどうか知りたいです。私はまだ「経験則」を求めるのは愚かだと思うが、それでも私はそれを探している。 Wikipediaでこのリストに遭遇しました。これには、プロトコルと、表形式でTCPとUDPのどちらを使用するかが記載されています。ただし、特定のプロトコルの行に単一のポート番号を持つTCPとUDPの両方が含まれている場合の意味を理解できません。たとえば、Telnet行の場合は23-TCP-UDPです。これは何を意味するのでしょうか？TelnetはTCPポート23とUDPポート23の両方で動作しますか？ また、教科書でTFTPがUDPを使用していると記載されていますが、上の表を見ると、TFTP行は69-TCP-UDPです。したがって、上の表で何が起こっているのかを推測してください。
2
ウィンドウサイズとACK番号
講師のスライドからコピーして貼り付ける： • 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を送信するのはなぜですか？
4
TCPソケットが4タプルで識別されるのはなぜですか？
ここでネットワーキングの初心者。私はコンピュータネットワーキング（第3版）の本を読んでおり、セクション3.2では、UDPとTCPの両方の多重化/逆多重化について説明しています。 UDPプロトコルでは、ソケットは送信元IPと送信元ポートによって一意に識別されます。 TCPプロトコルでは、ソケットは送信元IP、送信元ポート、宛先IP、および宛先ポートによって一意に識別されます。TCPプロトコルがセグメントを正しく逆多重化して正しいプロセスに送信するために、受信ホストが2つの追加情報を必要とするのはなぜですか？ これが必要な理由を私が考えることができる唯一の理由は、クライアントが常にTCPセグメントを接続要求セグメントと同じポートに送信する場合です。たとえば、サーバーが別のポートでそのセッション専用のTCPソケットを確立していても、ブラウザは常にデータをサーバーのポート80に送信します。その場合、TCPは送信元IPと送信元ポートの情報を使用して、正しいソケットに逆多重化する必要があります。単一のホストが複数のセッションを確立できるため、ソースIP情報だけに依存することはできませんが、各セッションは異なるポート上にある必要があります。 UDPにこの問題がない理由は、UDPには要求に対する複数の新しいソケットの「発生」がないため、宛先IP /ポートコンボが要求を処理するプロセスが接続されているソケットを識別するためです。 これは正しいですか、それとも間違った結論に達しましたか？
1
TCPウィンドウサイズをイーサネットパケットの最大サイズよりも大きくするにはどうすればよいですか？
TCPウィンドウサイズは64KB以上に拡大できることは知っていますが、次のようなイーサネットパケットデータグラムを見てください。 レイヤー2パケットのサイズはそれよりもはるかに小さいように制限されているようです。単一のTCP要求が複数のネットワーク要求をレシーバーでアセンブルする必要がある場合、ACKはTCPレイヤーでどのように機能しますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.