Thử nghiệm, đánh giá giao thức truyền đa đường trên các thiết bị điện thoại thông minh sử dụng hệ điều hành Android

Thông tin khoa học công nghệ Tạp chí Nghiên cứu KH&CN quân sự, Số Đặc san An toàn Thông tin, 05 - 2017 157 THỬ NGHIỆM, ĐÁNH GIÁ GIAO THỨC TRUYỀN ĐA ĐƯỜNG TRÊN CÁC THIẾT BỊ ĐIỆN THOẠI THÔNG MINH SỬ DỤNG HỆ ĐIỀU HÀNH ANDROID Ngô Hải Linh*, Nguyễn Hoàng Long Tóm tắt: Gần đây, giao thức truyền đa đường (Multipath TCP – MPTCP) đã nhận được rất nhiều sự chú ý khi nó được chọn bởi tập đoàn Apple để hỗ trợ ứng dụng nhận dạng giọng nói Siri. MPTCP hỗ trợ sự kết nối liên tục giữa mạng di động và mạng wifi. Trong bài báo này, tác giả đề xuất một framework tự động hóa các hành động của người dùng trên các ứng dụng điện thoại thông minh Android để thực hiện các phép đo lưu lượng mạng, qua đó đưa ra những đánh giá về hiệu quả và lợi ích của giao thức truyền đa đường MPTCP. Từ khóa: Giao thức TCP, Giao thức truyền đa đường. 1. MỞ ĐẦU Multipath TCP [3, 4] là một giao thức mở rộng các đặc điểm từ giao thức TCP cho phép một kết nối phân chia thành nhiều đường khác nhau và dữ liệu được truyền trên các đường đồng thời. Multipath TCP hoạt động giống như TCP và mở rộng thêm các API nhằm cung cấp thêm chức năng điều khiển cho các ứng dụng multipath TCP. Việc truyền dữ liệu trên đa đường như thế sẽ cải thiện thông lượng truyền, có thể cân bằng tắc nghẽn trong các đường và cung cấp khả năng chuyển vùng tự nhiên trong mạng; Điều này rất hữu ích trong lĩnh vực an toàn thông tin khi có thể đảm bảo sự truyền nhận dữ liệu là liên tục. Trên một điện thoại thông minh, multipath TCP cho phép các ứng dụng đồng thời gửi và nhận dữ liệu qua cả WiFi và mạng di động bằng cách thiết lập một kết nối multipath TCP gồm nhiều subflow [3] mà mỗi subflow điều khiển một đường (mạng di động và wifi) [7, 5, 1, 2]; Sử dụng cửa sổ điều khiển tắc nghẽn để điều chỉnh tốc độ trên mỗi đường. 2. GIAO THỨC MULTIPATH TCP 2.1. Những mục tiêu đặt ra khi thiết kế MP TCP 2.1.1. Mục tiêu về chức năng Cải thiện thông lượng của hệ thống (throughput): MPTCP hoạt động trên cơ sở truyền trên nhiều đường truyền, tuy nhiên, một kết nối MPTCP sau khi được thiết lập phải có thông lượng lớn hơn thông lượng của một kết nối TCP đơn lẻ tốt nhất. Nói ngắn gọn, việc triển khai MPTCP phải có kết quả khả quan hơn là việc lựa chọn ra đường đi tốt nhất và gửi theo đường đi đó. Công nghệ thông tin N. H. Linh, N. H. Long, “Thử nghiệm, đánh giá giao thức hệ điều hành Android.” 158 Cải thiện khả năng phục hồi và chịu lỗi (resilience): MPTCP cho phép mọi đường dẫn phải có khả năng nhận và truyền gói tin như một kết nối TCP đơn lẻ bình thường. Nhờ có cơ chế này mà MPTCP vẫn đảm bảo được hệ thống hoạt động thông suốt khi có sự cố xảy ra trên một trong những đường dẫn đó. Ngoài ra, khả năng phục hồi của một kết nối MPTCP phải nhanh hơn bất kỳ một kết nối TCP đơn lẻ nào. Cân bằng tải và điều khiển tắc nghẽn: Dễ dàng nhận thấy việc truyền dẫn bằng nhiều con đường khác nhau góp một phần không hề nhỏ vào việc tránh tắc nghẽn trên đường truyền. Đương nhiên, việc điều khiển tắc nghẽn không chỉ đơn giản như thế, còn cần phải giải quyết rất nhiều vấn đề phát sinh khác như kiểm soát tắc nghẽn trên từng luồng con, hoặc ngăn ngừa thắt cổ chai ở hai bên đầu kết nối MPTCP Muốn làm được điều đó, MPTCP phải sử dụng các thuật toán kiểm soát tắc nghẽn riêng. 2.1.2. Mục tiêu về sự tương thích Ngoài các mục tiêu chức năng được liệt kê ở trên, giao thức TCP Multipath phải đáp ứng một số mục tiêu tương thích để hỗ trợ triển khai trên mạng Internet ngày nay. Tương thích với ứng dụng: Khả năng tương thích ứng dụng là sự ảnh hưởng của MPTCP tới các ứng dụng thông thường vẫn chạy trên nền TCP. Để đạt được điều này, đầu tiên MP TCP phải thiết kế theo cùng một mô hình dịch vụ như TCP : gửi theo thứ tự, tin cậy, theo byte. Hơn nữa, như đã đề cập, một kết nối MPTCP cung cấp cho các ứng dụng có thông lượng phải không thấp hơn một kết nối TCP đơn lẻ trên bất kỳ một trong đường nào có sẵn của nó. Tương thích với tầng mạng: Khái niệm tương thích với tầng mạng và tương thích với các thiết bị hoạt động ở tầng mạng nghĩa là Multipath TCP phải tương thích với mạng Internet ngày nay bao gồm khả năng truyền qua các middlebox sẵn có như: firewall, NAT, và các proxy nâng cao hiệu suất. Điều này yêu cầu phải xây dựng giao thức với các chức năng có thể dò và truyền qua các middlebox. Tương thích với những người dùng các giao thức mạng khác: Là hệ quả của sự tương thích về mạng và tương thích về ứng dụng, kiến trúc MPTCP phải cho phép việc tồn tại song song giữa các luồng MPTCP mới và các luồng TCP thông thường. Việc sử dụng nhiều đường truyền không có nghĩa là làm tổn hại đến những luồng TCP thông thường tại những liên kết thắt cổ chai. Các luồng MPTCP trên cùng một nút cổ chai phải chia sẻ băng thông với mỗi luồng khác tương tự như Thông tin khoa học công nghệ Tạp chí Nghiên cứu KH&CN quân sự, Số Đặc san An toàn Thông tin, 05 - 2017 159 việc chia sẻ xảy ra tại một nút thắt cổ chai của TCP thông thường. Ngoài ra, MPTCP phải có đặc điểm tự động thỏa thuận. Một máy chủ hỗ trợ Multipath phải có khả năng dò tìm thiết bị mới có hỗ trợ giao thức thế hệ sau và sử dụng nó nếu được, hay nói cách khác là tự động liên kết với giao thức đang tồn tại. 2.2. Mô hình phân chia chức năng của MP TCP Hình 1. Mô hình MPTCP. Nằm bên dưới tầng ứng dụng, mô hình MPTCP lần lượt quản lý các TCP subflow (luồng con) dưới nó. Để làm điều này, nó phải thực hiện các cơ chế sau đây: Quản lý đường dẫn (Path Management): Đây là cơ chế dùng để phát hiện và sử dụng nhiều đường dẫn giữa hai thiết bị. Để nhận biết các đường dẫn, MPTCP có thể dựa vào số lượng địa chỉ IP của hai đầu mỗi host. Sau khi đã thiết lập được các luồng con, MPTCP có thể tạo mới một kết nối hoặc gia nhập các luồng con này vào các kết nối đã có sẵn. Lập lịch (Scheduling): Cơ chế này chia dòng byte nhận được từ tầng ứng dụng thành các segment, sau đó sẽ truyền đi trên một trong những subflow sẵn có. Cũng giống như mô hình TCP, MPTCP cũng dùng cơ chế đánh số sequence để điều chỉnh thứ tự của các gói tin. Nếu bên gửi chịu trách nhiệm về việc phân phối các segment qua nhiều đường dẫn thế nào, thì bên nhận phải đảm bảo rằng có thể sắp xếp các segment nhận được theo đúng thứ tự ban đầu, sau đó ráp lại thành dữ liệu chuẩn rồi chuyển lên tầng ứng dụng. Sử dụng các luồng con (Subflow): Có thể hiểu mỗi subflow như là một đầu cho kết nối TCP đơn lẻ. Nhiệm vụ chính của subflow bên gửi là nhận các segment được lập lịch từ trước, kết nối TCP với các subflow bên nhận để truyền dữ liệu. Còn các subflow bên nhận sẽ nhận các segment này và chuyển cho bộ lập lịch của MPTCP để ráp dữ liệu lại. Chính vì MP TCP sử dụng giao thức TCP bên dưới (subflow) nên đảm bảo Application TCP Application IP MPTCP Subflow ( TCP ) Subflow ( TCP ) IP Công nghệ thông tin N. H. Linh, N. H. Long, “Thử nghiệm, đánh giá giao thức hệ điều hành Android.” 160 được tính tin cậy và đúng thứ tự vốn có của giao thức TCP. Việc mất gói hay truyền lại trên các kết nối TCP đơn lẻ thông qua subflow đều được thực hiện như một kết nối TCP bình thường. Kiểm soát tắc nghẽn: Bên cạnh việc điều khiển tắt nghẽn giữa các luồng con TCP với nhau, còn phải quan tâm đến vấn đề kiểm soát quản lý giữa kết nối MPTCP này với các kết nối TCP thông thường khác trong hệ thống mạng. Nói cách khác, các thiết bị được triển khai MPTCP phải đảm bảo không được gây ảnh hưởng, thậm chí chèn ép các kết nối TCP thông thường, làm cho các hệ thống cũ gặp bất lợi. 2.3. Các thành phần chính trong MPTCP MPTCP nằm hoàn toàn trong tầng vận chuyển, và có thể chia làm 2 thành phần chính. Đó là Path Manager (PM) và Multipath Scheduler (MPS). Có thể tham khảo mô hình phía dưới: Hình 2. Thành phần của MPTCP. Multipath Scheduler: Nhận biết đường dẫn dưới dạng các số. Nó chỉ nhìn một Multipath Scheduler ( MPS ) Path Manager ( PM ) Data segment subflow_id action xxxx yyyy zzzz với conn_id đường dẫn 1 3 có thể được sử dụng MPS gắn path id = 3 vào gói tin A1, B1, pA1,pB1 path1 path2 path3 zzzz  data plane control plane  Thông tin khoa học công nghệ Tạp chí Nghiên cứu KH&CN quân sự, Số Đặc san An toàn Thông tin, 05 - 2017 161 cặp địa chỉ trong suốt quá trình truyền dữ liệu, đó chính là cặp địa chỉ mà hai host dùng để thiết lập kết nối đầu tiên. Như ở hình trên, kết nối ban đầu được thiết lập trước nhất là giữa bên A (address A, port A1) và bên B (address B, port B1), nên MPS sẽ nhận biết kết nối này với connection ID là . Path Manager: có nhiệm vụ thăm dò phát hiện các đường dẫn khả dụng, ví dụ ba đường như hình vẽ. Sau đó, MP sẽ thông báo lên MPS rằng đang có ba đường có thể dùng để truyền dữ liệu. Quá trình phát hiện các đường dẫn, thêm đường dẫn vào kết nối chính. được thực hiện thông qua các gói tin multipath capable, add address, join connection Ở bên gửi, khi dữ liệu được đưa từ trên tầng ứng dụng xuống tầng vận chuyển (ở đây là MPTCP), thì MPS sẽ là người tiếp nhận dòng dữ liệu này. MPS sẽ chia nó ra thành các segment như giao thức TCP bình thường, sau đó lựa chọn điều phối truyền segment này đi bằng đường dẫn nào trong các đường dẫn khả dụng mà PM đã thông báo từ trước. Trong trường hợp này là đường dẫn có Path ID là 3 (path3). PM nhận được lệnh từ MPS sẽ chuyển segment này đi bằng path3 qua host đích không khác gì so với giao thức TCP bình thường. Khi các segment này qua tới bên nhận, nó sẽ được đưa lên MPS để tiến hành sắp xếp các gói tin cho đúng thứ tự. Sau đó được ráp lại thành dòng dữ liệu chuẩn ban đầu, và được đẩy lên tầng ứng dụng. Kết thúc quá trình. Thành phần kiểm soát tắc nghẽn và cân bằng tải tồn tại như một phần của MPS (tính toán, lập lịch các segment nên gửi với tốc độ nào, ở subflow nào...). 3. THỬ NGHIỆM Để thu thập được một số lượng lớn các phép đo lưu lượng mạng khi dùng MPTCP, tác giả đã dùng một framework tự động hoá các tương tác với các ứng dụng. Framework bao gồm hơn 4.000 dòng code và được chia thành hai phần riêng biệt: một để kiểm soát lưu lượng mạng trên smartphone và một để bắt chước các tương tác người dùng trên một ứng dụng. 3.1. Kịch bản thử nghiệm Kịch bản thử nghiệm của tác giả được chia thành hai loại: kịch bản upload và download. Thời gian tiến hành thử nghiệm chưa đến 120 giây. Upload: Đầu tiên tác giả sử dụng hai ứng dụng tương tác: Facebook và Messenger. Với ứng dụng Facebook, kịch bản là cập nhật tin mới, sau đó viết một dòng trạng thái mới, chụp và chia sẻ một hình ảnh mới kèm trạng thái và cuối cùng thực hiện chứng thực địa điểm kèm trạng thái. Với ứng dụng Messenger, kịch bản là gửi một tin nhắn văn bản, gửi một biểu tượng cảm xúc và cuối cùng sẽ gửi một hình ảnh. Sau đó, tác giả sử dụng hai ứng dụng lưu trữ đám mây: Dropbox và Công nghệ thông tin N. H. Linh, N. H. Long, “Thử nghiệm, đánh giá giao thức hệ điều hành Android.” 162 Google Drive. Đối với cả hai, kịch bản là tạo ra một tập tin mới chứa 20 MB dữ liệu hoàn toàn ngẫu nhiên và tải nó lên. Download: Đầu tiên, tác giả sử dụng trình duyệt Firefox để duyệt qua các trang chính của 12 trang web hàng đầu Alexa với một bộ nhớ cache trống. Ứng dụng thứ hai được sử dụng là Spotify (một ứng dụng cung cấp âm nhạc). Bài thử nghiệm này là nghe một bản nhạc mới (tính năng nghe ngẫu nhiên) trong 75 giây. Cuối cùng, tác giả xem xét hai ứng dụng video streaming phổ biến: Dailymotion và Youtube. Đối với cả hai ứng dụng, kịch bản là xem ba video khác nhau và mỗi video xem trong 25 giây. Tất cả video đều có độ phân giải HD. 3.2. Sử dụng MTCP trên điện thoại di động Trong bài thử nghiệm, tác giả sử dụng phiên bản 0.89v5 của MPTCP Linux kernel [6] trên thiết bị Samsung Galaxy Note N7000 chạy hệ điều hành Android 4.4.4. Tất cả ứng dụng trên smartphone sử dụng TCP tương tác với server được quản lý bởi các nhà phát triển ứng dụng, vì thế, rất khó khăn trong việc cài MTCP trên server của họ. Do đó, cần cấu hình smartphone sử dụng MTCP qua server SOCKS bằng việc sử dụng ứng dụng shadowsock. Ứng dụng cho phép bắt các packet qua điện thoại thông minh và SOCKS server. 3.3. Kết quả Dưới đây là kết quả sau khi thực hiện bắt tất cả gói tin được gửi từ điện thoại thông minh và SOCKS server (hơn 85.000 kết nối và 15GB dữ liệu). Hình dưới đây hiển thị các kết nối TCP được tạo bởi các ứng dụng trên điện thoại thông minh. Mỗi điểm tương ứng một kết nối cho cả lưu lượng upload và download. Hình 3. Các kết nối khi chỉ dùng wifi. Thông tin khoa học công nghệ Tạp chí Nghiên cứu KH&CN quân sự, Số Đặc san An toàn Thông tin, 05 - 2017 163 Trục ox chỉ thời gian kết nối. Trục oy thể hiện số bytes thay đổi mỗi kết nối. Firefox rõ ràng là ứng dụng sử dụng số lượng lớn các kết nối (63,9%), Dropbox (31,75%), Youtube (29,7%), Drive (19,9%), Spotify (4,96%) và Dailymotion (9,6%) là các ứng dụng có sự chuyển đổi dữ liệu lớn nhất. Trong khi đó, Facebook là ứng dụng có kết nối TCP dài nhất và không thay đổi dữ liệu quá nhiều. Qua đó, tác giả phân chia các kết nối làm 3 loại: trong thời gian ngắn và chiếm 75% dung lượng, trong thời gian dài và chiếm 98,5% dung lượng, trong thời gian dài nhưng tốn ít dung lượng (chiếm 18%). Các hình dưới đây hiển thị các kết nối MPTCP được tạo bởi các ứng dụng trên điện thoại thông minh. Hình 4. Các kết nối khi cài đặt mạng kết nối mặc định là mạng wifi. Hình 4 cho thấy 92,4% chỉ sử dụng kết nối wifi nhưng những kết nối này chỉ chiếm 1,1% toàn bộ dữ liệu (có thể giải thích tại sao MPTCP lại không sử dụng mạng di động cho những kết nối này). Thứ nhất, mạng kết nối mặc định là wifi, khi một ứng dụng khởi tạo kết nối MPTCP gửi gói tin SYN qua mạng kết nối mặc định ở đây chính là wifi. Vậy, nếu kết nối MPTCP ngắn và có sự chuyển đổi dữ liệu ít (vài KB) thì dữ liệu chủ yếu được truyền qua wifi. Hơn nữa, RTT [8](round- trip-time là khoảng thời gian tính từ lúc client bắt đầu gửi request tới lúc nó nhận gói dữ liệu đầu tiên trả về, không bao gồm thời gian nhận đầy đủ dữ liệu) qua wifi bé hơn qua mạng di động. Công nghệ thông tin N. H. Linh, N. H. Long, “Thử nghiệm, đánh giá giao thức hệ điều hành Android.” 164 Hình 5 cho thấy các kết nối ngắn chiếm 53,22% (mũi tên số 1). Dường như ngay cả khi mạng kết nối mặc định là mạng di động thì các kết nối chủ yếu vẫn sử Hình 5. Các kết nối khi cài đặt kết nối mặc định là mạng di động dụng wifi. Điều này xảy ra với các kết nối có tốc độ đẩy dữ liệu chậm. Nếu kết nối kéo dài hơn 2 RTT, MPTCP mới có đủ thời gian thiết lập subflow thứ 2. Do vậy, MPTCP sẽ lựa chọn kết nối với RTT thấp (chiếm 82,74%) và RTT của wifi thì ít hơn của mạng di động. Điều này giải thích tại sao phần dưới của hình 5 (mũi tên số 2) là tập hợp các kết nối của Firefox với sự chuyển đổi dữ liệu nhỏ hơn 10KB chủ yếu sử dụng mạng wifi. Bởi vì khi firefox khởi tạo kết nối, quá trình bắt tay bắt đầu, các command SOCKS sẽ được gửi tới máy chủ SOCKS. Các gói tin này sẽ được gửi qua mạng di động và Firefox sẽ không gửi ngay dữ liệu qua kết nối đã được thiết lập này nên MPTCP sẽ có đủ thời gian để tạo ra subflow thứ 2 và đo RTT của nó. Khi Firefox bắt đầu truyền dữ liệu thì trình lên lịch trên MPTCP sẽ sử dụng wifi (do RTT bé hơn) và không có dữ liệu nào (trừ command SOCK ban đầu) được gửi qua mạng di động. Khi ứng dụng đẩy nhiều dữ liệu hơn qua kết nối MPTCP, sự phân bố lưu lượng giữa mạng di động và WiFi cũng phụ thuộc vào sự tiến triển của các cửa sổ tắc nghẽn của hai subflow. Nếu ứng dụng đẩy dữ liệu ở tốc độ thấp thì trình lập Thông tin khoa học công nghệ Tạp chí Nghiên cứu KH&CN quân sự, Số Đặc san An toàn Thông tin, 05 - 2017 165 lịch gói tin sẽ gửi dữ liệu qua mạng có RTT thấp nhất (WiFi trong trường hợp dùng điện thoại thông minh ở trên). Tuy nhiên, điều này cũng không chính xác hoàn toàn. Nếu một gói tin bị mất (do lỗi mạng) thì cửa sổ tắc nghẽn sẽ bị giảm và dữ liệu tiếp theo có thể được gửi qua mạng khác. Nếu ứng dụng đẩy dữ liệu ở tốc độ cao hơn thì cửa sổ tắc nghẽn trên mạng có RTT bé nhất không đủ lớn và bộ lập lịch gói tin sẽ gửi dữ liệu qua subflow thứ hai. 4. KẾT LUẬN Trong bài báo này, tác giả đã đề xuất và thực hiện một bài thử nghiệm thu thập lưu lượng mạng được tạo ra bởi các ứng dụng trên điện thoại thông minh Android. Kết quả thu thập được sử dụng để đánh giá sự tương tác giữa các ứng dụng với Multipath TCP. Kết quả ban đầu cho thấy các ứng dụng trên điện thoại thông minh làm việc tốt với Multipath TCP. Tuy nhiên, Multipath TCP sử dụng quá nhiều subflow cho các kết nối ngắn (short connection) và việc cài đặt mạng kết nối mặc định cũng có tác động đến việc phân phối lưu lượng truy cập. Kết quả này giúp các nhà nghiên cứu đánh giá và tác động, đề xuất sửa đổi Multipath TCP trên các ứng dụng thực. TÀI LIỆU THAM KHẢO [1]. Y.-C. Chen, “A Measurement-based Study ofMultipath TCP Performance over Wireless Networks”, IMC’13 (2013). [2]. S. Deng , “WiFi, LTE, or both?: Measuring multi-homed wireless internet performance”, IMC ’14 (2014), ACM, pp. 181–194. [3]. A. Ford, “TCP Extensions for Multipath Operation with Multiple Addresses”, RFC 6824, 2013. [4]. K. Lee, “Mobile data offloading: How much can wifi deliver?”, SIGCOMM ’10 (2010). [5]. Y.-s. Lim, “How green is Multipath TCP for mobile devices?”, AllThingsCellular ’14 (2014), ACM. [6]. C. Paasch, Barre, S., “Multipath TCP in the Linux kernel”, [7]. C. Paasch, “Exploring Mobile/WiFi Handover with Multipath TCP”, ACM SIGCOMM CellNet workshop (2012), pp. 31–36. [8]. C. Paasch, “Experimental evaluation of Multipath TCP schedulers”, CSWS ’14 (2014). Công nghệ thông tin N. H. Linh, N. H. Long, “Thử nghiệm, đánh giá giao thức hệ điều hành Android.” 166 ABSTRACT EVALUATING, TESTING MULTIPATH TCP ON THE ANDROID APPLICATIONS Recently, multipath transport control protocol (Multipath TCP) received a lot of attention when it was selected by Apple Corporation to support its voice recognition (Siri) application. MPTCP supports seamless connectivity between cellular and wifi networks. In this paper, author propose a framework that automates user action on Android smartphone application to perform network measurements, thereby providing an assessment of the effectiveness and benefits of Multipath TCP Protocol. Keywords: TCP Protokol, Multipath TCP Protocol. Nhận bài ngày 22 tháng 02 năm 2017 Hoàn thiện ngày 10 tháng 4 năm 2017 Chấp nhận đăng ngày 01 tháng 5 năm 2017 Địa chỉ: Trung tâm 586, Cục CNTT. *Email: sleeper326@yahoo.com.