一般是丢弃，但这个行为可以通过 tcp_syncookies
首先我们需要明白，一般情况下，半连接的"生存"时间其实很短，只有在第一次和第三次握手间，如果半连接都满了，说明服务端疯狂收到第一次握手请求，如果是线上游戏应用，能有这么多请求进来，那说明你可能要富了。但现实往往比较骨感，你可能遇到了SYN Flood攻击。
所谓SYN Flood攻击，可以简单理解为，攻击方模拟客户端疯狂发第一次握手请求过来，在服务端憨憨地回复第二次握手过去之后，客户端死活不发第三次握手过来，这样做，可以把服务端半连接队列打满，从而导致正常连接不能正常进来。
syn攻击
那这种情况怎么处理？有没有一种方法可以绕过半连接队列？
有，上面提到的tcp_syncookies派上用场了。
# cat /proc/sys/net/ipv4/tcp_syncookies
1当它被设置为1的时候，客户端发来第一次握手SYN时，服务端不会将其放入半连接队列中，而是直接生成一个cookies，这个cookies会跟着第二次握手，发回客户端。客户端在发第三次握手的时候带上这个cookies，服务端验证到它就是当初发出去的那个，就会建立连接并放入到全连接队列中。可以看出整个过程不再需要半连接队列的参与。
- 会有一个cookies队列吗?
- 生成是
cookies，保存在哪呢？ - 是不是会有一个队列保存这些cookies？
我们可以反过来想一下，如果有cookies队列，那它会跟半连接队列一样，到头来，还是会被SYN Flood 攻击打满。
实际上cookies并不会有一个专门的队列保存，它是通过通信双方的IP地址端口、时间戳、MSS等信息进行实时计算的，保存在TCP报头的seq里。
tcp报头_seq的位置
当服务端收到客户端发来的第三次握手包时，会通过seq还原出通信双方的IP地址端口、时间戳、MSS，验证通过则建立连接。
cookies方案为什么不直接取代半连接队列？
目前看下来syn cookies方案省下了半连接队列所需要的队列内存，还能解决 SYN Flood攻击，那为什么不直接取代半连接队列？
凡事皆有利弊，cookies方案虽然能防 SYN Flood攻击，但是也有一些问题。因为服务端并不会保存连接信息，所以如果传输过程中数据包丢了，也不会重发第二次握手的信息。
另外，编码解码cookies，都是比较耗CPU的，利用这一点，如果此时攻击者构造大量的第三次握手包（ACK包），同时带上各种瞎编的cookies信息，服务端收到ACK包后以为是正经cookies，憨憨地跑去解码（耗CPU），最后发现不是正经数据包后才丢弃。
这种通过构造大量ACK包去消耗服务端资源的攻击，叫ACK攻击，受到攻击的服务器可能会因为CPU资源耗尽导致没能响应正经请求。
