TCP协议总结

TCP传输控制协议

TCP提供一种面向连接的、可靠的字节流服务
TCP通过下列方式来提供可靠性:
1.应用数据被分割成TCP认为最合适发送的数据块。这和UDP完全不同，应用程序产生的数据报长度将保持不变。由TCP传递给
  IP的信息单位成报文段或段(segment)
2.当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文
  段。
3.当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通过将推迟几分之一秒
4.TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的
  检验和有差错，TCP将丢弃这个这个报文段和不确认收到此报文段(希望发送端超时并重传)
5.既然TCP报文段作为IP数据报来传输，而IP数据报的达到可能会失序，因此TCP报文段的达到也可能会失序。如果必要，TCP
  将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层
6.既然IP数据报会发生重复，TCP的连接段必须丢弃重复的数据
7.TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳
  的数据。这将防止较快的主机致使较慢主机的缓冲区溢出

TCP首部
16位源端口号    16位目的端口号 
32位序列号 
32位确认序列号 
4位首部长度    保留6位 6位标志位   16位窗口大小 
16位检验和  16位紧急指针 
    选项 
    数据

TCP首部中有6个标志比特。他们中的多个可同时被设置为1.
URG    紧急指针(urgent pointer)有效
ACK    确认序号有效
PSH    接收方应该尽快将这个报文段交给应用层
RST    重建连接
SYN    同步序号用来发起一个连接
FIN    发端完成发送任务

TCP的流量控制由连接的梅一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序列号字段指明的值，这个值是
接收端正期望接收的字节。窗口大小是一个16bit字段，因而窗口大小最大为65535字节。
最常见的可选字段是最长报文大小，又称为MSS(Maximun Segment Size)中指明这个选项。它指明本端所能接收的最大长度的报文段

TCP连接的建立与终止

TCP是一个面向连接的协议。无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接
建立一个连接需要3次握手，而终止一个连接需要4次握手

客户端发送一个SYN给服务端，包含一个序列号A
服务端接收到SYN后也发送一个SYN给客户端，同时包含一个序列号B，并将序列号A+1返回
客户端收到确认后发送一个序列号B+1给服务端，连接完成

客户端发送一个FIN给服务端，其中包含一个序列号，希望终止连接
服务端返回ACK，并对序号+1
服务端也断开连接，发送一个FIN给客户端，也包含一个序列号
客户端返回ACK，并对序号+1

最大报文段长度(MSS)表示TCP传往另一端的最大块数据的长度，当一个连接建立时，连接的双方都有通告各自的MSS
MSS选项只能出现在SYN报文段中
MSS收到MTU的影响，在以太网中MTU最大为1500字节(还有6位MAC源,MAC目的,2位类型,4位尾部CRC)

TCP半连接
比如已完成了发送，可以发送一个结束FIN给另一端，但是我还想接受另一端发来的数据，知道它给我发来文件结束FIN

TIME_WAIT也成为 2MSL等待状态
每个具体TCP实现必须选择一个报文段最大生成时间MSL(Maximun Segment Lifetime)。它是任何报文段被丢弃前在网络内的
最长时间
在2MSL等待时，任何迟到的报文段江被丢弃。因为处于2MSL等待的，由该socket定义的连接在这段时间内不能再被使用，因此
当要建立一个有效的连接时，来自该连接的一个较早的替身的迟到报文作为新连接的的一部分不可能不被曲解

报文段复位
到不存在端口的连接请求(产生一个icmp差错报文)
异常终止一个连接

TCP双方可以同时打开或者同时关闭
TCP服务端可以限制IP地址，只允许指定的IP地址连接
TCP服务器有半连接队列，当处理连接过多，有新的连接过来了(发送了SYN报文)无法处理了，就放在这个半连接队列中

TCP选项
1.选项表结束
2.无操作
3.最大报文段长度
4.窗口扩大因子
5.时间戳

TCP的交互数据流

早期的统计约有一半的TCP报文段包含成块数据(如FTP)，另一半包含交互数据(如Telnet)

