嘿，大家好！今天我们来聊聊网络传输中的两位大佬——UDP和TCP。它们就像是交通工具中的跑车和面包车，各有各的特点。

UDP就像跑车，轻快又飘逸。它的报文长度有限，但通过分包传输就能解决大数据的问题。而校验和机制，像是个精准的导航，能发现数据传输中的错误，让你知道数据是否安全到达。

再看看TCP，它就像那个可靠的面包车。三次握手四次挥手的连接管理，让它在可靠性上无可挑剔。而确认应答和超时重传机制，确保数据准确送达，即使网络拥堵也能应对自如。

那问题来了，到底该选谁？如果你在直播或打游戏，用UDP绝对是首选，速度第一。但如果是传文件或发邮件，就把TCP请上车，确保数据完好无损送达。两者各有千秋，关键在于用对场景。

所以，选择UDP还是TCP，得看你的需求是要速度还是可靠性。它们就像是交通工具，看你是要速度还是安全。理解了它们的特点，才能更好地应用在实际中。希望这篇文章能让你对UDP和TCP有更深入的认识，也能帮你做出更明智的选择。毕竟，网络世界需要正确的工具来高效运转！

1.UDP报文

udp是传输层最重要的协议之一。
我们先来看一下udp报文的格式

一个完整的udp应用层数据报其实就是后面的UDP载荷部分
每个端口号在UDP报文里面，取值范围在0-65535，不过< 1024的端口，称为知名端口，给一些名气较大的协议使用的，这部分端口咋们日常中不应该使用。

源ip
源端口：数据从哪里来
目的ip
目的端口：数据到哪里去

1.1报文长度

报文长度 大小是两个字节，表示的范围 0-65535=》64kB
那么UDP豹纹的最大长度就是64KB！！！

那么64KB是大还是小？
在以前64KB算是大的，但是现在很小很小。那么我们如果准备传输一个比较大的数据怎么办？
（1）.把一个大数据拆分成多个部分，使用多个udp数据报来传输，但是比较复杂。
（2）.不用udp，直接使用tcp，就没有限制了

注意：使用udp编程的时候，要注意udp数据报不能太长，否则会有问题。

1.2校验和

网络传输中，并非是很稳定的，可能会出现问题。

那我们怎么判断是否出现错误呢? 这个时候就需要使用“校验和”，我们传输是通过网线传输的，也就是电信号，电信号使用高低电平表示0 1。
但是如果数据在传输过程中遭到外部环境干扰，例如强磁场之类的，就会导致 低电平->高电平 高电平->低电平。

校验和，存在的意义，就是判定一下，当前传输的数据是否出错了。
如果校验和不对，此时的数据一定不对
但是如果校验和对，但是数据也有一定的概率是错误的。
所以为了让校验和能够识别率高一点，计算的时候通常会以数据内容作为参数来进行计算，数据内容发生变化，校验和也会变化。

校验和往往是取内容一部分通过一些算术运算/数学公式变换，得到一个值

发送方，把载荷数据，带入校验和算法中，计算得到一个校验和结果，设为sum1，发送方就将这一串数据发给接收方，接收方得到的既有载荷还有校验和的值，接收方就可以把载荷按照同样的方法，在计算一遍校验和，得到sum2。我们对比sum1和sun2是否相同，如果不相同，数据就会有问题。（咋们一般使用CRC算法）。

2.TCP协议特性

TCP协议特点：
有连接
可靠传输：tcp存在的初心，最核心的机制
面向字节流
全双工

可靠传输：不是说100%能传过去，而是说尽可能传过去，如果传不过去，发送方至少能知道自己传没传过去。
核心机制：在于不管是否收到都会有个应答

2.1确认应答

实现可靠传输的核心机制。
发送方发送一个请求，接受方接收到以后，就会发出一个应答报文（ACK）

但是有的时候不一定会正确的对应上，可能会出现先发后至的情况。

为了解决上述问题，就需要针对消息进行编号！！给发送的消息分配一个“序号”，同时应答报文给出“确认序号”。
真实的TCp数据传输就是引入了序号和确认号。

TCP将每个字节都进行了编号，即为序列号

注意：确认序号的规则 不是说发送方的序号是啥，确认序号是啥 而是取得是发送方发来的所有数据，最后一个直接的在一个字节序号

确认序号1001的含义：
1.<1001的数据，我已经收到了
2.发送方接下里需要发送从1001开始的数据。
接收方就可以通过ack的确认序号，告诉发送发那些数据已经收到了。

2.2超时重传

如果一切顺利，那么就可以直接应答了，但是有的时候会发生丢包，丢包，也是网络上非常典型的情况。

那么为什么会丢包呢？ 发送方和接收方之间是有很多节点的，任何一个节点出错都会导致丢包。每个中间设备都会承担很多转发任务，一旦任务过多，达到上限（上面的流量达到峰值）就会导致数据丢包。
如果包丢了，接收方就收不到数据，自然不会返回ack

发送方等待一段时间后，迟迟接收不到ack，那么发送方就视为数据报丢了，就会重发一遍。

丢包的判定：
1.数据直接丢了，接收方没收到，自然就不会发ack
2.接收方收到数据了，返回的ack丢了
发送方区分不了这两种情况，所以都会重传。
如果是返回的ack丢了，B会受到重复的数据，不过tcp帮助咋们解决了这个问题，接收方会在缓冲区，根据收到的数据，自动去重，保证了应用程序读到的数据只有一份。

TCp针对多个包丢失，处理思路是超时重传，但是每一次丢都会导致，超时等待时间，连续多个重传，无法得到ack就会尝试重置连接，如果重置连接也失败，TCp就会关闭连接，放弃通信了（能重传就重传，重传不了就关闭连接，尽最大可能完成传输）。

tcp怎么实现可靠性的：
确认应答
超时重传

2.3连接管理

连接管理：（tcp最核心的考点）
tcp建立连接：
三次握手 tcp
释放连接：四次挥手
上述这两个过程 和 可靠性 多少有一点关系，但不是最主要的

2.3.1三次握手

握手（handshake）指的是通信双方，进行一次网络交互，相当于客户端和服务器之间。进行了三次交互，建立了连接关系。
syn称为同步报文段，意思就是一方向另一方，申请建立连接

上述过程是内核自动完成的，应用程序干预不了，等连接完成了，服务器accept把建立好的连接从内核拿到应用程序。

那么设么样子的报文属于同步保温呢？
大家观察tcp报文的格式，其中有六个特殊的比特位，这几位默认是为0.
如果变为1，就是有特殊的含义
第二位ACK如果为1，表示当前tcp数据报是一个应答报文
第五位SYN如果为1，表示当前tcp数据报是一个同步报文
如果第二位