Internet hoạt động dựa trên một số giao thức cốt lõi, với TCP và UDP là những ngựa thồ xử lý gần như tất cả dữ liệu của chúng ta. Nhưng điều gì xảy ra khi bạn cố gắng sử dụng một giao thức khác? Một thí nghiệm thú vị gửi các gói tin với các giao thức vận chuyển tự tạo qua internet đã tiết lộ những ràng buộc ẩn của cơ sở hạ tầng kỹ thuật số và lý do tại sao đổi mới ở tầng vận chuyển đã trở nên gần như không thể.
Sự Cứng Hóa Giao Thức: Vấn Đề Ẩn Của Internet
Internet đang phải chịu một tình trạng được gọi là sự cứng hóa giao thức - nơi mà việc triển khai rộng rãi các middlebox, tường lửa và thiết bị NAT đã thực sự khóa chúng ta vào việc chỉ sử dụng TCP và UDP cho vận chuyển dữ liệu. Mặc dù về lý thuyết, mạng IP nên chuyển tiếp bất kỳ giao thức nào, nhưng thực tế lại khác xa. Như một người bình luận giải thích, Internet đã tiêu chuẩn hóa xung quanh TCP và UDP. Có quá nhiều thiết bị trong hầu hết các đường dẫn không thể xử lý các giao thức khác. Sự cứng hóa này xảy ra bởi vì các nhà sản xuất và vận hành thiết bị mạng tối ưu hóa cho các giao thức họ thấy thường xuyên nhất, phá vỡ khả năng tương thích với bất cứ thứ gì mới hoặc khác biệt.
SCTP (Stream Control Transmission Protocol) là ví dụ hoàn hảo cho vấn đề này. Mặc dù về mặt kỹ thuật vượt trội hơn TCP trong nhiều khía cạnh, nhưng nó vẫn hầu như không được sử dụng trên internet công cộng.
SCTP thật thú vị vì nó là một trong những công nghệ nền tảng giúp giao tiếp trở nên khả thi cho hầu hết mọi người trên hành tinh (vì hệ thống mạng di động phần lớn phụ thuộc vào nó), nhưng nó lại không được hỗ trợ trên hầu hết mọi thiết bị người dùng.
Trong khi SCTP cung cấp năng lượng cho cơ sở hạ tầng viễn thông quan trọng bên trong, nó không thể đi qua internet công cộng một cách đáng tin cậy. Nghịch lý này nhấn mạnh cách mà ngay cả các giao thức được thiết kế tốt, đã được tiêu chuẩn hóa cũng có thể không được chấp nhận khi đối mặt với thực tế về cách các mạng được xây dựng và quản lý.
Các vấn đề về Hóa thạch hóa Giao thức
- Các Giao thức Thất bại: SCTP (Stream Control Transmission Protocol) - ưu việt về mặt kỹ thuật nhưng không thể đi qua internet công cộng
- Vấn đề NAT: Người dùng gia đình đằng sau NAT chỉ giới hạn ở TCP/UDP
- Chiến lược Giải quyết: Đóng gói các giao thức mới bên trong UDP (ví dụ: QUIC cho HTTP/3)
- Trường hợp Đặc biệt:
- SCTP được sử dụng rộng rãi trong cơ sở hạ tầng mạng di động nội bộ
- WebRTC chạy SCTP qua DTLS qua UDP
- Các giao thức tùy chỉnh có thể hoạt động giữa các máy chủ trung tâm dữ liệu nhưng thất bại khi đi qua internet công cộng
Lý do Giao thức Tùy chỉnh Thất bại
- Các middlebox loại bỏ các giao thức không quen thuộc
- Các thiết bị NAT không thể theo dõi trạng thái kết nối nếu không có số cổng
- Công cụ bảo mật doanh nghiệp mất khả năng giám sát
- Tường lửa chặn các gói tin không khớp với luồng hiện có
NAT: Rào Cản Lớn Nhất Của Internet
Các thiết bị Network Address Translation (NAT) đại diện cho rào cản đáng kể nhất đối với đổi mới giao thức. NAT hoạt động bằng cách theo dõi các kết nối sử dụng các trường tầng vận chuyển - cụ thể là số cổng trong tiêu đề TCP và UDP. Khi đối mặt với một giao thức không xác định không có các trường quen thuộc này, hầu hết các thiết bị NAT hoặc tiêu thụ toàn bộ địa chỉ IP (nhanh chóng làm cạn kiệt địa chỉ có sẵn) hoặc đơn giản là loại bỏ các gói tin.
Hạn chế này đặc biệt có vấn đề đối với người dùng gia đình. Như một người bình luận đã lưu ý, Mọi người dùng gia đình đều đứng sau NAT. Trong khi bạn có thể gửi bất kỳ giao thức nào giữa các máy chủ trung tâm dữ liệu, người dùng IPv4 tại nhà bị giới hạn với TCP hoặc UDP. Ngay cả trong thí nghiệm được mô tả trong bài viết, các gói tin sử dụng giao thức tùy chỉnh đôi khi đi qua được một lần nhưng sau đó bị loại bỏ, có thể vì tường lửa không thể khớp chúng với các luồng kết nối hiện có.
Tương Lai: Đường Hầm Giao Thức và IPv6
Để vượt qua sự cứng hóa, các nhà thiết kế giao thức hiện đại đã áp dụng một cách tiếp cận thực tế: tạo đường hầm cho các giao thức mới bên trong UDP. QUIC, cung cấp năng lượng cho HTTP/3, minh họa cho chiến lược này. Thay vì chống lại hệ thống, QUIC chấp nhận UDP như một nền tảng và xây dựng các đổi mới của nó trên đó.
Cách tiếp cận này tạo ra căng thẳng giữa đổi mới và bảo mật. Các quản trị viên mạng thường chống lại những phát triển này vì chúng phá vỡ các công cụ bảo mật hiện có. Như một chuyên gia mạng đã giải thích, Từ góc độ bảo mật doanh nghiệp, nó phá vỡ nhiều công cụ. Bạn không thể giải mã, chữ ký IDS/IPS không hoạt động, và bạn mất khả năng hiển thị những gì đang diễn ra trong mạng của mình.
IPv6 mang lại một số hy vọng cho sự đa dạng giao thức, vì nó loại bỏ nhu cầu về NAT trong nhiều tình huống. Tuy nhiên, ngay cả với IPv6, tường lửa và middlebox vẫn có thể chặn các giao thức không quen thuộc. Quá trình chuyển đổi sang IPv6 vẫn còn chậm đáng thất vọng, với nhiều mạng doanh nghiệp vẫn dựa vào không gian địa chỉ IPv4.
Thí nghiệm được mô tả trong bài viết xác nhận những gì các kỹ sư mạng đã nghi ngờ từ lâu: internet đã trở thành một môi trường chuyên biệt cao được tối ưu hóa cho một tập hợp nhỏ các giao thức. Mặc dù bạn có thể may mắn gửi một gói tin duy nhất với một giao thức kỳ lạ, việc xây dựng giao tiếp đáng tin cậy đòi hỏi làm việc trong các ràng buộc của những gì mạng thực sự hỗ trợ, không phải những gì về mặt lý thuyết nó nên hỗ trợ.
Trong tương lai gần, TCP và UDP sẽ vẫn là các tùy chọn vận chuyển khả thi duy nhất cho lưu lượng internet công cộng, với đổi mới chủ yếu xảy ra thông qua đường hầm và phân lớp hơn là thông qua các giao thức vận chuyển mới.
Tham khảo: Điều gì sẽ xảy ra nếu chúng ta không sử dụng TCP hoặc UDP?
 |
|---|
| Quy tắc tường lửa hạn chế lưu lượng đi ra thể hiện các ràng buộc mạng đối với đổi mới giao thức |