TCP 连接建立
通过三次握手
服务器 执行 LISTEN 和 ACCEPT 原语
然后等待入境连接请求
客户端 执行CONNECT原语 同时希望连接的IP地址与端口 愿意接受的最大TCP段长
以及一些可选的用户数据等参数
CONNECT原语发送一个SYN标志位置为on和ACK标志位置为off的TCP段
然后等待服务器响应
TCP连接释放
为了释放一个TCP连接 任意一方都可以发送一个设置了FIN标志位的TCP段
表示没有数据需要发送了
当FIN段被另一个方向确认后 这个方向上的连接就被关闭 不再发送任何数据 当然 另一个方向上或许还在继续着无线的数据流
当两个方向都关闭后 连接才算被彻底释放
TCP 连接管理模型
建立连接和释放连接所需要的步骤都可以用一个有限状态机来表示
CLOSE 没有活跃的连接或者挂起
LISTEN 服务器等待入境呼叫
SYN RCVD 到达一个连接请求； 等待ACK
SYN SEND 应用以及启动了打开一个连接
ESTABLISHEND 正常的数据传送状态
FIN WAIT1 应用没有数据要发送
FIN WAIT2 另一端同意释放连接
TIME WAIT 等待所有数据包寿终正寝
CLOSEING 两段同时试图关闭连接
CLOSE WAIT 另一端已经发起关闭连接
LAST ACK 等待所有数据包寿终正寝
TCP滑动窗口
假设接收端有2K的缓冲区 发送端发送了1K的数据 并且该数据段被成功接受 那么接收端将确认该数据段
然而 由于接收端只剩下1K的缓冲区（在应用程序从缓冲区中取走数据之前）
它将宣告下一个期望字节开始窗口为1K（TCP段头中包含序号和确认号 确认号指定下一个期望的字节）
现在发送端发送了另一个1K的数据段 该段被确认了 但是接收端宣告的窗口大小变为0
因此 发送端不得不停止发送 等待接受主机上的应用进程从缓冲区中取走一些数据 以便接收端重新宣告写一个期望的字节和窗口大小
这种数据包称为窗口探测 TCP标准明确提供该选项 以防止窗口更新数据包丢失后发生死锁
TCP可以缓冲数据来提高传输性能
当直到自己有4K的窗口可用时 当接受到2K的数据时 可以延迟发送 等到另一个2K的数据到来时
发送一个包含4KB有效载荷的段
Nagle 算法
第一次发送数据包之后将其余后面的字节缓冲起来 等到发送出去的字节包被确认
再将缓冲的字节包发送出去 再缓冲接受到的数据包
这样可以大大降低数据包发送所需要的带宽
因为TCP需要发送大量的IP数据报和TCP头 而数据可能只有一点点
低能窗口综合症
Clark
当接受端的TCP缓冲区满时 发送方也知道
当接收端的TCP缓冲区拥有了一个字节的空间时 接收端便会发送一个窗口更新的字段来告诉发送端发送一个字节的
TCP端 发送方再次发送一个字节来 接收方缓冲区便又满了
这将导致效率低下
Clark的解决方案是禁止发送一个字节的窗口更新段 并且强制接收端必须等待到拥有了一定数量
的可用空间后再通告给对方
