Middleware Máy Chủ Ngăn Chặn Bot Giả Trước Khi Chúng Đến Ứng Dụng Của Bạn

Đường ống xử lý yêu cầu trong một ứng dụng web là một điều tuyệt vời. Một yêu cầu đến máy chủ web, đi qua một ngăn xếp middleware, tiếp cận một bộ điều khiển, và trả về một phản hồi. Mỗi middleware trong ngăn xếp có cơ hội kiểm tra yêu cầu, sửa đổi nó, chuyển tiếp nó, hoặc từ chối nó hoàn toàn. Kiến trúc này hoàn hảo để triển khai phát hiện bot vì xác minh xảy ra trước khi yêu cầu chạm vào bất kỳ logic ứng dụng nào. Một crawler giả nói rằng nó là Googlebot sẽ bị xác định và chặn ở lớp middleware, và bộ điều khiển thậm chí không biết yêu cầu tồn tại. Không có chu kỳ CPU nào lãng phí để hiển thị trang. Không có truy vấn cơ sở dữ liệu nào được thực thi. Không có mục nhập bộ đệm nào được điền. Bot giả bị dừng ở cửa, và tài nguyên máy chủ sẽ được sử dụng được bảo tồn cho những khách truy cập hợp pháp.

Động lực để xây dựng middleware này đến từ một vấn đề cụ thể và tốn kém. Một ứng dụng lớn đang tiêu thụ băng thông và tài nguyên máy chủ với tốc độ không tương xứng với cơ sở người dùng thực tế của nó. Nhật ký truy cập cho thấy khối lượng lớn các yêu cầu từ user agent tự xưng là Googlebot, Bingbot và các crawler hợp pháp khác. Điều tra xác nhận rằng phần lớn những yêu cầu này là giả, xuất phát từ các nhà cung cấp lưu trữ đám mây chứ không phải từ các công cụ tìm kiếm mà chúng tự xưng là. Mỗi yêu cầu giả tiêu thụ cùng tài nguyên máy chủ như một yêu cầu thực: cùng thời gian thực thi PHP, cùng truy vấn cơ sở dữ liệu, cùng cấp phát bộ nhớ, cùng băng thông cho phản hồi. Nhân với hàng ngàn yêu cầu giả mỗi giờ, chi phí là đáng kể. Giải pháp middleware được thiết kế để loại bỏ sự lãng phí này bằng cách bắt bot giả trước khi chúng tiêu thụ bất kỳ tài nguyên ứng dụng nào.

Việc triển khai tuân theo một mô hình đơn giản mà bất kỳ nhà phát triển backend nào cũng có thể thích ứng. Middleware chặn mọi yêu cầu đến, kiểm tra xem chuỗi user agent có khớp với mô hình crawler công cụ tìm kiếm đã biết không, và nếu có, xác minh địa chỉ IP của yêu cầu theo cơ sở hạ tầng đã biết của crawler bằng cách sử dụng API phát hiện bot. Các yêu cầu tự xưng là crawler nhưng không qua xác minh bị chặn bằng phản hồi 403. Các yêu cầu vượt qua xác minh, hoặc các yêu cầu không tự xưng là crawler, tiếp tục thông qua ngăn xếp middleware bình thường. Toàn bộ kiểm tra thêm độ trễ tối thiểu vì kết quả xác minh được lưu vào bộ đệm theo địa chỉ IP, có nghĩa là mỗi IP duy nhất chỉ được xác minh một lần.

Logic Ra Quyết Định Đằng Sau Việc Chặn Ở Lớp Middleware

Chọn chặn ở lớp middleware chứ không phải ở cấp máy chủ web (Nginx hoặc Apache) hoặc ở cấp ứng dụng (trong các bộ điều khiển) là một quyết định kiến trúc cố ý với những đánh đổi cụ thể. Chặn ở cấp máy chủ web là tùy chọn hiệu quả nhất về tiêu thụ tài nguyên vì yêu cầu không bao giờ tiếp cận PHP. Tuy nhiên, cấu hình máy chủ web cho phát hiện bot thường liên quan đến danh sách đen IP tĩnh hoặc khớp user agent đơn giản, không có tùy chọn nào cung cấp xác minh động chạy bằng API cần thiết để phân biệt chính xác giữa crawler thực và giả. Duy trì danh sách đen tĩnh gồm hàng triệu địa chỉ IP là không thực tế, và khớp user agent một mình không thể xác minh danh tính vì user agent rất dễ bị giả mạo.

