网络

网络传输要解决的问题

• alice想要可靠的发送信息给bob,但是在网络的传输过程可能是不可靠的，网络可能中断，可能信息被黑客窃听，那么解决这些问题就变得很重要。

net01.png

为什么要有4层网络架构

net02.png

网络不可靠不安全体现在哪些方面，对应的解决方法

• 丢包，重复包
• 出错
• 乱序
• 中间人攻击
• 窃取
• 篡改

滑动窗口

• 维持发送方和接收方缓冲区，用来解决传输不可靠的问题

• 如何确认对方接收到包？

  
  net03.png
  

  问题： 这解决了正确传输包的问题，但是效率较低，于是有了改进方法，一次传输多个包。

  
  net04.png

问题： 上图中发送的效率得到了提高，但是同时发送的多个包中，可能会出现丢包的情况，如何解决丢包的问题，这里就用到了滑动窗口的概念。

net05.png

• 灰色：代表已经收到对方确认的包
• 黄色： 代表已经发送给对方，等待对方确认
• 绿色： 代表新划入滑动窗口缓冲区的包，待发送未确认的包。

正常的流程：
（1）先发送的包1 2 3收到了对方的确认
（2）滑动缓冲区中的4,5,6,7号包已经发送，对方还没有确认
（3）滑动缓冲区中的8，9，10号包是新加入缓冲区包，保持缓冲区7个包的大小
（4）这时候如果收到了4号包的确认，那么滑动窗口向前移动一个包的位置，整个窗口的大小不变仍然保持7个包的大小。
（5）以此类推，确认了几个包，滑动窗口就移动几个包的位置，同时保持7个包缓冲区的大小不变。

出错的流程：

net06.png

(1) 假设5号包丢掉了，那么此时可能6，7，8，9，10，11都已经到达了对方，但是由于要按顺序确认，所以即使6，7，8，9，10都正确的收到了，也没有办法回复给发送方ack。
(2) 此时需要重传。 重传后对方正确收到了5号包，这时候可能一起回复了5，6，7，8号包的确认，看到上图中的5，6，7，8包变成灰色。这是后恢复了正常传输过程。

三次握手，四次挥手

工程思路

• 网络是不可靠的，任何包都有可能丢失
• 遇见问题，解决问题，不断迭代

• 能用就好

  
  net08.png
  

  (1) 首先服务器处于Listen状态
  (2) 客户端发送SYN给服务端，同时自己的状态置为SYN_SENT状态
  (3) 服务器端收到syn包后，将自己的状态置为SYN_RECEIVED状态
  (4) 此时为了告诉客户端，我收到了你的包，所以回复了SYN ACK包
  (5) 此时客户端收到了服务器端发送的SYN ACK包，表示已经可以建立连接了，所以将自己的状态置为ESTABLISHED
  (6) 客户端为了告诉服务器我收到了你的SYN ACK包，所以回复了一个ACK包给服务器端，此时服务器端的状态置为ESTABLISHED
  (7) 开始正常的传输数据

基本的逻辑就是：如何让对方知道自己的状态，所以要多次的确认，但是确认总要有个尽头，所以大家觉着经过这样的三次就可以了。

net10.png

(0) 由于服务端和客户端都可以发起断开连接，所以这里双方是发起方和接收方的
(1) 发起方，发送FIN表示要断开连接，并将自己的状态设置为FIN_WAIT_1
(2) 接收方，收到后发送ACK给接收方，并将自己的状态设置为CLOSE_WAIT。(这里为什么不是发送ACK,FIN而只是发送了ACK?)
(3) 发起方，接收到ACK后将自己的状态设置为FIN_WAIT_2
(4) 接收方发送FIN给发起方，同时将自己的状态设置为LAST_ACK
(5) 发起方，接收到FIN后，发送ACK给接收方，同时将自己的状态设置为TIME_WAIT
(6) 接收方，接收到ACK后，将自己的状态设置为CLOSE
(7) 发起方，过了TIME_WAIT时间后，自己的状态变为CLOSE

问题：
为什么断开连接是4次?
为什么回复FIN,只有ACK 而不像三次握手一样是FIN,ACK?
为什么会有一个TIME_WAIT的状态

比喻：

net09.png

TCP及滑动窗口的常见问题

• 谈谈TCP协议及滑动窗口的常见问题
  保证包传输的正确性
  流量控制
  拥塞控制
  滑动窗口解决了什么问题