Chapter19_TCP连接的建立与终止

TCP三次握手建立连接

TCP握手协议

　　在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

　　第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；

　　第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

解析：syn包，即同步序号包，就是分组的初始序号(ISN)；

1，为什么要有这个分组的序号呢？

因为接收端每接收到一个数据包会返回一个ack应答包，而发送数据的过程并不是每发送一个数据包然后等待一个ack应答包，而是根据窗口大小发送几个数据包，所以返回的应答包到底是对哪个数据包的应答，这时候就靠序号来判别ack应答包是对哪个数据包的应答，因此可以有效的进行丢包和超时重传的机制，同理，如果应答包丢失的话，可能会导致接收端收到两个同样的数据包，这时候可以根据序号去过滤掉重复的包；

2，为什么要进行3次握手，两次握手会出现什么样的情况呢？

可以有效的防止已过期的连接再次传到服务器端，比如是A机要连到B机，结果发送的连接信息由于某种原因没有到达B机；于是，A机又发了一次，结果这次B收到了，于是就发信息回来，两机就连接。传完东西后，断开。结果这时候，原先没有到达的连接信息突然又传到了B机，于是B机发信息给A，然后B机就以为和A连上了；

3，那么三次握手是怎么防止过期的连接的呢？

如果服务器端的返回ack包延期到达，其实没有影响，因为此时的客户端的状态没有在正确的状态，因此该包没有影响；

4，滑动窗口引入的原因，

如果窗口大小只有1个，OK ，那每次发送方 发完一个数据包后都得等待回应，只有收到回应后才能发送第二个包，这样就减缓了处理速度。

如果发送方的窗口大小有100个，OK 他一次发送100个数据，但是请求方只能处理50个数据，他就会处理完50个数据，告诉发送方 他下次要的数据要从第51号开始，发送方接收到这个信息后，就知道请求方一次只能处理50个数据，就会改变窗口的大小置50，然后一次发送50个数据，这个滑动窗口会根据请求方的接受能力不断变化，所以称为滑动窗口。

5，建立连接过程的交互信息

TCP 连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP 窗口大小信息以及最大报文段长度等。

6，什么是半连接队列？

第一次握手完成后，服务端发送ACK+SYN包到客户端，在收到客户端返回前的状态为SYN_RECV，服务端为此状态维护一个半连接队列。当服务端收到客户的确认包时，删除该条目，服务端进入ESTABLISHED状态。Listen中的backlog参数表示这两个状态合的最大值。若客户端完成第一次握手后不再发送ACK包，导致服务端未完成队列溢出，达到Dos攻击的目的。

7，什么是SYN-ACK重传？

Dos攻击可以达到目的的一个重要因素是服务端在发送完SYN+ACK包后会等待客户端的确认包，如果等待时间内未收到，服务端会进行首次重传，等待一段时间仍未收到客户确认包，会进行第二次重传，直到重传次数超过系统规定的最大值，系统将该连接信息从半连接队列中删除。如果系统删除的频率小于半连接状态的增长频率，服务端就无法正常提供服务。 

8，最大报文段长度MSS与MTU？

mtu是网络传输最大报文包。mss是网络传输数据最大值（纯数据的大小）。也就是说MSS加上IP包头和TCp包头等就是MTU。

9：如果建立连接的第三个包丢失，那么会出现什么情况？

SYN-ACK 重传次数　服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超 过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。

10. 三次握手改成仅需要两次握手，死锁是可能发生

考虑计算机A和B之间的通信，假定B给A发送一个连接请求分组，A收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A认为连接已经成功地建立了，可以开始发送数据分组。可是，B在A的应答分组在传输中被丢失的情况下，将不知道A是否已准备好，不知道A建议什么样的序列号，B甚至怀疑A是否收到自己的连接请求分组。在这种情况下，B认为连接还未建立成功，将忽略A发来的任何数据分组，只等待连接确认应答分组。而A在发出的分组超时后，重复发送同样的分组。这样就形成了死锁

TCP四次握手断开连接

备注：

      当服务器端首次受到FIN的时候，将向上层应用层交付一个EOF标志；

一，   为什么TCP协议终止链接要四次？

（网上有人说是跟这个半关闭状态的原因，表示不敢苟同）

1、当主机A确认发送完数据且知道B已经接受完了，想要关闭发送数据口（当然确认信号还是可以发），就会发FIN给主机B。

2、主机B收到A发送的FIN，表示收到了，就会发送ACK回复。

3、但这是B可能还在发送数据，没有想要关闭数据口的意思，所以FIN与ACK不是同时发送的，而是等到B数据发送完了，才会发送FIN给主机A。

4、A收到B发来的FIN，知道B的数据也发送完了，回复ACK， A等待2MSL以后，没有收到B传来的任何消息，知道B已经收到自己的ACK了，A就关闭链接，B也关闭链接了。

 

