概述
- 点对点： 一个发送方，一个接收方
- 可靠的，按顺序的字节流： 没有报文边界
- 管道化（流水线）：TCP拥塞控制和流量控制设置窗口大小，分组发送和接收。
- 发送和接收缓存
- 全双工：在同一连接中数据双向流动，按照MSS(最大报文段)进行数据报传递。
- 面向连接： 数据交换之前通过握手（交换控制报文）初始化发送，接收方的状态变量。
- 有流量控制： 发送方不会淹没接收方。
报文段结构
- 序号，确认号
序号是报文段首字节在字节流的编号
确认号是期望从另一方收到的下一个字节的序号（累计确认）
Q: 接收方如何处理乱序的？
A: 报文段并没有规定。可以缓存或者丢弃。
并且标记tcp报文段的对应的标记位。
TCP可靠传输
TCP在IP不可靠服务的基础上，建立了rdt:
- 管道化的报文段（GBN or SR)
- 累计确认（像GBN）
- 单个重传定时器（像GBN）
- 是否可以接受乱序，没有规范。
通过以下事件触发重传：
- 超时（只重发最早未确认的段，类SR）
- 重复的确认（快速重传，都到3个相同的ack,未达到超时时间，触发重传）
TCP发送方事件
- 从应用层接收数据
- 用nextseq创建报文段
- 序号nextseq为报文段首字节的字节流编号
- 如果还没有运行，启动定时器（定时器与最早未确认的报文段关联，过期间隔TimeoutInterval)
- 超时
- 重传后沿最老的报文段
- 重新启动定时器
- 收到确认
- 如果是对尚未确认的报文段确认（更新已被确认的报文序号，还有未被确认的报文段，重新启动定时器）
TCP流量控制
流量控制：接收方控制发送方，不让发送方发送的数据太多，太快；以至于让接收方的缓存区溢出
TCP 往里写数据 => 数据缓冲区(网卡缓冲) <= app应用从当中读取数据
- 接收方在其向发送方的tcp段头部的rwnd字段同步其空闲buffer发小（捎带技术）
- RcvBuffer大小通过socket选项设置，默认大小为4096字节
- 很多操作系统自动调整RcvBuffer
- 发送方限制未确认字节的个数 <= 接收方发送过来的rwnd值
- 保证接收方不会被淹没
TCP连接管理
在正式交换数据之前，发送方和接收方握手建立通信关系。（同意建立连接，连接参数，控制变量同步）
TCP三次握手
TCP四次挥手
