tcp建立连接和断开连接过程

在之前对TCP协议的介绍中，说到了其中它的一个特点是面向连接。今天就来介绍一下它的连接和断开过程。

面向连接指的是采用TCP协议通讯，在数据传输之前必须先建立连接，通讯完成之后，必须关闭连接。

    建立连接的过程为三次握手过程，其作用是：

     1、使得通讯双发都做好通讯的准备

     2、告诉对端本端通讯所选用的报文标识号

     3、防止已失效的连接请求报文段又突然传递到了服务端，从而产生错误

  关闭连接的过程为四次挥手，由于TCP的全双工的通讯。所以每个方向都必须单独进行关闭。当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能继续发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

TCP三次握手和四次挥手过程：

当客户连接收到服务器发送的结束报文段（报文段6）之后，并没有直接进入CLOSED状态，而是转移到TIME_WAIT状态。在这个状态，客户端连接要等待一段长为2MSL(MSL：报文段最大生存时间)的时间，才能完全关闭。

TIME_WAIT状态存在的原因：

1、可靠的终止连接。   假设图中用于确认服务器报文段6的TCP报文段7丢失，那么服务器将重发结束报文段。因此客户端需要停留在某个状态处理重复收到的结束报文段（即向服务器发送确认报文段）。否则，客户端将以复位报文段来回应服务器，服务器则认为只是一个错误，因为它期望收到的是一个像报文段7那样的确认报文段。

2、保证让迟来的TCP报文段有足够的时间识别并丢弃。  在Linux系统上，一个TCP端口不能被同时打开两次及以上。当一个TCP连接处于TIME_WAIT状态时，我们无法立即使用该连接占用的端口号来建立一个新连接。因此，如果没有TIME_WAIT状态，则应用程序能够立即建立一个和刚关闭的连接相似的连接（相似是指它们具有相同的IP地址和端口号）。这个新的和原来相似的连接被称为原来的连接的化身。新的化身可能接收到属于原来的连接的、携带应用程序的TCP报文段（即迟到的报文段），这显然是不应该发生的，这是存在的第二个原因。

另外，因为TCP报文段的最大生存时间是MSL，所以坚持2MSL时间的TIME_WAIT状态能够确保网络上两个传输方向上尚未被接受到的、迟到的报文段都已经消失（被中转路由器丢弃）。因此，一个连接的新的化身可以再2MSL时间之后安全的建立，而绝对不会接收到属于原来连接的应用程序数据，这就是TIME_WAIT要持续2MSL时间的原因。

那么TCP为什么要进行三次握手和四次挥手呢？

 

“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。

 谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server“。

本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。主要目的防止server端一直等待，浪费资源。

 

四次挥手的原因：在四次挥手过程中，报文段6中也包含了确认信息，为什么还用报文段5单独先发一遍，那么这个报文段5可以背省略么？

实际上，仅用于确认目的的确认报文段5是可以省略的，因为报文段6中也携带了该确认信息。确认报文段5是否出现在连接断开的过程中，取决于TCP的延迟确认特性。

TCP连接是全双工的，所以它允许两个方向的数据传输被独立关闭。即，通信的一方可以发结束报文段给对方，告诉它本端已经完成了数据的发送，但允许继续接收来自对方的数据，直到对方也发送报文段结束。所以当客户端发送结束报文段后，服务器那里可能还有数据要发送，就先发送一个确认报文段表示已经接收到客户端发送过来的结束报文段，直到将数据发送完毕后再结束连接。

延迟确认：即服务器不马上确认上次收到的数据，而是在一段延迟时间后查看本端是否有数据需要发送，如果有，则和确认信息一起发出。因为服务器对客户的请求处理很快，所以他发送确认报文段的时候总是有数据一起发送。延迟确认可以减少发送TCP报文段的数量。而由于用户的输入速度明显慢于客户端程序的处理速度，所以客户端的确认报文段总是不携带任何应用程序。

转载于:https://www.cnblogs.com/Dovegege/p/10471185.html