Điều gì sẽ xảy ra nếu không dùng TCP hay UDP?

• Hạ tầng mạng được cấu thành từ switch, bridge, router, load balancer, firewall, v.v.
• Hệ điều hành kiểm soát giao tiếp mạng bằng cách phân loại gói tin, đưa vào hàng đợi và áp dụng các quy tắc firewall
• Vậy nếu dùng một giao thức tầng vận chuyển không tồn tại thì chuyện gì sẽ xảy ra?
• OS có cho phép không? Gói tin có thực sự được chuyển đi không? Firewall có chặn không?
• Tác giả đã trực tiếp làm thí nghiệm để kiểm chứng

Tổng quan về giao thức Internet

• Internet hoạt động bằng cách nhiều tầng giao thức phối hợp truyền dữ liệu
• Khi ứng dụng gửi yêu cầu, OS sẽ bọc nó bằng header của nhiều tầng mạng rồi truyền đi
• Tầng vận chuyển (Transport Layer): là nơi có các giao thức như TCP(6), UDP(17)
• Nếu sửa trường Protocol của IP header và đưa vào một số chưa dùng thì điều gì sẽ xảy ra?

Thí nghiệm #1: kiểm thử trực tiếp trên PC cá nhân

Cách thí nghiệm

1. Định nghĩa HDP (giao thức giả): thiết kế một giao thức tầng vận chuyển mới hoàn toàn khác với các giao thức hiện có
2. Triển khai server và client: phát triển chương trình gửi và nhận gói tin
3. Kiểm thử loopback: quan sát cách OS tự xử lý gói tin

Quá trình chạy

$ sudo cargo run --bin server  # chạy server  
$ fortune | cowsay | sudo cargo run --bin client 127.0.0.1  # chạy client  

Kết quả

• OS xử lý gói HDP bình thường và nhận lại qua giao diện loopback
• Tiếp tục kiểm thử thêm bằng cách thay đổi số giao thức IP
  • 1 (ICMP), 2 (IGMP), 6 (TCP) → server không phát hiện được
  • 50, 51 (các giao thức liên quan đến IPSec) → bản thân việc gửi đã bị chặn ở phía client
  • 256 (vượt phạm vi số giao thức IP) → phát sinh lỗi ở bước gọi socket()

Phân tích nguyên nhân

• Có trường hợp OS dành riêng ở cấp hệ thống một số giao thức nhất định và chặn chúng
• Trên Darwin (macOS dựa trên BSD), nếu đặt protocol=0 khi gọi socket() thì một số gói sẽ bị lọc tự động
• Các giao thức liên quan đến IPSec nhiều khả năng bị chặn vì lý do bảo mật
• Số giao thức IPv4 là 8 bit, nên chỉ hợp lệ trong khoảng 0~255

Thí nghiệm #2: truyền gói tin qua Internet

Kế hoạch thí nghiệm

1. Thiết lập VPS DigitalOcean: dựng môi trường thử nghiệm trên máy chủ cloud ở Frankfurt, Đức
2. Gửi gói HDP: truyền gói từ PC cá nhân (Saudi Arabia) đến server DigitalOcean
3. Phân tích phản ứng của thiết bị mạng: kiểm tra gói có tới nơi không, firewall có chặn hay không

Kết quả dự kiến

• Gói HDP có thể được chuyển đi bình thường, hoặc có thể bị firewall của một số ISP hay của DigitalOcean chặn

Kết quả thực tế

• Chỉ gói đầu tiên được chuyển tới, các gói sau đó bị chặn
• Kết quả xác minh bằng tcpdump:
  • Gói từ PC cá nhân được gửi đi bình thường
  • Server DigitalOcean chỉ phát hiện gói đầu tiên
  • Các gói sau đó bị chặn ở đâu đó (NAT, firewall, ISP, v.v.)

Phân tích nguyên nhân

• DigitalOcean không hỗ trợ các giao thức IP phi tiêu chuẩn
• Chính sách firewall của nhà cung cấp cloud nhiều khả năng là nguyên nhân chính
• Vì sao chỉ gói đầu tiên tới được thì vẫn chưa rõ

Thử nghiệm lại trên AWS

• Tác giả làm lại thí nghiệm trên AWS với hai instance
• Trong cùng một datacenter, gói HDP được gửi và nhận bình thường
• Nhưng khi truyền qua Internet thì lại gặp đúng vấn đề như DigitalOcean: chỉ gói đầu tiên tới được

Các vấn đề chính

• NAT (Network Address Translation): hoạt động dựa trên cổng TCP/UDP nên không có cách nào xử lý một giao thức mới như HDP
• Firewall/lọc mạng: đa số ISP và nhà cung cấp cloud chặn các giao thức IP chưa được chấp thuận
• Vấn đề tối ưu hóa của thiết bị mạng: một số thiết bị mạng có thể mặc định xóa các gói phi tiêu chuẩn

Kết luận: dùng TCP và UDP vẫn là tốt nhất

• Cách triển khai network stack giữa các OS là khác nhau
  • Cách socket() hoạt động trên Linux, macOS và Windows đều không giống nhau
