Abstract A Scalable Key Distribution Hierarchy

A Scalable Key Distribution Hierarchy

Patrick McDaniel Sugih Jamin

Electrical Engineering and Computer Science Department

University of Michigan

Ann Arbor,MI48109-2122

pdmcdan,jamin@https://www.wendangku.net/doc/f717353077.html,

April13,1998

Abstract

As the use of the Internet for electronic commerce,audio and video conferencing,and other applications with sen-sitive content grows,the need for secure services becomes critical.Central to the success of these services is the sup-port for secure public key distribution.Although there are several existing services available for this purpose,they are not very scalable,either because they depend on a cen-tralized server or rely on ad hoc trust relationships.

In this paper,we present and examine a?exible ap-proach to certi?cate distribution scalable to arbitrarily large networks.We propose a two level hierarchy where certi?cates can be independently authenticated by one or more peer authorities,called keyservers.Certi?cates for end-user and host entities are managed within local do-mains,called enterprises.By administering certi?cates close to the source,we reduce the load on the key servers and the effects of network topology changes.We describe the design of our system and present a preliminary per-formance analysis based on traces of present-day DNS re-quests.

1Introduction

Over the past several years,the use of distributed ap-plications has grown immensely.These applications al-low geographically distant users to communicate,leading to social,educational,and commercial interactions that were previously impossible.Unfortunately,because of the openness of the Internet,the form and content of these interactions is vulnerable to attack.Limiting these vulner-abilities is essential to the future success of these applica-tions.

Central to securing communication over an insecure medium is the distribution of cryptographic keys.These keys allow the communication participants the ability to ensure the authenticity,privacy,and integrity of the con-tent.These protections are fundamentally predicated on the security of the key distribution mechanism.Although the existing body of work on this problem is extensive, no single solution has adequately addressed the?exibil-ity and scalability problems inherent to key distribution in networks the size of the Internet.

In this paper we propose a global certi?cation hierar-chy used to distribute public key certi?cates over the In-ternet.The architecture of the system is driven by several design goals.First,the design must be scalable.The tar-get domain(Internet)contains millions of users and ser-vices,which will require the distribution of a like number of certi?cates.Any solution that limits accessibility based on the size of the user base or distance between users will be of limited use.Second,certi?cate retrieval must be timely.Effects on user-perceived performance aside,cer-ti?cate retrieval that incurs long delays may invalidate the content of the information exchange.Finally and most importantly,certi?cate distribution must be secure.

The focus of our investigation reported in this paper is on the scalability of the architecture and protocols of our public key certi?cate distribution hierarchy.The two de?ning features of our architecture are:

1.A set of keyservers form a fully-connected group

of mutually authenticated entities which,in con-cert,serve as our certi?cate authentication authority.

By mandating full-connectivity of authentication be-tween the keyservers,we bound certi?cate authenti-cation time to at most four requests.

2.The window of vulnerability that a revoked certi?-

cate may be used is controlled by user-speci?ed cer-ti?cate hold time.Certi?cate hold time can be set to less than or equal to the Certi?cation Revocation List (CRL)publication period of systems that depend on CRLs to ensure certi?cate integrity.

In evaluating this architecture we attempt to determine the viability of the system as a key distribution mechanism by estimating its performance characteristics.Further,we at-tempt to verify the scalability and timeliness of certi?cate retrieval.While we also identify several important issues related to the security of the proposed architecture itself, a rigorous analysis of the security provided by the archi-tecture is outside the scope of this paper.

In the Privacy Enhance Mail system(PEM)[Ken93], the authors de?ne a certi?cation authority whose require-

ments are similar to that de?ned in this paper.They de-scribe a rooted tree,where the security of all certi?cates are ultimately guaranteed by the root authority.In a global network,?nding one authority which all users trust is problematic.This shortcoming is common to many ex-isting key distribution systems.In this paper,we address this design limitation by de?ning a set of root nodes called keyservers.End users indirectly subscribe only to those keyservers in which they have some level of trust.Veri?-cation of certi?cates may be performed by polling a subset of the subscribed keyservers,from which a majority result is used.

The DNSSEC[EK99]speci?cation outlines a key dis-tribution hierarchy that uses the existing DNS infras-tructure to support authenticated retrieval of DNS data. When retrieving a DNS record an application will traverse the DNS hierarchy,recursively authenticating each zone. This scheme introduces arbitrarily long chains of trust, which reduce the requestor’s con?dence in the retrieved content.We avoid these long chains of authentication by proposing a design that ensures that each keyserver is able to authenticate any other.In this way,we reduce the max-imum length of the authentication chain to four.

A Certi?cation Revocation List(CRL)is a periodically published list of certi?cates that have been revoked.Re-vocation may be stated either explicitly(by unique inden-ti?er)or implicitly(by latest valid certi?cate timestamp or serial number).Systems that use Certi?cation Revoca-tion Lists(CRL)to announce the revocation of certi?cates force users to accept a window of vulnerability in which a revoked certi?cate can be used.This window is equal to the CRL publication period,which is controlled by the ad-ministrators of the authorities.Moreover,an attacker may interfere with the delivery or modify these lists in transit. In our architecture,we address these limitations by allow-ing the user to specify the length of time a certi?cate will be cached,and thus the window of vulnerability.

A possible limitation of this architecture is that key-server resources may become the bottleneck.With mil-lions of end users,there is a potential for the keyserver and associated network resources to become overloaded. We attempt to limit the load on the keyservers by certi?-cate caching and the aggregation of end user requests.We de?ne an enterprise as a collection of end users served by one distinct member called the enterprise root.The enterprise root proxies requests for certi?cates from in-ternal hosts by communicating with keyservers and other enterprise roots,caching the returned certi?cates.As war-ranted,an enterprise can be further divided into smaller groups to decrease the load on the enterprise root.

A certi?cate contains the public key of some entity and a series of other?elds that indicate the identity,contact information,expiration time,and other features of the cer-ti?cate.The X.509[Rec93]speci?cation describes a pop-ular format for public key certi?cates.In this paper,we assume all certi?cates contain a public key generated us-ing the RSA[RSA92,RSA78]cryptographic algorithm. We do not limit the type of entity that can own a certi?-cate.End-users,applications and hosts are examples of potential certi?cate owners.Throughout this paper and without loss of generality,we assume that certi?cates are owned by hosts.Each enterprise host(non-root node in an enterprise),enterprise root,and keyserver creates a certi?-cate.The primary function of the system is the distribu-tion and authentication of these certi?cates.Distribution of certi?cates is performed by the protocol described in Section2.4.A retrieved certi?cate is authenticated by the veri?cation of an attached digital signature.

The length of time a certi?cate is held in a cache,called the certi?cate hold time,is an important parameter of this architecture.If certi?cate locality can be observed,the performance of the system will be effected by this value.

A long hold time will increase the cache hit rate,resulting in less aggregate traf?c.This parameter also bounds the time that a revoked key can be used.A short hold time re-duces the possibility of obtaining a revoked key from the cache.When selecting a value for this parameter,admin-istrators must balance this tradeoff between performance and security.

In determining the viability of the architecture,we need a characterization of traf?c the system will see.From an analysis of expected usage,we can generate heuristics for determining preferred values for the protocol parameters. Primarily,we seek to?nd the best choices for caching policies and certi?cate hold times.Unfortunately,there are limited existing systems of this type from which we can collect data.

We argue that DNS(Domain Name Service)[Moc87a, Moc87b]likely has the usage characteristics that our sys-tem will encounter.Similar to certi?cate requests,DNS requests are most often used as a precursor to a session [DOK92].From an analysis of DNS traf?c we can de-termine when,how often,and to whom connections are made.Assuming that the secure communication sup-ported by our key distribution hierarchy follows the same traf?c pattern as DNS,we propose to estimate the perfor-mance of our system based on DNS traf?c.

The structure of the paper is as follows.We outline the design of our key distribution hierarchy in Section2.In Section3we use traces of DNS traf?c from existing net-works to analyze the performance of the design.Section4 describes some of the existing and proposed designs for certi?cate distribution systems.Section5concludes with a summary of our?ndings.

2Design

In this section we describe the design of our proposed key distribution hierarchy.

2.1Goals

The purpose of this work is to de?ne a key distribution hierarchy that is scalable to the Internet,while avoiding some of the problems found in existing solutions.We see four goals that are central to the design of an Inter-

Figure1:Internet Level Architecture

net certi?cate distribution service:scalability,availability, robustness,and?exibility.

The architecture must be scalable to the Internet.In our design,we attempt to manage certi?cates close to the certi?cate owner,thus reducing the administrative load on the upper levels of the hierarchy.

Certi?cate retrieval must be highly available and robust. We de?ne an authentication channel as the request-reply process of an enterprise root obtaining a certi?cate from a keyserver.In our architecture,we attempt to distribute critical authenticating information through multiple inde-pendent channels.Should con?dence in or connectivity to some node be lost,an enterprise root can use an alternate authentication channel.By making these channels inde-pendent,an enterprise root can validate received certi?https://www.wendangku.net/doc/f717353077.html,ers may also opt to validate certi?cates through several independent channels,resulting in increased con-?dence in their authenticity.This approach is similar to mechanisms for high-availability proposed in[GS91]. The architecture must be?exible.The topology of the Internet is constantly changing,so the architecture and un-derlying protocols must not be dependent on the physical connectivity or location of any singular authority.Mo-bility of users is of equal importance.As users travel from one domain to another,it is necessary for the cer-ti?cate and associated authenticity information to travel with them.By limiting the amount of time and expense of this transition,we provide for the dynamic nature of users in the Internet.2.2The Architecture

In our design,we introduce a two level hierarchy consist-ing of the keyserver level and the enterprise level.The keyserver level contains a set of servers from which en-terprise and keyserver certi?cates can be retrieved.The enterprise level contains independent hierarchies of end users.Figure1describes an Internet-centric view of one possible con?guration of the architecture.In the?gure,a link between two entities represents an exchange of dig-ital signatures,where each end-point signs and perma-nently caches the others’certi?cates.Keyservers form a fully-connected graph of peers,where all keyservers have exchanged certi?cates with all others.By mandating a fully-connected graph,we limit the number of certi?cates needed to be retrieved during authentication of other cer-ti?cates.An authenticated certi?cate of any keyserver can be retrieved from any other keyserver.In limiting the number of retrieved certi?cates,we reduce the points of failure or attack.1Using an out-of-band channel,enter-prises exchange signatures with keyservers in which they trust.It is from these keyservers that they later retrieve authenticating certi?cates.In essence,the exchange of signatures between a keyserver and an enterprise states that the enterprise trusts the keyserver to advertise cor-

rect certi?cates.However,this trust need not be absolute. Later,during authentication,multiple keyservers may be consulted.

Keyservers are intended to be administered indepen-dently by regional,national,or global organizations.In terms of hardware and administrative practices,these servers should have many of the same characteristics of those de?ned for the PCA services of RFC1422[Ken93]. These practices de?ne procedures used for mutual authen-tication before the exchange of signatures.For example, a keyserver may choose not to exchange signatures with some enterprise unless the administrators can provide suf-?cient proof of the security of their own internal signing practices.An enterprise provides its certi?cate to each keyserver with which it wishes to register.After appropri-ate mutual validation of credentials,the keyserver signs and caches the enterprise certi?cate and the enterprise root signs and caches the keyserver certi?cate.A thorough de-scription of the use of digital signatures can be found in [DH76].

Each enterprise encompasses some organization of end users.The enterprise is intended to represent a group of geographically close local area networks under control of a single administrative authority.A distinct host,called the enterprise root,is logically the single point of contact for requests for certi?cates of the enterprise.