延迟确认
当接受到数据时，如果立刻返回响应结果，ACK会和返回结果一起发送给客户端
但是如果不是立即返回结果，而是等待一段时间，则延迟确认就会生效，此时不会立刻发送ACK确认
而是等待一段时间，约40毫秒左右，当时间超时后就发送ACK确认

Nagle算法
该算法要求一个TCP连接上最多只能由一个未被确认的未完成的小分组，在该分组的确认达到之前不能发送其他的小分组
所以当Nagle算法碰到ACK延迟确认，正巧编写代码不当就会出问题
对于实时交互系统，通常是关闭Nagle算法
Nagle算法的伪代码如下
if there is new data to send
  if the window size >= MSS and available data is >= MSS
    send complete MSS segment now
  else
    if there is unconfirmed data still in the pipe
      enqueue data in the buffer until an acknowledge is received
    else
      send data immediately
    end if
  end if
end if

TCP的成块数据流

TCP使用滑动窗口协议控制流量
该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送不必每发一个分组就停下来等待确认，
因此该协议可以加速数据的传输
当接收方确认数据后，这个滑动窗口不时地向右移动。窗口两个边沿的相对运动增加或减少了窗口的大小。我们使用三个术语
来描述窗口左右边沿的运动:
1)称窗口左边沿向右边沿靠近为窗口合拢。这种现象发生在数据被发送和确认时。
2)当窗口右边沿向右移动时将允许发送更多的数据，我们称之为窗口的张开。这种现象发生在另一端的接收进程读取已经确认
的数据并释放了TCP的接收缓存时。
3)当右边沿向左移动时，我们成为窗口收缩。强烈建议不要使用这种方式。

PUSH标志表明，当TCP服务端接收到含有PUSH标志的报文段时，它需要立即将这些数据递交给服务器进程而不能等待判断是否
还有额外的数据到达

如果发送方和接收方在一个广域网中，中间有很多路由，一些路由必须缓存分组，并且可能好近存储的空间
TCP使用一个成为 慢启动 的算法。该算法通过观察到新分组进入网络的速率应该与另一端返回确认的速率相同而进行工作
慢启动为发送方的TCP增加了另一个窗口: 拥塞窗口(congestion windows)记为cwnd。
当与另一个网络的主机建立TCP连接时，拥塞窗口被初始化为1个报文段(即另一端通告的报文段大小)。每收到一个ACK，拥塞
窗口就增加一个报文段(cwnd以字节为单位，但是慢启动以报文段大小为单位进行增加)。发送方取拥塞窗口与通告窗口中的
最小值作为发送上限。
拥塞窗口是发送方使用的流量控制，而通告窗口是接收方使用的流量控制

可计算通道的容量为:
capacity(bit) = bandwidth(b/s) * round-trip time(s)
单元的往返时间RTT(Round-Trip Time)

拥塞
当数据达到一个大的管道(如一个快速的局域网)并向一个较小的管道(如一个较慢的广域网)发送时便会发生拥塞。

TCP提供了  紧急方式 ，它使一端可以告诉另一端有些具有某种方式的"紧急数据"已经放置在普通的数据流中。另一端被
通知这个紧急数据已被放置在普通数据流中，由接收方决定如何处理。

TCP的超时与重传

TCP提供可靠的运输层。它使用的方法之一就是确认从另一端收到的数据。但数据和确认都有可能会丢失。TCP通过在发送时
设置一个定时器来解决这种问题。如果当定时器溢出时还没有收到确认，它就重传该数据。
对任何实现而言，关键之处就
在于超时和重传的策略，即怎样决定超时间隔和如何确定重传的频率。

对于每个连接，TCP管理4个不同的定时器:
1)重传定时器使用于当希望收到另一端的确认
2)持久(persist)定时器使窗口大小信息保持不断流动，即使另一端关闭了其接收窗口。
3)保持(keepalive)定时器可检测到一个空闲连接的另一端何时崩溃或重启
4)2ML定时器测量一个连接处于TIME_WAIT状态的时间







             

TCP的持久定时器

