專利名稱：一種dhcp地址分配方法及裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，尤其涉及ー種DHCP地址分配方法及裝置。
背景技術(shù)：
DHCP (Dynamic Host Configuration Protocol,動態(tài)主機配置協(xié)議)是局域網(wǎng)的網(wǎng)絡(luò)協(xié)議，采用服務(wù)器/客戶端架構(gòu)，DHCP服務(wù)器主要用于為DHCP客戶端自動分配IP地
址等配置信息。 如圖I所示，DHCP客戶端從DHCP服務(wù)器動態(tài)獲取IP地址，主要通過四個階段進行(I)發(fā)現(xiàn)階段，即DHCP客戶端尋找DHCP服務(wù)器的階段。客戶端以廣播方式發(fā)送DHCP-DISCOVER 報文。(2)提供階段，即DHCP服務(wù)器提供IP地址的階段。DHCP服務(wù)器接收到客戶端的DHCP-DISCOVER報文后，根據(jù)IP地址分配的優(yōu)先次序選出ー個IP地址，與其他參數(shù)一起通過DHCP-0FFER報文發(fā)送給客戶端。DHCP-0FFER報文的發(fā)送方式由DHCP-DISC0VER報文中的flag字段決定。(3)選擇階段，即DHCP客戶端選擇IP地址的階段。如果有多臺DHCP服務(wù)器向該客戶端發(fā)來DHCP-0FFER報文，客戶端只接受第一個收到的DHCP-0FFER報文，然后以廣播方式發(fā)送DHCP-REQUEST報文，該報文中包含DHCP服務(wù)器在DHCP-0FFER報文中分配的IP地址。(4)確認階段，即DHCP服務(wù)器確認IP地址的階段。DHCP服務(wù)器收到DHCP客戶端發(fā)來的DHCP-REQUEST報文后，只有DHCP客戶端選擇的服務(wù)器會進行如下操作如果確認將地址分配給該客戶端，則返回DHCP-ACK報文；否則返回DHCP-NAK報文，表明地址不能分配
給該客戶端。由于在IP地址動態(tài)獲取過程中采用廣播方式發(fā)送請求報文，因此DHCP只適用于DHCP客戶端和服務(wù)器處于同一個子網(wǎng)內(nèi)的情況。為進行動態(tài)主機配置，需要在所有網(wǎng)段上都設(shè)置ー個DHCP服務(wù)器，這顯然是很不經(jīng)濟的。DHCP中繼功能的引入解決了這ー難題客戶端可以通過DHCP中繼與其他網(wǎng)段的DHCP服務(wù)器通信，最終獲取到IP地址。這樣，多個網(wǎng)絡(luò)上的DHCP客戶端可以使用同一個DHCP服務(wù)器，既節(jié)省了成本，又便于進行集中管理。通過DHCP中繼完成動態(tài)配置的過程中，DHCP客戶端與DHCP服務(wù)器的處理方式與不通過DHCP中繼時的處理方式基本相同。如圖2所示，基于DHCP中繼的DHCP地址分配過程包括具有DHCP中繼功能的網(wǎng)絡(luò)設(shè)備收到DHCP客戶端以廣播方式發(fā)送的DHCP-DISC0VER或DHCP-REQUEST報文后，將報文中的giaddr字段填充為DHCP中繼的IP地址，并根據(jù)配置將報文單播轉(zhuǎn)發(fā)給指定的DHCP服務(wù)器；DHCP服務(wù)器根據(jù)giaddr字段為客戶端分配IP地址等參數(shù)，并通過DHCP中繼將配置信息轉(zhuǎn)發(fā)給客戶端，完成對客戶端的動態(tài)配置?？梢钥闯?，在DHCP中繼和DHCP服務(wù)器之間都是通過單播方式轉(zhuǎn)發(fā)報文，并且針對每個客戶端都進行申請和確認過程，這樣，當存在大量客戶端同時登錄要求申請IP地址的時候，在DHCP中繼和DHCP服務(wù)器之間就存在大量的報文交互，對中繼和服務(wù)器造成一定的壓力。

發(fā)明內(nèi)容
本發(fā)明提供了ー種DHCP地址分配方法及裝置，用于在基于DHCP中繼進行IP地址分配的過程中，緩解DHCP中繼與DHCP服務(wù)器之間的報文交互壓カ。本發(fā)明實施例提供的DHCP地址分配方法，應(yīng)用于通過DHCP中繼進行IP地址分配的過程，該方法包括當DHCP中繼接收到設(shè)定數(shù)量的DHCP-DISC0VER報文后或者在設(shè)定時長到達時，根據(jù)接收到的設(shè)定數(shù)量的DHCP-DISC0VER報文或者在設(shè)定時長內(nèi)接收到的DHCP-DISC0VER報文，生成攜帶有相應(yīng)DHCP客戶端的客戶端信息的DHCP-DIC0VER報文并單播發(fā)送給DHCP服務(wù)器，以觸發(fā)DHCP服務(wù)器分別為所述相應(yīng)DHCP客戶端分配IP地址；