We propose two models for communication internal to the enterprise.The?rst(or enterprise root based)model uses the enterprise root node as a single point of contact for certi?cate retrieval.Similar to DNS,enterprise hosts directly contact the local service(enterprise root)to make requests for internal or external certi?cates.Retrieved cer-ti?cates are cached at the enterprise root node and each end user host.In the second(group based)model the en-terprise is a hierarchy of multicast groups which form the enterprise tree.Each group in the tree contains a node called the parent node,which is also a member of the next higher group in the tree.The role of the parent node is to propagate requests and responses to the vertically adja-cent groups in the enterprise tree.These requests are only propagated when the certi?cate is not held in any cache within the local group.In response to a certi?cate request, an enterprise internal protocol is used to search the caches of all hosts within the https://www.wendangku.net/doc/f717353077.html,ing these groups, the enterprise forms a logical enterprise-global cache.In Section3,we analyze the performance tradeoffs between these two approaches.

All certi?cates for entities within the enterprise are per-manently stored at the enterprise root.When a local host registers its public key with the enterprise,they mutu-ally authenticate and sign each other’s certi?cates.When an external entity requests a certi?cate for one of these hosts,the enterprise root will immediately respond with the cached certi?cate.Similar to DNS,if the root is prop-erly placed(i.e.at a network border),very little traf?c should be generated by external requests on the enterprise network.

The purpose of the hierarchy is the secure retrieval of public key certi?cates for arbitrary end points.This is

Figure2:Protocol Example-group oriented enter-prise,where represents a host,represents group in enterprise,represents the root node for enterprise,and represents a key-server.

done by the collection and veri?cation of signed certi?-cates.The requester logically traverses a graph represent-ing signature exchanges between the enterprises and key-servers,collecting certi?cates at each hop.After assem-bling the certi?cates,the signatures are authenticated.If all certi?cates are authenticated,the user is free to use the retrieved end point certi?cate.

This scheme is best illustrated through an example.In Figure2,we show a possible con?guration of the hierar-chy.In this example host is attempting to retrieve a certi?cate for host.Through the protocol described in Section2.4.1,will retrieve three certi?cates;the cer-ti?cate for keyserver signed by enterprise root (),the certi?cate enterprise root signed by keyserver(),and the certi?cate for the host signed by enterprise root().

authenticates the signature in using the public key in locally stored certi?cate,the sig-nature in using the certi?cate, and so on.may choose to validate by contacting additional keyservers.If the enterprises do not share a keyserver(in the sense of signature exchanges), only one additional certi?cate is retrieved,and validated (see Section2.4.1for an example),because our architec-ture mandates that keyservers be fully connected in their trust relationship,as described earlier in this section.

2.3Trust Model

In this design,an end user implicitly trusts the local ad-ministration of the enterprises for both end-points,and to a lesser degree the keyservers.Speci?cally,the end-user trusts both the local and remote enterprise root nodes to advertise correct certi?cates.The keyservers are also

trusted in this way,but alternate channels for validating certi?cates are available.Keyservers are logically the en-tities furthest removed from the end-points,and are likely to be least trusted.This model is simlar to other public key and trusted third party systems.

Kerberos[SNS88,NT94]is a trusted third party key distribution system based on symmetric key https://www.wendangku.net/doc/f717353077.html,ers appeal to Ticket Granting Servers(TGS)for

tickets to services and other users.These tickets are then used to establish a symmetric session key under which se-cure communication can be https://www.wendangku.net/doc/f717353077.html,rger networks (such as the Internet)are divided into Realms.Realms se-curely register secrets with other realms,which are later used establish inter-realm https://www.wendangku.net/doc/f717353077.html,ers communicating between realms are then required to trust both end-points; the source and target realms.

As with the single rooted hierarchy described in the PEM speci?cation[Ken93],the quality of retrieved cer-ti?cates is only as good as the local administration of both end points.In fact,when both enterprises share a key-server,the trust model is very similar.With respect to trust,our proposed system has two distinct advantages over PEM.First,our system does not rely on a single root authority for guarantees of authenticity.Certi?cates from several keyservers may be retrieved,the results being used to increase con?dence in authenticity.This increased con-?dence is predicated on the independent operation of the keyservers and the correctness of their signing practices.

A second advantage is that the selection of authorities is decided by the end-user,not dictated by the architecture. The web-of-trust systems such as PGP offer a more re-laxed trust model.Certi?cates are signed and distributed in an ad hoc manner.A user is required to trust all the intermediate signers.The advantage of the PGP system is that the intermediaries are?uid,allowing anyone to sign. Unfortunately,?nding a certi?cate for an arbitrary end point in which one can trust the signers is dif?cult.The certi?cate location problem is avoided in our architecture through the use of the keyserver and enterprise services. By allowing the requester to determine the intermediate signers,control of the trust relationship is left to certi?-cate users.

2.4The Protocol

In this section we describe the certi?cate retrieval pro-tocol used in the hierarchy.We divide the protocol into two parts,the enterprise external and enterprise internal protocols.The enterprise external protocol describes the process used to retrieve certi?cates that are not local to the enterprise.The enterprise internal protocol describes the communication of request forwarding and caching be-tween the enterprise root and hosts.For simplicity,we describe the aquisition of each end-user,enterprise,and keyserver certi?cate independently.Protocol optimiza-tions,such as request aggregation and negative caching, will reduce the retreival costs.

1 - Req:

H

3

{H

3

}

ER C

H

3

{H

3

}

ER C

9 - Req:

SK

1

{SK

1

}

ERA

Figure3:The certi?cate request process.

2.4.1The Enterprise External Protocol

The enterprise external protocol describes the retrieval of certi?cates of hosts local to the enterprise by exter-nal hosts and the retrieval of external certi?cates by lo-cal hosts.Each enterprise root node begins operation by warming its cache with permanent entries for the certi?-cates of entities within the enterprise,the enterprise cer-ti?cate,and the certi?cates of each keyserver with which it has exchanged signatures.

When the root node receives an external request for a certi?cate belonging to an entity within the enterprise,it returns the certi?cate and appends the list of keyservers with which it has exchanged signatures.The list of key-servers associated with the enterprise is always cached with the certi?cate.

As dictated by the communication model used in the enterprise,requests for certi?cates that do not currently reside in a host cache are ultimately forwarded to the en-terprise root node.If the certi?cate is found in the enter-prise root cache,the certi?cate and associated keyserver information is returned.Otherwise,the request is for-warded to the external enterprise.The response is cached and returned to the requesting host via the enterprise in-ternal protocol.A similar process is used for keyserver certi?cates,with the originating requester specifying from which keyserver it wishes to retrieve the certi?cate.

It is worth noting that we do not specify a mechanism for locating the enterprise root node of an external enter-prise.There are several existing designs for scalable net-work directory services,such as DNS[Moc87a,Moc87b]. These services are readily available within today’s Inter-net infrastructure,and as such are beyond the scope of this paper.

We illustrate this protocol through an example.We re-turn to our example hierarchy description in Figure2.As-sume all hosts initially have empty caches,save the per-manent entries.We state that both the enterprise root

nodes and have only exchanged signatures with keyserver and that enterprise root node

has exchanged signatures with keyserver.In Fig-ure3,we illustrate the request process used by enterprise host in enterprise to obtain and authenticate the cer-ti?cate of host in enterprise.begins by request-ing the certi?cate of.Via the internal protocol,the re-quest ultimately arrives at the enterprise root node (step1in Figure3).forwards the request to, returning the results to(steps2,3and4).then determines that the certi?cate of is needed,and re-peats the request process,specifying that the certi?cate be retrieved from the keyserver(steps5-8).Based on the keyserver information returned in the request, notes that both enterprises shared the keyserver.deter-mines that this is an acceptable trust relationship because they share a common keyserver,which it trusts.Finally, requests and receives the certi?cate for keyserver (steps9and10in Figure3).Having assembled all the certi?cates,recursively authenticates the digital sig-natures.Based on the results of the authentication, may initiate some secure action using the certi?cate. When the enterprise of a requester host and the enter-prise of the requested certi?cate do not share a common keyserver(in terms of signature exchange)an additional step is necessary.An example of this scenario(from Fig-ure2)would be requesting the certi?cate of.The certi?cate retrieval would proceed as in the previous ex-ample,with the addition of the retrieval of the certi?cate for keyserver.During authentication of the certi?-cates,would authenticate’s certi?cate using the certi?cate of.Recall that we require each keyserver to exchange signatures with all the other keyservers,so any trusted keyserver()may be used to retrieve and authenticated the certi?cate of another keyserver() with a single additional request.

An advantage of this architecture is that any host can re-trieve an arbitrary certi?cate with a maximum of four re-quests.This is an advantage over previous systems where the retrieval of potentially many certi?cates may be re-quired.Additionally,the effects of network partitioning can be reduced.When some keyserver is unavailable,oth-ers can be consulted.However,a certi?cate cannot be re-trieved from an unavailable enterprise.This may not be detrimental to the usefulness of our proposed architecture, as the target enterprise host is likely to also be unavailable. When more than one certi?cate for a single target is re-ceived with valid signatures,the enterprise and end user nodes must make a policy decision.The most secure pol-icy would be to disallow the use of any of the certi?-cates until the con?ict can be resolved.An alternative approach is to bias towards those keyservers with whom the local enterprise has exchanged keys.The administra-tion of these keyservers is known to the local enterprise, and thus should have more trust associated with them.An-other policy is to allow the end-user or application to make the decision on a case by case basis.The requesting entity knows the importance of the operation about to take place, so is in a better position to make a decision about the risk involved in using a questionable certi?cate.Our architec-ture does not dictate the policy,as any single policy will not be appropriate to all environments.

2.4.2The Enterprise Internal Protocol

Recall that we have two models for communication inter-nal to the enterprise.In this section,we describe the oper-ation of both the enterprise root and group based models. In the enterprise root based communication model en-terprise hosts communicate with the enterprise root via unicast.Enterprise hosts make requests for certi?cates di-rectly to the enterprise root.The protocol for retrieving certi?cates from external entities proceeds as described above,the results of which are cached and returned to the requesting host.We study several cache replacement poli-cies for this model in Section3.5.

In the group based communication model,each group in the enterprise tree represents a multicast group to which all members’requests are sent.A group has a distinct node,called the parent node,which operates as the link to the higher groups in the tree.The enterprise root acts as the parent node of the highest group in the tree.The request process begins by a member host multicasting the request to the local group.Each member of the group looks in their local cache for the requested certi?cate.If the certi?cate is found,the member starts a timer initial-ized to a random value between and some?xed time. If the timer expires and no response has been seen in the group,the member multicasts its response to the group. When the request is received by a parent node,it sets its timer to.If the parent node timer expires before

a response is seen in the group,it multicasts the request to the next higher group in the tree.This random wait response scheme at each level is similar to those used in the SRM[Flo95]reliable multicast protocol.This pro-cess is repeated until a response is received or the request timer expires at the root node in the tree.In the latter case,the enterprise root retrieves the certi?cate via the enterprise external protocol and returns the response cer-ti?cate.The response is then recursively multicast to the enterprise groups,where it is eventually received by the requester.

2.4.3Key Revocation

Key revocation is a primary concern of any key distribu-tion system.If the private key associated with a certi?cate becomes exposed,the owner will wish to immediately in-validate all cached copies.Due to the large number of hosts,?nding all the cached copies in large networks can be problematic.In extant systems,Certi?cate Revocation Lists(CRLs)are used for this purpose.Unfortunately, CRLs create a different set of problems.The mechanics of disbursing this potentially large set of revoked certi?-cates to an enumerable set of interested parties presents a daunting task.

Similar to DNSsec[Eas98],we avoid many of the prob-lems associated with key revocation by requiring short

hold times on cache entries.When a certi?cate is re-voked,the enterprise or keyservers that advertise the cer-ti?cate immediately?ush the certi?cate from its perma-nent cache.In this way,the time a compromised certi?-cate can be used is bounded by the cache hold time.An enterprise can ensure that no revoked certi?cates are used by setting the cache hold time in the enterprise hosts to zero.

