لماذا تقوم بنقل ملفات Javascript الخاصة بك إلى نطاق رئيسي مختلف تمتلكه أيضًا؟

Question

لقد لاحظت أنه في العام الماضي أو نحو ذلك، قامت العديد من مواقع الويب الكبرى بإجراء نفس التغيير على طريقة تنظيم صفحاتها.قام كل منهم بنقل ملفات Javascript الخاصة بهم من الاستضافة على نفس النطاق مثل الصفحة نفسها (أو نطاق فرعي من ذلك)، إلى الاستضافة على نطاق مسمى مختلف.

انها ليست مجرد التوازي

توجد الآن تقنية معروفة لنشر مكونات صفحتك عبر نطاقات متعددة لموازاة التنزيل. تنصح شركة ياهو بذلك كما يفعل كثيرون آخرون.على سبيل المثال، www.example.com هو المكان الذي تتم فيه استضافة HTML الخاص بك، ثم تقوم بوضع الصور عليه image.example.com وجافا سكريبت على scripts.example.com.يتغلب هذا على حقيقة أن معظم المتصفحات تحد من عدد الاتصالات المتزامنة لكل خادم حتى تكون مواطنًا صالحًا للإنترنت.

ما سبق هو لا ما أتحدث عنه.

لا يقتصر الأمر على مجرد إعادة التوجيه إلى شبكة توصيل المحتوى (أو ربما يكون كذلك - راجع الجزء السفلي من السؤال)

ما أتحدث عنه هو استضافة Javascripts على وجه التحديد في مجال مختلف تمامًا.اسمحوا لي أن أكون محددا.فقط في العام الماضي أو نحو ذلك لاحظت ما يلي:

youtube.com قام بنقل ملفات .JS الخاصة به إلى ytimg.com

cnn.com قام بنقل ملفات .JS الخاصة به إلى cdn.turner.com

Weather.com قام بنقل ملفات .JS الخاصة به إلى j.imwx.com

الآن، أعرف عن شبكات توصيل المحتوى مثل أكاماي الذين يتخصصون في الاستعانة بمصادر خارجية لهذا لمواقع الويب الكبيرة.(يدلنا الاسم "cdn" الموجود في مجال Turner الخاص على أهمية هذا المفهوم هنا).

لكن لاحظ في هذه الأمثلة أن كل موقع لديه نطاق مسجل خاص به لهذا الغرض، وليس نطاق شبكة توصيل المحتوى أو أي مزود بنية أساسية آخر.في الواقع، إذا حاولت تحميل الصفحة الرئيسية من معظم مجالات البرامج النصية هذه، فعادةً ما يتم إعادة التوجيه مرة أخرى إلى المجال الرئيسي للشركة.وإذا قمت بالبحث العكسي عن عناوين IP المعنية، فسيتم العثور عليها أحيانا تظهر الإشارة إلى خوادم شركة CDN، وفي بعض الأحيان لا.

لماذا أهتم؟

بعد أن عملت سابقًا في شركتين أمنيتين مختلفتين، أصبحت مصابًا بجنون العظمة من جافا سكريبت الخبيثة.

ونتيجة لذلك، فإنني أتبع ممارسات القائمة البيضاء للمواقع التي سأسمح بتشغيل Javascript (والمحتوى النشط الآخر مثل Java).ونتيجة لذلك، لجعل موقع مثل cnn.com العمل بشكل صحيح، لا بد لي من وضع يدويا cnn.com في القائمة.إنه ألم في الخلف، لكني أفضله على البديل.

عندما استخدم الناس أشياء مثل scripts.cnn.com للتوازي، كان ذلك جيدًا مع أحرف البدل المناسبة.وعندما يستخدم الأشخاص نطاقات فرعية خارج نطاقات شركة CDN، يمكنني فقط السماح للنطاق الرئيسي لشركة CDN بحرف بدل في المقدمة أيضًا وقتل العديد من الطيور بحجر واحد (مثل *.edgesuite.net و*.akamai.com).

لقد اكتشفت الآن أن هذا (اعتبارًا من عام 2008) ليس كافيًا.الآن لا بد لي من البحث في الكود المصدري للصفحة التي أريد إدراجها في القائمة البيضاء، ومعرفة المجال (أو المجالات) "السري" الذي يستخدمه هذا الموقع لتخزين نصوص جافا سكريبت الخاصة به.في بعض الحالات، وجدت أنه يتعين علي السماح بثلاثة نطاقات مختلفة حتى يعمل الموقع.

