המחבר נבנה עם אפשרות להתממשקות מול מתאמים מיוחדים וזאת על מנת לשמור על תאימות למחברי ה-USB הקודמים.
ב-2014 הכריזה חברת אינטל כי היא תציג טלפונים וטאבלטים חדשים עם תאימות למחבר החדש ובהמשך גם מחשבים נייחים וכל מוצר אחר אשר עושה שימוש ב-USB יכיל את המחבר החדש.
המפרט הסופי של מחבר ה-Type-C נקבע ב-2014 והחל להיות מופץ ב-2015.
(USB On the Go (OTG.
USB OTG הוא התקן ל-USB 2.0 המאפשר להתקנים שונים שבדרך כלל פועלים כ"Slave" (כשמחוברים למחשב) לפעול כ"Master" אל מול התקן "Slave" אחר. באמצעות תקן USB OTG ניתן לדוגמה לחבר מקלדת רגילה או החסן נייד (דיסק און קי) למחשב כף יד או לטלפון חכם.
Wireless USB.
התקן המשחרר לחלוטין את הצורך בכבלים מסוג כלשהו על ידי יציאה משולבת מתאם המקיים קשר רדיו אלחוטי.
סימון החיבורים.
צבע חיבור.
בנוסף על סוגי החיבורים הפיזיים, קיים שוני בצבע החיבור, המצביע על קצבי העברת נתונים, והקצאות חשמל שונות.
שחור ולבן - רגיל, כחול - SuperSpeed (לרוב USB3), תכלת - SuperSpeed+, ירוק - Qualcomm Quick Charge, סגול - Huawei Supercharge, אדום, כתום וצהוב - High-Current או Sleep-and-Charge.
פרוטוקולים של USB.
שלא כמו RS-232 וממשקים טוריים דומים שבהם פורמט הנתונים הנשלחים אינו מוגדר, USB מורכב מכמה שכבות של פרוטוקולים.
כל עסקת USB מורכבת מ:
USB הוא אפיק ממוקד מארח. המארח יוזם את כל העסקאות. החבילה הראשונה, הנקראת גם אסימון, נוצרת על ידי המארח כדי לתאר מה יש לעקוב והאם עסקת הנתונים תהיה קריאה או כתיבה ומהי כתובת המכשיר ונקודת הקצה המיועדת. החבילה הבאה היא בדרך כלל חבילת נתונים הנושאת את המטען ואחריה חבילת לחיצת יד, המדווחת אם הנתונים או האסימון התקבלו בהצלחה, או אם נקודת הקצה נתקעה או לא זמינה לקבל נתונים.
חבילות USB נפוצות.
נתונים על ה-USBus מועברים תחילה LSBit. מנות USB מורכבות מהשדות הבאים,
כל החבילות חייבות להתחיל בשדה סנכרון. שדה הסנכרון הוא באורך 8 סיביות במהירות נמוכה ומלאה או באורך 32 סיביות עבור מהירות גבוהה ומשמש לסנכרון השעון של המקלט עם זה של המשדר. שתי הסיביות האחרונות מציינות היכן מתחילים שדות ה-PID.
PID מייצג מזהה מנות. שדה זה משמש לזיהוי סוג החבילה הנשלחת. הטבלה הבאה מציגה את הערכים האפשריים.
ישנם 4 סיביות ל-PID, אולם כדי להבטיח שהוא מתקבל כהלכה, 4 הסיביות מושלמות וחוזרות על עצמן, מה שהופך PID של 8 סיביות בסך הכל. הפורמט המתקבל מוצג להלן.
שדה הכתובת מציין לאיזה מכשיר מיועדת החבילה. אורך 7 ביטים מאפשר תמיכה ב-127 מכשירים. כתובת 0 אינה חוקית, שכן כל מכשיר שעדיין לא הוקצתה לו כתובת חייב להגיב למנות שנשלחות לכתובת אפס.
שדה נקודת הקצה מורכב מ-4 ביטים, המאפשרים 16 נקודות קצה אפשריות. עם זאת, להתקנים במהירות נמוכה יכולים להיות רק 2 נקודות קצה נוספות על גבי צינור ברירת המחדל. (4 נקודות קצה מקסימום)
בדיקות יתירות מחזוריות מבוצעות על הנתונים בתוך מטען החבילות. לכל מנות האסימון יש CRC של 5 סיביות בעוד לחבילות הנתונים יש CRC של 16 סיביות.
סוף חבילה. מאותת על ידי אפס בודד (SE0) למשך כ-2 פעמים סיביות ואחריו J למשך זמן של סיביות אחת.
סוגי חבילות USB.
ל-USB יש ארבעה סוגי חבילות שונים. חבילות אסימונים מציינות את סוג העסקה שיש לעקוב אחריה, מנות נתונים מכילות את המטען, מנות לחיצת יד משמשות לאישור נתונים או דיווח על שגיאות ומנות התחלה של מסגרת מציינות את תחילתה של מסגרת חדשה.
Hypertext Transfer Protocol
Hypertext Transfer Protocol (ראשי תיבות: HTTP) הוא פרוטוקול תקשורת שנועד להעברת דפי HTML ואובייקטים שהם מכילים (כמו תמונות, קובצי קול, סרטוני פלאש וכו') ברשת האינטרנט וברשתות אינטראנט. הפרוטוקול פועל בשכבת היישום של מודל ה-OSI ובשכבת היישום של מודל TCP/IP. שרתי HTTPS הם שרתי התוכן המרכזיים ברשת האינטרנט ודפדפנים הם תוכנות הלקוח הנפוצות ביותר לפרוטוקול HTTPS.
התקשורת ב־HTTP מתחילה ביצירת שיחה בין השרת ללקוח באמצעות פרוטוקול TCP בשכבת התעבורה של פרוטוקול TCP/IP, ונמשכת בסדרה של בקשות (requests) ותשובות (responses) שנשלחות על ידי הלקוח והשרת, בהתאמה. ראשית, הלקוח יוצר חיבור לכתובת ה-IP ולפורט שבו השרת נמצא, בדרך כלל פורט 80. לאחר מכן נשלחת הבקשה, הכוללת את הכתובת של האובייקט המבוקש (למשל, דף HTML) ופרטים נוספים על הבקשה ועל הלקוח. השרת קורא את הבקשה, מפענח אותה, שולח ללקוח תשובה בהתאם ולרוב מנתק את החיבור ללקוח כשהשליחה הסתיימה.
מעצם הגדרתו, פרוטוקול HTTP הוא – חסר מצבים. על מנת ליצור תקשורת בין הלקוח לשרת שמבוססת על היסטוריית הבקשות-תשובות בין השרת ללקוח נעשה שימוש בעוגיות (cookies). לדוגמה, שרת יכול לשתול במחשב הלקוח עוגייה עם אישור שהלקוח התחבר לחשבון מסוים עם סיסמה נכונה על מנת שלא יצטרך להקיש סיסמה בכל התחברות מחדש לאתר שמתארח על השרת.
היסטוריה.
בשנת 1991 פורסמה הגרסה הראשונה של הפרוטוקול שהייתה בשימוש (0.9). גרסה זו הייתה פשוטה ביותר ולא תמכה ברוב האפשרויות הקיימות כיום. שיטת הבקשה היחידה בגרסה זו הייתה GET, לא הוגדרו שדות כותרת והבקשות לא כללו את גרסת ה-HTTP כפי שהן כיום. כתוצאה מכך הלקוח לא יכול היה להעביר לשרת שום אינפורמציה נוספת פרט לכתובת של העמוד המבוקש. התשובה של השרת הכילה את האובייקט שכתובתו ניתנה בבקשה, גם כן ללא שדות כותרת, ואינדיקציה לסוף ההודעה ניתנה על ידי ניתוק חיבור ה-TCP על ידי השרת. מכיוון שהתשובות הכילו רק את האובייקט המבוקש, הודעות שגיאה נשלחו גם הן בפורמט HTML ולא היה ניתן להבחין ביניהן לבין דפים רגילים.
במאי 1996 התפרסמה גרסה 1.0 של הפרוטוקול, שנמצאת עדיין (אוקטובר 2007) בשימוש נרחב בעיקר על ידי שרתי פרוקסי. בגרסה זו נוספו שיטות הבקשה HEAD, POST, PUT, DELETE, LINK ו-UNLINK ובקשות נדרשו לציין את גרסת הפרוטוקול. תשובות השרת כללו עתה פרט לתוכן הדף המבוקש, קוד מיוחד שמציין את תוצאת הבקשה (ראו להלן), מלווה בהסבר טקסטואלי בן מספר מילים על משמעות הקוד. הוגדרו כ-30 שדות כותרת, שנועדו בין השאר לייעל את השימוש במטמון, לציין מראש את אורך ההודעה, לאפשר הפניות אוטומטיות בין דפים ולהעביר מידע נוסף.
הגרסה הנוכחית, HTTP/1.1, פורסמה ביוני 1999 והתבססה ברובה על גרסה 1.0. ההבדלים העיקריים בין גרסה זו לקודמתה הם שליטה טובה יותר במטמון, הוספת שיטות הבקשה OPTIONS ו-TRACE, תמיכה ב-virtual hosts, ותוספות מתקדמות שמטרתן לייעל את אופן הפעולה של הפרוטוקול. כמו כן, הוסרו מספר אפשרויות שהיו קיימות בגרסה הקודמת, לרוב משום שנמצאו לא שימושיות. מאפיין חשוב שנתמך בגרסה זו הוא האפשרות להשתמש בחיבור יחיד עבור מספר בקשות, במקום לפתוח חיבור חדש עבור כל אובייקט שנמצא בדף שהתקבל בתשובה הראשונה.
נעשו ניסיונות להרחיב את הפרוטוקול וליצור גרסה 1.2, אך הם לא יצאו לפועל.
בקשות HTTP.
בקשות HTTP מורכבות מהנתונים הבאים:
שיטות בקשה.
נכון לגרסה 1.1, קיימות 8 שיטות בקשה: GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE ו-CONNECT. ניתן לסווג אותן בשני אופנים: שיטות בטוחות לעומת שיטות לא בטוחות, ושיטות אידמפוטנטיות (idempotent) לעומת שיטות שאינן אידמפוטנטיות. סיווגים אלו נועדו להוות אינדקציה כללית עבור שרתים, דפדפנים ובוני אתרים באשר למידת ההשפעה של כל אחת מהשיטות על השרת ועל הלקוח.
שיטות בטוחות מוגדרות ככאלה שמיועדות רק לשם קבלת מידע מהשרת; הן לא אמורות לשמש, למשל, לשליחת מידע מהלקוח לשרת, לביצוע שינויים כלשהם במסדי נתונים שנמצאים על השרת וכו'. במילים אחרות, אין לשיטות אלה תופעות לוואי, למשל תוצאות, פרט לקבלת מידע. GET ו-HEAD נחשבות לשיטות בטוחות.
שיטות אידמפוטנטיות הן שיטות ששליחה חוזרת שלהן גורמת בדיוק לאותן תוצאות כמו שליחה אחת. שיטות שהן בטוחות הן, לפי ההגדרה, גם אידמפוטנטיות, משום שאין להן כלל תופעות לוואי. השיטות PUT ו-DELETE גם הן נכללות בסיווג זה. במקרה של DELETE, למשל, בקשה נוספת למחיקה של אותו פריט תגרום לכך שהפריט לא ימצא על השרת. אפילו אם הוא כבר לא היה עליו אחרי בקשה אחת, התוצאה של הבקשות החוזרות היא בדיוק אותה תוצאה של הבקשה הראשונה.
אלו הן שיטות הבקשה הנתמכות בגרסה 1.1:
כל שרתי ה- HTTP הכלליים נדרשים ליישם לפחות את שיטות ה-GET וה-HEAD. כל שיטה אחרת נחשבת אופציונלית.
כתובות בבקשות HTTP.
כתובת בבקשת HTTP יכולה להיות כתובת מלאה (כמו: http://www.w3.org/Protocols) או כתובת יחסית לשרת (בדוגמה זו, Protocols/). השימוש בכתובות יחסיות הוא הנפוץ ביותר, דבר שהקשה בעבר על אחסון של מספר אתרים על אותו שרת, משום שהשרת לא יכול היה לדעת לאיזה אתר מבין האתרים המאוחסנים אצלו מכוונת הבקשה. כדי לפתור את הבעיה מבלי לאבד את התמיכה לאחור בגרסאות קודמות, גרסה 1.1 מחייבת כל בקשה לכלול שדה כותרת בשם host, שערכו הוא שם המתחם של האתר אליו מיועדת הבקשה.
תשובות HTTP.
לאחר קריאת הבקשה ששלח הלקוח, השרת מחזיר תשובה שמכילה:
קוד המצב ומשמעותו.
כאמור, קוד המצב מורכב ממספר תלת ספרתי והסבר קצר (בן שורה אחת) על משמעות הקוד. המספרים מחולקים ל-5 מחלקות, בהתאם לספרה הראשונה שלהם:
1xx – ההודעה מכילה מידע בלבד.
2xx – הבקשה ששלח הלקוח בוצעה בהצלחה על ידי השרת, והתשובה מכילה את מה שהשרת נתבקש לשלוח בהתאם לשיטת הבקשה.
3xx – הבקשה פוענחה בהצלחה, אך מסיבות כלשהן התשובה אינה כוללת את האובייקט המבוקש (למשל, משום שהעמוד מפנה אוטומטית לעמוד אחר).
4xx – נמצאה שגיאה כלשהי בבקשה עצמה.