WebSocket cung cấp cho bạn một kênh hai chiều, liên tục giữa máy khách và máy chủ thông qua một kết nối TCP duy nhất. Sau khi kết nối được mở, cả hai bên đều có thể gửi tin nhắn bất cứ lúc nào, đây là lý do tại sao nó trở thành xương sống của các ứng dụng trò chuyện trực tiếp, nguồn cấp dữ liệu giao dịch, trò chơi nhiều người chơi và bảng điều khiển. Kiểm thử nó là một bài tập khác so với kiểm thử một API yêu cầu-phản hồi, bởi vì không có một phản hồi duy nhất để kiểm tra. Có một luồng dữ liệu.
Hướng dẫn này mang tính thực tế. Nó bao gồm những gì curl có thể và không thể làm với WebSocket, cách sử dụng công cụ chuyên dụng websocat, và khi nào một client GUI là lựa chọn tốt hơn. Mọi lệnh ở đây đều có thật và sẵn sàng để sao chép.
Tại sao kiểm thử WebSocket không giống kiểm thử REST
Một kiểm thử REST là một giao dịch. Bạn gửi một yêu cầu, bạn nhận được một phản hồi, bạn khẳng định nó, bạn hoàn thành. Một kiểm thử WebSocket là một cuộc trò chuyện. Bạn mở một kết nối một lần, sau đó trao đổi nhiều tin nhắn trong suốt vòng đời của nó, và các tin nhắn có thể đến mà không cần yêu cầu.
Điều đó thay đổi những gì bạn kiểm tra. Bạn xác nhận kết nối được nâng cấp đúng cách từ HTTP. Bạn xác nhận máy chủ chấp nhận tin nhắn đầu tiên của bạn và trả lời như mong đợi. Bạn xác nhận rằng các tin nhắn được máy chủ đẩy đến mà không cần bạn yêu cầu. Bạn theo dõi cách kết nối đóng, và với mã đóng nào. Một công cụ được xây dựng cho các yêu cầu một lần gặp khó khăn với tất cả những điều này, đó là lý do tại sao curl, công cụ HTTP phổ quát, chỉ phù hợp một phần. Đối với bức tranh kiểm thử rộng hơn, sự khác biệt giữa một kịch bản kiểm thử và một trường hợp kiểm thử khớp gọn gàng với một cuộc trò chuyện WebSocket so với một lần kiểm tra tin nhắn duy nhất.
Quy trình bắt tay WebSocket
Mọi kết nối WebSocket bắt đầu như một yêu cầu HTTP yêu cầu được nâng cấp. Máy khách gửi các tiêu đề Upgrade: websocket và Connection: Upgrade cộng với một Sec-WebSocket-Key, và máy chủ trả lời bằng HTTP 101 Switching Protocols. Sau đó, kết nối không còn là HTTP. Nó sử dụng giao thức khung WebSocket được định nghĩa trong RFC 6455.
Đây là nguồn gốc của hạn chế của curl. curl cổ điển chỉ giao tiếp HTTP. Nó có thể gửi các tiêu đề nâng cấp, nhưng nó không thể đóng khung và giải khung các tin nhắn WebSocket sau quy trình bắt tay. Cố gắng giả lập một phiên WebSocket đầy đủ bằng các cờ tiêu đề thô không hoạt động vượt quá quy trình bắt tay. Bạn cần một công cụ hiểu các khung.
Kiểm thử WebSocket với curl
Phiên bản curl hiện đại, từ 7.86 trở lên, đã bổ sung hỗ trợ WebSocket gốc thử nghiệm. Nó thực sự có thể sử dụng được cho các kiểm tra đơn giản, với lưu ý rằng nó vẫn được đánh dấu là thử nghiệm.
Đầu tiên xác nhận phiên bản của bạn:
curl --version
Nếu bạn đang sử dụng phiên bản 7.86 trở lên, bạn có thể kết nối trực tiếp đến một điểm cuối WebSocket. Đây là một kết nối đến một máy chủ echo công cộng, nó sẽ trả lời bằng bất cứ điều gì bạn gửi:
curl --include --no-buffer \
--header "Connection: Upgrade" \
--header "Upgrade: websocket" \
--header "Sec-WebSocket-Version: 13" \
--header "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
https://echo.websocket.org
Cờ --include hiển thị các tiêu đề phản hồi để bạn có thể xác nhận trạng thái 101, và --no-buffer ngăn curl giữ đầu ra, điều này quan trọng đối với một luồng. Đối với các kết nối an toàn, hãy sử dụng URL wss:// chính xác như bạn sử dụng https://.
Hỗ trợ WebSocket của curl nổi bật ở một điểm: xác nhận một điểm cuối có thể truy cập được và hoàn tất việc nâng cấp. Nó khá khó xử cho một phiên tương tác nơi bạn gửi nhiều tin nhắn và đọc các phản hồi, bởi vì curl không được xây dựng xung quanh một vòng lặp tin nhắn. Đối với một kiểm tra nhanh "điểm cuối này có hoạt động không" trong một script, nó ổn. Đối với kiểm thử tương tác thực sự, hãy tìm một công cụ chuyên dụng. Nếu bạn đang viết script các kiểm tra này vào một pipeline, hướng dẫn của chúng tôi về tự động hóa kiểm thử API trong CI/CD bao gồm cách kết nối các kiểm tra dòng lệnh vào một bản dựng.
Kiểm thử WebSocket với websocat
websocat là công cụ dòng lệnh mà hầu hết mọi người thực sự muốn sử dụng cho công việc WebSocket. Nó được xây dựng chuyên dụng, hiểu đúng các khung và hoạt động như một netcat cho WebSocket.
Cài đặt nó bằng trình quản lý gói của bạn, ví dụ brew install websocat trên macOS hoặc thông qua cargo install websocat. Sau đó, kết nối và trò chuyện chỉ bằng một lệnh:
websocat wss://echo.websocket.org
Thao tác đó mở một phiên tương tác. Nhập một dòng, nhấn enter, và nó được gửi đi như một tin nhắn. Các phản hồi của máy chủ sẽ in ra khi chúng đến. Để gửi một tin nhắn duy nhất và thoát, hãy chuyển nó qua đường ống:
echo '{"action":"subscribe","channel":"prices"}' | websocat wss://stream.example.com/feed
websocat cũng xử lý các tính năng bổ sung hữu ích. Bạn có thể truyền các tiêu đề cho các điểm cuối được xác thực:
websocat --header "Authorization: Bearer your-token-here" wss://api.example.com/socket
Và bạn có thể chạy nó như một máy chủ cục bộ để kiểm thử một máy khách, hoặc cầu nối WebSocket với một cổng TCP thuần túy. Đối với kiểm thử WebSocket dòng lệnh, websocat bao gồm gần như mọi thứ mà curl không thể. Xử lý các khẳng định theo cách tương tự như bạn làm ở nơi khác; các ghi chú của chúng tôi về viết các khẳng định API hữu ích cũng áp dụng cho việc kiểm tra tải trọng tin nhắn.
Kiểm thử WebSocket bằng công cụ GUI
Các công cụ dòng lệnh rất tuyệt vời cho các script và kiểm tra nhanh. Chúng mệt mỏi cho việc kiểm thử thăm dò, nơi bạn muốn xem dòng thời gian tin nhắn, gửi JSON có cấu trúc một cách thoải mái và giữ kết nối mở trong khi bạn thử nghiệm.
Apidog có một client WebSocket chuyên dụng được xây dựng cho mục đích này. Bạn nhập một URL ws:// hoặc wss://, kết nối và xem mọi tin nhắn đã gửi và nhận trong chế độ xem dòng thời gian với tô sáng cú pháp JSON. Bạn có thể lưu các kết nối, đặt tiêu đề và tham số truy vấn để xác thực, và giữ kết nối trực tiếp trong khi bạn thử nghiệm. Nó xử lý REST, GraphQL và SOAP trong cùng một ứng dụng, vì vậy kiểm thử WebSocket nằm cùng với các công việc API khác của bạn chứ không phải trong một công cụ riêng biệt. Tải xuống Apidog để kiểm thử các điểm cuối WebSocket với một dòng thời gian trực quan.
Một GUI là lựa chọn đúng đắn khi bạn đang khám phá một API WebSocket không quen thuộc, gỡ lỗi tại sao tin nhắn không đến, hoặc chia sẻ một kiểm thử có thể tái tạo với đồng đội. Dòng lệnh là lựa chọn đúng đắn khi bạn muốn kiểm tra chạy tự động. Hầu hết các kỹ sư đều sử dụng cả hai, lựa chọn tùy theo nhiệm vụ. Nếu bạn muốn có cái nhìn rộng hơn về các tùy chọn GUI, tổng hợp của chúng tôi về các công cụ kiểm thử API trực tuyến miễn phí bao gồm một số công cụ xử lý WebSocket.
Danh sách kiểm tra kiểm thử WebSocket đơn giản
- Xác nhận việc nâng cấp. Kết nối phải trả về HTTP 101. Nếu không, điểm cuối, đường dẫn hoặc tiêu đề của bạn bị sai.
- Kiểm tra xác thực. Nhiều máy chủ WebSocket mong đợi một mã thông báo trong tiêu đề hoặc tham số truy vấn. Một kết nối mở sau đó đóng ngay lập tức thường có nghĩa là mã thông báo bị từ chối.
- Gửi một tin nhắn đã biết và xác minh phản hồi. Sử dụng tải trọng thực mà API của bạn hiểu và xác nhận hình dạng phản hồi.
- Xác minh các tin nhắn được máy chủ đẩy. Đăng ký một kênh và xác nhận rằng các cập nhật đến mà không cần bạn yêu cầu thêm.
- Kiểm thử việc đóng kết nối. Đóng kết nối và kiểm tra mã đóng. Một lần đóng sạch là 1000; các mã khác báo hiệu các vấn đề cụ thể.
- Kiểm thử các đường dẫn lỗi. Gửi một tin nhắn bị sai cấu trúc và xác nhận máy chủ phản hồi một cách hợp lý thay vì im lặng bỏ qua.
Để tổ chức những điều này thành một bộ có thể lặp lại, hướng dẫn của chúng tôi về xây dựng các bộ kiểm thử API áp dụng cho các luồng WebSocket cũng như REST.
Gỡ lỗi một kết nối WebSocket không hoạt động
Khi một kết nối WebSocket thất bại, nguyên nhân gần như luôn là một trong số ít vấn đề. Hãy xem xét chúng theo thứ tự.
Bắt đầu với lược đồ URL. Một kết nối đến wss:// từ một trang hoặc ngữ cảnh mong đợi ws://, hoặc ngược lại, sẽ thất bại ngay lập tức. Các trình duyệt cũng chặn kết nối ws:// từ một trang được phục vụ qua HTTPS, vì điều đó trộn lẫn nội dung an toàn và không an toàn. Xác nhận lược đồ phù hợp với môi trường.
Tiếp theo, kiểm tra phản hồi bắt tay. Nếu bạn không thấy HTTP 101, máy chủ chưa bao giờ đồng ý nâng cấp. Lỗi 404 có nghĩa là đường dẫn sai. Lỗi 401 hoặc 403 có nghĩa là xác thực thất bại trước khi nâng cấp. Lỗi 400 thường có nghĩa là thiếu hoặc sai cấu trúc tiêu đề nâng cấp. Cả cờ --include của curl và chế độ verbose của websocat đều cho bạn thấy phản hồi này, vì vậy bạn có thể phân biệt lỗi bắt tay với một vấn đề sau đó.
Nếu quá trình bắt tay thành công nhưng kết nối bị ngắt vài giây sau đó, hãy xem xét các khoảng thời gian chờ không hoạt động và các khung ping hoặc pong. Nhiều máy chủ mong đợi máy khách trả lời các khung ping để chứng minh nó vẫn còn hoạt động, và chúng đóng các kết nối im lặng. Một proxy hoặc bộ cân bằng tải trước máy chủ cũng có thể ngắt các kết nối không hoạt động theo lịch trình riêng của nó. Cuối cùng, đọc mã đóng. Các mã được định nghĩa trong RFC 6455, và một mã như 1006 chỉ ra một lần đóng bất thường mà không có quá trình bắt tay sạch sẽ, trong khi 1011 báo hiệu lỗi máy chủ. Mã đóng thường cho bạn biết bên nào đã bỏ cuộc và tại sao.
Tự động hóa kiểm tra WebSocket
Một kiểm thử thủ công một lần xác nhận một điểm cuối hoạt động hôm nay. Nó không bảo vệ bạn khỏi sự hồi quy vào tuần tới. Đối với điều đó, kiểm tra WebSocket phải chạy tự động.
Các công cụ dòng lệnh làm cho điều này trở nên đơn giản. Một script nhỏ có thể mở một kết nối với websocat, gửi một tin nhắn đã biết, thu thập phản hồi và so sánh nó với một giá trị mong đợi, sau đó thoát với mã khác không nếu nó không khớp. Script đó sẽ được đưa vào một pipeline CI như bất kỳ bước kiểm thử nào khác. Một công cụ GUI với bộ chạy kịch bản, chẳng hạn như Apidog, có thể lưu một luồng WebSocket, bao gồm các tin nhắn đã gửi và các khẳng định về các phản hồi, và phát lại nó theo lịch trình hoặc từ một trình kích hoạt pipeline.
Giữ các kiểm thử WebSocket tự động tập trung. Khẳng định kết nối được nâng cấp, khẳng định một cặp yêu cầu và phản hồi đã biết, và khẳng định rằng một kênh đã đăng ký cung cấp ít nhất một tin nhắn được đẩy trong một khoảng thời gian chờ. Cố gắng khẳng định mọi tin nhắn có thể có của một kết nối dài hạn làm cho kiểm thử chậm và không ổn định. Sự kiềm chế tương tự giúp một trường hợp kiểm thử sắc nét cũng giúp kiểm tra WebSocket đáng tin cậy: kiểm tra một điều rõ ràng, và kiểm tra nó thật tốt.
Các câu hỏi thường gặp
curl có thể kiểm thử kết nối WebSocket không?
Một phần. curl 7.86 trở lên có hỗ trợ WebSocket gốc thử nghiệm có thể hoàn thành quy trình bắt tay và trao đổi các tin nhắn cơ bản, đủ để xác nhận một điểm cuối có thể truy cập được. Nó khá khó sử dụng cho các phiên tương tác với nhiều tin nhắn. Để kiểm thử WebSocket thực sự, websocat hoặc một client GUI như Apidog phù hợp hơn.
Sự khác biệt giữa ws và wss là gì?
ws:// là một kết nối WebSocket không được mã hóa, và wss:// được mã hóa bằng TLS, tương đương với HTTP so với HTTPS của WebSocket. Luôn sử dụng wss:// cho bất cứ điều gì ngoài phát triển cục bộ, vì ws:// gửi tin nhắn dưới dạng văn bản thuần túy. Các công cụ xử lý hai URL này giống hệt nhau ngoại trừ việc mã hóa.
Tại sao kết nối WebSocket của tôi mở rồi đóng ngay lập tức?
Nguyên nhân phổ biến nhất là xác thực. Nếu máy chủ mong đợi một mã thông báo trong tiêu đề hoặc tham số truy vấn và không nhận được mã hợp lệ, nó sẽ chấp nhận kết nối TCP và sau đó đóng nó. Kiểm tra mã đóng, xác minh mã thông báo của bạn và xác nhận bạn đang gửi nó theo cách mà máy chủ mong đợi.
websocat có tốt hơn curl để kiểm thử WebSocket không?
Cụ thể cho WebSocket, có. websocat được xây dựng chuyên dụng, hiểu đầy đủ giao thức khung, hỗ trợ các phiên tương tác, tiêu đề tùy chỉnh và đường ống tin nhắn vào và ra. curl là một công cụ HTTP tổng quát mà hỗ trợ WebSocket của nó vẫn đang trong giai đoạn thử nghiệm. Sử dụng curl để kiểm tra nhanh khả năng tiếp cận và websocat để kiểm thử thực tế.
Làm cách nào để kiểm thử rằng một máy chủ đẩy tin nhắn mà không cần yêu cầu?
Mở kết nối, đăng ký kênh hoặc sự kiện liên quan nếu API yêu cầu, sau đó chờ và quan sát. Với websocat, các tin nhắn được đẩy sẽ in ra khi chúng đến. Với một client GUI như Apidog, chúng sẽ xuất hiện trong dòng thời gian tin nhắn. Xác nhận rằng các tin nhắn đến mà không cần thêm bất kỳ đầu vào nào từ bạn, vì việc phân phối không yêu cầu là mục đích của WebSocket.