锦囊篇｜一文遨游运输层

前言

在现实生活中，我们基于的网络都是基于TCP/IP模型建立的，但是这篇文章我们主要讨论的是TCP层，当然你也同样可以叫他传输层/运输层。

在这个层次中，涉及了两个非常重要的协议：TCP、UDP。之后将对这两个协议做一个着重的介绍。

TCP/传输控制协议

TCP作为传输层的重要协议，首当其冲的自然就是面试中最常见的两个问题三次握手、四次挥手了。

三次握手

他的终极目标是为了确认双方是有完备的接收响应能力和发送能力的。

握手的实现顺序：

1. 第一次握手:客户机向服务器发出包SYN。服务器确认了客户机有发送能力。
2. 第二次握手:服务器确认客户机的包SYN，发送给客户机包SYN+ACK。客户机确认了服务器有接收相应和发送能力。
3. 第三次握手:客户机确认服务器的包SYN+ACK，发送包ACK+Data给服务器。服务器确认了客户机有接收响应能力。

从第三次握手开始，我们就已经可以带上我们的数据进行传输了。

Q1：为什么采用三次握手而不是二次握手的原因：

为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生资源浪费。

简单的说就是:1号请求发出后，因网络原因延迟导致客户端重新发起了2号建立连接请求报文，当2号请求报文与服务器建立连接并断开后，1号请求连接到达。采用二次握手导致服务器进入连接状态，而客户端去进行响应的时候发现已经是正在连接状态的资源，直接抛弃并不会通知服务器，造成服务器资源的消耗。

其实从另外一个角度看，这是一个两军对垒的问题。

讲个故事好了，一天吴军想打魏国，蜀军这天也想打魏国，但是他们单独的兵力攻克不下魏国，他们看到对方，都想借对方军力灭了魏国。这个时候，吴军选择先派出使者去发出同盟请求，并协定以狼烟作为信号 （第一次握手开始） ，但是会途径魏国啊，那可能使者就有掉脑袋或者被偷换的可能了 （数据包丢失或者数据位出错） ，到了蜀军以后，蜀军认可了这次的行动，然后送走了来使 （第一次握手成功，第二次握手开始） ，当然中间又要路过魏国，有可能出现上述情况。吴军收到了蜀军的回信，十分高兴，吴军立刻点了狼烟，就要告诉蜀军要冲去灭魏国了。（完成第二次握手，发出数据，开始第三次握手）

四次挥手

四次挥手就没有这么精彩的故事了，就平淡点讲一下好了。

挥手的实现顺序：

1. 第一次挥手:客户机向服务器发送包FIN。
2. 第二次挥手:服务器确认客户机的包FIN，发送给客户机包ACK。服务器确认了客户机需要关闭资源。
3. 第三次挥手:服务器向客户机发送包FIN。
4. 第四次挥手:客户机确认服务器的包FIN+ACK，发送给服务器ACK，完成挥手。客户机确认了服务器需要关闭资源。

Q1：为什么要实现四次挥手呢？

其实这是为了关闭双方的资源，和三次握手并不一样，三次握手的主体是客户端，而四次挥手的主体是两者，因为两者都需要确保自己的资源完成关闭。

可靠数据传输原理

先来想一下TCP是依靠什么样的机制来完成可靠数据传输的：

1. 检验和
2. 确认
3. 重传
4. 计时器：当 客户端通过TCP 发出一个段后，它启动一个计时器，等待服务端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
5. 序号：用于报文段的顺序传递。

没错就是依靠5大传输机制来完成了我们所说的可靠数据传输。但其实这5种机制的背后还有支撑了他们的一种协议——停止等待协议。

停止等待协议的基本原理就是每发完一个分组就停止，进入等待期，直到对方确认。在收到确认后再发下一个分组；在停止等待协议中，若接收方收到重复的分组，就会进行丢弃，但同时还要发送确认。

主要包括以下几种情况：无差错情况、出现差错情况（超时重传）、确认丢失和确认迟到、确认丢失和确认迟到。

拥塞控制

Q1：什么是拥塞控制？

拥塞控制是为了解决过多的数据注入到网络,导致网络奔溃,超过负荷.当每个发送方发送数据大量的数据会注入到网络,如果不做出限制,网络就会因数据量过大超负荷变卡,拥塞控制的用的是拥塞窗口解决的这个问题

Q2：TCP是如何感知网络拥塞的？

