前言

这一篇博客。就是专门用来讲解TCP协议对应的知识。

一丶TCP协议格式

TCP协议是位于传输层的协议，传输层的功能是什么呢？是确保数据能安全稳定的从客户端传输到服务端。那在传输层传输的数据叫什么呢？叫段。
由此我们的TCP协议应运而生。TCP，全称Transmission Control Protocol，传输控制协议。就像名字一样，他就是专门对数据的传输进行一个详细的控制。

TCP协议的格式如下：
在这里插入图片描述
TCP协议是二进制的传输协议，而HTTP是超文本传输协议（还是文本格式）。

端口号

源端口号：源主机对应应用程序的进程，16位
目的端口号：目的主机对应应用程序的进程，16位

序列号

TCP序列号：占32位，TCP对数据的每个字节都进行了编号，数据第一个字节的编号就是数据报的序列号，每个字节都有自己独一无二的编号，故序列号有唯一性。
序列号的作用：接收端为了区别重复的报文段（报文段也叫帧），那么这个时候就需要TCP协议就需要能够识别出那些是重复的的，并且把重复的丢掉，这个时候就需要使用序列号来实现去重的功能。

确认号

TCP确认号：占 32 位。它表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。其值是接收数据报时序列号的连续最大下标+1.

首部长度

TCP首部长度：数据偏移是指数据段中的数据部分起始处距离TCP数据段起始部分的字节偏移量，占4个字节。这里的“数据偏移”也是在确认TCP数据段头部分的长度，告诉接收端的引用程序，数据从何处开始。

保留字段

保留字段：为TCP将来的发展预留空间，开始必须全部是0

标志位字段

名称	说明
URG	表示本报文段中发送的数据是否包含紧急数据：URG=1 时表示有紧急数据。当 URG=1 时，后面的紧急指针字段才有效
ACK	表示前面的确认号字段是否有效：ACK=1 时表示有效；只有当 ACK=1 时，前面的确认号字段才有效；TCP 规定，连接建立后，ACK 必须为 1
PSH	告诉对方收到该报文段后是否立即把数据推送给上层。如果值为 1，表示应当立即把数据提交给上层，而不是缓存起来
RST	表示是否重置连接：若 RST=1，说明 TCP 连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接
SYN	在建立连接时使用，用来同步序号：当 SYN=1，ACK=0 时，表示这是一个请求建立连接的报文段；当 SYN=1，ACK=1 时，表示对方同意建立连接；ACK=1 时，说明这是一个请求建立连接或同意建立连接的报文；只有在前两次握手中 SYN 才为 1
FIN	标记数据是否发送完毕：若 FIN=1，表示数据已经发送完成，可以释放连接

窗口大小

TCP窗口：表示从Ack Number开始还可以接收多少字节的数据量，也表示当前接收端的接收窗口还有多少剩余空间，该字段可以用于TCP的流量控制。

检验位

TCP检验位：用于确认传输的数据是否有损坏，发送端基于数据内容校验数据内容生成一个数值，接收端根据接收的数据校验生成一个值。两个值必须一样，才能证明数据是有效的。如果两个值不同，就丢掉这个数据包。这里的校验位是根据伪头部 + TCP头部 + TCP数据三部分组成。

紧急指针

紧急指针字段：当且仅当前面的URG控制位为1的时候才有意义。他指出本数据段中为紧急数据的字节数，占16位。当紧急数据处理完之后，TCP就会告诉应用程序恢复到正常操作。所以即便是窗口大小为0，也是可以发送紧急数据的，因为紧急数据无需缓存。

可选项字段

选项：长度不定，但是长度必须是32bits的整数倍，选项中的内容不确定，因此就必须使用首部长度来区分选项具体的长度。

二丶TCP协议的特性

<1>TCP协议的特点

特点	含义
有连接	应用程序每次使用TCP协议之前，都要建立TCP连接。
可靠传输	网络数据的传输过程，是一跳一跳的经过所有途中的网络设备。就可能发生数据丢失。TCP提供可靠交付的服务。通过 TCP 连接传送的数据，无差错、不丢失、不重复，并且按序到达。
面向字节流	在连接没有关闭的时候，可以多次的接收和发送数据
有接收缓冲区和发送缓冲区	接收程序的时候，先由接收缓存区接收数据，然后再交给应用程序。发送数据的时候，先写到缓存区再发送。后面我们讲的确认应答机制和超时重传机制都会用到这两个缓存区。
大小不限	因为可以多次收发数据，且每次收发都可以很大，所以对于传输数据大小不限。

