TCP连接的建立和终止

1.三路握手

建立一个tcp连接会发生下列情形

1.1服务器必须准备好接受外来的连接。这通常通过调用socket,bind和listen这3个函数来完成,我们称之为被动打开

1.2客户端通过调用connect发起主动打开(active open)。这导致客户tcp发送一个SYN分节,它告诉服务器客户将在(带建立的)连接中发送的数据的初始序列号。通常SYN分节不携带数据,其所在IP数据报只含有一个IP首部,一个TCP首部及可能有的TCP选项。

1.3服务器必须确认(ACK)客户的SYN,同时自己也得发送一个SYN分节,它含有服务器将在同一连接中发送的数据的初始序列号。服务器在单个分节中发送SYN和对客户SYN的ACK确认。

1.4客户端确认服务器的SYN。

这种交换至少三个分组,因此称之为tcp的三路握手。如图所示


图中给出的客户端的初始序列号(SYN)为 J,服务器端的初始序列号是 K ,ACK中的确认号是发送这个ACK的一端所期待的下一个序列号。因为SYN所占据的一个字节的序列号空间,所以每个SYN的ACK中的确认序号就是该SYN序列号加 1。类似的,每一个FIN的ACK中的确认序号为FIN加 1。

2.TCP选项

每一个SYN可以含有多个TCP选项。下面是常用的tcp选项

2.1MSS选项。发送SYN的TCP一端使用本选项通告对端它的最大分节大小(MSS),也就是它在本连接的每个TCP分节中愿意接受的最大数据量。发送端TCP使用接收端的MSS值作为所发送分节的最大大小。

2.2窗口规模选项。TCP连接任何一端能够通告对端的最大窗口大小是65535,因为在TCP首部中相应的字段占16位。然而当今因特网上也以普及的高速网络连接或长延迟路径要求有更大的窗口以获得尽可能大的吞吐量。这个新选项指定TCP首部中的通告窗口必须扩大(0~14)位,因此所提供的最大窗口接近1 GB(65535*2^14)。在一个TCP连接上使用窗口规模的前提是它的两个端系统必须都支持这个选项。

2.3时间戳选项。这个选项对于高速连接网络是必要的,他可以防止失而复现的分组可能造成的数据损坏。它是一个新的选项,也以类似于窗口规模选项的方式协商处理。

3.TCP连接终止

TCP建立一个连接需要3个分节,TCP终止一个连接则需4个分节

3.1某个应用进程调用close函数,我们称该端执行主动关闭。该端的TCP预试发送一个FIN分节,表示数据发送完毕。

3.2接受到这个FIN的对端执行被动关闭,这个FIN由TCP确认。它的接受也作为一个文件结束符传递给接收端应用进程,因为FIN的接收意味着接收端应用进程在相应连接上再无额外数据可接收。

3.3一段时间后,接收到这个文件结束符的应用进程也将调用close关闭它的套接字。这导致它的TCP也发送一个FIN。

3.4接收这个最终FIN的原发送端TCP确认这个FIN。

如图示:


类似SYN,一个FIN也占据一个字节的序列号空间。因此每个FIN的ACK确认序号就是这个FIN的序列号加 1。

在步骤2和步骤3之间,从执行被动关闭一端到执行主动关闭一端的数据流动是可能的。这称为半关闭,另外在主动关闭接受到被动关闭一个传来的FIN后,会进入TIME_WAIT状态。

    当套接字被关闭时,其所在端TCP各自发送了一个FIN。当一个UNIX进程无论自愿的还是非自愿的终止时,所有打开的描述符都被关闭,这也导致仍然打开的任何TCP连接上也会发出一个FIN。

4.TCP状态转换图

TCP为一个连接定义了11中状态,并且TCP规则规定如何基于当前状态及在该状态下所接收到的分节从一个状态转换为另一个状态。举例来说,当某个应用进程在CLOSED状态下执行主动打开时,TCP将发送一个SYN,且新的状态是SYC_SENT。如果这个TCP接着接受到一个带ACK的SYN,它将发送一个ACK,且新的状态是ESTABLISHED。这个最终状态是绝大多数数据传送发生的状态。

自ESTABLISHED状态引出的两个箭头处理连接的终止。如果一个进程在接受到一个FIN之间主动调用close,那么就转换到FIN_WAIT_1状态。但如果某个应用进程在ESTABLISHED状态期间接受到一个FIN(被动关闭),就会转换到CLOSE_WAIT状态。


5.观察分组

下图中有完整的TCP连接终止的过程及状态


本例中的客户通告一个值为536的MSS(表明该客户只实现了最小重组缓冲区大小),服务器通告一个值为1460(以太网上IPV4的典型值)。不同方向上MSS值不相同不成问题。

一旦建立一个连接,客户就构造一个请求并发送给服务器。这里我们假设该请求适合于单个TCP分节(即请求大小小于服务器通告的值为1460字节的MSS)。服务器处理该请求并发送一个应答,我们假设该应答也适合当个分节(本例小于536字节)。图中使用粗箭头表示这两个数据分节。注意,服务器对客户请求的确认是伴随其应答发送的。这种做法称为捎带,它通常在服务器处理请求并产生应答的时间少于200ms时发送。如果服务器耗用更长时间,譬如1s,那么我们将看到先是确认后是应答。

图中随后展示的是终止连接的4个分节。注意,执行主动关闭的那一端(本例子中为客户)进入TIME_WAIT状态。

6.TIME_WAIT状态

TIME_WAIT状态有两个存在的理由:

(1)可靠地实现TCP全双工连接的终止;

(2)允许老的重复分节在网络中消逝。

理由1:例如图中,在被动关闭方,发送FIN后,主动关闭方要回应一个ACK,这个ACK可能会丢失,或者超时,则会导致被动关闭方重新发送一个FIN,此时主动关闭方处于TIME_WAIT状态,则可继续响应传送来的FIN;如果没有TIME_WAIT状态,主动关闭方直接进入CLOSED状态,将会响应一个RST(另外一种类型的TCP分节),该分节被服务器解释成一个错误。如果TCP打算执行所有必要的工作以彻底终止某个连接上两个方向上的数据流(即全双工关闭),那么它必须正确处理连接终止序列4个分节中任何一个分节丢失的情况。本例子也说明了为什么执行主动关闭的那一端是处于TIME_WAIT状态的那一端:因为可能不得不重传最终那个ACK的就是那一端。

为理解存在TIME_WAIT状态的第二个理由,我们假设在12.106.32.154的1500端口和206.168.112.219的21端口之间有一个TCP连接。我们关闭这个连接,过一段时间后在相同的IP地址和端口直接建立另一个连接。后一个连接称为前一个连接的化身,因为它们的IP地址和端口号都相同。TCP必须防止来自某个连接的老的重复分组在该连接已终止后再现,从而被误解成属于同一连接的某个新的化身。为做到这一点,TCP将不给处于TIME_WAIT状态的连接发起新的化身。既然TIME_WAIT状态的持续时间是MSL的2倍,这就足以让某个方向上的分组最多存活MSL秒即被丢弃,另一个方向上的应答最多存活MSL秒也被丢弃。通过实施这个规则,我们就能保证每成功建立一个TCP连接时,来自该连接先前化身的老的重复分组都已在网络中消逝了。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值