Java DatagramSocket והעברת UDP דרך SOCKS5
הבינו מדוע socket UDP של Java זקוק למימוש SOCKS5 UDP גם כאשר חיבורי TCP כבר משתמשים ב-SOCKS.
בקשת ה-HTTP שלכם ב-Java עובדת דרך SOCKS, אך תכונת UDP עדיין שולחת תעבורה ישירות או נכשלת. הגדרת מאפייני SOCKS של ה-JVM אינה נותנת ל-DatagramSocket מימוש SOCKS5 UDP.
ה-API של DatagramSocket שולח ומקבל datagram ים המיועדים לנקודות קצה ברשת. השיטה connect() שלו בוחרת עמית עבור אותו socket. היא אינה מבצעת משא ומתן SOCKS עם העמית.
מסלול UDP דרך SOCKS5 דורש עבודה נוספת
SOCKS5 מגדיר שיוך UDP שנוצר מעל חיבור בקרה של TCP. לאחר מכן הלקוח מחליף datagram ים עטופים עם כתובת ההעברה שסופק על ידי ה-proxy. כל הודעה עטופה מזהה את יעדה. מימוש לקוח צריך לטפל במסגור הזה ובמשך החיים של חיבור הבקרה.
הפניית socket UDP רגיל אל פורט ההאזנה של TCP של ה-proxy מדלגת על השלבים האלה. שליחת ה-datagram ים הגולמיים של היישום לכתובת הזו אינה תחליף לשיוך.
בחרו ספרייה או תכונת יישום שתומכת במפורש בהעברת UDP דרך SOCKS5, וודאו שגם השרת תומך בכך. ספרייה שמפרסמת תמיכה ב-SOCKS עשויה לממש רק TCP CONNECT. מפרט הפרוטוקול מבחין בין הפקודות.
העברת ה-UDP זקוקה גם למסלול שמיש
חיבור TCP מוצלח ל-proxy קובע רק את מסלול הבקרה. חומות אש או התנהגות NAT עדיין יכולות להפריע ל-datagram ים שנשלחים אל ההעברה. אספו את נקודת הקצה של ההעברה שהוחזרה ואת כל שגיאת העברה לפני שתסיקו שהיעד של היישום אינו מקוון.
לבסוף, תמיכת התעבורה של SOCKS אינה מוסיפה הבטחות מסירה ל-UDP. פסקי הזמן של היישום שלכם, הטיפול באובדן ומגבלות גודל ההודעה עדיין חלים לאחר שהמסלול משתנה.