Khi phân tích các thị trường, tự động hóa công việc với mạng xã hội hoặc thu thập dữ liệu qua API, việc chọn chiến lược gửi yêu cầu đúng cách là cực kỳ quan trọng. Cấu hình sai dẫn đến việc bị chặn IP, captcha và lãng phí thời gian. Trong hướng dẫn này, chúng ta sẽ phân tích khi nào nên sử dụng các yêu cầu song song để đạt tốc độ tối đa và khi nào nên sử dụng yêu cầu tuần tự để đảm bảo an toàn.
Sự khác biệt giữa các yêu cầu song song và tuần tự
Các yêu cầu tuần tự là khi script hoặc chương trình của bạn gửi yêu cầu một cách lần lượt: chờ đợi phản hồi từ yêu cầu đầu tiên, chỉ sau đó mới gửi yêu cầu thứ hai. Điều này chậm nhưng an toàn và trông tự nhiên nhất cho trang web mục tiêu.
Các yêu cầu song song là khi nhiều yêu cầu (5, 10, 50 hoặc thậm chí hàng trăm) được gửi đồng thời mà không chờ đợi phản hồi từ các yêu cầu trước đó. Điều này nhanh hơn nhiều, nhưng tạo ra tải cho máy chủ và có thể gây nghi ngờ cho các hệ thống chống gian lận.
Hãy tưởng tượng việc phân tích giá của 10.000 sản phẩm trên Wildberries. Nếu thực hiện tuần tự với độ trễ 2 giây giữa các yêu cầu — sẽ mất 20.000 giây hoặc 5,5 giờ. Nếu khởi động 20 luồng song song — chỉ mất 16 phút. Sự khác biệt là rõ ràng, nhưng có những điểm cần lưu ý.
Quan trọng: Các yêu cầu song song không có nghĩa là “gửi 1000 yêu cầu cùng một lúc”. Đây là sự song song có kiểm soát — ví dụ, 10-50 luồng hoạt động, mỗi luồng có độ trễ. Nếu không kiểm soát, bạn sẽ ngay lập tức bị cấm.
So sánh các phương pháp
| Tham số | Tuần tự | Song song |
|---|---|---|
| Tốc độ | Chậm (1 yêu cầu tại một thời điểm) | Nhanh (10-100+ đồng thời) |
| Rủi ro bị chặn | Thấp | Trung bình-cao |
| Tải cho proxy | Tối thiểu | Cao |
| Độ phức tạp trong cấu hình | Đơn giản | Cần có kinh nghiệm |
| Tiêu thụ bộ nhớ | Thấp | Cao |
| Xử lý lỗi | Dễ theo dõi hơn | Khó khăn hơn trong việc ghi log |
Khi nào sử dụng các yêu cầu song song
Các yêu cầu song song là lựa chọn khi tốc độ là yếu tố quan trọng và khối lượng dữ liệu lớn. Nhưng điều quan trọng là phải hiểu rằng điều này chỉ hoạt động khi cấu hình proxy đúng và kiểm soát tải.
Các kịch bản lý tưởng cho các yêu cầu song song
1. Phân tích các thị trường với danh mục lớn
Nếu bạn cần thu thập giá từ 50.000 sản phẩm trên Wildberries hoặc Ozon, phân tích tuần tự sẽ mất hàng ngày. Với 20-30 luồng song song và proxy trung tâm dữ liệu, nhiệm vụ sẽ hoàn thành trong vài giờ.
Cấu hình: 20-30 luồng, mỗi luồng với IP riêng biệt, độ trễ 1-3 giây giữa các yêu cầu trong luồng. Thay đổi IP sau mỗi 100-200 yêu cầu.
2. Thu thập dữ liệu từ các API công khai
Nhiều API (ví dụ: dịch vụ thời tiết, cơ sở dữ liệu công ty, dịch vụ định vị địa lý) có giới hạn yêu cầu từ một IP: 100-1000 mỗi ngày. Các yêu cầu song song qua một nhóm proxy cho phép vượt qua các giới hạn này.
Ví dụ: Bạn cần thu thập dữ liệu về 10.000 công ty qua API. Giới hạn — 500 yêu cầu/ngày từ IP. Sử dụng 20 proxy song song = 10.000 yêu cầu trong một ngày thay vì 20 ngày.
3. Kiểm tra tính khả dụng của tài nguyên
Nếu bạn đang kiểm tra tính khả dụng của các trang web, hoạt động của các gương hoặc giám sát trạng thái của các máy chủ — các yêu cầu song song tiết kiệm hàng giờ. Ở đây không cần mô phỏng hành vi của con người, chỉ cần tốc độ là quan trọng.
4. Kiểm tra hàng loạt proxy
Khi mua các nhóm proxy lớn (1000+ IP), cần nhanh chóng kiểm tra tính khả dụng, tốc độ, địa điểm địa lý của chúng. Kiểm tra tuần tự sẽ mất hàng giờ, kiểm tra song song chỉ mất vài phút.
Chú ý: Các yêu cầu song song KHÔNG phù hợp cho việc làm việc với các nền tảng bảo mật (Facebook Ads, Instagram API, Google Ads), nơi cần mô phỏng hành vi của người dùng thực. Ở đó, hãy sử dụng các yêu cầu tuần tự.
Các yêu cầu chính cho các yêu cầu song song
- Một nhóm proxy lớn (tối thiểu 10-20 IP, tốt hơn là 50-100+)
- Tự động thay đổi IP khi có lỗi
- Kiểm soát số lượng luồng đồng thời (không quá 50-100)
- Độ trễ giữa các yêu cầu ngay cả trong các luồng (0.5-2 giây)
- Ghi log lỗi để phân tích nguyên nhân bị chặn
- Hệ thống retry (thử lại) khi có thời gian chờ
Khi nào sử dụng các yêu cầu tuần tự
Các yêu cầu tuần tự là lựa chọn an toàn và đáng tin cậy hơn so với tốc độ. Chúng mô phỏng hành vi của người dùng thực và giảm thiểu rủi ro bị chặn trên các nền tảng bảo mật.
Các kịch bản bắt buộc cho các yêu cầu tuần tự
1. Làm việc với các tài khoản quảng cáo
Facebook Ads, TikTok Ads, Google Ads không chỉ theo dõi IP mà còn theo dõi các mẫu hành vi. Các yêu cầu song song từ một tài khoản sẽ ngay lập tức gây nghi ngờ. Một tài khoản = một luồng = các hành động tuần tự với độ trễ 5-15 giây.
Ví dụ: Bạn quản lý 20 tài khoản quảng cáo Facebook qua trình duyệt chống phát hiện Dolphin Anty. Mỗi tài khoản hoạt động trong một hồ sơ riêng biệt với proxy di động, các hành động diễn ra một cách tuần tự: đăng nhập → kiểm tra thống kê → điều chỉnh giá thầu → đăng xuất. Độ trễ 7-12 giây giữa các hành động.
2. Tự động hóa hành động trên mạng xã hội
Instagram, TikTok, VK có giới hạn nghiêm ngặt về hành động: thích, theo dõi, bình luận. Việc vượt quá giới hạn hoặc hành động quá nhanh = shadowban hoặc bị chặn hoàn toàn. Chỉ có các yêu cầu tuần tự với độ trễ ngẫu nhiên từ 20-60 giây.
Cấu hình cho Instagram: Một tài khoản tối đa 60 lượt thích/giờ. Đây là 1 lượt thích mỗi phút với độ trễ 45-75 giây (ngẫu nhiên hóa là rất quan trọng!). Sử dụng proxy riêng cho mỗi tài khoản.
3. Xác thực và làm việc với các tài khoản cá nhân
Bất kỳ hành động nào yêu cầu đăng nhập vào tài khoản (dịch vụ email, ngân hàng, thị trường như người bán) phải được thực hiện tuần tự. Các nỗ lực đăng nhập song song từ các IP khác nhau vào một tài khoản — là con đường dẫn đến việc bị chặn.
4. Các trang web với bảo vệ chống bot nghiêm ngặt
Các nền tảng với Cloudflare, Akamai, PerimeterX không chỉ phân tích tần suất yêu cầu mà còn cả các mẫu của chúng. Nếu từ một IP hoặc User-Agent nhận được 10 yêu cầu đồng thời — đó là dấu hiệu rõ ràng của bot. Các yêu cầu tuần tự với độ trễ từ 3-10 giây trông tự nhiên hơn.
5. Khối lượng dữ liệu nhỏ
Nếu bạn cần phân tích 50-100 trang, sự khác biệt về thời gian giữa phân tích tuần tự và song song là không đáng kể (5 phút so với 1 phút). Nhưng phương pháp tuần tự đảm bảo không gặp vấn đề.
Độ trễ đúng cho các yêu cầu tuần tự
| Nền tảng/nhiệm vụ | Độ trễ giữa các yêu cầu | Ngẫu nhiên hóa |
|---|---|---|
| Facebook Ads (hành động trong tài khoản) | 7-15 giây | ±30% |
| Instagram (thích, theo dõi) | 45-90 giây | ±40% |
| TikTok (xem, thích) | 30-60 giây | ±35% |
| Google Ads (yêu cầu API) | 5-10 giây | ±25% |
| Phân tích với Cloudflare | 3-7 giây | ±30% |
| Các trang web thông thường không có bảo vệ | 1-3 giây | ±20% |
Mẹo: Ngẫu nhiên hóa độ trễ là rất quan trọng. Nếu script của bạn thực hiện yêu cầu chính xác mỗi 5.00 giây — đó là mẫu của bot. Sử dụng ngẫu nhiên từ 4 đến 7 giây để mô phỏng hành vi của con người.
Rủi ro bị chặn với các phương pháp khác nhau
Hiểu rõ các rủi ro giúp bạn chọn chiến lược đúng và thiết lập bảo vệ. Việc bị chặn không chỉ xảy ra do tần suất yêu cầu mà còn do các mẫu của chúng.
Những gì các hệ thống chống gian lận theo dõi
1. Tần suất yêu cầu từ một IP
Nếu từ một IP nhận được 100 yêu cầu mỗi phút — đó là dấu hiệu rõ ràng của bot. Các giới hạn khác nhau: các trang web thông thường chịu đựng 10-30 yêu cầu/phút, các nền tảng bảo mật — 2-5 yêu cầu/phút.
Giải pháp cho các yêu cầu song song: Phân phối yêu cầu qua một nhóm IP lớn. Ví dụ, 1000 yêu cầu/phút = 50 IP mỗi IP 20 yêu cầu. Điều này trông giống như 50 người dùng thông thường.
2. Các khoảng thời gian giống nhau giữa các yêu cầu
Các yêu cầu chính xác mỗi 2.00 giây — là dấu hiệu của tự động hóa. Con người nhấp chuột với các khoảng thời gian khác nhau: 1.8 giây, 3.2 giây, 2.1 giây.
Giải pháp: Thêm ngẫu nhiên hóa ±30-50% từ độ trễ cơ bản. Thay vì 5 giây cố định, hãy sử dụng random(3.5, 7.5).
3. Thiếu hành vi điển hình của người dùng
Người dùng thực không đi thẳng đến trang sản phẩm — họ sẽ vào trang chính trước, tìm kiếm danh mục, nhấp vào sản phẩm. Bot ngay lập tức yêu cầu một URL cụ thể.
Giải pháp cho các nền tảng quan trọng: Mô phỏng toàn bộ đường đi của người dùng. Trước khi phân tích sản phẩm, thực hiện 2-3 yêu cầu: trang chính → danh mục → sản phẩm. Điều này làm chậm tốc độ, nhưng giảm rủi ro bị chặn xuống 70-80%.
4. User-Agent và tiêu đề đáng ngờ
User-Agent lỗi thời (ví dụ: Chrome 95 vào năm 2024), thiếu tiêu đề Accept-Language, Referer — là dấu hiệu của bot.
Giải pháp: Sử dụng User-Agent hiện tại (Chrome 120+, Firefox 120+), thêm đầy đủ các tiêu đề như của trình duyệt thực. Thay đổi User-Agent cùng với IP.
So sánh rủi ro bị chặn
| Kịch bản | Rủi ro với các yêu cầu tuần tự | Rủi ro với các yêu cầu song song |
|---|---|---|
| Phân tích thị trường (10K yêu cầu) | Thấp (5-10%) | Trung bình (20-30%) |
| Làm việc với Facebook Ads | Thấp (2-5%) | Nguy hiểm (80-95%) |
| Tự động hóa Instagram | Trung bình (15-25%) | Cao (60-80%) |
| API công khai (trong giới hạn) | Rất thấp (1-3%) | Thấp (5-10%) |
| Các trang web với Cloudflare | Trung bình (10-20%) | Cao (40-60%) |
Loại proxy nào phù hợp với mỗi phương pháp
Loại proxy ảnh hưởng trực tiếp đến khả năng sử dụng các yêu cầu song song hoặc tuần tự. Lựa chọn sai sẽ dẫn đến việc bị chặn hoặc phải trả giá cao.
Proxy cho các yêu cầu song song
Proxy trung tâm dữ liệu — lựa chọn tối ưu cho việc phân tích hàng loạt và các yêu cầu song song. Chúng rẻ (từ $1-3 cho mỗi IP/tháng), nhanh (ping 20-50 ms) và có sẵn với số lượng lớn. Nhược điểm — dễ dàng bị xác định là proxy, do đó không phù hợp cho các nền tảng bảo mật.
Khi nào sử dụng: Phân tích các thị trường, thu thập dữ liệu từ các nguồn công khai, kiểm tra tính khả dụng của tài nguyên, yêu cầu API hàng loạt đến các dịch vụ không có bảo vệ nghiêm ngặt.
Cấu hình: Mua một nhóm 50-100 IP, thiết lập 20-30 luồng song song, mỗi luồng sử dụng IP riêng. Thay đổi IP sau mỗi 100-200 yêu cầu hoặc khi có lỗi.
Proxy cư trú — đắt hơn (từ $3-7 cho 1 GB dữ liệu), nhưng trông giống như người dùng thực. Phù hợp cho các yêu cầu song song đến các nền tảng bảo mật, nếu cần tốc độ nhưng cần cẩn thận.
Khi nào sử dụng: Phân tích mạng xã hội (không cần xác thực), thu thập dữ liệu từ các trang web có Cloudflare, làm việc với các nền tảng chặn các trung tâm dữ liệu. Đối với các yêu cầu song song, cần một nhóm IP lớn với tự động thay đổi.
Quan trọng: Khi sử dụng các yêu cầu song song qua proxy cư trú, hãy kiểm soát mức tiêu thụ dữ liệu. 10.000 yêu cầu có thể "tiêu tốn" 5-10 GB, điều này sẽ tốn khoảng $20-50. Các trung tâm dữ liệu rẻ hơn: dữ liệu không giới hạn với $100-200/tháng cho 100 IP.
Proxy cho các yêu cầu tuần tự
Proxy di động — loại đáng tin cậy nhất cho việc làm việc với các nền tảng bảo mật. IP trông giống như các thiết bị di động thực (4G/5G của các nhà mạng), điều này giảm thiểu rủi ro bị chặn. Nhược điểm — đắt (từ $50-150 cho mỗi IP/tháng).
Khi nào sử dụng: Facebook Ads, Instagram, TikTok, Google Ads — tất cả nơi cần bảo mật tối đa và mô phỏng hành vi của người dùng thực. Một tài khoản = một proxy di động = các hành động tuần tự.
Cấu hình: Mỗi tài khoản quảng cáo hoặc tài khoản mạng xã hội gắn với một IP di động riêng. Các hành động diễn ra tuần tự với độ trễ từ 10-60 giây. IP không thay đổi (một tài khoản luôn hoạt động từ một IP).
Proxy cư trú — là lựa chọn tốt cho các nhiệm vụ ít nghiêm trọng hơn: phân tích với xác thực, tự động hóa SMM, làm việc với các thị trường như người bán.
Khi nào sử dụng: Quản lý tài khoản trên các thị trường (Wildberries, Ozon như người bán), tự động hóa đăng bài trên mạng xã hội (không phải hàng loạt), phân tích dữ liệu yêu cầu xác thực.
Khuyến nghị về việc chọn proxy
| Nhiệm vụ | Loại proxy | Phương pháp yêu cầu | Số lượng IP |
|---|---|---|---|
| Phân tích các thị trường (khối lượng lớn) | Trung tâm dữ liệu | Song song | 50-100+ |
| Facebook Ads (đa tài khoản) | Di động | Tuần tự | 1 IP cho mỗi tài khoản |
| Tự động hóa Instagram | Di động/cư trú | Tuần tự | 1 IP cho mỗi tài khoản |
| Phân tích với Cloudflare | Cư trú | Song song (cẩn thận) | 20-50 |
| API công khai (thu thập hàng loạt) | Trung tâm dữ liệu | Song song | 10-30 |
| Thị trường (tài khoản cá nhân của người bán) | Cư trú | Tuần tự | 1 IP cho mỗi tài khoản |
Cấu hình tối ưu: độ trễ, luồng, thời gian chờ
Cấu hình đúng các tham số là rất quan trọng để cân bằng giữa tốc độ và an toàn. Cấu hình quá hung hăng sẽ dẫn đến việc bị chặn, trong khi quá cẩn thận sẽ lãng phí thời gian.
Cấu hình các yêu cầu song song
Số lượng luồng đồng thời (concurrency)
Đây là tham số chính. Quá nhiều luồng = quá tải cho proxy và máy chủ mục tiêu. Quá ít = tốc độ thấp.
Khuyến nghị:
- Phân tích các thị trường: 20-50 luồng với nhóm 50+ proxy
- API công khai: 10-30 luồng, dựa vào giới hạn của API
- Các trang web có bảo vệ: 5-15 luồng, nhiều hơn — rủi ro bị chặn
- Kiểm tra proxy: 50-100 luồng (tại đây tốc độ quan trọng hơn)
Độ trễ trong các luồng
Ngay cả khi làm việc song song, mỗi luồng cũng cần có thời gian nghỉ giữa các yêu cầu của mình. Điều này giảm tải cho một IP và giảm rủi ro bị chặn.
Khuyến nghị:
- Các trang web đơn giản: 0.5-2 giây giữa các yêu cầu trong một luồng
- Các thị trường: 1-3 giây với ngẫu nhiên hóa ±30%
- Các trang web với Cloudflare: 2-5 giây với ngẫu nhiên hóa ±40%
- API với giới hạn: tính toán dựa trên giới hạn (ví dụ, 100 yêu cầu/phút = 0.6 giây/yêu cầu, hãy làm 1 giây để dự phòng)
Thời gian chờ (timeout)
Thời gian chờ phản hồi từ máy chủ. Thời gian chờ quá ngắn = mất dữ liệu do phản hồi chậm. Thời gian chờ quá dài = làm treo các luồng.
Khuyến nghị:
- Các trang web nhanh: 10-15 giây
- Các trang web/API chậm: 20-30 giây
- Qua proxy cư trú: +5-10 giây (chúng chậm hơn các trung tâm dữ liệu)
- Thời gian chờ kết nối: 5-10 giây (thời gian thiết lập kết nối)
Retry (thử lại)
Khi có lỗi (thời gian chờ, 503, proxy bị chặn), cần thử lại yêu cầu với một IP khác. Nếu không có retry, bạn sẽ mất một phần dữ liệu.
Cấu hình: 2-3 lần thử cho mỗi yêu cầu, thay đổi proxy sau mỗi lần thử không thành công, thời gian nghỉ 3-5 giây trước khi thử lại.
Cấu hình các yêu cầu tuần tự
Độ trễ cơ bản giữa các yêu cầu
Phụ thuộc vào nền tảng và loại hành động. Quy tắc chính: mô phỏng người dùng thực.
Khuyến nghị cho các nền tảng:
- Facebook Ads (chuyển giữa các phần trong tài khoản): 7-15 giây
- Instagram (thích): 45-90 giây, tối đa 60 lượt thích/giờ
- Instagram (theo dõi): 60-120 giây, tối đa 30 lượt theo dõi/giờ
- TikTok (xem): 30-60 giây
- Phân tích với xác thực: 3-7 giây
- Các thị trường (hành động trong tài khoản người bán): 5-10 giây
Ngẫu nhiên hóa
Là bắt buộc cho tất cả các yêu cầu tuần tự. Sử dụng độ lệch ±30-50% từ độ trễ cơ bản.
Ví dụ: Độ trễ cơ bản 10 giây, ngẫu nhiên hóa ±40% → độ trễ thực tế sẽ là 6-14 giây (giá trị ngẫu nhiên mỗi lần).
Thời gian chờ
Đối với các yêu cầu tuần tự, có thể sử dụng thời gian chờ dài hơn, vì không có rủi ro bị chặn tất cả các luồng.
Khuyến nghị: 30-60 giây cho các nền tảng bảo mật (Facebook, Instagram), 15-30 giây cho các trang web thông thường.
Lời khuyên thực tiễn: Bắt đầu với các thiết lập bảo thủ (ít luồng, nhiều độ trễ), từ từ tăng cường độ hung hăng, theo dõi tỷ lệ lỗi. Nếu lỗi >5-10% — hãy quay lại một bước.
Công cụ để thực hiện cả hai phương pháp
Việc chọn công cụ phụ thuộc vào nhiệm vụ của bạn và kỹ năng kỹ thuật. Đối với các nhiệm vụ kinh doanh (trọng tài, SMM, thương mại điện tử), hãy sử dụng các giải pháp có sẵn mà không cần mã. Đối với các nhiệm vụ kỹ thuật — thư viện và framework.
Giải pháp có sẵn không cần mã (cho doanh nghiệp)
Trình duyệt chống phát hiện cho đa tài khoản
Nếu bạn làm việc với các tài khoản quảng cáo hoặc mạng xã hội, trình duyệt chống phát hiện là tiêu chuẩn của ngành. Chúng tự động quản lý proxy, dấu vân tay của trình duyệt và cách ly các tài khoản.
Các giải pháp phổ biến:
- Dolphin Anty: dẫn đầu cho các nhà đầu tư Facebook/TikTok, gói miễn phí cho 10 hồ sơ, cấu hình proxy đơn giản
- AdsPower: tốt cho thương mại điện tử (Amazon, eBay), có tự động hóa qua RPA (không cần mã)
- Multilogin: đắt nhất ($100+/tháng), nhưng bảo vệ tối đa cho các nhà đầu tư nghiêm túc
- GoLogin: lựa chọn ngân sách ($25/tháng), phù hợp cho SMM và các nhóm nhỏ
Cách chúng hoạt động với proxy: Tạo hồ sơ trình duyệt → gán proxy → tất cả các hành động trong hồ sơ này đi qua IP này. Một hồ sơ = một tài khoản = các hành động tuần tự. Để làm việc song song, mở nhiều hồ sơ cùng một lúc (mỗi hồ sơ với proxy riêng).
Các công cụ phân tích và thu thập dữ liệu (có sẵn)
Để thu thập dữ liệu từ các thị trường và trang web, có các công cụ có sẵn với GUI, không yêu cầu lập trình.
- Octoparse: trình tạo phân tích trực quan, hỗ trợ proxy, có thể thiết lập các luồng song song qua giao diện
- ParseHub: tương tự như Octoparse, gói miễn phí cho 200 trang, cấu hình độ trễ qua GUI
- Scrapy Cloud: dịch vụ đám mây để chạy các spider Scrapy (cần kiến thức Python tối thiểu)
Tự động hóa SMM (không cần mã)
Để quản lý mạng xã hội, có các dịch vụ với tự động hóa qua giao diện.
- Jarvee: tự động hóa Instagram, TikTok, Twitter, hỗ trợ proxy tích hợp, cấu hình độ trễ qua GUI (cẩn thận: tự động hóa hung hăng dẫn đến việc bị chặn)
- Ingramer (Inflact): tự động hóa an toàn cho Instagram, hoạt động qua proxy của họ
- Combin: theo dõi/nhấn thích có mục tiêu trên Instagram, hỗ trợ proxy bên ngoài
Công cụ kỹ thuật (dành cho lập trình viên)
Nếu bạn viết các script của riêng mình để phân tích hoặc tự động hóa, hãy sử dụng các thư viện đã được kiểm chứng.
Python (phổ biến nhất cho phân tích):
- Requests + threading/asyncio: cho các yêu cầu song song đơn giản, dễ dàng cấu hình proxy
- aiohttp: thư viện bất đồng bộ cho các yêu cầu song song cao (1000+ đồng thời)
- Scrapy: framework cho phân tích, hỗ trợ tích hợp cho việc thay đổi proxy, middleware cho độ trễ
- Selenium: cho các trang web có JavaScript, chậm hơn nhưng vượt qua nhiều bảo vệ
- Playwright: lựa chọn hiện đại cho Selenium, nhanh hơn và tiện lợi hơn
JavaScript/Node.js:
- Axios: thư viện phổ biến cho các yêu cầu HTTP, dễ dàng cấu hình proxy
- Puppeteer: thư viện cho tự động hóa trình duyệt, hỗ trợ proxy và có thể chạy nhiều phiên đồng thời