前言：

网络初始：对于网络有一个直观的大体的认识

网络编程：让我们真正通过代码感受网络通信程序

网络原理：进一步的理解网络是如何工作的，以理论为主，很多比较抽象的东西，同时这里也包含大量的面试题（考点，工作不常用！）

网络原理：

按照网络协议这个几个层次来展开的！

• 应用层
• 传输层
• 网络层
• 数据链路层
• 物理层

应用层，传输层（重点介绍）；

网络层，数据链路层（简单了解）

物理层（直接跳过）

应用层：

此处先简单介绍，预计后面有一个专门的章节《HTTP协议》，应用层的代表协议，应用层和代码直接相关一层，决定了数据要传输什么，拿到数据之后，如何使用！

应用层这里，虽然存在一些现有的协议（HTTP），但是也有很大情况，需要程序员自定制协议（和吃饭喝水一样，非常容易）

约定应用层数据报，数据格式就是在自定义协议：

如何约定？？

1. 确定要传输哪些信息》》（根据需求定的）
2. 确定数据按照啥样的格式来组织（随意约定的），在实际开发中，有一些现成的格式，可以直接使用的！

一种典型的格式XML，之前流行的格式，现在用的比较少，但是也还会经常遇到！通过标签的形式来组织的！

请求：
<request>
    <userd>100</userd>
    <userPos>
        100-100
    </userPos>
</request>

在XML中包含了很多标签，<request>（开始标签）  </request>（结束标签）是一对标签，标签之间可以嵌套，标签之间放内容！

XML中的标签都是用户自定义的，每个标签的名字乐意叫啥就叫啥！！

HTMl可以视为XML的特殊情况！Html的标签有哪些？？标签的含义是什么？？都是人家有一回标准委员会大佬约定的！咱们只能遵守！！

另一种非常流行的格式：json（XML用的少了，主要就是json了）

{
    userd:100,
    userPos:100_100
}

使用{}大括号作为标识，

{}大括号里面是若干个键值对，

每个键值对之间使用，（逗号）分割，

键和值之间使用：（冒号）分割，

键必须是字符串，

值可以是数字，字符串，数组，另一个json……

重点掌握json，后面程序/代码会用到！

数据组织的方式，有无数种，只不过比较常见的为：XML和json

传输层：

UDP和TCP是两个比较重要的协议（重点）更多详情，可见笔者上篇文章：TCP VS UDP-CSDN博客

学一个协议，其中最重要的环节，就是认识协议报文格式（具体怎么组织的这个数据）

源IP

源端口：数据从哪里来？？

目的IP

目的端口：数据到哪里来？？

唐僧自我介绍：

贫僧自东土大唐而来，到西天拜佛求经！

源端口：贫僧

源IP：自东土大唐而来

目的IP：到西天

目的端口：拜佛求经

每个端口号在UDP报文里，占两个字节，其实端口号的取值范围为：0~~65535，小于1024的端口，称为“知名端口号”，给一些名气比较大的服务器预留，这部分端口咱们在写代码的时候，不应该使用，当然，用也没事，可能需要提供管理员权限！

报文长度：2字节：比较小！

2字节表示的范围0~~65535（64KB），则一个UDP报文最大长度为64KB

万一真的需要传输一个比较大的数据咋办？？

1. 可以把一个大的数据拆分为多个部分，使用多个UDP数据报来传输，虽然可行，但是比较麻烦！
2. 不用UDP，直接使用TCP，TCP没有限制！

因此：使用UDP编程的时候，需要注意：UDP数据报不能太长，否则会有问题！！

校验和

网络传输并非那么稳定，可能会出现什么幺蛾子！

如：通过网络传输——》电信号（电信号使用高低电平，表示0，1

但是，如果外部环境干扰，强磁场之类的，就可以导致低电平——》高电平，或者高电平——》低电平，比特翻转——》数据传输就出错了！！

校验和最大的意义：就是用来判定当前传输的数据是否出错，如果校验和不对，此时你的数据一定不对，如何校验和对，但是数据也有一定概率是错的！！

为了让校验和能够识别率更高一些，计算的时候通常会以数据内容作为参数来进行计算（可用的计算公式有很多），数据内容发生变化，校验和也会发生变化！

TCP：

