プログラマーが信じているTCPに関する誤った情報

 (lwn.net)
3 ポイント 投稿者 GN⁺ 2024-09-16 | 1件のコメント | WhatsAppで共有

NetworkManager または networkd

  • NetworkManager または networkd

    • ユーザーは wpa_supplicant ベースの管理へ移行した理由を説明している
    • TCP に関する誤った思い込みの一覧を提示している
    • TCP の信頼性に関する誤解を扱っている

  • TCP に関する誤った思い込みの一覧

    • TCP は常に信頼できる
    • TCP はたいてい信頼できる
    • TCP は信頼できないが、送信者と受信者は最終的に送信されたバイトについて合意する
    • TCP の上にメッセージ指向プロトコルを構築すれば信頼性を保証できる
    • TCP パケットというものは存在する
    • TCP パケットというものは存在しない
    • リモートホストへの接続に失敗したら、相手はオフラインである
    • Nagle アルゴリズムは良い
    • Nagle アルゴリズムは悪い
    • Nagle アルゴリズムを気にする必要はない
    • TCP はネットワークを透過的に扱う
    • ネットワークが TCP に対して透過的なら、IP に対しても透過的である
    • ネットワークが HTTP/1.1 に対して透過的なら、TCP に対しても透過的である
    • 標準プロトコルに対して透過的でないネットワークは例外的である
    • TCP は IP を基盤として実装されている

  • 説明

    • ACK を待っている間に接続が切れると、送信者はセグメントが受信されたかどうか分からない
    • Paxos や Raft のようなアルゴリズムが必要であり、最低 3 ノードが必要になる
    • SMTP のようなプロトコルでもこの問題は発生する

  • 追加の意見

    • 2 者は不確実なリンクを通じて合意に到達できる
    • 送信されたバイトの部分集合について合意できる
    • 合意されたバイト集合が 0 である場合もあり、そこから増えていく可能性がある
    • Paxos は不要である

  • 追加の議論

    • 合意されたバイト集合の正確な範囲は分からない
    • ネットワーク透過性に関する誤った思い込みが問題を引き起こす
    • ICMP を遮断したり、理解できないパケットをドロップしたりするネットワークがある
    • 輻輳制御に関する知識が必要である

GN⁺の要約

  • この記事は TCP の信頼性に関する誤った思い込みを扱っており、ネットワーク管理ツールの選択に関する議論も含んでいる
  • TCP の信頼性の問題は、Paxos のような複雑なアルゴリズムが必要になることを説明している
  • ネットワーク透過性に関する誤った思い込みが、実際の問題を引き起こしうることを強調している
  • ネットワーク管理ツールを選ぶ際に考慮すべきさまざまな要素を提示している

関連記事

1件のコメント

 
GN⁺ 2024-09-16
Hacker Newsの意見

  • 「falsehoods programmers believe」形式が明確でなく、混乱する

    • TCPパケットの存在有無をめぐる議論が理解できない
    • 哲学的な混乱を招く内容だ

  • Ethernetケーブルを抜いて再接続しても接続が維持されることに驚く

    • TCPは爆弾が落ちても動作するように設計されている

  • 「at most once」または「at least once」の配信保証は可能だが、「exactly once」の配信保証は不可能だ

    • 多くのジュニア開発者は「exactly once」の配信保証がないとバグだと思っている

  • ACKが未解決の状態で接続が切れると、送信者はセグメントが受信されたかどうかわからない

    • TCPは双方向パイプを提供するのであり、厳密な配信保証はアプリケーションの責任だ
    • HTTPリクエストがレスポンスを受け取る前に中断された場合、送信者はリクエストがサーバーに到達しなかったと仮定し、新しい接続で再試行しなければならない

  • 誤り訂正符号について聞いたことがないのか疑問だ

    • TCPまたはEthernetフレームにはFECバイトが含まれている
    • HTTP over TLSは暗号化されたデータフレームを使用しており、データ損失が発生すると受信できない
    • 現代のインターネットの多くはこのパラダイムに基づいている

  • データセンター内部で独自ハードウェアを使う場合は、低レベルの詳細を無視できる

    • 帯域幅制限、パケットRPS制限、レイテンシは依然として重要だ

  • この記事は完成した文章ではなく、HNの投稿タイトルが誤解を招く可能性がある

  • VKontakteで働いていたときに解決しようとしていた問題を思い出す

    • 地下鉄でメッセージを送るとサーバーには到達するが、レスポンスが届く前に電波が切れる
    • クライアントはメッセージ送信失敗と認識して再試行する
    • クライアント生成の「ランダムID」を使って問題を解決した
    • Telegramは、クライアントがサーバーに再接続したとき、前回の接続中に確認されなかったすべてのレスポンスを送信する

  • 多くの人はTCPが関数呼び出しではないことを理解していない

    • 最近、新しいTCPレートリミッターが非常にひどい状態でリリースされた
    • ほとんどのコンテナがBufferbloat問題を抱えているはずだ