Chặn ở cấp ứng dụng, trong các bộ điều khiển hoặc lớp dịch vụ, là tùy chọn linh hoạt nhất nhưng kém hiệu quả nhất. Khi yêu cầu tiếp cận bộ điều khiển, ngăn xếp middleware đã được thực thi, tuyến đường đã được giải quyết, và các hoạt động có thể tốn kém như khởi tạo phiên và xác thực đã xảy ra. Chặn tại thời điểm này tiết kiệm thời gian thực thi bộ điều khiển nhưng lãng phí mọi thứ xảy ra trước đó. Đối với các ứng dụng lưu lượng truy cập cao nơi các yêu cầu bot giả có số lượng hàng ngàn mỗi giờ, việc tiền xử lý lãng phí này tích lũy.

Lớp middleware nằm ở điểm tối ưu trong đường dẫn. Nó thực thi trước khi xử lý phiên, trước khi xác thực, trước khi middleware dành riêng cho tuyến, và chắc chắn trước khi logic bộ điều khiển. Nhưng nó có quyền truy cập vào đối tượng yêu cầu đầy đủ, bao gồm tiêu đề, địa chỉ IP và tham số truy vấn, điều này có nghĩa là nó có thể thực hiện logic xác minh tinh vi chứ không phải khớp mô hình đơn giản. Middleware có thể gọi một API bên ngoài, kết quả bộ đệm, áp dụng logic có điều kiện dựa trên danh tính được tuyên bố, và ghi lại kết quả xác minh để phân tích. Sự kết hợp của hiệu quả và tính linh hoạt này làm cho middleware trở thành nhà của phát hiện bot trong một ứng dụng web.

Chiến lược bộ đệm đặc biệt quan trọng cho hiệu suất. Không có bộ đệm, mọi yêu cầu từ một crawler được tuyên bố sẽ yêu cầu một lệnh gọi API để xác minh địa chỉ IP. Ngay cả với API nhanh, điều này sẽ thêm độ trễ cho mọi yêu cầu. Giải pháp là lưu kết quả xác minh vào bộ đệm bằng cách sử dụng địa chỉ IP làm khóa, với thời gian tồn tại của một vài giờ hoặc thậm chí một ngày đầy đủ. Crawler công cụ tìm kiếm hoạt động từ các phạm vi IP ổn định thay đổi không thường xuyên, vì vậy kết quả xác minh được lưu vào bộ đệm vẫn hợp lệ trong thời gian dài. Khi một yêu cầu đến từ Googlebot được tuyên bố, middleware trước tiên kiểm tra bộ đệm. Nếu IP được xác minh là hợp pháp trong thời gian bộ đệm, yêu cầu được cho phép ngay lập tức. Nếu IP được xác minh là giả, nó bị chặn ngay lập tức. Chỉ các địa chỉ IP lần đầu yêu cầu một lệnh gọi API thực tế, và sau đó, kết quả được phục vụ từ bộ đệm với chi phí độ trễ không đáng kể.

Điều Xảy Ra Với Các Yêu Cầu Bị Chặn

Chặn một crawler giả không đơn giản là trả lại phản hồi 403 và tiếp tục. Quyết định chặn và bối cảnh của nó nên được ghi nhật ký để phân tích. Mỗi yêu cầu bị chặn đại diện cho một điểm dữ liệu về ai đang cố gắng truy cập trang, họ giả vờ là ai, và họ đến từ đâu. Theo thời gian, nhật ký này tiết lộ các mô hình thông báo cho quyết định bảo mật rộng hơn. Có thể một ASN cụ thể chịu trách nhiệm về một tỷ lệ không tương xứng của bot giả. Có thể các yêu cầu Googlebot giả tăng đột biến vào những thời điểm nhất định trong ngày. Có thể một đường dẫn URL cụ thể thu hút nhiều bot giả hơn những cái khác, gợi ý rằng bot đang nhắm mục tiêu nội dung cụ thể.

