前言
TCP报文段结构、可靠数据传输、TCP连接管理（三次握手、四次挥手）、拥塞控制。
一、面向连接传输TCP
- 点对点：
- —个发送方，一个接收方
- 可靠的、按顺序的字节流：
- 没有报文边界
- 管道化（流水线）：
- TCP拥塞控制和流量控制设置窗口大小
- 发送和接收缓存
- 全双工数据：
- 在同一连接中数据流双向流动
- MSS：最大报文段大小
- 面向连接：
- 在数据交换之前，通过握手（交换控制报文）初始化发送方、接收方的状态变量
- 有流量控制：
- 发送方不会淹没接收方
1.段结构
- 序号：
- 报文段首字节的在字节流的编号（在整个字节中的偏移量）
- 确认号：
- 期望从另一方收到的下一个字节的序号
- 累积确认
- Q：接收方如何处理乱序的报文段——没有规定
如下：主机A向主机B传输的序号42的字节（字母C），序号42字节到了主机B，主机B收到后回显，告诉主机A：我已经收到，我希望你传来43及以后的字节；对于主机B来说它受到主机A的确认号79，说明78及以前的字节主机A收到了，所以后面它将传输79及以后的字节。即：主机B向主机A回传的Seq = 79，ACK = 43。
TCP往返延时（RTT）和超时
Q：怎样设置TCP超时?
- 比RTT要长
- 但RTT是变化的
- 太短：太早超时
- 不必要的重传
- 太长：对报文段丢失反应太慢，消极
Q：怎样估计RTT?
- SampleRTT：测量从报文段发出到收到确认的时间
- 如果有重传，忽略此次测量
- SampleRTT会变化，因此估计的RTT应该比较平滑
- 对几个最近的测量值求平均，而不是仅用当前的sampleRTT
2.可靠数据传输
- TCP在IP不可靠服务的基础上建立了rdt
- 管道化的报文段
- GBN or SR
- 累积确认（像GBN）
- 单个重传定时器（像GBN）
- 是否可以接受乱序的，没有规范
- 通过以下事件触发重传
- 超时（只重发那个最早的未确认段:SR）
- 重复的确认
- 例子：收到了ACK50,之后又收到3个ACK50
下面首先考虑简化的TCP发送方：
- 忽略重复的确认
- 忽略流量控制和拥塞控制
TCP发送方事件
- 从应用层接收数据：用nextseq创建报文段
- 序号nextseq为报文段首字节的字节流编号
- 如果还没有运行，启动定时器
- 定时器与最早未确认的报文段关联
- 过期间隔：TimeOutInterval
- 超时：
- 重传后沿最老的报文段
- 重新启动定时器
- 收到确认：
- 如果是对尚未确认的报文段确认
- 更新己被确认的报文序号如果当前还有未被确认的报文段，重新启动定时器
TCP重传
产生TCP ACK的建议[RFC 1122. RFC 2581]
建议的实施见下面讲解
快速重传
- 超时周期往往太长：
- 在重传丢失报文段之前的延时太长
- 通过重复的ACK来检测报文段丢失
- 发送方通常连续发送大量报文段
- 如果报文段丢失，通常会引起多个重复的ACK
- 如果发送方收到同一数据的3个冗余ACK，重传最小序号的段：
- 快速重传：在定时器过时之前重发报文段
- 它假设跟在被确认的数据后面的数据丢失了
- 第一个ACK是正常的;
- 收到第二个该段的ACK，表示接收方收到一个该段后的乱序段;
- 收到第3，4个该段的ack，表示接收方收到该段之后的2个，3个乱序段，可能性非常大段丢失了
根据下图通俗总结：下面五个报文段，先来了40-49的报文段，接收方立马回传ACK50的确认，后面本来要传50-59，但是60-69、70-79、80-89报文段依次来了，但是在这三个报文段来之后，接收方都依然依次回传ACK50。
TCP快速重传示意图：
3.流量控制
- 接收方在其向发送方的TCP段头部的rwnd字段“通告”其空闲buffer大小
- RcvBuffer大小通过socket选项设置(典型默认大小为4096字节)
- 很多操作系统自动调整RcvBuffer
- 发送方限制未确认(“in-flight”)字节的个数 ≤ 接收方发送过来的rwnd值
- 保证接收方不会被淹没
4.TCP连接管理
在正式交换数据之前，发送方和接收方握手建立通信关系：
- 同意建立连接（每一方都知道对方愿意建立连接）
- 同意连接参数
同意建立连接（2次握手）
Q：在网络中，2次握手建立连接总是可行吗?
- 变化的延迟(连接请求的段没有丢，但可能超时)
- 由于丢失造成的重传(e.9.req_conn(×))
- 报文乱序
- 相互看不到对方
两次握手的失败场景：
- 第一次发送连接请求，但是在连接确认回复时超时了，就发出第二次连接请求，结果发出去后，超时的确认终于到了，新发的连接未确认，确认连接的是以前超时的请求连接，导致维护了虚假连接。
- 在上面的情况时，第一次请求连接建立后会发送数据，服务器接收数据，但是当第一次连接关闭后，新连接这时到达服务器得到确认并发送数据，服务器又收到数据。
- 注意这里，你在第一次连接成功了，然后客户端做的操作会通过此连接传输数据，但是关闭第一次连接后，新连接终于连上，然后开始发送数据，这时的数据就是以前请求的数据，很难保证第一次连接做了其他数据传输，但第二次连接中也有。（类似于你在半连接成功后，第二次新连接成功前做了些操作，此时第一个连接肯定正常，但是第二个连接虽然未连接上，但是也发数据，当第一个关闭连接后，新连接终于连上，开始发送数据但是发送的时以前第一次连接关闭前传输过的老数据。）
TCP三次握手
- 三次握手的关键是要确认对方收到了自己的数据包，这个目标就是通过“确认号（Ack）”字段实现的。计算机会记录下自己发送的数据包序号Seq，待收到对方的数据包后，检测“确认号（Ack）”字段，看Ack = Seq + 1是否成立，如果成立说明对方正确收到了自己的数据包。
- 在开始握手时，客户端和服务器都会选择初始序号，这个初始序号是随机的，这样是为了避免半连接和接收老数据问题——正因为每次建立连接时Seq是随机的，而当个一个连接建立后，服务器和客户端就开始维护成功的连接的状态了，所以其他连接的Seq不在这个维护状态的范围内（如果运气很差随机值在这个维护范围内，那也没办法，网络不能解决所有问题）。
- 所谓的维护范围：TCP连接的一方A，由操作系统动态随机选取一个32位长的序列号(InitialSequence Number)，假设A的初始序列号为1000，以该序列号为原点，对自己将要发送的每个字节的数据进行编号，1001，1002，1003…，并把自己的初始序列号ISN告诉B，让B有一个思想准备，什么样编号的数据是合法的，什么编号是非法的，比如编号900就是非法的，同时B还可以对A每一个编号的字节数据进行确认。如果A收到B确认编号为2001，则意味着字节编号为1001-2000，共1000个字节已经安全到达。同理B也是类似的操作，假设B的初始序列号ISN为2000，以该序列号为原点，对自己将要发送的每个字节的数据进行编号，2001，2002，200…，并把自己的初始序列号ISN告诉A，以便A可以确认B发送的每一个字节。如果B收到A确认编号为4001，则意味着字节编号为2001-4000，共2000个字节已经安全到达。
实际中，第三次握手通常跟第一次数据传递弄在一起
为什么要三次握手：
- 第一次握手 ：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
- 第二次握手 ：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常
- 第三次握手 ：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常
按照现在的理解2次握手是不行的，说根本点就是客户端（发起建立连接的一方）知道服务器（客户端的初始序列号与服务器达成了一致，相对于客户端来说），服务器其实并不知道客户端是否收到自己同步信号。
TCP关闭连接（四次挥手）
- 客户端，服务器分别关闭它自己这一侧的连接
- 发送FIN bit = l 的TCP段
- 一旦接收到FIN，用ACK回应
- 接到FIN段，ACK可以和它自己发出的FIN段一起发送
- 可以处理同时的FIN交换
- 第一次挥手：Clien发送一个FIN = 1，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
- 第二次挥手：Server收到FIN = 1后，发送一个ACK给Client,Server进入CLOSE_WAIT状态，Client进入到FIN_WAIT_2状态。
- 第三次挥手： Server发送一个FIN = 1，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
- 第四次挥手：Client收到FIN = 1后，Client进入TIME_WAIT状态（假定 ACK 丢失,TIME_WAIT状态使TCP客户重传最后的确认报文），发送ACK给Server，Server进入CLOSED状态，完成四次握手。
5.拥塞控制
拥塞：
- 非正式的定义:"太多的数据需要网络传输，超过了网络的处理能力”
- 与流量控制不同
- 拥塞的表现/原因：
- 链路最大的吞吐量有限，当输入速率无限接近链路带宽时，延迟增大。
- 路由器的缓冲区是有限的，缓冲区溢出，新来分组丢失，发送端重传，传输层的输入又增加了重传的输入
- 发送超时，重传多个分组拷贝
- 没必要的重传，链路中包括多个分组拷贝
- 分组经历比较长的延迟（在路由器的队列中排队）
- 网络中前10位的问题
2种常见的拥塞控制方法：
- 端到端拥塞控制：没有来自网络的显式反馈
- 端系统根据延迟和丢失事件推断是否有拥塞
- TCP采用的方法
- 网络辅助的拥塞控制：路由器提供给端系统以反馈信息
- 单个bit置位，显示有拥塞(SNA,DECbit,TCP/IP ECN,ATM)
- 显式提供发送端可以采用的速率
机制
- 端到端的拥塞控制机制
- 路由器不向主机有关拥塞的反馈信息
- 路由器的负担较轻
- 符合网络核心简单的TCP/IP架构原则
- 端系统根据自身得到的信息，判断是香发生拥塞，从而采取动作
- 拥塞控制的几个问题
- 如何检测拥塞
- 轻微拥塞
- 拥塞
- 控制策略
- 在拥塞发送时如何动作，降低速率
- 轻微拥塞，如何降低
- 拥塞时，如何降低
- 在拥塞缓解时如何动作，增加速率
拥塞感知
发送端如何探测到拥塞？
- 某个段超时了（丢失事件）：拥塞
- 超时时间到，某个段的确认没有来
- 原因1：网络拥塞（某个路由器缓冲区没空间了，被丢弃）概率大
- 原因2：出错被丢弃了（各级错误，没有通过校验，被丢弃）概率小
- 一旦超时，就认为拥塞了，有一定误判，但是总体控制方向是对的
- 有关某个段的3次重复ACK：轻微拥塞
- 段的第1个ack，正常，确认该段，期待紧挨着的第二个段
- 段的第2个重复ack，意味着紧挨的的第二段的后一段（第三段）收到了，第三段乱序到达
- 段的第2、3、4个ack重复，意味着第二段后的三个段收到了，他们都是乱序到达，但是就是没有第二段，所以第二段丢失的可能性很大
- 网络这时还能够进行一定程度的传输，拥塞但情况要比第一种好
速率控制：速率控制方法
如何控制发送端发送的速率
- 维持一个拥塞窗口的值：CongWin
- 发送端限制已发送但是未确认的数据量（的上限）∶LastBytesent-LastByteAcked ≤ CongWin
- 从而粗略地控制发送方的往网络中注入的速率
- Congwin是动态的，是感知到的网络拥塞程度的函数
- 超时或者3个重复ack，Congwin值下降
- 超时时: Congwin降为1MSS（最大报文段长度）,进入慢启动（SS）阶段然后再倍增到Congwin/2(每个RTT)，从而进入拥塞避免（CA）阶段
- 3个重复ack : Congwin降为congwin/2 ,CA阶段
- 否则（正常收到Ack，没有发送以上情况）: congwin跃跃欲试
- SS阶段:加倍增加(每个RTT)
- CA阶段:线性增加(每个RTT)
联合控制的方法
发送端控制发送但是未确认的量同时也不能够超过接收
窗口，满足流量控制要求
- sendWin=min{CongWin, RecvWin};RecvWin是对方接收的空闲尺寸
- 同时满足拥塞控制和流量控制要求
TCP控制策略
- 慢启动
- AIMD:线性增、乘性减少
- 超时事件后的保守策略
TCP慢启动：
- 连接刚建立，Congwin = 1MSS
- 如:MSS = 1460bytes & RTT = 200 msec
- 初始速率 = 58.4kbps
- 可用带宽可能MSS/RTT
- 应该尽快加速，到达希望的速率
- 当连接开始时，指数性增加发送速率，直到发生丢失的事件
- 启动初值很低
- 但是速度很快
- 当连接开始时，指数性增加（每个RTT）发送速率直到发生丢失事件
- 每一个RTT，CongWin加倍
- 每收到一个ACK时，CongWin加1MSS
- 慢启动阶段:只要不超时或3个重复ack，一个RTT,CongWin加倍
- 总结：初始速率很慢，但是加速却是指数性的
- 指数增加，SS时间很短，长期来看可以忽略
TCP拥塞控制：AIMD
- 乘性减：
- 丢失事件后将congwin降为1，将congwin/2作为阙值,进入慢启动阶段（倍增直到congwin/2）
- 加性增:
- 当CongWin>阈值时，一个RTT如没有发生丢失事件,将congwin加1MSS：探测
- 当收到3个重复的ACKs：
- congwin 减半
- 窗口（缓冲区大小）之后线性增长
- 当超时事件发生时：
- Congwin被设置成1MSS，进入SS阶段
- 之后窗口指数增长
- 增长到一个阈值（上次发生拥塞的窗口的一半）时，再线性增加
Q：什么时候应该将
指数性增长变成线性?
A：在超时之前，当congwin变成上次发生超时的窗口的一半
实现：
- 变量:Threshold
- 出现丢失，Threshold设置成CongWin的1/2
总结
以上就是TCP的讲解。
