مآخذ الويب تجعل ajax/CORS قديمًا؟
https://stackoverflow.com/questions/4042691
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
هل ستجعل مقابس الويب عند استخدامها في جميع متصفحات الويب أياكس قديمًا؟
لأنه إذا كان بإمكاني استخدام مقابس الويب لجلب البيانات وتحديثها في الوقت الفعلي، فلماذا أحتاج إلى أياكس؟حتى لو كنت أستخدم أجاكس لجلب البيانات مرة واحدة فقط عند بدء تشغيل التطبيق، فقد لا أزال أرغب في معرفة ما إذا كانت هذه البيانات قد تغيرت بعد فترة من الوقت.
وهل ستكون مآخذ الويب ممكنة في المجالات المتقاطعة أم أنها من نفس المصدر فقط؟
المحلول
لن تجعل WebSockets Ajax عفا عليها الزمن تمامًا ويمكن لـ WebSockets القيام بمجال عبر.
أياكس
يمكن استخدام آليات AJAX مع خوادم الويب العادية. في مستواها الأساسي ، تعد AJAX مجرد وسيلة لصفحة الويب لتقديم طلب HTTP. WebSockets هو بروتوكول مستوى أقل بكثير ويتطلب خادم WebSockets (إما مدمج في خادم الويب أو المستقل أو المباشر من خادم الويب إلى خادم مستقل).
مع WebSockets ، يتم تحديد الإطار والحمولة النافعة بواسطة التطبيق. يمكنك إرسال HTML/XML/JSON ذهابًا وإيابًا بين العميل والخادم ، لكنك لست مجبرًا على ذلك. AJAX هو HTTP. يحتوي WebSockets على مصافحة ودية HTTP ، ولكن Websockets ليس HTTP. WebSockets هو بروتوكول ثنائي الاتجاه أقرب إلى مآخذ أو الخام (عن قصد) مما هو عليه في HTTP. يتم ترميز بيانات حمولة WebSockets UTF-8 في الإصدار الحالي من المعيار ولكن من المحتمل أن يتم تغيير/تمديده في الإصدارات المستقبلية.
لذلك من المحتمل أن يكون هناك دائمًا مكان لطلبات نوع Ajax حتى في عالم يدعم فيه جميع العملاء WebSockets أصلاً. تحاول WebSockets حل المواقف التي لا يكون فيها Ajax قادرًا أو قادرًا بشكل هامشي (لأن WebSockets ثنائية الاتجاه وأقل بكثير). لكن WebSockets لا تحل محل كل شيء يستخدمه أياكس.
عبر النطاق
نعم, ، يدعم WebSockets المجال المتقاطع. المصافحة الأولية لإعداد الاتصال ينقل معلومات السياسة الأصل. تعرض صفحة ويكيبيديا مثالاً على المصافحة النموذجية: http://en.wikipedia.org/wiki/Websockets
نصائح أخرى
سأحاول تقسيم هذا إلى الأسئلة:
هل ستجعل مآخذ الويب عند استخدامها في جميع متصفحات الويب Ajax عفا عليها الزمن؟
بالطبع لا. WebSockets هي اتصالات المقبس الخام للخادم. هذا يأتي مع إنها مخاوف أمنية خاصة. مكالمات AJAX هي ببساطة متزامنة. طلبات HTTP التي يمكن أن تتبع نفس إجراءات التحقق من الصحة مثل بقية الصفحات.
السبب إذا كان بإمكاني استخدام مآخذ الويب لجلب البيانات وتحديث البيانات في الوقت الفعلي ، فلماذا أحتاج إلى AJAX؟
يمكنك استخدام Ajax لمهام أكثر بساطة قابلية للإدارة. لا يريد الجميع الحصول على النفقات العامة لتأمين اتصال المقبس للسماح ببساطة بطلبات ASYNC. يمكن التعامل معها ببساطة بما فيه الكفاية.
حتى إذا استخدمت AJAX لجلب البيانات مرة واحدة عندما يبدأ التطبيق ، فقد ما زلت أرغب في معرفة ما إذا كانت هذه البيانات قد تغيرت بعد فترة من الوقت.
بالتأكيد، إذا كانت هذه البيانات تتغير. قد لا يكون لديك تغيير البيانات أو منعش باستمرار. مرة أخرى ، هذا رمز النفقات العامة أن عليك حساب.
وهل ستكون مآخذ الويب ممكنة في المجالات المتقاطعة أو فقط لنفس الأصل؟
يمكنك الحصول على WebSockets عبر المجال ولكن عليك ترميز خادم WS لقبولها. يمكنك الوصول إلى رأس المجال (المضيف) الذي يمكنك استخدامه بعد ذلك لقبول / رفض الطلبات. ومع ذلك ، يمكن أن يتم تخفيف هذا بشيء بسيط مثل nc. من أجل تأمين الاتصال حقًا ، ستحتاج إلى مصادقة الاتصال بوسائل أخرى.
لدى Websockets بعض الجوانب السلبية الكبيرة من حيث قابلية التوسع التي يتجنبها أياكس.نظرًا لأن ajax يرسل طلبًا/استجابة ويغلق الاتصال (.. أو بعد فترة وجيزة) إذا بقي شخص ما على صفحة الويب، فإنه لا يستخدم موارد الخادم عند الخمول.تهدف Websockets إلى دفق البيانات مرة أخرى إلى المتصفح، وتقوم بربط موارد الخادم للقيام بذلك.لدى الخوادم حدًا لعدد الاتصالات المتزامنة التي يمكنها الاحتفاظ بها مفتوحة في وقت واحد.ناهيك عن الاعتماد على تقنية جانب الخادم الخاص بك، فقد يربطون خيطًا للتعامل مع المقبس.لذا فإن مقابس الويب لديها متطلبات أكثر كثافة للموارد لكلا الجانبين لكل اتصال.يمكنك بسهولة استنفاد جميع سلاسل الرسائل الخاصة بك التي تخدم العملاء ومن ثم لا يمكن أن يأتي أي عملاء جدد إذا كان هناك الكثير من المستخدمين جالسين على الصفحة.هذا هو المكان الذي يمكن لـnodejs وvertx وnetty أن تساعد فيه حقًا، ولكن حتى تلك لها حدود عليا أيضًا.
هناك أيضًا مشكلة حالة المقبس الأساسي، وكتابة الكود على كلا الجانبين الذي يستمر في المحادثة ذات الحالة وهو أمر لا يجب عليك فعله بأسلوب ajax لأنه عديم الحالة.تتطلب Websockets إنشاء بروتوكول منخفض المستوى يتم حله لك باستخدام ajax.أصبحت أشياء مثل نبض القلب، وإغلاق الاتصالات الخاملة، وإعادة الاتصال عند حدوث أخطاء، وما إلى ذلك ذات أهمية حيوية الآن.هذه هي الأشياء التي لم يكن عليك حلها عند استخدام AJAX لأنه كان عديم الحالة.تعد الحالة مهمة جدًا لاستقرار تطبيقك والأهم من ذلك صحة الخادم الخاص بك.انها ليست تافهة.قبل HTTP، قمنا ببناء الكثير من بروتوكولات TCP ذات الحالة (FTP، telnet، SSH)، ثم حدث HTTP.ولم يعد أحد يفعل هذه الأشياء كثيرًا لأنه حتى مع قيوده، كان HTTP أسهل وأكثر قوة بشكل مدهش.تعيد Websockets الأشياء الجيدة والسيئة للبروتوكولات ذات الحالة.سوف تتعلم قريبًا بما فيه الكفاية إذا لم تحصل على جرعة من تلك الجولة الأخيرة.
إذا كنت بحاجة إلى دفق البيانات في الوقت الفعلي، فهذا الحمل الإضافي له ما يبرره لأن استقصاء الخادم للحصول على البيانات المتدفقة يكون أسوأ، ولكن إذا كان كل ما تفعله هو تفاعل المستخدم->الطلب->الاستجابة->تحديث واجهة المستخدم، فإن Ajax يكون أسهل وسيستخدم موارد أقل لأنه بمجرد إرسال الرد تنتهي المحادثة ولا يتم استخدام أي موارد إضافية للخادم.لذلك أعتقد أنها مقايضة ويجب على المهندس المعماري أن يقرر الأداة التي تناسب مشكلته.AJAX لها مكانها، ومآخذ الويب لها مكانها.
تحديث
لذا فإن بنية الخادم الخاص بك هي ما يهم عندما نتحدث عن سلاسل الرسائل.إذا كنت تستخدم خادمًا (أو عمليات) تقليديًا متعدد الخيوط، حيث يحصل كل اتصال مأخذ توصيل على مؤشر ترابط خاص به للاستجابة للطلبات، فإن مقابس الويب تهمك كثيرًا.لذلك، لدينا مأخذ توصيل لكل اتصال، وفي النهاية سوف ينهار نظام التشغيل إذا كان لديك عدد كبير جدًا من هذه المقبسات، وينطبق الشيء نفسه على الخيوط (وخاصة العمليات).الخيوط أثقل من المقابس (من حيث الموارد) لذا نحاول الحفاظ على عدد الخيوط التي نقوم بتشغيلها في وقت واحد.وهذا يعني إنشاء تجمع مؤشرات الترابط وهو مجرد عدد ثابت من سلاسل الرسائل المشتركة بين جميع المقابس.ولكن بمجرد فتح المقبس، يتم استخدام الخيط للمحادثة بأكملها.يحدد طول هذه المحادثات مدى سرعة إعادة استخدام هذه الخيوط لمآخذ التوصيل الجديدة القادمة.يحدد طول محادثتك مدى قدرتك على التوسع.ومع ذلك، إذا كنت تقوم بالبث المباشر، فإن هذا النموذج لا يعمل بشكل جيد من أجل القياس.عليك كسر تصميم الخيط/المقبس.
نموذج الطلب/الاستجابة الخاص بـ HTTP يجعله فعالاً للغاية في تسليم سلاسل الرسائل لمآخذ توصيل جديدة.إذا كنت ستستخدم الطلب/الاستجابة فقط، فاستخدم HTTP، فهو تم إنشاؤه بالفعل وهو أسهل بكثير من إعادة تنفيذ شيء كهذا في websockets.
نظرًا لأن websockets ليس من الضروري أن تكون طلبًا/استجابة مثل HTTP ويمكنها دفق البيانات إذا كان خادمك يحتوي على عدد ثابت من سلاسل الرسائل في تجمع سلاسل الرسائل الخاص به وكان لديك نفس العدد من websockets التي تربط جميع سلاسل الرسائل الخاصة بك بالمحادثات النشطة، يمكنك لا تخدم العملاء الجدد القادمين!لقد وصلت إلى الحد الأقصى لطاقتك.وهنا يكون تصميم البروتوكول مهمًا أيضًا مع مقابس الويب والخيوط.قد يسمح لك البروتوكول الخاص بك بفك الخيط لكل مقبس لكل نموذج محادثة بحيث لا يستخدم الأشخاص الجالسين هناك خيطًا على الخادم الخاص بك.
هذا هو المكان الذي تأتي فيه خوادم الخيوط المفردة غير المتزامنة.في Java، غالبًا ما نسمي هذا NIO للإدخال غير المحظور.وهذا يعني أنها واجهة برمجة تطبيقات مختلفة للمقابس حيث لا يؤدي إرسال البيانات واستقبالها إلى حظر الخيط الذي يقوم بإجراء المكالمة.
تقليديًا جدًا، يتم حظر المقابس عند استدعاء المقبس ()socket.read أو المقبس ()socket.write، حيث ينتظرون حتى يتم استلام البيانات أو إرسالها قبل إعادة التحكم إلى برنامجك.وهذا يعني أن برنامجك عالق في انتظار دخول أو خروج بيانات المقبس حتى تتمكن من فعل أي شيء آخر.لهذا السبب لدينا خيوط حتى نتمكن من القيام بالعمل بشكل متزامن (في نفس الوقت).أرسل هذه البيانات إلى العميل X أثناء انتظار البيانات من العميل Y.التزامنات هو اسم اللعبة عندما نتحدث عن الخوادم.
في خادم NIO، نستخدم مؤشر ترابط واحد للتعامل مع جميع العملاء وتسجيل عمليات الاسترجاعات ليتم إعلامك عند وصول البيانات.على سبيل المثال
socket.read( function( data ) {
// data is here! Now you can process it very quickly without waiting!
});
سيعود استدعاء المقبس ()socket على الفور دون قراءة أي بيانات، ولكن سيتم استدعاء الدالة التي قدمناها عندما تأتي.يغير هذا التصميم بشكل جذري كيفية إنشاء التعليمات البرمجية الخاصة بك وتصميمها لأنه إذا توقفت عن الانتظار لشيء ما، فلن تتمكن من استقبال أي عملاء جدد.لديك خيط واحد لا يمكنك فعل شيئين في وقت واحد!عليك أن تبقي هذا الخيط يتحرك.
NIO، غير المتزامن IO، البرنامج القائم على الأحداث كما هو معروف، هو تصميم نظام أكثر تعقيدًا، ولا أقترح عليك محاولة كتابة هذا إذا كنت تبدأ.حتى كبار المبرمجين يجدون صعوبة بالغة في بناء أنظمة قوية.نظرًا لأنك غير متزامن، فلا يمكنك الاتصال بواجهات برمجة التطبيقات التي تحظر.مثل قراءة البيانات من قاعدة البيانات أو إرسال الرسائل إلى خوادم أخرى يجب إجراؤها بشكل غير متزامن.حتى القراءة/الكتابة من نظام الملفات يمكن أن تؤدي إلى إبطاء مؤشر الترابط الفردي الخاص بك مما يقلل من قابلية التوسع لديك.بمجرد أن تصبح غير متزامن، يصبح كل شيء غير متزامن طوال الوقت إذا كنت تريد الحفاظ على حركة الخيط الواحد.وهنا يصبح الأمر صعبًا لأنك ستواجه في النهاية واجهة برمجة تطبيقات، مثل قواعد البيانات، وهي غير متزامنة وسيتعين عليك اعتماد المزيد من سلاسل الرسائل على مستوى ما.لذا فإن الأساليب الهجينة شائعة حتى في العالم غير المتزامن.
والخبر السار هو أن هناك حلولًا أخرى تستخدم واجهة برمجة التطبيقات (API) ذات المستوى الأدنى والتي تم إنشاؤها بالفعل والتي يمكنك استخدامها.NodeJS، Vertx، Netty، Apache Mina، Play Framework، Twisted Python، Stackless Python، إلخ.قد تكون هناك بعض المكتبات الغامضة لـ C++، لكن بصراحة لن أزعجني.لا تتطلب تقنية الخادم أسرع اللغات لأنها مرتبطة بـ IO أكثر من ارتباطها بوحدة المعالجة المركزية.إذا كنت من عشاق الأداء الصعب، فاستخدم Java.إنه يحتوي على مجتمع ضخم من التعليمات البرمجية التي يمكن الاستفادة منها وسرعته قريبة جدًا (وأحيانًا أفضل) من C++.إذا كنت تكره ذلك، فاستخدم Node أو Python.
نعم ، نعم يفعل. :د
الإجابات السابقة تفتقر إلى الخيال. لا أرى أي سبب لاستخدام Ajax إذا كانت WebSockets متاحة لك.
