SSL协议由SSL记录协议和SSL握手协议两部分组成。

——①SSL记录协议

——在SSL协议中，所有的传输数据都被封装在记录中。记录是由记录头和记录数据组成的。所有的SSL通信包括握手消息、安全空白记录和应用数据都使用SSL记录层。

——②SSL握手协议

——SSL握手协议包含两个阶段，第一个阶段用于建立私密性通信信道，第二个阶段用于客户认证。

——第一阶段是通信的初始化阶段，首先SSL要求服务器向浏览器出示证书。证书包含有一个公钥，这个公钥是由一家可信证书授权机构签发的。通过内置的一些基础公共密钥，客户的浏览器可以判断服务器证书正确与否。然后，浏览器中的SSL软件发给服务器一个随机产生的传输密钥，此密钥由已验证过的公钥加密。由于传输密钥只能由对应的私有密钥来解密，这证实了该服务器属于一个认证过的公司。随机产生的传输密钥是核心机密，只有客户的浏览器和此公司的Web服务器知道这个数字序列。这个两方共享密钥的密文可以通过浏览器安全地抵达Web服务器，Internet上的其他人无法解开它。

—— 第二阶段的主要任务是对客户进行认证，此时服务器已经被认证了。服务器方向客户发出认证请求消息。客户收到服务器方的认证请求消息后，发出自己的证书，并 且监听对方回送的认证结果。而当服务器收到客户的证书后，给客户回送认证成功消息，否则返回错误消息。到此为止，握手协议全部结束。

SSL协议提供的安全信道有以下三种特性：

——·私密性：在握手协议定义了会话密钥后，所有的消息都被加密。

——·确认性：尽管会话的客户端认证是可选的，但是服务器端始终是被认证的。

——·可靠性：传送的消息包括消息完整性检查。

The DOT Language

          

---

The following is an abstract grammar defining the DOT language. Terminals are shown in bold font and nonterminals in italics. Literal characters are given in single quotes. Parentheses ( and ) indicate grouping when needed. Square brackets [ and ] enclose optional items. Vertical bars | separate alternatives.

    

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

            

            

        

    

graph	:	[ strict ] (graph | digraph) [ ID ] ‘{‘ stmt_list ‘}’
stmt_list	:	[ stmt [ ‘;’ ] [ stmt_list ] ]
stmt	:	node_stmt
	|	edge_stmt
	|	attr_stmt
	|	ID ‘=’ ID
	|	subgraph
attr_stmt	:	(graph | node | edge) attr_list
attr_list	:	‘[‘ [ a_list ] ‘]’ [ attr_list ]
a_list	:	ID [ ‘=’ ID ] [ ‘,’ ] [ a_list ]
edge_stmt	:	(node_id | subgraph) edgeRHS [ attr_list ]
edgeRHS	:	edgeop (node_id | subgraph) [ edgeRHS ]
node_stmt	:	node_id [ attr_list ]
node_id	:	ID [ port ]
port	:	‘:’ ID [ ‘:’ compass_pt ]
	|	‘:’ compass_pt
subgraph	:	[ subgraph [ ID ] ] ‘{‘ stmt_list ‘}’
compass_pt	:	(n | ne | e | se | s | sw | w | nw | c | _)

The keywords node, edge, graph, digraph, subgraph, and strict are case-independent. Note also that the allowed compass point values are not keywords, so these strings can be used elsewhere as ordinary identifiers and, conversely, the parser will actually accept any identifier.

An ID is one of the following:  

Any string of alphabetic ([a-zA-Z'200-'377]) characters, underscores ('_') or digits ([0-9]), not beginning with a digit;

a numeral [-]^?(.[0–9]⁺  | [0–9]⁺(.[0–9]^*)^? );  