作为不能接触物理链路的一层，他的做法其实是基于ACK的反馈情况来调整的，分为以下两种情况：

1. 超时。
2. 同一个ACK收到了三次。

这两种的情况的讲解自然要涉及到四大策略了。

四大策略：

1. 慢开始：开始传输时的窗口大小仅为1
2. 拥塞避免：超时将窗口大小置为1，收到3个重复的ACK将窗口置为原来的一半。
3. 快重传：当接受方收到顺序错误的数据时不接收数据,同时重复发起对于之前数据的确认,发动到第三次,发送方得知自己的一部分数据在发送中丢失,立即发起重传。

1. 快恢复：窗口减半，然后以每次加1的速度进行恢复。

流量控制

流量控制是为了解决发送方和接收方速度不匹配的问题,当发送方发送的太快,接收方来不及接受就会导致数据丢失,流量控制用滑动窗口的形式解决问题

为了完成这一项艰巨的任务，接收方在发送确认报文的同时，会告诉发送方自己缓存区剩余的空间到底还有多少，这样同样的在接受方接收到确认报文后就会对自己的发送窗口大小进行了相应的调整，也就防止了大量丢包情况的发生。

其实你在上述的TCP包头结构中也能清晰的看到，对应的就是窗口大小的字段。

UDP/用户数据报协议

相比于TCP而言，UDP就是一个相对简单的协议了，废话不多说，先来看看它的包头结构。

和TCP的包头一对比，马上能感觉它的结构实在太简单了。

但是在网络环境下，我们一共要考虑的问题有两点：数据出错、数据丢失。

1. 对于数据出错，我们能够看到它的方案就是检验和，如果出错那就重发呗。
2. 如果出现数据丢失，那就真的丢了。

Q1：既然是一个数据不稳定的协议，为什么还会存在于世呢？

想来这是绝大多数人思考过的问题，其实原因有下面几个：

1. 应用场景的不同。 类似语音通话，视频通话中都全都是用了UDP协议。举一个很简单的例子，打语音电话的时候，你会因为别人的一个字缺失而失去对整句话意思的理解吗？更何况，在语音电话的时候，我们没听清楚的事情是可以，重新再询问一遍的。也就是说我们的沟通之间是容错的。
2. 传输效率的问题。 如果使用的是TCP协议，那么出现的问题就在于他的流量控制和拥塞控制，他的传输速率会受到网络环境改变的冲击而随之改变。但是UDP不一样，他没有三次握手，四次挥手，它只是一股脑的只管发，这个带宽已经足够大的时代，完全是能够承受起这样的资源占用的，而效率上也得到了保障。
3. 使用感受。 这是效率问题作为铺垫的引申，人的卡顿感是有一定的范围的，如果使用TCP协议却因为网络波动改变数据流量大小，那人们的体验感会马上下降，而且数据包到达的速度不理想，可以一个“开”的语音被拆成了“k”，“ai”，瞬间失去语义。然后还要可能“k”到了，“ai”丢了，重传等到了3秒以后，那更完了。

UDP组播/多播

UDP三类信息传递方式：

① 单播：是客户端与服务器之间的点到点连接。

② 广播：主机之间“一对所有”的通讯模式，广播者可以向网络中所有主机发送信息。

③ 多播：主机之间“一对一组”的通讯模式，也就是加入了同一个组的主机可以接受到此组内的所有数据。

组播原理：组播首先由一个用户申请一个组播组，这个组播组被维护在路由器中，其他用户申请加入组播组，这样当一个用户向组内发送消息时，路由器将消息转发给组内的所有成员。

基于这样的技术基础我们可以建立一个简易版的群聊系统，但是特别要注意的一点是，UDP是一个不可靠的数据传输协议，如何保障数据的到达是一个至关重要的问题。

总结

1. 拥塞控制和流量控制不同，前者是全局性的，而后者是端到端接收能力的控制。
2. TCP与UDP的针对场景性而进行设置使用，会丢失数据的协议并不一定是差的协议。

为了方便让你牢记于心的特点归总。

TCP：（1）面向连接（2）点对点传输，不存在一个数据发送存在多个接受方。（3）复杂的包头结构（4）可靠数据传输（5）拥塞控制（6）流量控制

UDP：（1）无连接状态（2）简单的包头结构（3）不可靠的数据传输（4）支持一对一、一对多的传输