怎么理解TCP是面向连接的，HTTP基于TCP却是无连接的？

HTTP是无连接的是什么鬼说法，应该是短连接吧？然而实际上“HTTP=短连接”早就已经是过去式了

HTTP连接方式的进化史：

HTTP/0.9时代：短连接

每个HTTP请求都要经历一次DNS解析、三次握手、传输和四次挥手。反复创建和断开TCP连接的开销巨大，在现在看来，这种传输方式简直是糟糕透顶。

HTTP/1.0时代：持久连接概念提出

人们认识到短连接的弊端，提出了持久连接的概念，在HTTP/1.0中得到了初步的支持。

持久连接，即一个TCP连接服务多次请求：

客户端在请求header中携带Connection:

Keep-Alive，即是在向服务端请求持久连接。如果服务端接受持久连接，则会在响应header中同样携带Connection:

Keep-Alive，这样客户端便会继续使用同一个TCP连接发送接下来的若干请求。（Keep-Alive的默认参数是[timout=5,

max=100]，即一个TCP连接可以服务至多5秒内的100次请求）

当服务端主动切断一个持久连接时（或服务端不支持持久连接），则会在header中携带Connection: Close，要求客户端停止使用这一连接。

HTTP/1.1时代：持久连接成为默认的连接方式；提出pipelining概念

HTTP/1.1开始，即使请求header中没有携带Connection: Keep-Alive，传输也会默认以持久连接的方式进行。

目前所有的浏览器都默认请求持久连接，几乎所有的HTTP服务端也都默认开启对持久连接的支持，短连接正式成为过去式。（HTTP/1.1的发布时间是1997年，最后一次对协议的补充是在1999年，我们可以夸张地说：HTTP短连接这个概念已经过时了近20年了。）

同时，持久连接的弊端被提出 —— HOLB（Head of Line Blocking）

即持久连接下一个连接中的请求仍然是串行的，如果某个请求出现网络阻塞等问题，会导致同一条连接上的后续请求被阻塞。

所以HTTP/1.1中提出了pipelining概念，即客户端可以在一个请求发送完成后不等待响应便直接发起第二个请求，服务端在返回响应时会按请求到达的顺序依次返回，这样就极大地降低了延迟。

然而pipelining并没有彻底解决HOLB，为了让同一个连接中的多个响应能够和多个请求匹配上，响应仍然是按请求的顺序串行返回的。所以pipelining并没有被广泛接受，几乎所有代理服务都不支持pipelining，部分浏览器不支持pipelining，支持的大部分也会将其默认关闭。

SPDY和HTTP/2：multiplexing

multiplexing即多路复用，在SPDY中提出，同时也在HTTP/2中实现。

multiplexing技术能够让多个请求和响应的传输完全混杂在一起进行，通过streamId来互相区别。这彻底解决了holb问题，同时还允许给每个请求设置优先级，服务端会先响应优先级高的请求。

现在Chrome、FireFox、Opera、IE、Safari的最新版本都支持SPDY，Nginx/Apache HTTPD/Jetty/Tomcat等服务端也都提供了对SPDY的支持。

另外，谷歌已经关闭SPDY项目，正式为HTTP/2让路。可以认为SPDY是HTTP/2的前身和探路者。

HTTP使用TCP的目的难道不是为了保证HTTP数据传输的可靠性？

例如是使用浏览器浏览百度搜索的主页

第一步：你发出HTTP请求 （在地址栏输入

，然后敲回车）

第二步：百度服务器收到你的HTTP请求

第三步：百度服务器把

这个默认主页返回到你的电脑

第四步：你的浏览器上显示出 百度搜索 的主页

使用TCP的目的是保证你所发送的请求和百度服务器返回的页面这两者信息传输的完整性。

有些页面包含的文字、图片很多，服务器需要把整个页面分割成许多个数据包再发到你的电脑上，如果中途因为网络拥挤等原因，丢失了部分数据包，那你在电脑上显示的请求页面是不完整的。

例如，如果百度的服务器返回给你的主页数据在传输过程中丢失了一部分，刚好丢失的部分是

包含这个图片的数据包。

那你在电脑上看到的百度主页可能是这样的：

所以，HTTP使用TCP的目的是为了保证数据传输的可靠性和完整性。

TCP的面向连接是基于网络底层的数据传输。

HTTP的无连接是基于应用层面的沟通交互。