- 自动重传请求（ARQ、平均往返时间）
- 流量控制 （接受窗口rwnd）
- 拥塞控制（拥塞窗口cwnd）
0、概述：
众所周知，TCP/IP是面向链接的可靠传输协议，但是问题是如何实现可靠传输的呢？在我看来，TCP/IP可靠传输的基础是滑动窗口协议和连续ARQ协议，配合着流量控制和拥塞控制，使得整个传输过程保证：
传输信道不产生差错
不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据（通过累计确认、超时重传、拥塞控制三大模块保证）
1、停止等待协议和自动重传请求(ARQ)
所谓停止等待协议就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。但是在传输过程中可能出现意外，这时候就需要用到ARQ协议了，比如说：B可能没有收到A发送的M1M1
这时候A就会有个超时计时器，当超时计时器到期时没收到B的确认报文，则A重新发送M1M1，因此必须保证以下几点：
A发送完一个分组后，必须暂时保留已发送的分组副本，只有收到确认后才能清除分组副本
分组和确认分组都必须进行编号
-
超时计时器设置的重传时间应当比数据在分组传输的往返时间更长一些
如果A对于B的发送的数据有一定的延迟，但是B接收到了后A还是重新发送了同样的数据（可能超时了A认为丢包所以重新发送了），对于重复的数据包和响应信号AB都会不会再处理。
2、以字节为单位的滑动窗口（累计确认方式）
为了提高信道的利用率，实际上采用了流水线传输的方案。
这时就需要使用连续ARQ协议和滑动窗口协议。发送方和接收方各自维持着发送窗口和接受窗口，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。接收方一般采用累计确认方式，即接收方不必对收到的分组逐个发送确认，而是可以在收到几个分组后，对按序到达的最后一个分组发送确认，这样就表示：到这个分组位置的所有分组都已经正确收到了。
- A向B发送数据，B的初始滑动窗口的大小是20；因此A只能发送滑动窗口大小内的数据，在发送了20个字节的数据且没有得到B的相应ACK信号的之前无法继续发送了；A不是发一次数据就要等B相应再发下一次数据，而是不断发送自己在发送窗口内的数据，直到发完。
- B接收到1到6的数据包后会发出相应ACK信号（应该是接收到一部分数据后暂时没有新的数据B就会去相应），此时ACK中的seq=7，告诉A要发序列号为7后面的数据了；
- A再接收到相应信号ACK后滑动自己的窗口到序列号为7的位置，此时A中1到6的数据就没有必要一直存放了，可以删掉了；此时A还可以继续发送滑动窗口中之前未发送的21到25字节的数据；
-
B在确认收到1到6的数据后，B这边的应用程序就可以开始处理这些确认过的数据了。同时B还会继续确认A发送过的数据了
如果出现丢包TCP协议是怎么处理的？
- A向B发送数据，但是由于网络原因导致部分丢包（7、8、9）
- B发现自己没有收到7开头的数据包（但是收到了10、11、12的数据包），因此就会发送选择性ACK信号，seq=7，这样A收到该选择性确认后就知道自己之前发送的（7、8、9）的数据包已经丢失了，需要进行重传，同时也知道了1到6已经接受了，就不继续发送10、11、12了。
2、超时重传时间选择
RTT表示往返时间，其中的s表示甲醛平均的意思？
