TCP链接的创建和断开过程

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

面向链接指的是采用TCP协议通信，在数据传输以前必须先创建链接，通信完成以后，必须关闭链接。

    创建链接的过程为三次握手过程，其做用是：

     一、使得通信双发都作好通信的准备

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

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

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

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

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

TIME_WAIT状态存在的缘由：

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

二、保证让迟来的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报文段的数量。而因为用户的输入速度明显慢于客户端程序的处理速度，因此客户端的确认报文段老是不携带任何应用程序。