איך להגביל את רוחב הפס של אפליקציה אחת ב-Mac

הפעילו את הפרוקסי של Throttlr, בחרו את האפליקציה שמשתמשת בחיבור והפעילו תקרת הורדה, תקרת העלאה או את שתיהן. האפליקציה שנבחרה ממשיכה להעביר נתונים, אבל רק עד הקצבים שהגדרתם. שאר האפליקציות נשארות ללא הגבלה, אלא אם תגדירו מגבלה גם עליהן או על יעד רחב יותר כמו “אינטרנט” או “רשת מקומית”.

זה שימושי כשהעברה צריכה להמשיך להתקדם בלי לצרוך את כל הקיבולת הזמינה. גיבוי לענן יכול להמשיך במהלך שיחה, משחק יכול להתעדכן בזמן שאתם עובדים, והורדה בדפדפן יכולה לרוץ ברקע בלי שתצטרכו לנתק את ה-Mac כולו.

תקרת רוחב פס שונה מהגדרת עדיפות. Throttlr מחיל קצב מרבי מפורש על התעבורה שנקלטה; הוא לא מדרג באופן דינמי אפליקציה אחת מעל אחרת. הוא גם לא יוצר כללים לדומיינים, לשרתים או לפורטים מסוימים, ואינו מוסיף השהיה (latency) או אובדן מנות.

macOS כולל כלי בקרה לרשת, אבל חומת האש המובנית שלו נועדה בעיקר לשלוט בחיבורים נכנסים לאפליקציות ולשירותים. היא אינה מגבילת רוחב פס לכל אפליקציה, ואין בה שדות של מהירות העלאה והורדה לאפליקציות בודדות.

“מוניטור הפעילות” יכול לעזור לזהות שימוש ברשת, והגדרות איכות שירות (QoS) בנתב עשויות לתעדף מכשיר או סוג תעבורה. אף אחד מהם לא מספק את אותה זרימת עבודה מקומית של בחירת תהליך אחד ב-Mac והחלת תקרות נפרדות לכל כיוון. Network Link Conditioner של Apple יכול ליצור פרופילי בדיקה לפיתוח, כולל רוחב פס מוגבל ותנאים גרועים, אבל הוא מיועד לבדיקת תנאי רשת ולא לשליטה שוטפת באפליקציית שולחן עבודה אחת שנבחרה.

לכן, הגבלת קצב לכל אפליקציה דורשת כלי רשת שיכול לשייך זרימות שנקלטו לאפליקציה ולאכוף עליהן מגבלה. Throttlr עושה זאת באמצעות מסגרת Network Extension של Apple ב-macOS 15 ואילך. יש לאשר את הרחבת הרשת, והפרוקסי צריך לפעול, לפני שהוא יכול לנטר או לשלוט בתעבורה חדשה.

תעבורת הורדה מעבירה נתונים אל האפליקציה: דפי אינטרנט, מדיה, חבילות תוכנה, קבצי ענן ונכסי משחקים הם דוגמאות נפוצות. תעבורת העלאה מעבירה נתונים ממנה החוצה: גיבויים, סנכרון קבצים, וידאו שנשלח במהלך שיחה וקבצים מצורפים יוצאים משתמשים כולם בקיבולת ההעלאה.

כשאפשר לזהות את הכיוון שגורם לבעיה, הגבילו רק אותו. הגבלת ההעלאה של גיבוי משאירה את ההורדות שלו ללא שינוי, והגבלת הורדה גדולה של משחק לא מגבילה שלא לצורך בקשות יוצאות קטנות. השתמשו בשני הכיוונים כשנדרשת תקרה צפויה לאפליקציה כולה.

הקצב החי הוא תצפית על התעבורה הנוכחית, לא הבטחה שהאפליקציה תגיע לתקרה באופן רציף. שרתים, תנאי Wi-Fi, תקורת פרוטוקול, אגירה (buffering) וההתנהגות של האפליקציה עצמה יכולים כולם ליצור קצב נמוך יותר או לא אחיד. הסיקו מסקנות לאורך העברה פעילה, ולא מרגע בודד.

אין מספר אחד שמתאים לכולם. קודם צפו באפליקציה בזמן פעילות מייצגת, ואז בחרו תקרה מתחת לקצב הרציף שלה, תוך השארת מספיק קיבולת כדי שהמשימה תתקדם באופן מועיל. הורידו את התקרה בהדרגה ובדקו אם העבודה המוגנת מתייצבת.

