linux内核协议栈 TCP选项之MSS

目录

1 MSS概述

2 客户端三次握手

2.1 发送SYN段MSS选项值

2.1.1 tcp_advertise_mss()

2.1.2 tp->advmss的初始化

2.2 接收SYN+ACK段

3 服务器端三次握手

3.1 接收SYN段

3.2 接收 ACK 报文

3.2.1 初始化 advmss

扫描二维码关注公众号,回复: 11907536 查看本文章

3.3 发送SYN+ACK段

4 三次握手小结

5 发送过程中获取MSS

5.1 tcp_current_mss()

5.2 tcp_sync_mss()

5.2.1 tcp_mtu_to_mss()

6 小结


1 MSS概述

MSS(Maximum Segment Size,最大报文段大小)的概念是指TCP层所能够接收的最大段大小,该值只包括TCP段的数据部分,不包括选项部分。

另外,在TCP首部有一个MSS选项,在三次握手过程中,TCP发送端使用该选项告诉对方自己所能接受的最大段大小,该选项值仅会出现SYN报文段中即三次握手的前两次

MSS选项虽然作为一个选项存在,原则上讲是可有可无的,但是目前绝大多数的TCP通信过程中都会携带该选项,所以可以说它是TCP中最重要的一个选项了。

关于MSS的内容,主要包括两个方面:

  1. SYN段和SYN+ACK段中携带的MSS选项是如何确定的(有些资料中会提到的RMSS,即接收MSS)?
  2. 连接建立后的发包过程中,MSS是如何发挥作用的(有些资料中会提到的SMSS,即发送MSS)?

从客户端和服务器端的三次握手过程中可以看到RMSS是如何确定的。从连接态的数据发送过程可以看到SMSS是如何发乎作用的。

2 客户端三次握手

客户端处理MSS的机会为:

  1. 发送SYN段时告诉服务器端本端能够接收的MSS;
  2. 收到SYN+ACK后接收服务器端通告的MSS。

2.1 发送SYN段MSS选项值

SYN段也是通过tcp_transmit_skb()发送的,在该函数中会调用tcp_syn_build_options()构造SYN段携带的选项,代码如下:

static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
			    gfp_t gfp_mask)
{
...
	//如果发送的是SYN段,则调用tcp_syn_build_options()构造要携带的TCP选项,其中
	//MSS选项的值就是tcp_advertise_mss()的返回值
	if (unlikely(tcb->flags & TCPCB_FLAG_SYN)) {
		tcp_syn_build_options((__be32 *)(th + 1),
				      tcp_advertise_mss(sk),
				      (sysctl_flags & SYSCTL_FLAG_TSTAMPS),
				      (sysctl_flags & SYSCTL_FLAG_SACK),
				      (sysctl_flags & SYSCTL_FLAG_WSCALE),
				      tp->rx_opt.rcv_wscale,
				      tcb->when,
				      tp->rx_opt.ts_recent,
#ifdef CONFIG_TCP_MD5SIG
				      md5 ? &md5_hash_location :
#endif
				      NULL);
	}
...
}

2.1.1 tcp_advertise_mss()

advertise为广告的意思,该函数用来计算要告诉对端的MSS值,对应到TCB中,其实就是根据本端设备的MTU计算tp->advmss的值。

static __u16 tcp_advertise_mss(struct sock *sk)
{
	struct tcp_sock *tp = tcp_sk(sk);
	//获取路由
	struct dst_entry *dst = __sk_dst_get(sk);
	//用tp->advmss初始化临时变量mss
	int mss = tp->advmss;

	//如果路由有效并且路由中的MSS比当前值小,那么用路由中的MSS更新tp->advmss
	//因为路由中的MSS是根据网络设备的MTU得来的,必须尊重,可以认为路由中的MSS
	//取值为min(65536-40, MTU-40),其中65535为IP报文的最大长度
	if (dst && dst_metric(dst, RTAX_ADVMSS) < mss) {
		mss = dst_metric(dst, RTAX_ADVMSS);
		tp->advmss = mss;
	}
	//返回确定的mss
	return (__u16)mss;
}

