C# TCP协议

• TCP协议建立连接需要通过“三次握手”来实现：

下面是“三次握手”的流程图：

1. 几个名词：

1. SYN：处于TCP连接建立过程。
2. ACK：确认序号标志，为1时表示确认号有效，为0时表示报文中不含确认信息,忽略该字段。

1. 连接过程：

1. TCP服务器进程打开，准备接受客户进程的连接请求，此时服务器进入了LISTEN（监听）状态
2. 客户端向服务器发出连接请求报文，这时报文首部SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
3. TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1（确认号），自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
4. 当服务器收到客户端的确认后也进入ESTABLISHED状态，双方可以开始通信。

1. 关于建连接时SYN超时：

如果server端接到了clien发的SYN后回了SYN-ACK后client掉线了，server端没有收到client回来的ACK，那么，这个连接处于一个中间状态，即没成功，也没失败。于是，server端如果在一定时间内没有收到的TCP会重发SYN-ACK。在Linux下，默认重试次数为5次，重试的间隔时间从1s开始每次都翻售，5次的重试时间间隔为1s, 2s, 4s, 8s, 16s，总共31s，第5次发出后还要等32s都知道第5次也超时了，所以，总共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 2^6 -1 = 63s，TCP才会把断开这个连接。

 

1. 解决方案：
2. 调整三个TCP参数可供选择，第一个是：tcp_synack_retries 可以用他来减少重试次数；第二个是：tcp_max_syn_backlog，可以增大SYN连接数；第三个是：tcp_abort_on_overflow 处理不过来干脆就直接拒绝连接了。
3. 三次握手主要目的是：
   1. 防止超时导致脏连接。如果使用的是两次握手建立连接，假设客户端发送了第一个请求连接并且没有丢失，只是因为在网络中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。
   2. （Stackoverflow上给出的解答）要初始化Sequence Number 的初始值。通信的双方要互相通知对方自己的初始化的Sequence Number。这个号要作为以后的数据通信的序号，以保证应用层接收到的数据不会因为网络上的传输的问题而乱序
   Alice ---> Bob SYNchronize with my Initial Sequence Number of X
   Alice <--- Bob    I received your syn, I ACKnowledge that I am ready for [X+1]
   Alice <--- Bob    SYNchronize with my Initial Sequence Number of Y
   Alice ---> Bob    I received your syn, I ACKnowledge that I am ready for [Y+1]
   这样2人都知道对方的序号并发出了确认，因为第2和第3步可以放在一起，所以只需要3次通信

 

 

• 关闭连接时需要“四次挥手”：

下面时原理图：

1. 几个名词：

FIN：发送端已完成数据传输，请求释放连接。
TIME_WAIT：主动要求关闭的机器表示收到了对方的FIN报文，并发送出了ACK报文，进入TIME_WAIT状态，等2MSL后即可进入到CLOSED状态。如果FIN_WAIT_1状态下，同时收到待FIN标识和ACK标识的报文时，可以直接进入TIME_WAIT状

态，而无需经过FIN_WAIT_2状态。
CLOSE_WAIT：被动关闭的机器收到对方请求关闭连接的FIN报文，在第一次ACK应答后，马上进入CLOSE_WAIT状态。这种状态其实标识在等待关闭，并且通知应用发送剩余数据，处理现场信息，关闭相关资源。

1. 释放过程：

1.数据传输完毕，客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

2.服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

3.客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文。

4.服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

5.客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，才进入CLOSED状态。

6.服务器只要收到了客户端发出的确认，立即进入CLOSED状态

1. 为什么客户端最后还要等待2MSL（为什么需要TIME_WAIT状态）？（最坏情况下，未收到4步的ACK，3步的FIN需要重发，去向ACK【第四步】最大存活时间（MSL) + 来向FIN【第三步】的最大存活时间(MSL)）

MSL（Maximum Segment Lifetime，TCP允许不同的实现可以设置不同的MSL值）。第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失。站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。如果客户端收到服务端的FIN+ACK报文后，发送一个ACK给服务端之后就“自私”地立马进入CLOSED状态，可能会导致服务端无法确认收到最后的ACK指令，也就无法进入CLOSED状态。第二，防止失效请求。防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。防止在该段时间内创建两个具有相同IP和端口的连接

 

1. 大量TIME_WAIT的影响？

在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。主动正常关闭TCP连接，都会出现TIMEWAIT。在业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间的情况下，持续的到达一定量的高并发短连接，会使服务器因端口资源不足而拒绝为一部分客户服务。可以通过负载均衡来变相的解决该问题。

查询TCP各个状态的连接数？netstat -ant|awk'/^tcp/ {++S[$NF]} END {for(a in S) print (a,S[a])}'

如何尽量处理TIME_WAIT过多？开启TIME-WAIT重用，表示TIME-WAIT状态的socket可以新的TCP连接；开启TIME-WAIT快速回收；加大用于向外连接的端口范围；减少系统同时保持TIME-WAIT的数量

1. 调优

在TIME_WAIT状态无法真正释放句柄资源，在此期间，Socket中使用的本地端口在默认情况下不能再被使用。该限制对于客户端机器来说是无所谓的，但对于高并发服务器来说，会极大地限制有效连接的创建数量，称为性能瓶颈。所以建议将高并发服务器TIME_WAIT超时时间调小。RFC793中规定MSL为2分钟。但是在当前的高速网络中，2分钟的等待时间会造成资源的极大浪费，在高并发服务器上通常会使用更小的值。通过变更/etc/sysctl.conf文件来修改该默认值net.ipv4.tcp_fin_timout=30（建议小于30s）。修改完之后执行 /sbin/sysctl -p 让参数生效。

1. 为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。 而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。