内核3.10，接《tcp的发送端一个小包就能打破对端的delay_ack么？》
我们继续来分析这个没满mss的小包，
可以看到，由于受到syn ack这端是发包端，所以该发送链路协商的mss为 1460，而接收的时候，mss只能为1412.
我们来找下规律，看下小包发送有没有其他时间规律：
可以看到，小包就是下面那排小点，其中总长度为490，很明显的一排。
图形还是比较好找规律，可以大概看出，小包的发送间隔几乎是固定的，间隔为400ms。凭着对tcp的了解，协议栈肯定不会有固定400ms发送一个固定大小的小包的
行为，所以这个应该是用户态行为。
用户态如何制造这种情况，我们再来看两个时间间隔内的报文总长度：
对应的seq分别为：1052063,1576351,2100639,2624927,3149215,3673503，4197791,4722079,5246367。
可以算出，两个小包之间的seq相差刚好为524288字节，也就是512k，而从下图的报文时间分布来看，发包的时候，是一种burst现象，也就是有包赶紧发，有的时间段是没有包的。
所以得出这样的结论：每400ms，用户态进程发送512k的报文，其中最后一个报文，是不满mss的，这个不满mss的报文，因为某种原因，
等待了一会，发现后面没有报文继续发送，所以还是发送出去了，前面等待是因为不满mss，等待超时之后，只能发送出去，发送出去之后，因为没有新的数据要下发，所以形成了一个明显的前后间隔。
那什么样的情况，不满mss的报文需要等待呢？熟悉tcp的兄弟肯定会想起来，这个就像nagle啊。
我们来看这样一个流程，在一个establish的链路中，在收到ack之后，会先调用tcp_ack处理这个ack，尽可能地清理到之前因为未收到ack而保存在在发送队列中的skb，
void tcp_rcv_established(struct sock *sk, struct sk_buff *skb,
const struct tcphdr *th, unsigned int len)
{
。。。 if (len <= tcp_header_len) {
/* Bulk data transfer: sender */
if (len == tcp_header_len) {
/* Predicted packet is in window by definition.
* seq == rcv_nxt and rcv_wup <= rcv_nxt.
* Hence, check seq<=rcv_wup reduces to:
*/
if (tcp_header_len ==
(sizeof(struct tcphdr) + TCPOLEN_TSTAMP_ALIGNED) &&
tp->rcv_nxt == tp->rcv_wup)
tcp_store_ts_recent(tp); /* We know that such packets are checksummed
* on entry.
*/
tcp_ack(sk, skb, );//入向ack处理
__kfree_skb(skb);
tcp_data_snd_check(sk);---------------检查是不是有数据需要发送，收到ack是触发数据发送的三大原因之一，其余两个为用户调用发送以及定时器超时后发送
return;
}
处理完ack之后，也就是清理了那些ack的skb之后，需要再检查是否有数据发送，因为一个有效的ack除了清理我们保存的skb外，也就是调用tcp_clean_rtx_queue，还可能为我们提供了新的窗口信息：
static inline void tcp_data_snd_check(struct sock *sk)
{
tcp_push_pending_frames(sk);
。。。
} static inline void tcp_push_pending_frames(struct sock *sk)
{
if (tcp_send_head(sk)) {
struct tcp_sock *tp = tcp_sk(sk); __tcp_push_pending_frames(sk, tcp_current_mss(sk), tp->nonagle);
}
} void __tcp_push_pending_frames(struct sock *sk, unsigned int cur_mss,
int nonagle)
{
....... if (tcp_write_xmit(sk, cur_mss, nonagle, ,
sk_gfp_atomic(sk, GFP_ATOMIC)))
tcp_check_probe_timer(sk);--------------------------tcp_write_xmit返回1，则设置timer
}
最后进入到熟悉的tcp_write_xmit 函数，
static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
int push_one, gfp_t gfp)
{
。。。。。 if (tso_segs == ) {------走的这个流程
if (unlikely(!tcp_nagle_test(tp, skb, mss_now,
(tcp_skb_is_last(sk, skb) ?-----------------确实是最后一个报文，因为其他报文因为nginx限速没有下来
nonagle : TCP_NAGLE_PUSH))))
break;
} else {
if (!push_one &&
tcp_tso_should_defer(sk, skb, &is_cwnd_limited,
max_segs))
break;
}
。。。。
}
break出去之后，并没有发包，而是等待，因为
static inline void tcp_check_probe_timer(struct sock *sk)
{
const struct tcp_sock *tp = tcp_sk(sk);
const struct inet_connection_sock *icsk = inet_csk(sk); if (!tp->packets_out && !icsk->icsk_pending)
inet_csk_reset_xmit_timer(sk, ICSK_TIME_PROBE0,
icsk->icsk_rto, TCP_RTO_MAX);
}
主要就是设置定时器，ICSK_TIME_PROBE0，对应的超时时间为rto，
static inline u32 __tcp_set_rto(const struct tcp_sock *tp)
{
return usecs_to_jiffies((tp->srtt_us >> ) + tp->rttvar_us);
}
tp->rttvar_us 其实不能小于 200ms，由于tp->srtt_us存储的是平滑rtt的8倍（为了不进行float计算，因为平滑的时候，是取的7/8的老rtt+1/8新rtt），所以需要>>3,按照当前流来说，
在设置rto之前，前面都是有多个40ms的delay_ack作为rtt，所以最终的定时器大概就是在240ms左右。和ttl图形是吻合的。当然，由于第一个小包之前的rtt都不大，平滑之后大概20ms左右，
所以第一个小包离收到ack之后的rto大概在220ms，也是符合图形的。