لماذا بدأت كل هذه المواقع الكبرى في القيام بذلك؟

يحرر:نعم كما أشار "onebyone"., ، يبدو أنه مرتبط بتسليم محتوى CDN.لذلك اسمحوا لي بتعديل السؤال قليلاً بناءً على بحثه ...

لماذا Weather.com استخدام j.imwx.com بدلاً من twc.vo.llnwd.net?

لماذا youtube.com استخدام s.ytimg.com بدلاً من static.cache.l.google.com?

لا بد من وجود سبب وراء هذا.

Answer 1

سؤال المتابعة الخاص بك هو في الأساس:بافتراض أن أحد مواقع الويب الشهيرة يستخدم CDN، فلماذا يستخدمون TLD الخاص بهم مثل imwx.com بدلاً من النطاق الفرعي (static.weather.com) أو مجال CDN؟

حسنًا، سبب استخدام المجال الذي يتحكمون فيه مقابل مجال CDN هو أنهم يحتفظون بالسيطرة - من المحتمل أن يغيروا شبكات CDN بالكامل ويتعين عليهم فقط تغيير سجل DNS، مقابل الاضطرار إلى تحديث الروابط في آلاف الصفحات/التطبيقات.

فلماذا نستخدم أسماء النطاقات الهراء؟حسنًا، الشيء المهم في الملفات المساعدة مثل .js و.css هو أنك تريد تخزينها مؤقتًا بواسطة الوكلاء ومتصفحات الأشخاص قدر الإمكان.إذا قام شخص ما بزيارة gmail.com وتم تحميل جميع ملفات .js من ذاكرة التخزين المؤقت للمتصفح الخاص به، فسيبدو الموقع أكثر سرعة بالنسبة له، كما أنه يحفظ النطاق الترددي على طرف الخادم (يفوز الجميع).تكمن المشكلة في أنه بمجرد إرسال رؤوس HTTP للتخزين المؤقت القوي حقًا (على سبيل المثال،قم بتخزينها مؤقتًا لمدة أسبوع أو عام أو إلى الأبد)، لم يعد يتم تحميل هذه الملفات بشكل موثوق من الخادم بعد الآن ولا يمكنك إجراء تغييرات/إصلاحات عليها لأن الأشياء سوف تتعطل في متصفحات الأشخاص.

لذا، ما يتعين على الشركات فعله هو تنظيم هذه التغييرات وتغيير عناوين URL لكل هذه الملفات فعليًا لإجبار متصفحات الأشخاص على إعادة تحميلها.التنقل عبر نطاقات مثل "a.imwx.com" و"b.imwx.com" وما إلى ذلك.هو كيف يتم ذلك.

باستخدام اسم مجال لا معنى له، يمكن لمطوري Javascript ونظرائهم في مسؤول اتصال Javascript/CDN أن يكون لديهم اسم المجال/DNS الخاص بهم الذي يدفعون هذه التغييرات من خلاله، ويكونون مسؤولين/مستقلين عنه.

بعد ذلك، إذا بدأ حدوث أي نوع من حظر ملفات تعريف الارتباط أو حظر البرامج النصية على TLD، فسيتم تغييرهم من TLD واحد لا معنى له إلى kyxmlek.com أو أي شيء آخر.ولا داعي للقلق بشأن القيام عن غير قصد بشيء شرير له آثار جانبية مضادة على جميع مواقع *.google.com.

Answer 2

هل تريد الحد من حركة ملفات تعريف الارتباط؟

بعد تعيين ملف تعريف الارتباط على مجال معين، سيتم إرسال ملف تعريف الارتباط مرة أخرى إلى الخادم عند كل طلب إلى هذا المجال.كل طلب!

يمكن أن تضيف ما يصل بسرعة.

Answer 3

أسباب كثيرة:

CDN - اسم نظام أسماء النطاقات المختلف يجعل من السهل تحويل الأصول الثابتة إلى شبكة توزيع المحتوى

التوازي - تستخدم الصور وأوراق الأنماط وجافا سكريبت الثابتة اتصالين آخرين لن يمنعا الطلبات الأخرى، مثل عمليات رد اتصال ajax أو الصور الديناميكية

حركة ملفات تعريف الارتباط - صحيحة تمامًا - خاصة مع المواقع التي لديها عادة تخزين أكثر بكثير من مجرد معرف جلسة بسيط في ملفات تعريف الارتباط

