文章目录

前言
Tcp协议段格式
TCP的可靠性
面向字节流
应答机制
超时重传
流量控制
滑动窗口（重要）
拥塞控制
延迟应答
捎带应答
标志位
具体标志位
三次握手
四次挥手
粘包问题
TCP异常情况
listen的第二个参数

前言

前面我们学习了传输层协议Udp，今天我们一起学习Tcp，Tcp比Udp复杂，但可靠，非常多的场景需要这种可靠。

Tcp协议段格式

在这里插入图片描述

只从格式来看，Tcp就比Udp复杂许多，那么Tcp的报头和有效载荷应当如何分离？

首先，报头前20个字节一定是固定的，我们先提取前20个字节，找到4位首部长度
然后，首部长度 * 4 -20，来查看是否有选项
最后，读完选项的字节，剩下的就是数据。

TCP的可靠性

大量丢包，乱序，重复，校验失败，发送缓慢，网络故障，都是不可靠的表现，正是因为传输距离变长，才会引发如此多的可靠性问题，为了解决这些问题。TCP引入了应答进制。

假如C给S发送了一条数据，只有当S给C了应答，C才认为自己的数据已经送到了S的手里，如果等待一段时间后没有收到这个应答，C就会认为自己发送的数据丢失了，会触发超时重传。

为了提高发送的效率，多个TCP报文会同步传送，这也就导致到达对端的数据没有顺序，而乱序正是我们要可靠问题，所以TCP报文注定是有编号的

面向字节流

应用层将数据拷贝到TCP的发送缓冲区，以 uint8 为一个单位将整个发送缓冲区划分。所以发送缓冲区天然带编号（数组下标）。

应答机制

上面我们知道TCP需要应答和编号，应答其实就是一个TCP报文中携带了ACK字段，而32位序号就是我们所说的编号，对端需要针对这个序号对我们做出ACK应答。

例如：C端发出了32位序号为10的报文，S端就要返回一个32确认编号为11的报文

发送序号：当前报文的编号。
确认序号：表示前面的报文已经全部收到，接下来应该从这个序号开始发送了。

由于Tcp报文具有捎带应答机制，即S发送ACK的时候，也有想要发给C的信息，所以必须设计为两个独立字段，而不能复用在一起。

超时重传

数据丢失的两种可能性：
1、数据半路真的丢包了
2、数据没有丢包，但ACK半路丢了

第一种情况，必然需要我们重传数据，也就要求TCP必须能做到暂时保存这些数据，以支持重传。
第二种情况，可以参考其他的ACK，因为如果只是ACK丢失，其他ACK的确认序号不会变。

等待时间：各个平台不同，在linux下以500ms为基准，n*500的方式动态调整。

流量控制

TCP具有接收缓冲区和发送缓冲区，也是全双工的，但只要是缓冲区就有大小，设想一下这样的场景：

C将报文送到了S，但S的接收缓冲区放不下了。在这种情况下，S只能丢弃掉来的报文，并不做应答，过一段时间，C会进行重传操作。

仔细一下就会发现这样是十分低效的，报文千里迢迢赶到对端主机，却因为对端没法接收而被丢弃，为了解决这个问题，TCP报文有一个叫做16位窗口大小的字段，这个字段填充自己的接收缓冲区的大小，对方拿到报文时就会看到这个大小，并根据此大小调整（增大或减小）发送数据的速度、大小。

窗口探测：
双端会定期向对方发送不携带数据的TCP报文，以此来询问对方的接收能力，调整自己发送数据的速度和大小（这个过程是双向的）

滑动窗口（重要）

TCP协议，可靠性是主要的研究问题，但效率问题，也是TCP需要考虑的问题。

发送方并发发送，一定要在对方能够接收的前提条件下，才能进行并发发送。

1、一般情况
在这里插入图片描述

一个发送缓冲区就被滑动窗口划分成了三个区域。

左边的区域：已经发送，且已经确认的数据——可以被覆盖的
中间的区域：可以直接发送（大小限制），但尚未收到应答
右边的区域：尚未发送的数据区域

滑动窗口的大小，应该与与对方的接收能力有关。

1.5、如何理解滑动窗口

字节流

2、特殊情况

1、滑动窗口只能向右，因为左边的数据已经没有了意义

2、变大变小本质是在调整winend，取决于对方的窗口大小，滑动窗口是浮动的

3、变成0，说明对方不能接收数据了（进行窗口探测，窗口通知）

4、应答也要按序到达
应答编号：winstart = seq；
应答窗口大小：winend = winstart + win；

5、丢失问题

a、第一个丢失了
重传补发

b、中间的丢失了
向右滑动，又变成了第一个丢失

c、最后一个丢失
也会变成最左侧丢失

快重传：（高速重发）
当某一个报文丢失，连续收到了三个一样的确认应答后，立马进行重传。

重传的下限：超时重传
重传的上限：快重传

拥塞控制

如果网络出现问题，TCP也进行了策略控制。

同样都是丢包，丢少和丢多也是不一样的，如果一直在丢包，那就是网络的问题。

