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

10 6 0
  • Loading ...
1/10 trang

Thông tin tài liệu

Ngày đăng: 11/02/2020, 17:02

Bài viết đề 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. Thông tin khoa học công nghệ 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 Hồng Long Tóm tắt: Gần đây, giao thức truyền đa đường (Multipath TCP – MPTCP) nhận nhiều ý chọn tập đoàn Apple để hỗ trợ ứng dụng nhận dạng giọng nói Siri MPTCP hỗ trợ kết nối liên tục mạng di động mạng wifi Trong báo này, tác giả đề xuất framework tự động hóa hành động người dùng ứng dụng điện thoại thông minh Android để thực phép đo lưu lượng mạng, qua đưa đánh giá hiệu lợi ích giao thức truyền đa đường MPTCP Từ khóa: Giao thức TCP, Giao thức truyền đa đường MỞ ĐẦU Multipath TCP [3, 4] giao thức mở rộng đặc điểm từ giao thức TCP cho phép kết nối phân chia thành nhiều đường khác liệu truyền đường đồng thời Multipath TCP hoạt động giống TCP mở rộng thêm API nhằm cung cấp thêm chức điều khiển cho ứng dụng multipath TCP Việc truyền liệu đa đường cải thiện thông lượng truyền, cân tắc nghẽn đường cung cấp khả chuyển vùng tự nhiên mạng; Điều hữu ích lĩnh vực an tồn thơng tin đảm bảo truyền nhận liệu liên tục Trên điện thoại thông minh, multipath TCP cho phép ứng dụng đồng thời gửi nhận liệu qua WiFi mạng di động cách thiết lập kết nối multipath TCP gồm nhiều subflow [3] mà subflow điều khiển đường (mạng di động 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 độ đường GIAO THỨC MULTIPATH TCP 2.1 Những mục tiêu đặt thiết kế MP TCP 2.1.1 Mục tiêu chức Cải thiện thông lượng hệ thống (throughput): MPTCP hoạt động sở truyền nhiều đường truyền, nhiên, kết nối MPTCP sau thiết lập phải có thơng lượng lớn thơng lượng kết nối TCP đơn lẻ tốt Nói ngắn gọn, việc triển khai MPTCP phải có kết khả quan việc lựa chọn đường tốt gửi theo đường Tạp chí Nghiên cứu KH&CN qn sự, Số Đặc san An tồn Thơng tin, 05 - 2017 157 Công nghệ thông tin Cải thiện khả phục hồi chịu lỗi (resilience): MPTCP cho phép đường dẫn phải có khả nhận truyền gói tin kết nối TCP đơn lẻ bình thường Nhờ có chế mà MPTCP đảm bảo hệ thống hoạt động thơng suốt có cố xảy đường dẫn Ngồi ra, khả phục hồi kết nối MPTCP phải nhanh kết nối TCP đơn lẻ Cân tải điều khiển tắc nghẽn: Dễ dàng nhận thấy việc truyền dẫn nhiều đường khác góp phần khơng nhỏ vào việc tránh tắc nghẽn đường truyền Đương nhiên, việc điều khiển tắc nghẽn không đơn giản thế, cần phải giải nhiều vấn đề phát sinh khác kiểm soát tắc nghẽn luồng con, ngăn ngừa thắt cổ chai hai bên đầu kết nối MPTCP… Muốn làm điều đó, MPTCP phải sử dụng thuật tốn kiểm sốt tắc nghẽn riêng 2.1.2 Mục tiêu tương thích Ngoài mục tiêu chức liệt kê trên, giao thức TCP Multipath phải đáp ứng số mục tiêu tương thích để hỗ trợ triển khai mạng Internet ngày Tương thích với ứng dụng: Khả tương thích ứng dụng ảnh hưởng MPTCP tới ứng dụng thông thường chạy TCP Để đạt điều này, MP TCP phải thiết kế theo mơ hình dịch vụ TCP : gửi theo thứ tự, tin cậy, theo byte Hơn nữa, đề cập, kết nối MPTCP cung cấp cho ứng dụng có thơng lượng phải không thấp kết nối TCP đơn lẻ đường có sẵ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 tương thích với thiết bị hoạt động tầng mạng nghĩa Multipath TCP phải tương thích với mạng Internet ngày bao gồm khả truyền qua middlebox sẵn có như: firewall, NAT, proxy nâng cao hiệu suất Điều yêu cầu phải xây dựng giao thức với chức dò truyền qua middlebox Tương thích với người dùng giao thức mạng khác: Là hệ tương thích mạng tương thích ứng dụng, kiến trúc MPTCP phải cho phép việc tồn song song luồng MPTCP luồng TCP thông thường Việc sử dụng nhiều đường truyền khơng có nghĩa làm tổn hại đến luồng TCP thông thường liên kết thắt cổ chai Các luồng MPTCP nút cổ chai phải chia sẻ băng thông với luồng khác tương tự 158 N H Linh, N H Long, “Thử nghiệm, đánh giá giao thức… hệ điều hành Android.” Thông tin khoa học công nghệ việc chia sẻ xảy nút thắt cổ chai TCP thơng thường Ngồ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ả dò tìm thiết bị có hỗ trợ giao thức hệ sau sử dụng được, hay nói cách khác tự động liên kết với giao thức tồn 2.2 Mơ hình phân chia chức MP TCP Application Application TCP MPTCP Subflow ( TCP ) IP Subflow ( TCP ) IP Hình Mơ hình MPTCP Nằm bên tầng ứng dụng, mơ hình MPTCP quản lý TCP subflow (luồng con) Để làm điều này, phải thực chế sau đây: Quản lý đường dẫn (Path Management): Đây chế dùng để phát sử dụng nhiều đường dẫn hai thiết bị Để nhận biết đường dẫn, MPTCP dựa vào số lượng địa IP hai đầu host Sau thiết lập luồng con, MPTCP tạo kết nối gia nhập luồng vào kết nối có sẵn Lập lịch (Scheduling): Cơ chế chia dòng byte nhận từ tầng ứng dụng thành segment, sau truyền subflow sẵn có Cũng giống mơ hình TCP, MPTCP dùng chế đánh số sequence để điều chỉnh thứ tự gói tin Nếu bên gửi chịu trách nhiệm việc phân phối segment qua nhiều đường dẫn nào, bên nhận phải đảm bảo xếp segment nhận theo thứ tự ban đầu, sau ráp lại thành liệu chuẩn chuyển lên tầng ứng dụng Sử dụng luồng (Subflow): Có thể hiểu subflow đầu cho kết nối TCP đơn lẻ Nhiệm vụ subflow bên gửi nhận segment lập lịch từ trước, kết nối TCP với subflow bên nhận để truyền liệu Còn subflow bên nhận nhận segment chuyển cho lập lịch MPTCP để ráp liệu lại Chính MP TCP sử dụng giao thức TCP bên (subflow) nên đảm bảo Tạp chí Nghiên cứu KH&CN quân sự, Số Đặc san An toàn Thông tin, 05 - 2017 159 Công nghệ thông tin tính tin cậy thứ tự vốn có giao thức TCP Việc gói hay truyền lại kết nối TCP đơn lẻ thông qua subflow thực 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 luồng TCP với nhau, phải quan tâm đến vấn đề kiểm soát quản lý kết nối MPTCP với kết nối TCP thơng thường khác hệ thống mạng Nói cách khác, thiết bị triển khai MPTCP phải đảm bảo khơng gây ảnh hưởng, chí chèn ép kết nối TCP thông thường, làm cho hệ thống cũ gặp bất lợi 2.3 Các thành phần MPTCP MPTCP nằm hoàn toàn tầng vận chuyển, chia làm thành phần Đó Path Manager (PM) Multipath Scheduler (MPS) Có thể tham khảo mơ hình phía dưới: control plane   data plane Multipath Scheduler ( MPS ) với conn_id đường dẫn  sử dụng A1, B1, pA1,pB1 Data segment Path Manager ( PM ) MPS gắn path id = vào gói tin zzzz subflow_id action xxxx yyyy zzzz path1 path2 path3 Hình Thành phần MPTCP Multipath Scheduler: Nhận biết đường dẫn dạng số Nó nhìn 160 N H Linh, N H Long, “Thử nghiệm, đánh giá giao thức… hệ điều hành Android.” Thông tin khoa học công nghệ cặp địa suốt q trình truyền liệu, cặp địa mà hai host dùng để thiết lập kết nối Như hình trên, kết nối ban đầu thiết lập trước bên A (address A, port A1) bên B (address B, port B1), nên MPS nhận biết kết nối với connection ID Path Manager: có nhiệm vụ thăm dò phát đường dẫn khả dụng, ví dụ ba đường hình vẽ Sau đó, MP thơng báo lên MPS có ba đường dùng để truyền liệu Q trình phát đường dẫn, thêm đường dẫn vào kết nối chính… thực thơng qua gói tin multipath capable, add address, join connection… Ở bên gửi, liệu đưa từ tầng ứng dụng xuống tầng vận chuyển (ở MPTCP), MPS người tiếp nhận dòng liệu MPS chia thành segment giao thức TCP bình thường, sau lựa chọn điều phối truyền segment đường dẫn đường dẫn khả dụng mà PM thông báo từ trước Trong trường hợp đường dẫn có Path ID (path3) PM nhận lệnh từ MPS chuyển segment path3 qua host đích khơng khác so với giao thức TCP bình thường Khi segment qua tới bên nhận, đưa lên MPS để tiến hành xếp gói tin cho thứ tự Sau ráp lại thành dòng liệu chuẩn ban đầu, đẩy lên tầng ứng dụng Kết thúc trình Thành phần kiểm soát tắc nghẽn cân tải tồn phần MPS (tính tốn, lập lịch segment nên gửi với tốc độ nào, subflow ) THỬ NGHIỆM Để thu thập số lượng lớn phép đo lưu lượng mạng dùng MPTCP, tác giả dùng framework tự động hoá tương tác với ứng dụng Framework bao gồm 4.000 dòng code chia thành hai phần riêng biệt: để kiểm soát lưu lượng mạng smartphone để bắt chước tương tác người dùng ứng dụng 3.1 Kịch thử nghiệm Kịch thử nghiệm tác giả chia thành hai loại: kịch upload 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 Messenger Với ứng dụng Facebook, kịch cập nhật tin mới, sau viết dòng trạng thái mới, chụp chia sẻ hình ảnh kèm trạng thái cuối thực chứng thực địa điểm kèm trạng thái Với ứng dụng Messenger, kịch gửi tin nhắn văn bản, gửi biểu tượng cảm xúc cuối gửi hình ảnh Sau đó, tác giả sử dụng hai ứng dụng lưu trữ đám mây: Dropbox Tạp chí Nghiên cứu KH&CN qn sự, Số Đặc san An tồn Thơng tin, 05 - 2017 161 Công nghệ thông tin Google Drive Đối với hai, kịch tạo tập tin chứa 20 MB liệu hoàn toàn ngẫu nhiên tải lên Download: Đầu tiên, tác giả sử dụng trình duyệt Firefox để duyệt qua trang 12 trang web hàng đầu Alexa với nhớ cache trống Ứng dụng thứ hai sử dụng Spotify (một ứng dụng cung cấp âm nhạc) Bài thử nghiệm nghe nhạc (tính nghe ngẫu nhiên) 75 giây Cuối cùng, tác giả xem xét hai ứng dụng video streaming phổ biến: Dailymotion Youtube Đối với hai ứng dụng, kịch xem ba video khác video xem 25 giây Tất video có độ phân giải HD 3.2 Sử dụng MTCP điện thoại di động Trong thử nghiệm, tác giả sử dụng phiên 0.89v5 MPTCP Linux kernel [6] thiết bị Samsung Galaxy Note N7000 chạy hệ điều hành Android 4.4.4 Tất ứng dụng smartphone sử dụng TCP tương tác với server quản lý nhà phát triển ứng dụng, thế, khó khăn việc cài MTCP server họ Do đó, cần cấu hình smartphone sử dụng MTCP qua server SOCKS việc sử dụng ứng dụng shadowsock Ứng dụng cho phép bắt packet qua điện thoại thông minh SOCKS server 3.3 Kết Dưới kết sau thực bắt tất gói tin gửi từ điện thoại thông minh SOCKS server (hơn 85.000 kết nối 15GB liệu) Hình hiển thị kết nối TCP tạo ứng dụng điện thoại thông minh Mỗi điểm tương ứng kết nối cho lưu lượng upload download Hình Các kết nối dùng wifi 162 N H Linh, N H Long, “Thử nghiệm, đánh giá giao thức… hệ điều hành Android.” Thông tin khoa học công nghệ Trục ox thời gian kết nối Trục oy thể số bytes thay đổi kết nối Firefox rõ ràng ứng dụng sử dụng số lượng lớn kết nối (63,9%), Dropbox (31,75%), Youtube (29,7%), Drive (19,9%), Spotify (4,96%) Dailymotion (9,6%) ứng dụng có chuyển đổi liệu lớn Trong đó, Facebook ứng dụng có kết nối TCP dài không thay đổi liệu nhiều Qua đó, tác giả phân chia kết nối làm loại: thời gian ngắn chiếm 75% dung lượng, thời gian dài chiếm 98,5% dung lượng, thời gian dài tốn dung lượng (chiếm 18%) Các hình hiển thị kết nối MPTCP tạo ứng dụng điện thoại thơng minh Hình Các kết nối cài đặt mạng kết nối mặc định mạng wifi Hình cho thấy 92,4% sử dụng kết nối wifi kết nối chiếm 1,1% toàn liệu (có thể giải thích MPTCP lại khơng sử dụng mạng di động cho kết nối này) Thứ nhất, mạng kết nối mặc định wifi, ứ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 wifi Vậy, kết nối MPTCP ngắn có chuyển đổi liệu (vài KB) liệu chủ yếu truyền qua wifi Hơn nữa, RTT [8](roundtrip-time khoảng thời gian tính từ lúc client bắt đầu gửi request tới lúc nhận gói liệu trả về, không bao gồm thời gian nhận đầy đủ liệu) qua wifi bé qua mạng di động Tạp chí Nghiên cứu KH&CN quân sự, Số Đặc san An tồn Thơng tin, 05 - 2017 163 Cơng nghệ thơng tin Hình cho thấy kết nối ngắn chiếm 53,22% (mũi tên số 1) Dường mạng kết nối mặc định mạng di động kết nối chủ yếu sử Hình Các kết nối cài đặt kết nối mặc định mạng di động dụng wifi Điều xảy với kết nối có tốc độ đẩy liệu chậm Nếu kết nối kéo dài RTT, MPTCP có đủ thời gian thiết lập subflow thứ Do vậy, MPTCP lựa chọn kết nối với RTT thấp (chiếm 82,74%) RTT wifi mạng di động Điều giải thích phần hình (mũi tên số 2) tập hợp kết nối Firefox với chuyển đổi liệu nhỏ 10KB chủ yếu sử dụng mạng wifi Bởi firefox khởi tạo kết nối, trình bắt tay bắt đầu, command SOCKS gửi tới máy chủ SOCKS Các gói tin gửi qua mạng di động Firefox không gửi liệu qua kết nối thiết lập nên MPTCP có đủ thời gian để tạo subflow thứ đo RTT Khi Firefox bắt đầu truyền liệu trình lên lịch MPTCP sử dụng wifi (do RTT bé hơn) khơng có liệu (trừ command SOCK ban đầu) gửi qua mạng di động Khi ứng dụng đẩy nhiều liệu qua kết nối MPTCP, phân bố lưu lượng mạng di động WiFi phụ thuộc vào tiến triển cửa sổ tắc nghẽn hai subflow Nếu ứng dụng đẩy liệu tốc độ thấp trình lập 164 N H Linh, N H Long, “Thử nghiệm, đánh giá giao thức… hệ điều hành Android.” Thơng tin khoa học cơng nghệ lịch gói tin gửi liệu qua mạng có RTT thấp (WiFi trường hợp dùng điện thoại thông minh trên) Tuy nhiên, điều khơng xác hồn tồn Nếu gói tin bị (do lỗi mạng) cửa sổ tắc nghẽn bị giảm liệu gửi qua mạng khác Nếu ứng dụng đẩy liệu tốc độ cao cửa sổ tắc nghẽn mạng có RTT bé khơng đủ lớn lập lịch gói tin gửi liệu qua subflow thứ hai KẾT LUẬN Trong báo này, tác giả đề xuất thực thử nghiệm thu thập lưu lượng mạng tạo ứng dụng điện thoại thông minh Android Kết thu thập sử dụng để đánh giá tương tác ứng dụng với Multipath TCP Kết ban đầu cho thấy ứng dụng đ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 nhiều subflow cho kết nối ngắn (short connection) việc cài đặt mạng kết nối mặc định có tác động đến việc phân phối lưu lượng truy cập Kết giúp nhà nghiên cứu đánh giá tác động, đề xuất sửa đổi Multipath TCP ứ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 http://www.multipath-tcp.org 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) Tạp chí Nghiên cứu KH&CN qn sự, Số Đặc san An tồn Thơng tin, 05 - 2017 165 Công nghệ thông tin 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 ngày 22 tháng 02 năm 2017 Hoàn thiện ngày 10 tháng năm 2017 Chấp nhận đăng ngày 01 tháng năm 2017 Địa chỉ: Trung tâm 586, Cục CNTT * 166 Email: sleeper326@yahoo.com N H Linh, N H Long, “Thử nghiệm, đánh giá giao thức… hệ điều hành Android.” ... Thử nghiệm, đánh giá giao thức hệ điều hành Android. ” Thông tin khoa học cơng nghệ lịch gói tin gửi liệu qua mạng có RTT thấp (WiFi trường hợp dùng điện thoại thông minh trên) Tuy nhiên, điều. .. thực thử nghiệm thu thập lưu lượng mạng tạo ứng dụng điện thoại thông minh Android Kết thu thập sử dụng để đánh giá tương tác ứng dụng với Multipath TCP Kết ban đầu cho thấy ứng dụng điện thoại thông. .. Long, Thử nghiệm, đánh giá giao thức hệ điều hành Android. ” Thông tin khoa học công nghệ Trục ox thời gian kết nối Trục oy thể số bytes thay đổi kết nối Firefox rõ ràng ứng dụng sử dụng số
- Xem thêm -

Xem thêm: 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ử 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

Gợi ý tài liệu liên quan cho bạn