我的android审视之旅-----http的无状态和tcp的基于连接

        最近随便看了一些博客，就是一些关于http的框架，其中retrofit+okhttp+rxjava好火，可能是因为其中涉及到一种比较清晰的设计模式——观察者模式吧。

        抱着这种态度，决定来复习一下http这个网络协议。

        然后，我们经常会听到那么一句话，http是基于tcp的无状态无连接的应用层协议，tcp是面向连接的，可靠的传输层协议，这两个听起来就觉得矛盾和尴尬。

        接下来，我说说我对这个概念的理解。

        首先，我们先对层级进行了解，在网络四层模型中，

         HTTP属于第四层，应用层；

         TCP属于第三层，传输层；

         所以，我们首先认为他俩不是平级的，可认为TCP是父级，HTTP是子级。

         然后，从这两个层级的职责来说，传输层负责铺路还有路的稳定性，应用层负责在这个路上面运送什么东西。

         所以，从这个职责稍稍可以理解到，对于目的地来说，运送什么物品，其实事先它是不知道的，来了就收呗，不来我也没办法，所以http是无状态的；但是道路一旦建起来了，除非你把它毁了，不然目的地就能根据这个道路给你回点礼，所以TCP是基于连接的。

         ok，我们从道路和物品这个模型上有了一点认识，继续探讨。

         这里，我先臆断一句话，每一个HTTP连接都会经过TCP的3次握手连接和4次握手断连。

         有些网友就会有些躁动了，有时加载一个web页面的请求n多的图片，音乐，视频等等，那不是得7n的握手，得多损耗资源！

          在http1.0之前，确实是这样的，因为每一次的http连接都是一个短连接，连接完了马上断掉，也就是把上面说的道路和物品模型中的道路都毁了，然后第二次请求再建立；在http1.0，http1.1之后，有了长连接这个概念，我们可以设置keepalive_timeout这个请求头来设置长连接的超时时间，一般会是几百毫秒，然后在这个超时时间内，道路不会毁坏，我们可以尽情的传输物品。

         我们试着抓个包看看，打开wireshark抓包神器，这里我过滤了某个目标ip地址，ip.dst==**.**.**.**，然后打开这个ip的网页，得到如图，

         

         前两个TCP包就是三次握手的第一和第三次，由于我只过滤目标的，没有源的，所以没能看到第二次。然后整个接下来就是在不停的控制窗口接收数据，其中http包里面就是描述数据的大概内容，图片，视频等等，tcp包就在序列号和窗口大小以保证这个包能被正确接收（具体不细说了，水太深了，我们这里只要知道http的过程）。什么时候才发送断开连接的FIN包呢，我们一直往下拖，看到了好多的http请求，但知道最后，才看到FIN包，如图：

         最后没有东西接了，就试图保活，最后保活无望，发送断开连接的握手。

         这个过程其实有好多的http请求，但只有一对的握手，这就是短暂的长连接的优点。

         对于app的http请求来说，其实很多都是一次请求，所以每次请求都会7次握手。

         http维持这个长连接也是需要很大代价的，比如现在的推送技术，就是hold这个长连接，等到有消息的时候可以及时的发出去，就相当于要维持着这个道路，虽然没什么货物需要运输，所以这个推送服务器，游戏服务器之类的都超级贵。

         好了，暂时说到这里，得继续上班码字了。