从上面可以看出,tcp_advertise_mss()实际上就是取当前tp->advmss和路由表MSS二者中的最小值,而后者就是本地网卡的MTU-40,下面需要继续看下tp->advmss的初始值的如何确定的。

2.1.2 tp->advmss的初始化

搜索代码可以发现,该字段的初始化是在tcp_connect_init()中完成的,该函数被tcp_connect()调用,也就是说该值的初始化是在SYN段的发送过程中进行的,代码如下:

static void tcp_connect_init(struct sock *sk)
{
...
	//即也是来源于本端MTU
	tp->advmss = dst_metric(dst, RTAX_ADVMSS);
...
}

小结一下:SYN段中携带的MSS选项值实际上就是本端网络设备的MTU-40。

2.2 接收SYN+ACK段

接收SYN+ACK段是在tcp_rcv_synsent_state_process()中处理的,其中会调用tcp_paser_option()解析SYN段中携带的选项,其中和MSS选项相关的代码如下:

void tcp_parse_options(struct sk_buff *skb, struct tcp_options_received *opt_rx,
		       int estab)
{
...
	switch (opcode) {
	case TCPOPT_MSS:
		if (opsize == TCPOLEN_MSS && th->syn && !estab) {
			//取得选项中携带的MSS值记录到临时变量in_mss中
			u16 in_mss = ntohs(get_unaligned((__be16 *)ptr));
			if (in_mss) {
				//user_mss是应用程序通过TCP选项TCP_MAXSEG设定的,如果不设置,默认为0;
				//如果设定了user_mss并且设定的值小于对端通告的,那么调整in_mss为两者中的最小值。
				if (opt_rx->user_mss &&
					opt_rx->user_mss < in_mss)
					in_mss = opt_rx->user_mss;
				//将min(user_mss, in_mss)记录到mss_clamp中
				opt_rx->mss_clamp = in_mss;
			}
		}
		break;
	}
	...
}

小结一下:客户端在收到服务器端通告的MSS后,将其与应用程序通过TCP_MAXSEG设定的MSS值比较,将二者中的较小值保存在tp->rx_opt.mss_clamp中,该值会影响到客户端发送MSS的确定,见下文。

3 服务器端三次握手

服务器端处理MSS的机会为:

  1. 收到SYN段后对客户端通告的MSS的处理;
  2. 发送SYN+ACK时携带的MSS选项值的确定;

3.1 接收SYN段

SYN段的核心处理在tcp_v4_conn_request()中完成的,其中和MSS选项解析相关的内容如下:

int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
{
...
	//将SYN段中携带的选项先解析到临时变量tmp_opt中
	struct tcp_options_received tmp_opt;
	struct request_sock *req;
...

	//先清空临时变量
	tcp_clear_options(&tmp_opt);
	//将临时变量中的mss_clamp初始化为536
	tmp_opt.mss_clamp = 536;
	//user_mss设置为用户通过套接字选项TCP_MAXSEG设定的值
	tmp_opt.user_mss  = tcp_sk(sk)->rx_opt.user_mss;
	//该函数上面已经见过,它会比较SYN段中携带的MSS和user_mss,
	//然后取二者中较小者保存在tmp_opt.mss_clamp中
	tcp_parse_options(skb, &tmp_opt, 0);
...
	//初始化连接请求块
	tcp_openreq_init(req, &tmp_opt, skb);
...
}

static inline void tcp_openreq_init(struct request_sock *req,
				    struct tcp_options_received *rx_opt,
				    struct sk_buff *skb)
{
...
	//最终确定下来的MSS记录到了连接请求块的mss字段中
	req->mss = rx_opt->mss_clamp;
...
}

