Những hiểu lầm sai về TCP mà lập trình viên tin là đúng

 (lwn.net)
3 điểm bởi GN⁺ 2024-09-16 | 1 bình luận | Chia sẻ qua WhatsApp

NetworkManager hoặc networkd

  • NetworkManager hoặc networkd

    • Người dùng giải thích lý do chuyển sang quản lý dựa trên wpa_supplicant
    • Đưa ra danh sách những niềm tin sai về TCP
    • Bàn về các hiểu lầm liên quan đến độ tin cậy của TCP

  • Danh sách những hiểu lầm về TCP

    • TCP luôn đáng tin cậy
    • TCP hầu hết là đáng tin cậy
    • TCP không đáng tin cậy, nhưng bên gửi và bên nhận cuối cùng sẽ thống nhất về các byte đã được truyền
    • Xây dựng giao thức hướng thông điệp trên TCP có thể đảm bảo độ tin cậy
    • Có tồn tại cái gọi là gói TCP
    • Không tồn tại cái gọi là gói TCP
    • Nếu kết nối tới máy chủ từ xa thất bại thì nó đang offline
    • Thuật toán Nagle là tốt
    • Thuật toán Nagle là tệ
    • Không cần quan tâm đến thuật toán Nagle
    • TCP xử lý mạng một cách trong suốt
    • Nếu mạng trong suốt với TCP thì cũng trong suốt với IP
    • Nếu mạng trong suốt với HTTP/1.1 thì cũng trong suốt với TCP
    • Mạng không trong suốt với các giao thức tiêu chuẩn là trường hợp ngoại lệ
    • TCP được triển khai dựa trên IP

  • Giải thích

    • Nếu kết nối bị ngắt trong khi ACK đang chờ, bên gửi sẽ không thể biết phân đoạn đã được nhận hay chưa
    • Cần các thuật toán như Paxos hoặc Raft, và cần tối thiểu ba nút
    • Vấn đề này cũng xảy ra với các giao thức như SMTP

  • Ý kiến bổ sung

    • Hai bên có thể đạt được đồng thuận qua một liên kết không chắc chắn
    • Có thể đồng thuận về một tập con các byte đã được truyền
    • Tập byte đã được đồng thuận có thể là 0, và có thể tăng dần
    • Không cần Paxos

  • Thảo luận thêm

    • Không thể biết chính xác phạm vi của tập byte đã được đồng thuận
    • Những hiểu lầm về tính trong suốt của mạng gây ra vấn đề
    • Có những mạng chặn ICMP hoặc loại bỏ các gói mà chúng không hiểu
    • Cần có kiến thức về kiểm soát tắc nghẽn

Tóm tắt của GN⁺

  • Bài viết này bàn về những hiểu lầm liên quan đến độ tin cậy của TCP, đồng thời bao gồm thảo luận về việc lựa chọn công cụ quản lý mạng
  • Giải thích rằng các vấn đề về độ tin cậy của TCP đòi hỏi những thuật toán phức tạp như Paxos
  • Nhấn mạnh rằng những hiểu lầm về tính trong suốt của mạng có thể gây ra các vấn đề thực tế
  • Đưa ra nhiều yếu tố cần cân nhắc khi lựa chọn công cụ quản lý mạng

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-09-16
Ý kiến trên Hacker News

  • Cách dùng kiểu "những điều sai lầm mà lập trình viên tin là đúng" không đủ rõ ràng nên gây khó hiểu

    • Không hiểu cuộc tranh luận về việc TCP packet có thực sự tồn tại hay không
    • Đây là nội dung dễ gây rối loạn về mặt triết học

  • Ngạc nhiên khi rút cáp Ethernet rồi cắm lại mà kết nối vẫn được duy trì

    • TCP được thiết kế để vẫn hoạt động ngay cả khi bom rơi

  • Có thể bảo đảm truyền tải kiểu "at most once" hoặc "at least once", nhưng không thể bảo đảm kiểu "exactly once"

    • Nhiều lập trình viên junior nghĩ rằng nếu không có bảo đảm "exactly once" thì đó là lỗi

  • Nếu kết nối bị ngắt khi ACK vẫn đang outstanding, bên gửi sẽ không thể biết segment đã được nhận hay chưa

    • TCP cung cấp một đường ống hai chiều, còn bảo đảm truyền chính xác là trách nhiệm của ứng dụng
    • Nếu một HTTP request bị gián đoạn trước khi nhận được response, bên gửi phải giả định rằng request chưa đến được server và thử lại bằng một kết nối mới

  • Tự hỏi liệu tác giả có từng nghe về mã sửa lỗi hay chưa

    • TCP hoặc Ethernet frame có chứa các byte FEC
    • HTTP over TLS dùng các khung dữ liệu đã mã hóa, nên nếu xảy ra mất dữ liệu thì sẽ không thể nhận được
    • Phần lớn Internet hiện đại được xây dựng trên mô hình này

  • Khi dùng phần cứng riêng trong nội bộ datacenter, có thể bỏ qua các chi tiết ở mức thấp

    • Nhưng giới hạn băng thông, giới hạn packet RPS và độ trễ vẫn rất quan trọng

  • Bài viết này chưa phải là một bài hoàn chỉnh, và tiêu đề khi gửi lên HN có thể gây hiểu nhầm

  • Gợi nhớ đến vấn đề từng cố giải quyết khi làm việc ở VKontakte

    • Khi gửi tin nhắn trong tàu điện ngầm, dữ liệu đến được server nhưng tín hiệu bị mất trước khi response quay lại
    • Client hiểu đó là gửi tin nhắn thất bại và thử lại
    • Đã giải quyết bằng cách dùng "random ID" do client tạo ra
    • Telegram sẽ gửi lại mọi response chưa được xác nhận trong kết nối trước đó khi client kết nối lại với server

  • Nhiều người không hiểu rằng TCP không phải là một lời gọi hàm

    • Gần đây đã có một bộ giới hạn tốc độ TCP mới được phát hành trong tình trạng cực kỳ sai lệch
    • Hầu hết container có lẽ đang gặp vấn đề Bufferbloat