TCP/UDP

TCP与UDP

TCP： 一种面向连接的、可靠的、基于字节流的传输层通信协议。
UDP：一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。

  UDP具有较好的实时性 适用场景：短消息，多客户端，对信息可靠性要求不高，对效率要求高。每一条TCP是点对点的，UDP支持更广泛 一对一，多对一，多对多。TCP对资源要求较高，UDP对资源要求较少。TCP面向数据流， UDP面向数据报。

区别：

• 面向连接VS无连接
    TCP建立一个连接需要3次握手IP数据包，断开连接需要4次握手。另外断开连接时发起方可能进入TIME_WAIT状态，在此状态下连接（端口）无法被释放。UDP不需要建立连接，可以直接发起。
• 可靠VS不可靠
  TCP利用握手、ACK和重传机制，UDP没有。
  1、校验和（校验数据是否损坏）
  2、定时器（分组丢失则重传）
  3、序列号（用于检测丢失的分组和重复的分组）
  4、确认应答ACK（接收方告知发送方正确接收分组以及期望的下一个分组）
  5、否定确认（接收方通知发送方未被正确接收的分组）
  6、窗口和流水线（用于增加信道的吞吐量）。（窗口大小：无需等待确认应答而可以继续发送数据的最大值）
• 有序性
  TCP利用seq序列号对包进行排序，UDP没有。
• 面向字节流vs面向报文
  1、面向报文
    面向报文的传输方式是应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。因此，应用程序必须选择合适大小的报文。若报文太长，则IP层需要分片。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这也就是说，应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。（一个upd的最大报文长度2^16-1-20-8,20是ip报文头，8是udp报文头）
  2、面向字节流
    面向字节流的话，虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。如果应用程序一次只发送一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去。
• TCP有流量控制，UDP没有
• TCP的头部20bytes，UDP8byres

TCP应用场景：
  效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。举几个例子：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。

UDP应用场景：
  效率要求相对高，对准确性要求相对低的场景。举几个例子：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）。

补充：视频使用TCP还是UDP
　1. 网页上的视频是基于HTTP/HTTPS，传输层是TCP
　2. QQ视频聊天等是基于UDP
　3. 甚至有的应用使用p2p协议，传输层应该也是TCP
　4. 通过http进行流化视频有很多种方法
　5. 传输视频还有很多其他的应用层协议

  一方面，在网页上看视频可以忍受缓冲5s看到更清楚的视频，所以用TCP问题不大，在网络情况较好的情况下更是如此。视频聊天时绝不能容忍等待5s才听到对方的回话，所以用UDP更合适。

TCP/IP 实现可靠传输的方式

TCP协议保证数据传输可靠性的方式主要有：
校验和
序列号
确认应答
超时重传
连接管理
流量控制
拥塞控制

校验和

计算方式：在数据传输的过程中，将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。
发送方：在发送数据之前计算检验和，并进行校验和的填充。
接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。

确认应答与序列号

序列号：TCP传输时发送方给每个要发送的数据包都标有一个序列号。序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。这也是TCP传输可靠性的保证之一。
确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答，即发送ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方下一个数据包的序列号。

拥塞控制

  拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制是一个全局性的过程，和流量控制不同，流量控制指点对点通信量的控制。
  发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。拥塞窗口cwnd的维护原则：只要网络没有出现拥塞，拥塞窗口就再增大一些，但只要网络出现拥塞，拥塞窗口就减小一些。网络拥塞的依据：没有按时收到应当到达的确认报文（即发生重传）。拥塞控制的四个算法：
慢开始算法：刚开始发送TCP报文段时，先令拥塞窗口cwnd=1 （1个最大报文段长度MSS），逐次加倍。当到达慢开始门限时，改用拥塞避免算法
拥塞避免算法：cwnd每次加1。当网络出现拥塞时，慢开始门限ssthresh变为此时拥塞窗口cwnd的一半，cwnd 变为1，开始使用慢开始算法
快重传算法：当出现三个重复的ACK报文时，直接重传对方尚未接收到的报文段
快恢复：当出现三个重复的ACK报文时，开始使用快恢复算法，将拥塞窗口变为原来的一半，开始使用拥塞避免算法

