解释：Alice要给Bob发送的内容希望是可靠，安全的；而实际物理线路是不可靠不安全的，所以搭建了网络的七层架构
解决方法：
-
数据链路层：提供一个最小的传输单位——数据包，可以通过奇偶校验等校验方法来校验这个包是否正确，这样就完成了一个节点到另外一个节点的数据包的传递。而且传过去后，接收节点可以知道这个数据包是正确的还是错误的。（这样在同一个实验室的Alice和Bob就能相互传输数据，但是对于不同实验室的呢？所以要通过网络层）
数据链路层.png -
网络层：有路由，Alice会把自己的数据包发送给实验室的路由器，然后路由器再发送给其他路由器，可能会转很多层，最后发送到了Bob。同时，为了标识在网络中的各个节点，使用了一个IP协议，每一个节点都有一个IP地址。（但是在数据链路层虽然能够知道包是正确的还是错误的，蛋不能保证其是可靠的，所以需要一种出错重传机制，能够在出错的时候重传这个包而不需要Alice不断去检验这个包是否发送成功，所以有了传输层）
网络层.png -
传输层：有了TCP和UDP协议，TCP协议是基于连接的，会在Alice和Bob之间，建立可靠的连接，在连接上传输数据。（能够传输数据了，但是是为哪个应用服务的呢？HTTP?FTP?还是其他？所以需要有应用层）
传输层.png -
应用层
图片.png
这样就有了五层协议：物理层，数据链路层，网络层，传输层，应用层
网络传输
滑动窗口
- TCP协议中使用
- 维持发送方/接收方缓冲区（解决不可靠问题）
在没有滑动窗口的前提下，如何保证包的可靠？
-
发送一个包确认一个包。问题在于吞吐量很低
问题.png -
改进，发送两个包，确认两个包。问题，每次发多少个包呢？多少个包最优呢？或者同时发送了包1和包2，收到了确认包1的消息，能否收到确认后直接发送第三个包而不是等待包2的确认后才发？
图片.png -
滑动窗口初始化：一共有16个包，希望按照顺序发包，每个包对方都给予确认（即ACK）。 比如1、2、3号包已经收到了Ack，说明这些包已经确认过了。4、5、6、7包是已经发送但未Ack的，不知道对方有没有收到，8、9、10是未发送的，是接下来马上要发送的。
滑动窗口.png -
滑动窗口正常情况下：收到包4的确认，滑动窗口向右移动一个位置，在这段时间又把8和9发送过去但未收到确认。
zhengchang.png 滑动窗口丢Ack: 可能是包丢了，也可能是Ack没收到。 比如一直等Ack, 一直没等到， 就把10和11都发送，但是这个时候窗口已经满了，就不能把12读进来，接下来就始终等待Ack的产生。这样用到了超时重传机制。对于Ack，对方必须按照顺序Ack,比如对方收到了6-11的包，但不能返回对应的Ack,必须收到包5后Ack.
-
滑动窗口重发:比如对方一直在等包5，经过超时重传后，对方重新接收到包5就把5-8的Ack一起返回，之后窗口右移，
图片.png
TCP连接
最开始三行中可以看到SYN、[SYN、ACK]、ACK的字样，标识三次握手
TCP Segment Len代表TCP里的内容，除去头部之外是0
Sequence number是滑动窗口中的编号
访问imooc.com后得到的回复
Acknoeledgment number是1， TCP里面的Acknoeledgment number是期待对方发第几个包，第0号包收到后就希望对方发1号包
Flag一个是SYN，一个是ACK，代表接到了请求并愿意建立连接
第三次握手
HTTP协议
然后按照滑动窗口，进行发送和接收