當DHCP中繼接收到DHCP服務(wù)器返回的攜帶有至少2個DHCP客戶端信息的DHCP-0FFER報文后，分別為所述至少2個DHCP客戶端生成攜帶有為相應(yīng)DHCP客戶端分配的IP地址的DHCP-0FFER報文，井分別發(fā)送給相應(yīng)DHCP客戶端；當DHCP中繼接收到設(shè)定數(shù)量的DHCP-REQUEST報文后或者在設(shè)定時長到達吋，根據(jù)接收到的所述設(shè)定數(shù)量的DHCP-REQUEST報文或者在設(shè)定時長內(nèi)接收到的DHCP-REQUEST報文，生成攜帶有相應(yīng)DHCP客戶端的客戶端信息的DHCP-REQUEST報文并單播發(fā)送給DHCP服務(wù)器，以觸發(fā)DHCP服務(wù)器分別為所述相應(yīng)DHCP客戶端確認分配的IP地址；當DHCP中繼接收到DHCP服務(wù)器返回的攜帶有至少2個DHCP客戶端信息的DHCP-ACK報文后，分別為所述至少2個DHCP客戶端生成攜帯有IP地址確認信息的DHCP-ACK/NAK報文，并分別發(fā)送給相應(yīng)DHCP客戶端。本發(fā)明實施例提供的DHCP中繼設(shè)備，包括地址請求模塊，用于當接收到設(shè)定數(shù)量的DHCP-DISC0VER報文后或者在設(shè)定時長到達時，根據(jù)接收到的設(shè)定數(shù)量的DHCP-DISCOVER報文或者在設(shè)定時長內(nèi)接收到的DHCP-DISC0VER報文，生成攜帶有相應(yīng)DHCP客戶端的客戶端信息的DHCP-DIC0VER報文并單播發(fā)送給DHCP服務(wù)器，以觸發(fā)DHCP服務(wù)器分別為所述相應(yīng)DHCP客戶端分配IP地址；地址請求響應(yīng)模塊，用于當接收到DHCP服務(wù)器返回的攜帶有至少2個DHCP客戶端信息的DHCP-0FFER報文后，分別為所述至少2個DHCP客戶端生成攜帶有為相應(yīng)DHCP客戶端分配的IP地址的DHCP-0FFER報文，并分別發(fā)送給相應(yīng)DHCP客戶端；地址確認請求模塊，用于當接收到設(shè)定數(shù)量的DHCP-REQUEST報文后或者在設(shè)定時長到達時，根據(jù)接收到的所述設(shè)定數(shù)量的DHCP-REQUEST報文或者在設(shè)定時長內(nèi)接收到的DHCP-REQUEST報文，生成攜帶有相應(yīng)DHCP客戶端的客戶端信息的DHCP-REQUEST報文并單播發(fā)送給DHCP服務(wù)器，以觸發(fā)DHCP服務(wù)器分別為所述相應(yīng)DHCP客戶端確認分配的IP地址；地址確認請求響應(yīng)模塊，用于當接收到DHCP服務(wù)器返回的攜帯有至少2個DHCP客戶端信息的DHCP-ACK報文后，分別為所述至少2個DHCP客戶端生成攜帯有IP地址確認信息的DHCP-ACK/NAK報文，并分別發(fā)送給相應(yīng)DHCP客戶端。
本發(fā)明實施例提供的DHCP服務(wù)器，包括地址分配模塊，用于當從DHCP中繼接收到攜帶有至少2個DHCP客戶端的客戶端信息的DHCP-DISC0VER報文后，分別為所述至少2個DHCP客戶端分配IP地址，并生成DHCP-0FFER報文，其中攜帶有為所述至少2個DHCP客戶端分配的IP地址；地址分配確認模塊，用于當從DHCP中繼接收到攜帶有至少2個DHCP客戶端的客戶端信息的DHCP-REQUEST報文后，分別對所述至少2個DHCP客戶端的IP地址進行確認，并生成DHCP-ACK報文，其中攜帶有對所述至少2個DHCP客戶端的IP地址進行確認的信息。本發(fā)明的上述實施例，通過DHCP中繼將接收到的多個DHCP請求報文處理成包含相應(yīng)多個客戶端信息的DHCP請求報文并單播發(fā)送給DHCP服務(wù)器，以觸發(fā)DHCP服務(wù)器為多個客戶端分配IP地址，以及在接收到DHCP服務(wù)器返回的攜帶有多個客戶端信息的DHCP響 應(yīng)報文后，生成相應(yīng)數(shù)量的DHCP響應(yīng)報文并分別發(fā)送給相應(yīng)客戶端，從而一次代理多個客戶端向DHCP服務(wù)器請求IP地址，與現(xiàn)有技術(shù)相比，減少了 DHCP中繼和DHCP服務(wù)器之間交互的報文數(shù)量，進而緩解DHCP中繼與DHCP服務(wù)器之間的報文交互壓カ。


