mtu

一般TCP的书都会说在网络传输中最大传输报文MTU一般为1500字节，但是在一次局域网的测试却发现了如下问题： 首先从后两张图片我们可以确定C/S两端都是相互确认了MSS为1460个字节的，但是为啥第一张图却出了一个2962字节的包了呢，这明显这是跟书上观点相违背的。 转载请标明出处: 关于网络传输中最大传输报文MTU的思考 文章来源: 关于网络传输中最大传输报文MTU的思考

一、TCP粘包、拆包图解 假设客户端分别发送了两个数据包D1和D2给服务端，由于服务端一次读取到字节数是不确定的，故可能存在以下四种情况： TCP粘包 TCP拆包 二、 粘包、拆包发生原因 产生原因 主要有这3种：滑动窗口、MSS/MTU限制、Nagle算法 1、滑动窗口 TCP流量控制，主要使用 滑动窗口协议 ，滑动窗口是接受数据端使用的窗口大小，用来告诉发送端接收端的缓存大小，以此可以控制发送端发送数据的大小，从而达到流量 控制的目的。这个窗口大小就是我们一次传输几个数据。对所有数据帧按顺序赋予编号，发送方在发送过程中始终保持着一个发送窗口，只有落在发送窗口内的帧才允许被发送； 同时接收方也维持着一个接收窗口，只有落在接收窗口内的帧才允许接收。 这样：通过调整发送方窗口和接收方窗口的大小，可以实现流量控制。 　　 现在来看一下滑动窗口是如何造成粘包、拆包的？ 粘包：假设发送方的每256 bytes表示一个完整的报文，接收方由于数据处理不及时，这256个字节的数据都会被缓存到SO_RCVBUF(接收缓存区）中。 　　　如果接收方的SO_RCVBUF中缓存了多个报文，那么对于接收方而言， 这就是粘包。 拆包：考虑另外一种情况，假设接收方的窗口只剩了128，意味着发送方最多还可以发送128字节， 这就造成了拆包。 2、MSS和MTU分片 MSS: 是Maximum Segement

概述 ip_fragment函数用于判断是否进行分片，在没有设置DF标记的情况下进入分片，如果设置了DF标记，则继续判断，如果不允许DF分片或者收到的最大分片大于MTU大小，则回复ICMP，释放skb，其余情况仍然需要走分片； ip_do_fragment是详细的分片流程，整个过程分为快速分片和慢速分片两种，如果存在分片列表frag_list，并且通过检查，则走快速路径，复制每个分片的ip头等信息之后，发送出去；如果不存在分片列表，或者分片列表检查失败，则走慢速路径，慢速路径会根据MTU大小，对整个数据进行重新划分，分配skb，进行数据拷贝，设置ip头等信息，然后发送出去； 源码分析 1 static int ip_fragment(struct net *net, struct sock *sk, struct sk_buff *skb, 2 unsigned int mtu, 3 int (*output)(struct net *, struct sock *, struct sk_buff *)) 4 { 5 struct iphdr *iph = ip_hdr(skb); 6 7 /* 如果没有DF标记，则进行分片 */ 8 if ((iph->frag_off & htons(IP_DF)) == 0) 9 return ip_do_fragment(net, sk,

最大报文段长度(MSS)表示TCP传往另一端的最大数据库的长度。当一个连接建立时，连接的双方都要通告各自需要接收的MSS选项(MSS选项只能出现在SYN报文段中)。如果一方不接收来自另一方的MSS值，则MSS就定为默认值536字节(这个默认值允许20字节的IP首部和20字节的TCP首部以适合576字节的IP数据报)； 一般来说，如果没有分段发生，MSS是越大越好(并不总是正确)。报文段越大允许每个报文发送的数据就越多。相对IP和TCP首部有更高的网络利用率。当TCP发送一个SYN时，或者是因为一个本地应用进程发起一个连接，或者是因为另一端的主机收到了一个连接请求，它将MSS的值设置为出接口上的MTU长度减去固定的IP首部和TCP首部长度。对于以太网来说，MSS值可达1460字节； 如果目的IP地址为“非本地地址”，MSS通常的默认值是536.而区分地址是本地还是非本地是简单的，如果目的IP地址的网络号与子网号都与我们相同，则是本地地址；如果目的IP地址的网络号与我们完全不同，则是非本地地址；如果目的IP地址的网络号与我们的相同而子网号与我们的不同，则可能是本地的，也可能是非本地的。大多数，TCP实现版都提供一个配置选项，让系统管理员来说明不同的子网数是属于本地还是非本地。这个选项的设置将确定MSS可以选择尽可能大(大到外出接口的MTU长度)或者是默认值536；

1、概述 首先要看TCP/IP协议，涉及到四层：链路层，网络层，传输层，应用层。 　　 其中以太网（Ethernet）的数据帧在链路层 　　 IP包在网络层 　　 TCP或UDP包在传输层 　　 TCP或UDP中的数据（Data)在应用层 　　 它们的关系是 数据帧｛IP包｛TCP或UDP包｛Data｝｝｝ 　　 不同的协议层对数据包有不同的称谓，在传输层叫做段(segment)，在网络层叫做数据报(datagram)，在链路层叫做帧(frame)。数据封装成帧后发到传输介质上，到达目的主机后每层协议再剥掉相应的首部，最后将应用层数据交给应用程序处理。 在应用程序中我们用到的Data的长度最大是多少，直接取决于底层的限制。 　　 我们从下到上分析一下： 　　 1.在链路层，由以太网的物理特性决定了数据帧的长度为(46＋18)－(1500＋18)，其中的18是数据帧的头和尾，也就是说数据帧的内容最大为1500(不包括帧头和帧尾)，即MTU(Maximum Transmission Unit)为1500； 　 2.在网络层，因为IP包的首部要占用20字节，所以这的MTU为1500－20＝1480；　 3.在传输层，对于UDP包的首部要占用8字节，所以这的MTU为1480－8＝1472； 　　 所以，在应用层，你的Data最大长度为1472。当我们的UDP包中的数据多于MTU(1472

配置 docker0 网桥 Docker 服务默认会创建一个 docker0 网桥（其上有一个 docker0 内部接口），它在内核层连通了其他的物理或虚拟网卡，这就将所有容器和本地主机都放到同一个物理网络。 Docker 默认指定了 docker0 接口 的 IP 地址和子网掩码，让主机和容器之间可以通过网桥相互通信，它还给出了 MTU（接口允许接收的最大传输单元），通常是 1500 Bytes，或宿主主机网络路由上支持的默认值。这些值都可以在服务启动的时候进行配置。 --bip=CIDR IP 地址加掩码格式，例如 192.168.1.5/24 --mtu=BYTES 覆盖默认的 Docker mtu 配置 也可以在配置文件中配置 DOCKER_OPTS，然后重启服务。 由于目前 Docker 网桥是 Linux 网桥，用户可以使用 brctl show 来查看网桥和端口连接信息。 $ sudo brctl show bridge name bridge id STP enabled interfaces docker0 8000.3a1d7362b4ee no veth65f9 vethdda6 *注： brctl 命令在 Debian、Ubuntu 中可以使用 sudo apt-get install bridge-utils 来安装。 每次创建一个新容器的时候

一. 基本知识： OSPF（Open Shortest Path Fist），开放式最短路径优先，传信机制，目前所使用的为OSPFv2版本，IPV6使用OSPFv3版本,协议优先级为10/150 OSPF依靠IP进行承载，协议号位89。OSPF作为链路状态的协议（Link-state Routing Protocol），具有收敛快、路由无环、扩展性好等优点，被快速接受并广泛使用。 链路状态算法路由协议互相通告的是链路状态信息，每台路由器都将自己的链路状态信息（包含接口的IP地址和子网掩码、网络类型、该链路的开销值等）发送给其它路由器，，并在网络中泛洪，当这台路由器收集到网络内所有的链路状态信息后，就能应有整个网络的拓扑情况，然后通过运行SPF（Shortest Path First）算法，得出所有网段的最短路径。 1. 特点： ① 支持无类域间路由CIDR ② 支持报文的认证 ③ 无路由自环 ④ 路由变化收敛速度快，触发更新 ⑤ 使用组播首发协议数据（DR-other：224.0.0.5/DR：224.0.0.6） ⑥ 支持多条等价路由 ⑦ 支持区域划分 （1）支持无类域间路由CIDR： OSPF路由汇总可以减少LSA的条目，当明细条目消失时，不会形成路由动荡，当所有的明细条目消失后，汇总路由也会消失。与RIP不同，OSPF不支持自动路由聚合，仅支持手动路由聚合

网络基础管理 文章目录 网络基础管理 1. 网卡命名 1.1 传统网卡命名机制 1.2 redhat7网卡命名机制 1.3 网络接口名称组成格式 1.4 网卡设备的命名过程 1.5 回归传统命名 2. 网络管理常用命令 2.1 ifconfig 2.2 ip 2.3 route 2.4 hostname与hostnamectl 3. 网络相关配置文件 3.1 网络配置文件 3.2 网络接口配置文件 3.3 路由配置文件 3.4 DNS配置文件 4. NetworkManager管理网络 5. 使用原生network管理网络 6. 网络检测工具与故障排查 6.1 ping 6.2 host与nslookup 6.3 traceroute 6.4 netstat 6.5 ss 6.6 网络故障排查 作业 1. 网卡命名 1.1 传统网卡命名机制 传统命名： 以太网eth[0,1,2,…] wlan[0,1,2,…] 1.2 redhat7网卡命名机制 systemd对网络设备的命名方式： 如果Firmware或BIOS为主板上集成的设备提供的索引信息可用，且可预测，则根据此索引进行命名，例如eno1 如果Firmware或BIOS为PCI-E扩展槽所提供的索引信息可用，且可预测，则根据此索引进行命名，例如ens1 如果硬件接口的物理位置信息可用，则根据此信息进行命名，例如enp2s0

给新添加的网卡配置IP地址 现有新添加的两张网卡eno33554992和eno50332216 在server1上使用nmcli [root@server_1 network-scripts]# nmcli connection add con-name eth1 type ethernet ifname eno33554992 ip4 192.168.19.102/24 gw4 192.168.19.1 Connection ‘eth1’ (8099abb8-2a30-4d11-a3ae-ce4c5c534d8b) successfully added. [root@server_1 network-scripts]# nmcli connection add con-name eth2 type ethernet ifname eno50332216 ip4 192.168.19.103/24 gw4 192.168.19.1 Connection ‘eth2’ (f127ca55-37d3-4913-8b62-1969ceabaacd) successfully added. [root@server_1 network-scripts]# ip addr 2 : eno16777736 : < BROADCAST , MULTICAST , UP , LOWER_UP >

目录 1.网卡命名 1.1 传统网卡命名机制 1.2 redhat7网卡命名机制 1.3 网络接口名称组成格式 1.4 网卡设备的命名过程 1.5 回归传统命名 2. 网络管理常用命令 2.1 ifconfig 2.2 ip 2.3 route 2.4 hostname与hostnamectl 3. 网络相关配置文件 3.1 网络配置文件 3.2 网络接口配置文件 3.3 路由配置文件 3.4 DNS配置文件 4. NetworkManager管理网络 5. 使用原生network管理网络 6. 网络检测工具与故障排查 6.1 ping 6.2 host与nslookup 6.3 traceroute 6.4 netstat 6.5 ss 6.6 网络故障排查 1.网卡命名 1.1 传统网卡命名机制 传统命名： 以太网eth[0,1,2,...] wlan[0,1,2,...] 1.2 redhat7网卡命名机制 systemd对网络设备的命名方式： 如果Firmware或BIOS为主板上集成的设备提供的索引信息可用，且可预测，则根据此索引进行命名，例如eno1 如果Firmware或BIOS为PCI-E扩展槽所提供的索引信息可用，且可预测，则根据此索引进行命名，例如ens1 如果硬件接口的物理位置信息可用，则根据此信息进行命名，例如enp2s0 如果用户显式启动