ip面向无连接？TCP面向连接？HTTP连接方式？

ip协议：网络层，这一层容易和数据链路层混淆，在这里可以把网络层理解成传输的节点，点到点的数据网络控制。ip是网络层协议（bai倒数第二层，du最下面一层是数据链路层，zhi通过mac地址区分一个链路内的不同主机，进行dao送达），作用是通过ip地址（ipv4、ipv6）为传输层寻找目标主机并进行数据传输，ip就像快递员，仅仅负责将数据传递给全网内的目标地址，其本身并不保持连接状态。

 

TCP协议：传输层，传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务。tcp（传输控制协议）是一种面向连接的、可靠的传输层通信协议，通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。tcp的连接管理：在数据通信之前，通过tcp首部发送一个SYN包作为简历连接的请求等待确认应答。如果对端发来确认应答，则认为可以进行数据通信。如果对端的确认应答未能到达，就不会进行数据通信。此外，在通信结束时会进行断开连接的处理（FIN包）。 可以使用TCp首部用于控制的字段管理TCP连接，一个连接的建立与断开，正常过程至少需要来回发送7个包才能完成。

 

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的前身和探路者。