2020-01-09感谢回答！我的表述有误，其实我是想知道，服务器推送技术，像websock这种技术，其实就是服务器和客户端建立一条连接，建立连接可以基于TCP也可以基于UDP，但是却很少见到基于UDP的上层应用协议。
如果说是因为TCP可靠性，时序性，保活这些特性才选择TCP，那这些特性转移到应用层这一层来维护也非不可。
那究竟是何原因导致在服务器推送技术领域中，没有广泛应用的基于UDP的上层应用协议呢？作者回复: 我是这样认为的：
就像你说的，比如可靠性，保序性，拥塞控制等等，完全是可以放到应用层来做的。
但是，对应用层来说，它们关心的内容，不需要，也不应该包括这些传输方面的基本特性，或者说，已经有传输层的TCP把这些事做好了。而协议的设计者，关心他/她设计的协议想解决的问题，这些传输方面的特性，拿来用就可以了，而不需要再实现一遍。
往大了说，软件分层的目的最大目的，就是解耦。解耦之后“谁”做“什么事”就是每一层的职责，7层/5层模型里的传输层也一样。 1 1
2019-09-16谢谢老师给这么多资料 1- 2020-01-06服务端能够推送消息给客户端，就需要事先知道客户端开放的端口。这就不难理解各种服务端推送技术了。
- 2020-01-06对于服务端推送技术，之前有考虑过，有一个疑问，为何客户端和服务器端为何不直接通过UDP进行通信呢？换句话说，为何在服务器推送技术中没有一种 比较被广泛应用的+基于UDP的 应用层协议呢？
作者回复: 其实基于 UDP 的应用层协议也有一些，常听说的比如有 DHCP。之所以我们平时接触的不多，主要还是由它们的特点所决定的，你可以看一下 https://en.wikipedia.org/wiki/User_Datagram_Protocol#Comparison_of_UDP_and_TCP 比如其中提到的可靠性和有序性就是我们一般应用层的基本通信要求。
另外一个，HTTP/3 也会使用 UDP 代替 TCP，主要原因还是在物理设备改进，传输质量提升了以后，出于性能的考虑。可以参见：https://thenewstack.io/http-3-replaces-tcp-with-udp-to-boost-network-speed-reliability/ 
2019-11-15老师我看不懂英文资料，是不是多看看就会有感觉了？有没有啥秘诀。。。作者回复: 最佳实践那一章的最后一篇特别放送，我会讲一讲程序员怎么学英语。可以期待一下。
2019-10-22
Location:
wss://echo.websocket.org
Message:
Rock it with HTML5 WebSocket
这个的操作方式我没太看懂，老师可以帮忙解释一下吗？展开作者回复: 这是你打开 https://www.websocket.org/echo.html 的时候，它已经默认帮你填好的内容
2019-10-16老师您好，请教个问题。
我想让pad和PC之上的两个应用全双工通信，想到两种办法。
一是和服务器建立websocket连接，让其作为通讯的中转，但是这种方法网络不好的情况下容易挂掉；
为了解决办法一的问题，想了第二个方法，在PC上启动一个websocket server，让pad应用与PC应用内启的这个server建立连接，实现局域网内部全双工通信，但这有个限制，必须要求pad和PC连到同一局域网下。但是因为PC可能连接着网线，也可能在用无线网络，且无线网络不止一个，我检测不出来PC和pad连接的是否是同一子网。
所以想问问老师，有没有什么办法能解决上述两个办法的问题？展开
2019-09-29老师你好，我有个疑问，是关于comet: 客户端必须在服务端结束当次传输后才能向服务端发送消息，服务端会采用分块传输，也就是"我说完你再说"，客户端这时候有新的请求就只能等着才能发送？要是长时间不结束客户端的请求就没法发送了嘛？作者回复: 好问题，是这样的，HTTP/1.1 Comet 的一个局限性就在这里，也就是说，传输是单工的，从协议的角度来说，服务端的响应分多次返回，因此这个过程中，返回并没有传输完，那么对于该次 HTTP 连接来说，客户端也就无法发送新的请求。
当然，除了升级到 HTTP/2 或者采用其他技术以外，对于这个问题本身，还是有一些改进办法的，你可以思考一下。:)
2019-09-25思考题 1：
工作中主要用到 Pull，还没有使用到 Push。
思考题 2：
Push 的优势还有：
- 客户端可以提前 cache push 过来的内容，在其他页面上使用。
- 服务端可以决定 push 的优先级，把影响 performance 的重要资源优先 push。
- 客户端可以根据自己的情况，选择是否接受 push，或者限制数量。
Pull 的 stateless 带来的优势强大，其他的优势还没有查到。展开作者回复: 👍，你也可以看看其他回答
- 2019-09-24思考题：
1. 在实际的项目中用 pull 的例子比较多，没怎么接触过 push，感觉上 push 的话是不是会相对来说复杂些，因为要维护不同 client 的状态；相对来说 pull 的话，只用基于 request 参数做相应的 response 即可
2. 这里我在想，pull 的无状态优势只是对于服务器端来说的，如果在客户端，对于 pull 来说，是不是需要保存服务器的状态？另外，由于 push 是有状态的，那么状态在服务器上的存储会不会成为一个难题？从分析来看，pull 的缺点是 push 的优点，push 的缺点又是 pull 的优点，我想到了前一章我们讲过对称加密和非对称加密，对称加密高效但是 key 不易分享，非对称加密 key 易分享但是不高效，因此 HTTPS 将他们两个做了个结合。这里或许我们也可以将 push 和 pull 结合起来使用，比如，消息更新的时候，服务器端使用 push 通知客户端更新资源，然后客户端使用 pull 获取资源，这样会不会比单一使用 pull 或 push 更好？
很赞同老师说的，学习就是需要去用自己学过的东西对比理解和分析新学的东西，深度理解他们的本质思想，以及区别和共同点，这样才能形成知识体系，这会对新知识的掌握更快，对技术也会有更高维度的认识
关于学习全栈专栏的认识：
学完了这几章，感觉自己知道的东西还是太少，老师推荐的文章都很好，也很有深度，但是有些文章真的没有时间去仔细推敲，我在想，先把整个专栏跟下来，对全栈知识有个宏观的认识，然后在仔细阅读这些著作，老师你觉得这样是否可行呢？
收获很多，谢谢老师展开作者回复: 感谢回复。
1. 正确。
2. 不一定。而且即便客户端需要保持服务端状态，也比服务端保持客户端状态，要简单得多（数量上是 1 和 N 的关系，在横向扩展的时候，这个 N 就可能成为瓶颈）
你说的这个 push-pull 结合的方式很好，其实它是一种非常常见的实现方式，你可以想想互联网有哪些应用。:) 1 
2019-09-22请问今天的课堂实例如果要自己用代码来实现，前后段代码是否有相关的实例代码可以做参考？作者回复: 你可以自己尝试实现一个最简单的 Comet：
客户端，你甚至都不用写 JavaScript，一个普通的 get 请求即可——浏览器直接访问某一个服务端暴露的接口（URL）。
服务端则是往响应中写数据，使用按块传输，返回类型设置为 plain/text，随便写一点数据并 flush，然后 sleep 10 秒，再写一点并 flush，再 sleep 10 秒，如是多次，这样可以模拟多次返回。
这样，你会看到浏览器一直在加载，页面十秒十秒地新增新的内容。
2019-09-18之前一个项目中IM是用websocket实现的。
2019-09-17老师你好，文章写的真好？但是我有点疑问，就是看comet是一个单工的，也就是“我说完了，你再说”。但是他还是一个基于HTTP协议的，我的理解就是keep-alive。那问题来了我要是用HTTP2.0的话是不是可以把comet转化为双工的呢，因为HTTP2.0是双工通讯？作者回复: HTTP/2 确实有了专门的 server push，但这个最主要用来解决资源的预加载问题。因此，如果要完全替代 Comet，实现任意时刻的推送，可以使用 SSE 等技术，或者是将 server push 和 SSE 等技术结合起来（即让浏览器端预留一个回调来响应服务端的推送）。
2019-09-16第一个问题，我们的后台系统里的二维码扫码登录用的就是 Pull 的形式，每隔一段时间就去轮询有没有扫码，有没有确认登录，对于后台这类系统是可以满足需求的；在调度系统里的状态实时推送里用到了 WebSocket 技术，可以实时反馈任务的执行情况。
第二个问题，Push 模型的优势是高效性和实时性，Pull 模型的优点除了无状态外，优势可能是实现起来更方便，不用引入新的框架作者回复: 对于大多数分布式的系统来说，Pull 确实要比 Push 实现起来方便一些，但是也不绝对。至于你说的“是否引入新的框架”这个描述比较模糊，两种方式和是否引入框架没有必然联系。
2019-09-16老师讲得真好。
提问🙋，Comet这种假PUSH方式，由客户端发起的HTTP请求服务器不释放，但是会受超时限制吧？作者回复: 非常好的问题！
是的，完全正确。你可以考虑这样几点：
1. 客户端和服务端，还有网关等中间节点，都要商定好一个最大的超时时间。并且，业务端配置的超时时间要稍短于其它，以留足余量。
2. 服务端即便没有消息需要推送，也要定期返回一个无业务意义的消息，以避免超时发生。
3. 客户端如果在若干个推送周期后，可以结束连接，休息一段时间，再重新连接。
2019-09-16Push 的模型
优点：响应及时
缺点：
a.如果客户端接收不及时，造成数据包堆积；
b. 需要客户端做流控处理；
Pull模型
优点：
a. 提取消息方便
b. 传输失败不用重试
缺点：实时性差展开作者回复: 感谢分享！
对于 Push 模型，你说的内容都是正确的，就提一点，对于你提到的数据包堆积和流控的问题，可以引入第三方的消息队列服务来协调消息发布者和订阅者，来缓解你说的问题。
对于 Pull 模型，“传输失败不用重试”这个不对，因为是不是重试并非 Push 或 Pull 的区别，二者都可以重试，也都可以不重试，取决于设计。其它正确。
当然，这是一个开放性问题，还有其它的优缺点，你也可以看看其他人的答复。
2019-09-16四火老师讲得真好，服务端推送模型最后都可以看作是Comet和WebSocket的变形。作者回复: 谢谢。
很多技术都是相通的，学习全栈技术都是可以用类比的方式进行的。- 2019-09-161)公司一个简单的聊天业务系统！就用了push模型！
2)push模型处理信息比poll稍微复杂一些！存在解包封包！需要定一套消息结构！作者回复: 感谢分享！
关于第 2) 个答复：解包和封包其实并不是 push 和 poll 的本质区别，poll 也可以由解包封包，也可以定义一套消息结构。 1