Phản hồi đối với một yêu cầu bị chặn cũng có thể tinh tế hơn 403 chung chung. Một số triển khai trả lại 429 (Quá Nhiều Yêu Cầu) để che giấu thực tế rằng bot đã bị xác định, khiến bot operator khó hơn khi điều chỉnh cách tiếp cận của họ. Những cái khác trả lại 200 với một phần thân trống, lãng phí băng thông tối thiểu trong khi ngăn bot biết rằng nó đã bị phát hiện. Những cách tiếp cận tích cực hơn trả lại 403 kèm theo thông báo cho biết xác minh crawler không thành công, điều này là minh bạch nhưng cung cấp thông tin cho bot operator về cơ chế phát hiện. Lựa chọn phụ thuộc vào triết lý của nhà điều hành trang về sự minh bạch so với bảo mật hoạt động.

Đối với các bot tự xưng là crawler nhưng thực sự là các dịch vụ hợp pháp tình cờ sử dụng user agent giống crawler một cách không chính xác, việc chặn có thể gây rối hơn dự định. Một số công cụ giám sát SEO, chẳng hạn, sử dụng user agent giống Googlebot để mô phỏng cách Google nhìn thấy trang. Các công cụ này sẽ không qua xác minh vì chúng không phải Google, mặc dù mục đích của chúng là hợp pháp từ quan điểm của nhà điều hành trang. Middleware có thể thích ứng với điều này bằng cách duy trì danh sách trắng các phạm vi IP đã biết cho các dịch vụ bên thứ ba đáng tin cậy, hoặc bằng cách áp dụng xác minh chỉ cho các mô hình user agent cụ thể trong khi bỏ qua những cái khác. Tính linh hoạt của cách tiếp cận middleware cho phép loại chính sách sắc thái này mà không yêu cầu thay đổi cấu hình máy chủ web hoặc mã ứng dụng.

Xác Minh Đồng Bộ So Với Không Đồng Bộ

Câu hỏi về việc xác minh bot đồng bộ hay không đồng bộ ảnh hưởng đến cả hiệu quả của việc chặn và tác động hiệu suất trên ứng dụng. Xác minh đồng bộ có nghĩa là middleware tạm dừng yêu cầu, gọi API xác minh, chờ phản hồi, và sau đó cho phép hoặc chặn yêu cầu dựa trên kết quả. Cách tiếp cận này cung cấp việc chặn ngay lập tức nhưng thêm độ trễ cho yêu cầu đầu tiên từ mỗi địa chỉ IP. Với bộ đệm, độ trễ chỉ ảnh hưởng đến yêu cầu đầu tiên, nhưng đối với các ứng dụng lưu lượng truy cập cao thậm chí độ trễ không thường xuyên đó cũng có thể không thể chấp nhận được.

Xác minh không đồng bộ sử dụng một cách tiếp cận khác. Yêu cầu đầu tiên từ một IP mới được cho phép trong khi công việc xác minh được xếp hàng trong nền. Khi kết quả xác minh trở lại, nó được lưu vào bộ đệm, và tất cả các yêu cầu tiếp theo từ địa chỉ IP đó được xử lý theo kết quả. Cách tiếp cận này thêm độ trễ bằng không cho đường dẫn yêu cầu nhưng cho phép một số lượng nhỏ các yêu cầu ban đầu từ bot giả vượt qua trước khi xác minh hoàn tất. Đối với hầu hết các ứng dụng, sự đánh đổi này có thể chấp nhận được. Một bot giả gửi ba yêu cầu trước khi bị chặn đã tiêu thụ ít tài nguyên hơn một yêu cầu gửi hàng ngàn yêu cầu mà không bị cản trở.

Hệ thống hàng đợi làm cho cách tiếp cận không đồng bộ đơn giản. Middleware gửi một công việc xác minh gọi API phát hiện bot, lưu trữ kết quả trong bộ đệm, và tùy chọn bắt sự kiện mà các phần khác của ứng dụng có thể lắng nghe. Công việc chạy trong vài giây, có nghĩa là cửa sổ mà lưu lượng bot chưa được xác minh có thể vượt qua là cực kỳ hẹp. Đối với các ứng dụng sử dụng bộ đệm trong bộ nhớ nhanh, kết quả được lưu vào bộ đệm có sẵn cho tất cả các phiên bản ứng dụng ngay lập tức, vì vậy thậm chí trong một môi trường được cân bằng tải, xác minh chỉ cần xảy ra một lần mỗi địa chỉ IP trên tất cả các máy chủ.

