tcp分片和ip分片的区别

我们在计算机网络上所看到的分片一般是指ip分片，ip分片是指在网络传输过程中若遇到链路MTU比自己报文小的情况则进行分片。

MTU是链路层中的网络对数据帧的一个限制，以以太网为例，MTU为1500个字节。一个IP数据报在以太网中传输，如果它的长度大于该MTU值，就要进行分片传输，使得每片数据报的长度小于MTU。分片传输的IP数据报不一定按序到达，但IP首部中的信息能让这些数据报片按序组装。IP数据报的分片与重组是在网络层进完成的。

占16位。IP软件在存储器中维持一个计数器，每产生一个数据报，计数器就加1，并将此值赋给标识字段。但这个“标识”不是序号，因为IP是无连接服务，数据报不存在按序接收的问题。当数据报由于长度超过网络的MTU而必须分片时，这个标识字段的值就被复制到所有的数据报片的标识字段中。相同的标识字段的值使分片后的各数据报片最后能正确地重装成为原来的数据报。

标志（flags）占用3位（即16 - 18），这三位分别是：R，DF，MF三位，第一位是保留位，没有被使用，目前只有后两个比特有意义。

R：标志字段中的第一位是一个保留位，现在还没有使用，可能将来会用到这位

D：标志字段中间的一位是 DF (Don’t fragment)，表示传输的数据不允许分片。一般DF = 1的话，表示数据一次性传输过去，不允许分片。

M：标志字段的最低位是 MF (More fragment)。代表数据是否分片，如果MF位值为1，表示后面还有数据，还没有传输完毕，相当于数据分片，分批次传输，如果MF = 0表示最后一个分片或者只有一个分片。

这三位同一时刻也是只能有一个位的值能设置为1

占用13位：每次分片传输的数据之间的偏移距离，也就是某分片的数据在原数据中的相对位置，一般偏移以8字节为单位。比如：在网络层传输的ip数据报总长度最大不能超过65535字节，如果超过了，要么对ip数据报进行分片传输，否则将丢弃。

互联网协议使网络互相通信。设计要迎合不同物理性质的网络它是独立于链路层使用的基础传输技术。具有不同硬件的网络通常会发生变化，不仅在传输速度，而且在最大传输单元（MTU）。当一个网络要的数据报发送到具有较小MTU的一个网络，它可能片段的数据报。

当路由器收到一个数据包时，它会检查目的地址，并确定出接口使用，并且该接口的MTU。如果分组的大小是比MTU大，并且在该分组的头中的不分段（DF）位被设置为0，则路由器可对其进行分片。

分片机制有一定的缺陷：分片越多，分片丢失的机率就越大，对于一个数据报，一旦一个分片丢失，那么整个数据报就要重传；每一个数据报都要复制报头（只复制ip包头），这在一定程度上增加了带宽消耗。

组装时，需要重新设置首部的某些字段

修改分片标志和片偏移量字段

首部其他字段复制原来数据报首部的相应字段。

在IP头里面有16bit的识别号唯一记录了一个IP包的ID,以确定这几个分片是否属于同一个包，具有同一个ID的IP分片将会从新组装。13bit的片偏移记录了一个IP分片相对于整个包的位置。3bit的标志位记录了该分片后面是否还有新的分片。这三个分片组成了IP分片的所有的信息。

1.如果在源主机的以太网上进行数据包装，且tcp/udp向ip传送的数据包大于MTU1500字节，将在ip层进行分片。

2.在数据在数据链路（路由器）中传输的时候，每个路由器的MTU不一定相同，如果其中一个MTU只为800，则会触发ip分片，将1500字节的数据包拆成两个符合长度的数据包（但不一定会分片，由ip首部的两个标志位MF：More Fragment 和DF：Don't Fragment决定）如果是DF被设置，将会触发ICMP协议，将当前数据包丢弃，并把当前路由的MTU回传给源主机。

MSS(Maximum Segment Size，最大报文长度)是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，客户端声明MSS=8960，服务器端声明了MSS=1460。三次握手之后，客户端的MTU值比服务器端大，如果发送一个9000字节的包过去可能被分片或丢弃。因此客户端会把自己的MSS也降到1460字节。

TCP分段的原因是MSS，IP分片的原因是MTU， 由于一直有MSS<=MTU，很明显，分段后的每一段TCP报文段再加上IP首部后的长度不可能超过MTU，因此也就不需要在网络层进行IP分片了。 因此TCP报文段很少会发生IP分片的情况。

再来看UDP数据报， 由于UDP数据报不会自己进行分段，因此当长度超过了MTU时，会在网络层进行IP分片。 同样，ICMP（在网络层中）同样会出现IP分片情况。