تشكيل التحميل - حتى بدون CDN، لا تزال هناك أسباب وجيهة لاستضافة الأصول الثابتة على عدد أقل من خوادم الويب المحسنة للاستجابة بسرعة كبيرة لعدد كبير من طلبات عناوين URL للملفات، بينما تتم استضافة بقية الموقع على عدد أكبر من الخوادم المستجيبة لمزيد من الطلبات الديناميكية المكثفة للمعالج

---

التحديث - سببان لعدم استخدام اسم DNS الخاص بـ CDN.يعمل اسم نظام أسماء النطاقات للعميل كمفتاح لـ "الخلية" المناسبة للأصول التي يقوم CDN بتخزينها مؤقتًا.وبما أن CDN الخاص بك عبارة عن خدمة سلعية، فيمكنك تغيير الموفر عن طريق تغيير سجل نظام أسماء النطاقات - حتى تتمكن من تجنب أي تغييرات في الصفحة أو إعادة التكوين أو إعادة النشر على موقعك.

Answer 4

أعتقد أن هناك شيئًا ما في نظرية CDN:

على سبيل المثال:

$ host j.imwx.com
j.imwx.com              CNAME   twc.vo.llnwd.net
twc.vo.llnwd.net        A       87.248.211.218
twc.vo.llnwd.net        A       87.248.211.219
$ whois llnwd.net
<snip ...>
Registrant:
  Limelight Networks Inc.
  2220 W. 14th Street
  Tempe, Arizona 85281-6945
  United States

لايملايت هو CDN.

في أثناء:

$ host s.ytimg.com
s.ytimg.com             CNAME   static.cache.l.google.com
static.cache.l.google.com       A       74.125.100.97

أعتقد أن هذا هو CDN للمحتوى الثابت الذي يتم تشغيله داخليًا بواسطة Google.

$ host cdn.turner.com
cdn.turner.com A record currently not present

آه، حسنًا، لا أستطيع الفوز بهم جميعًا.

بالمناسبة، إذا كنت تستخدم Firefox مع الوظيفة الإضافية NoScript، فسيتم أتمتة عملية البحث من خلال المصدر، وواجهة المستخدم الرسومية (GUI) لعملية القائمة البيضاء.في الأساس، انقر على أيقونة NoScript في شريط الحالة، وستحصل على قائمة بالنطاقات مع خيارات لإضافتها إلى القائمة البيضاء بشكل مؤقت أو دائم، بما في ذلك "الكل في هذه الصفحة".

Answer 5

لقد قمت بتنفيذ هذا الحل منذ حوالي عامين إلى ثلاثة أعوام لدى صاحب عمل سابق، عندما بدأ تحميل موقع الويب بشكل زائد بسبب تنفيذ خادم ويب قديم.من خلال نقل صور CSS والتخطيط إلى خادم Apache، قمنا بتقليل الحمل على الخادم الرئيسي وزيادة السرعة بلا نهاية.

ومع ذلك، كان لدي دائمًا انطباع بأن وظائف Javascript لا يمكن الوصول إليها إلا من داخل نفس النطاق مثل الصفحة نفسها.يبدو أن مواقع الويب الأحدث لا تحتوي على هذا القيد:كما ذكرت، لدى العديد منها ملفات Javascript في نطاقات فرعية منفصلة أو حتى نطاقات منفصلة تمامًا.

هل يمكن لأي أحد أن يقدم لي مؤشرًا حول السبب الذي يجعل هذا الأمر ممكنًا الآن، في حين أنه لم يكن كذلك قبل عامين؟

Answer 6

لا يقتصر الأمر على جافا سكريبت فقط، حيث يمكنك الانتقال إلى مجالات مختلفة، ولكن أكبر عدد ممكن من الأصول سيؤدي إلى تحسينات في الأداء.

لدى معظم المتصفحات حد لعدد الاتصالات المتزامنة التي يمكنك إجراؤها بمجال واحد (أعتقد أنه حوالي 4) لذا عندما يكون لديك الكثير من الصور، فغالبًا ما تتعطل ملفات js وcss وما إلى ذلك عند تنزيل كل ملف.

يمكنك استخدام شيء مثل YSlow وFireBug لعرض وقت تنزيل كل ملف من الخادم.

من خلال وجود أصول في نطاقات منفصلة، ​​فإنك تقلل العبء على جهازك الأساسي ويمكن أن يكون لديك المزيد من الاتصالات المتزامنة وتنزيل المزيد من الملفات في أي وقت محدد.

