【Linux网络编程】传输层中的TCP和UDP（TCP篇）

【Linux网络编程】传输层中的TCP和UDP（TCP篇）
- TCP协议
- - TCP协议段格式
  - 确认应答（ACK）机制（保证可靠性）
  - 超时重传机制
  - 连接管理机制
  - 理解TIME_WAIT状态
  - 解决TIME_WAIT状态引起的bind失败的方法
  - 理解CLOSE_WAIT状态
- 滑动窗口
- - 流量控制
  - 拥塞控制
  - 延迟应答
  - 捎带应答
  - 面向字节流(读写次数不用完全匹配)
  - 粘包问题
  - TCP异常情况
  - TCP小结
  - 基于TCP应用层协议
- TCP/UDP对比
- 如何用UDP实现可靠传输（经典题目）

作者：爱写代码的刚子

时间：2024.5.14

前言：本篇博客将会介绍TCP底层，了解TCP机制

TCP协议

TCP全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制，由操作系统决定什么时候发；UDP为什么不是传输控制协议？因为UDP没有发送缓冲区

TCP也是全双工的，可以从同一个文件描述符里面读和写，因为里面有读和写缓冲区（内存空间，由多个struct page（内存块）构成）

TCP里面的缓冲区相当于一个系统级别的生产者消费者模型

TCP虽然保证可靠性，但是TCP允许连接建立失败

TCP协议段格式

在这里插入图片描述

源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;
32位序号/32位确认号: 后面详细讲;
4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部最大长度是15 * 4 = 60 （也就是报头 + 选项的长度）[0000,1111] => [0,15] => [0,60]. 通过这种方法来将报头和有效载荷进行分离
6位标志位（区分报文的类型）:
- URG: 紧急指针是否有效
- ACK: 确认号是否有效
- PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
- RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
- SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
- FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段
16位窗口大小:用于告知己方的内核接收缓冲区剩余空间的大小
16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分.
16位紧急指针：标识哪部分数据是紧急数据（如果URG无效则紧急指针无意义）通过偏移量的方式标识，但是TCP中紧急数据一般只允许携带一个字节；
40字节头部选项：暂时忽略

client和server基于tcp协议进行通信的时候互发消息的时候，发送的是完整的tcp报文，一定携带完整的tcp报头

【问题】：什么时候会用到紧急指针呢？

如果服务端卡顿了，缓冲区里面的数据没有被读取，我们客户端可以向服务端发送紧急数据，服务端由于设置过能处理紧急数据，其他数据要被处理需要排队，服务端有固定的例程去读取紧急数据，于是服务端就可以将当前软件功能提供的状态编号反向提供给客户端。（避免了排队）

确认应答（ACK）机制（保证可靠性）

这个世界上，不存在100%可靠的网络协议，因为最新的一条消息是没有应答的，但是局部上是可靠的。

确认应答机制贯穿整个TCP协议的设计
数据发送方向另一端发送报文,数据接收方收到报文后向数据发送方回应一个ACK报文进行应答,数据发送方接收到ACK应答则可以确定自己发送的某个报文是否被对方接收到

在这里插入图片描述

ACK应答本身的传输是否可靠是无法得到保证的,即应答方无法得知自己的ACK报文是否传输成功,因此确认应答机制保证的是单方向上的数据传输可靠性(可以理解成牺牲ACK报文来保证通信报文的可靠传输),于是双方互相执行确认应答,便可以保证数据的双向可靠传输
为了提升效率，TCP并不是采用收到一条消息就应答的方式，而是发送一批数据。（与带宽有关）但是服务器收到的报文顺序很可能与客户端发送的报文顺序不同（数据包乱序问题）

所以TCP将每个字节的数据都进行了编号. 即为序列号（报文中的32位序号来保证数据按序到达）.

【问题】：由于我们发送了一批报文，同时收到一批响应，但是我们如何区分报文对应的响应呢？

通过报头中的32位确认信号来区分，确认序号填充的是收到报文的序号 + 1

（如果收到了2001的报文，代表2001之前的报文都被收到了，如果再发送就从2001开始，这种机制允许了应答有少部分丢失）

