Blog

Mã Trạng Thái 101 Switching Protocols Là Gì?

INEZA Felin-Michel

INEZA Felin-Michel

9 tháng 9 2025

Mã Trạng Thái 101 Switching Protocols Là Gì?

Apidog cho doanh nghiệp

Triển khai tại chỗ

SSO & RBAC

Tuân thủ SOC 2

Khám phá Apidog Enterprise

Bạn đang sử dụng tính năng trò chuyện trực tiếp trên một trang web. Tin nhắn xuất hiện ngay lập tức mà không cần bạn phải làm mới trang. Bạn đang chơi một trò chơi trên trình duyệt, nơi mọi hành động của người chơi được phản ánh trên màn hình của bạn theo thời gian thực. Phép thuật này có vẻ liền mạch, nhưng bên dưới, một sự biến đổi quan trọng đang diễn ra. Ngôn ngữ mà trình duyệt của bạn đang sử dụng để nói chuyện với máy chủ đang thay đổi giữa cuộc trò chuyện.

Sự biến đổi này được thực hiện nhờ một trong những mã trạng thái HTTP năng động và đặc biệt nhất: 101 Switching Protocols.

Không giống như các mã trạng thái phổ biến hơn báo cáo về sự thành công hay thất bại của một yêu cầu, mã trạng thái 101 là một hành động. Nó không phải là một báo cáo; nó là một yếu tố kích hoạt. Đó là cách máy chủ nói, "Được rồi, chúng ta hãy ngừng sử dụng HTTP cho cuộc trò chuyện này và chuyển sang thứ gì đó phù hợp hơn cho công việc."

Nó tương đương với việc hai điệp viên gặp nhau trong công viên công cộng. Họ bắt đầu bằng một cuộc trò chuyện bình thường, thông thường (HTTP) để đảm bảo mọi thứ an toàn. Sau đó, khi đã xác minh lẫn nhau, một người nói, "Đại bàng đã hạ cánh" (tiêu đề Upgrade). Người kia gật đầu và nói, "Đi theo tôi" (phản hồi 101). Sau đó, họ rời khỏi không gian công cộng và chuyển sang một kênh liên lạc an toàn, riêng tư và hiệu quả cao (như WebSocket).

Nếu bạn tò mò về cách các ứng dụng web thời gian thực thoát khỏi những hạn chế của HTTP truyền thống, mã này chính là chìa khóa bạn đang tìm kiếm.

Và trước khi chúng ta đi sâu vào quá trình bắt tay kỹ thuật, nếu bạn là nhà phát triển đang xây dựng các tính năng thời gian thực như trò chuyện, nguồn cấp dữ liệu trực tiếp hoặc trò chơi nhiều người chơi, bạn cần một công cụ có thể gỡ lỗi các cuộc đàm phán giao thức phức tạp này. Hơn hết, bạn có thể tải xuống Apidog miễn phí và bắt đầu ngay hôm nay; đó là một nền tảng API tất cả trong một cung cấp khả năng hiển thị sâu sắc về toàn bộ vòng đời kết nối, bao gồm cả quá trình nâng cấp 101 quan trọng, giúp bạn đảm bảo các kết nối WebSocket và các giao thức khác được thiết lập hoàn hảo.

button

Bây giờ, hãy cùng vén màn về sự chuyển đổi giao thức hấp dẫn này.

Thiết lập: Công cụ phù hợp cho công việc

Để hiểu tại sao chúng ta cần chuyển đổi giao thức, trước tiên chúng ta phải hiểu giới hạn của giao thức HTTP tiêu chuẩn.

HTTP được xây dựng trên một mô hình yêu cầu-phản hồi đơn giản, không trạng thái.

  1. Client: "Tôi có thể xem trang chủ không?" (GET /)
  2. Server: "Đây là nó." (200 OK + HTML)
  3. Kết nối: Cuộc trò chuyện về cơ bản đã kết thúc. Mọi dữ liệu mới đều yêu cầu một yêu cầu hoàn toàn mới.

Điều này hoàn hảo để tải tài liệu, hình ảnh và biểu định kiểu. Nhưng nó tệ cho bất cứ thứ gì yêu cầu giao tiếp hai chiều, thời gian thực, liên tục.

Hãy tưởng tượng bạn cố gắng có một cuộc trò chuyện trôi chảy mà sau mỗi câu, bạn lại cúp điện thoại và phải gọi lại. Đó là cách xây dựng một ứng dụng trò chuyện trên HTTP thuần túy. Đây thường được gọi là vấn đề "HTTP polling", và nó cực kỳ kém hiệu quả.