3.2 接收 ACK 报文

记录到req中的mss,在三次握手完成后,即受到客户端的ACK报文,服务器会创建子套接字的TCB时会赋值给tp->rx_opt.mss_clamp,代码如下:

struct sock *tcp_create_openreq_child(struct sock *sk, struct request_sock *req, struct sk_buff *skb)
{
...
	newtp->rx_opt.mss_clamp = req->mss;
...
}

小结一下:从代码上看,其实服务器端接收到SYN后,对MSS选项的处理流程与客户端收到SYN+ACK段后对MSS选项的处理流程是相同的。

3.2.1 初始化 advmss

在上面,我们并没有看到服务器端对tp->advmss的初始化,实际上,这个过程是在收到握手的第三个ACK报文后执行的,代码如下:

struct sock *tcp_v4_syn_recv_sock(struct sock *sk, struct sk_buff *skb,
				  struct request_sock *req,
				  struct dst_entry *dst)
{
...
	//取值就是路由中的MSS值
	newtp->advmss = dst_metric(dst, RTAX_ADVMSS);
...
}

3.3 发送SYN+ACK段

SYN+ACK段的发送过程主要由tcp_v4_send_synack()完成,其中和MSS选项相关的内容如下:

static int tcp_v4_send_synack(struct sock *sk, struct request_sock *req,
			      struct dst_entry *dst)
{
...
	//创建SYN+ACK段
	skb = tcp_make_synack(sk, dst, req);
...
}

struct sk_buff *tcp_make_synack(struct sock *sk, struct dst_entry *dst,
				struct request_sock *req)
{
...
	//为SYN+ACK段构造TCP选项,第二个参数就是要发送给客户端的MSS,来自于路由
	tcp_syn_build_options((__be32 *)(th + 1), dst_metric(dst, RTAX_ADVMSS), ireq->tstamp_ok,
			      ireq->sack_ok, ireq->wscale_ok, ireq->rcv_wscale,
			      TCP_SKB_CB(skb)->when,
			      req->ts_recent,
			      (
#ifdef CONFIG_TCP_MD5SIG
			       md5 ? &md5_hash_location :
#endif
			       NULL)
			      );
...
}

小结一下:从代码上看,其实服务器端发送SYN+ACK段时,对MSS选项的处理流程与客户端发送SYN段时对MSS选项的处理流程是相同的。

4 三次握手小结

从前面的代码中可以看到,无论是服务器端还是客户端,它们对通告给对端的MSS值的选择方式是一样的,都是取自本地网卡的MTU-40,该值会被记录在tp->advmss中;收到对端通告的MSS后,和应用程序设定的tp->rx_opt.user_mss比较后,取二者中的较小者保存在tp->rx_opt.mss_clamp中,mss_clamp会影响发送过程中发送MSS的选择。

5 发送过程中获取MSS

TCP数据发送之tcp_sendmsg()中有看到,tcp_sendmsg()的核心逻辑就是根据MSS将待发送数据切割成一个个的skb,过程中是通过调用tcp_current_mss()确定当前的发送MSS的。这篇笔记前面有提到,对端通告的MSS经过矫正后最终保存在了tp->rx_opt.mss_clamp中,按道理我们使用该值作为发送MSS就很好啊,然而并非如此简单,如下:

int tcp_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg,
		size_t size)
{
...
	//获取当前有效的MSS,如果没有带外数据,就可以使用更大的段(TSO相关)
	mss_now = tcp_current_mss(sk, !(flags&MSG_OOB));
	size_goal = tp->xmit_size_goal;
...
}

5.1 tcp_current_mss()

该接口用于获取当前有效的MSS,并且会根据MTU的大小设定tp->xmit_size_goal变量,该变量后续将用于组织skb,它的取值和TSO、GSO等特性相关,不是这篇笔记要讨论的话题,先忽略。

