写这篇文章前，我有些肺腑之言想感谢一下我的微信好友“风大”。 是他给了我信心，原来没有很难的技术，只要你肯努力总能赶上其他人。 后来关注他的博客后，发现他尽然觉得弄懂hashmap的 最好办法是自己实现一个hashmap。一开始我也是不懂为什么要这样，后来发现读懂hashmap之后，再自己实现的时候，刚好可以读懂hashmap中那些设计巧妙的地方，发现自己与大师的差距。最后我也总结了一个学习方法：
先弄懂一个技术怎么样，再考虑如果是自己去设计会是什么样子，一开始就算是抄，抄多了你就会自己写了。
之前写过一个springMVC的小轮子，后来看spring事务机制的时候 ，又写了一个TransactionManage。
这些东西就像高冷的美女，只有你征服她时，你才能感受到她平凡而又不普通的一面。
开始进入话题：
两个物理节点之间的网络传输 如果不建立在7层网络模型或者是5层网络模型的基础上，一定是不安全的。
那为了让网络传输变得安全，所以5层网络模型就每层都加了点东西，来给我们的网络传输带来一些保障。
没有数据链路层，你怎么把数据打包发出去呢？
没有网络层，你怎么把你的爱说给你的女神呢？
没有传输层，你怎么保证你的女神就能收到你的爱呢？
没有应用层，你女神怎么知道你按什么协议来发，他按什么协议来接呢？HTTP 还是 FTP？
好的，今天我们重点来谈谈，传输层怎么让女神收到你的爱。一分不多，一分不少。
在网络传输的过程中，经常会出现丢包，重复包，发错了，发的顺序不对等各种各样的问题。
在传输层中使用的协议是 TCP/IP协议。
TCP协议 维持着 发送方 and 接收方 的缓冲区、 双方商定包的重传机制。接收方如何来ack 发送方发过来的包。
首先我们看看 如果生活中的两个人发消息是怎么发的，然后映射到网络上：
发送方发一个包1，接收方就确认一个包1，这样看起来，逻辑上并没有问题。
不会出现丢包呀，发重复包，发错包了，发的顺序不对的情况。
但是，问题来了，一个数据包的大小并不大，你一来我一回的，就导致了这个方案，发送消息的吞吐量上不去。如果你了解一些操作系统，多线程方便的知识，或者看过我之前关于cpu处理能力及redis 为什么是单线程的文章，
你一定知道，对于硬盘，还有网络这种“慢速通道”，频繁的多次IO绝不是一个好的方案，是可以将多次请求放到一个buff中，然后统一由这个buff 把多个消息拼在一起发送过去的。
所以改进的方案就来了，我可以将多个消息放在一起再发送过去，然后对方也可以一次性接受多个消息，只要顺序是对的就可以了嘛，我们接着来看怎么做。
滑动窗口协议就随之产生了：
滑动窗口协议是传输层进行流控的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致接收方接受不赢，导入数据丢失的问题。
关于滑动窗口协议可以使用搜索引擎或者上知乎了解:TCP协议的滑动窗口协议
看看滑动窗口协议是什么样子的：
如果传输的过程中丢包了怎么办呢？
发送方丢包了，接收方不会回复ack标识，同时又因为接受方的滑动窗口大小是已经确定了的。所以并不会发送后面栏位的包。
那自然丢包了就要重发~ 重发的时候是什么样呢？
发送方发5号包，丢包时，滑动窗口协议会继续的把6 7 号包发过去，但是接收方并没有收到5号包，滑动窗口协议，为了保证 传输的顺序，接收方不会把 6 7号包的ack给发送回来，
只有在5号包重发后，并且接收方接收到了五号包的时候，接收方才会将 5 6 7 号包的ack 再重新返回。
5 6 7号包的 ack 返回后， 滑动窗口又可以向右移动三位 去传 12 13 14号包了。
这样丢包的问题通过重发就解决了。