Một cách tiếp cận kỳ lạ kết hợp những điều tốt nhất của cả hai. Các user agent bot đã biết khớp với các mô hình tự tin cao kích hoạt xác minh đồng bộ với kết quả được lưu vào bộ đệm, thêm độ trễ tối thiểu. Các mô hình tự tin thấp hơn kích hoạt xác minh không đồng bộ, cho phép yêu cầu đầu tiên vượt qua trong khi xác minh chạy trong nền. Cách tiếp cận phân tầng này tối ưu hóa cho trường hợp chung trong khi xử lý các trường hợp cạnh một cách sang trọng. Vị trí của middleware trong đường dẫn yêu cầu làm cho nó là nơi lý tưởng để triển khai logic này, vì nó có quyền truy cập vào tất cả thông tin cần thiết để đưa ra quyết định định tuyến và thực thi trước bất kỳ logic ứng dụng tốn kém nào.

Tác Động Có Thể Đo Lường Được Của Việc Chặn Ở Cửa

Kết quả của việc triển khai middleware phát hiện bot được nhìn thấy gần như ngay lập tức trong các chỉ số máy chủ. Thay đổi đáng chú ý nhất là trong tiêu thụ băng thông. Crawler giả yêu cầu các trang HTML hoàn chỉnh, bao gồm tất cả các tài sản được tham chiếu trong phản hồi. Mỗi yêu cầu bị chặn tiết kiệm băng thông sẽ được sử dụng để truyền phản hồi đầy đủ, có thể đối với các trang nặng nội dung là hàng chục hoặc hàng trăm kilobyte mỗi yêu cầu. Trên hàng ngàn yêu cầu bị chặn mỗi giờ, tiết kiệm băng thông tích lũy thành giảm chi phí có ý nghĩa, đặc biệt là đối với các ứng dụng được lưu trữ trên các nhà cung cấp tính phí theo gigabyte chuyển.

Sử dụng CPU giảm vì máy chủ không còn thực thi mã PHP, chạy truy vấn cơ sở dữ liệu, và hiển thị mẫu cho các yêu cầu không tạo ra giá trị. Sự giảm đó rõ ràng nhất trong giờ ngoài giờ cao điểm khi lưu lượng người dùng thấp nhưng lưu lượng bot vẫn không đổi. Trước khi triển khai middleware, máy chủ duy trì sử dụng CPU cơ sở ngay cả lúc ba giờ sáng vì bot không ngủ. Sau khi triển khai, sử dụng ngoài giờ cao điểm giảm gần bằng không, cung cấp không gian cho máy chủ cho lưu lượng hợp pháp trong giờ cao điểm.

Thời gian phản hồi cho khách truy cập hợp pháp được cải thiện như một hệ quả trực tiếp của tải máy chủ giảm. Máy chủ web xử lý năm trăm yêu cầu mỗi giây, ba trăm trong số đó là bot giả, có ít dung lượng có sẵn cho hai trăm khách truy cập thực hơn máy chủ xử lý chỉ hai trăm yêu cầu mỗi giây, tất cả đều hợp pháp. Middleware không chỉ tiết kiệm tài nguyên trên các yêu cầu bị chặn. Nó cải thiện chất lượng dịch vụ cho mọi yêu cầu vượt qua, vì máy chủ có dung lượng sẵn có nhiều hơn cho công việc thực.

Tải cơ sở dữ liệu giảm tỷ lệ thuận. Nếu ứng dụng truy vấn cơ sở dữ liệu cho mọi yêu cầu trang, chặn ba trăm yêu cầu giả mỗi giây loại bỏ ba trăm truy vấn cơ sở dữ liệu không cần thiết mỗi giây. Đối với các ứng dụng có các truy vấn phức tạp hoặc kết nối cơ sở dữ liệu hạn chế, sự giảm này có thể là sự khác biệt giữa hoạt động ổn định và quá tải định kỳ. Middleware bảo vệ toàn bộ ngăn xếp, từ máy chủ web qua lớp ứng dụng đến cơ sở dữ liệu, bằng cách dừng lưu lượng không mong muốn trước khi nó đến bất kỳ điều nào trong số chúng.