技术库 > 网站架构

数据包data packet

技术库:tec.5lulu.com

from:tec.5lulu.com

 包(Packet)是TCP/IP协议通信传输中的数据单位,一般也称“数据包”。有人说,局域网中传输的不是“帧”(Frame)吗?没错,但是TCP/IP协议是工作在OSI模型第三层(网络层)、第四层(传输层)上的,而帧是工作在第二层(数据链路层)。上一层的内容由下一层的内容来传输,所以在局域网中,“包”是包含在“帧”里的。
简单的说,你上网打开网页,这个简单的动作,就是你先发送数据包给网站,它接收到了之后,根据你发送的数据包的IP地址,返回给你网页的数据包,也就是说,网页的浏览,实际上就是数据包的交换。
1、数据链路层对数据帧的长度都有一个限制,也就是链路层所能承受的最大数据长度,这个值
称为最大传输单元,即MTU。以以太网为例,这个值通常是1500字节。
2、对于IP数据包来讲,也有一个长度,在IP包头中,以16位来描述IP包的长度。一个IP包,最长可能是65535字节。
3、结合以上两个概念,第一个重要的结论就出来了,如果IP包的大小,超过了MTU值,那么就需要分片,也就是把一个IP包分为多个.
4、IP分片是很多资料常讲的内容,但是我倒是觉得分不分片其实不重要,重要的是另一个东西。一个数据包穿过一个大的网络,它其间会穿过多个网络,每个网络的MTU值是不同的。我们可以设想,如果接受/发送端都是以太网,它们的MTU都是1500,我们假设发送的时候,数据包会以1500来封装,然而,不幸的是,传输中有一段X.25网,它的MTU是576,这会发生什么呢?我想,这个才是我们所关心的。
当然,结论是显而易见的,这个数据包会被再次分片,咱开始用火车拉,到了半路,不通火车,只通汽车,那一车货会被分为很多车……仅此而已,更重要的是,这种情况下,如果IP包被设置了“不允许分片标志”,那会发生些什么呢?对,数据包将被丢弃,然后收到一份ICMP不可达差错,告诉你,需要分片!这个网络中最小的MTU值,被称为路径MTU,我们应该有一种有效的手段,来发现这个值,最笨的方法或许是先用traceroute查看所有节点,然后一个个ping……
5、到了传输层,也会有一个最大值的限制,当然,对于只管发,其它都不管的UDP来说,不在我们讨论之列。这里说的是TCP协议。说到大小,或许会让人想到TCP著名的滑动窗口的窗口大小,它跟收发两端的缓存有关,这里讨论的是传输的最大数据包大小,所以,它也不在讨论之列。
TCP的选项字段中,有一个最大报文段长度(MSS),表示了TCP传往另一端的最大数据的长度,当一个连接建立时,连接的双方都要通告各自的MSS,也就是说,它是与TCP的SYN标志在一起的。当然,对于传输来讲,总是希望MSS越大越好,现在超载这么严重,谁家不希望多拉点货……但是,MSS总是有个限制的,也就是它的值=MTU-IP头长度-TCP头长度,对于以太网来讲它通常是1500-20-20=1460,虽然总是希望它能很大(如1460),但是大多数BSD实现,它都是512的倍数,如1024……
6、回到分片上来,例如,在Win2000下执行如下命令:
"ping 192.168.0.1 -l 1473
按刚才的说法,1473+20(ip头)+8(icmp头)=1501,则好大于1500,它会被分片,但是,我们关心的是:
这个数据包会被怎么样分法?
可以猜想,第一个包是
以太头+IP头+ICMP头+1472的数据;
那第二个分片包呢?
它可以是:
以太头+IP头+ICMP头+1个字节的数据
或者是:
以太头+IP头+1个字节的数据"(引号内的内容可否在这里不详细阐述,对于1473的数据如何被分为1472和1不是很清楚2010.01.15 13:50)也就是省去ICMP头的封装,当然,IP头是不可以省的,否则怎么传输了……
事实上,TCP/IP协议采用的是后一种封装方式,这样,一次可以节约8个字节的空间。IP包头中,用了三个标志来描述一个分片包:
1、分片标志:如果一个包被分片了,分片标志这个字段被置于1,最后一个分片除外;——这样,对于接收端来讲,可以根据这个标志位做为重组的重要依据之一;
2、分片偏移标志:光有一个标志位说明“自己是不是分片包”是不够的,偏移标志位说明了自己这个分片位于原始数据报的什么位置。很明显,这两个标志一结合,就很容易重组分片包了。
3、不允许分片标志:如果数据包强行设置了这个标志,那么在应该分片的时候,…… err,刚才已经说过了。

