一、TCP[!]

1.1、TCP协议报文格式

TCP协议报文格式的表现形式1：

TCP协议报文格式的表现形式2：

1、源端口号、目的端口号：
端口号是传输层协议的一个重要部分，知道了端口号，才能进一步确认这个数据报应该交给哪个应用程序；所占字节也都是2个字节，TCP的端口号其使用规则与UDP的端口号一致。

2、32位序号、32位确认序号：
32位序号这个字段用来给普通报文使用，32位确认序号这个字段用来给确认应答报文使用的，确认应答：即数据报被正确传送，并且返回响应。

3、4位首部长度：
TCP的报头是 变长 的，4位(bit)首部长度表示的数据范围是 0 ~ 15，但是其实此处 0 ~ 15 的单位是字节 ，即 4字节 ~ 15*4 字节，才是真正的首部长度。因此 TCP 数据报的最大长度最短、固定时是20个字节，最长时是60个字节。故TCP能够传送的数据比只能够传送64KB的UDP协议要多得多。我们需要使用首部长度来判断，报头到哪里结束，而载荷部分从哪里是开始。

4、6位保留位：
保留位是设计TCP协议的团队，汲取了UDP64KB长度的教训，用来给未来TCP留下可以升级扩展的空间的一个字段。其实就类似我们电脑预留的接口、插槽一样。有的电脑是轻薄本，因此可能只能够插一个内存，但是有的电脑他的设计师设计电脑时预留了很多插槽，即使可能这些插槽用户也用不上，但是还是预留了，以防出现突发情况。相对的，这些电脑，价格也就会相对插槽少的电脑昂贵一些，虽然价格昂贵，但是也还是会有大部分的用户选择这类扩展性好的电脑。

保留位后面是6个标志位，分别是：UBG、ACK、PSH、RST、SYN、FIN，他们的具体含义后续会补充介绍。

5、16位窗口大小、16位校验和、16位紧急指针：
暂时不用了解。

6、选项：
选项部分，可以有，也可以没有；可以有一个选项，也可以有多个选项。最少是0个字节，最多可以是40个字节。

7、载荷数据：应用层数据报。

1.2、TCP十大机制

TCP特性：
1、有连接
2、可靠传输：可靠传输是由内核实现的，我们写代码时无法感知到。（TCP的可靠传输不代表安全传输）
3、面向字节流
4、全双工

那么TCP就围绕这4个特性，提供了一系列重要的 机制 ，让我们更深入的理解报头结构。

1.2.1、确认应答机制

确认应答机制，是保证 TCP “可靠性” 最核心的机制。
举个例子理解：

上述情况3其应答消息就出现了 “后发先至” 的情况。其实不止代码会发生这样的情况，现实生活中，这类情况比比皆是：
比如说：结婚时的接亲过程：接亲一般就是男方开婚车队伍到女方家。一般来说，接亲车队的车辆排列顺序都是有一定讲究的一般是新郎的车在最前头。但是，有可能在接亲路上遇到一些突发状况(比如过红绿灯时)，导致新郎的车落在后头了，别的婚车在新郎前面了。

那对于传输在网络中的数据也是一样的，数据从主机A发出，到被主机B接收的这一过程中，数据在网络中走的路线有很多，同时每个节点(路由器/交换机)的繁忙程度不一，此时，这样的转发过程，就会存在差异，就和等红绿灯一样。

那怎么保证数据的可靠传输(数据的顺序性、数据的完整性、数据的正确性…)？？可以 针对数据进行编号 解决该问题。

1.2.2、超时重传机制

针对丢包、传输失败的数据，进行重传。

如果发送方的数据丢了，正常超时重传就行；

如果是确认应答报文(ACK)丢了，有两种情况：
(1)、ack发送成功，但接收方不回复，无视你的消息，发送方也会进行重传，因为发送方得不到回复，就会认为数据丢包了。

(2)、ack发送失败，你收不到回复。针对2这种情况，正常重传即可；针对1这种情况，会导致接收方收到重复内容的消息，这不太好。因此TCP针对接收方丢失ACK而受到重复的消息这种情况，他会根据消息的序号来进行 去重 ，即如果接收方已经收了一个序号为 1001 的数据，没多久又收到 1001 序号的数据，此时 TCP 就会将序号相同的消息进行去重。

那么超时时间如何确定 ？？一般系统中有一个配置项，描述了超时的时间阈值。例如：第一次丢包出现后，发送方就会在达到超时时间阈值之后，进行重传；如果重传的数据仍然无响应，还会继续超时重传，第二次的超时时间一般要比第一次更长。超时的时间并非是均等的，而是逐渐变大的。因为假设单个数据报丢包的概率为10%，那么第一次丢包的概率是0.1，第二次丢包的概率是0.1 * 0.1 = 0.01，因此丢包的概率是逐渐减小的，所以第二次传输，大概可以顺利到达的，所以超时重传的时间是逐渐变大的。那如果第二次传输也没有到达，说明当前网络环境比较糟糕，那单个数据报丢包的概率可能非常大，甚至概率是100%的，断网了，都断网了，再怎么频繁的重传，也没用，所以把超时重传的频率降低一点(时间间隔长一点)，至少可以节省主机的开销。

超时重传几次之后，仍然无法传输，就会尝试重置 TCP 连接(断开连接)，如果还是连不上，此时就直接释放TCP连接(彻底放弃)。

那到底基础的重传间隔时间是多少?每次间隔增加多少？？最多重传几次？？不知道！没有具体的参数，因为不同的系统他们的时间都不一样，一旦给出了具体的参数，可能大家就会对此数值过度关注，甚至于对此数值死记硬背，没必要，我们需要关注的是超时重传此机制的本身策略，而不是这个数字。

典型的反例就是HashMap解决哈希冲突，是通过链表的方式，但如果链表太长了怎么办？？需要把链表转成红黑树。那链表元素个数达到多少时，会转成红黑树呢？不知道，不好说！不同的哈希表的表现方式不同，只是 JDK1.8 标准库的 HashMap 是按照这个数字来设定的，如果是其他版本的 JDK 或者不是标准库实现 或者是 其他语言中的其他版本的实现，还是不是这个数字，不好说！

不变的是策略，可变的是参数。

1.2.3、连接管理机制

连接管理机制：描述的是TCP建立连接和断开连接的过程。

什么是连接？
（1）、物理上的连接：使用网线把两个电脑连上，这是 “物理上” 的连接。
（2）、逻辑上的连接：只要是网络通信，不管是用 TCP 还是 UDP 还是别的协议，物理上已经连接好了。逻辑上的连接就是：主机A与主机B建立连接，主机A的系统内核里，记录了一个数据结构，包含了和他连接的对方信息(IP、端口、使用的协议…)；主机B的系统内核里，记录了一个数据结构，包含了和他连接的对方信息。

1.2.3.1、三次握手[其流程至关重要，面试必考]

三次握手只能是客户端先握，四次挥手既可以是客户端先挥，也可以是服务器先挥。[!]
TCP是通过三次握手完成建立连接的（即双方建立一个相互认同的关系）。

[!]

ack 标志位我们前面已经讲过了，ack = 1，表示当前是个应答报文，ack = 0，表示当前是个普通报文。syn 也是TCP报头6个标志位里的其中之一，syn = 1，说明这是一个同步报文段(即：尝试和对方建立连接)；syn = 0，则反之。

1.2.3.2.1、那为啥要建立连接？？建立连接的意义是啥？？

1、投石问路。即：检查一下当前的网络情况是否是通畅的。就像地铁每天运营之前，都需要先空车跑一趟，来看看当前地铁线路是否畅通。
2、三次握手同时也是在检查通信双方的 发送能力 和 接收能力。

3、三次握手过程中，也在协商一些重要参数。
TCP 里面有很多参数需要协商。例如TCP的序号并非是从1开始的，通常都是建立连接的时候协商了一个数字。目的是保证两个连接的序号有差别，如果连接断开又快速重连，
接收方就可以区分当前收到的数据是当前连接的还是上个连接的。

TCP3次握手的详细流程图：（流程图上详细说明了TCP3次握手的两个比较重要的状态，当然还有别的状态，但就不一一列举了）

1.2.3.2、四次挥手

四次挥手用于断开连接，即双方取消相互认同关系。通信双方，各自向对方申请断开连接，再各自给对方回应。

那4次挥手能像3次握手那样合并吗？？不一定能。为什么？？


TCP4次挥手的详细流程图：（流程图上详细说明了TCP4次挥手的两个比较重要的状态，当然还有别的状态，但就不一一列举了）

ACK( acknowledge应答) 和 响应(response) 是否相同呢？？
不相同。ACK只是告诉发送方，我收到数据了。而 响应 则是携带业务上的数据。

