TCP的运输连接管理(三次握手和四次挥手）

TCP的运输连接管理

TCP是面向连接的协议，它基于运输连接来传送TCP报文段.

TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。

TCP运输连接有以下三个阶段:

1. 建立TCP连接
2. 数据传送
3. 释放TCP连接

TCP的运输连接管理就是使运输连接的建立和释放都能正常地进行。

TCP的连接建立要解决以下三个问题:

1. 使TCP双方能够确知对方的存在;
2. 使TCP双方能够协商一些参数(如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等);
3. 使TCP双方能够对运输实体资源（如缓存大小、连接表中的项目等)进行分配。

TCP使用“三报文握手”建立连接

1.最初。两端的TCP进程都处于关闭状态

2.一开始，TCP服务器进程首先创建传输控制块，用来存诸TCP莲接中的一些重要信息，例如tcp连接表，指向发送和接收缓存的指针等。。

3.TCP服务器进程进入监听状态，被动等待TCP客户进程的莲接请求

4.TCP客户进程也是首先创建传输控制块。

5.TCP客户进程向tcp服务进程发送tcp连接请求报文段，并将自己进入同步已发送状态

TCP连接请求报文段首部中的同步位SYN被设置为1,表明这是一个TCP连接请求报文段。序列号seq=x表示这是TCP客户进程所随机选择的初始序号。TCP规定SYN被设置为1的报文段不能携带数据

6.如果tcp服务器同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接收状态

该报文段首部中的同步位SYN和确认位ACK都设置为1，表明这是一个TCP连接请求确认报文段，序号字段seg被设置了一个初始值y，确认号字段ack的值被设置成了x+1,这是对TCP客户进程所选择的初始序号的确认。这个报文段也不能携带数据。

7.TCP客户进程收到TCP连接请求确认报文段后，还要向TCP服务器进程发送一个普通的TCP确认报文段，并进入连接已建立已状态。

ACK设置为1表明，表明这是一个普通的TCP确认报文段，序号字段seq被设置为X+1,这是因为TCP客户进程发送的第一个TCP报文段的序号为x并且不携带数据，因此这时客户端发送的第二个报文段的序号为x+1，TCP规定普通的TCP确认报文段可以携带数据。但如果不携带数据则不消耗序号，那么所发送的下一个数据报文段的序号仍是X+1，确认号字段ack被设置为y+1,这是对TCP服务器进程所选择的初始序号的确认。TCP服务器进程收到该确认报文段后也进入连接已建立状态，此时双方可以开始数据传输了

能不能使用“两次握手”？

如果客户端取消最后一次报文发送，改使用”两次握手“进行连接，即tcp服务器发送第二次连接后就进入连接已建立状态，这样会产生什么后果？

答：不可以，”三次握手“这是为了防止已失效的连接请求报文段突然又传送到了TCP服务器，因而导致错误。

考虑这样一种情况，TCP客户进程发出一个TGP连接请求报文段。但该报文段在某些网络结点长时间滞留了。

在滞留过程中触发了该报文段的超时重传，客户端将之前那条报文段设置为失效并且重传的报文段被服务器正常接收，TCP服务器进程给TCP客户进程发送一个TCP连接请求确认报文段,并且TCP服务器进程发送完TCP童接请求确认报文段后进入的是连接已建立状态，客户端收到该报文后也进入连接已建立状态，并且双方可以传输数据，传输结束后通过四次挥手来释放连接

释放连接后tcp双方都立即进入了关闭状态，一段时间后客户端之前滞留的那条失效的报文段到达了服务器端，TCP服务器进程会误认为这是TCP客户进程又发起了一个新的TCP连接请求，于是给TCP客户进程发送TCP连接请求确认报文段，并进入连接已建立状态，而由于TCP客户进程并没有发起新的TCP连接请求且处于关闭状态因此不会理睬该报文段，而tcp服务器端一直等待TCP客户进程发来数据，这将白白浪费TCP服务器进程所在主机的很多资源。

TCP的连接释放

TCP通过“四报文挥手”来释放连接

数据传输结束后，TCP通信双方都可以释放连接，现TCP客户进程和TCP服务器进程都处于连接已建立状态，假设使用TCP客户进程的应用进程通知其主动关闭TCP连接。

TCP客户进程会发送TCP连接释放报文段，并进入终止等待1状态

