tác giả:  (1) Vinod S. Khandkar và Manjesh K. Hanawal, Nghiên cứu vận hành và kỹ thuật công nghiệp Viện Công nghệ Ấn Độ Bombay, Mumbai, Ấn Độ và {vinod.khandkar, mhanawal}@iitb.ac.in.  Bảng liên kết   Tóm tắt & Giới thiệu   Công việc liên quan và bối cảnh   Những thách thức trong việc phát triển thiết lập đo lường phát hiện TD   Nghiên cứu điển hình: Wehe - Công cụ phát hiện TD cho môi trường di động   Thiếu sót của Wehe về lưu lượng HTTPS   TD Phát hiện lưu lượng truy cập HTTPS   Kết luận & Tài liệu tham khảo  V. SỰ THIẾU CỦA WEHE TRÊN LƯU LƯỢNG HTTPS  Nghiên cứu của chúng tôi tập trung vào việc xác thực các phản hồi của mạng đối với các luồng lưu lượng được phát lại, phát hiện TD và tính khả thi trong hoạt động trong các cấu hình mạng khác nhau. Mặc dù tính khả thi trong hoạt động được xác thực bằng ứng dụng Android “Wehe” có sẵn công khai trên Google Playstore, nhưng các kịch bản phát hiện TD được xác thực bằng cách sử dụng các lập luận lý thuyết. Việc xác thực các phản hồi của mạng yêu cầu phân tích băng thông của luồng lưu lượng nhận được. Phân tích này yêu cầu nhật ký mạng cho hoạt động phát lại cụ thể được thực hiện theo kịch bản xác thực. Việc phát lại được thực hiện trên thiết bị và nhiều luồng khác   Hình 6. Phân loại lưu lượng truy cập YouTube được phát lại  các dịch vụ chạy song song là một trong những trường hợp như vậy. Ứng dụng Wehe không cung cấp ngay nhật ký mạng như vậy cho các lần phát lại sau khi hoàn thành quá trình kiểm tra. Vì vậy, chúng tôi đã triển khai máy khách-người dùng và máy chủ bắt chước hoạt động của công cụ Wehe.  Chúng tôi sử dụng thiết lập máy khách-máy chủ tương tự như thiết lập được hiển thị trong Hình 3 để xác thực Wehe. Trong thiết lập hiện tại, chúng tôi đã thay thế máy chủ của dịch vụ ban đầu bằng máy chủ phát lại. Máy khách người dùng và máy chủ phát lại được kết nối thông qua một công cụ định hình lưu lượng truy cập thương mại. Hơn nữa, thiết lập của chúng tôi có điều khoản để thực hiện nhiều lần phát lại song song. Thiết lập xác thực của chúng tôi không cần các kênh quản trị và chi phí chung, ví dụ: các kênh phụ. Máy chủ của chúng tôi luôn cần hỗ trợ máy khách một người dùng. Việc xác thực các tình huống với nhiều khách hàng sử dụng trực tiếp Ứng dụng Wehe do không yêu cầu phân tích lưu lượng truy cập liên quan.  Lời nhắc của phần này mô tả kết quả xác nhận.   A. Mô phỏng lưu lượng truy cập của dịch vụ gốc  Phản hồi của mạng phụ thuộc vào việc áp dụng các chính sách mạng dựa trên việc phân loại lưu lượng thăm dò chính xác theo các hộp giữa của mạng như đã đề cập trong Phần III-A. Chúng tôi đã xác thực việc phân loại lưu lượng truy cập mô phỏng của Wehe bằng cách sử dụng công cụ định hình lưu lượng truy cập thương mại. Việc phân loại lưu lượng truy cập mô phỏng được quan sát bằng giao diện người dùng của công cụ định hình lưu lượng truy cập thương mại.  Để thực hiện thử nghiệm, dữ liệu ứng dụng YouTube được phát lại từ máy chủ phát lại đến người dùng-khách hàng thông qua công cụ định hình lưu lượng truy cập thương mại. Trong quá trình truyền dữ liệu, cửa sổ giao diện người dùng của công cụ định hình lưu lượng truy cập thương mại sẽ quan sát sự hiện diện của lưu lượng truy cập YouTube. Chúng tôi cũng đã truy cập lưu lượng truy cập YouTube bằng trình duyệt internet và quan sát kết quả phân loại của công cụ định hình lưu lượng truy cập để làm cơ sở quan sát phân loại lưu lượng truy cập của chúng tôi.  Hình 6 cho thấy kết quả phân loại lưu lượng truy cập được hiển thị qua cửa sổ giao diện người dùng của công cụ định hình lưu lượng truy cập thương mại đối với lưu lượng truy cập được truy cập trực tiếp bằng trình duyệt internet từ máy chủ YouTube. Nó hiển thị hoạt động internet ở cửa sổ bên trái và phân loại lưu lượng truy cập tương ứng ở cửa sổ bên phải.  Hình 6(a) cho thấy lưu lượng truy cập được truy cập bằng trình duyệt internet được phân loại chính xác là YouTube. Điều này phù hợp với hành vi dự định của người định hình lưu lượng truy cập thương mại.  Hình 6(b) hiển thị kết quả phân loại lưu lượng truy cập cho lưu lượng truy cập bằng người dùng-máy khách. Nó cho thấy bằng chứng về việc không có lưu lượng truy cập YouTube nào được chuyển qua liên kết truyền thông. Hơn nữa, nó phân loại lưu lượng truy cập giống như lưu lượng HTTPS. Kết quả của thử nghiệm này cho thấy rằng không phải tất cả các hộp trung gian của mạng đều có thể phân loại chính xác lưu lượng truy cập được phát lại của Wehe.   B. Ảnh hưởng của tốc độ dữ liệu trong tập lệnh phát lại  Việc tạo lưu lượng truy cập thăm dò tác động đến phản hồi mạng như mong đợi bằng thuật toán phát hiện TD. Wehe sử dụng dấu vết lưu lượng truy cập từ dịch vụ ban đầu để tạo tập lệnh phát lại nhằm bảo toàn dữ liệu ứng dụng và mối quan hệ thời gian của nó. Tập lệnh phát lại này được sử dụng trên mạng ban đầu và cả trên các mạng có vị trí địa lý khác nhau. Vì tốc độ định hình lưu lượng thay đổi giữa các mạng cho cùng một dịch vụ (như đã đề cập trong [32]), tốc độ lưu lượng được bảo toàn trong tập lệnh phát lại có thể khác với tốc độ định hình lưu lượng của mạng hiện đang được xem xét. Tốc độ lưu lượng phát lại có thể thấp hơn tốc độ định hình lưu lượng.  Phương pháp Wehe không phát hiện sự phân biệt lưu lượng nếu tốc độ lưu lượng truy cập của tập lệnh phát lại thấp hơn tốc độ định hình của mạng vì nó không ảnh hưởng đến luồng lưu lượng. Các tập lệnh phát lại như vậy không bao giờ có thể phát hiện được việc định hình lưu lượng truy cập trên các mạng như vậy. Do đó, khả năng phát hiện TD của công cụ Wehe bị hạn chế bởi tốc độ lưu lượng thăm dò của tập lệnh phát lại.   C. Sử dụng cổng số 80  Phản hồi của mạng được thúc đẩy bởi nhận thức của hộp trung gian mạng về lưu lượng thăm dò (tham khảo Phần III-A). Tập lệnh phát lại lưu giữ dữ liệu trong dấu vết mạng ban đầu của ứng dụng. Các máy chủ ứng dụng gốc sử dụng cổng 80 cho dữ liệu văn bản thuần túy và cổng 443 để truyền dữ liệu được mã hóa. Tập lệnh phát lại của Wehe trực tiếp sử dụng dữ liệu được mã hóa từ dấu vết mạng của ứng dụng và truyền dữ liệu đó trên cổng 80. Trong những trường hợp như vậy, Wehe hy vọng luồng lưu lượng phát lại ban đầu của nó sẽ được phân loại chính xác bởi các thiết bị mạng sử dụng dữ liệu ứng dụng được mã hóa. Dữ liệu như vậy trên cổng 80 là không thể vì dữ liệu lưu lượng được mã hóa không thể tiết lộ danh tính của nó cho thiết bị mạng. Do đó, công cụ Wehe không thể tạo luồng lưu lượng cần thiết cho các dịch vụ chạy trên cổng số 443 do sử dụng cổng 80 mặc định để chạy lại.   D. Hành vi mạng chi phối lưu lượng truy cập  Lưu ý rằng sự khan hiếm tài nguyên sẽ thúc đẩy các mạng áp dụng một số biện pháp quản lý lưu lượng mạng nhất định, đặc biệt là trong các tình huống tải mạng nặng, điều này có lợi cho tất cả các dịch vụ đang hoạt động trên mạng của nó, ví dụ: quản lý lưu lượng dựa trên QoS (tham khảo Phần III-A). Chúng tôi đã xác nhận hiệu quả của việc quản lý lưu lượng truy cập như vậy   Hình 7. Ảnh hưởng của tải mạng đến hiệu suất luồng lưu lượng truy cập của Wehe  về hiệu suất của cả bản phát lại gốc và bản kiểm soát. Việc xác thực sử dụng ba kịch bản sau để xác thực,  • Chỉ phát lại hai luồng lưu lượng của Wehe mà không tải trên mạng (Hình 7(a))  • Phát lại ba luồng lưu lượng truy cập của Wehe với một dịch vụ phát trực tuyến bổ sung chạy song song (Hình 7(b))  • Phát lại ba luồng lưu lượng truy cập của Wehe với 2 dịch vụ phát trực tuyến bổ sung chạy song song (Hình 7(c))  Hiệu suất trong Hình 7(a) cho thấy hiệu suất của các luồng lưu lượng do công cụ Wehe tạo ra là như nhau trong điều kiện không có tải mạng bổ sung. Khi tải mạng tăng lên, hiệu suất của tính năng phát lại điều khiển sẽ khác so với hiệu suất của tính năng phát lại ban đầu và ở mức cao hơn (Hình 7(b)). Trong khi hiệu suất của tính năng phát lại điều khiển khác biệt hơn so với tính năng phát lại ban đầu ở phía dưới, hai bản phát lại gốc vẫn hiển thị hiệu suất tương tự như trong Hình 7(c). Nó vô hiệu hóa kỳ vọng của công cụ Wehe về việc phát lại điều khiển không bị khác biệt. Nó cũng vô hiệu hóa tuyên bố của công cụ phát hiện TD do tổng băng thông.   E. Chúng tôi kiểm tra từ nhiều thiết bị trong cùng một mạng con  Các kênh bên được giới thiệu trong thiết kế Wehe để hỗ trợ nhiều khách hàng người dùng cùng một lúc. Các kênh bên cũng hỗ trợ xác định ánh xạ giữa người dùng-máy khách và sự kết hợp giữa địa chỉ IP và cổng. Nó rất hữu ích trong trường hợp mạng sử dụng NAT [33]. Chúng tôi đã xác thực khả năng hỗ trợ của Wehe dành cho nhiều máy khách và mạng hỗ trợ NAT bằng hai thử nghiệm khác nhau. Đầu tiên, chúng tôi kết nối hai máy khách người dùng từ trong cùng một mạng con, tức là các máy khách chia sẻ cùng một địa chỉ IP công cộng. Trong một thử nghiệm, công cụ Wehe kiểm tra cùng một dịch vụ trên cả hai thiết bị, ví dụ: Ứng dụng Wehe trên cả hai thiết bị kiểm tra YouTube. Kết quả cho thấy thử nghiệm Wehe chỉ hoàn thành việc hoàn tất trên một thiết bị trong khi Ứng dụng Wehe đột ngột đóng trên một thiết bị khác. Chúng tôi lặp lại kịch bản tương tự, nhưng lần này Wehe thử nghiệm các dịch vụ khác nhau, ví dụ: Wehe trên một thiết bị đang thử nghiệm YouTube trong một lần thử nghiệm Netflix khác. Chúng tôi nhận thấy rằng thử nghiệm Wehe trên một thiết bị hoàn thành bình thường trong khi thử nghiệm Wehe trên một thiết bị khác đưa ra lỗi trên màn hình, thông báo cho người dùng rằng một ứng dụng khách khác đang thực hiện thử nghiệm, như trong Hình 9. Các thử nghiệm này cho thấy Wehe đã làm như vậy không hỗ trợ nhiều thiết bị nếu chúng chia sẻ cùng một địa chỉ IP. Mặc dù kênh bên rất hữu ích trong việc xác định từng phát lại từ máy khách-người dùng được kết nối trực tiếp với máy chủ phát lại Wehe nhưng nó không hữu ích trong mạng sử dụng thiết bị NAT. Nhiều người dùng chia sẻ cùng một địa chỉ IP trong trường hợp NAT. Trong những trường hợp như vậy, kênh bên không thể ánh xạ duy nhất mỗi lần chạy lại tới một máy khách. Nó giới hạn việc sử dụng Wehe chỉ ở một khách hàng đang hoạt động trên mỗi máy chủ phát lại, ISP và ứng dụng. Hạn chế này cũng được các nhà phát triển Wehe ghi lại.   F. Ảnh hưởng của tải mạng thiết bị đến việc phát hiện TD  Máy chủ phát lại của Wehe sử dụng cùng thời gian giữa quá trình truyền dữ liệu ứng dụng với lưu lượng truy cập ứng dụng gốc. Chiến lược truyền tải như vậy dự kiến sẽ không làm cạn kiệt băng thông sẵn có. Do đó, ảnh hưởng của điều chế tốc độ nguồn do tốc độ lưu lượng vượt quá băng thông khả dụng là không thể xảy ra. Nó làm cho các bản phát lại gốc và bản kiểm soát hiển thị hiệu suất lưu lượng truy cập tương tự trừ khi được sửa đổi có chủ ý bởi các chính sách mạng, tức là TD.  Tuy nhiên, kỳ vọng này không phải lúc nào cũng được đáp ứng vì tốc độ dữ liệu lưu lượng được điều chỉnh theo tải mạng trên thiết bị người dùng trong khi thực hiện kiểm tra Wehe. Những nhiễu loạn như vậy tạo ra sự khác biệt vì ảnh hưởng của tải mạng hiện tại thay đổi theo thời gian lên lưu lượng thăm dò cũng thay đổi theo thời gian và có thể không phải lúc nào cũng giống nhau. Chiến lược phát lại giáp lưng của Wehe đảm bảo rằng cả luồng lưu lượng thăm dò (phát lại gốc và kiểm soát) đều bị ảnh hưởng khác nhau bởi tải mạng hiện tại. Dưới tải mạng như vậy về phía thiết bị, khái niệm dịch vụ không làm cạn kiệt băng thông sẵn có sẽ không còn tồn tại cùng với những lợi ích của nó đối với việc phát hiện TD. Cần phải bình thường hóa các yếu tố gây nhiễu như vậy (tham khảo Phần III-B) trước khi phát hiện TD.  Bài viết này   theo giấy phép CC 4.0. có sẵn trên arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Read My Stories

NetNeutrality

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

dài quá đọc không nổi

Boost your HackerNoon story @ $159.99! 🚀

Tìm hiểu những thiếu sót của Wehe trong việc phát hiện lưu lượng truy cập HTTPS

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

179 Stories To Learn About Reading

184 Stories To Learn About Psychology

145 Stories To Learn About Book

178 Stories To Learn About Essay

179 Stories To Learn About Reading

184 Stories To Learn About Psychology

145 Stories To Learn About Book

178 Stories To Learn About Essay

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps