rfc2983.Differentiated Services and Tunnels

IPSec 中文RFCNetwork Working Group D. Harkins Request for Comments: 2409 D. Carrel Category: Standards Track cisco SystemsNovember 1998Internet密钥交换（IKE）（The Internet Key Exchange）本备忘录的现状本文档指定了一个Internet 团体的Internet标准协议，并请求讨论和建议以作改进。

请参考当前版本的“Internet官方协议标准”（STD 1），查看本协议的标准化进程和现状。

本文档的分发不受限制。

版权通告Copyright (C) The Internet Society (1998)。

保留所有的权利。

目录1.摘要 22.讨论 23.术语和定义 33.1必要的术语 33.2符号 33.3完全后继保密 43.4安全联盟 44.简介 55.交换 65.1 使用签名来验证的IKE第一阶段85.2 使用公共密钥加密的第一阶段验证85.3 使用修改过的公钥加密模式来进行第一阶段的验证105.4 使用共享密钥的第一阶段协商115.5 第二阶段——快速模式125.6 新组模式145.7 ISAKMP信息交换156 Oakley组156.1 第一个Oakley缺省组156.2 第二个Oakley组166.3 第三个Oakley组166.4 第四个Oakley组167. 完整IKE交换的负载爆炸177.1 使用主模式的第一阶段177.2 使用快速模式的第二阶段188. 完全后继保密举例2010.安全考虑2111.IANA考虑2211.1 属性类2211.2 加密算法类2211.3 hash算法2211.4 组描述和组类型2311.5 存活期类型2312. 鸣谢2313.参考23附录A 25属性分配号码25属性种类26种类值26附录B 28作者地址30作者的注释30完全版权声明311.摘要ISAKMP ([MSST98])中对验证和密钥交换提出了结构框架，但没有具体定义。

Huawei USG6330/6350/6360 next-generation firewalls are security gateways designed for small- and medium-sized businesses and branch offices with 200 to 800 users. The firewalls provide VPN, intrusion prevention, and antivirus functions for comprehensive and integrated network protection, effectively reducing management costs. Refined bandwidth management improves bandwidth efficiency and ensures quality experiences for key services. These firewalls provide continuous next-generation network security in an easy and efficient way.HighlightsComprehensive and integrated protection• Multiple security functions, including firewall, VPN, intrusion prevention, and online behavior management,for complete versatility• Refined bandwidth management based on application and website category to prioritize bandwidth formission-critical services• Detection and prevention of unknown threats, such as zero-day attacks, using sandboxing and thereputation system*Simple management and rapid deployment• Zero-configuration deployment using USB disks to improve deployment efficiency• Predefined common-scenario defense templates to facilitate security policy deployment • Intelligent detection of redundant and invalid policies• Supports cloud-based management and enables Huawei Agile Controller-Cloud Manager to manage andconfigure the firewalls Flexible bandwidth management, improving Internet access experience•Differentiated user bandwidth and quota management for fair and prioritized bandwidth usageHUAWEI USG6330/6350/6360 Next-Generation Firewalls---Securely and Reliably Connect Small- and Medium-Sized Businesses• Application-based bandwidth management to prioritize bandwidth for mission-critical applications• Modification of URL category priorityDeploymentSecure interconnections between enterprise branches• Inspect services in six dimensions (application, user, content, threat, time, and location) and provide refined service access control at the Internet egress.• Establish IPsec or L2TP over IPsec permanent tunnels for branches and partners with fixed VPN gateways (L2TP over IPsec tunnel is recommended if account authentication is required).• Provide SSL VPN for remote access of people on the move and implement fine-grained control over the resources accessible to users.• Authenticate VPN tunnel users to ensure they are legitimate and authorized.• Enable intrusion prevention, antivirus, file blocking, and data filtering functions to prevent remote access users from introducing network threats or leaking information.HardwareUSG6330/6350/6360Interfaces1. USB Port2. Console Port3. 1 x GE (RJ45) Management Port4. 4 x GE (RJ45) Ports5. 2 x GE (Combo) PortsTable 1. Wide Service Interface Cards (WSICs) for USG6300 SeriesSoftware Features1: I f no hard disk is inserted, you can view and export system and service logs. By inserting a hard disk, you can also view, export, customize, and subscribe to reports.Functions marked with * are supported only in USG V500R001 and later versions.Specifications *System Performance and Capacity1. P erformance is tested under ideal conditions based on RFC 2544 and RFC 3511. The actual result may vary with deployment environments.2. Antivirus, IPS, and SA performances are measured using 100 KB of HTTP files.3. Throughput is measured with the Enterprise Traffic Model.4. SSL inspection throughput is measured with IPS-enabled and HTTPS traffic using TLS v1.2 with AES256-SHA.5. SSL VPN throughput is measured using TLS v1.2 with AES128-SHA.6. USG6000 V100R001 supports only the RESTCONF interface and cannot interwork with sandbox or third-party tools.* SA indicates Service Awareness.* This content is applicable only to regions outside mainland China. Huawei reserves the right to interpret this content. Hardware Specifications*WISC is not hot-swappable.CertificationsRegulatory, Safety, and EMC ComplianceOrdering GuideAbout This PublicationThis publication is for reference only and does not constitute any commitments or guarantees. All trademarks, pictures, logos, and brands mentioned in this document are the property of Huawei Technologies Co., Ltd. or a third party.For more information, visit /en/products/enterprise-networking/security.Copyright©2018 Huawei Technologies Co., Ltd. All rights reserved.。