• Firewall và thiết bị NAT chặn các giao thức phi tiêu chuẩn
  • Có thể chạy trong mạng riêng, nhưng trên Internet thì gần như bất khả thi
• Không có lợi ích cải thiện hiệu năng
  • Đã có những lựa chọn thay thế được kiểm chứng như QUIC triển khai trên nền UDP
• Hãy dùng TCP/UDP
  • Khi dùng giao thức tiêu chuẩn, NAT theo cổng, firewall, định tuyến, v.v. sẽ được hỗ trợ tự động

Tài liệu bổ sung

• Đặc tả giao thức UDP
• Danh sách số giao thức IP
• Sự khác biệt raw socket theo từng nền tảng

[junhochoi]

Có vẻ đọc bài https://www.saturnsoft.net/network/2019/03/21/quic-http3-1/ cũng sẽ giúp ích đấy.

[secret3056]

Tôi nhớ hồi xưa khi chơi multiplayer StarCraft qua Hamachi có IPX, lúc đó tôi đã rất tò mò không biết nó là gì.

[secret3056]

Nghĩ lại thì NAT sẽ chặn tất cả... Nếu IPv6 được triển khai hoàn toàn và NAT biến mất (dù có lẽ chuyện đó sẽ không xảy ra), thì cũng có thể giao tiếp bằng giao thức do chính mình tạo ra.

[tujuc]

Ồ, một thử nghiệm hay đấy...
Ý tưởng làm rung chuyển nền tảng mạng thì rất thú vị, nhưng mọi thiết bị mạng trên đời này đều chỉ được tối ưu cho TCP/UDP thôi...

Khi còn chưa biết rằng thiết bị mạng thực chất là kiểu sản xuất theo khuôn mẫu... thì có vẻ vẫn làm được... nhưng khi đã biết rồi thì sẽ nhận ra rằng, trừ khi mình thành công đến mức khiến mọi người đều dùng giao thức của mình, nếu không thì là chuyện không thể...

[GN⁺]

Ý kiến Hacker News

• Có SCTP, một giao thức cũ tốt hơn TCP nhưng không được chấp nhận
  • Vì phần cứng mạng đã chặn mọi thứ ngoài TCP và UDP
• Với tư cách là người từng triển khai nhiều giao thức truyền tải khác nhau, trở ngại lớn nhất khi xây dựng các lớp trên IP không phải là router WAN mà là các thiết bị NAT dành cho người dùng
  • Với một số router Netgear nhất định, lưu lượng vẫn đi được đến đích nhưng xảy ra lỗi hỏng kỳ lạ là 4 byte đầu tiên bị biến thành 0
  • Nghi ngờ rằng nó được xử lý như TCP/UDP nhưng trên thực tế lại không đi theo đường dịch địa chỉ thông thường
• Nếu không dùng TCP hay UDP thì việc liên lạc sẽ rất khó
  • Internet lấy TCP và UDP làm tiêu chuẩn
  • Có rất nhiều thiết bị không thể xử lý các giao thức khác
  • Việc thay toàn bộ phần cứng Internet sẽ còn mất nhiều thời gian hơn cả việc loại bỏ IPv4
  • Chỉ khi một giao thức mới có lợi ích đủ lớn thì mọi doanh nghiệp và chính phủ mới bỏ ra chi phí lớn để triển khai hỗ trợ
• Phần kết của bài viết tạo cảm giác như một cliffhanger
  • Tò mò vì sao chỉ có một gói tin của giao thức tùy chỉnh đi qua được còn những gói còn lại lại bị drop
• Tôi từng nghĩ các gói TCP/UDP chỉ được OS network stack chuyển tới các tiến trình đang lắng nghe trên một cổng cụ thể
  • Đây có thể là một tính năng bảo mật, và các tiến trình không có quyền thì không thể lắng nghe một số cổng
  • Không nghĩ rằng một tiến trình khác lại có thể bắt toàn bộ lưu lượng
  • Trước đây không biết có thể bắt lưu lượng của nhiều giao thức tầng vận chuyển khác nhau
  • Có lẽ system call tương ứng sẽ yêu cầu quyền cao
• Tò mò nếu Internet protocol và thiết bị định tuyến được thiết kế lại từ đầu trong thời đại ngày nay thì sẽ như thế nào
  • Có lẽ sẽ dùng các gói lớn hơn nhiều và một giao thức cơ sở kiểu UDP để thay thế HTTP
  • Một giao thức streaming đơn giản sẽ thay TCP và hỗ trợ phát video
  • Hai giao thức đó có lẽ sẽ xử lý phần lớn lưu lượng hiệu quả hơn
• Đây là một giả định kiểu "nếu tái phát minh bánh xe thì sao?"
• Cần packet socket
  • Mạng IP lẽ ra phải chuyển mọi thứ, nhưng NAT mới là vấn đề chính
  • Thử với IPv6 có lẽ sẽ rất thú vị
• Đã có thể dùng các giao thức khác từ thời trước khi TCP/UDP/IP thống trị mọi thứ
• Mọi người hẳn sẽ dùng UUCP
  • Nó từng làm những việc tương tự trước thời TCP/UDP