<2>可靠传输机制

1>确认应答机制

当接收端接收到一条报文的时候，就要向发送端发送一条确认ACK：我（接收端）已经成功的接收到了消息，我希望收到你（发送端）的下一条报文的序列号。

在这里插入图片描述
那确认应答机制存在的意义是什么呢？

那么确认应答机制的作用是什么呢？

那确认应答机制是怎么实现的呢？

2>超时重传机制

问题一：什么是超时重传机制？

有时候可能网络延迟什么的，或者说拥堵什么问题的，导致数据无法导致接收端。这个时候发送端就会重新发送数据报，如果接收端收到了重复报文，这个时候就是我们的序列号起作用的时候了，根据序列号去重。

问题二：超时的时间怎么设置？

3>连接管理机制

TCP三次握手

什么是三次握手？

所谓三次握手，指的是在TCP连接的过程中，发送端和接收端一共发送了三个包（第二次发送的时候是二包合一）。三次握手的主要目的就是确认一下，我发送端和你接收端的接收能力和发送能力都是正常的，同时指定自己的初始化序列号为后面的可靠性传输做准备。实际上也就是发送端连接接收端的指定的进程，建立TCP连接，并且同步双方的序列号和确认号，交换TCP窗口大小的信息。
那么现在正式开始我们的三次握手环节的讲解。先上图
在这里插入图片描述
初始我们的客户端是Closed状态，服务端是Listen状态。

第一次握手

第二次握手

第三次握手

关于三次握手中的一些问题

$\color{red}{三次握手可不可以只改成两次}$

$\color{red}{什么是半连接队列}$

$\color{red}{ISN是固定的吗？}$

$\color{red}{三次握手过程中可以携带数据吗？}$

TCP四次挥手

还是老规矩，先上图
在这里插入图片描述
这里可以发现，如果单单就发送数据包来说，三次握手和四次挥手的区别就是第二次握手的时候，挥手这里是把AKC报和FIN报分开发送了，但是握手是合在一起发送的。为什么会有这种情况出现呢？这是因为TCP的半关闭（half-close）造成的。所谓半关闭，就是连接的一端在结束它的发送之后还能接收来自另外一端数据的能力。
在正式讲解四次挥手之前，有一点需要注意，就是我们的发送端和接收端都是可以发起关闭连接的请求。这里我们假设是接收端发起的关闭连接请求。

第一次挥手

第二次挥手

第三次挥手

第四次挥手

关于四次挥手中的一些问题

$\color{red}{挥手为什么是四次？}$

$\color{red}{2MSL等待状态}$

4>流量控制

接收端处理数据的能力是有现的，如果一致发，而且发送数据报的速度很快，就会导致接收端的缓存区被沾满，然后后续的数据报就有很大的丢包风险。
所以TCP就会依据接收端的处理能力，来限制发送端的发送速度，这个机制就是流量控制。

问题来了，就是我们的窗口大小是16个比特位，最大接收是65535字节，那么窗口最大就是65535？不是的，我们的TCP首部还有一个窗口扩大因子M，实际上窗口大小应该是窗口字段的值往左移动M位。滑动窗口的大小，就是发送数据的大小，是以流量窗口大小为其中一个依据。

5>拥塞控制

虽然TCP已经有了滑动窗口机制，但是如果刚开始一次性发送大量数据还是会出现问题。因为网络上很多的计算机，可能当前的网络状态就是很拥塞的了，再发数据不是处理不过来了？这个时候就需要用到我们的拥塞控制机制

<3>效率传输机制

1>滑动窗口

首先来看一下，如果说没有滑动窗口，那么接收端和发送端之间，是怎样收发数据的
在这里插入图片描述
没错，就只能一个收，一个发，但是无疑，这样会很浪费时间。那既然一收一发的效率很低，那么我们就可以一次性发送多个，接收多个数据。
问：那么什么是滑动窗口？