-------------------------------------------------------------------------------------------
In computer networking, a packet is a formatted unit of data carried by a packet mode computer network. Computer communications links that do not support packets, such as traditional point-to-point telecommunications links, simply transmit data as a series of bytes, characters, or bits alone. When data is formatted into packets, the bitrate of the communication medium can be better shared among users than if the network were circuit switched.

 

1Packet framing

A packet consists of two kinds of data: control information and user data (also known as payload). The control information provides data the network needs to deliver the user data, for example: source and destination addresses, error detection codes like checksums, and sequencing information. Typically, control information is found in packet headers and trailers, with payload data in between.

Different communications protocols use different conventions for distinguishing between the elements and for formatting the data. In Binary Synchronous Transmission, the packet is formatted in 8-bit bytes, and special characters are used to delimit the different elements. Other protocols, like Ethernet, establish the start of the header and data elements by their location relative to the start of the packet. Some protocols format the information at a bit level instead of a byte level.

A good analogy is to consider a packet to be like a letter: the header is like the envelope, and the data area is whatever the person puts inside the envelope. A difference, however, is that some networks can break a larger packet into smaller packets when necessary (note that these smaller data elements are still formatted as packets).

A network design can achieve two major results by using packets: error detection and multiple host addressing.

Error detection

It is more efficient and reliable to calculate a checksum or cyclic redundancy check over the contents of a packet than to check errors using character-by-character parity bit checking.

The packet trailer often contains error checking data to detect errors that occur during transmission.

Host addressing

Modern networks usually connect three or more host computers together; in such cases the packet header generally contains addressing information so that the packet is received by the correct host computer. In complex networks constructed of multiple routing and switching nodes, like the ARPANET and the modernInternet, a series of packets sent from one host computer to another may follow different routes to reach the same destination. This technology is called packet switching.

2Terminology

In the seven-layer OSI model of computer networking, 'packet' strictly refers to a data unit at layer 3, the Network Layer. The correct term for a data unit at the Data Link Layer—Layer 2 of the seven-layer OSI model—is a frame, and at Layer 4, the Transport Layer, the correct term is a segment or datagram. Hence, e.g., a TCP segment is carried in one or more IP Layer packets, which are each carried in one or more Ethernet frames—though the mapping of TCP, IP, and Ethernet, to the layers of the OSI model is not exact.

In general, the term packet applies to any message formatted as a packet, while the term datagram is reserved for packets of an "unreliable" service. A "reliable" service is one that notifies the user if delivery fails, while an "unreliable" one does not notify the user if delivery fails. For example, IPprovides an unreliable service. Together, TCP and IP provide a reliable service, whereas UDP and IP provide an unreliable one. All these protocols use packets, but UDP packets are generally called datagrams.

When the ARPANET pioneered packet switching, it provided a reliable packet delivery procedure to its connected hosts via its 1822 interface. A host computer simply arranged the data in the correct packet format, inserted the address of the destination host computer, and sent the message across the interface to its connected Interface Message Processor. Once the message was delivered to the destination host, an acknowledgement was delivered to the sending host. If the network could not deliver the message, it would send an error message back to the sending host.

Meanwhile, the developers of CYCLADES and of ALOHAnet demonstrated that it was possible to build an effective computer network without providing reliable packet transmission. This lesson was later embraced by the designers of Ethernet.

If a network does not guarantee packet delivery, then it becomes the host's responsibility to provide reliability by detecting and retransmitting lost packets. Subsequent experience on the ARPANET indicated that the network itself could not reliably detect all packet delivery failures, and this pushed responsibility for error detection onto the sending host in any case. This led to the development of the end-to-end principle, which is one of the Internet's fundamental design assumptions.

