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.
Trang 1THỬ 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 đó
Trang 2Cả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ư
Trang 3việ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
Trang 4đượ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
<A1,B1,pA1,pB1,1> xxxx
<A1,B1,pA1,pB1,2> yyyy
<A1,B1,pA1,pB1,3> zzzz
với conn_id
<A1, B1, pA1, pB1>
đườ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
Trang 5cặ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à <A1, B1, pA1, pB1>
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à
Trang 6Google 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
Trang 7Trụ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
Trang 8Hì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
Trang 9lị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”,
http://www.multipath-tcp.org
[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)
Trang 10ABSTRACT
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