每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据;下一次你从哪里开始发.

在这里插入图片描述

【问题】：为什么要有32位序号和32位确认序号这两个字端呢，一个不也行吗？

这样做类似于捎带应答，能提高效率（一个报文可能有双重身份，既可能是应答又可能携带了数据）

【问题】第三次握手客户端向服务端发送ACK代表链接建立好还是服务端收到ACK代表链接建立好？

客户端向服务端发送ACK代表链接建立好，因为客户端并不知道服务端是否收到ACK，客户端先发送数据，服务端如果没有收到ACK则会将收到的报文丢弃

TCP缓冲区以字节为单位进行编号（本质就是数组下标）

但是实际上这个编号和数组下标是两套概念，因为为了保证TCP的可靠性，开始的序号可能是一个随机值。

超时重传机制

主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B;
如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发;

但是, 主机A未收到B发来的确认应答, 也可能是因为ACK丢失了;

因此主机B会收到很多重复数据. 那么TCP协议需要能够识别出那些包是重复的包,并且把重复的丢弃掉. 这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果.

那么, 如果超时的时间如何确定?

最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.
但是这个时间的长短, 随着网络环境的不同, 是有差异的.
如果超时时间设的太长, 会影响整体的重传效率;
如果超时时间设的太短, 有可能会频繁发送重复的包

TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间.(这个时间是动态的，和网络状况是强相关的)

Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍.
如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传.
如果仍然得不到应答, 等待 4*500ms 进行重传（下次为8 * 500ms）. 依次类推, 以指数形式递增.
累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接

丢包重传是由操作系统中TCP自主决定的

在这里插入图片描述

连接管理机制

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

在这里插入图片描述

上面所有的数据报头的往来，其实发的是裸的TCP报头，只不过是标记位被设置

建立连接一方主动一方被动，但是关闭连接要双方都没信息才断开。TCP通信是基于连接的，建立和断开，三次握手和四次挥手

【问题】：为什么要三次握手，为什么要四次挥手？

本质都是一来一回保证可靠性

为什么要三次握手？

原本是四次握手的，但是中间两个报文被我们捎带应答了

为什么要四次挥手？

按理来说我们也可以采用捎带应答的方式使用三次挥手，但是有时候服务器并不想与客户端断开连接，所以服务器并不想发送FIN，这种情况就不能使用捎带应答来强迫服务器发送FIN。（三次是四次的最小集）

断开连接的本质是没有数据给对方发送了（但是可以发一些管理报文，如：ACK）

对于三次握手再换一种说法：

说法一：验证全双工：无论是客户端还是服务器都至少有一次发和一次收（简称验证全双工是否通畅）。

如果是单次握手（一次握手就成功了），客户端持续向服务器发送SYN，服务端要接着，这会占用服务器资源（SYN洪水）（其实三次握手也会有这样的问题，但是第一次收到SYN，由于连接没有完全建立，很快就被释放掉，但是如果是单次握手，连接已经建立好了，释放的速度就会比较慢）
如果是两次握手：客户端向服务器发送SYN，服务器再发送ACK（服务器发送ACK之前我们就认为连接就已经建立好了），所以服务端先把连接建立好，其实如果客户端不管服务器发来的ACK，那就和单次握手的问题是一样的。两次握手的情况下我们要求服务器的连接先建立好。（因为存在客户端发完SYN就崩了，但是服务器依旧向客户端发送数据的情况，依旧挂着异常连接，所以必须是服务器先建立连接），所以要优先让服务器做出建立连接的动作。

服务器是1对多的，不能对客户端的资源进行让步，不能让异常情况由服务器承担
三次握手：前两次的发送数据出现丢包我们是不担心的，因为存在应答，但是第三次发送ACK时存在丢包，客户端的对服务器的连接没有建立成功，服务器没有收到SYN所以认为连接没有建立成功，出现异常的成本由客户端来承担，重新发送报文，这是合理的。

**说法二：**奇数次的握手，可以确保一般情况握手失败的连接成本是嫁接在客户端的。

三次握手其实是验证全双工的最小次数

通过netstat -ntp能查看状态

