Test

Bu bo'limda spring-test da mavjud imkoniyatlar haqida qisqacha ma'lumot beriladi, Spring MVC dasturlari uchun.

• Soxta Servlet API obyektlari: modular test qilish uchun Servlet API kontraktlarining soxta amalga oshirilishi, kontrollerlar, filtrlari va boshqa web komponentlari uchun.

• TestContext Framework: JUnit va TestNG testlarida Spring konfiguratsiyasini yuklashni qo'llab-quvvatlash, yuklangan konfiguratsiyani test metodlarida samarali kesh qilish va WebApplicationContext ni MockServletContext bilan yuklashni qo'llab-quvvatlash.

• Spring MVC Test: MockMvc deb ham ataladigan ramka, DispatcherServlet orqali anotatsiya qilingan kontrollerlarni test qilish uchun mo'ljallangan (ya'ni, anotatsiyalarni qo'llab-quvvatlaydi), Spring MVC infrastrukturasiga ega, lekin HTTP-serversiz.

• Mijoz tomonidagi REST: spring-test MockRestServiceServer ni taqdim etadi, bu esa mijoz tomonidagi kodni test qilish uchun soxta server sifatida foydalanish mumkin, bu RestTemplate ni ichki darajada ishlatadi.

• WebTestClient: WebFlux dasturlarini test qilish uchun yaratilgan, lekin HTTP-aloqa orqali har qanday serverda oxirigacha integratsion test qilish uchun foydalanilishi mumkin. Bu bloklanmaydigan, reaktiv mijoz bo'lib, asinxron ishlash va oqim o'tkazish ssenariylarida test qilish uchun juda mos keladi.

WebSocket protokolining Web-soketlari

Ushbu ma'lumotnoma qismi servletlar stekini, WebSocket orqali xabar almashinuvini qamrab oladi, jumladan xom WebSocket o'zaro ta'siri, SockJS orqali WebSocket emulyatsiyasi va WebSocket ustida subprotokol sifatida STOMP orqali xabar almashinuvi.

WebSocket protokoliga kirish

WebSocket protokoli, RFC 6455, mijoz va server o'rtasida bitta TCP ulanish ustida to'liq-dupleks ikki tomonlama aloqani o'rnatish uchun standartlashtirilgan usulni ta'minlaydi. Bu HTTP dan farqli TCP protokol, lekin HTTP ustida ishlash uchun mo'ljallangan, 80 va 443 portlaridan foydalanadi va mavjud xavfsizlik devori qoidalaridan foydalanish imkonini beradi.

WebSocket muloqoti HTTP-sorovidan boshlanadi, bu HTTP sarlavhasidan Upgrade foydalanishga o'tish yoki tanlangan holda WebSocket protokoliga o'tish uchun foydalanadi. Quyidagi misol bunday o'zaro ta'sirni ko'rsatadi:

GET /spring-websocket-portfolio/portfolio HTTP/1.1
Host: localhost:8080
Upgrade: websocket 
Connection: Upgrade 
Sec-WebSocket-Key: Uc9l9TMkWGbHFD2qnFHltg==
Sec-WebSocket-Protocol: v10.stomp, v11.stomp
Sec-WebSocket-Version: 13
Origin: http://localhost:8080

1. Upgrade sarlavhasi.
2. Upgrade aloqasidan foydalanish.

Oddiy 200 holat kodi o'rniga, WebSocket qo'llab-quvvatlaydigan server quyidagiga o'xshash xabar chiqaradi:

HTTP/1.1 101 Switching Protocols 
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 1qVdfYHU9hPOl4JYYNXF623Gzn0=
Sec-WebSocket-Protocol: v10.stomp

1. Protokollarni almashtirish

Muvaffaqiyatli ulanish tasdiqlangandan so'ng, HTTP yangilanish so'rovidasasi ostidagi TCP soket ochiq qoladi, shunda mijoz va server xabarlarni jo'natish va qabul qilishda davom etishlari mumkin.

WebSocket protokolining web-soketlar bilan ishlashiga to'liq kirish ushbu hujjat doirasidan tashqarida. "RFC 6455" ni, HTML5 dagi WebSocket ga bag'ishlangan bobni yoki internetdagi ko'plab ta'riflar va qo'llanmalarni ko'ring.

