TCP协议

TCP协议格式

1. 16位源端口号：发送该报文主机的端口号
2. 16位目的端口号：要发送目标主机的端口号
3. 32位序号：发送数据的顺序和接收数据的顺序可能不一样，所以需要标记对方主机发送数据的顺序，所以就有了32位序号
4. 32未确认序号：接收方给应答方的一种回应序号，例如发送方发送的32位序号为1000——2000，那么接受方就应该给发送方发送2001，表示，接收到了数据，也表示下一次发送数据从2001开始发送
5. 4位首部长度：表示报头有多少个32个比特位，所以报头的最大长度为15*4=60个字节,最短为20个字节
6. 16位校验和：发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也 包含TCP数据部分
7. 滑动窗口：由网络状况和接收方缓冲区剩余大小决定
8. 六为标志位：

• URG:紧急指针是否有效
• ACK：确认号是否有效
• PSH:表示接收端立刻把数据从接收缓冲区拿走
• RST：对方要求重新建立连接，我们把携带RST标志位的报文称为复位报文段
• SYN：请求建立连接，这是我们会把发送出去的报文中的
• SYN标志位值为一FIN：当需要断开连接的时候，报文中会携带该标志位

确认应答(ACK)机制

TCP将每个字节的数据都

 

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

超时重传机制 

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

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

 

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

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

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

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

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

连接管理机制 

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

 

连接时：

• 在连接时客户端会向服务端先发送SYN请求，在发送完SYN请求后客户端会进入SYN_SENT状态
• 服务端在接受到SYN请求后，不会立马变为SYN_RCVD状态，在向客户端发送完SYN连接请求和ACK应答之后，才会进入SYN_RCVD
• 客户端在接收到服务端的SYN连接请求和ACK应答之后，再向服务端发送ACK应答后，会变为ESTABUSHED状态
• 服务端接收到应答之后会变为ESTABUSHED状态

断开时：

• 客户端会向服务端发送FIN断开连接的请求，在发送完成之后会进入FIN_WAIT_1状态
• 服务端在接收到FIN请求并向客户端发送ACK应答之后会进入CLOSE_WAIT状态
• 服务端向客户端发送FIN断开连接请求后会进入LAST_ACK状态、
• 客户端在接收到服务端发来的ACK后会进入FIN_WAIT_2，再接收到FIN后会进入TIME_WAIT
• 客户端再向服务端发送ACK应答之后，再经过一段时间会变为CLOSED状态
• 服务端在接收到客户端的ACK应答之后会变为CLOSED，至此客户端和服务端才算完整断开连接

理解TIME_WAIT状态

• 客户端在发送完应答之后，会经过俩个MSL才会进入CLOSED状态
• 在TIME_WAIT期间，端口号是不会被释放的，依旧是处于被占用状态
• RFC1122中的MSL是60s，不同的操作系统MSL是不相同
• 可以通过cat /proc/sys/net/ipv4/tcp_fin_timeout命令查看MSL的数值

 那么TIME_WAIT持续的时间为什么是2个MSL？

• MSL是报文的最大生存时间
• 就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启, 可能会收到来自上次连接所发送的相关信息，从而造成一些不想必要的麻烦）
• 保证最后一个报文安全地到达（假如最后一个应答丢失，尽管进程已经关闭，但是TCP服务依旧存在，服务端会重发FIN，客户端再向服务端发送ACK应答） 

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

理解 CLOSE_WAIT 状态 

• 假如我们在代码编写中没有调用close（）,在断开连接时就会出现CLOSE_WAIT ，这说明连接没有完全断开，这样就会导致服务器在运行一段时间后会变得非常卡慢，甚至出现崩溃

滑动窗口 

对每一个发送的数据段 , 都要给一个 ACK 确认应答 . 收到 ACK 后再发送下一个数据段 . 这样做有一个比较大的缺点, 就是性能较差 . 尤其是数据往返的时间较长的时候

 

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

 

• 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值. 上图的窗口大小就是4000个字节(四个段).
• 发送前四个段的时候 , 不需要等待任何 ACK, 直接发送
• 收到第一个 ACK 后 , 滑动窗口向后移动 , 继续发送第五个段的数据 ; 依次类推
• 窗口越大 , 则网络的吞吐率就越高
• 操作系统内核为了维护这个滑动窗口 , 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答 ; 只有确认应答过的数据, 才能从缓冲区删掉

 

那么如果出现了丢包 , 如

情况一 : 数据包已经抵达

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

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

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

 这种机制被称为 "高速重发控制"(也叫 "快重传")

流量控制

接收端处理数据的速度是有限的 . 如果发送端发的太快 , 导致接收端的缓冲区被打满 , 这个时候如果发送端继续发送 , 就会造成丢包, 继而引起丢包重传等等一系列连锁反应

因此 TCP 支持根据接收端的处理能力 , 来决定发送端的发送速度 . 这个机制就叫做 流量控制 (Flow Control) ;

• 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段, 通过ACK端通知发送端
• 如果接收端缓冲区满了 , 就会将窗口置为 0; 这时发送方不再发送数据 , 但是需要定期发送一个窗口探测数 据段, 使接收端把窗口大小告诉发送端
• 窗口大小字段越大 , 说明网络的吞吐量越高
• 发送端接受到这个窗口之后 , 就会减慢自己的发送速度
• 接收端一旦发现自己的缓冲区快满了 , 就会将窗口大小设置成一个更小的值通知给发送端

拥塞控制

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

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

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

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

 

 

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

延迟应答

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

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

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

• 数量限制 : 每隔 N 个包就应答一次 ;
• 时间限制 : 超过最大延迟时间就应答一次

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

捎带应答

在延迟应答的基础上 , 我们发现 , 很多情况下 , 客户端服务器在应用层也是 " 一发一收 " 的 . 意味着客户端给服务器说 了 "How are you", 服务器也会给客户端回一个 "Fine, thank you";

那么这个时候 ACK 就可以搭顺风车 , 和服务器回应的 "Fine, thank you" 一起回给客户端

 

面向字节流

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

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