连接建立成功和上层有没有accept没有关系

三次握手是双方操作系统自动完成的！

listen的第二个参数： backlog + 1表示底层已经建立好的全连接队列（队列中的连接会被accept获取到上层）的最大长度，如果全连接队列满了客户端会认为连接建立成功，但是服务器并不会认为建立成功，服务器处于SYN_RCVD状态（这是因为客户端发起了第三次握手，但是由于服务器的全连接队列已经满了，所以服务器会将客户端发来的ACK丢弃(前两次握手是成功的)）

同时，服务端不会长时间维护syn_recv，被建立连接的一方，处于syn_recv，半连接，处于半连接队列（长度由内核决定），半连接的节点不会长时间维护。（这样就会存在客户端和服务器链接建立不一致的问题）

进入全连接队列前先要进入半连接队列，所以半连接队列有可能被一些非法链接打满了（真正意义的SYN洪水）TCP随机序号还有cookie机制、限制连接速率、调整TCP堆栈参数等可以解决（网页出现404有可能是这个原因）

【问题】：listen的第二个参数为什么不能太长？为什么不能没有？

如果太长了会导致有些链接来不及被上层处理但依旧要在系统内维持，如果服务器太忙会导致系统资源占用，设置短一点能腾出一些资源（没必要太长，来不及处理）

那为什么不能没有半连接队列呢，这个道理类似于接客，客流量大了没什么区别，但是如果客流量小了服务器就会闲着，所以有必要让一些链接进行等待等到服务器有时间了就能处理链接，提高时间、资源利用率。

服务端状态转化：

[CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态, 等待客户端连接;
[LISTEN -> SYN_RCVD] 一旦监听到连接请求(同步报文段), 就将该连接放入内核等待队列中, 并向客户端发送SYN确认报文.
[SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端的确认报文, 就进入ESTABLISHED状态, 可以进行读写数据了.
[ESTABLISHED -> CLOSE_WAIT] 当客户端主动关闭连接(调用close), 服务器会收到结束报文段, 服务器返回确认报文段并进入CLOSE_WAIT;
[CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据); 当服务器真正调用close关闭连接时, 会向客户端发送FIN, 此时服务器进入LAST_ACK状态, 等待最后一个 ACK到来(这个ACK是客户端确认收到了FIN)
[LAST_ACK -> CLOSED]服务器收到了对FIN的ACK，彻底关闭连接

客户端状态转化：

[CLOSED -> SYN_SENT] 客户端调用connect, 发送同步报文段;
[SYN_SENT -> ESTABLISHED] connect调用成功, 则进入ESTABLISHED状态, 开始读写数据;
[ESTABLISHED -> FIN_WAIT_1] 客户端主动调用close时, 向服务器发送结束报文段, 同时进入 FIN_WAIT_1;
[FIN_WAIT_1 -> FIN_WAIT_2] 客户端收到服务器对结束报文段的确认, 则进入FIN_WAIT_2, 开始等待服务器的结束报文段;
[FIN_WAIT_2 -> TIME_WAIT] 客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出LAST_ACK;
[TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life, 报文最大生存时间)的时间, 才会进入CLOSED状态.

理解TIME_WAIT状态

注意，要看到FIN_WAIT_2状态必须调用accept接口将链接获取上来，

主动断开连接的一方会在4次挥手之后进入TIME_WAIT的状态，等待若干时长之后自动释放

现在做一个测试,首先启动server,然后启动client,然后用Ctrl-C使server终止,这时马上再运行server, 结果是:

bind error：Address already in use

这是因为，如果主动断开连接的一方是服务方，服务方就要进入TIME_WAIT状态，连接没有被彻底断开，IP和PORT还在被使用，端口号不能被两个不同的进程绑定，所以新起的进程不能绑定端口号

如何解决这种TIME_WAIT情况呢？

设置套接字选项：

int opt = 1;//将套接字选项设为有效
setsockopt(listensock_, SOL_SOCKET,SO_REUSEADDR | SO_REUSEPORT ,&opt ,sizeof(opt));//SO_REUSEPORT选项可以适配不同系统版本

该选项：启动地址复用，如果是服务器正常使用，启动就失败，如果IP和port被使用是因为TIME_WAIT状态，则立即重启，因为TIME_WAIT状态不进行通信，不影响后续通信

【问题】：为什么客户端不存在TIME_WAIT？

因为客户端使用的是随机端口，再启动时就是另一个端口号了。

MSL：指的是一个报文在网络中存活的最长时间（报文在网络中阻塞的时长、存在时长）
TCP协议规定,主动关闭连接的一方要处于TIME_ WAIT状态,等待两个MSL(maximum segment lifetime) 的时间（一来一回）后才能回到CLOSED状态.
我们使用Ctrl-C终止了server, 所以server是主动关闭连接的一方, 在TIME_WAIT期间仍然不能再次监听同样的server端口;
MSL在RFC1122中规定为两分钟,但是各操作系统的实现不同, 在Centos7上默认配置的值是60s;
可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 查看MSL的值;
规定TIME_WAIT的时间参考UNP

在这里插入图片描述

服务端如果在LAST_ACK状态向客户端发起FIN，客户端需要维持TIME_WAIT状态，如果服务端没有收到ACK则可以进行补发FIN。

为什么TIME_WAIT的时间是2MSL?

MSL是TCP报文的最大生存时间, 因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据, 但是这种数据很可能是错误的);
同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失, 那么服务器会再重发一个FIN. 这时虽然客户端的进程不在了，但是TCP连接还在，仍然可以重发LAST_ACK);

