•  ánh sáng không có thực

TCSplitter

Một đường hầm để chia kết nối TCP hoặc UDP qua nhiều kết nối TCP

Ghi bàn

Khi nào bạn muốn chia một kết nối TCP thành nhiều kết nối? Thông thường bạn sử dụng một đường hầm để đạt được hoàn toàn ngược lại . Trường hợp sử dụng của tôi là vượt qua giới hạn băng thông trong mạng di động, vì vậy các thử nghiệm được thực hiện với thẻ sim không còn dữ liệu trong gói của nó[1].

Làm thế nào nó hoạt động

Các đường hầm được viết bằng golang vì nó đủ nhanh và thường được sử dụng cho công cụ mạng. Cli gần như không thể sử dụng được vì hầu hết các tùy chọn đã được làm lại khi tôi thử nghiệm các phương pháp khác nhau.

Ban đầu có "flings" và "lassos", để phân chia số lượng kết nối cho đi (flinged) và đến (lassoed), nhưng đây là một sự trừu tượng không cần thiết vì tốt hơn là gắn thẻ các gói với đích của chúng, mặc dù mục đích chính là để cung cấp các giới hạn tốc độ khác nhau cho các kết nối đi và đến, do đó, sự phân tách cấp cao hơn giữa lên / xuống dường như thực tế.

Máy khách phải khởi tạo tất cả các kết nối vì chúng tôi giả định rằng máy chủ không thể mở các kết nối gửi đi. Khi máy khách nhận được kết nối từ một ứng dụng người dùng, nó sẽ thiết lập nhóm kết nối cần thiết với máy chủ và bất kỳ dữ liệu nào nó nhận được, nó sẽ chia nó ra giữa các kết nối chuyên dụng, theo một giới hạn do người dùng xác định.

Sau đó, các gói được gửi đến máy chủ, máy chủ phải cấu trúc lại chúng theo đúng thứ tự, vì các kết nối TCP khác nhau có thể kết thúc luồng dữ liệu bất kỳ lúc nào (thứ tự đã gửi không được tôn trọng, bởi vì định tuyến ), và sau đó được chuyển tiếp đến ứng dụng nhận.

Các kết nối bị đóng và các kết nối mới được mở khi đạt đến giới hạn dữ liệu đã định cấu hình cho mỗi kết nối, tương tự như cách tất bóngproxy đường hầm dữ liệu qua các luồng khác nhau với mục tiêu che dấu hoạt động của các luồng dữ liệu, ngoại trừ việc đường hầm của chúng tôi đang làm điều đó thường xuyên nhất có thể.

Tại sao nó hoạt động

Mục đích ở đây là kiểm soát lượng dữ liệu mà mọi kết nối sẽ xử lý. Đối với mục đích của chúng tôi, nó không bao giờ vượt quá thường là MTU kích thước cửa sổ. Bạn có thể coi MTU là giới hạn trên của một phần dữ liệu truyền toàn bộ mạng và nó là mục tiêu của chúng tôi vì chúng tôi muốn vượt qua giới hạn tốc độ băng thông của một mạng được kiểm soát. Để giới hạn lượng dữ liệu mà khách hàng có thể chuyển qua, bạn cần đếm đúng? Nếu logic của bạn hoạt động với một cái gì đó giống nhưdo-while

Sau đó, bạn cần phải ít nhất nhận đượcpacket . Tôi không chắc liệu đây có phải là điều thực sự xảy ra hay lý do đường hầm của tôi hoạt động là một lý do khác. Có thể hoàn toàn có thể kiểm tra ngay cả gói đầu tiên, nhưng từ góc độ thiết kế, điều đó có nghĩa là bạn sẽ phải kiểm tra mỗi kết nối đơn lẻ, điều này sẽ làm cho hệ thống yếu hơn trước các cuộc tấn công DOS và vâng, đường hầm của tôi có thể dễ dàng được sử dụng như một công cụ DOS / Stress hiệu quả, vì bạn có thể chia dữ liệu thành các gói rất nhỏ (có nghĩa là các kết nối TCP sẽ có áp suất tái chế cao ) và có một nhóm kết nối lớn tùy thích.

