TCP协议(一)

TCP协议格式

• 源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;
• 32位序号/32位确认号
• 4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部最大长度是15 * 4 = 60
• 6位标志位
  URG: 紧急指针是否有效
  ACK: 确认号是否有效
  PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
  RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
  SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
  FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段
• 16位窗口大小
• 16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分.
• 16位紧急指针: 标识哪部分数据是紧急数据;
• 40字节头部选项: 暂时忽略;

连接管理机制

也是可靠性的一部分

• 建立连接的意义
  （1）双方先打探一下对方是否适合和我建立通信
  （1）双方可以协商一些重要的数据，比如序号从几开始

TCP要经过三次握手建立连接 点开该链接，四次挥手断开连接

理解TIME_WAIT状态

• TCP协议规定,主动关闭连接的一方要处于TIME_ WAIT状态,等待2个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态.
• MSL在RFC1122中规定为两分钟,但是各操作系统的实现不同, 在Centos7上默认配置的值是60s;
  为什么是2个MSL？
• MSL是TCP报文的最大生存时间
• 能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据, 但是这种数据很可能是错误的);
• 同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失, 那么服务器会再重发一个FIN. 这时虽然客户端的进程不在了, 但是TCP连接还在, 仍然可以重发LAST_ACK);

确认应答(ACK)机制

对于序号来说，按照每个字节的方式来编号
每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 当前序号之前的数据我已经正确收到了，对端应该给我发确认序号开始的数据

超时重传机制

可靠性的核心机制，和确认应答相辅相成

1. 概念：
   （1）主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B；如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发；重传是为了降低丢包的可能性，重传的时间间隔是一种悲观的态度，等待时间越来越长，如果达到一定的次数之后对方还未响应，就断开和对方通信的链接。
   （2）如果是主机A未收到B发来的确认应答, 也可能是因为（应答数据包）ACK丢失了;因此主机B会收到很多重复数据. 那么TCP协议需要能够识别出哪些包是重复的包, 并且把重复的丢弃掉. 这时候我们可以利用前面提到的序列号，起到去重的效果。
2. 超时的时间如何确定?

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

3. TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间.

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

滑动窗口（提高传输效率）

窗口的含义：不等待ACK的情况下最多发多少数据
滑动的含义：每次收到ACK数据的同时，就继续往后发下一组数据
由于往返时间长的话会导致性能较差，如果一次发送多条数据就可以大大提高性能，就是将多个时间段的等待时间重叠在一起

• 系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;
• 窗口越大，传输效率越高，但是窗口不能太大，否则会影响可靠性
  如果出现了丢包如何重传？
• 采用快速重传的方式，本质上还是超时重传；只是重传的时候只传了真正丢包的数据

1. 数据包已经从客户端到服务器了，但是服务器发给客户端的ACK丢了，这种情况下，部分ACK虽然丢了，但是可以通过后续的ACK进行确认
2. 数据包直接丢了
   当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 "我想要的是 1001"一样;如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送;这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中

流量控制（Flow Control）

定义：如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包，继而引起丢包重传等等一系列连锁反应.因此TCP支持根据接收端的处理能力, 来决定发送端的发送，这个机制就是流量控制。

• 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端;
• 窗口大小字段越大, 说明网络的吞吐量越高；但是窗口不能无限大，太大的话接收端可能处理不过来
• 接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端；发送端接受到这个窗口之后, 就会减慢自己的发送速度;
• 如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端。根据接收端的处理能力，来决定发送端的发送速度
• 接收端如何把窗口大小告诉发送端呢?
  我们的TCP首部中, 有一个16位窗口字段, 就是存放了窗口大小信息;
  16位数字最大表示65535, 那么TCP窗口最大就是65535字节么?
  实际上, TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是 窗口字段的值左移 M 位;
• 使用接受缓冲区空余空间大小，用这个指标衡量接受端的处理能力，并用这个指标来控制发送端窗口的大小（发送速度）
• 接受端的缓冲区空余空间大小，作为TCP协议报头中的窗口大小，这个值就是发送端滑动窗口大小的一个“建议值”

拥塞控制

虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题，滑动窗口不能太大，即使接收端处理速度很快，也可能因为网络环境不佳导致数据丢包。
因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据, 是很有可能引起雪上加霜的.
TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;

• 此处引入一个概念程为拥塞窗口
• 发送开始的时候, 定义拥塞窗口大小为1;
• 每次收到一个ACK应答, 拥塞窗口加1;
• 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;
  像上面这样的拥塞窗口增长速度, 是指数级别的. “慢启动” 只是指初使时慢, 但是增长速度非常快.
• 为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍.
• 此处引入一个叫做慢启动的阈值
• 当拥塞窗口超过这个阈值的时候,不再按照指数方式增长,而是按照线性方式增长
  当TCP开始启动的时候, 慢启动阈值等于窗口最大值;
  在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1;
  少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;
  当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;
  拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案

最终的滑动窗口大小由 流量控制 和 拥塞控制 共同决定

拥塞窗口：拥塞控制所建议的窗口大小，从一个比较小的数字开始，如果网络畅通，放大窗口大小；如果网络丢包，缩小窗口大小。

滑动窗口的最终值：流量控制的窗口 和 拥塞窗口的较小值