A byproduct of our key revocation mechanism is user https://www.wendangku.net/doc/f717353077.html,ers who wish to move from one enterprise to another can do so without revoking thier key.When mov-ing between enterprises,the only requirement is that the certi?cate is registered(digitally signed and advertised) by the new enterprise.An enterprise never has access to the user’s private key,so their are no security risks associ-ated with using the old key.

Implicit to this approach is the need for freshness assur-ances in the certi?cate retrieval process.In the absence of such assurances,an attacker may obtain certi?cates before revocation and later impersonate one or more keyservers. In this way,the attacker could induce a user into using a revoked key.We stipulate that all requests are retrieved using a protocol that ensures freshness,but cite no spe-ci?c method.There are several approaches for achieving freshness described in[NS78]and[Sch96].

Our approach to certi?cate revocation that relies on cer-ti?cate hold time offers several advantages over the use of CRLs.First,the control over the window of vulnerability is left to the user.With CRLs,the user is forced to use the last published CRL,which is broadcast at a rate controlled by the certi?cation authority.Moreover,an attacker may delete or intercept the CRL publication.Secondly,revo-cation in our system is a simple,one step process.Revo-cation is not predicated on the support of external entities. Note that we assume an out-of-band method for the re-vocation itself.Social processes are needed for this pur-pose.One possible solution would be to assign secret re-vocation codes during the signature exchange that would be used as credentials during revocation.

3Performance Evaluation

In this section we evaluate the performance of our archi-tecture by using traces of Domain Name Service(DNS) traf?c as a model of expected usage.We investigate the performance characteristics of the three central compo-nents of our architecture:the(end-user)enterprise hosts, the enterprise root node,and the keyserver.We attempt to quantify the following factors:

1.First and foremost,the locality of DNS requests.The

scalability of our proposed architecture hinges cru-cially on the locality of certi?cate requests.

2.The effect of cache replacement policies on enter-

prise root node’s certi?cate cache hit rate.

3.The cost bene?t trade offs of the two enterprise

internal communication models described in Sec-tion2.4.2.

4.The effect of speci?c enterprise characteristics,

mainly,the number of hosts within an enterprise,on the validity of our results.

5.The load on keyservers as measured by the num-

ber of requests received;and the effect of enterprise-level certi?cate caching on keyserver load.

The main results of our evaluation of the proposed key distribution hierarchy based on DNS traces can be sum-marized as follow:

The traces we collected on DNS requests show a high degree of locality.

Enterprise hosts tend to be idle,in terms of initiating DNS requests,for long periods of time.During these idle periods host caches remain empty,such that enter-prise host caching has minimal effect on the overall per-formance of the architecture.

The group based communication model provides us a practically in?nite cache size.Hence enterprise-level hit rate is best under the group based communication model. Under the enterprise root communication model,we?nd the LFU(Least Frequently Used)cache replacement pol-icy to provide marginally better performance than the LRU(Least Recently Used)cache replacement polices. The performance of the LFU cache replacement pol-icy under the enterprise-root communication model ap-proaches that of the group based communication model. In all cases,the enterprise root is not overwhelmed by the requests seen in our DNS traces,even during the period of highest load.

The observation that enterprise host caches are often empty explains why caching at the enterprise root alone provides cache hit rate comparable to that of the group based model.This,coupled with the observation that enterprise-root sees an acceptable load,leads us to con-clude that the management overhead of and the additional retrieval latency introduced by the group-based model are not warranted by the marginal performance gain achieved. Using traces from enterprises of varying sizes,we de-termine that these?ndings appear to be independent of enterprise size;we assert that our Enterprise External and Internal Protocols are scalable to existing domain sizes. DNS traces from a top-level domain(us)shows that in the worst case the top-level DNS server processes a lit-tle over100,000requests per hour.Arguing that traf?c seen by a top-level DNS server models the traf?c our key-servers will see,we stipulate that the load placed on key-server hosts will be low.Our simulation results also show that enterprise-level certi?cate caching can further reduce keyserver load by as much as65%.

Based on these results,we claim that our key distribu-tion hierarchy is scalable to networks the size of the Inter-net.

In the remainder of this section we?rst present the col-lection and characteristics of our traces.After describing our cache simulation setup,we present data supporting our performance claims on the proposed key distribution hierarchy summarized above.

Table 1:Collected DNS traces

Trace Date Date Local Total AT&T

1/7/98

1/8/98

27,744

57,059

1,104

11:57pm

11:47pm

272,656

CAEN

1/8/98

1/9/98

175,177

461,55231,113

11:55pm

9:59pm

543,273

us

1/7/981/9/98

N/A

2,365,122

5001000150020002500300035004000450000:00

03:0006:0009:0012:0015:0018:0021:00

R e q u e s t s (p e r m i n u t e )

Time

Enterprise Local Requests Enterprise Remote Requests

Total Requests Mean Total Requests

Figure 4:Requests per minute for https://www.wendangku.net/doc/f717353077.html, trace

3.1Trace Collection