圖I為現(xiàn)有技術(shù)中DHCP客戶端動態(tài)獲取IP地址的流程示意圖；圖2為現(xiàn)有技術(shù)中基于DHCP中繼的IP地址分配流程示意圖；圖3為本發(fā)明實施例提供的基于DHCP中繼的IP地址分配流程框圖；圖4為本發(fā)明實施例提供的基于DHCP中繼的IP地址分配流程信令圖；圖5為現(xiàn)有技術(shù)中DHCP報文格式示意圖；圖6為本發(fā)明實施例提供的DHCP中繼發(fā)送給DHCP服務(wù)器的DHCP-DISCOVER報文格式示意圖；圖I為本發(fā)明實施例提供的DHCP中繼設(shè)備的結(jié)構(gòu)示意圖；圖8為本發(fā)明實施例提供的DHCP服務(wù)器的結(jié)構(gòu)示意圖。
具體實施例方式為了減少DHCP中繼與DHCP服務(wù)器之間的報文交互壓力，本發(fā)明實施例擴展了DHCP中繼和DHCP服務(wù)器的功能，DHCP中繼可以一次代理多個DHCP客戶端向DHCP服務(wù)器申請IP地址，DHCP服務(wù)器可以響應(yīng)DHCP中繼為多個DHCP客戶端申請IP地址的請求。下面結(jié)合附圖對本發(fā)明實施例進行詳細描述。參見圖3和圖4，為本發(fā)明實施例提供的基于DHCP中繼為DHCP客戶端(以下簡稱客戶端)分配IP地址的流程示意圖，其中圖3為流程框圖，圖4為信令流程示意圖。DHCP中繼在設(shè)備初始化時，可預先在其上配置報文數(shù)量N(N > I)。N的取值可根據(jù)客戶端的IP地址分配請求的并發(fā)數(shù)量或/和網(wǎng)絡(luò)環(huán)境等因素而定。進ー步的，根據(jù)客戶端的IP地址分配請求的并發(fā)數(shù)量在不同時段而不同的特點，也可根據(jù)時段的不同對N的取值進行相應(yīng)調(diào)整。如圖3所示，該流程可包括以下步驟步驟301 302，DHCP中繼接收客戶端廣播的DHCP-DISCOVER報文，并當接收到的報文數(shù)量到達N時，轉(zhuǎn)入步驟303。
具體實施時，大量客戶端通過DHCP中繼向DHCP服務(wù)器申請地址，此種情況下，DHCP中繼會在短時間內(nèi)收到大量的DHCP-DISCOVER報文，DHCP-DISC0VER報文中攜帶有客戶端的硬件地址等信息。一旦DHCP中繼接收到的DHCP-DISC0VER報文數(shù)量達到N，則繼續(xù)執(zhí)行以下步驟。步驟303，DHCP中繼根據(jù)接收到的N個DHCP-DISC0VER報文，重新生成DHCP-DISCOVER報文，其中攜帶有所述N個DHCP-DISC0VER報文所對應(yīng)的客戶端的信息，并通過一次請求過程單播發(fā)送給DHCP服務(wù)器。具體實施吋，DHCP中繼提取接收到的N個DHCP-DISC0VER報文中每個報文攜帶的客戶端信息，然后根據(jù)提取到的客戶端信息生成一個新的DHCP-DISC0VER報文，其中攜帯這些客戶端信息，并單播發(fā)送給DHCP服務(wù)器。DHCP中繼所生成的DHCP-DISC0VER中攜帶的客戶端信息中至少包括客戶端硬件地址信息。如果DHCP服務(wù)器有多個，則DHCP中繼可分別向每個DHCP服務(wù)器單播發(fā)送其所生成的DHCP-DISC0VER報文。步驟304，DHCP服務(wù)器接收到DHCP中繼發(fā)送的DHCP-DISC0VER報文后，根據(jù)其中攜帶的多個客戶端信息，分別為這些客戶端分配IP地址，根據(jù)分配結(jié)果生成DHCP-0FFER報文，并通過一次響應(yīng)過程單播返回給DHCP中繼。 具體實施吋，DHCP服務(wù)器具備一次性分配多個IP地址的能力，可以處理帶有多個客戶端信息的DHCP-DISC0VER報文。DHCP服務(wù)器在接收到DHCP中繼發(fā)送的攜帶有多個客戶端信息的DHCP-DISC0VER報文后，分別為這些客戶端分配IP地址，根據(jù)分配結(jié)果生成一個DHCP-0FFER報文，其中攜帶這些客戶端的信息(包括客戶端的硬件地址信息和為客戶端分配的IP地址信息等)并將其返回給DHCP中繼。步驟305，DHCP中繼接收到DHCP服務(wù)器返回的DHCP-0FFER報文后，根據(jù)其中攜帶的多個客戶端信息，分別為這些客戶端生成DHCP-0FFER報文，其中攜帯客戶端的硬件地址信息和為該客戶端分配的IP地址信息，然后分別將為相應(yīng)客戶端生成的DHCP-0FFER報文發(fā)送給相應(yīng)的客戶端。步驟306 307，客戶端接收到DHCP中繼返回的DHCP-0FFER報文后，廣播DHCP-REQUEST報文。DHCP中繼接收客戶端廣播的DHCP-REQUEST報文，并當接收到的報文數(shù)量到達N時，轉(zhuǎn)入步驟308。具體實施吋，客戶端接收到DHCP-0FFER報文，并在確認接受分配的IP地址后，廣播發(fā)送DHCP-REQUEST報文，該報文中攜帶有該客戶端的硬件地址信息和該客戶端選擇的DHCP服務(wù)器的IP地址信息等信息。步驟308，DHCP中繼根據(jù)接收到的N個DHCP-REQUEST報文，重新生成DHCP-REQUEST報文，其中攜帶有所述N個DHCP-REQUEST報文所對應(yīng)的客戶端的信息，并通過一次請求過程單播發(fā)送給DHCP服務(wù)器。具體實施吋，DHCP中繼提取接收到的N個DHCP-REQUEST報文中每個報文攜帶的客戶端信息(包括客戶端硬件地址信息和該客戶端所接受的IP地址信息等)，然后根據(jù)提取到的客戶端信息生成一個新的DHCP-REQUEST報文，其中攜帶這些客戶端信息，并單播發(fā)送給DHCP服務(wù)器。DHCP中繼所生成的DHCP-REQUEST報文中攜帶的客戶端信息中可包括客戶端硬件地址信息和該客戶端所接受的IP地址信息。步驟309，DHCP服務(wù)器接收到DHCP中繼發(fā)送的DHCP-REQUEST報文后，根據(jù)其中攜帶的多個客戶端信息，生成ー個DHCP-ACK報文，并通過一次響應(yīng)過程單播返回給DHCP中繼。具體實施時，DHCP服務(wù)器根據(jù)接收到的DHCP-REQUEST報文，可以獲知哪些客戶端接受本服務(wù)器分配的IP地址，哪些服務(wù)器未接受本服務(wù)器分配的IP地址。在生成的DHCPACK報文中，對于接受本服務(wù)器分配的IP地址的客戶端，其客戶端信息中包含ACK(確認)信息，對于未接受本服務(wù)器分配的IP地址的客戶端，其客戶端信息中包含NAK (未確認)信息。對于本服務(wù)器所分配的但未被客戶端所接受的IP地址，本服務(wù)器還可繼續(xù)分配給其它請求IP地址的客戶端。步驟310，DHCP中繼接收到DHCP服務(wù)器返回的DHCP-ACK報文后，根據(jù)其中攜帶的多個客戶端信息，分別為這些客戶端生成DHCP-ACK/NAK報文，然后分別將為相應(yīng)客戶端生 成的DHCP-ACK/NAK報文發(fā)送給相應(yīng)的客戶端。具體實施吋，DHCP中繼根據(jù)DHCP服務(wù)器返回的DHCP-ACK報文可獲知DHCP服務(wù)器對哪些客戶端進行了 ACK確認，對哪些客戶端進行了 NAK確認。對于那些進行了 ACK確認的客戶端，DHCP中繼生成DHCP-ACK報文并發(fā)送給相應(yīng)客戶端，對于那些進行了 NAK確認的客戶端，DHCP中繼生成DHCP-NAK報文并發(fā)送給相應(yīng)客戶端。上述流程的步驟303中，若DHCP中繼所生成的DHCP-DISC0VER報文長度沒有超過規(guī)定的報文長度，則將所生成的DHCP-DISC0VER報文作為ー個報文發(fā)送；若DHCP中繼所生成的DHCP-DISC0VER報文長度超過規(guī)定的報文長度，則將所生成的DHCP-DISC0VER報文進行分片發(fā)送。同理，在步驟308中，若DHCP中繼所生成的DHCP-REQUEST報文長度沒有超過規(guī)定的報文長度，則將所生成的DHCP-REQUEST報文作為ー個報文發(fā)送；若DHCP中繼所生成的DHCP-REQUEST報文長度超過規(guī)定的報文長度，則將所生成的DHCP-REQUEST報文進行分片發(fā)送。對于DHCP服務(wù)器，也可在報文長度超過規(guī)定的報文長度時，將生成的DHCP-0FFER報文或DHCP-ACK報文進行分片發(fā)送。在本發(fā)明的另ー實施例中，可以在DHCP中繼上配置設(shè)定時長信息，相應(yīng)的，步驟301 302可替換為DHCP中繼在接收客戶端廣播的DHCP DISCOVER報文的過程中，一旦該設(shè)定時長到達，則執(zhí)行步驟303，此后的處理過程與圖3所示流程類似。同理，步驟306 307可替換為DHCP中繼接收客戶端廣播的DHCP-REQUEST報文，一旦該設(shè)定時長到達，轉(zhuǎn)入步驟308，此后的處理過程與圖3所示流程類似。本發(fā)明的各實施例中，DHCP中繼所生成的發(fā)向DHCP服務(wù)器的DHCP報文(包括DHCP-DISCOVER報文和DHCP-REQUEST報文)，以及DHCP服務(wù)器所生成并發(fā)向DHCP中繼的DHCP報文(包括DHCP-0FFER報文和DHCP-ACK報文)，可參照現(xiàn)有DHCP報文的格式設(shè)計。現(xiàn)有DHCP報文有4種類型，每種類型的DHCP報文的格式相同，只是某些字段的取值不同?，F(xiàn)有的DHCP報文格式可如圖5所示。其中，各字段的解釋如下op :DHCP報文的操作類型，分為請求報文和響應(yīng)報文，I表示請求報文；2表示響應(yīng)報文，更具體的報文類型在options字段中標識；htype、hlen DHCP客戶端的硬件地址類型及長度；hops =DHCP報文經(jīng)過的DHCP中繼的數(shù)目。DHCP請求報文每經(jīng)過ー個DHCP中繼，該字段就會增加I ;xid :客戶端發(fā)起一次請求時選擇的隨機數(shù)，用來標識一次地址請求過程；
secs DHCP客戶端開始DHCP請求后所經(jīng)過的時間。目前沒有使用，固定為0 ;flags :第一個比特為廣播響應(yīng)標識位，用來標識DHCP服務(wù)器響應(yīng)報文是采用單播還是廣播方式發(fā)送，0表示采用單播方式，I表示采用廣播方式，其余比特保留不用。ciaddr =DHCP 客戶端的 IP 地址；yiaddr DHCP服務(wù)器分配給客戶端的IP地址；siaddr =DHCP客戶端獲取IP地址等信息的服務(wù)器IP地址；giaddr =DHCP客戶端發(fā)出請求報文后經(jīng)過的第一個DHCP中繼的IP地址；

