Listen（sockfd,backlog）监听函数的第二个参数到底是什么？深度解释

listen队列剖析

int listen(int sockfd,int backlog)
  
  backlog : 
监听套接字队列
对于一个调用监听的套接字，系统会维护给这个套接字两个队列
1. 未完成连接队列
  //当客户端发生三次握手的第一次syn包给服务器的时候，服务器就会再未完成队列中创建一个跟这个syn包对应的一项
  //可以看成一个半连接，这个半连接的状态从LISTEN变为SYN_RCVD状态，同时给客户端返回第二次握手 SYN,ACK包
  //这个时候服务器端是在等待完成的第三次握手

2.已完成连接队列
  //当第三次握手完成后，，这个连接就变成了ESTABLISHED,每个已经完成三次握手的客户端，都放在这个队列中作为一项（从未完成连接拿走，不是拷贝，是移动）

曾经的backlog：已完成队列和未完成队列的总值不超过backlog

小问题：

（1）问题： 客户端调用connect（）的函数的时候什么时候返回？
 收到三次握手的第二次握手包，也就是服务器端返回的 syn ack 包的时候，这时候半连接建立了返回，经过了客户端的一个RTT

accept函数

accept()函数就使用从已完成连接队列中的队首（队头）取出来一项（已经完成三次握手的TCP连接）返回给进程

如果已完成队列里是空呢，那么accept函数会阻塞等待，一直等到已完成连接队列有一项才会被唤醒

所以从编程的角度，我们要尽快的用accept（）把已完成队列中的取走

accept返回的是一个套接字，这个套接字代表那个已经用三次握手建立起来的TCP连接 也就是通信文件描述符cfd。因为accept是从已完成队列取的数据；
服务器程序，必须严格区分两个套接字：
  监听lfd，服务器程序存在，lfd也就一直存在；
  当客户端连接的进来，操作系统会为每个建立三次握手的客户端再创建一个套接字（cfd）；通信套接字，从已完成连接的队列取出来的

思考题：

（1.）如果已完成未完成队列的和达到了backlog，满了，此时再有客户端发送SYN包请求，服务器什么反应？

实际上服务器会忽略SYN包，不予回应，客户端这边发现没有回应，过一会会重新发送SYN包

（2.）从连接被扔到已完成连接队列的时候，到accept从已完成的队列取出的时候有一个时间差，就是刚来，但是还没被取出，这时候客户端发来数据怎么办

这个数据会保存在已经连接的套接字对应的接收缓冲区里

SYN攻击

匿名地址连续向服务器发送syn包，然后，服务器端并没有发送回ack，也没有收到ack，导致未连接的队列会满掉大于backlog之和，进而导致真正的syn包没有收到

然后backlog又规定了改掉了，是已连接的队列的总值；

尽快需要把已完成的队列里面的连接取走，尽快留出空闲为止给后续已完成三次握手的条目用，那么这个已完成队列一般不会满 backlog300 500左右

backlog深释

参照：https://www.cnblogs.com/yangbodong/p/15344832.html

listen 函数的 backlog 参数在不同的操作系统上可能有不同的实现和含义。一般来说，backlog 参数既涉及到半连接队列（syn queue），也涉及到全连接队列（accept queue）的大小。

半连接队列与全连接队列

1. 半连接队列（SYN Queue）：

• 当一个客户端发送 SYN 包请求与服务器建立连接时，服务器会在半连接队列中创建一个记录（还没有完成三次握手）。

• 半连接队列保存的是那些已经发送了 SYN 包但还没有完成三次握手的连接。

1. 全连接队列（Accept Queue）：

• 当三次握手完成时，连接从半连接队列移到全连接队列。

• 全连接队列保存的是那些已经完成了三次握手等待被应用程序调用 accept 接受的连接。

listen 函数中的 backlog

listen 函数的定义如下：

int listen(int sockfd, int backlog);

• sockfd 是套接字描述符。

• backlog 是请求队列的最大长度。

在许多实现中，backlog 同时限制了半连接队列和全连接队列的大小之和。但具体实现可能会有所不同。例如：

• 在 Linux 中，backlog 指定了全连接队列的大小，而半连接队列的大小由 tcp_max_syn_backlog 系统参数控制。

• 在某些其他操作系统中，backlog 可能限制的是总的连接队列大小（包括半连接和全连接）。

SYN 攻击

SYN 攻击是一种拒绝服务攻击（DoS 攻击），攻击者通过发送大量伪造的 SYN 包使目标服务器的半连接队列充满，从而阻止合法用户建立连接。

SYN 攻击的工作原理：

1. 攻击者发送大量伪造源地址的 SYN 包到目标服务器。

2. 服务器收到 SYN 包后，为每个连接分配资源并发送 SYN-ACK 包。

3. 由于源地址是伪造的，攻击者不会响应 SYN-ACK 包，导致这些连接一直停留在半连接队列中。

4. 半连接队列充满后，服务器无法再处理新的连接请求，导致合法用户无法连接到服务器。

防御 SYN 攻击的方法：

1. 缩短 SYN-ACK 重传次数和超时时间：

• 减少服务器等待 SYN-ACK 确认的时间，可以加快清理无效连接的速度。

• 例如，在 Linux 中可以通过调整 tcp_synack_retries 系统参数来实现。

1. 增加半连接队列的大小：

• 增大 tcp_max_syn_backlog 参数可以增加半连接队列的大小，使其能够承受更多的半连接。

1. SYN Cookies：

• SYN Cookies 是一种不依赖于半连接队列的防御机制。服务器在 SYN 包中嵌入一个加密的序列号，客户端返回的 ACK 包中包含这个序列号，服务器通过验证这个序列号来确认连接是否有效。

• 启用 SYN Cookies 可以在半连接队列满时继续处理新连接。

1. 防火墙和过滤：

• 使用防火墙或入侵检测系统（IDS）来过滤掉明显的 SYN 洪泛攻击流量。

通过这些方法，服务器可以增强对 SYN 攻击的防御能力，从而保障服务的可用性。