Chúng ta cần một giao thức khác cho các tác vụ thời gian thực – một giao thức cho phép kết nối liên tục mà cả hai bên có thể gửi tin nhắn bất cứ lúc nào. Nổi tiếng nhất trong số này là giao thức WebSocket.

Nhưng có một thách thức: làm thế nào một cuộc trò chuyện bắt đầu dưới dạng yêu cầu HTTP (cách tất cả lưu lượng truy cập web bắt đầu) có thể biến đổi thành kết nối WebSocket?

Câu trả lời là mã trạng thái HTTP 101 Switching Protocols.

Mã trạng thái 101 Switching Protocols là gì?

Mã trạng thái HTTP 101 Switching Protocols thuộc lớp phản hồi 1xx (Thông tin). Giống như các mã 1xx khác (chẳng hạn như 100 Continue), nó không phải là phản hồi cuối cùng. Thay vào đó, nó là một tín hiệu từ máy chủ rằng có điều gì đó đặc biệt đang xảy ra.

Cụ thể, 101 Switching Protocols cho client biết:

“Tôi hiểu yêu cầu của bạn về việc thay đổi giao thức truyền thông, và tôi đã đồng ý chuyển đổi.”

Ví dụ:

Điều này cho phép các phương pháp truyền thông hiện đại, hiệu quả hơn trong khi vẫn duy trì khả năng tương thích ngược với cơ sở hạ tầng HTTP hiện có.

Tại sao 101 Switching Protocols tồn tại?

Để hiểu tại sao mã trạng thái này tồn tại, hãy xem một phép ẩn dụ đơn giản.

Hãy tưởng tượng bạn bước vào một phòng họp và bắt đầu nói tiếng Anh. Giữa chừng, ai đó nói, "Hãy chuyển sang tiếng Tây Ban Nha – sẽ dễ dàng hơn cho mọi người." Nếu mọi người đồng ý, cuộc trò chuyện sẽ tiếp tục liền mạch bằng tiếng Tây Ban Nha.

Đó về cơ bản là những gì xảy ra với 101 Switching Protocols.

HTTP ban đầu được thiết kế như một giao thức yêu cầu-phản hồi không trạng thái để tìm nạp tài liệu. Nhưng khi các ứng dụng web phát triển, nhu cầu về giao tiếp client-server thời gian thực, song công hoàn toàn hoặc thông minh hơn đã nảy sinh.

Mã trạng thái 101 được giới thiệu để cho phép client và server nâng cấp giao thức giữa kết nối mà không cần đóng và mở lại một kết nối mới. Cơ chế nâng cấp này mang lại lợi ích cho các tình huống như:

Nếu không có 101 Switching Protocols, những chuyển đổi liền mạch này sẽ không thể thực hiện được hoặc sẽ yêu cầu các lần đặt lại kết nối tốn kém.

Cách hoạt động của việc chuyển đổi giao thức trong chu trình yêu cầu-phản hồi

Đây là một phân tích đơn giản về quá trình bắt tay 101 Switching Protocols:

Client → Server:

Client gửi một yêu cầu HTTP với tiêu đề Upgrade. Ví dụ:

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade

Server → Client:

Nếu máy chủ hỗ trợ nâng cấp được yêu cầu, nó sẽ trả lời bằng:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

Client & Server:

Từ thời điểm này trở đi, họ ngừng sử dụng HTTP và bắt đầu giao tiếp qua giao thức đã nâng cấp (trong trường hợp này là WebSocket).

Cuộc trò chuyện HTTP đã kết thúc. Nếu bạn gửi một yêu cầu HTTP khác qua cùng kết nối này, nó sẽ thất bại. Các quy tắc của trò chơi đã thay đổi hoàn toàn. Bây giờ, cả hai bên có thể gửi các khung dữ liệu WebSocket (tin nhắn) qua lại tùy ý, theo cách song công hoàn toàn, thời gian thực.

Ví dụ về 101 Switching Protocols trong thực tế

Giả sử bạn đang xây dựng một ứng dụng trò chuyện sử dụng WebSockets. Đây là cách nó có thể trông như thế nào bên dưới.

Yêu cầu từ Client (khởi tạo nâng cấp WebSocket):

GET /chat HTTP/1.1
Host: chat.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Version: 13

Phản hồi từ Server (đồng ý chuyển đổi):

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=

Từ đây, kết nối HTTP được nâng cấp thành kết nối WebSocket. Các tin nhắn hiện được trao đổi theo thời gian thực qua một kết nối liên tục.

