【计算机网络】Tcp详解

文章目录

• 前言
• 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

粘包问题

TCP没有UDP里面的报文长度字段，我们并不知道两个数据的边界，这样的问题就是粘包问题

解决：明确两个包之间的边界（上层去完成）。

TCP异常情况

进程终止/机器重启：进程终止会释放文件描述符，仍然发送FIN，和正常关闭一样（操作系统回收所有相关资源）

机器掉电/网线断开：对端认为连接还在，一旦接收端有写入操作，发现连接不在了，就会reset，服务器发送保活定时器，发送端也可reset

listen的第二个参数

设置第二个参数为1，连接服务器，一定程度后，进入SYN_RECV，即已经建立好的链接只能是两个。

TCP协议，需要在底层维护全连接队列，最大长度为：第二个参数 + 1

将没有连接到半连接队列，时间非常断。

全连接队列不能太长，也不能没有。全连接的长度不是服务器处理的长度，而是一个 "排队" 的地方.

1、会消耗过多的OS资源，不如给server使用

2、尾部等待太长。