就像一些企业所用的软件：企业微信、钉钉、飞书、雨雀…当A给B发消息，网络没问题的话消息就会顺利传送到B处，那这个消息上就会出现 “已读” 两个字，这就是ACK，即系统内核收到请求就会立即返回的，不表示任何业务上的概念，只是单纯进行反馈而已。B收到消息后，回复的内容，就是响应，他表示了具体的业务数据，是由应用程序负责的，取决于代码怎么写。

1.2.4、滑动窗口机制

TCP通过 超时重传机制、确认应答机制、连接管理机制 来确保TCP协议的可靠传输。由于TCP协议是可靠传输，因此TCP的传输效率比UDP慢一些，但是 TCP 也在想方设法的提高自己的传输效率。即通过 滑动窗口机制。



上面我们讨论的是使用滑动窗口机制时是在正常的情况，如果在使用滑动窗口机制时，出现了 丢包(1、发送方传的数据丢了。2、接收方回复的ACK丢了) ，那该怎么办？？

情况一：数据报抵达，但 ACK 丢了。

丢了就丢了，对于TCP的可靠传输没有任何影响，无需处理。这是因为，虽然丢了，但是只要后面发送的数据有ACK就足够了。

比如1001丢了，但是后面ACK 2001 成功了，此时就说明其实 1001 也已经 ACK 成功了。

就好比，有人问你，大学毕业了没，你回答说你已经硕士毕业了，这时候人家就明白了，原来你已经小学、初中、高中、大学都毕业了。

情况二：数据包丢包了。


在上述设定中，只是把丢失的数据进行了重传，没丢的包，无需重传，这种传输效率比较高，叫做 “快速重传”（快速重传是搭配 滑动窗口机制的 超时重传）。当传输数据很多时，批量传输，自然是遵守快速重传的方式，但如果传输的数据很少(就只有一条)，此时仍然是按照超时重传的方式进行。只要是丢包重传的，都是 “超时重传”，快速重传算是超时重传的特殊情况。

1.2.5、流量控制机制

使用滑动窗口机制之后，TCP协议效率高不高，主要取决于窗口大小，窗口越大，效率越高；窗口越小，效率越小。假设窗口大小是无限大、无穷大，此时发送方就完全不需要等待ACK了，此时效率就和 UDP 协议是一样的了。

但是发送方的窗口大小不能无限大，要考虑接收方的接收能力，如果接收方的接收能力跟不上发送方的发送能力，此时接收方就会被迫放弃一部分的数据，那此时TCP既要保证传输的可靠性，又需要重传这些被接收方丢弃的数据，很麻烦。因此TCP协议就需要使用其他机制在滑动窗口机制的基础上，限制发送方的发送速度，即限制发送方的窗口大小不要太大，此时 流量控制机制 就出现了。

流量控制机制：在滑动窗口的基础之上，对发送速率做出限制的机制，就是限制发送方的窗口大小不要太大。 那到底多大才合适呢？窗口大小，大了也不行，小了也不行，多少合适呢？？**那就问问接收方，看看接收方，觉得发多快合适。**其实流量控制机制就是接收方对于发送方的反制，接收方根据自己的接收能力，来反向影响发送方接下来的发送速率。

那接收方的接收速率如何量化？？接收方使用它的接收缓冲区的剩余空间大小，来作为发送方发送窗口大小的参考数值！

1.2.6、拥塞控制机制

流量控制机制，是根据接收方的处理能力，来控制发送方的发送速率。但是其实发送方的发送速率，不仅仅只被接收方的接收速率制约，也受到中间节点的制约。

因为在网络通信中，两个主机通过网络进行通信，他们传输的数据报会经过网络中的多个节点、设备，如果通信中这些网络传输设备有某一个出现了问题，那此时就会发生丢包问题，如果发生丢包问题，就说明此时接收方的接受速率比较吃力，此时发送方就需要调整其发送速率：

那么，我们可以知道了，流量控制机制、拥塞控制机制 都是在控制发送方的窗口大小，那么，两个机制的发送窗口大小不一致时，到底听谁的？？哪个机制发送窗口小，听谁的！

拥塞控制总的思路：
从小的发送速率开始，试探一下接收方的接收速率，再逐渐变大，如果出现丢包，那就逐渐变小，反复的动态调整。

那么TCP实现拥塞控制具体方式是什么？
TCP引入 慢启动 机制 ，即发送之初，网络情况还不知道，就先发送
窗口小的，然后再指数翻倍增长(这样做的好处就是可以在短时间内摸清楚网络传输承载的底线)，但是我们也需要设置一个窗口大小阈值，当慢启动时其指数增长时的窗口大小超过了该阈值，就不再指数增长了，而是开始线性增长了。

