网络：TCP与UDP总结
TCP与UDP都是传输层得协议
一、UDP
- udp是面向数据报文、无连接，不可靠得传输层协议
无连接：只知道对端的IP和端口号就可以发送，不需要实现建立连接。
不可靠：不保证数据能够发送到对端、丢包之后也不会重传等措施
- udp支持一对一、一对多、多对多、多对一得连接方式
- udp一般用于实时通话、直播等领域
常见使用UDP传输得应用层协议：
- DNS：域名解析系统
- DHCP：IP分发系统
二、TCP
- TCP是面向连接，可靠得传输层协议
连接：每次都需要三次握手来建立连接，四次挥手来释放连接
可靠：保证数据传输到对端，丢包会重新发送，还提供了拥塞控制等措施
1、三次握手
TCP的三次握手可以确保连接双方都具有收发的能力
首先客户端发送请求连接SYN，并带上自己的序列号
客户端表示我想要和你建立连接
服务端接收到之后，需要发送ACK确认请求，并且也要发送SYN请求连接，并带上自己的序列号
服务端表示收到，我也想要和你建立连接
客户端收到服务端的确认及请求连接之后，会再发送一次ACK确认请求，该次请求是可以带上数据的
客户端表示收到
这样就建立了连接
之后的每次请求都需要客户端发送一次确认来保证数据的正确到达，当然如果每次都需要一个请求来应答，比较耗费性能，TCP提供了拥塞窗口，后续会讲到
2、四次挥手
TCP需要客户端和服务端都发送断开连接请求
当客户端想要断开请求是，会发送FIN请求
客户端表示我想走了
服务端收到客户端的断开请求后，会发送ACK请求，确认收到
服务端表示收到
在收到客户端的断开请求之后，可能服务端还有数据没有发完，等发完之后，服务端也会发送一个FIN请求断开连接
服务端表示我也想走了
客户端收到服务端的断开连接请求之后，会发送最后的一个ACK确认请求，发送之后，客户端还会等待2MSL的时间，保证服务端能够收到
客户端表示收到
- MSL：
MSL是TCP报文在发送缓冲区的最大生存时间通过TCP的三次握手和四次挥手很好的看到TCP的这种一发一确认的流程
每一个请求都需要一个确认来保证请求被准确的传递
3、重发超时的确定
重发超时是指在重发数据之前，等待确认应答到来的那个特定时间间隔。如果超过这个时间仍未收到确认应答，发送端将进行数据重发。
在 BSD 的 Unix 以及 Windows 系统中，超时都以0.5秒为单位进行控制，因此重发超时都是0.5秒的整数倍。不过，最初其重发超时的默认值一般设置为6秒左右。
数据被重发之后若还是收不到确认应答，则进行再次发送。此时，等待确认应答的时间将会以2倍、4倍的指数函数延长。
数据也不会被无限、反复地重发。达到一定重发次数之后，如果仍没有任何确认应答返回，就会判断为网络或对端主机发生了异常，强制关闭连接。并且通知应用通信异常强行终止。
4、拥塞窗口
前面提到过，拥塞窗口是为了解决TCP每次发送都必须收到对方的确认才可以继续这样带来的性能损耗
- 滑动窗口控制
拥塞窗口采用滑动窗口的方式
窗口大小指的是无需等待确认应答而可以继续发送数据的最大值
上图中的窗口内的请求即便没有收到确认应答也可以被发送出去。不过，在整个窗口的确认应答没有到达之前，如果其中部分数据出现丢包，那么发送端仍然要负责重传。为此，发送端主机需要设置缓存保留这些待被重传的数据，直到收到他们的确认应答。
在滑动窗口以外的部分包括未发送的数据以及已经确认对端已收到的数据。当数据发出后若如期收到确认应答就可以不用再进行重发，此时数据就可以从缓存区清除。
收到确认应答的情况下，将窗口滑动到确认应答中的序列号的位置。这样可以顺序地将多个段同时发送提高通信性能。这种机制也别称为滑动窗口控制。
- 窗口控制中的重发控制
① 确认应答未能返回的情况。在这种情况下，数据已经到达对端，是不需要再进行重发的
比如：上图中的发送了1001之后没有收到确认应答，但是在发送1002的时候收到了
下一个1003的确认应答，则表示1001已经被正确收到
② 某个报文段丢失的情况。接收主机如果收到一个自己应该接收的序列号以外的数据时，会针对当前为止收到数据返回确认应答。
当某一报文段丢失后，发送端会一直收到序号为1001的确认应答，因此，在窗口比较大，又出现报文段丢失的情况下，同一个序列号的确认应答将会被重复不断地返回。
比如：上图中的发送了1001之后没有收到确认应答，在发送1002 的时候收到了
下一个1001的确认应答，则表示1001丢失了
发送端主机如果连续3次收到同一个确认应答，就会将其对应的数据进行重发。这种机制比之前提到的超时管理更加高效，因此也被称为高速重发控制。
5、拥塞控制
有了拥塞窗口解决了一发一确认的性能损耗，但是由于不了解不同网络状态，仍可能产生其他问题，比如：对方的网络状态很差，一时间处理不了这么多请求，就会照成堵塞。
TCP提供了慢开始、快重传、拥塞避免、快恢复
- 慢开始
假设当前发送方拥塞窗口cwnd的值为1，而发送窗口swnd等于拥塞窗口cwnd，因此发送方当前只能发送一个数据报文段（拥塞窗口cwnd的值是几，就能发送几个数据报文段），接收方收到该数据报文段后，给发送方回复一个确认报文段，发送方收到该确认报文后，将拥塞窗口的值变为2
当然慢开始也是有限制的，不可能让它一直这样增长，当前的拥塞窗口cwnd的值已经等于慢开始门限值，之后改用拥塞避免算法
- 拥塞避免
，拥塞窗口cwnd只能线性加一，而不是像慢开始算法时，每个传输轮次，拥塞窗口cwnd按指数增长。同理，16+1……直至到达24，假设24个报文段在传输过程中丢失4个，接收方只收到20个报文段，给发送方依次回复20个确认报文段，一段时间后，丢失的4个报文段的重传计时器超时了，发送发判断可能出现拥塞，更改cwnd和ssthresh.并重新开始慢开始算法
- 快重传
快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期
- 快恢复
采用快恢复算法时，慢开始只在TCP连接建立时和网络出现超时时才使用。
当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法。
考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。
参考链接：
