由于TCP使用IP服务，而IP服务是无连接且不可靠的，所以TCP就要自然地承担起差错控制的重任。

TCP处理的差错包括报文段失序、丢失、重复和损坏。

数据失序是由于IP服务是无连接的，每个IP数据报独自路由，走的路经可能完全不同，无法保证数据报的按序交付。对于数据失序，引入序号和确认号的最根本的目的就是为了解决失序问题。TCP对于未按序提前到达（序号靠后）的数据暂不确认，直到按序到达的数据到达后，再一起确认。

重复的报文段是由超时重传造成的。发送方由于长时间未收到确认，重传计时器就会超时，这时就会重传TCP报文段。接收方可以根据序号判断出该报文段为重复报文段。而对于重复报文段，丢弃即可，不过仍需要再次确认，如图6-7所示。图中演示了A向B发送TCP报文段的过程，其中SN=1的报文段超时重发，并滞后到达。

图6-7　TCP超时重传的控制

先来分析一下超时重传引起的多个报文段副本的问题，然后看看迟滞的报文段会带来什么问题。

图中假设每个报文段有200字节的数据信息。A向B传输了SN=1、SN=201、SN=401的3个报文段，其中B接收到了SN=201和SN=401的两个报文段，但由于SN=1的报文段因网络时延没有到达B，所以B暂时不会对未按序到达的SN=201和SN=401的两个报文段进行任何确认。

A没有收到B的确认导致计时器超时，重传SN=1的报文段。当报文段SN=1到达B时，B才对SN=1、SN=201、SN=401的报文段一起进行确认。与此同时，A的计时器再次超时，并重传报文段SN=201。当B接收到这个报文段时，发现序号已经确认到了600，显然这个SN=201的报文段为重复的数据副本，因而简单丢弃后，对A再次用AN=601进行确认，告诉A需要的是从SN=601开始的新数据。(www.daowen.com)

接下来，A最先发送的那个SN=1报文段终于经历了较长的时延之后到达了B端，而B端同样发现自己已经确认到600的序号，因而也将这个SN=1的报文段视为重复的数据副本，丢弃后再次确认。

A继续往下发送SN=601的报文段，B收到后用AN=801确认。

从数据的传输过程可以看到，副本不一定就是重传的报文段，如果原始报文段比重传的报文段到达还要晚的话，也会被接收方作为副本处理。

序号是循环使用的，序号范围应该足够大，否则就会出现问题，如图6-8所示。图中假设序号空间为800字节，这样，当A发送完SN=601的报文段后，序号空间的800字节用完，A从1开始循环使用序号。对于图中严重迟滞的SN=1报文，如果迟滞的时间很长，A和B的序号空间开始循环使用，就会把旧数据当做新数据交付给上层应用程序，而把新数据当做副本丢弃。

图6-8　严重迟滞的报文段

TCP处理的差错还包括报文段丢失和报文段损坏。报文段损坏是指报文段在传输中出现了差错，但不管怎么样，这个报文段仍然到达了它的目的地。由于报文段中包含有校验和字段，当接收端检测出错误后就会丢弃这个报文段。值得注意的是，TCP不使用ARQ差错控制方式，当检测到差错后，不反馈任何信息。发送方有一个重传定时器，超时后就重传。

报文段丢失是由于网络复杂状况（如IP数据报出错被丢弃）导致报文段未能到达目的地。无论是报文段丢失还是损坏，都会导致发送方没有收到确认，从而导致定时器超时，最终靠重传来解决。