لقد أطلقنا مؤخرًا موقعًا عقاريًا يحتوي على الكثير من الصور (للمنازل، duh :P) والذي يستخدم هذا المبدأ للصور، لذلك يكون إدراج البيانات أسرع كثيرًا.

لقد استخدمنا هذا أيضًا في العديد من مواقع الويب الأخرى التي تحتوي على حجم كبير من الأصول.

Answer 7

أعتقد أنك أجبت على السؤال الخاص بك.

أعتقد أن مشكلتك متعلقة بالأمان، وليس بالسبب.

ربما تكون هناك علامة META جديدة تصف شبكات CDN الصالحة للصفحة المعنية، فكل ما نحتاجه هو وظيفة إضافية للمتصفح لقراءتها والتصرف وفقًا لذلك.

Answer 8

هل سيكون ذلك بسبب الحظر الذي يتم بواسطة مرشحات البريد العشوائي والمحتوى؟إذا كانوا يستخدمون نطاقات غريبة، فمن الصعب معرفة ذلك و/أو سينتهي بك الأمر بحظر شيء تريده.

لا أدري، مجرد فكرة.

Answer 9

إذا كنت اسمًا كبيرًا وشركة متعددة العلامات التجارية، فأعتقد أن هذا النهج سيكون منطقيًا لأنك تريد إتاحة كود جافا سكريبت كمكتبة.أرغب في جعل أكبر عدد ممكن من الصفحات متسقًا قدر الإمكان في التعامل مع أشياء مثل العناوين وأسماء الولايات والرموز البريدية.ربما يجعل AJAX هذا القلق بارزًا.

في نموذج الأعمال التجارية عبر الإنترنت الحالي، تعد النطاقات علامات تجارية، وليست أسماء شبكات.إذا حصلت على علامات تجارية تم شراؤها أو عرضها، فسينتهي بك الأمر بالكثير من التغييرات في النطاق.وهذه مشكلة حتى لأبرز المواقع.

لا تزال هناك روابط تشير إلى مستندات مفيدة في *.netscape.com و*.mcom.com وقد اختفت منذ فترة طويلة.

ويكيبيديا ل نتسكيب يقول:

"في 12 أكتوبر 2004، تم إغلاق موقع المطورين الشهير Netscape DevEdge بواسطة AOL.لقد كان DevEdge موردًا مهمًا للتقنيات المرتبطة بالإنترنت، حيث احتفظ بالوثائق النهائية في متصفح Netscape، والوثائق المتعلقة بالتقنيات المرتبطة مثل HTML وJavaScript، والمقالات الشائعة التي كتبها رواد الصناعة والتكنولوجيا مثل داني جودمان.تمت إعادة نشر بعض محتويات DevEdge على موقع Mozilla الإلكتروني."

لذلك سيكون ذلك في أقل من 10 سنوات:

• شركة موزاييك للإتصالات
• شركة نتسكيب للاتصالات
• أمريكا أون لاين
• ايه او ال تايم وارنر
• تحذير الوقت

إذا قمت بوضع الكود في مجال ليس اسم علامة تجارية، فستحتفظ بقدر كبير من المرونة ولن تضطر إلى إعادة هيكلة جميع نقاط الإدخال والتحكم في الوصول ومراجع الكود عند إعادة تسمية مواقع الويب.

Answer 10

لقد عملت مع شركة تقوم بذلك.إنهم في مركز بيانات مع تناظر جيد إلى حد ما، لذا فإن منطق CDN ليس كبيرًا بالنسبة لهم (ربما يساعدهم ذلك، لكنهم لا يفعلون ذلك لهذا السبب).السبب وراء ذلك هو أنهم يقومون بتشغيل العديد من خوادم الويب بالتوازي والتي تتعامل بشكل جماعي مع صفحاتهم الديناميكية (برامج PHP النصية)، ويقدمون الصور وبعض جافا سكريبت خارج نطاق منفصل حيث يستخدمون خادم ويب سريع وخفيف الوزن مثل lighttpd أو thttpd للخدمة. الصور وجافا سكريبت ثابت.

PHP يتطلب PHP.جافا سكريبت الثابتة والصور لا تفعل ذلك.يمكن تجريد الكثير من خادم الويب كامل الميزات عندما يكون كل ما عليك فعله هو الحد الأدنى المطلق.

بالتأكيد، ربما يمكنهم استخدام وكيل يعيد توجيه الطلبات إلى دليل فرعي محدد إلى خادم مختلف، ولكن من الأسهل التعامل مع كل المحتوى الثابت باستخدام خادم مختلف.