fastboot協議版本0.4
***********************************=
fastboot協議是一種通過usb連線與bootloaders通訊的機制。
它被設計的非常容易實現，能夠用於多種裝置和執行linux、windows或者osx的主機。
基本需求（basic requirements）
* 兩個端點，乙個輸入端，乙個輸出端。
* 對於全速（full-speed）usb，最大包尺寸必須是64個位元組；
對於高速（hign-speed）usb，最大包尺寸必須是512個位元組。
* 協議完全是主機驅動（ssw注：相對於裝置客戶端而言），並且同步的。
這與多通道、雙向、非同步的adb協議不同。
傳輸和組幀（transport and framing）
步驟1、主機傳送命令（command）。
乙個命令是乙個ascii字串，並且只能包含在不大於64個位元組的單個包內。
步驟2、客戶端（ssw注：裝置）用乙個單個的不大於64個位元組的包響應。
響應包開頭四個位元組是「okay」、「fail」、「data」或者「info」。
響應包剩餘的位元組可以包含ascii格式的說明性資訊。
a、info -> 剩餘的60個位元組包含說明資訊（提供進度或者診斷資訊）。
這些說明資訊應該被顯示，然後重複步驟2。
b、fail -> 指示請求的命令失敗。
剩餘的60個位元組可以提供乙個文字形式的失敗原因呈現給使用者。互動停止。
c、okay -> 指示請求的命令成功完成。跳轉到步驟5。
d、data -> 請求的命令已經為資料階段做好準備。
乙個資料響應包是12個位元組長，組織形式為data00000000，
其中8位十六進製制的數字表示所傳輸資料的總大小。
步驟3、資料階段。
根據命令的不同，主機或者客戶端將傳送指定大小的資料。
比指定長度短的包總是可接受的，零長度的包將被忽略。
這個階段會一直持續，直到客戶端已經傳送或接收了上面資料響應包中指定大小的位元組數為止。
步驟4、客戶端用乙個單個的不大於64個位元組的包響應。
響應包開頭四個位元組是「okey」、「fail」或者「info」，類似於步驟2。
a、info -> 顯示剩餘的60個位元組，然後返回到步驟4。
b、fail -> 顯示剩餘的60個位元組（如果有的話）作為失敗原因，命令失敗，停止互動。
c、okay -> 成功。跳轉到步驟5。
步驟5、命令執行成功。
結束互動。
示例會話（example session）
host：主機 client：客戶端（裝置）
host： "getvar:version" 請求版本號
client: "okay0.4" 返回版本為"0.4"
host: "getvar:nonexistant" 請求未定義的變數
client: "okay" 返回值為""
host: "download:00001234" 請求傳送0x1234大小的位元組資料
client: "data00001234" 準備好接收資料
host: < 0x1234 bytes > 傳送資料
client: "okay" 資料接收成功完成
host: "flash:bootloader" 請求重新整理資料到bootloader
client: "infoerasing flash" 指示狀態/進度為「擦除flash」
"infowriting flash" 指示狀態/進度為「寫入flash」
"okay" 重新整理成功完成
host: "powerdown" 傳送「關機」命令
client: "failunknown command" 命令執行失敗
命令參考（command reference）
* 命令引數以printf風格的轉義序列表示。
* 命令是ascii字串，傳送時不用引號（下面命令外使用引號僅僅為了在此文件中清楚的表達命令），傳送時也不以位元組0結尾。
* 以小寫字母開頭的命令是為本規範保留的，oem特定的命令不應該以小寫字母開頭，以防和規範的未來版本不相容。
這個命令是很有用的。
"powerdown" 裝置關機。
客戶端變數（client variables）
命令"getvar:%s"用來讀取客戶端變數，客戶端變數代表關於裝置和執行於裝置之上軟體的各種資訊。
當前已經定義的變數名稱如下：
version fastboot協議所支援的版本。
version-bootloader bootloader的版本字串。
version-baseband 基帶（baseband）軟體的版本字串。
product 產品名稱。
serialno 產品序列號。
secure 如果值是」yes「，說明這是乙個安全的bootloader，在它安裝或啟動映像之前，需要乙個簽名。
以小寫字母開頭的變數名被本規範保留，oem特定的變數名不應該以小寫字母開頭。
**
04 ip協議分析
單看這麼一張圖，彷彿ip包頭的結構是乙個二維的多行多列結構，事實上它應當是乙個只有一行的資料，但是擺不開，擺的開也看不見。現在這個東西，包括之前的，都是基於ipv4的基礎上進行的。之前提到過乙個叫mtu的概念，如果本層的資料大於這個mtu，此時就會對上兩層來的資料進行拆分，為了拆分以後的資料可以準確...
面試 04 HTTP協議
一面中，如果有筆試，考http協議的可能性較大。一面要講的內容 二面要講的內容 通常我們要答出以上四個內容。如果實在記不住，一定要記得後面的兩個 無連線 無狀態。我們分別來解釋一下。http協議的頭部有乙個資料型別，通過http協議，就可以完成不同資料型別的傳輸。連線一次，就會斷開，不會繼續保持連線...
HTTP協議版本差異
要規定了客戶端和伺服器之間的通訊格式，預設使用80埠。沒有首部 只能獲取純文字 只支援get方法.請求完成後即關閉tcp連線 除了get命令，還引入了post命令和head命令，豐富了瀏覽器與伺服器的互動手段。http請求和回應的格式也變了。除了資料部分，每次通訊都必須包括頭資訊 http head...