[计算机网络] - TCP半连接队列和全连接队列

最新推荐文章于 2024-02-18 17:10:54 发布
最新推荐文章于 2024-02-18 17:10:54 发布
阅读量1.3k 收藏 2
点赞数
分类专栏： 计算机网络
原文链接：https://blog.csdn.net/qq_34827674/article/details/106448326
版权

转载自：https://blog.csdn.net/qq_34827674/article/details/106448326

1. 概念

在 TCP 三次握手的时候，Linux 内核会维护两个队列，分别是：

  • 半连接队列，也称 SYN 队列；
  • 全连接队列，也称 accept 队列；

服务端收到客户端发起的 SYN 请求后，内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK，接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到 accept 队列，等待进程调用 accept 函数时把连接取出来。
在这里插入图片描述
不管是半连接队列还是全连接队列，都有最大长度限制，超过限制时，内核会直接丢弃，或返回 RST 包。

2. TCP 全连接队列溢出

如何知道应用程序的 TCP 全连接队列大小？

在服务端可以使用 ss 命令，来查看 TCP 全连接队列的情况：

但需要注意的是 ss 命令获取的 Recv-Q/Send-Q 在「LISTEN 状态」和「非 LISTEN 状态」所表达的含义是不同的。从下面的内核代码可以看出区别：
在这里插入图片描述
在「LISTEN 状态」时，Recv-Q/Send-Q 表示的含义如下：
在这里插入图片描述

  • Recv-Q：当前全连接队列的大小，也就是当前已完成三次握手并等待服务端 accept() 的 TCP 连接；
  • Send-Q：当前全连接最大队列长度，上面的输出结果说明监听 8088 端口的 TCP 服务，最大全连接长度为 128；

在「非 LISTEN 状态」时，Recv-Q/Send-Q 表示的含义如下：
在这里插入图片描述

  • Recv-Q：已收到但未被应用进程读取的字节数；
  • Send-Q：已发送但未收到确认的字节数；

当超过了 TCP 最大全连接队列，服务端则会丢掉后续进来的 TCP 连接，丢掉的 TCP 连接的个数会被统计起来，我们可以使用 netstat -s 命令来查看：
在这里插入图片描述
上面看到的 41150 times ，表示全连接队列溢出的次数，注意这个是累计值。可以隔几秒钟执行下，如果这个数字一直在增加的话肯定全连接队列满了。

当服务端并发处理大量请求时，如果 TCP 全连接队列过小，就容易溢出。发生 TCP 全连接队溢出的时候，后续的请求就会被丢弃，这样就会出现服务端请求数量上不去的现象。

在这里插入图片描述
实际上，丢弃连接只是 Linux 的默认行为，我们还可以选择向客户端发送 RST 复位报文，告诉客户端连接已经建立失败。
在这里插入图片描述
tcp_abort_on_overflow共有两个值分别是 0 和 1，其分别表示：

  • 0 ：如果全连接队列满了，那么 server 扔掉 client 发过来的 ack ；
  • 1 ：如果全连接队列满了，server 发送一个 reset 包给 client，表示废掉这个握手过程和这个连接；

如果要想知道客户端连接不上服务端，是不是服务端 TCP 全连接队列满的原因，那么可以把 tcp_abort_on_overflow 设置为 1，这时如果在客户端异常中可以看到很多 connection reset by peer 的错误，那么就可以证明是由于服务端 TCP 全连接队列溢出的问题。

通常情况下，应当把 tcp_abort_on_overflow 设置为 0，因为这样更有利于应对突发流量。

举个例子，当 TCP 全连接队列满导致服务器丢掉了 ACK，与此同时，客户端的连接状态却是 ESTABLISHED，进程就在建立好的连接上发送请求。只要服务器没有为请求回复 ACK，请求就会被多次重发。如果服务器上的进程只是短暂的繁忙造成 accept 队列满，那么当 TCP 全连接队列有空位时，再次接收到的请求报文由于含有 ACK，仍然会触发服务器端成功建立连接。

