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.