chaddr =DHCP客戶端的硬件地址；sname =DHCP客戶端獲取IP地址等信息的服務(wù)器名稱；file =DHCP服務(wù)器為DHCP客戶端指定的啟動配置文件名稱及路徑信息；options :可選變長選項字段，包含報文的類型、有效租期、DNS(Domain NameSystem,域名系統(tǒng))服務(wù)器的 IP 地址、WINS (Windows Internet NamingServer, WindowsInternet命名服務(wù))服務(wù)器的IP地址等配置信息。DHCP報文的ciaddr、yiaddr、chaddr字段，在DHCP各報文中針對不同客戶端其內(nèi)容不同；對于options字段，由DHCP中繼發(fā)送給相同服務(wù)器的字段都可以重用。根據(jù)以上特點，本發(fā)明實施例中，DHCP中繼在生成發(fā)向DHCP服務(wù)器的DHCP報文時，對于不同客戶端不能共用的信息，需要在DHCP報文中添加與客戶端數(shù)量相應(yīng)的字段，用這些字段進行承載，對于不同客戶端可以共用的信息，則可以重用現(xiàn)有DHCP報文中的字段(如對于各客戶端所共用的option信息，可用DHCP報文的options字段承載)。比如，不同客戶端的硬件地址、IP地址等信息不相同，則可在DHCP報文中為各客戶端對應(yīng)設(shè)置Dhcp-option字段以承載各客戶端的專有信息。而在同一類環(huán)境中，大部分報文所包含的option信息相同，如都是請求報文，都來自同一個廠家等，因此本發(fā)明實施例可將這些信息承載到整個報文的options字段中。進ー步的，考慮到一些客戶端可以有特定的與其它客戶端不同的option信息,對于這樣的客戶端，需要在該客戶端對應(yīng)的Dhcp-option字段中包含該客戶端所特定的option信息。同理，DHCP服務(wù)器生成的DHCP報文也具有類似結(jié)構(gòu)。進ー步的，DHCP中繼可在其所生成的發(fā)向DHCP服務(wù)器的DHCP報文中，添加指示標識，以標識該DHCP報文中是否攜帯多個客戶端的信息，以及進一歩在攜帯有多個客戶端信息的情況下，標識攜帶有多個客戶端的信息，以便DHCP服務(wù)器采用相應(yīng)方式以響應(yīng)該DHCP報文。同理，DHCP服務(wù)器在發(fā)送給DHCP中繼的DHCP報文中也可攜帶類似指示標識。通過這種方式可在DHCP中繼和DHCP服務(wù)器之間進行能力協(xié)商。本發(fā)明實施例優(yōu)選使用flag字段攜帯上述指示信息。目前flag字段總共有16個bit，其中第I個比特為廣播相應(yīng)標識位，本發(fā)明實施例使用第2個比特標識是否支持一次性申請多個IP地址的能力(如I表示支持，0表示不支持)，進ー步可使用第3 15個比特表示此次申請IP地址的個數(shù)，即可以支持0x1 fff = 8191個，最后一個比特為客戶端信息開始標識位。如果在設(shè)定長時間內(nèi)僅接收到ー個客戶端發(fā)送的DHCP-DISC0VER報文，則可將flag字段中的第2個比特的取值設(shè)置為0(表示不支持一次性申請多個IP地址)，相應(yīng)的，DHCP服務(wù)器按照現(xiàn)有方式響應(yīng)包含該指示信息的DHCP報文。圖6示出了本發(fā)明實施例提供的ー種DHCP中繼和DHCP服務(wù)器之間交互的DHCP報文的格式。以DHCP中繼規(guī)定可一次性申請3個IP地址為例，其所生成的DHCP-DISCOVER報文可如圖6所示。其中對于3個客戶端，包含有3個dhcp-option字段，以分別承載相應(yīng)客戶端所必須的信息，還可以承載相應(yīng)客戶端所特定的option信息。在報文最后的options字段中，承載這3個客戶端所共用的option信息(如報文的類型、有效租期、DNS服務(wù)器的IP地址、WINS服務(wù)器的IP地址等配置信息)。其中，dhcp-option字段可米用T-L-V格式T(Type):標識dhcp-option字段的類型，即該字段是用來承載客戶端信息的；L(Iength):整個 dhcp-option 字段的長度；V(value):客戶端的具體信息。其中，V中可包含如下幾種信息ciaddr =DHCP 客戶端的 IP 地址； yiaddr =DHCP服務(wù)器分配給客戶端的IP地址；chaddr =DHCP客戶端的硬件地址；Options =DHCP各客戶端所帯特有的option信息。該字段根據(jù)實際情況可選。通過以上描述可以看出，本發(fā)明實施例通過DHCP中繼對從客戶端接收到的多個DHCP報文進行適當裁剪屬性，合并冗余字段，從而生成發(fā)送給DHCP服務(wù)器DHCP報文，通過一次請求過程將多個客戶端的IP地址請求發(fā)送給DHCP服務(wù)器，提供DHCP報文批量處理能力，提高DHCP服務(wù)器多地址分配的能力，有效地緩解了 DHCP中繼與DHCP服務(wù)器之間的報文交互壓力。尤其在大量客戶端集中上線申請IP地址的時候，采用本發(fā)明實施例可有效減少DHCP中繼和DHCP服務(wù)器之間的報文交互，有效的緩解DHCP中繼和DHCP服務(wù)器的報文處理能力，減少鏈路帶寬的壓力。下面以在有線電視網(wǎng)絡(luò)中應(yīng)用本發(fā)明實施例為例進行說明。有限電視網(wǎng)絡(luò)結(jié)構(gòu)分為核心層，匯聚層，接入層三個部分。核心層采用核心路由器，匯聚全網(wǎng)業(yè)務(wù)；匯聚層采用具有三層功能的匯聚交換機，通過DHCP中繼的方式為終端機頂盒提供IP地址；接入層一般采用EPON(Ethernet Passive Optical Network,以太網(wǎng)無源光網(wǎng)絡(luò))或接入交換機實現(xiàn)入戶。有線電視網(wǎng)絡(luò)具有如下幾方面的特點(I)終端類型單ー對于ー個有線電視運營商，出于降低運營成本的考慮，一般機頂盒品牌不會超過三家，在同一個地區(qū)，一般只選擇ー個廠家的機頂盒；(2)終端密集，數(shù)量眾多由于廣播電視業(yè)務(wù)的滲透率較高，基本可以做到ー戶一臺，甚至ー戶多臺機頂盒的情況，而且家庭電視業(yè)務(wù)并發(fā)率高于數(shù)據(jù)業(yè)務(wù)，因此高峰時段在線用戶數(shù)量非常龐大。在工程實踐中，觀察到ー個現(xiàn)象，就是在晚間6 7點左右的時段，用戶上線非常集中，經(jīng)常出現(xiàn)大量用戶并發(fā)上線，同時申請地址，導致DHCP服務(wù)器不能有效分配出地址的現(xiàn)象。該現(xiàn)象的出現(xiàn)主要原因是作為DHCP中繼的設(shè)備，由于下掛用戶過多，DHCP報文數(shù)量過大，導致部分DHCP報文被丟棄。采用本發(fā)明實施例，可以解決瞬間大量客戶端同時申請地址，造成DHCP中繼和DHCP服務(wù)器之間大量報文交互，設(shè)備處理壓力過大的問題?；谙嗤募夹g(shù)構(gòu)思，本發(fā)明實施例還提供了ー種DHCP中繼設(shè)備和ー種DHCP服務(wù)器。參見圖7，為本發(fā)明實施例提供的DHCP中繼設(shè)備的結(jié)構(gòu)示意圖，該設(shè)備可包括地址請求模塊701、地址請求響應(yīng)模塊702、地址確認請求模塊703和地址確認請求響應(yīng)模塊704，其中地址請求模塊701，用于當接收到設(shè)定數(shù)量的DHCP-DISC0VER報文后或者在設(shè)定時長到達時，根據(jù)接收到的設(shè)定數(shù)量的DHCP-DISC0VER報文或者在設(shè)定時長內(nèi)接收到的DHCP-DISC0VER報文，生成攜帶有相應(yīng)DHCP客戶端的客戶端信息的DHCP-DIC0VER報文并單播發(fā)送給DHCP服務(wù)器，以觸發(fā)DHCP服務(wù)器分別為所述相應(yīng)DHCP客戶端分配IP地址；地址請求響應(yīng)模塊702，用于當接收到DHCP服務(wù)器返回的攜帶有至少2個DHCP客 戶端信息的DHCP-0FFER報文后，分別為所述至少2個DHCP客戶端生成攜帯有為相應(yīng)DHCP客戶端分配的IP地址的DHCP-0FFER報文，并分別發(fā)送給相應(yīng)DHCP客戶端；地址確認請求模塊703，用于當接收到設(shè)定數(shù)量的DHCP-REQUEST報文后或者在設(shè)定時長到達時，根據(jù)接收到的所述設(shè)定數(shù)量的DHCP-REQUEST報文或者在設(shè)定時長內(nèi)接收到的DHCP-REQUEST報文，生成攜帶有相應(yīng)DHCP客戶端的客戶端信息的DHCP-REQUEST報文并單播發(fā)送給DHCP服務(wù)器，以觸發(fā)DHCP服務(wù)器分別為所述相應(yīng)DHCP客戶端確認分配的IP地址；地址確認請求響應(yīng)模塊704，用于當接收到DHCP服務(wù)器返回的攜帯有至少2個DHCP客戶端信息的DHCP-ACK報文后，分別為所述至少2個DHCP客戶端生成攜帯有IP地址確認信息的DHCP-ACK/NAK報文，并分別發(fā)送給相應(yīng)DHCP客戶端。具體的，地址請求模塊701生成的DHCP-DISC0VER報文中，每個DHCP客戶端的客戶端信息中，至少包括=DHCP客戶端的硬件地址信息；地址請求響應(yīng)模塊702接收到的DHCPOFFER報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息和分配給該客戶端的IP地址信息。進ー步的，對于具有特定OPTION信息的DHCP客戶端地址請求模塊701生成的DHCP-DISC0VER報文中，相應(yīng)DHCP客戶端的客戶端信息中，還攜帶有該DHCP客戶端所具有的特定OPTION信息，地址請求模塊701生成的DHCP-DISCOVER報文的OPTIONS字段中所攜帯的信息為各DHCP客戶端所共有的OPTION信息；地址請求響應(yīng)模塊702接收到的DHCP-0FFER報文中，相應(yīng)DHCP客戶端的客戶端信息中，還攜帶有該DHCP客戶端所具有的特定OPTION信息，地址請求響應(yīng)模塊702接收到的DHCP-0FFER報文的OPTIONS字段中所攜帯的信息為各DHCP客戶端所共有的OPTION信息。具體的，地址確認請求模塊703生成的DHCP-REQUEST報文中，每個DHCP客戶端的客戶端信息中，至少包括=DHCP客戶端的硬件地址信息和該客戶端所接受的IP地址；地址確認請求響應(yīng)模塊704接收到的DHCP-ACK報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息和針對該客戶端的IP地址確認信息。進ー步的，若地址請求模塊701生成的DHCP-DISC0VER報文的長度未超過規(guī)定長度，則通過一次發(fā)送過程將生成的DHCP-DISC0VER報文單播發(fā)送給DHCP服務(wù)器；若地址請求模塊701生成的DHCP-DISC0VER報文的長度超過規(guī)定長度，則將生成的DHCP-DISC0VER報文進行分片，并通過多次發(fā)送過程單播發(fā)送到DHCP服務(wù)器，每次發(fā)送其中的ー個分片。若地址確認請求模塊703生成的DHCP-REQUEST報文的長度未超過規(guī)定長度，則通過一次發(fā)送過程將生成的DHCP-REQUEST報文單播發(fā)送給DHCP服務(wù)器；若地址確認請求模塊703生成的DHCP-REQUEST報文的長度超過規(guī)定長度，則將生成的DHCP-REQUEST報文進行分片，并通過多次發(fā)送過程單播發(fā)送到DHCP服務(wù)器，每次發(fā)送其中的ー個分片。進ー步的，地址請求模塊701生成的DHCP-DISC0VER報文或/和地址確認請求模塊703生成的DHCP-REQUEST報文中還攜帶有標識信息，以標識報文中攜帶有至少2個DHCP
客戶端的客戶端信息。參見圖8，為本發(fā)明實施例提供的DHCP服務(wù)器的結(jié)構(gòu)示意圖，該DHCP服務(wù)器可包括地址分配模塊801、地址分配確認模塊802，其中地址分配模塊801，用于當從DHCP中繼接收到攜帶有至少2個DHCP客戶端的客戶端信息的DHCP-DISC0VER報文后，分別為所述至少2個DHCP客戶端分配IP地址，并生成DHCP-0FFER報文，其中攜帶有為所述至少2個DHCP客戶端分配的IP地址；地址分配確認模塊802，用于當從DHCP中繼接收到攜帶有至少2個DHCP客戶端的客戶端信息的DHCP-REQUEST報文后，分別對所述至少2個DHCP客戶端的IP地址進行確 認，并生成DHCP-ACK報文，其中攜帶有對所述至少2個DHCP客戶端的IP地址進行確認的信息。具體的，地址分配模塊801接收到的DHCP-DISCOVER報文中，每個DHCP客戶端的客戶端信息中，至少包括=DHCP客戶端的硬件地址信息；地址分配模塊801生成的DHCPOFFER報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息和分配給該客戶端的IP地址信息。進ー步的，對于具有特定OPTION信息的DHCP客戶端地址分配模塊801接收到的DHCP-DISC0VER報文中，相應(yīng)DHCP客戶端的客戶端信息中，還攜帶有該DHCP客戶端所具有的特定OPTION信息，地址分配模塊801接收到的DHCP-DISC0VER報文的OPTIONS字段中所攜帯的信息為各DHCP客戶端所共有的OPTION信息；址分配模塊801生成的DHCP-0FFER報文中，相應(yīng)DHCP客戶端的客戶端信息中，還攜帶有該DHCP客戶端所具有的特定OPTION信息，址分配模塊801生成的DHCP-0FFER報文的OPTIONS字段中所攜帯的信息為各DHCP客戶端所共有的OPTION信息。具體的，地址分配確認模塊802接收到的DHCP-REQUEST報文中，每個DHCP客戶端的客戶端信息中，至少包括=DHCP客戶端的硬件地址信息和該客戶端所接受的IP地址；地址分配確認模塊802生成的DHCP-ACK報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息和針對該客戶端的IP地址確認信息。進ー步的，若地址分配模塊801生成的DHCP-0FFER報文的長度未超過規(guī)定長度，則通過一次發(fā)送過程將生成的DHCP-0FFER報文單播發(fā)送給DHCP中繼；若地址分配模塊801生成的DHCP-0FFER報文的長度超過規(guī)定長度，則將生成的DHCP-0FFER報文進行分片，并通過多次發(fā)送過程單播發(fā)送到DHCP中繼，毎次發(fā)送其中的一個分片；若所述DHCP服務(wù)器生成的DHCP-ACK報文的長度未超過規(guī)定長度，則通過一次發(fā)送過程將生成的DHCP-ACK報文單播發(fā)送給DHCP中繼；若地址分配確認模塊802生成的DHCP-ACK報文的長度超過規(guī)定長度，則將生成的DHCP-ACK報文進行分片，并通過多次發(fā)送過程單播發(fā)送到DHCP中繼，每次發(fā)送其中的ー個分片。進ー步的，地址分配模塊801生成的DHCP-0FFER報文或/和地址分配確認模塊802生成的DHCP-ACK報文中還攜帶有標識信息，以標識報文中攜帶有至少2個DHCP客戶端
的客戶端信息。
通過以上的實施方式的描述，本領(lǐng)域的技術(shù)人員可以清楚地了解到本發(fā)明可借助軟件加必需的通用硬件平臺的方式來實現(xiàn)，當然也可以通過硬件，但很多情況下前者是更佳的實施方式。基于這樣的理解，本發(fā)明的技術(shù)方案本質(zhì)上或者說對現(xiàn)有技術(shù)做出貢獻的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品存儲在ー個存儲介質(zhì)中，包括若干指令用以使得一臺終端設(shè)備(可以是手機，個人計算機，服務(wù)器，或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個實施例所述的方法。以上所述僅是本發(fā)明的優(yōu)選實施方式，應(yīng)當指出，對于本技術(shù)領(lǐng)域的普通技術(shù)人 員來說，在不脫離本發(fā)明原理的前提下，還可以做出若干改進和潤飾，這些改進和潤飾也應(yīng)視本發(fā)明的保護范圍。
權(quán)利要求
1.一種動態(tài)主機配置協(xié)議DHCP地址分配方法，應(yīng)用于通過DHCP中繼進行IP地址分配的過程，其特征在于，該方法包括 當DHCP中繼接收到設(shè)定數(shù)量的DHCP-DISCOVER報文后或者在設(shè)定時長到達時，根據(jù)接收到的設(shè)定數(shù)量的DHCP-DISCOVER報文或者在設(shè)定時長內(nèi)接收到的DHCP-DISCOVER報文，生成攜帶有相應(yīng)DHCP客戶端的客戶端信息的DHCP-DICOVER報文并單播發(fā)送給DHCP服務(wù)器，以觸發(fā)DHCP服務(wù)器分別為所述相應(yīng)DHCP客戶端分配IP地址； 當DHCP中繼接收到DHCP服務(wù)器返回的攜帶有至少2個DHCP客戶端信息的DHCP-OFFER報文后，分別為所述至少2個DHCP客戶端生成攜帶有為相應(yīng)DHCP客戶端分配的IP地址的DHCP-OFFER報文，并分別發(fā)送給相應(yīng)DHCP客戶端； 當DHCP中繼接收到設(shè)定數(shù)量的DHCP-REQUEST報文后或者在設(shè)定時長到達時，根據(jù)接收到的所述設(shè)定數(shù)量的DHCP-REQUEST報文或者在設(shè)定時長內(nèi)接收到的DHCP-REQUEST報文，生成攜帶有相應(yīng)DHCP客戶端的客戶端信息的DHCP-REQUEST報文并單播發(fā)送給DHCP服務(wù)器，以觸發(fā)DHCP服務(wù)器分別為所述相應(yīng)DHCP客戶端確認分配的IP地址； 當DHCP中繼接收到DHCP服務(wù)器返回的攜帶有至少2個DHCP客戶端信息的DHCP-ACK報文后，分別為所述至少2個DHCP客戶端生成攜帶有IP地址確認信息的DHCP-ACK/NAK報文，并分別發(fā)送給相應(yīng)DHCP客戶端。
2.如權(quán)利要求I所述的方法，其特征在于，所述DHCP中繼生成的DHCP-DISCOVER報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息； 所述DHCP中繼接收到的DHCP OFFER報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息和分配給該客戶端的IP地址信息。
3.如權(quán)利要求2所述的方法，其特征在于，對于具有特定OPTION信息的DHCP客戶端 所述DHCP中繼生成的DHCP-DISCOVER報文中，相應(yīng)DHCP客戶端的客戶端信息中，還攜帶有該DHCP客戶端所具有的特定OPTION信息，所述DHCP中繼生成的DHCP-DISCOVER報文的OPTIONS字段中所攜帶的信息為各DHCP客戶端所共有的OPTION信息； 所述DHCP中繼接收到的DHCP-OFFER報文中，相應(yīng)DHCP客戶端的客戶端信息中，還攜帶有該DHCP客戶端所具有的特定OPTION信息，所述DHCP中繼接收到的DHCP-OFFER報文的OPTIONS字段中所攜帶的信息為各DHCP客戶端所共有的OPTION信息。
4.如權(quán)利要求I所述的方法，其特征在于，所述DHCP中繼生成的DHCP-REQUEST報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息和該客戶端所接受的IP地址； 所述DHCP中繼接收到的DHCP-ACK/NAK報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息和針對該客戶端的IP地址確認信息。
5.如權(quán)利要求1-4之一所述的方法，其特征在于，所述DHCP中繼生成的攜帶有至少2個DHCP客戶端的客戶端信息的DHCP-DISCOVER報文或/和DHCP-REQUEST報文中還攜帶有標識信息，以標識報文中攜帶有至少2個DHCP客戶端的客戶端信息。
6.一種動態(tài)主機配置協(xié)議DHCP中繼設(shè)備，其特征在于，包括 地址請求模塊，用于當接收到設(shè)定數(shù)量的DHCP-DISCOVER報文后或者在設(shè)定時長到達時，根據(jù)接收到的設(shè)定數(shù)量的DHCP-DISCOVER報文或者在設(shè)定時長內(nèi)接收到的DHCP-DISCOVER報文，生成攜帶有相應(yīng)DHCP客戶端的客戶端信息的DHCP-DICOVER報文并單播發(fā)送給DHCP服務(wù)器，以觸發(fā)DHCP服務(wù)器分別為所述相應(yīng)DHCP客戶端分配IP地址； 地址請求響應(yīng)模塊，用于當接收到DHCP服務(wù)器返回的攜帶有至少2個DHCP客戶端信息的DHCP-OFFER報文后，分別為所述至少2個DHCP客戶端生成攜帶有為相應(yīng)DHCP客戶端分配的IP地址的DHCP-OFFER報文，并分別發(fā)送給相應(yīng)DHCP客戶端； 地址確認請求模塊，用于當接收到設(shè)定數(shù)量的DHCP-REQUEST報文后或者在設(shè)定時長到達時，根據(jù)接收到的所述設(shè)定數(shù)量的DHCP-REQUEST報文或者在設(shè)定時長內(nèi)接收到的DHCP-REQUEST報文，生成攜帶有相應(yīng)DHCP客戶端的客戶端信息的DHCP-REQUEST報文并單播發(fā)送給DHCP服務(wù)器，以觸發(fā)DHCP服務(wù)器分別為所述相應(yīng)DHCP客戶端確認分配的IP地址； 地址確認請求響應(yīng)模塊，用于當接收到DHCP服務(wù)器返回的攜帶有至少2個DHCP客戶端信息的DHCP-ACK報文后，分別為所述至少2個DHCP客戶端生成攜帶有IP地址確認信息的DHCP-ACK/NAK報文，并分別發(fā)送給相應(yīng)DHCP客戶端。
7.如權(quán)利要求6所述的DHCP中繼設(shè)備，其特征在于，所述地址請求模塊生成的DHCP-DISCOVER報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息； 所述地址請求響應(yīng)模塊接收到的DHCP OFFER報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息和分配給該客戶端的IP地址信息。
8.如權(quán)利要求7所述的DHCP中繼設(shè)備，其特征在于，對于具有特定OPTION信息的DHCP客戶端 所述地址請求模塊生成的DHCP-DISCOVER報文中，相應(yīng)DHCP客戶端的客戶端信息中，還攜帶有該DHCP客戶端所具有的特定OPTION信息，所述地址請求模塊生成的DHCP-DISCOVER報文的OPTIONS字段中所攜帶的信息為各DHCP客戶端所共有的OPTION信息； 所述地址請求響應(yīng)模塊接收到的DHCP-OFFER報文中，相應(yīng)DHCP客戶端的客戶端信息中，還攜帶有該DHCP客戶端所具有的特定OPTION信息，所述地址請求響應(yīng)模塊接收到的DHCP-OFFER報文的OPTIONS字段中所攜帶的信息為各DHCP客戶端所共有的OPTION信息。
9.如權(quán)利要求6所述的DHCP中繼設(shè)備，其特征在于，所述地址確認請求模塊生成的DHCP-REQUEST報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息和該客戶端所接受的IP地址； 所述地址確認請求響應(yīng)模塊接收到的DHCP-ACK/NAK報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息和針對該客戶端的IP地址確認信息。
10.一種動態(tài)主機配置協(xié)議DHCP服務(wù)器，其特征在于，包括 地址分配模塊，用于當從DHCP中繼接收到攜帶有至少2個DHCP客戶端的客戶端信息的DHCP-DISCOVER報文后，分別為所述至少2個DHCP客戶端分配IP地址，并生成DHCP-OFFER報文，其中攜帶有為所述至少2個DHCP客戶端分配的IP地址； 地址分配確認模塊，用于當從DHCP中繼接收到攜帶有至少2個DHCP客戶端的客戶端信息的DHCP-REQUEST報文后，分別對所述至少2個DHCP客戶端的IP地址進行確認，并生成DHCP-ACK報文，其中攜帶有對所述至少2個DHCP客戶端的IP地址進行確認的信息。
11.如權(quán)利要求10所述的DHCP服務(wù)器，其特征在于，所述地址分配模塊接收到的DHCP-DISCOVER報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息； 所述地址分配模塊生成的DHCP OFFER報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息和分配給該客戶端的IP地址信息。
12.如權(quán)利要求11所述的DHCP服務(wù)器，其特征在于，對于具有特定OPTION信息的DHCP客戶端 所述地址分配模塊接收到的DHCP-DISCOVER報文中，相應(yīng)DHCP客戶端的客戶端信息中，還攜帶有該DHCP客戶端所具有的特定OPTION信息，所述地址分配模塊接收到的DHCP-DISCOVER報文的OPTIONS字段中所攜帶的信息為各DHCP客戶端所共有的OPTION信息； 所地址分配模塊生成的DHCP-0FFER報文中，相應(yīng)DHCP客戶端的客戶端信息中，還攜帶有該DHCP客戶端所具有的特定OPTION信息，所述址分配模塊生成的DHCP-0FFER報文的OPTIONS字段中所攜帶的信息為各DHCP客戶端所共有的OPTION信息。
13.如權(quán)利要求10所述的DHCP服務(wù)器，其特征在于，所述地址分配確認模塊接收到的DHCP-REQUEST報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息和該客戶端所接受的IP地址； 所述地址分配確認模塊生成的DHCP-ACK報文中，每個DHCP客戶端的客戶端信息中，至少包括DHCP客戶端的硬件地址信息和針對該客戶端的IP地址確認信息。
全文摘要
本發(fā)明公開了一種DHCP地址分配方法及裝置，通過DHCP中繼將接收到的多個DHCP請求報文處理成包含相應(yīng)多個客戶端信息的DHCP請求報文并單播發(fā)送給DHCP服務(wù)器，以觸發(fā)DHCP服務(wù)器為多個客戶端分配IP地址，以及在接收到DHCP服務(wù)器返回的攜帶有多個客戶端信息的DHCP響應(yīng)報文后，生成相應(yīng)數(shù)量的DHCP響應(yīng)報文并分別發(fā)送給相應(yīng)客戶端，從而一次代理多個客戶端向DHCP服務(wù)器請求IP地址，與現(xiàn)有技術(shù)相比，減少了DHCP中繼和DHCP服務(wù)器之間交互的報文數(shù)量，進而緩解DHCP中繼與DHCP服務(wù)器之間的報文交互壓力。
文檔編號H04L29/12GK102769678SQ201210254638
公開日2012年11月7日 申請日期2012年7月23日 優(yōu)先權(quán)日2012年7月23日
發(fā)明者邱秀梅, 馬臻 申請人:杭州華三通信技術(shù)有限公司