所以，tcp_abort_on_overflow 设为 0 可以提高连接建立的成功率，只有你非常肯定 TCP 全连接队列会长期溢出时，才能设置为 1 以尽快通知客户端。

2.1 增大 TCP 全连接队列

当发现 TCP 全连接队列发生溢出的时候，我们就需要增大该队列的大小。

TCP 全连接队列的最大值取决于 somaxconn 和 backlog 之间的最小值，也就是 min(somaxconn, backlog)。从下面的 Linux 内核代码可以得知：
在这里插入图片描述

  • somaxconn 是 Linux 内核的参数，默认值是 128，可以通过 /proc/sys/net/core/somaxconn 来设置其值；
    在这里插入图片描述
  • backlog 是 listen(int sockfd, int backlog) 函数中的 backlog 大小，Nginx 默认值是 511，可以通过修改配置文件设置其长度；
    在这里插入图片描述
    如果持续不断地有连接因为 TCP 全连接队列溢出被丢弃，就应该调大 backlog 以及 somaxconn 参数。

3. TCP 半连接队列溢出

很遗憾，TCP 半连接队列长度的长度，没有像全连接队列那样可以用 ss 命令查看。

但是我们可以抓住 TCP 半连接的特点，就是服务端处于 SYN_RECV 状态的 TCP 连接，就是在 TCP 半连接队列。

于是，我们可以使用如下命令计算当前 TCP 半连接队列长度：
在这里插入图片描述
可以通过 netstat -s 观察半连接队列溢出的情况:
在这里插入图片描述
上面输出的数值是累计值，表示共有多少个 TCP 连接因为半连接队列溢出而被丢弃。隔几秒执行几次，如果有上升的趋势，说明当前存在半连接队列溢出的现象。

3.1 TCP 半连接队列的最大值

TCP 第一次握手（收到 SYN 包）的 Linux 内核代码如下，其中缩减了大量的代码，只需要重点关注 TCP 半连接队列溢出的处理逻辑：
在这里插入图片描述
从源码中，我可以得出共有三个条件会使得连接因队列长度的关系而被丢弃：

  1. 如果半连接队列满了，并且没有开启 tcp_syncookies，则会丢弃；
  2. 若全连接队列满了，且没有重传 SYN+ACK 包的连接请求多于 1 个，则会丢弃；
  3. 如果没有开启 tcp_syncookies，并且 max_syn_backlog 减去 当前半连接队列长度小于 (max_syn_backlog >> 2)，则会丢弃；

接下来，我们继续跟一下检测半连接队列是否满的函数 inet_csk_reqsk_queue_is_full 和 检测全连接队列是否满的函数 sk_acceptq_is_full ：
在这里插入图片描述
从上面源码，可以得知：

  • 全连接队列的最大值是 sk_max_ack_backlog 变量，sk_max_ack_backlog 实际上是在 listen() 源码里指定的，也就是 min(somaxconn, backlog)；
  • 半连接队列的最大值是 max_qlen_log 变量，max_qlen_log 是在哪指定的呢？现在暂时还不知道，我们继续跟进；

我们继续跟进代码，看一下是哪里初始化了半连接队列的最大值 max_qlen_log：
在这里插入图片描述
从上面的代码中，我们可以算出 max_qlen_log 是 8，于是代入到 检测半连接队列是否满的函数 reqsk_queue_is_full ：
在这里插入图片描述
也就是 qlen >> 8 什么时候为 1 就代表半连接队列满了。这计算这不难，很明显是当 qlen 为 256 时，256 >> 8 = 1。

至此，总算知道为什么上面模拟测试 SYN 攻击的时候，服务端处于 SYN_RECV 连接最大只有 256 个。

可见，半连接队列最大值不是单单由 max_syn_backlog 决定，还跟 somaxconn 和 backlog 有关系。

在 Linux 2.6.32 内核版本，它们之间的关系，总体可以概况为：

  • 当 max_syn_backlog > min(somaxconn, backlog) 时， 半连接队列最大值 max_qlen_log = min(somaxconn, backlog) * 2;
  • 当 max_syn_backlog < min(somaxconn, backlog) 时， 半连接队列最大值 max_qlen_log = max_syn_backlog * 2;

