mss

mss: 发送257长度的数据: node2:/root/test#cat t8.py import socket import time s = socket.socket(socket.AF_INET,socket.SOCK_STREAM) s.connect(("192.168.137.2",8080)) #print s.getsockopt() print s.getsockname() print s.getpeername() #s.sendall("this is shutdown test" + "\r\n") str='11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111' print len(str) print s.send(str) node2:/root/test#python t8.py ('192

尽管IP分片看起来是是透明的，但有一点让人不想使用它：即使只丢失一片数据也要重传整个数据报。为什么会发生这种情况呢？ 因为IP层本身没有超时重传的机制——由更高层来负责超时和重传（TCP有超时和重传机制，但UDP没有。一些UDP应用程序本身也执行超时和重传）。当来自TCP报文段的某一片丢失后，TCP在超时后重发整个TCP报文段，该报文段对应于一份IP 数据报。没有办法只重传数据报中的一个数据片。事实上，如果对数据分片的是中间路由器，而不是起始端系统，那么超始端系统就不无知道数据报是如何被分片的。就这个原因，经常要避免分片。 注：把一份IP数据报分片以后，只有到达目的地才进行重新组装（这里的重新组装与其他的网络协议不同，它们要求在下一站就进行重新组装，而不是在最终的目的地）。重新组装由目的端的IP层来完成，其目的是使分片和重新组装过程对运输层(TCP和UDP)是透明的，除了某些可能的越级操作处。已经分片过的数据报有可能会再次进行分片（可能不止一次）。IP首部中包含的数据为分片和重新组装提供了足够的信息。 1，MTU（Maximum Transmission Unit，MTU），最大传输单元 （1）以太网和802.3对数据帧的长度都有一个限制，其最大值分别是1500和1492个字节。链路层的这个特性称作MTU。不同类型的网络大多数都有一个上限。如果IP层有一个数据要传

MTU 和 MSS 1. MTU 2. MSS 参考 1. MTU 1 .MTU: Maxitum Transmission Unit 最大传输单元 以太网数据帧 以太网EthernetII最大的数据帧是 1518 Bytes 以太网帧报头为目的地址6+源地址6+类型2+CRC 4= 18 bytes 那么剩下承载上层协议的地方也就是Data域最大就只能有 1500 Bytes. 数据与填充：46~1500 个字节 这个值我们就把它称之为 MTU 2. MSS 1.MSS Maxitum Segment Size 最大分段大小 MSS就是TCP数据包每次能够传输的最大数据分段 2.为了达到最佳的传输效能TCP协议在建立连接的时候通常要协商双方的MSS值， 这个值TCP协议在实现的时候往往用MTU值代替 3.MSS 大小 需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes） 所以往往MSS为1460 参考 https://www.cnblogs.com/softidea/p/5541302.html https://blog.csdn.net/weixin_39453325/article/details/83656881 来源： CSDN 作者： Hani_97 链接： https://blog.csdn.net/lqy971966/article

搞了三年网络，今天才知道这个细节，汗，总结下： MTU大家都知道，是链路层中的网络对数据帧的一个限制，依然以以太网为例，MTU为1500个字节。一个IP数据报在以太网中 传输，如果它的长度大于该MTU值，就要进行分片传输，使得每片数据报的长度小于MTU。分片传输的IP数据报不一定按序到达，但IP首部中的信息能让这些数据报片按序组装。IP数据报的分片与重组是在网络层进完成的。 MSS（最大分段大小） MSS是TCP里的一个概念（首部的选项字段中）。MSS是TCP数据包每次能够传输的最大数据分段，TCP报文段的长度大于MSS时，要进行分段传输。TCP协议在建立连接的时候通常要协商双方的MSS值，每一方都有用于通告它期望接收的MSS选项（MSS选项只出现在SYN报文段中，即TCP三次握手的前两次）。MSS的值一般为MTU值减去两个首部大小（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）所以如果用链路层以太网，MSS的值往往为1460。而Internet上标准的MTU（最小的MTU，链路层网络为x2.5时）为576，那么如果不设置，则MSS的默认值就为536个字节。很多时候，MSS的值最好取512的倍数。TCP报文段的分段与重组是在运输层完成的。 到了这里有一个问题自然就明了了，TCP分段的原因是MSS，IP分片的原因是MTU，由于一直有MSS<=MTU