The architecture of DNS as implemented on the current Internet parallels our proposed key distribution hierarchy in that DNS recognizes a set of top-level root servers that resolve top-level domain names (https://www.wendangku.net/doc/f717353077.html,,com,gov,mil,org ,etc.)and domain-level name servers that resolve do-main speci?c names.We collected DNS request traces from both top-level and domain-level name servers.We use traces from top-level name servers to model expected traf?c our keyservers will see.We use domain-level traces to model expected enterprise root traf?c.To study the ef-fect of domain size on the expected performance charac-teristics of our enterprise root nodes,we collected DNS traces from large,medium,and small DNS domains.DNS request traces were collected using the logging and debug options built-in to the named name server.A summary of the collected traces is given in Table 1.2

We choose the University of Michigan (https://www.wendangku.net/doc/f717353077.html, )as a representative large-size DNS domain.The Univer-sity is served by four primary name servers.We col-lected traces from the name server that is set up to be the main name server for the University by the network administrators.We consider the College of Engineering of the University a representative medium-size DNS do-main.The https://www.wendangku.net/doc/f717353077.html, domain is a subdomain of the https://www.wendangku.net/doc/f717353077.html, domain,but operates its own two DNS servers

0.10.20.30.40.50.60.70.80.911

10

1001000

10000

100000

C D F

Number of Distinct Addresses Requested

Local Remote

Figure 5:Cumulative distribution function for IP ad-dresses requests

Internet sur?ng.

Due to errors in some DNS implementations,the DNS resolver may send several requests for the same address to the server rapidly [DOK92].We consider a request for a single address within a single second from the same source as a suspect request.We cannot state that a suspect request is invalid,as a host that does not cache DNS data will correctly generate them.Of the requests in the data collected from the https://www.wendangku.net/doc/f717353077.html, domain,17%were suspect.In the event that some or all of these requests are erro-neous,our results are still valid.The existence of these spurious requests would sightly increase the locality of requests,resulting in higher cache hit rates.We make no de?nitive statements about absolute cache hit rates.Some applications append an additional local domain name onto a request which contains a fully resolvable name.These requests will never be resolved,and were thus removed.We found in and removed from our traces 5%of these unresolvable requests.

In our simulation,we interpret each DNS request as a corresponding certi?cate https://www.wendangku.net/doc/f717353077.html,ing the name server con?guration information,we map all hostnames for which the server acts as an authority into a simulated

enterprise.As de?ned by the cache replacement policy,caches are maintained for each simulated host.In the sim-ulation,information about the cache hit rate and size are recorded over the simulated time.

In the remainder of this section,unless otherwise noted,all reported results are from the https://www.wendangku.net/doc/f717353077.html, traces.

3.3Request Locality The performance of our system is chie?y dependent on the locality of certi?cate requests.In a system where no lo-cality can be observed,a caching mechanism is of no use.In Figure 5,we show the distributions of enterprise local and external requests for the https://www.wendangku.net/doc/f717353077.html, domain trace.The ?gure shows a high degree of locality for enterprise lo-cal requests.More than 76%of the requests where made

for the same 100addresses,while over 93%where for the same 1000.We can attribute this locality to several factors.All hosts within the domain access services pro-vided by domain speci?c servers.Moreover,users tend to have a set of hosts on which they perform their daily tasks.Over time,end users access the same machines (e.g.?le-server),while never utilizing resources on the vast major-ity of available machines.

Enterprise external traf?c shows a lower,but still sig-ni?cant,degree of locality.Figure 5shows that over the measured period,over 40%of the requests where for the same 100addresses.Similar to the enterprise local data,the vast majority of addresses are only requested a few times.Given this observed locality,we conclude that caching external certi?cates will provide performance im-provements.

3.4Enterprise Host Performance

In our simulation of enterprise hosts.We ?nd that certi?-cate caching at these hosts has little effect on the overall performance of the system.As depicted in Figure 6,the average cache occupancy per minute of the average host remains small during the entire simulation period.We note that host caches are empty the majority of time.Dur-ing short periods of activity,the caches grow larger,but never exceeding 1entry on the average,and empty when the entries time out.For longer timeouts,we see overlap-ping periods of activity for some machines,but the ma-jority of machines remain idle with respect to certi?cate requests.

We next investigate the maximum resource usage at the enterprise hosts.We again ?nd that even at the highest ob-served loads resource requirements at the hosts are within an acceptable range.In Figure 7,we show the maxi-mum cache occupancy over all hosts within the enterprise for the duration of our trace.Under extreme load condi-tions,we see that the maximum cache size remains un-der 1000entries,which for most systems is acceptable

load.3Therefore,signi?cant effort to optimize enterprise host caches will result in very little performance gain.3.5Enterprise Root Performance To determine the expected load on the enterprise root,we

analyze traces from the https://www.wendangku.net/doc/f717353077.html, domain.We also sim-ulate small,medium,and large enterprises to determine

that our results are independent of enterprise size.We ?nd the load on the enterprise root to be acceptable.Re-viewing the traces for the domain,we ?nd that the DNS

server processed an average of 78,420requests/hour,with

a high of 151,115and a low of 33,395requests per hour.

The domain contains over 30,000hosts.These request arrival rates can easily be processed by a dedicated high-end workstation.Should an enterprise root become over-whelmed by requests,the server may be replicated over a cluster of workstations.

0.1

0.2

0.3

0.4

0.5

0.60.7

03:0006:0009:0012:0015:0018:0021:00A v e r a g e H o s t C a c h e O c c u p a n c y (p e r m i n u t e )

Time

Cache Hold Time

1 second 1 minute 10 minutes

1 hour

Figure 6:Average Enterprise Host Cache Occupancy (per minute)

2004006008001000120014001600180003:0006:0009:0012:0015:0018:0021:00

A v e r a g e H o s t C a c h e O c c u p a n c y (p e r m i n u t e )

Time

Cache Hold Time

1 second 1 minute 10 minutes

1 hour

Figure 7:Maximum Enterprise Host Cache Occu-pancy (per minute)

In implementing the enterprise root cache,we selected the LRU (least recently used)and LFU (least frequently used)cache replacement policies to study.We use the standard de?nition for the LRU policy,but use a modi?ed version of LFU.In our de?nition of LFU,we keep a per-manent hit count for every certi?cate seen,whether it is present in the cache or not.The cache uses this counter in its entry replacement computation.This way,a certi?-cate’s access frequency is not reset when its hold time ex-pires.We simulate the system using the DNS trace with a cache size of 1000certi?cates.The results of this sim-ulation show that certi?cate hold times of less than 10minutes never cause the cache to become full.Hence for certi?cate hold times less than 10minutes,all the alterna-tive caching policies perform the same.In Figure 8,we show the performance of the different caching policies for certi?cate hold times between 10minutes and 1hour.In Figure 8we include the performance of the group-based communication model.The group based model represents the best case scenario,where the sharing of caches among the enterprise hosts represents a cache of practically in-?nite size.A cache replacement policy that achieves hit rates at or near those of the group based communication model represents a viable alternative.In this case,we ?nd the LFU cache replacement policy to perform marginally better than the LRU policy and to approach the perfor-mance of the group-based model.Note that the perfor-mance reported in Figure 8is the hit rate of external cer-ti?cate requests.Our key distribution architecture dictates that certi?cates of local hosts and trusted keyservers be permanently held in the enterprise root cache,and as such will always be readily available.

Given the marginal performance gain of the group based communication model over the enterprise-root cache with LFU replacement policy,the observation in the previous section that host caches are often empty,and the moderate number of requests per hour the root node can expect to see,we do not believe that the extra over-head of certi?cate sharing via the group communication model,with the attendant additional retrieval latency,is warranted.

We repeated the above simulations using all the traces available to us and found the performance to be compa-rable.Figure 9shows the expected enterprise root cache hit rate as a function of cache hold time from 1second to 1hour.From this data,we state that the scalability of our proposed key distribution architecture is independent of enterprise size.We make no claim about the exact ex-pected quantitative performance of our architecture,only that we expect to see a high degree of locality in certi?cate requests and acceptable request arrival rates.

3.6Keyserver Performance

The dominant role keyservers play in our proposed archi-tecture could potentially make them the bottleneck that limit the scalability of the architecture.We use traces from an authoritative server for the us domain to estimate the load on a typical keyserver.In this trace,we see ar-rival rates of between 19,787and 111,038requests/hour,with an average of 52,558requests.Given the state of high end workstations,a dedicated host will be able to serve loads considerably larger than those indicated by this trace.Should keyservers become overwhelmed by re-quests,it could be replicated over a cluster of workstations to alleviate the problem.

In a series of tests,we seek to determine the effects of enterprise caching on keyserver performance.Our simu-lations shows that certi?cate hold time at each enterprise has a signi?cant effect on request arrivals at the keyserver.Certi?cate hold times over 5minutes at each enterprise re-duce the load on the keyserver by as much as 60%.Using the us domain trace,we simulate a keyserver and the as-sociated requesting enterprises.Because the CIDR blocks [FLYV93]of the requesters in our trace were unavailable,we execute two simulations.In the ?rst simulation,we treat all addresses as Class-C addresses,using the ?rst 24bits of their address.If two addresses have the same ?rst 24bits,they are deemed to be in the same enterprise.In the second simulation,we repeat the simulation using only the ?rst 16bits:a Class-B addresses.Because real networks encompass more than one Class C,but less than

717273747576777879808182600

1200

1800

2400

3000

3600

E n t e r p r i s e R o o t C a c h e T i m e R a t e (%)

Cache Hold Time (in seconds)

SRM LFU LRU

Figure 8:Enterprise Root Caching Policy Perfor-mance

E n t e r p r i s e R o o t C a c h e T i m e R a t e (%)

Cache Hold Time (in seconds)

Figure 9:Enterprise Cache Hit Rate -hit rate for re-quests for certi?cates external to each simulated en-terprise.The tests were performed under the enter-prise root communication model using a 100certi?-cate LFU cache.

one Class B,addresses,the ?rst simulation reports worse

performance than reality and the second better.The re-sults from these two simulation,shown in Figure 10,are very similar,and give us a tight bound on expected real

performance.The ?gure shows keyserver residual load de?ned as a percentage of total requests in the original

trace that are not served by enterprise root cache.For very short cache hold times (1second),20%of the re-quests will be serviced by a cache internal to the enter-prise.These dramatic improvements continue until cache hold times reach about 5minutes,where only 40%of the

original requests are forwarded to the keyserver.Certi?-cate hold times longer than 5minutes do little to improve this performance,consistent with the enterprise root cache

performance as a function of certi?cate hold times pre-sented in Figure 9.4Related Work

There has been signi?cant investigation of key distri-bution both in the standards bodies and in industry.We classify the resultant key distribution systems into three classes:trusted third party,hierarchical,and ad-hoc .

Trusted third party systems such as Kerberos [NT94,SNS88]rely on secrets shared with local trusted athori-ties.In larger networks,the authorities collaborate or form hierarchies to allow intra-domain secure communication.The Kerberos system is a symmetric (private key)system used to provide authentication in a network environment.Before accessing network services,a user provides a pass-word known only to the user and the Kerberos system.After being authenticated,the user retreives tickets which are presented to services.These tickets are used to boot-strap secure communication between the service and the user.The Kerberos services act as a third party in which

10

2030

40

50

60

701101001000

K e y s e r v e r L o a d (%)

Enterprise Cache Hold Time (in seconds)Class B Enterprises Class C Enterprises Figure 10:Keyserver load -simulated with enterprises modeled from class B and class C addresses in the DNS

trace.

both end-points (entities)trust.

In strict hierarchies,such as the Privacy Enhanced Mail [Ken93],X.500Directory [],Public Key Infrastructure [Cho94],and DNSsec [Eas98]services form a rooted hi-erarchy under which all secruity is ultimately gaurenteed by the root authority.The Privacy Enhanced Mail (PEM)Certi?cate Hierarchy de?nes a design for certi?cate (pub-lic key)distribution to be used by all entities on the In-ternet.As described in RFC 1422,the authors propose a hierarchy which contains a tree of certi?cation author-ities rooted at the Internet Policy Registration Authority (IPRA).Each node (Certi?cation Authority)in the tree is classi?ed by policies implemented by the administrators.Intended to increase end user con?dence in the authori-ties,each classi?cation has a set of social and physical re-quirements.These requirements de?ne the administrative practices and hardware environment in which the author-ity operates.The signers for the certi?cates are de?ned by their position in the tree,whose path within the tree is

required to be unique.

Extentions to the existing DNS service that provide se-cure distribution of public key certi?cates are speci?ed in [Eas98].The service,called DNSsec,introduces new re-source records containing public key certi?cates.In re-trieving certi?cates,DNSsec uses the same distribution hierarchy and communication channel as DNS.Revoca-tion of certi?cates is similar to those found in KDH.Each certi?cate is distributed with a TTL that speci?es how long the certi?cate should be cached.Note that the TTL is controlled by the certi?cate provider,and not the re-questor,as in KDH.Revocation is handled by the re-moval of the revoked certi?cate from the authoritative DNS server.

Ad-hoc distribution services do not specify an architec-ture or service model for https://www.wendangku.net/doc/f717353077.html,ers are free to exchange certi?cates in any way they wish.The public key certi?cate based Pretty Good Privacy[Zim94](PGP) system de?nes a key signing scheme based on“webs of trust”.In PGP,public key certi?cates are distributed inse-curely.Certi?cates are digitally signed serially resulting in an ordered list of signatures attached to the original cer-ti?cate.By convention,a user will only sign a certi?cate if they trust the source from which it was received.There-fore,when a certi?cate is received from a trusted source (such as a network administrator),their signature should provide assurance that the certi?cate is valid.

The X.509[Rec93]speci?cation describes both the for-mat of public key certi?cates and Certi?cate Revocation Lists(CRL).The certi?cate revocation scheme used in X.509describes the periodic publication of CRLs.When a user wishes to verify the authenticity of the certi?cate, she checks a recently published list for the identities of the certi?cate.If it is not on the list,the certi?cates are assumed to be valid.

The IETF Internet Public-Key Infrastructure working group(PKIX)outlines version3of the X.509speci?ca-tion in[HFPS98].The speci?cation adds several new ?elds in the certi?cates,as well as propose a new mecha-nism for limiting the length of the certi?cation path of hi-erarchical systems.Directed by strictly de?ned policies, certi?cates may be retrieved from peer authorities without consulting the hierarchy.Unfortuneatly this requires the peer authories establish a level of trust prior to certi?cate retreival.

5Conclusions

In this paper we have de?ned a certi?cate distribution hi-erarchy that attempts to avoid the limitations found in ex-isting designs.We propose a solution where users are free to select some set of authorities that they trust.By polling a subset of selected authorities,the end user may increase their con?dence that received certi?cates are au-thentic.We also avoid the problems inherent to loosely connected or“web of trust”systems by stipulating that a received certi?cate has only been signed by authorities trusted by the end user.

The design of our system attempts to de-centralize the signing of certi?cates from a singular authority.In do-ing this,we enable the scalability and?exibility needed for large networks.By managing the certi?cates close to the source and by aggregating requests within the lo-cal environment,we attempt to limit the burden placed on network resources.Finally,users need only trust the prac-tices of the administrators of their local environment.

In the security community,key revocation is widely ac-cepted as a dif?cult problem.Existing design use revoca-tion lists that are distributed to all interested parties.This solution does not scale to millions of users,and is sub-ject to many denial of service attacks.We address this problem by limiting the hold time of certi?cates.We fol-low the example used in the DNS protocol,by advertis-ing only correct keying material.End users bound the time in which they are vulnerable to compromised cer-ti?cates by setting the hold time for received certi?cates. Our architecture can accommodate much shorter bounds on the window of vulnerability than systems described in the X.509speci?cation[Rec93],which use certi?cate re-vocation lists to advertise explicitly that keys have been revoked.

We evaluate the scalability and performance of our pro-posed key distribution hierarchy by using traces of Do-main Name Service traf?c.We argue that characteris-tics of DNS traf?c mirror those of future certi?cate hi-erarchies.Our analysis?nd that the proposed architecture perform well under the DNS traf?c patterns.The locality of requests found in the DNS traces show that our caching mechanisms will be effective for various domain sizes. Acknowledgements

We wish to thank the following people for assistance in collecting DNS traces.Paul Kiley and Andrew In-man helped in the collection of DNS traces from the https://www.wendangku.net/doc/f717353077.html, and https://www.wendangku.net/doc/f717353077.html, domains,respectively. Ram′o n C′a ceres assisted in the collection of DNS traces from the AT&T domain.We also wish to thank Deborah Estrin and Peter Danzig for allowing us to collect DNS traces from the us domain.

References

[BAN90]M.Burrows,M.Abadi,and R.M.Needham.A Logic of Authentication.ACM Transactions on

Computer Systems,8,February1990.

[Cho94]S.Chokhani.Towards a National Public Key Infrastructure.IEEE Communications Maga-

zine,pages70–74,September1994.

[DH76]W.Dif?e and M.E.Hellman.New Directions in Cryptography.IEEE Transactions on Infor-

mation Theory,IT-22(6):644–654,November

1976.

[DOK92]Peter B.Danzig,Katia Obraczka,and Anant Kumar.An Analysis of Wide-Area Name

Server Traf?c.In SIGCOMM92’,1992. [Eas98] D.Eastlake.Internet,Draft,Domain Name System Security Extensions.DNS Security

Working Group,March1998.

[EK99] D.Eastlake and C.Kaufman.RFC2065,Do-main Name System Security Extensions.RFC

2065,Internet Network Working Group,Jan-

uary1999.

[Flo95]S.Floyd.A Reliable Multicast Framework for Light-Weight Sessions and Application Level

Framing.In Proceedings of SIGCOMM’95,

pages342–356,August1995.

[FLYV93]V.Fuller,T.Li,J.I.Yu,and K.Varadhan.

Classless Inter-Domain Routing(CIDR):An

Address Assignment and Aggregation Strategy.

RFC1519,Internet Network Working Group,

September1993.

[GS91]Jim Grey and Daniel P.Siewiorek.High-Availability Computer Systems.IEEE Com-

puter,24(9):39–48,September1991. [HFPS98]R.Housley,W.Ford,W.Polk,and D.Solo.In-ternet,Draft,Internet Public Key Infrastructure.

PKIX Working Group,March1998.

[Ken93]S.Kent.RFC1422,Privacy Enhancement for Internet Electronic Mail:Part II:Certi?cate-

Based Key Management.RFC1422,Internet

Network Working Group,February1993. [KPS95]Charlie Kaufman,Radia Perlman,and Mike https://www.wendangku.net/doc/f717353077.html,work Security,Private Commu-

nication in a Public World.Prentice Hall,En-

glewood Cliffs,New Jersey,1995.

[Moc87a]P.Mockapetris.Domain Names-Concepts and Facilities.RFC1034,Internet Network

Working Group,November1987.

[Moc87b]P.Mockapetris.Domain Names-Implemen-tation and Speci?cation.RFC1035,Internet

Network Working Group,November1987. [NS78]R.M.Needham and https://www.wendangku.net/doc/f717353077.html,ing En-cryption for Authentication in Large Networks

of https://www.wendangku.net/doc/f717353077.html,munications of the ACM,

21(12):993–999,December1978.

[NT94] B.C.Neuman and T.Ts’o.Kerberos:An authentication service for computer networks.

IEEE Communications,pages33–38,Septem-

ber1994.

[PF95]V.Paxson and S.Floyd.Wide-Area Traf?c: The Failure of Poisson Modeling.IEEE/ACM

Transactions on Networking,3(3):226–244,

June1995.[Rec93]Recommendation X.509.The Directory:Au-thentication https://www.wendangku.net/doc/f717353077.html,rmation technol-

ogy-Open Systems Interconnection,November

1993.

[RSA78]R.L.Rivest,A.Shamir,and L.M.Adleman.A Method for Obtaining Digital Signatures and

Public Key https://www.wendangku.net/doc/f717353077.html,munications of

the ACM,21(2):120–126,February1978. [RSA92]RSA Laboratories.RSAREF(TM):A Cryp-tographic Toolkit for Privacy-Enhanced Mail.

RSA Laboratories,Redwood City,CA,1992. [Sch96]Bruce Schneier.Applied Cryptography.John Wiley&Sons,Inc.,New York,Chichester,

Brisbane,Toronto,Singapore,second edition,

1996.

[SNS88]J.G.Steiner,B.C.Neuman,and J.J.Schiller.

Kerberos:An authentication service for open

network systems.In Proceedings of the Usenix

Conference,pages191–202,1988.

[Zim94]P.Zimmermann.PGP user’s guide.Distributed by the Massachusetts Institute of Technology,

May1994.

干扰处理方法

技术支持 干扰的来源及影响方式 闭路电视监控系统中传输信号的类型主要有两类：一类是模拟视频信号，传输路径由摄象机到矩阵，从矩阵再到显示器或录象机；一类是数字信号包括矩阵与摄象机之间的控制信息传输，矩阵中计算机部分的数字信号。一般设备成为干扰源的可能性很小，因此干扰主要通过信号传输路径进入系统。闭路电视监控系统的信号传输路径是能通过视频电缆和传输控制信号的双绞线耦合进系统的干扰有：各种高频噪声比如大电感负载启停，地电位不等引入的工频干扰，平衡传输线路失衡使抑噪能力下降将共频干扰转成了差模干扰，传输线上阻抗不匹配造成信号的反射使信号传输质量下降，静电放电沿传输线进入设备造成接口芯片损伤或损坏。具体表现如下：由于阻抗不匹配造成的影响在视频图象上表现为重影。在信号传输线上会将在脉冲序列的前后沿形成震荡。震荡的存在使高低电平间的阈值差变小，当震荡的幅值再大或有其他干扰引入时就无法正确分辨出脉冲电平值，导致通信时间变长或通信中断。接地和屏蔽不好会导致传输线抑制外部电磁干扰能力的下降，体现在视频图象就是雪花噪点、网纹干扰以及横纹滚动等；在信号传输线上形成尖峰干扰，造成通信错误。平衡传输线路失衡也会在信号传输线上形成尖峰干扰。静电放电除了会造成设备损坏外，还会影响存储器内的数据，使设备出现些莫名其妙的错误。 抗干扰的方法 从干扰源的分析了解到并没有特别的干扰源，消除或者减少上述干扰的理论探讨也有许多，如何针对闭路电视监控工程解决干扰问题，很少有文献涉及，下面就闭路电视监控工种中常见的干扰及解决方法进行些探讨。 视频信号的干扰 视频信号的干扰在图象上表现为地花点和５０ＨＺ横纹滚动，对于雪花点干扰是由于传输线上信号衰减以及耦合了高频干扰所致，这种干扰比较容易消除，在摄象机与控制矩阵之间合理位置增加一个视频放大器，将信号的受噪比提高，或者改变视频电缆的路径避开高频干扰源，高频干扰的问题可基本上得到解决。较难解决的是５０ＨＺ横纹滚动及进一步加高频干扰的情况，比如电梯轿厢内摄象机的输出图象。为了抑制上述干扰，首先分析一 下造成上述问题的原因。 摄象机要求的供电电源一般有三种：直流１２Ｖ、交流２４Ｖ或２２０Ｖ，大多数工程应用中不从电梯轿厢的供电电源上取，而是另外布设供电电源给摄象机供电，摄象机输出图象经过一条软性的视频电缆从井道的上方

异方差性的white检验及处理方法

实验二异方差模型的white检验与处理 【实验目的】 掌握异方差性的white检验及处理方法 【实验原理】 1. 定性分析异方差 (1) 经济变量规模差别很大时容易出现异方差。如个人收入与支出关系，投入与产出 关系。 (2) 利用散点图做初步判断。 (3) 利用残差图做初步判断。 2、异方差表现与来源异方差通常有三种表现形式 （1）递增型 （2）递减型 （3）条件自回归型。 3、White检验 （1）不需要对观测值排序，也不依赖于随机误差项服从正态分布，它是通过一个辅助回归式构造 2 统计量进行异方差检验。White检验的零假设和备择假设是 H0: (4－1)式中的ut不存在异方差， H1: (4－2)式中的ut存在异方差。 (2)在不存在异方差假设条件下，统计量 T R 2 2(5) 其中T表示样本容量，R2是辅助回归式(4－3)的OLS估计式的可决系数。自由度5表示辅助回归式(4－3)中解释变量项数（注意，不计算常数项）。T R 2属于LM统计量。 （3）判别规则是 若T R 2 2 (5), 接受H0（ut 具有同方差） 若T R 2 > 2 (5), 拒绝H0（ut 具有异方差） 【实验软件】 Eview6 【实验要求】 熟练掌握异方差white检验方法 【实验内容】 建立并检验我国部分城市国民收入y和对外直接投资FDI异方差模型 【实验方案设计】 下表列出了我国各地区农村居民家庭人均纯收入与家庭人均生活消费支出的数据，并利用统计软件Eviews建立异方差模型

表1 各地区农村居民家庭人均纯收入与家庭人均生活消费支出的数据（单位：元） 【实验过程】 1、启动Eviews6软件，建立新的workfile. 在主菜单中选择【File 】--【New 】--【Workfile 】,弹出 Workfile Create 对话框,在Workfile structure typ 中选择unstructured/undted.然后在observations 中输入31.在WF 中输入Work1，点击OK 按钮。如图： 2、数据导入且将要分析的数据复制黏贴. 在主菜单的空白处输入data x y 按下enter 。将家庭人均纯收入X 和家庭生活消 地区 家庭人均 纯收入 家庭生活消费支出 地区 家庭人均 纯收入 家庭生活消费支出 北京 湖北 3090 天津 湖南 河北 广东 山西 广西 内蒙古 海南 辽宁 重庆 吉林 四川 黑龙江 贵州 上海 云南 江苏 西藏 浙江 陕西 安徽 甘肃 福建 青海 江西 宁夏 山东 新疆 河南

公文写作规范格式

商务公文写作目录 一、商务公文的基本知识 二、应把握的事项与原则 三、常用商务公文写作要点 四、常见错误与问题

一、商务公文的基本知识 1、商务公文的概念与意义 商务公文是商业事务中的公务文书，是企业在生产经营管理活动中产生的，按照严格的、既定的生效程序和规范的格式而制定的具有传递信息和记录作用的载体。规范严谨的商务文书，不仅是贯彻企业执行力的重要保障，而且已经成为现代企业管理的基础中不可或缺的内容。商务公文的水平也是反映企业形象的一个窗口，商务公文的写作能力常成为评价员工职业素质的重要尺度之一。 2、商务公文分类：（1）根据形成和作用的商务活动领域，可分为通用公文和专用公文两类（2）根据内容涉及秘密的程度，可分为对外公开、限国内公开、内部使用、秘密、机密、绝密六类（3）根据行文方向，可分为上行文、下行文、平行文三类（4）根据内容的性质，可分为规范性、指导性、公布性、陈述呈请性、商洽性、证明性公文（5）根据处理时限的要求，可分为平件、急件、特急件三类（6）根据来源，在一个部门内部可分为收文、发文两类。 3、常用商务公文： （1）公务信息：包括通知、通报、通告、会议纪要、会议记录等 （2）上下沟通：包括请示、报告、公函、批复、意见等 （3）建规立矩：包括企业各类管理规章制度、决定、命令、任命等； （4）包容大事小情：包括简报、调查报告、计划、总结、述职报告等； （5）对外宣传：礼仪类应用文、领导演讲稿、邀请函等； （6）财经类：经济合同、委托授权书等； （7）其他：电子邮件、便条、单据类（借条、欠条、领条、收条）等。 考虑到在座的主要岗位，本次讲座涉及请示、报告、函、计划、总结、规章制度的写作，重点谈述职报告的写作。 4、商务公文的特点： （1）制作者是商务组织。（2）具有特定效力，用于处理商务。 （3）具有规范的结构和格式，而不像私人文件靠“约定俗成”的格式。商务公文区别于其它文章的主要特点是具有法定效力与规范格式的文件。 5、商务公文的四个构成要素： （1）意图：主观上要达到的目标 (2）结构：有效划分层次和段落，巧设过渡和照应 (3）材料：组织材料要注意多、细、精、严 (4) 正确使用专业术语、熟语、流行语等词语，适当运用模糊语言、模态词语与古词语。 6、基本文体与结构 商务文体区别于其他文体的特殊属性主要有直接应用性、全面真实性、结构格式的规范性。其特征表现为：被强制性规定采用白话文形式，兼用议论、说明、叙述三种基本表达方法。商务公文的基本组成部分有：标题、正文、作者、日期、印章或签署、主题词。其它组成部分有文头、发文字号、签发人、保密等级、紧急程度、主送机关、附件及其标记、抄送机关、注释、印发说明等。印章或签署均为证实公文作者合法性、真实性及公文效力的标志。 7、稿本 （1）草稿。常有“讨论稿”“征求意见稿”“送审稿”“草稿”“初稿”“二稿”“三稿”等标记。（2）定稿。是制作公文正本的标准依据。有法定的生效标志（签发等）。（3）正本。格式正规并有印章或签署等表明真实性、权威性、有效性。（4）试行本。在试验期间具有正式公文的法定效力。（5）暂行本。在规定

信号抗干扰解决办法

信号抗干扰解决办法 The Standardization Office was revised on the afternoon of December 13, 2020

解决现场的信号干扰问题 时间:2010-04-24 22:30来源:作者:点击: 17次 生产过程监视和控制中要用到多种自动化仪表、计算机及相应执行机构,过程中的信号既有微弱到毫伏级的小信号,又有数十伏的大信号,而且还有高达数千伏、数百安培的信号要处理。从频率上讲，有直流低频范围的，也有高频/脉冲尖峰。设备、仪表间互扰成为系统调试中必须要解决的问题。除了电磁屏蔽之外，解决各种设备、仪表的“地”，也即信号参考点的电位差，将成为重要课题。因为不同设备、仪表的信号要互传互送，那就存在信号参考点问题。换句话说，要使信号完整传送，理想化的情况是所有设备、仪表中的信号有一个共同的参考点，也即共有一个“地”。进一步讲，所有设备、仪表的信号的参考点之间电位为“零”。但是在实际环境中，这一点几乎是不可及的，这里面除了各个设备、仪表“地”之间连线电阻产生的电压降之外，尚有各种设备、仪表在不同环境受到干扰不同，以及导线接点经受风吹雨淋，导致接点质量下降等诸多因素。致使各个“地”之间有差别。以示意图一为例. 图一 PLC与外接仪表示意图 图一中标明有两个现场设备仪表向PLC传送信号以及PLC向两台现场设备仪表发出信号。假定传送的均为0-10VDC信号。理想情况，PLC及两个现场设备“地”电位完全相等。传送过程中又没有干扰，这样从PLC输入来看，接收正确。但正如前所述，两个现场设备通常有“地”电位差，举例来讲，1#设备“地”与PLC“地”同电位，2#设备比它们的“地”电位高，这样1#设备给PLC的信号为0-10V，而2#设备给PLC的为误差就产生了,同时1#,2#设备的“地”线在PLC汇合联接。将电压施加在PLC地线条上，有可能损坏PLC局部“地”线，同时在显示错误数据，由此引起的问题在现场调试中屡有出现。例如某大型建材公司的生产线调试中，使用美国AB-PLC接国内某厂家手操器。AB-PLC的数据采集板有每八个通道，八个通道共用一个12位A/D，经过变换

关于会议纪要的规范格式和写作要求

关于会议纪要的规范格式和写作要求 一、会议纪要的概念 会议纪要是一种记载和传达会议基本情况或主要精神、议定事项等内容的规定性公文。是在会议记录的基础上，对会议的主要内容及议定的事项，经过摘要整理的、需要贯彻执行或公布于报刊的具有纪实性和指导性的文件。 会议纪要根据适用范围、内容和作用，分为三种类型： 1、办公会议纪要(也指日常行政工作类会议纪要)，主要用于单位开会讨论研究问题，商定决议事项，安排布置工作，为开展工作提供指导和依据。如，xx学校工作会议纪要、部长办公会议纪要、市委常委会议纪要。 2、专项会议纪要(也指协商交流性会议纪要)，主要用于各类交流会、研讨会、座谈会等会议纪要，目的是听取情况、传递信息、研讨问题、启发工作等。如，xx县脱贫致富工作座谈会议纪要。 3、代表会议纪要(也指程序类会议纪要)。它侧重于记录会议议程和通过的决议，以及今后工作的建议。如《××省第一次盲人聋哑人代表会议纪要》、《xx市第x次代表大会会议纪要》。 另外，还有工作汇报、交流会，部门之间的联席会等方面的纪要，但基本上都系日常工作类的会议纪要。 二、会议纪要的格式 会议纪要通常由标题、正文、结尾三部分构成。

1、标题有三种方式：一是会议名称加纪要，如《全国农村工作会议纪要》;二是召开会议的机关加内容加纪要，也可简化为机关加纪要，如《省经贸委关于企业扭亏会议纪要》、《xx组织部部长办公会议纪要》;三是正副标题相结合，如《维护财政制度加强经济管理——在xx部门xx座谈会上的发言纪要》。 会议纪要应在标题的下方标注成文日期，位置居中，并用括号括起。作为文件下发的会议纪要应在版头部分标注文号，行文单位和成文日期在文末落款(加盖印章)。 2、会议纪要正文一般由两部分组成。 (1)开头，主要指会议概况，包括会议时间、地点、名称、主持人，与会人员，基本议程。 (2)主体，主要指会议的精神和议定事项。常务会、办公会、日常工作例会的纪要，一般包括会议内容、议定事项，有的还可概述议定事项的意义。工作会议、专业会议和座谈会的纪要，往往还要写出经验、做法、今后工作的意见、措施和要求。 (3)结尾，主要是对会议的总结、发言评价和主持人的要求或发出的号召、提出的要求等。一般会议纪要不需要写结束语，主体部分写完就结束。 三、会议纪要的写法 根据会议性质、规模、议题等不同，正文部分大致可以有以下几种写法： 1、集中概述法(综合式)。这种写法是把会议的基本情况，讨

titlesec宏包使用手册

titlesec&titletoc中文文档 张海军编译 makeday1984@https://www.wendangku.net/doc/f717353077.html, 2009年10月 目录 1简介,1 2titlesec基本功能,2 2.1.格式,2.—2.2.间隔, 3.—2.3.工具,3. 3titlesec用法进阶,3 3.1.标题格式,3.—3.2.标题间距, 4.—3.3.与间隔相关的工具, 5.—3.4.标题 填充,5.—3.5.页面类型,6.—3.6.断行,6. 4titletoc部分,6 4.1.titletoc快速上手,6. 1简介 The titlesec and titletoc宏包是用来改变L A T E X中默认标题和目录样式的，可以提供当前L A T E X中没有的功能。Piet van Oostrum写的fancyhdr宏包、Rowland McDonnell的sectsty宏包以及Peter Wilson的tocloft宏包用法更容易些；如果希望用法简单的朋友，可以考虑使用它们。 要想正确使用titlesec宏包，首先要明白L A T E X中标题的构成，一个完整的标题是由标签+间隔+标题内容构成的。比如： 1.这是一个标题，此标题中 1.就是这个标题的标签，这是一个标签是此标题的内容，它们之间的间距就是间隔了。 1

2titlesec基本功能 改变标题样式最容易的方法就是用几向个命令和一系列选项。如果你感觉用这种方法已经能满足你的需求，就不要读除本节之外的其它章节了1。 2.1格式 格式里用三组选项来控制字体的簇、大小以及对齐方法。没有必要设置每一个选项，因为有些选项已经有默认值了。 rm s f t t md b f up i t s l s c 用来控制字体的族和形状2，默认是bf,详情见表1。 项目意义备注（相当于） rm roman字体\textrm{...} sf sans serif字体\textsf{...} tt typewriter字体\texttt{...} md mdseries(中等粗体)\textmd{...} bf bfseries(粗体)\textbf{...} up直立字体\textup{...} it italic字体\textit{...} sl slanted字体\textsl{...} sc小号大写字母\textsc{...} 表1:字体族、形状选项 bf和md属于控制字体形状，其余均是切换字体族的。 b i g medium s m a l l t i n y（大、中、小、很小） 用来标题字体的大小，默认是big。 1这句话是宏包作者说的，不过我感觉大多情况下，是不能满足需要的，特别是中文排版，英文 可能会好些！ 2L A T E X中的字体有5种属性：编码、族、形状、系列和尺寸。 2

信号抗干扰解决办法

解决现场的信号干扰问题 时间:2010-04-24 22:30来源:作者:点击: 17次 生产过程监视和控制中要用到多种自动化仪表、计算机及相应执行机构,过程中的信号既有微弱到毫伏级的小信号,又有数十伏的大信号,而且还有高达数千伏、数百安培的信号要处理。从频率上讲，有直流低频范围的，也有高频/脉冲尖峰。设备、仪表间互扰成为系统调试中必须要解决的问题。除了电磁屏蔽之外，解决各种设备、仪表的“地”，也即信号参考点的电位差，将成为重要课题。因为不同设备、仪表的信号要互传互送，那就存在信号参考点问题。换句话说，要使信号完整传送，理想化的情况是所有设备、仪表中的信号有一个共同的参考点，也即共有一个“地”。进一步讲，所有设备、仪表的信号的参考点之间电位为“零”。但是在实际环境中，这一点几乎是不可及的，这里面除了各个设备、仪表“地”之间连线电阻产生的电压降之外，尚有各种设备、仪表在不同环境受到干扰不同，以及导线接点经受风吹雨淋，导致接点质量下降等诸多因素。致使各个“地”之间有差别。以示意图一为例.

图一PLC与外接仪表示意图 图一中标明有两个现场设备仪表向PLC传送信号以及PLC向两台现场设备仪表发出信号。假定传送的均为0-10VDC信号。理想情况，PLC及两个现场设备“地”电位完全相等。传送过程中又没有干扰，这样从PLC输入来看，接收正确。但正如前所述，两个现场设备通常有“地”电位差，举例来讲，1#设备“地”与PLC“地”同电位，2#设备比它们的“地”电位高0.1V，这样1#设备给PLC的信号为0-10V，而2#设备给PLC的为0.1V-10.1V,误差就产生了,同时1#,2#设备的“地”线在PLC汇合联接。将0.1V电压施加在PLC地线条上，有可能损坏PLC局部“地”线，同时在显示错误数据，由此引起的问题在现场调试中屡有出现。例如某大型建材公司的生产线调试中，使用美国AB-PLC接国内某厂家手操器。AB-PLC的数据采集板有每八个通道，八个通道共用一个12位A/D，经过变换后，由12个光耦实现与主机隔离。它的八个通道输入之间并没有隔离，致使八个通道输入信号每个单独接入采集板均正常，接入两个或多于两个外部信号时，显示数字乱跳，故障无法排除。又如航天某部门测试发动机各点温度，使用K型偶作为传感器，同上述相似，仅测试一点一切正常，但是向主机接入两点或两点以上温度时，显示的温度明显错误。这两种情况在接入隔离器后，均正常。隔离器之所以能起到这个作用，就是它具有使输入/输出在电气上完全隔离的特点。换句话讲，输入/输出之间没有共同“地”，外来信号不管是0-10V，或带着+10V干扰的10V-20V经隔离后均为0-10V，也即隔离后新建立的PLC“地”与外部设备、仪表“地”没关系。正是由于这个原因，也实现输入到PLC主机

异方差性的检验及处理方法

实验四异方差性 【实验目的】 掌握异方差性的检验及处理方法 【实验内容】 建立并检验我国制造业利润函数模型 【实验步骤】 【例1】表1列出了1998年我国主要制造工业销售收入与销售利润的统计资料，请利用统计软件Eviews建立我国制造业利润函数模型。 一、检验异方差性 ⒈图形分析检验 ⑴观察销售利润（Y）与销售收入（X）的相关图(图1)：SCAT X Y 图1 我国制造工业销售利润与销售收入相关图 从图中可以看出，随着销售收入的增加，销售利润的平均水平不断提高，但离散程度也逐步扩大。这说明变量之间可能存在递增的异方差性。

⑵残差分析 首先将数据排序（命令格式为：SORT 解释变量），然后建立回归方程。在方程窗口中点击Resids按钮就可以得到模型的残差分布图（或建立方程后在Eviews工作文件窗口中点击resid对象来观察）。 图2 我国制造业销售利润回归模型残差分布 图2显示回归方程的残差分布有明显的扩大趋势，即表明存在异方差性。 ⒉Goldfeld-Quant检验 ⑴将样本按解释变量排序（SORT X）并分成两部分（分别有1到10共11个样本合19到28共10个样本） ⑵利用样本1建立回归模型1（回归结果如图3），其残差平方和为2579.587。 SMPL 1 10 LS Y C X 图3 样本1回归结果 ⑶利用样本2建立回归模型2（回归结果如图4），其残差平方和为63769.67。 SMPL 19 28 LS Y C X

图4 样本2回归结果 ⑷计算F 统计量：12/RSS RSS F =＝63769.67/2579.59=24.72，21RSS RSS 和分别是模型1和模型2的残差平方和。 取 05 .0=α时，查F 分布表得 44.3)1110,1110(05.0=----F ，而 44.372.2405.0=>=F F ，所以存在异方差性 ⒊White 检验 ⑴建立回归模型：LS Y C X ，回归结果如图5。 图5 我国制造业销售利润回归模型 ⑵在方程窗口上点击View\Residual\Test\White Heteroskedastcity,检验结果如图6。 图6 White 检验结果

解决监控视频干扰的二个方法

解决监控视频干扰的二 个方法 The manuscript was revised on the evening of 2021

解决监控视频干扰的二个方法 第一：在建设的时候就要考虑 视频监控信号传输的传统方式为视频基带传输。视频基带传输是指视频信号不经过频率变换等任何处理，由图像摄取端通过同轴电缆直接传输到监视端的传输方式。图像在传输时直接利用同轴电缆的0～6MHz来传输，非常易受到干扰，使图像出现网纹、横纹和噪点影响监视效果。对于基带传输视频干扰，从干扰源角度分为交流声干扰和空间电磁波干扰，从干扰切入方式分为传导式干扰和辐射式干扰。 闭路电视监控系统，在建筑物内的应用越来越多，由于建筑物内的电气环境比较复杂，容易形成各种干扰源，如果未采取恰当的防范措施，各种干扰就会通过传输线缆进入闭路电视监控系统，造成视频图象质量下降、系统控制失灵、运行不稳定等现象。 一、干扰是如何产生的 闭路电视监控系统中传输信号的类型主要有两类：一类是模拟视频信号，传输路径由摄像机到矩阵，从矩阵再到显示器或录像机；一类是数字信号包括矩阵与摄像机之间的控制信息传输，矩阵中计算机部分的数字信号。一般设备成为干扰源的可能性很小，因此干扰主要通过信号传输路径进入系统。闭路电视监控系统的信号传输路径是，能通过视频电缆和传输控制信号的双绞线耦合进系统的干扰有：各种高频噪声比如大电感负载启停，地电位不等引入的工频干扰，平衡传输线路失衡使抑噪能力下降将共频干扰转成了差模干扰，传输线上阻抗不匹配造成信号的反射使信号传输质量下降，静电放电沿传输线进入设备造成接口芯片损伤或损坏。具体表现如下：

做安防工程，经常遇到的就是干扰问题，现实中的干扰现象越来越多，如果按照工艺要求施工的话，工程量将非常巨大。所有的管线要地埋或者穿屏蔽，电源线缆与视频线缆要隔开距离传输，另外线缆不能太长，75-5的视频线缆不能超过500米。另外在布线的过程中暴力布线很严重，往往会将线缆的屏

毕业论文写作要求与格式规范

毕业论文写作要求与格式规范 关于《毕业论文写作要求与格式规范》，是我们特意为大家整理的，希望对大家有所帮助。 (一)文体 毕业论文文体类型一般分为：试验论文、专题论文、调查报告、文献综述、个案评述、计算设计等。学生根据自己的实际情况，可以选择适合的文体写作。 (二)文风 符合科研论文写作的基本要求：科学性、创造性、逻辑性、

实用性、可读性、规范性等。写作态度要严肃认真，论证主题应有一定理论或应用价值;立论应科学正确，论据应充实可靠，结构层次应清晰合理，推理论证应逻辑严密。行文应简练，文笔应通顺，文字应朴实，撰写应规范，要求使用科研论文特有的科学语言。 (三)论文结构与排列顺序 毕业论文，一般由封面、独创性声明及版权授权书、摘要、目录、正文、后记、参考文献、附录等部分组成并按前后顺序排列。 1.封面：毕业论文(设计)封面具体要求如下： (1)论文题目应能概括论文的主要内容，切题、简洁，不超过30字，可分两行排列;

(2)层次：大学本科、大学专科 (3)专业名称：机电一体化技术、计算机应用技术、计算机网络技术、数控技术、模具设计与制造、电子信息、电脑艺术设计、会计电算化、商务英语、市场营销、电子商务、生物技术应用、设施农业技术、园林工程技术、中草药栽培技术和畜牧兽医等专业，应按照标准表述填写; (4)日期：毕业论文(设计)完成时间。 2.独创性声明和关于论文使用授权的说明：需要学生本人签字。 3.摘要：论文摘要的字数一般为300字左右。摘要是对论文的内容不加注释和评论的简短陈述，是文章内容的高度概括。主要内容包括：该项研究工作的内容、目的及其重要性;所使用的实验方法;总结研究成果，突出作者的新见解;研究结论及其意义。摘要中不列举例证，不描述研究过程，不做自我评价。

视频信号干扰原因和解决方法

视频信号干扰原因和解决方法 2009-05-13 11:39 在电厂，变电站，电台，，泵站，基站，车间等恶劣电磁环境下，有必要事先考虑传输线缆，最好是用光缆、其次用双绞线传输，再次用同轴视频线传输。 以下转摘EIE工程师的技术文章，他提供了全面的解决思路，请参考；如果是真干扰，用他们公司的加权信号抗干扰器的效果还是明显的。 1.BNC头接触不良会造成干扰——属于施工水平和经验问题，也有BNC公母头质量问题和75/50欧姆混卖混用问题； 2.电缆伤断造成干扰：穿管时拉断电缆，垂直或倾斜自承重布线拉断电缆——如电梯视频线，弱电井多路捆绑垂直走线等——属于施工水平和经验问题； 3.使用了劣质电缆，产生了干扰，劣质线质甚至用铁包铜来卖； 4.摄像机因素造成干扰：摄像机本身质量问题，输出视频信号中含有干扰信号。 5.摄像机电源因素造成干扰：电源适配器质量不好，波纹太大，实际供电功率不够；集中供电线路衰减太大，电压太低；设备漏电等。 6.主机问题：相邻通道串扰，采集卡或主机质量问题等产生了干扰； 7.引入了电网传导干扰——电源没有净化； 8.云台运动时，视频信号闪动；红外夜视晚上背景有噪点，画面一层白雾等，以为是干扰； 9.系统多点接大地引入地电位环路干扰：摄像机安装在接地金属物体上,金属立柱，金属塔架，接触了建筑物钢筋，电缆破损触到接地金属体等等——属于施工经验不足，不当的失误；或者使用了不合格防雷器，被个别防雷厂家“等电位体连接”误导，把摄像机外壳接了大地。 10.其他工程中各种“低级错误”造成的干扰现象。解决这类主观因素造成的假干扰，从外部找原因，用抗干扰设备来解决，您觉得思路对吗？ 问题是工程中发现的是“干扰现象”，这类与主观因素有关的“干扰现象”，并没有打上“人工制造的”标签。工程中最现实，最急切的问题是，怎么判断它是“假干扰”呢？ “真干扰”是指空间电磁波与传输线发生电磁耦合，在传输线上产生了感应电动势，干扰感应电动势进入信号传输回路，在信号有效负载上，产生了干扰信号电压。这就是安防工程的“真干扰”。

公文格式规范与常见公文写作

公文格式规范与常见公文写作 一、公文概述与公文格式规范 党政机关公文种类的区分、用途的确定及格式规范等，由中共中央办公厅、国务院办公厅于2012年4月16日印发，2012年7月1日施行的《党政机关公文处理工作条例》规定。之前相关条例、办法停止执行。 （一）公文的含义 公文，即公务文书的简称，属应用文。 广义的公文，指党政机关、社会团体、企事业单位，为处理公务按照一定程序而形成的体式完整的文字材料。 狭义的公文，是指在机关、单位之间，以规范体式运行的文字材料，俗称“红头文件”。 ?（二）公文的行文方向和原则 ?、上行文下级机关向上级机关行文。有“请示”、“报告”、和“意见”。 ?、平行文同级机关或不相隶属机关之间行文。主要有“函”、“议案”和“意见”。 ?、下行文上级机关向下级机关行文。主要有“决议”、“决定”、“命令”、“公报”、“公告”、“通告”、“意见”、“通知”、“通报”、“批复”和“会议纪要”等。 ?其中，“意见”、“会议纪要”可上行文、平行文、下行文。?“通报”可下行文和平行文。 ?原则： ?、根据本机关隶属关系和职权范围确定行文关系 ?、一般不得越级行文 ?、同级机关可以联合行文 ?、受双重领导的机关应分清主送机关和抄送机关 ?、党政机关的部门一般不得向下级党政机关行文 ?(三) 公文的种类及用途 ?、决议。适用于会议讨论通过的重大决策事项。 ?、决定。适用于对重要事项作出决策和部署、奖惩有关单位和人员、变更或撤销下级机关不适当的决定事项。

?、命令（令）。适用于公布行政法规和规章、宣布施行重大强制性措施、批准授予和晋升衔级、嘉奖有关单位和人员。 ?、公报。适用于公布重要决定或者重大事项。 ?、公告。适用于向国内外宣布重要事项或者法定事项。 ?、通告。适用于在一定范围内公布应当遵守或者周知的事项。?、意见。适用于对重要问题提出见解和处理办法。 ?、通知。适用于发布、传达要求下级机关执行和有关单位周知或者执行的事项，批转、转发公文。 ?、通报。适用于表彰先进、批评错误、传达重要精神和告知重要情况。 ?、报告。适用于向上级机关汇报工作、反映情况，回复上级机关的询问。 ?、请示。适用于向上级机关请求指示、批准。 ?、批复。适用于答复下级机关请示事项。 ?、议案。适用于各级人民政府按照法律程序向同级人民代表大会或者人民代表大会常务委员会提请审议事项。 ?、函。适用于不相隶属机关之间商洽工作、询问和答复问题、请求批准和答复审批事项。 ?、纪要。适用于记载会议主要情况和议定事项。?（四）、公文的格式规范 ?、眉首的规范 ?（）、份号 ?也称编号，置于公文首页左上角第行，顶格标注。“秘密”以上等级的党政机关公文，应当标注份号。 ?（）、密级和保密期限 ?分“绝密”、“机密”、“秘密”三个等级。标注在份号下方。?（）、紧急程度 ?分为“特急”和“加急”。由公文签发人根据实际需要确定使用与否。标注在密级下方。 ?（）、发文机关标志（或称版头） ?由发文机关全称或规范化简称加“文件”二字组成。套红醒目，位于公文首页正中居上位置（按《党政机关公文格式》标准排

ctex 宏包说明 ctex

ctex宏包说明 https://www.wendangku.net/doc/f717353077.html,? 版本号：v1.02c修改日期：2011/03/11 摘要 ctex宏包提供了一个统一的中文L A T E X文档框架，底层支持CCT、CJK和xeCJK 三种中文L A T E X系统。ctex宏包提供了编写中文L A T E X文档常用的一些宏定义和命令。 ctex宏包需要CCT系统或者CJK宏包或者xeCJK宏包的支持。主要文件包括ctexart.cls、ctexrep.cls、ctexbook.cls和ctex.sty、ctexcap.sty。 ctex宏包由https://www.wendangku.net/doc/f717353077.html,制作并负责维护。 目录 1简介2 2使用帮助3 2.1使用CJK或xeCJK (3) 2.2使用CCT (3) 2.3选项 (4) 2.3.1只能用于文档类的选项 (4) 2.3.2只能用于文档类和ctexcap.sty的选项 (4) 2.3.3中文编码选项 (4) 2.3.4中文字库选项 (5) 2.3.5CCT引擎选项 (5) 2.3.6排版风格选项 (5) 2.3.7宏包兼容选项 (6) 2.3.8缺省选项 (6) 2.4基本命令 (6) 2.4.1字体设置 (6) 2.4.2字号、字距、字宽和缩进 (7) ?https://www.wendangku.net/doc/f717353077.html, 1

1简介2 2.4.3中文数字转换 (7) 2.5高级设置 (8) 2.5.1章节标题设置 (9) 2.5.2部分修改标题格式 (12) 2.5.3附录标题设置 (12) 2.5.4其他标题设置 (13) 2.5.5其他设置 (13) 2.6配置文件 (14) 3版本更新15 4开发人员17 1简介 这个宏包的部分原始代码来自于由王磊编写cjkbook.cls文档类，还有一小部分原始代码来自于吴凌云编写的GB.cap文件。原来的这些工作都是零零碎碎编写的，没有认真、系统的设计，也没有用户文档，非常不利于维护和改进。2003年，吴凌云用doc和docstrip工具重新编写了整个文档，并增加了许多新的功能。2007年，oseen和王越在ctex宏包基础上增加了对UTF-8编码的支持，开发出了ctexutf8宏包。2009年5月，我们在Google Code建立了ctex-kit项目1，对ctex宏包及相关宏包和脚本进行了整合，并加入了对XeT E X的支持。该项目由https://www.wendangku.net/doc/f717353077.html,社区的开发者共同维护，新版本号为v0.9。在开发新版本时，考虑到合作开发和调试的方便，我们不再使用doc和docstrip工具，改为直接编写宏包文件。 最初Knuth设计开发T E X的时候没有考虑到支持多国语言，特别是多字节的中日韩语言。这使得T E X以至后来的L A T E X对中文的支持一直不是很好。即使在CJK解决了中文字符处理的问题以后，中文用户使用L A T E X仍然要面对许多困难。最常见的就是中文化的标题。由于中文习惯和西方语言的不同，使得很难直接使用原有的标题结构来表示中文标题。因此需要对标准L A T E X宏包做较大的修改。此外，还有诸如中文字号的对应关系等等。ctex宏包正是尝试着解决这些问题。中间很多地方用到了在https://www.wendangku.net/doc/f717353077.html,论坛上的讨论结果，在此对参与讨论的朋友们表示感谢。 ctex宏包由五个主要文件构成：ctexart.cls、ctexrep.cls、ctexbook.cls和ctex.sty、ctexcap.sty。ctex.sty主要是提供整合的中文环境，可以配合大多数文档类使用。而ctexcap.sty则是在ctex.sty的基础上对L A T E X的三个标准文档类的格式进行修改以符合中文习惯，该宏包只能配合这三个标准文档类使用。ctexart.cls、ctexrep.cls、ctexbook.cls则是ctex.sty、ctexcap.sty分别和三个标准文档类结合产生的新文档类，除了包含ctex.sty、ctexcap.sty的所有功能，还加入了一些修改文档类缺省设置的内容（如使用五号字体为缺省字体）。 1https://www.wendangku.net/doc/f717353077.html,/p/ctex-kit/

PLC控制系统解决现场信号干扰源的方法

PLC控制系统解决现场信号干扰源的方法 随着科学技术的发展，PLC在工业控制中的应用越来越广泛。PLC控制系统的可靠性直接影响到工业企业的安全生产和经济运行，系统的干扰能力是关系到整个系统可靠运行的关键。自动化系统中所使用的各种类型PLC，有的是集中安装在控制室，有的是安装在生产现场和各种电机设备上，它们大多处在强电电路和强电设备形成的恶劣电磁环境中。要提高PLC控制系统可靠性，设计人员只有预先了解到各种干扰才能有效保证系统可靠运行。 电磁干扰源及对系统的干扰 影响PLC控制系统的干扰源于一般影响工业控制设备的干扰源一样，大都产生在电流或电压剧烈变化的部位，这些电荷剧烈移动的部位就是噪声源，即干扰源。 干扰类型通常按干扰产生的原因、噪声的干扰模式和噪声的波形性质的不同 划分。其中：按噪声产生的原因不同，分为放电噪声、偶发噪声等：按声音干扰 模式不同，分为共模干扰和差模干扰是一种比较常用的分类方法。共模干扰是 信号对地面的电位差，主要是由电网串入，、地电位差及空间电磁辐射在信号线 上感应的共态电压所加形成。共模电压有时较大，特别是采用隔离性能差的电 器供电室，变送器输出信号的共模电压普遍较高，有的可高达130V以上。共模电压通过不对称电路可转换成共模电压，直接影响测控信号，造成元器件坏， 这种共模干扰可为直流、亦可谓交流。共模干扰是指用于信号两级间得干扰电压， 主要由空间电磁场在信号间耦合感应及由不平衡电路转换共模干扰所形成的电压，这种让直接叠加在信号上，直接影响测量与控制精度。 PLC控制系统中电磁干扰的主要来源有哪些呢? 1) 来自空间的辐射干扰 空间的辐射电磁场主要是由电力网络、电气设备的暂态过程、雷电、无线电广播、电视、雷达、高频感应加热设备等产生的，通常称为辐射干扰。其分布极 为复杂，若plc系统置于所设频场内，就回收到辐射干扰，其影响主要通过两 条路劲，一是直接对PLC内部的辐射，由电路感应产生干扰，而是对PLC通信内网络的辐射，出通信线路的感应引入干扰。辐射干扰与现场设备所产生的电磁 干场大小，特别是频率有关，一般通过设置屏蔽电缆和PLC局部屏蔽及高压泻放元件进行保护。 2) 来自系统外引线的干扰 主要通过电源和信号线引入，通常称为传导干扰。这种干扰在我国工业现场 教严重。 3) 来自电源的干扰 实践证明，因电源引入的干扰造成控制系统故障的情况很多，在，工程调式中遇到过，后更换隔离性能较高的PLC电源。问题才能得到解决。 PLC系统的正常供电电源均由电网供电，由于电网覆盖范围广，将受到所有 空间电磁干扰而在线路上感应电压和电路，尤其是电网内部的变化，开关操作浪涌、大型电力设备启停、交直流转动装置引起的谐波、电网短路暂态冲击等，都 通过社电线路到电源边PLC电源通常采用隔离电源，但其结构及制造工艺因素使 其隔离性并不理想。实际上，由于分布参数特别是分布电容的存在，绝对隔离 室不可能的。 4) 来自接地系统混乱时引入的干扰