有链接，可靠传输（TCP存在的初心），面向字节流，全双工

TCP如何实现的可靠传输！！

所谓的可靠传输，并不是说100%就能传输过去！（要求太高了！）是尽可能的传输过去，如果传不过去，发送方至少能知道自己没传过去！！

核心机制：在于接收方收到了或者没收到，会有个应答！！

确认应答：是实现可靠性的最核心机制！！

为了解决上述问题，就需要针对消息进行编号！！给发送的信息进行编号！！同时给出应答报文，给出确定序号！！

真实的TCP数据传输也是引入了序号和确认序号！

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

TCP是针对每个字节都去编号（TCP并没有“一条消息，两条消息”这样的说法~）

注意：确定序列号的规则：

并不是说，发送方的序列号是啥，确认序号就是啥！！而是取的是发送方发过来的数据，最后一个字节的下一个字节的序号！！

确认序号1001的含义：（这种规则的优势，在我们后面的博客学习中可以体会到！）

1. 小于1001的数据我们已经收到
2. 我接下来想向发送方索要从1001开始的数据

接收方就可以通过ack的确认序号，告诉发送方哪些数据已经收到了！

其实，后发先至的情况还是很常见的！！（结亲——》结婚）

结亲的车队，在开的时候，很难保证顺序，经常是车头还在很远地方，后面的车就先到了，然后在门口等待，等车都到齐了，再重新整队！！

对于TCP来说，自身也承担了整队的任务！

TCP会有个接收缓冲区（一块内核中的内存空间）

每个socket都有一份自己的缓冲区

TCP就可以按照序列号针对收到的信息进行整队（优先级序列），这也是TCP序号的一个重要用途！

如果一切顺利，就可以直接确认应答了，可靠性自然得到了支持！

丢包：

对于丢包也是网络上非常典型的情况！

那么，为啥会发生丢包呢？？

从发送方到接收方之间，需要进行多个服务器的转化，如果中间任何一个节点出现了问题，都可能导致丢包！！

每个设备都是再承担很大的转发任务的！每个设备的转发能力都是有上限的，某一时刻，某一设备上面的流量达到峰值，就可能会引起部分数据的丢包！

其实这种情况下是非常容易出现的，概率性丢包的！！

看视频，看直播，对于丢包是不敏感的（看视频提前有预缓冲）

打游戏，尤其是对抗性的游戏，对于丢包是非常敏感的！

如果丢包了，接收方就收不到了，自然就不会返回ack

发送方就迟迟拿不到应答报文，等待一段时间后，还是没有收到应答报文，发送方就视为刚才的数据丢包了，就会重新再发送一遍！！（超时重传）

网络丢包是概率性事件，上个包丢了，重传还是有很大机会传过去的！！

发送方对于丢包的判定是在一定的时间内没有收到对应的ack

1. 数据直接丢了，接收方没有收到，自然不会发送ack
2. 接收方收到数据了，返回的ack丢了

发送方是区分不了这两个情况，只能都进行重传！

对于情况1：这种丢包问题不大

对于情况2：这种丢包，虽然是重新发送数据，但也会出现问题（发送方发送的是：转账请求）

当然对于这个问题，TCP非常贴心的帮助咱们处理好了！会在接收缓冲区中根据收集到的数据序号，自动去重（重复数据），保证了应用程序读到的数据仍然只有一份！——》哪有什么岁月静好，只不过TCP在给咱们负重前行！

当然，对于重复的数据，有没有可能又丢了呢？？当然，这个也是有可能的！！一旦出现连续丢包，这种情况下，多半你的网络出现了非常严重的问题（网络故障）

TCP针对多个包丢失的处理思路是：继续超时重传！！

但是，每丢包一次，超时等待时间都会变长（重传的频率降低了！）

TCP觉得重传怕也是没戏，干脆就摆烂摸鱼了！反正重传也没啥卵用！（网络已经出现严重问题）

连续多次重传都没有得到ack，此时TCP就会尝试重置连接（相当于尝试重连），如果重置连接也失效，TCP就会关闭连接——》放弃网络通信了（跟我们打电话是一个道理，如果打不通，就停一会在打，如果还打不通………）能重传就重传，实在传不了，就关闭连接了，尽最大可能完成传输！！

TCP可靠性的基石！！