半连接队列最大值 max_qlen_log 就表示服务端处于 SYN_REVC 状态的最大个数吗？

并不是。max_qlen_log 是理论半连接队列最大值，并不一定代表服务端处于 SYN_REVC 状态的最大个数。

在前面我们在分析 TCP 第一次握手（收到 SYN 包）时会被丢弃的三种条件：

  1. 如果半连接队列满了，并且没有开启 tcp_syncookies，则会丢弃；
  2. 若全连接队列满了，且保存在 SYN queue 中未进行 SYN,ACK 重传的连接超过 1 个，则会丢弃；
  3. 如果没有开启 tcp_syncookies，并且 max_syn_backlog 减去 当前半连接队列长度小于 (max_syn_backlog >> 2)，则会丢弃；

假设条件 1 当前半连接队列的长度 「没有超过」理论的半连接队列最大值 max_qlen_log，那么如果条件 3 成立，则依然会丢弃 SYN 包，也就会使得服务端处于 SYN_REVC 状态的最大个数不会是理论值 max_qlen_log。

所以，服务端处于 SYN_RECV 状态的最大个数分为如下两种情况：

  • 如果「当前半连接队列」没超过「理论半连接队列最大值」，但是超过 max_syn_backlog - (max_syn_backlog >> 2)，那么处于 SYN_RECV 状态的最大个数就是 max_syn_backlog - (max_syn_backlog >> 2)；
  • 如果「当前半连接队列」超过「理论半连接队列最大值」，那么处于 SYN_RECV 状态的最大个数就是「理论半连接队列最大值」；

每个 Linux 内核版本「理论」半连接最大值计算方式会不同。

在上面我们是针对 Linux 2.6.32 版本分析的「理论」半连接最大值的算法，可能每个版本有些不同。

比如在 Linux 5.0.0 的时候，「理论」半连接最大值就是全连接队列最大值，但依然还是有队列溢出的三个条件：

在这里插入图片描述

如果 SYN 半连接队列已满，只能丢弃连接吗？

并不是这样，开启 syncookies 功能就可以在不使用 SYN 半连接队列的情况下成功建立连接，在前面我们源码分析也可以看到这点，当开启了 syncookies 功能就不会丢弃连接。

syncookies 是这么做的：服务器根据当前状态计算出一个值，放在己方发出的 SYN+ACK 报文中发出，当客户端返回 ACK 报文时，取出该值验证，如果合法，就认为连接建立成功，如下图所示。
在这里插入图片描述
syncookies 参数主要有以下三个值：

  • 0 值，表示关闭该功能；
  • 1 值，表示仅当 SYN 半连接队列放不下时，再启用它；
  • 2 值，表示无条件开启功能；

那么在应对 SYN 攻击时，只需要设置为 1 即可：
在这里插入图片描述

3.1.1 防御 SYN 攻击

这里给出几种防御 SYN 攻击的方法：

  • 增大半连接队列；
  • 开启 tcp_syncookies 功能
  • 减少 SYN+ACK 重传次数
3.1.1.1 增大半连接队列

要想增大半连接队列，不能只单纯增大 tcp_max_syn_backlog 的值，还需一同增大 somaxconn 和 backlog，也就是增大全连接队列。否则，只单纯增大 tcp_max_syn_backlog 是无效的。

增大 tcp_max_syn_backlog 和 somaxconn 的方法是修改 Linux 内核参数：
在这里插入图片描述
增大 backlog 的方式，每个 Web 服务都不同，比如 Nginx 增大 backlog 的方法如下：
在这里插入图片描述
最后，改变了如上这些参数后，要重启 Nginx 服务，因为半连接队列和全连接队列都是在 listen() 初始化的。

3.1.1.2 开启 tcp_syncookies 功能

开启 tcp_syncookies 功能的方式也很简单，修改 Linux 内核参数：
在这里插入图片描述

