UDP

UDP全称是User Datagram Protocol ，即用户数据报协议。他是一个简单高效但是不保证可靠性的传输协议。应用层送下来的报文，只要加上UDP的首部就直接发了。

image.png

UDP具有以下四个特点：

不需要握手挥手效率高
不可靠传输实时性高
可以实现多播
有差错检测

TCP

TCP全称是Transmission control protocol，即传输控制协议。
TCP连接的端点是套接字：socket = IP:PORT

Socket，是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口(API)。
Web socket，是应用层协议，WebSocket的目的是取代HTTP在双向通信场景下的使用，而且它的实现方式有些也是基于HTTP的（WS的默认端口是80和443）
see：https://juejin.cn/post/6942358900171603975

有时候会出现端口冲突，如果是针对同一个应用程序在相同端口上启动服务而冲突，很好理解，但是如果是不同应用程序，相同端口号，会冲突吗？
会。若是进程先绑定一个端口号，而后在fork一个子进程，这样的话就能够是实现多个进程绑定一个端口号，可是两个不一样的进程绑定同一个端口号是不能够的。

TCP的可靠性

怎样才能称之为“可靠”？

传输信道不产生差错，我传给你什么，你收到的就是什么，不会多不会少，也不会不一样；
不管我发数据发的多快，你总是能有条不紊地收到数据。

TCP 首部

image.png

可靠性的工作原理

停止等待协议
连续ARQ协议

实现可靠传输

以字节为单位的滑动窗口
超时重传的时间选择
选择确认SACK

流量控制

拥塞控制

慢开始
快重传
快恢复

运输连接管理

三次握手

image.png

为什么一定要三次握手，两次不行吗？拿一个对山歌的例子来举例。我在这个山头，贝贝在对面山头。

贝贝：巧儿，你听得到吗？
我：我听得到
贝贝听到我的回应之后，开始唱歌：“山歌好比春江水...”

另外一个实际中的例子：在zoom开会的时候，轮到我发言时，我会先说：Can you hear me?
如果我听到有人说yes, 那么我就直接开始进入正题了。

这个例子中，我用的也是两次挥手。
那么明明两次挥手就可以达到目的，为什么还要第三次呢？

image.png

拿对山歌的例子来说
贝贝：巧儿你听得到吗？（这条消息阻塞在网络中了）
---- end
贝贝：巧儿你听得到吗？（再次呼唤，成功送达）
我：听得到
贝贝：好，那我要开始唱了
...
歌唱结束了，我们挥手告别了，突然间之前阻塞的消息送达了，我有听到了贝贝在叫我：巧儿你听得到吗？
我：听得到
尽管我回应了，但是BB已经不可能回应我了，因为这是条失效的信息，而我会很生气，为什么教一下我又不说话了，让我干耗着。

拿zoom meeting的例子来说，这就好比，假设我的网络不好，我问了一句can you hear me之后，就卡住了，过了很久，我都放弃了，退出了zoom，然而在我刚退出zoom的时候，对方听到了我的呼唤，并答复我他听得到，如果此时就正式建立连接的话，那么对方一定会纳闷我为什么一直不说话，找他到底干嘛，对方也很忙，他不应该浪费自己的资源一直等我回应。

解决办法就是再增加一次确认，只有当对方再次收到我的确认的时候才会正式建立连接。

四次挥手

image.png

我：贝贝我嗓子哑了，请求断开我这边的连接。你可以继续唱，我可以听到，但是我不能唱给你听了。
贝贝：知道了，我再唱2首
两首唱完后...
贝贝：我唱完了。我嗓子也哑了，不如我们今天就唱到这里吧？
我：行
贝贝：我走了
我：我不会立马走，我要再等2MSL(4分钟)再走。

为什么要等待2MSL?
我要告知贝贝，我清楚了他要走的消息，如果这条消息没有及时送达，我还有回旋余地重新发送。

拿ZOOM 的例子来说，假设我和他开会中途，我突然有事要离开了。

我: 我有事我要先drop了，如果有事请在skype给我留言。
他: 好的。

我听到他说好之后，就drop了，但是我的skype还登着，所以我还能收到消息。
期间对方把剩余的会议内容陆续都发到了我的skype上，最后会开完了

他：会议结束了，会议内容发到你的skype了，你确认一下，你确认无误的话我就下线了。
我：确认完毕，你可以下线了。

他收到我的消息后就会从skype下线，然而我不会立马下线，我要防止刚发的消息他收不到一直在等我，如果一段时间我看到他还没下线，我会重新提醒他一次。

每发送一个HTTP请求就要进行一次完整的三次握手,四次挥手吗？那样的话会导致效率很低。
HTTP1.1默认使用持久连接（persistent connection），在一个TCP连接上也可以传输多个Request/Response消息对，只要没有人提出断开，那就不会断开，这样在一定程度上可以优化。
see: https://zhuanlan.zhihu.com/p/388270712