HTTP系列之HTTP概念解释

我不是女神ヾ 2022-06-11 07:36 231阅读 0赞

在探索过程中，发现了这么几个混淆的概念：  
**1.无连接与面向连接**

出现历史：

> HTTP协议产生于互联网，因此服务器需要处理同时面向全世界数十万、上百万客户端的网页访问，但每个客户端（即浏览器）与服务器之间交换数据的间歇性较大（即传输具有突发性、瞬时性），并且网页浏览的联想性、发散性导致两次传送的数据关联性很低，如果按照上面的方式则需要在服务器端开的进程和句柄数目都是不可接受的，象paranoid945所说的，大部分通道实际上会很空闲、无端占用资源。因此HTTP的设计者有意利用这种特点将协议设计为请求时建连接、请求完释放连接，以尽快将资源释放出来服务其他客户端。  
> 随着时间的推移，html页面变得复杂了，里面可能嵌入了很多图片，这时候每次访问图片都需要建立一次tcp连接就显得低效了。因此Keep-Alive被提出用来解决效率低的问题。  
> 这样一来，客户端和服务器之间的HTTP连接就会被保持，不会断开（超过Keep-Alive规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接。

面向连接和无连接：

> 面向连接服务所谓连接是两个对等实体在通信前所执行的一组操作。包括申请存贮器资源，初始化若干变量，进行通信参数的协商等。面向连接服务与人们打电话类似，先通过呼叫操作获得一条可通话的电路，然后再通话，通话完毕再挂机，释放所占用的电路。面向连接服务也要经过三个阶段：数据传数前，先建立连接，连接建立后再传输数据，数据传送完后，释放连接。面向连接服务，可确保数据传送的次序和传输的可靠性。无连接服务类似于日常生活中书信的往来。它仅具有数据传输这个阶段。书信来往过程中，仅要求写信人在工作，而无需收信人在工作。类似地，无连接服务中，只要发送实体是活跃的，通信便可进行。无连接服务由于无连接建立和释放过程，故消除了除数据通信外的其它开销，因而它的优点是灵活方便、迅速，特别适合于传送少量零星的报文，但无连接服务不能防止报文的丢失、重复或失序。

总结

> 无连接：应用层面传输信息后没有连接  
> 短连接：http0.9时用的，每个HTTP请求都要经历一次DNS解析、三次握手、传输和四次挥手。反复创建和断开TCP连接的开销巨大，在现在看来，这种传输方式简直是糟糕透顶。  
> 长连接：人们认识到短连接的弊端，提出了持久连接的概念，在HTTP/1.0中得到了初步的支持。

1.  http是无连接的，tcp是面向连接的，UDP是无连接的。TCP的面向连接是基于网络底层的数据传输。HTTP的无连接是基于应用层面的沟通交互。
2.  这三个概念太容易混淆了，其实http本身是无连接的；而一般web应用http协议的下层协议是tcp协议，其实说长连接短连接说的都是http控制tcp的方式；而另外的udp也确实是无连接的，跟http的无连接其实是两码事，udp其实说的是发送的方式。
3.  Tcp都已经连接上了，所以http只要控制就好了，无需再开辟通道；

详细介绍：  
[https://www.zhihu.com/question/51996213][https_www.zhihu.com_question_51996213] http是无连接而tcp是面向连接的  
[https://zhidao.baidu.com/question/569437163.html][https_zhidao.baidu.com_question_569437163.html]  
[http://blog.csdn.net/shenquanxi/article/details/6689463][http_blog.csdn.net_shenquanxi_article_details_6689463] （很全的基本知识）

**2.无状态**

> 【无状态】：  
> 1.协议对于事务处理没有记忆能力  
> 2.对同一个url请求没有上下文关系  
> 3.每次的请求都是独立的，它的执行情况和结果与前面的请求和之后的请求是无直接关系的，它不会受前面的请求应答情况直接影响，也不会直接影响后面的请求应答情况  
> 4.服务器中没有保存客户端的状态，客户端必须每次带上自己的状态去请求服务器  
> 5.人生若只如初见

大家看完这个大概就是知道无状态表示的到底是什么了，但是为什么这种概念并没有完全普及起来呢，主要还是因为之前的应用主要还是得靠状态来做一些验证、安全等，所以直到最近rest火起来，rest能够把http的无状态特性彻底发挥出来。  
先来看看之前www应用（这个用到http最多的应用为什么没有说成是无状态的呢）？

> http和web应用（www）的区别  
> 1.通过增加cookie和session机制，现在的网络请求其实是有状态的  
> 2.在没有状态的http协议下，服务器也一定会保留你每次网络请求对数据的修改，但这跟保留每次访问的数据是不一样的，保留的只是会话产生的结果，而没有保留会话。  
> 在Session  
> ID可以被认为是一个用来标识某一会话状态的Key，将其传递给服务器端意味着这样一个请求：“请帮我取出这个状态信息”，也就是说这个请求假设响应方保有着状态信息。由于与某一特定请求相关的状态属于应用状态，而RESTful架构要求任何此类状态由请求方负责提供，所以传递Session  
> ID被认为是unRESTful的做法。反过来，user  
> credential作为一种应用状态，是被期望由请求方提供的，所以在请求中传递user  
> credentials（姑且忽略安全性问题）是符合RESTful架构规范的。

参考：  
[http://www.cnblogs.com/bellkosmos/p/5237146.html][http_www.cnblogs.com_bellkosmos_p_5237146.html]  
[http://blog.csdn.net/Jmilk/article/details/50461577][http_blog.csdn.net_Jmilk_article_details_50461577]  
[https://zhidao.baidu.com/question/584683373.html][https_zhidao.baidu.com_question_584683373.html]

3.http与tcp/ip （这个其实大家不用看也OK，科班出身的人应该都知道）

好多人好像把http和web连接给混淆了  
把tcp和http给混淆了  
把tcp/ip和tcp、ip混淆了  
长连接、短连接、无连接

参考：  
[http://blog.csdn.net/jenminzhang/article/details/47017741][http_blog.csdn.net_jenminzhang_article_details_47017741] [http://www.cnblogs.com/renyuan/archive/2013/01/19/2867720.html][http_www.cnblogs.com_renyuan_archive_2013_01_19_2867720.html]  
tcp握手协议：[http://blog.csdn.net/changcsw/article/details/52103640][http_blog.csdn.net_changcsw_article_details_52103640]

[https_www.zhihu.com_question_51996213]: https://www.zhihu.com/question/51996213
[https_zhidao.baidu.com_question_569437163.html]: https://zhidao.baidu.com/question/569437163.html
[http_blog.csdn.net_shenquanxi_article_details_6689463]: http://blog.csdn.net/shenquanxi/article/details/6689463
[http_www.cnblogs.com_bellkosmos_p_5237146.html]: http://www.cnblogs.com/bellkosmos/p/5237146.html
[http_blog.csdn.net_Jmilk_article_details_50461577]: http://blog.csdn.net/Jmilk/article/details/50461577
[https_zhidao.baidu.com_question_584683373.html]: https://zhidao.baidu.com/question/584683373.html
[http_blog.csdn.net_jenminzhang_article_details_47017741]: http://blog.csdn.net/jenminzhang/article/details/47017741
[http_www.cnblogs.com_renyuan_archive_2013_01_19_2867720.html]: http://www.cnblogs.com/renyuan/archive/2013/01/19/2867720.html
[http_blog.csdn.net_changcsw_article_details_52103640]: http://blog.csdn.net/changcsw/article/details/52103640