Mã Trạng Thái 102 Processing Là Gì? Tín Hiệu Máy Chủ Đang Xử Lý

Bạn đang tải một tệp video khổng lồ, nhiều gigabyte lên đám mây. Thanh tiến trình đang từ từ nhích lên. Đột nhiên, trình duyệt của bạn bị treo. Trang web dường như không phản hồi. Sau vài phút lo lắng, bạn nhận được một lỗi đáng sợ: 504 Gateway Timeout. Máy chủ đã từ bỏ bạn.

Bây giờ, hãy tưởng tượng một kịch bản khác. Quá trình tải lên vẫn chậm như vậy, nhưng một chỉ báo xoay nhỏ trên trang đang hoạt động. Bạn nhận được thông báo: "Đang xử lý video của bạn... việc này có thể mất vài phút." Bạn kiên nhẫn chờ đợi, và cuối cùng, bạn nhận được thông báo thành công.

Sự khác biệt là gì? Trong kịch bản thứ hai, máy chủ có thể đã sử dụng một mã trạng thái HTTP thông minh, mặc dù hiếm gặp, để quản lý kỳ vọng của bạn: 102 Processing.

Mã trạng thái này là cách máy chủ lịch sự nói: "Này, tôi đã nhận được yêu cầu của bạn. Đó là một yêu cầu lớn, và tôi sẽ mất một thời gian để hoàn thành. Nhưng tôi vẫn đang hoạt động và làm việc với nó, vì vậy xin đừng ngắt kết nối với tôi!"

Nó tương đương với việc một người phục vụ kiểm tra bàn của bạn trong khi bếp đang bận chuẩn bị một món ăn phức tạp. Họ chưa mang thức ăn của bạn ra, nhưng họ đang trấn an bạn rằng đơn hàng của bạn không bị quên.

Nếu bạn đã từng tham gia phát triển web hoặc tích hợp API, bạn có thể đã lướt qua các mã trạng thái HTTP, chắc chắn là những mã phổ biến như 200 OK hoặc 404 Not Found. Tuy nhiên, một số mã ít được biết đến hơn nhưng cũng quan trọng không kém vẫn tồn tại, chẳng hạn như 102 Processing. Mặc dù không được hiểu rộng rãi, trạng thái HTTP này giúp cải thiện hiệu quả giao tiếp giữa máy khách và máy chủ, đặc biệt khi xử lý các yêu cầu phức tạp hoặc kéo dài.

Thoạt nhìn, nó có vẻ khó hiểu. "Đang xử lý" chính xác là gì? Tại sao máy chủ cần gửi thông báo này? Và quan trọng nhất, các nhà phát triển nên xử lý nó như thế nào trong các ứng dụng thực tế?

Đó chính xác là những gì chúng ta sẽ khám phá trong hướng dẫn này.

Trong bài đăng blog chi tiết này, bạn sẽ khám phá ý nghĩa của mã trạng thái 102 Processing, lý do nó được giới thiệu, cách thức hoạt động và các tình huống sử dụng nó. Nếu bạn muốn kiểm tra các mã trạng thái HTTP, bao gồm cả những mã hiếm như 102 Processing, bạn cần một nền tảng kiểm thử API đáng tin cậy. Đó là lúc Apidog xuất hiện. Với Apidog, bạn có thể thiết kế, giả lập, kiểm thử, gỡ lỗi và tài liệu hóa API một cách liền mạch trong khi kiểm tra phản hồi theo thời gian thực. Và phần tốt nhất? Bạn có thể tải xuống Apidog miễn phí ngay hôm nay và bắt đầu khám phá các mã như 102 Processing một cách thực tế.

Bây giờ, hãy cùng khám phá mục đích, lịch sử và ứng dụng thực tế của mã trạng thái HTTP 102 Processing.

Vấn đề: Internet thiếu kiên nhẫn

Internet được xây dựng trên nền tảng của sự thiếu kiên nhẫn. Các kết nối HTTP không có nghĩa là sẽ mở mãi mãi. Mỗi thành phần trong chuỗi từ máy khách (trình duyệt của bạn) đến các proxy và bộ cân bằng tải tiềm năng đều có các thời gian chờ được tích hợp sẵn.

