組播及igmp/mld協議詳解(二)
1 IGMP 協議
IGMP用來動態的將各個主機註冊到特定區域網中的一個組播組中。主機向本地的組播路由器傳送IGMP訊息來表明自己所屬的組播組。在IGMP協議中,路由器偵聽IGMP訊息並週期的發出查詢,以發現某個子網上哪些組是活動的,哪些是不活動的。
IGMP訊息在IP資料報內傳送,用IP協議號2來標識。同時,將IP存活時間(TTL)欄位值設定為1,因此IGMP資訊處於本地範圍本子網內傳送並且不會被路由器轉發。
1989年,IGMP版本1(RFClll2)第一次詳細定義了IGMP規範。後來施樂公司對最早的IGMP版本1進行了大幅更新,產生了IGMP版本2(RFC2236)。到目前為止
1.1 IGMPv1協議
1.1.1 IGMPv1的工作原理
在IGMPvl中定義了基本規則、組成員查詢機制和報告機制。當某接收主機希望接收到某個組播組的資料時,它會向本地鏈路上的查詢路由器傳送加入訊息,通知查詢路由器本機希望申請加入的組播組;查詢路由器收到加入訊息之後,把這條訊息加入到查詢路由器所維護的狀態列表,同時向源發起建立組播分發樹的請求
1.1.2 IGMPv1報文格式
IGMPvl報文格式如圖2-4所示,
圖2-4 IGMPv1報文格式
其主要內容包括:
(1)版本欄位表示IGMP協議的版本號,在IGMP中置為1.
(2)型別欄位,在IGMPv1中,只有兩個值:
取值為0x11,表示該報文為成員關係查詢(Membership Query),主要是由路由器使用。
取值為0x12,表示該報文為成員關係報告(Membership Report)
(3)校驗和欄位用於資料報文的校驗。
(4)組地址欄位。當用於成員關係查詢時,本欄位置為0,並被主機忽略;當用於成員關係報告時,本欄位包含組播組地址。
IGMPv1報文在網路中傳輸完整的報文格式如圖2-5:
圖2-5 在網路中傳輸的IGMPv1報文
1.1.3 IGMPv1工作過程
在IGMPv1中,路由器利用查詢一響應過程來確定在本地子網中是否有加入某個組播組的主機存在,如果有,則這臺路由器就要完成向本子網組播資料包的功能;如果沒有,則這臺路由器就不必向此子網轉發組播包。路由器週期性地向子網上的所有主機發送組播成員關係查詢報文,希望加入某個組播組的主機就響應該查詢,傳送一個組播成員關係報告報文到子網上,在IGMP報文的組地址地段中加入想要加入的組播組的地址。路由器接收到來自主機的成員關係報告報文後,就知道了在該子網上有主機要加入組播組,組播組地址在報文中可以獲得,接下來,路由器就會根據所使用的路由協議建立起相應的轉發狀態。
當一個子網上有多臺主機想加入同一個組播組時,就可以利用報告響應抑制功能,來減少子網中的重複資訊傳遞。處理流程如下:
主機接收到IGMP成員關係查詢報文後,對加入的每個組播組啟動一個倒數計時器。當計時器的值為0時,主機發送IGMP成員關係報告報文,通知路由器子網內仍有處於活動狀態的組播接收者。當計時器到達0之前,若主機接收到來自其他主機發送的同一組成員關係報告報文,那麼它就停止與該計時器得到的數,重新計時,這樣,就避免了傳送同一個成員關係報告報文給路由器。
如果在一個子網中有多個組播路由器,那麼多個路由器都發送IGMP查詢報文是一種浪費,所以應當確定一個路由器作為查詢路由器就可以了。但是在IGMPv1中,沒有提供選舉查詢路由器的機制,而是把這一任務留給了組播路由協議。由於不同的協議使用不同的選舉機制,會造成在一個子網中出現多個查詢路由器,這也是IGMPv1的缺點之一。
但是IGMPv1的另一個缺點是缺乏顯式的離開方式。當一臺主機想要離開一個組播組時,並不顯式地表示出來,而只是不再對路由器的查詢報文進行響應。當一個網段內某個組播組的最後一個成員退出後,路由器還會繼續組播這個組的資料,直到一段時間內路由器接收不到任何來自該組的成員響應,才會知道該組已經沒有接收者了,然後停止轉發該組的組播資料報文。因此,路由器中需要為子網中的每一個組維護一個計時器。當路由器接收到某臺主機發送的報告報文時,就會將該組的計時器清零;當某個組的計時器超時後,就說明在本網段上已經沒有接收者,於是停止轉發該組報文。
下面是工作過程圖解:
1) 組成員加入
圖2-6 IGMPv1組成員加入
2) 查詢與響應
圖2-7 IGMPv1組成員查詢
3) 響應抑制機制
圖2-8 IGMPv1響應抑制機制
4) 組成員離開
圖2-9 IGMPv1組成員離開
1.2 IGMPv2協議
1.2.1 IGMPv2的工作原理
IGMPv1的主要缺點是離開延遲過大和選擇查詢路由器需要依賴組播路由協議進行。針對這些缺點,IGMPv2做了相關的改進。在IGMPv2中,增加了離開組的報文格式,當主機想要離開某個組播組時,不必等待路由器發出查詢報文,而是可以直接向路由器傳送成員關係報告報文,這樣可以有效地縮短離開延遲。另外在IGMPv2中,還明確了查詢路由器的選舉機制。除此之外,IGMPv2的工作原理與IGMPv1基本一致
1.2.2 IGMPv2的報文格式
IGMPv2的報文格式如圖2-10所示:
圖2-10 IGMPv2報文格式
它在IGMPvl的基礎上,進行了兩處改動:一個是將v1的版本欄位和型別欄位進行了合併;另一個是增加了最大響應時間欄位 (MaxResponseTime)。其主要內容如下:
(1)型別欄位,在相容IGMPv1的基礎上,IGMPv2中新增了兩種報文型別。
·0xll:成員關係查詢。與IGMPv1不同,IGMPv2的查詢分為兩種型別:①通用查詢 (GeneralQuery),組地址欄位置為全0,對所有的組進行組成員查詢;②特定組查詢 (GrouPpecificQuery),針對特定組進行組成員查詢,組地址欄位置為特定組的地址。
·0x12:IGMPv1成員關係報告(為了向後相容IGMPv1)。
·0x16:IGMPv2成員關係報告。
·0xl7:離開組。
(2)最大響應時間欄位,只有在成員關係查詢報文中有效,主機必須在最大響應時間到達之前發出成員關係報告報文。通過該值,路由器可以調節組成員的離開延遲。
(3)校驗和欄位,與IGMPv1中的一樣。
(4)組地址地段,與IGMPv1中的基本一樣,當採用特定組查詢時,該欄位存放要查詢的組播組的地址。
IGMPv2報文在網路中傳輸完整的報文格式如圖2-11:
圖2-11 在網路中傳輸的IGMPv2報文格式
1.2.3 IGMPv2工作過程
查詢一響應過程與IGMPv1基本相同,但是有兩點改進:①增加了特定組查詢,特定組查詢的目的是為了讓路由器知道一個特定組在子網內是否還有組成員,以便判斷是否還需要轉發該組的資料報文;②IGMPv2的成員關係報告的型別程式碼不一樣。
IGMPv2的組成員加入與 IGMPv1中的完全一樣。IGMPv2離開過程與IGMPv1相比有了較大的改進。主機離開一個組時,需要顯式地傳送一個離開報文給路由器。其過程如下:
要離開的主機發送一個離開報文給子網上所有路由器(目的地址224.0.0.2),查詢路由器接收到離開報文後,會立即傳送一個特定組查詢到子網上。如果子網上還有該組的成員,則會發回一個響應報文;如果子網上己經沒有該組的成員,則沒有主機迴應,於是路由器就知道己經沒有該組成員了,就停止轉發該組的資料。
在IGMPv1中,選擇查詢路由器依賴於組播路由協議;而在IGMPv2中,明確了選擇查詢路由器的機制。其過程如下:
開始時,子網上的每個路由器都假定自己就是查詢路由器,傳送一個通用查詢報文給所有主機(目的地址224.0.0.1)。每個路由器都可以接收到來自其他路由器的報文,然後進行IP地址的比較,具有最低IP地址的路由器就成為查詢路由器;非查詢路由器啟動一個計時器,無論何時接收到來自當選的查詢路由器的通用查詢報文,就將計時器復位。如果計時器超時,就認為當選的查詢路由器發生故障,轉向開始重新選擇。計時器的取值一般為查詢間隔的2倍
圖解工作過程如下:
1)組成員加入
圖2-12 IGMPv2組成員加入
2)查詢與響應
圖2-13 IGMPv2組成員查詢與響應
3)查詢器選舉
圖2-14 IGMPv2查詢路由器選擇
4)成員離開
圖2-15 IGMPv2組成員離開
1.3 IGMPv3協議
1.3.1 IGMPv3的工作原理
IGMPv3的提出,主要是為了配合源特定組播的實現,即組播組成員可以指定接收或指定不接收某些組播源的報文。這樣主機就可以有選擇性接收來自某個特定組播源的資料包,而不是被動接收該組中所有組播源的資料包。IGMPv3的這一特性,可以實現源特定組播SSM技術。源特定組播(Source Specific Multicast,SSM)是一種區別於傳統組播的新的業務模型,SSM保留了傳統PIM-SM模式中的主機顯式加入組播組的高效性,但是跳過了PIM-SM模式中的共享樹和RP規程。SSM直接建立由(S,G)標誌的一個組播最短路徑樹。SSM的一個(S,G)對也被稱為一個頻道(Channel)。PIM-SSM是對傳統PIM協議的擴充套件,使用SSM,使用者能直接從組播源接收組播報文,需要匯聚點(RP)的幫助。
IGMPv3在IGMPvl/v2的基礎上提供了額外的源過濾組播功能(Source FilteredMulticast,SFM)。在IGMPvl/v2中,主機只根據組地址來決定加入某個組,並從任何一個源接收發給該組地址的報文。具有源過濾組播功能(SFM)的主機使用IGMPv3來表示主機所希望加入的組播組,同時還表示該主機所希望接收的組播源的地址。主機可以使用一個包括列表(Inclusion List)或一個排除列表 (Exclusion List)來表示對源地址的限制。即組播組成員可以指定接收或指定不接收某些組播源的報文。這樣主機就可以有選擇性接收來自某個特定組播源的資料包,而不是被動接收該組中所有組播源的資料包。
1.3.2 IGMPv3的報文格式
IGMPv3的報文型別有以下幾種:
0xll:成員關係查詢報文 (MembershipQeury)。
0x22:版本3成員關係報告報文(version 3 Membership Report)
0x12:版本1成員關係報告報文(version 1 Membership Report)
0x16:版本2成員關係報告報文 (version 2 Membership Report)
0x17:版本2離開報文 (version 2 LeaveGroup)。
報文型別的值填寫在報文中的型別欄位。在IGMPv3中,查詢報文和報告報文格式有較大差異,需要分別描述。圖2-16為查詢報文的格式
圖2-16 IGMPv3查詢資訊格式
(1)型別欄位,設定為0xll,代表該報文為查詢報文。
(2)最大響應時間欄位,指明瞭主機發出響應的最長時間。
(3)組地址欄位,功能與IGMPv2一樣,可以用於通用查詢和組特定查詢。
(4)s欄位,置為1時,其他路由器不對該報文進行處理。
(5)QRV欄位,查詢路由器的健壯值(Querier’s RobustnessVariable),該值影響計時器和重試次數的取值。
(6)QQIC欄位,查詢路由器的查詢間隔碼(Querier’s QueryIntervalCode),該值影響查詢路由器的查詢間隔時間,非查詢路由器按照此值更新自己的預設值。
(7)源地址數目欄位,該值表在這個報文中包含了多少個源地址。當進行通用查詢(GeneraQuery)或者組特定查詢 (GroupSpecific Query)時,該值置為0;當進行特定組和源查詢 (Group Source pecific Query,用於PIM一SSM)時,該值為源特定地址的數目。雖然該值最大可為65536,但是實際上受限於資料鏈路層的MTU,例如在乙太網上,1P資料報最長為1500位元組,除去IP報頭的24位元組和IGMP報頭的12位元組,剩餘1464位元組,所以最多包含366(1464/4)個源地址。
(8)源地址地段。
IGMPv3查詢資訊報文在網路中傳輸完整的報文格式如圖2-17:
圖2-17 在網路中傳輸的IGMPv3查詢報文格式
IGMPv3報告報文的格式較為複雜,如圖2-18所示。
圖2-18 IGMPv3偵聽者報告格式
(1)型別欄位,置為0x22,表示該報文為IGMPv3報告報文。
(2)組記錄數目欄位,表示此報文中包含的組記錄數目。
(3)組記錄欄位。包含若干個組記錄,每個組記錄長度不固定,其內容如圖2-19:
圖2-19 IGMPv3組記錄格式
①組記錄型別欄位,表示該組記錄中包含的資料的型別,目前定義了六種類
型,分別是:
·MODE IS INCLUDE。表示該主機的過濾模式為INCLUDE.也就是說,後面列出的地址都是主機想要接收的組播源地址。
·MODE IS EXCLUDE。表示該主機的過濾模式為EXCLUDE,也就是說,後面列
出的地址都是主機想要拒絕的組播源地址。
·CHANGE TO INCLUDEMODE。表示該主機的過濾模式從EXCLUDE切換為INCLUDE模式。
·CHANGE TO EXCLUDEMODE。表示該主機的過濾模式從INCLUDE切換為EXCLUDE模式。
·ALLOW NEW SOURCES。表示該主機中新增的想要接收的源地址。
·BLOCK OLD SOURCES。表示從該主機中刪除的不想接收的源地址。
②輔助資料長度欄位,在組記錄的最後,可以增加以4位元組為單位的輔助資料,如果沒有輔助資料,則置為0。
③源地址數目欄位,表示該記錄中包含了多少個組播源地址。
④組地址欄位,與源地址共同表示特定源組播。
⑤源地址欄位,每個長度為32bits。標誌源地址,數目由源地址數目欄位表示。
⑥輔助資料欄位。為將來的應用預留,在IGMPv3中並不需要。一臺主機在傳送報告報文的時候,應當把自己的源IP地址包含在IP資料報中,當主機還沒有獲得IP地址的時候,可以使用0.0.0.0作為源IP地址,支援IGMPv3的路由器必須接收來自0.0.0.0的資料報。主機的IGMP報文的目的地址標誌為224.0.0.22,代表子網中所有支援IGMPv3的路由器。
1.3.3 IGMPv3的主要改進
IGMPv3除了支援原特定組播外,其工作原理與IGMPv2相比,並沒有本質的改變,只是在某些地方做了改進和優化。以下列出了IGMPv3的主要特點和改進:
①支援源特定組播SSM;
②向後相容IGMPvl和IGMPv2;
③主機可以定義要接收的組播源地址;
④非查詢路由器可以與查詢路由器保持引數值同步;
⑤最大響應時問從25.5s增加到53min,適合於較大的網路;
⑥輔助資料欄位為將來的應用預留了空間;
⑦關係成員報告報文傳送給目的地址224.0.0.22,可以幫助二層交換機更有效地實現IGMP監聽 (IGMPSnooping)功能;
⑧報告報文中可以包含多個組記錄,可以有效地減少網路通訊量;
⑨在IGMPv3中,取消了前面版本中的響應抑制功能,主要原因是:
第一,使用響應抑制時,路由器只知道子網上是否有組成員,而不知道有幾個組成員,以及成員是哪些主機:取消響應抑制,路由器就可以記錄每一個組成員的資訊,可以開發一記賬等增值服務功能。
第二,許多網橋或者二層/三層交換機在實現IGMP監聽功能時,為了避免響應抑制,一般不轉發網段問的IGMP報文。取消了響應抑制後,可以簡化這些裝置的設計。
第三,取消響應抑制後,主機不必處理來自其他主機的報文,簡化了主機的實現。在查詢報文中,增加S標誌位,可以提高系統的健壯性。
IGMPv3報告報文在網路中傳輸完整的報文格式如圖2-20:
圖2-20 在網路中傳輸的IGMPv3報告報文
2 MLD協議
IPv6的組管理協議被稱為MLD(組播監聽者發現)。1999年,MLD版本l(RFC2710)被IETF釋出。2004年,MLD版本2(RFC3810)標準出臺,後一個版本可以向前一個相容。MLD協議是專門針對基於IPv6的組播組管理協議。因為MLD使用全新的ICMPv6的報文格式,所以MLD協議就是ICMPv6協議的一個子集。MLD訊息使用鏈路本地IPv6源地址傳送,其跳數被限制為1。MLD訊息的封裝格式如圖2-21所示:
圖2-21 MLD訊息封裝格式
以下分別描述MLD協議的兩個版本以及MLDSnooping,其中對於MLDSnooping的詳細描述見第三章。
2.1 MLDv1協議
2.1.1 MLDv1的工作原理
MLDvl協議是從IGMPv2協議中派生出來的,其執行機制和IGMPv2協議相同,專門用於IPv6組播群組的管理,其主要是應用於ASM模式組播路由協議的組管理工作。
對於執行MLD協議的路由器,其介面要監聽由IPv6組播地址產生的所有鏈路組播地址。路由器為它所在的每一條鏈路維護一個列表。表項有此鏈路中存在的組成員的組播地址,以及該地址相應的定時器。路由器週期性地傳送通用請求 (general query),以查詢該鏈路上是否存在某組播地址的組成員。節點收到路由器傳送的常規請求後,經過隨機時延後發出組播監聽報告。這樣是為了防止所有的節點都在同一時間發出報告分組,從而造成網路的突發性阻塞。當路由器收到鏈路上的報告分組時,如果報告地址不在路由器的列表上,則加入該項,否則計時器重新置位。如果某個地址的計時器過期,則從列表中刪除。當節點要加入一個組播組時,主動傳送組播監聽報告,向路由器報告組成員的存在。節點退出組播組時,傳送完成分組,刪除有關路徑。當請求狀態的路由器從鏈路上接收到一個完成訊息,如果訊息中的組播地址在路由器的列表上,路由器傳送一個特定組播地址查詢。如果一段時延後沒有報告分組,則認為該組播地址在此鏈路上沒有組成員了。
2.1.2 MLDv1報文格式
MLDv1的報文格式如圖2-22所示:
圖2-22 MLDv1報文格式
(1)型別欄位,MLDvl有如下三種報文型別:
·組播偵聽查詢訊息(Type=130),分為兩種型別:①通用查詢(GeneralQuery),組地址欄位置為全0,對所有的組進行組成員查詢;②特定組查詢(Group Pecific Query),用於判斷一個特定的組播地址在本地鏈路上是否有組播偵聽者。
·組播偵聽報告訊息(Type = 131)
·組播偵聽完成訊息(Type = 132)
(2)編碼欄位,初始值為0。
(3)校驗和欄位。
(4)最大響應時間欄位,只有在組播監聽者查詢報文中有效,主機必須在最大響應時間到達之前發出成員關係報告報文。通過該值,路由器可以調節組成員的離開延遲。
(5)組地址欄位,在通用組查詢中,置為0;在特定組查詢時,該欄位存放要查詢的組播組的地址。在報告和完成報文中,分別用於存放主機要加入和離開的組地址。
MLDv1報文在網路中傳輸完整的報文格式如圖2-23:
圖2-23 在網路中傳輸的MLDv1報文
以上這些查詢訊息和應答訊息報文有三種不同的報文互動方式:
第一種互動方式是由路由器發起的。路由器作為詢問者向與其相連線的所有主機發送一個一般查詢訊息報文。其目的地址是FF02::1。主機收到此訊息後,應答一個包含當前組播地址狀態記錄的報文訊息,此報文告訴路由器此主機希望接收哪個組播組或者哪些源發來的資料。
第二種互動方式是由主機發起的。當一個主機離開一個組播組時,它就要向路由器傳送組播偵聽者完成訊息,該訊息包括一個狀態改變一記錄。路由器收到此訊息後,向其相連的鏈路上傳送一個特定組播地址查詢,詢問是否還有主機加人了此特定的組。
第三種互動方式是由路由器發起的。如果在路由器的組播地址表中某一個組播地址的相關定時器超時後,仍然沒有收到主機發來的包含狀態變化記錄的組播偵聽者報告訊息,路由器則向所有主機發送一個特定組查詢訊息,確認該組播組是否還有組播偵聽者。
2.1.3 MLDv1工作流程
當一個網段內連線有多臺路由器執行MLDvl協議時,必須選舉一臺路由器作為查詢路由器,其餘的自然成為非查詢路由器。選舉的機制是:地址最小的路由器當選。非查詢路由器中有一個其他查詢路由器存在計時器,當該計時器到期仍沒有收到來自查詢路由器的報文,則認為該查詢路由器失效,重新開始新的選舉。
路由器定期向子網內所有的主機廣播查詢報文(目的地址為FF02::1),目的是獲得主機的報告報文。在路由器剛開始工作時,會快速連續地傳送查詢報文,以便儘快蒐集到子網內的組成員資訊。
當主機接收到一個查詢報文後,就為每一個要接收的組地址啟動一個延遲定時器。定時器的值在[0,最大響應時間]之間取一個隨機數。如果查詢報文中的最大響應時間欄位被置為0,則定時器立刻到期。定時器到期後,主機會發送一個報告報文給路由器,通知路由器主機想接收的組播組地址。
如果一臺主機在定時器還未到期時,就收到其它主機通告路由器的報告報文,則讀取該報文的組地址,如果和自己需要通告的組地址相同,則立刻停止相應的定時器,並不再發送關於該組地址的報告報文,這樣就可以避免多臺主機發送相同內容的報告報文給路由器,這種機制稱為“響應抑制”。路由器收到來自主機的報告報文後,檢視其中的組地址,如果該地址未在路由器的組地址列表中,則將其新增到組地址列表中,同時為其啟動一個相應的定時器;如果該地址已經在路由器的組地址列表中,則將相應的定時器恢復最大值。如果一個組地址的定時器到期了,則說明該組地址在子網內已經沒有接收者了,路由器會將此組地址從列表中刪除。
當一臺主機想要加入某個組播組時,可以不必等待路由器的查詢報文,而是直接向路由器傳送報告報文。為了保障該報文的可靠性,一般會進行重傳。當一臺主機想要離開某個組播組時,必須傳送一個離開報文給子網內的路由器。路由器收到離開報文後,會首先檢視該組地址是否在組地址列表中,如果在,則傳送一個特定組地址查詢給子網內的所有主機。在一定的時間內,路由器收不到來自主機的應答,則會認為該組已經沒有接收者,於是將該組地址從列表中刪除。非查詢路由器會忽略所有的離開報文。
2.2 MLDv2協議
MLDv2從IGMPv3中發展過來,和MLDvl相比,增加了IGMPv3所具有的源過濾功能,不僅能夠支援ASM模式組播路由協議,而且還能夠支援基於IPv6的SSM模式組播路由協議。
MLDv2在MLDv1的基礎上添加了源組播 (Source Specific Multieast)的概念,主機可以組播源報告(Group-Source Report)報告感興趣的源,路由器則只轉發該鏈路上所有組成員感興趣的源所傳送的報文。當主機想退出某組播源時,主機發送離開組播源報告(Group-Source Leave),查詢者在接收到該報告後可以傳送指定組播源請求,確認是否仍有組成員關心該組播源。MLDv2支援源過濾 (SourceFiltering)
1 IGMP 協議 IGMP用來動態的將各個主機註冊到特定區域網中的一個組播組中。主機向本地的組播路由器傳送IGMP訊息來表明自己所屬的組播組。在IGMP協議中,路由器偵聽IGMP訊息並週期的
組播和IGMP的作用---------------------------------所謂組播,與單播和廣播相對,是指將網路主機將一次將資料發給多個屬於同一組的目標主機。主要使用了IGMP協議。IGMP,就是Internet Group Management Protocol -c 基本 公鑰加密 工作方式 通信 使用 sha2 公開 原理 HTTPS協議的主要功能基本都依賴於TLS/SSL協議,本節分析TLS/SSL協議工作原理。 TLS/SSL的功能實現主要依賴於三類基本算法:散列函數 Hash、對稱加密和非對稱加密,其利用非對稱加密實 產生 差分 4.2 所有 管理 錯誤處理 遠程終端 同時 通道 1553B簡介本設計文檔將在SylixOS下設計一個1553B設備驅動的抽象層,從而進一步解除用戶層與驅動層的耦合。MIL-STD-1553B總線是美國空軍電子子系統聯網的標準總線,是一種中央集權式的串行總線,
Sip的核心請求訊息 INVITE、ACK、OPTIONS、BYE、CANCEL 和 REGISTER
INVITE • INVITE可以在郵件正文中包含主叫方的媒體資訊。 • 如果INVITE已經接收到成功響應(2xx)或已經發送ACK,則會話被認為是建立的。 • 成功的INVIT
網際控制報文協議ICMP
功能:ICMP允許主機或者路由器報告差多情況和提供有關異常情況的報告,它是網路層的協議,ICMP報文裝在IP資料報中,作為其中的資料部分。
ICMP報文的種類
ICMP差錯報文
終點不可達
源點抑制
超時 一、基礎篇:
CSMA/CD是一種爭用型的介質訪問控制協議。它起源於美國夏威夷大學開發的ALOHA網所採用的爭用型協議,並進行了改進,使之具有比ALOHA協議更高的介質利用率。主要應用於現場匯流排Ethernet中。另一個改進是,對於每一個站而言,一旦它檢測到有衝突,它就放棄它當前的傳送任務。換句話說,如果兩
1.HTTP/1.0和HTTP/1.1的比較
RFC 1945定義了HTTP/1.0版本,RFC 2616定義了HTTP/1.1版本。
1.1建立連線方面
HTTP/1.0 每次請求都需要建立新的TCP連線,連線不能複用。HTTP/1.1 新的請求可以在上次請求建立 網絡協議 test 未能 第一個 為什麽 體系 index 緩存 hyper 目錄::::::
一、網絡協議
二、TCP(Transmission Control Protocol,傳輸控制協議)
TCP頭格式 TCP協議中的三次握手和四次揮手 cnp 運用 web應用 media 服務器端 所有 長度 request bad 轉載:http://e7kan.com/?p=264&
引言
HTTP是一個屬於應用層的面向對象的協議,由於其簡捷、快速的方式,適用於分布式超媒體信息系統。它於1990年提出,經過幾 表單 pos 換行 none 必須掌握 通信 pow print expires HTTP是一個屬於應用層的面向對象的協議,由於其簡捷、快速的方式,適用於分布式超媒體信息系統。它於1990年提出,經過幾年的使用與發展,得到不斷地完善和擴展。目前在WWW中使用的是HTTP/1 範圍 文件傳輸 ext text 繼續 warn 分組 asi nsf 前言:
之前買過一本《圖解 HTTP》這本書,作者好像是個小日本,也繼承了小日本在動漫方面的天賦,30% 的內容都是 Q 版畫圖。
之後沒有引起我的重視,書一借出去,然後,之後 .. 之後, linux 命令用戶管理命令:useradd,userdel,usermod,passwd,chsh.chfn,finger,id,chageUseradd(建立用戶)useradd [options] USERNAME 例:useradd -g mygroup user2建立一個 code sps 網頁 提示 agent tor 指定 6.0 lec HTTP是一個屬於應用層的面向對象的協議,由於其簡捷、快速的方式,適用於分布式超媒體信息系統。它於1990年提出,經過幾年的使用與發展,得到不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六 spark 大數據 javaapi 老湯 rdd package com.twq.javaapi.java7;
import org.apache.spark.SparkConf;
import org.apache.spark.api.java.JavaRDD;
import org. ack 傳遞 滿足 copyright fun 事件觸發 頂級 工作 tle
React—組件生命周期詳解
轉自 明明的博客 http://blog.csdn.net/slandove/article/details/50748473 (非原創)
版權聲明:轉 linux——vim編輯器詳解 vim 十六、使用vim編輯多個文件用法: vim FILE1 FILE2 FILE3文件之間切換:末行模式下: :next 切換至下一個文件 :prev 切換至前一個文件 :last 切換至最後一個文件 :first 切換至第 其它 對數 hello 減少 受保護 改版 text gin 組裝 1、握手與密鑰協商過程
基於RSA握手和密鑰交換的客戶端驗證服務器為示例詳解TLS/SSL握手過程
再看一張手繪時序圖
(1).client_hello 客戶端發起請求,以明文傳輸請求信息,包 客戶 判斷 節點 無法 三方 證書無效 進行 證書 roo 1、RSA身份驗證的隱患 身份驗證和密鑰協商是TLS的基礎功能,要求的前提是合法的服務器掌握著對應的私鑰。但RSA算法無法確保服務器身份的合法性,因為公鑰並不包含服務器的信息,存在安全隱患: 客戶端C和 fc標題索引本文出自 “一步一印,有印為證” 博客,謝絕轉載!FC協議詳解 相關推薦
組播及igmp/mld協議詳解(二)
組播及igmp/mld協議詳解(一)
HTTPS協議詳解(二):TLS/SSL工作原理
1553B 協議詳解之二字的組成
sip協議詳解 系列(二)
ICMP協議/IGMP協議詳解
網路知識總結二:物理層和鏈路層協議詳解
深入理解HTTP協議(二)——協議詳解篇
網絡協議詳解
HTTP協議詳解(真的很經典)
http協議詳解
HTTP 協議詳解
用戶和組管理命令介紹與詳解
Http 協議詳解筆記
spark2.x由淺入深深到底系列六之RDD java api詳解二
React—組件生命周期詳解
Linux——vim編輯器詳解二
HTTPS協議詳解(四):TLS/SSL握手過程
HTTPS協議詳解(三):PKI 體系
FC協議詳解