Network Working Group S. Bradner Request for Comments: 2544 Harvard University Obsoletes: 1944 J. McQuaid Category: Informational NetScout Systems March 1999 Benchmarking Methodology for Network Interconnect DevicesStatus of this MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The Internet Society (1999). All Rights Reserved.IESG NoteThis document is a republication of RFC 1944 correcting the valuesfor the IP addresses which were assigned to be used as the defaultaddresses for networking test equipment. (See section C.2.2 ). This RFC replaces and obsoletes RFC 1944.AbstractThis document discusses and defines a number of tests that may beused to describe the performance characteristics of a networkinterconnecting device. In addition to defining the tests thisdocument also describes specific formats for reporting the results of the tests. Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additionalinformation about testing practices. Appendix B is a referencelisting of maximum frame rates to be used with specific frame sizeson various media and Appendix C gives some examples of frame formats to be used in testing.1. IntroductionVendors often engage in "specsmanship" in an attempt to give theirproducts a better position in the marketplace. This often involves"smoke & mirrors" to confuse the potential users of the products. Bradner & McQuaid Informational [Page 1]This document defines a specific set of tests that vendors can use to measure and report the performance characteristics of networkdevices. The results of these tests will provide the user comparable data from different vendors with which to evaluate these devices.A previous document, "Benchmarking Terminology for NetworkInterconnect Devices" (RFC 1242), defined many of the terms that are used in this document. The terminology document should be consulted before attempting to make use of this document.2. Real worldIn producing this document the authors attempted to keep in mind the requirement that apparatus to perform the described tests mustactually be built. We do not know of "off the shelf" equipmentavailable to implement all of the tests but it is our opinion thatsuch equipment can be constructed.3. Tests to be runThere are a number of tests described in this document. Not all ofthe tests apply to all types of devices under test (DUTs). Vendorsshould perform all of the tests that can be supported by a specifictype of product. The authors understand that it will take aconsiderable period of time to perform all of the recommended testsnder all of the recommended conditions. We believe that the results are worth the effort. Appendix A lists some of the tests andconditions that we believe should be included for specific cases.4. Evaluating the resultsPerforming all of the recommended tests will result in a great dealof data. Much of this data will not apply to the evaluation of thedevices under each circumstance. For example, the rate at which arouter forwards IPX frames will be of little use in selecting arouter for an environment that does not (and will not) support thatprotocol. Evaluating even that data which is relevant to aparticular network installation will require experience which may not be readily available. Furthermore, selection of the tests to be runand evaluation of the test data must be done with an understanding of generally accepted testing practices regarding repeatability,variance and statistical significance of small numbers of trials. Bradner & McQuaid Informational [Page 2]5. RequirementsIn this document, the words that are used to define the significance of each particular requirement are capitalized. These words are:* "MUST" This word, or the words "REQUIRED" and "SHALL" mean that the item is an absolute requirement of the specification.* "SHOULD" This word or the adjective "RECOMMENDED" means thatthere may exist valid reasons in particular circumstances toignore this item, but the full implications should beunderstood and the case carefully weighed before choosing adifferent course.* "MAY" This word or the adjective "OPTIONAL" means that thisitem is truly optional. One vendor may choose to include theitem because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements. Animplementation that satisfies all the MUST and all the SHOULDrequirements for its protocols is said to be "unconditionallycompliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be"conditionally compliant".6. Test set upThe ideal way to implement this series of tests is to use a testerwith both transmitting and receiving ports. Connections are madefrom the sending ports of the tester to the receiving ports of theDUT and from the sending ports of the DUT back to the tester. (seeFigure 1) Since the tester both sends the test traffic and receives it back, after the traffic has been forwarded but the DUT, the tester can easily determine if all of the transmitted packets were received and verify that the correct packets were received. The samefunctionality can be obtained with separate transmitting andreceiving devices (see Figure 2) but unless they are remotelycontrolled by some computer in a way that simulates the singletester, the labor required to accurately perform some of the tests(particularly the throughput test) can be prohibitive.Bradner & McQuaid Informational [Page 3]+------------+| |+------------| tester |<-------------+| | | || +------------+ || || +------------+ || | | |+----------->| DUT |--------------+| |+------------+Figure 1+--------+ +------------+ +----------+| | | | | || sender |-------->| DUT |--------->| receiver || | | | | |+--------+ +------------+ +----------+Figure 26.1 Test set up for multiple media typesTwo different setups could be used to test a DUT which is used inreal-world networks to connect networks of differing media type,local Ethernet to a backbone FDDI ring for example. The tester could support both media types in which case the set up shown in Figure 1would be used.Two identical DUTs are used in the other test set up. (see Figure 3) In many cases this set up may more accurately simulate the realworld. For example, connecting two LANs together with a WAN link or high speed backbone. This set up would not be as good at simulating a system where clients on a Ethernet LAN were interacting with aserver on an FDDI backbone.+-----------+| |+---------------------| tester |<---------------------+| | | || +-----------+ || || +----------+ +----------+ || | | | | |+------->| DUT 1 |-------------->| DUT 2 |---------+| | | |+----------+ +----------+Figure 3Bradner & McQuaid Informational [Page 4]7. DUT set upBefore starting to perform the tests, the DUT to be tested MUST beconfigured following the instructions provided to the user.Specifically, it is expected that all of the supported protocols will be configured and enabled during this set up (See Appendix A). It is expected that all of the tests will be run without changing theconfiguration or setup of the DUT in any way other than that required to do the specific test. For example, it is not acceptable to change the size of frame handling buffers between tests of frame handlingrates or to disable all but one transport protocol when testing thethroughput of that protocol. It is necessary to modify theconfiguration when starting a test to determine the effect of filters on throughput, but the only change MUST be to enable the specificfilter. The DUT set up SHOULD include the normally recommendedrouting update intervals and keep alive frequency. The specificversion of the software and the exact DUT configuration, includingwhat functions are disabled, used during the tests MUST be includedas part of the report of the results.8. Frame formatsThe formats of the test frames to use for TCP/IP over Ethernet areshown in Appendix C: Test Frame Formats. These exact frame formatsSHOULD be used in the tests described in this document for thisprotocol/media combination and that these frames will be used as atemplate for testing other protocol/media combinations. The specific formats that are used to define the test frames for a particular test series MUST be included in the report of the results.9. Frame sizesAll of the described tests SHOULD be performed at a number of framesizes. Specifically, the sizes SHOULD include the maximum and minimum legitimate sizes for the protocol under test on the media under test and enough sizes in between to be able to get a full characterization of the DUT performance. Except where noted, at least five framesizes SHOULD be tested for each test condition.Theoretically the minimum size UDP Echo request frame would consistof an IP header (minimum length 20 octets), a UDP header (8 octets)and whatever MAC level header is required by the media in use. Thetheoretical maximum frame size is determined by the size of thelength field in the IP header. In almost all cases the actualmaximum and minimum sizes are determined by the limitations of themedia.Bradner & McQuaid Informational [Page 5]In theory it would be ideal to distribute the frame sizes in a waythat would evenly distribute the theoretical frame rates. Theserecommendations incorporate this theory but specify frame sizes which are easy to understand and remember. In addition, many of the sameframe sizes are specified on each of the media types to allow foreasy performance comparisons.Note: The inclusion of an unrealistically small frame size on some of the media types (i.e. with little or no space for data) is to helpcharacterize the per-frame processing overhead of the DUT.9.1 Frame sizes to be used on Ethernet64, 128, 256, 512, 1024, 1280, 1518These sizes include the maximum and minimum frame sizes permitted by the Ethernet standard and a selection of sizes between these extremes with a finer granularity for the smaller frame sizes and higher frame rates.9.2 Frame sizes to be used on 4Mb and 16Mb token ring54, 64, 128, 256, 1024, 1518, 2048, 4472The frame size recommendations for token ring assume that there is no RIF field in the frames of routed protocols. A RIF field would bepresent in any direct source route bridge performance test. Theminimum size frame for UDP on token ring is 54 octets. The maximumsize of 4472 octets is recommended for 16Mb token ring instead of the theoretical size of 17.9Kb because of the size limitations imposed by many token ring interfaces. The reminder of the sizes are selectedto permit direct comparisons with other types of media. An IP (i.e. not UDP) frame may be used in addition if a higher data rate isdesired, in which case the minimum frame size is 46 octets.9.3 Frame sizes to be used on FDDI54, 64, 128, 256, 1024, 1518, 2048, 4472The minimum size frame for UDP on FDDI is 53 octets, the minimum size of 54 is recommended to allow direct comparison to token ringperformance. The maximum size of 4472 is recommended instead of the theoretical maximum size of 4500 octets to permit the same type ofcomparison. An IP (i.e. not UDP) frame may be used in addition if ahigher data rate is desired, in which case the minimum frame size is 45 octets.Bradner & McQuaid Informational [Page 6]9.4 Frame sizes in the presence of disparate MTUsWhen the interconnect DUT supports connecting links with disparateMTUs, the frame sizes for the link with the *larger* MTU SHOULD beused, up to the limit of the protocol being tested. If theinterconnect DUT does not support the fragmenting of frames in thepresence of MTU mismatch, the forwarding rate for that frame sizeshall be reported as zero.For example, the test of IP forwarding with a bridge or router thatjoins FDDI and Ethernet should use the frame sizes of FDDI when going from the FDDI to the Ethernet link. If the bridge does not support IP fragmentation, the forwarding rate for those frames too large forEthernet should be reported as zero.10. Verifying received framesThe test equipment SHOULD discard any frames received during a testrun that are not actual forwarded test frames. For example, keep-alive and routing update frames SHOULD NOT be included in the countof received frames. In any case, the test equipment SHOULD verifythe length of the received frames and check that they match theexpected length.Preferably, the test equipment SHOULD include sequence numbers in the transmitted frames and check for these numbers on the receivedframes. If this is done, the reported results SHOULD include inaddition to the number of frames dropped, the number of frames thatwere received out of order, the number of duplicate frames receivedand the number of gaps in the received frame numbering sequence.This functionality is required for some of the described tests.11. ModifiersIt might be useful to know the DUT performance under a number ofconditions; some of these conditions are noted below. The reportedresults SHOULD include as many of these conditions as the testequipment is able to generate. The suite of tests SHOULD be firstrun without any modifying conditions and then repeated under each of the conditions separately. To preserve the ability to compare theresults of these tests any frames that are required to generate themodifying conditions (management queries for example) will beincluded in the same data stream as the normal test frames in placeof one of the test frames and not be supplied to the DUT on aseparate network port.Bradner & McQuaid Informational [Page 7]11.1 Broadcast framesIn most router designs special processing is required when framesaddressed to the hardware broadcast address are received. In bridges (or in bridge mode on routers) these broadcast frames must be flooded to a number of ports. The stream of test frames SHOULD be augmented with 1% frames addressed to the hardware broadcast address. Theframes sent to the broadcast address should be of a type that therouter will not need to process. The aim of this test is todetermine if there is any effect on the forwarding rate of the other data in the stream. The specific frames that should be used areincluded in the test frame format document. The broadcast framesSHOULD be evenly distributed throughout the data stream, for example, every 100th frame.The same test SHOULD be performed on bridge-like DUTs but in thiscase the broadcast packets will be processed and flooded to alloutputs.It is understood that a level of broadcast frames of 1% is muchhigher than many networks experience but, as in drug toxicityevaluations, the higher level is required to be able to gage theeffect which would otherwise often fall within the normal variability of the system performance. Due to design factors some test equipment will not be able to generate a level of alternate frames this low.In these cases the percentage SHOULD be as small as the equipment can provide and that the actual level be described in the report of thetest results.11.2 Management framesMost data networks now make use of management protocols such as SNMP. In many environments there can be a number of management stationssending queries to the same DUT at the same time.The stream of test frames SHOULD be augmented with one managementquery as the first frame sent each second during the duration of the trial. The result of the query must fit into one response frame. The response frame SHOULD be verified by the test equipment. One example of the specific query frame that should be used is shown in AppendixC.11.3 Routing update framesThe processing of dynamic routing protocol updates could have asignificant impact on the ability of a router to forward data frames. The stream of test frames SHOULD be augmented with one routing update frame transmitted as the first frame transmitted during the trial. Bradner & McQuaid Informational [Page 8]Routing update frames SHOULD be sent at the rate specified inAppendix C for the specific routing protocol being used in the test. Two routing update frames are defined in Appendix C for the TCP/IPover Ethernet example. The routing frames are designed to change the routing to a number of networks that are not involved in theforwarding of the test data. The first frame sets the routing table state to "A", the second one changes the state to "B". The framesMUST be alternated during the trial.The test SHOULD verify that the routing update was processed by theDUT.11.4 FiltersFilters are added to routers and bridges to selectively inhibit theforwarding of frames that would normally be forwarded. This isusually done to implement security controls on the data that isaccepted between one area and another. Different products havedifferent capabilities to implement filters.The DUT SHOULD be first configured to add one filter condition andthe tests performed. This filter SHOULD permit the forwarding of the test data stream. In routers this filter SHOULD be of the form:forward input_protocol_address to output_protocol_addressIn bridges the filter SHOULD be of the form:forward destination_hardware_addressThe DUT SHOULD be then reconfigured to implement a total of 25filters. The first 24 of these filters SHOULD be of the form:block input_protocol_address to output_protocol_addressThe 24 input and output protocol addresses SHOULD not be any that are represented in the test data stream. The last filter SHOULD permitthe forwarding of the test data stream. By "first" and "last" wemean to ensure that in the second case, 25 conditions must be checked before the data frames will match the conditions that permit theforwarding of the frame. Of course, if the DUT reorders the filtersor does not use a linear scan of the filter rules the effect of thesequence in which the filters are input is properly lost.The exact filters configuration command lines used SHOULD be included with the report of the results.Bradner & McQuaid Informational [Page 9]11.4.1 Filter AddressesTwo sets of filter addresses are required, one for the single filter case and one for the 25 filter case.The single filter case should permit traffic from IP address198.18.1.2 to IP address 198.19.65.2 and deny all other traffic.The 25 filter case should follow the following sequence.deny aa.ba.1.1 to aa.ba.100.1deny aa.ba.2.2 to aa.ba.101.2deny aa.ba.3.3 to aa.ba.103.3...deny aa.ba.12.12 to aa.ba.112.12allow aa.bc.1.2 to aa.bc.65.1deny aa.ba.13.13 to aa.ba.113.13deny aa.ba.14.14 to aa.ba.114.14...deny aa.ba.24.24 to aa.ba.124.24deny all elseAll previous filter conditions should be cleared from the routerbefore this sequence is entered. The sequence is selected to test to see if the router sorts the filter conditions or accepts them in the order that they were entered. Both of these procedures will resultin a greater impact on performance than will some form of hashcoding.12. Protocol addressesIt is easier to implement these tests using a single logical streamof data, with one source protocol address and one destinationprotocol address, and for some conditions like the filters described above, a practical requirement. Networks in the real world are notlimited to single streams of data. The test suite SHOULD be first run with a single protocol (or hardware for bridge tests) source anddestination address pair. The tests SHOULD then be repeated withusing a random destination address. While testing routers theaddresses SHOULD be random and uniformly distributed over a range of 256 networks and random and uniformly distributed over the full MACrange for bridges. The specific address ranges to use for IP areshown in Appendix C.Bradner & McQuaid Informational [Page 10]13. Route Set UpIt is not reasonable that all of the routing information necessary to forward the test stream, especially in the multiple address case,will be manually set up. At the start of each trial a routing update MUST be sent to the DUT. This routing update MUST include all of the network addresses that will be required for the trial. All of theaddresses SHOULD resolve to the same "next-hop". Normally this willbe the address of the receiving side of the test equipment. Thisrouting update will have to be repeated at the interval required bythe routing protocol being used. An example of the format andrepetition interval of the update frames is given in Appendix C.14. Bidirectional trafficNormal network activity is not all in a single direction. To testthe bidirectional performance of a DUT, the test series SHOULD be run with the same data rate being offered from each direction. The sum of the data rates should not exceed the theoretical limit for the media.15. Single stream pathThe full suite of tests SHOULD be run along with whatever modifierconditions that are relevant using a single input and output network port on the DUT. If the internal design of the DUT has multipledistinct pathways, for example, multiple interface cards each withmultiple network ports, then all possible types of pathways SHOULD be tested separately.16. Multi-portMany current router and bridge products provide many network ports in the same module. In performing these tests first half of the portsare designated as "input ports" and half are designated as "outputports". These ports SHOULD be evenly distributed across the DUTarchitecture. For example if a DUT has two interface cards each ofwhich has four ports, two ports on each interface card are designated as input and two are designated as output. The specified tests arerun using the same data rate being offered to each of the inputports. The addresses in the input data streams SHOULD be set so that a frame will be directed to each of the output ports in sequence sothat all "output" ports will get an even distribution of packets from this input. The same configuration MAY be used to perform abidirectional multi-stream test. In this case all of the ports areconsidered both input and output ports and each data stream MUSTconsist of frames addressed to all of the other ports.Bradner & McQuaid Informational [Page 11]Consider the following 6 port DUT:-----------------------| in A out X|-----------------| in B out Y|-----------------| in C out Z|----------------------The addressing of the data streams for each of the inputs SHOULD be: stream sent to input A:packet to out X, packet to out Y, packet to out Zstream sent to input B:packet to out X, packet to out Y, packet to out Zstream sent to input Cpacket to out X, packet to out Y, packet to out ZNote that these streams each follow the same sequence so that 3packets will arrive at output X at the same time, then 3 packets atY, then 3 packets at Z. This procedure ensures that, as in the realworld, the DUT will have to deal with multiple packets addressed tothe same output at the same time.17. Multiple protocolsThis document does not address the issue of testing the effects of a mixed protocol environment other than to suggest that if such testsare wanted then frames SHOULD be distributed between all of the test protocols. The distribution MAY approximate the conditions on thenetwork in which the DUT would be used.18. Multiple frame sizesThis document does not address the issue of testing the effects of a mixed frame size environment other than to suggest that if such tests are wanted then frames SHOULD be distributed between all of thelisted sizes for the protocol under test. The distribution MAYapproximate the conditions on the network in which the DUT would beused. The authors do not have any idea how the results of such a test would be interpreted other than to directly compare multiple DUTs in some very specific simulated network.19. Testing performance beyond a single DUT.In the performance testing of a single DUT, the paradigm can bedescribed as applying some input to a DUT and monitoring the output. The results of which can be used to form a basis of characterization of that device under those test conditions.Bradner & McQuaid Informational [Page 12]This model is useful when the test input and output are homogenous(e.g., 64-byte IP, 802.3 frames into the DUT; 64 byte IP, 802.3frames out), or the method of test can distinguish between dissimilar input/output. (E.g., 1518 byte IP, 802.3 frames in; 576 byte,fragmented IP, X.25 frames out.)By extending the single DUT test model, reasonable benchmarksregarding multiple DUTs or heterogeneous environments may becollected. In this extension, the single DUT is replaced by a system of interconnected network DUTs. This test methodology would supportthe benchmarking of a variety of device/media/service/protocolcombinations. For example, a configuration for a LAN-to-WAN-to-LANtest might be:(1) 802.3-> DUT 1 -> X.25 @ 64kbps -> DUT 2 -> 802.3Or a mixed LAN configuration might be:(2) 802.3 -> DUT 1 -> FDDI -> DUT 2 -> FDDI -> DUT 3 -> 802.3In both examples 1 and 2, end-to-end benchmarks of each system could be empirically ascertained. Other behavior may be characterizedthrough the use of intermediate devices. In example 2, theconfiguration may be used to give an indication of the FDDI to FDDIcapability exhibited by DUT 2.Because multiple DUTs are treated as a single system, there arelimitations to this methodology. For instance, this methodology mayyield an aggregate benchmark for a tested system. That benchmarkalone, however, may not necessarily reflect asymmetries in behaviorbetween the DUTs, latencies introduce by other apparatus (e.g.,CSUs/DSUs, switches), etc.Further, care must be used when comparing benchmarks of differentsystems by ensuring that the DUTs’ features/configuration of thetested systems have the appropriate common denominators to allowcomparison.20. Maximum frame rateThe maximum frame rates that should be used when testing LANconnections SHOULD be the listed theoretical maximum rate for theframe size on the media.Bradner & McQuaid Informational [Page 13]The maximum frame rate that should be used when testing WANconnections SHOULD be greater than the listed theoretical maximumrate for the frame size on that speed connection. The higher ratefor WAN tests is to compensate for the fact that some vendors employ various forms of header compression.A list of maximum frame rates for LAN connections is included inAppendix B.21. Bursty trafficIt is convenient to measure the DUT performance under steady stateload but this is an unrealistic way to gauge the functioning of a DUT since actual network traffic normally consists of bursts of frames.Some of the tests described below SHOULD be performed with bothsteady state traffic and with traffic consisting of repeated burstsof frames. The frames within a burst are transmitted with theminimum legitimate inter-frame gap.The objective of the test is to determine the minimum intervalbetween bursts which the DUT can process with no frame loss. Duringeach test the number of frames in each burst is held constant and the inter-burst interval varied. Tests SHOULD be run with burst sizes of 16, 64, 256 and 1024 frames.22. Frames per tokenAlthough it is possible to configure some token ring and FDDIinterfaces to transmit more than one frame each time that the tokenis received, most of the network devices currently available transmit only one frame per token. These tests SHOULD first be performedwhile transmitting only one frame per token.Some current high-performance workstation servers do transmit morethan one frame per token on FDDI to maximize throughput. Since this may be a common feature in future workstations and servers,interconnect devices with FDDI interfaces SHOULD be tested with 1, 4, 8, and 16 frames per token. The reported frame rate SHOULD be theaverage rate of frame transmission over the total trial period.23. Trial descriptionA particular test consists of multiple trials. Each trial returnsone piece of information, for example the loss rate at a particularinput frame rate. Each trial consists of a number of phases:a) If the DUT is a router, send the routing update to the "input"port and pause two seconds to be sure that the routing has settled. Bradner & McQuaid Informational [Page 14]。

