-
2009-03-11
二层交换机、三层交换机与路由器的比较 - [网络]
为了适应网络应用深化带来的挑战，网络在规模和速度方向都在急剧发展，局域网的速度已从最初的10Mbit/s 提高到100Mbit/s，目前千兆以太网技术已得到普遍应用。在网络结构方面也从早期的共享介质的局域网发展到目前的交换式局域网。交换式局域网技术使专用的带宽为用户所独享，极大的提高了局域网传输的效率。可以说，在网络系统集成的技术中，直接面向用户的第一层接口和第二层交换技术方面已得到令人满意的答案。但是，作为网络核心、起到网间互连作用的路由器技术却没有质的突破。在这种情况下，一种新的路由技术应运而生，这就是第三层交换技术：说它是路由器，因为它可操作在网络协议的第三层，是一种路由理解设备并可起到路由决定的作用；说它是交换器，是因为它的速度极快，几乎达到第二层交换的速度。二层交换机、三层交换机和路由器这三种技术究竟谁优谁劣，它们各自适用在什么环境？为了解答这问题，我们先从这三种技术的工作原理入手：1.二层交换技术二层交换机是数据链路层的设备，它能够读取数据包中的MAC地址信息并根据MAC地址来进行交换。交换机内部有一个地址表，这个地址表标明了MAC地址和交换机端口的对应关系。当交换机从某个端口收到一个数据包，它首先读取包头中的源MAC地址，这样它就知道源MAC地址的机器是连在哪个端口上的，它再去读取包头中的目的MAC地址，并在地址表中查找相应的端口，如果表中有与这目的MAC地址对应的端口，则把数据包直接复制到这端口上，如果在表中找不到相应的端口则把数据包广播到所有端口上，当目的机器对源机器回应时，交换机又可以学习一目的MAC地址与哪个端口对应，在下次传送数据时就不再需要对所有端口进行广播了。二层交换机就是这样建立和维护它自己的地址表。由于二层交换机一般具有很宽的交换总线带宽，所以可以同时为很多端口进行数据交换。如果二层交换机有N个端口，每个端口的带宽是M，而它的交换机总线带宽超过N×M，那么这交换机就可以实现线速交换。二层交换机对广播包是不做限制的，把广播包复制到所有端口上。二层交换机一般都含有专门用于处理数据包转发的ASIC （Application specific Integrated Circuit）芯片，因此转发速度可以做到非常快。
2.路由技术路由器是在OSI七层网络模型中的第三层——网络层操作的。路由器内部有一个路由表，这表标明了如果要去某个地方，下一步应该往哪走。路由器从某个端口收到一个数据包，它首先把链路层的包头去掉（拆包），读取目的IP地址，然后查找路由表，若能确定下一步往哪送，则再加上链路层的包头（打包），把该数据包转发出去；如果不能确定下一步的地址，则向源地址返回一个信息，并把这个数据包丢掉。路由技术和二层交换看起来有点相似，其实路由和交换之间的主要区别就是交换发生在OSI参考模型的第二层（数据链路层），而路由发生在第三层。这一区别决定了路由和交换在传送数据的过程中需要使用不同的控制信息，所以两者实现各自功能的方式是不同的。路由技术其实是由两项最基本的活动组成，即决定最优路径和传输数据包。其中，数据包的传输相对较为简单和直接，而路由的确定则更加复杂一些。路由算法在路由表中写入各种不同的信息，路由器会根据数据包所要到达的目的地选择最佳路径把数据包发送到可以到达该目的地的下一台路由器处。当下一台路由器接收到该数据包时，也会查看其目标地址，并使用合适的路径继续传送给后面的路由器。依次类推，直到数据包到达最终目的地。路由器之间可以进行相互通讯，而且可以通过传送不同类型的信息维护各自的路由表。路由更新信息主是这样一种信息，一般是由部分或全部路由表组成。通过分析其它路由器发出的路由更新信息，路由器可以掌握整个网络的拓扑结构。链路状态广播是另外一种在路由器之间传递的信息，它可以把信息发送方的链路状态及进的通知给其它路由器。3.三层交换技术一个具有第三层交换功能的设备是一个带有第三层路由功能的第二层交换机，但它是二者的有机结合，并不是简单的把路由器设备的硬件及软件简单地叠加在局域网交换机上。从硬件上看，第二层交换机的接口模块都是通过高速背板/总线（速率可高达几十Gbit/s）交换数据的，在第三层交换机中，与路由器有关的第三层路由硬件模块也插接在高速背板/总线上，这种方式使得路由模块可以与需要路由的其他模块间高速的交换数据，从而突破了传统的外接路由器接口速率的限制。在软件方面，第三层交换机也有重大的举措，它将传统的基于软件的路由器软件进行了界定。其做法是：对于数据包的转发：如IP/IPX包的转发，这些规律的过程通过硬件得以高速实现。对于第三层路由软件：如路由信息的更新、路由表维护、路由计算、路由的确定等功能，用优化、高效的软件实现。假设两个使用IP协议的机器通过第三层交换机进行通信的过程，机器A在开始发送时，已知目的IP地址，但尚不知道在局域网上发送所需要的MAC地址。要采用地址解析（ARP）来确定目的MAC地址。机器A把自己的IP地址与目的IP地址比较，从其软件中配置的子网掩码提取出网络地址来确定目的机器是否与自己在同一子网内。若目的机器B与机器A在同一子网内，A广播一个ARP请求，B返回其MAC地址，A得到目的机器B的MAC地址后将这一地址缓存起来，并用此MAC地址封包转发数据，第二层交换模块查找MAC地址表确定将数据包发向目的端口。若两个机器不在同一子网内，如发送机器A要与目的机器C通信，发送机器A要向“缺省网关”发出ARP包，而“缺省网关”的IP地址已经在系统软件中设置。这个IP地址实际上对应第三层交换机的第三层交换模块。所以当发送机器A对“缺省网关”的IP地址广播出一个ARP请求时，若第三层交换模块在以往的通信过程中已得到目的机器C的MAC地址，则向发送机器A回复C的MAC地址；否则第三层交换模块根据路由信息向目的机器广播一个ARP请求，目的机器C得到此ARP请示后向第三层交换模块回复其MAC地址，第三层交换模块保存此地址并回复给发送机器A。以后，当再进行A与C之间数据包转发进，将用最终的目的机器的MAC地址封装，数据转发过程全部交给第二层交换处理，信息得以高速交换。既所谓的一次选路，多次交换。第三层交换具有以下突出特点：有机的硬件结合使得数据交换加速；优化的路由软件使 得路由过程效率提高；除了必要的路由决定过程外，大部分数据转发过程由第二层交换处理；多个子网互连时只是与第三层交换模块的逻辑连接，不象传统的外接路由器那样需增加端口，保护了用户的投资。4.三种技术的对比可以看出，二层交换机主要用在小型局域网中，机器数量在二、三十台以下，这样的网络环境下，广播包影响不大，二层交换机的快速交换功能、多个接入端口和低廉价格为小型网络用户提供了很完善的解决方案。在这种小型网络中根本没必要引入路由功能从而增加管理的难度和费用，所以没有必要使用路由器，当然也没有必要使用三层交换机。三层交换机是为IP设计的，接口类型简单，拥有很强二层包处理能力，所以适用于大型局域网，为了减小广播风暴的危害，必须把大型局域网按功能或地域等因素划他成一个一个的小局域网，也就是一个一个的小网段，这样必然导致不同网段这间存在大量的互访，单纯使用二层交换机没办法实现网间的互访而单纯使用路由器，则由于端口数量有限，路由速度较慢，而限制了网络的规模和访问速度，所以这种环境下，由二层交换技术和路由技术有机结合而成的三层交换机就最为适合。路由器端口类型多，支持的三层协议多，路由能力强，所以适合于在大型网络之间的互连，虽然不少三层交换机甚至二层交换机都有异质网络的互连端口，但一般大型网络的互连端口不多，互连设备的主要功能不在于在端口之间进行快速交换，而是要选择最佳路径，进行负载分担，链路备份和最重要的与其它网络进行路由信息交换，所有这些都是路由完成的功能。在这种情况下，自然不可能使用二层交换机，但是否使用三层交换机，则视具体情况而下。影响的因素主要有网络流量、响应速度要求和投资预算等。三层交换机的最重要目的是加快大型局域网内部的数据交换，揉合进去的路由功能也是为这目的服务的，所以它的路由功能没有同一档次的专业路由器强。在网络流量很大的情况下，如果三层交换机既做网内的交换，又做网间的路由，必然会大大加重了它的负担，影响响应速度。在网络流量很大，但又要求响应速度很高的情况下由三层交换机做网内的交换，由路由器专门负责网间的路由工作，这样可以充分发挥不同设备的优势，是一个很好的配合。当然，如果受到投资预算的限制，由三层交换机兼做网间互连，也是个不错的选择. -
(MultiProtocol Label Switching) A standard from the IETF for including routing information in the packets of an IP network. MPLS is used to ensure that all packets in a particular flow take the same route over a backbone. Deployed by many telcos and service providers, MPLS can deliver the quality of service (QoS) required to support real-time voice and video as well as service level agreements (SLAs) that guarantee bandwidth. Large enterprises may also use MPLS in their national networks.
Similar to Cisco's tag switching, an MPLS router attaches labels (tags) containing forwarding information to outgoing IP packets. These "label edge routers" (LERs) sit at the edge of the network and perform the complex packet analysis and classification before the packet enters the core of the network. The routers within the core, known as "label switch routers" (LSRs), quickly examine the label and forward the packet per its directions without having to look up data in tables and compute the forwarding path each time. The edge routers at the receiving end remove the labels.
Following in the tradition of the "dumb network," MPLS enables more decisions to be made at the periphery of the network. See VPLS, GMPLS, dumb network and Diffserv.
An MPLS Core Using IP and MPLS in the core, a service provider can offer its customers a virtual private VPN service for IP traffic and guarantee bandwidth for real-time voice and video. In computer networking and telecommunications, Multi Protocol Label Switching (MPLS) is a data-carrying mechanism that belongs to the family of packet-switched networks. MPLS operates at an OSI Model layer that is generally considered to lie between traditional definitions of Layer 2 (Data Link Layer) and Layer 3 (Network Layer), and thus is often referred to as a "Layer 2.5" protocol. It was designed to provide a unified data-carrying service for both circuit-based clients and packet-switching clients which provide a datagram service model. It can be used to carry many different kinds of traffic, including IP packets, as well as native ATM, SONET, and Ethernet frames.
A number of different technologies were previously deployed with essentially identical goals, such as frame relay and ATM. MPLS technologies have evolved with the strengths and weaknesses of ATM in mind. Many network engineers agree that ATM should be replaced with a protocol that requires less overhead, while providing connection-oriented services for variable-length frames. MPLS is currently replacing some of these technologies in the marketplace. It is highly possible that MPLS will completely replace these technologies in the future, thus aligning these technologies with current and future technology needs.[1]
In particular, MPLS dispenses with the cell-switching and signaling-protocol baggage of ATM. MPLS recognizes that small ATM cells are not needed in the core of modern networks, since modern optical networks (as of 2008) are so fast (at 40 Gbit/s and beyond) that even full-length 1500 byte packets do not incur significant real-time queuing delays (the need to reduce such delays — e.g., to support voice traffic — was the motivation for the cell nature of ATM).
At the same time, MPLS attempts to preserve the traffic engineering and out-of-band control that made frame relay and ATM attractive for deploying large-scale networks.
While the traffic management benefits of migrating to MPLS are quite valuable (better reliability, increased performance), there is a significant loss of visibility and access into the MPLS cloud for IT departments.[2]
History
MPLS was originally proposed by a group of engineers from Ipsilon Networks, but their "IP Switching" technology, which was defined only to work over ATM, did not achieve market dominance. Cisco Systems, Inc. introduced a related proposal, not restricted to ATM transmission, called "Tag Switching". It was a Cisco proprietary proposal, and was renamed "Label Switching". It was handed over to the IETF for open standardization. The IETF work involved proposals from other vendors, and development of a consensus protocol that combined features from several vendors' work.
One original motivation was to allow the creation of simple high-speed switches, since for a significant length of time it was impossible to forward IP packets entirely in hardware. However, advances in VLSI have made such devices possible. Therefore the advantages of MPLS primarily revolve around the ability to support multiple service models and perform traffic management. MPLS also offers a robust recovery framework[3] that goes beyond the simple protection rings of synchronous optical networking (SONET/SDH)..
How MPLS works
MPLS works by prefixing packets with an MPLS header, containing one or more 'labels'. This is called a label stack. Each label stack entry contains four fields:
- A 20-bit label value.
- a 3-bit field for QoS (Quality of Service) priority (experimental).
- a 1-bit bottom of stack flag. If this is set, it signifies that the current label is the last in the stack.
- an 8-bit TTL (time to live) field.
These MPLS-labeled packets are switched after a Label Lookup/Switch instead of a lookup into the IP table. As mentioned above, when MPLS was conceived, Label Lookup and Label Switching were faster than a RIB lookup because they could take place directly within the switched fabric and not the CPU.
The entry and exit points of an MPLS network are called Label Edge Routers (LER), which, respectively, push an MPLS label onto the incoming packet and pop it off the outgoing packet. Routers that perform routing based only on the label are called Label Switch Routers (LSR). In some applications, the packet presented to the LER already may have a label, so that the new LSR pushes a second label onto the packet. For more information see Penultimate Hop Popping.
Labels are distributed between LERs and LSRs using the “Label Distribution Protocol” (LDP)[4]. Label Switch Routers in an MPLS network regularly exchange label and reachability information with each other using standardized procedures in order to build a complete picture of the network they can then use to forward packets. Label Switch Paths (LSPs) are established by the network operator for a variety of purposes, such as to create network-based IP Virtual Private Networks or to route traffic along specified paths through the network. In many respects, LSPs are no different than PVCs in ATM or Frame Relay networks, except that they are not dependent on a particular Layer 2 technology.[5]
In the specific context of an MPLS-based Virtual Private Network (VPN), LSRs that function as ingress and/or egress routers to the VPN are often called PE (Provider Edge) routers. Devices that function only as transit routers are similarly called P (Provider) routers. See RFC 2547.[6] The job of a P router is significantly easier than that of a PE router, so they can be less complex and may be more dependable because of this.
When an unlabeled packet enters the ingress router and needs to be passed on to an MPLS tunnel, the router first determines the forwarding equivalence class (FEC) the packet should be in, and then inserts one or more labels in the packet's newly-created MPLS header. The packet is then passed on to the next hop router for this tunnel.
When a labeled packet is received by an MPLS router, the topmost label is examined. Based on the contents of the label a swap, push (impose) or pop (dispose) operation can be performed on the packet's label stack. Routers can have prebuilt lookup tables that tell them which kind of operation to do based on the topmost label of the incoming packet so they can process the packet very quickly.
In a swap operation the label is swapped with a new label, and the packet is forwarded along the path associated with the new label.
In a push operation a new label is pushed on top of the existing label, effectively "encapsulating" the packet in another layer of MPLS. This allows hierarchical routing of MPLS packets. Notably, this is used by MPLS VPNs.
In a pop operation the label is removed from the packet, which may reveal an inner label below. This process is called "decapsulation". If the popped label was the last on the label stack, the packet "leaves" the MPLS tunnel. This is usually done by the egress router, but see PHP below.
During these operations, the contents of the packet below the MPLS Label stack are not examined. Indeed transit routers typically need only to examine the topmost label on the stack. The forwarding of the packet is done based on the contents of the labels, which allows "protocol-independent packet forwarding" that does not need to look at a protocol-dependent routing table and avoids the expensive IP longest prefix match at each hop.
At the egress router, when the last label has been popped, only the payload remains. This can be an IP packet, or any of a number of other kinds of payload packet. The egress router must therefore have routing information for the packet's payload, since it must forward it without the help of label lookup tables. An MPLS transit router has no such requirement.
In some special cases, the last label can also be popped off at the penultimate hop (the hop before the egress router). This is called Penultimate Hop Popping (PHP). This may be interesting in cases where the egress router has lots of packets leaving MPLS tunnels, and thus spends inordinate amounts of CPU time on this. By using PHP, transit routers connected directly to this egress router effectively offload it, by popping the last label themselves.
MPLS can make use of existing ATM network infrastructure, as its labeled flows can be mapped to ATM virtual circuit identifiers, and vice versa.
Installing and removing MPLS paths
There are two standardized protocols for managing MPLS paths: CR-LDP (Constraint-based Routing Label Distribution Protocol) and RSVP-TE, an extension of the RSVP protocol for traffic engineering. As of February 2003, as documented in RFC 3468,[7] defined in RFC 3209.
Extensions of the BGP protocol, starting with RFC 2547, can be used to manage an MPLS path, including RFC 3107 and RFC 4781. [8] [9].
An MPLS header does not identify the type of data carried inside the MPLS path. If one wants to carry two different types of traffic between the same two routers, with different treatment from the core routers for each type, one has to establish a separate MPLS path for each type of traffic.
Comparison of MPLS versus IP
MPLS cannot be compared to IP as a separate entity because it works in conjunction with IP and IP's IGP routing protocols. MPLS gives IP networks simple traffic engineering, the ability to transport Layer 3 (IP) VPNs with overlapping address spaces, and support for Layer 2 pseudowires (with Any Transport Over MPLS, or ATOM - see Martini draft). Routers with programmable CPUs and without LSP can either be (a) explicitly configured hop by hop, (b) dynamically routed by the Constrained Shortest Path First CSPF algorithm, or (c) configured as a loose route that avoids a particular IP or that is partly explicit and partly dynamic. In a pure IP network, the shortest path to a destination is chosen even when it becomes more congested. Meanwhile, in an IP network with MPLS Traffic Engineering CSPF routing, constraints such as the RSVP bandwidth of the traversed links can also be considered, such that the shortest path with available bandwidth will be chosen. MPLS Traffic Engineering relies upon the use of TE extensions to OSPF or IS-IS and RSVP. Besides the constraint of RSVP bandwidth, users can also define their own constraints by specifying link attributes and special requirements for tunnels to route (or to not route) over links with certain attributes. [10]
MPLS local protection (Fast Reroute)
In the event of a network element failure when recovery mechanisms are employed at the IP layer, restoration may take several seconds which is unacceptable for real-time applications (such as VoIP)[11] [12][13]. In contrast, MPLS local protection meets the requirements of real-time applications with recovery times comparable to those of SONET rings (up to 50ms).[11][13][14]
Comparison of MPLS versus Frame Relay
Frame relay aimed to make more efficient use of existing physical resources, which allow for the underprovisioning of data services by telecommunications companies (telcos) to their customers, as clients were unlikely to be utilizing a data service 100 percent of the time. In more recent years, frame relay has acquired a bad reputation in some markets because of excessive bandwidth overbooking by these telcos.
Telcos often sell frame relay to businesses looking for a cheaper alternative to dedicated lines; its use in different geographic areas depended greatly on governmental and telecommunication companies' policies.
AT&T is currently (as of June 2007) the largest frame relay service provider in the United States, with local networks in 22 states, plus national and international networks. This number is expected to change between 2007 and 2009 when most of these frame relay contracts expire. Many customers are likely to migrate from frame relay to MPLS over IP or Ethernet within the next two years, which in many cases will reduce costs and improve manageability and performance of their wide area networks.[15] [16]
Comparison of MPLS versus ATM
While the underlying protocols and technologies are different, both MPLS and ATM provide a connection-oriented service for transporting data across computer networks. In both technologies, connections are signaled between endpoints, connection state is maintained at each node in the path, and encapsulation techniques are used to carry data across the connection. Excluding differences in the signaling protocols (RSVP/LDP for MPLS and PNNI:Private Network-to-Network Interface for ATM) there still remain significant differences in the behavior of the technologies.
The most significant difference is in the transport and encapsulation methods. MPLS is able to work with variable length packets while ATM transports fixed-length (53 byte) cells. Packets must be segmented, transported and re-assembled over an ATM network using an adaption layer, which adds significant complexity and overhead to the data stream. MPLS, on the other hand, simply adds a label to the head of each packet and transmits it on the network.
Differences exist, as well, in the nature of the connections. An MPLS connection (LSP) is uni-directional - allowing data to flow in only one direction between two endpoints. Establishing two-way communications between endpoints requires a pair of LSPs to be established. Because 2 LSPs are required for connectivity, data flowing in the forward direction may use a different path from data flowing in the reverse direction. ATM point-to-point connections (Virtual Circuits), on the other hand, are bi-directional, allowing data to flow in both directions over the same path (bi-directional are only SVC ATM connections; PVC ATM connections are uni-directional).
Both ATM and MPLS support tunneling of connections inside connections. MPLS uses label stacking to accomplish this while ATM uses Virtual Paths. MPLS can stack multiple labels to form tunnels within tunnels. The ATM Virtual Path Indicator (VPI) and Virtual Circuit Indicator (VCI) are both carried together in the cell header, limiting ATM to a single level of tunnelling.
The biggest single advantage that MPLS has over ATM is that it was designed from the start to be complementary to IP. Modern routers are able to support both MPLS and IP natively across a common interface allowing network operators great flexibility in network design and operation. ATM's incompatibilities with IP require complex adaptation, making it comparatively less suitable for today's predominantly IP networks.
Comparison of MPLS VPN versus IPSec VPN
MPLS is more reliable than IPSec VPNs as there is less complication in the tunnelling and firewall configuration. Network intrusions are a greater concern with IPSec VPN tunnels since they are run through an Internet circuit, which is open to connections from around the world. A misconfigured firewall can open the VPN network to security threats of the Internet.
MPLS deployment
MPLS is currently in use in large "IP Only" networks, and is standardized by IETF in RFC 3031.
In practice, MPLS is mainly used to forward IP datagrams and Ethernet traffic. Major applications of MPLS are Telecommunications traffic engineering and MPLS VPN.
Competitors to MPLS
MPLS can exist in both IPv4 environment (IPv4 routing protocols) and IPv6 environment (IPv6 routing protocols). The major goal of MPLS development - the increase of routing speed - is no longer relevant because of the usage of ASIC, TCAM and CAM-based switching. Therefore the major usage of MPLS is to implement limited traffic engineering and Layer 3/Layer 2 “service provider type” VPNs over existing IPv4 networks. The only competitors to MPLS are technologies like L2TPv3 that also provide services such as service provider Layer 2 and Layer 3 VPNs.
IEEE 1355 is a completely unrelated technology that does something similar in hardware.
IPv6 references: Grossetete, Patrick, IPv6 over MPLS, Cisco Systems 2001; Juniper Networks IPv6 and Infranets White Paper; Juniper Networks DoD's Research and Engineering Community White Paper.
Access to MPLS networks
MPLS supports a range of access technologies, including T1, ATM and frame relay. In April 2008, New Edge Networks announced traffic prioritization on its MPLS network available via less expensive DSL access. Previously, traffic prioritization was not possible across DSL connections.
Benefits of MPLS
MPLS provides networks with a more efficient way to manage applications and move information between locations. With the convergence of voice, video and data applications, business networks face increasing traffic demands. MPLS enables class of service (CoS) tagging and prioritization of network traffic, so administrators may specify which applications should move across the network ahead of others. This function makes an MPLS network especially important to firms that need to ensure the performance of low-latency applications such as VoIP and their other business-critical functions. MPLS carriers differ on the number of classes of service they offer and in how these CoS tiers are priced. [17]
-
2009-03-02
ATM协议及ATM技术介绍 - [网络]
43.1.1 协议简介
ATM(Asynchronous Transfer Mode)是一种以信元为单位的异步转移模式。它是基于B-ISDN宽带综合服
务数字网标准而设计的用来提高用户综合访问速度的一项技术。在交换形式上而言，ATM 是面向连接的
链路，任何一个 ATM 终端与另一个用户通信的时候都需
要建立连接，这一方面来看，ATM 拥有电路交换的特点；
另一方面 ATM 采用信元(Cell)交换的方式，信元长度固定
为53字节。
选择净荷长度需要考虑的几个因素：
网络总时延：1000km 传输，8 个 ATM 交换机，2 次
ATM和非ATM之间的转换，端到端时延： 32字节信元14ms，
64字节信元22ms，总时延过大对话音承载有困难。欧洲
意见：32字节，时延小。美国、日本意见：64字节,传输
效率高。
最终 ITU折衷：48字节
ATM协议参考模型如下：
用户平面：
采用分层结构，提供用户信息流的传送，同时也具有一定的控制功能，如流量控制、差错控
制等；
控制平面：
采用分层结构，完成呼叫控制和连接控制功能，利用信令进行呼叫和连接建立、监视和释放；
管理平面：
包括层管理和面管理。其中层管理采用分层结构，完成与各协议层实体的资源和参数相关的
管理功能，如元信令。同时层管理还处理与各层相关的 OAM 信息流；面管理不分层，它完
成与整个系统相关的管理功能，并对所有平面起协调作用。43.1.2 ATM物理层
ATM 物理层和 OSI 模型中的第一层非常一致。在物理介质上控制传输，并结收位流。 ATM 物理层分
为两个子层，传输汇聚层(TC)和物理介质层(PMD)。输入 TC 层的是 53 字节长的 ATM 信元。而 PMD 层输
出的是包含ATM信元的第一层数据。
ATM物理层有很多职责：
TC子层：
传输汇聚子层察看信头，并使用HEC检查信头是否有错，同时可以进行信元定界，即计算和
忽略开始前7 个信元，完成计算后，对接下来的信元进行分析和传送。以一条OC-3 链路而言，大
约每秒产生2.5M个Cell，前 7个显得微不足道了。
同时由于ATM为异步传输链路，但在SONET以及DS-3这些链路上，是采用同步传输方式的，
ATM 使用信元率退耦功能插入空载信元到同步链路中去。这种模式可以与同步 T1 线路做一对比。
在 T1 线路中每 125us 都有一个 T1 帧生成，该速率由主时钟控制，每帧的第 k 时隙中有从相同源
来的1字节数据。而ATM不严格要求信元交替地从不同的源到来，每一列从各个源来的信元，没
有特别的模式，信元可以从任意不同的源到来，而且，不要求从一台计算机来的信元流是连续的，
数据信元可以有间隔，这些间隔由特殊的空闲信元(idle cell)填充。
VCI/VPI均为0 的信元被定义为空信元。
TC 子层的另一项重要任务是：针对从事传输的系统，产生成帧信息。比如，一个 ATM 摄象
机在线路上只产生一系列信元，但它也可能用ATM信元产生SONET帧， 嵌入SONET有效载荷中。在后一种情况下，TC 子层将产生 SONET 或帧，并把 ATM 信元打包，这并不完全是一个不必要的
步骤，因为SONET有效载荷不能支持53字节信元的整数倍。
物理介质子层：
物理介质子层提供比特传输能力，对比特定时和线路编码等方面作出了规定，并针对所采用
的物理介质(如光纤、同轴电缆、双绞线等)定义其相应的特性；
ITU-T标准(协议I.432)定义了两个主要的ATM物理层协议：
1、基于信元的接口－不需要成帧的连续信元流
2、基于帧的接口－使用SDH 和PDH的传输帧结构。
1、ATM信元流被映射到带有VC－4路径开销的VC-4容器中
2、由于C-4容量(2340字节)并不是信元长度的整数倍，因此信元可以跨过C-4边界
3、映射的细节和开销的结构由协议I.432 和 G.707(1995)给出
STM-1的标准速率为155.52Mbps，去掉各种开销，信元的传送速率为：
(155.52/270)x260=149.76Mbps
类似的原理可以用于STM-4(622.08 Mbits/s结构中的信元映射； PDH的映射结构在协议G.703, G.803和G.832中有所描述。但传输帧映射/开销处理是很复杂的且需要大量的硬件工作。
ATM定义了众多接口标准，如下：
43.1.3 IMA反向多路复用
IMA(Inverse Multiplexing for ATM)用于将一个单一的高速ATM信元流在发送端拆散并放在两个或多个
低速链路上进行传输。在接收端将多个低速ATM信元流还原为高速ATM信元流。 其工作原理如下图
他在发送端通过IMA模块对信号进行处理，并将空载信元过滤，然后通过ICP协议在特定的时间发送
ICP 信元，帮助接收方 IMA 进行流重组和空载信元的再次加入。它工
作在TC和 PMD层之上，位于ATM层下方，右图为Cisco 的ATM-IMA
模块，它可以将8 个T1链路进行聚合。
43.1.4 ATM层
ATM 不同于同步交换机制，它是一种异步多路复用机制，在 ATM 层的作用为产生 5 字节的 ATM 信元
头。并将信元头夹在到净荷前端。ATM交换机制如下：
1．信元传输
第一步是进行头部的校验和。一旦产生出 HEC，并插入信元头部，那么此信元就作好了发送准
备。传输手段分成两组：异步的和同步的。当使用异步方式时，只要准备好了发送它，就可以发送，没有时间限制。使用同步方式，信元就必须按照事先确定的时间节拍发送。如果在需要时无数据信
元可用，TC子层就必须发明一个，这种信元称为空闲信元(idle cell)。
无数据信元的另一种类型是操作和维护OAM(operation and maitenance)信元。ATM机制也使用
OAM 信元来交换控制及其他必需的信息，以保证系统的运行。把 ATM 输出速率与从事传输系统的
速率相匹配是TC子层的重要任务。
在接收方，空闲信元在TC子层中进行处理，但OAM信元交给了ATM层。
尽管电话公司明确地使用 SONET 作为 ATM 的传输系统，但是也可以定义成把 ATM 对应到其他
系统的有效载荷字段，并且这种新帧已在工作。尤其是，映射成T1，T3或FDDI帧也是可以的。
2．信元接收
在输出处，TC 子层的工作是取得一系列信元，在每个信元上增加一个HEC，把此结果转变成比
特流，并通过加入 OAM 信元，将比特流匹配为进行物理传输系统的速率。在输入处，TC 层准确地
进行逆变换。它取来到达的比特流，设定信元边界，确定信元头(丢弃拥有不合法头部的信元)，处
理OAM信元，并把数据信元上传给ATM层。
最困难的部分是在到来的比特流中设定信元边界。在某些情况下，进行传输的物理层提供了帮
助。然而，有时物理层对成帧并不能提供帮助。这时应该使用HEC。随着比特流到达TC子层，保留
一个40位移位寄存器，比特流从左边进入，右边出来。TC子层然后审查这40位，看是否可能存在
一个合法的信元头部。如果有，最右边的8位将是合法的HEC，而最左边的32位则不是。如果不存
在这种情况，则缓冲区没有存在一个合法信元，在这种情况下，缓冲区中所有的位都向右移动一位，
使得后端空出一位，于是一个新的输入位就加到最左端。不断重复此过程，直到定位一个合法的 HEC。
此时，明确了信元边界，因为移位寄存器包括了一个有效的头部。43.1.5 VPI/VCI
ATM 交换机使用 VPI/VCI 进行数据交换，这一点和 Frame-Relay 的 DLCI 号比较相似，每个交换机将分
析信元头部的信息，根据信元头部的VCI/VPI信息进行数据交换。VPI 和VCI的关系如下：
VP 表示一个虚通路，而 VC 表示为一个虚电路。 而一个 VCC 表示一个虚电路连接，通常为 OC-3 E3
等数字链路。下图为它们之间的关系：
一个 VCC 链路可以包含多条 VP，而一个 VP 则可以包含多个 VC。ATM 则采用这种方式来讲多个虚拟
链路聚合到一条VP或者VCC 中进行传输。通过VPI/VCI 编址，ATM可以支持如下多种虚电路类型：永久虚电路PVC
交换虚电路SVC
Soft VC在链路建立过程中，如下图：
一个虚通道连接VPC是虚通道链接(Virtual Path Links, VPL)的级联。每条VPL与一个VPI 值相联系。交
换点可以改变VPI值。一个VCC是VCL的级联。每条VCL与一VPI 及VCI相联系。交换点可以改变VPI/VCI
值。如下图，Cell在传输过程中VPI/VCI的改变过程
VPI/VCI 值分配方式如下：
关于UNI/NNI，ATM论坛定义了多种网络接口：
1、UNI(User-Network Interface)
UNI为ATM网中的用户网络接口，它是用户设备与网络之间的接口，直接面向用户。UNI接
口定义了物理传输线路的接口标准，即用户可以通过怎样的物理线路和接口与ATM 网相连，还定
义了ATM层标准、UNI信令、OAM功能和管理功能等。按 UNI接口所在的位置不同，又可分为公
用网的 UNI 和专用网的 UNI(PUNI)，这两种 UNI 接口的定义基本上是相同的，只是 PUNI 由于不必
象公网的接口那样过多地考虑严格的一致性，所以 PUNI 的接口形式更多、更灵活、发展也更快。
2、NNI(Network to Network/Network Node Interface)
NNI可理解为网络节点接口或网络/网络之间的接口，一般为两个交换机之间的接口，与 UNI
一样，NNI 接口也定义了物理层、ATM 层等各层的规范，以及信令等功能，但由于 NNI 接口关系
到连接在网络中的路由选择问题，所以特别对路由选择方法做了说明。同样，NNI 接口也分为公
网NNI和专用网中的NNI(PNNI)，公网NNI和PNNI的差别还是相当大的，如公网NNI的信令为3、
7 号信令体系的宽带 ISDN 用户部分 B-ISUP，而 PNNI 则完全基于 UNI 接口，仍采用 UNI 的信令结
构。ATM论坛又开发了一种新型接口AINI，用于PNNI 和 B-ICI之间的互联，它同样采用PNNI 类似
的信令。
3、B-ICI(BISDN Inter-Carrier Interface)
B-ICI 定义为两个公用 ATM 网之间的接口，为分别属于两个运营者的 UNI 接口提供了连接，
它的定义基于 NNI 接口，其特点是支持不同网络间的多种业务传送，包括基于信元的 PVC 方式业
务、PVC方式的帧中继业务、电路仿真业务、SMDS以及SVC业务等。
4、DXI(Data Exchange Interface)
DXI 定义在数字终端设备 DTE 和数字连接设备 DCE 之间，DTE 通过 DXI 与 DCE 相连，再通过
ATM UNI 接口接入 ATM 网中，DCE 完成了不符合 ATM 标准的数据终端到 ATM 的适配过程，相当
于终端适配器。
5、FUNI(Frame Based UNI Interface)
FUNI的意义与 DXI相似，FUNI 将ATM适配功能完全移入了交换机内部，终端和ATM交换机
之间传送FUNI 帧，所以与基于信元的DXI 接口相比，FUNI在接入线上有更高的效率。
VPI/VCI 号放置在ATM信元的信头，信元头部格式如下：
HEC:信头错误控制：
信头错误控制(HEC)机制提供了两项重要的功能：
1、ATM信头差错的检测和校正
2、信元定界
ATM信头差错检测和校正
信头差错控制在整个的信元头(在发送端)上完成一CRC 8 的计算。每个信元都有一个5字节
的头部，头部中包括 4 字节的虚拟电路及控制信息和 1 字节的校验和。校验和只包括了前 4 个头
部字节，而不占用有效载荷字节。它是由32个头部位除以多项式x^8+x^2+x+1 后，所得的余数构成的。校验和加上常数01010101。
做出只校验头部的决定，是为了减少由于头部错误，而造成不正确传递信元的可能，也为了
避免其校验开始要大得多的有效载荷字段的校验。如果确需校验有效载荷字段，就要上到较高的
层上完成这一功能。由于校验和字段只位于头部，因此这 8 位校验和字段被称为头部错误控制
HEC(header error control)。
接收HEC算法能够完成
1) 单比特的错误校正
2) 多比特的错误检测
信元定界：
利用HEC域完成信元定界的功能以识别信元的边界， 信元定界的算法是通过利用头中的32个防止
错误的信头比特和8个控制比特间的相关性来完成。如下图：
确的HEC
在捕获状态，定界过程是通过比特接比特地检验假设信头域中的正确的HEC来完成。一旦找
到，运行机制即进入预同步状态。在捕获状态，自同步加扰器是被禁能的。(加扰器只被用于信息
域，而不被用于信头)。在预同步状态，定界是由检查信元接信元的HEC相关性来完成的。在同步
状态，信元定界会丢失掉，如果出现7次连续的不正确的HEC时，重新进入捕获状态。
CLP信元丢失优先级
信元丢失优先级域(CLP)被用来严格地指示出在一个给定的连接中的信元的优先级
CLP＝0 指示一连接中的“高优先级”信元；
CLP＝1 指示一连接中的“低优先级”信元。在遇到拥塞的情况下，一个 ATM网络元素可以有选择地在删除高优先级(CLP=0)的信元之前删除低优
先级 (CLP=1)的信元。 这一CLP应用很类似于帧中继承载业务中的Discard Eligibility(DE)功能。 CLP与 ATM
的流量控制策略和业务质量 (QOS)参数密切相关。
PT载荷类型
载荷类型字段有3位，分别表示：净荷类型，帧结尾和拥塞情况。
第一位用于区分OAM信元和用户数据信元，PT的第二位为拥塞状况，任何拥塞的ATM网络元素可以
按下面方式改变 PTI 值：以 PTI＝000 或 010 接收的信元可以按 PTI＝010 发送出去；而以 PTI＝001 或 011
接收的信元可以按PTI＝011 发送出去。没有拥塞的网络元素不应该改变PTI。
详细的PT值分类如下：
预分配信头值：
43.1.6 AAL层
ATM适配层用于和高层和ATM之间的通讯，高层信息类型为语音，数据或视频。
ATM网络的AAL层与TCP具有本质区别，其主要原因是设计者对传输音频和视频数据流更有兴趣，为
此迅速传送比精确地传送更重要。ATM层连续输出53字节的信元。信元中没有差错控制、没有流量控制
以及其他种类的控制。所以，它不能很好地满足多数应用的要求。为了弥补这一不足，在建议 I.363 中，
ITU在ATM层之上定义了一个端到端的层。这一层称为ATM适配层AAL(ATM adaptation layer)，
AAL 的目标是向应用提供有用的服务，并将它们与在发送端(方)将数据分割为信元、在接收端将信元重新组织为数据的机制隔离开来。它按照3个坐标轴来组织服务空间：
1、实时服务和非实时服务。
2、恒定比特率服务和变化的比特率服务。
3、面向连接的服务和非连接的服务。原则上，用3个坐标轴和每个坐标轴上的2 个值可以定义8种不同的服务, ITU觉得只有其中的4个有
使用价值，并分别命名为类 A、B、C、D。其他几种则未得到支持。从 ATM4.0 开始，主要的不同是传输
类(ABR、CBR、NRT-VBR、RT-VBR和UBR)之间，而不是这些AAL支持的服务类之间。
恒定比特率CBR(constant bit rate)--Class A
主要用来模仿铜线或者光导纤维。没有差错校验，没有流量控制，也没有其余的处理。这个类
别在当前的电话系统和将来的 B-ISDN 系统中作了一个比较圆滑的过渡，因为话音级的 PCM 通道，
T1电路以及其余的电话系统都使用恒定速率的同步数据传输。
可变比特率VBR(variable bit rate)--Class B/C
VBR划分为两个子组别，分别是为实时传输和非实时传输而设立的。RT-VBR主要用来描述具有
可变数据流并且要求严格实时的服务，比如交互式的压缩视频(例如电视会议)。NRT-VBR用于主要
是定时发送的通信场合，在这种场合下，一定数量的延迟及其变化是可以被应用程序所忍受的，
如电子邮件。
可用比特率ABR(available bit rate)--Class C/D
为带宽范围已大体知道的突发性信息传输而设计的。ABR是唯一一种网络会向发送者提供速度
反馈的服务类型。当网络中拥塞发生时会要求发送者减小发送速率。假设发送者遵守这些请求，
采用ABR通信的信元丢失就会很低。运行着的ABR有点象等待机会的机动旅客：如果有空余的座
位(空间)，机动的旅客就会无延迟地被送到空余座位处；如果没有足够的容量，他们就必须等待(除
非有些最低带宽是可用的)。
未指定比特率UBR(unspecified bit rate)--Class C/D
不做任何承诺，对拥塞也没有反馈，这种类型很适合于发送 IP 数据报。如果发生拥塞，UBR
信元也会被丢弃，但是并不给发送者发送反馈，也不给发送者希望放慢速度的期望。
AAL层必须将这些大小不等的数据流分割为48字节的净荷。AAL层分为2层：
1．会聚子层(CS)
服务特定会聚子层(SSCS)
公共部分会聚子层(CPCS)
2．分装和重组(SAR)子层SSCS部分与各种业务的特性相关联，CPCS 则通过在帧前后加入可变长度的填充字符来成48字节帧和
进行错误检测。
各AAL层特征如下：
AAL1：在各种类型的CBR业务间提供多种共同的程序：检测丢失/误插入信元，定时信息，结构信息，
前向差错校验(FEC)
AAL2：为节省带宽，对时延敏感的应用， 提供在单个 VCC 中复用多达 255 个用户数据的一种手段，
用于传送短和可变长度的分组
AAL3/4:提供检测用户数据的差错手段，用于无连接业务的适配
AAL5：提供检测用户数据的差错手段，以及提供把破坏的数据前转给用户的能力
43.1.7 AAL1
AAL1向用户提供了恒定比特率的数据传输能力，并提供传送定时信息和结构信息的能力。在必要时
还能够提供一定的纠错能力和报告错误的能力(包括丢失和错误插入的信元，以及信头错误等).
AAL1中对用户数据不使用通常的检错码。在需要低误码率时采用前向纠错(FEC)。理论上不可能使误码率降低为0。以恒定比特率传输数据时，若收发双方的用户时钟不能同步，则会发生滑码。若不允许滑
码现象的出现，则收方用户时钟必须与发方用户时钟严格一致。
AAL1中提供的传送定时信息的能力，就是传送发方用户时钟同步信息的能力。用户所传送的恒定比
特率数据中通常总是具有某种结构。如数字一次群和高次群中的帧结构。这体现为用户传送的比特流被
划分为一些段落，在这些段落中的不同位置上的各个比特的意义往往并不相同。为使收方能够正确划分
出这些段落，发方必须把这些段落的起始和终止位置通知对方。AAL1 中的传送结构信息的能力，指的就
是传送这些起始和终止位置的能力。由于数据传送是恒定比特率的，所以必然是连续不断的，因此，一
个段落的终止位置必然就是下一个段落的起始位置。这即意味着只需指明两个段落的边界。
AAL1可以进一步划分成分段重组(SAR)子层和会聚子层(CS)。
在发送端，AAL-SDU就是CS-SDU，它经过CS 子层后成为CS-PDU， 并做为SAR-SDU送至SAR子层，
经过SAR子层后成为48字节数据块，即SAR-PDU。SAR-PDU就是AAL-PDU。
在接收端，SAR 子层从 ATM 层接收 SAR-PDU，即 AAL-PDU，经处理后成为 SAR-SDU。SAR-SDU 做为
CS-PDU，送至 CS子层，经CS 子层后成为CS-SDU，即AAL-SDU。
SAR子层向CS 子层提供：SAR-SDU的序号；CSI比特以及SN 字段是否可用(即指明是否含有
不可纠正的错误)。
CSI比特的值由 CS子层提供。SNP(SequenceNumberProtection)是SN字段的CRC校验码，使
用多项式x^3+x+1。第4个比特是偶校验码，用于前面7 个比特的偶极性校验。
AAL1的CS子层：
CS 子层的功能是：处理 SAR-SDU 的序号，传送时钟信息和结构信息以及纠错。AAL1 规定
了两种实现业务时钟同步的方法－同步剩余时间标志法 SRTS(SynchronousResidualTimeStamp)和
自适应时钟法(AdaptiveClockMethod)。
解释：在 ATM 物理层，收发信息的双方是时钟同步的。这个时钟称为是 ATM 系统时钟。
由于存在ATM 系统时钟，因此只要接收方知道业务时钟和ATM系统时钟的比值，就可以由ATM
系统时钟将业务时钟精确地恢复出来。通常，接收方可以事先知道业务时钟的标称值。因此，
我们需要知道的仅仅是实际使用的业务时钟和标称值的偏差。值得重点说明的是：此偏差可以
利用CSI比特进行传送。结构消息传送(SDT)
如果AAL1用户传送的信息中包括某种结构，则需要在传送数据的同时把结构消息也传送过
去。在实际应用中，有许多种信息包含着某种结构(如数字一次群或高次群中的帧结构)。
AAL1规定了采用CSI比特来传送结构消息。为此存在两种SAR-PDU格式，一种叫做非P格
式，一种叫做 P 格式。在非 P 格式中，SAR-PDU 净荷的 47 个字节都用于传送用户信息；而在 P
格式中，SAR-PDU 的第一个字节是一个指针，用于指示用户信息结构的起始位置，其余的 46 个
字节用于传送用户信息。为防止与时钟信息的传送发生矛盾，规定只允许 CSI 比特 0，2，4，6
可以是P格式。CSI比特为0 时代表非P格式；而为1时代表P格式。
用户信息的纠错保证
AAL1 规定了一种纠错方法，可以用来传送误码率要求极低的信息。AAL1 用户可以选择是
否使用这种方法。AAL1中的 RS码造成了一个128 x 47个字节的矩阵，而后作为128 个信元发送
出去，相当于在每 124 个装载用户信息的信元后面都附加了 4 个 RS 码信元。RS(128,124)码可以
用于纠正两个错误字节或恢复 4 个已知位置的丢失字节。由于使用了 SAR-SDU 序号，所以在发
生信息丢失时，丢失字节的位置是可以知道的。43.1.8 AAL2
AAL1是针对简单的、面向连接的、实时数据流而设计的，除了具有对丢失和误入信元的检测机制外，
它没有错误检测功能。对于单纯的未经压缩的音频或视频数据，或者其中偶尔有一些较重要的位的其他
任何数据流都没有什么问题，AAL1就已经足够了。
对于压缩的音频或视频数据，数据传输速率随时间会有很大的变化。例如，很多压缩方案在传送视
频数据时，先周期性地发送完整的视频数据，然后只发送相邻顺序帧之间的差别，最后再发送完整的一
帧。当镜头静止不动并且没有东西发生移动时，则差别帧很小。其次，必须要保留报文分界，以便能区
分出下一个满帧的开始位置，甚至在出现丢失信元或坏数据时也是如此。由于这些原因，需要一种更完
善的协议。AAL2就是针对这一目的而设计的。
AAL2 同样将会聚子层分为 CPCS 和 SSCS 两层。SSCS
为AAL2的独立用户提供AAL2 与高层应用的连接， CPS提
供的功能是提供识别 AAL2 用户的基本结构，查错，封装
和分解各种净荷。AAL2 的独特之处在于它允许在一个
ATM信元中或跨越多个信元存在可变长度的净荷。
AAL2 可以通过 CID 字段标示 AAL2 的用户信道，该
字段为8位，由于1~7被ITU占用，故能支持248个用户
信道
AAL2协议结构如下：
CID： 信道标识符（8比特）
LI： 长度指示（6比特）
UUI： 用户到用户指示（5比特）
HEC： 信头差错控制（5比特）
INFO： 信息（1－45/64字节）
CID＝0： 未使用
CID＝1： 预留给层管理对等层到对等层程序
CID＝2－7： 预留
CID＝8－255： AAL2 CPS用户实体标识
CPS-PP 的大小依赖于分组填充时延(PFD)和提供给每一语音汇聚的带宽。PFD 是把 AAL2-PDU 组装和
分段为信元所需的时间， 对PFD进行配置，可以改变语音的时延特性以成为AAL2的ATM适配段。不同
的语音电路可能会有不同的最小时延需求。AAL2 可用于第三代移动通信接入网络(如 W-CDMA)。可借助独立于 ATM 信令的全新 AAL2 信令来快
速、灵活地建立AAL连接。
43.1.9 AAL3/4
开始时，ITU 为服务类 C 和 D 制订了不同的协议（服务类 C 和 D 分别是对数据丢失或出错敏感，但
不具有实时性的面向连接和非连接的数据传输服务类）。后来 ITU 发现没有必要指定两套协议，于是便将
它们合二为一，形成了一个单独的协议，即AAL3/4。
AAL3/4可以按两种模式进行操作，即流和报文。在流模式中不保留报文分界信息。以下将集中讨论
流模式。在每种模式中都可能出现可靠的传输和不可靠的（即不保证可靠性）的传输。AAL3/4 具有一个
其他协议中没有的性能--支持多路复用。 AAL3/4的这一功能允许来自于一台主机的多个会话（如远程登录）
沿着同一条虚电路传输并在目的端分离出来。使用一条虚电路的所有会话得到相同质量的服务，因为这
是由虚电路本身性质所决定的。
和 AAL1、AAL2 不一样，AAL3/4 具有会聚子层协议和 SAR 子层协议。从应用程序到达会聚子层的报
文最大可达 65535 字节。首先将其填充为 4 的整数倍字节。接着加上头和尾信息。在会聚子层对保温进
行了重构，并加上了头和尾信息后，便将报文传送给 SAR子层，由SAR 子层将报文分为最大44字节的数
据片。AAL3/4 具有两层协议开销：每个报文需要增加 8 字节，每个信元增加 4 字节。总之，它是一种开
销极大的机制，尤其是对短的报文。
CPCS-PDU格式如下图：
1. 公共部分指示符(CPI)：用来指示消息类型、解释接下来的字段和计数单元(默认编码为
0000 0000，用于按字节计数)。
2. 开始标志(B-Tag)：与尾中的End Tag 结合起来，来检测错误/误装配条件。
3. 缓冲器分配(BA)大小：被用于数据帧所需的最大缓冲器要求。
4. 垫塞(Pad)：被用于对CPCS-PDU载荷进行32 比特的校准。取值范围为0－3个字节。
5. 对准：这一字段被用于尾的32比特对准。其它编码没有被规定。
6. 结束标志(E-Tag)：与B-Tag字段相关起来，用于CPCS-PDU的错误/误装配控制。
7. 长度(Length)：指示出CPCS-PDU载荷字段的长度。也可与B/E-Tag关联起来，以进行差错
控制。AAL3/4-SAR格式：
1. 段类型(ST)：这一字段被编码成用来指示出该SAR-PDU是消息开始BOM、消息继续(COM)、
消息结束(EOM)还是单段消息(SSM)。
2. 序列号(SN)：指示CPCS-PDU段中的序列号。
3. 消息识别符(MID)：这一字段提供了能力以进行多个 AAL 连接的复用/去复用(交织)(在一条ATM连接上)。这一能力也可被用于无连接的传输。
4. 垫塞(Pad)：用来将SAR-PDU 载荷调整为44 字节。此字段被编码为全0。
5. 长度指示符(LI)：按字节数指示出用户信息的长度。
6. CRC：CRC-10被用于检测错误。CRC的计算是在整个的SAR-PDU上进行的。
AAL 类型 3/4 的 CPCS 能够提供广泛的错误检测/序列号能力以用于可靠数据的传输和将来功能的增
强，但实现上相对复杂。AAL 类型 3/4 的 SAR 功能提供了复用和错误检测/序列校验能力，但实现上相对
复杂且效果不是很有效。
43.1.10 AAL5
从 AAL1 到 AAL3/4 协议主要是由电信工业设计的并被 ITU 标准化，它没有太多地考虑计算机工业的
要求。由于两个协议层所导致的复杂性及低效性，再加上校验和字段十分短（仅 10 位），使一些研究人
员萌生了一个制订新的适配层协议的念头。该协议被称为简单有效的适配层 SEAL(simple efficient
adaptation layer)，经过论证，ATM论坛接受了SEAL，并为它起名叫AAL5。
AAL5向其应用程序提供了几种服务。一种选择是可靠服务（即采用流控机制来保证传输，以防过载）；
另一种选择是不可靠服务（即不提供数据传输保证措施），通过选项使校验错的信元或者丢失或者传送给
应用程序（但被标识为坏信元）。AAL5支持点到点方式和多点播送方式的传输，但多点播送方式未提供数
据传输的保证措施。
像AAL3/4一样， AAL5支持报文模式和流模式。在报文模式中，应用程序可以将长度从1 字节~65535
字节的数据报传送到 AAL 层。当到达会聚子层时，将报文填充至有效载荷字段并加上尾部信息，选择填
充数据（0 字节~47 字节），以使整个报文（包括填补的数据和尾部信息）为 48 字一节的整数倍。AAL5
没有会聚子层头，只有一个8字节的尾。
用户到用户UU（User to User）字段不用于AAL层本身，而是为了自己的目的供更高一层（可能是
会聚子层的特定服务子部分）使用，例如，排序或者多路复用。长度（Length）字段指出真正的有效载荷
是多少，以字节为单位，不包括填充的字节数。0值用于终止未传送完毕的报文。CRC 字段是基于整个报
文的标准32位校验和，包括填充数据和尾部信息（CRC字段设置为0）。尾部的一个8 位的字段留作将来
使用。报文交给SAR子层，然后发送出去。在SAR子层不增加任何头、尾信息，而是将报文分成48字节
的单元，并将每个单元送到 ATM 层进行传输。它还通知 ATM 层将最后信元的 PTI 字段置为 1，以便保留
报文分界。（这时出现了一个问题：这是一种不正确的协议层混合体，因为 AAL 层不该使用 ATM 层的头
部信息。）AAL5较AAL3/4 的主要优点是更加高效。虽然AAL3/4对每个报文只增加4字节的头信息，但它还要
为每个信元增加4字节的头信息，因而使有效载荷的容量减少到44字节，对于长的报文，无效数据占8%。
AAL5的每个报文有一个稍大的尾部（8字节），但每个信元无额外开销。信元中没有顺序号，可以通过长
的校验和来弥补，从而可以检测丢失的、误插的或错误的信元，而不需要使用顺序号。
在因特网中，与ATM网接口的一般方法是使用AAL5的有效载荷字段来传输IP分组。
AAL5的CPCS-PDU如上图所示：
1. CPCS-PDU载荷：被用于运载CPCS-SDU(用户信息)。该字段是字节调整的，其长度范围可以
从1 到65535 个字节。
2. 垫塞(Pad)：被用于将CPCS-PDU凑成48个字节的整倍数，以利于SAR使用。此Pad 的范围
可以从0到 47 个字节，可取任何编码(例如全0)。
3. CPCS用户到用户指示CPCS-UU(CPCS User-to-user indication)：被用于透明地传输用户到用户
的信息。
4. 公共部分指示 CPI：用于将尾调整到 64 比特边界。默认的编码为 0。这一字段也可被用于
消息类型功能(在将来)以区分例如管理消息。
5. 长度(Length)：被用于指示出按字节计算的 CPCS-PDU 载荷的长度。当被置为零时，它指示
出异常中止功能。
6. CRC：CRC-32被用于对整个的CPCS-PDU进行错误的检测。各种AAL协议似乎不必要地相似，并且考虑得很不周到，把会聚子层和SAR子层区分开也是有疑问
的，尤其是因为 AAL5 的 SAR 子层并无任何自己的特点。用稍微增强一些的 ATM 层头部信息来提供像排
序、多路复用和数据分帧的功能便足够了。
AAL 给人的整体印象是变体很多，变体之间存在很多细微的差别，而且尚未完工。原来的 4 个服务
类 A、B、C、D 实际上已被废除。AAL1 可能确实没有必要存在；AAL2 不完整；AAL3 和 AAL4 永无出头之
日；AAL3/4 效率低而且校验和字段位数太少。
将来的一切都依赖于 AAL5，但到目前为止，AAL5 尚有很多改进的余地。AAL5 报文应该有一个顺序
号和一位用于区分数据还是控制报文的标志位，从而可以成为一种可靠的传输协议。可以用尾部的未用
空间来实现上述功能。 -
2009-03-01
理解网络协议ICMP, IP, TCP - [网络]
理解和使用ICMP协议
随着本讲座开始接触涉及路由的层，我们必须暂时停一下。我们需要关注一下最容易误解的协议:ICMP(互联网控制消息协议 )。经理人和网络管理员如果计划制定防火墙决策就要了解ICMP协议的真正用途，而且网络管理员要能够使用ICMP协议的知识全面理解路由问题。
既然IP网络不可靠并且不能保证信息传递，因此当发生问题时通知发送人是很重要的。ICMP协议是一种提供有关阻止数据包传递的网络故障问题反馈信息的机制。 它让TCP等上层协议能够意识到数据包没有送达目的地，ICMP协议提供一种查出灾难性问题的方法。这些灾难性的问题包括“TTL exceeded”(超过生存时间)和“需要分更多的数据段”等。ICMP协议不报告IP校验失败等常见的问题。这是因为我们假定TCP或者其它可靠的协议能够处理这类数据包损坏的问题。而且，如果我们使用UDP等不可靠的协议，我们就不应理会较小数量的数据损失。
反之，网络问题需要立即报告。例如，如果IP TTL值(IP生存时间)将达到零，这就可能是网络的某个部分发生了路由环路问题，这样将没有任何数据包能发送到目的地。端点系统需要了解这些类型的故障。ICMP是一种发送各种消息报告网络状态的协议，而非仅仅是简单的ping(联通性测试程序)。回应请求（echo request）仅是ICMP协议提供的众多消息之一。Ping信息可以被过滤掉。但是，大多数ICMP消息类型是IP、TCP和其它协议正常运行所需要的。永远不要相信ICMP协议是邪恶的并且简单的封锁这个协议。
ICMP协议本身非常复杂。每一种类型的ICMP消息也称“主要类型（major type）”拥有自己的“子类型编码（minor codes）”。ICMP协议工作在第3层，因此，它能够在互联网上路由。一个ICMP数据包实际上就是一个IP数据部分包含ICMP协议数据的IP数据包。每一个ICMP消息都将包含引发这条ICMP消息的数据包的完全IP包头，这样，端点系统就会知道实际上哪一个数据包没有发送到目的地。另外引发此ICMP消息的数据包的前8个字节也将包括在内，这通常是TCP或者UDP包头。
简略的说，ICMP协议消息包含永远不会变化的三个字段，随后是ICMP数据，然后是引发此消息的源IP数据包包头。不会变化的三个字段中，前8个字节包含ICMP类型(主要类型)、第二个字段包含了类型代码、第三个字段是ICMP消息校验值。
我们需要认识到，ICMP协议在某些情况下不会发送错误信息。ICMP不会对ICMP信息做出响应。如果ICMP回应其它ICMP消息，这些消息的数量会爆炸性增长而演变为一场ICMP消息风暴。为了防止出现广播风暴，ICMP消息也不会回应一个广播或者多播地址。
最有用的ICMP数据包类型“目标不可达”（类型三）的消息。错误消息一般由路由器生成，并且发送给数据包的来源。大多数错误信息还将发送给与发送的数据包有关的应用程序。在这种情况下，TCP协议将广泛使用ICMP协议。我们在后面将很快看到这种情况。
在IPv4协议中最常用的ICMP消息类型有以下几种:
•回显应答(类型0)和回显请求(类型8):这是Ping程序发送的信息。
•目标不可达(类型3)
•源抑制(类型4):这是一种用于通知发送者路由器或者主机出现阻塞现象的ICMP消息，发送者需要降低发送速度。
•重定向(类型5):这个消息用来向可以访问两台路由器的主机说“请使用另一台路由器”。我们在此系列讲座中未来的路由问题中再详细讨论这个问题。
•路由器信息应答(类型9)和路由器信息请求(类型10)
•超时(类型11):这个消息有两种用途。第一，当超过IP生存期时向发送系统发出错误信息。第二，如果分段的IP数据报没有在某种时限内重新组合，这个消息将通知发送系统。
当然，上述各种类型的消息中都包含子类型代码。类型三消息“目标不可达”本身有15个子类型代码。我们就不提供每一项的细节了。但是，ICMP协议中有一项非常重要的应用要依靠类型三的消息。
路径最大传输单元(PMTU)是各种协议用来寻找整条路径中支持的最大的MTU(最大传输单元)的机制，小于此限制的数据可以不用分段。发送者在其本地接口设置最大的数据包规格，然后，在IP包头中使用DF(不要分段)的标记发出数据包。如果有问题发送者就会收到第三种类型的ICMP错误信息，其子类型代码是“要求分段，但是已经设置了DF标记”。当发生这种情况是，发送者知道它必须要减小发送数据的规格。如果没有返回错误信息，这就表明MTU的设置没有问题。
在查找PMTU时的主要问题是人们常封锁ICMP协议，阻止这个报错信息传递到发送数据的主机。这种情况很多时候发生在你设法连接的远程站点。假如你向一台Web服务器发送一个请求，但是，一个空白页却不断出现。在虚拟专用网连接上的人们经常会看到这种情况，这是因为由于有的虚拟专用网封装的额外的文件头，它们的MTU比通常的容量要小一些。当远程Web服务器向虚拟专用网用户发送其要求的内容时，如果数据包太大，用户前面最后的路由跳数需要为这个数据分段。如果发送方设置DF标记之后，它能做的一切就是通知发送者必须发送较小的数据包。但是，发送者封锁了ICMP协议，因此这个网站将永远不会看到这种ICMP信息。不过一个好消息是大多数TCP协议的执行都是智能化的。如果它们一直得不到发送数据的许可，它们会自己以较小的分段尺寸发送数据。但是，如果你使用某些流行的、操作方便的操作系统，这种机制并没实现。
简言之，封锁ICMP协议对于成功地运行网络是有害的。这不仅会破坏ping，事实上，如果ICMP协议不工作，许多协议都将不能完全发挥作用。
小结
ICMP包括许多种类型的用于各种用途的数据包，每一种类型都有子类型代码，用于指明这些消息类型的具体内容。
查找路径最大传输单元能够让规格正确的数据包在各种数据包容量的链路上传送。
ICMP对于恰当的路由和数据包传递是非常重要的，你只能封锁你不需要的那一些消息。
IP协议介绍
本文将介绍理解路由问题所需要的IP协议知识。互联网上的大多数东西都使用IP协议。与以太网不同，了解这个协议对于理解网络在更大范围的应用非常重要。在以后发表的文章中，这个讲座将介绍TCP和UDP协议、路由理论、然后再深入研究具体的路由协议。
IP协议直接位于2层数据链路层之上，负责生成发往目的地的数据报。IP协议原来在RFC 791中定义，后来进行了修改并且进行了多次重新修订。但是，IP协议的基本设计思想仍没有变。IP层不提供任何类型的流量控制或者排序功能。这些功能留给上层。我们将使用“数据报” (datagram)这个词汇指一个完整的IP信息，使用“数据包”(packet)这个词汇指一个单个的IP数据包。
IP协议负责接收和发送指定IP地址数据包。但是，IP协议并不保证数据传递的可靠性。在IP协议层中没有“重试一下”的概念。由于各种原因，数据包有可能出现丢失、损坏、重复、不按照顺序传递或者延迟等问题。IP协议还负责处理IP选项并且以ICMP错误和控制消息等方式提供反馈信息。
IP数据报头有20个字节长，紧接在2层报头后面(因为IP协议是第3层协议)。IP数据部分包含一个完整的TCP或者UDP数据包等一切其它的信息，如下面的图表所示。还要指出的是，如果使用IP选项，IP数据报头可以超过20个字节。
以太网报头IPv4包头数据(TCP等)IP协议的目标很简单:生成发往目的地的数据报，而且除了把这个数据包发送到下一跳路由器之外，不需要担心任何事情。实际上，IP协议很复杂，否则，IP数据报头就不需要那么多的字段。认真研究IP数据报头是非常重要的。这些字段从第一个字节开始的含义是:
•版本:使用的IP协议的版本。IPv4数据包将把这个字段设置为“4”。
•报头长度:以4个字节的倍数的方式说明报头的长度。因为很少使用IP选项功能。因此，你很可能你看到它的值将是“5”，意味着报头的长度是5个4字节，也就是20个字节。
•服务类型:这个字段很少使用。但是，在理论上，这个字段旨在向路由器提供转发队列中特定IP数据报优先级顺序信息。主要用于提高服务质量。主机可以选择设置各种选项，如低延迟、高数据吞吐量或者高可靠性等。大多数路由器都忽略这些选项。
•总长度:以字节为单位具体说明包括报头在内的整个IP数据包的总长度。因为这个字段有16位，所以IP数据包长度限制在65K之内。这个数字定义的是字段所在的IP数据包，而不是整个IP数据报的长度。
•IP数据报ID:有时候称作“段标识符”。这个标识符用来确定一个具体的IP数据包属于哪一个IP数据报。如果IP协议需要把多个单个的IP数据包组合成一个IP数据报，这个字段是必要的。
•标志:DF(不分片)位在这个字段中用来指示路由器不要把IP数据包分段。这里也可以使用MF(更多地分片)标识。
•段内偏移量:原来数据报中的分段的偏移量，用64位的块表示。
•生存时间(TTL):IP数据包在被销毁之前包含的跳数。生存时间是为了避免无法发送的数据包永远在互联网上流动。
•协议类型:具体指明下一个协议。也就是在IP数据包的数据部分中将遇到的报头。
•头校验和:一个报头的校验和，而不是数据的校验和。
•IP源:原来发送数据包的主机的IP地址。
•IP目的地:IP数据包目的地主机的IP地址。
当路由器收到一个IP数据包的时候，路由器首先要检查这个数据包的目的地。如果这台路由器有一个通向目的地的路由，这台路由器将减少这个数据包的TTL，重新计算校验和，然后再把这个数据包发出去。如果出现错误，将会发出相应的ICMP错误通知，这个数据包将被丢弃。IP协议就是以这种最简单的方式工作的:它遇到每一个数据包都要重复上述的步骤。
IP分段对于IP功能是非常重要的，它提供了这些报头字段的真正含义。并非每一个发送数据包的物理网络都能够接受同样大小的数据包。各种各样的2层帧格式允许同时发送不同大小的数据。允许的最大的MTU是65KB，最小的是68字节。RFC 1122规定，所有的主机必须能够重新组合最多为576字节的数据报，但实际上是应该能够重新组合与系统接口的MTU规格相同的数据报。
当在互联网上发送一个IP数据报的时候，你不知道沿着每一个2层链路前进的MTU将发生什么情况。你可能通过以太网连接自己的ISP。但是，你正在设法访问的远程站点也许是在一个ISDN链路上。因此，你的IP数据包在到达最后一个跳点之前必须要分段。分段可能需要进行多次。如果我们要向一个通过ISDN连接的远程站点发送一个2000个字节的数据包，我们原来可能把这个数据包分段以便符合我们的1500个字节的链路要求。但它大于576字节(ISDN的MTU)。因此，在到达ISDN链路之前的最后一个路由器必须还要对这个数据包分段。
应该知道，IP不是一个可靠的协议。因此，如果任何IP分段在传输的路径中丢失，整个数据报必须要重新发送。IP没有办法要求得到数据报中丢失的特定部分。因此，当出现错误时，其结果是重新发送该数据报所有的分段。有时候，阻塞的路由器不得不丢弃一些数据包。如果被丢弃的数据包恰巧是一个65KB数据报的一部分，那么，整个数据报必须要重新发送。TCP或者其它上层协议一般都知道一个完整的数据报是否全丢失了，并且能够要求重新发送。然而，TCP协议不能告诉你一个数据报的片段是否丢失了，因为IP收到数据报将是不完整的，并且永远不会向上层TCP协议发送这个数据报。如果TCP协议从来没有收到这个数据报，这个数据报最终将被重新发送。显然，65K数据包的一小部分的丢失对于缓解一个阻塞的链路并没有什么帮助，而是会引起更严重的阻塞。UDP应用程序发送时的大小一般不超过576字节，这有两个原因。第一，MTU小于576字节的链路并不多，因此，这个IP数据报将不会分段。第二，要记住，576是所有采用IP协议的端点系统的特殊数字:它们必须能够把数据报重新组合为这个大小。配置有限内存的设备对于处理大于这个规格的数据可能会遇到困难，因此，这个做法值得推荐。
假设我们是一台主机，我们想发送一个1550个字节的数据报(1530个字节的数据+20个字节的报头)。但是，我们的MTU是1500个字节。我们必须要分为两个数据包发送，相关的IP报头看起来是这样的:
• fragment 0, offset = 0, size = 1480, MF位设置.
• fragment 1, offset = 1480, size = 50
分段中的IP ID和IP地址总是与原来IP数据报中内容是一样的。但是，报头的校验值、偏离量和字段长度肯定要发生变化。当另一方收到第一个数据包并且看到这个数据包是一个分段的时候，另一方将等待获得其它的分段，并且把这些分段重新组合在一起，然后再发送给上层协议。
在这个数据报发出之后，假如在IP标志中没有设置DF字节，我们就不会听到任何有关这个数据报的消息。但是，如果这个链路的某一个地方的MTU是400字节会发生什么情况呢?在可以发送1480字节的数据包之前，这个链路中的路由器会先对这个数据包分段。上一篇教程的MTU路径可用来解决中间路由器为数据包分段的问题。分段要耗费时间和宝贵的路由器资源。我们避免过度分段的主要原因就是因为过度分段将不可避免地引起通信的延迟。
对数据包的重新组合总是在最后的目的地完成。因此，中间路由器不需要存储IP数据报。这也意味着IP数据包能够在不同的路径上单独地路由，而不会引起混乱。这是一个需要理解的重要的概念。这将使IP协议有多种用途。无论接收方以什么顺序收到这个数据包，接收方都能够根据IP报头中的分段偏移量字段重新把数据报组合起来。
现在，我们理解了分段。我们发现分段提出了这样一个问题:IP真的与数据链路层无关吗?
小结
IP协议是不可靠的。当IP数据包丢失的时候，要更高一层的协议认识到数据包的丢失并且要求重新发送。
路由器在每一次发送IP数据包的时候都必须要重新计算IP报头的校验值。
IP分段能够让路由器延迟发送一个数据包或者在多个链路上发送数据包。端点系统将能过重新组合整个IP数据报。
TCP协议介绍
仅仅介绍为了让你理解下一篇关于TCP协议的讲座所需的知识。经过本文的学习你会了解一些TCP相关的术语，理解TCP包头的各组成部分，然后，我们将在后面一篇文章中重点讲解TCP协议常见的一些问题，包括TCP窗口可伸缩性问题、阻塞和TCP连接机制等问题。
我们有时候听到人们提到“TCP/IP协议栈”。这意味着他们在谈论1至4层和7层的问题，TCP协议位于第四层。其代表的含义是传输控制协议(Transmission Control Protocol)。还记得IP协议那篇文章中的协议头的构成吗?当一个数据包被封装之后，第三层当然有个IP协议头，紧接着就是这个TCP协议头。TCP协议头成为了IP协议头中的“数据”。就像其它协议都有自己的术语一样，TCP协议也有自己的专门术语，如以太网帧、IP数据报和现在的TCP段等。你可以把它们都当作数据包。但是，当它们之间在进行通讯的时候，一定要使用正确的术语。
TCP协议是一种端对端的协议。使用TCP没有任何广播或类似的概念。要用TCP协议与另一台计算机通信，两台机之间必须像打电话一样连接在一起，每一端都都为通话做好准备。“流传输”(Stream delivery)是谈到TCP时的另一个常用词语。这个短语的含义是TCP协议主要用来处理数据流，可以正确处理乱序的数据包。TCP协议甚至还允许存在丢失的或者损坏的数据包，最终它可以再次得到这些数据包。你很可能听一位程序员在谈论“流”的概念。他指的是这样一个事实:数据到底是在什么时候发送的是很难说清楚的，你也可以在TCP流中发送非结构化数据。TCP协议以它自己的方式缓存数据。不过，其缓存过程对程序员和用户是透明的。
TCP协议每发送一个数据包将会收到一个确认信息。这种发送/应答模式是提供可靠的协议的唯一方法:你必须让对方知道你否收到了数据。当然，这也会造成一些性能损失，而人们需要改善系统效率不高的状况。所以引入了“捎带确认（piggybacking ACKs）”的方法。TCP协议之所以是全双工的就是因为这个“捎带确认”信息，因为它允许双方同时发送数据。这是通过在当前的数据包中携带以前收到的数据的确认信息方式实现的。从提高网络利用率的角度看，这比单纯发送一个通知对方“信息已收到”的数据包要好得多。最后，还有一个批量确认的概念：也即一次确认一个以上的数据包，表示“我收到了包括这个数据包在内的全部数据包”。
在IP协议中，我们处理的单个数据包是一个更大的数据报的一部分。请记住，一个TCP段就是一个单个的TCP数据包。TCP是一个数据流，因此，除了“连接”之外，没有任何需要真正担心的其它概念。最大报文段长度(MSS)是在连接的时候协商的，但是，它总是在不断地改变。默认的最大报文段长度是536字节，这是576字节(IP协议保证的最小数据包长度)减去用于IP头的20个字节和用于TCP头的20个字节以后的长度。TCP协议要设法避免在IP级别上的分段。因此，TCP协议总是从536字节开始的。
TCP协议最有魅力的功能仍然保留着。这就是滑动窗口协议。这个窗口实际上是已经发出的“没有签收确认的”数据总数。这个窗口可以根据意愿放大和缩小。这是很有趣的。下一讲将介绍这方面的内容。
一个TCP数据包的头是20个字节，就像一个IP数据包一样。如果使用一些选项，IP和TCP数据包头都可以放大。TCP头不包含IP地址，它仅需要知道要连接哪一个端口。不过，你不要被这弄晕了。TCP工作时要一直跟踪状态表中的端对端的连接。这个状态表包含IP地址和端口。这就是说，只是TCP头不需要IP信息，因为它来自于IP头。
把一个数据包设想为一个字节跟着一个字节的数据流是很容易的。很多人都想要一个显示TCP头的表格。但是，这常会把事情搞乱。TCP头从第一位开始依次是下面这些内容:
•源端口，16位:用于这次连接的本地TCP端口。
•目的地端口，16位:通讯目标机器的TCP端口。
•序列号，32位:用来跟踪数据包顺序的号码。
•确认编号，32位:我们确认的以前收到的序列号。
•头长度，4位:报头中的32位字(words)的数量。如果不使用选项，这个值设定为5。
•保留，6位:为将来的使用保留的字节。
•标记，一共6位:每一个标记一个字节(开或者关)
-URG:紧急字段指针。
-ACK:本数据包是(或者包含)一个确认信息。
-PSH:推送功能(没有使用)。
-RST:重置，或者中断本次连接。
-SYN:同步数据包，也就是开始连接。
-FIN:最后一个数据包，开始挂断序列。
•窗口尺寸，16位:从接收方将收到的确认字段开始。
•校验和，16位:TCP头和数据的校验和。
•应急指针，16位:指向跟在URG数据后面的数据的序列号的偏移值。
•选项:MSS、窗口比例等等。我们在关于TCP协议的下一讲中将重点介绍这个部分。
TCP连接的两端使用两对IP地址和端口识别这个连接，并且向监听这个端口的应用程序发送数据。
现在我们来介绍一下TCP协议的运行问题，因为我们对TCP协议实际上是什么样子知道的并不多。
我们说过，TCP协议在能够发送数据之前就建立起了“连接”。要实现这个连接，启动TCP连接的那一方首先将发送一个SYN(回忆一下在上一篇文章中讲到的TCP包头格式)数据包。这只是一个不包含数据的数据包，然后，打开SYN标记。如果另一方同时在它收到SYN标记的端口通话，它将发回一个SYN+ACK:SYN和ACK标志位都被打开，并将ACK(确认)编号字段设定为刚收到的那个数据包的顺序号字段的值。接下来，连接发起方为了表示收到了这个SYN+ACK信息，会向发送方发送一个最终的确认信息（ACK包）。这种SYN、SYN+ACK、ACK的步骤被称为TCP连接建立时的“三次握手”。在这之后，连接就建立起来了。这个连接将一直保持活动状态，直到超时或者任何一方发出一个FIN(结束)信号。
任何一方都可以关闭一个TCP连接，要求双方发送一个FIN信号关闭自己的通讯频道。一方可以在另一方之前关闭，或者双方同时关闭TCP连接。因此，当一方发送一个FIN信号时，另一方可发送“FIN+ACK”，开始关闭自己一方的通信并且确认收到了第一个FIN信号。发送第一个FIN信号的人接下来再发送一个“FIN+ACK”信息，确认收到第二个FIN信号。另一方就知道这个连接已经关闭了，并且关闭了自己的连接。发送第一个FIN的人没有办法收到最后一个ACK信号的确认信息。这时它会进入“TIME_WAIT”(等待时间)状态并启动一个定时器，防止另一方没有收到ACK信息并且认为连接仍是打开的。一般来说，这个状态会持续1至2分钟。
现在，我们来讨论第一个问题。如果有人(假如一个黑客)在你的Web服务器上留下一个半开或者半关的连接，那就是一个坏消息。每一个连接都要消耗内存，打开数千个虚假的TCP连接可能导致服务器瘫痪。当然，你实际上不可能在不影响TCP正常工作的情况下调整TCP定时器。如果你听说过TCP SYN 攻击的话，那就是这个意思。为了防止出现这种情况，大多数操作系统都要限制半开连接的数量。例如，Linux默认的限制一般是256个。
我们前面提过将讨论关于持续流控制问题，现在我们就来讨论这个问题。TCP中实现它的机制是TCP滑动窗口机制。TCP协议使用“重新发送与正向ACK”来保证数据传输的可靠性。发送方将等待一段时间，如果没有收到其发送的数据包的ACK确认信息，发送方就要重新发送。顺便说一下，TCP协议中有许多定时器。这只是其中一个定时器。ACK的概念对于流控制是非常重要的，因为TCP滑动窗口协议使TCP的往复确认变得更有效率。如果TCP要发送一个数据包并且等待每一个ACK确认信息，它实际上就把数据吞吐量削减了一半。
-
2009-03-01
TCP协议的拥塞控制策略及改进 - [网络]
摘 要：TCP是针对固定网络设计的一种传输协议，其错误控制机制是基于将所有丢包原因都归结于网络拥塞的假设。这种错误控制机制在有线网络上获得了很大的成功；但由于移动计算环境有着明显不同于有线网络环境的特点，如较高的位出错率、可用带宽小、衰减信道等，因此针对传统有线网络设计的TCP协议，其性能受到了很大影响。本文对目前移动计算环境下TCP协议的一些主要改进方案进行了综述，在对这些方案进行分类的基础上，对其优缺点进行了分析，并且对这些方案进行了比较。最后，提出了进一步研究的方向。
1. 引言
互联网最初源于美国国防部的ARPANET计划。在上世纪60年代中期，正是冷战的高峰，美国国防部希望有一个命令和控制网络能够在核战争的条件下幸免于难，而传统的电路交换的电话网络则显得太脆弱。国防部指定其下属的高级研究计划局（ARPA）解决这个问题，此后诞生的一个新型网络便称为ARPANET，其最大特点是采用无连接的端到端包交换服务。随后ARPANET开始与美国国家科学基金会（NSF）建成的NSFNET及加拿大、欧洲和太平洋地区的网络互联。到了80年代中期，人们开始把互联的网络称为互联网。
早在70年代中期，ARPA为了实现异种网络之间的互联与互通，推出了TCP/IP体系结构和协议规范。时至今日，TCP/IP协议也成为最流行的网际互联协议，并由单纯的TCP/IP协议发展成为一系列以IP为基础的TCP/IP协议簇。TCP／IP协议簇为互联网提供了基本的通信机制。
互联网采用的是无连接的端到端数据包交换，提供“尽力而为”（best effort）服务模型的设计机制。这种机制的最大优势是设计简单，可扩展性强。互联网在过去的十几年中经历了爆炸式的增长，这已经充分证明了这种设计机制的成功。然而这种优势并不是没有代价的，随着互联网用户数量的膨胀，网络的拥塞问题也越来越严重。例如由于队列溢出，互联网路由器会丢弃约10%的数据包。据统计，互联网上95%的数据流使用的是TCP/IP协议，因此，互联网上主要的互连协议TCP/IP的拥塞控制（congestion control）机制对控制网络拥塞具有特别重要的意义。拥塞控制是确保互联网鲁棒性（robustness）的关键因素，也是各种管理控制机制和应用（如多媒体通信中QoS控制、区分服务（differentiated services））的基础，因此关于互联网的拥塞控制问题一直是网络研究的一个热点。
TCP是目前Internet上使用最广泛的一种传输协议，根据MCI的统计，Internet上总字节数的95％及总数据包数的90％使用TCP协议传输[25]。TCP的目的是为了解决Internet的稳定性、异质性（接受端缓冲区大小、网络带宽及延迟等）、各流之间享用带宽的公平性、使用效率及拥塞控制等问题，从而为Internet提供可靠、健壮（robust）的端到端通讯。Internet近十年来的迅猛发展已证明TCP协议在设计上是成功的。
但是，TCP是为固定主机及有线网络设计的一种滑动窗口协议，它在位出错率（bit rate error，BER）很低、丢包的主要原因是网络拥塞的传统网络上的成功在移动计算环境下受到了巨大的挑战。移动计算带来的新问题主要是无线链路传输的可靠性、移动操作的特点以及对效率进行评估的性能尺度等。因此，对TCP协议的改进已经成为近几年网络通讯领域的一个研究热点。
本文第二部分对网络拥塞的基本概念进行了简要介绍；第三部分TCP的拥塞控制机制及有线网络环境下的改进进行了介绍；第四部分分析了TCP在移动计算环境下的缺点及其需要增加的功能；第五部分对增强移动环境下TCP的技术方案进行了分类介绍，分析了各自的优缺点，并对这些方案进行了比较。最后进行了总结，并提出了有待进一步研究的一些热点方向。
2. 网络拥塞的基本概念
2.1 拥塞的基本概念和互联网模型
当网络中存在过多的数据包时，网络的性能就会下降，这种现象称为拥塞。在网络发生拥塞时，会导致吞吐量下降，严重时会发生“拥塞崩溃”（congestion collapse）现象。一般来说，拥塞崩溃发生在网络负载的增加导致网络效率的降低的时候。最初观察到这种现象是在1986年10月，在这个过程中，LBL与UC Berkeley之间的吞吐量从32kbps下降到了40bps。Floyd总结出拥塞崩溃主要包括以下几种：传统的崩溃、未传送数据包导致的崩溃、由于数据包分段造成的崩溃、日益增长的控制信息流造成的崩溃等。
图1：网络负载与吞吐量及响应时间的关系对于拥塞现象，我们可以进一步用图1来描述。当网络负载较小时，吞吐量基本上随着负载的增长而增长，呈线性关系，响应时间增长缓慢。当负载达到网络容量时，吞吐量呈现出缓慢增长，而响应时间急剧增加，这一点称为Knee。如果负载继续增加，路由器开始丢包，当负载超过一定量时，吞吐量开始急剧下降，这一点称为Cliff。拥塞控制机制实际上包含拥塞避免（congestion avoidance）和拥塞控制（congestion control）两种策略。前者的目的是使网络运行在Knee附近，避免拥塞的发生；而后者则是使得网络运行在Cliff的左侧区域。前者是一种“预防”措施，维持网络的高吞吐量、低延迟状态，避免进入拥塞；后者是一种“恢复”措施，使网络从拥塞中恢复过来，进入正常的运行状态.
拥塞现象的发生和前面提到的互联网的设计机制有着密切关系，我们对这种设计机制作一个简单的归纳：
- 数据包交换（packet switched）网络：与电路交换（circuit switched）网络相比，由于包交换网络对资源的利用是基于统计复用（statistical multiplexing）的，因此提高了资源的利用效率。但在基于统计复用的情况下，很难保证用户的服务质量（quality of service，QoS），并且很容易出现数据包“乱序”的现象，对乱序数据包的处理会大大增加拥塞控制的复杂性。
- 无连接（connectionless）网络：互联网的节点之间在发送数据之前不需要建立连接，从而简化了网络的设计，网络的中间节点上无需保留和连接有关的状态信息。但无连接模型很难引入接纳控制（admission control），在用户需求大于网络资源时难以保证服务质量；此外，由于对数据发送源的追踪能力很差，给网络安全带来了隐患；无连接也是网络中出现乱序数据包的主要原因。
- “尽力而为”的服务模型：不对网络中传输的数据提供服务质量保证。在这种服务模型下，所有的业务流被“一视同仁”地公平地竞争网络资源，路由器对所有的数据包都采用先来先处理（First Come First Service，FCFS）的工作方式，它尽最大努力将数据包包送达目的地。但对数据包传递的可靠性、延迟等不能提供任何保证。这很适合Email、Ftp、WWW等业务。但随着互联网的飞速发展，IP业务也得到了快速增长和多样化。特别是随着多媒体业务的兴起，计算机已经不是单纯的处理数据的工具。这对互联网也就相应地提出了更高的要求。对那些有带宽、延迟、延迟抖动等特殊要求的应用来说，现有的“尽力而为”服务显然是不够的。
2.2 拥塞产生的原因
拥塞发生的主要原因在于网络能够提供的资源不足以满足用户的需求，这些资源包括缓存空间、链路带宽容量和中间节点的处理能力。由于互联网的设计机制导致其缺乏“接纳控制”能力，因此在网络资源不足时不能限制用户数量，而只能靠降低服务质量来继续为用户服务，也就是“尽力而为”的服务。
图2（a） 图2（b）拥塞虽然是由于网络资源的稀缺引起的，但单纯增加资源并不能避免拥塞的发生。例如增加缓存空间到一定程度时，只会加重拥塞，而不是减轻拥塞，这是因为当数据包经过长时间排队完成转发时，它们很可能早已超时，从而引起源端超时重发，而这些数据包还会继续传输到下一路由器，从而浪费网络资源，加重网络拥塞。事实上，缓存空间不足导致的丢包更多的是拥塞的“症状”而非原因。另外，增加链路带宽及提高处理能力也不能解决拥塞问题，例如，图2（a）中，四个节点之间的链路带宽都是19.2kbps，传输某个文件需要用时5分钟；当第一个节点和第二个节点之间的链路带宽提高到1Mbps时（如图2（b）所示），传输完该文件所需时间反而大大增加到了7个小时！这是因为在路由器R1中，数据包的到达速率远远大于转发的速率，从而导致大量数据包被丢弃，源端的发送速度被抑止，从而使得传输时间大大增加。即使所有链路具有同样大的带宽也不能解决拥塞问题，例如图3中，
所有链路带宽都是1Gbps，如果A和B同时向C以1Gbps的速率发送数据，则路由器R的输入速率为2Gbps，而输出速率只能为1Gbps，从而产生拥塞。
单纯地增加网络资源之所以不能解决拥塞问题，是因为拥塞本身是一个动态问题，它不可能只靠静态的方案来解决，而需要协议能够在网络出现拥塞时保护网络的正常运行。目前对互联网进行的拥塞控制主要是依靠在源端执行的基于窗口的TCP拥塞控制机制。网络本身对拥塞控制所起的作用较小，但近几年这方面的研究已经成了一个新的热点。3. TCP拥塞控制及其改进
3.1 TCP拥塞控制机制介绍
基于源端的拥塞控制策略中，使用最为广泛的是TCP协议中的拥塞控制策略，TCP协议是目前互联网中使用最为广泛的传输协议。根据MCI的统计，互联网上总字节数的95％及总数据包数的90％使用TCP协议传输。
早期的TCP协议只有基于窗口的流控制（flow control）机制而没有拥塞控制机制，因而易导致网络拥塞。1988年Jacobson针对TCP在网络拥塞控制方面的不足，提出了“慢启动”（Slow Start）和“拥塞避免”（Congestion Avoidance）算法。1990年出现的TCP Reno版本增加了“快速重传 ”（Fast Retransmit）、“快速恢复”（Fast Recovery）算法，避免了网络拥塞不严重时采用“慢启动”算法而造成过度减小发送窗口尺寸的现象，这样TCP的拥塞控制就主要由这4个核心算法组成。
TCP协议的目的是为上层应用提供可靠的服务，其主要特征在于：- 确保各流享用带宽的公平性。
- 动态发现当前可利用的带宽。
- 拥塞避免及控制机制以避免拥塞崩溃（congestion collapse）的发生。
标准版本的TCP使用基于窗口的的和式增加积式减小（Additive Increase Multiplicative Decrease，AIMD）方式控制发送速率，以保证稳定性及带宽享用的公平性。
错误控制机制是一个可靠传输协议的关键部分。它对协议的性能有很大的影响，包括吞吐量、能量消耗及可靠性。错误控制通常包括错误检测和错误恢复两部分。为了保证数据传输的可靠性，TCP要求接受端在正确接收到数据段（data segment）后向发送端发送一个确认包，确认包中包含了期望接收到的下一个数据段的序号。TCP发送端通过监测确认包的序号来检测是否发生了错误。如果发生超时或者发送端收到一定数量（通常是3个）重复的确认包，则认为传输过程中发生了错误，数据段被丢弃。由于有线网络的位出错率很低（例如光纤的BER通常只有10－12[22]），因此TCP假设丢包是由于网络拥塞引起的。在错误恢复处理过程中，TCP重传丢弃的数据段、减小发送端窗口大小并且在超时情况下重置超时时钟。
最初的TCP协议只有基于窗口的流控制（flow control）机制而没有拥塞控制机制。流控制作为接受方管理发送方发送数据的方式，用来防止接受方可用的数据缓存空间的溢出。流控制是一种局部控制机制，其参与者仅仅是发送方和接收方，它只考虑了接收端的接收能力，而没有考虑到网络的传输能力；而拥塞控制则注重于整体，其考虑的是整个网络的传输能力，是一种全局控制机制。正因为流控制的这种局限性，从而导致了拥塞崩溃现象的发生。
1986年初，Jacobson开发了现在在TCP应用中的拥塞控制机制。运行在端节点主机中的这些机制使得TCP连接在网络发生拥塞时回退（back off），也就是说TCP源端会对网络发出的拥塞指示（congestion notification）（例如丢包、重复的ACK等）作出响应。1988年Jacobson针对TCP在控制网络拥塞方面的不足，提出了“慢启动”（Slow Start）和“拥塞避免”（Congestion Avoidance）算法。1990年出现的TCP Reno版本增加了“快速重传 ”（Fast Retransmit）、“快速恢复”（Fast Recovery）算法，避免了网络拥塞不严重时采用“慢启动”算法而造成过大地减小发送窗口尺寸的现象，这样TCP的拥塞控制就由这4个核心部分组成。近几年又出现TCP的改进版本如NewReno和选择性应答（selective acknowledgement，SACK）等。正是这些拥塞控制机制防止了今天网络的拥塞崩溃。
TCP拥塞控制四个主要过程（如图4（a）和（b）所示）简要介绍如下：- 慢启动阶段：早期开发的TCP应用在启动一个连接时会向网络中发送大量的数据包，这样很容易导致路由器缓存空间耗尽，网络发生拥塞，使得TCP连接的吞吐量急剧下降。由于TCP源端无法知道网络资源当前的利用状况，因此新建立的TCP连接不能一开始就发送大量数据，而只能逐步增加每次发送的数据量，以避免上述现象的发生。具体地说，当建立新的TCP连接时，拥塞窗口（congestion window，cwnd）初始化为一个数据包大小。源端按cwnd大小发送数据，每收到一个ACK确认，cwnd就增加一个数据包发送量，这样cwnd就将随着回路响应时间（Round Trip Time，RTT）呈指数增长，源端向网络发送的数据量将急剧增加。事实上，慢启动一点也不慢，要达到每RTT发送W个数据包所需时间仅为RTT×logW。由于在发生拥塞时，拥塞窗口会减半或降到1，因此慢启动确保了源端的发送速率最多是链路带宽的两倍。
- 拥塞避免阶段：如果TCP源端发现超时或收到3个相同ACK副本时，即认为网络发生了拥塞（主要因为由传输引起的数据包损坏和丢失的概率很小（<<1%））。此时就进入拥塞避免阶段。慢启动阈值（ssthresh）被设置为当前拥塞窗口大小的一半；如果超时，拥塞窗口被置1。如果cwnd>ssthresh，TCP就执行拥塞避免算法，此时，cwnd在每次收到一个ACK时只增加1/cwnd个数据包，这样，在一个RTT内，cwnd将增加1，所以在拥塞避免阶段，cwnd不是呈指数增长，而是线性增长。
- 快速重传和快速恢复阶段：快速重传是当TCP源端收到到三个相同的ACK副本时，即认为有数据包丢失，则源端重传丢失的数据包，而不必等待RTO超时。同时将ssthresh设置为当前cwnd值的一半，并且将cwnd减为原先的一半。快速恢复是基于“管道”模型（pipe model）的“数据包守恒”的原则（conservation of packets principle），即同一时刻在网络中传输的数据包数量是恒定的，只有当“旧”数据包离开网络后，才能发送“新”数据包进入网络。如果发送方收到一个重复的ACK，则认为已经有一个数据包离开了网络，于是将拥塞窗口加1。如果“数据包守恒”原则能够得到严格遵守，那么网络中将很少会发生拥塞；本质上，拥塞控制的目的就是找到违反该原则的地方并进行修正。
图4（a）：慢启动和拥塞避免 图4（b）：快速重传和快速恢复经过十多年的发展，目前TCP协议主要包含有四个版本：TCP Tahoe、TCP Reno、TCP NewReno和TCP SACK。TCP Tahoe是早期的TCP版本，它包括了3个最基本的拥塞控制算法－“慢启动”、“拥塞避免”和“快速重传”。TCP Reno在TCP Tahoe基础上增加了“快速恢复”算法。TCP NewReno对TCP Reno中的“快速恢复”算法进行了修正，它考虑了一个发送窗口内多个数据包丢失的情况。在Reno版中，发送端收到一个新的ACK后旧退出“快速恢复”阶段，而在NewReno版中，只有当所有的数据包都被确认后才退出“快速恢复”阶段。TCP SACK关注的也是一个窗口内多个数据包丢失的情况，它避免了之前版本的TCP重传一个窗口内所有数据包的情况，包括那些已经被接收端正确接收的数据包，而只是重传那些被丢弃的数据包。
另外，在1994年，L.S.Brakmo等提出了一种新的拥塞控制策略－TCP Vegas。由于RTT值与网络运行情况有密切关系，因此，TCP Vegas通过观察TCP连接中RTT值改变感知网络是否发生拥塞，从而控制拥塞窗口大小。如果发现RTT值变大，Vegas就认为网络正在发生拥塞，于是开始减小拥塞窗口；另一方面，如果RTT变小，Vegas就认为网络拥塞正在解除，于是再次增加拥塞窗口。这样，拥塞窗口在理想情况下就会稳定在一个合适的值上。TCP Vegas的最大优点在于拥塞机制的触发只与RTT的改变有关，而与包的具体传输时延无关。由于TCP Vegas不是利用丢包来判断网络可用带宽，而是以RTT的变化来判断，因此能更精确地预测网络的可利用带宽，其公平性、效率都较好。但TCP Vegas之所以未能在互联网上大规模使用，主要是因为使用TCP Vegas的流在带宽竞争能力方面不及未使用TCP Vegas的流，从而导致网络资源享用不公平，而不是算法本身的问题。3.2 拥塞控制的主要问题
拥塞控制的问题主要集中在效率和公平性（fairness）上。网络资源的使用效率是指源端要求的总资源与网络所能提供的资源之间的关系。如果二者刚好相等或者很接近，那么这种算法的效率就是高的，否则都是效率不高的表现。
公平性是指在网络发生拥塞时各连接能公平地共享网络资源。产生公平性的根本原因在于拥塞发生必然导致数据包丢失，而数据包丢失会导致各数据流之间为争抢有限的网络资源发生竞争，竞争能力强的数据流将到更多网络资源，从而损害了其他流的利益。所以说没有拥塞，也就没有公平性问题。公平性问题表现在两方面：一是拥塞响应的TCP流和非拥塞响应的UDP流之间资源享用不公平；二是TCP流之间资源享用的不公平。前者主要是在发生拥塞时对拥塞指示作出的不同反应造成的。由于TCP流具有拥塞控制机制，在收到拥塞指示后，源端会主动降低发送速率；而UDP流由于没有端到端的拥塞控制机制，因此在收到拥塞指示后，UDP不会降低数据发送速率。结果在网络拥塞时，拥塞适应的TCP流得到的资源越来越少，非拥塞适应的UDP得到的资源越来越多，从而导致了网络资源分配的不公平。网络资源分配的不公平反过来会加重拥塞情况，甚至可能导致拥塞崩溃。对于第二个不公平性问题，研究表明，不同的窗口大小、RTT值及数据包的尺寸都会影响TCP流对带宽的占用。窗口较大，或者RTT较小，或者数据包较大的流往往能占用更多的带宽。
3.3 有线网络中TCP拥塞控制机制的改进
3.3.1 针对对不必要的超时重传和快速重传
我们知道，当前的TCP应用主要有两种重传机制－快速重传和超时重传。当TCP源端收到3个ACK副本时，就会触发快速重传机制，此时源端重传丢失的数据包并且将拥塞窗口大小减半。这种情况下，TCP流往往能够很快从丢包中恢复过来，重新回到原先的发送速率。但如果TCP源端没有收到3个ACK副本，例如拥塞窗口大小小于4，那么TCP源端则需要等待相当长时间，以便超时重发。这样，小窗口的TCP流就很容易陷入不必要的超时重发，使其吞吐量大大下降。
为了避免这种不必要的超时重传，一种改进办法就是只要TCP源端收到一个或者两个ACK副本，并且如果通告窗口允许，便继续发送新的数据包。这是因为只要收到ACK副本，就表明有数据包已经离开网络被接受端接收了，而此时源端还无法判断数据包是否被丢弃，根据“数据包守恒”原则，只要遵守拥塞窗口的规范，也即同时在网络中传送的数据包数量不能超过拥塞窗口的大小（以数据包为单位），源端就可以继续发送新的数据包。这种机制称为限制传输机制（Limited Transmit mechanism），这种机制对排序的数据包尤其有效。
限制传输机制可以使小窗口的TCP流很快从丢包中恢复过来。例如，对于拥塞窗口大小为4地TCP流，如果其第二个数据包丢失，那么按传统地做法需要等待超时重传。而在限制传输机制下，当源端收到对第三个数据包确认的ACK副本时（ACK中要求源端发送第二个数据包），继续发送新的数据包，最终源端可以收到三个ACK副本从而触发快速重传，从而减少了不必要的超时重传。
3.3.2 针对乱序包和延迟包引起的重传
在不少情况下，TCP源端推断认为数据包被丢弃了，从而导致重传及拥塞窗口的减小，而实际上数据包并没有被丢弃。如果超时时钟过早地到时了（事实上数据包或者ACK并没有丢失，只要能够再等待一会儿并可收到ACK），源端便毫无必要地重发了数据包，更严重的是拥塞窗口的减小，而实际上并没有数据包被丢弃。类似地，如果由于数据包的乱序导致源端接收到3个ACK副本，便会导致快速重传，TCP源端也毫无必要地重发了数据包，并且减小了拥塞窗口。对于前者，虽然可以通过更为精确地调节超时时钟来减少不必要地超时重传，但要完全避免却是不可能的。同样，对于后者，虽然可以通过提高快速重传算法的性能来减少不必要的快速重传，但也不可能完全避免。
对于拥塞窗口较大的流，比如大小为W，不必要地减小拥塞窗口会导致其至少花费W/2 RTT时间恢复到原来拥塞窗口的大小，从而使其性能大大下降，特别是在数据包持续出现乱序或者对RTT的估算不很精确的情况下。持续乱序的数据包往往是由于路由的改变或者链路层重传受损的数据包引起的。
为了使得在出现不必要的超时重传和快速重传情况下，TCP性能能够更加健壮（robust），一种方法就是在出现这些情况时向TCP源端发送有关的信息。这个工作已经由D-SACK扩展（duplicate-SACK extension）完成了。D-SACK扩展允许TCP接受端在利用SACK选项来通报收到重复的数据包，从而TCP源端能够正确地推断出接受端是否收到了重复地数据包。因此，D-SACK扩展使得TCP源端在重发后一个RTT时间内正确地推断出重发是否必要。如果源端认为重发是不必要的，那么拥塞窗口减半也就没必要了，源端就会将拥塞窗口大小和慢启动阈值分别恢复到原来的值，这样拥塞窗口恢复到原来的大小只需1RTT时间而不是W/2 RTT时间了。
3.3.3一种新的拥塞控制机制XCP
针对目前基于窗口的TCP拥塞控制机制的不足，最近MIT的D.Katabi、C.Rohrs和UC Berkeley的M.Handley共同提出了一种新的互联网拥塞控制机制XCP（eXplicit Control Protocol）。XCP源端维持有拥塞窗口cwnd和回路响应时间RTT并且通过数据包中的拥塞头（congestion header）将这两个值与路由器进行通信。当XCP连接刚刚建立时，与TCP一样，初始cwnd较小，XCP将其理想的发送速率填入到拥塞头中，如果链路带宽允许，则在一个RTT后就以次速率发送数据；如果链路带宽不足，则网络会给出一个发送速率，在一个RTT后源端就以此速率发送数据。
在随后的数据包传输过程中，根据数据流入速率和链路带宽之间的关系，路由器通知每个流是要增加还是减少拥塞窗口并将有关信息填入到拥塞头中。如果在后面的传输过程中，有路由器拥塞更加严重，则该路由器将拥塞头中的有关信息改写。最终该数据包将获得传输过程中的瓶颈链路信息，并将传送给接收端。接收端再将次信息写入到确认包中传送给源端，源端依此信息对拥塞窗口进行调整。通过将拥塞状态信息放入数据包中，XCP无需路由器维持每流状态信息，扩展性较好。
实验表明，与传统的TCP拥塞控制机制相比，XCP具有链路利用效率高、公平性好、可扩展性强、排队时延小的优点，并且路由器的开销也非常小。但XCP最终能否被标准化作为下一代互联网的传输协议我们将拭目以待。 -
2009-02-21
三层交换原理及与二层交换的比较 - [网络]
在今天的网络建设中，三层交换机以其高效的性能、优良的性能价格比得到用户的认可和赞许。目前，三层交换机在企业网、校园网建设、智能社区接入等等许多场合中得到了大量的应用，市场的需求和技术的更新推动这种应用向纵深发展。
传统二层(工作在OSI7层模型的第二层)交换技术
传统的局域网交换机是一种二层网络设备，它在操作过程中不断收集信息去建立起它本身的一个MAC地址表。这个表相当简单，基本上说明了某个MAC 地址是在哪个端口上被发现的。这样当交换机收到一个以太网包时，它便会查看一下该以太网包的目的MAC地址，核对一下自己的地址表以确认该从哪个端口把包发出去。但当交换机收到一个不认识的包时，也就是说如果目的MAC地址不在MAC地址表中，交换机便会把该包“扩散”出去，即从所有端口发出去，就如同交换机收到一个广播包一样，这就暴露出传统局域网交换机的弱点：不能有效的解决广播、异种网络互连、安全性控制等问题。因此，产生了交换机上的VLAN（虚拟局域网）技术。
三层(工作在OSI7层模型的第三层)交换技术
三层交换（也称多层交换技术，或IP交换技术）是相对于传统交换概念而提出的。众所周知，传统的交换技术是在OSI网络标准模型中的第二层――数据链路层进行操作的，而三层交换技术在网络模型中的第三层实现了分组的高速转发。简单的说，三层交换技术就是“二层交换技术 + 三层转发”。三层交换技术的出现，解决了局域网中网段划分之后网段中的子网必须依赖路由器进行管理的局面，解决了传统路由器低速、复杂所造成的网络瓶颈问题。
二层交换机通讯过程
假设两个使用IP协议的站点A、B通过第二层交换机进行通信，发送站点A在开始发送时，会先拿自己的IP地址与B站的IP地址进行比较，判断B站是否与自己在同一子网内。若目的站B与发送站A在同一子网内，则进行二层的转发。具体步骤如下：为了得到站点B的 MAC地址，站点A首先发一个ARP广播报文，请求站点B的MAC地址。该ARP请求报文进入交换机后，首先进行源MAC地址学习，芯片自动把站点A的MAC地址以及进入交换机的端口号等信息填入到芯片的MAC地址表中，然后在MAC地址表中进行目的地址查找。由于此时是一个广播报文，交换机则会把这个广播报文从进入交换机端口所属的VLAN中进行广播。B站点收到这个ARP请求报文之后，会立刻发送一个ARP回复报文，这个报文是一个单播报文，目的地址为站点A的MAC地址。该包进入交换机后，同样，首先进行源MAC地址学习，然后进行目的地址查找，由于此时MAC地址表中已经存在了A站点MAC地址的匹配条目，所以交换机直接把此报文从相应的端口中转发出去。通过以上一次ARP过程，交换芯片就把站点A和B的信息保存在其MAC地址表中。以后A、B之间进行通信或者同一网段的其它站点想要与A或B通信，交换机就知道该把报文从哪个端口送出。从以上过程可以看出，所有二层转发都是由硬件完成的，无论是MAC地址表的学习过程还是目的地址查找确定输出端口过程都没有软件进行干预。
三层交换机通讯过程
站点A、B通过三层交换机进行通信。站点A和B所在网段都属于交换机上的直连网段，若站点A和站点B不在同一子网内，发送站A首先要向其“缺省网关”发出ARP请求报文，而“缺省网关”的IP地址其实就是三层交换机上站点A所属VLAN的IP地址。当发送站A对“缺省网关”的IP地址广播出一个ARP请求时，交换机就向发送站A回一个ARP回复报文，告诉站点A交换机此VLAN的MAC地址，同时可以通过软件把站点A的IP地址、MAC地址、与交换机直接相连的端口号等信息设置到交换芯片的三层硬件表项中。站点A收到这个ARP回复报文之后，进行目的MAC地址替换，把要发给B的包首先发给交换机。交换机收到这个包以后，同样首先进行源MAC地址学习，目的MAC地址查找，由于此时目的MAC地址为交换机的MAC地址，在这种情况下将会把该报文送到交换芯片的三层引擎处理。一般来说，三层引擎会有两个表，一个是主机路由表，这个表是以IP地址为索引的，里面存放目的IP地址、下一跳MAC地址、端口号等信息。若找到一条匹配表项，就会在对报文进行一些操作（例如目的MAC与源MAC替换、TTL减1等）之后将报文从表中指定的端口转发出去。若主机路由表中没有找到匹配条目，则会继续查找另一个表――网段路由表。这个表存放网段地址、下一跳MAC地址、端口号等信息。一般来说这个表的条目要少得多，但覆盖的范围很大，只要设置得当，基本上可以保证大部分进入交换机的报文都走硬件转发，这样不仅大大提高转发速度，同时也减轻了CPU的负荷。由于芯片内部的三层引擎中已经保存站点A、B的路由信息，以后站点A、B之间进行通信或其它网段的站点想要与A、B进行通信，交换芯片则会直接把包从三层硬件表项中指定的端口转发出去，而不必再把包交给CPU处理。这种通过“一次路由，多次交换”的方式，大大提高了转发速度。
三层交换实现的例子:每个VLAN对应一个IP网段。在二层上，VLAN之间是隔离的，这点跟二层交换机中交换引擎的功能是一模一样的。不同IP 网段之间的访问要跨越VLAN，要使用三层转发引擎提供的VLAN间路由功能。在使用二层交换机和路由器的组网中，每个需要与其他IP网段通信的IP网段都需要使用一个路由器接口作为网关。而第三层转发引擎就相当于传统组网中的路由器，当需要与其他VLAN通信时也要在三层交换引擎上分配一个路由接口，用来做VLAN的网关。三层交换机上的这个路由接口是在三层转发引擎和二层转发引擎上的，是通过配置转发芯片来实现的，与路由器的接口不同，它是不可见的。假设两个使用IP协议的站点A、B通过第三层交换机进行通信，发送站A在开始发送时，把自己的IP地址与B站的IP地址比较，判断B站是否与自己在同一子网内，若目的站B与发送站A在同一子网内，则进行二层的转发，若两个站点不在同一子网内，如发送站A要与目的站B通信，发送站A要向三层交换机的三层交换模块发出ARP(地址解析)封包。当发送站A对三层交换模块的IP地址广播出一个ARP请求时，如果三层交换模块在以前的通信过程中已经知道B站的MAC地址(应该还有交换机的端口号等等信息)，则向发送站A回复B的MAC地址，否则三层交换模块根据路由信息向B站广播一个ARP请求，B站得到此ARP请求后向三层交换模块回复其MAC地址，三层交换模块保存此地址并回复给发送站A，同时将B站的MAC地址发送到二层交换引擎的MAC地址表中。从这以后，A向B发送的数据包便全部交给二层交换处理，信息得以高速交换。可见由于仅仅在路由过程中才需要三层处理，绝大部分数据都通过二层交换转发，三层交换机的速度很快，接近二层交换机的速度。
三层交换从概念的提出到今天的普及应用，虽然只历经了几年的时间，但其在网络建设中的应用越来越广泛，从最初骨干层、中间的汇聚层一直渗透到边缘的接入层。三层交换机具有速度快、性能好、价格低等众多的优势。凡是没有广域网连接需求，同时又需要路由器的地方，都可以用三层交换机代替。随着ASIC硬件芯片技术的发展和实际应用的推广，三层交换的技术与产品会得到进一步发展。
-
2009-02-20
TCP Keepalive HOWTO under linux - [网络]
1. Introduction
Understanding TCP keepalive is not necessary in most cases, but it's a subject that can be very useful under particular circumstances. You will need to know basic TCP/IP networking concepts, and the C programming language to understand all sections of this document.
The main purpose of this HOWTO is to describe TCP keepalive in detail and demonstrate various application situations. After some initial theory, the discussion focuses on the Linux implementation of TCP keepalive routines in the modern Linux kernel releases (2.4.x, 2.6.x), and how system administrators can take advantage of these routines, with specific configuration examples and tricks.
The second part of the HOWTO involves the programming interface exposed by the Linux kernel, and how to write TCP keepalive-enabled applications in the C language. Pratical examples are presented, and there is an introduction to the libkeepalive project, which permits legacy applications to benefit from keepalive with no code modification.
1.1. Copyright and License
This document, TCP Keepalive HOWTO, is copyrighted (c) 2007 by Fabio Busatto. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is available at http://www.gnu.org/copyleft/fdl.html.
Source code included in this document is released under the terms of the GNU General Public License, Version 2 or any later version published by the Free Software Foundation. A copy of the license is available at http://www.gnu.org/copyleft/gpl.html.
Linux is a registered trademark of Linus Torvalds.
1.2. Disclaimer
No liability for the contents of this document can be accepted. Use the concepts, examples and information at your own risk. There may be errors and inaccuracies that could be damaging to your system. Proceed with caution, and although this is highly unlikely, the author does not take any responsibility.
All copyrights are held by their by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Naming of particular products or brands should not be seen as endorsements.
1.3. Credits / Contributors
This work is not especially related to any people that I should thank. But my life is, and my knowledge too: so, thanks to everyone that has supported me, prior to my birth, now, and in the future. Really.
A special thank is due to Tabatha, the patient woman that read my work and made the needed reviews.
1.4. Feedback
Feedback is most certainly welcome for this document. Send your additions, comments and criticisms to the following email address: <fabio.busatto@sikurezza.org>.
1.5. Translations
There are no translated versions of this HOWTO at the time of publication. If you are interested in translating this HOWTO into other languages, please feel free to contact me. Your contribution will be very welcome.
2. TCP keepalive overview
In order to understand what TCP keepalive (which we will just call keepalive) does, you need do nothing more than read the name: keep TCP alive. This means that you will be able to check your connected socket (also known as TCP sockets), and determine whether the connection is still up and running or if it has broken.
2.1. What is TCP keepalive?
The keepalive concept is very simple: when you set up a TCP connection, you associate a set of timers. Some of these timers deal with the keepalive procedure. When the keepalive timer reaches zero, you send your peer a keepalive probe packet with no data in it and the ACK flag turned on. You can do this because of the TCP/IP specifications, as a sort of duplicate ACK, and the remote endpoint will have no arguments, as TCP is a stream-oriented protocol. On the other hand, you will receive a reply from the remote host (which doesn't need to support keepalive at all, just TCP/IP), with no data and the ACK set.
If you receive a reply to your keepalive probe, you can assert that the connection is still up and running without worrying about the user-level implementation. In fact, TCP permits you to handle a stream, not packets, and so a zero-length data packet is not dangerous for the user program.
This procedure is useful because if the other peers lose their connection (for example by rebooting) you will notice that the connection is broken, even if you don't have traffic on it. If the keepalive probes are not replied to by your peer, you can assert that the connection cannot be considered valid and then take the correct action.
2.2. Why use TCP keepalive?
You can live quite happily without keepalive, so if you're reading this, you may be trying to understand if keepalive is a possible solution for your problems. Either that or you've really got nothing more interesting to do instead, and that's okay too. :)
Keepalive is non-invasive, and in most cases, if you're in doubt, you can turn it on without the risk of doing something wrong. But do remember that it generates extra network traffic, which can have an impact on routers and firewalls.
In short, use your brain and be careful.
In the next section we will distinguish between the two target tasks for keepalive:
-
Checking for dead peers
-
Preventing disconnection due to network inactivity
2.3. Checking for dead peers
Keepalive can be used to advise you when your peer dies before it is able to notify you. This could happen for several reasons, like kernel panic or a brutal termination of the process handling that peer. Another scenario that illustrates when you need keepalive to detect peer death is when the peer is still alive but the network channel between it and you has gone down. In this scenario, if the network doesn't become operational again, you have the equivalent of peer death. This is one of those situations where normal TCP operations aren't useful to check the connection status.
Think of a simple TCP connection between Peer A and Peer B: there is the initial three-way handshake, with one SYN segment from A to B, the SYN/ACK back from B to A, and the final ACK from A to B. At this time, we're in a stable status: connection is established, and now we would normally wait for someone to send data over the channel. And here comes the problem: unplug the power supply from B and instantaneously it will go down, without sending anything over the network to notify A that the connection is going to be broken. A, from its side, is ready to receive data, and has no idea that B has crashed. Now restore the power supply to B and wait for the system to restart. A and B are now back again, but while A knows about a connection still active with B, B has no idea. The situation resolves itself when A tries to send data to B over the dead connection, and B replies with an RST packet, causing A to finally to close the connection.
Keepalive can tell you when another peer becomes unreachable without the risk of false-positives. In fact, if the problem is in the network between two peers, the keepalive action is to wait some time and then retry, sending the keepalive packet before marking the connection as broken.
_____ _____ | | | | | A | | B | |_____| |_____| ^ ^ |--->--->--->-------------- SYN -------------->--->--->---| |---<---<---<------------ SYN/ACK ------------<---<---<---| |--->--->--->-------------- ACK -------------->--->--->---| | | | system crash ---> X | | system restart ---> ^ | | |--->--->--->-------------- PSH -------------->--->--->---| |---<---<---<-------------- RST --------------<---<---<---| | |2.4. Preventing disconnection due to network inactivity
The other useful goal of keepalive is to prevent inactivity from disconnecting the channel. It's a very common issue, when you are behind a NAT proxy or a firewall, to be disconnected without a reason. This behavior is caused by the connection tracking procedures implemented in proxies and firewalls, which keep track of all connections that pass through them. Because of the physical limits of these machines, they can only keep a finite number of connections in their memory. The most common and logical policy is to keep newest connections and to discard old and inactive connections first.
Returning to Peers A and B, reconnect them. Once the channel is open, wait until an event occurs and then communicate this to the other peer. What if the event verifies after a long period of time? Our connection has its scope, but it's unknown to the proxy. So when we finally send data, the proxy isn't able to correctly handle it, and the connection breaks up.
Because the normal implementation puts the connection at the top of the list when one of its packets arrives and selects the last connection in the queue when it needs to eliminate an entry, periodically sending packets over the network is a good way to always be in a polar position with a minor risk of deletion.
_____ _____ _____ | | | | | | | A | | NAT | | B | |_____| |_____| |_____| ^ ^ ^ |--->--->--->---|----------- SYN ------------->--->--->---| |---<---<---<---|--------- SYN/ACK -----------<---<---<---| |--->--->--->---|----------- ACK ------------->--->--->---| | | | | | <--- connection deleted from table | | | | |--->- PSH ->---| <--- invalid connection | | | |3. Using TCP keepalive under Linux
Linux has built-in support for keepalive. You need to enable TCP/IP networking in order to use it. You also need procfs support and sysctl support to be able to configure the kernel parameters at runtime.
The procedures involving keepalive use three user-driven variables:
- tcp_keepalive_time
-
the interval between the last data packet sent (simple ACKs are not considered data) and the first keepalive probe; after the connection is marked to need keepalive, this counter is not used any further
- tcp_keepalive_intvl
-
the interval between subsequential keepalive probes, regardless of what the connection has exchanged in the meantime
- tcp_keepalive_probes
-
the number of unacknowledged probes to send before considering the connection dead and notifying the application layer
Remember that keepalive support, even if configured in the kernel, is not the default behavior in Linux. Programs must request keepalive control for their sockets using the setsockopt interface. There are relatively few programs implementing keepalive, but you can easily add keepalive support for most of them following the instructions explained later in this document.
3.1. Configuring the kernel
There are two ways to configure keepalive parameters inside the kernel via userspace commands:
-
procfs interface
-
sysctl interface
We mainly discuss how this is accomplished on the procfs interface because it's the most used, recommended and the easiest to understand. The sysctl interface, particularly regarding the sysctl(2) syscall and not the sysctl(8) tool, is only here for the purpose of background knowledge.
3.1.1. The procfs interface
This interface requires both sysctl and procfs to be built into the kernel, and procfs mounted somewhere in the filesystem (usually on /proc, as in the examples below). You can read the values for the actual parameters by "catting" files in /proc/sys/net/ipv4/ directory:
# cat /proc/sys/net/ipv4/tcp_keepalive_time 7200 # cat /proc/sys/net/ipv4/tcp_keepalive_intvl 75 # cat /proc/sys/net/ipv4/tcp_keepalive_probes 9The first two parameters are expressed in seconds, and the last is the pure number. This means that the keepalive routines wait for two hours (7200 secs) before sending the first keepalive probe, and then resend it every 75 seconds. If no ACK response is received for nine consecutive times, the connection is marked as broken.
Modifying this value is straightforward: you need to write new values into the files. Suppose you decide to configure the host so that keepalive starts after ten minutes of channel inactivity, and then send probes in intervals of one minute. Because of the high instability of our network trunk and the low value of the interval, suppose you also want to increase the number of probes to 20.
Here's how we would change the settings:
# echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time # echo 60 > /proc/sys/net/ipv4/tcp_keepalive_intvl # echo 20 > /proc/sys/net/ipv4/tcp_keepalive_probesTo be sure that all succeeds, recheck the files and confirm these new values are showing in place of the old ones.
Remember that procfs handles special files, and you cannot perform any sort of operation on them because they're just an interface within the kernel space, not real files, so try your scripts before using them, and try to use simple access methods as in the examples shown earlier.
You can access the interface through the sysctl(8) tool, specifying what you want to read or write.
# sysctl \ > net.ipv4.tcp_keepalive_time \ > net.ipv4.tcp_keepalive_intvl \ > net.ipv4.tcp_keepalive_probes net.ipv4.tcp_keepalive_time = 7200 net.ipv4.tcp_keepalive_intvl = 75 net.ipv4.tcp_keepalive_probes = 9Note that sysctl names are very close to procfs paths. Write is performed using the -w switch of sysctl (8):
# sysctl -w \ > net.ipv4.tcp_keepalive_time=600 \ > net.ipv4.tcp_keepalive_intvl=60 \ > net.ipv4.tcp_keepalive_probes=20 net.ipv4.tcp_keepalive_time = 600 net.ipv4.tcp_keepalive_intvl = 60 net.ipv4.tcp_keepalive_probes = 20Note that sysctl (8) doesn't use sysctl(2) syscall, but reads and writes directly in the procfs subtree, so you will need procfs enabled in the kernel and mounted in the filesystem, just as you would if you directly accessed the files within the procfs interface. Sysctl(8) is just a different way to do the same thing.
3.1.2. The sysctl interface
There is another way to access kernel variables: sysctl(2 ) syscall. It can be useful when you don't have procfs available because the communication with the kernel is performed directly via syscall and not through the procfs subtree. There is currently no program that wraps this syscall (remember that sysctl(8) doesn't use it).
For more details about using sysctl(2) refer to the manpage.
3.2. Making changes persistent to reboot
There are several ways to reconfigure your system every time it boots up. First, remember that every Linux distribution has its own set of init scripts called by init (8). The most common configurations include the /etc/rc.d/ directory, or the alternative, /etc/init.d/. In any case, you can set the parameters in any of the startup scripts, because keepalive rereads the values every time its procedures need them. So if you change the value of tcp_keepalive_intvl when the connection is still up, the kernel will use the new value going forward.
There are three spots where the initialization commands should logically be placed: the first is where your network is configured, the second is the rc.local script, usually included in all distributions, which is known as the place where user configuration setups are done. The third place may already exist in your system. Referring back to the sysctl (8) tool, you can see that the -p switch loads settings from the /etc/sysctl.conf configuration file. In many cases your init script already performs the sysctl -p (you can "grep" it in the configuration directory for confirmation), and so you just have to add the lines in /etc/sysctl.conf to make them load at every boot. For more information about the syntax of sysctl.conf(5), refer to the manpage.
4. Programming applications
This section deals with programming code needed if you want to create applications that use keepalive. This is not a programming manual, and it requires that you have previous knowledge in C programming and in networking concepts. I consider you familiar with sockets, and with everything concerning the general aspects of your application.
4.1. When your code needs keepalive support
Not all network applications need keepalive support. Remember that it is TCP keepalive support. So, as you can imagine, only TCP sockets can take advantage of it.
The most beautiful thing you can do when writing an application is to make it as customizable as possible, and not to force decisions. If you want to consider the happiness of your users, you should implement keepalive and let the users decide if they want to use it or not by using a configuration parameter or a switch on the command line.
4.2. The setsockopt function call
All you need to enable keepalive for a specific socket is to set the specific socket option on the socket itself. The prototype of the function is as follows:
int setsockopt(int s, int level, int optname, const void *optval, socklen_t optlen)The first parameter is the socket, previously created with the socket(2); the second one must be SOL_SOCKET, and the third must be SO_KEEPALIVE . The fourth parameter must be a boolean integer value, indicating that we want to enable the option, while the last is the size of the value passed before.
According to the manpage, 0 is returned upon success, and -1 is returned on error (and errno is properly set).
There are also three other socket options you can set for keepalive when you write your application. They all use the SOL_TCP level instead of SOL_SOCKET, and they override system-wide variables only for the current socket. If you read without writing first, the current system-wide parameters will be returned.
-
TCP_KEEPCNT: overrides tcp_keepalive_probes
-
TCP_KEEPIDLE: overrides tcp_keepalive_time
-
TCP_KEEPINTVL: overrides tcp_keepalive_intvl
4.3. Code examples
This is a little example that creates a socket, shows that keepalive is disabled, then enables it and checks that the option was effectively set.
/* --- begin of keepalive test program --- */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> int main(void); int main() { int s; int optval; socklen_t optlen = sizeof(optval); /* Create the socket */ if((s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) { perror("socket()"); exit(EXIT_FAILURE); } /* Check the status for the keepalive option */ if(getsockopt(s, SOL_SOCKET, SO_KEEPALIVE, &optval, &optlen) < 0) { perror("getsockopt()"); close(s); exit(EXIT_FAILURE); } printf("SO_KEEPALIVE is %s\n", (optval ? "ON" : "OFF")); /* Set the option active */ optval = 1; optlen = sizeof(optval); if(setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, &optval, optlen) < 0) { perror("setsockopt()"); close(s); exit(EXIT_FAILURE); } printf("SO_KEEPALIVE set on socket\n"); /* Check the status again */ if(getsockopt(s, SOL_SOCKET, SO_KEEPALIVE, &optval, &optlen) < 0) { perror("getsockopt()"); close(s); exit(EXIT_FAILURE); } printf("SO_KEEPALIVE is %s\n", (optval ? "ON" : "OFF")); close(s); exit(EXIT_SUCCESS); } /* --- end of keepalive test program --- */5. Adding support to third-party software
Not everyone is a software developer, and not everyone will rewrite software from scratch if it lacks just one feature. Maybe you want to add keepalive support to an existing application because, though the author might not have thought it important, you think it will be useful.
First, remember what was said about the situations where you need keepalive. Now you'll need to address connection-oriented TCP sockets.
Since Linux doesn't provide the functionality to enable keepalive support via the kernel itself (as BSD-like operating systems often do), the only way is to perform the setsockopt (2) call after socket creation. There are two solutions:
-
source code modification of the original program
-
setsockopt (2) injection using the library preloading technique
5.1. Modifying source code
Remember that keepalive is not program-related, but socket-related, so if you have multiple sockets, you can handle keepalive for each of them separately. The first phase is to understand what the program does and then search the code for each socket in the program. This can be done using grep(1), as follows:
# grep 'socket *(' *.cThis will more or less show you all sockets in the code. The next step is to select only the right ones: you will need TCP sockets, so look for PF_INET (or AF_INET), SOCK_STREAM and IPPROTO_TCP (or more commonly, 0) in the parameters of your socket list, and remove the non-matching ones.
Another way to create a socket is through accept(2). In this case, follow the TCP sockets identified and check if any of these is a listening socket: if positive, keep in mind that accept(2) returns a socket descriptor, which must be inserted in your socket list.
Once you've identified the sockets you can proceed with changes. The most fast & furious patch can be done by simply adding the setsockopt(2 ) function just after the socket creation block. Optionally, you may include additional calls in order to set the keepalive parameters if you don't like the system defaults. Please be careful when implementing error checks and handlers for the function, maybe by copying the style from the original code around it. Remember to set the optval to a non-zero value and to initialize the optlen before invoking the function.
If you have time or you think it would be really cool, try to add complete keepalive support to your program, including a switch on the command line or a configuration parameter to let the user choose whether or not to use keepalive.
5.2. libkeepalive: library preloading
There are often cases where you don't have the ability to modify the source code of an application, or when you have to enable keepalive for all your programs, so patching and recompiling everything is not recommended.
The libkeepalive project was born to help add keepalive support for applications since the Linux kernel doesn't provide the ability to do the same thing natively (like BSD does). The libkeepalive project homepage is http://libkeepalive.sourceforge.net/
It consists of a shared library that overrides the socket system call in most binaries, without the need to recompile or modify them. The technique is based on the preloading feature of the ld.so(8) loader included in Linux, which allows you to force the loading of shared libraries with higher priority than normal. Programs usually use the socket(2) function call located in the glibc shared library; with libkeepalive you can wrap it and inject the setsockopt (2) just after the socket creation, returning a socket with keepalive already set to the main program. Because of the mechanisms used to inject the system call, this doesn't work when the socket function is statically compiled into the binary, as in a program linked with the gcc(1 ) flag -static.
After downloading and installing libkeepalive, you will able to add keepalive support to your programs without the prerequisite of being root, simply setting the LD_PRELOAD environment variable before executing the program. By the way, the superuser can also force the preloading with a global configuration, and the users can then decide to turn it off by setting the KEEPALIVE environment variable to off.
The environment is also used to set specific values for keepalive parameters, so you have the ability to handle each program differently, setting KEEPCNT, KEEPIDLE and KEEPINTVL before starting the application.
Here's an example of libkeepalive usage:
$ test SO_KEEPALIVE is OFF $ LD_PRELOAD=libkeepalive.so \ > KEEPCNT=20 \ > KEEPIDLE=180 \ > KEEPINTVL=60 \ > test SO_KEEPALIVE is ON TCP_KEEPCNT = 20 TCP_KEEPIDLE = 180 TCP_KEEPINTVL = 60And you can use strace (1) to understand what happens:
$ strace test execve("test", ["test"], [/* 26 vars */]) = 0 [..] open("/lib/libc.so.6", O_RDONLY) = 3 [..] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 getsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [0], [4]) = 0 close(3) = 0 [..] _exit(0) = ? $ LD_PRELOAD=libkeepalive.so \ > strace test execve("test", ["test"], [/* 27 vars */]) = 0 [..] open("/usr/local/lib/libkeepalive.so", O_RDONLY) = 3 [..] open("/lib/libc.so.6", O_RDONLY) = 3 [..] open("/lib/libdl.so.2", O_RDONLY) = 3 [..] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0 setsockopt(3, SOL_TCP, TCP_KEEPCNT, [20], 4) = 0 setsockopt(3, SOL_TCP, TCP_KEEPIDLE, [180], 4) = 0 setsockopt(3, SOL_TCP, TCP_KEEPINTVL, [60], 4) = 0 [..] getsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], [4]) = 0 [..] getsockopt(3, SOL_TCP, TCP_KEEPCNT, [20], [4]) = 0 [..] getsockopt(3, SOL_TCP, TCP_KEEPIDLE, [180], [4]) = 0 [..] getsockopt(3, SOL_TCP, TCP_KEEPINTVL, [60], [4]) = 0 [..] close(3) = 0 [..] _exit(0) = ?For more information, visit the libkeepalive project homepage: http://libkeepalive.sourceforge.net/
-
-
2009-02-20
VLAN 实现虚拟工作组的新兴技术 - [网络]
1 VLAN概述
VLAN(Virtual Local Area Network)即虚拟局域网，是一种通过将局域网内的设备逻辑地而不是物理地划分成一个个网段从而实现虚拟工作组的新兴技术。IEEE于1999年颁布了用以标准化VLAN实现方案的802.1Q协议标准草案。
VLAN技术允许网络管理者将一个物理的LAN逻辑地划分成不同的广播域(或称虚拟LAN，即VLAN)，每一个VLAN都包含一组有着相同需求的计算机工作站，与物理上形成的LAN有着相同的属性。但由于它是逻辑地而不是物理地划分，所以同一个VLAN内的各个工作站无须被放置在同一个物理空间里，即这些工作站不一定属于同一个物理LAN网段。一个VLAN内部的广播和单播流量都不会转发到其他VLAN中，从而有助于控制流量、减少设备投资、简化网络管理、提高网络的安全性。
VLAN是为解决以太网的广播问题和安全性而提出的一种协议，它在以太网帧的基础上增加了VLAN头，用VLAN ID把用户划分为更小的工作组，限制不同工作组间的用户二层互访，每个工作组就是一个虚拟局域网。虚拟局域网的好处是可以限制广播范围，并能够形成虚拟工作组，动态管理网络。局域网（LAN）通常是一个单独的广播域，主要由Hub、网桥或交换机等网络设备连接同一网段内的所有节点形成。处于同一个局域网之内的网络节点之间可以直接通信，而处于不同局域网段的设备之间的通信则必须经过路由器才能通信。图1所示即为使用路由器构建的典型的局域网环境。
随着网络的不断扩展，接入设备逐渐增多，网络结构也日趋复杂，必须使用更多的路由器才能将不同的用户划分到各自的广播域中，在不同的局域网之间提供网络互联。
但这样做存在两个缺陷：
首先，随着网络中路由器数量的增多，网络时延逐渐加长，从而导致网络数据传输速度的下降。这主要是因为数据在从一个局域网传递到另一个局域网时，必须经过路由器的路由操作: 路由器根据数据包中的相应信息确定数据包的目标地址，然后再选择合适的路径转发出去。
其次，用户是按照它们的物理连接被自然地划分到不同的用户组（广播域）中。这种分割方式并不是根据工作组中所有用户的共同需要和带宽的需求来进行的。因此，尽管不同的工作组或部门对带宽的需求有很大的差异，但它们却被机械地划分到同一个广播域中争用相同的带宽。
VLAN的定义及特点
虚拟局域网VLAN是一组逻辑上的设备和用户，这些设备和用户并不受物理网段的限制，可以根据功能、部门及应用等因素将它们组织起来，相互之间的通信就好像它们在同一个网段中一样，由此得名虚拟局域网。VLAN是一种比较新的技术，工作在OSI参考模型的第2层和第3层，一个VLAN就是一个广播域，VLAN之间的通信是通过第3层的路由器来完成的。与传统的局域网技术相比较，VLAN技术更加灵活，它具有以下优点：
● 网络设备的移动、添加和修改的管理开销减少;
● 可以控制广播活动;
● 可提高网络的安全性。
VLAN在交换机上的实现方法，可以大致划分为4类:
2、 基于端口划分的VLAN
这种划分VLAN的方法是根据以太网交换机的端口来划分，比如Quidway S3526的1~4端口为VLAN 10，5~17为VLAN 20，18~24为VLAN 30，当然，这些属于同一VLAN的端口可以不连续，如何配置，由管理员决定，如果有多个交换机，例如，可以指定交换机 1 的1~6端口和交换机 2 的1~4端口为同一VLAN，即同一VLAN可以跨越数个以太网交换机，根据端口划分是目前定义VLAN的最广泛的方法，IEEE 802.1Q规定了依据以太网交换机的端口来划分VLAN的国际标准。
这种划分的方法的优点是定义VLAN成员时非常简单，只要将所有的端口都指定义一下就可以了。它的缺点是如果VLAN A的用户离开了原来的端口，到了一个新的交换机的某个端口，那么就必须重新定义。基于端口的VLAN的划分是最简单、有效的VLAN划分方法，它按照局域网交换机端口来定义VLAN成员。VLAN从逻辑上把局域网交换机的端口划分开来，从而把终端系统划分为不同的部分，各部分相对独立，在功能上模拟了传统的局域网。基于端口的VLAN又分为在单交换机端口和多交换机端口定义VLAN两种情况：
(1) 单交换机端口定义VLAN
如图2所示，交换机的1、2、6、7、8端口组成VLAN1，3、4、5端口组成了VLAN2。这种VLAN只支持一个交换机。
(2) 多交换机端口定义VLAN
如图3所示，交换机1的1、2、3端口和交换机2的4、5、6端口组成VLAN1，交换机1的4、5、6、7、8端口和交换机2的1、2、3、7、8端口组成VLAN2。
基于端口的VLAN的划分简单、有效，但其缺点是当用户从一个端口移动到另一个端口时，网络管理员必须对VLAN成员进行重新配置。
3、基于MAC地址划分VLAN
这种划分VLAN的方法是根据每个主机的MAC地址来划分，即对每个MAC地址的主机都配置他属于哪个组。这种划分VLAN的方法的最大优点就是当用户物理位置移动时，即从一个交换机换到其他的交换机时，VLAN不用重新配置，所以，可以认为这种根据MAC地址的划分方法是基于用户的VLAN，这种方法的缺点是初始化时，所有的用户都必须进行配置，如果有几百个甚至上千个用户的话，配置是非常累的。而且这种划分的方法也导致了交换机执行效率的降低，因为在每一个交换机的端口都可能存在很多个VLAN组的成员，这样就无法限制广播包了。另外，对于使用笔记本电脑的用户来说，他们的网卡可能经常更换，这样，VLAN就必须不停的配置。
4、基于网络层划分VLAN
这种划分VLAN的方法是根据每个主机的网络层地址或协议类型(如果支持多协议)划分的，虽然这种划分方法是根据网络地址，比如IP地址，但它不是路由，与网络层的路由毫无关系。它虽然查看每个数据包的IP地址，但由于不是路由，所以，没有RIP，OSPF等路由协议，而是根据生成树算法进行桥交换，
这种方法的优点是用户的物理位置改变了，不需要重新配置所属的VLAN，而且可以根据协议类型来划分VLAN，这对网络管理者来说很重要，还有，这种方法不需要附加的帧标签来识别VLAN，这样可以减少网络的通信量。
这种方法的缺点是效率低，因为检查每一个数据包的网络层地址是需要消耗处理时间的(相对于前面两种方法)，一般的交换机芯片都可以自动检查网络上数据包的以太网祯头，但要让芯片能检查IP帧头，需要更高的技术，同时也更费时。当然，这与各个厂商的实现方法有关。
5、根据IP组播划分VLAN
IP 组播实际上也是一种VLAN的定义，即认为一个组播组就是一个VLAN，这种划分的方法将VLAN扩大到了广域网，因此这种方法具有更大的灵活性，而且也很容易通过路由器进行扩展，当然这种方法不适合局域网，主要是效率不高。
鉴于当前业界VLAN发展的趋势，考虑到各种VLAN划分方式的优缺点，为了最大程度上地满足用户在具体使用过程中需求，减轻用户在VLAN的具体使用和维护中的工作量，Quidway S系列交换机采用根据端口来划分VLAN的方法。 -
2008-12-18
OSI七层协议和Tcp/IP五层协议，路由器交换机和HUB的区别 - [网络]
在网络历史的早期，国际标准化组织(ISO)和国际电报电话咨询委员会(CCITT)共同出版了开放系统互联的七层参考模型。一台计算机操作系统中的网络过程包括从应用请求(在协议栈的顶部)到网络介质(底部) ，OSI参考模型把功能分成七个分立的层次。图2.1表示了OSI分层模型。
┌─────┐
│ 应用层 │←第七层
├─────┤
│ 表示层 │
├─────┤
│ 会话层 │
├─────┤
│ 传输层 │
├─────┤
│ 网络层 │
├─────┤
│数据链路层│
├─────┤
│ 物理层 │←第一层
└─────┘
图2.1 OSI七层参考模型
OSI模型的七层分别进行以下的操作：
第一层 物理层
第一层负责最后将信息编码成电流脉冲或其它信号用于网上传输。它由计算机和网络介质之间的实际界面组成，可定义电气信号、符号、线的状态和时钟要求、数据编码和数据传输用的连接器。如最常用的RS-232规范、10BASE-T的曼彻斯特编码以及RJ-45就属于第一层。所有比物理层高的层都通过事先定义好的接口而与它通话。如以太网的附属单元接口(AUI)，一个DB-15连接器可被用来连接层一和层二。物理层（PhysicalLayer)，规定通信设备的机械的、电气的、功能的和过程的特性，用以建立、维护和拆除物理链路连接。具体地讲，机械特性规定了网络连接时所需接插件的规格尺寸、引脚数量和排列情况等；电气特性规定了在物理连接上传输bit流时线路上信号电平的大小、阻抗匹配、传输速率距离限制等；功能特性是指对各个信号先分配确切的信号含义，即定义了DTE和DCE之间各个线路的功能；规程特性定义了利用信号线进行bit流传输的一组操作规程，是指在物理连接的建立、维护、交换信息是，DTE和DCE双放在各电路上的动作系列。
在这一层，数据的单位称为比特（bit）。
属于物理层定义的典型规范代表包括：EIA/TIA RS-232、EIA/TIA RS-449、V.35、RJ-45等。
第二层 数据链路层
数据链路层通过物理网络链路提供可靠的数据传输。不同的数据链路层定义了不同的网络和协议特征，其中包括物理编址、网络拓扑结构、错误校验、帧序列以及流控。物理编址（相对应的是网络编址）定义了设备在数据链路层的编址方式；网络拓扑结构定义了设备的物理连接方式，如总线拓扑结构和环拓扑结构；错误校验向发生传输错误的上层协议告警；数据帧序列重新整理并传输除序列以外的帧；流控可能延缓数据的传输，以使接收设备不会因为在某一时刻接收到超过其处理能力的信息流而崩溃。数据链路层实际上由两个独立的部分组成，介质存取控制（Media Access Control,MAC）和逻辑链路控制层（Logical Link Control,LLC）。MAC描述在共享介质环境中如何进行站的调度、发生和接收数据。MAC确保信息跨链路的可靠传输，对数据传输进行同步，识别错误和控制数据的流向。一般地讲，MAC只在共享介质环境中才是重要的，只有在共享介质环境中多个节点才能连接到同一传输介质上。IEEE MAC规则定义了地址，以标识数据链路层中的多个设备。逻辑链路控制子层管理单一网络链路上的设备间的通信，IEEE 802.2标准定义了LLC。LLC支持无连接服务和面向连接的服务。在数据链路层的信息帧中定义了许多域。这些域使得多种高层协议可以共享一个物理数据链路。数据链路层（DataLinkLayer):在物理层提供比特流服务的基础上，建立相邻结点之间的数据链路，通过差错控制提供数据帧（Frame）在信道上无差错的传输，并进行各电路上的动作系列。
数据链路层在不可靠的物理介质上提供可靠的传输。该层的作用包括：物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。
在这一层，数据的单位称为帧（frame）。
数据链路层协议的代表包括：SDLC、HDLC、PPP、STP、帧中继等。
第三层 网络层
网络层负责在源和终点之间建立连接。它一般包括网络寻径，还可能包括流量控制、错误检查等。相同MAC标准的不同网段之间的数据传输一般只涉及到数据链路层，而不同的MAC标准之间的数据传输都涉及到网络层。例如IP路由器工作在网络层，因而可以实现多种网络间的互联。在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。网络层将数据链路层提供的帧组成数据包，包中封装有网络层包头，其中含有逻辑地址信息- -源站点和目的站点地址的网络地址。
如果你在谈论一个IP地址，那么你是在处理第3层的问题，这是“数据包”问题，而不是第2层的“帧”。IP是第3层问题的一部分，此外还有一些路由协议和地址解析协议（ARP）。有关路由的一切事情都在第3层处理。地址解析和路由是3层的重要目的。网络层还可以实现拥塞控制、网际互连等功能。
在这一层，数据的单位称为数据包（packet）。
网络层协议的代表包括：IP、IPX、RIP、OSPF等。
第四层 传输层
传输层向高层提供可靠的端到端的网络数据流服务。传输层的功能一般包括流控、多路传输、虚电路管理及差错校验和恢复。流控管理设备之间的数据传输，确保传输设备不发送比接收设备处理能力大的数据；多路传输使得多个应用程序的数据可以传输到一个物理链路上；虚电路由传输层建立、维护和终止；差错校验包括为检测传输错误而建立的各种不同结构；而差错恢复包括所采取的行动（如请求数据重发），以便解决发生的任何错误。传输控制协议（TCP）是提供可靠数据传输的TCP/IP协议族中的传输层协议。第4层的数据单元也称作数据包（packets）。但是，当你谈论TCP等具体的协议时又有特殊的叫法，TCP的数据单元称为段（segments）而UDP协议的数据单元称为“数据报（datagrams）”。这个层负责获取全部信息，因此，它必须跟踪数据单元碎片、乱序到达的数据包和其它在传输过程中可能发生的危险。第4层为上层提供端到端（最终用户到最终用户）的透明的、可靠的数据传输服务。所为透明的传输是指在通信过程中传输层对上层屏蔽了通信传输系统的具体细节。
传输层协议的代表包括：TCP、UDP、SPX等。
第五层 会话层
会话层建立、管理和终止表示层与实体之间的通信会话。通信会话包括发生在不同网络应用层之间的服务请求和服务应答，这些请求与应答通过会话层的协议实现。它还包括创建检查点，使通信发生中断的时候可以返回到以前的一个状态。这一层也可以称为会晤层或对话层，在会话层及以上的高层次中，数据传送的单位不再另外命名，统称为报文。会话层不参与具体的传输，它提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制。如服务器验证用户登录便是由会话层完成的。
第六层 表示层
表示层提供多种功能用于应用层数据编码和转化，以确保以一个系统应用层发送的信息可以被另一个系统应用层识别。表示层的编码和转化模式包括公用数据表示格式、性能转化表示格式、公用数据压缩模式和公用数据加密模式。
公用数据表示格式就是标准的图像、声音和视频格式。通过使用这些标准格式，不同类型的计算机系统可以相互交换数据；转化模式通过使用不同的文本和数据表示，在系统间交换信息，例如ASCII(American Standard Code for Information Interchange，美国标准信息交换码)；标准数据压缩模式确保原始设备上被压缩的数据可以在目标设备上正确的解压；加密模式确保原始设备上加密的数据可以在目标设备上正确地解密。
表示层协议一般不与特殊的协议栈关联，如QuickTime是Applet计算机的视频和音频的标准，MPEG是ISO的视频压缩与编码标准。常见的图形图像格式PCX、GIF、JPEG是不同的静态图像压缩和编码标准。这一层主要解决拥护信息的语法表示问题。它将欲交换的数据从适合于某一用户的抽象语法，转换为适合于OSI系统内部使用的传送语法。即提供格式化的表示和转换数据服务。数据的压缩和解压缩， 加密和解密等工作都由表示层负责。
第七层 应用层
应用层是最接近终端用户的OSI层，这就意味着OSI应用层与用户之间是通过应用软件直接相互作用的。注意，应用层并非由计算机上运行的实际应用软件组成，而是由向应用程序提供访问网络资源的API（Application Program Interface，应用程序接口）组成，这类应用软件程序超出了OSI模型的范畴。应用层的功能一般包括标识通信伙伴、定义资源的可用性和同步通信。因为可能丢失通信伙伴，应用层必须为传输数据的应用子程序定义通信伙伴的标识和可用性。定义资源可用性时，应用层为了请求通信而必须判定是否有足够的网络资源。在同步通信中，所有应用程序之间的通信都需要应用层的协同操作。
OSI的应用层协议包括文件的传输、访问及管理协议(FTAM) ，以及文件虚拟终端协议(VIP)和公用管理系统信息(CMIP)等。应用层为操作系统或网络应用程序提供访问网络服务的接口。
应用层协议的代表包括：Telnet、FTP、HTTP、SNMP等。
2.2 TCP/IP分层模型
TCP/IP分层模型（TCP/IP Layening Model）被称作因特网分层模型(Internet Layering Model)、因特网参考模型(Internet Reference Model)。图2.2表示了TCP/IP分层模型的四层。
┌────────┐┌─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┐
│ ││Ｄ│Ｆ│Ｗ│Ｆ│Ｈ│Ｇ│Ｔ│Ｉ│Ｓ│Ｕ│ │
│ ││Ｎ│Ｉ│Ｈ│Ｔ│Ｔ│Ｏ│Ｅ│Ｒ│Ｍ│Ｓ│其│
│第四层，应用层 ││Ｓ│Ｎ│Ｏ│Ｐ│Ｔ│Ｐ│Ｌ│Ｃ│Ｔ│Ｅ│ │
│ ││ │Ｇ│Ｉ│ │Ｐ│Ｈ│Ｎ│ │Ｐ│Ｎ│ │
│ ││ │Ｅ│Ｓ│ │ │Ｅ│Ｅ│ │ │Ｅ│它│
│ ││ │Ｒ│ │ │ │Ｒ│Ｔ│ │ │Ｔ│ │
└────────┘└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
┌────────┐┌─────────┬───────────┐
│第三层，传输层 ││ ＴＣＰ │ ＵＤＰ │
└────────┘└─────────┴───────────┘
┌────────┐┌─────┬────┬──────────┐
│ ││ │ＩＣＭＰ│ │
│第二层，网间层 ││ └────┘ │
│ ││ ＩＰ │
└────────┘└─────────────────────┘
┌────────┐┌─────────┬───────────┐
│第一层，网络接口││ＡＲＰ／ＲＡＲＰ │ 其它 │
└────────┘└─────────┴───────────┘
图2.2 ＴＣＰ／ＩＰ四层参考模型TCP/IP协议被组织成四个概念层，其中有三层对应于ISO参考模型中的相应层。ICP/IP协议族并不包含物理层和数据链路层，因此它不能独立完成整个计算机网络系统的功能，必须与许多其他的协议协同工作。
TCP/IP分层模型的四个协议层分别完成以下的功能：第一层 网络接口层
网络接口层包括用于协作IP数据在已有网络介质上传输的协议。实际上TCP/IP标准并不定义与ISO数据链路层和物理层相对应的功能。相反，它定义像地址解析协议(Address Resolution Protocol,ARP)这样的协议，提供TCP/IP协议的数据结构和实际物理硬件之间的接口。第二层 网间层
网间层对应于OSI七层参考模型的网络层。本层包含IP协议、RIP协议(Routing Information Protocol，路由信息协议)，负责数据的包装、寻址和路由。同时还包含网间控制报文协议(Internet Control Message Protocol,ICMP)用来提供网络诊断信息。第三层 传输层
传输层对应于OSI七层参考模型的传输层，它提供两种端到端的通信服务。其中TCP协议(Transmission Control Protocol)提供可靠的数据流运输服务，UDP协议(Use Datagram Protocol)提供不可靠的用户数据报服务。第四层 应用层
应用层对应于OSI七层参考模型的应用层和表达层。因特网的应用层协议包括Finger、Whois、FTP(文件传输协议)、Gopher、HTTP(超文本传输协议)、Telent(远程终端协议)、SMTP(简单邮件传送协议)、IRC(因特网中继会话)、NNTP（网络新闻传输协议）等，这也是本书将要讨论的重点。一般意义上说交换机是工作在数据链路层。但随着科技的发展，现在有了三层交换机，三层交换机已经扩展到了网络层。也就是说：它等于“数据链路层 + 部分网络层”。交换机中传的是帧。通过存储转发来实现的。
路由器是工作在网络层。路由器中传的是IP数据报。主要是选址和路由。
1.什么是交换机
交换机也叫交换式集线器，它通过对信息进行重新生成，并经过内部处理后转发至指定端口，具备自动寻址能力和交换作用，由于交换机根据所传递信息包的目的地址，将每一信息包独立地从源端口送至目的端口，避免了和其他端口发生碰撞。广义的交换机就是一种在通信系统中完成信息交换功能的设备。
2.交换机的工作原理
在计算机网络系统中，交换机是针对共享工作模式的弱点而推出的。集线器是采用共享工作模式的代表，如果把集线器比作一个邮递员，那么这个邮递员是个不认识字的“傻瓜”--要他去送信，他不知道直接根据信件上的地址将信件送给收信人，只会拿着信分发给所有的人，然后让接收的人根据地址信息来判断是不是自己的!而交换机则是一个“聪明”的邮递员--交换机拥有一条高带宽的背部总线和内部交换矩阵。交换机的所有的端口都挂接在这条背部总线上，当控制电路收到数据包以后，处理端口会查找内存中的地址对照表以确定目的MAC（网卡的硬件地址）的NIC（网卡）挂接在哪个端口上，通过内部交换矩阵迅速将数据包传送到目的端口。目的MAC若不存在，交换机才广播到所有的端口，接收端口回应后交换机会“学习”新的地址，并把它添加入内部地址表中。
可见，交换机在收到某个网卡发过来的“信件”时，会根据上面的地址信息，以及自己掌握的“常住居民户口簿”快速将信件送到收信人的手中。万一收信人的地址不在“户口簿”上，交换机才会像集线器一样将信分发给所有的人，然后从中找到收信人。而找到收信人之后，交换机会立刻将这个人的信息登记到“户口簿”上，这样以后再为该客户服务时，就可以迅速将信件送达了。
3.交换机的性能特点
1）独享带宽
由于交换机能够智能化地根据地址信息将数据快速送到目的地，因此它不会像集线器那样在传输数据时“打扰”那些非收信人。这样一来，交换机在同一时刻可进行多个端口组之间的数据传输。并且每个端口都可视为是独立的网段，相互通信的双方独自享有全部的带宽，无须同其他设备竞争使用。比如说，当A主机向 D主机发送数据时，B主机可同时向C主机发送数据，而且这两个传输都享有网络的全部带宽--假设此时它们使用的是10Mb的交换机，那么该交换机此时的总流通量就等于2×10Mb=20Mb。
2）全双工
当交换机上的两个端口在通信时，由于它们之间的通道是相对独立的，因此它们可以实现全双工通信。
1.路由器的作用
通过集线器或交换机，我们可以将很多台电脑组成一个比较大的局域网（图3），但是当机器的数量达到一定数目时，问题也就来了：对于用集线器构成的局域网而言，由于采用“广播”工作模式，当网络规模较大时，信息在传输过程中出现碰撞、堵塞的情况越来越严重，即使是交换机，这种情况也同样存在。其次，这种局域网不安全，也不利于管理。
为了解决这些问题，人们便将一个较大的网络划分为一个个小的子网、网段，或者直接将它们划分为多个VLAN（即虚拟局域网），在一个VLAN内，一台主机发出的信息只能发送到具有相同VLAN号的其他主机，其他VLAN的成员收不到这些信息或广播帧。采用VLAN划分网络后，可有效地抑制网络上的广播风暴，增加网络的安全性，使管理控制集中（图4）。
既然是局域网，万一分别处于不同VLAN的主机需要互相通信时该怎么办呢?这时候就得通过路由器（Router，转发者）来帮忙了。路由器可以将处于不同子网、网段、VLAN的电脑连接起来，让它们自由通信。另外，我们都知道目前的网络有很多种结构类型，且不同网络所使用的协议、速度也不尽相同。当两个不同结构的网络需要互连时，也可以通过路由器来实现。路由器可以使两个相似或不同体系结构的局域网段连接到一起，以构成一个更大的局域网或一个广域网。
可见，路由器是一种连接多个网络或网段的网络设备，它能将不同网络、网段或VLAN之间的数据信息进行“翻译”，以使它们能够相互“读”懂对方的数据，从而构成一个更大的网络。
2.路由器的工作原理
所谓路由就是指通过相互连接的网络把信息从源地点移动到目标地点的活动。那么路由器具体是如何进行“翻译”工作的呢?我们平时在学习、翻译英语时，肯定会准备一本英汉字典，通过它来实现英文与中文之间的互现转换。而对于路由器而言，它也有这种用于翻译的字典--路径表。路径表（Routing Table）保存着各种传输路径的相关数据，如子网的标志信息、网上路由器的个数和下一个路由器的名字等内容。路径表可以是由系统管理员固定设置好的，也可以由系统动态修改，可以由路由器自动调整，也可以由主机控制。
通过路由器可以让不同子网、网段进行互连，因此路由器与集线器、交换机不同，它一般安装在网络的“骨干”部位，而不像集线器、交换机那样工作在基层。比如说一个较大规模的企业局域网，基于管理、安全、性能的考虑，一般都会将整个网络划分为多个VLAN，如此一来，当VLAN与VLAN之间进行通讯时，就必须使用路由器。
对于该企业网而言，肯定还需要与互联网相连，对于企业而言，一般都是通过租用电信的DDN专线或者利用ADSL、Cable、ISDN等方式将企业网接入互联网，而此时由于网络体系及所用协议的不同，也需要路由器来完成企业网与互联网的互连工作。
点击放大
一般来说，在路由过程中，信息至少会经过一个或多个中间节点。通常，人们会把路由和交换进行对比，这主要是因为在普通用户看来两者所实现的功能是完全一样的。其实，路由和交换之间的主要区别就是交换发生在OSI参考模型的第二层（数据链路层），而路由发生在第三层，即网络层。这一区别决定了路由和交换在移动信息的过程中需要使用不同的控制信息，所以两者实现各自功能的方式是不同的。路由器通过路由决定数据的转发。转发策略称为路由选择，这也是路由器名称的由来。
三剑客的外观比较
前面我们已经讲解了集线器、交换机、路由器的工作原理，但是对于很多初学者来说，有时也希望能够从外观上去区分它们。当然，集线器、交换机、路由器在外观上肯定有所区别，但这些往往只能作为参考信息，毕竟现在很多集线器、交换机与路由器产品在外观上看非常相似。而这里面最难区分的就是普通桌面型的集线器与交换机，而路由器相对比较容易识别。 -
2008-05-09
[转载]GPS实时动态定位原理及应用 - [网络]
本文介绍了 GPS RTK的工作原理和RTK系统的组成，并阐述了流动站工作范围与RTK定位精度的关系，对RTK的初始化过程、RTK相对于静态定位增加的设备及应用、基准站与流动站信号传输过程作了详细的说明。引言
随着我国经济的高速发展，为了满足工程施工、测绘等工作的需要,采用GPS实时动态定位技术的测绘系统逐步进入我国市场。采用传统 GPS RTK(Real-Time-Kinematic)技术的测绘系统的数据链路电台，必须经过无线电管理部门批准才可设置使用，但在此前的几起此类设备所造成的无线电干扰案例中，所查获的无线电台均未向无线电管理部门申报。目前这类设备使用时所造成的无线电干扰越来越多，因此无线电管理部门应该加强对这类设备的管理。而增加对GPS RTK技术的了解和认识，将会对查处工作及无线电管理工作大有帮助。
1 RTK 概述
RTK(Real-Time-Kinematic)技术是GPS实时载波相位差分的简称。这是一种将GPS与数传技术相结合，实时解算并进行数据处理，在1～2秒时间内得到高精度位置信息的技术。
1.1 RTK的工作原理
RTK的工作原理是将一台接收机置于基准站上，另一台或几台接收机置于载体(称为流动站)上，基准站和流动站同时接收同一时间、同一GPS卫星发射的信号，基准站所获得的观测值与已知位置信息进行比较，得到GPS差分改正值。然后将这个改正值通过无线电数据链电台及时传递给共视卫星的流动站精化其GPS观测值，从而得到经差分改正后流动站较准确的实时位置。
精密GPS定位均采用相对技术。无论是在几点间进行同步观测的后处理(RTK)，还是从基准站将改正值传输给流动站(DGPS)，这些都称为相对技术，以采用值的类型为依据可分为4类：
(1)实时差分GPS，其精度为1m～3m;
(2)广域实时差分GPS，其精度为1m～2m;
(3)精密时差分GPS，其精度为1cm～5cm;
(4)实时精密时差分GPS，其精度为1cm～3cm。
差分的数据类型有伪距差分、坐标差分和相位差分三类。前两类定位误差的相关性，会随基准站与流动站的空间距离的增加而迅速降低。故RTK采用第三类方法。
RTK的观测模型为：
因轨道误差、钟差、电离层折射及对流层折射的影响在实际的数据处理中一般采用双差观测值方程来解算，在定位前需确定整周未知数，这一过程称为动态定位的“初始化”(On The Fly即OTF)。实现OTF的方法有很多种，美国天宝导航有限公司的做法是：采用伪距和相位相结合的方法，首先用伪距求出整周未知数的搜索范围，再用相位组合和后继观测历元解算和精化;利用伪距估计初始位置和搜索空间，快速确定精确的初始位置。1.2 RTK的系统组成我们以美国天宝导航有限公司生产的4800GPS双频接收机为例介绍RTK系统组成。
天宝RTK系统由两部分组成，如图1所示。
图1 天宝RTK系统组成
2 RTK系统基准站的组成和作用
RTK系统基准站由基准站GPS接收机及卫星接收天线、无线电数据链电台及发射天线、直流电源等组成，如图2所示。
RTK系统基准站的作用是求出GPS实时相位差分改正值，然后将改正值通过数传电台及时传递给流动站以精化其GPS观测值，进而得到更为精确的实时位置信息。
图2 RTK系统基准站的组成
GPS-RTK作业能否顺利进行，关键因素是无线电数据链的稳定性和作用距离是否满足要求。它与无线电数据链电台本身的性能、发射天线类型、参考站的选址、设备架设情况以及无线电电磁环境等有关。
一般数据链电台采用400MHz～480MHz高频载波发送数据，而高频无线电信号是沿直线传播的，这就要求参考站发射天线和流动站接收天线之间没有遮挡信号的障碍物。这些障碍物在陆地上主要是建筑物、无线电信号发射台等，在海上则主要是地球曲率的影响。
为了尽量避免参考站设备之间的干扰，在GPS-RTK作业时，大于25W的数据链电台的发射天线，应距离GPS接收天线至少2m，最好在6m以上;发射天线与电台的连接电缆必须展开，以免形成新的干扰源。
电台所使用的频率和电台功率必须经过国家和当地无线电管理部门批准，使用时可能会受到某些限制。
RTK数据链无线电发射机(TRIMMRKⅡ)的工作频率为UHF频段(400MHz～480MHz)，当功率一定时，发射距离随天线高度增加而增加，如下式所示：
发射距离(半径) (2)。
式中：4.24 ——天宝公司的经验值;
H1 ——电台的天线高度;
H2 ——流动站的天线高度。
我们通过举例来说明流动站工作范围的计算过程。
例：天宝4800GPS接收机使用的TRIMMRKⅡ无线电数据链电台发射功率为25W，电台天线高度为9m，流动站的天线高度为2m，试计算流动站工作的最远距离?
解：已知H1=9m，H2=2m，流动站在开阔地带工作的最远距离为:发射距离(半径)。
需要指出的是，该距离是在无任何遮挡物的空旷地带的理论值。根据经验，在城市环境中，只有架设在高楼顶上，无线电数据链电台发射距离才可能达到10公里。
无线电数据链电台发射功率为25W，其耗电量大，因而直流电源的电流应大一些，一般选择12V/60A或12V/120A为宜。3 RTK流动站的组成和作用流动站的UHF电台接收基准站的信号，同时也接收相同的卫星信号，用配备的TSC1控制器进行实时解算。
流动站数据链电台的功率为2W，其电源和卫星接收机共用，不需另配电池。
基准站GPS接收机与TRIMMRKⅡ电台之间的数据传输波特率为38400，TRIMMRKⅡ电台与流动站GPS接收机之间的数据传输波特率为4800，流动站中的UHF数据链电台与流动站GPS接收机之间的数据传输波特率为38400(见图3)。
图3 RTK系统流动站的组成
为了保证流动站的测量精度和可靠性，应在整个测区选择高精度的控制点进行检测校对。选择的控制点应有代表性，并均匀地分布在整个测量区。
(1)若基准站安置在已知点上，则输入已知点的坐标，进行坐标的转换(WGS—84转换成BJ54或其他坐标系)。
(2)若基准站安置在未知点上，(在城市测量中，有时为了控制更远和更大的范围，根据RTK的特点，可将基准站架设在没有控制点的高楼顶上)，在启动基准站时，则需输入该点的WGS—84坐标，进行坐标的转换(WGS—84转换成BJ54或其他坐标系)。
求得WGS—84坐标的方法是：开机后，在TSC1控制器上进行初始化操作，然后按here键即可求得该点的WGS—84坐标。
(3)虽然RTK定位测量的基准站可以不放在已知点上，但测量区内必须有已知控制点，而且定位测量的精度和已知控制点的等级和个数有关。在放置好基准站并启动流动站后，用流动站分别到已知点上进行定位测量，以求得该点坐标，然后与该点的原有坐标相比较，求出其差值，若差值很小(根据工程性质定)，则不需改正，否则，必须输入该点的原有坐标。4 RTK定位测量的准备工作RTK定位测量的准备过程如下：
(1)外业踏勘。
(2)收集资料。
(3)制订观测计划。
(4)星历预报。
(5)器材准备：经检定合格的GPS接收机[基准站+流动站(含TSC1)]一套;12V/60A电源(含充电器)，数据链电台一套;手机或对讲机(每台GPS接收机上配一个);每台GPS接收机配观测记录手簿一本。
(6)运输工具：自备汽车或租车。5 RTK的作业方法5.1 架设基准站
将基准站GPS接收机安置在开阔的地方，架设电台和天线。
启动基准站，在TSC1控制器中进行如下操作：
按on/off键，打开TSC1控制器，则其自动调用主菜单。
选择Files(文件)来建立新工程如下：
(1)建立新工程：给工程起一个文件名。
(2)选择工程管理(Job management)并确认。
(3)在选择坐标系统窗口中选用手工键入参数(Key in parameter)。
(4)在键入参数窗口中设置投影参数(Projection)。
(5)在输入椭球参数窗口中选择：
①投影方式——Transverce Mercator(横轴墨卡托投影)。
②False northing(北偏)——0.000m (北偏为0)。
③False easting(东偏)——500000.000m (东偏500km)。
④origin lat(纬度)——0°00′00.0000N。
⑤central meridian——114°00′00.0000E(当地中央子午线经度)。
⑥scale(尺度比)——1.000000。
⑦semi-major axis——6378245.000m(BJ54椭球长半轴)。
⑧Flattening(扁率分母)——298.300000。
若在同一测区，椭球参数只需输入一次即可，如再进入其他测区，则需重新输入其他测区的椭球参数。
(6)在键入参数窗口中选择输入转换参数，有以下三种情况：
①No transformation(没有转换参数)——若基准站没有WGS-84或BJ-54坐标，则选此项。
②Three parameter(三参数)——若基准站有BJ-54坐标，则选此项，此时将测区的参数输入即可，也可输入0。
③Seven parameter(七参数)——一般不考虑。
到此，一个新工程项目建立完成。5.2 启动基准站点击TSC1控制器Survey(测量)图标，进入测量方式菜单。
(1)在(Survey Styles)测量工作方式菜单中选Trimble RTK(实时动态)。
(2)在(Survey)测量菜单中选Start base receiver(启动基准站)。
(3)显示连接接收机后，输入基准站所在控制点的名称、天线高度。若控制器已储存该点的坐标可直接按Start(F1键);若控制器没有该点坐标信息，则按here(F3键)求得该点的WGS-84坐标(伪距)，然后按回车键直到高程变化趋于稳定，然后按Start(F1键)即可。
当提示控制器可以离开接收机，即表示基准站已启动，可以将基准站接收机上的电缆插头拔下(可带电插拔)。但此时控制器并不显示电台的标志，只有启动流动站后才会显出电台标志。
5.3 启动流动站
将TSC1控制器上的电缆插头插入流动站GPS接收机，在(Survey)测量菜单中选Start Survey(开始测量)，此时在TSC1控制器的窗口下部即显示如图4所示画面。
图4 TSC1控制器显示的有关图标
图4中，4800表示TSC1控制器所连接的GPS接收机型号;卫星图标中的“5”表示搜索到的卫星颗数，RTK测量时不能少于5颗;电台图标中若两个小灯交替闪亮，则表明无线电数据链已连接;“H”和“V”分别代表水平和高程精度;“PDOP”代表空间位置精度因子值;当RTK=FIXED(固定解)时，初始化完毕，可以开始测量;当RTK=float(浮点解)时，初始化不成功，必须等RTK=FIXED 时方可测量。5.4 开始测量RTK测量一般有以下几步操作：
(1)测量点(Measure points)。
(2)连续的碎部点的采集(Continuous top)。
(3)输入方位、距离、计算不可到达的点位(Offsets)。
(4)放样(Stakeout)。
6 GPS网络RTK技术(VRS系统)
6.1 概述
(1)GPS实时差分定位RTK技术的缺点
①用户需要架设本地参考站。
②误差随距离的增加而增长。
③误差增长使流动站和参考站的距离受到限制，一般小于15公里。
④精度为1cm+1ppm，可靠性随距离增大而降低。
(2)虚拟参考站方案中VRS的特点与技术优势
虚拟参考站方案中，VRS的实施将使一个地区的测绘工作成为一个有机的整体，这改变了以往GPS作业“单打独斗”的局面，同时它使GPS技术的应用更为广泛，使其精度和可靠性得到进一步提高，最重要的是建立GPS网络的成本降低了很多。
由于VRS技术的种种先进性，一经问世就受到世界各国的广泛关注，并得到积极的实施。德国、瑞士等一些国家的VRS网络已经建成。我国深圳市第一个建成了VRS技术卫星定位服务系统，在深圳经济发展、城市信息化和数字化发挥着重要作用。6.2 VRS系统的构成与工作原理VRS系统集GPS、Internet、无线通信和计算机网络管理技术于一身。整个系统由若干个(三个以上)连续运行的GPS基准站和一个GPS网络控制中心构成。
(1)VRS的系统构成
VRS的系统构成由GPS固定基准站系统、数据传输系统、GPS网络控制中心系统、数据发播系统和用户系统等五部分组成。
(2)VRS的工作原理
一个VRS网络由三个以上的固定基准站组成，站与站之间的距离可达70km，固定基准站负责实时采集GPS卫星观测数据并传送给GPS网络控制中心，由于这些固定基准站有长时间的观测数据，故点位坐标精度很高。固定基准站与控制中心之间可通过光缆、ISDN或普通电话线相连，将数据实时传送到控制中心。
GPS流动站先向控制中心发送标准的NMEA位置信息，告之其概略位置，控制中心收到信息后重新计算所有GPS数据，内插到与流动站相匹配的位置，再向流动站发送改正过的RTCM信息。流动站可位于VRS网络中的任何位置，这样RTK的系统误差就将被消减。可以看出，VRS系统实际上是一种多基站技术，它在处理上利用了多个参考站的联合数据。
6.3 VRS系统的优势
(1)VRS系统的覆盖范围较大。
(2)相对传统RTK，提高了精度。
(3)可靠性提高。
(4)更广的应用范围。
VRS技术的出现，标志着高精度GPS进入了一个新的发展阶段。这种网络RTK技术，应用了最先进的多基站RTK算法，极大地扩展了GPS的应用领域。
7 结束语
本文简要介绍了 RTK GPS技术的原理和应用，这将使我们更加地容易对这类系统进行识别与管理。以美国天宝公司为例，关于陆地测绘的产品型号有：Trimble R3 GPS、Trimble 5700/5800 GPS、Trimble R7/R8 /R8 GNSS GPS、Trimble NetRS/NetR5 GPS等。我们需要区分出采用传统GPS RTK技术并且只能采用无线电台选件，用于基准站与流动站之间改正信息的传输的产品，此类产品型号有：R3、5700、R7。既可采用无线电台选件也可采用GSM/GPRS选件的产品型号有：5800、R8、R8 GNSS。采用GPS网络RTK技术(VRS系统)的产品型号有：NetRS、NetR5。
凡是采用传统 RTK GPS技术的测绘系统的数据链路电台的设置必须经过无线电管理部门的审批管理。这类设备的出现对无线电管理部门也提出了许多需要解决的问题。
(1)需要与海关等部门协调，严把进口关，严禁没有无线电发射设备核准证的电台入关。
(2)对此类无线电台使用频率的指配和协调问题，无线电管理部门需要通过与国家规划、测绘等部门协商解决。此类频率指配工作还需要考虑跨省市作业及设备通用性问题。
(3)此类设备必须实行严格的登记制度，因为相关测绘资料属国家机密资料，涉及国家安全问题。