二，为什么等待2MSL，从TIME_WAIT到CLOSE？

 在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(MaximumSegment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

       TCP 相关的内容

一，TCP半关闭状态：

TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力，这就是TCP的半关闭。然而多数情况下，"半关闭"使用的很少，而且半关闭需要SOCKETAIP支持在SOCKET上的shutdown(而不是调用close)。

二，RST复位报文段：

       RST表示复位，用来异常的关闭连接，在TCP的设计中它是不可或缺的。发送RST包关闭连接时，不必等缓冲区的包都发出去，直接就丢弃缓冲区的包发送RST包。而接收端收到RST包后，也不必发送ACK包来确认。

几种常见的RST的情况：

1.到不存在的端口的连接请求

产生复位的一种常见情况是当连接请求到达时，目的端口没有进程正在监听。对于UDP，当一个数据报到达目的端口时，该端口没在使用，它将产生一个ICMP端口不可达的信息；而TCP则使用复位。

2.异常终止一个连接

终止一个连接的正常方式是一方发送FIN，这也称为有序释放，因为在所有排队数据都已发送之后才发送FIN，正常情况下没有任何数据丢失。但也有可能发送一个复位报文段而不是FIN来中途释放一个连接，这也称为异常释放。异常终止一个连接对应用程序来说有两个优点：（1）丢弃任何待发数据并立即发送复位报文段；（2）RST的接收方会区分另一端执行的是异常关闭还是正常关闭。

3.检测半打开连接

如果一方已经关闭或异常终止连接而另一方却还不知道，我们将这样的TCP连接称为半打开的。任何一端的主机异常都可能导致发生这种情况。只要不打算在半打开连接上传输数据，仍处于连接状态的一方就不会检测另一方已经出现异常。下面介绍一种建立半打开连接的情形。在bsdi上运行Telnet客户程序，通过它和svr4上的丢弃服务器建立连接。接着断开服务器主机与以太网的电缆，并重启服务器主机。这可以模拟服务器主机出现异常（在重启服务器之前断开以太网电缆是为了防止它向打开的连接发送FIN，某些TCP在关机时会这么做）。服务器主机重启后，我们重新接上电缆，并从客户向服务器发送一行字符。由于服务器的TCP已经重新启动，它将丢失复位前连接的所有信息，因此它不知道数据报文段中提到的连接。TCP处理的原则是接收方以复位作为应答。

三，同时打开与同时关闭

      同时打开：就是说两个应用程序同时执行主动打开建立连接，那么此时将建立两条连接（可以认为是分开建立连接即可）彼此即是客户端又是服务器；

同时关闭：同时关闭与正常关闭使用的段交换数目相同；

它们的进程如下所示：

四，呼入连接请求队列

当服务器在创建一个新的进程时，或操作系统正忙于处理优先级更高的进程时，到达

多个连接请求。当服务器正处于忙时， T C P是如何处理这些呼入的连接请求？

在伯克利的T C P实现中采用以下规则：

1) 正等待连接请求的一端有一个固定长度的连接队列，该队列中的连接已被T C P接受

（即三次握手已经完成），但还没有被应用层所接受。

注意区分T C P接受一个连接是将其放入这个队列，而应用层接受连接是将其从该队列

中移出。

2) 应用层将指明该队列的最大长度，这个值通常称为积压值( b a c k l o g )。它的取值范围是0 ~ 5之间的整数，包括0和5（大多数的应用程序都将这个值说明为5）。

3) 当一个连接请求（即S Y N）到达时，T C P使用一个算法，根据当前连接队列中的连接数来确定是否接收这个连接。我们期望应用层说明的积压值为这一端点所能允许接受连接的最大数目，但情况不是那么简单。图1 8 - 2 3显示了积压值与传统的伯克利系统和S o l a r i s2 . 2所能允许的最大接受连接数之间的关系。注意，积压值说明的是T C P监听的端点已被T C P接受而等待应用层接受的最大连接数。这个积压值对系统所允许的最大连接数，或者并发服务器所能并发处理的客户数，并无影响。在这个图中，S o l a r i s系统规定的值正如我们所期望的。而传统的B S D系统，将这个本地地址远端地址描述限制到一个客户进程(通常不支持)限制为到达一个本地接口：Local IP的连接接收发往Lport的所有连接值（由于某些原因）设置为积压值乘3除以2，再加1。

4) 如果对于新的连接请求，该T C P监听的端点的连接队列中还有空间（基于图1 8 - 2 3），T C P模块将对S Y N进行确认并完成连接的建立。但应用层只有在三次握手中的第三个报文段收到后才会知道这个新连接时。另外，当客户进程的主动打开成功但服务器的

应用层还不知道这个新的连接时，它可能会认为服务器进程已经准备好接收数据了（如果发生这种情况，服务器的T C P仅将接收的数据放入缓冲队列)。

5) 如果对于新的连接请求，连接队列中已没有空间， T C P将不理会收到的S Y N。也不发回任何报文段（即不发回R S T）。如果应用层不能及时接受已被T C P接受的连接，这些连接可能占满整个连接队列，客户的主动打开最终将超时。