流控制传输协议SCTP摘要SCTP被设计用来在IP网上传输PSTN信令消息,但能有更广泛的用途。

SCTP是一个可靠的传输层协议，运行在无连接的包网络上（如IP网）。

它为用户提供下列服务:-- 确保（acknowledged）用户数据无差错，无重复的传送；-- 根据通路MTU的限制，进行用户数据的分段；-- 流内用户消息的顺序递交；（可选的）每个用户消息按到达顺序（order-of-arrival）进行递交；-- （可选的）多个用户消息捆绑到单个SCTP包中进行传输；-- 通过在偶联的一端或两端提供的多归属（multi-homing）机制，提供网络级容错；SCTP的设计包含了避免拥塞机制和防泛播（flooding）及匿名攻击（masquerade attacks）的能力。

目录1. Introduction (5)1.1 Motivation (6)1.2 Architectural View of SCTP (6)1.3 Functional View of SCTP (7)1.3.1 Association Startup and Takedown (8)1.3.2 Sequenced Delivery within Streams (9)1.3.3 User Data Fragmentation (9)1.3.4 Acknowledgement and Congestion Avoidance (9)1.3.5 Chunk Bundling (10)1.3.6 Packet Validation (10)1.3.7 Path Management (11)1.4 Key Terms (11)1.5 Abbreviations (15)1.6 Serial Number Arithmetic (15)2. Conventions (16)3. SCTP packet Format (16)3.1 SCTP Common Header Field Descriptions (17)3.2 Chunk Field Descriptions (18)3.2.1 Optional/Variable-length Parameter Format (20)3.3 SCTP Chunk Definitions (21)3.3.1 Payload Data (DATA) (22)3.3.2 Initiation (INIT) (24)3.3.2.1 Optional or Variable Length Parameters (26)3.3.3 Initiation Acknowledgement (INIT ACK) (30)3.3.3.1 Optional or Variable Length Parameters (33)3.3.4 Selective Acknowledgement (SACK) (33)3.3.5 Heartbeat Request (HEARTBEAT) (37)3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK) (38)3.3.7 Abort Association (ABORT) (39)3.3.8 Shutdown Association (SHUTDOWN) (40)3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK) (40)3.3.10 Operation Error (ERROR) (41)3.3.10.1 Invalid Stream Identifier (42)3.3.10.2 Missing Mandatory Parameter (43)3.3.10.3 Stale Cookie Error (43)3.3.10.4 Out of Resource (44)3.3.10.5 Unresolvable Address (44)3.3.10.6 Unrecognized Chunk Type (44)3.3.10.7 Invalid Mandatory Parameter (45)3.3.10.8 Unrecognized Parameters (45)3.3.10.9 No User Data (46)3.3.10.10 Cookie Received While Shutting Down (46)3.3.11 Cookie Echo (COOKIE ECHO) (46)3.3.12 Cookie Acknowledgement (COOKIE ACK) (47)3.3.13 Shutdown Complete (SHUTDOWN COMPLETE) (48)4. SCTP Association State Diagram (48)5. Association Initialization (52)5.1 Normal Establishment of an Association (52)5.1.1 Handle Stream Parameters (54)5.1.2 Handle Address Parameters (54)5.1.3 Generating State Cookie (56)5.1.4 State Cookie Processing (57)5.1.5 State Cookie Authentication (57)5.1.6 An Example of Normal Association Establishment (58)5.2 Handle Duplicate or unexpected INIT, INIT ACK, COOKIE ECHO,and COOKIE ACK (60)5.2.1 Handle Duplicate INIT in COOKIE-WAITor COOKIE-ECHOED States (60)5.2.2 Unexpected INIT in States Other than CLOSED,COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT (61)5.2.3 Unexpected INIT ACK (61)5.2.4 Handle a COOKIE ECHO when a TCB exists (62)5.2.4.1 An Example of a Association Restart (64)5.2.5 Handle Duplicate COOKIE ACK (66)5.2.6 Handle Stale COOKIE Error (66)5.3 Other Initialization Issues (67)5.3.1 Selection of Tag Value (67)6. User Data Transfer (67)6.1 Transmission of DATA Chunks (69)6.2 Acknowledgement on Reception of DATA Chunks (70)6.2.1 Tracking Peer's Receive Buffer Space (73)6.3 Management Retransmission Timer (75)6.3.1 RTO Calculation (75)6.3.2 Retransmission Timer Rules (76)6.3.3 Handle T3-rtx Expiration (77)6.4 Multi-homed SCTP Endpoints (78)6.4.1 Failover from Inactive Destination Address (79)6.5 Stream Identifier and Stream Sequence Number (80)6.6 Ordered and Unordered Delivery (80)6.7 Report Gaps in Received DATA TSNs (81)6.8 Adler-32 Checksum Calculation (82)6.9 Fragmentation (83)6.10 Bundling (84)7. Congestion Control (85)7.1 SCTP Differences from TCP Congestion Control (85)7.2 SCTP Slow-Start and Congestion Avoidance (87)7.2.1 Slow-Start (87)7.2.2 Congestion Avoidance (89)7.2.3 Congestion Control (89)7.2.4 Fast Retransmit on Gap Reports (90)7.3 Path MTU Discovery (91)8. Fault Management (92)8.1 Endpoint Failure Detection (92)8.2 Path Failure Detection (92)8.3 Path Heartbeat (93)8.4 Handle "Out of the blue" Packets (95)8.5 Verification Tag (96)8.5.1 Exceptions in Verification Tag Rules (97)9. Termination of Association (98)9.1 Abort of an Association (98)9.2 Shutdown of an Association (98)10. Interface with Upper Layer (101)10.1 ULP-to-SCTP (101)10.2 SCTP-to-ULP (111)11. Security Considerations (114)11.1 Security Objectives (114)11.2 SCTP Responses To Potential Threats (115)11.2.1 Countering Insider Attacks (115)11.2.2 Protecting against Data Corruption in the Network (115)11.2.3 Protecting Confidentiality (115)11.2.4 Protecting against Blind Denial of Service Attacks (116)11.2.4.1 Flooding (116)11.2.4.2 Blind Masquerade (118)11.2.4.3 Improper Monopolization of Services (118)11.3 Protection against Fraud and Repudiation (119)12. Recommended Transmission Control Block (TCB) Parameters (120)12.1 Parameters necessary for the SCTP instance (120)12.2 Parameters necessary per association (i.e. the TCB) (120)12.3 Per Transport Address Data (122)12.4 General Parameters Needed (123)13. IANA Considerations (123)13.1 IETF-defined Chunk Extension (123)13.2 IETF-defined Chunk Parameter Extension (124)13.3 IETF-defined Additional Error Causes (124)13.4 Payload Protocol Identifiers (125)14. Suggested SCTP Protocol Parameter Values (125)15. Acknowledgements (126)16. Authors' Addresses (126)17. References (128)18. Bibliography (129)Appendix A (131)Appendix B (132)Full Copyright Statement (134)1. 引言本节解释了发展SCTP的缘由, SCTP提供的服务及理解协议细节所需的基本概念。