为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下：
当cwnd<ssthresh时，使用慢开始算法
当cwnd>ssthresh时，改用拥塞避免算法
当cwnd=ssthresh时，慢开始与拥塞避免算法任意

慢开始与拥塞避免

慢开始
  慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。
  假设当前发送方拥塞窗口cwnd的值为1，而发送窗口swnd等于拥塞窗口cwnd，因此发送方当前只能发送一个数据报文段，接收方收到该数据报文段后，给发送方回复一个确认报文段，发送方收到该确认报文后，将拥塞窗口的值变为2，发送方此时可以连续发送两个数据报文段，接收方收到该数据报文段后，给发送方一次发回2个确认报文段，发送方收到这两个确认报文后，将拥塞窗口的值加2变为4，发送方此时可连续发送4个报文段，接收方收到4个报文段后，给发送方依次回复4个确认报文，发送方收到确认报文后，将拥塞窗口加4，置为8，发送方此时可以连续发送8个数据报文段，接收方收到该8个数据报文段后，给发送方一次发回8个确认报文段，发送方收到这8个确认报文后，将拥塞窗口的值加8变为16。当拥塞窗口cwnd的值已经等于慢开始门限值，之后改用拥塞避免算法。

拥塞避免
  每个传输轮次，拥塞窗口cwnd只能线性加一，而不是像慢开始算法时，每个传输轮次，拥塞窗口cwnd按指数增长。
  无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞，就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。

快重传和快恢复

  快重传要求接收方在收到一个失序的报文段后就立即发出重复确认而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
  快重传配合使用的还有快恢复算法，有以下两个要点:
①当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法。
②考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。

超时重传

  在进行TCP传输时，由于确认应答与序列号机制，也就是说发送方发送一部分数据后，都会等待接收方发送的ACK报文，并解析ACK报文，判断数据是否传输成功。如果发送方发送完数据后，迟迟没有等到接收方的ACK报文，这该怎么办呢？
  TCP引入超时重传机制。发送方在规定时间内没有接收到接收方的ACK时，将会重发送该数据包，并且下一次等待重发的时间成指数增长。当重发一定次数后，若还没有收到ACK，就会强制的断开连接。

连接管理

连接管理就是三次握手与四次挥手的过程

流量控制

  接收端在接收到数据后，对其进行处理。如果发送端的发送速度太快，导致接收端的结束缓冲区很快的填充满了。此时如果发送端仍旧发送数据，那么接下来发送的数据都会丢包，而TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。TCP的窗口单位是字节，不是报文段，发送方的发送窗口不能超过接收方给出的接收窗口的数值。
  TCP数据报根据首部字段来控制滑动窗口的大小。在TCP协议的报头信息当中，有一个16位字段的窗口大小。窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大，证明接收端接收缓冲区的剩余空间越大，网络的吞吐量越大。接收端会在确认应答发送ACK报文时，将自己的即时窗口大小填入，并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端。

流量控制中的死锁问题
  如图所示，说明了利用可变窗口大小进行流量控制。设主机A向主机B发送数据。双方确定的窗口值是400.再设每一个报文段为100字节长，序号的初始值为seq=1,图中的箭头上面大写ACK，表示首部中的却认为为ACK，小写ack表示确认字段的值。
  接收方的主机B进行了三次流量控制。第一次把窗口设置为rwind=300，第二次减小到rwind=100最后减到rwind=0，即不允许发送方再发送过数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。
  假如，B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwind=400的报文段，然而这个报文段在传送中丢失 了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。这样就死锁了。为了解决这种死锁状态，TCP为每个连接设有一个持续计时器。只 要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。
