上周Linux内核修复了4个CVE漏洞[1],其中的CVE-2019-11477感觉是一个很厉害的Dos漏洞,不过因为有其他事打断,所以进展的速度比较慢,这期间网上已经有相关的分析文章了。[2][3]
作者:Hcamael@知道创宇 404 实验室 时间:2019 年 6 月 26 日 英文版本:https://paper.seebug.org/967/
前几天,我厂剑英和晓培同学在定位一个TCP通信失败问题时,发现原因是客户端发送的TCP数据过长(1460字节),导致数据包无法成功发送到服务端。但通过抓包发现,在三次握手时,双方协商的MSS就是1460。那么,应该是在这个连接的传输过程中,数据包的传输路径发生了变化,走了不同的中间设备,从而导致协商时的MSS大小已经超过了实际的传输路径限制。因为客户端已经发布,我们通过修改服务端的对外接口的MTU,暂时解决了这样的问题。
本文主要讲解网络通信中MTU,IP MTU和MSS的概念以及它们之间的关系。这三个概念对于网络通信来说非常重要,在实际的网络场景中常常很多网页打不开等问题,往往罪魁祸首都是这几个参数没配置正确导致的。VPP在21.06提交了一个tcp mss clamp的patch,本文主要来学习一下配置及使用。
于是出现了对于握手过程进行的攻击。攻击者发送大量的SYN包,服务器回应(SYN+ACK)包,但是攻击者不回应ACK包,这样的话,服务器不知道(SYN+ACK)是否发送成功,默认情况下会重试5次(tcp_syn_retries)。这样的话,对于服务器的内存,带宽都有很大的消耗。攻击者如果处于公网,可以伪造IP的话,对于服务器就很难根据IP来判断攻击者,给防护带来很大的困难。
在前面两篇文章中,我们研究了在TCP三次握手时MSS选项的值:一般情况下,都是由出口路由的MTU大小决定:MTU-40。也就是说,TCP在握手阶段,通过MSS选项,通知对端本端可以接收的最大报文长度是多少。
根据用户提供的文章内容进行摘要总结
很多人常常对TCP优化有一种雾里看花的感觉,实际上只要理解了TCP的运行方式就能掀开它的神秘面纱。Ilya Grigorik 在「High Performance Browser Networking」中做了很多细致的描述,让人读起来醍醐灌顶,我大概总结了一下,以期更加通俗易懂。 流量控制 传输数据的时候,如果发送方传输的数据量超过了接收方的处理能力,那么接收方会出现丢包。为了避免出现此类问题,流量控制要求数据传输双方在每次交互时声明各自的接收窗口「rwnd」大小,用来表示自己最大能保存多少数据,这主要是针
很多人常常对TCP优化有一种雾里看花的感觉,实际上只要理解了TCP的运行方式就能掀开它的神秘面纱。Ilya Grigorik 在「High Performance Browser Networking」中做了很多细致的描述,让人读起来醍醐灌顶,我大概总结了一下,以期更加通俗易懂。
网络编程几乎是每一门编程语言都会涉及的内容,虽然各种语言调用的方式可能不一样,但它们背后的原理支持都是一样的。因此本文将从TCP的连接的建立说起。在此之前,假设你已经对计算机网络有了最基本的认识。
要用到的命令是 route route 命令 显示和设置Linux路由表 -A:设置地址类型; -C:打印将Linux核心的路由缓存; -v:详细信息模式; -n:不执行DNS反向查找,直接显示数字形式的IP地址; -e:netstat格式显示路由表; -net:到一个网络的路由表; -host:到一个主机的路由表。 Add:增加指定的路由记录; Del:删除指定的路由记录; Target:目的网络或目的主机; gw:设置默认网关; mss:设置TCP的最大区块长度(MSS),单位MB; windo
当服务器的并发TCP连接数以十万计时,我们就会对一个TCP连接在操作系统内核上消耗的内存多少感兴趣。socket编程方法提供了SO_SNDBUF、SO_RCVBUF这样的接口来设置连接的读写缓存,linux上还提供了以下系统级的配置来整体设置服务器上的TCP内存使用,但这些配置看名字却有些互相冲突、概念模糊的感觉,如下(sysctl -a命令可以查看这些配置):
当服务器的并发TCP连接数以十万计时,我们就会对一个TCP连接在操作系统内核上消耗的内存多少感兴趣。socket编程方法提供了SO_SNDBUF、SO_RCVBUF这样的接口来设置连接的读写缓存,linux上还提供了以下系统级的配置来整体设置服务器上的TCP内存使用,但这些配置看名字却有些互相冲突、概念模糊的感觉,如下(sysctl -a命令可以查看这些配置): net.ipv4.tcp_rmem = 8192 87380 16777216 net.ipv4.tcp_wmem = 8192 65536
而且,这个超时时间在不同的网络的情况下,根本没有办法设置一个死的值。只能动态地设置。 为了动态地设置,TCP引入了RTT——Round Trip Time,也就是一个数据包从发出去到回来的时间。这样发送端就大约知道需要多少的时间,从而可以方便地设置Timeout——RTO(Retransmission TimeOut),以让我们的重传机制更高效。 听起来似乎很简单,好像就是在发送端发包时记下t0,然后接收端再把这个ack回来时再记一个t1,于是RTT = t1 – t0。没那么简单,这只是一个采样,不能代表普遍情况。
IP层叫分片,TCP/UDP层叫分段。网卡能做的事(TCP/UDP组包校验和分段,IP添加包头校验与分片)尽量往网卡做,网卡不能做的也尽量迟后分片(发送)或提前合并片(接收)来减少在网络栈中传输和处理的包数目,从而减少数据传输和上下文切换所需要的CPU计算时间。
毕竟这个问题算是很基本的了,平常处理网络问题的时候,这个基础点作为技术支持是必须要了解的,可能没有那么深,但是要知道发生了个啥,在和客户、网络专家沟通的时候要知道人家说的是什么
大家好,我是架构君,一个会写代码吟诗的架构师。今天说一说udp端口转发 Linux,Linux iptables 端口转发[通俗易懂],希望能够帮助大家进步!!!
【统计->捕获文件属性】 Statistics -> Summary,查看文件属性信息,如平均速度、包大小、包数等等
[注解:如果执行packetdrill自带的用例出错,一般是协议栈发出的包没有达到预期的包,先将预期>那部分干掉,然后再执行测试用例,然后通过抓包分析预期结果。通常是因为三次握手mss 的限制]
网络编程中经常会遇到一些异常的情况,定位问题需要了解协议栈的实现,以下是工作中遇到的一些常见问题的深入分析和解决思路。 问题1:server端业务进程响应心跳超时被监控进程kill,导致数据或者逻辑异常 我们的后台框架采用的是proxy,worker模型,proxy处理连接和会话,worker处理业务,proxy和worker之间通过共享内存队列进行通信,并有监控进程扫描proxy和worker的运行情况。管理进程会定时向worker发起心跳查询,防止业务进程挂起。业务worker的心跳默认是60s,如
[注解:如果执行packetdrill自带的用例出错,一般是协议栈发出的包没有达到预期的包,先将预期 那部分干掉,然后再执行测试用例,然后通过抓包分析预期结果。通常是因为三次握手mss 的限制]
最近项目测试遇到个奇怪的现象,在测试环境通过 Apache HttpClient 调用后端的 HTTP 服务,平均耗时居然接近 39.2ms。可能你乍一看觉得这不是很正常吗,有什么好奇怪的?其实不然,我再来说下一些基本信息,该后端的 HTTP 服务并没有什么业务逻辑,只是将一段字符串转成大写然后返回,字符串长度也仅只有 100 字符,另外网络 ping 延时只有 1.9ms左右。因此,理论上该调用耗时应该在 2-3ms 左右,但为什么平均耗时 39.2ms 呢?
最近项目测试遇到个奇怪的现象,在测试环境通过 Apache HttpClient 调用后端的 HTTP 服务,平均耗时居然接近 39.2ms。可能你乍一看觉得这不是很正常吗,有什么好奇怪的?其实不然,我再来说下一些基本信息,该后端的 HTTP 服务并没有什么业务逻辑,只是将一段字符串转成大写然后返回,字符串长度也仅只有 100 字符,另外网络 ping 延时只有 1.9ms 左右。因此,理论上该调用耗时应该在 2-3ms 左右,但为什么平均耗时 39.2ms 呢?
问题 TCP客户端发送数据一般这样写 发送数据调用的是write函数,第一个参数是表示socket的文件指针,后面是要传送的数据指针和数据长度。如果数据长度超过了MSS(TCP传送的最大单元)那么数据会被拆分成多个TCP数据包发送。问题:两个线程同时写入超过MSS大小的数据包那么发送的数据包是否存在乱序 比如:Thread1写入的数据被拆分成P1、P2、P3三个TCP数据包;Thread2写入的数据被拆分成P4、P5、P6。接收端收到是数据包是否会存在“交叉”的情况——P1、P4、P5、P2…… 为了照顾大
唐聪、王超凡,腾讯云原生产品中心技术专家,负责腾讯云大规模 TKE 集群和 etcd 控制面稳定性、性能和成本优化工作。 王子勇,腾讯云专家级工程师, 腾讯云计算产品技术服务专家团队负责人。 概况 作为当前中国广泛使用的云视频会议产品,腾讯会议已服务超过 3 亿用户,能高并发支撑千万级用户同时开会。腾讯会议数百万核心服务都部署在腾讯云 TKE 上,通过全球多地域多集群部署实现高可用容灾。在去年用户使用最高峰期间,为了支撑更大规模的并发在线会议的人数,腾讯会议与 TKE 等各团队进行了一轮新的扩容。 然而,在
TCP是一个巨复杂的协议,因为他要解决很多问题,而这些问题又带出了很多子问题和阴暗面。所以学习TCP本身是个比较痛苦的过程,但对于学习的过程却能让人有很多收获。关于TCP这个协议的细节,我还是推荐你去看W.Richard Stevens的《TCP/IP 详解 卷1:协议》(当然,你也可以去读一下RFC793以及后面N多的RFC)。另外,本文我会使用英文术语,这样方便你通过这些英文关键词来查找相关的技术文档。 之所以想写这篇文章,目的有三个, 一个是想锻炼一下自己是否可以用简单的篇幅把这么复杂的TCP协议描清
TCP首部中的Window字段,表示当前套接字的接收窗口,即目前可以接收的数据大小,对端不会发送超过接收窗口大小的数据。如果在三次握手时,两端都支持Windows Scale选项,则实际的接收窗口还要乘以Windows Scale的值。
上周因为发烧没办法坚持每“周一”更 —— 再次感叹“每周一更”这个名字,先给大家道声抱歉。
tcp的三次握手是指client与server端通过发送http请求,建立tcp连接, 分为三个步骤
前期一个项目与外部厂商联调时,由于外部某几个网络环节存在超时或不通的情况,排查到可能需要修改部分网络环节的MSS参数信息,以下对相关操作进行记录,留待后续参考。
TCP/IP 协议簇建立了互联网中通信协议的概念模型,该协议簇中的两个主要协议就是 TCP 和 IP 协议。TCP/ IP 协议簇中的 TCP 协议能够保证数据段(Segment)的可靠性和顺序,有了可靠的传输层协议之后,应用层协议就可以直接使用 TCP 协议传输数据,不在需要关心数据段的丢失和重复问题。
当客户端想和服务端建立 TCP 连接的时候,首先第一个发的就是 SYN 报文,然后进入到 SYN_SENT 状态。
tcpdump 是一款强大的网络抓包工具,运行在 linux 平台上。熟悉 tcpdump 的使用能够帮助你分析、调试网络数据。
图片下载走的 k8s ingress,这个 ingress 路径对应后端 service 是一个代理静态图片文件的 nginx deployment,这个 deployment 只有一个副本,静态文件存储在 nfs 上,nginx 通过挂载 nfs 来读取静态文件来提供图片下载服务,所以调用链是:client --> k8s ingress --> nginx --> nfs。
TCP拥塞控制是为了解决发送方以过高的速率发送导致网络中出现阻塞,其核心思想就是发生重传时控制发送方滑动窗口(通过控制拥塞窗口cwnd)的大小,从而控制其发送速率。
这个问题 flannel 和 calico 的 VXLAN 模式下都会发生,部分人的集群的A记录 UDP 下查询可能有问题。原因是 v1.17+ 的 kubernetes 某部分会引起内核的某个 UDP 相关的 BUG 而不是 CNI 的软件层面, WEAVE 没有这个问题,原因后面会说到。
在网络层(IP层),叫分片。(注意以下提到的IP没有特殊说明的情况下,都是指IPV4)
上面的文章已经分析了tcp建立的整个过程,下面我们来看下write是如何实现tcp写的。
本文讲述了在弱联网场景下,如何通过优化TCP参数、合理设置TCP窗口大小,达到高可靠性的数据传输以及优化的网络利用效率,同时分析了在不同网络环境下的性能表现。
MTU: Maximum Transmit Unit,最大传输单元,即物理接口(数据链路层)提供给其上层(通常是IP层)最大一次传输数据的大小;以普遍使用的以太网接口为例,缺省MTU=1500 Byte,这是以太网接口对IP层的约束,如果IP层有<=1500 byte 需要发送,只需要一个IP包就可以完成发送任务;如果IP层有> 1500 byte 数据需要发送,需要分片才能完成发送,这些分片有一个共同点,即IP Header ID相同。 MSS:Maximum Segment Size ,TCP提交给IP
在上一篇中,我们已经建立好的TCP连接,对应着操作系统分配的1个套接字。操作TCP协议发送数据时,面对的是数据流。通常调用诸如send或者write方法来发送数据到另一台主机,那么,调用这样的方法时,在操作系统内核中发生了什么事情呢?我们带着以下3个问题来细细分析:发送方法成功返回时,能保证TCP另一端的主机接收到吗?能保证数据已经发送到网络上了吗?套接字为阻塞或者非阻塞时,发送方法做的事情有何不同?
公众号中关于Unix网络编程的1、2章节对基础知识做了铺垫,介绍了建立网络通信的API。然而客户和服务器之间建立通信管道(以下简称Channel)之后,如何管理Channel以及Channel中双向流动的数据才是开发者关注的重点,这构成了所有网络应用(如http服务器,ftp服务器等)的基础,也才真正是Unix网络课程这个分支所涉及的内容。
作者Liam,海外老码农,对应用密码学、CPU微架构、高速网络通信等领域都有所涉猎。
转载:https://www.kancloud.cn/chunyu/php_basic_knowledge/2106519
http://blog.csdn.net/russell_tao/article/details/9370109
这是TCP/IP协议栈系列的第二篇文章,之前的一篇理解TCP/IP协议栈之HTTP2.0感兴趣可以看下,今天一起来学习下一个热点问题。
tcpdump 是一个命令行应用程序,可让你捕获和分析通过系统的网络流量。它通常用于帮助解决网络问题以及安全工具。 tcpdump 是一个强大且多功能的工具,包括许多选项和过滤器,可用于各种情况。由于它是一个命令行工具,因此非常适合在没有 GUI 的远程服务器或设备中运行,以收集可以稍后分析的数据。它也可以在后台启动或使用 cron 等工具作为预定作业启动。 1. 在 Linux 上安装 Tcpdump 包含在多个 Linux 发行版中,因此你可能已经安装了它。使用以下命令检查你的系统上是否安装了 tcpd
领取专属 10元无门槛券
手把手带您无忧上云