日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁 > 云知道 > >

TCP/IP協(xié)議詳解卷1學(xué)習筆記-IP校驗和與ICMP協(xié)議

云知道


IP數(shù)據(jù)報的檢驗和：
為了計算一份數(shù)據(jù)報的I P檢驗和，首先把檢驗和字段置為0 。然后，對首部中每個16 bit進行二進制反碼求和（整個首部看成是由一串16 bit的字組成），結(jié)果存在檢驗和字段中 。當收到一份I P數(shù)據(jù)報后，同樣對首部中每個16 bit進行二進制反碼的求和 。由于接收方在計算過程中包含了發(fā)送方存在首部中的檢驗和，因此，假如首部在傳輸過程中沒有發(fā)生任何差錯，那么接收方計算的結(jié)果應(yīng)該為全1 。
這個是原文 ?？匆恍┚W(wǎng)絡(luò)程序的源碼時，發(fā)現(xiàn)幾乎都是用同一種程序來計算檢驗和的：
USHORT checksum(USHORT *buffer, int size) {
unsigned long cksum=0;
while(size >1) {
cksum =*buffer;
size -=sizeof(USHORT);
}
if(size ) {
cksum= *(UCHAR*)buffer;
}
cksum = (cksum >> 16)(cksum & 0xffff);
cksum= (cksum >>16);
return (USHORT)(~cksum);
}
ICMP協(xié)議，基本格式：
-------- IP 數(shù)據(jù)報 ------------
--20 bytes -- ----------------
IP首部ICMP 報文
------------------------------
ICMP報文還是通過IP報文發(fā)送出去的 。
ICMP的格式：
----8--- ----8--- -------- --------
8位類型8位代碼16位檢驗和
-----------------------------------
不同類型有不同的內(nèi)容和長度
-----------------------------------
ICMP的報文類型有很多種，而每種類型里又有多種代碼 。
報文分查詢報文和差錯報文 。差錯報文不會嵌套產(chǎn)生 。差錯報文中包含導(dǎo)致差錯的IP首部和數(shù)據(jù)部分的前8個字節(jié)，并據(jù)此與具體的協(xié)議和進程聯(lián)系起來 。因為TCP和UDP的前8個字節(jié)中包含有源端口和目的端口，可以據(jù)此查找到與此聯(lián)系的用戶進程 。大部分的實現(xiàn)中只返回8個字節(jié)，有系統(tǒng)返回的是前64個字節(jié) 。假如是UDP報文產(chǎn)生差錯，而又沒有預(yù)先通過 connect與指定端口聯(lián)系起來，用戶進程將收不到這個差錯報文 。內(nèi)核在處理后將丟棄 。
討論了部分tFTP實現(xiàn)中的的簡單的差錯重傳機制，等待5秒重傳，已被RFC禁用 。我在串口通訊中用的還是這種簡單的重傳方式，看來要改了 。
具體討論了時間截請求與回復(fù)的過程，以及地址掩碼請求與回應(yīng)數(shù)據(jù)包的格式 。對端口不可達錯誤，差錯報文為：
----------------- 端口不可達的ICMP差錯報文 -------------------------------
以太網(wǎng)首部IP首部ICMP首部產(chǎn)生差錯的IP首部IP報數(shù)據(jù)域
- 14 bytes--- 20 bytes ---8 bytes---- 20 bytes ---- -- 8 bytes -
根據(jù)標準，列出5種情況下，不會產(chǎn)生差錯報文，基本上都是為了避免出現(xiàn)ICMP廣播風暴的 。
這個協(xié)議因為類型與具體的細節(jié)太多，比較的費事，不過也比較簡單 。假如不做協(xié)議的分析，倒不需要對每個類型都搞得十分清楚 。似乎這個并沒有多少利用的空間 。不過假如在一個主機試圖發(fā)起連接時，發(fā)送一個偽裝的ICMP包告訴它“端口不可達”，結(jié)果會怎么樣？值得試試 。
第2卷 第13章 HTTP協(xié)議
這一章對HTTP的請求與響應(yīng)格式做了簡單的介紹 。由于所有傳送的內(nèi)容基于ASCII，雖然也會傳送其他二進制，如圖片，MIME文件，但是其本是還是可以從請求或響應(yīng)頭中看出傳送的類型，分析起來就沒什么難度了 。這些可以用 telnet 或者 nc做一個真實的會話過程 。把后面一章（第2卷第14章 HTTP服務(wù)器的分組）看完，預(yù)備自已動手做一個小的Web服務(wù)器 。公司下一步的計劃是把大部分的硬件都做成可直接由瀏覽器操作的 。而這些必須要由一個 web服務(wù)器來驅(qū)動 。我是作軟件的，本來不需要我去關(guān)心這個 。不過自己動手作一下，實踐一下總不是壞事，而且可以跟他們交流一下 。

推薦閱讀