计算机网络中socket，TCP，HTTP，长连接等概念的形象比喻，便于理解和记忆

把网络上的客户端需要给服务器发送请求并接收服务器响应这件事，具象化为给仓库退货并换货这件事，可能事情就是这样的：

形象比喻	计算机网络原型
我要给网商的仓库退回商品，并且要求退货	客户端要往服务器发一个请求，并且要接收服务器的回复。
我叫来了一个快递员	发送请求之前需要先建立连接
我开始填快递单，在是否保证送达这一栏，我选择了必达，并且填写了寄件人，寄件地址，收件人，收件地址。	建立TCP连接需要先有socket套接字，套接字准确定义了连接的双方，是用以下5条数据定义的：连接使用的协议，本机IP，本地进程的端口，远程主机IP，远程进程端口。
快递员说：既然保证送达，我先去打探一下，看看能不能到的了那个地方。 我：你不能带着我的东西去打探么？ 快递员：谁知道你要送的东西有多大呢？你要是送个集装箱，我发现到不了然后还得给你抗回来，那我就累死了，只是打探一下的话速度是很快的，要是发现送不了就那咱直接拉倒了，你也不用等了。 我：好吧……	传输数据之前需要三次握手，三次握手保证了客户端和服务端之间的链路是通畅的，客户端能正常发送，服务端能正常接收，并且服务端的响应能正常返回客户端。
快递员拿着我的快递单去了仓库，结果是道路通畅，没有打劫的，虽然中途转了汽车，火车，马车，但是最终可以到达仓库，仓库门卫知道他要去2号门之后表示可以放行，地址里写的仓库门牌号没有问题，2号门里面也有人接应。 2号门的工作人员表示：没问题，我们这个门最近一直开着呢，东西可以随时可以送过来。	TCP第一次握手，从客户端到服务端链路通畅。 从客户端到服务端中间的网络可能经过路由器，交换机等网络节点，通过防火墙，到达指定IP的服务器的指定端口，能连通并且服务器正常接收了该次握手的信息则表示第一次握手成功。
去路已经确认，快递员从仓库回到我这，回来的路上也没什么问题，告诉我说仓库那边可以接收我的货物。	TCP第二次握手，在第一次握手成功的前提下，从服务端到客户端链路通畅，并且客户端可以收到服务端确认反馈的信息则表示第二次握手成功
快递员再次去了仓库，告诉仓库工作人员说仓库的确认消息已经给我带到了，马上准备送货。 通知完仓库之后快递员回到我这准备给我送货。	TCP第三次握手，在第二次握手成功的前提下，客户端给服务端发送确认消息，表示客户端可以收到服务端的确认。 三次握手成功后正式建立连接，三次握手结束。
我开始打包我要退货的东西，期间我问快递员：虽然刚才确认了能送到，但是也有可能道路在你一会出发之前刚刚断了，然后就送不到了吧？ 快递员：确实存在这种可能，其实我也可以现在再跑一遍再次确认，但是这个问题是无穷无尽的，因为我不管确认多少次，最终我总得送货过去，然后可能就这时候路断了。所以一般情况下就跑这么三趟，我们就认为道路是通畅的。这就要求确认的过程必须比较快，时间越长变数越大，所以确认的时候我只能带个口信，不能带你的货物。	TCP的三次握手并不能保证100%的成功率，因为网络的问题是随时发生的。 TCP协议认为，一般情况下三次的握手就可以绝大程度的保证网络环境是可靠且稳定的。 可见在网络环境多变的客观情况下，三次握手的时间越短，可靠性就越高。为了减少三次握手的时间，握手的时候只携带了很少的信息。
快递员拿着我的货物送到了指定的仓库，仓库的工作人员开始检测货物并研究，结论是不予换货，让快递员给我带个口信。	客户端往服务端发送请求，服务端进行处理，并反馈给客户端。
得知不能换货之后我十分生气，于是我让快递员也帮我捎个口信：黑心网商！ 快递员：捎不了啊。 我：为啥？ 快递员：我们的一次服务在送完东西回来之后就结束了，再往那边送就算是第二次服务了。虽然我们可以支持多次送的服务，但是还不完善，如果客户不要求就默认只送一次。 我：好吧……	HTTP1.0协议默认是短连接，在请求发送并返回之后连接就会断开。 HTTP1.0已经有了keep-alive的持久连接模式，但不是默认的。
过了几天我又把快递员叫来了，快递员一来就跟我说：现在我们这边服务升级了，默认可以送多次了， 只不过每次送的时候你还是需要填单子。	HTTP1.1默认使用了持久连接，可以在一次连接时间内处理多次请求
快递员：而且现在正在试点服务，速度更快，而且可以支持一次送货回来之前就送下一次，我可以给你送的货物上编个号，送货回来你也不会搞错了。	HTTP2.0使用多路复用技术，多个请求可以并发处理，每个请求都标记了一个唯一的id，便于在客户端接收反馈的时候区分。 另外HTTP2.0在HTTP1.1的基础上做了很多的优化，效率大幅提高。
我：这回不用，我做了一面锦旗，上书“黑心网商”，你帮我给送过去，这回不用保证必达了，也不用来回来去确认了，送不到你就直接给我扔了吧。	UDP协议和TCP协议不同，是面向数据报的协议，不提供可靠性，没有三次握手，不保证数据到达，没有超时重发，传输速度非常快。
快递员发现路断了，没送到	网络无法连接，请求发送失败
快递员路上堵车了，没送到	网络拥堵，请求发送失败
快递员汽车转火车的时候被打劫了，没送到	请求包被劫持，请求发送失败
快递员到仓库发现门卫不让进，没送到	请求被防火墙拦截，请求发送失败
快递员进了大门发现2号门没开，没送到	请求的端口没打开，请求发送失败
快递员到了2号门发现工作人员不在，没送到	端口没有对应的服务监听，请求发送失败
至于商家的反馈，我到现在终于没有见，大约锦旗的确是没送到。	UDP协议不提供可靠的服务
随着我给仓库退货越来越多，仓库给我开通了专门服务，我和仓库协商好货物打包的形式，然后我把货物放在自家门口，快递员就自动来拿走并且送到仓库，感觉就像我直接放在了仓库门口一样，十分方便。	RPC服务和HTTP的服务不同，RPC服务由双方协定接口定义，由服务端提供实现，由客户端调用，RPC框架提供远程调用方式。 对客户端来说，调用远程接口就像是调用本地接口一样。
对于退货这事，不同的人关注的点不一样。	计算机网络有分层结构，各层一起运作才保证了计算机网络的正常运转。
电商公司往往关注用户退货业务本身，便利程度，用户体验等	应用层，是和用户关系最近，最形象化的一层
物流公司往往关注货物配送这件事，速度，中转，时效等。	传输层，处理端到端的信息传送。
城市规划部门往往关注道路的规划调整，小区和门牌号的规划统筹等。	网络层，为数据在网络中的传输提供流，拥塞控制，网络设备地址等基础服务。

 

由此可见，一些概念理解了之后就发现其实都是一回事。