3.1.1.3 减少 SYN+ACK 重传次数

当服务端受到 SYN 攻击时，就会有大量处于 SYN_REVC 状态的 TCP 连接，处于这个状态的 TCP 会重传 SYN+ACK ，当重传超过次数达到上限后，就会断开连接。

那么针对 SYN 攻击的场景，我们可以减少 SYN+ACK 的重传次数，以加快处于 SYN_REVC 状态的 TCP 连接断开。
在这里插入图片描述

附录：
部分TCP源码(Linux v2.6.32)：

// net/core/request_sock.h
/** struct listen_sock - listen state
 *
 * @max_qlen_log - log_2 of maximal queued SYNs/REQUESTs
 */
struct listen_sock {
	u8			max_qlen_log;
	/* 3 bytes hole, try to use */
	int			qlen;
	int			qlen_young;
	int			clock_hand;
	u32			hash_rnd;
	u32			nr_table_entries;
	struct request_sock	*syn_table[0];
};

//--------------------------------------------------------------------------------------------

// net/core/request_sock.c
/*
 * Maximum number of SYN_RECV sockets in queue per LISTEN socket.
 * One SYN_RECV socket costs about 80bytes on a 32bit machine.
 * It would be better to replace it with a global counter for all sockets
 * but then some measure against one socket starving all other sockets
 * would be needed.
 *
 * It was 128 by default. Experiments with real servers show, that
 * it is absolutely not enough even at 100conn/sec. 256 cures most
 * of problems. This value is adjusted to 128 for very small machines
 * (<=32Mb of memory) and to 1024 on normal or better ones (>=256Mb).
 * Note : Dont forget somaxconn that may limit backlog too.
 */
int sysctl_max_syn_backlog = 256;

//--------------------------------------------------------------------------------------------

// net/ipv4/tcp_ipv4.c
int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
{
	struct inet_request_sock *ireq;
	struct tcp_options_received tmp_opt;
	struct request_sock *req;
	__be32 saddr = ip_hdr(skb)->saddr;
	__be32 daddr = ip_hdr(skb)->daddr;
	__u32 isn = TCP_SKB_CB(skb)->when;
	struct dst_entry *dst = NULL;
#ifdef CONFIG_SYN_COOKIES
	int want_cookie = 0;
#else
#define want_cookie 0 /* Argh, why doesn't gcc optimize this :( */
#endif

	/* Never answer to SYNs send to broadcast or multicast */
	if (skb_rtable(skb)->rt_flags & (RTCF_BROADCAST | RTCF_MULTICAST))
		goto drop;

	/* TW buckets are converted to open requests without
	 * limitations, they conserve resources and peer is
	 * evidently real one.
	 */
	// 判定 SYN queue 是否已满
	if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
#ifdef CONFIG_SYN_COOKIES
  // SYN queue 已满，并且设置了 net.ipv4.tcp_syncookies = 1 ，则设置 want_cookie = 1 以便后续处理
		if (sysctl_tcp_syncookies) {
			want_cookie = 1;
		} else
#endif
         // 否则，直接丢弃当前 SYN 包
		goto drop;
	}

	/* Accept backlog is full. If we have already queued enough
	 * of warm entries in syn queue, drop request. It is better than
	 * clogging syn queue with openreqs with exponentially increasing
	 * timeout.
	 */
	// 若此时 accept queue 也已满，并且 qlen_young 的值大于 1（即保存在 SYN queue 中未进行 SYN,ACK 重传的连接超过 1 个）
	// 则直接丢弃当前 SYN 包（相当于针对 SYN 进行了速率限制）
	if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1)
		goto drop;

	req = inet_reqsk_alloc(&tcp_request_sock_ops);
	if (!req)
		goto drop;

#ifdef CONFIG_TCP_MD5SIG
	tcp_rsk(req)->af_specific = &tcp_request_sock_ipv4_ops;