——————————————
  为了防止网络的拥塞现象，TCP提出了一系列的拥塞控制机制。最初提出的TCP的拥塞控制由“慢启动”和“拥塞避免”组成，后来TCP Reno版本中又针对性的加入了“快速重传”、“快速恢复”算法，再后来在TCP NewReno中又对“快速恢复”算法进行了改进，近些年又出现了选择性应答( selective acknowledgement,SACK)算法。
  快速重传算法首次出现在4.3BSD的Tahoe版本。Tahoe包含了一个TCP版本，它在连接之初处于慢启动阶段，若检测到丢包，不论由于超时还是快速重传，都会重新进入慢启动状态。有丢包情况发生时，Tahoe简单地将cwnd减为初始值以达到慢启动目的，直至cwnd增长为ssthresh。这种方法带来的一个问题是，对于有较大BDP的链路来说，会使得带宽利用率低下。因为TCP发送方经重新慢启动，回归到的还是未丢包状态。为解决这一问题，针对不同的丢包情况，重新考虑是否需要重回慢启动状态。若是由重复ACK引起的丢包（引发快速重传），cwnd值将被设为上一个ssthresh，而非先前的1 SMSS。这种方法使得TCP无须重新慢启动，而只要把传输速率减半即可。
  快速恢复首次出现在4.3BSD的Reno版本。进一步讨论较大BDP链路的情况，结合之前提到的包守恒原理，只要接收到ACK回复，就有可能传输新的数据包。Reno版中的快速恢复机制就是基于上述结论。在恢复阶段，每收到一个ACK，cwnd就能（临时）增长1 SMSS，相应地就意味着能发送一个新的数据包。因此拥塞窗口在一段时间内会急速增长，直到接收一个好的ACK。不重复的（“好的”） ACK表明TCP结束恢复阶段，拥塞已减少到之前状态。
  Reno的快速重传算法是针对一个包的重传情况的，然而在实际中，一个重传超时可能导致许多的数据包的重传，因此当多个数据包从一个数据窗口中丢失时并且触发快速重传和快速恢复算法时，问题就产生了。因此NewReno出现了，它在Reno快速恢复的基础上稍加了修改，可以恢复一个窗口内多个包丢失的情况。具体来讲就是：Reno在收到一个新的数据的ACK时就退出了快速恢复状态了，而NewReno需要收到该窗口内所有数据包的确认后才会退出快速恢复状态，从而更一步提高吞吐量。
  SACK就是改变TCP的确认机制，最初的TCP只确认当前已连续收到的数据，SACK则把乱序等信息会全部告诉对方，从而减少数据发送方重传的盲目性。比如说序号1，2，3，5，7的数据收到了，那么普通的ACK只会确认序列号4，而SACK会把当前的5，7已经收到的信息在SACK选项里面告知对端，从而提高性能，当使用SACK的时候，NewReno算法可以不使用，因为SACK本身携带的信息就可以使得发送方有足够的信息来知道需要重传哪些包，而不需要重传哪些包。

TCP/IP 实现高性能传输的方式

