?Is it possible to apply better compression to Netfree HTTP traffic

yzahn

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

@yzahn said in Is it possible to apply better compression to Netfree HTTP traffic:

I am throwing out an idea which isn't fully thought through. I am unsure if this feature is at all technically possible, and how much of a benefit it will be.
The problem is that the http protocol allows various 'transfer-encoding's, some of which are compressed. This can cause enormous speed and bandwidth savings depending on the compression quality and the data being transferred. I have noticed that Netfree removes any {transfer|content}-encoding from the traffic that passes through it and passes it on to the end user uncompressed with transfer-encoding: chunked.
The obvious problem with dealing with compressed data is that it must be decompressed for inspection/injection so it obviously must be decompressed in transit. The question is can it be recompressed before continuing on it's way?
I am not an expert in the HTTP protocol but from a very quick skimming of some MDN articles it would seem that any transfer-encoding other than chunked must include a content-length header. This would mean that the entire HTTP response must have been received and have passed filtering before Netfree can pass it on to the client. This obviously would introduce a major latency. This would explain the lack of compression since as such Netfree can begin transferring content to the client before knowing the final content-length.
My questions therefore are as follows:

Am I correct that there is no way of transferring compressed data without knowing before hand the content-length.
In the real world, how much extra volume is being transferred due to the lack of compression?
Can compression be introduced in cases where the page static and the final content-length can be known before the full HTTP response has been received and filtered.
And for some bonus points I think that Netfree doesn't allow QUIC and HTTP/2. So, can anyone say, how much would customers benefit from HTTP/2 and is it at all possible to allow it with keeping it's benefits?

I would love it if people can weigh in on this.

אשמח מאוד לתגובות ענייניות.

לתצוגה משמאל לימין אפשר לקרוא אותו כאן

test

@magicode אמר בקיבלתי סימן.:

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

yzahn

גם אני שיודע אנגלית טוב מבין בקושי מה שכתוב בפטנטים! הם כתובים בשפה משפטית ע"י עו"ד מפולפלים ולא מיועדים עבור אנשים ישרים לקרוא.

מעמד

@yzahn אמר ב?Is it possible to apply better compression to Netfree HTTP traffic:

גם אני שיודע אנגלית טוב מבין בקושי מה שכתוב בפטנטים! הם כתובים בשפה משפטית ע"י עו"ד מפולפלים ולא מיועדים עבור אנשים ישרים לקרוא.

@test אמר ב?Is it possible to apply better compression to Netfree HTTP traffic:

@magicode אמר בקיבלתי סימן.:

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

@yzahn @test מה זה קשור לנושא שנפתח ???

yzahn

@מעמד אמר ב?Is it possible to apply better compression to Netfree HTTP traffic:

@yzahn @test מה זה קשור לנושא שנפתח

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

טוב, נחכה בסבלנות...

מעמד

פוסט זה נמחק!

מרדכי

@yzahn תתרגם את זה לעברית אולי זה יעזור

yzahn

הנה תרגום הודות לגוגל, עם קצת עזרה ממני...

