本篇主要主要解析各个层面的协议，包括应用层、传输层、数据链路层、

一、应用层

序列化和反序列化：网络上传输的数据，本质上就是二进制的“字符串”，但java中写的都是一个个对象，我们也无法传输一个“Java对象”，所以为了实现网络通信，就需要相互转化对象和二进制字符串，即序列化（对象 <—> 二进制字符串）和反序列化。

1.1 自定义协议

对于自定义协议，我们需要首先明确传递的信息是什么，数据是如何组织的

1.2 通用协议

尽管协议可以自定义，但早已有大佬搞出了通用协议，便于我们直接使用，比如xml、JSON

XML

概念：

• 用成对的标签来表示“键值对”信息，标签支撑嵌套。
• 每个标签都是人自定义的，只要记住格式(<></>)即可。
• 与html相比，并没有一个标准，html如果不按标准来，无法正常运行。

优缺点：

• 优点：能够清晰地表示结构化数据
• 缺点：
  • 要引入大量标签，十分繁琐。
  • 因为要传标签，会占用不少的网络带宽。

<request>
	<userId>1234</userId>	//键值对结构：key = userId， value = 1234
	<userName>张三</userName>
</request>

JSON

概念：

• 是最流行的一种数据组织格式，本质也是键值对，但更简洁。用{}表示键值对，[]表示数组，数组中的每个元素可以是数字、字符串、其他的{}、[]
• JSON对于换行并不敏感，所以一般网络运输时，会对JSOM进行压缩（去掉不必要的换行和空格），同时把所有数据都放到一行里，整体占用的带宽就更低了（但会影响到可读性）

优缺点

• 优点：数据简洁，可读性好
• 缺点：花费带宽传输了名字

protobuf

概念：谷歌提出的一套二进制的数字序列化方式，即使用二进制的方式约定哪些字节表示哪个属性

优缺点：

• 优点：可以最大限度的节省空间（不必传key，而是根据位置和长度来区分每个属性）
• 缺点：都是二进制数据，可读性差，使用也比较麻烦，需要专门编写一个 protobuf 文件

1.3 DNS 域名解析系统

1. 什么是域名：上网需要访问服务器，也就需要知道服务器的IP地址。但是IP地址即使是用点分十进制进行简洁表示了，依旧不方便人民记忆和传播，于是我们便使用baidu，taobao这样的单词来代替IP地址，这样的单词就被称为 “域名”。
2. 实践中，为了保证域名的唯一性，域名往往是分级的
   

二、传输层

2.1 UDP协议

1. 全双工：又能receive，又能send
2. 端口：因为是2字节，所以范围是0 ~ 65535，注意0一般不用，1~1024被分配给知名的程序了，一般也不用
3. 16位UDP长度：描述了载荷有多大，但是只有2字节，即64kb，对于现在而言，有些小。但是我们无法把协议中设置的位数加大，这涉及到了政治问题。为了解决这个问题，有两个方法：
   • 把一个要传的数据拆成多个后重组。但是代码量较大，成本高，不建议实行。
   • 改用TCP，因为TCP没有报文长度要求
4. 16位校验和：
   （1）网络通信要传的数据到最后物理层都会变成光信号/电信号，同时传输时难免会出现漏传的情况，校验和可以帮我们检验，该数据是否完整传输了。
   （2）CRC检验算法，主要是把UDP数据报中的每个字节都依次进行累加。传输数据时，发送方发送原始数据和校验和，接收方收到后，会将数据再算一遍，然后将受到的检验和和自己算的进行比较，如果相同，那么数据相同，即传输过程中没有出现错误。

1字节：
     有符号:-128 ~ 127
     无符号：0~255
2字节：
     有符号:-32768 ~ 32768
     无符号：0~65535
4字节：
     有符号:-21亿 ~ 21亿
     无符号：0~42亿95万

2.2 TCP协议

协议端格式及解析

1. 4位首部长度：
   • 作用：表示TCP协议报头的长度。报头前9个加起来20字节，大小是固定的，但是选项是可变的，所以总体TCP的报头是变化的，需要专门描述
   • 注意点：单位是“4字节”，要把这里的数值乘以4字节才是真正的大小
2. 选项：可以有，也可以没有。包含了一个窗口扩大因子M，可以接受的缓冲区大小是 “16位窗口大小”字段的值左移 M 位（与）。
3. 保留（6位）：解决了UDP无法升级的问题，为未来留下了可以升级扩展的空间
4. 6个标志位：每个都是1bit，有对应的含义
   • ACK：表示是否是确认报文。当ACK为0时，为普通报文，此时只有32位序号有效。当ACK为为1时，为应答报文，序号和确认序号都有效。
   • RST：复位报文段
   • SYN：申请和对面建立连接，“同步报文段”
   • FIN：通知对面要删除连接了，“结束报文段”
5. 32位序号：该数据报地第一关字节的序号，需要结合IP协议中的“16位总长度”来确认最后一位字节的序号
6. 32位确认序号：反馈给发送方收到了多少数据，以及发送数据要从哪里发起
7. 16位窗口大小：接收端自己可以接收的缓冲区大小放入，用于流量控制，通过ACK端通知发送端

