网站制作成品下载,wordpress首页生成在,濮阳,专业的做网站的注#xff1a;TCP/IP等知识牵涉面太广#xff0c;且不说本文#xff0c;哪怕是原书#xff0c;限于篇幅#xff0c;很多知识点都是大致介绍下。如果想深入理解#xff0c;需要更一步Google相关页面资料。
延迟与带宽
WPO#xff0c;Web Performance Optimization…注TCP/IP等知识牵涉面太广且不说本文哪怕是原书限于篇幅很多知识点都是大致介绍下。如果想深入理解需要更一步Google相关页面资料。
延迟与带宽
WPOWeb Performance OptimizationWeb性能优化。
对所有网络通信都有决定性影响的两个方面
延迟分组从信息源发送到目的地所需的时间带宽逻辑或物理通信路径最大的吞吐量。
路由器负责在客户端和服务器之间转发消息的设备牵涉影响延迟的4大因素
传播延迟消息从发送端到接收端需要的时间是信号传播距离和速度的函数传输延迟把消息中的所有比特转移到链路中需要的时间是消息长度和链路速率的函数处理延迟处理分组首部、检查位错误及确定分组目标所需的时间排队延迟到来的分组排队等待处理的时间
以上延迟的时间总和就是客户端到服务器的总延迟时间
传播时间取决于距离和信号通过的媒介另外传播速度通常不超过光速传输延迟由传输链路的速率决定与客户端到服务器的距离无关分组(packet)到达路由器路由器必须检测分组的首部以确定出站路由并且还可能对数据进行检查。这些检查通常由硬件完成相应的延迟一般非常短但再短也还是存在分组到达的速度超过路由器的处理能力分组就要在入站缓冲区排队即排队时间。
每个分组在通过网络时都会遇到这样或那样的延迟。发送端与接收端的距离越远传播时间就越长。一路上经过的路由器越多每个分组的处理和传输延迟就越多。最后网络流量越拥挤分组在入站缓冲区中被延迟的可能性就越大。
CDNContent Delivery Network内容分发网络通过把内容部署在全球各地让用户从最近的服务器加载内容大幅降低传播分组的时间。
最后一公里问题延迟中相当大的一部分往往花在最后几公里而不是在横跨大洋或大陆时产生。
想提高上网速度那选择延迟最短的ISPInternet Service Provider物流服务提供商如电信移动是最关键的。
网络核心的带宽光纤通信通过波分复用WDMWavelength-Division Multiplexing技术光纤可以同时传输很多不同波长信道的光因而具有明显的带宽优势。一条光纤连接的总带宽等于每个信道的数据传输速率乘以可复用的信道数。
网络边缘的带宽用户可用带宽取决于客户端与目标服务器间最低容量连接相比于核心光纤通信非常小。Ookla运营的speedtest相信大家都用过。
高带宽和低延迟宽度已经足够性能优化重点是降低延迟。
拓展
Hibernia Express
华为与Hibernia Atlantic合作铺设的一条横跨大西洋连接伦敦和纽约的近5000km的海底光缆。唯一目的就是减少城市间的路由为金融交易商节省5ms延迟。只服务于金融机构耗资预计达4亿美元。即1ms延迟成本价是8000万美元。
Bufferbloat
缓冲区爆满Jim Gettys发明的术语表述排队延迟影响网络整体性能。
造成这个问题的原因主要是如今市面上的路由器都会配备很大的入站缓冲区以便不惜一切代价避免丢包分组。可是这种做法破坏TCP的拥塞预防机制(Congestion Avoidance)导致网络中产生较长且可变的延迟时间。
为解决这个问题有人提出新的CoDel主动队列管理算法且已经在Linux内核3.5以上版本中实现。
traceroute
Linux平台的网络诊断工具可以列出分组经过的路由节点以及它在IP网络中每一跳的延迟。为找到每一跳的节点它会向目标发送一系列分组每次发送时的跳数限制都会递增。在达到跳数限制时中间的节点会返回ICMP Time Exceeded消息traceroute根据这个消息可计算出每一跳的延迟。
Windows平台中对应的命令为tracert。
TCP构成
TCP负责在不可靠的传输信道之上提供可靠的抽象层向应用层隐藏大多数网络通信的复杂细节如丢包重发、按序发送、拥塞控制及避免、数据完整等。采用TCP数据流可以确保发送的所有字节能够完整地被接收到且到达客户端的顺序也一样。TCP的目标是精确传送并没过多顾及时间。
三次握手
在交换应用数据之前必须就起始分组序列号以及其他一些连接相关的细节达成一致。 出于安全考虑序列号由两端随机生成
SYNSynchronize Sequence Numbers同步序列编号。客户端选择一个随机序列号x并发送一个SYN分组其中可能还包括其他TCP标志和选项。SYN ACK服务器给x加1并选择自己的一个随机序列号y追加自己的标志和选项然后返回响应。ACK客户端给x和y加1并发送握手期间的最后一个ACK分组。
三次握手带来的延迟影响性能因此需要重用连接。
TFOTCP Fast OpenTCP快速打开致力于减少新建TCP连接带来的性能损失。Linux 3.7及之后的内核已经在客户端和服务器中支持TFO。
但是TFO只能在某些情况下有效
随同SYN分组一起发送的数据净荷有最大尺寸限制只能发送某些类型的HTTP请求由于依赖加密cookie只能应用于重复的连接。
拥塞预防及控制
拥塞崩溃可能是往返时间超过所有主机的最大中断间隔于是相应的主机会在网络中制造越来越多的数据报副本使得整个网络陷入瘫痪。最终所有交换节点的缓冲区都将被填满多出来的分组必须删掉。目前的分组往返时间已经设定为最大值。主机会把每个分组都发送好几次结果每个分组的某个副本会抵达目标。
ARPANETAdvanced Research Projects Agency Network高级研究计划局网络是现代互联网的前身是世界上第一个实际运行的分组交换网络。
流量控制
流量控制一种预防发送端过多向接收端发送数据的机制。否则接收端可能因为忙碌、负载重或缓冲区容量有限而无法处理。为实现流量控制TCP连接的每一方都要通告自己的接收窗口(rwnd)其中包含能够保存数据的缓冲区空间大小信息。 发送端和接收端的窗口都可能成为制约因素。为了缓解性能瓶颈每个ACK分组都会携带相应的最新rwnd值以便两端动态调整数据流速使之适应发送端和接收端的容量及处理能力。
窗口缩放TCP Window ScalingRFC 1323引入可把接收窗口大小由65535字节16位即 2 16 2^{16} 216提高到1G字节缩放TCP窗口是在三次握手期间完成的其中有一个值表示在将来的ACK中左移16位窗口字段的位数。
检查和启用窗口缩放选项的命令
sysctl net.ipv4.tcp_window_scaling
sysctl -w net.ipv4.tcp_window_scaling1慢启动
TODO
拥塞预防
慢启动以保守的窗口初始化连接随后的每次往返都会成倍提高传输的数据量直到超过接收端的流量控制窗口即系统配置的拥塞阈值(ssthresh)窗口或者有分组丢失为止此时拥塞预防算法介入。
拥塞预防算法把丢包作为网络拥塞的标志即路径中某个连接或路由器已经拥堵以至于必须采取删包措施。因此必须调整窗口大小以避免造成更多的包丢失从而保证网络畅通。
TCP比例降速 确定丢包恢复的最优方式并不容易。如果太激进那么间歇性的丢包就会对整个连接的吞吐量造成很大影响。而如果不够快那么还会继续造成更多分组丢失。
TCP最初使用AIMDMultiplicative Decrease and Additive Increase倍减加增算法即发生丢包时先将拥塞窗口减半然后每次往返再缓慢地给窗口增加一个固定的值。很多时候太过保守。
PRRProportional Rate Reduction比例降速RFC 6937规定的新算法其目标就是改进丢包后的恢复速度。Linux 3.2内核默认的拥塞预防算法。
带宽延迟积
发送端和接收端之间在途未确认的最大数据量取决于拥塞窗口(cwnd)和接收窗口(rwnd)的最小值。rwnd会随每次ACK一起发送而cwnd则由发送端根据拥塞控制和预防算法动态调整。
BDPBandwidth Delay Product带宽延迟积数据链路的容量与其端到端延迟的乘积。这个结果就是任意时刻处于在途未确认状态的最大数据量。
窗口大小的协商与调节由网络栈自动控制应该会自动调整。但事实上窗口大小有时候仍然是TCP性能的限制因素。
队首阻塞
TCP的HOLHead of Line队首阻塞每个TCP分组都会带着一个唯一的序列号被发出而所有分组必须按顺序传送到接收端。如果中途有一个分组没能到达接收端那后续分组必须保存在接收端的TCP缓冲区等待丢失的分组重发并到达接收端。这一切都发生在TCP层应用程序对TCP重发和缓冲区中排队的分组一无所知必须等待分组全部到达才能访问数据。在此之前应用程序只能在通过套接字读数据时感觉到延迟交付。 问题分组到达时间会存在无法预知的延迟变化被称为抖动。
无需按序交付数据或能够处理分组丢失的应用程序以及对延迟或抖动要求很高的应用程序最好选择UDP等协议。
丢包不一定是坏事。反而是让TCP达到最佳性能的关键。被删除的包恰恰是一种反馈机制能够让接收端和发送端各自调整速度以避免网络拥堵同时保持延迟最短。
很多应用程序可以容忍丢失一定数量的包。
TCP优化建议
TCP调优非常复杂但核心原理不变
TCP三次握手增加整整一次往返时间TCP慢启动将被应用到每个新连接TCP流量及拥塞控制会影响所有连接的吞吐量TCP的吞吐量由当前拥塞窗口大小控制。
服务器配置调优
升级服务器内核到最新版服务器配置最佳实践
增大TCP的初始拥塞窗口加大起始拥塞窗口可以让TCP在第一次往返就传输较多数据而随后的速度提升也会很明显。慢启动重启在连接空闲时禁用慢启动可以改善瞬时发送数据的长TCP连接的性能。窗口缩放RFC 1323启用窗口缩放可以增大最大接收窗口大小可以让高延迟的连接达到更好吞吐量。TFO在某些条件下允许在第一个SYN分组中发送应用程序数据。TFO是一种新的优化选项需要客户端和服务器共同支持。
应用程序行为调优
三点
再快也快不过什么也不用发送能少发就少发。启用压缩。不能让数据传输得更快但可以让它们传输的距离更短。重用TCP连接是提升性能的关键。
性能检查清单
包括但不限于
把服务器内核升级到最新版本Linux3.2确保cwnd大小为10禁用空闲后的慢启动确保启动窗口缩放减少传输冗余数据压缩要传输的数据把服务器放到离用户近的地方以减少往返时间尽最大可能重用已经建立的TCP连接。
UDP构成
User Datagram Protocol用户数据报协议。UDP的主要功能和亮点并不在于它引入什么特性而在于它忽略的那些特性因此也叫无Null协议。
数据报一个完整、独立的数据实体携带着从源节点到目的地节点的足够信息对这些节点间之前的数据交换和传输网络没有任何依赖
数据报(datagram)和分组(packet)
分组可以用来指代任何格式化的数据块数据报则通常只用来描述那些通过不可靠的服务传输的分组既不保证送达也不发送失败通知
无协议服务
IP层的主要任务就是按照地址从源主机向目标主机发送数据报。 IP层不保证消息可靠的交付也不发送失败通知实际上是把底层网络的不可靠性直接暴露给上一层。
上图是IPv4首部多大20字节作为对比看一下仅8字节的UDP首部 如上图UDP协议会用自己的分组结构封装用户消息只增加4个字段源端口、目标端口、分组长度和校验和。事实上UDP数据报中的源端口和校验和字段都是可选的。
UDP的无服务
不保证消息交付不确认不重传无超时。不保证交付顺序不设置包序号不重排不会发生队首阻塞。不跟踪连接状态不必建立连接或重启状态机。不需要拥塞控制不内置客户端或网络反馈机制。
UDP与网络地址转换器
NATNetwork Address Translator网络地址转换器RFC 1631规范提出的解决IPv4地址即将耗尽的临时性方案。在网络边缘加入NAT设备每个NAT设备负责维护一个表表中包含本地IP和端口到全球唯一外网IP和端口的映射。NAT设备背后的IP地址空间就可以在各种不同的网络中得到重用从而解决地址耗尽问题。
IANAInternet Assigned Numbers Authority因特网号码分配机构作为监管全球IP地址分配的机构为私有网络保留三段IP地址这些IP地址经常可以在NAT设备后面的内网中看到。为防止路由错误和引起不必要的麻烦不允许给外网计算机分配这些保留的私有IP地址。
连接状态超时
NAT转换的问题在于必须维护一份精确的路由表才能保证数据转发。NAT设备还被赋予删除转换记录的责任。为解决这个问题UDP路由记录会定时过期。引入一个双向keep-alive分组周期性地重置传输路径上所有NAT设备中转换记录的计时器。
NAT穿透
NAT问题内部客户端不知道外网IP地址只知道内网IP地址。NAT负责重写每个UDP分组中的源端口、地址以及IP分组中的源IP地址。如果客户端在应用数据中以其内网IP地址与外网主机通信连接必然失败。
为解决UDP与NAT的这种不搭配发明很多穿透技术(TURN、STUN、ICE)用于在UDP主机之间建立端到端的连接。
STUN、TURN与ICE
TODO
UDP优化建议
UDP省略的功能连接状态、握手、重发、重组、重排、拥塞控制、拥塞预防、流量控制甚至可选的错误检测。
如果要使用UDP协议则开发者需要按需增加功能。
RFC 5405文档对设计单播UDP应用程序给出的设计建议
必须容忍各种因特网路径条件应该控制传输速度应该对所有流量进行拥塞控制应该使用与TCP相近的带宽应该准备基于丢包的重发计数器应该不发送大于路径MTU的数据报应该处理数据报丢失、重复和重排应该足够稳定以支持2分钟以上的交付延迟应该支持IPv4 UDP校验和必须支持IPv6校验和可以在需要时使用keep-alive最小间隔15秒。
传输层安全
两个容易混淆的概念
SSLSecure Sockets Layer安全套接字层TLSTransport Layer Security传输层安全。
SSL 2.0是该协议第一个公开发布的版本但由于存在很多安全缺陷很快就被SSL 3.0取代。
IETF成立一个小组负责标准化SSL协议时将其改名为TLS其中RFC 2246诞生TLS 1.0是SSL 3.0的升级版。TLS 1.0和SSL 3.0的区别并不特别明显但这些区别会严重妨碍TLS 1.0与SSL 3.0之间的互操作性。IETF随后又发布TLS 1.1TLS 1.2版本。
RFC 6347引入的DTLSDatagram Transport Layer Security数据报传输层安全协议旨在给UDP增加TLS安全保障。
加密、身份验证与完整性
TLS协议的目标是为在它之上运行的应用提供三个基本服务
加密混淆数据的机制身份验证验证身份标识有效性的机制数据完整性检测消息是否被篡改或伪造的机制
TLS握手 TLS握手协议
TLS会话恢复
完整TLS握手会带来额外的延迟和计算量从而给所有依赖安全通信的应用造成严重的性能损失。为了挽回某些损失TLS提供恢复功能即在多个连接间共享协商后的安全密钥。
会话标识符
RFC 5246最早在SSL 2.0中引入Session Identifier会话标识符SI支持服务器创建32字节的SI并作为ServerHello消息的一部分发送。
如果客户端和服务器都可在各自缓存中找到共享的会话ID参数就能进行如下图所示的简短握手否则就要重新启动一次全新的会话协商生成新的会话ID。 借助SI可节省一次往返还可省去用于协商共享加密密钥的公钥加密计算。因为重用之前协商过的会话数据故连接是加密的且安全的。
每个打开的TLS连接都要占用内存对会话ID的缓存和清除策略需要精心设计。
会话记录单
RFC 5077提出Session Ticket会话记录单ST机制用于解决上述服务器会话缓存问题。
ST不用服务器保存每个客户端的会话状态。如果客户端表明其支持会话记录单则服务器可以在完整TLS握手的最后一次交换中添加一条新会话记录单(New Session Ticket)记录包含只有服务器知道的安全密钥加密过的所有会话数据。客户端将此ST保存起来在后续会话的ClientHello消息中包含在SessionTicket扩展中。所有会话数据只保存在客户端而由于数据被加密过且密钥只有服务器知道因此仍然是安全的。
上面两个RFC机制也被称为会话缓存或无状态恢复机制。优点是消除服务器端的缓存负担通过要求客户端在与服务器建立新连接时提供会话记录单简化部署除非记录单过期。
信任链与证书颁发机构
信任链信任的传递性。
证书颁发机构Certificate AuthorityCA被证书接受者拥有者和依赖证书的一方共同信任的第三方。
每个浏览器操作系统也是但不在本书讨论范围内都会内置一个可信任的CA根机构名单。通过浏览器到浏览器开发商再到CA的信任链传递可以把信任扩展至目标站点。
证书撤销
证书撤销证书更新或删除。
CRLCertificate Revocation List证书撤销名单RFC 5280规定的一种检查所有证书状态的机制即每个CA维护并定期发布已撤销证书的序列号名单。
CRL以文件形式分发定期更新可通过URL形式访问可缓存存在的问题
名单长文件大实时性不好。
OCSPOnline Certificate Status Protocol在线证书状态协议RFC 2560为解决CRL上述问题而提供的一种实时检查证书状态的机制。占用带宽更少支持实时验证。
OCSP的问题
CA作为一个服务必须保证高可用且能接受并处理客户端的实时查询客户端在进一步协商之前阻塞OCSP请求CA知道客户端要访问哪个站点OCSP请求可能会泄露客户端的隐私。
实践中两者结合CRLOCSP。
TLS记录协议
TLS会话中交换的所有数据同样使用规格明确的协议进行分帧 TLS记录协议负责识别不同的消息类型握手、警告或数据通过内容类型字段以及每条消息的安全和完整性验证。
发送端交付应用数据的典型流程
记录协议接收应用数据接收到的数据被切分为块最大为每条记录214字节即16KB压缩应用数据可选添加MACMessage Authentication Code或HMAC使用商定的加密套件加密数据。
接收端的流程相同顺序相反。
记录协议的限制
TLS记录最大为16KB每条记录包含5字节的首部、MAC不同版本字节数不一样最多32字节如果使用块加密则还有填充必须接收到整条记录才能开始解密和验证。
小记录会因记录分帧而产生较大开销大记录在被TLS层处理并交付应用前必须通过TCP传输和重新组装。
TLS优化建议
计算成本
建立和维护加密信道给两端带来额外的计算复杂度公钥非对称加密与对称加密相比在握手期间确定共享密钥作为对后续TLS记录加密的对称密钥因此需要更大的计算工作量。
在Web发展早期通常都需要专门的硬件来进行SSL卸载。如今通过CPU就能完成。
另外升级OpenSSL库到最新版系统自带的默认OpenSSL库大概率已经过时。
尽早完成握手
会话缓存与无状态恢复
TLS记录大小
TLS压缩
TLS内置支持对记录协议传输的数据进行无损压缩。压缩算法在TLS握手期间商定压缩操作在对记录加密之前执行。
但是实践中往往需要禁用服务器上的TLS压缩功能
CRIME攻击会利用TLS压缩恢复加密认证cookie让攻击者实施会话劫持传输级的TLS压缩不关心内容可能会再次压缩已经压缩过的数据图像、视频等。
双重压缩会浪费服务器和客户端的CPU时间而且暴露的安全漏洞也很严重因此请禁用TLS压缩。实践中大多数浏览器会禁用TLS压缩但即便如此你也应该在服务器的配置中明确禁用它以保护用户的利益。
虽然不能使用TLS压缩但应该使用服务器的Gzip设置压缩所有文本资源同时对图像、音频、视频等采用最合适的压缩格式。
证书链长度
验证信任链需要浏览器遍历链条中的每个节点从站点证书开始递归验证父证书直至信任的根证书。
如果包含未验证的中间证书浏览器会暂停验证并获取中间证书验证后再继续。此时很可能需要进行新DNS查找、建立TCP连接、发送HTTP GET请求导致握手多花几百毫秒时间。
切记确保信任链中仅包含必要的证书即确保证书链的长度最小。
服务器证书是在握手期间发送的而发送证书使用的很可能是一个处于慢启动算法初始阶段的新TCP连接。如果证书链长度超过TCP的初始拥塞窗口则无意间就会让握手多一次往返证书长度超过拥塞窗口从而导致服务器停下来等待客户端的ACK消息。增大拥塞窗口或减小证书大小。
优化思路
尽量减少中间CA的数量。理想情况下发送的证书链应该只包含两个证书站点证书和中间CA的证书。把这一条作为选择CA的标准。第三个证书根CA的证书已经包含在浏览器内置的信任名单中不用发送。很多站点会在证书链中包含根CA的证书这是完全没有必要的。如果浏览器的信任名单中没有该根证书那说明它是不被信任的即便发送它也无济于事。理想的证书链应该在2~3KB左右同时还能给浏览器提供所有必要的信息避免不必要的往返或者对证书本身额外的请求。优化TLS握手可以消除关键的性能瓶颈因为每个新TLS连接都要经历同样的延迟。
OCSP封套
每个新TLS连接都要求浏览器至少验证两样东西证书链签名证书没有被撤销。此时浏览器行为差别很大
使用自己的更新机制推送更新的CRL名单而不会按需发送请求只会针对扩展验证证书EV证书进行实时OCSP和CRL检查。在上述任何一种方式下阻塞TLS握手有些则不会具体情况取决于开发商、平台和浏览器版本。
OCSP封套OCSP Stapling某些浏览器采用的优化措施服务器可在证书链中包含封套CA的OCSP响应让浏览器跳过在线查询。把查询OCSP操作转移到服务器让服务器缓存签名的OCSP响应从而节省很多客户端请求
需服务器NginX、Apache和IIS等支持OCSP响应约400~4000字节把这么大的响应封套在证书链里可能会造成TCP拥塞窗口溢出只能包含一个OCSP响应在没有缓存时浏览器对其他中间证书可能仍然需要发送OCSP请求。
HSTS
HTTP Strict Transport SecurityHTTP严格传输安全一种安全策略机制它能让服务器通过简单的HTTP首部如Strict-Transport-Security: max-age31536000对适用的浏览器声明访问规则。具体来讲它可以让用户代理遵从如下规则
所有对原始服务器的请求都通过HTTPS发送所有不安全的链接和客户端请求在发送之前都应该在客户端自动转换为HTTPS万一证书有错误则显示错误消息用户不能回避警告max-age以秒为单位指定HSTS规则集的生存时间用户代理可以可选根据指令在指定的证书链中记住某主机的指纹以便将来访问时使用从而有效限制CA在特定时间由max-age指定内可颁发证书的范围。
HSTS会把原始服务器转换为只处理HTTPS的目标服务器从而确保应用不会因各种主动或被动攻击给用户造成损失。HSTS通过把责任转移到客户端让客户端自动把所有链接重写为HTTPS消除从HTTP到HTTPS的重定向损失。
性能检查清单
检查清单
最大限制提升TCP性能把TLS库升级到最新版本在此基础上重新构建服务器启用并配置会话缓存和无状态恢复监控会话缓存的使用情况并作出相应调整在接近用户的地方完成TLS会话尽量减少往返延迟配置TLS记录大小使其恰好能封装在一个TCP段内确保证书链不会超过拥塞窗口的大小从信任链中去掉不必要的证书减少链条层次禁用服务器的TLS压缩功能启用服务器对SNI的支持启用服务器的OCSP封套功能追加HTTP严格传输安全首部。
测试与验证
为了测试和验证服务器配置可使用Qualys提供的SSL Server Test等在线服务来扫描服务器以发现常见的配置和安全漏洞。
还需要熟练掌握openssl工具用于检查整个握手和本地服务器配置情况。
