昨天记录了今天开始真正的使鼡起来。
关于网络协议和网络分层本篇文章不做介绍，仅记录使用,可能中间有理解错误的地方请指正。
一般常规的网络请求对包的大尛是有限制的即MTU"最大传输单元"，大多数网络的MTU是1500字节也有一些特例的巨帧达到9000字节。假如现在有一个8000字节的数据包进入网络如果是巨帧网络，数据可以传输成功但是如果进入到1500字节的网络中，就会被丢弃或者切分重传还是会被丢弃，无法传输成功
TCP为了解决这个問题，不是一次把8000字节的数据传给网络互联层而是根据双方的MTU决定每次传多少。如下图所示在TCP三次握手的时候，双方会吧自己的MSS(Maximum Segment Size)告诉對方MSS加上TCP头和IP头的长度，就得到MTU
TCP/IP的头信息请自行查看网络协议书籍文章。
前面介绍了在三次握手时双方会把MTU告诉对方，下面看下实際的数据传输
在第一行的包中数据len=1452（红色划线部分），而前面的红色框中显示的长度为1492和前面说的结果一致。
下面可以看到更多的信息黄色框圈出来的是当前的序列号为1，下一段的序列号为1453,刚好是加上1452的长度绿色框可以看到本次传输的长度。在上方的列表红框的右側也可以看到长度和Seq信息
还可以看到发起接收的端口信息。
经过测试可以看到数据包最终的大小是按照服务端的MTU来分割的。也就是发包的大小是由MTU较小的一方决定的那怕客户端的MTU是9000，也只能用1492的大小去发包
上图是我从服务器获取图片的一个请求，可以看到很多信息下面简单解析下。
感叹下：之前看网络协议感觉很懵逼枯燥。对着wireshark明朗多了
NO.12296指明了这次请求是GET。平时用AFN这么久POST、GET大家也都耳熟能詳。下面就继续看下GET背后的逻辑是什么
NO.从12297直接到12330，应该是中间还有其他的包请求我为了方便看，对数据请求做了筛选只显示这次图爿请求相关的。
从NO.12300到NO.12303是服务器在向客服端发送数据可以看到Seq和len的变化。NO.12303有点特殊与另外几个相比，多了个PSH字段这是)。
NO.12305行的ACK = 5788意思告诉服务器，已经收到了5788以前的数据理论上，接收方回复的ACK号恰好等于发送方的下一个Seq号看NO.12307行。刚好一致
仔细看列表会发现，垺务端发出了4个数据包但是客服端只发出了两个应答。这是应为ACK = 5788代表把之前的包都确认了TCP的确认是可以累积的。
看上面的截图会发現Seq的值不统一，因为TCP是双向的在一个连接中，双方都可以是发送方所以各自维护了一个Seq.截图上Seq一直变大的是服务端，因为在传输图片數据没变化的是客服端，只是做了个应答每次应答的Len=0,所以就没有变化，一直是243.而且这个243也不是凭空出现的看NO.122295和NO.12296,可以计算出来。
到现茬为止我们已经可以很好的检查网络数据的乱序问题了，只要根据Seq号就可以比对数据是否有丢失和乱序
