网络协议中HTTP,TCP,UDP,Socket,WebSocket的优缺点/区别
先说一下网络的层级：由下往上分为 物理层、数据链路层、网络层、传输层、会话层、表示层和应用层
1、TCP和UDP
TCP：是面向连接的一种传输控制协议。属于传输层协议。TCP连接之后，客户端和服务器可以互相发送和接收消息，在客户端或者服务器没有主动断开之前，连接一直存在属于长连接。
优点：安全、传输数据无大小限制、准确可靠，先发先至
缺点：效率低，不能做离线任务、连接有耗时
UDP：是面向非连接的用户数据报协议。属于传输层协议。所谓的无连接就是在传输数据之前不需要交换信息，没有握手建立连接的过程，只需要直接将对应的数据发送到指定的地址和端口就行。
例：我不管你要不要，我就一直发给你。就好比QQ消息一样，当你离线的时候仍然可以收到消息
优点：可以传输大文件，速度快，效率高
缺点：不安全，容易丢包（数据）、先发未必先至
补充：
TCP协议建立需要三次握手，断开连接需要四次挥手
第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
为什么需要三次握手：避免丢包（数据丢失）
握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据
断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次握手”
因为当A给B发送消息时，只有B同意了才能传输。由此可以看出HTTP协议是基于TCP的。因为当你在向后台请求数据的时候，后台必须同意，你才可以请求，否则都是白扯
2、HTTP
HTTP是基于TCP协议的应用的超文本传输协议，属于应用层的协议。请求时需建立TCP连接，请求结束后断开连接，完成一次请求/响应操作。
HTTP协议永远都是客户端发起请求，服务器回送响应，这样就限制了使用HTTP协议，无法实现在客户端没有发起请求的时候，服务器将消息推送给客户端。
HTTP协议是一个无状态的协议，同一个客户端的这次请求和上次请求是没有对应关系。
优点：基于应用级的接口使用方便
缺点：(1)传输速度慢，数据包大。(2)如实现实时交互，服务器性能压力大。(3)数据传输安全性差
注意：服务器不会主动给客户端发送数据。
3、Socket
Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API）
Socket连接需要一对套接字，一个运行于客户端，另一个运行于服务端！之间的连接分为三个步骤：服务器监听，客户端请求，连接确认。
（1）服务器监听：是服务端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态。
（2）客户端请求：是由客户端的套接字提出连接请求，要连接的目标是服务端的套接字。所以客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。
（3）连接确认：是指当服务器端套接字监听到或者说接收到客户端套接字的连接请求，它就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发给客户端，一旦客户端确认了此描述，连接就建立好了。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。
4、WebSocket
WebSocket也是一种协议，并且也是基于TCP协议的。可以理解为WebSocket是HTTP的优化，但WebSocket不仅仅在Web应用程序上得到支持。
WebSocket虽然是html5的产物，但也不仅仅局限于浏览器的应用程序，许多语言都提供了WebSocket的支持，比如C，C++，Python等
在WebSocket概念出来之前，如果页面要不停地显示最新的价格，那么必须不停地刷新页面，或者用一段js代码每隔几秒钟发消息询问服务器数据。
而使用WebSocket技术之后，当服务器有了新的数据，会主动通知浏览器。 如当服务端有新的比特币价格之后，浏览器立马接收到消息。
webSocket优点：
1. 节约带宽。不停地轮询服务端数据这种方式，使用的是http协议，head信息很大，有效数据占比低， 而使用WebSocket方式，头信息很小，有效数据占比高。
2. 无浪费。 轮询方式有可能轮询10次，才碰到服务端数据更新，那么前9次都白轮询了，因为没有拿到变化的数据。 而WebSocket是由服务器主动回发，来的都是新数据。
3. 实时性，考虑到服务器压力，使用轮询方式不可能很短的时间间隔，否则服务器压力太多，所以轮询时间间隔都比较长，好几秒，设置十几秒。 而WebSocket是由服务器主动推送过来，实时性是最高的。
Websocket的作用
在讲Websocket之前，我就顺带着讲下 long poll 和 ajax轮询 的原理。
ajax轮询
首先是 ajax轮询 ，ajax轮询 的原理非常简单，让浏览器隔个几秒就发送一次请求，询问服务器是否有新信息。
场景再现：
客户端：啦啦啦，有没有新信息(Request)
服务端：没有（Response）
客户端：啦啦啦，有没有新信息(Request)
服务端：没有。。（Response）
客户端：啦啦啦，有没有新信息(Request)
服务端：你好烦啊，没有啊。。（Response）
客户端：啦啦啦，有没有新消息（Request）
服务端：好啦好啦，有啦给你。（Response）
客户端：啦啦啦，有没有新消息（Request）
服务端：。。。。。没。。。。没。。。没有（Response） ---- loop
long poll
long poll 其实原理跟 ajax轮询 差不多，都是采用轮询的方式，不过采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，客户端发起连接后，如果没消息，就一直不返回Response给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。
场景再现
客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request）
服务端：额。。 等待到有消息的时候。。来 给你（Response）
客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request） -loop
从上面可以看出其实这两种方式，都是在不断地建立HTTP连接，然后等待服务端处理，可以体现HTTP协议的另外一个特点，被动性。
何为被动性呢，其实就是，服务端不能主动联系客户端，只能有客户端发起。
简单地说就是，服务器是一个很懒的冰箱（这是个梗）（不会、不能主动发起连接），但是上司有命令，如果有客户来，不管多么累都要好好接待。
说完这个，我们再来说一说上面的缺陷（原谅我废话这么多吧OAQ）
从上面很容易看出来，不管怎么样，上面这两种都是非常消耗资源的。
ajax轮询 需要服务器有很快的处理速度和资源。（速度）
long poll 需要有很高的并发，也就是说同时接待客户的能力。（场地大小）
所以ajax轮询 和long poll 都有可能发生这种情况。
客户端：啦啦啦啦，有新信息么？
服务端：月线正忙，请稍后再试（503 Server Unavailable）
客户端：。。。。好吧，啦啦啦，有新信息么？
服务端：月线正忙，请稍后再试（503 Server Unavailable）
--------------------------
言归正传，我们来说Websocket吧
通过上面这个例子，我们可以看出，这两种方式都不是最好的方式，需要很多资源。
一种需要更快的速度，一种需要更多的'电话'。这两种都会导致'电话'的需求越来越高。
哦对了，忘记说了HTTP还是一个无状态协议。（感谢评论区的各位指出OAQ）
通俗的说就是，服务器因为每天要接待太多客户了，是个健忘鬼，你一挂电话，他就把你的东西全忘光了，把你的东西全丢掉了。你第二次还得再告诉服务器一遍。
所以在这种情况下出现了，Websocket出现了。
他解决了HTTP的这几个难题。
首先，被动性，当服务器完成协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端啦。
所以上面的情景可以做如下修改。
客户端：啦啦啦，我要建立Websocket协议，需要的服务：chat，Websocket协议版本：17（HTTP Request）
服务端：ok，确认，已升级为Websocket协议（HTTP Protocols Switched）
客户端：麻烦你有信息的时候推送给我噢。。
服务端：ok，有的时候会告诉你的。
服务端：balabalabalabala
服务端：balabalabalabala
服务端：哈哈哈哈哈啊哈哈哈哈
服务端：笑死我了哈哈哈哈哈哈哈
就变成了这样，只需要经过一次HTTP请求，就可以做到源源不断的信息传送了。（在程序设计中，这种设计叫做回调，即：你有信息了再来通知我，而不是我傻乎乎的每次跑来问你）
这样的协议解决了上面同步有延迟，而且还非常消耗资源的这种情况。
那么为什么他会解决服务器上消耗资源的问题呢？
其实我们所用的程序是要经过两层代理的，即HTTP协议在Nginx等服务器的解析下，然后再传送给相应的Handler（php等）来处理。
简单地说，我们有一个非常快速的接线员（Nginx），他负责把问题转交给相应的客服（Handler）。
本身接线员基本上速度是足够的，但是每次都卡在客服（Handler）了，老有客服处理速度太慢。，导致客服不够。
Websocket就解决了这样一个难题，建立后，可以直接跟接线员建立持久连接，有信息的时候客服想办法通知接线员，然后接线员在统一转交给客户。
这样就可以解决客服处理速度过慢的问题了。
虽然接线员很快速，但是每次都要听这么一堆，效率也会有所下降的，同时还得不断把这些信息转交给客服，不但浪费客服的处理时间，而且还会在网路传输中消耗过多的流量/时间。
但是Websocket只需要一次HTTP握手，所以说整个通讯过程是建立在一次连接/状态中，也就避免了HTTP的非状态性，服务端会一直知道你的信息，直到你关闭请求，这样就解决了接线员要反复解析HTTP协议，还要查看identity info的信息。
同时由客户主动询问，转换为服务器（推送）有信息的时候就发送（当然客户端还是等主动发送信息过来的。。），没有信息的时候就交给接线员（Nginx），不需要占用本身速度就慢的客服（Handler）了。