Network Working Group(网络工作组) R. Fielding Request for Comments: 2616 UC Irvine Obsoletes(过时弃用）: 2068 J. Gettys Category: Standards Track （类别:标准组） Compaq/W3CJ. MogulCompaqH. FrystykW3C/MITL. MasinterXeroxP. LeachMicrosoftT. Berners-LeeW3C/MITJune 1999超文本传输协议-HTTP/1.1本备忘录状况本文档说明了用于互联网社区的标准化跟踪协议，但还需要讨论和建议以便更加完善。

请参考"互联网官方协议标准"（STD1）来了解本协议的标准化状态。

分发散布本文是不受限制的。

版权声明Copyright (C) The Internet Society (1999). All Rights Reserved.摘要超文本传输协议（HTTP）是一种应用于分布式、协作式、超媒体信息系统的应用层协议。

它是一种通用的，状态无关的协议，可以用于除了超文本以外，还可以通过扩展它的请求方法，错误代码和报头[47]来完成更多任务，比如名称服务和分布对象管理系统。

HTTP的一个特点是数据表示方式的典型性（可输入的）（typing）和可协商性，允许建立独立于被传输数据的系统。

HTTP在1990年WWW全球信息刚刚起步的时候就得到了应用。

本规范定义了HTTP/1.1协议，这是RFC 2068的升级版[33]。

[页码1]------------------------------------------------------------------------目录1 Introduction （介绍） (7)1.1 Purpose（目的） (7)1.2 Requirements （要求） (8)1.3 Terminology （术语） (8)1.4 Overall Operation （概述） (12)2 Notational Conventions and Generic Grammar（标志转换及通用语法） (14)2.1 Augmented BNF （扩充的范式） (14)2.2 Basic Rules （基本规则） (15)3 Protocol Parameters （协议参数） (17)3.1 HTTP Version （版本） (17)3.2 Uniform Resource Identifiers （统一资源标识） (18)3.2.1 General Syntax （通用语法） (19)3.2.2 http URL (19)3.2.3 URI Comparison （URI对比） (20)3.3 Date/Time Formats （时间日期格式） (20)3.3.1 Full Date （完整日期） (20)3.3.2 Delta Seconds (21)3.4 Character Sets （字符集） (21)3.4.1 Missing Charset （不见了的字符集） (22)3.5 Content Codings （内容编码） (23)3.6 Transfer Codings （传输编码） (24)3.6.1 Chunked Transfer Coding （大块数据传输编码） (25)3.7 Media Types （媒介类型） (26)3.7.1 Canonicalization and Text Defaults (27)3.7.2 Multipart Types （复合类型） (27)3.8 Product Tokens （产品记号） (28)3.9 Quality Values （质量值） (29)3.10 Language Tags （语言标签） (29)3.11 Entity Tags （实体标签） (30)3.12 Range Units （范围单位） (30)4 HTTP Message （HTTP 消息） (31)4.1 Message Types （消息类型） (31)4.2 Message Headers （消息头） (31)4.3 Message Body （消息主体） (32)4.4 Message Length （消息长度） (33)4.5 General Header Fields （通用头字段） (34)5 Request （请求） (35)5.1 Request-Line （请求行） (35)5.1.1 Method （方法） (36)5.1.2 Request-URI （请求-URI） (36)5.2 The Resource Identified by a Request (38)5.3 Request Header Fields （请求头字段） (38)6 Response （应答） (39)6.1 Status-Line （状态行） (39)6.1.1 Status Code and Reason Phrase （状态码和原因短语） (39)6.2 Response Header Fields （应答头字段） (41)[页码2]------------------------------------------------------------------------7 Entity （实体） (42)7.1 Entity Header Fields （实体头字段） (42)7.2 Entity Body （实体主体） (43)7.2.1 Type （类型） (43)7.2.2 Entity Length （实体长度） (43)8 Connections （连接） (44)8.1 Persistent Connections （持久连接） (44)8.1.1 Purpose （目的） (44)8.1.2 Overall Operation（概述） (45)8.1.3 Proxy Servers （代理服务器） (46)8.1.4 Practical Considerations （实践中的考虑） (46)8.2 Message Transmission Requirements （消息传送请求） (47)8.2.1 Persistent Connections and Flow Control（持久连接和流程控制） (47)8.2.2 Monitoring Connections for Error Status Messages（出错状态消息的监测连接） (48)8.2.3 Use of the 100 (Continue) Status（状态号100的使用） (48)8.2.4 Client Behavior if Server Prematurely Closes Connection（如果服务器过早关闭连接，客户端的行为） (50)9 Method Definitions （方法的定义） (51)9.1 Safe and Idempotent Methods （安全和幂等方法） (51)9.1.1 Safe Methods （安全方法） (51)9.1.2 Idempotent Methods （幂等方法） (51)9.2 OPTIONS （选项） (52)9.3 GET （命令：GET） (53)9.4 HEAD （命令：HEAD） (54)9.5 POST （命令：POST） (54)9.6 PUT （命令：PUT） (55)9.7 DELETE （命令：DELETE） (56)9.8 TRACE （命令：TRACE） (56)9.9 CONNECT （命令：CONNECT） (57)10 Status Code Definitions （状态码定义） (57)10.1 Informational 1xx （报告：1XX） (57)10.1.1 100 Continue （100 继续） (58)10.1.2 101 Switching Protocols（交换协议） (58)10.2 Successful 2xx （成功：2XX） (58)10.2.1 200 OK （200 正常） (58)10.2.2 201 Created （201 已建立） (59)10.2.3 202 Accepted （202 已接受） (59)10.2.4 203 Non-Authoritative Information （无认证信息） (59)10.2.5 204 No Content （无内容） (60)10.2.6 205 Reset Content （重置内容） (60)10.2.7 206 Partial Content （部分内容） (60)10.3 Redirection 3xx （3XX 重定向） (61)10.3.1 300 Multiple Choices （复合选择） (61)10.3.2 301 Moved Permanently （永久转移） (62)10.3.3 302 Found （找到） (62)10.3.4 303 See Other （访问其他） (63)10.3.5 304 Not Modified （304 没有更改） (63)10.3.6 305 Use Proxy （305 使用代理） (64)10.3.7 306 (Unused) （306 未使用） (64)[页码3]------------------------------------------------------------------------10.3.8 307 Temporary Redirect （暂时重定向） (65)10.4 Client Error 4xx （客户端错误） (65)10.4.1 400 Bad Request （错误请求） (65)10.4.2 401 Unauthorized （未认证） (66)10.4.3 402 Payment Required （支付请求） (66)10.4.4 403 Forbidden （禁止） (66)10.4.5 404 Not Found （没有找到） (66)10.4.6 405 Method Not Allowed （方法不容许） (66)10.4.7 406 Not Acceptable （不可接受） (67)10.4.8 407 Proxy Authentication Required （要求代理认证） (67)10.4.9 408 Request Timeout （请求超时） (67)10.4.10 409 Conflict （冲突） (67)10.4.11 410 Gone （离开） (68)10.4.12 411 Length Required （长度请求） (68)10.4.13 412 Precondition Failed （预处理失败） (68)10.4.14 413 Request Entity Too Large （请求的实体太大了） (69)10.4.15 414 Request-URI Too Long （请求URI太长了） (69)10.4.16 415 Unsupported Media Type （不支持的媒提类型） (69)10.4.17 416 Requested Range Not Satisfiable （请求范围未满足） (69)10.4.18 417 Expectation Failed （期望失败） (70)10.5 Server Error 5xx （服务器错误 5XX） (70)10.5.1 500 Internal Server Error （内部错误） (70)10.5.2 501 Not Implemented （未实现） (70)10.5.3 502 Bad Gateway （错误网关） (70)10.5.4 503 Service Unavailable （服务不可用） (70)10.5.5 504 Gateway Timeout （网关超时） (71)10.5.6 505 HTTP Version Not Supported （版本不支持） (71)11 Access Authentication （访问认证） (71)12 Content Negotiation （内容协商） (71)12.1 Server-driven Negotiation （服务器驱动协商） (72)12.2 Agent-driven Negotiation （客户端驱动协商） (73)12.3 Transparent Negotiation （透明协商） (74)13 Caching in HTTP （缓存） (74)13.1.1 Cache Correctness （缓存正确性） (75)13.1.2 Warnings （警告） (76)13.1.3 Cache-control Mechanisms （缓存控制机制） (77)13.1.4 Explicit User Agent Warnings （直接用户代理警告） (78)13.1.5 Exceptions to the Rules and Warnings （规则和警告的异常）.78 13.1.6 Client-controlled Behavior（客户控制的行为） (79)13.2 Expiration Model （过期模式） (79)13.2.1 Server-Specified Expiration （服务器指定过期） (79)13.2.2 Heuristic Expiration （启发式过期） (80)13.2.3 Age Calculations （年龄计算） (80)13.2.4 Expiration Calculations （过期计算） (83)13.2.5 Disambiguating Expiration Values （消除歧义的过期值） (84)13.2.6 Disambiguating Multiple Responses （消除歧义的复合应答）..84 13.3 Validation Model （确认模式） (85)13.3.1 Last-Modified Dates （最后更改日期） (86)[页码4]------------------------------------------------------------------------13.3.2 Entity Tag Cache Validators （实体标签缓存确认） (86)13.3.3 Weak and Strong Validators （强弱确认） (86)13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates当使用实体标签和最后更改日期字段时候的规则 (89)13.3.5 Non-validating Conditionals （不可确认的条件） (90)13.4 Response Cacheability （应答缓存功能） (91)13.5 Constructing Responses From Caches （从缓存构造应答） (92)13.5.1 End-to-end and Hop-by-hop Headers （端对端和逐跳的头） (92)13.5.2 Non-modifiable Headers （不可以更改的报头） (92)13.5.3 Combining Headers （组合报头） (94)13.5.4 Combining Byte Ranges （组合字节范围） (95)13.6 Caching Negotiated Responses （缓存协商过的应答） (95)13.7 Shared and Non-Shared Caches （共享和非共享缓存） (96)13.8 Errors or Incomplete Response Cache Behavior（错误或不完整应答缓存行为） (97)13.9 Side Effects of GET and HEAD （GET和HEAD的单方影响） (97)13.10 Invalidation After Updates or Deletions（更新和删除后的失效） (97)13.11 Write-Through Mandatory （强制写通过） (98)13.12 Cache Replacement （缓存替换） (99)13.13 History Lists （历史列表） (99)14 Header Field Definitions （头字段定义） (100)14.1 Accept （接受） (100)14.2 Accept-Charset （接受的字符集） (102)14.3 Accept-Encoding （接受的编码方式） (102)14.4 Accept-Language （接受的语言） (104)14.5 Accept-Ranges （接受的范围） (105)14.6 Age （年龄，生存期） (106)14.7 Allow （容许） (106)14.8 Authorization （认证） (107)14.9 Cache-Control （缓存控制） (108)14.9.1 What is Cacheable （什么可以缓存） (109)14.9.2 What May be Stored by Caches （什么将被缓存存储） (110)14.9.3 Modifications of the Basic Expiration Mechanism基本过期机制的更改 (111)14.9.4 Cache Revalidation and Reload Controls缓存重确认和重载控制 (113)14.9.5 No-Transform Directive （不可转换指示） (115)14.9.6 Cache Control Extensions （缓存控制扩展） (116)14.10 Connection （连接） (117)14.11 Content-Encoding （内容编码） (118)14.12 Content-Language （内容语言） (118)14.13 Content-Length （内容长度） (119)14.14 Content-Location （内容位置） (120)14.15 Content-MD5 （内容的MD5校验） (121)14.16 Content-Range （内容范围） (122)14.17 Content-Type （内容类型） (124)14.18 Date （日期） (124)14.18.1 Clockless Origin Server Operation （无时钟服务器操作）..125 14.19 ETag （标签） (126)14.20 Expect （期望） (126)14.21 Expires （过期） (127)14.22 From （来自） (128)[页码5]------------------------------------------------------------------------14.23 Host （主机） (128)14.24 If-Match （如果匹配） (129)14.25 If-Modified-Since （如果自从某个时间已经更改） (130)14.26 If-None-Match （如果没有匹配） (132)14.27 If-Range （如果范围） (133)14.28 If-Unmodified-Since （如果自从某个时间未更改） (134)14.29 Last-Modified （最后更改） (134)14.30 Location （位置） (135)14.31 Max-Forwards （最大向前量） (136)14.32 Pragma （语法） (136)14.33 Proxy-Authenticate （代理鉴别） (137)14.34 Proxy-Authorization （代理授权） (137)14.35 Range （范围） (138)14.35.1 Byte Ranges （字节范围） (138)14.35.2 Range Retrieval Requests （范围重获请求） (139)14.36 Referer （引用自） (140)14.37 Retry-After （一会重试） (141)14.38 Server （服务器） (141)14.39 TE (142)14.40 Trailer （追踪者） (143)14.41 Transfer-Encoding（传输编码） (143)14.42 Upgrade （改良） (144)14.43 User-Agent （用户代理） (145)14.44 Vary （变更） (145)14.45 Via （经由） (146)14.46 Warning （警告） (148)14.47 WWW-Authenticate （WWW鉴别） (150)15 Security Considerations （对安全的考虑） (150)15.1 Personal Information（个人信息） (151)15.1.1 Abuse of Server Log Information （服务日志信息的滥用） (151)15.1.2 Transfer of Sensitive Information （敏感信息传输） (151)15.1.3 Encoding Sensitive Information in URI's（对URI中的敏感信息编码） (152)15.1.4 Privacy Issues Connected to Accept Headers（可接受头的秘密问题） (152)15.2 Attacks Based On File and Path Names基于文件名和路径的攻击 (153)15.3 DNS Spoofing （DNS欺骗） (154)15.4 Location Headers and Spoofing （位置头和欺骗） (154)15.5 Content-Disposition Issues （内容部署问题） (154)15.6 Authentication Credentials and Idle Clients（信用鉴定与空闲客户） (155)15.7 Proxies and Caching （代理与缓存） (155)15.7.1 Denial of Service Attacks on Proxies（对代理的服务拒绝攻击） (156)16 Acknowledgments （致谢） (156)17 References （参考） (158)18 Authors' Addresses （作者地址） (162)19 Appendices （附录） (164)19.1 Internet Media Type message/http and application/http（网络媒体类型：消息/HTTP和应用/HTTP） (164)19.2 Internet Media Type multipart/byteranges（网络媒体类型：多部分/字节范围） (165)19.3 Tolerant Applications （容错的应用） (166)19.4 Differences Between HTTP Entities and RFC 2045 Entities（HTTP的实体和RFC2045中实体的区别） (167)[页码6]------------------------------------------------------------------------19.4.1 MIME-Version （MIME版本） (167)19.4.2 Conversion to Canonical Form （语言形式转变） (167)19.4.3 Conversion of Date Formats （日期格式的转变） (168)19.4.4 Introduction of Content-Encoding （内容编码的介绍） (168)19.4.5 No Content-Transfer-Encoding （不要内容传输编码） (168)19.4.6 Introduction of Transfer-Encoding （传输编码的介绍） (169)19.4.7 MHTML and Line Length Limitations（MHTML与行长度限制） (169)19.5 Additional Features （附加的一些性质） (169)19.5.1 Content-Disposition （内容部署） (170)19.6 Compatibility with Previous Versions （与久版本的兼容性） (170)19.6.1 Changes from HTTP/1.0 （自HTTP/1.0的更改） (171)19.6.2 Compatibility with HTTP/1.0 Persistent Connections（与HTTP/1.1持久连接的兼容性） (172)19.6.3 Changes from RFC 2068 （自RFC268的更改） (172)20 Index （索引） (175)21 Full Copyright Statement （完整版权声明） (176)1 概述1.1 目的超文本传输协议（HTTP）是一种应用于分布式、合作式、多媒体信息系统的应用层协议。

OSPF 版本2/第二稿目录1 绪论1.1 协议概述1.2 常用术语的定义1.3 连接状态路由技术的简要历史1.4 本文档的结构1.5 感谢2 连接状态数据库：组织和计算2.1 路由器和网络的表示方法2.1.1 非广播网络的表示方法2.1.2 一个连接状态数据库的示例2.2 最短路径树2.3 使用外部路由信息2.4 等值多路径3 将自制系统划分为区域3.1 自制系统的骨干区域3.2 区域间路由3.3 路由器的分类3.4 一个简单区域配置3.5 IP子网化支持3.6 支持存根区域3.7 区域的划分4 功能摘要4.1 区域间路由4.2 自制系统外部路由4.3 路由协议包4.4 基本实现的需求4.5 OSPF可选项5 协议数据结构6 区域数据结构7 形成邻接7.1 Hello协议7.2 数据库同步7.3 指定路由器7.4 备份指定路由器7.5 邻接图8 协议包处理8.1 发送协议包8.2 接收协议包9 接口数据结构9.1 接口状态9.2 引起接口状态改变的事件9.3 接口状态机9.4 选举指定路由器9.5 发送Hello包9.5.1 在NBMA网络上发送Hello包10 邻居数据结构10.1 邻居状态10.2 引起邻居状态改变的事件RFC 232810.3 邻居状态机10.4 是否形成邻接10.5 接收到Hello包10.6 接收到数据库描述包10.7 接收到连接状态请求包10.8 发送数据库描述包10.9 发送连接状态请求包10.10 示例11 路由表结构11.1 查找路由表11.2 路由表示例，无区域11.3 路由表示例，有区域12 连接状态宣告（LSA）12.1 LSA头部12.1.1 连接状态时限12.1.2 选项12.1.3 连接状态类型12.1.4 连接状态标识12.1.5 宣告路由器12.1.6 连接状态序号12.1.7 连接状态校验和12.2 连接状态数据库12.3 TOS表现12.4 生成LSA12.4.1 Router-LSA12.4.1.1 描述点对点接口12.4.1.2 描述广播和NBMA接口12.4.1.3 描述虚拟通道12.4.1.4 描述点对多点接口12.4.1.5 Router-LSA示例12.4.2 Network-LSA12.4.2.1 Network-LSA示例12.4.3 Summary-LSA12.4.3.1 向存根区域生成Summary-LSA 12.4.3.2 Summary-LSA示例12.4.4 AS-external-LSA12.4.4.1 AS-external-LSA示例13 洪泛过程13.1 判定较新的LSA13.2 将LSA加入数据库13.3 洪泛过程的下一步操作13.4 接收自生成的LSA13.5 发送连接状态确认包（LSAck包）13.6 重传LSA13.7 接收连接状态确认包（LSAck包）14 老化连接状态数据库14.1 提前老化LSA15 虚拟通道16 计算路由表16.1 计算一个区域的最短路径树OSPF 版本2/第二稿16.1.1 计算下一跳16.2 计算区域间路径16.3 查看传输区域的Summary-LSA16.4 计算AS外部路径16.4.1 外部路径参数16.5 增量更新——Summary-LSA16.6 增量更新——AS-external-LSA16.7 路由表改变引起的事件16.8 等值多路径脚注引用A OSPF数据格式A.1 OSPF包的封装A.2 选项域A.3 OSPF包格式A.3.1 OSPF包头A.3.2 Hello包A.3.3 数据库描述包（DD包）A.3.4 连接状态请求包（LSR包）A.3.5 连接状态更新包（LSU包）A.3.6 连接状态确认包（LSAck包）A.4 LSA格式A.4.1 LSA头部A.4.2 Router-LSAA.4.3 Network-LSAA.4.4 Summary-LSAA.4.5 AS-external-LSAB 结构常量C 可配置变量C.1 全局参数C.2 区域参数C.3 路由器接口参数C.4 虚拟通道参数C.5 NBMA网络参数C.6 点对多点网络参数C.7 主机路径参数D 验证D.1 空验证D.2 简单口令验证D.3 密码验证D.4 信息生成D.4.1 生成空验证D.4.2 生成简单口令验证D.4.3 生成密码验证D.5 信息校验D.5.1 校验空验证D.5.2 校验简单口令验证D.5.3 校验密码验证E 设定LS标识的一种算法F 多接口接入同一网络/子网RFC 2328G 与RFC 2178的不同G.1 洪泛过程的修改G.2 外部路径优先级的改变G.3 解决不完整的虚拟下一跳G.4 路由表查找安全性考虑作者的地址完整的版权声明OSPF 版本2/第二稿1. 绪论本文档描述了开放最短路径优先/Open Shortest Path First（OSPF）TCP/IP网际路由协议。