3Example: IP packets

IP packets are composed of a header and payload. The IPv4 packet header consists of:

  1. 4 bits that contain the version, that specifies if it's an IPv4 or IPv6 packet,
  2. 4 bits that contain the Internet Header Length, which is the length of the header in multiples of 4 bytes (e.g., 5 means 20 bytes).
  3. 8 bits that contain the Type of Service, also referred to as Quality of Service (QoS), which describes what priority the packet should have,
  4. 16 bits that contain the length of the packet in bytes,
  5. 16 bits that contain an identification tag to help reconstruct the packet from several fragments,
  6. 3 bits. The first contains a zero, followed by a flag that says whether the packet is allowed to be fragmented or not (DF: Don't fragment), and a flag to state whether more fragments of a packet follow (MF: More Fragments)
  7. 13 bits that contain the fragment offset, a field to identify position of fragment within original packet
  8. 8 bits that contain the Time to live (TTL), which is the number of hops (router, computer or device along a network) the packet is allowed to pass before it dies (for example, a packet with a TTL of 16 will be allowed to go across 16 routers to get to its destination before it is discarded),
  9. 8 bits that contain the protocol (TCP, UDP, ICMP, etc.)
  10. 16 bits that contain the Header Checksum, a number used in error detection,
  11. 32 bits that contain the source IP address,
  12. 32 bits that contain the destination address.

After those 160 bits, optional flags can be added of varied length, which can change based on the protocol used, then the data that packet carries is added. An IP packet has no trailer. However, an IP packet is often carried as the payload inside an Ethernet frame, which has its own header and trailer.

Delivery not guaranteed

Many networks do not provide guarantees of delivery, nonduplication of packets, or in-order delivery of packets, e.g., the UDP protocol of the Internet. However, it is possible to layer a transport protocol on top of the packet service that can provide such protection; TCP and UDP are the best examples of layer 4, the Transport Layer, of the seven layered OSI model.

The header of a packet specifies the data type, packet number, total number of packets, and the sender's and receiver's IP addresses.

The term frame is sometimes used to refer to a packet exactly as transmitted over the wire or radio.

4Example: the NASA Deep Space Network

The Consultative Committee for Space Data Systems (CCSDS) packet telemetry standard defines the protocol used for the transmission of spacecraft instrument data over the deep-space channel. Under this standard, an image or other data sent from a spacecraft instrument is transmitted using one or more packets.

CCSDS packet definition

A packet is a block of data with length that can vary between successive packets, ranging from 7 to 65,542 bytes, including the packet header.

  • Packetized data is transmitted via frames, which are fixed-length data blocks. The size of a frame, including frame header and control information, can range up to 2048 bytes.
  • Packet sizes are fixed during the development phase.

Because packet lengths are variable but frame lengths are fixed, packet boundaries usually do not coincide with frame boundaries.

Telecom processing notes

Data in a frame is typically protected from channel errors by error-correcting codes.

  • Even when the channel errors exceed the correction capability of the error-correcting code, the presence of errors nearly always is detected by the error-correcting code or by a separate error-detecting code.
  • Frames for which uncorrectable errors are detected are marked as undecodable and typically are deleted.

Handling data loss

Deleted undecodable whole frames are the principal type of data loss that affects compressed data sets. In general, there would be little to gain from attempting to use compressed data from a frame marked as undecodable.

  • When errors are present in a frame, the bits of the subband pixels are already decoded before the first bit error will remain intact, but all subsequent decoded bits in the segment usually will be completely corrupted; a single bit error is often just as disruptive as many bit errors.
  • Furthermore, compressed data usually are protected by powerful, long-blocklength error-correcting codes, which are the types of codes most likely to yield substantial fractions of bit errors throughout those frames that are undecodable.

Thus, frames with detected errors would be essentially unusable even if they were not deleted by the frame processor.

This data loss can be compensated for with the following mechanisms.

  • If an erroneous frame escapes detection, the decompressor will blindly use the frame data as if they were reliable, whereas in the case of detected erroneous frames, the decompressor can base its reconstruction on incomplete, but not misleading, data.
  • However, it is extremely rare for an erroneous frame to go undetected.
  • For frames coded by the CCSDS Reed–Solomon code, fewer than 1 in 40,000 erroneous frames can escape detection.
  • All frames not employing the Reed–Solomon code use a cyclic redundancy check (CRC) error-detecting code, which has an undetected frame-error rate of less than 1 in 32,000.

5Example: Radio and TV Broadcasting

MPEG packetized stream

Packetized Elementary Stream (PES) is a specification defined by the MPEG communication protocol (see the MPEG-2 standard) that allows an elementary streamto be divided into packets. The elementary stream is packetized by encapsulating sequential data bytes from the elementary stream inside PES packet headers.

A typical method of transmitting elementary stream data from a video or audio encoder is to first create PES packets from the elementary stream data and then to encapsulate these PES packets inside an MPEG transport stream (TS) packets or an MPEG program stream (PS). The TS packets can then be multiplexed and transmitted using broadcasting techniques, such as those used in an ATSC and DVB.

PES packet header

Name Size Description
Packet start code prefix 3 bytes 0x000001
Stream id 1 byte Examples: Audio streams (0xC0-0xDF), Video streams (0xE0-0xEF) 
    Note: The above 4 bytes is called the 32-bit start code.
PES Packet length 2 bytes Can be zero as in not specified for video streams in MPEG transport streams
Optional PES header variable length  
Stuffing bytes variable length  
Data   See elementary stream. In the case of private streams the first byte of the payload is the sub-stream number.

Optional PES header

Name Number of Bits Description
Marker bits 2 10 binary or 0x2 hex
Scrambling control 2 00 implies not scrambled
Priority 1  
Data alignment indicator 1 1 indicates that the PES packet header is immediately followed by the video start code or audio syncword
Copyright 1 1 implies copyrighted
Original or Copy 1 1 implies original
PTS DTS indicator 2 11 = both present, 10 = only PTS
ESCR flag 1  
ES rate flag 1  
DSM trick mode flag 1  
Additional copy info flag 1  
CRC flag 1  
extension flag 1  
PES header length 8 gives the length of the remainder of the PES header
Optional fields variable length presence is determined by flag bits above
Stuffing Bytes variable length 0xff

NICAM

In order to provide mono "compatibility", the NICAM signal is transmitted on a subcarrier alongside the sound carrier. This means that the FM or AM regular mono sound carrier is left alone for reception by monaural receivers.

A NICAM-based stereo-TV infrastructure can transmit a stereo TV programme as well as the mono "compatibility" sound at the same time, or can transmit two or three entirely different sound streams. This latter mode could be used to transmit audio in different languages, in a similar manner to that used for in-flight movies on international flights. In this mode, the user can select which soundtrack to listen to when watching the content by operating a "sound-select" control on the receiver.

NICAM offers the following possibilities. The mode is auto-selected by the inclusion of a 3-bit type field in the data-stream

  • One digital stereo sound channel.
  • Two completely different digital mono sound channels.
  • One digital mono sound channel and a 352 kbit/s data channel.
  • One 704 kbit/s data channel.

The four other options could be implemented at a later date. Only the first two of the ones listed are known to be in general use however.

NICAM packet transmission

The NICAM packet (except for the header) is scrambled with a nine-bit pseudo-random bit-generator before transmission.

  • The topology of this pseudo-random generator yields a bitstream with a repetition period of 511 bits.
  • The pseudo-random generator's polynomial is: x^9 + x^4 + 1.
  • The pseudo-random generator is initialized with: 111111111.

Making the NICAM bitstream look more like white noise is important because this reduces signal patterning on adjacent TV channels.

  • The NICAM header is not subject to scrambling. This is necessary so as to aid in locking on to the NICAM data stream and resynchronisation of the data stream at the receiver.
  • At the start of each NICAM packet the pseudo-random bit generator's shift-register is reset to all-ones.

 

 

数据包data packet


本文链接 http://tec.5lulu.com/detail/105k5n1e68nty83d6.html

我来评分 :6.1
0

转载注明:转自5lulu技术库

本站遵循:署名-非商业性使用-禁止演绎 3.0 共享协议

www.5lulu.com