Network Working Group G. Pelletier Request for Comments: 4224 L-E. Jonsson Category: Informational K. Sandlund Ericsson January 2006 RObust Header Compression (ROHC):
ROHC over Channels That Can Reorder Packets
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
RObust Header Compression (ROHC), RFC 3095, defines a framework for
header compression, along with a number of compression protocols
(profiles). One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is
required to maintain packet ordering. This document discusses
aspects of using ROHC over channels that can reorder packets. It
provides guidelines on how to implement existing profiles over such
channels, as well as suggestions for the design of new profiles. Pelletier, et al. Informational [Page 1]
Table of Contents
1. Introduction (3)
2. Terminology (4)
3. Applicability of This Document to ROHC Profiles (5)
3.1. Profiles within Scope (5)
3.2. Profiles with Special Considerations (5)
3.3. Profiles Incompatible with Reordering (6)
4. Background (6)
4.1. Reordering Channels (6)
4.2. Robustness Principles of ROHC (6)
4.2.1. Optimistic Approach (U/O-mode) (7)
4.2.2. Secure Reference Principle (R-mode) (7)
5. Problem Description (7)
5.1. ROHC and Reordering Channels (7)
5.1.1. LSB Interpretation Interval and Reordering (7)
5.1.2. Reordering of Packets in R-mode (9)
5.1.2.1. Updating Packets (9)
5.1.2.2. Non-Updating Packets (10)
5.1.3. Reordering of Packets in U/O-mode (10)
5.1.4. Reordering on the Feedback Channel (11)
5.1.5. List Compression (11)
5.1.6. Reordering and Mode Transitions (12)
5.2. Consequences of Reordering (13)
5.2.1. Functionality Incompatible with Reordering (13)
5.2.2. Context Damage (Loss of Synchronization) (13)
5.2.3. Detected Decompression Failures (U/O/R-mode) (13)
5.2.4. Undetected Decompression Failures (R-mode only) (14)
6. Making ROHC Tolerant against Reordering (14)
6.1. Properties of ROHC Implementations (14)
6.1.1. Compressing Headers with Robustness against
Reordering (14)
6.1.1.1. Reordering and the Optimistic Approach (15)
6.1.1.2. Reordering and the Secure
Reference Principle (15)
6.1.1.3. Robust Selection of Compressed Header (15)
6.1.2. Implementing a Reordering-Tolerant Decompressor (16)
6.1.2.1. Decompressor Feedback Considerations (16)
6.1.2.2. Considerations for Local Repair
Mechanisms (17)
6.2. Specifying ROHC Profiles with Robustness against
Reordering (17)
6.2.1. Profiles with Interpretation Interval
Offset p = -1 (17)
6.2.2. Modifying the Interpretation Interval Offset (18)
6.2.2.1. Example Profile for Handling Reordering (18)
6.2.2.2. Defining the Values of p for New
Profiles (18)
Pelletier, et al. Informational [Page 2]
7. Security Considerations (19)
8. Acknowledgements (19)
9. Informative References (19)
1. Introduction
RObust Header Compression (ROHC), RFC 3095 [1], defines a framework
for header compression, along with a number of compression protocols (profiles). One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is
required to maintain packet ordering for each compressed flow. The
motivation behind this assumption was that the primary candidate
channels considered did guarantee in-order delivery of header-
compressed packets. This assumption made it possible to meet the
design objectives that were on top of the requirements list at the
time when ROHC was being designed, namely to improve the compression efficiency and the tolerance to packet losses.
Since the publication of RFC 3095 in 2001, the question about ROHC
operation over channels that do not guarantee in-order delivery has
surfaced several times; arguments that ROHC cannot perform adequately over such channels have been heard. Specifically, this has been
raised as a weakness when compared to other header compression
alternatives, as RFC 3095 explicitly states its inability to operate if in-order delivery is not guaranteed. For those familiar with the details of ROHC and of other header compression schemes, it is clear that this is a misconception, but it can also be easily understood
that the wording used in RFC 3095 can lead to such interpretation.
This document discusses the various aspects of implementing ROHC over channels that can reorder header-compressed packets. It explains
different ways of implementing the profiles found in RFC 3095, as
well as other profiles based on those profiles, over reordering
channels. This can be achieved either by ensuring that compressor
implementations use compressed headers that are sufficiently robust
to the expected possible reordering and/or by modifying decompressor implementations to tolerate reordered packets. Ideas regarding how
existing profiles could be updated and how new profiles can be
defined to cope efficiently with reordering are also discussed.
In some scenarios, there might be external means (such as a sequence number) to detect and potentially correct reordering. That is, for
example, the case when running compression over an IPsec
Encapsulating Security Payload (ESP) tunnel. With such external
means to detect reordering, the decompressor can be modified to make use of the external information provided, and reordering can then be handled. How to make use of external means to address reordering is, however, out of scope for this document.
Pelletier, et al. Informational [Page 3]
2. Terminology
This document uses terminology consistent with RFC 3759 [2], and is
in itself only informative. Although it does discuss technical
aspects of implementing the ROHC specifications in particular
environments, it does not specify any new technology.
ROHC
The term "ROHC" herein refers to the following profiles:
- 0x0001, 0x0002, and 0x0003 defined in RFC 3095 [1];
- 0x0004 for compression of IP-only headers [3];
- 0x0007 and 0x0008 for compression of UDP-Lite headers [4].
The term "ROHC" excludes the following profiles, which are either not affected by reordering or have the assumption of in-order
delivery as a fundamental requirement for their proper operation: - 0x0000 (uncompressed) [1];
- 0x0005 (Link-Layer Assisted (LLA)) [5] and 0x0105
(R-mode extension to LLA) [6];
Reordering
A type of transmission taking place between compressor and
decompressor where in-order delivery of header-compressed packets is not guaranteed.
Reordering channel
A connection over which reordering, as defined above, can occur.
Sequentially early packet
A packet that reaches the decompressor before one or several
packets of the same context identifier (CID) that were delayed on the link. At the time of the arrival of a sequentially early
packet, the packet(s) delayed on the link cannot be differentiated from lost packet(s).
Sequentially late packet
A packet is late within its sequence if it reaches the
decompressor after one or several other packets belonging to the
same CID have been received, although the sequentially late packet was sent from the compressor before the other packet(s).
Pelletier, et al. Informational [Page 4]
Updating packet
A packet that updates the context of the decompressor, e.g., all
packets except R-0 and R-1* in RFC 3095 [1].
Non-updating packet
A packet that does not update the context of the decompressor,
e.g., only R-0 and R-1* in RFC 3095 [1].
Change packet
A packet that updates one or more fields of the context other than the fields pertaining to the functions established with respect to the sequence number (SN). Specifically, it is a packet that
updates fields other than the SN, the IPv4 identifier (IP-ID), the sequence number of an extension header or the RTP timestamp (TS).
3. Applicability of This Document to ROHC Profiles
This document addresses general reordering issues for ROHC profiles. The foremost objectives are to ensure that ROHC implementations do
not forward packets with incorrectly decompressed headers to upper
layers, as well as to limit the possible increase in the rate of
decompression failures or in events leading to context damage, when
compression is applied over reordering channels.
3.1. Profiles within Scope
The following sections outline solutions that are generally
applicable to profiles 0x0001 (RTP), 0x0002 (UDP), and 0x0003 (ESP)
defined in RFC 3095 [1]. Profile 0x0000 (uncompressed) is not
affected by reordering, as the headers are sent uncompressed. The
solutions also apply to profiles for IP-only (0x0004) [3] and for
UDP-Lite (0x0007 and 0x0008) [4]. These profiles are based on the
profiles of RFC 3095 [1] and inherently make the same in-order
delivery assumption.
3.2. Profiles with Special Considerations
Special considerations are needed to make some of the implementation solutions of sections 6.1 and 6.2 applicable to profiles 0x0002 (UDP) [1], 0x0004 (IP-only) [3], and 0x0008 (UDP-Lite) [4]. For these
profiles, the SN is generated at the compressor, as it is not present in headers being compressed. For the least significant bit (LSB)
encoding method, the interpretation interval offset (p) is always
p = -1 (see section 5.1.1) when interpreting the SN. The SN is thus Pelletier, et al. Informational [Page 5]
required to increase for each packet received at the decompressor,
which means that reordered packets cannot be decompressed.
3.3. Profiles Incompatible with Reordering
The ROHC LLA profiles defined in RFC 3242 [5] and RFC 3408 [6] have
been explicitly designed with in-order delivery as a fundamental
requirement to their proper operation. Profiles 0x0005 and 0x0105
can therefore not be implemented over channels where reordering can
occur; this document therefore does not apply to these profiles.
4. Background
ROHC was designed with the assumption that packets are delivered in
order from compressor to decompressor. This was considered as a
reasonable working assumption for links where it was expected that
ROHC would be used. However, many have expressed that it would be
desirable to use ROHC also over connections where in-order delivery
is not guaranteed [7].
4.1. Reordering Channels
The reordering channels that are potential candidates to use ROHC are single-hop channels and multi-hop virtual channels.
A single-hop channel is a point-to-point link that constitutes a
single IP hop. Note that one IP hop could be one or multiple
physical links. For example, a single-hop reordering channel could
be a wireless link that applies error detection and performs
retransmissions to guarantee error-free delivery of all data.
Another example could be a wireless connection that performs
bicasting of data during a handoff procedure.
A multi-hop virtual channel is a virtual point-to-point link that
traverses multiple IP hops. A multi-hop virtual channel would
typically be an IP tunnel, where compression is applied over the
tunnel by the endpoints of the tunnel (not to be confused with single link compression of tunneled packets).
4.2. Robustness Principles of ROHC
Robustness is based on the optimistic approach in the unidirectional and optimistic modes of operation (U/O-mode), and on the secure
reference principle in the bidirectional reliable mode (R-mode).
Both approaches have different characteristics in the presence of
reordering between compressor and decompressor. However, in any
mode, decompression of sequentially early packets will generally be Pelletier, et al. Informational [Page 6]
handled quite well since they will be perceived and treated by the
decompressor as if there had been one or more packet losses.
4.2.1. Optimistic Approach (U/O-mode)
A ROHC compressor uses the optimistic approach to reduce header
overhead when performing context updates in U/O-mode. The compressor normally repeats the same update until it is fairly confident that
the decompressor has successfully received the information. The
number of consecutive packets needed to obtain this confidence is
open to implementations, and this number is normally related to the
packet loss characteristics of the link where header compression is
used (see also [1], section 5.3.1.1.1).
All packet types used in U/O-mode are context updating.
4.2.2. Secure Reference Principle (R-mode)
A ROHC compressor uses the secure reference principle in R-mode to
ensure that context synchronization between ROHC peers cannot be lost due to packet losses. The compressor obtains its confidence that the decompressor has successfully updated the context from a packet
carrying a 7- or 8-bit Cyclic Redundancy Check (CRC) based on
acknowledgements received from the decompressor (see also [1],
section 5.5.1.2).
The secure reference principle makes it possible for a compressor to use packets that do not update the context (i.e., R-0 and R-1* [1]).
5. Problem Description
5.1. ROHC and Reordering Channels
This section reviews different aspects of ROHC susceptible of being
impacted by reordering of compressed packets between ROHC peers.
5.1.1. LSB Interpretation Interval and Reordering
The least significant bit (LSB) encoding method defined in RFC 3095
([1], section 5.7) specifies the interpretation interval offset,
called p, as follows:
For profiles 0x0001, 0x0003, and 0x0007:
p = 1, when bits(SN) <= 4;
p = 2^(bits(SN)-5) - 1 otherwise.
Pelletier, et al. Informational [Page 7]
The resulting table describing the interpretation interval is as
follows:
+-----------+--------------+--------------+
| bits (SN) | Offset p | (2^k-1) - p |
| k | (reordering) | (losses) |
+-----------+--------------+--------------+
| 4 | 1 | 14 |
| 5 | 0 | 31 |
| 6 | 1 | 62 |
| 7 | 3 | 124 |
| 8 | 7 | 248 |
| 9 | 15 | 496 |
+-----------+--------------+--------------+
As shown in the table above, the ability for ROHC to handle
sequentially late packets depends on the number of bits sent in
each packet. For example, a sequentially late packet of type 0
(with either 4 or 6 bits of SN) sets the limit to one packet out
of sequence for successful decompression to be possible.
For profiles 0x0002, 0x0004, and 0x0008:
p = - 1, independently of bits(SN).
A value of p = -1 means that the interpretation interval offset
can only take positive values and that no sequentially late packet can be decompressed if reordering occurs over the link.
The trade-off between reordering and robustness
The ability of ROHC to handle sequentially late packets is limited by the interpretation interval offset of the sliding window used
for LSB encoding. This offset has a very small value for packets with a small number of sequence number (SN) bits, but grows with
the number of SN bits transmitted.
For channels where both packet losses and reordering can occur,
modifications to the interpretation interval face a trade-off
between the amount of reordering and the number of consecutive
packet losses that can be handled by the decompressor. If the
negative offset (i.e., p) is increased to handle a larger amount
of reordering, the value of the positive offset of the
interpretation interval must be decreased. This may impact the
compression efficiency when the channel has a high loss rate. Pelletier, et al. Informational [Page 8]
This is shown in the figure:
<--- interpretation interval (size is 2^k) ---->
|------------------+---------------------------|
Lower v_ref Upper
Bound Bound
<--- reordering --> <--------- losses --------->
max delta(SN) = p max delta(SN) = (2^k-1) - p
where v_ref is the reference value as per [1], section 4.5.1.
In practice, the maximum variation in SN value (max delta(SN)) due to reordering that can be handled will normally correspond to the maximum number of packets that can be reordered. The same applies to the maximum number of consecutive packet losses covered by the robustness interval.
Timer-based compression of RTP TS (see [1], section 4.5.4) provides
means to reduce the number of timestamp bits needed in compressed
headers after longer gaps in the packet stream (e.g., for an audio
stream, this is typically due to silence suppression). To use
timer-based compression, an upper limit on the inter-arrival jitter
must be reliably estimated by the compressor. It should be noted
that although the risk of reordering of course means there is a more significant jitter on the path between the compressor and the
decompressor, there are no special reordering considerations for
timer-based compression. It all still boils down to the task of
estimating the jitter, requiring channel characteristics knowledge at the compressor, and/or jitter estimation figures received from the
decompressor.
5.1.2. Reordering of Packets in R-mode
5.1.2.1. Updating Packets
The compressor always adds references in the sliding window for all
updating packets sent. The compressor removes values older than
values for which it has received an acknowledgement to shrink the
window and thereby increase the compression efficiency.
The decompressor always updates the context when receiving an
updating packet and uses the new reference for decompression.
Acknowledgements are sent to allow the compressor to shrink its
sliding window.
Pelletier, et al. Informational [Page 9]
Reordering between updating packets
The decompressor can update its context from the reception of a
sequentially late updating packet. The decompressor reference is then updated with a value that is no longer in the sliding window of the compressor. This "missing reference" can be caused by
reordering when operating in R-mode.
The result is that the compressor and the decompressor lose
synchronization with each other. When the decompressor
acknowledges the sequentially late packet, the compressor might
already have discarded the reference to this sequence number, and continue to compress packets based on more recent references (in
packet arrival time). Decompression will then be attempted using the wrong reference.
5.1.2.2. Non-Updating Packets
Reordering between non-updating packets only
A non-updating packet that reaches the decompressor out of
sequence only with respect to other non-updating packets can
always be decompressed properly.
Reordering between non-updating packets and updating packets
When a non-updating packet is reordered and becomes sequentially
late with respect to an updating packet, the decompressor may have already updated the context with a new reference when the late
packet is received. It is thus possible for a non-updating packet to be decompressed based on the wrong reference because of
reordering when operating in R-mode.
Since decompression of non-updating packets cannot be verified,
this can lead to a packet erroneously decompressed to be forwarded to upper layers.
5.1.3. Reordering of Packets in U/O-mode
Reordering between non-change packets only
When only non-change packets are reordered with respect to each
other, decompression of sequentially late packets is limited by
the offset p of the interpretation interval (see section 5.1.1).
Decompression of a sequentially late packet with SN = x is
possible if the value of the SN of the packet that last updated
the context was less than or equal to x + p.
Pelletier, et al. Informational [Page 10]
Problems occur if context(SN) has increased by more than p with
respect to field(SN) carried within the packet to decompress.
This means that for a well-behaved stream with a constant unit
increase in the RTP SN, a packet can arrive up to p packets out of sequence and still be correctly decompressed. Otherwise, it
cannot be properly decompressed. It also means that if the
compressor sends two consecutive packets with SN(packet1)=100 and SN(packet2)=108 when p=7, packet1 cannot be decompressed if it
arrives even one packet late due to reordering.
Reordering involving change packets
When a packet is reordered and becomes sequentially late with
respect to a change packet, decompression of the late packet may
eventually fail, as the context information required for
successful decompression may not be available anymore.
Decompression can always be verified since all U/O-mode packet types are context updating. Consequently, a failure to decompress a packet that is caused by reordering can be detected, and context
invalidation due to reordering can thus be avoided. The risk of
forwarding incorrectly decompressed packets to upper layers is
therefore small when operating in U/O-mode. For channels known to
reorder packets, U/O-mode should therefore be the preferred mode of
operation. The additional risk of losing context synchronization, or for erroneous packet to be delivered to upper layers, is limited.
5.1.4. Reordering on the Feedback Channel
For R-mode, upon reception of an acknowledgement, the compressor
searches the sliding window to locate an updating packet with the
corresponding SN; if it is not found, the acknowledgement is invalid and is discarded ([1], section 5.5.1.2). In other words, feedback
received out of order either is still useful or is discarded.
In U/O-mode, if the compressor updates its context based on feedback, the same logic as for R-mode applies in practice.
Reordering on the feedback channel has thus no impact in either mode.
5.1.5. List Compression
ROHC list compression is an additional compression scheme for RTP
contributing source (CSRC) lists and IP extension header chains. The base is called table-based item compression, and it is almost
completely independent from the rest of the ROHC compression logic.
Therefore, this part of the scheme does not exhibit any special Pelletier, et al. Informational [Page 11]
vulnerabilities when it comes to reordering, assuming a reasonable
optimistic approach is used in U/O-mode. Specifically, it does not
suffer significantly from the "missing reference" problem when
operating in R-mode.
On top of the table-based item compression mechanism, an additional
compression technique may be used, called reference based list
compression. Reference based list compression however has a logic
that is similar to the rest of the ROHC compression logic, and
therefore it suffers from similar reordering vulnerabilities,
especially the "missing reference" problem of R-mode. Note, however, that the generation identifier used in U/O-mode makes that scheme
more robust to reordering.
When using list encoding type 1, 2, or 3, which makes use of
reference lists, decompression will succeed only if all individual
items are known by the decompressor, along with the correct reference list required to properly decompress the packet. List compression
using the "Generic scheme", also known as "Encoding type 0", is not
using reference based list compression, and type 0 decompression will thus succeed as long as all individual items are known by the
decompressor. Because of this, type 0 list compression should be the preferred method used when operating over reordering channels.
5.1.
6. Reordering and Mode Transitions
Transition from U/O-mode to R-mode
This transition can be affected by reordering if a packet type 0
(UO-0) is reordered and delayed by at least one round-trip time
(RTT). If the decompressor initiates a mode change request to
R-mode in the meantime, the reordered UO-0 packet may be handled
as an R-0 packet; it can be erroneously decompressed and forwarded to upper layers. This is because the decompressor can switch to
R-mode as soon as it sends the acknowledgement Ack(SN, R) to the
compressor (see also [1], section 5.6).
Transition from R-mode to U/O-mode
A similar situation as above can occur during this transition.
However, because the outcome of the decompression is always
verified using a CRC verification in U/O-mode, the reordered
packet will most likely fail decompression and will be discarded. The above situation, although it is not deemed to occur frequently,
is still possible; thus, mode transitions from U/O-mode to R-mode
should be avoided when reordering can occur.
Pelletier, et al. Informational [Page 12]
5.2. Consequences of Reordering
The context updating properties of the packets exchanged between ROHC peers are the most important factors to consider when deriving the
impacts of reordering. For this reason, the robustness properties of the U/O-mode and of the R-mode are affected differently.
The effects of reordering on ROHC can be summarized as follows:
- Functionality incompatible with reordering;
- Increased probability of context damage (loss of synchronization); - Increased number of decompression failures - Detected (U/O/R-mode); - Increased number of decompression failures - Undetected (R-mode).
5.2.1. Functionality Incompatible with Reordering
There is one optional ROHC function that cannot work in the presence of reordering between ROHC peers.
The ROHC segmentation scheme (see [1], section 5.2.5) relies entirely on the in-order delivery of each segment, as there is no sequencing
information in the segments. A segmented packet for which one (or
more) segment is received out of order cannot be decompressed, and it is discarded by the decompressor. Therefore, segmentation should not be used if there can be reordering between the ROHC peers.
The use of this optional feature is open to implementations and is
local to the compressor only; it does not impact the decompressor.
5.2.2. Context Damage (Loss of Synchronization)
Reordering of packets between ROHC peers can impact the robustness
properties of the optimistic approach (U/O-mode) as well as the
reliability of the secure reference principle (R-mode).
The successful decompression of a sequentially late change packet
(U/O-mode) and/or updating packet (R-mode) can update the context of the decompressor in a manner unexpected by the compressor. This can lead to a loss of context synchronization between the ROHC peers.
5.2.3. Detected Decompression Failures (U/O/R-mode)
Reordering of packets between ROHC peers can lead to an increase in
the number of decompression failures for context updating packets
(see sections 5.1.2.1 and 5.1.3). Fortunately, as the outcome of the decompression of updating packets can be verified, the decompressor
can reliably detect decompression failures, including those caused by reordering, and discard the packet. Note that local repairs, subject Pelletier, et al. Informational [Page 13]
to the limitations stated in [1] section 5.3.2.2.3, can still be
performed.
5.2.4. Undetected Decompression Failures (R-mode only)
Reordering of packets between ROHC peers can lead to an increase in
the number of decompression errors for non-updating packets. For
R-mode, decompression of R-0 and R-1* packets cannot be verified. If reordering occurs and decompression is performed using the wrong
secure reference (see section 5.1.2.1 and 5.1.2.2), the decompressor cannot reliably detect such errors. As a result, erroneous packets
may be forwarded to upper layers.
6. Making ROHC Tolerant against Reordering
This section describes different approaches that can improve the
performance of ROHC when used over reordering channels and minimize
the effects of reordering. Examples are provided to guide
implementers and designers of new profiles. The solutions target
either the properties of ROHC implementations or the specification of profiles. This is covered by sections 6.1 and 6.2, respectively.
6.1. Properties of ROHC Implementations
Existing ROHC profiles can be implemented with the capability to
properly handle packet reordering. The methods described in this
section conform with, and thus do not require any modifications to,
the ROHC specifications within scope of this document (see section
3). Specifically, the methods presented in this section can be
implemented without any impairment to interoperability with other
ROHC implementations that do not use these methods.
The methods suggested here may, however, lower the compression
efficiency, and these modifications should not be used when
reordering is known not to occur. Some of these methods aim to
increase the decompression success rate at the decompressor, while
others aim to avoid context damage that would cause a loss of context synchronization between compressor and decompressor.
The methods proposed are each addressing specific issues listed in
section 5 and can be combined to achieve better robustness against
reordering.
6.1.1. Compressing Headers with Robustness against Reordering
The methods described in this section are methods local only to the
compressor implementation. They can be used without modifications or impact to the decompressor.
Pelletier, et al. Informational [Page 14]
6.1.1.1. Reordering and the Optimistic Approach
The optimistic approach is affected by the reordering characteristics of the channel when operating over a reordering channel. Compressor implementations should therefore adjust their optimistic approach
strategy to match both packet loss and reordering characteristics.
For example, the number of repetitions for each context update can be increased. The compressor should ensure that each update is repeated until it is reasonably confident that at least one change packet in
the sequence of repetitions has reached the decompressor before the
first packet sent after this sequence.
6.1.1.2. Reordering and the Secure Reference Principle
Fundamental to the secure reference principle is that only values
acknowledged by the decompressor can be used as reference for
compression. In addition, some of the packet types used in R-mode do not include a CRC over the original uncompressed header, and the
decompressor has no means to verify the outcome of the decompression. Decompression of non-updating packet types thus entirely relies on
the cumulative effect of previous updates to the secure reference,
and the compressed data is based on the current value of the
reference. This reference must be synchronized between ROHC peers.
For R-0 and R-1* packets, the reception of the encoded bits applied
to the secure reference is sufficient for correct decompression, but only when in-order delivery between ROHC peers is guaranteed.
Avoiding the "missing reference" problem (section 5.1.2.1)
A compressor implementation can delay the advance in the sliding
window to a reference acknowledged by the decompressor, until it
has confidence that no acknowledgement for any of the values that could be discarded can be received. This confidence can be based on the maximum delay that reordering can introduce over the
channel.
6.1.1.3. Robust Selection of Compressed Header
Packet formats can be chosen with an interpretation interval for the LSB encoded sequence number that allows for larger negative offsets
(see section 5.1.1). This provides the capability to decompress
sequentially late packets with a greater amount of reordering.
To achieve this, the compressor should be implemented conservatively in terms of the choice of packet types to send, by transmitting
packets with more sequence number bits. As shown in the table in Pelletier, et al. Informational [Page 15]
section 5.1.1, using 8 bits of SN allows a packet to be decompressed when the reordering leads to up to 7 units in sequence number
variation (i.e., delta(SN)). Increasing the number of SN bits (i.e., using a larger SN_k [1]) transmitted will make ROHC even more
tolerant to reordering.
For example, a conservative compressor implementation could use the
packet types as shown in the table below:
+----------------------+-------------------------+
| Optimal Packet Type | Alternative Packet Type |
| (without reordering) | (reordering possible) |
+----------------------+-------------------------+
| UO-0 | UOR-2*-ext0 |
| R-0 | R-1*-ext0 |
| R-0-CRC | UOR-2*-ext0 |
| R-1* | R-1*-ext0 |
| UO-1 | UOR-2-ext0 |
| UO-1-TS | UOR-2-TS-ext0 |
| UO-1-ID | UO-1-ID-ext3 (with S=1) |
| | UOR-2-ID-ext0 |
| UOR-2* | UOR-2*-ext0 |
+----------------------+-------------------------+
Such a compressor implementation would thus always be sending at
least 3 octets (R-mode) or 4 octets (U/O-mode). This is a trade-off when compared to the 1 octet that can be sent by a more aggressive
implementation operating on a channel with no reordering.
Note that since the interpretation interval for profiles 0x0002,
0x0004, and 0x0008 is always p = -1 independently of bits(SN), the
methods suggested in this section will not work for these profiles
unless this value is modified (section 6.2.1).
6.1.2. Implementing a Reordering-Tolerant Decompressor
The methods described in this section are methods local only to the
decompressor implementation. They can be used without modifications or impact to the compressor.
6.1.2.1. Decompressor Feedback Considerations
Reducing the feedback rate when the flow behaves linearly
The decompressor should reduce its feedback rate when a large
number of UOR-2 packets with extensions are received, when the
flow behaves linearly (i.e., when only fields pertaining to the Pelletier, et al. Informational [Page 16]
functions established with respect to the sequence number are
changing).
In particular, if the compressor implementation makes a more
conservative selection of packet types (section 6.1.1.3) in order to handle reordering, the decompressor should try to avoid sending more feedback than it would for the case where the more optimal
packet types are used. This can be useful to minimize the usage
of the feedback channel, thereby improving efficiency of the link. Note that even if the decompressor does not make this adjustment
to its feedback rate, packet losses or context damages will not
increase.
Acknowledgements and sequentially late packets
Reordered feedback (or feedback for packets received out of order) will not cause problems (see section 5.1.4). However, the
decompressor should not send acknowledging feedback for a packet
that can be identified as being sequentially late (e.g., based on the sequence number of the packet), as the current state of the
context will better reflect the compressor context than the
content of the reordered packet.
6.1.2.2. Considerations for Local Repair Mechanisms
When decompression fails, and if reordering can be assumed to be the cause of this failure, subsequent decompressions may be attempted for sequentially late packets by going backward in the interpretation
interval (as opposed to moving forward for local repair). If one of the decompression attempts is successful, the late packet may be
passed on to upper layers with or without updating the decompressor
context. If the subsequent decompression attempt fails, the packet
should be handled according to [1] section 5.3.2.2.3.
6.2. Specifying ROHC Profiles with Robustness against Reordering
6.2.1. Profiles with Interpretation Interval Offset p = -1
New revisions of profiles 0x0002 (UDP) [1], 0x0004 (IP-only) [3], and 0x0008 (UDP-Lite) [4] should redefine how the value of the offset p
is determined, and use the same algorithm as in profile 0x0001 [1]
instead of p = -1 independently of bits(SN) (section 5.1.1).
While such a change would make these updated profiles slightly less
robust to packet losses, they would still be no less robust than
profile 0x0001.
Pelletier, et al. Informational [Page 17]
6.2.2. Modifying the Interpretation Interval Offset
The interpretation interval offset p could be modified for existing
profiles to handle reordering while improving the compression
efficiency when compared to the solution in section 6.1.1.3.
6.2.2.1. Example Profile for Handling Reordering
The value of the interpretation interval offset p can be adjusted to achieve a robustness against reordering similar to the effect of
selecting packet types as suggested in section 6.1.1.3.
Consider a scenario where robustness against packet losses is kept a priority, and for which of a value p=7 is deemed enough. In this
case, a ratio where the positive offset is about twice as large as
the negative offset can be used. This leaves a value of p = 2^k/ 3. The resulting values are shown in the following table:
+-----------+--------------+----------------+
| bits (SN) | Offset p | Positive range |
| k | (reordering) | (losses) |
+-----------+--------------+----------------+
| 4 | 5 | 10 |
| 5 | 10 | 21 |
| 6 | 21 | 42 |
| 7 | 42 | 85 |
| 8 | 85 | 170 |
| 9 | 170 | 341 |
+-----------+--------------+----------------+
Using this value for p, a fair amount of reordering can be handled
without having to send UOR-2 packets most of the time. The trade-off is that this is at the expense of robustness against packet losses. 6.2.2.2. Defining the Values of p for New Profiles
As described in RFC 3095 [1], the interpretation interval when
sending k bits of SN is defined as follows:
f(v_ref, k) = [v_ref - p, v_ref + (2^k - 1) - p]
The negative bound (v_ref - p) limits the ability to handle
reordering, and the positive bound (v_ref + (2^k - 1) - p) limits the ability to handle packet losses.
Adjusting p will increase one of these ranges, while the other range will decrease. This trade-off between the capability to handle Pelletier, et al. Informational [Page 18]
reordering and packet losses, including how these correlate with each other, should be considered in a ROHC profile that is meant to handle reordering.
For example, if it is desirable for a profile to be as robust against reordering (negative range) and against packet losses (positive
range), this range can be made equal by setting p near (2^k / 2).
7. Security Considerations
This document does not include additional security risks to [1]. In addition, it may lower risks related to context damage in R-mode with injected packets when sequentially late packets do not update the
context (section 6.1.2.1).
8. Acknowledgements
Thanks to the committed WG document reviewers, Carl Knutsson and Mark West, for their review efforts. Thanks also to Aniruddha Kulkarni,
Ramin Rezaiifar, and Gorry Fairhurst for their constructive comments.
9. Informative References
[1] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001.
[2] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology
and Channel Mapping Examples", RFC 3759, April 2004.
[3] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[4] Pelletier, G., "RObust Header Compression (ROHC): Profiles for
User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.
[5] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, April 2002.
[6] Liu, Z. and K. Le, "Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header
Compression (ROHC) Profile", RFC 3408, December 2002.
Pelletier, et al. Informational [Page 19]
[7] Ash, J., Goode, B., Hand, J., and R. Zhang, "Requirements for
Header Compression over MPLS", RFC 4247, November 2005.
Authors’ Addresses
Ghyslain Pelletier
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 43
Fax: +46 920 996 21
EMail: ghyslain.pelletier@https://www.doczj.com/doc/0f13151742.html,
Lars-Erik Jonsson
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 61
Fax: +46 920 996 21
EMail: lars-erik.jonsson@https://www.doczj.com/doc/0f13151742.html,
Kristofer Sandlund
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 41 58
Fax: +46 920 996 21
EMail: kristofer.sandlund@https://www.doczj.com/doc/0f13151742.html,
Pelletier, et al. Informational [Page 20]
钥匙开机其实并不神秘 还记不记得你第一次见到装电脑的时候，JS将CPU、存、显卡等插在主板上，然后从兜里掏出自己的钥匙（或者是随便找颗螺丝）在主板边上轻轻一碰，电脑就运转起来了的情景吗？是不是感到很惊讶（笔者第一次见到的时候反正很惊讶）！面对一个全新的主板，JS总是不用看任何说明书，就能在1、2分钟之将主板上密密麻麻的跳线连接好，是不是觉得他是高手？呵呵，看完今天的文章，你将会觉得这并不值得一提，并且只要你稍微记一下，就能完全记住，达到不看说明书搞定主板所有跳线的秘密。 这个叫做真正的跳线
首先我们来更正一个概念性的问题，实际上主板上那一排排需要连线的插针并不叫做“跳线”，因为它们根本达不”到跳线的功能。真正的跳线是两根/三根插针，上面有一个小小的“跳线冒”那种才应该叫做“跳线”，它能起到硬件改变设置、频率等的作用；而与机箱连线的那些插针根本起不到这个作用，所以真正意义上它们应该叫做面板连接插针，不过由于和“跳线”从外观上区别不大，所以我们也就经常管它们叫做“跳线”。 看完本文，连接这一大把的线都会变得非常轻松 至于到底是谁第一次管面板连接插针叫做“跳线”的人，相信谁也确定不了。不过既然都这么叫了，大家也都习惯了，我们也就不追究这些，所以在本文里，我们姑且管面板连接插针叫做跳线吧。 轻松识别各连接线的定义 为了更加方便理解，我们先从机箱里的连接线说起。一般来说，机箱里的连接线上都采用了文字来对每组连接线的定义进行了标注，但是怎么识别这些标注，这是我们要解决的第一个问题。实际上，这些线上的标注都是相关英文的缩写，并不难记。下面我们来一个一个的认识（每图片下方是相关介绍）！
电脑主机内部所有接线连 接方法 Prepared on 22 November 2020
电脑主机内部所有接线连接方法 主机外的连线虽然简单，但我们要一一弄清楚哪个接口插什么配件、作用是什么。对于这些接口，最简单的连接方法就是对准针脚，向接口方向平直地插进去并固定好。 电源接口（黑色）：负责给整个主机电源供电，有的电源提供了开关，笔者建议在不使用电脑的时候关闭这个电源开关（图1）。 图1 PS/2接口（蓝绿色）：PS/2接口有二组，分别为下方（靠主板PCB方向）紫色的键盘接口和上方绿色的鼠标接口（图2），两组接口不能插反，否则将找不到相应硬件；在使用中也不能进行热拔插，否则会损坏相关芯片或电路。 图2
USB接口（黑色）：接口外形呈扁平状，是家用电脑外部接口中唯一支持热拔插的接口，可连接所有采用USB接口的外设，具有防呆设计，反向将不能插入。 LPT接口（朱红色）：该接口为针角最多的接口，共25针。可用来连接打印机，在连接好后应扭紧接口两边的旋转螺丝（其他类似配件设备的固定方法相同）。 COM接口（深蓝色）：平均分布于并行接口下方，该接口有9个针脚，也称之为串口1和串口2。可连接游戏手柄或手写板等配件。 Line Out接口（淡绿色）：靠近COM接口，通过音频线用来连接音箱的Line接口，输出经过电脑处理的各种音频信号(图3)。 图3
Line in接口（淡蓝色）：位于Line Out和Mic中间的那个接口，意为音频输入接口，需和其他音频专业设备相连，家庭用户一般闲置无用。 Mic接口（粉红色）：粉红色是MM喜欢的颜色，而聊天也是MM喜欢的。MIC接口可让二者兼得。MIC接口与麦克风连接，用于聊天或者录音。 显卡接口（蓝色）：蓝色的15针D-Sub接口是一种模拟信号输出接口（图4），用来双向传输视频信号到显示器。该接口用来连接显示器上的15针视频线，需插稳并拧好两端的固定螺丝，以让插针与接口保持良好接触。 MIDI/游戏接口（黄色）：该接口和显卡接口一样有15个针脚，可连接游戏摇杆、方向盘、二合一的双人游戏手柄以及专业的MIDI键盘和电子琴。 网卡接口：该接口一般位于网卡的挡板上（目前很多主板都集成了网卡，网卡接口常位于US B接口上端）。将网线的水晶头插入，正常情况下网卡上红色的链路灯会亮起，传输数据时则亮起绿色的数据灯。主机内的连线有简单的也有复杂的，但无论简单还是复杂，我们DIYer都要攻克这些困难，这样才能真正地组装起一台可以流畅运行的电脑。 1．电源连线
机箱主板插连接线图解 1.一般有7个接口（AUDIO，USB，HDD-LED，两个PW-LED,PW开关，重启开关）以上为一般机箱，假如弄到特殊的，这里也很难说明白 2.对于AUDIO和USB接口的都为9针借口，各有一个卡位，但是位置不一样，所以LZ只要留心点就很容易在主板上发现这两个接口，因为主板上那9针是唯一的，不可能接错，而USB的9针虽然在主板上有两三个，不过都是一样的，作为后备用，所以LZ接那一个都没关系 3.对于另外那几个也很容易判断，都是两针，不过不知道为什么，POWER-LED的两针是分开，其余都一样 4.主板上都有显示那两针是接什么都，通常每块主板的位置都差不远，只要LZ习惯就好 5.对于HDD-LED，两个PW-LED,PW开关，重启开关各两针，要小心的是正负，一般有颜色的那条线为正，白色为负；或者看接口那黑色的头上面，有一个三角形箭头，有三角的那端为正。 钥匙开机其实并不神秘 还记不记得你第一次见到装电脑的时候，JS将CPU、内存、显卡等插在主板上，然后从兜里掏出自己的钥匙（或者是随便找颗螺丝）在主板边上轻轻一碰，电脑就运转起来了的情景吗？是不是感到很惊讶（笔者第一次见到的时候反正很惊讶）！面对一个全新的主板，JS总是不用看任何说明书，就能在1、2分钟之内将主板上密密麻麻的跳线连接好，是不是觉得他是高手？呵呵，看完今天的文章，你将会觉得这并不值得一提，并且只要你稍微记一下，就能完全记住，达到不看说明书搞定主板所有跳线的秘密。
这个叫做真正的跳线 首先我们来更正一个概念性的问题，实际上主板上那一排排需要连线的插针并不叫做“跳线”，因为它们根本达不”到跳线的功能。真正的跳线是两根/三根插针，上面有一个小小的“跳线冒”那种才应该叫做“跳线”，它能起到硬件改变设置、频率等的作用；而与机箱连线的那些插针根本起不到这个作用，所以真正意义上它们应该叫做面板连接插针，不过由于和“跳线”从外观上区别不大，所以我们也就经常管它们叫做“跳线”。
在主板上，我们可以看到一个长方形的插槽，这个插槽就是电源为主板提供供电的插槽（如下图）。目前主板供电的接口主要有24针与 20针两种，在中高端的主板上，一般都采用2 4PIN的主板供电接口设计，低端的产品一般为20PIN。不论采用24PIN和20PIN，其插法都是一样的。 主板上24PIN的供电接口 主板上20PIN的供电接口
电源上为主板供电的24PIN接口 为主板供电的接口采用了防呆式的设计，只有按正确的方法才能够插入。通过仔细观察也会发现在主板供电的接口上的一面有一个凸起的槽，而在电源的供电接口上的一面也采用了卡扣式的设计，这样设计的好处一是为防止用户反插，另一方面也可以使两个接口更加牢固的安装在一起.
二、认识CPU供电接口图解安装详细过程 为了给CPU提供更强更稳定的电压，目前主板上均提供一个给CPU单独供电的接口（有4针、6针和8针三种），如图： 主板上提供给CPU单独供电的12V四针供电接口
电源上提供给CPU供电的4针、6针与8针的接口 安装的方法也相当的简单，接口与给主板供电的插槽相同，同样使用了防呆式的设计，让我们安装起来得心应手。
三、认识SATA串口图解SATA设备的安装 SATA串口由于具备更高的传输速度渐渐替代PATA（IDE）并口成为当前的主流，目前大部分的硬盘都采用了串口设计，由于SATA的数据线设计更加合理，给我们的安装提供了更多的方便。接下来认识一下主板上的SATA接口。这图片跟下面这图片便是主板上提供的SA TA接口，也许有些朋友会问，两块主板上的SATA口“模样”不太相同。 大家仔细观察会发现，在下面的那图中，SATA接口的四周设计了一圈保护层，这样对接口起到了很好的保护作用，在一起大品牌的主板上一般会采用这样的设计。
Q：电脑电源黄线是+12V的可我找不到-12V 请问我该怎么接？ A：1、千万不能接到-12V上，这样就成了24V了，要接到地线上，就是黑色的线（所有的黑线都是负极他们是相通的），也可以接到机箱上，机箱的电位就是零，和黑线是通的。 2、-12V 是蓝色的线，对0V黑线，通常只能输出大约0.5A的小电流，请注意。 电脑电源20pin与24pin接线区别及各针角对应电压 红色：代表+5V电源线（主板、硬盘、光驱等硬件上的芯片工作电压）。 黄色：代表+12V电源线（硬盘、光驱、风扇等硬件上的工作电压，和-12V同时向串口提供EIA电源）。 橙色：代表+3.3V电源线（直接向DIMM、AGP插槽供电）。 灰色：代表P.G信号线（电源状态信息线，它是其他电源线通过一定电路计算所得到的结果，当按下电脑开头键后，这个信号表示电源良好可以开机无信号说明有故障主板自动监测）。蓝色：代表-12V电源线（向串口提供EIA电源）。 白色：代表-5V电源线（软驱锁相式数据分离电路）。 紫色：代表+5V StandBy电源线（关机后为主板的一小部分电路提供动力，以检测各种开机命令). 绿色：代表PS-ON信号线（主板电源开／关的信号线，未接通时有一定电压） 黑色：系统电路的地线。 U V W是三相电源中表示3根火线的字母，3根火线在实际应用中可以都是用黑色线，也可以分分为红，黄，蓝3种颜色。PE表示地线，一般用黄绿双色线。 N L 则是零线火线，单相电源中L（火线）一般用红色，N（零线）一般用蓝色 相线：红、黄或红绿 零线：蓝或黑 地线：黄绿相间 1、+5V（红色线）：转换各种逻辑电路。 2、+12V（黄色线）：驱动磁盘驱动器马达和所有风扇（例外：笔记本电脑的风扇使用+5V 或+3.3V）。 3、+3.3V（橙色线）：为CPU、主板、PCI（Peripheral Component Interconnect 外部设备互连）总线、I/O控制电路供电。 4、+5VSB（Stand By、紫色线）：负责远程电源的启动（大于720mA，主板启动只要0.01A）。 5、PS-ON（绿色线）：负责操作系统管理电源的开关，是一种主板信号，和+5VSB一起统称为软电源。小于1V时开启电源、大于4.5V时关闭电源，实现软件开关机、网络远程唤醒功能（设置唤醒时间、通过键盘开机）（和GND接电线短接就可启动电源） 6、-5V（白色线）：（负电压很少使用、如SFX去掉了-5V） 7、-12V（蓝色线）：PG信号(Power Good、灰色线、+5V信号(+3.0~+6.0V))：系统启动前，电源(电源打开后0.1秒~0.5秒发出该信号)进行内部检查和测试，测试通过则发给主板一个信号，故电源的开启受控于主板上的电源监控部件。PG信号非常重要，即使各路输出都正
电脑各种主板USB接线方法图解 主板USB管脚接口大全 一、概述 因为每个USB接口能够向外设提供＋5V500MA的电流，当我们在连接板载USB接口时，一定要严格按照主板的使用说明书进行安装。绝对不能出错，否则将烧毁主板或者外设。相信有不少朋友在连接前置USB插线时也发生过类似的“冒烟事见“。这就需要我们能够准确判别前置USB线的排列顺序如果我们晓得USB接口的基本布线结构，那问题不是就迎刃而解了吗。 二、USB接口实物图 主机端： 接线图： VCC Data－ Data＋ GND 实物图： 设备端： 接线图： VCC GND Data－ Data＋三、市面上常见的USB接口的布线结构 这两年市面上销售的主板，板载的前置USB接口，使用的都是标准的九针USB接口，第九针是空的，比较容易判断。但是多数品牌电脑使用的都是厂家定制的主板，我们维修的时候根本没有使用说明书；还有像以前的815主板，440BX，440VX主板等，前置USB的接法非常混乱，没有一个统一的标准。当我们维修此类机器时，如何判断其接法呢？ 现在，把市面上的比较常见的主板前置USB接法进行汇总，供大家参考。(说明：■代表有插针，□代表有针位但无插针。) 1、六针双排 这种接口不常用，这种类型的USB插针排列方式见于精英P6STP－FL(REV：1.1)主板，用于海尔小超人766主机。其电源正和电源负为两个前置USB接口共用，因此前置的两个USB 接口需要6根线与主板连接，布线如下表所示。 ■DATA1+ ■DAT A1- ■VCC
■DATA2+ ■GND 2、八针双排 这种接口最常见，实际上占用了十针的位置，只不过有两个针的位置是空着的，如精英的P4VXMS(REV：1.0)主板等。该主板还提供了标准的九针接法，这种作是为了方便DIY在组装电脑时连接容易。 ■VCC ■DATA－ ■DATA＋ □NUL ■GND ■GND □NUL ■DATA＋ ■DATA－ ■VCC 微星MS-5156主板采用的前置USB接口是八针互反接法。虽然该主板使用的是Intel 430TX芯片组，但首先提供了当时并不多见的USB1.0标准接口两个，只不过需要使用单独的引线外接。由于该主板的USB供电采用了限流保护技术，所以即使我们把USB的供电线接反，也不会导致主板无法启或烧毁USB 设备的情况产生。 ■VCC ■DATA－ ■DATA＋ ■GND ■GND ■DATA＋ ■DATA- ■VCC 以下这种接口比较常见，多使用于815，或440BX较早的主板上。 ■VCC ■DATA＋ ■DATA－ ■GND ■VCC
主板插线-开机键的接法 作为一名新手，要真正从头组装好自己的电脑并不容易，也许你知道CPU应该插哪儿，内存应该插哪儿，但遇到一排排复杂跳线的时候，很多新手都不知道如何下手。 钥匙开机其实并不神秘 还记不记得你第一次见到装电脑的时候，JS将CPU、内存、显卡等插在主板上，然后从兜里掏出自己的钥匙（或者是随便找颗螺丝）在主板边上轻轻一碰，电脑就运转起来了的情景吗？是不是感到很惊讶（笔者第一次见到的时候反正很惊讶）！面对一个全新的主板，JS总是不用看任何说明书，就能在1、2分钟之内将主板上密密麻麻的跳线连接好，是不是觉得他是高手？呵呵，看完今天的文章，你将会觉得这并不值得一提，并且只要你稍微记一下，就能完全记住，达到不看说明书搞定主板所有跳线的秘密。
这个叫做真正的跳线 首先我们来更正一个概念性的问题，实际上主板上那一排排需要连线的插针并不叫做“跳线”，因为它们根本达不”到跳线的功能。真正的跳线是两根/三根插针，上面有一个小小的“跳线冒”那种才应该叫做“跳线”，它能起到硬件改变设置、频率等的作用；而与机箱连线的那些插针根本起不到这个作用，所以真正意义上它们应该叫做面板连接插针，不过由于和“跳线”从外观上区别不大，所以我们也就经常管它们叫做“跳线”。
看完本文，连接这一大把的线都会变得非常轻松 至于到底是谁第一次管面板连接插针叫做“跳线”的人，相信谁也确定不了。不过既然都这么叫了，大家也都习惯了，我们也就不追究这些，所以在本文里，我们姑且管面板连接插针叫做跳线吧。 为了更加方便理解，我们先从机箱里的连接线说起。一般来说，机箱里的连接线上都采用了文字来对每组连接线的定义进行了标注，但是怎么识别这些标注，这是我们要解决的第一个问题。实际上，这些线上的标注都是相关英文的缩写，并不难记。下面我们来一个一个的认识（每张图片下方是相关介绍）！
作为一名新手，要真正从头组装好自己的并不容易，也许你知道CPI应该插哪儿, 内存应该插哪儿，但遇到一排排复杂跳线的时候，很多新手都不知道如何下手。 钥匙开机其实并不神秘 还记不记得你第一次见到装电脑的时候，JS将CPU内存、显卡等插在主板上，然后从兜里掏出自己的钥匙（或者是随便找颗螺丝）在主板边上轻轻一碰，电脑就运转起来了的情景吗？是不是感到很惊讶（笔者第一次见到的时候反正很惊讶）！面对一个全新的主板，JS总是不用看任何说明书，就能在1、2分钟之内将主板上密密麻麻的跳线连接好，是不是觉得他是高手？呵呵，看完今天的文章，你将会觉得这并不值得一提，并且只要你稍微记一下，就能完全记住，达到不看说明书搞定主板所有跳线的秘密。 这个叫做真正的跳线 首先我们来更正一个概念性的问题，实际上主板上那一排排需要连线的插针并不叫做“跳线”，因为它们根本达不”到跳线的功能。真正的跳线是两根/ 三根插针，上面 有一个小小的“跳线冒”那种才应该叫做“跳线”，它能起到硬件改变设置、频率等的作用；而与机箱连线的那些插针根本起不到这个作用，所以真正意义上它们应该叫做面板连接插针，不过由于和“跳线”从外观上区别不大，所以我们也就经常管它们叫做“跳线”。 看完本文，连接这一大把的线都会变得非常轻松 至于到底是谁第一次管面板连接插针叫做“跳线”的人，相信谁也确定不了。不过既然都这么叫了，大家也都习惯了，我们也就不追究这些，所以在本文里，我们姑且管面板连接插针叫做跳线吧。 为了更加方便理解，我们先从机箱里的连接线说起。一般来说，机箱里的连接线上都采用了文字来对每组连接线的定义进行了标注，但是怎么识别这些标注，这是我们要解决的第一个问题。实际上，这些线上的标注都是相关英文的缩写，并不难记。下面我们来一个一个的认识（每张图片下方是相关介绍）！ 电源开关：POWER SW 英文全 称： Power Swicth 可能用名： POWE、RPOWER SWIT、CHON/OFF、POWER SET、U P W 功能定义：机箱前面的开机按钮 复位/重启开关：RESET SW 英文全称：Reset Swicth 可能用名：RESET Reset Swicth、Reset Setup、RST等电脑板插线方法图解详解
主板插线接口大全 - 装机必看 2007-11-04 09:57 主板插线接口大全 - 装机必看 前段时间好多同学跟我反映说装机已经基本可以了 但是插个种线很困难所以小鱼就搜集了一些这方面的资料 让大家参考一下 很多朋友对各种接口和线缆的连接方法还不是很清楚，那么这里同样以Intel 平台为例，借助两块不同品牌的主板，对各种接口及其连接方法进行一下详细的介绍。 一、认识主板供电接口图解安装详细过程 在主板上，我们可以看到一个长方形的插槽，这个插槽就是电源为主板提供供电的插槽（如下图）。目前主板供电的接口主要有24针与 20针两种，在中高端的主板上，一般都采用24PIN的主板供电接口设计，低端的产品一般为 20PIN。不论采用24PIN和20PIN，其插法都是一样的。
主板上24PIN的供电接口 主板上20PIN的供电接口
电源上为主板供电的24PIN接口 为主板供电的接口采用了防呆式的设计，只有按正确的方法才能够插入。通过仔细观察也会发现在主板供电的接口上的一面有一个凸起的槽，而在电源的供电接口上的一面也采用了卡扣式的设计，这样设计的好处一是为防止用户反插，另一方面也可以使两个接口更加牢固的安装在一起。 二、认识CPU供电接口图解安装详细过程 为了给CPU提供更强更稳定的电压，目前主板上均提供一个给CPU单独供电
的接口（有4针、6针和8针三种），如下图： 主板上提供给CPU单独供电的12V四针供电接口
电源上提供给CPU供电的4针、6针与8针的接口 安装的方法也相当的简单，接口与给主板供电的插槽相同，同样使用了防呆式的设计，让我们安装起来得心应手。 三、认识SATA串口图解SATA设备的安装 SATA串口由于具备更高的传输速度渐渐替代PATA并口成为当前的主流，目前大部分的硬盘都采用了串口设计，由于SATA的数据线设计更加合理，给我们
904305016.doc Q：电脑电源黄线是+12V的可我找不到-12V 请问我该怎么接？ A：1、千万不能接到-12V上，这样就成了24V了，要接到地线上，就是黑色的线（所有的黑线都是负极他们是相通的），也可以接到机箱上，机箱的电位就是零，和黑线是通的。 2、-12V 是蓝色的线，对0V黑线，通常只能输出大约0.5A的小电流，请注意。 电脑电源20pin与24pin接线区别及各针角对应电压 红色：代表+5V电源线（主板、硬盘、光驱等硬件上的芯片工作电压）。 黄色：代表+12V电源线（硬盘、光驱、风扇等硬件上的工作电压，和-12V同时向串口提供EIA电源）。 橙色：代表+3.3V电源线（直接向DIMM、AGP插槽供电）。 灰色：代表P.G信号线（电源状态信息线，它是其他电源线通过一定电路计算所得到的结果，当按下电脑开头键后，这个信号表示电源良好可以开机无信号说明有故障主板自动监测）。 蓝色：代表-12V电源线（向串口提供EIA电源）。 白色：代表-5V电源线（软驱锁相式数据分离电路）。 紫色：代表+5V StandBy电源线（关机后为主板的一小部分电路提供动力，以检测各种开机命令). 绿色：代表PS-ON信号线（主板电源开／关的信号线，未接通时有一定电压）黑色：系统电路的地线。 U V W是三相电源中表示3根火线的字母，3根火线在实际应用中可以都是用黑色线，也可以分分为红，黄，蓝3种颜色。PE表示地线，一般用黄绿双色线。N L 则是零线火线，单相电源中L（火线）一般用红色，N（零线）一般用蓝色 相线：红、黄或红绿 零线：蓝或黑 地线：黄绿相间 1、+5V（红色线）：转换各种逻辑电路。 2、+12V（黄色线）：驱动磁盘驱动器马达和所有风扇（例外：笔记本电脑的风扇使用+5V或+3.3V）。 3、+3.3V（橙色线）：为CPU、主板、PCI（Peripheral Component Interconnect 外部设备互连）总线、I/O控制电路供电。
主板与机箱连接线的接法，实用 主板跳线连接方法揭秘作为一名新手，要真正从头组装好自己的电脑并不容易，也许你知道CPU应该插哪儿，内存应该插哪儿，但遇到一排排复杂跳线的时候，很多新手都不知道如何下手。 钥匙开机其实并不神秘 还记不记得你第一次见到装电脑的时候，技术员将CPU、内存、显卡等插在主板上，然后从兜里掏出自己的钥匙（或者是随便找颗螺丝）在主板边上轻轻一碰，电脑就运转起来了的情景吗？是不是感到很惊讶（笔者第一次见到的时候反正很惊讶）！面对一个全新的主板，JS总是不用看任何说明书，就能在1、2分钟之内将主板上密密麻麻的跳线连接好，是不是觉得他是高手？呵呵，看完今天的文章，你将会觉得这并不值得一提，并且只要你稍微记一下，就能完全记住，达到不看说明书搞定主板所有跳线的秘密
下图所示就是，机箱里的跳线，我们现在就是来，把这些扎乱的线，正确的插到主板上，实现机箱上所有按钮，插孔，指示灯工作。仔细看其实，每一个插帽上，都写有其功能缩写的英文字，如音频连接线：AUDIO，报警器：SPEAKER，硬盘状态指示灯：HDD LED，电源指示灯：+/-等等。 实际上，机箱上的线并不可怕，80%以上的初学者感觉最头疼的是主板上跳线的定义，但实际上真的那么可怕吗？答案是否定的！并且这其中还有很多的规律，就是因为这些规律，我们才能做到举一反三，无论什么品牌的主板都不用看说明书插好复杂的跳线。 ● 哪儿是跳线的第一Pin？
要学会如何跳线，我们必须先了解跳线到底从哪儿开始数，这个其实很简单。在主板（任何板卡设备都一样）上，跳线的两端总是有一端会有较粗的印刷框，而跳线就应该从这里数。找到这个较粗的印刷框之后，就本着从左到右，从上至下的原则数就是了。如上图。 9Pin的开关/复位/电源灯/硬盘灯跳线是目前最流行的一种方式，市场上70%以上的品牌都采用的是这种方式，慢慢的也就成了一种标准，特别是几大代工厂为通路厂商推出的主板，采用这种方式的更是高达90%以上。如下图：
图解：主板电源线接法 图解：主板电源线接法（电源开关、重启开关、USB、耳机麦克风等） 一般，主板电源开关和重启线不分正负，只要接上电源开关线就可以正常开机和关机了；电源和硬盘灯就分正负，不过些线接不接都不影响电脑正常使用。 一般，主板电源线等共有8根，每两根组成一组，电源开关一组，重启一组，电源灯一组（分正负），硬盘灯一组（分正负）。 一般电源线接口如下： 电源LED灯 + －电源开关 。。。。 。。。。。 + －重启未定义接口（这果多一个接口，貌似没用的） 硬盘LED灯 一般只需注意以上电源线的接法就行了，其他基本不用记，只要接口接合适就行了。 其他线如USB线、音频线、耳麦线都是整合成一组一组的，只要接口插得进就对了。
菜鸟进阶必读！主板跳线连接方法揭秘 初级用户最头疼的跳线连接 作为一名新手，要真正从头组装好自己的电脑并不容易，也许你知道CPU应该插哪儿，内存应该插哪儿，但遇到一排排复杂跳线的时候，很多新手都不知道如何下手。 钥匙开机其实并不神秘 还记不记得你第一次见到装电脑的时候，JS将CPU、内存、显卡等插在主板上，然后从兜里掏出自己的钥匙（或者是随便找颗螺丝）在主板边上轻轻一碰，电脑就运转起来了的情景吗？是不是感到很惊讶（笔者第一次见到的时候反正很惊讶）！面对一个全新的主板，JS总是不用看任何说明书，就能在1、2分钟之内将主板上密密麻麻的跳线连接好，是不是觉得他是高手？呵呵，看完今天的文章，你将会觉得这并不值得一提，并且只要你稍微记一下，就能完全记住，达到不看说明书搞定主板所有跳线的秘密。
这个叫做真正的跳线 首先我们来更正一个概念性的问题，实际上主板上那一排排需要连线的插针并不叫做“跳线”，因为它们根本达不”到跳线的功能。真正的跳线是两根/三根插针，上面有一个小小的“跳线冒”那种才应该叫做“跳线”，它能起到硬件改变设置、频率等的作用；而与机箱连线的那些插针根本起不到这个作用，所以真正意义上它们应该叫做面板连接插针，不过由于和“跳线”从外观上区别不大，所以我们也就经常管它们叫做“跳线”。 看完本文，连接这一大把的线都会变得非常轻松 至于到底是谁第一次管面板连接插针叫做“跳线”的人，相信谁也确定不了。不过既然都这么叫了，大家也都习惯了，我们也就不追究这些，所以在本文里，我们姑且管面板连接插针叫做跳线吧。 轻松识别各连接线的定义
DIY攒机的详细步骤过程，在《菜鸟晋级必修功课!图解Ｉｎtel电脑组装全过程》这篇文章中我们已经为大家做了详细的介绍。通过查看网友的留言，小编感觉到很多朋友对各种接口和线缆的连接方法还不是很清楚，那么这里同样以Intｅl平台为例,借助两块不同品牌的主板，对各种接口及其连接方法进行一下详细的介绍。 一、认识主板供电接口图解安装详细过程 在主板上,我们可以看到一个长方形的插槽，这个插槽就是电源为主板提供供电的插槽(如下图)。目前主板供电的接口主要有24针与2０针两种，在中高端的主板上，一般都采用24PＩN的主板供电接口设计,低端的产品一般为20PIN。不论采用24PIN和20PＩＮ，其插法都是一样的。 主板上2４ＰIN的供电接口 ? 主板上２０ＰIN的供电接口 ? 电源上为主板供电的24ＰIN接口
为主板供电的接口采用了防呆式的设计，只有按正确的方法才能够插入。通过仔细观察也会发现在主板供电的接口上的一面有一个凸起的槽,而在电源的供电接口上的一面也采用了卡扣式的设计，这样设计的好处一是为防止用户反插,另一方面也可以使两个接口更加牢固的安装在一起. 二、认识CＰU供电接口图解安装详细过程 为了给ＣPU提供更强更稳定的电压，目前主板上均提供一个给CPU单独供电的接口(有４针、6针和8针三种),如
图:? 主板上提供给CPＵ单独供电的1２Ｖ四针供电接口 电源上提供给CＰU供电的４针、6针与８针的接口
? 安装的方法也相当的简单,接口与给主板供电的插槽相同,同样使用了防呆式的设计,让我们安装起来得心应手。 ? 三、认识ＳATA串口图解ＳATＡ设备的安装 SAＴA串口由于具备更高的传输速度渐渐替代PATA并口成为当前的主流，目前大部分的硬盘都采用了串口设计,由于SＡTA的数据线设计更加合理,给我们的安装提供了更多的方便。接下来认识一下主板上的ＳＡＴA接口。 这张图片跟下面这张图片便是主板上提供的ＳATＡ接口，也许有些朋友会问,两块主板上的
电脑组装各接口以及主机内部各种线的连接方法图解 有时候我们在组装一台电脑回家，总会遇到一些小问题需要我们自已来解决，然而主板上面的众多连接线我们如何来区分它，怎么认识主机箱内的所有硬件设备呢，及连接线呢?主机内各线的连接方法图解 主机外连线 主机外的连线虽然简单，但我们要一一弄清楚哪个接口插什么配件、作用是什么。对于这些接口，最简单的连接方法就是对准针脚，向接口方向平直地插进去并固定好。 电源接口（黑色）：负责给整个主机电源供电，有的电源提供了开关，笔者建议在不使用电脑的时候关闭这个电源开关（图1）。 PS/2接口（蓝绿色）：PS/2接口有二组，分别为下方（靠主板PCB方向）紫色的键盘接口和上方绿色的鼠标接口（图2），两组接口不能插反，否则将找不到相应硬件；在使用中也不能进行热拔插， 否则会损坏相关芯片或电路。
USB接口（黑色）：接口外形呈扁平状，是家用电脑外部接口中唯一支持热拔插的接口，可连接所有采用USB接口的外设，具有防呆设计，反向将不能插入。 LPT接口（朱红色）：该接口为针角最多的接口，共25针。可用来连接打印机，在连接好后应扭紧接口两边的旋转螺丝（其他类似配件设备的固定方法相同）。 COM接口（深蓝色）：平均分布于并行接口下方，该接口有9个针脚，也称之为串口1和串口2。可连接游戏手柄或手写板等配件。 Line Out接口（淡绿色）：靠近COM接口，通过音频线用来连接音箱的Line接口，输出经过电脑处理的各种音频信号(图3)。 Line in接口（淡蓝色）：位于Line Out和Mic中间的那个接口，意为音频输入接口，需和其他音频专业设备相连，家庭用户一般闲置无用。 Mic接口（粉红色）：粉红色是MM喜欢的颜色，而聊天也是MM喜欢的。MIC接口可让二者兼得。MIC接口与麦克风连接，用于聊天或者录音。 显卡接口（蓝色）：蓝色的15针D-Sub接口是一种模拟信号输出接口（图4），用来双向传输视频信号到显示器。该接口用来连接显示器上的15针视频线，需插稳并拧好两端的
解：主板电源线接法（电源开关、重启开关、USB、耳机麦克风等） 一般，主板电源开关和重启线不分正负，只要接上电源开关线就可以正常开机和关机了；电源和硬盘灯就分正负，不过些线接不接都不影响电脑正常使用。 一般，主板电源线等共有8根，每两根组成一组，电源开关一组，重启一组，电源灯一组（分正负），硬盘灯一组（分正负）。 一般电源线接口如下： 电源LED灯 + －电源开关 。。。。 。。。。。 + －重启未定义接口（这果多一个接口，貌似没用的） 硬盘LED灯 一般只需注意以上电源线的接法就行了，其他基本不用记，只要接口接合适就行了。 其他线如USB线、音频线、耳麦线都是整合成一组一组的，只要接口插得进就对了。 菜鸟进阶必读！主板跳线连接方法揭秘 初级用户最头疼的跳线连接 作为一名新手，要真正从头组装好自己的电脑并不容易，也许你知道CPU 应该插哪儿，内存应该插哪儿，但遇到一排排复杂跳线的时候，很多新手都不知道如何下手。
钥匙开机其实并不神秘 还记不记得你第一次见到装电脑的时候，JS将CPU、内存、显卡等插在主板上，然后从兜里掏出自己的钥匙（或者是随便找颗螺丝）在主板边上轻轻一碰，电脑就运转起来了的情景吗？是不是感到很惊讶（笔者第一次见到的时候反正很惊讶）！面对一个全新的主板，JS总是不用看任何说明书，就能在1、2分钟之内将主板上密密麻麻的跳线连接好，是不是觉得他是高手？呵呵，看完今天的文章，你将会觉得这并不值得一提，并且只要你稍微记一下，就能完全记住，达到不看说明书搞定主板所有跳线的秘密。
这个叫做真正的跳线 首先我们来更正一个概念性的问题，实际上主板上那一排排需要连线的插针并不叫做“跳线”，因为它们根本达不”到跳线的功能。真正的跳线是两根/三根插针，上面有一个小小的“跳线冒”那种才应该叫做“跳线”，它能起到硬件改变设置、频率等的作用；而与机箱连线的那些插针根本起不到这个作用，所以真正意义上它们应该叫做面板连接插针，不过由于和“跳线”从外观上区别不大，所以我们也就经常管它们叫做“跳线”。
电脑主板插线方法图解详解 作为一名新手，要真正从头组装好自己的电脑并不容易，也许你知道CPU 应该插哪儿，内存应该插哪儿，但遇到一排排复杂跳线的时候，很多新手都不知道如何下手。 钥匙开机其实并不神秘 还记不记得你第一次见到装电脑的时候，JS将CPU、内存、显卡等插在主板上，然后从兜里掏出自己的钥匙（或者是随便找颗螺丝）在主板边上轻轻一碰，电脑就运转起来了的情景吗？是不是感到很惊讶（笔者第一次见到的时候反正很惊讶）！面对一个全新的主板，JS总是不用看任何说明书，就能在1、2分钟之内将主板上密密麻麻的跳线连接好，是不是觉得他是高手？呵呵，看完今天的文章，你将会觉得这并不值得一提，并且只要你稍微记一下，就能完全记住，达到不看说明书搞定主板所有跳线的秘密。
这个叫做真正的跳线 首先我们来更正一个概念性的问题，实际上主板上那一排排需要连线的插针并不叫做“跳线”，因为它们根本达不”到跳线的功能。真正的跳线是两根/三根插针，上面有一个小小的“跳线冒”那种才应该叫做“跳线”，它能起到硬件改变设置、频率等的作用；而与机箱连线的那些插针根本起不到这个作用，所以真正意义上它们应该叫做面板连接插针，不过由于和“跳线”从外观上区别不大，所以我们也就经常管它们叫做“跳线”。
看完本文，连接这一大把的线都会变得非常轻松 至于到底是谁第一次管面板连接插针叫做“跳线”的人，相信谁也确定不了。不过既然都这么叫了，大家也都习惯了，我们也就不追究这些，所以在本文里，我们姑且管面板连接插针叫做跳线吧。 为了更加方便理解，我们先从机箱里的连接线说起。一般来说，机箱里的连接线上都采用了文字来对每组连接线的定义进行了标注，但是怎么识别这些标注，这是我们要解决的第一个问题。实际上，这些线上的标注都是相关英文的缩写，并不难记。下面我们来一个一个的认识（每张图片下方是相关介绍）！
主板与机箱连接线详细图解(1) 很多朋友喜欢手动组装电脑(DRY)，也许你看到电脑城的JS们装机很快很熟练，觉得他们技术一流，其实手动装机并不复杂，不过，很多人往往被最后一道步骤——主板与机箱的连接线难倒了，本文就详细说说如何正确连接它们。 一般来说，机箱里的连接线上都采用了文字来对每组连接线的定义进行了标注，但是怎么识别这些标注，这是我们要解决的第一个问题。实际上，这些线上的标注都是相关英文的缩写，并不难记。下面我们来一个一个的认识（每张图片下方是相关介绍）！ 电源开关：POWER SW 英文全称：Power Swicth
可能用名：POWER、POWER SWITCH、ON/OFF、POWER SETUP、PWR等功能定义：机箱前面的开机按钮 复位/重启开关：RESET SW 英文全称：Reset Swicth 可能用名：RESET、Reset Swicth、Reset Setup、RST等 功能定义：机箱前面的复位按钮
电源指示灯：+/- 可能用名：POWER LED、PLED、PWR LED、SYS LED等 硬盘状态指示灯：HDD LED 英文全称：Hard disk drive light emitting diode 可能用名：HD LED
报警器：SPEAKER 可能用名：SPK 功能定义：主板工作异常报警器 这个不用说，连接前置USB接口的，一般都是一个整体
音频连接线：AUDIO 可能用名：FP AUDIO 功能定义：机箱前置音频 看完以上简单的图文介绍以后，大家一定已经认识机箱上的这些连线的定义了，其实真的很简单，就是几个非常非常简单英文的缩写。下一页我们在来认识主板上的“跳线”。 实际上，机箱上的线并不可怕，80%以上的初学者感觉最头疼的是主板上跳线的定义，但实际上真的那么可怕吗？答案是否定的！并且这其中还有很多的规律，就是因为这些规律，我们才能做到举一反三，无论什么品牌的主板都不用看说明书插好复杂的跳线。 ● 哪儿是跳线的第一Pin？
关于DIY攒机的详细步骤过程，在《菜鸟晋级必修功课！图解Intel电脑组装全过程》这篇文章中我们已经为大家做了详细的介绍。通过查看网友的留言，小编感觉到很多朋友对各种接口和线缆的连接方法还不是很清楚，那么这里同样以Intel平台为例，借助两块不同品牌的主板，对各种接口及其连接方法进行一下详细的介绍。 一、认识主板供电接口图解安装详细过程 在主板上，我们可以看到一个长方形的插槽，这个插槽就是电源为主板提供供电的插槽（如下图）。目前主板供电的接口主要有24针与20针两种，在中高端的主板上，一般都采用24PIN的主板供电接口设计，低端的产品一般为20PIN。不论采用24PIN和20PIN，其插法都是一样的。 主板上24PIN的供电接口 主板上20PIN的供电接口 电源上为主板供电的24PIN接口
为主板供电的接口采用了防呆式的设计，只有按正确的方法才能够插入。通过仔细观察也会发现在主板供电的接口上的一面有一个凸起的槽，而在电源的供电接口上的一面也采用了卡扣式的设计，这样设计的好处一是为防止用户反插，另一方面也可以使两个接口更加牢固的安装在一起. 二、认识CPU供电接口图解安装详细过程 为了给CPU提供更强更稳定的电压，目前主板上均提供一个给CPU单独供电的接口（有4针、6针和8针三种），如图：
主板上提供给CPU单独供电的12V四针供电接口 电源上提供给CPU供电的4针、6针与8针的接口
安装的方法也相当的简单，接口与给主板供电的插槽相同，同样使用了防呆式的设计，让我们安装起来得心应手。 三、认识SATA串口图解SATA设备的安装 SATA串口由于具备更高的传输速度渐渐替代PA TA并口成为当前的主流，目前大部分的硬盘都采用了串口设计，由于SATA的数据线设计更加合理，给我们的安装提供了更多的方便。接下来认识一下主板上的SATA接口。 这图片跟下面这图片便是主板上提供的SATA接口，也许有些朋友会问，两块主板上的SATA
电脑接线图解 这里以Intel平台为例，借助两块不同品牌的主板，对各种接口及其连接方法进行一下详细的介绍。 一、认识主板供电接口图解安装详细过程 在主板上，我们可以看到一个长方形的插槽，这个插槽就是电源为主板提供供电的插槽（如下图）。目前主板供电的接口主要有24针与20针两种，在中高端的主板上，一般都采用24PIN的主板供电接口设计，低端的产品一般为20PIN。不论采用24PIN和20PIN，其插法都是一样的。图1 主板上24PIN的供电接口.图2 主板上20PIN的供电接口.图3
电源上为主板供电的24PIN接口.图4 为主板供电的接口采用了防呆式的设计，只有按正确的方法才能够插入。通过仔细观察也会发现在主板供电的接口上的一面有一个凸起的槽，而在电源的供电接口上的一面也采用了卡扣式的设计，这样设计的好处一是为防止用户反插，另一方面也可以使两个接口更加牢固的安装在一起。 二、认识CPU供电接口图解安装详细过程 为了给CPU提供更强更稳定的电压，目前主板上均提供一个给CPU单独供电的接口（有4针、6针和8针三种），如下图：5、6
主板上提供给CPU单独供电的12V四针供电接口.图7
电源上提供给CPU供电的4针、6针与8针的接口.图8 安装的方法也相当的简单，接口与给主板供电的插槽相同，同样使用了防呆式的设计，让我们安装起来得心应手。 三、认识SATA串口图解SATA设备的安装 SATA串口由于具备更高的传输速度渐渐替代PATA并口成为当前的主流，目前大部分的硬盘都采用了串口设计，由于SATA的数据线设计更加合理，给我们的安装提供了更多的方便。接下来认识一下主板上的SATA接口。图9、10
一、认识主板供电接口图解安装详细过程 在主板上，我们可以看到一个长方形的插槽，这个插槽就是电源为主板提供供电的插槽（如下图）。目前主板供电的接口主要有24针与 20针两种，在中高端的主板上，一般都采用24PIN的主板供电接口设计，低端的产品一般为20PIN。不论采用24PIN和20PIN，其插法都是一样的。 主板上24PIN的供电接口 主板上20PIN的供电接口
电源上为主板供电的24PIN接口
为主板供电的接口采用了防呆式的设计，只有按正确的方法才能够插入。通过仔细观察也会发现在主板供电的接口上的一面有一个凸起的槽，而在电源的供电接口上的一面也采用了卡扣式的设计，这样设计的好处一是为防止用户反插，另一方面也可以使两个接口更加牢固的安装在一起. 二、认识CPU供电接口图解安装详细过程 为了给CPU提供更强更稳定的电压，目前主板上均提供一个给CP U单独供电的接口（有4针、6针和8针三种），如图：
主板上提供给CPU单独供电的12V四针供电接口
电源上提供给CPU供电的4针、6针与8针的接口 安装的方法也相当的简单，接口与给主板供电的插槽相同，同样使用了防呆式的设计，让我们安装起来得心应手。
三、认识SATA串口图解SATA设备的安装 SATA串口由于具备更高的传输速度渐渐替代PATA并口成为当前的主流，目前大部分的硬盘都采用了串口设计，由于SATA的数据线设计更加合理，给我们的安装提供了更多的方便。接下来认识一下主板上的SATA接口。 这张图片跟下面这张图片便是主板上提供的SATA接口，也许有些朋友会问，两块主板上的SATA口“模样”不太相同。
电脑主板与机箱各插口接法详图解解 很多朋友会装机，那很简单啊，几块板卡接上就OK了，但是只有主板那密密麻麻的连接线可能让他觉得有点犯晕！ 好了，直接下面看： 一、机箱上我们需要完成的控制按钮 开关键、重启键是机箱前面板上不可缺少的按钮，电源工作指示灯、硬盘工作指示灯、前置蜂鸣器需要我们正确的连接。另外，前置的USB接口、音频接口以及一些高端机箱上带有的IEEE1394接口，也需要我们按照正确的方法与主板进行连接。 机箱前面板上的开关与重启按钮和各种扩展接口 首先，我们来介绍一下开关键、重启键、电源工作指示灯、硬盘工作指示灯与前置蜂鸣器的连接方法，请看下图.
机箱前面板上的开关、重启按钮与指示灯的连线方法 上图为主板说明书中自带的前置控制按钮的连接方法，图中我们可以非常清楚的看到不同插针的连接方法。其中PLED即机箱前置电源工作指示灯插针，有“+”“－”两个针脚，对应机箱上的PLED接口；IDE_LED即硬盘工作指示灯，同样有“+”“－”两个针脚，对应机箱上的IDE_LED接口；PWRSW为机箱面板上的开关按钮，同样有两个针脚，由于开关键是通过两针短路实现的，因此没有“+”“－”之分，只要将机箱上对应的PWRSW接入正确的插针即可。RESET是重启按钮，同样没有“+”“－”之分，以短路方式实现。SPEAKER是前置的蜂鸣器，分为“+”“－”相位；普通的扬声器无论如何接都是可以发生的，但这里比较特殊。由于“+”相上提供了+5V的电压值，因此我们必须正确安装，以确保蜂鸣器发声。 这是机箱上提供了插头 上图为机箱是提供的三种接头。其中HDDLED是硬盘指示灯，对应主板上的IDE_LED；POWERSW 是电源开关，对应主板上的PWRSW；RESETSW是重启开关，对应主板上的RESET。除了HDDLED硬盘指示灯有“+”“－”之分外，其它两个没有正负之分，HDDLED硬盘指示灯“+”“－”插反了机箱上的硬盘指示灯不会亮。当然，为了方便消费者安装，“+”采用了红、棕与蓝进行了标识，而“－”绝一为白色线缆，这一点在任何的机箱当中是通用的，大家可以仔细观察一下。另外补充一点：一般还有一个PowerLED插头（上图未出现），是电源指示灯插头，对应主板相应的PowerLED插座，PowerLED指示灯有“+”“－”之分，插反了机箱上的指示灯不会亮。 机箱前置蜂鸣器插头