问：那窗口大小怎么说？

问：那么窗口怎么滑动？

问：如果中途发生了丢包问题怎么处理？

在这里插入图片描述

这种机制也叫“高速重发机制”，也叫快重传。

2>延迟应答

如果说当接收端主机接收到数据包后立刻进行ACK应答，这个时候窗口可能有点小。什么意思呢？

流量窗口越大，那么网络吞吐量就越大，传输效率就越高，在保证网络不堵塞的情况下，我们努力提高这个窗口大小就行了。
当然，延时是为了提高吞吐量，但是也不能无限延迟，要根据以下两个因素来设置延迟应答

3>捎带应答

在延迟应答的基础上，我们发现，很多情况下，客户端服务器在应用层也是 “一发一收” 的。意味着客户端给服务器说了 “在吗老弟？”，服务器也会给客户端回一个 “在呢老哥。”；那么这个时候ACK就可以搭顺风车，和服务器回应的 “在呢老哥” 一起回给客户端。典型的例子就是三次握手中的二次握手。

<4>粘包问题

这个问题的话，我从哪里说起呢？

$\color{red}{什么是粘包问题？}$

首先，粘包粘包，你首先要知道他是个“包”’，然后才知道他是咋粘的。那么就从包说起。这里的包指的是什么包？
其实仔细想一想，我们好像突然真的可以发现数据包还真找不到一个具体的概念，因为TCP/IP五层模型中每一层对于数据包都有自己的称呼

所以可以发现这里的包其实只是一个抽象概念，所以粘包问题不仅仅是传输层才有的现象，它在数据链路层和传输层和网络层都是存在的。但是由于日常的网络开发都是在传输层，而UDP协议又有消息保护边界，所以粘包问题大都针对于TCP协议讨论。

然后，我们来说说“粘”，为什么会发生粘这个现象？关于这一点我想从TCP协议的定义往里面入手

那么这是什么意思呢？

那么流式传输最大的特点是什么呢？就是没有边界。

如果我们站在传输层来看，TCP就是一个一个报文过来的，按照序号排列在我们的缓存区中。但是如果说我们站在应用层来看，TCP就是一连串的字节数据。当应用层看到这一连串的字节数据的时候，就不知道从哪里开始，从哪里结束算是一个完整的应用层数据包。

$\color{red}{怎么解决？}$

三丶UDP协议

<1>UDP协议的格式

在这里插入图片描述

源端口号： 这个字段占据UDP报文的前16位，通常包含发送数据报的应用程序所使用的UDP端口。接收端的应用程序利用这个字段的值作为发送端响应的目的地址。这个字段是可选的，所以发送端的应用程序不一定会把自己的端口号写入该字段当中。如果不写入端口号，这个字段的值设置为0就好，这样的话接收端的应用程序就不能发送响应了。
目的端口号：接收端计算机上UDP软件使用的端口，占据16位。
UDP长度：占据16位，表示UDP数据报的长度，包含UDP报文头和UDP数据长度。UDP的报文头长度是8个字节，所以这个UDP长度最小为8
UDP检验和：用来校验数据在传输过程中数据是否有损坏。
数据：就是携带的数据。

<2>关于UDP和TCP协议的区别

回答这个问题，还是应该从TCP和UDP协议的特点来说。首先说一下UDP协议的特点

特点	含义
无连接	在使用UDP协议之前不需要建立稳定的连接
不可靠	没有可靠传输机制
面向数据报	一次性的发送所有数据，一次性的接收所有数据
有接收缓冲区，没有发送缓冲区	发送缓冲区：因为发送端不关心接收端是否接收到了信息，所以就不需要发送缓冲区来记录数据编号（超时重传机制才可以用到）。接收缓冲区：接收端此时还是可以接收到多组数据，接收端处理速度可能比发送端的发送速度要慢，所以就需要用接收缓冲区来保存数据
大小受限	最多64K

（PS：所以这个问题要结合UDP和TCP协议的特点来进行对比）

还要两个问题需要我们在这里提一下：

首先我们要明白，UDP协议被指定后传输层只能使用UDP协议，所以为了解决上述问题，我们可以在应用层自定义协议来去实现上述功能，具体的话参考TCP协议的功能实现原理。