该报文段首部中的终止位FIN，和确认位ACK的值都被设置为1,表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认。序号段seq的值设置为u，等于tcp客户进程之前已传送过的，数据的最后一个字节的序号加1，TCP规定终止位FIN等于1的报文段即使不携带数据,也要消耗一个序列号，确认号ack的值设置为v，它等于TCP客户进程之前已收到的，数据的最后一个字节的序号加1。

TCP服务器进程收到报文后，会发送一个普通的TCP确认报文段并进入关闭等待状态。

该报文段首部中的确认位ACK的值被设置为1,表明这是一个普通的TCP确认报文段。序号seq字段的值设置为v，它等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加1。这也与之前收到的TCP连接释放报文段中的确认号匹配。确认号ack字段的值设置为u+1，这是对TCP连接释放报文段的确认。

TCP服务器进程这时应通知高层应用进程：TCP客户进程要断开与自己的TCP连接。

此时，从TCP客户进程到TCP服务器进程这个方向的连接就释放了。这时的TCP建连接属于半关闭状态，也就是TCP客户进程已经没有数据要发送了,但TCP服务器进程如果还有数据要发送,TCP客户进程仍要接收。也就是说从TCP服务器进程到TCP客户进程这个方向的连接并未关闭。这个状态可能会持续一段时间，TCP客户进程收到TCP确认报文段后就进入终止等待2状态。等待TCP服务器进程发出的TCP连接释放报文段。

TCP服务器进程发送TCP连接释放报文段并进入最后确认状态。

若使用TCP服务器进程的应用进程已经没有数据要发送了，应用进程就通知其TCP服务器进程释放连接。由于TCP连接释放是由TCP客户进程主动发起的,因此TCP服务器进程对TCP连接的释放称为被动关闭连接。

该报文段首部中的终止位FIN和确认位ACK的值都被设置为1,表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认，假定序号seq的值设置为w，这是因为在半关闭状态下，TCP服务器进程可能又发送了一些数据。确认号ack的值设置为u+1，这是对之前收到的TCP连接释放报文段的重复确认。数据的最后一个字节的序号加1

TCP客户端收到这条报文后，必须针该报文段发送普通的TCP确认报文段，之后进入时间等待状态

该报文段首部中的确认位ACK的值被设置为1，表明这是一个普通的TCP确认报文段，序号seq的值设置为u+1,这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据,但要消耗一个序列号，确认号ack的值设置为w+1，这是对所收到的TCP连接释放报文段的确认

TCP服务器进程收到该报文段后就进入关闭状态，而TCP客户进程还要经过2MSL后才能进入关闭状态

MSL(Maximum Segment Lifetime)意思是最长报文段寿命，RFC793建议为2分钟。也就是说tcp用户进程要等待4分钟，实际上tcp可根据不同的情况使用不同的MSL值

能不能取消掉TCP客户端的时间等待时间呢？

当TCP客户端收到TCP服务器的TCP连接释放报文段并且发送普通的TCP确认报文段后能否直接进入关闭状态？

答：不可以，时间等待是为了防止客户端报文段丢失导致tcp服务器端无法关闭

如果客户端最后发送的报文段丢失了，那么客户端就会一直等待客户端发送最后一段报文且自身一直处于最后确认状态，当触发服务器端的超时重传机制时服务器端会重新发送TCP连接释放报文段，而tcp客户端因为已经关闭自身所以无法作出回应，因此TCP客户端之所以要将时间等待时间设置为2MSL就是确保当服务器端超时重传时自己还处于能接收的状态

TCP保活计时器

设想这样一种情况:TCP双方已经建立了连接。然后TCP客户进程所在的主机突然出现了故障。TCP服务器进程以后就不能再收到TCP客户进程发来的数据，所以应当有措施使TCP服务器进程不要再白白等待下去。

保活计时器详情

• TCP服务器进程每收到一次TCP客户进程的数据，就重新设置并启动保活计时器(2小时定时)。
• 若保活计时器定时周期内未收到TCP客户进程发来的数据，则当保活计时器到时后，TCP服务器进程就向TCP客户进程发送一个探测报文段，以后则每隔75秒钟发送一次。若一连发送10个探测报文段后仍无TCP客户进程的响应，TCP服务器进程就认为TCP客户进程所在主机出了故障，接着就关闭这个连接。