عندما تُرسل أداة أتمتة أول بايت من اتصالها إلى خادم حديث، لا يبدأ التحدي عند تحميل HTML — بل يبدأ على مستوى البروتوكول نفسه. شرح بصمة HTTP/2 يعني فهم كيف تُجمّع شبكات التوزيع (CDN) مثل Akamai وCloudflare إشاراتٍ بروتوكولية دقيقة قبل أن يُنظر إلى محتوى الصفحة. هذه الإشارات تشمل إطار SETTINGS، تحديثات النافذة (WINDOW_UPDATE)، أولوية التدفقات، وترتيب pseudo-headers. إن تجاهلها يجعل حتى أدق أدوات الأتمتة تُرفض قبل أن تُقيّم.
هذا الدليل مكتوب لمهندسي الكشط (scraping) المخضرمين والباحثين الأمنيين الذين يعرفون JA3/JA4 بالفعل، ويريدون فهم الطبقة التالية: بصمة HTTP/2 (وHTTP/3) وكيف تجعل البصمة المتسقة فرقاً حاسماً بين نجاح الطلب وحظره.
ما الذي تُبصمه طبقة HTTP/2 فعلياً؟
بصمة HTTP/2 ليست اختراعاً واحداً بل مجموعة من الإشارات التي يُجمعها الخادم خلال أول ميلي ثانية من الاتصال. أوضح تصنيف لهذه الإشارات يأتي من عمل Akamai في هذا المجال، حيث يُنتج ما يُعرف بـ akamai http2 fingerprint — سلسلة مدمجة تُلخّص سلوك العميل البروتوكولي.
إطار SETTINGS (h2 settings frame)
أول ما يُرسله العميل بعد اتصال TLS الناجح هو إطار SETTINGS الذي يحتوي على معاملات الاتصال. القيم المفاتيحية التي تُبصم:
- HEADER_TABLE_SIZE — حجم جدول ضغط ترويسات HPACK. يرسل Chrome قيمة 65536، بينما يرسل httpx الافتراضي 4096.
- ENABLE_PUSH — تفعيل دفع الخادم. Chrome يُرسلها كـ 0 (معطّلة).
- INITIAL_WINDOW_SIZE — حجم نافذة التدفق الابتدائي. Chrome يستخدم 6291456 (6 ميجابايت).
- MAX_HEADER_LIST_SIZE — الحد الأقصى لقائمة الترويسات، عادةً 262144 في Chrome.
- MAX_FRAME_SIZE — الحد الأقصى لحجم الإطار، 16384 افتراضياً.
- MAX_CONCURRENT_STREAMS — الحد الأقصى للتدفقات المتزامنة، 1000 في Chrome.
ترتيب هذه المعاملات نفسه يُبصم. الخادم لا يقرأ فقط القيم بل يُسجّل ترتيبها في الإطار. يصف RFC 9113 هذه المعاملات رسمياً، لكن التطبيقات تختلف في ترتيبها وقيمها الافتراضية، وهذا الاختلاف هو جوهر البصمة.
WINDOW_UPDATE و stream priority
بعد إطار SETTINGS، يُرسل العميل WINDOW_UPDATE على التدفق 0 (الاتصال نفسه) لتعزيز النافذة الابتدائية. Chrome يُرسل WINDOW_UPDATE بقيمة 15663105 (ليرفع النافذة إلى 15728640 تقريباً). هذه القيمة محددة جداً لكل تطبيق.
أولوية التدفقات (stream priority) في HTTP/2 تُرسل عبر إطارات PRIORITY (قبل إلغائها في HTTP/3). Chrome يُرسل إطار PRIORITY للتدفق 0 (الجذر) مع وزن 256 واعتماد على 0، ثم يُرسل ترويسة priority في الطلبات الفعلية. ترتيب وكثافة إطارات PRIORITY تُبصم أيضاً.
ترتيب pseudo-headers (m,a,s,p)
HTTP/2 يستبدل سطر الطلب بـ pseudo-headers أربعة: :method، :authority، :scheme، :path. الترتيب الذي يُرسلها به العميل يُبصم. Chrome يُرسلها بالترتيب: :method، :authority، :scheme، :path — ويُختصر بـ m,a,s,p. بعض المكتبات تُرسلها بترتيب مختلف (مثلاً m,p,s,a)، وهو اختلاف يكشف فوراً أن العميل ليس متصفحاً.
سلسلة بصمة Akamai المدمجة
يُلخّص Akamai كل ما سبق في سلسلة مدمجة بصيغة شبيهة بـ:
1:65536;2:0;3:10000;4:2;5:0;6:1000;7:0;8:0;9:0;m,a,s,pالحقل الأول (مثل 1:65536) هو HEADER_TABLE_SIZE، والحقول اللاحقة تتبع ترتيب SETTINGS. الجزء الأخير m,a,s,p هو ترتيب pseudo-headers. أي انحراف عن سلسلة Chrome المعروفة يُرفع درجة الشك.
JA4H: بصمة HTTP الموحّدة
وسّعت FoxIO مفهوم JA4 ليشمل طبقة HTTP عبر ja4h fingerprint. صيغة JA4H تُجمّع: طريقة الطلب، نسخة HTTP، قائمة الترويسات بترتيبها، وقيم Accept/Accept-Encoding/Accept-Language. مثال JA4H لـ Chrome:
ge11cn13enusالجزء ge يعني GET مع ترتيب ترويسات Chrome القياسي، 11 يعني HTTP/1.1 أو h2، cn يعني ترتيب الترويسات (cookie ثم accept...)، 13 عدد الترويسات، enus لغة القبول. هذه البصمة تُدمج مع JA3/JA4 لـ TLS لتكوين صورة كاملة. لمزيد من التفاصيل، راجع مستودع JA4 على GitHub.
لماذا يكشف انحراف واحد درجة بوت قصوى قبل تحميل HTML
تخيّل عميلاً يدّعي أنه Chrome 148 في ترويسة User-Agent، لكنه يُرسل HEADER_TABLE_SIZE 4096 (القيمة الافتراضية في httpx/h2). Chrome الحقيقي لا يُرسل هذه القيمة أبداً — يستخدم 65536. هذا التناقض وحده كافٍ لأن يُعطيه الخادم أعلى درجة بوت قبل أن يُرسل أي HTML.
المنطق بسيط: لا يوجد متصفح حقيقي يُرسل HEADER_TABLE_SIZE 4096. هذه القيمة تأتي من تطبيقات Python/Go/Node الافتراضية. لذا فإن الخادم يُصنّف الطلب ضمن "عميل غير متصفح" فوراً، ويُطبّق عليه منطق التحدي (CAPTCHA، حظر، أو تقييد).
المشكلة الأعمق: التطبيقات التي تُعدّل User-Agent فقط دون تعديل طبقة البروتوكول تُكشف بسهولة أكبر، لأنها تُقدّم قصة متناقضة — "أنا Chrome في الترويسات لكنني httpx في البروتوكول". أنظمة الكشف الحديثة تُقيّم الاتساق، لا الصدق الفردي لكل ترويسة.
| العميل | HEADER_TABLE_SIZE | INITIAL_WINDOW_SIZE | ترتيب pseudo-headers | درجة الاشتباه |
|---|---|---|---|---|
| Chrome 148 (حقيقي) | 65536 | 6291456 | m,a,s,p | منخفضة |
| httpx (افتراضي) | 4096 | 4194304 | m,p,s,a | عالية جداً |
| curl_cffi (impersonate=chrome) | 65536 | 6291456 | m,a,s,p | منخفضة |
| Playwright (Chromium) | 65536 | 6291456 | m,a,s,p | منخفضة |
لماذا يجب أن تتفق TLS (JA3/JA4) وHTTP/2
البصمة ليست طبقة واحدة بل طبقتان مترابطتان. JA4 يصف مصافحة TLS (الإصدار، مجموعات التشفير بترتيبها، الامتدادات)، بينما بصمة HTTP/2 تصف سلوك البروتوكول فوق TLS. إذا ادّعى JA4 أنه Chrome لكن أرسل h2 fingerprint خاص بـ Python، فالخادم يرى تناقضاً صريحاً.
أي مكتبة عميل تُسحب TLS من Chrome لكن تُعيد استخدام مكدس HTTP/2 خاص بها تُنتج بصمة هجينة. أمثلة على تسريبات شائعة:
- httpx + h2: يُستخدم TLS قياسي من Python، وh2 بإعدادات افتراضية. كلتا الطبقتين تكشف.
- requests + urllib3: HTTP/1.1 فقط، لكن حتى هناك ترتيب الترويسات يُبصم.
- Node.js + http2 module: يُرسل SETTINGS بترتيب وقيم مختلفة عن Chrome.
- Go net/http2: HEADER_TABLE_SIZE 4096، INITIAL_WINDOW_SIZE مختلفة.
الحل ليس "تزييف" TLS فقط، بل ضمان أن مكدس HTTP/2 بالكامل يُحاكي المتصفح. هذا ما يفعله curl_cffi عبر BoringSSL (نفس مكتبة Chrome) وإعدادات h2 مطابقة.
لماذا تظل البروكسيات السكنية ضرورية رغم البصمة المتسقة
حتى لو أصدرت بصمة Chrome مثالية على مستوى TLS وHTTP/2 وHTTP/3، يبقى عامل واحد لا يستطيع البروتوكول وحده حله: سمعة عنوان IP. أنظمة الكشف تُقيّم عنوان المصدر عبر قواعد متعددة:
- هل ينتمي إلى نطاق مزود سحابي (AWS، GCP، Azure)؟ → درجة بوت عالية.
- هل هو ASN معروف ببروكسيات مراكز البيانات؟ → درجة بوت عالية.
- هل سُجّل في قوائم حظر احتيال معروفة؟ → حظر فوري.
- هل الموقع الجغرافي يطابق ترويسة Accept-Language؟ → تناقض يُرفع به الاشتباه.
البروكسيات السكنية تحل هذا لأنها تستخدم عناوين ASN مخصصة لمزودي إنترنت منزليين فعليين، فتُمرّ عبر فلاتر سمعة IP دون اعتراض. هذا لا يعني أن البصمة البروتوكولية غير مهمة — بل يعني أن كليهما ضروري. بروكسي سكني مع بصمة httpx مكشوفة يُحظر، وبصمة Chrome مثالية مع IP مركز بيانات تُحظر أيضاً. التكامل هو ما ينجح.
لمزيد من خيارات المواقع، راجع صفحة مواقع ProxyHat. ولمعرفة التسعير، زر صفحة التسعير.
تنفيذ عملي: بصمة Chrome متسقة عبر ProxyHat
الخيار 1: curl_cffi مع انتحال Chrome
curl_cffi هي مكتبة Python تُغلّف curl مع دعم انتحال بصمة المتصفح (TLS + HTTP/2). إليك مثالاً runnable يُوجّه الطلب عبر ProxyHat السكني:
from curl_cffi import requests
proxy = "http://user-country-US-session-sess1:pass@gate.proxyhat.com:8080"
resp = requests.get(
"https://tls.peet.ws/api/all",
impersonate="chrome124",
proxies={"http": proxy, "https": proxy},
timeout=30,
)
print(resp.json()["tls"]["ja4"])
print(resp.json()["http2"]["akamai_fingerprint"])
هذا يُصدر بصمة Chrome 124 كاملة: JA4 مطابق، h2 settings frame بترتيب Chrome، WINDOW_UPDATE بقيمة Chrome، وترتيب pseudo-headers m,a,s,p. مع ProxyHat السكني، يُضاف عنوان IP سكني نظيف، فيصبح الطلب متماسكاً عبر كل الطبقات.
الخيار 2: متصفح حقيقي عبر Playwright + ProxyHat
للحالات التي تتطلب تنفيذ JavaScript كاملاً (مثل بصمة Canvas أو WebRTC)، استخدم متصفحاً حقيقياً:
from playwright.sync_api import sync_playwright
proxy = {
"server": "http://gate.proxyhat.com:8080",
"username": "user-country-DE-city-berlin",
"password": "pass",
}
with sync_playwright() as p:
browser = p.chromium.launch(proxy=proxy, headless=True)
page = browser.new_page()
page.goto("https://tls.peet.ws/api/all")
print(page.content())
browser.close()
هنا يُصدر Chromium بصمة HTTP/2 وTLS أصلية بالكامل، والميزة أنك لا تحتاج إلى انتحال — بل تستخدم المتصفح نفسه. العيب هو الأداء الأبطأ (إقلاع متصفح ~500ms مقابل ~50ms لـ curl_cffi).
التحقق من البصمة
استخدم نقطة نهاية مثل tls.peet.ws/api/all لفحص بصمتك قبل النشر في الإنتاج. تحقق من:
- JA4 يطابق إصدار Chrome المُنتحل.
- سلسلة Akamai h2 fingerprint تطابق Chrome.
- JA4H يطابق (ترتيب الترويسات، اللغة، الترميز).
- عنوان IP يُصنّف كسكني وليس مركز بيانات.
HTTP/3 و QUIC: الطبقة التالية
مع انتشار HTTP/3 على QUIC، تظهر بصمة جديدة. يصف RFC 9114 البروتوكول، لكن البصمة تأتي من تفاصيل التطبيق: قيم SETTINGS في HTTP/3 (QPACK_MAX_TABLE_CAPACITY، MAX_FIELD_SECTION_SIZE)، وترتيب إطارات التحكم في QUIC، واختيار معرّف الاتصال (CID).
Chrome يُرسل SETTINGS في HTTP/3 بقيم مختلفة عن HTTP/2 (مثلاً QPACK_MAX_TABLE_CAPACITY 0 في بعض الإصدارات). أنظمة الكشف المتقدمة تُقارن بصمة h2 وh3 للعميل نفسه — إن اختلفتا بشكل غير متوقع، يُرفع الاشتباه.
curl_cffi يدعم انتحال HTTP/3 في الإصدارات الحديثة، لكن الدعم لا يزال أقل نضجاً من HTTP/2. حتى أواخر 2025، يُفضّل معظم مهندسي الكشط تعطيل HTTP/3 (إرسال Alt-Svc: clear أو استخدام --http2) للبقاء في طبقة h2 حيث البصمة أكثر استقراراً.
أخطاء شائعة وحالات حدية
1. تعديل User-Agent فقط
أكثر خطأ شيوعاً. يُغيّر الترويسة لكن يترك h2 settings frame مكشوفاً. النتيجة: تناقض صريح يُكشف فوراً.
2. استخدام بروكسي مركز بيانات مع بصمة Chrome مثالية
البصمة البروتوكولية نظيفة لكن IP من AWS. أنظمة الكشف تُقيّم IP أولاً، فتُرفض قبل فحص البصمة البروتوكولية.
3. نسيان WINDOW_UPDATE
بعض المكتبات تُرسل SETTINGS صحيحة لكن تُهمل WINDOW_UPDATE أو تُرسلها بقيمة مختلفة. هذا يُكشف لأن Chrome يُرسل WINDOW_UPDATE بقيمة محددة جداً (15663105).
4. ترتيب الترويسات في JA4H
حتى لو كانت h2 settings صحيحة، فإن ترتيب ترويسات HTTP (مثل sec-ch-ua قبل accept) يُبصم. Chrome يُرسلها بترتيب ثابت، وأي انحراف يُكشف في JA4H.
5. تجاهل الترويسات الثانوية
ترويسات مثل sec-fetch-dest، sec-fetch-mode، sec-fetch-site تُرسلها المتصفحات الحديثة بترتيب وقيم محددة. غيابها أو ترتيبها الخاطئ يُكشف.
الاستخدام المناسب والاعتبارات القانونية
هذا الدليل موجه للاستخدام المشروع: البحث الأمني المخوّل، المراقبة المصرّح بها، اختبار الاختراق ضمن نطاق متفق عليه. البصمة المتسقة ليست أداة احتيال بل أداة بحث.
في الولايات المتحدة، يُعرّف Computer Fraud and Abuse Act (CFAA) الوصول غير المصرّح به إلى الأنظمة المحمية كجريمة. الكشط الذي يتجاوز حدود robots.txt أو شروط الخدمة قد يُعدّ انتهاكاً. في الاتحاد الأوروبي، يفرض GDPR قيوداً على جمع البيانات الشخصية، حتى لو كانت متاحة للعموم.
قواعد عملية:
- احصل على إذن كتابي قبل اختبار الأنظمة التي لا تملكها.
- احترم
robots.txtوحدود المعدل (rate limits) للهدف. - لا تُخزّن بيانات شخصية دون أساس قانوني.
- وثّق غرض البحث وأبقِ السجلات.
- استخدم البروكسيات لتفادي الحظر العرضي، لا لتجاوز القيود القانونية.
لحالات استخدام أوسع، راجع حالة استخدام الكشط وتتبع نتائج البحث. وللتفاصيل التقنية للاتصال، راجع وثائق ProxyHat.
النقاط الرئيسية
البصمة البروتوكولية طبقة، لا طبقة واحدة. JA3/JA4 لـ TLS، h2 settings frame وWINDOW_UPDATE وترتيب pseudo-headers لـ HTTP/2، وJA4H لترتيب الترويسات — كلها يجب أن تتفق.
- بصمة HTTP/2 تُجمّع من SETTINGS (HEADER_TABLE_SIZE، INITIAL_WINDOW_SIZE، MAX_CONCURRENT_STREAMS)، WINDOW_UPDATE، stream priority، وترتيب pseudo-headers (m,a,s,p).
- أي انحراف عن Chrome (مثل HEADER_TABLE_SIZE 4096 من httpx) يُعطي درجة بوت قصوى قبل تحميل HTML.
- curl_cffi مع انتحال Chrome يُصدر بصمة h2 متسقة، لكن يجب توجيهها عبر بروكسي سكني لتجاوز سمعة IP.
- HTTP/3 يضيف طبقة بصمة جديدة (QPACK، CID، SETTINGS) لا تزال أقل استقراراً في الأدوات.
- الاستخدام المشروع فقط: بحث أمني مخوّل، مراقبة مصرّح بها، مع احترام CFAA وGDPR.
الخطوة التالية: ابدأ بفحص بصمتك الحالية عبر tls.peet.ws/api/all، حدد التناقضات، ثم وجّه طلباتك عبر ProxyHat السكني مع curl_cffi أو متصفح حقيقي. البصمة المتسقة + IP السكني = وصول مستقر.
