服务端没有 listen，客户端发起连接建立，会发生什么？        

服务端如果只 bind 了 IP 地址和端口，而没有调用 listen 的话，然后客户端对服务端发起了连接建立，服务端会回 RST 报文。

没有 listen，能建立 TCP 连接吗？

是可以的，客户端是可以自己连自己的形成连接（TCP自连接），也可以两个客户端同时向对方发出请求建立连接（TCP同时打开），这两个情况都有个共同点，就是没有服务端参与，也就是没有listen，就能建立连接。

执行 listen 方法时，会创建半连接队列和全连接队列，三次握手的过程中会在这两个队列中暂存连接信息。客户端没有执行listen，因为半连接队列和全连接队列都是在执行 listen 方法时，内核自动创建的，所以客户端没有半连接队列。

但内核还有个全局 hash 表，可以用于存放 sock 连接的信息。

在 TCP 自连接的情况中，客户端在 connect 方法时，最后会将自己的连接信息放入到这个全局 hash 表中，然后将信息发出，消息在经过回环地址重新回到 TCP 传输层的时候，就会根据 IP + 端口信息，再一次从这个全局 hash 中取出信息。于是握手包一来一回，最后成功建立连接。

没有 accept，能建立 TCP 连接吗？

 

 一般情况下，如果启动服务器，会发现最后程序会阻塞在accept()里。

客户端比较简单，创建好socket之后，直接就发起connect方法。

此时回到服务端，会发现之前一直阻塞的accept方法，返回结果了。

就算不执行accept()方法，三次握手照常进行，并顺利建立连接。在服务端执行accept()前，如果客户端发送消息给服务端，服务端是能够正常回复ack确认包的。

 建立连接的过程中根本不需要accept()参与， 执行accept()只是为了从全连接队列里取出一条连接。

为什么半连接队列要设计成哈希表，全连接队列是链表？

全连接里队列，本质是个链表，因为也是线性结构，里面放的都是将要取走的连接，服务端取走连接不需要顺序，直接从队列头取就可以了复杂度为O(1)。

半连接队列，里面都是不完整的连接，等待着第三次握手的到来。那么现在有一个第三次握手来了，则需要从队列里把相应IP端口的连接取出，设计成哈希，时间复杂度就变On。

怎么观察两个队列的大小

#查看全连接队列

ss -lnt

查看半连接队列

SYN_RECV状态的连接 使用

netstat -nt 

cookies方案为什么不直接取代半连接队列？

• 服务端并不会保存连接信息，所以如果传输过程中数据包丢了，也不会重发第二次握手的信息。
• 编码解码cookies，都是比较耗CPU的，

        过构造大量ACK包去消耗服务端资源的攻击，叫ACK攻击，受到攻击的服务器可能会因为CPU资源耗尽导致没能响应正经请求。