אני מציע כאן רעיון שעדיין אינו מחושב במלואו. אני לא יודע אם תכונה זו בכלל אפשרי מבחינה טכנית, וכמה תועלת זה יהיה (כמו שנסביר להלן בחלק השאילות).
נקדים שפרוטוקול HTTP מאפשר קידודי העברה שונים, חלקם דחוסים. זה יכול לגרום לשיפור עצומה במהירות וחיסכון ברוחב הפס, בהתאם לאיכות הדחיסה וסוגי הנתונים שמועברים. שמתי לב ש- Netfree מסירה כל הידר (header בלע"ז)transfer-encoding וcontent-encodingמהתנועה העוברת דרכה ומעבירה אותו למשתמש הקצה לא דחוס עם tranfer-encoding:chunked.
הבעיה הברורה בהתמודדות עם נתונים דחוסים היא שזה חייב לעבור אי-דחיסה עבור סינון/הזרקת תוכן ולכן זה חייב להיות לא דחוס בשלב מסויים במעבר. השאלה היא האם ניתן לחזור ולדחוס לפני המשך הדרך?
אני לא טוען להיות מומחה בפרוטוקול HTTP אבל מתוך קריאה מהירה של כמה מאמרים בMDN זה היה נראה כי כל קידוד העברה מלבד chunked חייב לכלול הידר content-length. משמעות הדבר היא שתגובת HTTP כולה חייבת להתקבל ולעבור סינון לפני ש- Netfree יכולה להעביר אותה אל הלקוח. זה ללא ספק יגרום להאטה משמעותית. זה יסביר את חוסר דחיסה בNetfree שכן כך Netfree יכול להתחיל להעביר תוכן ללקוח לפני לדעת את אורך התוכן הסופי.
השאלות שלי לכן הם כדלקמן:

האם אני צודק בטענתי שאין דרך להעביר נתונים דחוסים מבלי לדעת מראש את אורך התוכן.
בעולם האמיתי, כמה נפח מתווסף לתעבורה טיפוסית בשל חוסר דחיסה?
האם ניתן עדיין להשתמש בדחיסה במקרים שבהם הדף סטטי ואורך התוכן הסופי יכול להיות ידוע מראש לפני שתגובת HTTP מלאה התקבלה ועברה סינון.
ועוד שאילה לנקודות בונוס אני חושב Netfree אינו מאפשר את הפרוטוקולים QUIC ו HTTP/2. האם מישהו יכול לומר, כמה משמעותי הוא עבורנו והאם בכלל אפשרי לאפשר את זה עם שמירה על היתרונות שלו?

אשמח לקבל תגובות

magicode

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

yzahn

@magicode אמר ב?Is it possible to apply better compression to Netfree HTTP traffic:

ראשית כל, אני מודה לך על התגובה, וגם על כל מה שעשית ואתה עושה למען נטפרי וכו' וכו'

אפשר לדחוס גם בלי לדעת את האורך.

השאילה המתבקשת א"כ למה הדחיסה מורדת ע"י נטפרי
לקחתי איזה עמוד בצורה אקראי לגמרי

Transfer-Encoding: chunked
x-netfree--content--encoding--remove: gzip
x-netfree--content--length--remove: 32758

הcontent-length שהתקבל למעשה (בלי הידר כזה כמובן כי זה הועבר כchunked) היתה 176344 יותר מפי 5!

תלוי בנתונים.

ברור. תמונות וקבצי שמע ווידיאו בין כך דחוסים. שאילתי היתה מה היחס של הקבצים שיהנו מדחיסה לעומת אלו שלא צריכים. לדעתי זה די משמעותי אם כי לא ערכתי מחקר מדעי... כי html css וjs כולם יהנו מאוד מדחיסה.

magicode

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

yzahn

@magicode כל שרת כמעט ברחבי האינטרנט דוחס את התשובות שלו (גם אם אינו דף סטטי שאז אפשר לדחוס מקודם) נ"ל שהנטל על המעבד ממש זניח (תלוי בכמה פרמטרים שאפשר להגדיר). אולי לפחות כדאי לבדוק את הנושא? ובמקביל לנסות לקבל תמונה של כמה זה משפיע על רוחב פס בשימוש "רגיל" (קשה להגדיר מה שימוש רגיל, אולי אפשר לקבל מדגם מיצג ע"י נסיון במכונת סינון אחד מתוך כלל משתמשי נטפרי)

yzahn

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

yzahn

@האברך אמר ב?Is it possible to apply better compression to Netfree HTTP traffic:

אני חושב ש @test התכוין שכנראה @yzahn מצפה לתשובה מ @magicode

השאילה לא כוונה ספציפית ל@magicode אם כי אני שמח שהוא הגיב.

yzahn

@magicode אמר ב?Is it possible to apply better compression to Netfree HTTP traffic:

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

אם אפשר שוב לשגע את המוח עם השאילות המיותרות שלי...

האם יש אפשרות טכנית להוסיף אפשרות זו?

magicode

@yzahn אמר ב?Is it possible to apply better compression to Netfree HTTP traffic:

@magicode אמר ב?Is it possible to apply better compression to Netfree HTTP traffic:

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

אם אפשר שוב לשגע את המוח עם השאילות המיותרות שלי...

האם יש אפשרות טכנית להוסיף אפשרות זו?

בשביל להוסיף את זה צריך הרבה פיתוח שהוא נדרש יותר מאשר נוחות.
זה פיתוח של נוחות וזה דורש הרבה משאבים.

יעקב.אא

גם אני חושב שזה פיתוח מאוד רצוי , האם אפשר להוסיף ל- 'פיתוח תכונות חדשות'

nigun

משהו התקדם עם זה בסוף?
אני רואה שהחיבורים עדיין על HTTP/1.1

shloimy95

@nigun אם אתה בודק את לוח המפתחים בכרום אתה רואה שהרבה תוכן נטען על http/2.

Http/3 (QUIC) עדיין לא בשימוש נפוץ אז לא יודע אם יש דרך קלה לבדוק. אני מניח שאם אתה משתמש במכשיר לא מסונן ובמקרה רואה http/3 אתה יכול לנסות לטעון את האתר הזה ב-netfree ולראות מה קורה.

nigun

@shloimy95
צודק, אני בדקתי מול שרת שלי שחשבתי שהוא על http/2
מסתבר שהוא על HTTP/1.1.
אני יכול לנסות להקים שרת http/3 ולנסות לקרוא לו (ולבדוק קודם שהוא באמת על http/3)