TCP/IP

1.TCP如何实现可靠性传输

****1.1通过序列号&确认应答
TCP应用中，发送端向接收端发送数据时，在接收端收到之后，会向发送端回复一个确认代表已经收到，对于发送端来说，如果某个数据包没有收到回复只要重传就可以，而对于接收端，如果反复收到来自发送端的重传数据，这将是灾难性的，如果每次收到数据包都处理显然是不现实的，接收端就要一种机制来确认是否需要接收数据；序列号是发送端顺序发送的每一个数据包的序列号，接收端收到数据包之后，解析这个序列号以及数据长度，并且将二者之和作为自己下一次收包的序列号，这样实现了可靠的传输

1.2 超时重传
超时重传是指发送出去的数据包到接收到确认包之间的时间，如果超过了这个时间会被认为是丢包了，需要重传。那么我们该如何确认这个时间值呢？在一个稳定的网络环境中，一个数据包的收发时间是差不多的，都会有一个类似于平均值的概念。比如发送一个包到接收端收到这个包一共是0.5s，然后接收端回发一个确认包给发送端也要0.5s，这样的两个时间就是RTT（往返时间）。当然，随着网络拥堵等环境的变化，时间会有偏差，如果我们可以设置一个合理的超时门限，也将大大保证TCP包重传的稳定性；
1.3 连接控制
TCP是面向连接的协议，双端在发送数据之前，必须进行连接，才可以通信，在通信完成之后主动断开连接，断开连接之后，将不在处理收到的发送端的任何数据包，连接与断开连接流程如下：

1.4TCP以段为单元传输
在此之前我们说过，IP层数据包的传输单元是MTU，在传输层，其最小传输单元是MSS，这个值最理想的情况就是

长度不至于在IP层分包，以此简单分包对于性能的损耗；MSS在TCP建立连接时协商得到，双端在建立请求时分别告诉对端自己的传输单元，然后本次连接将采用最小值进行传输，报文内容如下
//syn

//ack 确认长度

1.3 滑动窗口
TCP传输是以段位传输单位，每发送一个段，接收端就需要一次应答，按照这种方式来传输的话，TCP的性能将会大打折扣，为了解决这个性能问题，就引入了滑动窗口的概念，简单来说就是，扩大TCP传输单位，即一次传输多个数据包，同时，接收端也需要进行多次应答，如果其中一个数据包没有收到应答，发送端应该继续保留这部分数据并且进行重传，直到收到应答，再将缓存区这部分数据删除。
几个注意的点：
1.TCP滑动窗口并不是越大越好；
2.发送的窗口 <= 接收端窗口；
3.滑动窗口的大小是需要根据网络拥堵情况动态调整；
4.窗口大小由接收端决定；

2.窗口控制如何实现高效传输？

（1）减少不必要的重传，在发送单个数据段必须对应收到应答报文的传输过程中，如果丢失了一个数据包，就必须要进行重传，而设置了滑动窗口的传输过程中，如果仅仅丢失了一个数据包，可以根据后续应答报文的序列号进行复判是否需要重传。
2）在快速响应重传，在发送单个数据段必须对应收到应答报文的传输过程中，如果发送端没有收到应答报文，只能依赖超时机制进行检测，而在滑动窗口的传输过程中，由于发送端在反复发包，如果中间丢失了一个报文，接收端可以通过应答报文的序列号快速响应，如果连续收到几个ack序列号一致，那么就认为数据丢失，可以快速进行重传，效率相对较高；

3.流量控制

为了解决TCP单段传输的性能问题，我们引入了滑动窗口的概念，允许TCP一次发送多个数据包，接收端进行多次确认，那么试想，如果网络环境比较拥堵，发送端在发送多个数据包的时候，丢失了其中几个包，如何保证传输数据的可靠性？如果窗口设置太多，发送端不停的发送数据包，而接收端处理效率低于发送端，造成的流量阻塞如何解决？
流控制解决网络拥堵问题
接收端的应答报文中（TCP首部）会包含一个窗口字段，这个字段也代表了接收端数据缓存区的大小，这个值越大代表网络的吞吐越大；如果接收端因为环境拥堵或者CPU性能限制，这个值也是逐渐减小，平滑的处理性能问题；
这里两个代表的算法名称就是：
快重传算法：快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时才进行捎带确认。接收方收到了M1和M2后都分别发出了确认。现在假定接收方没有收到M3但接着收到了M4。显然，接收方不能确认M4，因为M4是收到的失序报文段。根据 可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认。但按照快重传算法的规定，接收方应及时发送对M2的重复确认，这样做可以让 发送方及早知道报文段M3没有到达接收方。发送方接着发送了M5和M6。接收方收到这两个报文后，也还要再次发出对M2的重复确认。这样，发送方共收到了 接收方的四个对M2的确认，其中后三个都是重复确认。
快恢复算法：与快重传配合使用的还有快恢复算法，其过程有以下两个要点：当发送方连续收到三个重复确认，就执行“乘法减小”算法，把慢开始门限ssthresh减半。与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为 慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大
慢启动算法，发送方维持一个拥塞窗口 cwnd ( congestion window )的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。
慢开始算法：当主机开始发送数据时，如果立即将大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的方法是 先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ，可以使分组注入到网络的速率更加合理。每经过一个传输轮次，拥塞窗口 cwnd 就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。不过“传输轮次”更加强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。
拥塞避免算法：让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送 方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生 拥塞的路由器有足够时间把队列中积压的分组处理完毕