Nếu máy chủ mất quá nhiều thời gian để gửi phản hồi, các thành phần này sẽ cho rằng kết nối đã chết và chấm dứt nó, thường dẫn đến các lỗi như:

• 504 Gateway Timeout: Một máy chủ proxy không nhận được phản hồi từ máy chủ thượng nguồn kịp thời.
• 408 Request Timeout: Máy chủ hết thời gian chờ yêu cầu từ máy khách.
• Thời gian chờ phía máy khách: Bản thân trình duyệt hoặc ứng dụng từ bỏ việc chờ máy chủ.

Đây là một biện pháp an toàn hợp lý. Nó ngăn các kết nối bị treo tiêu tốn tài nguyên quý giá. Tuy nhiên, nó tạo ra một vấn đề cho các hoạt động hợp pháp đơn giản là mất nhiều thời gian để hoàn thành, như xử lý một video lớn, tạo một báo cáo phức tạp hoặc thực hiện một thao tác dữ liệu hàng loạt.

Câu hỏi đặt ra là: Làm thế nào để máy chủ nói với máy khách, "Tôi vẫn đang làm việc," mà không thực sự gửi phản hồi cuối cùng?

Câu trả lời, được định nghĩa trong RFC 2518 (cho WebDAV), là mã trạng thái 102 Processing.

Mã trạng thái 102 Processing là gì?

Mã trạng thái HTTP 102 Processing thuộc lớp phản hồi thông tin 1xx. Các mã trạng thái này không đại diện cho câu trả lời cuối cùng; thay vào đó, chúng cung cấp thông tin bổ sung trong vòng đời yêu cầu-phản hồi.

Cụ thể, 102 Processing có nghĩa là:

"Máy chủ đã nhận được yêu cầu của bạn và đang tích cực làm việc với nó, nhưng chưa có phản hồi cuối cùng nào."

Mã trạng thái này được định nghĩa trong RFC 2518 (phần mở rộng WebDAV cho HTTP). Nó chủ yếu được thiết kế để cho máy khách biết:

• Yêu cầu hợp lệ.
• Máy chủ đang bận xử lý nó.
• Máy khách không nên hết thời gian chờ hoặc cho rằng lỗi chỉ vì phản hồi đang mất một thời gian.

Không giống như các mã phản hồi điển hình báo hiệu thành công hay thất bại, 102 là một cách để giữ cho máy khách được thông báo và ngăn chặn thời gian chờ sớm trên các yêu cầu kéo dài.

Kết nối WebDAV

Để hiểu 102 Processing, bạn phải nói về WebDAV (Web Distributed Authoring and Versioning). WebDAV là một phần mở rộng của HTTP cho phép máy khách cùng nhau chỉnh sửa và quản lý tệp trên một máy chủ web từ xa. Đó là công nghệ đằng sau "ổ đĩa mạng" mà bạn có thể ánh xạ trong Windows hoặc macOS.

Các hoạt động của WebDAV như sao chép hoặc di chuyển một thư mục chứa hàng nghìn tệp có thể mất rất nhiều thời gian. Mã trạng thái 102 được phát minh đặc biệt cho ngữ cảnh này để giữ cho kết nối tồn tại trong các hoạt động kéo dài này.

Tại sao 102 Processing lại tồn tại?

Các yêu cầu web hiện đại thường có thể phức tạp và tốn thời gian, đặc biệt khi xử lý liên quan đến:

• Nhiều dịch vụ backend
• Xác thực dữ liệu sâu
• Các phép tính hoặc hoạt động cơ sở dữ liệu kéo dài
• Các hoạt động WebDAV phức tạp

Hãy tưởng tượng việc tải lên một tệp lớn hoặc chạy một hoạt động cơ sở dữ liệu phức tạp thông qua API. Nếu máy chủ mất quá nhiều thời gian để phản hồi, máy khách có thể nghĩ rằng có điều gì đó không ổn và ngắt kết nối.

