网络演进（演进到TCP协议）

本文章的内容是为了让大家对于网络变化进程有一个初步了解，如果大家想要精进一步可以再去搜索其他内容进行学习。

 UDP协议

你有一台电脑，现在你知道你的朋友的ip地址于是你将一个数据包传输给你的朋友。这就是物理层、数据链路层、网络层所做的事情。你此时所做的工作暂且认作传输层。

传输层是整个网络体系结构中的关键层次之一，主要负责向两个主机中进程之间的通信提供服务。由于一个主机同时运行多个进程，因此运输层具有复用和分用功能。

传输层也会面临着诸多的问题，首先遇到的一个问题就是你把数据包传送过来了，但是你应该具体交给哪个程序（进程）呢？

这时候你需要把通信的进程区分开，于是你给了每一个进程设置了一个“端口号”。

于是你要发送的数据包中又多了，源端口号和目标端口号。

这样你原本从主机到主机的通信，变成了进程到进程的通信。

于是我们可以把这看成一个UDP协议。（为后面演进成TCP做铺垫，理解即可）

传输遇到的问题

丢包情况

我们知道一种情况，网络并不是绝对稳定的，数据包是有可能在半路丢失的，但是如果在半路丢失的话，双方是无法察觉到的，因为A不知道B未收到，B不知道A未发送。

所以我们要让A知道B有没有收到，那么该如何做呢？

那就是让B告诉A，他收到了，也就是说在B收到包后，B会发送一个确认（ACK）

丢了的包该怎么办呢？

重传

于是我们的传输就变成了，A发送一个包，都必须收到B的确认，再发送下一个，否则在一定时间内没有收到确认，就重传这个包。

这个可以叫做停止等待协议，这个进程变的进一步可靠，于是我们的通信进程就有了一个新的特征，可靠交付。

效率问题

如果按照停止等待协议，一个一个发送并等到确认信号，这个进程是相当漫长的，所以我们必须要提升他的效率。

于是我们可以用流水线的方式来操作，也就是说，我们可以一次传多个，在一次返回多个确认的方式。

顺序问题

我们知道网络并不是一条直线，他的实际状况是十分复杂的，他可能是在乱序流动，也就是说，本来发送时正确的顺序，在发送的途中被打乱。

所以我们要解决这个问题。

A发送的数据包添加一个序号，B返回的ACK包上增加一个确认号。B的这个确认号还有一个作用，假如B发出了一个确认后ack=3，这就表示序号2及2之前的都收到了，这个叫做累计确认或累计应答。

流量问题

有的时候A发送的能力很强，但B的接收能力不足以匹配A的发送能力。这个问题该如何解决呢？

窗口大小（win）

B 每次发送数据包给 A 时，顺带传过来一个值，叫窗口大小（win)，这个值就表示 B 的接收能力。同理，每次 A 给 B 发包时也带上自己的窗口大小，表示 A 的接收能力。

A不断发送包，已发送的序号一直往右走直到碰到窗口上边界，此时A就无法继续发送包，达到了流量控制。

在A发包的过程中，A也在不断接收着B的确认号，窗口的上边界也在不断右移。

其他问题

还有常常面临的问题是阻塞问题和连接问题。这两个问题涉及篇幅较大，我再写一篇博客来记录，下面就简单介绍一下。

阻塞问题是由于网络环境影响的。

连接问题就涉及到了我们常常听到的三次握手、四次挥手协议。

总结

以上就是TCP协议的核心思想，如果有人问你UDP协议不安全，怎么优化呢？

那么你就可以回答我们上面面对的情况和解决问题。