|
1、網(wǎng)絡(luò)包的組成： 報頭/起始幀分界符——MAC頭部——IP頭部——TCP頭部——數(shù)據(jù)——FCS（幀校驗序列）
2、TCP頭部由TCP模塊負責添加，頭部格式如下：（最?。玻白止?jié)） 發(fā)送方端口號 接收方端口號 序號(發(fā)送數(shù)據(jù)的順序編號)：發(fā)送方告訴接收方該網(wǎng)絡(luò)包發(fā)送的數(shù)據(jù)相當于所有發(fā)送數(shù)據(jù)的第幾個字節(jié)。 ACK號(接收數(shù)據(jù)的順序編號) 數(shù)據(jù)偏移量 保留 控制位： URG：表示緊急指針字段有效 ACK：表示接收數(shù)據(jù)序號字段有效 PSH：表示通過flush操作發(fā)送的數(shù)據(jù) RST：強制斷開連接，用于異常中斷的情況 SYN：發(fā)送方和接受方相互確認序號，表示連接操作 FIN：表示斷開連接 窗口：接收方告知發(fā)送方窗口的大小(即無需等待確認認可一起發(fā)送的數(shù)據(jù)量) 校驗和 緊急指針 可選字段
3、IP頭部和MAC頭部由IP模塊負責添加。 IP頭部：IP用的頭部，包含IP頭部 MAC頭部：以太網(wǎng)的頭部，包含MAC地址 IP頭部格式如下： 版本號 頭部長度 服務(wù)類型 總長度：表示IP消息的總長度 ID號：用于識別包的編號，一般為包的序列號。如果一個包被IP分片，則所有的分片都擁有相同的ID 標志：該字段有3個比特，有效的是前兩個比特。分別表示是否允許分片，當前包是否是分片包 分片偏移量 生存時間 協(xié)議號：十六進制表示，TCP：06 UDP：11 ICMP：01 頭部校驗和 發(fā)送方IP地址 接收方IP地址 可選字段
MAC頭部的格式如下： 接收方MAC地址（48比特，5字節(jié)） 發(fā)送方MAC地址 以太類型：使用的協(xié)議類型0000-05DC：IEEE802.3 0800：IP協(xié)議 0806：ARP協(xié)議 86DD：IPV6
4、數(shù)據(jù)包分片、重組操作： （1）發(fā)送方： 將數(shù)據(jù)包分為多個TCP頭部+數(shù)據(jù)包的組合，TCP頭部中存著不同的數(shù)據(jù)序號；之后將多個組合交由IP模塊，統(tǒng)一添加IP頭部和MAC頭部，IP頭部的ID號設(shè)為統(tǒng)一的。 （2）接收方： ＩＰ模塊具有分片重組的功能，如果接收到的包是進過分片的，那么ＩＰ模塊會將它們還原成原始的包。分片的包會在ＩＰ頭部的標志字段中進行標記，當收到分片的包時，ＩＰ模塊會將其暫時存在內(nèi)部的內(nèi)存空間中，然后等待ＩＰ頭部中具有相同ＩＤ的包全部到達，因為同一個包的所有分片都具有相同的ＩＤ。此外，ＩＰ頭部還有一個分片偏移量的字段，它表示當前分片在整個包中所處的位置。根據(jù)這些信息，在所有的分片全部收到之后，就可以將它們還原成原始的包。
5、滑動窗口機制： 所謂滑動窗口，就是在發(fā)送一個包之后，不等待ACK號的返回，直接發(fā)送后續(xù)的一系列包。有效利用等待ACK號的這段時間。 窗口大小：能夠接收的最大數(shù)據(jù)量。 注意接收緩沖區(qū)的概念、TCP頭部中的滑動窗口字段的使用（三次握手時傳遞互相的窗口大小，并且中途還會更新大?。?/span>
6、IP頭部的兩個IP地址分別為：發(fā)送方網(wǎng)卡的IP地址；應(yīng)用程序提供的接收方IP地址。 MAC頭部的發(fā)送方和接受方的MAC地址分別是發(fā)送方網(wǎng)卡的MAC地址；利用ARP（地址解析協(xié)議）協(xié)議，根據(jù)接收方IP地址廣播得到的接收方MAC地址。 注意：ARP緩存概念。
7、ＩＣＭＰ協(xié)議： ICMP是（Internet Control Message Protocol）Internet控制報文協(xié)議。它是ＴＣＰ／ＩＰ協(xié)議族的一個子協(xié)議，用于在IP主機、路由器之間傳遞控制消息?？刂葡⑹侵妇W(wǎng)絡(luò)通不通、主機是否可達、路由是否可用等網(wǎng)絡(luò)本身的消息。這些控制消息雖然并不傳輸用戶數(shù)據(jù)，但是對于用戶數(shù)據(jù)的傳遞起著重要的作用。 ICMP協(xié)議是一種面向無連接的協(xié)議，用于傳輸出錯報告控制信息。
８、ＵＤＰ傳輸協(xié)議： ＵＤＰ協(xié)議使用的具體案例： 向ＤＮＳ服務(wù)器查詢ＩＰ地址的時候就是使用的ＵＤＰ協(xié)議。 發(fā)送音頻和視頻數(shù)據(jù)。
像ＤＮＳ查詢等交換控制信息的操作基本上都可以在一個包的大小范圍內(nèi)解決，這種場景下就可以使用ＵＤＰ協(xié)議傳輸。ＵＤＰ協(xié)議沒有ＴＣＰ的接收確認、窗口機制。在收發(fā)數(shù)據(jù)前不需要交換控制信息，也就是說不需要建立和斷開連接。
ＵＤＰ頭部的格式如下：（８字節(jié)） 發(fā)送方端口號 接收方端口號 數(shù)據(jù)長度：ＵＤＰ頭部后面數(shù)據(jù)的長度 校驗和：用于校驗錯誤
發(fā)送數(shù)據(jù)： 從應(yīng)用程序獲取的數(shù)據(jù)前面加上ＵＤＰ頭部，然后交給ＩＰ進行發(fā)送就ＯＫ了。 接收數(shù)據(jù)： 根據(jù)ＩＰ頭部中的接收方和發(fā)送方ＩＰ地址，以及ＵＤＰ頭部中的接收方和發(fā)送方的端口號，找到對應(yīng)的套接字并將數(shù)據(jù)交給相應(yīng)的應(yīng)用程序就ＯＫ了。
９、TCP與UDP的區(qū)別： （轉(zhuǎn)載）1、基于連接與無連接； 2、對系統(tǒng)資源的要求（TCP較多，UDP少）； 3、UDP程序結(jié)構(gòu)較簡單； 4、流模式與數(shù)據(jù)報模式 ； 5、TCP保證數(shù)據(jù)正確性，UDP可能丟包，TCP保證數(shù)據(jù)順序，UDP不保證。
１０、TCP與UDP的區(qū)別： （１）回答發(fā)送數(shù)據(jù)前是否存在建立連接的過程。 （２）ＴＣＰ過確認機制，丟包可以重發(fā)，保證數(shù)據(jù)的正確性；ＵＤＰ不保證正確性，只是單純的負責發(fā)送數(shù)據(jù)包。 （３） UDP是面向報文的。發(fā)送方的UDP對應(yīng)用程序交下來的報文，在添加首部后就向下交付給IP層。既不拆分，也不合并，而是保留這些報文的邊界，因 此，應(yīng)用程序需要選擇合適的報文大小。 ?。ǎ矗?/span>UDP的頭部，只有8個字節(jié)，相對于TCP頭部的20個字節(jié)信息包的額外開銷很小。
|
