IPv6

IPV6 היא הגרסא הבאה של פרוטוקול האינטרנט, שכבר מתבשלת כמה שנים טובות.
השינוי המרכזי ביותר, והמוטיבציה הגדולה של השינוי נובעת מהבעיה המחריפה והולכת של חוסר בכתובות IP פנויות. בIPV4 – הגרסא הנוכחית, כל כתובת תופסת 4 בתים שהם 32 ביט, מה שאומר שיש 2 בחזקת 32 כתובות אפשריות שזה קצת יותר מארבע מיליארד כתובות אפשריות.
התקן של IPV4 נקבע ב1981, ארבע מיליארד כתובות נראו אז כמו הגזמה פראית, ואף אחד לא דימיין שבתוך כמה עשרות שנים יהיה צורך ביותר כתובות.
השוק התמודד עם המגבלה במספר כתובות הIP במספר צורות:

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

NAT
מכיוון שאין מספיק כתובות IP לתת לכל מחשב או לכל מכשיר נייד (כן, לסלולרי שלכם יש כתובת IP), קמו חכמים וחשבו:
מה אם נגדיר טווח כתובות מיוחד (או כמה טווחים) שישמש לרשתות פנימיות בלבד, ולא יהיה חוקי באינטרנט הגדול?
זה יאפשר לנו לבחור כתובות IP למחשבים ברשת הפנימית שלנו בלי תלות במספר הכתובות האמיתיות שלנו (שעולות לא מעט).
הבעיה עם זה היא שאם הכתובות לא חוקיות באינטרנט, איך מחשב כזה יכול לתקשר עם מחשבים מחוץ לרשת הפנימית שלו (בה הכתובות חוקיות)?
ברגע שנתב שם בחוץ יראה חבילת מידע עם הכתובת שלו ככתובת יעד, הוא לא ידע לאן לנתב אותה ויזרוק אותה לסל המיחזור של החבילות.
הפתרון הוא NAT, או Network address translation. הרעיון די פשוט: נשים מחשב (או נתב) אחד עם כתובת IP אמיתית, וננתב את כל חבילות המידע שנשלחות החוצה מהרשת שלנו דרכו. המחשב הזה ישנה את פרטי החבילה כך שכתובת הIP ממנה היא נשלחה תהיה שלו, יזכור את פורט המקור של החבילה, וישלח אותה.
ברגע שמגיעה חבילה שממוענת אל אותו מחשב NAT, הוא יבדוק את החבילה, יסיק לפי מה שהוא זוכר לאיזה מחשב ברשת הפנימית החבילה ממוענת, יתקן את הכתובת והפורט לפרמטרים הנכונים ויעביר את החבילה.
גישה זו מאפשרת לרשת עם עשרות או מאות מחשבים להתחבר לאינטרנט עם כתובת IP אמיתית אחת בלבד.
NAT

שני הפתרונות האלו (ועוד כמה פחות משמעותיים) הורידו את דחיפות הפיתרון האמיתי, שהוא מעבר לIPV6.

IPV6
השינוי המרכזי בIPV6 הוא הרחבת טווח הכתובות האפשריות. במקום 4 בתים לכתובת IPV4, יש לא פחות מ16 בתים בכתובת IPV6.
קצת מתמטיקה:
4 בתים הם 32 סיביות. 2 בחזקת 32 זה 4,294,967,296,
4 מיליארד כתובות בIPV4.
16 בתים הם 128 סיביות, 2 בחזקת 128 זה:
340,282,366,920,938,463,463,374,607,431,770,000,000
340 מיליארד מיליארד מיליארד מיליארד כתובות בIPV6.
אז תחום הכתובות של IPV6 יספיק להרבה הרבה זמן.

שיפורים נוספים בIPV6
IPV4 לא תוכנן להיות מאובטח בשום רמה, ובשלב מסויים הוגדר תקן IPSec, אבל גם אחרי שהוא הוגדר הוא היה אופציונלי ולא מחויב.
בIPV6 לעומת זאת, האבטחה מוגדרת כחובה, והיא בנויה בצורה יותר טובה.
למשל, בIPV4 – נתמכת הצפנה של תוכן ההודעות בלבד (payload), ובIPV6 נתמכת הצפנה של התוכן והכותרת (header).

