TCP提供面向连接的、可靠的、全双工的字节流传输服务。

面向连接意味着两个TCP应用程序在彼此传输数据之前必须先建立一个TCP连接,传输结束后一般也会断开连接。TCP连接通过三次握手建立,四次挥手断开。

TCP通过以下方式保证可靠性。

  • TCP分段。区别于UDP,UDP将应用程序封装成一个数据报,长度保持不变。

  • 重传定时器。每发出一个报文段,就启动一个定时器,等待接收端确认。如果没有及时收到确认,会重发这个报文段。

  • TCP收到另一端数据,将发送一个ACK确认。确认不是立即发送,通常将推迟几分这一秒,以捎带确认,这是通过延迟ACK定时器实现的。TCP不对ACK报文段进行确认,TCP只确认那些包含有数据的ACK报文段。

  • 检查和。检测数据在传输过程中是否发生变化,如果有差错,TCP将丢弃并不确认这个报文段。

  • TCP重排序。IP分组的到达可能会失序,因此TCP报文段的到达也可能会失序。TCP重排序将保证收到的数据以正确的顺序交给应用层。

  • TCP丢弃重复数据。重复数据的原因是IP分组会发生重复。

  • TCP流量控制。使用滑动窗口防止较快主机使较慢主机的缓冲区溢出。

全双工是指发送数据的同时也能接收数据,可理解为有两个方向相反的独立通道。

字节流服务是指TCP连接传输8bit字节构成的字节流,不在字节流中插入记录标识符,同时对字节流的内容也不作任何解释。

定时器在TCP可靠传输的过程中起着举足轻重的作用,每个TCP连接有以下七个定时器。

  • 连接建立定时器:在发送SYN报文段建立一个新连接时启动。如果没有在75s内收到响应,连接建立将终止。

  • 重传定时器:用于当希望收到另一端的确认。

    为了控制丢失的报文段或丢弃的报文段,也就是对报文段确认的等待时间。当TCP发送报文段时,就创建这个特定报文段的重传定时器。可能发生两种情况:若在定时器超时之前收到对报文段的确认,则撤销定时器;若在收到确认之前定时器超时,则重传该报文,并把定时器复位。重传间隔与RTT(连接的往返时间)有关,但有最小值,采用指数退避策略。

    重传定时器与拥塞控制有关。拥塞控制通过慢启动、拥塞避免和快速重传与快速恢复算法来实现。慢启动为发送端的TCP增加了另一个窗口即拥塞窗口。发送端取拥塞窗口和滑动窗口中的最小值作为发送上限。拥塞窗口是发送端使用的流量控制,而滑动窗口则是接收端使用的流量控制。拥塞窗口以报文段为单位,初始为1个报文段大小,是一种指数增加的关系。

    TCP超时并重传时,不一定要重传同样的报文段。相反,TCP允许进行重新分组而发送一个较大的报文段,这有助于提高性能。

  • 延迟ACK定时器:在TCP收到必须被确认但无需马上发出确认的数据时,不会立即确认,而是等待200ms后再发送确认。如果在这200ms内,有数据要在该连接上发送,延迟的ACK就可以随着数据一起发往对端,这被称为捎带确认。

  • 坚持定时器:使窗口大小信息保持不断流动,即使另一端关闭了其接收窗口。

    TCP通过让接收端指明希望从发送端接收的数据字节数(即窗口大小)来进行流量控制。如果窗口大小为零,将阻止发送方传送数据,直到窗口变为非零为止。

    TCP发送端收到接收端的零窗口大小报文时,就启动一个定时器。定时器到期时向接收端查询窗口是否已经增大,如果得到非零的窗口就重新开始发送数据,如果得到零窗口就再开一个新的定时器准备下一次查询。这些从发送端发出的报文段称为窗口探查。查询间隔初始为重传时间,采用指数退避,直到到达60s,之后每60s探查一次,持续到窗口被打开或连接终止。

    TCP的窗口协议,会引起一种通常叫做糊涂窗口综合症的问题。具体表现为,当接收端通告一个小的非零窗口时,发送端立刻发送小数据给接收端并充满其缓冲区,这就会使得网络中充满小的TCP报文段,从而影响网络利用率。有多种方法来避免该问题,比如接收端不通告小窗口等,这里不详述。

  • 时间等待定时器:测量一个连接处于TIME_WAIT状态的时间。

    在连接终止时使用。当TCP关闭连接时,并不认为这个连接就真正关闭了,而是处于一种中间过渡状态即TIME_WAIT状态。处于这个状态的时间由时间等待定时器控制,值通常设置为报文段最大生存时间 (MSL)的两倍。这个定时器有两个作用:

    一是为了测量连接处于TIME_WAIT状态的时间。这样可以让TCP再次发送最后的ACK以防止这个ACK丢失。如果丢失,另一端会重传FIN,2MSL的时间可以保证重传的FIN报文段可到达。

    二是为了使得老的重复报文段在网络中消失。如果一个TCP连接在断开之前有迷途报文段尚未消失,在断开该TCP连接之后立刻重启一个相等连接(相同四元组的连接),那么之前的迷途分节可能会到达并被新的TCP连接接收,从而造成错误的解析。为了避免这种情况,TCP规定在TIME_WAIT状态,不能启动一个相等连接。既然TIME_WAIT状态维持2MSL,这就保证了一个老连接上的报文段在新连接建立前都会消失。

  • FIN_WAIT_2定时器:当某个连接从FIN_WAIT_1状态变迁到FIN_WAIT_2状态,并且不再接收任何新数据时(意味着应用进程调用了close,而非shutdown,没有利用TCP的半关闭功能),FIN_WAIT_2定时器启动,设为10分钟。定时器超时后,重新设为75s。第二次超时后连接被关闭。这个定时器的目的是为了避免对端一直不发送FIN,连接会永远滞留在FIN_WAIT_2状态。

  • 保活定时器:可检测到一个空闲连接的另一端何时崩溃或重启。

    保活主要是为服务器应用程序提供的。因为TCP是面向连接的,就会出现只连接不传送数据的“半开放连接”。中间路由器可以崩溃和重启,但只要两端的主机没有被重启,则连接依然保持建立。服务器需要检测到这种连接并且在某些情况下进行释放,这就是保活定时器的作用。

    每当服务器收到客户端的信息,就将保活定时器复位。保活时间根据服务器的实现不同而不同,通常设置为2小时。若服务器超过2小时还没有收到来自客户的信息,就发送探测报文段,若发送了10个探测报文段(每隔75s发送一个)还没收到响应,则终止连接。

    值得一提的是,当其中一端崩溃并重新启动的情况下,如果收到该连接“前生”的保活探察,则要发送一个RST报文帮助另一端结束连接。

    保活并不是TCP规范中的一部分,所以其实现是可选的。

TCP需要同时处理成块数据和交互数据。如果需要发送太多小数据,会影响TCP传输效率,并增加拥塞出现的可能。TCP通过上面提到的捎带确认及Nagle算法解决该问题。

Nagle算法要求一个 TCP连接上最多只能有一个未被确认的未完成的微小分组(tinygram),在该微小分组的确认到达之前不能发送其他的微小分组。相反, TCP收集这些微小分组,并在确认到来时以一个报文段的方式发出去。

Nagle算法会导致微小分组的时延。在一些交互实时性要求较高的场合,微小分组必须无时延地发送,可以使用TCP_NODELAY选项来关闭Nagle算法。