小结：

TIME_WAIT可以让通信双方历史在网络中存在的数据得以消散（客户端和服务端将数据丢掉，避免极端情况，避免对后续过程产生影响），所以我们之前谈到的报文序号起始位置的随机性，不管是发送方还是接收方，可以规避一些黑客猜序号以及历史上的报文对我们通信的影响。
让我们断开连接，4次挥手，具有较好的容错性

最大存在时长：报文在网络中阻塞的时长

所以TIME_WAIT并不是毫秒级别的，必须等待网络中的报文

解决TIME_WAIT状态引起的bind失败的方法

在server的TCP连接没有完全断开之前不允许重新监听, 某些情况下可能是不合理的

服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短, 但是每秒都有很大数量的客户端来请求).
这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃, 就需要被服务器端主动清理掉), 就会产生大量TIME_WAIT连接.
由于我们的请求量很大, 就可能导致TIME_WAIT的连接数很多, 每个连接都会占用一个通信五元组(源ip, 源端口, 目的ip, 目的端口, 协议). 其中服务器的ip和端口和协议是固定的. 如果新来的客户端连接的ip和端口号和TIME_WAIT占用的链接重复了, 就会出现问题.

使用setsockopt()设置socket描述符的选项SO_REUSEADDR为1, 表示允许创建端口号相同但IP地址不同的多个 socket描述符

修改操作系统参数：缩短TIME_WAIT持续时间
设计上规避TIME_WAIT：
- 尽量减少短连接:通过保持长连接（例如使用HTTP Keep-Alive）来减少频繁建立和关闭连接，从而减少进入TIME_WAIT状态的机会。
- 负载均衡:使用负载均衡器（如Nginx、HAProxy）将流量分发到多个后端服务器，可以有效减少单个服务器的端口占用率。

理解CLOSE_WAIT状态

双方在进行四次挥手时，如果只有客户端调用了close函数，而服务器不调用close函数，此时服务器就会进入CLOSE_WAIT状态，而客户端则会进入到FIN_WAIT_2状态。
但只有完成四次挥手后连接才算真正断开，此时双方才会释放对应的连接资源。如果服务器没有主动关闭不需要的文件描述符，此时在服务器端就会存在大量处于CLOSE_WAIT状态的连接，而每个连接都会占用服务器的资源，最终就会导致服务器可用资源越来越少。
因此如果不及时关闭不用的文件描述符，除了会造成文件描述符泄漏以外，可能也会导致连接资源没有完全释放，这其实也是一种内存泄漏的问题。
因此在编写网络套接字代码时，如果发现服务器端存在大量处于CLOSE_WAIT状态的连接，此时就可以检查一下是不是服务器没有及时调用close函数关闭对应的文件描述符。

