httpx là gì?

Scrapeless Proxies cho phép HTTP client của bạn định tuyến các yêu cầu đi ra thông qua một kết nối proxy đã chọn.

HTTPX là một HTTP client cho Python với cả giao diện đồng bộ và bất đồng bộ. Nó gửi yêu cầu, quản lý kết nối và cung cấp các phản hồi để ứng dụng của bạn kiểm tra. Nó hỗ trợ HTTP/1.1 và tùy chọn HTTP/2, khiến nó hữu ích trong script, dịch vụ web và bộ thu thập dữ liệu cần một vòng đời client rõ ràng.

Tên này cũng có thể chỉ tới phần mềm không liên quan, vì vậy trang này nói về thư viện Python. Điểm thiết kế hữu ích nhất của nó là lựa chọn mô hình thực thi mà không bỏ các khái niệm request quen thuộc. Bạn vẫn làm việc với phương thức, URL, header và thân phản hồi; một client bất đồng bộ chỉ thay đổi cách ứng dụng chờ các phản hồi đó.

Điều gì xảy ra trong một yêu cầu HTTPX?

Một yêu cầu HTTPX chuyển các thiết lập của ứng dụng tới một transport, thứ sẽ kết nối đến đích và trao đổi các thông điệp HTTP. Kết quả là một đối tượng phản hồi chứa thông tin như trạng thái, header và nội dung thân. Giao diện HTTPX client interface cũng hỗ trợ xác thực, cookie, streaming và cấu hình ở cấp độ client.

Có một số kết quả riêng biệt trên đường đi này. Một kết nối có thể thất bại trước khi có bất kỳ phản hồi HTTP nào. Máy chủ có thể trả về một trạng thái lỗi HTTP. Một trạng thái thành công có thể mang nội dung mà ứng dụng không thể dùng. Hãy xử lý chúng như các trường hợp riêng để một pipeline dữ liệu có thể giải thích điều thực sự đã xảy ra.

Gọi bộ phân tích JSON của một phản hồi chỉ giải mã phần thân. Nó không xác minh rằng có mặt một mức giá, một bản ghi thuộc về mục đã yêu cầu, hay phân trang đã tới đúng điểm cuối mong đợi. Ứng dụng chịu trách nhiệm cho các kiểm tra đó. HTTPX cung cấp kết quả transport từ đó quyết định đó có thể được đưa ra.

Client Sync và Async khác nhau thế nào?

Một client đồng bộ chờ trong luồng thực thi gọi nó, trong khi một client bất đồng bộ cung cấp các thao tác có thể được await bởi một ứng dụng async. Hãy dùng Client đồng bộ cho công việc tuần tự đơn giản. Dùng AsyncClient khi ứng dụng xung quanh đã phối hợp các thao tác bất đồng bộ hoặc có I/O độc lập để chồng lấp.

Async không tự động đồng nghĩa với song song. Một coroutine chờ từng yêu cầu trước khi bắt đầu yêu cầu tiếp theo vẫn là tuần tự. Bộ lập lịch phải nhận được công việc độc lập trước khi thời gian chờ mạng có thể chồng lấp. Chương trình của bạn cũng cần một chính sách giới hạn số lượng thao tác đang hoạt động; chỉ riêng kiểu client không cung cấp một chính sách tải công việc đầy đủ.

Với một bộ kiểm tra tài liệu mang tính minh họa, một vòng lặp đồng bộ có thể đủ nếu mỗi tài liệu phụ thuộc vào một giá trị trích xuất từ tài liệu trước đó. Thiết kế async hấp dẫn hơn khi bộ kiểm tra đã có các URL độc lập. Quyết định nên theo các quan hệ phụ thuộc đó thay vì ưu thích một cú pháp nào đó.

Vì sao một client có thể tái sử dụng lại quan trọng

Một HTTPX client có thể tái sử dụng duy trì một connection pool và cấu hình dùng chung giữa các yêu cầu. Tái sử dụng một kết nối đủ điều kiện tránh việc thiết lập kết nối mới cho mỗi yêu cầu tới cùng một đích. Điều này có thể giảm công việc thiết lập kết nối, nhưng lợi ích phụ thuộc vào khối lượng công việc và việc máy chủ có cho phép tái sử dụng hay không.

Đặt client bao quanh một phạm vi mạch lạc, như một batch hoặc một thành phần dịch vụ. Tạo một client mới trong mỗi vòng lặp sẽ làm mất phần lớn lý do sử dụng pooling. Để một client mở sau khi chủ sở hữu của nó kết thúc lại tạo ra vấn đề ngược lại: tài nguyên vẫn sống mà không có vòng đời rõ ràng.

