tcp timestamps

最近讨论到net.ipv4.tcp_timestamps这个系统配置是否能够开启,RFC文档上说道该值必须为单调递增,否则接受到的包可能会被丢掉

于是查看下tcp协议栈中是根据什么来生成这个timestamps的,是否会受时间改变而改变?

tcp协议栈代码如下:

static unsigned tcp_syn_options(struct sock *sk, struct sk_buff *skb,
	struct tcp_out_options *opts,
        struct tcp_md5sig_key **md5) {
        //...
        if (likely(sysctl_tcp_timestamps && *md5 == NULL)) {
	        opts->options |= OPTION_TS;
	        opts->tsval = TCP_SKB_CB(skb)->when;
	        opts->tsecr = tp->rx_opt.ts_recent;
	        size += TCPOLEN_TSTAMP_ALIGNED;
        }
        //...
}

然后搜索到:

TCP_SKB_CB(skb)->when = tcp_time_stamp;

接着

#define tcp_time_stamp ((__u32)(jiffies))

google得知:

jiffies变量记录了系统启动以来,系统定时器已经触发的次数。内核每秒钟将jiffies变量增加HZ次。因此,对于HZ值为100的系统,1个jiffy等于10ms,而对于HZ为1000的系统,1个jiffy仅为1ms。 

测试环境抓包验证:

1、系统HZ(250)

2、开启timestamps选项后进行抓包

计算1s钟后Tsval理论上应该=1040600478 + 250 = 1040600728

实际抓包如下:

与计算值刚好相符合。

因此,这里可以判断tcp中的timestamps取的就是系统启动滴答声jiffies(若将Tsval/HZ可以看到与系统启动时间是一致的)

结论:

1、tcp_timestamps不受系统墙上时间和RTC时间修改的影响;

2、具体jiffies是否能够被修改(担心会被ntp服务修改),后续接着查询资料。

tcp timestamps,布布扣,bubuko.com

时间: 2024-10-23 05:21:19

tcp timestamps的相关文章

TCP协议选项

原文转自:http://blog.chinaunix.net/uid-20249205-id-1713871.html Kind   Meaning                               Reference----   -------------------------------   ---------  0       End of Option List                 [RFC793]  1       No-Operation           

TCP Timeout and Retransmission(2)

Retransmission Ambiguity and Karn's Algorithm A problem measuring an RTT sample can occur when a packet is retransmitted. Say a packet is transmitted, a timeout occurs, the packet is retransmitted, and an acknowledgment is received for it. Is the ACK

Technical analysis of client identification mechanisms

http://www.chromium.org/Home/chromium-security/client-identification-mechanisms Chromium‎ > ‎Chromium Security‎ > ‎ Technical analysis of client identification mechanisms Written by Artur Janc <[email protected]> and Michal Zalewski <[email

linux系统收到SYN但不回SYN+ACK问题排查

一,背景: 今天下午发现线上的一台机器从办公网登录不上且所有tcp端口都telnet不通,但是通过同机房的其它机器却可以正常访问到出问题的机器.于是就立即在这台出问题的server端抓包分析,发现问题如下:server端收到了本地pc发的SYN包,但是没有回syn+ack包,所以确认是server端系统问题.tcpdump抓包如下: 二,排查 1,发现系统没有任何负载 2,网卡也没有丢包 3,iptables策略也都没问题 4,系统的SYN_RECV连接很少,也没超限 5,系统的文件描述符等资源

TIME_WAIT与tcp_tw_reuse /tcp_tw_recycle, 开还是不开?

对于这个问题找到的一些资料, 仅供参考: ------------------------------------------------------ 关于TIME_WAIT数量太多.从上面的描述我们可以知道,TIME_WAIT是个很重要的状态,但是如果在大并发的短链接下,TIME_WAIT 就会太多,这也会消耗很多系统资源.只要搜一下,你就会发现,十有八九的处理方式都是教你设置两个参数,一个叫tcp_tw_reuse,另一个叫tcp_tw_recycle的参数,这两个参数默认值都是被关闭的,后

Haproxy Configure File

---------------------- HAProxy Configuration Manual ---------------------- version 1.5.11 willy tarreau 2015/02/01 This document covers the configuration language as implemented in the versionspecified above. It does not provide any hint, example or

005-TCP传输控制协议

一.概述 传输控制协议(英语:Transmission Control Protocol,缩写为 TCP)是一种面向连接的.可靠的.基于字节流的传输层通信协议,由IETF的RFC 793定义.在简化的计算机网络OSI模型中,它完成第四层传输层所指定的功能,用户数据包协议(UDP)是同一层内另一个重要的传输协议. 在因特网协议族(Internet protocol suite)中,TCP层是位于IP层之上,应用层之下的中间层.不同主机的应用层之间经常需要可靠的.像管道一样的连接,但是IP层不提供这

记一次由tcp_tw_recycle参数引发的血案

一,故障描述: 从昨天开始,在值班群中陆续值班人员反映系统后台存在卡顿问题,如下图:而且在卡顿的同时登陆服务器也会卡好久.此现象只在一台服务器有出现. 二,故障分析: 1,登陆服务器查看资源使用top,vmstat等命令查看了一番发现服务器各项指标都没有异常.于是将问题转向了网络层.2,客户端端值班人员反映只有在访问系统后台的时候才会出现卡顿,访问其他网站正常.3,本地使用ping服务器外网ip正常返回,无丢包,延迟也正常.4,使用http-ping工具时,问题出现了,会经常性的出现连接失败:(

TCP协议

TCP(Transmission Control Protocol )传输控制协议,是目前传输层应用最广泛的协议,当然这跟它的特性息息相关. 一.它的主要特性有: 1.可靠,面向连接 2.工作在传输层面向连接协议 3.全双工协议 4.半关闭(单方关闭) 5.错误检查 每个数据包有编号,对方收到之后,会告诉发送方收到了,回给对方说我下次希望收到第n+1个包,假如发送了三个包,但是接受方只收到了两个,会说下次希望收到第三个包,那么就实现了错误检查和重传 6.将数据打包成段,排序 即标记序列号,有时候