标签：
延迟简单地说，它是一种转移或信息包从起点到终点，所花费的时间。
延迟=发送延迟+传播延迟+处理延迟+排队延迟：
Propagation delay 传播时延
传播时延这个概念。是指电磁信号或者光信号在传输介质中传输的时延。而在光纤或者铜线中。光信号和电磁信号的传播速度都在20万公里/秒以上，在传输介质中传输的是电磁信号或者光信号，而不是数据！
Transmission delay 传送时延
发送时延是指结点在发送数据时使数据块从结点进入到传输媒体所需的时间，也就是从数据块的第一个比特開始发送算起，到最后一个比特发送完成所需的时间。
发送时延又称为传输时延
Processing delay 处理时延
处理数据包的头部。校对位错误， 并确定数据包要传输的方向
Queuing delay 排队时延
数据包等待处理的时间
总的时延是从client到server全部时延的总各。Propagation 时间是由两者之间的距离和传播的介质(光纤或铜线)决定。
还有一方面。Transmission delay 是由两者建立起来传输链接的传输速率决定的，跟两者之者的距离没有关系。 举例来说， 如果我们分别在1Mb的链接和100Mb的链接，传递一个10Mb的文件。 前者的时间为10秒，而100Mbps时，仅仅需花费0.1秒。
下一步。 当数据包到达一个路由器。 路由器必需检測数据包的头，从而决定下一个路由。 同一时候还须要对数据进行校验， 全部的这些逻辑都是在路由器硬件上完毕。所以Processing delay是很小的， 但它也确时存在。 最后来讲讲Queuing delay. 当数据包从较快的传速速率（光钎）到一个100MB的路由器。这就常过了路由器的处理速度， 那么这个数据包就须要进入到缓存区提排队。 这个排队时间。就是Queuing Delay.
光速是299, 792, 458米每秒， 但光速在介质中传播会有能量损耗， 这仅仅是一个理论的值。通过下面图表，能够清楚的了解光纤实际的速度和造成的Propagation 延时
| 路径 | 距离 | 真空光速延时 | 光纤延时 | 光纤信号往返时间 |
|---|---|---|---|---|
| New York to San Francisco | 4,148 km | 14 ms | 21 ms | 42 ms |
| New York to London | 5,585 km | 19 ms | 28 ms | 56 ms |
| New York to Sydney(悉尼) | 15,993 km | 53 ms | 80 ms | 160 ms |
| 绕赤道一周 | 40,075 km | 133.7 ms | 200 ms | 200 ms |
光纤上的传输速度是挺快的， 但从纽约到悉尼还是花费了160毫秒. 这也不过理论上的值（两个城市是直接通过光纤相连）， 实际上数据包会经过不同的路径（悉尼到旧金山， 在到纽约等等）。经理的路径越多，就会引入很多其它的处理延时。等待延时， 传输延时。终于RTT(Round-trip time)将达到 200 - 300ms.
通常100-200ms是正常的值， 假设超过了300ms, 那么整个交互就变慢了. 能够使用Content delivery network(CDN), 将server的资料缓存在离client近期的server。 降低两者之者的距离.
互联网由两个重要的协议组成，IP 和 TCP. IP(Internet Protocol) 提供了通信两方之间的路由以及寻址，它仅仅管发送数据。而不保证数据是否完速的传送到了接收端。TCP(Transmission Control Protocal), 提供了在不可靠的通道上。建立一个抽像的可靠网络。
TCP 提供了一个可靠的抽像网络。
它向应用程序隐藏了复杂的网络通信细节： 重发丢失的数据。 按序发送。拥塞控制。 数据的完整性等。 当你使用TCP时。你能够保证发送和接受到的数据是一样的，并且顺序也是一样的。 所以TCP是保证准确传输最佳化的协议。
TCP 并非 HTTP唯一的传送协议。 HTTP也能够建立在用户数据报协议(User Datagram Protocal) 或者 UDP, 也能够选择其他传送协议。 但在实际中， HTTP在互联网的通信都是通过 TCP。
所以理解TCP的核心执行原理，是我们优化web性能的基础知识。
全部的TCP都是从三次握手開始。 在client或者server交换随意应用数据之前，它们必须先建立连接，确认数据包的序列号， 以及其他用于连接的特殊变量。 因为安全原因，序列号是从两方中随机挑选。
SYN
client会挑选出一个数字序列号 X, 而且发送一个SYN 数据包(包括额外的TCP 标记和选项)
SYN ACK
server接受到 syn 包， 在序列号X上加1. 而且挑选一个序列号Y, 并附上它自己的标记和选项。 并响应这个数据包
ACK
client对x, y 加1 ， 并发回ACK包， 完毕握手。
图1-1
当三次握手完毕， 应用层数据就能够在client和server之间传送。 client能够在ACK 包发送完后马上传送数据包。 但server必须在接受到ACK包之后，才干够。
整个的启动过程(三次握手) 。 每个TCP连接都须要进行， 所以对于使用TCP的应用程序。 这个过程会很重要： 每个新的连接在传输数据之前都会有一个响应延时。
举一个样例， 假设我们的client在New York, 但server是在London, TCP连接是建立在光纤上的， 三次握手将至少花费56 毫秒(client能够在第三次ACK后，马上数据传输): 28ms 是一个方向的Propogation delay.
三次握手产生的延时，使得建立新的TCP连接是昂贵的， 这也是为什么在使用TCP时。须要对已有连接进行重要最大的原因之中的一个.
这时你的朋友用你家的网络下载一个软件。 但这里你家的网络带宽已经很少了，所以 video server必须调速它的数据传送率。 否则，如果它还是以同样的速度传送的话，数据仅仅会仅仅简单的堆积在某个中间网关，而且数据包将会被丢弃。导致网络的低效利用。
非常快这四个算法成为了TCP规范中的强制部分。
首先经历三次握手， 在此其间。双方都通过ACK包，向对方告知自己的 receive window(rwnd)的大小。 一旦后一个ACK包进入网线。我们就能够交换应用数据。
一開始， server初始化每个TCP连接 初始化一个 congestion window(cwnd 拥塞窗体)， 而且保守的设置一个初始值 （由Linux系统指定大小).
client和server都是在三次握手后，发送第一个数据包时。 初始化1MSS.
比方浏览器(图1-1的第二步。 y+1, x+1 后就能够发送数据了， 那么此时浏览器的cwnd 为 1MSS, 在一个RTT时间内，收到带ACKed的数据包后，会添加1个MSS. 能够发送两个数据包了。）
而server要在接到收到浏览器的ACK包后，才干够发送数据， 它的cwnd 为1MSS, 在下一次接收到client的ACKed包后，会添加1MSS.
我们不能直接将合适的流量应用到每个连接。
每个新建的TCP连接的吞吐量都被限制为 cwnd的大小。 实际上， 要达到64 KB的限制， 我们将添加cwnd的大小为45 MSS, 这须要花费244毫秒：
比如， 将server布置到离client更进的位置。 或者。我们能够添加初始的 cwnd的大小 到 10 MSS (RFC 6928).
对于视频以及大型文件来说， Slow-start不是特别大的问题。 但对于非常多短的和突发的http来说。 由于它限制了带宽吞吐量的能力（高带宽，但使用不上). 这就会对性能造成影响。
为了了解三次握手和慢启动对http请求造成的影响，我们如果 New York的客户 从 London的server请求一个20 KB的文件。新的TCP连接。如图 2-5所看到的。
图2-5
0 ms Client 通过SYN包，进行TCP第一次握手
28ms server返回一个SYN-ACK, 而且有指定 rwnd 大小
56ms Client 发送一个对SYN-ACK所的确认包。 并指定 自已的 rwnd大小， 并马上发送一个 HTTP GET 请求
84ms server接受 HTTP request, 并花 40 ms处理
124ms server完毕，并产生一个20kb的响应， 而且发送4 TCP segments的数据(5480 bytes), 并暂停，等待client返回一个 ACK包
152ms client接收到 4 个片段的数据。 并确认每一段数据, 并返回一个ACKed 包。
180ms server添加cwnd的值， 并发送8 个数据段
208ms client接收到 8个数据段。并确认每一段数据
236ms server添加每一个ACK 包的 cwnd, 并发送剩余的数据段
264ms client接收剩余数据段，并返回每个段的ACKs包
在一个新的TCP传递一个20KB的数据, 花费了264ms . 让我们对照一下，重用同样的TCP连接, 并请求同样的内容
图2-6
0 ms client发送请求
28ms server接收到请求
68ms server处理完请求。并生成20KB的响应。可是当前的cwnd为15 segments, 因此能够一次性发送完20KB的数据
96ms client接收到15个数据段。并ACKs 它们
同样同样的请求在同样的连接上（除了三次握手）。 性能上提升了275%;
在这两个样例中， 5 Mbps的带宽没有对性能产生不论什么影响，基本的影响因素是拥塞窗体大小。
从慢启动能够看到，cwnd能够非常快的增长上来（2的N次方)。从而最大程度利用网络带宽资源，可是cwnd不能一直这样无限增长下去，一定须要某个限制。TCP使用了一个叫慢启动门限(ssthresh)的变量。当cwnd超过该值后，慢启动过程结束，进入拥塞避免阶段, 或者发生了丢包现像。也会进入到拥塞避免阶段. （http://www.cnblogs.com/fll/archive/2008/06/10/1217013.html）
TCP 通过拥塞控制和拥塞避免，调整拥塞窗体的大小， 以免在网络中发生丢包。
TCP 内制的拥塞控制和拥塞避免带来了还有一个重要的性能优化： 发生者和接收者最佳值，这取决于RTT 和 两者之前的带宽（ data rate）
我们回顾一下之前内容。 在发送者和接收者之间传送中的数据大小（unacknowledged)，取决于 rwnd 和 cwnd 中最小的一个。
rwnd 的大小每次都会出如今ACK包中（固定), 而 cwnd 根据发送者的拥塞控制和拥塞避免。动态调整的。
假设发生者 或 接收者 超过了最大的unacknowledged data（未确认数据)， 它必须停下来，等待其他之前发送过的包的确认信息(ACK). 那么它须要等待多久呢？ 这取决于两者之者的响应时间RTT.
Bandwidth-Delay Product
数据链路上带宽与 end-to-end 之间的延时乘积。 它所表示的是。 任一时间点， 能够发送的最大 未确认(unacknowledged）的数据.
sender 或 receiver 在停下来等待之前发送的包确认信息, 就会有一段时间空隙（data gap), 在这段空隙内。发送端是不能在发送数据的。
为了解决问题， 窗体的大小就须要调整到足够大。 这样服sender在接受到receiver 返回的ACK包之前，也能够继续发送数据。 这样就没有gaps。
因此最优的窗体大小依赖于 Round-trip time (RTT). 当窗体比較小的时候， 你将会限制连接的吞吐量。
这包含基础包的错误检察和改动， 按序发送， 重发丢失的包， 以及流量控制， 拥塞控制 和拥塞避免（保证网络资源的最有效利用). 所以非常多应用都是使用TCP.
这就是 TCP head-of-line(HOL) blocking（线头堵塞）
线头堵塞使我们的应用程序避免了对数据包进行又一次排序。 使得应用程序代码easy编写。
但是。 这会引入不确定的延时，以等待丢失的数据包重发。
这样的延时能够称为 （jjitter， http://blog.csdn.net/junllee/article/details/6110912) 。这影响到程序的性能。
并且， 有的应用程序能够忍受数据包丢失： audio, video , 游戏状态更新。
它们都不须要可靠和有序的数据传递。 顺便说一样， 这也是什么WebRTC(网页实时通信（)是基于UDP作为传输协议的原因.
假设一个包丢失。 视频解码器会简单的在视频中插入一小段空白， 并继续处理之后的处据包。 假设这个空隙很小。视频解码都不会通知使用者，这样就不用在视频输出的时候。 以暂停的方式等待丢失的包。
相同的。假设我们正在传递的数据是 3D游戏中一个角色的状态更新， 这时我们等待的数据是用来描写叙述 T-1 时间点的状态。 而T时间点的数据包已经接收。那么T-1 秒的数据包就是不须要的了。 理想的是，我们能够接收到每个状态更新。 可是为了保证游戏的不发生延迟。 我们能够接爱间歇性的丢包。 以保证较低的延迟.
尽管每个TCP算法都有自已特定的细节，并继续发展出不同的反馈(feedback)机制，但核心的原理依旧同样， 这些原理导致的性能问题也没有改变:
因此， 每一个tcp 连接在现代化的快速网络下，传送数据的速率也是受限于 发送者和接受者之间的 roundtrip 时间的影响（能够看看带宽拖延积）。或者这么解释， 尽管能够无限制的添加带宽， 採用光速传送数据，从New York 到 London的拖延还是有28ms. 在非常多情况下，TCP的瓶颈不是带宽的大小。而是延迟的大小。 能够查看图2-5.
同一时候意味着它能够加速window的增长。 特别是 在优化突发性。短连接中起来决定性的作用。
这就是TLS1.0, 它实际上是SSL 3.0的一个升级。
MAC算法是一种单向加密散列函数， 它的key 是通信两方协商 的一个结果(session key) , 能够查看http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html 。 每当TLS record 要发送， 就会产生一个MAC值， 并附加在消息的后面。这样接收者，就能够计算和校验发送过的值， 以确保消息的完整性和身份认证。 (简单点说，密文通过MAC算法，基于session key 生成密文的校验值。 并把这个校验值一起发送到接收端，接收端使用MAC算法和同样的session key 对接到的信息生成校验值。并对照是否一样。就能保证消息的一致性)
并附上自己的证书， 发回一个响应给client。 在这里，另一些可选项。 server也能够要求客户商提供证书， 以及扩展TLS的參数
到眼下为此。全部交换过的数据都是以明文的方式进行， 除了新的对称密钥。 是使用server的公共密钥进行了加密。
另外，你能够选择一种简单的握手， 它仅仅需一次往返。 能够查看 55页的 ”TLS Session Resumption"
能够直接通过port进行确定, e.g HTTP使用 80port。 TLS 使用 443port。 全部的client和server都是使用的这些公认的port。但在实际中。通过port来配匹配应用层协议是不可靠的，每个port都须要由系统开发。 并且防火墙和其他的中间机构仅仅同意 80 和 443port的信息通过。
但是。 使用TLS 攻克了可靠性的问题， 我们依旧须要有一种方法。协商新的应用层协议。
但在很多老的client并不支持SNI, 比方执行在 Windows XP的浏览器, Android 2.2 等。
在全部使用安全通信的应用程序中， 握手阶段导致了额外的延迟和CPU计算， 严重的影响了应用程序的性能。为了减小同样的浪费， TLS 提供了在多个连接中。共用同样的安全密钥（生成的对称密钥）的能力。
会话标识重用是在SSL 2.0版本号被引入， 它充许server创建并发送 32 字节的会话标识，作为 ”ServerHello" 消息的一部份。
在server内部，它须要为每个client缓存 session ID 以及TLS连接參数 （key, 加密算法）。 相同。 client也须要保存sessionID 信息， 而且在下次的TLS请求中, 在ClientHello 消息中带上sessionID. 当server收到sessionID时， 就知道client依旧保存了之前加密套件和 从上次握手所获得的 对称密钥。如图 4-3所看到的。 一个简短的握手过程。
假设两方没有从缓存在找到之前的信息，那么将会产生一个新的 session ID.
图4-3 简短的握手过程
利用会话标识。让我们减小了一个RTT时间。 以及计算开销。
但是，在实际的工作中。使用server创建和保存session 标识符 具有局限性。 比方每天都会有成千上万的连接须要保存到缓存，这会导致缓存被使用完成， 有的站点是採用多个server，假设共享这些session也是一个问题。
(session 保存在server会带来哪些实际问题，能够查看 http://nil-zhang.iteye.com/blog/1279214)
取代的是， 假设client表明。它支持 Session Tickets, 在 TLS 握手的最后。 server会包括进一个新的 Session Ticket record. 这个记录包括了全部会话数据， 而且会以server才知道的安全密解加密。
会话船票会保存在client。 在之后的连接中，会以 SessionTick 扩展，包括进ClientHello 信息中。 这样全部的信息就仅保存在client。 并且 ticket 依旧是安全的， 由于它是使用server才知道的密钥加密的。
session indentifiers 和 session ticket 机制能够分别称为 会话缓存 和 无状态恢复。 无状态恢复的最大改进是不须要server端缓存。 client仅仅需在新的连接中提供 session ticket， 除非ticket 已经过期。
我们如何才干知道，在建立加密遂道是我们信任的一方，而不是一个攻击者， 所以身份证认证在TLS 连接中是不可切割的一部分。为了知道如何验证两方的身份， 我们举了在 Alice 和 Bob 之间的一个样例:
信任是交换数据之前的关键， 公钥加密算法，同意我们使用信息发送者的公共密钥， 确认被签名的信息是正确人发送过来的。
但这样的信任全然是基于 Alice 和 Bob 相互认识的基础上。才交换的公共密钥。
下一步， Alice 从Clarlie那里接收到一条信息， Alice 没有见过Clarlie, 但Clarlie 声称它是 Bob‘s 的朋友。
实际上， Clarlie 为了证明自己是Bob的朋友。 Clarlie 要求Bob 对自己的公开密钥 使用 Bob 的私有密钥进行签时。 并以消息的附件，一起发送给Alice. 如图4-4. 在这样的情况下， Alice 首先确认 Clarlie的公共密钥中Bob的签名。 她已经有了Bob 的公开密钥， 所以知道Clarlie 的公开密钥的确是由 Bob签过的。Alice
接受了这条消息。 并使用消息中的Clarlie 公开密钥， 确证发送条消息的人确实是Clarlie.
图4-4
在实际中，你不可能存放全部站点的证书。因此最通用的解决方法是使用CAs来帮我们进行校验. 如图 4-5. 站点会让认证中心对他的名字和公钥进行签名，并将这个签名发送到浏览器。假设浏览器的CAs的根文件夹下。有认证中心的公开密钥，就能确认这个站点是真实的。
不重要。忽略
不同于IP 或者 TCP协议， 在TLS会话中的全部数据交换都是由TSL Record协议负责。 该协议须要负责识别不同类型的消息（握手信息，警告，数据）， 并校对每个信息的完整性。
图 4-8 TLS record 结构
传递应用程序的数据的流程例如以下：
完毕以上步聚， 被加密的数据就会向下传入TCP层，进行传输。 在接收端， 则是相反的过程。
这个过程看起来非常easy。但须要注间几个地方：
为你的应用程序挑选出最佳的record 的大小。对性能的优化非常重要，小的records 会导致非常大的开销, 然而大的records 会被TCP又一次进行组装
TLS的优化主要是配置你的server，比方TLS records 的大小。 内存缓冲区， 证书的大小， 是否支持简短的握手等等， 通过对这些參数的正确配置，会明显改善用户体验，减少操作开销。
但如今的硬件的性能有非常大的提升。都能直接完毕
但对于TLS Session 的恢复。 还是能够降低使用公钥加密。 除低计算的开销。
无论是新建还是重用一个连接，都会有延迟的发生。 对于优化来说。 连接的建立是一个重要的区域。
我们看看一个TLS连接有哪些: TCP 三次握手， 之后是TLS握手， 添加两个RTT时间(新建)。
或者一个RTT（重用）。
在最坏的情况下，数据交换之前， TCP 和 TLS连接的设置过程就将花费三个 RTT. 以我们之前New York到London的样例， 一个RTT 时间为56ms, 那么新建一个TLS 将花费168ms, 而重用一个将花费112ms.
由于TLS是执行在TCP之上。所以对TCP的优化。也适用于这里。 通过CDN将server位置到离client近期的地方，减小RTT的值。
CDN不仅能够优化静态资源。你也能够应用动态内容上，提前终止TLS 会话。 如图 4-9所看到的，在本地代理server上，建立与client的连接（加速完毕握手），代理server与原始server之间建立一个长久(没有握手。仅仅负责数据传送)，加密的连接。
这样全部的请求和响应都是从原server获取
图4-9 提前终止client连接
要做到这一点非常easy，非常多CDN都提供这种服务。 你也喜欢冒险。也能够以最小的花费搭建自己的基础设施： 在全球各地的数据中心部署云server，并配置代理server，将请求转发到你的原始server中。
并能够增加基于地理位置的DNS 负载均衡。
假设一个记录刚好能够装入一个 TCP数据包， 我们还须要加入IP 和 TCP的信息， 比方 IP会有20字节的头部信息， TCP也会有20字节的头部信息。
终于， 每个记录大概会加入60-100字节的头部信息。
电路中一个标准的最大传输单位(MTU) 大小是1500 字节。 数据包的结构就占领了 6% 的大小(overhead，在计算机网络的帧结构中，除了实用数据以外，还有非常多控制信息，这些控制信息用来保证通信的完毕。
这些控制信息被称作系统开销).
但是，简单的添加记录的值，使它达到最大同意传递的16KB, 这也不是一个非常好的方法。 假设一个record 非常大，它会被分装进多个TCP 数据包。 则TLS的还有一端必须等待全部的TCP包到达之后才干够对数据进行解码（如图4-10)。
假设某些TCP数据包丢失， 还须要重传， 造成额外的延迟。
在实际中， 这样的延迟对于浏览器造成非常大的延迟, 还不如对数据一个字节一个字节的传递， 这样还可能会更快。
对应的，传送可用数据越少意味着传送的数据要很多其它的数据包。
这还意味着完毕传输数据须要额外的时间。
假设是大的records 又会引发延迟的发生。 这里非常难找到一个“正确” 的 record大小。 还好。浏览器会自己主动将web应用程序的值，设置为TCP MSS的大小，即records 值为 一个MSS(1460 bytes). 这种个TCP数据包传递一个record。 这样一个record就能够分配到多个TCP 数中包其中。
通过下面的方式。我们能计算出一个最佳的record：
MTU通用的大小为1500 bytes, 那么在IPv4中 TLS record 大小就是1420 （1500- IP 20 - TCP 20 - TCP Option 40), 而对于IPv6,这个大小为1400. 为了兼容未来。 所以最佳的值为1400.
而是须要通过server级别的配置，详细方法，须要查看server系统文档。
假设你的server须要处理大量的TLS 连接，则须要为每一个连接分配最小的内存使用。
OpenSSL 一般会为每一个连接分配50KB 的内存， 但正如调整record 大小一样，不妨查看OpenSSL 的文档。 Google的server能常将OpenSSL的值设置为5KB.
TLS 内部通过 record协议。 支持对传输的数据进行无损压缩： 压缩的算法是通过握手协议。两方协商好的。 压缩会发生在对每条record 加密之前。
但通常，你要禁止server的压TLS 压缩功能， 有下面几个原因:
两次的压缩，会浪费server和client的CPU, 并且导致非常严重的安全问题， 尽管非常多的浏览器禁用了TLS 压缩。但为了更好的保护你的客户。 你须要明白的禁止server压缩.
浏览器验证证书的过程是： 从站点的证书開始， 在遍历父证书。 直到信任的根文件夹( 证书是分级的，全球。 国家， 省份). 因此。第一条优化的原则是，在server上配置全部的中级证书。 假设忘记了， 那么很多浏览器依旧能够工作，可是它会暂停。 等待， 并向中间证书的server。 获取中间证书。 然后继续验证。直至根文件夹信任的证书。 这过程中会有新的DNS 查询， TCP连接。 和 HTTP GET请求。 会有数百毫秒的握手延迟。
但是浏览器怎么知道怎样获取中间证书的呢？ 每个子证书通常都包括了父证书的URL
相反的， 你必须在你的信任链里不会包括不是必需的证书， 或者通俗点说， 你应该降低信任链的大小。
回顾一下。 server在TLS 握手期间。 会向client发送证书， 非常有可能证书的发送是在发生在新TCP连接的slow-start 阶段。
假设证书链的大小超过了TCP 初始 cwnd 的大小， 则仅仅能先发送一部份（TCP cwnd大小）。 等待client的 ACK后，在发送剩下的部分， 这就会导致多个RTT时间。
如图 4-11
图4-11 WireShack 软件截图 TLS 证书链的大小为 5, 323-byte
图4-11中， 证书链超过了5KB的大小，它超过了一些的老的server的拥塞窗体的大小。这就在握手阶段引入了其他RTT的大小。有一个解决方式是添加初始的拥塞窗体的大小。 能够查看 "Increasing TCP‘s Initial Congestion Window " 原书 26页。
另外。 你也能够降低证书的大小：
以证实证书是否吊销。所以我们能够在server 发送一个请求到认证中心的响应，而且把它包括（装订）到认识链中（部分浏览器能够识别）。 这样我们自己的server就能够缓存被签名过的OCSP响应。能够节省多个client的额外请求。
但这里也须要注意一些问题：
近期。你须要在配置server。同意有OCSP装订的功能。 好的消息是，主流的server。 比方Nginx, Apache, IIS是有这个功能的。 你能够查看这些server的文档说明。
HTTP Strict Transport Security 是一个安全策略机制， 它同意server通过简单的HTTP 头， 比方 Strict-Transport-Security: max-age = 3153600. 向顺从的浏览器（知道这类http头的浏览器) 声明訪问规则。
这条规则表示，client必须强制运行下面规则：
HSTS 不仅能够将原始连接转变为 HTTPS, 还能够保护应程序。 在性能上, 能够减小从 HTTP-to-HTTS的跳转（301 或者302）。
在2013年时。 支持HSTS的浏览器有 Firefox 4+, Chrome 4+, Opera 12+ 以及Android 版的Chrome 和 Firefox. 最新的了解能够查看 caniuse.com/stricttransportsecurity.
最后， 检验和測试你的配置。 你能够使用在线的服务， 比方 Qualys SSL Server Test 扫描你公开的server的通用配置 和安全缺陷。 另外，你也能够使用 openssl 命令， 它将帮助你检验整个握手过程和本地的server配置
$> openssl s_client -state -CAfile startssl.ca.crt -connect igvita.com:443 CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing /CN=StartCom Certification Authority verify return:1 depth=1 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing /CN=StartCom Class 1 Primary Intermediate Server CA verify return:1 depth=0 /description=ABjQuqt3nPv7ebEG/C=US /CN=www.igvita.com/emailAddress=ilya@igvita.com verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A --- Certificate chain 0 s:/description=ABjQuqt3nPv7ebEG/C=US /CN=www.igvita.com/emailAddress=ilya@igvita.com i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing /CN=StartCom Class 1 Primary Intermediate Server CA 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing /CN=StartCom Class 1 Primary Intermediate Server CA i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing /CN=StartCom Certification Authority --- Server certificate -----BEGIN CERTIFICATE----- ... snip ... --- No client certificate CA names sent --- SSL handshake has read 3571 bytes and written 444 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-SHA Session-ID: 269349C84A4702EFA7 ... Session-ID-ctx: Master-Key: 1F5F5F33D50BE6228A ... Key-Arg : None Start Time: 1354037095 Timeout : 300 (sec) Verify return code: 0 (ok)
在此之样例中， 我们通过TLS的默认port(443) 连接到 igvita.com ， 并运行TLS 握手。 因为 s_client 不清楚root证书，我们须要手动将 StartSSL Certifiecate Authority 导入到根文件夹（很重要的一步） ， 否则 s_client 会看到一个校验失败的错误日志。
检測证书链的过程中，我们看到server发送了两个证书。 总的大小为3,571 bytes, 这是进军 3 至 4 分割 （TCP 老server初始拥塞窗口的大小 4 分割) 。终于， 我们检测磋商 SSL 变量 - 最新的协议。 加密演算法 ， 对称密钥 - 我们也可以看到server发送一斤session 马克。
High Performance Browser Networking - TCP UDP TLS
标签：
原文地址：http://www.cnblogs.com/yxwkf/p/4732723.html