1. 一切顺利：使用确认应答，保证可靠
2. 出现丢包：使用超时重传作为补充

问：TCP是如何实现可靠性的？？

答：确认应答+超时重传

连接管理：

TCP建立连接，和TCP断开连接的流程！（连接管理和TCP可靠性之间，并没有非常直接的关系）

• TCP建立连接：三次握手
• TCP断开连接：四次挥手

TCP最核心的考点，也是整个网络原理最核心的考点（建立连接，断开连接）

三次握手：建立连接——》一定是客户端主动先发起的！

握手（handshake)指☞：通信双方进行一次网络交互，相当于客户端和服务器之间，通过三次交互，建立连接关系（客户端与服务器双方各自记录对方的信息）

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

syn称为：同步报文段：意思就是：一方要向另一方申请建立连接！

知道了三次握手，还得了解下三次握手起到了啥样的效果？？达成了什么目标？？三次握手这个过程，本质上是投石问路！验证了客户端和服务器各自的发送能力和接收能力是否正常！！

---

四次挥手：断开连接——》客户端和服务器都有可能主动先发起通信双方各自给对方发送一个FIN（结束报文），再各自给对方返回一个ACK

锲约解除，双方都恢复自由之身。

在上述的过程中，服务器发送的ACK和FIN有一定概率合并成一个，但是通常情况下是不可能的！！

为啥三次握手可以100%合并？？四次挥手就不能合并？？

三次握手：ack和syn是同一个机制触发的！（都是内核来完成的！）

四次会是：ack和syn则是不同时机触发的！（ack是内核完成的，会在收到fin的时候，第一时间返回；fin则是应用程序代码控制的，在调用到socket的close方法的时候才会触发！

TCP要保证的不仅仅是可靠性，还有效率（提升可靠性，往往意味着损失效率）

要想提高效率，就要缩短等待时间——》批量发送数据！（一次发送多条数据，一次等多个ack）

这里就是批量发送数据，发送完之后，统一等待ack，每当收到一个ack后，就立即发送下一条（不是收到全部ack数据——》浪费时间）

批量发送不是无限发送，是发送到一定程度就等待ack，不等待直接发送的数据量是有上限的！！而是回来一个ack，就立即发下一条，相当于总的要等待的数据是一致的（把批量等待数据的数量，就称为窗口大小）

在批量发送的过程中，如果出现了丢包咋办？？（可靠性第一，效率靠后），丢包有两种可能

1. 数据报已经到达，ack丢了！
2. 数据丢了

情况一：数据报已经到达，ack丢了！具体过程如下图所示：

在这个图中，相当于一半的ack都丢了，算是相当高的丢包率了！！

注意在这种情况下，啥事都没有，即使丢了这么多ack，对于可靠性没有任何影响，这就是确认序号的含义了！！（表示该序号之前的数据都已经收到了，后一个ack能够涵盖前一个ack的意思！

当收到2001这个ack的时候，此时发送方就知道2001之前的数据都收到了，1--1000这个数据也收到了，至于1001这个ack丢了就丢了，无所谓！！当然，如果最后一个数据丢了，照样超时重传即可！！

情况二：数据包丢了！！具体过程如下图所示：

在该过程中，由于刚才1001--2000这个数据丢了，所以接收方仍然再索要1001，不会说因为收到的是2001--3000就返回3001了，因此在接下来的几次数据的ack，确认序号都是1001，主机B在向主机A反复索要1001这个数据，主机A这边连续收到几个1001之后，就知道可能会丢包了！！因此，主机A就重传了1001--2000这个数据。

当主机A把1001--2000这个数据重传之后，主机B 收到了，返回的序号是7001，而不是2001，原因在于：2001--7000这些数据，B都已经收到过了，再上述重传过程，没有任何的冗余操作！！只有丢了数据，才会重传，不丢的数据不必重传，因此整体的速度还是比较快的！！那么，该重传的过程也称为：快速重传！！

滑动窗口，超时重传是再批量传输大量数据的时候，会采取的措施，如果你就只传输一条，两条，少量的，低频的操作，就不会按滑动窗口这么搞了，仍然是前面的确认应答和超时重传了！

在此推荐一本靠谱的书籍：《图解TCP/IP》，网络原理相关书籍！