1.2.7、延迟应答机制

延迟应答机制是基于流量控制机制，用来提高传输效率的机制。

举个例子：寒暑假，学生一般都会有寒暑假作业，但其实很多学生只会在开学前几天狂补。某一天假期已经倒数一星期时，小明的老师发微信问小明寒假作业做到哪里了，小明这才想起居然还有寒假作业没写，他找到寒假作业本，翻开是一片空白，于是小明不敢立马回老师微信，只能默默狂补寒假作业，经过了一天一夜的狂补，小明的寒假作业只剩下2页没写，这时小明才敢回复老师说快写完了，还剩2页。这就是延迟应答：把应答时间往后拖，趁着这个拖后的时间，赶紧补作业。

1.2.8、捎带应答机制

捎带应答机制：是基于延迟应答机制的基础上引进的。

在我们的网络通信中，典型的通信模式是：一收一发。

同时由于这个捎带应答机制，4次握手能够合并，但这个合并其实是 偶发性，并不是每次一定都能够合并！。

1.2.9、面向字节流[粘包” 问题]

由于TCP是面向字节流的，此时就存在一个典型问题，叫做 “粘包” 问题。[其实不只是TCP，只要是面向字节流传输的，都有粘包问题出现]。

如何理解粘包问题：举个例子。平常我们吃一些糯叽叽的食物，比如说雪媚娘，雪梅娘做好之后如果不撒上一层熟糯米粉就放在一块的话，他们就会粘连起来，拿起一个时由于都粘在一起了，此时就只能取到半个。粘包问题就是这样，很有可能会使接收方接收不到完整的数据，因为接收方压根不知道数据是从哪里开始，又是从哪里结束。

TCP或者其他使用面向字节流的传输方式，都有一个接收缓冲区。

要解决粘包问题，就需要在应用层协议里进行区分，即：只要在定义应用层数据协议时，明确包和包之间的 ”边界“ 就可以区分出，从哪儿到哪儿是一个完整的应用层协议。

那么边界如何区分呢？？典型方法2种：
1、通过分隔符：比如约定使用分隔符 ; 作为包的结束标志。
2、通过指定包的长度，比如在数据报的开头位置声明长度。

那如果分隔符与数据内容一致了怎么办？？一致是不行的，一般在选择分隔符时，就需要根据传输的内容，决定选择什么样的分隔符，所以一般不会一致。

自定义应用层协议，有几个典型的实现：
1、xml。此时分隔符就相当于 结束标签。
2、json。分隔符就相当于 } 。
3、protobuffer。里面通过声明长度的方式来确定边界的。
4、http。分隔符和长度两个都会用到。

1.2.10、TCP中的异常处理

a)、TCP连接着，但程序却突然崩溃。
即：进程异常退出，操作系统会回收进程的资源，包括释放文件描述符表，这样的释放操作，就相当于调用了对应的 socket 的 close()，执行 close() 就会触发 FIN 报文，进一步的开始四次挥手。
b)、程序在跑，主机却突然关机(通过开始菜单方式关机)
关机时，系统会强制结束所有用户进程，和上述的进程崩溃类似，系统内核，会进行文件描述符的释放操作，进一步的进行四次挥手。

上述这两种情况会进行杀进程，但 c) 这种情况却不一样了。
c)、主机掉电(拔电源…)
非常突然，猝不及防。需要分两个情况进行分析：
(1)、掉电的是接收方
发送方不知道对方挂了，继续发送数据。此时发的数据没有ACK，发送方触发超时重传机制，重传也没有应答，重传几次之后，就尝试重置连接(可以理解为断开连接后又重连，但是原理不一样)，重置连接是使用复位报文段(RST为1)，重置连接也不行的话，最后只能放弃连接了。
（2）、掉电的是发送方，此时接收方就等着。但接收方并不是干等着，等了一会儿后，发现发送方还是没动静，接收方就会发送一个心跳包，心跳包是周期性触发的，只是一个不携带任何业务数据的包，存在的意义就是为了确认发送方是否还在。如果对方不返回心跳包，就说明对方挂了，此时接收方就会放弃连接。
d)、网线断开
情况同主机掉电，两端各自按照上述两种情况分别进行。但是通信双方的主机没问题。

1.3、TCP 和 UDP 的区别？[常见面试题]

后面再补充，