文档书写格式规范要求

学生会文档书写格式规范要求 目前各部门在日常文书编撰中大多按照个人习惯进行排版，文档中字体、文字大小、行间距、段落编号、页边距、落款等参数设置不规范，严重影响到文书的标准性和美观性，以下是文书标准格式要求及日常文档书写注意事项，请各部门在今后工作中严格实行： 一、文件要求 1.文字类采用Word格式排版 2.统计表、一览表等表格统一用Excel格式排版 3.打印材料用纸一般采用国际标准A4型（210mm×297mm），左侧装订。版面方向以纵向为主，横向为辅，可根据实际需要确定 4.各部门的职责、制度、申请、请示等应一事一报，禁止一份行文内同时表述两件工作。 5.各类材料标题应规范书写，明确文件主要内容。 二、文件格式 （一）标题 1.文件标题：标题应由发文机关、发文事由、公文种类三部分组成，黑体小二号字,不加粗，居中，段后空1行。 （二）正文格式 1. 正文字体：四号宋体，在文档中插入表格，单元格内字体用宋体，字号可根据内容自行设定。 2.页边距：上下边距为2.54厘米；左右边距为 3.18厘米。

3.页眉、页脚：页眉为1.5厘米；页脚为1.75厘米； 4.行间距：1.5倍行距。 5.每段前的空格请不要使用空格，应该设置首先缩进2字符 6.年月日表示：全部采用阿拉伯数字表示。 7.文字从左至右横写。 （三）层次序号 (1)一级标题：一、二、三、 (2)二级标题：（一）（二）（三） (3)三级标题：1. 2. 3. (4)四级标题：（1）（2）（3） 注：三个级别的标题所用分隔符号不同，一级标题用顿号“、”例如：一、二、等。二级标题用括号不加顿号，例如：（三）（四）等。三级标题用字符圆点“.”例如：5. 6.等。 （四）、关于落款： 1.对外行文必须落款“湖南环境生物专业技术学院学生会”“校学生会”各部门不得随意使用。 2.各部门文件落款需注明组织名称及部门“湖南环境生物专业技术学院学生会XX部”“校学生会XX部” 3.所有行文落款不得出现“环境生物学院”“湘环学院”“学生会”等表述不全的简称。 4.落款填写至文档末尾右对齐，与前一段间隔2行 5.时间落款：文档中落款时间应以“2016年5月12日”阿拉伯数字

