TCP/IP 之TCP

TCP/IP 之TCP

TCP与UDP

1. TCP是面向连接的, UDP是面向无连接的
2. 提供通用的, 可靠的 进程到进程的通信服务, UDP提供不可靠的进程到进程的通信服务.
3. TCP使用数据流, UDP使用报文.

注意: TCP 在与上层协议交流时使用数据流的传输格式 , 但是在与下层协议交流时, 为了提高效率, 同样采用报文段的传输格式

• 报文与数据流的对比

  –	报文	数据流
  投递单位	报文	byte
  接收顺序	报文按顺序接收, 连续报文流, 有报文边界	byte按序接收, 连续字节流,无边界
  接收的内容	大小和顺序严格与发送方一致	顺序严格与发送方一致
  发送	发送方和接收方以及网络传输过程中都是以报文格式,报文前后可以分割不能合并	发送和接收两端都是数据流, 在网络传输过程冲可以合并成大小不一的数据块

TCP 协议特点

可靠投递服务特点

1. 面向数据流的传输, 无结构字节流: 没有边界, 内容任意
2. 虚电路连接, 尽管IP网络是无连接的. 但是在TCP的端点上, 却可以看做是面向连接的通信
3. 有缓冲的传达–提高传输效率
   * 应用进程: 使用自己认为适宜的任意大小的数据片
   * TCP 协议软件: 根据网络情况选择适当的收发缓冲区. TCP对上层提供服务是按字节流的方式, 但是对下层协议, 并不是来一个字节就发送一个自己, 而是有一定的缓冲区, 等缓冲区满了, 在交付给下层协议发送, 对于缓冲区的大小, 其实是由当前网络环境的最大发送能力决定的.
   * Push: 强制发送滞留的数据. 无论缓冲区的数据是否达到标准, 都强制发送.
4. 双全工服务 可以同时双向发送数据
5. 捎带确认方式: 确认信息放在发送数据的报文中一起发送.

TCP的报文段格式 segment

控制字段

1. UTG: 紧急位
2. RST: 连接复位
3. ACK: 1: 头部携带了确认信息
4. SYN:连接建立
5. PSH: push操作
6. FIN:连接拆除

报文序号:

假设当前流序号为X, 长度为L, 则当前报文序号为X, 下一个报文流序号是X+ L, 下一个报文序号也是X + L;

数据流. 报文段

TCP 在对上和本层使用的都是数据流, 但是对下层. 为了提供效率, 采用的是报文段

紧急指针与带外数据

1. 带外数据(segment)
   
   • 位于数据字段的开始
   • 不在数据流中排队, 直接递交到上层
   • 提供快速传递数据的功能
2. 紧急指针:指向外带数据的最后一个字段. 外带数据从第一位开始, 到紧急指针指向的位结束

带外数据又叫紧急数据. 与普通数据不同的是, 一旦收到带外数据不会再数据流中排队, 而是直接递交到上层. 一个报文中如果有带外数据则会放在数据部分的开始位置. Urgent Point 指向的是外带数据的最后一个字节.

选项字段

1. 单字节
   
   • 无操作
   • 选项结束
2. 多字节
   
   • 最大报文段长度. 一个MSS太小, 网络利用率太低. MSS太大, 需要分片, 就有可能丢失, 丢失后TCP需要重传, 降低成功率. 通信中常用双方MSS选项进行MSS值的协商.
     通常在TCP连接建立过程中完成协商.
   • 窗口比例因子: 允许TCP一次发送数据的大小.首部中定义的窗口大小为2^16. 为解决大的吞吐量网络, 采用 新窗口大小= 首部中定义的窗口大小 * 2^比例因子.
   • 时间戳 用了计算往返时间

Window Size 只有16 bits 意味着TCP一次最大发送2^16 个字节. 但是对于大吞吐量的网络, 可以通过 Option中的窗口比例因子来调节窗口的大小. 计算方式为: 新窗口的大小 = 首部定义的窗口大小 * 2^(比例因子). 比例因子取值范围是 0 -16. 需要注意的是窗口大小可以在传输阶段改变, 但是比例因子必须在TCP连接建立的过程中确定.

差错控制

TCP的可靠性

• 按序
• 无差错
• 不丢失, 不重复

机制

检查: 检验校验和. 确认. 超时

确认机制: 带重传的肯定确认.

• 接收方接收到正确的数据后, 向源站发送ACK报文
• 发送方重传错误报文 (包括 受损报文, 丢失报文)

累积确认

• ACK number 是接收方希望接收的下一个字节
• 对ACK number以前的所有字节的确认. 将ACK number以前的定时器 失效.

超时重传机制

发送方发送数据时启动一个定时器, 在定时器结束, 没有收到确认数据. 没有收到包括: 1. 发送数据丢失 2 确认信息丢失, 都会认为是没有收到确认信息, 会触发重传.
对于确认信息的丢失, 接受方会再次接受到接收过的数据, 这时候 接收方会将数据直接丢掉, 并会告知接收方, 超时定时器不合理.
纠正: 重传

累计确认机制
当前收到的消息是对之前数据的确认, 虽然没有收到数据1的确认消息, 但是收到数据2的确认机制, 就可以说明数据1, 已经确认收到.
超时重传机制
当数据3的定时器超时, 会再次发生数据3.这时超时定时器的时长会根据自适应超时重传算法计算所得.
重复报文问题.
如果接收方接收到数据后, 再次接收到重传数据, 会将重复报文丢弃