/* Compute the current effective MSS, taking SACKs and IP options,
 * and even PMTU discovery events into account.
 *
 * LARGESEND note: !urg_mode is overkill, only frames up to snd_up
 * cannot be large. However, taking into account rare use of URG, this
 * is not a big flaw.
 */
unsigned int tcp_current_mss(struct sock *sk, int large_allowed)
{
	struct tcp_sock *tp = tcp_sk(sk);
	struct dst_entry *dst = __sk_dst_get(sk);
	//下面最终决策出的当前有效发送MSS值会记录到该变量中
	u32 mss_now;
	u16 xmit_size_goal;
	int doing_tso = 0;

	//mss_now来自于tp->mss_cache,一脸懵逼,到目前为止还没见过该字段(见下文)
	mss_now = tp->mss_cache;

	//判断是否允许TSO,忽略
	if (large_allowed && sk_can_gso(sk) && !tp->urg_mode)
		doing_tso = 1;

	if (dst) {
		//获取路由中保存的PMTU值
		u32 mtu = dst_mtu(dst);
		//icsk_pmut_cookie为上次缓存的PMTU值,其初始值为本端MTU大小,
		//如果二者不等,则说明PMTU发生了变化,需要调用tcp_sync_mss()更新MSS
		if (mtu != inet_csk(sk)->icsk_pmtu_cookie)
			mss_now = tcp_sync_mss(sk, mtu);
	}
	//如果TCP有SACK选项,则从MSS中减去相应的开销
	if (tp->rx_opt.eff_sacks)
		mss_now -= (TCPOLEN_SACK_BASE_ALIGNED + (tp->rx_opt.eff_sacks * TCPOLEN_SACK_PERBLOCK));

#ifdef CONFIG_TCP_MD5SIG
	if (tp->af_specific->md5_lookup(sk, sk))
		mss_now -= TCPOLEN_MD5SIG_ALIGNED;
#endif

	//下面的代码用来确定xmit_size_goal的值,该值和TSO相关,先忽略
	xmit_size_goal = mss_now;
	if (doing_tso) {
		xmit_size_goal = (65535 -
				  inet_csk(sk)->icsk_af_ops->net_header_len -
				  inet_csk(sk)->icsk_ext_hdr_len -
				  tp->tcp_header_len);

		xmit_size_goal = tcp_bound_to_half_wnd(tp, xmit_size_goal);
		xmit_size_goal -= (xmit_size_goal % mss_now);
	}
	tp->xmit_size_goal = xmit_size_goal;
	//返回当前有效的MSS值
	return mss_now;
}

5.2 tcp_sync_mss()

该函数用参数pmtu更新PMTU相关字段,其中icsk->icsk_pmtu_cookie保存的就是之前缓存的PMTU值,根据该PMTU值计算MSS后,将计算结果保存到tp->mss_cache中,该值就是当前最新的MSS值。

/* This function synchronize snd mss to current pmtu/exthdr set.

   tp->rx_opt.user_mss is mss set by user by TCP_MAXSEG. It does NOT counts
   for TCP options, but includes only bare TCP header.

   tp->rx_opt.mss_clamp is mss negotiated at connection setup.
   It is minimum of user_mss and mss received with SYN.
   It also does not include TCP options.

   inet_csk(sk)->icsk_pmtu_cookie is last pmtu, seen by this function.

   tp->mss_cache is current effective sending mss, including
   all tcp options except for SACKs. It is evaluated,
   taking into account current pmtu, but never exceeds
   tp->rx_opt.mss_clamp.

   NOTE1. rfc1122 clearly states that advertised MSS
   DOES NOT include either tcp or ip options.

   NOTE2. inet_csk(sk)->icsk_pmtu_cookie and tp->mss_cache
   are READ ONLY outside this function.		--ANK (980731)
 */