可靠性机制

安全机制主要支持了TCP可靠性的实现，TCP可靠传输主要依靠内核实现，用户方面是感知不到的。其中确认应答是保证可靠性的最核心机制，其他的安全机制都只是有效补充。

确认应答

1. 网络上从一个点到另一个点的能走的线路很多，而不同的路线选择以及路由器/交换机的繁忙程度，都会影响到包到达的顺序。所以，为了区分，TCP将每个字节的数据都进行了编号，即为序列号。
2. 每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据；下一次你从哪里开始发。

超时重传

1. 什么是超时重传：当出现下面两种问题时，等待了一段时间后都没有收到数据包时，就需要重传数据包，即【超时重传】。

2. 去重：内核是无法区分到底是第一种丢包还是第二种，都是要重传，所以接收方就需要对数据去重，确保不会重复读取。

   • 如何去重：使用TCP的序号作为判定依据。
     TCP会在内核中给每个Socket对象都安排一个内存空间，相当于一个队列，即“接收缓冲区”，收到的数据都会被放到接收缓冲区里，并且按照序号排列好，此时就可以很容易判断新收的数据是否重复。当队列首元素序号>新接收数据序号，就表示该数据已经被读取过了。
   • 如何确定超时时间：
     （1）最理想的情况下，找到一个最小的时间，保证 “确认应答一定能在这个时间内返回”。这个时间的长短，随着网络环境的不同，是有差异的。如果超时时间设的太长，会影响整体的重传效率，如果超时时间设的太短，有可能会频繁发送重复的包。
     （2）TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。如果重发一次之后，仍然得不到应答，等待 2 *500ms 后再进行重传。如果仍然得不到应答，等待 4 *500ms 进行重传。依次类推，以指数形式递增。累计到一定的重传次数，会尝试重置TCP连接，即“TCP复位报文“。如果连重置操作都不行，那么TCP就会认为网络或者对端主机出现异常，强制关闭连接。
     拉长等待时间是等待修复，当前网络可能有问题，而次数太多了就说明此时网络已经出现了严重故障。
     

连接管理（三次握手，四次挥手）

在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接。

1. 三次握手：
   概念：
   （1）什么是三次握手：握手指发一个不携带业务信息，只用于打招呼，测试网络连接是否可行的数据。而三次握手就是指A、B如果要建立连接，这样的数据要发三次。三次握手是内核完成的工作，应用程序是无法干涉的，确保IP、端口对即可。

   （2）如何衡量连接的建立：ServerSocket socket = new ServerSocket();new完成，连接就建立完毕，accept()是将把连接队列中的元素取出来。单线程TCP服务器情况下，无法调用第二次accept，但这不影响连接操作的完成，形成的连接对象在连接队列里。

   （3）关于合并问题：中间的SYN+ACK其实可以拆开来，但为了节省效率，故而合并变成【三次挥手】

   （4）关于丢包问题：遵循超时重传机制，会重传，多次失败也会单方面释放连接

   意义：
   （1）保证可靠性：先行测试网络是否通常，以及各个主机的通信能力和接收能力是否正常（三次握手恰好能够验证双方的能力，二次握手无法验证完设备的正确性，四次握手可以，但没必要效率太低）
   （2）消息协商：协商双方的序号从几开始，保证双方连接消息的序号有较大差异，从而好判定该消息是否属于这个连接

2. 四次挥手：释放在内存中保存的对端的相关信息
   概念：
   （1）关于合并问题：中间的两次无法像“三次握手”那样合并，因为ACK的应答由内核控制，见到FIN就发送，是顺发的，可能会因为延迟应答机制返回慢。FIN则是当服务器执行到 close() 时发送。当FIN发送快，即可和ACK合并。所以这个合并因为FIN发送快慢问题，并不能百分百合并。

   （2）客户端如果迟迟收不到对方的FIN，也会单方面删掉连接

   （3）关于丢包问题：遵循超时重传机制，会重传，多次失败也会单方面释放连接。
                 如果是第一组FIN/ACK丢失：A直接重传FIN即可
                 如果是第二组 ACK 丢失：注意当A收到FIN发出ACK后，不能直接释放连接，因为最后一个ACK可能会丢包。万一连接删了，又丢包了，那B重传的FIN永远没人接收了。所以A需要等一会（等待时间是网络上任意两点之间传输数据的最大时间 * 2，即MSL），如果对方未重传FIN，就认为ACK已经被对方接受到了，此时A才能释放连接。

流量控制

根据接收端的处理能力，来决定发送端的发送速度（窗口大小）。用“接收缓冲区剩余空间大小”来衡量，越大，处理能力就越强。

拥塞控制

1. 概念：
   （1）使用场景：窗口大小的决定不能光关注接收方（流量控制），还要关注中间节点（交换机/路由器），总的传输效率取决于最短板。
   （2）如何衡量中间设备的转发能力：把中间设备看成一个整体，通过“实验”的方式，动态调整，最终产生出一个合适的窗口大小（具体细节看下面的操作部分）
   （3）拥塞窗口：在拥塞控制机制下采用的窗口大小