TCP在三次握手建立连接过程中，会在SYN报文中使用MSS（Maximum Segment Size）选项功能，协商交互双方能够接收的最大段长MSS值。

MSS是传输层TCP协议范畴内的概念，顾名思义，其标识TCP能够承载的最大的应用数据段长度，因此，MSS=MTU-20字节TCP报头-20字节IP报头，那么在以太网环境下，MSS值一般就是1500-20-20=1460字节。

客户端与服务器端分别根据自己发包接口的MTU值计算出相应MSS值，并通过SYN报文告知对方。

IP分片产生的原因是网络层的MTU；TCP分段产生原因是MSS

IP分片由网络层完成，也在网络层进行重组；TCP分段是在传输层完成，并在传输层进行重组

对于以太网，MSS为1460字节，而MUT往往会大于MSS

故采用TCP协议进行数据传输，是不会造成IP分片的。若数据过大，只会在传输层进行数据分段，到了IP层就不用分片。而我们常提到的IP分片是由于UDP传输协议造成的，因为UDP传输协议并未限定传输数据报的大小。

TCP的分片和IP分片的区别

TCP的分片和IP分片的区别

MTU和MSS详解

写在文前：视频版本和文字版本略有不同，想要看我深情并茂演绎，请看视频版本 (喵懂区块链22期|分片（Sharding）：以太坊太慢，“盘”他！)，思维逻辑怪，请看文案加长版。

最近以太坊由于君士坦丁堡升级（Constantinople）而出现了压倒性的积极走势，而以太坊的升级之路则犹如升级打怪一般，落入了rabbit hole，谁也不知道这洞有多深。既然是“路漫漫其修远兮”，则把脚下的每一步走好走准，则成了至关重要的点。攻破这一难点之后，以太坊的下一技术难点---Sharding分片，则又被摆到了台面上。本期《喵懂区块链》会带大家走进让以太坊快起来的法宝--- Sharding分片。

什么是sharding分片？

分片技术其实并不是什么新概念，起初是针对大型中心数据库提出的优化方案，具体来说就是将大型数据库中的数据划按照某种规则分成很多数据分片（shard），再将这些数据分片分别存放在不同的服务器中，以减小每个服务器的数据访问压力，从而提高整个数据库系统的性能。

我们举一个通俗的小例子：

比如我们平时经常使用的美团，滴滴打车等软件，就可以按照“城市”来进行分片，由于不同城市的数据不需要互通，就可以将不同城市的数据存放在不同数据库中，这样既可以把数据库服务器部署到离对应城市最近的节点上，还可以提高访问速度，何乐而不为呢？！

从上面的例子中，我大家应该对分片的概念有了初步了解，那么对应到区块链场景中来说，分片又是怎么样的呢？

以以太坊分片为例，在原有的单链系统中，公链整体的性能取决于单个节点的性能，进行分片之后，每个节点只需要承当全网部分工作，各个分片并行工作，按照Vitalik的话来说，each shard is like a separate galaxy每个分片都像是独立的小宇宙，这样效率自然噌噌噌提升！原本以太坊链全网TPS约为20，现在若增加到100个分片，那么全网TPS可以提升至2000，同理，全网容量也将提升至原来的100倍。

“每个节点只需要承担全网部分工作”，这就会引出几大问题，1.怎么确定这个节点是负责哪个分片的工作？2.哪些交易应该归类到哪些分片当中去？3.每个节点是否只需要储存自己所在分片的交易信息（账本）？

根据以上问题的实现与否，我们可以将分片依次分为三种类型：网络分片，交易分片，状态分片。

网络分片：如何将全网节点划分到不同分片当中去。

交易分片：如何将全网交易划分到不同分片当中去。

状态分片：如何让各个节点只维护各自分片内的账本，但又不影响整个系统的安全性。

主链和分片链的区别和联系？

分片的类型我们已经明白了，那么主链（Main chain）和分片链（shard chain）有什么不同呢？

向左转|向右转

在主链中，我们知道记账的人叫做矿工，账本是存在区块当中，对应到分片链当中，则是Collator校对人和Collation校对块。

类似于区块的构成，Collation校对块也包含Collation header校对头和tansaction list具体的交易信息。

向左转|向右转

对比下来，主链和分片链本身来说，还是大同小异，但是一但要把他们联系起来，问题就变得复杂了，这里我们举个通俗的小例子类比一下：

假设，

以太坊主链=温州银行

每个分片=温州银行分行

比如：

shard1（分片1）=温州银行（杭州分行）