#endif

	tcp_clear_options(&tmp_opt);
	tmp_opt.mss_clamp = 536;
	tmp_opt.user_mss  = tcp_sk(sk)->rx_opt.user_mss;

	tcp_parse_options(skb, &tmp_opt, 0);

	if (want_cookie && !tmp_opt.saw_tstamp)
		tcp_clear_options(&tmp_opt);

	tmp_opt.tstamp_ok = tmp_opt.saw_tstamp;

	tcp_openreq_init(req, &tmp_opt, skb);

	ireq = inet_rsk(req);
	ireq->loc_addr = daddr;
	ireq->rmt_addr = saddr;
	ireq->no_srccheck = inet_sk(sk)->transparent;
	ireq->opt = tcp_v4_save_options(sk, skb);

	if (security_inet_conn_request(sk, skb, req))
		goto drop_and_free;

	if (!want_cookie)
		TCP_ECN_create_request(req, tcp_hdr(skb));

    // 若 accept queue 未满，或者 qlen_young 的值未大于 1
	if (want_cookie) {
#ifdef CONFIG_SYN_COOKIES
		syn_flood_warning(skb); // 输出 "possible SYN flooding on port %d. Sending cookies.\n"
		req->cookie_ts = tmp_opt.tstamp_ok; // 为当前 socket 设置启用 cookie 标识
#endif
        // 生成 syncookie
		isn = cookie_v4_init_sequence(sk, skb, &req->mss);
	} else if (!isn) {
		struct inet_peer *peer = NULL;

		/* VJ's idea. We save last timestamp seen
		 * from the destination in peer table, when entering
		 * state TIME-WAIT, and check against it before
		 * accepting new connection request.
		 *
		 * If "isn" is not zero, this request hit alive
		 * timewait bucket, so that all the necessary checks
		 * are made in the function processing timewait state.
		 */
		if (tmp_opt.saw_tstamp &&
		    tcp_death_row.sysctl_tw_recycle &&
		    (dst = inet_csk_route_req(sk, req)) != NULL &&
		    (peer = rt_get_peer((struct rtable *)dst)) != NULL &&
		    peer->v4daddr == saddr) {
			if (get_seconds() < peer->tcp_ts_stamp + TCP_PAWS_MSL &&
			    (s32)(peer->tcp_ts - req->ts_recent) >
							TCP_PAWS_WINDOW) {
				NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSPASSIVEREJECTED);
				goto drop_and_release;
			}
		}
		/* Kill the following clause, if you dislike this way. */
		else if (!sysctl_tcp_syncookies &&
			 (sysctl_max_syn_backlog - inet_csk_reqsk_queue_len(sk) <
			  (sysctl_max_syn_backlog >> 2)) &&
			 (!peer || !peer->tcp_ts_stamp) &&
			 (!dst || !dst_metric(dst, RTAX_RTT))) {
			/* Without syncookies last quarter of
			 * backlog is filled with destinations,
			 * proven to be alive.
			 * It means that we continue to communicate
			 * to destinations, already remembered
			 * to the moment of synflood.
			 */
			LIMIT_NETDEBUG(KERN_DEBUG "TCP: drop open request from %pI4/%u\n",
				       &saddr, ntohs(tcp_hdr(skb)->source));
			goto drop_and_release;
		}

		isn = tcp_v4_init_sequence(skb);
	}
	tcp_rsk(req)->snt_isn = isn;

	if (__tcp_v4_send_synack(sk, req, dst) || want_cookie)
		goto drop_and_free;

	inet_csk_reqsk_queue_hash_add(sk, req, TCP_TIMEOUT_INIT);
	return 0;

drop_and_release:
	dst_release(dst);
drop_and_free:
	reqsk_free(req);