常见的图像干扰及其解决方法

说起视频干扰，要讲一下视频监控信号传输的传统方式视频基带传输。所谓的视频基带传输是指视频信号不经过频率变换等任何处理由图像摄取端通过同轴电缆直接传输到监视端的传输方式，图像在传输时直接利用同轴电缆的0~6MHz来传输，非常容易受到干扰，使图像出现网纹、横纹和噪点影响监视效果。对于基带传输视频干扰，从干扰源角度分为交流声干扰和空间电磁波干扰，从干扰切入方式分为传导式干扰和辐射式干扰。下面分析一下常见视频干扰现象及其原因。 1、工频干扰 干扰现象：图像出现雪花噪点、网纹或很宽暗横带持续不断滚动。 干扰原因：此现象是当摄像端与监控设备端同时接地时，由于地电阻及电缆外皮电阻的存在，在两地之间电力系统各相负载不平衡或接地方式不同引起50Hz电位差，从而产生工频干扰所致。地电位使两接地端存在电压降，电压降加在屏蔽层两端并与大地（地电阻）构成回路产生地电流，地电流经过线缆屏蔽层形成干扰电压，地电流的部分谐波分量落入视频芯线，致使芯线与屏蔽层之间产生干扰电位，使干扰信号加入视频信号中对监控图像形成干扰。 2、空间电磁波干扰 干扰现象：图像出现较密的斜形网纹，严重时会淹没图像。 干扰原因：当监控电缆在空中架设时，空中电磁波干扰信号所产生的空间电场会作用于监控传输线路，使线路两端而产生相当大的电磁干扰电压，其频率约在200Hz~2.3MHz。由于电缆中电位差的存在，使电缆屏蔽层产生干扰电流，而一般情况下摄像端和监控设备端均为接地状态，这就使干扰电流通过线缆两端接地点与大地形成回路，导致终端负载产生干扰电压，干扰信号耦合进视频信号中，产生图像干扰情况。 3、低频干扰（20Hz-nKHz低频噪声干扰） 干扰现象：图像出现静止水平条纹。 现象原因：由于声音、数据等信号属于低频信号，其频带狭窄在传输时只用到20Hz~nKHZ，几乎采用任何种类的电缆都可以传输，一般只受交流声干扰。用于传输视频信号的同轴电缆，其屏蔽层抗干扰曲线特性表明干扰信号频率越高其屏蔽性能越好，对于诸如载波电话、有线电台等低频率信号干扰反而显得苍白无力。低频干扰信号同样会在传输线缆上产生干扰电压，从而影响图像质量。 4、高频干扰（高频噪声干扰） 干扰现象：图像出现雪花点或高亮点。 现象原因：虽然视频传输所用同轴电缆抗高频干扰要比抗低频干扰性能强，但是强高频干扰信号还会对图像的传输产生干扰。大电荷负载启停、变频机及高频机等在工作时除了输

