TCP选项之MSS_tcp mss

1. 概述

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

另外，在TCP首部有一个MSS选项，在三次握手过程中，TCP发送端使用该选项告诉对方自己所能接受的最大段大小。

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);
	}
...
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

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;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

从上面可以看出，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);
...
}
1
2
3
4
5
6
7

小结一下：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;
	}
	...
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

小结一下：客户端在收到服务器端通告的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;
...
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

记录到req中的mss，在三次握手完成后，创建子套接字的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;
...
}
1
2
3
4
5
6

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

3.2 发送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)
			      );
...
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

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

3.3 收到ACK段

在上面，我们并没有看到服务器端对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);
...
}
1
2
3
4
5
6
7
8
9

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;
...
}
1
2
3
4
5
6
7
8
9

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;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

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;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

注：上面有几个和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;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

小结一下：实际上在三次握手过程中，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。

7. 参考

1. RFC 6691标准