כשמגינים על שיחה, התחילו במעלה הקבצים שפועל ברקע ולא באפליקציית השיחה. רוויה של ערוץ ההעלאה עלולה לערער את השמע והווידאו גם כשבדיקת מהירות מראה קיבולת הורדה גבוהה. במשימה עתירת הורדות, הגבילו את הקצב הנכנס של אותה משימה והשאירו את הבקשות הקטנות שלה ללא הגבלה, אלא אם גם הן יוצרות בעיה.

אל תניחו שהמהירות המלאה שמפורסמת בחבילת האינטרנט זמינה באופן רציף. עומס ב-Wi-Fi, מכשירים אחרים, VPN ושירותים מרוחקים משנים את הקיבולת השמישה. תקרה מעשית צריכה להשאיר מרווח מתחת לקצב שנמדד בפועל בחיבור, במיוחד כשהיענות חשובה יותר מסיום ההעברה מהר ככל האפשר.

לבדיקות שחוזרות על עצמן, תעדו את ערכי ההעלאה וההורדה המדויקים ואת ההיקף שהגבלתם. מגבלה לפתרון בעיות בשימוש יומיומי ופרופיל בדיקה משרתים מטרות שונות: הראשונה מגינה על העבודה השוטפת, והשני צריך לשחזר תנאי מוגדר באופן עקבי.

הגבלת מהירות מאפשרת לתעבורה להמשיך מתחת לתקרה מפורשת. השתמשו בה כשההעברה לגיטימית אבל אגרסיבית מדי. חסימה היא עצירה מוחלטת, ומתאימה לבדיקות במצב לא מקוון או להעברה שאסור לה להמשיך. אם זו ההתנהגות הדרושה, המדריך הנפרד לחסימה מסביר איך לעצור ולשחזר בבטחה את שני כיווני התעבורה.

תעדוף נותן לתעבורה העדפה יחסית כשהקווים עמוסים; תקרה מפורשת נותנת ליעד שנבחר קצב מרבי קבוע. Throttlr מיישם תקרות, לא תור עדיפויות. קל יותר לחשוב על תקרה כשיודעים כמה מהחיבור משימת רקע רשאית לצרוך, אבל היא לא מבטיחה רוחב פס שמור לאפליקציה אחרת.

התניית רשת נועדה לשחזר סביבה מסוימת, לרוב על ידי שילוב של רוחב פס מוגבל עם השהיה, אובדן מנות או מאפיינים אחרים. Throttlr אינו מדמה השהיה או אובדן מנות. מפתחים שזקוקים לתנאים כאלה צריכים להשתמש בכלי התניה מתאים; המדריך לרשת איטית מתמקד בבדיקות המצומצמות יותר שאפשר לשחזר בעזרת כלי רוחב הפס והחסימה של Throttlr.

האפליקציה שאת החלון שלה אתם רואים היא לא תמיד התהליך שפותח את החיבור. משגרים, מעדכנים, שירותי XPC, הרחבות ספק קבצים, פריטי התחברות וסוכני גיבוי יכולים להיות הבעלים של התעבורה של מוצר מוכר. Throttlr מקבץ מזהי תהליכי עזר תחת אפליקציית האם כשהוא מצליח לזהות את הקשר ביניהם, ואילו שירותים שנחתמו בנפרד עשויים להופיע בשורות משלהם.

צרו העברה מוכרת ועקבו אחרי הקצב החי, במקום לבחור שורה רק לפי השם שלה. אם הגבלת האפליקציה הראשית לא משנה את ההעברה, חפשו תהליך עזר או שירות עם פעילות תואמת. היזהרו עם שירותי macOS משותפים, כי כלל עלול להשפיע על יותר מזרימת העבודה הגלויה שהתכוונתם לשלוט בה.

גרסת ההורדה הישירה יכולה לבחון תהליכים פעילים כדי להציג מטא-נתונים עשירים יותר על שירותי רקע. בגלל מגבלות ה-Sandbox של App Store, גרסת App Store מבקשת מכם לצאת ידנית מאפליקציה מושפעת לפני ש-Throttlr פותח אותה מחדש; הגרסה הישירה יכולה בדרך כלל לבצע בעצמה את רצף היציאה והפתיחה מחדש. שתי הגרסאות שומרות על כלי בקרת התעבורה שהוגדרו במהלך ההפעלה מחדש.