Đó là lúc 102 Processing xuất hiện.

Nó nói với máy khách: "Thư giãn đi, tôi đã nhận được yêu cầu của bạn. Nó đang mất thời gian, nhưng tôi đang làm việc với nó."

Điều này đặc biệt hữu ích trong:

• Các hoạt động kéo dài: Tải lên tệp, xử lý hàng loạt, các truy vấn lớn.
• Tránh thời gian chờ: Ngăn máy khách cho rằng yêu cầu đã thất bại.
• Cải thiện trải nghiệm người dùng: Bằng cách báo hiệu tiến độ ngay cả khi chưa có kết quả cuối cùng.

Trước khi 102 được giới thiệu, máy khách không biết liệu một yêu cầu chỉ chậm hay bị mất, thường dẫn đến việc thử lại không cần thiết hoặc hết thời gian chờ kết nối. Mã 102 hoạt động như một nhịp tim, nói với máy khách: "Chờ chút, tôi đang làm việc!"

Vai trò của 102 trong WebDAV

102 Processing ban đầu được giới thiệu trong WebDAV (Web Distributed Authoring and Versioning), mở rộng HTTP để quản lý tệp cộng tác.

Ví dụ, nếu người dùng tải lên một tệp 500 MB:

• Máy chủ có thể cần vài phút để xử lý nó.
• Thay vì im lặng, máy chủ có thể định kỳ phản hồi bằng 102 Processing.
• Điều này trấn an máy khách rằng yêu cầu vẫn đang hoạt động.

Mặc dù WebDAV là động lực chính, 102 cũng có thể hữu ích trong các API REST hiện đại và các dịch vụ đám mây xử lý khối lượng công việc nặng.

Sự khác biệt giữa 100 Continue và 102 Processing

Bạn có thể tự hỏi 102 khác với 100 Continue tương tự như thế nào:

• 100 Continue: Được gửi trước khi máy khách gửi phần thân yêu cầu. Nó báo hiệu máy chủ đã sẵn sàng nhận toàn bộ tải trọng.
• 102 Processing: Được gửi sau khi toàn bộ yêu cầu đã được nhận, cho máy khách biết rằng quá trình xử lý thực tế vẫn đang diễn ra.

Cùng nhau, các mã trạng thái này cải thiện hiệu quả giao tiếp trong các chu kỳ yêu cầu phức tạp.

Cách thức hoạt động: Luồng giao tiếp

Hãy cùng xem một ví dụ giả định về phản hồi 102 Processing đang hoạt động.

Kịch bản: Một máy khách yêu cầu máy chủ "xử lý tất cả các hình ảnh đã tải lên để tạo ảnh toàn cảnh." Đây là một tác vụ tiêu tốn CPU sẽ mất 90 giây.

Yêu cầu:

Máy khách gửi yêu cầu POST đến /api/generate-panorama.

Phản hồi ngay lập tức (102):

API của máy chủ nhận yêu cầu và xác thực nó. Nó biết công việc sẽ mất một thời gian. Thay vì im lặng, nó ngay lập tức gửi lại:

HTTP/1.1 102 Processing

Phản hồi này không có phần thân. Nó chỉ là một dòng trạng thái và các tiêu đề. Công việc duy nhất của nó là nói, "Tôi đang làm việc với nó."

Thời gian chờ:

Máy khách nhận mã 102. Một máy khách hoạt động tốt hiểu rằng điều này có nghĩa là nó nên giữ kết nối mở và tiếp tục chờ. Bộ đếm thời gian chờ của máy khách được đặt lại một cách hiệu quả.

Phản hồi cuối cùng:

Chín mươi giây sau, máy chủ hoàn thành việc tạo ảnh toàn cảnh. Bây giờ nó gửi phản hồi thực sự qua cùng một kết nối:

HTTP/1.1 200 OKContent-Type: application/json
{"status": "success", "url": "/images/panorama-123.jpg"}

Chu kỳ yêu cầu-phản hồi hiện đã hoàn tất.