小结: 对于服务器上出现大量的 CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭 socket, 导致四次挥手没有正确完成. 这是一个 BUG. 只需要加上对应的 close 即可解决问题.

滑动窗口

前提：

已经发出去，但是暂时没有收到应答的报文要被tcp暂时保存起来,可能会在发送方存在多个没收到应答的报文，那么它们会被保存到哪里呢？

刚才我们讨论了确定应答策略，对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候

既然这样一发一收的方式性能较低, 那么我们一次发送多条数据, 就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了).

在这里插入图片描述

滑动窗口 ——在哪？是我们发送缓冲区的一部分

已发送但未确认的区域可以是多大？是对方接收窗口（目前理解）

滑动窗口的区域划分怎么做到的（数组下标，TCP中维护几个整数，相当于双指针）窗口滑动本质是指针右移

【问题】为什么采用将滑动窗口中的数据按区域发送，而不是直接打包整体发送呢？

与硬件有关，网卡不允许发送大块数据。（数据链路层知识）

窗口大小指的是无需等待确认应答而可以继续发送数据的最大值. 上图的窗口大小就是4000个字节(四个段).

发送前四个段的时候, 不需要等待任何ACK, 直接发送;

收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推; 操作系统内核为了维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;

窗口越大，则网络的吞吐率就越高；

在这里插入图片描述

【问题】：如果丢包了怎么理解滑动窗口？

我们对于确认序号的定义：确认序号是x，x之前的报文我们全部收到了(允许少量ACK丢失)

如果3001报文的ACK丢了，即使收到了4001、5001的ACK，确认序号也只能填2001（2001～3000的报文是丢的），所以窗口在向右滑动时不会出现越过丢包的情况

确认认序号的存在保证了滑动窗口线性地连续的向后更新，不会出现跳跃的情况

**情况一：**数据包已经抵达，ACK被丢了

在这里插入图片描述

这种情况下, 部分ACK丢了并不要紧, 因为可以通过后续的ACK进行确认;

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

在这里插入图片描述

当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 “我想要的是 1001” 一样;
如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送;
这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中;

这种机制被称为“高速重发控制”（也叫“快重传”）。

已经有快重传，为什么还要有超时重传？（快重传是有条件的，超时重传是兜底的）

【问题】：向左移动？向右移动？移动的时候窗口大小会变化吗，怎么变化，会为0吗？

不会向左移会向右移，窗口大小是动态变化的（变大，变小，不变，取决于对方的接收能力）

变小右不变，左移动：对方的上层一直不取数据

变大，整体向右：对方通知了一个更大的窗口

窗口的指针：

int start = 根据确认序号，设置。确认序号

int end = 确认序号 + min(win , 有效数据)大小(应答中对方的接收能力)(两个变量三种情况)

【问题】：滑动窗口，会在发送缓冲区中越界吗？

tcp采用了类似环状算法（物理上是线性结构，逻辑上是环形结构。）

随机序号+TIME_WAIT能有效让历史上的数据消散

确认序号 - 随机起始序号 = 下次发送数据在缓冲区中的位置

流量控制

接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传（不能滥用重传机制，这是一种效率低下的表现）等等一系列连锁反应.
因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);

接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端;

窗口大小字段越大, 说明网络的吞吐量越高;

接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;

发送端接受到这个窗口之后, 就会减慢自己的发送速度;

如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端.

在这里插入图片描述

接收端如何把窗口大小告诉发送端呢? 回忆我们的TCP首部中, 有一个16位窗口字段, 就是存放了窗口大小信息; 那么问题来了, 16位数字最大表示65535, 那么TCP窗口最大就是65535字节么?
实际上, TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是窗口字段的值左移 M 位;（但是还是要看操作系统是否支持缓冲区大小）

【问题】：第一次发送数据的时候，怎么保证发送数据量是合理的？

不要理解三次握手只是三次握手，双方也交换了报文！！，已经协商了双方的接收能力，第三次握手的时候就可以携带数据了

主机在进行窗口探测时不会携带数据，如果通信不成功，重传一定次数后，双方要主动关闭异常连接

