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