mtu是网络传输最大报文包，mss是网络传输数据最大值。 具体分析如下： 1、mss加包头数据就等于mtu. 简单说拿TCP包做例子。 报文传输1400字节的数据的话，那么mss就是1400，再加上20字节IP包头，20字节tcp包头，那么mtu就是1400+20+20. 当然传输的时候其他的协议还要加些包头在前面，总之mtu就是总的最后发出去的报文大小。mss就是你需要发出去的数据大小。 2、MSS: Maxitum Segment Size 最大分段大小 2.MSS最大传输大小的缩写，是TCP协议里面的一个概念。 3.MSS就是TCP数据包每次能够传输的最大数据分段。 3、为了达到最佳的传输效能TCP协议在建立连接的时候通常要协商双方的MSS值，这个值TCP协议在实现的时候往往用MTU值代替（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）所以往往MSS为1460。通讯双方会根据双方提供的MSS值得最小值确定为这次连接的最大MSS值。 来源： CSDN 作者： 行yutian空 链接： https://blog.csdn.net/ChenYuJin1314520/article/details/103473656

目前以太网的事实标准Ethernet v2最大包长度1514，但是从wireshark里发现没有到这个长度的，都是1434的 而且本方的mss值是1460，但是对方只返回最大包1434的。 这是为什么呢？从网上文章得知ip分包的最大值mss会被更改。 https://wenku.baidu.com/view/47561ded551810a6f524865a.html 于是找两台主机测试一下。 上面的一次连接，本方mss1460，对方要求1380。 从对方的监控看一下 对方收到封包的mss值果真被更改了。 看来经过外网的时候果真有个设备更改了mss值。 另外纯本地局域网测试了一下，mss值没有被更改。 备注： mss指的是tcp包内数据部分的本方期望长度。 Ethernet v2最大长度=14（mac头）+20（ip头）+20（tcp头）+mss = 1514 从上图和上述公式也看出tcp最短包为54 来源： https://www.cnblogs.com/sap-George/p/12009988.html

tcp_nodelay, tcp_nopush 和 sendfile tcp_nodelay 在 TCP 发展早期，工程师需要面对流量冲突和堵塞的问题，其中涌现了大批的解决方案，其中之一是由 John Nagle 提出的算法。 Nagle 的算法旨在防止通讯被大量的小包淹没。该理论不涉及全尺寸 tcp 包（最大报文长度，简称 MSS）的处理。只针对比 MSS 小的包，只有当接收方成功地将以前的包(ACK)的所有确认发送回来时，这些包才会被发送。在等待期间，发送方可以缓冲更多的数据之后再发送。 if package . size >= MSS . size send ( package ) elsif acks . all_received ? send ( package ) else # acumulate data end 与此同时，诞生了另一个理论，延时 ACK 在 TCP 通讯中，在发送数据后，需要接收回应包(ACK)来确认数据被成功传达。 延时 ACK 旨在解决线路被大量的 ACK 包拥堵的状况。为了减少 ACK 包的数量，接收者等待需要回传的数据加上 ACK 包回传给发送方，如果没有数据需要回传，必须在至少每 2 个 MSS，或每 200 至 500 毫秒内发送 ACK（以防我们不再收到包）。 if packages . any ? send elsif last

一：基本介绍 在Loadrunner的使用中，对于Run-time Settings下的browser emulation设置是比较容易让人产生困惑的地方。下面我们结合sniffer来具体看看每个选项的用途，以及对测试的影响。 Browser Emulation 图 1--什么是浏览器缓存？-- 简单来说，浏览器的缓存就是--使用浏览器访问页面时，浏览器会将一些网页的文字，图片，保存到本地的一个文件内。然后，再次使用浏览器访问这个网页的时候，先前被保存（缓存）的文字和图片不会从新被下载，而是使用保存在本地的资源。 Browser Emulation就是用来设置脚本回放时，lr模拟浏览器缓存策略的 缓存的东西一般都放在C:\Documents and Settings\用户\Local Settings\Temporary Internet Files下。可以进去打开立面都是些什么--文档和图片，而且都是你曾经浏览过的界面中信息 2--Browser Emulation选项说明-- 详解见： http://www.rosoo.net/a/201011/10401.html http://hi.baidu.com/c1425/item/0f4af76fc4f3a20ca1cf0f9d 上面这个连接对浏览器的设置，解释的很好，本人尝试了对Browser Emulation各种设置

一、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

最大报文段长度(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；