概述
TCP服务
-
多路复用与多路分解
将端系统间的IP交付服务扩展为运行在端系统上的两进程间的交付服务，即运输层多路复用与多路分解。 -
可靠数据传输
即保证分组不错不丢不乱 -
拥塞控制
防止任何一条TCP连接用过多的流量淹没通信主机之间的链路和交换设备以优化整个因特网环境
TCP特点
三次握手 两进程在通过TCP传递传递有效数据前，必须互相握手，即发送某些预备报文段以建立确保数据传输的参数。
客户首先发出一个特殊报文段，服务器用另一个特殊报文段响应，最后，客户用第三个特殊报文段作为响应。前两个特殊报文段不承载有效载荷，第三个报文段可以承载有效载荷。面向连接
通信双方在发送数据之前必须建立连接。
TCP协议仅在端系统中运行，连接状态在端系统中维护，中间网络元素不会维护TCP连接状态。双全工服务 AB两进程间的TCP连接可以从A向B传输数据也可以从B向A传输数据。
TCP是双全工的点对点 TCP是点对点的，不支持多播
多播： 一次发送操作中，从一个发送方将数据传输给多个接收方缓存上层数据 发送方应用层通过套接字向TCP传递数据，TCP将数据引导至该连接的发送缓存中，发送缓存在三次握手期间设置。
最大报文段（有效载荷）长度(Maximun Segment Size,MSS) TCP可以从缓存中取出并放入报文段中的最大数据数量。 MSS通常根据最大链路层帧长度设置。该设置保证一个TCP报文段封装在IP数据报中后，再加上TCP/IP的首部，其总长度将适合单个链路层帧。
流水线机制 TCP使用流水线机制，但结合了GBN和SR的特点，在收发双方都设置有缓存
TCP连接的组成
- 两个端系统中，各自的TCP缓存，变量，与进程连接的套接字。
- 两端系统之间的网络元素没有为该连接分配任何缓存和变量。
TCP报文段
TCP报文段由首部字段和数据字段组成。数据字段最大长度由MSS限制。
首部字段结构
- 源端口号 用于多路复用/分解
- 目的端口号 用于多路复用/分解
- 序号字段 32bit 用于实现可靠数据传输
- 确认号字段 32bit 用于实现可靠数据传输
- 接收窗口字段 16bit 用于流量控制
- 检验和字段 16bit 用于差错检测
- 首部长度字段 4bit 指示TCP首部长度。（选项字段常为空，故TCP首部典型长度为20byte）
- 选项字段 可选的，变长的。 可用于协商MSS大小，传输窗口调节因子，时间戳等。
-
标志字段 6bit
ACK位用于指示该报文段包括对一个已被成功接收的报文段的确认。
RST，SYN,FIN位用于连接的建立与拆除。
PSH位指示接收方应立即将数据交付上层。
URG位指示报文段中存在被发送端上层实体设置为紧急的数据。
在实践中，PSH，URG未被使用。 （然鹅可以监测到一些报文的PSH位被置位）
TCP可靠数据传输
序号和确认号
TCP将数据视为无结构的有序字节流。
报文段序号 序号建立在传送的字节流上而非建立在传送的报文段序列上。报文段序号是该报文段首字节的字节流编号。发送方TCP隐式地对字节流中的每一个字节编号，将一个报文段中首字节的字节编号作为该报文段的序号。
确认号 主机A填充进报文段的确认号是主机A期望从主机B收到的下一字节的序号。
累计确认 TCP只确认流中至第一个丢失字节为止的字节。即确认号之前的所有字节都已正确接收。
失序报文段 TCP RFC 中未规定如何处理收到的失序报文段。实现者可以令接收方直接丢弃失序报文段，也可以令接收方缓存失序的字节。实践中一般缓存失序的字节。
初始序号 一条TCP连接双方可以随机地选择初始序号，以减小将网络中的其它报文段（先前建立，现已关闭的连接）误认为本连接报文段的可能。
确认信号 确认报文段可以在一个独立的报文段中传输（数据字段为空），也可以被一个含有效数据的报文段捎带。
丢包检测与恢复
- TCP提供定时器超时和冗余ACK两种丢包检测机制（冗余ACK也可表征包错误）
- 相应地，TCP提供超时重传和快速重传两种丢包恢复机制（快速重传也可恢复包错误）
TCP超时机制
- TCP需要超时重传机制以处理报文段的丢失。
一个重要的问题是如何设置超时间隔的长度。
RTT可以作为超时间隔长度设置的一个重要参考。
往返时间估计
往返时延(Round-Trip Time,RTT) 从发送端发送一段数据开始，到发送端收到来自接收端的确认总共经历的时延。
RTT由三个部分决定：链路的传播时间，端系统的处理时间，路由器的缓存中的排队和处理时间。
样本RTT（SampleRTT） 报文段的样本RTT是 从某报文段交付IP到对该报文段的确认被收到之间的时间量。TCP根据具体实现在某些时刻作样本RTT测量。只可能为已发送未确认报文段做测量，不会为已重传报文段做测量
报文段的样本RTT会随着路由器拥塞和端系统负载情况变化，任一给定样本RTT都是非典型的。
平均RTT（EstimatedRTT） TCP维护样本RTT的均值，每获得一个新样本就更新该均值。
这是一种老化算法，或称指数加权移动平均。新样本权重大于老样本权重。
a常取1/8
偏差RTT（DevRTT) 描述RTT的偏差
b常取1/4
RTT波动越大，DevRTT越大
超时间隔加倍
- 每当超时事件发生时，TCP会重置定时器，且新TimeoutInterval为原TimeoutInterval的两倍。而在其它情况下，TimeoutInterval或根据EstimatedRTT和DevRTT计算，或使用初始值。
- 超时间隔加倍潜在的提供了一定的拥塞控制功能。因为超时事件很可能是由网络拥塞引起的，超时间隔加倍有助于缓解拥塞。
重传超时间隔 TimeoutInterval
（0） 初始值
(1) 正常事件
(2) 超时事件
即通常情况下超时间隔大于平均往返时间，RTT波动越大，超时间隔的余量也应越大。
初始TimeoutInterval常设为1秒，出现超时后TimeoutInterval翻倍
快速重传
报文丢失时，因超时周期可能较长，通过超时机制触发的重传可能导致端到端时延过长。
冗余ACK 是发送方检测丢包的另一手段。冗余ACK即对同一个报文段的多个ACK。
快速重传
发送方收到三个冗余ACK，即收到同一个报文的四个ACK时，执行快速重传，即在超时事件发生之前重传丢失的报文段。
为什么是三次冗余ACK？因为分组重排（乱序）也会导致冗余ACK，三次冗余ACK从概率上或者说从实践经验上强烈地指示发送方很可能发生了丢包而非乱序。
收发双方行为
发送方事件
- 接收上层数据
- 定时器超时
- 收到ACK
接收方ACK产生策略 [RFC 5681]
假定接收方期望下一个到达的报文段为i
- 若 报文段i到达，且i之前的所有报文都已被确认（发送了i-1的ACK） 则 延迟ACK。等待报文段i+1 500ms，若500ms后i+1未到达，发送i的ACK
- 若 报文段i到达，且i之前有报文未被确认（i-1的ACK未被发送） 则 立即发送单个累积ACK（i的ACK）,以确认两个按序报文段
- 若 报文段j到达，j>i,即检测出失序 则 立即发送一个冗余ACK（即发送i-1的ACK）以指示下一个期待的报文段为i
- 若 报文段i到达，且i能部分或完全填充之前失序接收的报文序列间的间隔， 则 立即发送i的ACK
TCP差错恢复机制——回退N步与选择重传
TCP使用累积确认技术，正确接收但失序的报文段不会被接收方逐个确认，对报文段i的确认代表i之前的所有报文都已正确接收。
基于累积确认，TCP发送方仅需维护已发送但未被确认的最小序号和下一个待发送字节的序号即可。
大多数TCP实现会将正确接收但失序的报文段缓存起来。当报文i的ACK超时后，TCP不会依照回退N步的策略将报文段i，i+1.....N都重传，而是只重传报文段i。
TCP的差错恢复机制是回退N步与选择重传的结合。
流量控制
速度匹配服务，即匹配发送方的发送速率与接收方的接收速率。
TCP连接的两侧有各自的缓冲区，若发送/接收速率不匹配，易造成缓冲区溢出。流量控制与拥塞控制 两者的措施都是抑制发送方，但两者目的不同。流量控制在接收方速率低于发送方速率时抑制发送方，拥塞控制在网络拥塞时抑制发送方。
接收窗口 发送方维护的一个状态变量，用以实现流量控制。接收窗口给发送方关于接收方还有多少可用缓存空间的指示。
接收方在给发送方的报文中，包含关于自身剩余缓存大小的字段，即接收窗口字段。
发送方应当保证所有已发送未确认分组的总数据量不会超出接收窗口。
零接收窗口 在接收窗口为0时，若完全抑制发送方，则即使将来接收方的缓存有空余，也无法通知发送方。故即使在接收窗口为0时，发送方也会发生带一个字节数据的报文段，以备接收方确认。
TCP连接管理
本节考察TCP连接的建立与拆除。
连接建立
三次握手
-
SYN报文段m1
客户端TCP向服务端TCP发送一个特殊TCP报文段m1，m1被称为SYN报文段；
m1不含应用层数据；
m1的首部中标志位SYN置为1；
客户端还会选择一个随机序号client_isn，置于m1的序号字段中，作为发送方初始序号； -
SYNACK报文段m2
当m1到达服务端后，服务器为服务器侧的该TCP连接分配缓存和变量，并向客户TCP发送允许连接的报文段m2;
m2不含应用层数据；
m2的SYN位被置位1；
m2首部的确认号字段被置为client_isn+1;
服务器选择自己的初始序号server_isn，将之置于序号字段; -
确认与数据报文段m3
客户端收到m2后，为该TCP分配缓存和变量;
客户向服务端发送报文段m3；
m3对服务器的允许连接报文段m2进行了确认，即将server_isn+1置于确认字段;
此时连接已经建立，故m3的SYN比特置为0;
报文段m3中可携带有效负载;
三次握手之后，TCP连接上可用发送数据报文段。数据报文段的SYN比特都被置为0。
SYN洪泛
注意在三次握手中，第一次握手发起方不会为TCP分配资源，第二次握手接收方会为TCP分配资源，第三次握手发起方会为TCP分配资源。
故而，发起方若只发送第一次握手，就可以在很少的代价下（发起方不必为TCP维护资源）让接收方付出较大的代价（接收方为TCP分配资源直至等待第三次握手超时）。
SYN cookie
SYN cookie技术可以很好地应对SYN洪泛攻击。对于部署了SYN cookie的操作系统，接收方在第二次握手时不会分配资源，而是把状态信息，TCP标识（双方IP，port），接收方秘密值一起hash加密后作为初始序号，放置到第二次握手的序号字段中。接收方只有在收到第三次握手信号并验证后才会为TCP分配资源。
在这种情况下，要施时SYN洪泛的发起方必须消耗较多资源维护连接信息。
连接拆除
参与TCP连接的两者之任一都可以终止该连接。连接结束后，端系统中的相关资源将被释放。
终止连接时，终止发起方发送一个特殊的TCP报文段，该报文段首部行中的FIN标志位被置为1；
另一方接收到该报文段后，向发送方回送一个确认报文段，并向终止发起方发送自己的终止报文段，该报文段中FIN标志位为1；
最后，终止发起方对另一方的终止报文段进行确认；
套接字不匹配
考察端系统收到一个TCP报文段，而该报文段没有匹配套接字的情况，即没有服务端进程在监听相应端口的情况。
此时，主机向源发送一个特殊的重置报文段，该报文段将RST位置为1。
UDP套接字不匹配时，主机向源发送一个特殊的ICMP数据报。