//注释很重要,仔细看
unsigned int tcp_sync_mss(struct sock *sk, u32 pmtu)
{
	struct tcp_sock *tp = tcp_sk(sk);
	struct inet_connection_sock *icsk = inet_csk(sk);
	int mss_now;

	if (icsk->icsk_mtup.search_high > pmtu)
		icsk->icsk_mtup.search_high = pmtu;
	//根据PMTU值计算MSS,这里除了标准的IP、TCP首部外,还会考虑IP选项、TCP选项
	mss_now = tcp_mtu_to_mss(sk, pmtu);
	//调整MSS为当前发送窗口的一半
	mss_now = tcp_bound_to_half_wnd(tp, mss_now);

	/* And store cached results */
	//将PMTU缓存到icsk_pmtu_cookie中
	icsk->icsk_pmtu_cookie = pmtu;
	if (icsk->icsk_mtup.enabled)
		mss_now = min(mss_now, tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_low));
	//最终决策出来的MSS保存在mss_cache中
	tp->mss_cache = mss_now;

	return mss_now;
}

注:上面有几个和PMTU机制强相关的几个字段还没有弄清楚,弄清楚后回来补充…

5.2.1 tcp_mtu_to_mss()

该函数将MTU转变为MSS值,会考虑IP选项、TCP选项。

/* Not accounting for SACKs here. */
int tcp_mtu_to_mss(struct sock *sk, int pmtu)
{
	struct tcp_sock *tp = tcp_sk(sk);
	struct inet_connection_sock *icsk = inet_csk(sk);
	int mss_now;

	/* Calculate base mss without TCP options:
	   It is MMS_S - sizeof(tcphdr) of rfc1122
	 */
	//从MTU中减去标准TCP首部、IP首部
	mss_now = pmtu - icsk->icsk_af_ops->net_header_len - sizeof(struct tcphdr);

	/* Clamp it (mss_clamp does not include tcp options) */
	//MSS不能超过对端通告的MSS
	if (mss_now > tp->rx_opt.mss_clamp)
		mss_now = tp->rx_opt.mss_clamp;

	/* Now subtract optional transport overhead */
	//减去扩展首部,启用IPsec时,会有扩展首部
	mss_now -= icsk->icsk_ext_hdr_len;

	/* Then reserve room for full set of TCP options and 8 bytes of data */
	//MSS最小不能小于48字节
	if (mss_now < 48)
		mss_now = 48;

	/* Now subtract TCP options size, not including SACKs */
	//减去TCP选项长度(不包括选择ACK选项),tp->tcp_header_len的值是该TCP连接中可能的最大TCP
	//首部长度,该值是在三次握手过程中根据双方对TCP选项的支持情况确定的
	mss_now -= tp->tcp_header_len - sizeof(struct tcphdr);

	return mss_now;
}

小结一下:实际上在三次握手过程中,TCP会多次调用tcp_sync_mss()更新MSS值,不过其原理相同,无非是根据设备MTU或者当前最新的PMTU更新,这里不再一一列举。

6 小结

正如开头所说,MSS相关内容可以分为发送MSS和接收MSS两部分,上面详细分析了这两种MSS在代码中的相关处理逻辑,这里用一张图来表示它们之间的关系:
在这里插入图片描述
图30-9是发送MSS的更新规则。PMTU会更新到路由metrics[RTAX_MTU]中,每次发送操作时,都会重新检查是否需要更新发送MSS,此时会首先检查路由中的MSS和icsk_pmtu_cookie中缓存的上一次PMTU值,如果二者不等,说明两次发送期间MTU发生了变化,这时会用路由MSS更新icsk_pmtu_cookie。然后决定最终的发送MSS时也会参考三次握手过程中协商的值mss_clamp,保证最终值不会超过该值,而mss_clamp又受限于TCP选项TCP_MAXSEG。

图30-10是通告MSS的确定规则。非常直接,就是来自于网络设备的MTU。

猜你喜欢

转载自blog.csdn.net/wangquan1992/article/details/109028964
今日推荐