Ngoài WebSockets: Các trường hợp sử dụng khác cho 101

Mặc dù WebSockets là trường hợp sử dụng nổi tiếng nhất, cơ chế Upgrade là một tính năng đa năng của HTTP/1.1. Nó cũng có thể được sử dụng để đàm phán các giao thức khác.

Tuy nhiên, trong thực tế, việc áp dụng rộng rãi và các yêu cầu bảo mật của web hiện đại đã khiến việc nâng cấp WebSocket trở thành trường hợp sử dụng chính, và gần như độc quyền, cho mã trạng thái 101 Switching Protocols.

Các trường hợp sử dụng thực tế (Đặc biệt là WebSockets)

Trường hợp sử dụng phổ biến nhất cho 101 Switching Protocols là WebSockets, cho phép giao tiếp hai chiều, thời gian thực giữa client và server.

Một số ví dụ bao gồm:

Một trường hợp sử dụng khác liên quan đến việc nâng cấp HTTP/2 và HTTP/3, mặc dù những trường hợp này ít phổ biến hơn vì hầu hết các trình duyệt đều tự động xử lý chúng.

Tại sao quá trình bắt tay này lại cần thiết? Sự thiên tài trong thiết kế

Bạn có thể tự hỏi tại sao chúng ta cần quá trình bắt tay HTTP phức tạp này. Tại sao không chỉ mở kết nối WebSocket trực tiếp?

  1. Khả năng tương thích với cơ sở hạ tầng Web: Toàn bộ web được xây dựng trên HTTP. Tường lửa, proxy, bộ cân bằng tải và bộ định tuyến đều được cấu hình để hiểu và cho phép lưu lượng HTTP trên các cổng 80 và 443. Bằng cách bắt đầu như một yêu cầu HTTP, quá trình bắt tay WebSocket trông giống như bất kỳ lưu lượng truy cập web nào khác, đảm bảo nó có thể đi qua hầu hết cơ sở hạ tầng mạng mà không bị chặn. Đó là một chiến lược "ngựa thành Troy" thông minh.
  2. Bảo mật: Quá trình bắt tay cho phép sử dụng tất cả các tính năng HTTP tiêu chuẩn để xác thực và ủy quyền trước khi nâng cấp. Yêu cầu GET ban đầu có thể bao gồm cookie và tiêu đề Authorization. Máy chủ có thể kiểm tra xem người dùng đã đăng nhập và có quyền mở kênh thời gian thực trước khi đồng ý nâng cấp 101.
  3. Đàm phán giao thức: Quá trình bắt tay cho phép client và server đồng ý về giao thức nào và phiên bản nào của giao thức đó sẽ sử dụng. Tiêu đề Sec-WebSocket-Version đảm bảo cả hai đều nói cùng một "phương ngữ" của WebSocket.

Điều gì xảy ra nếu máy chủ không hỗ trợ nâng cấp?

Nếu máy chủ không chấp nhận yêu cầu nâng cấp, nó thường sẽ:

Lợi ích của việc chuyển đổi giao thức

Tại sao lại sử dụng 101 Switching Protocols? Dưới đây là những lợi thế:

Các vấn đề thường gặp và ý nghĩa của chúng

Nếu bạn đang triển khai máy chủ WebSocket, đây là ý nghĩa của các phản hồi máy chủ khác nhau:

Xử lý trạng thái 101 Switching Protocols trong ứng dụng của bạn

Nếu bạn đang xây dựng các ứng dụng yêu cầu chuyển đổi giao thức:

Đây là nơi các API và nền tảng kiểm thử trở nên quan trọng.

Gỡ lỗi 101: Sự chuyển đổi vô hình

Đối với các nhà phát triển, quá trình 101 có thể khó gỡ lỗi vì đó là một khoảnh khắc chuyển tiếp. Khi quá trình chuyển đổi xảy ra, các công cụ gỡ lỗi HTTP tiêu chuẩn thường mất khả năng hiển thị.

Đây là lúc một nền tảng API tinh vi như Apidog trở nên không thể thiếu. Apidog không chỉ dành cho các API REST; nó có hỗ trợ hạng nhất cho WebSockets.