当大量丢包的时候，发送方的发送策略是等等再发！！

如果网络出现瘫痪的时候，所有主机再次重传，会让瘫痪的网络更难以恢复，所以我们采用的策略是，如果发现了网络拥塞，要减少发送量。总的来说要符合以下两点要求：

1、保证网络拥塞不能加重
2、在网络恢复有起色时，尽快恢复网络通信

TCP引入了 慢启动 机制：

发生了网络拥塞，发送方要基本得知网络拥塞的严重程度，必须进行网络状态的探测

拥塞窗口
需要对网络状况进行衡量——拥塞窗口

网络状态时变化的，衡量网络健康状态，即拥塞窗口的大小一定是变化的。

因此发送方的滑动窗口 = min(16位窗口大小，网络的拥塞窗口)

拥塞窗口的增长速度是指数级别的，慢启动指的是前期慢，后期增长速度非常快。

1、慢启动有一个阈值
2、当拥塞窗口超过这个阈值后，不再指数增长，而是按线性增长
3、每次超时重发的时候，慢启动阈值（ssthresh）会变成原来的一半，同时拥塞窗口置为1（乘法减少）

延迟应答

立即返回ACK应答，返回的窗口大小可能会比较小。

给对方通告出更大的win大小，对方就能在更大概率上提高传送效率。给上层更多时间来读取，在这段时间尽快读取，且读取更多。

捎带应答

ACK搭顺风车。

标志位

标志位的本质

一个二进制位，来标识不同类型的报文

为什么要有标志位

不同的标志位提供不同的服务。

具体标志位

ACK：确认应答报文，可能携带数据（捎带应答）
SYN：连接请求的报文（三次握手）
FIN：连接断开的报文（四次挥手）
PSH：提示对方应用层尽快将缓冲区数据取走（多路转接）
RST：告诉对方要重新连接（连接被重置了）
URG：按序到达，但我们想插队？（紧急数据）16位紧急指针，紧急数据在有效载荷中的偏移量。紧急数据（带外数据）只有一个字节。（下载取消案例）recvfrom的MSG_OOB选项。

三次握手

在这里插入图片描述

1、什么是连接？
一个OS内一定右多个建立好的连接，OS必须要把这些连接管理起来。
维护连接是有成本的，必然要消耗CPU、内存资源。
2、为什么是三次？
三次握手过程，由双方操作系统在TCP自主完成
connect：触发连接，等待完成
accept：等待建立完成，获取连接

对于客户端来说，只要发出了最后一个ACK，就认为链接已经建立好了。
对于服务端来说，只有收到了最后一个ACK，服务器才消耗资源构建。

因此，三次握手本质在赌服务端的确收到了最后一个ACK。假如没有收到ACK，两者建立认知不一致了，这时候客户端再给服务端发消息，服务端就会回复一个RST，进行连接重置
- 如果两次握手，只要发出SYN+ACK就得浪费资源构建。容易被SYN洪水攻击。注意，TCP本身并不考虑解决安全问题，但TCP不能出现安全漏洞！因此需要规避SYN洪水。
- 如果大于3次握手，仍然解决不了最后一个ACK问题，如果是偶数次握手，最后一个ACK是服务器端承担风险、奇数次握手是客户端承受风险。而服务器端保存着大量的数据，出现异常是必然的，固而两次以及偶数握手是不妥的
- 3次握手的好处：
  1、没有明显漏洞，出现异常，成本嫁接到客户端
  2、验证双方通信信道通畅情况，是验证流畅（全双工）的最小成本（收、发）
3、状态变化
SYN_SENT：同步发送
SYN_RCVD：同步收到
ESTABLiSH：建立完成

四次挥手

在这里插入图片描述
四次挥手，是双方建立连接断开共识的最小成本！必须要双方同意（都不发消息）！

状态变化：

当客户端退出，服务器端不调用close的时候，服务端进入CLOSE_WAIT状态，服务端进入FIN_WAIT2的状态。

在这里插入图片描述

一段时间后，客户端的FIN_WAIT2消失，服务端仍是CLOSE_WAIT状态。所以，对于服务器端，要关掉文件描述符！

调用close后，服务器端立马进入LAST_ACK状态，并发送FIN给对端，如果对端已经关闭，在经历几次重传后，服务器端也会断开连接。

主动断开的一方，要进入TIME_WAIT状态，此时立马想要重启，会失败，原因是底层连接还在，正处于TIME_WAIT状态。

1、为什么要进入TIME_WAIT

TCP协议规定，主动断开连接的一方，要等待两个MSL时间（一个报文在网络里存在的最大时间），
- 1、让网络中的报文尽快消散，防止对新的连接产生影响。
- 2、保证最后一个ACK让对方收到。对方如果没收到最后一个ACK，会再发送FIN。

2、如果server不想等待

//设置地址可以复用，令服务器立马重启
setsockopt(int sockfd,int level,int optname,const void* optval,socklen_t optlen)
参数：
sockfd：套接字
level：当前在哪一层（SOL_SOCKET）
optname：（SO_REUSEADDR | SO_REUSEPORT）
optval:1
optlen:len