• 滑动窗口
    在保证TCP传输的可靠的性的时候，其中有一条就是确认应答。倘若是每发送一条数据，就等待一次ACK应答的话。大量的时间就会浪费在数据的往返上，这样性能会大大降低。如果能够一次发送多条数据，就可以大大的提高性能（实质是将多个数据等待的ACK响应时间重叠）。
    滑动窗口有效的缓解了这个问题。窗口大小：指的是无需等待确认应答而可以继续发送数据的最大值。操作系统为了维护这一个滑动窗口，需要开辟缓冲区来记录当前还有哪些数据没有应答，只有确认过应答的数据，才能从缓冲区删了。这个缓冲区被称作“发送缓冲区”。因此，窗口越大，网络的吞吐率就越高。
    滑动窗口处理丢包问题主要有两种情况：发送端发送的数据丢包、接收端的ACK响应丢包。
    对于发送端发送的数据丢包：例如1001~ 2000的数据报文丢失，此时发送端并不知道，继续发送滑动窗口内的报文。这时候接收到了三条重复的ACK响应（TCP协议规定，收到三条相同的ACK响应就出发重传）。此时重传1001~ 2000的数据报文。重传完毕后，等待接收端的响应。此时接收端响应为下一条是6001的数据报文，也就是说在2001~6000的报文都接收到了，这段报文被放到了接收端的接收缓冲区中。那么此时滑动窗口继续移动，发送端继续发送。这个接收到三个重复的ACK响应，就开始重传响应所要求的报文的机制就是快重传速机制。注：快重传机制与超时重传机制不同，超时重传机制应用于没有任何一条ACK响应收到，而超时时间已经到达，则出发超时重传；而快速重传机制是接收到了重复的三条ACK响应才触发。
    接收端ACK响应丢包：接连三条的ACK响应都丢包，但是第四条ACK响应到达。此时并不会影响发送端的发送。因为ACK响应的是下一条数据包是4001，这意味着接收端已接收到前面的所以报文数据。所以接收端ACK响应丢包其实对发送端发送的影响并不是那么大，后续的ACK响应能够处理好这个问题。
• 快速重传
• 延迟应答
    接收数据的主机如果立刻返回ACK应答，返回的窗口可能比较小。假设这样一种情景，结束缓冲区为1M，一次收到500K的数据，如果立刻应答，返回的窗口就是500K，但实际上可能处理的速度非常快，很短的时间就将500K的数据从缓冲区消费掉了。接收端的处理能力可能远比这个大，如果稍微等一段时间再进行应答，返回的窗口可能就会为1M。所以，接收窗口越大，网络的吞吐量就越大，减少应答数量，传输效率就越高。但是不是所有的包都可以延迟应答，会有一些限制。数量限制：每隔N个包就应答一次。时间限制：超过最大延迟时间就应答一次。数量限制和时间限制，在不同的操作下也会有不同，一般N取2，超时时间取200ms。
• 捎带应答
    在两主机之间通信时，常常采用捎带应答的方式来提高效率。而ACK响应常常伴随着数据报文共同传输。比如说TCP连接的三次握手时，在服务器收到SYN请求报文后，也会给客户端发送SYN请求，这时候服务器对于刚才客户端SYN请求的ACK应答就随着服务器发送的SYN请求一并过去，这个过程就是捎带应答。

TCP如何解决丢包问题

  TCP协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP基于不可靠的网路实现可靠传输，肯定会存在丢包问题。例如：有2台服务器 ，A和B服务器。A服务器发送数据给B服务器频率过高时，B服务器来不及处理，造成数据丢包。如果A服务器不对发送频率进行控制，或者数据进行重发的话，那么B服务器收到数据就会少，就会造成丢失数据。为了满足TCP协议不丢包。TCP协议有如下规定：

1. 数据分片：发送端对数据进行分片，接受端要对数据进行重组，由TCP确定分片的大小并控制分片和重组

2. 到达确认：接收端接收到分片数据时，根据分片数据序号向发送端发送一个确认

3. 超时重发：发送方在发送分片时设置超时定时器，如果在定时器超时之后没有收到相应的确认，重发分片数据

4. 滑动窗口：TCP连接的每一方的接受缓冲空间大小固定，接收端只允许另一端发送接收端缓冲区所能接纳的数据，TCP在滑动窗口的基础上提供流量控制，防止较快主机致使较慢主机的缓冲区溢出

5. 失序处理：作为IP数据报来传输的TCP分片到达时可能会失序，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层

6. 重复处理：作为IP数据报来传输的TCP分片会发生重复，TCP的接收端必须丢弃重复的数据

7. 数据校验：TCP将保持它首部和数据的检验和，这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到分片的检验或有差错，TCP将丢弃这个分片，并不确认收到此报文段导致对端超时并重发

TCP三次握手 四次挥手