目录
从这篇博客就开始给大家简略的介绍TCP和UDP的网络知识啦，我觉得吧，与其这个焦虑，那个焦虑，不如在一个安静的午后，写写自己最近所学感觉有点一知半解的知识，在这途中，我觉得通过不断查资料，回顾知识，认真复盘，写个几篇博客下来，结果也不会太差，不多说了，我们知识走起！
🍕网络中协议分层
应用层：和应用程序直接相关
传输层：端到端传输，不关心中间过程，只关心起点和终点，我的理解是两个电脑之间的通信，也就是这么讲吧，它呢，只关心数据到了电脑上，该如何到达啥样的端口
网络层：点到点的传输，规划传输的中间路径，这个也就是电脑把数据发出去，这个数据该如何规划经过哪些路由器啊，交换机啊啥的，就相当于物流
数据链路层：两个相邻点之间的传输，也就是路由器和路由器，路由器和交换机，如何传输数据的问题了
物理层：底层基础设备，硬件设备，这个就是最基本的了，毕竟是物理实在层面上的
应用层
在应用层最重要就是HTTP协议了，所谓协议，就是很多大佬已经研究出来的协议，其中HTTP就是的，其它协议也有，只不过HTTP是让大众更为接受的，懂嘛，就是历史悠久的意思哈哈
🍕端口号
所谓端口号就是一个整数，用来区分，同一主机上不同的应用程序
对于服务器来说，端口号，程序员手动指定的。
对于客户端来说，端口号，系统自动分配的。
端口号是两个字节表示的无符号整数。
范围是0~65535，其中0~1023是知名端口号，专门给知名服务器预留的。
端口号中，有两个知名端口号，
80端口---HTTP服务器
443端口---HTTPS服务器
端口和进程
一个端口号只能绑定一个进程
一个进程可以绑定多个端口号
就是公司中开发的服务器程序，一般会提供至少两个端口
1.业务端口
用户的客户端通过这个端口连上服务器
2.调试端口/管理端口
不对外公开，程序员自己偷偷使用，这是因为在生产环境上，服务器程序，不能使用调试器来调，调试器可能会把整个进程阻塞住，使用户无法正常使用，所以就需要这些调试端口，来实现一些"调试请求"和"调试响应"。
🍕UDP的报文格式
其实这个图是连续的，像下面这样
整个UDP报头，是8个字节，分成4个部分，每个部分是2个字节（还剩下载荷哦，也就是数据）
🍔长度
长度，通过2个字节的数据，描述了UDP数据的长度。
2个字节表示的数字，最大65535也就是64KB，也就是一个UDP数据报，最大就是64KB了
然后我们思考一个问题，我们使用UDP数据报，可他最大长度也只是64KB，64KB啊，肯定不够用啊，所以当时的方案有两个：
1.手动实现，拆包组包逻辑~~：使用多个UDP数据报，传递一组广告数据？？完全可以，但是需要考虑的东西太多了，需要考虑如何拆分，还得考虑接收方怎么组包，组包的时候考虑顺序/如果中间丢了东西咋办----这个方案风险太大，直接PASS掉了。
2.使用TCP替代UDP.（这个具体的后面讲到TCP自然就明白了）
然后就有人会疑问了，UDP的长度只有2个字节，可不可以把它从2个字节搞成4个字节呢？
其实呢，这个事情非常难做到，不是技术问题，而是政治问题。
UDP协议呢，它集成在操作系统内核中的，世界上有很多种操作系统，windows，linux，macos，android，ios，其它的操作系统，一旦决定修改UDP协议，意味着上面的每一种系统都的一起释放，所以相比于升级UDP，可能发明新的协议，代替UDP反而成本更低一些，TCP很多时候扮演了这样的角色。
🍔校验和：
校验和的作用是，验证传输的数据，是否出错了，那么为啥网络传输中为啥会出错呢？本质上是电信号/光信号，电信号，高电平表示1，低电平表示0，网络传输过程中，可能会受到外界环境的干扰，所以如果出错了，有两个方案：
1.发现错误--UDP的校验和，起到了发现错误（知道数据错了，但不知道哪个位置错了）
2.纠正错误--海明码，知道数据错了，也能够知道哪个位置错了（引入太多的辅助的位，导致整体传输的数据变多）