Shard2（分片2）=温州银行（宁波分行）

……

在这个系统中，我们就会清晰看到几大问题：1.各大分行的账本如何汇总到总行里去？2.各大分行的账本如何互联？

对应到主链和分片链系统当中来，则变成了1.分片链和主链如何实现跨链链接？2.分片之间怎么互联？甚至分叉的场景要怎么办?

分片链和主链如何实现跨链链接？

为了将分片链加入到主链中，在主链上需要有一个叫做验证人管理员合约（Validator Manager Contract）VMC的特殊合约。VMC具体是这样的：

向左转|向右转

所有的验证人把它们的保证金（stake）存入 VMC当中，这些验证人就会被收录在VMC的common validator pool验证人备选池中。系统将会“隔一段时间”根据stake权益的多少随机为每个分片抽取一名验证人，将各个分片的collation header校对头信息同步到主链中去。

这里的“隔一段时间”，我们需要额外解释一下：“时间”，也叫period周期，这到底是怎么确定的呢？答案是主要看开发人员在最终代码中的实现为准，比如说我们把周期定为5个区块，那么就意味着主链出5个区块，所有分片链分别出一个collation校对块，这就间接决定了分片链的出块时间。

这种随机的形式，使得验证者无法提前预测他们何时会成为验证者，也无法预测会成为哪个分片的验证人，从而预防作恶的可能性。

如果一旦发现我们的分片验证人作恶了，他的stake权益就会被剥夺。

跨分片通信（cross-shard communication）怎么办？

比如说一个转账方小A在分片M中，收款方小B在分片N中，小A可以通过主链这个桥梁，完成扣款操作，并创建一个带有ID的 receipt收据，代表着“自己已经完成了扣款操作”，收款方小B可以根据这个 receipt ID 创建一个receipt-consuming收据消费交易，“消费”成功了之后，收款也就成功了。

向左转|向右转

分片链分叉了怎么办？（fork choice rule）

在以往的分叉情况中，都是“以最长链为主链”，在分片当中，分叉规则是“以最长主链里面的最长分片链为有效分片链（the longest valid shard chain within the longest valid main chain）”。

什么意思呢？我们举个例子：

一条主链出现了分叉，一条分叉连续跟了两个区块，同时也跟了两个Collation校对块，另一条则是一个区块和一个校对块，那么很明显，第一条是有效链。

向左转|向右转

接下来，第二条链又加了一个区块，变成两个区块和一个Collation校对块，依然很明显，第一条链仍然是有效链：

向左转|向右转

接下来，第一条链上又加了一个区块，虽然这条链上只有一个Collation校对块，但是它的主链长度已经超过了第一条，那么第二条则成为了现在的有效链，这就是分片场景下的分叉规则，首先比较主链长度，再比较分片链长度！

向左转|向右转

以太坊分片的实现是一个漫长的过程，就连Vitalik自己也说将会分阶段来逐步实现，分片到底能不能从理论走向实践，我们还是小小期待一下吧。

参考资料：

https://github.com/ethereum/sharding/blob/develop/docs/doc.md

https://www.8btc.com/article/348469

https://ethfans.org/posts/ethereum-sharding-and-finality

http://www.qukuaiwang.com.cn/news/11390.html

后来发现原因是Docker容器后台运行,就必须有一个前台进程！容器运行的命令如果不是那些一直挂起的命令（比如运行top，ping），就是会自动退出的。

分片是指将数据拆分,将其分散存在不同机器上的过程.有时也叫分区.将数据分散在不同的机器上,不需要功能强大的大型计算机就可以存储更多的数据,处理更大的负载.使用几乎所有数据库软件都能进行手动分片,应用需要维护与若干不同数据库服务器的连接,每个连接还是完全独立的.应用程序管理不同服务器上的不同数据,存储查村都需要在正确的服务器上进行.这种方法可以很好的工作,但是也难以维护,比如向集群添加节点或从集群删除节点都很困难,调整数据分布和负载模式也不轻松.MongoDB支持自动分片,可以摆脱手动分片的管理.集群自动切分数据,做负载均衡。

设置分片时,需要从集合里面选一个键,用该键的值作为数据拆分的依据.这个键成为片键.假设有个文档集合表示的是人员,如果选择名字"name"做为片键,第一篇可能会存放名字以A-F开头的文档.第二片存G-P开头的文档,第三篇存Q-Z的文档.随着增加或删除片,MongoDB会重新平衡数据,是每片的流量比较均衡,数据量也在合理范围内(如流量较大的片存放的数据或许会比流量下的片数据要少些)

---