【问题】：流量控制属于可靠性还是属于效率？

属于可靠性：因为可以防止丢包

属于效率：减少丢包，提高效率

两者不冲突，可靠性为主。

拥塞控制

如果发送数据，出现问题，不仅仅是对方主机出现了问题，也可能是网络出现了问题！

如果通信的时候，出现了少量的丢包（常规情况）
如果通信的时候，出现了大量的丢包（网络出现了问题：硬件设备问题，数据量太大引起阻塞）

【问题】：如果通信双方出现了大量的数据丢包问题，tcp会判断网络出问题了（网络拥塞了，大量的数据没收到应答，超时了）我们发送方，应该怎么办？？？

我们不能立即对报文进行超时重发，会加重网络拥塞。

TCP协议实现了多主机面对网络出现拥塞时的“共识”

拥塞控制的策略——每台识别主机拥塞的机器都要做

虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题.
因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据, 是很有可能引起雪上加霜的.

TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;

此处引入一个概念程为拥塞窗口
发送开始的时候, 定义拥塞窗口大小为1;
每次收到一个ACK应答, 拥塞窗口加1;
每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;

滑动窗口大小 = min(窗口大小，拥塞窗口大小) 两者决定了上限

窗口大小：考虑对方主机的接收能力

拥塞窗口：考虑的是动态的，网络的接收能力，网络是动态的，拥塞窗口本身肯定不能是静态的！

像上面这样的拥塞窗口增长速度, 是指数级别的. “慢启动” 只是指初使时慢, 但是增长速度非常快.

为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍.
此处引入一个叫做慢启动的阈值
当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长

在这里插入图片描述

当TCP开始启动的时候, 慢启动阈值等于窗口最大值;
在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1;

少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;
当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.

网络出现拥塞，发送少量的报文，如果都ok，网络已经趋于健康了，应该尽快恢复正常通信了。（前期慢，增长幅度高）

延迟应答

【问题】为什么要延迟应答？

给上层充分的时间，来取走数据，收到报文不着急应答，有可能会让接收方获得更大的窗口（延迟应答博概率）

比较推荐的做法：

每次都尽快通过read、recv尽快的把数据全部从内核中拿上来！

如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小.

假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;
但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;
在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;

一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;

那么所有的包都可以延迟应答么? 肯定也不是;

数量限制: 每隔N个包就应答一次;

时间限制: 超过最大延迟时间就应答一次;

具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms;

延迟应答时间一定比超时时间要短的

延迟应答是为了提高效率

捎带应答

在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的. 意味着客户端给服务器说了 “How are you”, 服务器也会给客户端回一个 “Fine, thank you”;
那么这个时候ACK就可以搭顺风车, 和服务器回应的 “Fine, thank you” 一起回给客户端

面向字节流(读写次数不用完全匹配)

创建一个TCP的socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区;

调用write时, 数据会先写入发送缓冲区中;
如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区; 然后应用程序可以调用read从接收缓冲区拿数据;
另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工

由于缓冲区的存在，TCP程序的读和写不需要一一匹配，例如：

写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;
读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节，重复100次；

TCP面向字节流，UDP面向数据报

内核中只认识字节数据，一次取多少由用户决定，再转化为多个报文，再对报文进行一个一个处理，将字节流变成一个一个完整的请求

如果不定任何标准和约定，用户就有可能读取一个半的报文，并对之后的报文产生影响从而导致数据包粘包问题。

粘包问题

首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包.
在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段. 站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中.
站在应用层的角度, 看到的只是一串连续的字节数据.
那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包.

那么如何避免粘包问题呢? 归根结底就是一句话, 明确两个包之间的边界.

对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可;
对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置; 对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可);

思考: 对于UDP协议来说, 是否也存在 “粘包问题” 呢?

对于UDP, 如果还没有上层交付数据, UDP的报文长度仍然在. 同时, UDP是一个一个把数据交付给应用层. 就有很明确的数据边界.
站在应用层的站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收. 不会出现”半个“的情况。

所以相对于用户层的概念解决粘包问题：定协议（Encode和Decode原因）

解决用户层的粘包问题？