松鼠书读书笔记（三）——HTTP连接管理

世界上 几乎所有的HTTP通信都是由TCP/IP承载的

我不知道为什么这里说的是“几乎所有”，而不是全部。我不知道哪个HTTP应用实现是建立在UDP协议上的，书里也没有举例子。总之，结论就是看到HTTP，可以默认其下层协议是TCP/IP

所以基本上，一次HTTP事务的过程，就是客户端首先与服务端建立TCP连接，然后客户端发送一条http请求，服务端发送一条http响应，最后断开TCP连接

我们常说的端口号，是TCP端口号；而主机名，则会被解析成IP地址。IP地址用于连接到正确的计算机上，而端口号则用于连接到正确的应用程序上。

TCP连接通过4个值来识别：

源IP、源端口、目的IP、目的端口

比如从我的机器上，开了一个IE连到百度，又开了一个chrome也连到百度，那么这个时候就是这样的：

我的IP、某端口A、220.181.111.147、80
我的IP、某端口B、220.181.111.147、80

经常说的socket，就是一组操纵TCP/IP的编程API。由于其设计精巧，并且对应用层程序员完全隐藏了TCP/IP的细节，所以基本上，所有需要用到TCP/IP的程序，都会使用socket接口来完成

但是并不能说“HTTP是建立在socket基础上的”。HTTP是实实在在的应用层协议，它几乎100%是建立在TCP/IP上的。而socket是简化TCP/IP编程的API接口，其本身并不是一个协议

socket最早是为UNIX开发的，现在几乎所有的操作系统和语言中都有它，比如JAVA中，就有整套Socket API

最后，书中提到，HTTP/1.1允许HTTP在事务结束之后，将TCP连接保持在打开状态，未来的 HTTP请求可以重用该连接。这样的话可以节省重新建立TCP连接的时间，提升一点性能。这样的连接叫做“持久连接”

但是，其实持久连接，是可以用来做更多事情的，比如服务端推送。但是HTTP协议仅规定client agent未来发送http request时重用，没有规定server利用该连接实现推送的相关细节。所以服务端推送貌似并没有官方标准，至少在HTTP/1.1里没有，我觉得这点很遗憾

现在即使持久连接已经建立，服务端并不知道通过什么标准往client agent反推消息；client agent也没有标准的做法，在连接上监听等待server发来的消息，并进行相应的处理。我认为这恐怕是HTTP/1.1最大的缺陷