Aytish lozimki, agar WebSocket serveri web-server ortida ishlayotgan bo'lsa (masalan, nginx), ehtimol, unga WebSocket yangilanish so'rovlarini o'tkazishni sozlash kerak bo'ladi. Xuddi shunday, agar dastur bulutli muhitda ishlayotgan bo'lsa, WebSocket qo'llab-quvvatlash bo'yicha bulut xizmat ko'rsatuvchi provayder ko'rsatmalarini tekshiring.

HTTP va WebSocket taqqoslashi

WebSocket protokoli HTTP bilan mos keladigan va HTTP-sorovidan chiqadigan qilib ishlab chiqilgan bo'lishiga qaramay, shuni tushunish muhimki, bu ikki protokol butunlay boshqa ilova arxitekturasi va dasturiy modellarni talab qiladi.

HTTP va REST da dasturni URL-manzillar to'plami sifatida modellashtiriladi. Dastur bilan o'zaro ta'sir qilish uchun mijozlar bu URL-manzillarga "so'rov-javob" uslubida murojaat qiladi. Serverlar so'rovlarni URL-manzil, usul va HTTP sarlavhalariga asoslangan tegishli qayta ishlashchiga yo'naltiradi.

Aksincha, WebSocket protokolining web-soketlarida dastlabki ulanishda odatda faqat bitta URL-manzil ishlatiladi. Keyinchalik barcha dastur xabarlari shu bir xil TCP ulanishi orqali uzatiladi. Bu butunlay boshqa asinxron, voqealar bilan boshqariladigan xabar almashinuvi arxitekturasini ko'rsatadi.

WebSocket shuningdek, past darajadagi transport protokoli bo'lib, u HTTP dan farqli o'laroq, xabar tarkibiga qandaydir semantikalarni tayinlamaydi. Bu mijoz va server o'rtasida xabar semantikasi kelishilmagunicha xabarni yo'naltirish yoki qayta ishlash mumkin emasligini anglatadi.

WebSocketdagi mijozlar va serverlar yuqori darajadagi xabar almashinuvi protokolini (masalan, STOMP) Sec-WebSocket-Protocol sarlavhasi orqali ulanish tasdiqlovchi HTTP so'rovda kelishib olishlari mumkin. Boshqa holda, ular o'zlarining kelishuvlarini ishlab chiqishlari kerak.

WebSocket protokolining web-soketlarini qachon ishlatish kerak?

WebSocket protokolining web-soketlari veb-sahifani dinamik va interaktiv qilishi mumkin. Ammo ko'p hollarda Ajax va HTTP oqimi yoki uzoq so'rov (polling) kombinatsiyasi oddiy va samarali yechim bo'lishi mumkin.

Misol uchun, yangiliklar, pochta va ijtimoiy lentlar dinamik ravishda yangilanib turishi kerak, lekin bir necha daqiqa ichida yangilanishi etarli bo'lishi mumkin. Boshqa tomondan, hamkorlik dasturlari, o'yinlar va moliyaviy dasturlar ko'proq real vaqt rejimida ishlashi kerak.

O'zi kechikish aniq hal qiluvchi omil emas. Agar xabar hajmi nisbatan kichik bo'lsa (masalan, tarmoqli xatolarni kuzatishda), HTTP protokoli orqali oqimli ravishda yuborish yoki polling samarali yechim bo'lishi mumkin. Aynan past kechikish, yuqori chastota va katta hajmdagi xabarlar kombinatsiyasi WebSocket ishlatish uchun eng yaxshi dalil.

Shuningdek, Internetda sizning nazoratingizdan tashqarida bo'lgan cheklovchi proksi-serverlar mavjud bo'lib, ular WebSocket o'zaro ta'sirini to'sib qo'yishi mumkin, yoki ular Upgrade sarlavhasini o'tkazishga moslanmagani uchun, yoki ular uzoq muddati davom etib kelayotgan, lekin faoliyat ko'rsatmayotgan ko'rinadigan ulanishlarni yopishi mumkin. Bu WebSocket ichki ilovalarini xavfsizlik devori ichida ishlatishni omonlik soliq qilishni osonlashtiradi, jamoatchilik ilovalari uchun esa qiyinroq.