שיפורים נוספים הם תמיכה מובנית בתעדוף תעבורה מסויימת (QOS), הגדרה אוטומטית (Auto-configuration), חבילות נתונים גדולות לשיפור ביצועים ברשתות שמעבירות הרבה מאוד מידע (JumboGrams, חבילות נתונים בIPV4 מוגבלות לגודל של 65535 בתים, בIPV6 לעומת זאת החבילות יכולות להגיע לגודל 4 ג'יגה לחבילה)

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

ייצוג טקסטואלי של כתובות IPV6
אנשים רגילים לכך שכתובת IP הן מהצורה המקובל של a.b.c.d, כאשר כל מספר הוא בן 0 ל255.
בIPV6 התמונה משתנה, במקום 4 קבוצות בין 0 ל255, פתאום יש לנו 8 קבוצות של 0 עד 65535, שמיוצגות בבסיס 16, ומופרדות על ידי נקודותיים.
למשך:
[code]
2001:0db8:0000:0000:0000:0000:1428:57ab
[/code]
יהיה לא נעים להקריא את זה בטלפון.
כדי לעזור קצת, הוגדר הקיצור הבא:
סדרת אפסים אחת בכתובת יכולה להתכווץ לצמד נקודותיים, ואפשר גם להתעלם מאפסים שפותחים קבוצה – מה שאומר שאת הכתובת הזו אפשר לכתוב גם כך:
[code]
2001:db8::1428:57ab
[/code]
קצת יותר טוב.

FireStats וIPV6.
עד גרסא 1.4, פיירסטטס מאכסן כתובות IP בתוך מחרוזת תווים, ולכן תומך גם בIPV4 וגם בIPV6.
אחד הפיצ'רים המבוקשים ביותר הוא היכולת להתעלם מטווח של כתובות IP.
עד 1.4, ניתן להוסיף כתובות מסויימות לרשימת ההתעלמות, אבל זה לא מספיק כשרוצים להתעלם מטווח שלם, למשל כדי לסנן את הספאם של מייקרוסופט.
כדי לתמוך בסינון לפי טווח כתובות, הכי טוב לשמור את כתובת הIP כמספר ולא כמחרוזת – כי אז אפשר לבדוק אם המספר נמצא בטווח בקלות.
אבל באיזה כתובות IP לתמוך?
אומנם 99% מהמשתמשים עובדים עם IPV4 בלבד, אבל אם אני אסתמך על זה, זה בעצם אומר שאני מבטל את התמיכה בIPV6, צולעת ככל שתהיה.
לא ממש רציתי לעשות את זה, ולכן החלטתי לתמוך בIPV6 גם אחרי המעבר משמירת כתובות טקסטאלית לשמירה מספרית.

אבל איך שומרים כתובת IPV6 בMySQL כמספר? הטיפוס המספרי הגדול ביותר בMySQL הוא BIGINT, שרוחבו 8 בתים, וסיכמנו כבר שכתובת IPV6 היא ברוחב 16 בתים.
הפתרון הוא להשתמש בשתי עמודות של BIGINT, אחת לחצי הימני של כתבות הIP והשניה לחצי השמאלי.
קצת מכוער, אבל זה המצב.
בעיה נוספת שצריכה התייחסות מיוחדת היא בעיית ההצגה והקליטה של כתובות IP.
כשמגיעה כתובת IP טקסטואלית למערכת, צריך להבין מאיזה גרסא היא, ולתרגם אותה לייצוג מספרי.
כשרוצים להציג כתובת IP מספרית, צריך לעשות את הפעולה ההפוכה ולהציג אותה בצורה הידידותית ביותר (IPV4 אם הכתובת המקורית היא בIPV4, אחרת IPV6).
מכיוון שהתמיכה בIPV6 בPHP די צולעת – קיימות פונקציות, אבל רק מגרסאות חדשות של PHP וגם אז הן לא נתמכות בכל מערכות ההפעלה – כתבתי את פונקציות ההמרה והזיהוי בעצמי.
אפשר לראות בתמונה טווח IPV6 ליד כתובת IPV4 בודדת:
firestats ipv6

קריאה נוספת:

IPv6: The Promise, The Problems, The Protocol
ווקיפדיה

כותרות הסופ"ש

והרי כותרות הסופ"ש:
יום שישי
שוחררה תוכנת ההתקנה FireStats Installer, שמאפשרת התקנה מהירה של FireStats.
FireStats Installer מוריד את הגרסא האחרונה של FireStats, פורש אותה ומוודא שכל הקבצים תקינים – כל זה על השרת בצורה מהירה ואמינה.

יום שבת בבוקר
שוחררה גרסא 1.0.0 של Plugin Commander
Plugin Commander הוא תוסף לWordPress MU שמאפשר הפעלה אוטומטית של תוספים לבלוגים חדשים וכן כיבוי והדלקה של תוספים עבור כל הבלוגים.
בגרסא החדשה נוספה תכונה נוספת שחסרה בWordPress MU, והיא היכולת לשלוט על רשימת התוספים שמשתמשים יכולים להדליק ולכבות.

שבת בערב
שוחררה FireStats 1.4.3-RC1, גרסא זו היא מועמדת לשחרור רשמי של FireStats 1.4 (מה חדש?), וכוללת כמה תיקוני באגים.
עם הגרסא הזו, FireStats 1.4 נחשב כבר מספיק יציב, ופתחתי את הברז של ההתראה על גרסא חדשה, מה שאומר שצפוי גשם של מורידים בימים הקרובים, לא לשכוח מטריות.

מיקרוספאם

מזה מספר חודשים אני רואה בפיירסטטס של firestats.cc זרימה הולכת וגוברת הפניות חיפוש ממנוע החיפוש של מיקרוסופט:
Microsoft spam

מסתבר שההפניות, שמכילות UserAgent מזוייף ודף מפנה מזוייף (עם מילות חיפוש שלא באמת מובילות אלי), יוצאות – תאמינו או לא – משרתי מייקרוסופט.
יש שני טווחי כתובות IP שמהן יוצאות הבקשות:

65.55.165.*
131.107.151.*

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

Second, we want to explain what this is all about. The traffic you are seeing is part of a quality check we run on selected pages. While we work on
addressing your conerns, we would request that you do not actively block the IP addreses used by this quality check; blocking these IP addresses could prevent your site from being included in the Live Search index.

אז מייקרוסופט מודים שזה הם (כאילו הם יכלו להסתתר באמת), וטוענים – תחזיקו – שהם עושים לדפים נבחרים בדיקת איכות!
ואו, הרבה תודה מייקרוסופט, עכשיו שבדקתם את איכות הדפים שלי (תודה תודה!), אתם מוכנים (תודה!) להפסיק לזבל לי את הסטטיסטיקות בצואה דיגיטלית?
(הממ, צואה דיגיטלית = דואה?)
מה שיפה זה שהם טוענים שאם תחסמו את כתובות הIP האלו, אתם עלולים לא להיות מאונדקסים על ידי הזחלנים של מנוע החיפוש של מייקרוסופט.
אכן טרגדיה, הרי אני מקבל כל כך הרבה הפניות משם שפשוט חבל לחסום אותו, כהוכחה – ראו את התמונה המצורפת למעלה, כמעט כל ההפניות מLive!

אגב, ניתן לזהות בקלות שאלו הפניות מאותה חווה גם על פי הדף המפנה, שמכיל תמיד את המילה LIVOP, למשל:

http://search.live.com/results.aspx?q=custom&mrt=en-us&FORM=LIVSOP

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

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

FireStats 1.4.0-beta

שחררתי בטא ראשונה של FireStats 1.4.
בין השינויים:

  • זמני עליה משופרים של המסך הראשי.
  • תמיכה בריבוי משתמשים (כולל אימות והגדרות אישיות)
  • תמיכה בכותרות פוסטים של וורדפרס (אם יש כותרת זמינה היא תוצג במקום הURL)
  • שיפור משמעותי של תצוגת המפנים האחרונים
  • ווידג'ט וורדפרס חדש של פוסטים פופולריים
  • תמיכה בWPMU
  • שיפור משמעותי בביצועים של הוידג'טים.

אפשר לראות את רשימת השינויים המשמעותיים (כולל תמונות!) פה.
כמו שהשם מרמז, זו גרסאת בטא. Buyer beware.

וורדקאמפ ישראל 2007 יוצא לדרך

רשמו לפניכם, ב25 לאוקטובר במכללת אפקה יתקיים וורדקאמפ ישראל 2007.
הכנס מתאפשר בעיקר תודות לעבודה הקשה של טל גלילי, שהביא את זה על עצמו (מגיע לך!).
לורל מLorelle on WordPress תהיה שם כמרצה אורחת (!), ועוד הרבה אנשים מעניינים.
גם אני אהיה שם, ואקשקש קצת על FireStats (אלא אם אני אשתפן ברגע האחרון).
בקיצור, הרשמו לפני שיגמר המקום, יהיה אחלה.

wpil2007.gif

וורדפרס 2.3, בעיית פרטיות

אחד החידושים בוורדפרס 2.3 הוא היכולת של המערכת לבדוק קיום של גרסא חדשה, של עצמה ופוטנציאלית גם של הפלאגינים שמותקנים.
הבעיה עם הפיצ'ר המתבקש הזה הוא שוורדפרס שולחת בלי צורך אמיתי את הURL של הבלוג שלכם אל ספינת האם.
אין סיבה אמיתית לשלוח את המידע, ואין אפשרות לכבות את זה בלי לשנות את הקוד או להתקין פלאגינים שנכתבו במיוחד בשביל לנטרל את הפונקציונליות הזו.
כשנודע על הפיצ'ר הריגולי החדש, קמה מהומה קטנה ברשימה של wp-hackers, ואני בתוכה, וביקשנו הסברים לצורך לשלוח נתונים שמאפשרים לזהות את בעל הבלוג.
מאט נפנף את המודאגים ("תעשו פורק", "תתקינו פלאגינים", "זה לא מזיק", "אולי יום אחד נצטרך את זה") ולא ממש נתן הסברים מספקים.
הזהרתי שזה יתפוצץ, וכך היה.
אני אישית מתכוון לנטרל את הפעולה הזו פשוט על ידי שינוי הקוד כך שישלח URL אחר אל ספינת האם, אולי את זה של הבלוג של מאט, כי הרי זה לא מזיק.

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

כמפתח תוכנה בעצמי אני מודע היטב לצורך לדעת כמה שיותר מידע על ההתקנות של התוכנה שלי, ואפילו הוספתי לFireStats אפשרות לשלוח לי מידע.
ההבדל הוא שהמידע נשלח אלי רק בעקבות הסכמה מפורשת של המשתמש, ושהמידע שנשלח אלי הוא אנונימי.
למעשה, הצעתי ברשימת התפוצה של wp-hackers לעשות את אותו דבר (ואפילו לתרום קוד אם צריך) עוד לפני שהתפוצץ כל העניין, והרבה אנשים הביעו עניין ברעיון.
אף אחד, כולל מטורפי הפרטיות הגדולים ביותר לא התנגד להוסיף את האפשרות הזו כל עוד היא בגדר אפשרות, והיא מופעלת רק בעקבות אישור מפורש של המשתמש.
מאט העדיף להתעלם, ולהשאיר את המימוש הפולשני ששולח בשקט מידע בלי אפשרות מובנית לבטל את הפעולה.

אני חושב שהגלים מההתנהלות הזו רק מתחילים.

שיקולים ולבטים בתכנון בסיס הנתונים של FireStats

כשהתחלתי לפתח את פיירסטטס הייתי חסר נסיון מעשי בפיתוח של בסיסי נתונים, הייתי אומנם אחרי קורס של מבוא לבסיסי נתונים בפתוחה, שנתן לי את הרקע התאורטי, אבל לא היה לי את הרקע המעשי.
לאור זה, אני חושב שזה יפה שהצלחתי לתכנן בסיס נתונים בצורה מספיק חכמה כדי שהוא יוכל להתפתח ולהשתנות (כמעט מדי גרסא גדולה 1.x -> 1.y).
למרות זאת, לפעמים אני מפקפק בהחלטות תכנון שעשיתי אז וחושב שאולי הייתי עושה אחרת עכשיו.
למזלי, האפשרות לשנות את בסיס הנתונים מגרסא לגרסא קיימת ועובדת בפועל.

פיירסטאטס התבססה בהתחלה על Counteirze, שהיה בעל מבנה פשוט מאוד בבסיס הנתונים: טבלא אחת.
יש כמה בעיות עם התכנון הזה:
*הוא בזבזני מאוד במקום כי כל כתובת מפנה את מחרוזת דפדפן (UserAgent) תופיעה שוב ושוב ושוב.
* קשה להרחיב אותו לתמוך בנתונים נוספים בלי להחריף את בעיית המקום.
אחת ההחלטות הראשונות שעשיתי היתה לעבור למבנה מנורמל, שבו על כתובת מפנה ומחרוזת דפדפן נשמרות פעם אחת בטבלאות נפרדות, וטבלאת הכניסות מכילה מזהה יחודי של כל אחד מהשדות האלו בעמודה הרלוונטית.

טבלאת הכתובות נראית היום כ:
urls table
טבלאת ההמפנים נראית היום כך:
referrers table

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

במסגרת רצון להוסיף תמיכה בווידג'ט של פוסטים פופולריים הוספתי טבלאת METADATA לטבלאת הURLים.
הmetadata יכול להכיל פרטים כמו כותרת של הפוסט, אם יש, וסוג הכתובת (post, לינק להורדה בהמשך ועוד).

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

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