长连接与短连接_基于tcp协议的移动端im仍然需要心跳保活

前言：

        一个网页中包含了很多的资源，比如文本，图片，音频，视频等等。

        客户端发送一次请求，服务器的一次响应只能发送一个资源。

短连接

        短连接：一个信道只能发送一次请求和响应，服务器关闭连接。

长连接 

         长连接：一个信道能发送多个请求和响应。

 长连接的好处：

        由于一个网页中含有很多资源。想获取一个网页，如果使用短连接一次只能发送一个资源，要获取多个资源，需要是客户端和服务器多次建立连接和断开连接。建立连接和断开连接需要时间(三次握手和四次挥手)和空间(数据结构的建立)的成本。

        长连接减少了多次连接和断开连接的成本。提高了效率。

        http1.0使用的是短连接，http1.1使用的是长连接。由于以前的网页没有现在这么复杂，所以之前使用的都是短连接。现在网页复杂了所以出现了长连接。

问题

怎么确定使用长连接还是短连接

        在http协议的报头Header中，有一个属性connection，对应keep-alive，表示支持长连接。

用fiddler抓包：

 怎么区分每个请求

        首先，发送请求和响应并不是一条一条发的，而是一次性发很多条请求。怎么区分一个一个的请求？

        在http协议报文请求的响应格式。

         当读到空行，说明报文的报头和状态行读完了。

        报头中有一个content-length对应的字节数，表示正文字节数，按照这个读完说明一个请求读完了。

        响应的格式相同，相同方法确定一个一个的响应。

数据是一批一批发，会不会发生乱序？

        数据一批一批发，但是可能某些数据选择网络路径不同，或者阻塞在网络中了，会不会导致应用层收到的数据是乱序的？

        HTTP协议是建立在TCP协议上的，TCP协议是有可靠性保证的，TCP保证了数据发过来不是乱序的。

怎么保证？

        TCP是字节流的，按字节发送。而在TCP报文中有一个32位序号，会将每一个字节编写序号，虽然收到数据时是乱序的，但是收到数据后，TCP会将数据排好序，再交付给应用层。        

        具体细节请看博客：应用层协议(http)和网络层协议(TCP和UDP)中的TCP协议，介绍报文的序号这一段。

今天的文章长连接与短连接_基于tcp协议的移动端im仍然需要心跳保活分享到此就结束了，感谢您的阅读。