Với Apidog, bạn có thể:

  1. Tạo yêu cầu WebSocket: Dễ dàng chỉ định URL WebSocket (ws:// hoặc wss://).
  2. Kiểm tra quá trình bắt tay: Apidog sẽ hiển thị cho bạn yêu cầu nâng cấp HTTP thô và phản hồi 101 của máy chủ, cho phép bạn xác minh các tiêu đề và tính toán Sec-WebSocket-Accept.
  3. Kiểm tra kết nối: Sau khi nâng cấp, bạn có thể chuyển sang giao diện WebSocket để gửi và nhận tin nhắn (khung), cho phép bạn kiểm tra kỹ lưỡng logic thời gian thực của mình.
  4. Gỡ lỗi lỗi: Nếu quá trình nâng cấp thất bại (ví dụ: máy chủ trả về 400 Bad Request thay vì 101), Apidog giúp bạn xem lý do – có thể là thiếu tiêu đề hoặc lỗi xác thực trong yêu cầu ban đầu.

Khả năng hiển thị này biến quá trình nâng cấp từ một hộp đen bí ẩn thành một chuỗi sự kiện minh bạch, có thể gỡ lỗi được.

Kiểm thử chuyển đổi giao thức với Apidog

Khi bạn đang xây dựng API hoặc ứng dụng hỗ trợ WebSocket, điều cần thiết là phải kiểm thử nâng cấp giao thức. Kiểm thử nâng cấp giao thức có thể khó khăn vì nó liên quan đến nhiều giai đoạn và các phương thức giao tiếp khác nhau.

Đây là lúc Apidog phát huy tác dụng:

button

Tóm lại, Apidog giúp việc xử lý các quy trình làm việc phức tạp như chuyển đổi giao thức dễ dàng hơn nhiều. Hãy dùng thử Apidog miễn phí và tăng cường sự tự tin của bạn khi triển khai API hoặc ứng dụng phụ thuộc vào việc nâng cấp giao thức!

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

Dưới đây là một số mẹo để xử lý 101 Switching Protocols đúng cách:

Bức tranh lớn hơn: Kích hoạt Web thời gian thực

Mã trạng thái HTTP 101 Switching Protocols là một yếu tố nhỏ nhưng mạnh mẽ cho phép trải nghiệm web hiện đại. Nó là cầu nối quan trọng giữa thế giới tập trung vào tài liệu của HTTP và thế giới tương tác, năng động của giao tiếp thời gian thực.

Nếu không có cơ chế này, các công nghệ như WebSockets sẽ khó triển khai ở quy mô lớn hơn nhiều, và các ứng dụng web phản hồi nhanh, trực tiếp mà chúng ta coi là đương nhiên – từ các công cụ cộng tác như Google Docs đến cập nhật thể thao trực tiếp và hệ thống thông báo – sẽ cồng kềnh và kém hiệu quả hơn nhiều.

Kết luận: Hơn cả một mã trạng thái

Vậy, mã trạng thái 101 Switching Protocols là gì? Nói một cách đơn giản, đó là máy chủ nói:

“Tôi đồng ý chuyển từ HTTP sang một giao thức khác, như WebSocket.”

101 là một ví dụ hấp dẫn về một giải pháp thực dụng và thanh lịch cho một vấn đề phức tạp. Nó không chỉ là một con số; nó là một cánh cổng. Nó đại diện cho sự linh hoạt và tiến hóa của các tiêu chuẩn web, cho phép các giao thức chuyên biệt mới xuất hiện trong khi vẫn duy trì khả năng tương thích ngược với toàn bộ cơ sở hạ tầng web hiện có. Mã trạng thái này là tất cả về sự linh hoạt và hiệu quả, cho phép các ứng dụng thời gian thực, giao tiếp nhanh hơn và các trường hợp sử dụng hiện đại như trò chuyện, trò chơi và cập nhật chứng khoán.

Hiểu mã này giúp bạn đánh giá sâu sắc hơn về kỹ thuật đã làm cho web thời gian thực trở nên khả thi. Và nếu bạn đang kiểm thử API, gỡ lỗi nâng cấp WebSocket hoặc đơn giản là khám phá các mã trạng thái HTTP, Apidog là công cụ bạn cần. Nó giúp việc kiểm thử, tài liệu hóa và gỡ lỗi API cực kỳ dễ dàng – bao gồm cả những API liên quan đến việc chuyển đổi giao thức.

Vậy tại sao phải chờ đợi? Tải xuống Apidog miễn phí ngay hôm nay và bắt đầu thử nghiệm chuyển đổi giao thức đúng cách, đồng thời điều hướng quá trình nâng cấp với sự tự tin, rõ ràng và kiểm soát.

button

Thực hành thiết kế API trong Apidog

Khám phá cách dễ dàng hơn để xây dựng và sử dụng API

Đăng ký miễn phíTải xuống