政府公文写作格式规范

政府公文写作格式 一、眉首部分 （一）发文机关标识 平行文和下行文的文件头，发文机关标识上边缘至上页边为62mm，发文机关下边缘至红色反线为28mm。 上行文中，发文机关标识上边缘至版心上边缘为80mm，即与上页边距离为117mm，发文机关下边缘至红色反线为30mm。 发文机关标识使用字体为方正小标宋_GBK，字号不大于22mm×15mm。 （二）份数序号 用阿拉伯数字顶格标识在版心左上角第一行，不能少于2位数。标识为“编号000001” （三）秘密等级和保密期限 用3号黑体字顶格标识在版心右上角第一行，两字中间空一字。如需要加保密期限的，密级与期限间用“★”隔开，密级中则不空字。 （四）紧急程度 用3号黑体字顶格标识在版心右上角第一行，两字中间空一字。如同时标识密级，则标识在右上角第二行。 （五）发文字号 标识在发文机关标识下两行，用3号方正仿宋_GBK字体剧

中排布。年份、序号用阿拉伯数字标识，年份用全称，用六角括号“〔〕”括入。序号不用虚位，不用“第”。发文字号距离红色反线4mm。 （六）签发人 上行文需要标识签发人，平行排列于发文字号右侧，发文字号居左空一字，签发人居右空一字。“签发人”用3号方正仿宋_GBK，后标全角冒号，冒号后用3号方正楷体_GBK标识签发人姓名。多个签发人的，主办单位签发人置于第一行，其他从第二行起排在主办单位签发人下，下移红色反线，最后一个签发人与发文字号在同一行。 二、主体部分 （一）标题 由“发文机关+事由+文种”组成，标识在红色反线下空两行，用2号方正小标宋_GBK，可一行或多行居中排布。 （二）主送机关 在标题下空一行，用3号方正仿宋_GBK字体顶格标识。回行是顶格，最后一个主送机关后面用全角冒号。 （三）正文 主送机关后一行开始，每段段首空两字，回行顶格。公文中的数字、年份用阿拉伯数字，不能回行，阿拉伯数字：用3号Times New Roman。正文用3号方正仿宋_GBK，小标题按照如下排版要求进行排版：