any double-quoted string ("…") possibly containing escaped  quotes (‘")¹;

an HTML string (<…>).

An ID is just a string; the lack of quote characters in the first two forms is just for simplicity. There is no semantic difference between abc_2 and "abc_2", or between 2.34 and  "2.34". Obviously, to use a keyword as an ID, it must be quoted. Note that, in HTML strings, angle brackets must occur in matched pairs, and unescaped newlines are allowed. In addition, the content must be legal XML, so that the special XML escape sequences for ", &, <, and > may be necessary in order to embed these characters in attribute values or raw text.

Both quoted strings and HTML strings are scanned as a unit, so any embedded comments will be treated as part of the strings.

An edgeop is -> in directed graphs and -- in undirected graphs.

An a_list clause of the form ID is equivalent to ID=true.

The language supports C++-style comments: /* */ and //. In addition, a line beginning with a ‘#’ character is considered a line output from a C preprocessor (e.g., #  34 to indicate line 34 ) and discarded.

Semicolons aid readability but are not required except in the rare case that a named subgraph with no body immediately preceeds an anonymous subgraph, since the precedence rules cause this sequence to be parsed as a subgraph with a heading and a body. Also, any amount of whitespace may be inserted between terminals.

As another aid for readability, dot allows single logical lines to span multiple physical lines using the standard C convention of a backslash immediately preceding a newline character. In addition,  double-quoted strings can be concatenated using a ‘+’ operator. As HTML strings can contain newline characters, they do not support the concatenation operator.

Subgraphs and Clusters

Subgraphs play three roles in Graphviz. First, a subgraph can be used to  represent graph structure, indicating that certain nodes and edges should  be grouped together. This is the usual role for subgraphs  and typically specifies semantic information about the graph components.

In the second role, a subgraph can provide a context for setting attributes. For example, a subgraph could specify that blue  is the default color for all nodes defined in it.  In the context of  graph drawing, a more interesting example is:  

This (anonymous) subgraph specifies that the nodes A, B and C  should all be placed on the same rank if drawn using dot.

The third role for subgraphs directly involves how the graph will be laid out by certain layout engines. If the name of  the subgraph begins with cluster, Graphviz notes the subgraph as  a special cluster subgraph. If supported, the layout engine will  do the layout so that the nodes belonging to the cluster are drawn together,  with the entire drawing of the cluster contained within a bounding rectangle.  Note that, for good and bad, cluster subgraphs are not part of the DOT language, but solely a syntactic convention adhered to by certain of the layout engines.

Lexical and Semantic Notes

If a default attribute is defined using a node,  edge, or  graph statement, or by an attribute assignment not attached to a node or edge, any object of the appropriate type defined afterwards will inherit this attribute value. This holds until the default attribute is set to a new value, from which point the new value is used. Objects defined before a default attribute is set will have an empty string value attached to the attribute once the default attribute definition is made.

Note, in particular, that a subgraph receives the attribute settings of its parent graph at the time of its definition. This can be useful; for example, one can assign a font to the root graph and all subgraphs will also use the font. For some attributes, however, this property is undesirable. If one attaches a label to the root graph, it is probably not the desired effect to have the label used by all subgraphs. Rather than listing the graph attribute at the top of the graph, and the resetting the attribute as needed in the subgraphs, one can simple defer the attribute definition if the graph until the appropriate subgraphs have been defined.

If an edge belongs to a cluster, its endpoints belong to that cluster. Thus, where you put an edge can effect a layout, as clusters are sometimes laid out recursively.

There are certain restrictions on subgraphs and clusters. First, at present, the names of a graph and it subgraphs share the same namespace. Thus, each subgraph must have a unique name. Second, although nodes can belong to any number of subgraphs, it is assumed clusters form a strict hierarchy when viewed as subsets of nodes and edges.

Character encodings

The DOT language assumes at least the ascii character set. Quoted strings, both ordinary and HTML-like, may contain non-ascii characters. In most cases, these strings are uninterpreted: they simply serve as unique identifiers or values passed through untouched. Labels, however, are meant to be displayed, which requires that the software be able to compute the size of the text and determine the appropriate glyphs.  For this, it needs to know what character encoding is used.

By default, DOT assumes the UTF-8 character encoding. It also accepts the Latin1 (ISO-8859-1) character set, assuming the input graph uses the charset attribute to  specify this. For graphs using other character sets, there are usually programs, such as iconv, which will translate from one character set to another.

Another way to avoid non-ascii characters in labels is to use HTML entities for special characters. During label evaluation, these entities are translated into the underlying character. This table shows the supported entities, with their Unicode value, a typical glyph, and the HTML entity name. Thus, to include a lower-case Greek beta into a string, one can use the ascii sequence &beta;.  In general, one should only use entities that are allowed in the output character set, and for which there is a glyph in the font.