drop:
	return 0;
}
_浮生_
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
计算机网络- tcp的半连接对列和全连接对列
后端学习
09-23 144
1. 全连接对列 1.1 全连接对列的最大长度的决定因素 全连接对列的最大值 = Math.min(somaxconn, backlog) ; somaxconn是内核参数；backlog根据web服务的不同而决定。 1.2 全连接对列的溢出时的处理 内核参数配置：tcp_abort_on_overflow 0：将溢出的连接给直接丢弃 - 默认方式，优点，在面对全连接对列短暂溢出时可以快速恢复连接，客户端会重发syn包；缺点，客户端可能不知道连接是否出现问题。 1：往溢出的连接中，发出一个rst 连接
【计算机网络】TCP全连接队列和半连接队列
最新发布
qq_43009242的博客
02-22 182
在内核中维护了两个队列，全连接队列，半连接队列。他们在下图中表示。可以看到在收到客户端的SYN包之后，就会将这个socket放入半连接队列。在服务端收到最后一个ack的时候，放入全连接队列。
TCP-半连接队列和全连接队列
Java程序员的知识博客
02-18 820
Linux内核就引入半连接队列（用于存放收到SYN，但还没收到ACK的连接）和全连接队列（用于存放已经完成3次握手，但是应用层代码还没有完成 accept() 的连接）两个概念，用于存放在握手中的连接。全连接队列、半连接队列溢出这种问题很容易被忽视，但是又很关键，特别是对于一些短连接应用（比如Nginx、PHP，当然他们也是支持长连接的）更容易爆发。
TCP 半连接队列和全连接队列
weixin_44479862的博客
09-12 1588
在 TCP 三次握手的时候，Linux 内核会维护两个队列，分别是：半连接队列，全连接队列。
TCP半连接队列和全连接队列
peng_shakalaka的博客
11-12 1231
在TCP连接的服务端，linux内核会维护两个队列SYN队列，也成半连接队列accept队列，全连接队列服务端收到客户端发起的 SYN 请求后，内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK，接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到 accept 队列，等待进程调用 accept 函数时把连接取出来。
TCP 半连接队列和全连接队列 420 -452
05-15
在TCP协议中，半连接队列和全连接队列是两个关键的概念，它们在服务器接收和处理客户端连接请求的过程中起到至关重要的作用。TCP半连接队列，也称为SYN队列，是在三次握手过程中，从客户端发出SYN到服务器响应SYN+...
p242- p270 TCP半连接队列和长连接队列
05-15
在TCP/IP网络协议中，半连接队列和全连接队列是两个重要的概念，它们在维护TCP连接状态和处理客户端请求时起到关键作用。这里主要讨论的是TCP半连接队列和全连接队列的原理、观察与管理方法，以及如何处理队列溢出的...
计算机网络教案16-TCP连接管理与拥塞控制机制.docx
12-17
计算机网络教案16-TCP连接管理与拥塞控制机制 本教案的主要内容是TCP连接管理和拥塞控制机制。 TCP连接管理包括连接建立、数据传送和连接释放三个阶段。在连接建立过程中，需要解决三个问题：使每一方能够确知对方...
tcp全连接和半连接问题查询步骤
02-01
这是由于 TCP 的半连接队列和全连接队列的溢出所导致的。在这里，我们将详细介绍 TCP 的半连接队列和全连接队列的知识，并提供解决问题的步骤。 半连接队列和全连接队列 在 TCP 的三次握手过程中，有两个队列：...
计算机网络实验5 - TCP数据包及连接建立过程分析
08-11
"计算机网络实验5 - TCP数据包及连接建立过程分析" 本实验报告的主要目的是学习并分析TCP数据包的结构、含义，并研究TCP连接的建立过程和数据传输过程。实验使用Wireshark网络分析软件和实验文件“计算机网络实验....
TCP半连接队列和全连接队列（史上最全）
架构师尼恩
07-23 3573
backlog的值即为未连接队列和已连接队列的和未完成连接队列(so_q0len)一个SYN已经到达，但三次握手还没有完成的连接中的数量已完成连接队列(so_q1len)三次握手已完成，内核正等待进程执行accept的调用中的数量半连接队列，也叫未完成连接队列，简称为syn队列全连接队列，也叫已完成连接队列，简称为accept队列@Override}else{}}要想搞清楚。......
【tcp】TCP 半连接队列、全连接队列基本概念
michaelwoshi的博客
01-23 6449
TCP 三次握手状态变化 对于客户端： 初始的状态是处于 CLOSED 状态。CLOSED 并不是一个真实的状态，而是一个假想的起点和终点。 客户端调用 connect 以后会发送 SYN 同步报文给服务端，然后进入 SYN-SENT 阶段，客户端将保持这个阶段直到它收到了服务端的确认包。 如果在 SYN-SENT 状态收到了服务端的确认包，它将发送确认服务端 SYN 报文的 ACK 包，同时进入 ESTABLISHED 状态，表明自己已经准备好发送数据。 对于服务端： 初始状态同.
半连接
minwang593的专栏
01-03 2048
这里的半连接指的是广义半连接，即由各种运算符所构成的子查询与主查询之间的连接。尽管子查询的种类有很多，但其都是一种为实现子查询与主查询之间连接的表连接。     实际上，大部分子查询的执行计划都是以表连接的形式出现的，且与一般方式的表连接有所不同。由于表连接其实就是集合运算，从逻辑上看，执行连接的两个集合之间是一种水平关系，不论哪个集合被优先执行都不会对结果产生任何影响。既然这两种集合是水平关系
（三）TCP三次握手和连接队列——网络编程
weixin_43284996的博客
12-01 317
TCP（Transmission Control Protocol）传输控制协议，仅支持单播，向上层提供面向连接的可靠传输服务，适用于要求可靠传输的应用，例如文件传输。
linux查看全连接队列大小,[TimLinux] TCP全连接队列满
weixin_29103603的博客
05-10 642
0. TCP三次握手syns queue: 半连接队列accept queue: 全连接队列控制参数存放在文件：/proc/sys/net/ipv4/tcp_abort_on_overflow中，0：表示如果三次握手第三步的时候全连接队列满了，那么server扔掉client发过来的ack(在server端因为全连接队列满了，认为连接还没有建立起来)，1：表示第三步的时候如果全连接队列满了，ser...
半连接&反连接
hanhan的博客
06-02 2244
半连接&反连接 1. 半连接 半连接返回左表中与右表至少匹配一次的数据行，通常体现为 EXISTS 或者 IN 子查询。左表驱动右表。只返回左表的数据，右表作为筛选条件。 可以用 EXISTS、 IN 或者 =ANY 举例：表t1和表t2做半连接，t1是驱动表，t2是被驱动表，半连接条件为t1.x=t2.y。 这里"t1.x semi= t2.y"的含义是只要在表t2中找到一条记录满足t1.x=t2.y，则马上停止搜索表t2，并直接返回表T1中满足条件t1.x=t2.y的记录。表t2中满足半连接条件
TCP三次握手过程中的半连接和全连接
dinghuiyang的博客
09-13 2630
accept过程： 当server端主动调用accept时，会将该client从半连接状态队列转入到全连接状态队列，并生成该client的fd，此后server通过该fd与client进行会话。之后 如果client不断去重新发出连接请求，最终server端的半连接状态队列将满（大小有listen接口设置），连接状态处于SYN_RECV状态（通过netstat 命令可以看到 Recv-Q已达到连接个数上限和连接状态）对于server端来说，
彻底讲清楚TCP半连接队列和全连接队列
fangyi2011的博客
10-20 2919
TCP半连接队列和全连接队列 1 简单的TCP建连流程 先来张图，如下: (1)client端使用connect()向server端发起连接请求(发送syn包)，此时client端的TCP的状态为SYN_SENT (2)server端在收到SYN包后，将TCP相关信息放到syn queue(半连接队列)中，同时向client发送syn+ack。server端TCP的状态为 SYN_R...
如何正确查看线上半/全连接队列溢出情况？
zhangyanfei01的专栏
08-23 2156
大家好，我是飞哥！在《深入解析常见三次握手异常》 这一文中，我们讨论到如果发生连接队列溢出而丢包的话，会导致连接耗时会上涨很多。那如何判断一台服务器当前是否有半/全连接队列溢出丢包发生呢？...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值