seo是什么意思?seo等于搜索引擎优化,它是基于搜索引擎的一种网络营销方式,隶属于sem --- 武汉小明seo教程,专注seo优化技术培训!
当前位置:首页 » SEO核心技术 » HTTPS网站的seo优化技术建议

HTTPS网站的seo优化技术建议

SEO核心技术 905℃ 18评论

因为HTTPS站点的安全特性,百度一直倡导网站管理员或者seo优化人员对网站进行HTTPS技术改造。另外,网站的打开速度,网站的安全系数等都是影响关键词排序的维度,从安全系数来讲,采用HTTPS协议的网站更为安全,在相同条件下,这类网站的排名会更高。

百度曾经明确表示,会全面支持HTTPS页面的收录,但从实际的情况来看,支持形式的网站更容易被收录,在这种情况下,就要对HTTPS类型的网站进行针对性的优化,在此,以问答的形式,讲解相关内容。

HTTPS网站的seo优化技术建议

1问:https的页面是否更具备排名优势?

答:相对于普通正常页面,https的页面具备安全方面的优势,安全性也是排名的因素之一,因此,这个答案是肯定的,

2问:因为改造,会使用301永久重定向,这对于原网站的排名是否有影响,原网站的百度快照是否有影响,301是需要持续做么?

答:对于原网站来讲,排名和快照都不会有影响。从时间来看,需要不间断的使用301永久重定向。

3问:百度是否会主动抓取HTTPS类型的网站?是否需要人工主动提交网站?

答:建议原类型的站点301到新类型的站点;建议对HTTPS类型的网站,进行引蜘蛛的工作,增加内容的更新频率;如果发现改造后的网站存在更新不及时以及不收录问题,需采用多种方式主动提交链接给搜索引擎。

4问:在搜索引擎抓取方面,需要注意哪些点?

答:301是必须使用的,另外,需要使用百度站长平台的两个工具,一个是抓取诊断工具,一个是抓取异常工具。保障经HTTPS改造后的网址,是能被搜索引擎识别并抓取的。

小明seo总结:

在优化技术方面的建议,可以归类于几个点,一是301重定向,一是发外链引蜘蛛,一是链接主动提交。把握好几个关键点,经过改造的页面变会有相对的,更好的排序。

喜欢 (6)or分享 (0)
发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
(18)个小伙伴在吐槽
  1. 有朝一日百度那边的技术进步了,就不用为https收录方面的问题发愁了。

    seo教程自学网2017-12-07 21:27 (6天前)回复
    • 技术的进步,需要seo人不断发现搜索引擎算法方面的缺陷,从而督促百度更加强大。

      小明seo2017-12-07 21:28 (6天前)回复
  2. 如果非要对这类型的网站进行seo优化,建议查看百度站长平台的相关文档,写得很详细。

    seo教程网2017-12-05 23:06 回复
    • 百度站长平台是最好的seo学习网站,没有毛病。

      小明seo2017-12-05 23:09 回复
  3. 一切都看百度对于这个技术的支持。

    seo优化网2017-12-01 20:48 回复
  4. 不建议用这个,小网站没这个必要,投入产出比太低了。

    武汉seo2017-11-30 22:38 回复
  5. 不知道怎么对网站进行https改造,有哪位做程序的小伙伴分享下经验。

    刑天seo2017-11-29 22:29 回复
  6. 提交新内容url给百度,之后等待百度那边的处理。

    seo研究协会网2017-11-28 21:20 回复
  7.   HTTP与HTTPS有什么区别
      超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息,HTTP协议以明文方式发送内容,不提供任何方式的数据加密,如果攻击者截取了Web浏览器和网站服务器之间的传输报文,就可以直接读懂其中的信息,因此,HTTP协议不适合传输一些敏感信息,比如:信用卡号、密码等支付信息。
      为了解决HTTP协议的这一缺陷,需要使用另一种协议:安全套接字层超文本传输协议HTTPS,为了数据传输的安全,HTTPS在HTTP的基础上加入了SSL协议,SSL依靠证书来验证服务器的身份,并为浏览器和服务器之间的通信加密。
      一、HTTP和HTTPS的基本概念
      HTTP:是互联网上应用最为广泛的一种网络协议,是一个客户端和服务器端请求和应答的标准(TCP),用于从WWW服务器传输超文本到本地浏览器的传输协议,它可以使浏览器更加高效,使网络传输减少。
      HTTPS:是以安全为目标的HTTP通道,简单讲是HTTP的安全版,即HTTP下加入SSL层,HTTPS的安全基础是SSL,因此加密的详细内容就需要SSL。
      HTTPS协议的主要作用可以分为两种:一种是建立一个信息安全通道,来保证数据传输的安全;另一种就是确认网站的真实性。
      二、HTTP与HTTPS有什么区别?
      HTTP协议传输的数据都是未加密的,也就是明文的,因此使用HTTP协议传输隐私信息非常不安全,为了保证这些隐私数据能加密传输,于是网景公司设计了SSL(Secure Sockets Layer)协议用于对HTTP协议传输的数据进行加密,从而就诞生了HTTPS。简单来说,HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比http协议安全。
      HTTPS和HTTP的区别主要如下:
      1、https协议需要到ca申请证书,一般免费证书较少,因而需要一定费用。
      2、http是超文本传输协议,信息是明文传输,https则是具有安全性的ssl加密传输协议。
      3、http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
      4、http的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。
      三、HTTPS的工作原理
      我们都知道HTTPS能够加密信息,以免敏感信息被第三方获取,所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。
      HTTP与HTTPS的区别-马海祥博客
      客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤,如图所示。
      (1)客户使用https的URL访问Web服务器,要求与Web服务器建立SSL连接。
      (2)Web服务器收到客户端请求后,会将网站的证书信息(证书中包含公钥)传送一份给客户端。
      (3)客户端的浏览器与Web服务器开始协商SSL连接的安全等级,也就是信息加密的等级。
      (4)客户端的浏览器根据双方同意的安全等级,建立会话密钥,然后利用网站的公钥将会话密钥加密,并传送给网站。
      (5)Web服务器利用自己的私钥解密出会话密钥。
      (6)Web服务器利用会话密钥加密与客户端之间的通信。
      四、HTTPS的优点
      尽管HTTPS并非绝对安全,掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击,但HTTPS仍是现行架构下最安全的解决方案,主要有以下几个好处:
      (1)使用HTTPS协议可认证用户和服务器,确保数据发送到正确的客户机和服务器;
      (2)HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比http协议安全,可防止数据在传输过程中不被窃取、改变,确保数据的完整性。
      (3)HTTPS是现行架构下最安全的解决方案,虽然不是绝对安全,但它大幅增加了中间人攻击的成本。
      (4)谷歌曾在2014年8月份调整搜索引擎算法,并称“比起同等HTTP网站,采用HTTPS加密的网站在搜索结果中的排名将会更高”。
      五、HTTPS的缺点
      虽然说HTTPS有很大的优势,但其相对来说,还是存在不足之处的:
      (1)HTTPS协议握手阶段比较费时,会使页面的加载时间延长近50%,增加10%到20%的耗电;
      (2)HTTPS连接缓存不如HTTP高效,会增加数据开销和功耗,甚至已有的安全措施也会因此而受到影响;
      (3)SSL证书需要钱,功能越强大的证书费用越高,个人网站、小网站没有必要一般不会用。
      (4)SSL证书通常需要绑定IP,不能在同一IP上绑定多个域名,IPv4资源不可能支撑这个消耗。
      (5)HTTPS协议的加密范围也比较有限,在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的,SSL证书的信用链体系并不安全,特别是在某些国家可以控制CA根证书的情况下,中间人攻击一样可行。
      六、http切换到HTTPS
      如果需要将网站从http切换到https到底该如何实现呢?
      这里需要将页面中所有的链接,例如js,css,图片等等链接都由http改为https。例如:http://www.baidu.com改为https://www.baidu.com
      BTW,这里虽然将http切换为了https,还是建议保留http。所以我们在切换的时候可以做http和https的兼容,具体实现方式是,去掉页面链接中的http头部,这样可以自动匹配http头和https头。例如:将http://www.baidu.com改为//www.baidu.com。然后当用户从http的入口进入访问页面时,页面就是http,如果用户是从https的入口进入访问页面,页面即使https的。

    seo教程自学网2017-11-27 20:28 回复
    • https的数据传输方式不同,安全性更高。

      小明seo2017-11-27 20:39 回复
  8. 对于网站新产生的内容,还是利用链接提交方法,将链接第一时间提交给百度。

    seo教程自学网2017-11-26 15:34 回复
    • 百度对于https的站点收录不是完全支撑的,需要做一些必要的优化。

      小明seo2017-11-26 15:48 回复
  9.   台湾seo:HTTPS性能与优化详解
      1、HTTPS性能损耗
      前文讨论了HTTPS原理与优势:身份验证、信息加密与完整性校验等,且未对TCP和HTTP协议做任何修改。但通过增加新协议以实现更安全的通信必然需要付出代价,HTTPS协议的性能损耗主要体现如下:
      (1).增加延时
      分析前面的握手过程,一次完整的握手至少需要两端依次来回两次通信,至少增加延时2* RTT,利用会话缓存从而复用连接,延时也至少1* RTT*。
      (2).消耗较多的CPU资源
      除数据传输之外,HTTPS通信主要包括对对称加解密、非对称加解密(服务器主要采用私钥解密数据);压测 TS8 机型的单核 CPU:对称加密算法AES-CBC-256 吞吐量 600Mbps,非对称 RSA 私钥解密200次/s。不考虑其它软件层面的开销,10G 网卡为对称加密需要消耗 CPU 约17核,24核CPU最多接入 HTTPS 连接 4800;
      静态节点当前10G 网卡的 TS8 机型的 HTTP 单机接入能力约为10w/s,如果将所有的HTTP连接变为HTTPS连接,则明显RSA的解密最先成为瓶颈。因此,RSA的解密能力是当前困扰HTTPS接入的主要难题。
      2、HTTPS接入优化
      (1).CDN接入
      HTTPS 增加的延时主要是传输延时 RTT,RTT 的特点是节点越近延时越小,CDN 天然离用户最近,因此选择使用 CDN 作为 HTTPS 接入的入口,将能够极大减少接入延时。CDN 节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法,极大减少 HTTPS 带来的延时。
      (2).会话缓存
      虽然前文提到 HTTPS 即使采用会话缓存也要至少1*RTT的延时,但是至少延时已经减少为原来的一半,明显的延时优化;同时,基于会话缓存建立的 HTTPS 连接不需要服务器使用RSA私钥解密获取 Pre-master 信息,可以省去CPU 的消耗。如果业务访问连接集中,缓存命中率高,则HTTPS的接入能力讲明显提升。当前TRP平台的缓存命中率高峰时期大于30%,10k/s的接入资源实际可以承载13k/的接入,收效非常可观。
      (3).硬件加速
      为接入服务器安装专用的SSL硬件加速卡,作用类似 GPU,释放 CPU,能够具有更高的 HTTPS 接入能力且不影响业务程序的。测试某硬件加速卡单卡可以提供35k的解密能力,相当于175核 CPU,至少相当于7台24核的服务器,考虑到接入服务器其它程序的开销,一张硬件卡可以实现接近10台服务器的接入能力。
      (4).远程解密
      本地接入消耗过多的 CPU 资源,浪费了网卡和硬盘等资源,考虑将最消耗 CPU 资源的RSA解密计算任务转移到其它服务器,如此则可以充分发挥服务器的接入能力,充分利用带宽与网卡资源。远程解密服务器可以选择 CPU 负载较低的机器充当,实现机器资源复用,也可以是专门优化的高计算性能的服务器。当前也是 CDN 用于大规模HTTPS接入的解决方案之一。
      (5).SPDY/HTTP2
      前面的方法分别从减少传输延时和单机负载的方法提高 HTTPS 接入性能,但是方法都基于不改变 HTTP 协议的基础上提出的优化方法,SPDY/HTTP2 利用 TLS/SSL 带来的优势,通过修改协议的方法来提升 HTTPS 的性能,提高下载速度等。
      来源:台湾seo

    台湾seo2017-11-17 07:53 回复
    • 在搜索引擎程序看来,https类型的网站具备更高的安全性。我们做seo,本身也需要考虑网站的安全性。从这个角度来讲,如果有这个技术,还是对网站进行https改造为宜。

      小明seo2017-11-17 08:21 回复
      •   武汉seo技术服务:如何对网站进行https改造?
          网站要实现HTTPS访问,首选你需要申请一张SSL证书,然后将SSL证书部署到服务器端,开启443端口,就可以实现HTTPS访问了。另外,如何获得SSL证书呢?可以到CA机构申请付费和免费的SSL证书,目前一些机构推出了免费SSL证书,如沃通CA推出了3年期多域名免费SSL,可以进行免费申请。如何部署SSL证书了,在申请的时候,有相应的部署指导手册。

        武汉seo技术服务2017-11-20 08:32 回复
        • 如果seo技术条件成熟,建议对自己的网站进行https部署,毕竟,百度提倡的mip改造等,对网站来讲,是有利的。

          小明seo2017-11-20 08:54 回复
          •   CSDN:Https优化方案与测试结果
              背景
              https 是基于http 和 ssl(安全套接字层) 的安全传输协议,使用ssl 协议作为会话层协议。这个协议最早是由网景公司 开发,但是随着网景的没落,现在由ietf负责维护,最初的版本也已经重新冠名(re-banded)tls(安全传输层协议) 1.0(1999年)。因此现在大部分协议是基于TLS的,尽管是相似的东西。
              针对https,能够保证数据更加安全,但是副作用是访问会变慢(相对于http),因为服务端增加了更多的计算,客户端和服务端之间多了一层协议协商过程。因此,我们要做的优化主要是针对这里
              优化点和优化方案
              大概阐述了优化的几个方向,下面我来具体的展开讨论下。如有疏漏请指正。
              同时,我也整理了一份针对https 的握手过程详解,可以帮助大家科普下。
              客户端优化
              客户端优化是针对发起 ssl client hello 的一端进行的优化。主要有两个大的方向:
              减少请求次数,提高效率
              优化加密效率
              规避完整握手
              针对减少请求次数,主要的一个点是 SSL Session 的复用,Client Hello 请求中的 Session ID可以唯一的区分一个ssl 会话的ID。这个ID在Client Say Hello的时候被填写,
              如果是第一次与server发生会话,那么Session ID可以是空。 如果之前与ssl 服务器建立过会话,而且客户端开启了Session Ticket;并且Server cache了这个Session Ticket的时候,服务端与客户端的握手就会简化,省略掉pre master 交换的过程,直接复用之前的ssl 会话
              优化加密效率
              这里是一个比较复杂的点,我们先来看下有哪些过程可能耗时:
              密钥协商阶段的非对称加密
              协商过后的针对通信的对称加密
              @协商密钥阶段
              密钥协商过程中,客户端的计算量相对小:
              生成 random1
              生成 pre-master (填充过的随机数)
              根据服务端的 random2 和自己的 random1 还有 pre-master 生成 master-secret
              使用服务端通知的(经过验证的)公钥加密 pre-master
              这个过程中大部分是在生成随机数,只有生成 master-secret 和 使用公钥加密 是消耗cpu 的。
              @加密通信阶段
              再看下ssl协商之后的过程中的加密方式,因为是采用之前协商后的secret 来进行对称加密通信,因此这里的加密算法显得尤为重要,基本上协商ssl之后的过程中一直会使用这个算法在进行加密和解密。目前采用的大部分是AES 128位密钥的方式,但是在某些不支持硬件AES加速的处理器上,性能还是有一定的限制
              另一种加密方式是 chacha20.
              ChaCha20-Poly1305是Google所采用的一种新式加密算法,性能强大,在CPU为精简指令集的ARM平台上尤为显著(ARM v8前效果较明显),在同等配置的手机中表现是AES的4倍(ARM v8之后加入了AES指令,所以在这些平台上的设备,AES方式反而比chacha20-Poly1305方式更快,性能更好),可减少加密解密所产生的数据量进而可以改善用户体验,减少等待时间,节省电池寿命等。
              因此作为一个可选的方案,chacha20 可能对于一些老旧的机型(据连荣讲,还有很多在使用arm v7 的硬件),chacha20 更具优势。
              服务端优化
              服务端的优化有几个方向
              规避完全握手
              优化加密效率
              优化证书验证流程
              因为针对的是ssl 服务端优化,所以下面结合我们常用的http server Nginx(Tenginx)来详细的讨论下优化点
              规避完整握手
              服务端规避完全握手也是通过回复会话的方式,但是对于如何成功命中Session ID恢复会话,有两个点:
              开启 session ticket
              配置session cache
              对于1来说,服务端基本都会开启。对于nginx来说,session ticket 默认就是开启的状态。
              session cache 这里就会涉及到很多问题。当前互联网场景下,大部分web服务采取了分布式的服务方式。如何共享session cache 使得经过负载均衡的请求无论落到哪个节点都可以命中cache 就是我们的一个目标。限于篇幅和验证的目的,这里就不做过多的展开。附带一篇文章可以了解
              在这里我们先配置session cache 参数和cache 过期时间。确保单机可以命中cache
              优化加密效率
              第一个阶段是我们ssl 握手中的重点阶段,根据资料,密钥协商阶段基本占据了90%的时间。
              在没有办法规避完全握手的时候,我们要尝试进行算法的优化。目前来看可以采用的非对称加密方式大约有以下的选择:
              * RSA:算法实现简单,诞生于1977年,历史悠久,经过了长时间的破解测试,安全性高。缺点就是需要比较大的素数(目前常用的是2048位)来保证安全强度,很消耗CPU运算资源。RSA是目前唯一一个既能用于密钥交换又能用于证书签名的算法。
              * DH:diffie-hellman密钥交换算法,诞生时间比较早(1977年),但是1999年才公开。缺点是比较消耗CPU性能。
              * ECDHE:使用椭圆曲线(ECC)的DH算法,优点是能用较小的素数(256位)实现RSA相同的安全等级。缺点是算法实现复杂,用于密钥交换的历史不长,没有经过长时间的安全攻击测试。
              * ECDH:不支持PFS,安全性低,同时无法实现false start。
              针对业内的选择,大部分是使用RSA加密的方式+椭圆曲线优化的DH加密
              百度的加密算法:TLS_ECDHE_RAS_WITH_AES_128_GCM_SHA256,128位秘钥 TLS1.2
              google的加密算法:TLS_ECDHE_RAS_WITH_AES_128_GCM_SHA256,128位秘钥 TLS1.2
              因此我们可优化的空间不太大,目前来看有两个优化点:
              针对椭圆曲线,选择更高效优化过的曲线模型。调优openssl 编译参数。
              采用硬件加速的方式来优化,这就涉及到采用加速卡或专门硬件。
              优化证书验证 OCSP
              证书验证是客户端验证服务端的过程。
              通常服务端会发送site的证书,这个证书是由可信机构签发的。clent在认证这个证书的时候,会先向可信机构查询站点证书的上一级中间证书的权威。然后再查询中间证书对应的根证书的权威。这个过程就是证书链查询
              OCSP 是server 把自己的站点证书和中间证书以及根证书打包一起下发到客户端,省去客户端查询的过程。
              测试中,我们使用了域名 varycloud.com ,这个域名对应申请了symentic证书。我们生成了相关的证书链。
              测试
              测试方案
              采用压力测试的方式,对比不同配置下,相同压力服务端的服务能力和延迟表现。
              服务端配置
              CPU Info E5 6核心 12线程(超线程)
              vendor_id : GenuineIntel
              cpu family : 6
              model : 62
              model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
              stepping : 4
              microcode : 0x428
              cpu MHz : 1331.367
              cache size : 15360 KB
              RAM 8G * 2
              Array Handle: 0x0032
              Error Information Handle: Not Provided
              Total Width: 72 bits
              Data Width: 64 bits
              Size: 8192 MB
              Form Factor: DIMM
              Set: None
              Locator: DIMM_A1
              Bank Locator: DIMM_A1
              Type: DDR3
              Type Detail: Registered (Buffered)
              Speed: 1333 MHz
              Manufacturer: Kingston
              Serial Number: 43153456
              Asset Tag: DIMM_A1_AssetTag
              Part Number: 9965433-091.A00
              NCI 万兆网卡
              Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
              Advertised pause frame use: No
              Advertised auto-negotiation: Yes
              Speed: 1000Mb/s
              Duplex: Full
              Port: Twisted Pair
              PHYAD: 1
              Transceiver: internal
              Auto-negotiation: on
              MDI-X: off (auto)
              Supports Wake-on: pumbg
              Wake-on: g
              Link detected: yes
              测试服务器 版本
              nginx version: nginx/1.10.2
              压测工具 wrk
              wrk 是一款压测工具,基于c开发
              https://github.com/wg/wrk
              测试使用 24线程 保持24链接 压测1分钟获得数据
              nginx 配置
              server {
              listen 443 ssl;
              server_name varycloud.com;
              access_log off;
              ssl_certificate cert.pem;
              ssl_certificate_key cert.key;
              # session tacket session cache option
              ssl_session_timeout 1d;
              ssl_session_cache shared:SSL:50m;
              ssl_session_tickets on;
              ssl_session_ticket_key tls_session_ticket.key;
              # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
              # ssl_dhparam /path/to/dhparam.pem;
              ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
              ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!aNULL:!MD5;
              ssl_prefer_server_ciphers on;
              # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
              add_header Strict-Transport-Security max-age=15768000;
              # 认证证书链
              # OCSP Stapling
              # fetch OCSP records from URL in ssl_certificate and cache them
              ssl_stapling on;
              ssl_stapling_verify on;
              resolver 114.114.114.114 8.8.8.8 8.8.4.4 223.5.5.5 valid=300s;
              resolver_timeout 5s;
              ssl_trusted_certificate chain.pem;
              location / {
              root html;
              index index.html index.htm;
              }
              基准测试过程
              测试使用是
              172.16.200.11(client)
              172.16.200.21(server)
              两台机器之间延迟大约在 0.2ms 左右
              64 bytes from 172.16.200.21: icmp_seq=1 ttl=64 time=0.186 ms
              64 bytes from 172.16.200.21: icmp_seq=2 ttl=64 time=0.229 ms
              64 bytes from 172.16.200.21: icmp_seq=3 ttl=64 time=0.204 ms
              原始数据
              针对未开启任何优化的测试数据,作为对比的基础。对于请求主动关闭这种情况测试了两次
              不主动关闭链接
              ./wrk -c 24 -t 24 -d 3m https://varycloud.com
              Running 3m test @ https://varycloud.com
              24 threads and 24 connections
              Thread Stats Avg Stdev Max +/- Stdev
              Latency 0.92ms 3.07ms 170.27ms 96.54%
              Req/Sec 1.73k 248.31 2.64k 69.64%
              7448946 requests in 3.00m, 2.25GB read
              Non-2xx or 3xx responses: 7448946
              Requests/sec: 41360.72
              Transfer/sec: 12.78MB
              每次请求链接关闭
              ./wrk -c 24 -t 24 -d 3m -H "Connection: Close" https://varycloud.com
              Running 3m test @ https://varycloud.com
              24 threads and 24 connections
              Thread Stats Avg Stdev Max +/- Stdev
              Latency 4.76ms 8.34ms 174.25ms 97.01%
              Req/Sec 51.91 10.48 90.00 69.50%
              223479 requests in 3.00m, 67.99MB read
              Non-2xx or 3xx responses: 223479
              Requests/sec: 1240.95
              Transfer/sec: 386.58KB
              开启session ticket 和 session cache
              ./wrk -c 24 -t 24 -d 3m https://varycloud.com
              Running 3m test @ https://varycloud.com
              24 threads and 24 connections
              Thread Stats Avg Stdev Max +/- Stdev
              Latency 468.71us 2.69ms 160.11ms 99.67%
              Req/Sec 2.60k 343.14 3.50k 71.52%
              11189348 requests in 3.00m, 3.38GB read
              Non-2xx or 3xx responses: 11189348
              Requests/sec: 62148.92
              Transfer/sec: 19.20MB
              ./wrk -c 24 -t 24 -d 3m -H "Connection: Close" https://varycloud.com
              Running 3m test @ https://varycloud.com
              24 threads and 24 connections
              Thread Stats Avg Stdev Max +/- Stdev
              Latency 1.71ms 10.17ms 165.85ms 98.78%
              Req/Sec 360.06 53.23 545.00 82.35%
              1544216 requests in 3.00m, 469.78MB read
              Non-2xx or 3xx responses: 1544216
              Requests/sec: 8574.25
              Transfer/sec: 2.61MB
              相比基准数据 提升大约 49% 和 64%
              开启ECDH + session ticket
              ./wrk -c 24 -t 24 -d 3m https://varycloud.com
              Running 3m test @ https://varycloud.com
              24 threads and 24 connections
              Thread Stats Avg Stdev Max +/- Stdev
              Latency 405.62us 558.95us 37.73ms 97.87%
              Req/Sec 2.61k 349.92 3.57k 71.27%
              11200203 requests in 3.00m, 3.38GB read
              Non-2xx or 3xx responses: 11200203
              Requests/sec: 62206.96
              Transfer/sec: 19.22MB
              ./wrk -c 24 -t 24 -d 3m -H "Connection: Close" https://varycloud.com
              Running 3m test @ https://varycloud.com
              24 threads and 24 connections
              Thread Stats Avg Stdev Max +/- Stdev
              Latency 1.28ms 7.68ms 166.22ms 99.27%
              Req/Sec 361.23 46.59 545.00 79.26%
              1549916 requests in 3.00m, 471.52MB read
              Non-2xx or 3xx responses: 1549916
              Requests/sec: 8606.01
              Transfer/sec: 2.62MB
              相比基准数据 提升大约 56% 和 72.9%
              相比开启 session ticket 提升大约 13.4% 和 25.1%
              开启OCSP + session ticket
              ./wrk -c 24 -t 24 -d 3m https://varycloud.com
              Running 3m test @ https://varycloud.com
              24 threads and 24 connections
              Thread Stats Avg Stdev Max +/- Stdev
              Latency 538.57us 3.79ms 162.60ms 99.62%
              Req/Sec 2.61k 369.00 3.55k 74.30%
              11219121 requests in 3.00m, 3.38GB read
              Non-2xx or 3xx responses: 11219121
              Requests/sec: 62318.07
              Transfer/sec: 19.25MB
              ./wrk -c 24 -t 24 -d 3m -H "Connection: Close" https://varycloud.com
              Running 3m test @ https://varycloud.com
              24 threads and 24 connections
              Thread Stats Avg Stdev Max +/- Stdev
              Latency 0.91ms 4.58ms 162.55ms 99.61%
              Req/Sec 368.12 40.66 540.00 74.09%
              1582284 requests in 3.00m, 481.37MB read
              Non-2xx or 3xx responses: 1582284
              Requests/sec: 8785.82
              Transfer/sec: 2.67MB
              相比基准数据 提升大约 41% 和 80%
              相比开启session ticket后的数据 提升大约 -14.8% 和 46.8%
              测试中资源消耗变化图
              cpu 资源变化图 从左至右对应4种测试情况:
              raw, session ticket, ECDH + session ticket , OCSP + session ticket
              这里写图片描述
              对于session ticket命中,cpu消耗降低了很多
              网络消耗如下
              这里写图片描述
              由于session ticket 命中,节约了cpu计算资源,因此服务能力有了提升,贷款增加明显
              测试总结
              数据已经能很明确的说明问题了,简单总结下:
              session ticket 可以简化握手,更重要的是,减少了服务端的计算量,如果能命中并且复用session ticket,会有很大的优化
              ECDH 对于生成密钥有提升,而且消耗的资源并不太明显
              OCSP 测试中有一定的抖动,但是总体趋向于降低了时延
              疑惑
              测试过程中,出现了一定的抖动。每次测试的结果都有一定的抖动,这个是困惑的点,还没有找到原因

            CSDN2017-11-25 17:42
          • 针对https改造的网站,进行特别的seo优化,很有必要。

            小明seo2017-11-25 17:43