滑动窗口引言

下面思考一个问题
当一个数据发送后, 在收到确认消息前是否可以发送另外一个数据?
1. 如果直接发送下一个数据, 那么在网络环境差的环境里会加重网络拥塞.
2. 如果必须等到确认消息后再发送下一个数据, 那么在网络环境好的环境里会造成高延迟,
3. 在网络环境很好时, 如果不断发送数据, 而接收方接收数据速度很慢时, 则可能造成接收方被数据淹没, 而没有及时给确认消息的数据, 因为重传机制的存在则会快又会到来一次, 这更加加重了接收方的负担.
为了解决这些问题, 引入了滑窗机制.

1. 只有在发送窗口内的数据才允许发送, 当收到确认消息, 则窗口向前移动,
   2 接收方会告诉发送方当前可用缓冲区大小, 发送方收到该告知后,会调整发送窗口大小. 当接收方通告发送方可用缓冲区是0时, 则发送方停止发送. 当收到发送窗口值不为0时, 才会继续发送, 发送方也会每隔一段时间试探性发送.

2. 对拥塞问题的解决. 引用拥塞窗口

   1. 加速递减: 一旦出现报文丢失, 则拥塞窗口减半. 发送窗口内数据超时时间加倍
   2. 慢启动: 每收到一个确认消息时, 拥塞窗口增加一个 MSS,
      发送窗口 = min(窗口通告值, 拥塞窗口)

3. 对重传机制的影响, 如果第一次发送时数据长度是200, 发送窗口大小也是200. 在重传时发送窗口大小改为100, 这时候就需要将200的数据分成两次发送.

滑动窗口

• 窗口: 发送方在收到确认信息之前, 发送缓冲区中还可以继续发送数据流的长度
• 滑动: 滑动的动力是确认信息的到达. 随着确认信息的不断到达, 窗口也在不断向前滑动.

TCP的发送窗口

• TCP 的发送窗口包括 已确认 窗口(已发送待确认, 可以发送未发送) 不允许发送, 三个部分
• 发送窗口大小动态可变. 接收方告知当前接收缓冲区大小. 发送方告知调整后的发送窗口大小
• 极端情况, 接收方告知发送方可用缓冲区为0, 发送方停止发送.
• 重新发送的条件 1. 收到接收缓冲区不为0的通知.
• 试探性发送 收到缓冲区为0后, 等待一段时间后, 发送小的报文试探

TCP的接收缓冲区

*TCP 的接收缓冲区包括 以提交 已排序待提交, 零散数据, 空白段 4个部分

TCP窗口的大小

TCP的窗口大小是由 窗口通告值(接收方告知当前可用缓冲区大小), 拥塞窗口 两者的最小值决定.
1. 拥塞窗口特性
1. 加速递减.
* 一旦出现丢失报文, 则拥塞窗口减半, 按指数递减
* 发送窗口内数据超时期时间加倍,
2. 慢启动
* 拥塞窗口 每收到一个确认, 拥塞窗口增加一个MSS
* 当拥塞窗口 = 窗口告知值的一半是, 只有当窗口内所有报文段都收到确认, 才增加一个MSS

TCP的糊涂窗口综合征

TCP发送方的窗口大小由 窗口告知值 和 拥塞窗口 两者的最小值决定. 如果接收方处理数据的速度特别慢, 导致可用缓冲区特别小, 这时如果按照窗口告知值大小发送, 很多的浪费网络资源.
* 解决办法:
1. 推迟窗口通告, 接收方在零窗口通知发出后, 并不是一有缓冲区就告知发送方, 而是等待缓冲区大小达到接收缓冲区的一半时, 或者达到最大报文段长度时, 才发送.
2. 推迟确认, 接收方在可用缓冲区很小时, 推迟确认的发送, 当窗口增加到一定程度, 或者有消息要发出, 或者将要超时时, 再将确认消息发出.
3. 延迟发送, 发送方并不是一有数据就立刻发送, 而是聚集到一定数据的数据后再发送.

TCP 连接管理

从上面的学习我们知道, 一对端点信息(发送方IP地址端口号, 接收方IP地址端口号)标识一个TCP连接. 系统要为每一个TCP连接分配发送缓冲区接收缓冲区, 这就标识一个机器上的TCP连接数量是有限制的.

初始序号

• TCP使用随机的初始序号值
• 双方都必须知道对方的初始序号才能正常通信.
• 双方都需要确认对方得到了自己的初始序号.
• 确保报序号发送到对方, 就有了三次握手方式建立连接.

TCP 三次握手建立连接

tcp的连接也可以拆开看做四次握手, 当通常 2, 3一起发送, 所以是三次握手建立连接
在三次连接中双方相互告知了自己的初始序号, 同时还要协商了窗口比例因子, MSS等数据.

TCP 连接的拆除 四次握手

• TCP 连接拆除的发起方只能关闭自己发送数据的能力, 不能关闭接收数据的能力(为了避免接网络延迟导致的数据没有完全收到), 而且可以发送确认信息.
  

为什么连接断开要四次. 因为网络的不确定性, 在收到client的断开连接时, 有可能有一些数据还没有发生完成, 或者发生失败需要重新发生的. 所以需要等到server端确认不需要再向Client发生数据时, 才会主动发生请求断开连接

TCP连接复位

• 异常中断连接
• 复位到无连接状态, 强制拆除, . 立即终止. 发送RST = 1 报文. 无需对方确认