TCP与UDP的爱恨情仇

很多人都把TCP与UDP拿来比较，那我们今天就来说说他们之间的爱恨情仇！

再奔入主题之前，我们先来看一张图

 

 首先，从这张图中可以发现，tcp、udp属于传输层，那我们就聊聊吧！

首先，我们从以下这几个方面聊：

第一：是什么？

第二：解决了什么问题？

第三：应用场景是什么？

第四：TCP的生命周期？

那我们就开始解答这三个问题吧

我们从广义上来说：

         1) TCP 其实是一个有状态服务（通俗地讲就是有脑子的，里面精确地记着发送了没有，接收到没有，发送到哪个了，应该接收哪个了，错一点儿都不行），TCP头包括：目标端口、源端口、序号、确认序号；

 

        主要有以下这几种特点：

        1、TCP 是面向字节流的，发送的时候发的是一个流，没头没尾；

        2、TCP 提供可靠交付。通过 TCP 连接传输的数据，无差错、不丢失、不重复、并且按序到达；

        3、TCP 是可以有拥塞控制的，它意识到包丢弃了或者网络的环境不好了，就会根据情况调整自己的行为，看看是不是发快了，要不要发慢点；

       2) 而UDP 则是无状态服务（通俗地说是没脑子的，应用让我发多少就发多少，发出去就发出去了）;它的请求头只有源端口、目标端口（为什么只有这两个，我们从他的特性来分析）；

        主要有以下特点：

        1、继承了 IP 的特性，基于数据报的，一个一个地发，一个一个地收；

          （特性：IP 包可不是一个流，而是一个个的 IP 包）

        2、UDP 继承了 IP 包的特性，不保证不丢失，不保证按顺序到达。

          （IP特性：IP 包是没有任何可靠性保证的，一旦发出去，就像西天取经，走丢了、被妖怪吃了，都只能随它去）

        3、像TCP本身是可以有拥堵控制的，而UDP则不会，它会无头脑的听从应用命令；

接下来，我们通过应用场景来聊解决了什么问题，俗话说，不在业务场景下聊技术，都是在耍流氓；

        我们从他们的特性分析，像UDP他是一种无状态，无感知的协议，需要资源少，在网络情况比较好的内网，或者对于丢包不敏感的应用，所以它会适用于什么场景呢？ 对，像视屏，实时游戏应用，他们需要处理速度快，时延低，可以容忍少数丢包，比如我们看个视频，突然卡住了，丢了几帧，其实看视频的人不会有感知，如果连续丢，就会有感知了；

        TCP在我们工作中就会有很多场景，比如：工作中的HTTP请求，HTTPS请求，包括SpringCloud的Feign，他们的底层都是TCP协议，为什么他们对包的要求性非常高，不言而喻，大家都知道，这里我就不过多解释了；

既然我们工作中经常用到TCP，接下来，那我们就细聊一下它；

除了以上我们聊过的TCP相关知识，大家还能想到什么？对，生命周期；TCP的生命周期相对复杂；他需要三次握手四次挥手，但是大家知道为什么是三次握手四次挥手吗？为什么不是一次或者两次？

        如果一次握手，A发起建立连接，B拒绝连接，A不知道，则连接失败；

        如果两次连接，如果A请求建立连接，网络包一入网络深似海，可能走丢可能迷路，A一直接收不到回应，一直重发，过了一段时间，B接收到了迷路的网络包，B就以为建立了连接，但是此时A可能已经挂了，所以两次建立也不成立；

        三次连接，如果A请求建立连接，同样会发出请求连接包，当B接收到了A请求的网络包，会告诉A，我愿意建立连接，给他发送回复包；

       A接收到之后就知道B愿意跟他建立连接；所以没有必要四次五次的握手；

四次挥手也是同样的道理；

建立连接成功后，以下问题我们应该如何处理：

如果建立连接之后，长时间不发数据，如何处理？

开启 keepalive 机制，即使没有真实的数据包，也有探活包

如何保证B接收到的是A发出的网络包？

TCP头包有端口

如何保证这三个包是同一组网络包的？

通过序号（序号是随着时间的变化生成的）

如何维护连接？

双方都会建立一个状态机；

四次挥手还有很多问题：

如果A告诉B想要断开连接，B回复好的之后，B又告诉A我也要断开，直接断开，A还会重复回复B，如何处理？

如果A直接跑路了，A的端口就会空出来，被其他应用占用，则新的应用很可能接收到B的回复包，如何处理？等等一系列问题；等我们下次再一起讨论；

这是本人对UDP、TCP的见解，如有误差，欢迎指正；