Những hiểu lầm của lập trình viên về TCP

• Giống như NetworkManager từng coi một chập chờn kết nối ngắn là “không có mạng”, một số phần mềm tin vào phán đoán trạng thái của chính mình hơn là khả năng phục hồi của TCP, nhưng điều này có thể nguy hiểm trên mạng thực tế
• Niềm tin rằng “dữ liệu đã gửi sẽ đến nơi”, “hai bên cuối cùng sẽ thống nhất được các byte đã được truyền”, hay “có thể bảo đảm điều đó bằng giao thức ứng dụng như HTTP hoặc SMTP” có thể bị phá vỡ trong một số tình huống
• Nếu kết nối bị ngắt trong lúc ACK đang được xử lý, bên gửi không thể biết segment đã được nhận hay chưa; giới hạn này không thể được giải quyết chỉ bằng một luồng TCP hai bên duy nhất, tương tự Two Generals’ Problem
• SMTP cũng xử lý vấn đề này trong RFC 1047 và RFC 2821; tại thời điểm trách nhiệm chuyển giao được chuyển sang bên khác, có một vùng mơ hồ nơi khi kết nối lỗi có thể dẫn đến gửi trùng hoặc bỏ sót
• Nếu xem các mạng kỳ lạ là ngoại lệ, hoặc bỏ qua các chi tiết hành vi như thuật toán Nagle, kiểm soát tắc nghẽn, chặn ICMP, ta rất dễ diễn giải sai các sự cố thực tế

---

Vấn đề kết luận trạng thái mạng trước cả TCP

• Một người dùng NetworkManager trước đây từng gặp kết nối không dây chập chờn trong môi trường roaming giữa ký túc xá và khuôn viên trường, và thấy rằng chỉ một chút mất gói cũng khiến toàn hệ thống nhận thông báo “không có mạng”
• Khi đó mạng có khả năng sớm hoạt động lại, và quá trình phục hồi của TCP thông thường, dù kéo theo độ trễ tăng vọt, vẫn có thể diễn ra một cách trong suốt với ứng dụng
• Ví dụ này liên quan đến vấn đề các ứng dụng hoặc thành phần hệ thống diễn giải quá nhanh một lỗi tạm thời mà TCP có thể xử lý thành thất bại

Những niềm tin thường sai về TCP

• Các câu sau là những niềm tin thường gặp khi làm việc với TCP, nhưng mỗi câu đều sai trong ít nhất một số trường hợp
  • TCP đáng tin cậy, nên mọi dữ liệu đã gửi đều đến được bên kia
  • TCP nhìn chung là đáng tin cậy
  • Ngay cả khi TCP không cung cấp độ tin cậy theo nghĩa đầy đủ, bên gửi và bên nhận cuối cùng vẫn thống nhất chính xác được byte nào đã được truyền
  • Nếu xây các giao thức ứng dụng hướng thông điệp như HTTP hoặc SMTP trên TCP, có thể tạo ra bảo đảm như vậy
  • Có thứ gọi là gói TCP
  • Không có thứ gọi là gói TCP
  • Nếu không kết nối được tới một host từ xa nổi tiếng thì nghĩa là đang offline
  • Thuật toán Nagle là tốt
  • Thuật toán Nagle là xấu
  • Không cần quan tâm đến thuật toán Nagle
  • Có thể coi TCP như một Unix pipe hai chiều đi qua mạng là đủ
  • 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
  • Các mạng kỳ lạ không trong suốt với giao thức chuẩn là ngoại lệ, có thể bỏ qua
  • TCP được triển khai trên IP

Vì sao khó thống nhất chính xác các byte đã được truyền

• Các vấn đề 1–4 ở trên liên quan đến độ tin cậy của TCP có liên hệ với Two Generals’ Problem
• Nếu kết nối bị ngắt khi ACK vẫn đang được xử lý, bên gửi không có cách nào xác nhận segment đó đã được nhận hay chưa
• Giới hạn này không biến mất ngay cả khi xếp thêm các lớp phức tạp lên trên TCP
• Không thể tạo ra bảo đảm này trên một luồng TCP hai bên duy nhất; những bảo đảm như vậy cần cách tiếp cận tương tự Paxos hoặc Raft và tối thiểu 3 node
• Cùng loại vấn đề này không chỉ áp dụng cho TCP mà còn cho UDP hoặc các dịch vụ hai bên dựa trên IP

Vùng xám về trách nhiệm chuyển giao mà SMTP làm lộ rõ

• SMTP là một dịch vụ trong đó hai bên phải quan tâm rõ ràng đến việc thông điệp đã được nhận hay chưa, nên vấn đề này hiện ra rất rõ
• RFC 1047 xử lý vấn đề này từ góc nhìn SMTP, còn RFC 2821 quy định rằng các triển khai phải tuân theo lời khuyên cốt lõi của RFC 1047
• Trong ví dụ SMTP, các trạng thái sau được phân biệt
  • Có thể đạt tới điểm mà cả hai bên thống nhất rằng email đã được truyền từ client sang server
  • Cũng có thể đạt tới điểm mà cả hai bên thống nhất rằng server đã nhận trách nhiệm chuyển giao email
  • Nhưng trước đó, chắc chắn phải đi qua một trạng thái mơ hồ về việc hiện ai đang chịu trách nhiệm chuyển giao email
• Nếu kết nối bị ngắt trong trạng thái mơ hồ này, email sẽ bị trùng lặp hoặc bỏ sót
• Đặc tả SMTP chỉ định phía sẽ tạo bản sao trùng của email, nhưng không rõ điều này đã được kiểm thử đến mức nào trong các triển khai thực tế
• Mục đích của Paxos và Raft không hẳn là đạt được trạng thái cuối cùng, mà là ngăn chặn các trạng thái mơ hồ như vậy

Giới hạn tri thức còn lại trong đồng thuận hai bên

• Một bình luận cho rằng ngay cả trên một liên kết không đáng tin cậy nhưng không ác ý, hai bên vẫn có thể thống nhất về một tập byte nào đó rằng “nó đã được truyền và cả hai bên đều biết điều đó”
• Trong thảo luận bổ sung, kết luận là một bên có thể biết rằng tập đã thống nhất bao gồm ít nhất N byte đầu tiên, nhưng không thể biết tập đã thống nhất chính xác là N byte đầu tiên
• Vì vậy, dù có thể tồn tại một tập byte “chắc chắn đã được truyền và cả hai bên đều biết”, phía sau nó vẫn còn một vùng xám nơi bên gửi và bên nhận không thể xác định chắc chắn trạng thái tri thức của nhau
• Nếu bỏ lỡ khác biệt này, các lỗi kỳ lạ rất dễ xảy ra trong hệ thống phân tán

Các cạm bẫy của mạng thực tế và các tầng thấp hơn

• Niềm tin rằng “các mạng kỳ lạ không trong suốt với giao thức chuẩn có thể bỏ qua” đã nhiều lần gây ra vấn đề
• buffer bloat được xem là một ví dụ trong đó router phá vỡ cơ chế kiểm soát tắc nghẽn
• Các mạng chặn ICMP hoặc loại bỏ lưu lượng mà chúng không hiểu cũng có thể gây vấn đề
• Niềm tin rằng “không cần biết về kiểm soát tắc nghẽn” cũng gần như là một ví dụ của việc hiểu sai TCP
  • Một ví dụ nhỏ là ý nghĩ rằng “nếu không đạt được tốc độ mong muốn thì cứ mở nhiều kết nối TCP”