2. 操作：
   

   （1）慢启动：使用一个小窗口，试试水
   （2）指数增长：如果网络传输十分通畅，拥塞窗口大小就会呈指数式增长。指数增长速度极快，所以需要靠线性增长来调整窗口大小。
   （3）线性增长：指数增长使得窗口大小越过一个阈值时，就会采用“线性增长”。线性增长寓意每一轮固定+N，一轮次指“发数据到收到回应”。因为是增长，也会使得发送速度越来越快，而当快接近网络传输的极限，就可能丢包了，少量的丢包，我们仅仅是触发超时重传；大量的丢包，我们就认为网络拥塞。
   （4）拥塞窗口回归小窗口：网络拥堵了，将窗口大小调为慢启动的小窗口，同时根据当前拥堵的窗口大小，调整阈值，然后重复增长操作。

3. 优缺点
   优点：能够更好地适应多变的网络环境

   缺点：每次回到慢启动，都会使得传输速度大打折扣，后续推出的优化操作，都只是尽可能缩短传输小窗口的时间而已

4. 注意点：
   拥塞控制和流量控制共同限制了滑动窗口机制，确定了要传的窗口大小，使得滑动窗口得以在可靠性的前提下，提高传输效率

效率机制

滑动窗口

概念：一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能（用原本一份等待时间换多份）

1. 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节（四个段）。
2. 发送前四个段的时候，不需要等待任何ACK，直接发送。收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据，依次类推。
3. 操作系统内核为了维护这个滑动窗口，需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉。
4. 窗口越大，则网络的吞吐率就越高，但如果太大，相当于完全不用等ACK，相当于不可靠传输了。而且无法保证接收方能否处理得过来，设备是否支持得住。

关于丢包问题：

情况一：数据包已经抵达，ACK被丢了 ----------- 不用做任何处理，因为可以通过后续的ACK进行确认前面的数据报是否正常收到。

情况二：数据包就直接丢了 --------------- 重传

延迟应答

（1）作用：接收方在返回ACK时，拖延一段时间，来让应用程序有更多的时间消费数据，从而提高接收缓冲区的剩余空间大小。

（2）限制：并非所有的包都能延迟应答。滑动窗口有数量限制，非滑动窗口则有时间限制。
                    数量限制：每隔N个包就应答一次。滑动窗口下丢了几个ACK应答包也没事，因为后面的ACK包可以涵盖前面的
                    时间限制：超过最大延迟时间就应答一次

捎带应答

1. 概念：ACK搭响应的顺风车，和响应合并起来一起发送出去。

2. 条件：
   时机合适：客户端和服务器的交互主要是一问一答的形式，而延迟应答又使得ACK的返回时机更迟，此时就有机会搭响应的顺风车，和响应合并起来。

   数据不冲突：ACK数据不需要携带载荷，和响应的数据包也不冲突。所以就可以让一个数据包既携带载荷数据，又带有ACK信息（ACK标志位、窗口大小、确认序号）

粘包问题

1. 问题：发送方可以一次性发送多个应用层数据报，此时接受的时候，无法区分从哪里到哪里是一个完整的应用层数据报
   

2. 解决方法：传输层方面已经规定死了，无解，只能从应用层协议上下手。
   （1）应用层协议引入分隔符来区分包，如JSON、xml
   

   （2）引入包长度来区分包，如 protobuf

TCP异常情况

1. 进程崩溃：和正常关闭没有什么区别
   （1）相当于进程没了，此时对应的PCB也就没了，对应的文件描述被释放，相当于调用了socket.close()，崩溃的一方发出FIN，进一步触发四次挥手。
   （2）Socket相当于一个网卡文件，会被放到文件描述符表中

2. 主机关机（正常关机）
   先尝试强制终止所有进程，主机关闭期间，如果四次挥手完成，那正好。如果没完成，对方也最终会单方面释放自己的连接信息
   

3. 主机掉电：没有任何可操作空间
   两种情况:
   （1）如果B正在给A发消息，那么就会像【主机正常关机】那样，最终单方面断开连接，B没有什么负面影响
   （2）如果A正在给B发消息。A突然不发消息了，但是B分不清A是等会发，还是一直不发了，于是B便阻塞等待。但这个等待时间不是无限的，B会周期性地给对方发起一个不携带任何业务数据（载荷）的TCP数据包，即【心跳包】。这主要是用来触发ACK，确认一下A是否正常工作/网络是否畅通。如果发现对方不在了，就会单方面断开连接。

   其他:
   （1）“心跳包”有点类似于“窗口探测报文”
   （2）应用层心跳包：虽然TCP已经有心跳包的支持了，但是还需要再应用层中重新实现心跳包。因为TCP的心跳包是分钟级别的，周期太长。在如今高并发的场景下，速度太慢。

4. 网线断开：机器都还在，但无法通信
   （1）客户端A：主机掉电的第一种情况
   （2）服务器B：主机掉电的第二种情况