tcp/ip连接

TCP ：transmission control protocol传输控制协议

我们常说的TCP/IP三次握手、四次挥手指的是三次握手连接，四次挥手终止连接

三次握手建立连接：

第一次握手：

建立连接时，客户端发送syn包（syn=1）到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手：

服务器收到syn包，发回确认包ack应答，此时服务器进入SYN_RECV状态；

第三次握手：

客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK（ack=k+1）,此包发送完毕，客户端与服务器进入established状态

完成三次握手之后，客户端与服务器开始传输数据。

syn攻击：

这是一种DDoS攻击；攻击客户端，在短时间内伪造大量不存在IP地址，向服务器不断发送syn包，服务器回复确认包并等待客户端确认，但是由于IP地址并不存在，服务器就会重复发送直至超时，这些伪造的syn包将长时间占用未连接队列，正常syn请求被丢弃，系统运行缓慢，严重时导致网络堵塞甚至系统瘫痪。

检测syn攻击：服务器上大量半连接状态，且IP地址是随机的，很有可能就是syn攻击

Linux的一些命令可以检测：netstart -n -p TCP|grep SYN_RECV

防范syn攻击：

synattackprotect 保护机制

syn cookies技术 

但是这也不能完全防范syn攻击

TCP四次挥手关闭连接：

第一次挥手：

当客户端A完成数据传输后,将控制位FIN置1，提出停止TCP连接的请求 ；

第二次挥手：

服务器B收到FIN后对其作出响应，确认这一方向上的TCP连接将关闭,将ACK置1；

第三次挥手：

服务器B再提出反方向的关闭请求,将FIN置1 ；

第四次挥手：

客户端A对服务端B的请求进行确认，将ACK置1，双方向的关闭结束.。

四次挥手完毕

其中SYN 同步序列号，TCP建立连接时将这个位置1     ACK：确认       FIN：结束

笔试/面试常会问道的：

1．为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？

这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的连接请求后，它可以把ACK和SYN(ACK起应答作用，而SYN起同步作用)放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可能未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

3. 为什么不能用两次握手进行连接？

我们知道，3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
    现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。