Thử nghiệm trên các cổng khác nhau cũng cho thấy rằng chỉ có thể một vài các cổng và giới hạn liên tục khác nhau giữa các cổng, với443 đưa ra một trong những cửa sổ cao hơn, xung quanh20kb , đoán vìTLS bắt tay yêu cầu nhiều dữ liệu hơn và các giới hạn tỷ lệ này sẽ thay đổi tùy theo thời gian trong ngày[2].

Kết quả

Tôi đã thử xóa mã hóa với hy vọng tăng thông lượng dữ liệu. Bằng cách sử dụng thư viện mã hóa xóa và mã hóa / giải mã chính dữ liệu và cũng bằng cách phủ KCP giao thức qua giao thức tách của tôi. Thử KCP có vẻ là một cách tiếp cận ngược, vì nó giao dịch độ trễ tốt hơn cho thông lượng thấp hơn, nhưng giả định ban đầu của tôi là nút thắt cổ chai của tôi là do kết nối bị rớt giữa đường truyền, điều này sẽ gây ra rất nhiều gói bị hỏng, vì vậy tôi có thể đạt được mức cao hơn thông lượng với sửa lỗi.

Hóa ra đó chỉ là một giới hạn tốc độ đối với số lượng kết nối TCP mà một máy khách có thể gửi qua mạng, vì vậy chỉ là một bảo vệ DOS mà tôi không thể làm gì được. Sau X lượng kết nối bất kỳSYN nỗ lực ngừng nhận được đến hạn của họACK , lấp đầy công việc tồn đọng và cuối cùng khiến đường hầm bị đình trệ. Thử nghiệm và sai sót cho thấy rằng có thể xảy ra giữa4-8[3] kết nối mở bất kỳ lúc nào và với MTU là500-1000 byte bạn có thể giữ một luồng ổn định ít nhất là128kbps , nếu một luồng liên tục không phải là một yêu cầu, bạn có thể đạt được tốc độ cao hơn trong một khoảng thời gian ngắn hơn bằng cách bùng nổ nhiều kết nối theo yêu cầu.

Ngược lại, a (true)DNS đường hầm hầu như không thể đẩy56kbps và có thể nhanh chóng bị điều chỉnh vì tôi nghĩ rằng một số lượng lớn các yêu cầu DNS trông đáng ngờ hơn so với các yêu cầu TCP. Chúng tôi phải xác định rằng mộttrue Đường hầm DNS mã hóa dữ liệu (gửi đi) qua các miền phụ không có thật và giải mã dữ liệu (đến) nhận được bằng cách truy vấn bản ghi DNS, trong khi đôi khi đường hầm DNS có thể được coi là một kết nối UDP thô qua cổng DNS, có thể là trước đây, máy chủ DNS được phép và chuyển tiếp một cách chính xác.

Kết luận

Tôi không chắc mình đã đạt được mục tiêu tính thiết thực khôn ngoan, vì chạy kiểu hầm hố như vậy có thể khiến điện thoại của bạn khá nóng và tốn rất nhiều pin, nhưng có nó như một kết nối dự phòng thì có thể yên tâm ... nếu tôi thực sự bận tâm để làm cho nó đủ ổn định :)

[1]thường khi thẻ sim không còn dữ liệu để duyệt web, các yêu cầu web sẽ chuyển hướng đến cổng chụp ảnh (để yêu cầu bạn mua thêm dữ liệu)
[2]các gói dữ liệu di động có thể cung cấp kết nối tốt hơn vào ban đêm
[3]Con số này, hơi phù hợp với số lượng lõi phổ biến, có thể khiến bạn nghi ngờ rằng bằng cách nào đó hạt nhân đang giới hạn kết nối, kịch bản về các kết nối đã mở của đường hầm của chúng ta chắc chắn là bất thường, nhưng việc điều chỉnh các nút linux không bao giờ cho kết quả tốt hơn về phía tôi.

Thẻ bài: