http和https

最新推荐文章于 2020-10-29 20:08:15 发布

FangYikaiii

最新推荐文章于 2020-10-29 20:08:15 发布

阅读量620

点赞数

分类专栏：网络通信

网络通信专栏收录该内容

2 篇文章 0 订阅

订阅专栏

超文本传输协议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加密、加密、及验证过程，如下图所示：

简单来说，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协议。

1、客户端发起HTTPS请求

这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。

2、服务端的配置

采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。

这套证书其实就是一对公钥和私钥，如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3、传送证书

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4、客户端解析证书

这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。

如果证书没有问题，那么就生成一个随机值，然后用证书对该随机值进行加密，就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5、传送加密信息

这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6、服务段解密信息

服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密，所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7、传输加密后的信息

这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。

8、客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容，整个过程第三方即使监听到了数据，也束手无策。

四、搜索引擎对HTTPS的态度

百度推出了全站HTTPS加密搜索服务，以此解决“第三方”对用户隐私的嗅探和劫持，其实，早在2010年5月份，谷歌便开始提供HTTPS加密搜索服务，在HTTPS网页的抓取问题上，百度在2014年9月份的一份公告中表示“百度不会主动抓取HTTPS网页”，谷歌在算法更新中则表示“同等条件下，使用HTTPS加密技术的站点在搜索排名上更具优势”。

那么，在这种大环境下，站长是否该采用“具有风险”的HTTPS协议呢？HTTPS对搜索引擎的SEO影响又如何呢？

1、谷歌的态度

谷歌在HTTPS站点的收录问题上与对HTTP站点态度并无什么不同之处，甚至把“是否使用安全加密”（HTTPS）作为搜索排名算法中的一个参考因素，采用HTTPS加密技术的网站能得到更多的展示机会，排名相对同类网站的HTTP站点也更有优势。

而且谷歌曾明确表示“希望所有的站长都能将使用HTTPS协议，而非HTTP”更是表明了其对达到“HTTPS everywhere”这一目标的决心。

2、百度的态度

虽然百度曾表示“不会主动抓取https网页”，但对于“很多https网页无法被收录”也是“耿耿于怀”，去年9月份，百度曾就“https站点如何建设才能对百度友好”问题发布了一篇文章，给出了“提高https站点的百度友好度”的四项建议及具体操作。

此外，近日的“百度全站HTTPS加密搜索”事件也再次彰显了百度对HTTPS加密的重视，可见，百度并不“反感”HTTPS站点，所以“不主动抓取”应该也只是暂时的吧！

五、HTTPS要比HTTP多用多少服务器资源？

HTTPS其实就是建构在SSL/TLS之上的 HTTP协议，所以，要比较HTTPS比HTTP多用多少服务器资源，马海祥认为主要看SSL/TLS本身消耗多少服务器资源。

HTTP使用TCP三次握手建立连接，客户端和服务器需要交换3个包（具体可查看马海祥博客《HTTP服务的七层架构技术解析及运用》的相关介绍）；HTTPS除了TCP的三个包，还要加上ssl握手需要的9个包，所以一共是12个包。

HTTP建立连接，按照下面链接中针对Computer Science House的测试，是114毫秒；HTTPS建立连接，耗费436毫秒，ssl部分花费322毫秒，包括网络延时和ssl本身加解密的开销（服务器根据客户端的信息确定是否需要生成新的主密钥；服务器回复该主密钥，并返回给客户端一个用主密钥认证的信息；服务器向客户端请求数字签名和公开密钥）。

当SSL连接建立后，之后的加密方式就变成了3DES等对于CPU负荷较轻的对称加密方式，相对前面SSL建立连接时的非对称加密方式，对称加密方式对CPU的负荷基本可以忽略不记，所以问题就来了，如果频繁的重建ssl的session，对于服务器性能的影响将会是致命的，尽管打开HTTPS保活可以缓解单个连接的性能问题，但是对于并发访问用户数极多的大型网站，基于负荷分担的独立的SSL termination proxy就显得必不可少了，Web服务放在SSL termination proxy之后，SSL terminationproxy既可以是基于硬件的，譬如F5；也可以是基于软件的，譬如维基百科用到的就是Nginx。

那采用HTTPS后，到底会多用多少服务器资源，2010年1月Gmail切换到完全使用HTTPS，前端处理SSL机器的CPU负荷增加不超过1%，每个连接的内存消耗少于20KB，网络流量增加少于2%，由于Gmail应该是使用N台服务器分布式处理，所以CPU负荷的数据并不具有太多的参考意义，每个连接内存消耗和网络流量数据有参考意义，这篇文章中还列出了单核每秒大概处理1500次握手（针对1024-bit 的RSA），这个数据很有参考意义。

Heartbleed这个被称作史上最大的网络安全漏洞，想必很多人都有所耳闻，Heartbleed之所以能够出现，其实和我们这个问题关系还不小，前面我们谈到了频繁重建SSL/TLS的session对于服务器影响是致命的，所以，聪明的RFC在2012年提出了RFC6520 TLS的心跳扩展，这个协议本身是简单和完美的，通过在客户端和服务器之间来回发送心跳的请求和应答，保活TLS session，减少重建TLS的session的性能开销，令人遗憾的是，openssl在实现这个心跳扩展时，犯了一个低级的错误，没有对收到的心跳请求进行长度检查，直接根据心跳请求长度拷贝数据区，导致简单的心跳应答中可能包含了服务器端的核心数据区内容，用户名，密码，信用卡信息，甚至服务器的私有密钥都有可能泄露。

六、HTTPS的优点

正是由于HTTPS非常的安全，攻击者无法从中找到下手的地方，从站长的角度来说，HTTPS的优点有以下2点：

1、SEO方面

谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。

2、安全性

尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：

（1）、使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；

（2）、HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。

（3）、HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

七、HTTPS的缺点

虽然说HTTPS有很大的优势，但其相对来说，还是有些不足之处的，具体来说，有以下2点：

1、SEO方面

据ACM CoNEXT数据显示，使用HTTPS协议会使页面的加载时间延长近50%，增加10%到20%的耗电，此外，HTTPS协议还会影响缓存，增加数据开销和功耗，甚至已有安全措施也会受到影响也会因此而受到影响。

而且HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。

最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

2、经济方面

（1）、SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。

（2）、SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗（SSL有扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器、操作系统支持，Windows XP就不支持这个扩展，考虑到XP的装机量，这个特性几乎没用）。

（3）、HTTPS连接缓存不如HTTP高效，大流量网站如非必要也不会采用，流量成本太高。

（4）、HTTPS连接服务器端资源占用高很多，支持访客稍多的网站需要投入更大的成本，如果全部采用HTTPS，基于大部分计算资源闲置的假设的VPS的平均成本会上去。

（5）、HTTPS协议握手阶段比较费时，对网站的相应速度有负面影响，如非必要，没有理由牺牲用户体验。

八、网站是否需要采用HTTPS加密？

虽然谷歌和百度都对HTTPS“另眼相看”，但这并不意味着站长们都应该把网站协议转换成HTTPS的！

早在去年9月份，Moz就针对“采用HTTPS协议”展开了一项调查，结果如下图：

注：调查开展时间在谷歌宣布“使用HTTPS协议的网站可以获得更好的排名”后

如上图所示，在此项调查中，17.24%的站长表示其网站已采用HTTPS协议；24.9%的站长表示正在搭建中；57.85%的站长表示目前仍无此项计划，从这些数据可以看出，当时大部分的站长还是没有选择使用HTTPS协议，那么，站长们到底该不该选择有利有弊的HTTPS协议呢？

从这些数据可以看出，当时大部分的站长还是没有选择使用HTTPS协议，那么站长们到底该不该选择有利有弊的HTTPS协议呢？

首先说说谷歌方面，虽然谷歌不断强调“使用HTTPS加密技术的网站能获得更好的排名”，但也不能排除这是“别有用心”之举。

国外分析师就曾针对这一问题表示：谷歌之所以做出这一举动（更新算法，将是否采用HTTPS加密技术作为搜索引擎排名的的一个参考因素）也许并非是为了提高用户的搜索体验和互联网安全问题，只是为了挽回在“棱镜门”丑闻中的“损失”，这是一个典型的打着“牺牲小我”旗号的利我之举，高举“安全影响排名”旗帜、高呼“HTTPS everywhere”口号，然后不费吹灰之力让广大站长们心甘情愿的投入HTTPS协议阵营。

然后是百度方面，虽然百度宣布全站进入HTTPS加密搜索时代，但至今仍“不会主动抓取HTTPS页面”，也从未就“未来是否会调整算法”问题表过态，如果站长在采用HTTPS协议后仍需制作个“http可访问版”、或是通过301重定向“自动跳入https版本”，那么，采用HTTPS协议的代价就不再只是多花money的问题了。

在思考“到底该不该采用HTTPS协议”这个问题时，多考虑考虑怎样做对你的用户更友好吧（具体可查看马海祥博客《从SEO的角度来分析网站是否该采用HTTPS协议》的相关介绍）！

如果你的网站属于电子商务、金融、社交网络等领域的话，那最好是采用HTTPS协议；如果是博客站点、宣传类网站、分类信息网站、或者是新闻网站之类的话，大可不必跟风而行，毕竟HTTPS协议不仅耗钱，浪费精力，而且暂时也不利于网站的SEO工作。详情可查看：我到底该不该用“影响搜索排名”的HTTPS？

九、站长如何搭建HTTPS站点？

说到HTTPS站点的搭建，就不得不提到SSL协议，SSL是Netscape公司率先采用的网络安全协议，它是在传输通信协议（TCP/IP）上实现的一种安全协议，采用公开密钥技术，SSL广泛支持各种类型的网络，同时提供三种基本的安全服务，它们都使用公开密钥技术。

1、SSL的作用

（1）、认证用户和服务器，确保数据发送到正确的客户机和服务器；

（2）、加密数据以防止数据中途被窃取；

（3）、维护数据的完整性，确保数据在传输过程中不被改变。

而SSL证书指的是在SSL通信中验证通信双方身份的数字文件，一般分为服务器证书和客户端证书，我们通常说的SSL证书主要指服务器证书，SSL证书由受信任的数字证书颁发机构CA（如VeriSign，GlobalSign，WoSign等），在验证服务器身份后颁发，具有服务器身份验证和数据传输加密功能，分为扩展验证型(EV)SSL证书、组织验证型(OV)SSL证书、和域名验证型（DV）SSL证书。

2、SSL证书申请的3个主要步骤

对于SSL证书的申请，主要有以下3个步骤：

（1）、制作CSR文件

所谓CSR就是由申请人制作的Certificate Secure Request证书请求文件，制作过程中，系统会产生2个密钥，一个是公钥就是这个CSR文件；另外一个是私钥，存放在服务器上。

要制作CSR文件，申请人可以参考WEBSERVER的文档，一般APACHE等，使用OPENSSL命令行来生成KEY+CSR2个文件，Tomcat，JBoss，Resin等使用KEYTOOL来生成JKS和CSR文件，IIS通过向导建立一个挂起的请求和一个CSR文件。

（2）、CA认证

将CSR提交给CA，CA一般有2种认证方式：

①、域名认证：一般通过对管理员邮箱认证的方式，这种方式认证速度快，但是签发的证书中没有企业的名称。

②、企业文档认证：需要提供企业的营业执照，一般需要3-5个工作日。

也有需要同时认证以上2种方式的证书，叫EV证书，这种证书可以使IE7以上的浏览器地址栏变成绿色，所以认证也最严格。

（3）、证书的安装

在收到CA的证书后，可以将证书部署上服务器，一般APACHE文件直接将KEY+CER复制到文件上，然后修改HTTPD.CONF文件；TOMCAT等，需要将CA签发的证书CER文件导入JKS文件后，复制上服务器，然后修改SERVER.XML；IIS需要处理挂起的请求，将CER文件导入。

十、免费证书推荐

使用SSL证书不仅能让信息的安全性更有保障，还可以提高用户对于网站的信任度，但鉴于对建站成本的考虑，很多站长对其望而却步，在网络上免费始终是一个永远不过时的市场，主机空间有免费的，而SSL证书自然也有免费的，此前，便有消息称，Mozilla、思科、Akamai、IdenTrust、EFF、以及密歇根大学的研究人员将开启Let’s Encrypt CA项目，计划从今夏开始，为网站提供免费SSL证书以及证书管理服务（注：如需更高级的复杂证书，则需付费），同时，还降低了证书安装的复杂程度，安装时间仅需20-30秒。

而需要复杂证书的往往是大中型网站，诸如个人博客之类的小型站点完全可以先尝试免费SSL证书，如果想要购买低价SSL证书可查看站长之家之前发布的文章：如何购买廉价SSL证书？。

下面马海祥博客再为大家介绍几款免费SSL证书，比如：CloudFlare SSL、StartSSL、Wosign沃通SSL、NameCheap等。

1、CloudFlare SSL

CloudFlare是美国一家提供CDN服务的网站，在世界各地都有自己的CDN服务器节点，国内外很多大型公司或者网站都在使用CloudFlare的CDN服务，当然国内站长最常用的就是CloudFlare的免费CDN，加速也很好，CloudFlare提供的免费SSL证书是UniversalSSL，即通用SSL，用户无需向证书发放机构申请和配置证书就可以使用的SSL证书，CloudFlare向所有用户(包括免费用户)提供SSL加密功能，web界面5分钟内就设置好证书，24小时内完成自动部署，为网站的流量提供基于椭圆曲线数字签名算法（ECDSA）的TLS加密服务。

2、StartSSL

StartSSL是StartCom公司旗下的SSL证书，提供免费SSL证书服务，且StartSSL被包括Chrome、Firefox、IE在内的主流浏览器支持，几乎所有的主流浏览器都可以正常识别StartSSL，任何个人都可以从StartSSL中申请到免费一年的SSL证书。

3、Wosign沃通SSL

Wosign沃通是国内一家提供SSL证书服务的网站，其免费的SSL证书申请比较简单，在线开通，一个SSL证书只能对应一个域名，支持证书状态在线查询协议(OCSP)。

4、NameCheap

NameCheap是一家领先的ICANN认可的域名注册和网站托管公司，成立于2000年，该公司提供免费DNS解析，网址转发（可隐藏原URL，支持301重定向）等服务，此外，NameCheap还提供了一年的SSL证书免费服务。

HTTP Keep-Alive

在http早期，每个http请求都要求打开一个tpc socket连接，并且使用一次之后就断开这个tcp连接。

使用keep-alive可以改善这种状态，即在一次TCP连接中可以持续发送多份数据而不会断开连接。通过使用keep-alive机制，可以减少tcp连接建立次数，也意味着可以减少TIME_WAIT状态连接，以此提高性能和提高http服务器的吞吐率(更少的tcp连接意味着更少的系统内核调用,socket的accept()和close()调用)。

但是，keep-alive并不是免费的午餐,长时间的tcp连接容易导致系统资源无效占用。配置不当的keep-alive，有时比重复利用连接带来的损失还更大。所以，正确地设置keep-alive timeout时间非常重要。

keepalvie timeout

Httpd守护进程，一般都提供了keep-alive timeout时间设置参数。比如nginx的keepalive_timeout，和Apache的KeepAliveTimeout。这个keepalive_timout时间值意味着：一个http产生的tcp连接在传送完最后一个响应后，还需要hold住keepalive_timeout秒后，才开始关闭这个连接。

当httpd守护进程发送完一个响应后，理应马上主动关闭相应的tcp连接，设置 keepalive_timeout后，httpd守护进程会想说：”再等等吧，看看浏览器还有没有请求过来”，这一等，便是keepalive_timeout时间。如果守护进程在这个等待的时间里，一直没有收到浏览发过来http请求，则关闭这个http连接。

下面写一个脚本，方便测试：

1	sleep(60); //为了便于分析测试，会根据测试进行调整
2	echo "www.example.com";

1. 当keepalive_timeout时间为0时，即不启用Keep-Alive时，一个tcp连接的生命周期：

01	#tcpdump -n host 218.1.57.236 and port 80
02	20:36:50.792731 IP 218.1.57.236.43052 > 222.73.211.215.http: S 1520902589:1520902589(0) win 65535

03	20:36:50.792798 IP 222.73.211.215.http > 218.1.57.236.43052: S 290378256:290378256(0) ack 1520902590 win 5840
04	20:36:50.801629 IP 218.1.57.236.43052 > 222.73.211.215.http: . ack 1 win 32768

05
06	20:36:50.801838 IP 218.1.57.236.43052 > 222.73.211.215.http: P 1:797(796) ack 1 win 32768

07	20:36:50.801843 IP 222.73.211.215.http > 218.1.57.236.43052: . ack 797 win 59
08

09	20:37:50.803230 IP 222.73.211.215.http > 218.1.57.236.43052: P 1:287(286) ack 797 win 59
10	20:37:50.803289 IP 222.73.211.215.http > 218.1.57.236.43052: F 287:287(0) ack 797 win 59

11	20:37:50.893396 IP 218.1.57.236.43052 > 222.73.211.215.http: . ack 288 win 32625
12	20:37:50.894249 IP 218.1.57.236.43052 > 222.73.211.215.http: F 797:797(0) ack 288 win 32625

13	20:37:50.894252 IP 222.73.211.215.http > 218.1.57.236.43052: . ack 798 win 59

· 第1~3行建立tcp三次握手，建立连接。用时8898μs

· 第4~5行通过建立的连接发送第一个http请求，服务端确认收到请求。用时5μs

· 第5~6行，可以知道脚本执行用时60s1387μs,与php脚本相符。

· 第6、8行服务端发送http响应。发送响应用时90166μs。

· 第7行，表明由服务端守护进程主动关闭连接。结合第6、8行，说明http响应一旦发送完毕，服务端马上关闭这个tcp连接

· 第7、9、10说明tcp连接顺序关闭,用时90963μs。需要注意,这里socket资源并没有立即释放，需要等待2MSL时间（60s）后才被真正释放。

由此可见，在没有设置 keepalive_timeout 情况下，一个socket资源从建立到真正释放需要经过的时间是:建立tcp连接 + 传送http请求 + php脚本执行 + 传送http响应 + 关闭tcp连接 + 2MSL 。(注:这里的时间只能做参考，具体的时间主要由网络带宽，和响应大小而定)

2. 当keepalive_timeout时间大于0时，即启用Keep-Alive时，一个tcp连接的生命周期。为了便于分析，我们将keepalive_timeout设置为300s

01	#tcpdump -n host 218.1.57.236 and port 80
02	21:38:05.471129 IP 218.1.57.236.54049 > 222.73.211.215.http: S 1669618600:1669618600(0) win 65535

03	21:38:05.471140 IP 222.73.211.215.http > 218.1.57.236.54049: S 4166993862:4166993862(0) ack 1669618601 win 5840
04	21:38:05.481731 IP 218.1.57.236.54049 > 222.73.211.215.http: . ack 1 win 32768

05	21:38:05.481976 IP 218.1.57.236.54049 > 222.73.211.215.http: P 1:797(796) ack 1 win 32768
06	21:38:05.481985 IP 222.73.211.215.http > 218.1.57.236.54049: . ack 797 win 59

07
08	21:38:07.483626 IP 222.73.211.215.http > 218.1.57.236.54049: P 1:326(325) ack 797 win 59

09	21:38:07.747614 IP 218.1.57.236.54049 > 222.73.211.215.http: . ack 326 win 32605
10	21:43:07.448454 IP 222.73.211.215.http > 218.1.57.236.54049: F 326:326(0) ack 797 win 59

11	21:43:07.560316 IP 218.1.57.236.54049 > 222.73.211.215.http: . ack 327 win 32605
12	21:43:11.759102 IP 218.1.57.236.54049 > 222.73.211.215.http: F 797:797(0) ack 327 win 32605

13	21:43:11.759111 IP 222.73.211.215.http > 218.1.57.236.54049: . ack 798 win 59

· 我们先看一下，第6~8行，跟上次示例不一样的是，服务端httpd守护进程发完响应后，没有立即主动关闭tcp连接。

· 第8行，结合第6行，我们可以看到，5分钟(300s)后，服务端主动关闭这个tcp连接。这个时间，正是我们设置的keepalive_timeout的时间。

· 由此可见，设置了keepalive_timout时间情况下，一个socket建立到释放需要的时间是多了keepalive_timeout时间。

3. 当keepalive_timeout时间大于0，并且在同一个tcp连接发送多个http响应。这里为了便于分析，我们将keepalive_timeout设置为180s

通过这个测试，我们想弄清楚,keepalive_timeout是从第一个响应结束开启计时，还是最后一个响应结束开启计时。测试结果证实是后者，这里，我们每隔120s发一次请求，通过一个tcp连接发送了3个请求。

01	# tcpdump -n host 218.1.57.236 and port 80
02	22:43:57.102448 IP 218.1.57.236.49955 > 222.73.211.215.http: S 4009392741:4009392741(0) win 65535

03	22:43:57.102527 IP 222.73.211.215.http > 218.1.57.236.49955: S 4036426778:4036426778(0) ack 4009392742 win 5840
04	22:43:57.111337 IP 218.1.57.236.49955 > 222.73.211.215.http: . ack 1 win 32768

05
06	22:43:57.111522 IP 218.1.57.236.49955 > 222.73.211.215.http: P 1:797(796) ack 1 win 32768

07	22:43:57.111530 IP 222.73.211.215.http > 218.1.57.236.49955: . ack 797 win 59
08	22:43:59.114663 IP 222.73.211.215.http > 218.1.57.236.49955: P 1:326(325) ack 797 win 59

09	22:43:59.350143 IP 218.1.57.236.49955 > 222.73.211.215.http: . ack 326 win 32605
10

11	22:45:59.226102 IP 218.1.57.236.49955 > 222.73.211.215.http: P 1593:2389(796) ack 650 win 32443
12	22:45:59.226109 IP 222.73.211.215.http > 218.1.57.236.49955: . ack 2389 win 83

13	22:46:01.227187 IP 222.73.211.215.http > 218.1.57.236.49955: P 650:974(324) ack 2389 win 83
14	22:46:01.450364 IP 218.1.57.236.49955 > 222.73.211.215.http: . ack 974 win 32281

15
16	22:47:57.377707 IP 218.1.57.236.49955 > 222.73.211.215.http: P 3185:3981(796) ack 1298 win 32119

17	22:47:57.377714 IP 222.73.211.215.http > 218.1.57.236.49955: . ack 3981 win 108
18	22:47:59.379496 IP 222.73.211.215.http > 218.1.57.236.49955: P 1298:1622(324) ack 3981 win 108

19	22:47:59.628964 IP 218.1.57.236.49955 > 222.73.211.215.http: . ack 1622 win 32768
20

21	22:50:59.358537 IP 222.73.211.215.http > 218.1.57.236.49955: F 1622:1622(0) ack 3981 win 108
22	22:50:59.367911 IP 218.1.57.236.49955 > 222.73.211.215.http: . ack 1623 win 32768

23	22:50:59.686527 IP 218.1.57.236.49955 > 222.73.211.215.http: F 3981:3981(0) ack 1623 win 32768
24	22:50:59.686531 IP 222.73.211.215.http > 218.1.57.236.49955: . ack 3982 win 108

· 第一组，三个ip包表示tcp三次握手建立连接，由浏览器建立。

· 第二组，发送第一次http请求并且得到响应，服务端守护进程输出响应之后，并没马上主动关闭tcp连接。而是启动keepalive_timout计时。

· 第三组，2分钟后，发送第二次http请求并且得到响应，同样服务端守护进程也没有马上主动关闭tcp连接，重新启动keepalive_timout计时。

· 第四组，又2分钟后，发送了第三次http请求并且得到响应。服务器守护进程依然没有主动关地闭tcp连接（距第一次http响应有4分钟了,大于keepalive_timeout值），而是重新启动了keepalive_timout计时。

· 第五组，跟最后一个响应keepalive_timeout(180s)内，守护进程再没有收到请求。计时结束，服务端守护进程主动关闭连接。4次挥手后，服务端进入TIME_WAIT状态。

这说明，当设定了keepalive_timeout，一个socket由建立到释放，需要时间是：tcp建立 + (最后一个响应时间 – 第一个请求时间) + tcp关闭 + 2MSL。红色加粗表示每一次请求发送时间、每一次请求脚本执行时间、每一次响应发送时间，还有两两请求相隔时间。进一步测试，正在关闭或者TIME_WAIT状态的tcp连接，不能传输http请求和响应。即，当一个连接结束keepalive_timeout计时，服务端守护进程发送第一个FIN标志ip包后，该连接不能再使用了。

http keep-alive与tcp keep-alive

http keep-alive与tcp keep-alive，不是同一回事，意图不一样。http keep-alive是为了让tcp活得更久一点，以便在同一个连接上传送多个http，提高socket的效率。而tcp keep-alive是TCP的一种检测TCP连接状况的保鲜机制。tcp keep-alive保鲜定时器，支持三个系统内核配置参数：

1	echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time
2	echo 15 > /proc/sys/net/ipv4/tcp_keepalive_intvl

3	echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes

keepalive是TCP保鲜定时器，当网络两端建立了TCP连接之后，闲置idle（双方没有任何数据流发送往来）了tcp_keepalive_time后，服务器内核就会尝试向客户端发送侦测包，来判断TCP连接状况(有可能客户端崩溃、强制关闭了应用、主机不可达等等)。如果没有收到对方的回答(ack包)，则会在 tcp_keepalive_intvl后再次尝试发送侦测包，直到收到对对方的ack,如果一直没有收到对方的ack,一共会尝试 tcp_keepalive_probes次，每次的间隔时间在这里分别是15s, 30s, 45s, 60s, 75s。如果尝试tcp_keepalive_probes,依然没有收到对方的ack包，则会丢弃该TCP连接。TCP连接默认闲置时间是2小时，一般设置为30分钟足够了。

也就是说，仅当nginx的keepalive_timeout值设置高于tcp_keepalive_time，并且距此tcp连接传输的最后一个http响应，经过了tcp_keepalive_time时间之后，操作系统才会发送侦测包来决定是否要丢弃这个TCP连接。一般不会出现这种情况，除非你需要这样做。

keep-alive与TIME_WAIT

使用http keep-alvie，可以减少服务端TIME_WAIT数量(因为由服务端httpd守护进程主动关闭连接)。道理很简单，相较而言，启用keep-alive，建立的tcp连接更少了，自然要被关闭的tcp连接也相应更少了。