Header và cookie ở cấp độ client cũng tồn tại trong phạm vi đó. Điều này thuận tiện cho một phiên dữ liệu công khai nhất quán, nhưng đòi hỏi phải tách bạch có chủ đích giữa các ngữ cảnh không liên quan. Tránh chia sẻ một cookie jar có thể thay đổi giữa các quan sát đại diện cho những tài khoản hoặc vùng khác nhau.

Tái sử dụng kết nối và số lượng yêu cầu là hai đại lượng khác nhau. HTTP/2 có thể multiplex nhiều yêu cầu trên một kết nối, trong khi HTTP/1.1 dùng hành vi kết nối khác. Đừng đánh đồng số lượng kết nối tối đa với một số lượng tối đa phổ quát cho các thao tác ứng dụng. Giữ giới hạn của ứng dụng và các thiết lập pool của transport tách biệt như hai bộ điều khiển riêng.

Timeout xác định các giai đoạn chờ khác nhau

HTTPX phân biệt timeout kết nối, đọc, ghi và pool. Timeout kết nối liên quan tới việc thiết lập kết nối. Timeout đọc liên quan tới việc chờ dữ liệu đến. Timeout ghi liên quan tới việc gửi dữ liệu, và timeout pool liên quan tới việc chờ một slot kết nối trong client.

Vì vậy, một timeout pool có thể chỉ ra tranh chấp cục bộ ngay cả khi đích vẫn khỏe mạnh. Tăng năng lực phía xa sẽ không giải quyết được một client mà các stream của nó không bao giờ được đóng hoặc có khối lượng công việc vượt quá hạn mức kết nối riêng. Hãy ghi lại loại ngoại lệ cùng với thao tác bị ảnh hưởng để việc chẩn đoán bắt đầu ở đúng lớp.

Timeout cho từng pha không nên bị nhầm với một thời hạn duy nhất bao phủ toàn bộ tác vụ nghiệp vụ. Một job có thể chờ trong hàng đợi ứng dụng trước khi HTTPX được gọi, và nó có thể phân tích hoặc lưu trữ dữ liệu sau khi yêu cầu kết thúc. Nếu tác vụ có một thời hạn tổng thể, hãy theo dõi điều đó riêng.

Chọn giá trị timeout dựa trên hợp đồng ứng dụng và khối lượng công việc quan sát được. Một phản hồi metadata nhỏ và một lượt tải xuống lớn được phép có các yêu cầu khác nhau. Gỡ bỏ mọi giới hạn có thể khiến tài nguyên bị chiếm dụng vô thời hạn; đặt mọi giới hạn cực kỳ ngắn có thể từ chối công việc lẽ ra đáp ứng được tác vụ.

Cách kiểm tra tính hợp lệ của một phản hồi cho đúng

Kiểm tra tính hợp lệ của phản hồi lần lượt kiểm tra thành công của lớp transport, ý nghĩa HTTP và nội dung ứng dụng. Tiêu chuẩn HTTP semantics standard định nghĩa các phương thức và ý nghĩa trạng thái, nhưng trạng thái thành công không chứng nhận logic trích xuất của bạn. Một phản hồi hợp lệ vẫn có thể mô tả sai tài nguyên cho tác vụ của bạn.

Bắt đầu với các URL được yêu cầu và cuối cùng. Nếu tính năng theo dõi chuyển hướng được bật, hãy kiểm tra nơi khách hàng đã đến. Sau đó kiểm tra loại phương tiện trước khi giải mã phần nội dung. Sau khi giải mã, xác minh các trường mong đợi và kiểu dữ liệu của chúng. Giữ lại lý do cho mỗi phản hồi bị từ chối để một tập dữ liệu trống không âm thầm trở thành một phát hiện kinh doanh tích cực.

Ví dụ, một quan sát về sản phẩm có thể yêu cầu một mã định danh sản phẩm và một đơn vị tiền tệ cùng với một mức giá. Nếu giá tồn tại nhưng đơn vị tiền tệ không có, ứng dụng không nên gộp giá trị đó vào một so sánh giữa các thị trường mà không có thêm ngữ cảnh. Đây là một quy tắc của mô hình dữ liệu, độc lập với thư viện phía khách.

Giữ giá trị thiếu khác biệt với các tập hợp rỗng và các giá trị số 0 rõ ràng. Một trường tồn kho bị thiếu không chứng minh rằng hàng tồn kho bằng 0. Một mảng JSON không có phần tử có thể là một kết quả hợp lệ chỉ khi phản hồi bao quanh xác nhận rằng truy vấn đã được chấp nhận và hoàn tất.

Yêu cầu phát trực tuyến cần một lifetime tường minh

Truyền phát cho phép một ứng dụng tiêu thụ phản hồi một cách tuần tự thay vì tải toàn bộ nội dung trước khi xử lý. Điều này hữu ích cho các tệp hoặc nguồn dữ liệu lớn, nhưng nó tạo ra một nghĩa vụ về tài nguyên: luồng phải được tiêu thụ hoặc đóng lại theo giao diện của phía khách.

