TCP三次握手与四次挥手_lished

三次握手

SYN：同步序列号，表示建立连接。当SYN=1时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建立连接时才会被置1，握手完成后SYN标志位被置0。
ACK：确认序号，表示响应。当ACK=1,确认字段有效。
ack：确认序号。表示收到对方下一个报文段的第一个数据字节的序号；当ack=x+1表示此前的x个数据已收到，且告知对方下次发包的序列号为x+1。
seq：序列号。表示发送端的数据包的初始序号。

状态解析：

客户端
closed--关闭状态
syn-sent--同步已发送
estab-lished--建立完成、得到认可的

服务端
closed--关闭状态
listen--侦听状态
syn-rcvd--同步收到
enstab-lished--建立完成、得到认可的
1
2
3
4
5
6
7
8
9
10

过程：

第一次握手：客户端发送syn=1，seq=x 到服务端，客户端从closed状态转到syn-sent状态。
第二次握手：服务器端收到客户端的包，进入listen状态，服务器向客户端发送syn=1，ACK=1，seq=y，ack=x+1，并进入syn-rcvd状态。
第三次握手：客户端收到服务器发来的包，于是向服务端发送ACK=1，seq=x+1,ack=y+1,并进入estab-lished状态，服务器收到包也进入estab-lished状态，
完成三次握手

SYN攻击：

在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN-RCVD状态，当收到ACK后，Server转入ESTAB-LISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击是一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了。
解决：

方式1：减少SYN-ACK数据包的重发次数（默认是5次）：
sysctl -w net.ipv4.tcp_synack_retries=3 
sysctl -w net.ipv4.tcp_syn_retries=3 

方式2：使用SYN Cookie技术：
sysctl -w net.ipv4.tcp_syncookies=1 

方式3：增加backlog队列（默认是1024）：
sysctl -w net.ipv4.tcp_max_syn_backlog=2048 

方式4：限制SYN并发数：
iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT --limit 1/s
1
2
3
4
5
6
7
8
9
10
11
12

四次挥手

1：客户端发出释放报文，FIN=1，seq=u到服务端，并从estab-lished状态进入fin-wait-1（终止等待1）状态。
2：服务端收到释放报文，发出确认报文，ACK=1，seq=v，ack=u+1。此时服务器处于半关闭状态，即客户端已没有数据的发送，但是若服务端还有数据发送时客户端必须接收。服务端进入close-wait状态。
3：客户端收到确认报文就进入fin-wait-2状态，等待服务端发出释放报文。
4：服务端在数据发送完毕后，发出释放报文，FIN=1，ACK=1，seq=w，ack=u+1，服务端进入last-ack（最后确认）状态。
5：客户端收到服务端发出的释放报文，发出确认报文，ACK=1，seq=u+1，ack=w+1。客户端进入time-wait（时间等待）状态。但是此时客户端并没有完全释放TCP连接，还需再等待2*MSL（最长报文段寿命）时间后进入closed状态。
6：服务器收到客户端的确认立即进入closed状态。

问题一：

为什么连接的时候是三次握手，断开的时候是四次握手？
答：1.首先分析三次握手对比两次握手。两次握手中，倘若客户端发出的第一个数据包由于网络原因延迟地到达服务端，服务端收到后又一次的与客户端建立连接，但客户端不给服务端回复确认，此时服务端就会一直给客户端发送报文，占用服务端的资源。采用三次握手就可以避免此种情况的发生。
两次握手中出现的死锁问题
A机与B机通信，假设A给B发送一个请求分组，B收到分组后，发送确认应答，按照两次握手协议，B认为连接建立完成可以发送数据分组。可是如果B的应答分组在传输过程中出现丢失的情况下，A将不知道B建议的序列号是多少，甚至怀疑B是否收到自己的请求报文。这种情况下A认为与B的连接并未完成，将忽略B发来的任何数据分组，只等待俩连接确认应答分组。而B在发出的分组超时时，重复发送同样的分组，这样就形成的死锁。
2.断开时采用四次挥手。由于TCP连接时全双工的，所以每次关闭时都是双向的。我是这么理解的，客户端主动的发送释放报文，服务端接收到释放报文回复SYN+ACK确认，但是此时服务端的数据不一定发送完毕，所以需要等服务端的数据发送完之后主动的给客户端发送释放报文。所以断开需要四次。

问题二：

为什么客户端在time-wait状态必须等待2MSL的时间呢？
答：为了保证客户端发送的最后一个ACK报文能传递到服务端。假如ACK报文断丢失，服务端收不到确认便会再发送一次FIN+ACK到客户端，客户端收到后会重传，刷新2MSL计时器。倘若没有这个等待时间，客户端发送最后一个ACK就关闭后，服务端接收不到确认便会一直处在last-ack状态。
也可以使下一个连接中不会旧的连接的请求报文。

问题三：

如果建立了连接，客户端出现了故障怎么办？
答：TCP有一个保活计时器，保活计时器到时时，服务器会发送一个探测报文段，如果连续10个报文没反应，服务器便会关闭连接。