Tín hiệu "giữ kết nối" đơn giản này ngăn thiết bị mạng và máy khách nhầm tưởng rằng máy chủ đã chết.

Tại sao 102 Processing không phổ biến hơn?

Nếu điều này hữu ích như vậy, tại sao hầu hết các nhà phát triển chưa bao giờ thấy hoặc sử dụng nó? Có một vài lý do chính:

Sự trỗi dậy của các mẫu bất đồng bộ: Giải pháp hiện đại cho các yêu cầu kéo dài thường tốt hơn 102 Processing. Thay vì giữ một kết nối mở trong vài phút, thực hành tốt nhất hiện nay là:

• Chấp nhận yêu cầu ngay lập tức và trả về mã trạng thái 202 Accepted.
• Trả về một ID duy nhất cho công việc và một URL mà máy khách có thể kiểm tra trạng thái của nó sau này (ví dụ: Location: /api/jobs/job-123).
• Xử lý công việc bất đồng bộ trong một trình xử lý nền (ví dụ: sử dụng Redis Queue, Celery hoặc Amazon SQS).
• Cho phép máy khách thăm dò URL trạng thái hoặc sử dụng webhook để thông báo cho máy khách khi công việc hoàn tất.

Mẫu này có khả năng mở rộng hơn. Nó không làm tắc nghẽn các tiến trình hoặc kết nối máy chủ quý giá chờ đợi các tác vụ dài.

Hỗ trợ máy khách hạn chế: Để 102 Processing hoạt động, máy khách phải biết cách xử lý nó. Không phải tất cả các máy khách và thư viện HTTP đều được xây dựng để mong đợi hoặc diễn giải chính xác nhiều phản hồi trên một kết nối duy nhất. Mẫu bất đồng bộ với thăm dò được hiểu phổ biến.

Nó không giải quyết tất cả các vấn đề: Phản hồi 102 đặt lại thời gian chờ cho kết nối, nhưng nó không cung cấp bất kỳ cập nhật tiến độ nào. Máy khách vẫn không biết liệu công việc đã hoàn thành 1% hay 99%. Mẫu thăm dò cho phép có trường tiến độ trong phản hồi trạng thái.

Ví dụ về 102 Processing trong thực tế

Hãy xem điều này có thể trông như thế nào trong thực tế.

Yêu cầu của máy khách:

PUT /files/large-video.mp4 HTTP/1.1
Host: example.com
Content-Length: 600000000

Phản hồi của máy chủ (trong khi vẫn đang làm việc):

HTTP/1.1 102 Processing

Phản hồi cuối cùng của máy chủ (sau khi hoàn tất):

HTTP/1.1 201 Created
Location: /files/large-video.mp4

Ở đây, phản hồi 102 trấn an máy khách rằng tiến trình đang diễn ra trước khi có 201 Created cuối cùng.

Các trường hợp sử dụng và lựa chọn thay thế hiện đại

Mặc dù 102 Processing thuần túy hiếm khi được sử dụng, vấn đề mà nó giải quyết thì không. Web hiện đại đã áp dụng các chiến lược khác mạnh mẽ và có khả năng mở rộng hơn:

1. 202 Accepted + Thăm dò: Như đã mô tả ở trên, đây là mẫu phổ biến và có khả năng mở rộng nhất hiện nay.
2. Server-Sent Events (SSE): Đối với các hoạt động kéo dài mà máy chủ muốn đẩy các cập nhật tiến độ, SSE cung cấp một kênh một chiều để máy chủ gửi nhiều sự kiện đến máy khách.
3. Webhooks: Sự tách rời tối ưu. Máy chủ xử lý công việc và sau đó gửi một lệnh gọi lại (webhook) đến một URL do máy khách cung cấp để thông báo cho nó về việc hoàn thành.

Tuy nhiên, 102 Processing vẫn có thể là một công cụ hữu ích trong các kịch bản cụ thể, đặc biệt là trong các API nội bộ hoặc các hệ thống nơi:

• Bạn cần một giao diện đồng bộ nhưng thỉnh thoảng có các hoạt động kéo dài.
• Bạn kiểm soát cả máy khách và máy chủ và có thể đảm bảo cả hai xử lý mã 102 một cách chính xác.
• Hoạt động kéo dài, nhưng không đủ dài để biện minh cho sự phức tạp của một hệ thống công việc bất đồng bộ hoàn chỉnh.

Các trường hợp sử dụng trong thế giới thực

Bạn có thể gặp 102 Processing trong đời thực ở đâu?

• Tải lên tệp: Gửi dữ liệu lớn nơi tệp được nhận, nhưng quá trình xử lý mất nhiều thời gian hơn.
• Các hoạt động cơ sở dữ liệu: Chạy các truy vấn hoặc cập nhật dài.
• Các công việc hàng loạt: Các yêu cầu kích hoạt các quy trình làm việc phức tạp hoặc các công việc backend nhiều bước.
• Các hệ thống phân tán: Các tác vụ mất nhiều thời gian hơn do nhiều phụ thuộc dịch vụ.
• Các máy khách WebDAV: 102 Processing có nguồn gốc từ các phần mở rộng WebDAV, nơi các yêu cầu có thể liên quan đến nhiều hoạt động phụ mất thời gian đáng kể.

Máy khách nên làm gì khi nhận được 102 Processing?

Phản hồi 102 hoàn toàn mang tính thông tin, vì vậy máy khách thường:

• Giữ kết nối mở và chờ trạng thái cuối cùng.
• Tránh gửi lại yêu cầu do hết thời gian chờ vì máy chủ cho biết nó đang tích cực xử lý.
• Hiển thị các chỉ báo tải hoặc thông tin tiến độ nếu áp dụng cho UX.

Hầu hết các máy khách HTTP hiện đại xử lý 102 một cách duyên dáng hoặc bỏ qua nó vì nó không kết thúc giao dịch.

Tác động của 102 Processing đến trải nghiệm người dùng và hiệu suất

Mặc dù 102 giúp ngăn chặn thời gian chờ sớm, nhưng nó có thể làm tăng sự phức tạp:

• Nó có thể làm cho tương tác máy khách-máy chủ cảm thấy chậm hơn nếu máy khách không được thiết kế để xử lý tốt.
• Máy chủ cần cẩn thận quyết định khi nào gửi 102 để tránh làm ngập máy khách với quá nhiều trạng thái trung gian.
• Hữu ích trong các API yêu cầu thăm dò dài hoặc phát trực tuyến nơi việc duy trì kết nối là cần thiết.

Lợi ích của 102 Processing

Tại sao phải bận tâm với 102 Processing?

• Ngăn chặn thời gian chờ sớm: Giữ kết nối máy khách hoạt động.
• Cải thiện độ tin cậy: Máy khách biết máy chủ đang tích cực xử lý.
• Nâng cao trải nghiệm người dùng: Tránh sự thất vọng với sự chậm trễ “im lặng”.
• Hỗ trợ các hoạt động dài một cách duyên dáng: Đặc biệt trong các API cấp doanh nghiệp.

Các vấn đề và cạm bẫy thường gặp

Mặc dù hữu ích, có một vài lưu ý:

• Không được triển khai rộng rãi: Nhiều máy chủ và framework không hỗ trợ nó theo mặc định.
• Khả năng tương thích của máy khách: Một số máy khách HTTP bỏ qua mã 1xx.
• Chi phí: Gửi quá nhiều phản hồi 102 có thể thêm lưu lượng mạng không cần thiết.
• Cân nhắc bảo mật: Phải đảm bảo các phản hồi không bị giả mạo hoặc lạm dụng.
• Khó khăn trong kiểm thử: Kiểm thử các yêu cầu liên quan đến phản hồi 102 yêu cầu các công cụ nắm bắt mã phản hồi tạm thời.
• Sử dụng quá mức có thể gây nhầm lẫn cho máy khách: Các thông báo thông tin quá mức có thể gây ra sự phức tạp không cần thiết.

Kiểm thử API với Apidog