Một luồng được quản lý bằng ngữ cảnh cung cấp một ranh giới rõ ràng cho nghĩa vụ đó. Nếu việc kiểm tra tính hợp lệ thất bại sớm, thì việc thoát khỏi ngữ cảnh vẫn phải đóng luồng. Giữ mở các phản hồi mới đọc một phần có thể làm cạn kiệt pool kết nối và khiến các yêu cầu không liên quan phải chờ tài nguyên trông như bị thiếu một cách khó hiểu.

Đầu vào gia tăng cũng làm thay đổi thiết kế bộ phân tích cú pháp. Ranh giới từng khối (chunk) là ranh giới truyền tải, không nhất thiết là một đối tượng JSON hoàn chỉnh, ký tự văn bản, hoặc bản ghi ứng dụng. Hãy sử dụng một bộ phân tích cú pháp phù hợp với định dạng và giữ lại dữ liệu chưa hoàn chỉnh cho đến khi khối tiếp theo đến. Đừng cho rằng một khối tương đương với một bản ghi có ý nghĩa.

Định tuyến Proxy và Xác minh Chứng chỉ

Một proxy định tuyến lưu lượng HTTPX thông qua một trung gian, trong khi việc xác minh TLS sẽ xác thực điểm cuối bảo mật mà khách hàng mong đợi. Những cơ chế kiểm soát này trả lời các câu hỏi khác nhau. Một kết nối proxy hoạt động không biện minh cho việc vô hiệu hóa kiểm tra chứng chỉ, và một chứng chỉ đã được xác minh không cho bạn biết đã chọn điểm thoát địa lý nào.

The Giao thức bảo mật TLS cung cấp phương thức truyền tải được mã hóa được sử dụng cho HTTPS. Trong một đường hầm HTTPS thông thường thông qua một proxy HTTP, máy khách có thể thiết lập TLS tới đích thông qua đường hầm đó. Một proxy kiểm tra được cấu hình rõ ràng có một mô hình tin cậy khác và cần được đánh giá như vậy.

Use the current Thiết lập proxy Scrapeless để lấy thông tin kết nối chính xác. Giữ thông tin xác thực proxy bên ngoài hệ thống quản lý mã nguồn và xóa/che các URL proxy đầy đủ khỏi nhật ký khi chúng chứa thông tin xác thực. Liên quan Hướng dẫn sử dụng HTTPX và Scrapeless Proxies là bối cảnh hữu ích, nhưng các ví dụ lịch sử cần được điều chỉnh cho phù hợp với các thiết lập sản phẩm hiện tại.

Các Giải Pháp Proxy Không Cần Thu Thập Dữ Liệu cung cấp thành phần mạng cho các ứng dụng vẫn giữ quyền kiểm soát đối với yêu cầu và việc phân tích cú pháp. So sánh hành vi của sản phẩm đã chọn và giá hiện tại với các yêu cầu theo lô trước khi cam kết cho một đợt chạy lớn hơn.

HTTPX Không Làm Gì

HTTPX không thực thi JavaScript trên trang hoặc hiển thị giao diện trình duyệt. Nếu phản hồi chứa một application shell, HTTPX sẽ trả về shell đó. Ứng dụng cần một phương thức thu thập khác khi nội dung cần thiết chỉ tồn tại sau khi trình duyệt được thực thi hoặc có tương tác.

HTTPX cũng không tự động lưu vào bộ nhớ đệm mọi phản hồi như một trình duyệt có thể làm. Bộ nhớ đệm HTTP có kho lưu trữ, quy tắc về tính mới và xác thực riêng, được định nghĩa trong Đặc tả bộ nhớ đệm HTTP. Xem bất kỳ bộ nhớ đệm của ứng dụng nào như một thành phần riêng biệt với khóa và chính sách độ mới được thiết kế rõ ràng.

Cuối cùng, việc thay đổi client không thiết lập quyền truy cập vào một tài nguyên. Hãy sử dụng các giao diện được ghi chép và các trang được phép phù hợp với quy trình làm việc. Yêu cầu xác thực vẫn là một ranh giới ngay cả khi một client khác báo cáo phản hồi khác.

Kết luận

HTTPX cung cấp cho các ứng dụng Python một lựa chọn rõ ràng giữa các thao tác HTTP đồng bộ và bất đồng bộ. Tái sử dụng các client trong một phạm vi sở hữu, phân loại timeout theo từng giai đoạn, và đóng các luồng phản hồi. Chỉ chấp nhận dữ liệu sau khi đã kiểm tra nội dung trả về so với tác vụ, thay vì xem mã trạng thái HTTP là kết quả cuối cùng.