HTTP/2 נכנס לתוך מנהרת ה-SOCKS של Go

מנהרת SOCKS נושאת חיבור TCP. Go יכול לבצע TLS עם היעד דרך המנהרה הזו ולדון ב-HTTP/2 שם; שרת ה-SOCKS עצמו אינו צריך לדבר HTTP/2.

בתוכנית ששומרת על תעבורת ברירת המחדל הסטנדרטית של Go, שכפלו את התצורה שלה ובחרו את הפרוקסי:

import (
    "net/http"
    "net/url"
    "time"
)

proxyURL := &url.URL{
    Scheme: "socks5",
    Host: "proxy.example:1080",
}
transport := http.DefaultTransport.(*http.Transport).Clone()
transport.Proxy = http.ProxyURL(proxyURL)
client := &http.Client{
    Transport: transport,
    Timeout: 30 * time.Second,
}

הפרוקסי והיעד נשארים ערכים שונים. בחרו נקודת קצה SOCKS5 מתוך רשימת פרוקסי SOCKS5 עבור ערך הפרוקסי; HTTP/2 עדיין נדון עם היעד. השתמשו ב-client כדי לבקש את כתובת שירות ה-HTTPS האמיתית, ואז סגרו את גוף התגובה דרך מחזור החיים הרגיל של היישום.

תעבורת ברירת המחדל הסטנדרטית תומכת ב-HTTP/2. שכפולה שומר על התצורה הזו ומאפשר לשנות את בחירת הפרוקסי. הבדיקה של הסוג מניחה שהתוכנית לא החליפה את http.DefaultTransport ב-RoundTripper אחר.

עבור תעבורה שנבנתה בנפרד, עיינו בתצורת ה-HTTP/2 שלה, במיוחד כשמספקים קרסי dial או TLS מותאמים. Go חושף את ForceAttemptHTTP2, ובגרסאות חדשות יותר תצורת Protocols מפורשת עבור הבחירות האלה.

היעד עדיין צריך להציע HTTP/2 דרך משא ומתן TLS. בדקו את ערך Proto או ProtoMajor של התגובה המוצלחת כדי לראות מה שימש. בקשת HTTPS שמצליחה דרך SOCKS אינה מוכיחה כשלעצמה שהפרוטוקול שנדון היה HTTP/2.