Khi làm việc với các mã trạng thái như 102 Processing, điều cần thiết là phải kiểm thử chúng đúng cách, nhưng việc kiểm thử các API sử dụng 102 Processing có thể khó khăn vì các phản hồi bất đồng bộ và đa giai đoạn.

Đây là lúc Apidog thực sự tỏa sáng:

• Mô phỏng các yêu cầu có thể kích hoạt phản hồi 102.
• Ghi lại toàn bộ chu kỳ yêu cầu-phản hồi, bao gồm các trạng thái thông tin.
• Tự động hóa các kiểm thử khẳng định việc xử lý đúng các giai đoạn xử lý kéo dài.
• Cung cấp nhật ký chi tiết để gỡ lỗi nơi xảy ra sự chậm trễ hoặc lỗi.
• Chia sẻ kiểm thử với nhóm của bạn để giữ mọi thứ nhất quán.

Nếu bạn nghiêm túc về phát triển API, Apidog giúp việc gỡ lỗi các mã trạng thái hiếm trở nên dễ dàng. Tải xuống Apidog miễn phí và làm chủ việc kiểm thử API của bạn, bao gồm cả những API xử lý các quy trình làm việc 102 Processing phức tạp.

Các phương pháp hay nhất cho nhà phát triển

Dưới đây là một số mẹo khi làm việc với 102 Processing:

• Chỉ sử dụng nó cho các tác vụ kéo dài.
• Không gửi quá nhiều phản hồi 102 không cần thiết.
• Luôn theo dõi nó bằng một phản hồi cuối cùng (ví dụ: 200 hoặc 201).
• Kiểm thử kỹ lưỡng bằng các công cụ như Apidog.
• Tài liệu hóa việc sử dụng nó rõ ràng trong tài liệu API của bạn.

Kết luận: Một công cụ thích hợp trong thế giới hiện đại

Vậy, mã trạng thái 102 Processing là gì?

Tóm lại, đó là một tín hiệu từ máy chủ nói rằng:

"Tôi đã nhận được yêu cầu của bạn và tôi đang làm việc với nó. Đừng bỏ cuộc vội!"

Nó đặc biệt có giá trị đối với các yêu cầu kéo dài mà sự im lặng có thể khiến máy khách cho rằng có lỗi. Mặc dù nó không phổ biến như các mã khác, nhưng nó là một công cụ mạnh mẽ trong các tình huống phù hợp.

Mã trạng thái HTTP 102 Processing là một di tích hấp dẫn của một thời điểm cụ thể trong phát triển web, được thiết kế để giải quyết một vấn đề cấp bách trong giao thức WebDAV. Mặc dù nó đã bị thay thế phần lớn bởi các mẫu bất đồng bộ có khả năng mở rộng hơn, nhưng nó vẫn là một phần hợp lệ và đôi khi hữu ích của đặc tả HTTP.

Hiểu 102 Processing giúp bạn hiểu sâu hơn về những thách thức của lập trình mạng và sự phát triển của thiết kế API. Nó làm nổi bật sự căng thẳng liên tục giữa sự đơn giản đồng bộ và khả năng mở rộng bất đồng bộ.

Đối với hầu hết các ứng dụng hiện đại, mẫu 202 Accepted với thăm dò hoặc webhook là lựa chọn ưu việt. Nhưng việc biết rằng 102 tồn tại cho phép bạn đưa ra quyết định kiến trúc sáng suốt. Và khi bạn cần kiểm thử bất kỳ hành vi API kéo dài nào, cho dù nó sử dụng 102, 202 hay bất kỳ mã trạng thái nào khác bằng một công cụ mạnh mẽ như Apidog sẽ cung cấp cho bạn khả năng kiểm soát và khả năng hiển thị mà bạn cần để đảm bảo trải nghiệm người dùng mượt mà và đáng tin cậy, bất kể yêu cầu mất bao lâu, bạn có thể mô phỏng các yêu cầu, kiểm tra các phản hồi trung gian và gỡ lỗi API như một chuyên gia.

Đừng chỉ đọc về nó, hãy tải xuống Apidog miễn phí và bắt đầu thử nghiệm ngay hôm nay.