ACK的传输不可靠，TCP只确认哪些包含有数据的ACK报文，对ACK报文不进行确认
如果接收窗口为0，则向发送方做一个通告，当处理完缓冲区的数据后，发送一个通告(非0窗口)给发送端
如果这个报文丢失，则发送方无法发送数据，因为要等待窗口更新确认
而接收方也在等待数据接收，就发生了死锁

发送方使用了一个持久定时器(persist timer)来周期性的向接收方查询，以便发现窗口是否已增大。这些从发送方发出的
报文段成为窗口探查(window probe)
检查时间使用普通的TCP指数退避，时间依次为:4,6,12,24,48,60秒，

糊涂窗口综合症(Silly Window Syndrome)
该现象可以发生在两端中的任何一端:
接收方可以通告一个小的窗口(而不是一直等待有大的窗口才通告)，而发送方也可以发送少量的数据(而不是等待其他的数据
以便发送一个大的报文段)

可以在任何一端采取措施避免出现糊涂窗口综合症的现象
1)接收方不通告小窗口，通常的算法是接收方不通告一个比当前窗口大的窗口(可以为0)，除非窗口可以增加一个报文段大小(

也就是将要接受的MSS)或者可以增加到接收方缓存空间的一半，无论实际有多少
2)发送方避免出现糊涂窗口综合症的措施是只有以下条件之一满足时才发送数据:
    a)可以发送一个满长度的报文段
    b)可以发送至少是接收方通告窗口大小一般的报文段
    c)可以发送任何数据且不希望接收到ACK(也就是说我们还有未被确认的数据)或者该连接数不能使用Nagle算法
条件b)主要对付那么总是通告小窗口的主机
条件c)使我们在有尚未被确认的数据(正在等待被确认)以及不能使用Nagle算法的情况下，避免发送小的报文

列子
1.发送方不停发送，接收方通告一个0的窗口
2.接收方处理完了，通告一个1533字节的窗口
3.发送方只发送了1024字节，但是接收方没有通告0窗口，而是通告了509字节的窗口
  这样违反了规则 1)，但是如果通告0窗口就会范围 窗口的右边沿不能向左边沿移动而导致窗口收缩的TCP原则
4.发送方没有立刻发送509字节的数据，而是等待了一段时间，等待是否有一个窗口更新，等待超时后发送509字节，这就是
  规则3)








               

TCP保持活跃定时器

当两个主机之间没有任何数据交换，但他们仍然可以保持连接
甚至中间的路由器可以崩溃或者重启
这意味着我们可以和服务端创建连接后，离开几个小时，几天，几周，回来后连接依然正常
当然一般情况2小时就会触发一次保持活跃探测，这个参数可以配置的，配置之后对所有TCP连接都有效

这个功能放到TCP层是有争议的，有人建议放到应用层
在连接空闲2小时候，一个连接上发送一个探测分组完成保持活跃功能，可能有4种情况:
1.对端正常运行，两小时之后发送一个探测包，并复位，再过两个会再发送一个包
2.客户端崩溃，服务端不能检查到探测响应，在75秒后超时，连续发送10个这样的探测后，认为客户端主机已经关闭并终止
连接
3.客户端主机已崩溃并重启，服务端收到一个对其保持活跃的探测响应，但这个响应是一个复位，使得服务端终止这个连接
4.客户端正常运行，但是从服务端不可达，如中间路由崩溃，返回一个ICMP网络不可达的差错报文



              

TCP的性能和未来

        路径MTU发现
两个主机之间路径人任何网络上的最小MTU，路径MTU发现在IP首部中设置不要分片(DF)比特
如果一个待转发的IP数据报被设置了DF比特，而起长度又超过了MTU，那么路由器将返回ICMP不可达的差错
中间的路由器由于设置了更小的MTU，当发现设置了DF后，返回一个ICMP差错报文，包含了新的MTU
之后使用这个新的MTU大小，再设置DF后发送报文，如果再碰到更新的MTU，同样也会返回ICMP错误，按照同样的方式处理即可