词条 | Dynamic Host Configuration Protocol | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
释义 |
The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on UDP/IP networks whereby a DHCP server dynamically assigns an IP address and other network configuration parameters to each device on a network so they can communicate with other IP networks.[1] A DHCP server enables computers to request IP addresses and networking parameters automatically from the Internet service provider (ISP), reducing the need for a network administrator or a user to manually assign IP addresses to all network devices.[1] In the absence of a DHCP server, a computer or other device on the network needs to be manually assigned an IP address, or to assign itself an APIPA address, which will not enable it to communicate outside its local subnet. DHCP can be implemented on networks ranging in size from home networks to large campus networks and regional Internet service provider networks.[2] A router or a residential gateway can be enabled to act as a DHCP server. Most residential network routers receive a globally unique IP address within the ISP network. Within a local network, a DHCP server assigns a local IP address to each device connected to the network. {{Anchor|LEASE}}OverviewUDP/IP defines how devices on one network communicate with devices on another network, and the DHCP server can manage UDP/IP settings for devices on a network, by automatically or dynamically assigning IP addresses to the devices. The DHCP operates based on the client–server model. When a computer or other device connects to a network, the DHCP client software sends a DHCP broadcast query requesting the necessary information. Any DHCP server on the network may service the request. The DHCP server manages a pool of IP addresses and information about client configuration parameters such as default gateway, domain name, the name servers, and time servers. On receiving a DHCP request, the DHCP server may respond with specific information for each client, as previously configured by an administrator, or with a specific address and any other information valid for the entire network and for the time period for which the allocation (lease) is valid. A DHCP client typically queries for this information immediately after booting, and periodically thereafter before the expiration of the information. When a DHCP client refreshes an assignment, it initially requests the same parameter values, but the DHCP server may assign a new address based on the assignment policies set by administrators. On large networks that consist of multiple links, a single DHCP server may service the entire network when aided by DHCP relay agents located on the interconnecting routers. Such agents relay messages between DHCP clients and DHCP servers located on different subnets. Depending on implementation, the DHCP server may have three methods of allocating IP addresses:
DHCP is used for Internet Protocol version 4 (IPv4) and IPv6. While both versions serve the same purpose, the details of the protocol for IPv4 and IPv6 differ sufficiently that they may be considered separate protocols.[3] For the IPv6 operation, devices may alternatively use stateless address autoconfiguration. IPv6 hosts may also use link-local addressing to achieve operations restricted to the local network link. OperationThe DHCP employs a connectionless service model, using the User Datagram Protocol (UDP). It is implemented with two UDP port numbers for its operations which are the same as for the bootstrap protocol (BOOTP). UDP port number 67 is the destination port of a server, and UDP port number 68 is used by the client. DHCP operations fall into four phases: server discovery, IP lease offer, IP lease request, and IP lease acknowledgement. These stages are often abbreviated as DORA for discovery, offer, request, and acknowledgement. The DHCP operation begins with clients broadcasting a request. If the client and server are on different subnets, a DHCP Helper or DHCP Relay Agent may be used. Clients requesting renewal of an existing lease may communicate directly via UDP unicast, since the client already has an established IP address at that point. Additionally, there is a BROADCAST flag (1 bit in 2 byte flags field, where all other bits are reserved and so are set to 0) the client can use to indicate in which way (broadcast or unicast) it can receive the DHCPOFFER: 0x8000 for broadcast, 0x0000 for unicast.[4] Usually, the DHCPOFFER is sent through unicast. For those hosts which cannot accept unicast packets before IP addresses are configured, this flag can be used to work around this issue. DHCP discoveryThe DHCP client broadcasts a DHCPDISCOVER message on the network subnet using the destination address 255.255.255.255 (limited broadcast) or the specific subnet broadcast address (directed broadcast). A DHCP client may also request its last known IP address. If the client remains connected to the same network, the server may grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server denies the request, causing the client to issue a new request. A non-authoritative server simply ignores the request, leading to an implementation-dependent timeout for the client to expire the request and ask for a new IP address. For example, if HTYPE is set to 1, to specify that the medium used is Ethernet, HLEN is set to 6 because an Ethernet address (MAC address) is 6 octets long. The CHADDR is set to the MAC address used by the client. Some options are set as well.
DHCP offerWhen a DHCP server receives a DHCPDISCOVER message from a client, which is an IP address lease request, the DHCP server reserves an IP address for the client and makes a lease offer by sending a DHCPOFFER message to the client. This message contains the client's client id (traditionally a MAC address), the IP address that the server is offering, the subnet mask, the lease duration, and the IP address of the DHCP server making the offer. The DHCP server may also take notice of the hardware-level MAC address in the underlying transport layer: according to current RFCs the transport layer MAC address may be used if no client ID is provided in the DHCP packet. The DHCP server determines the configuration based on the client's hardware address as specified in the CHADDR (client hardware address) field. Here the server, 192.168.1.1, specifies the client's IP address in the YIADDR (your IP address) field.
DHCP requestIn response to the DHCP offer, the client replies with a DHCPREQUEST message, broadcast to the server,{{Efn|name="optional-unicasts"|As an optional client behavior, some broadcasts, such as those carrying DHCP discovery and request messages, may be replaced with unicasts in case the DHCP client already knows the DHCP server's IP address.[5]}} requesting the offered address. A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer. Based on required server identification option in the request and broadcast messaging, servers are informed whose offer the client has accepted.[6]{{rp|Section 3.1, Item 3}} When other DHCP servers receive this message, they withdraw any offers that they have made to the client and return the offered IP address to the pool of available addresses.
DHCP acknowledgementWhen the DHCP server receives the DHCPREQUEST message from the client, the configuration process enters its final phase. The acknowledgement phase involves sending a DHCPACK packet to the client. This packet includes the lease duration and any other configuration information that the client might have requested. At this point, the IP configuration process is completed. The protocol expects the DHCP client to configure its network interface with the negotiated parameters. After the client obtains an IP address, it should probe the newly received address[7] (e.g. with ARP Address Resolution Protocol) to prevent address conflicts caused by overlapping address pools of DHCP servers.
DHCP informationA DHCP client may request more information than the server sent with the original DHCPOFFER. The client may also request repeat data for a particular application. For example, browsers use DHCP Inform to obtain web proxy settings via {{abbr|WPAD|Web Proxy Autodiscovery Protocol}}. DHCP releasingThe client sends a request to the DHCP server to release the DHCP information and the client deactivates its IP address. As client devices usually do not know when users may unplug them from the network, the protocol does not mandate the sending of DHCP Release. Client configuration parametersA DHCP server can provide optional configuration parameters to the client. RFC 2132 describes the available DHCP options defined by Internet Assigned Numbers Authority (IANA) - DHCP and BOOTP PARAMETERS.[8] A DHCP client can select, manipulate and overwrite parameters provided by a DHCP server. In Unix-like systems this client-level refinement typically takes place according to the values in the configuration file /etc/dhclient.conf. DHCP optionsOptions are octet strings of varying length. The first octet is the option code, the second octet is the number of following octets and the remaining octets are code dependent. For example, the DHCP message-type option for an offer would appear as 0x35, 0x01, 0x02, where 0x35 is code 53 for "DHCP message type", 0x01 means one octet follows and 0x02 is the value of "offer". Documented in RFC 2132The following tables list the available DHCP options, as listed in RFC 2132[9] and IANA registry.[8]
DHCP client vendor identificationAn option exists to identify the vendor and functionality of a DHCP client. The information is a variable-length string of characters or octets which has a meaning specified by the vendor of the DHCP client. One method that a DHCP client can utilize to communicate to the server that it is using a certain type of hardware or firmware is to set a value in its DHCP requests called the Vendor Class Identifier (VCI) (Option 60). This method allows a DHCP server to differentiate between the two kinds of client machines and process the requests from the two types of modems appropriately. Some types of set-top boxes also set the VCI (Option 60) to inform the DHCP server about the hardware type and functionality of the device. The value this option is set to gives the DHCP server a hint about any required extra information that this client needs in a DHCP response. Documented elsewhere
Relay agent information sub-optionsThe relay agent information option (option 82)[10] specifies container for attaching sub-options to DHCP requests transmitted between a DHCP relay and a DHCP server.
DHCP relayingIn small networks, where only one IP subnet is being managed, DHCP clients communicate directly with DHCP servers. However, DHCP servers can also provide IP addresses for multiple subnets. In this case, a DHCP client that has not yet acquired an IP address cannot communicate directly with the DHCP server using IP routing, because it does not have a routable IP address, does not know the link layer address of a router and does not know the IP address of the DHCP server. In order to allow DHCP clients on subnets not directly served by DHCP servers to communicate with DHCP servers, DHCP relay agents can be installed on these subnets. The DHCP client broadcasts on the local link; the relay agent receives the broadcast and transmits it to one or more DHCP servers using unicast. The relay agent stores its own IP address in field GIADDR field of the DHCP packet. The DHCP server uses the GIADDR-value to determine the subnet on which the relay agent received the broadcast, and allocates an IP address on that subnet. When the DHCP server replies to the client, it sends the reply to the GIADDR-address, again using unicast. The relay agent then retransmits the response on the local network. In this situation, the communication between the relay agent and the DHCP server typically uses both a source and destination UDP port of 67. ReliabilityThe DHCP ensures reliability in several ways: periodic renewal, rebinding,[6]{{rp|Section 4.4.5}} and failover. DHCP clients are allocated leases that last for some period of time. Clients begin to attempt to renew their leases once half the lease interval has expired.[6]{{rp|Section 4.4.5 Paragraph 3}} They do this by sending a unicast DHCPREQUEST message to the DHCP server that granted the original lease. If that server is down or unreachable, it will fail to respond to the DHCPREQUEST. However, in that case the client repeats the DHCPREQUEST from time to time,[6]{{rp|Section 4.4.5 Paragraph 8}}{{Efn|The RFC calls for the client to wait one half of the remaining time until T2 before it retransmits the DHCPREQUEST packet}} so if the DHCP server comes back up or becomes reachable again, the DHCP client will succeed in contacting it and renew the lease. If the DHCP server is unreachable for an extended period of time,[6]{{rp|Section 4.4.5 Paragraph 5}} the DHCP client will attempt to rebind, by broadcasting its DHCPREQUEST rather than unicasting it. Because it is broadcast, the DHCPREQUEST message will reach all available DHCP servers. If some other DHCP server is able to renew the lease, it will do so at this time. In order for rebinding to work, when the client successfully contacts a backup DHCP server, that server must have accurate information about the client's binding. Maintaining accurate binding information between two servers is a complicated problem; if both servers are able to update the same lease database, there must be a mechanism to avoid conflicts between updates on the independent servers. A proposal for implementing fault-tolerant DHCP servers was submitted to the Internet Engineering Task Force, but never formalized.[16]{{Efn|The proposal provided a mechanism whereby two servers could remain loosely in sync with each other in such a way that even in the event of a total failure of one server, the other server could recover the lease database and continue operating. Due to the length and complexity of the specification, it was never published as a standard; however, the techniques described in the specification are in wide use, with one open-source implementation in the ISC DHCP server, as well as several commercial implementations.}} If rebinding fails, the lease will eventually expire. When the lease expires, the client must stop using the IP address granted to it in its lease.[6]{{rp|Section 4.4.5 Paragraph 9}} At that time it will restart the DHCP process from the beginning by broadcasting a Security{{see also|DHCP snooping}}The base DHCP does not include any mechanism for authentication.[17] Because of this, it is vulnerable to a variety of attacks. These attacks fall into three main categories:
Because the client has no way to validate the identity of a DHCP server, unauthorized DHCP servers (commonly called "rogue DHCP") can be operated on networks, providing incorrect information to DHCP clients.[43] This can serve either as a denial-of-service attack, preventing the client from gaining access to network connectivity,[19] or as a man-in-the-middle attack.[20] Because the DHCP server provides the DHCP client with server IP addresses, such as the IP address of one or more DNS servers,[18] an attacker can convince a DHCP client to do its DNS lookups through its own DNS server, and can therefore provide its own answers to DNS queries from the client.[21][22] This in turn allows the attacker to redirect network traffic through itself, allowing it to eavesdrop on connections between the client and network servers it contacts, or to simply replace those network servers with its own.[21] Because the DHCP server has no secure mechanism for authenticating the client, clients can gain unauthorized access to IP addresses by presenting credentials, such as client identifiers, that belong to other DHCP clients.[43] This also allows DHCP clients to exhaust the DHCP server's store of IP addresses—by presenting new credentials each time it asks for an address, the client can consume all the available IP addresses on a particular network link, preventing other DHCP clients from getting service.[23] DHCP does provide some mechanisms for mitigating these problems. The Relay Agent Information Option protocol extension (RFC 3046, usually referred to in the industry by its actual number as Option 82[24][25]) allows network operators to attach tags to DHCP messages as these messages arrive on the network operator's trusted network. This tag is then used as an authorization token to control the client's access to network resources. Because the client has no access to the network upstream of the relay agent, the lack of authentication does not prevent the DHCP server operator from relying on the authorization token.[17] Another extension, Authentication for DHCP Messages ([https://tools.ietf.org/html/rfc3118 RFC 3118]), provides a mechanism for authenticating DHCP messages. As of 2002, RFC 3118 had not seen widespread adoption because of the problems of managing keys for large numbers of DHCP clients.[26] A 2007 book about DSL technologies remarked that: there were numerous security vulnerabilities identified against the security measures proposed by RFC 3118. This fact, combined with the introduction of 802.1x, slowed the deployment and take-rate of authenticated DHCP, and it has never been widely deployed.[27]A 2010 book notes that: [t]here have been very few implementations of DHCP Authentication. The challenges of key management and processing delays due to hash computation have been deemed too heavy a price to pay for the perceived benefits.[28] Architectural proposals from 2008 involve authenticating DHCP requests using 802.1x or PANA (both of which transport EAP).[29] An IETF proposal was made for including EAP in DHCP itself, the so-called EAPoDHCP;[30] this does not appear to have progressed beyond IETF draft level, the last of which dates to 2010.[31] IETF standards documents
See also{{Portal|Computer networking}}{{Div col|colwidth=25em}}
Notes{{Notelist|30em}}References1. ^1 TechTarget Network: DHCP (Dynamic Host Configuration Protocol) {{commons category|Dynamic Host Configuration Protocol (DHCP)}}{{Z148}}{{Authority control}}2. ^{{cite book |last1=Peterson |first1=Larry L. |last2=Davie |first2=Bruce S. |date=2011 |url=https://books.google.com/books?id=BvaFreun1W8C&pg=PA372&lpg=PA372 |title=Computer Networks: A Systems Approach |publisher=Elsevier |isbn=0123850606 |edition=5th |accessdate=March 21, 2019}} 3. ^{{cite book |title = The DHCP Handbook |year = 2003 |isbn = 978-0-672-32327-0 |first1= Ralph |last1=Droms |first2= Ted |last2=Lemon |publisher = SAMS Publishing |page = 436 }} 4. ^1 {{cite web|url=https://tools.ietf.org/html/rfc2131#section-4.1|title=Dynamic Host Configuration Protocol|first=Ralph|last=Droms|website=tools.ietf.org|accessdate=4 July 2017}} 5. ^{{cite web|url=https://tools.ietf.org/html/rfc2131#section-4.4.4|title=Dynamic Host Configuration Protocol|first=Ralph|last=Droms|website=tools.ietf.org|accessdate=4 July 2017}} 6. ^1 2 3 4 5 {{cite IETF| title = DHCP Options and BOOTP Vendor Extensions| rfc = 2131| last1 = Droms| first1 = Ralph|date=March 1997 | publisher = IETF| accessdate = September 9, 2014}} 7. ^{{cite web |title=RFC2131 Dynamic Host Configuration Protocol: Dynamic allocation of network addresses |url=http://tools.ietf.org/html/rfc2131#section-2.2 |website=tools.ietf.org}} 8. ^1 {{cite web|url=https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml|title=Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters|last=|first=|date=|website=|publisher=iana.org|archive-url=|archive-date=|dead-url=|accessdate=2018-10-16}} 9. ^1 2 3 4 5 6 7 8 9 10 {{cite IETF| title = DHCP options and BOOTP vendor extensions| rfc = 2132| last1 = Alexander| first1 = Steve| last2 = Droms| first2 = Ralph|date=March 1997| publisher = IETF| accessdate = June 10, 2012| doi = 10.17487/RFC2132}} 10. ^1 {{cite journal|last1=Patrick|first1=Michael|title=DHCP Relay Agent Information Option|url=https://tools.ietf.org/html/rfc3046|website=IETF Documents|publisher=IETF|accessdate=22 July 2017|doi=10.17487/RFC3046|date=January 2001}} 11. ^1 2 {{cite journal|last1=Provan|first1=Don|title=RFC 2241 – DHCP Options for Novell Directory Services|url=https://tools.ietf.org/html/rfc2241|website=IETF Documents|publisher=IETF|accessdate=23 July 2017|doi=10.17487/RFC3256|date=November 1997}} 12. ^1 {{cite web|last1=Lear|first1=E.|last2=Eggert|first2=P.|title=Timezone Options for DHCP|url=https://tools.ietf.org/html/rfc4833|website=IETF Documents|publisher=IETF|date=April 2007|accessdate=28 June 2018}} 13. ^{{cite journal|doi=10.17487/RFC3397|last1=Bernard|first1=Aboba|last2=Stuart|first2=Cheshire|title=RFC 3397 – Dynamic Host Configuration Protocol (DHCP) Domain Search Option|url=https://tools.ietf.org/html/rfc3397|website=IETF Documents|publisher=IETF|date=November 2002|accessdate=22 July 2017}} 14. ^[https://tools.ietf.org/html/rfc3442 RFC 3442] 15. ^{{cite journal|last1=Doug|first1=Jones|last2=Rich|first2=Woundy|title=RFC 3256 – The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option|url=https://tools.ietf.org/html/rfc3256|website=IETF Documents|publisher=IETF|accessdate=23 July 2017|doi=10.17487/RFC3256|date=April 2002}} 16. ^{{cite IETF| title = DHCP Failover Protocol| draft = draft-ietf-dhc-failover-12| last1 = Droms | first1 = Ralph| last2 = Kinnear | first2 = Kim| last3 = Stapp | first3 = Mark| last4 = Volz | first4 = Bernie| last5 = Gonczi | first5 = Steve| last6 = Rabil | first6 = Greg| last7 = Dooley | first7 = Michael| last8 = Kapur | first8 = Arun| date = March 2003| publisher = IETF| accessdate = May 9, 2010}} 17. ^1 {{cite web |url = http://tools.ietf.org/html/rfc3046#section-7 |title = RFC 3046 - DHCP Relay Agent Information Option |first= Michael |last=Patrick |date = January 2001 |work = Network Working Group }} 18. ^1 2 3 {{cite web |url = http://tools.ietf.org/html/rfc2131#section-7 |title = RFC 2131 - Dynamic Host Configuration Protocol |first= Ralph |last=Droms |date = March 1997 |work = Network Working Group }} 19. ^{{cite book |first= Derrick |last=Rountree |title = Windows 2012 Server Network Security: Securing Your Windows Network Systems and Infrastructure |url = https://books.google.com/books?id=NFzou_d4MGUC&pg=SA2-PA13 |year = 2013 |publisher = Newnes |isbn = 978-1-59749-965-1 |page = 22 }} 20. ^{{cite book |first= Timothy |last=Rooney |title = Introduction to IP Address Management |url = https://books.google.com/books?id=QgRDxkuI1MkC&pg=PA180 |year = 2010 |publisher = John Wiley & Sons |isbn = 978-1-118-07380-3 |page = 180 }} 21. ^1 {{cite web |url = http://www.securelist.com/en/blog/208188095/TDSS_loader_now_got_legs |title = TDSS loader now got "legs" |first= Sergey |last=Golovanov (Kaspersky Labs) |date = June 2011 }} 22. ^{{cite web |url = http://greyhatsspeak.blogspot.com/2015/11/dhcp-protocol-and-its-vulnerabilities.html |title = dhcp protocol and its vulnerabilities |first= Akash K |last=Sunny |date = October 2015 }} 23. ^1 2 {{cite book |first= Timothy |last=Stapko |title = Practical Embedded Security: Building Secure Resource-Constrained Systems |url = https://books.google.com/books?id=Mly55VntuYMC&pg=PA39 |year = 2011 |publisher = Newnes |isbn = 978-0-08-055131-9 |page = 39 }} 24. ^{{cite book |first1 = Francisco J. |last1=Hens |first2 = José M. |last2=Caballero |title = Triple Play: Building the converged network for IP, VoIP and IPTV |url = https://books.google.com/books?id=aS1ZngveBIkC&pg=PA239 |year = 2008 |publisher = John Wiley & Sons |isbn = 978-0-470-75439-9 |page = 239 }} 25. ^{{cite book |first= David H. |last=Ramirez |title = IPTV Security: Protecting High-Value Digital Contents |url = https://books.google.com/books?id=70tr_hSDULwC&pg=PA55 |year = 2008 |publisher = John Wiley & Sons |isbn = 978-0-470-72719-5 |page = 55 }} 26. ^{{cite web |url = http://www.ietf.org/mail-archive/web/dhcwg/current/msg00876.html |title = Implementation of RFC 3118 |first= Ted |last=Lemon |date = April 2002 }} 27. ^{{cite book |first1 = Philip |last1=Golden |first2 = Hervé |last2=Dedieu |first3 = Krista S. |last3=Jacobsen |title = Implementation and Applications of DSL Technology |url = https://books.google.com/books?id=Jjkd74jY47oC&pg=PA484 |year = 2007 |publisher = Taylor & Francis |isbn = 978-1-4200-1307-8 |page = 484 }} 28. ^{{cite book |first= Timothy |last=Rooney |title = Introduction to IP Address Management |url = https://books.google.com/books?id=QgRDxkuI1MkC&pg=PA181 |year = 2010 |publisher = John Wiley & Sons |isbn = 978-1-118-07380-3 |pages = 181–182 }} 29. ^{{cite book |first= Rebecca |last=Copeland |title = Converging NGN Wireline and Mobile 3G Networks with IMS |url = https://books.google.com/books?id=ruWv8RGkBGgC&pg=PA142 |year = 2008 |publisher = Taylor & Francis |isbn = 978-1-4200-1378-8 |pages = 142–143 }} 30. ^{{cite book |first1 = Ramjee |last1=Prasad |first2 = Albena |last2=Mihovska |title = New Horizons in Mobile and Wireless Communications: Networks, services, and applications |url = https://books.google.com/books?id=w9bEwBwd33MC&pg=PA339 |year = 2009 |publisher = Artech House |isbn = 978-1-60783-970-5 |page = 339 |volume = 2 }} 31. ^{{cite web |url=http://tools.ietf.org/search/draft-pruss-dhcp-auth-dsl-07 |title=Archived copy |accessdate=2013-12-12 |deadurl=yes |archiveurl=https://web.archive.org/web/20150403091552/http://tools.ietf.org/search/draft-pruss-dhcp-auth-dsl-07 |archivedate=2015-04-03 }} 3 : Internet Standards|Application layer protocols|Network service |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
随便看 |
|
开放百科全书收录14589846条英语、德语、日语等多语种百科知识,基本涵盖了大多数领域的百科知识,是一部内容自由、开放的电子版国际百科全书。