传输层重要协议之UDP协议和TCP协议详解

更多关于UDP协议和TCP协议请移步官网：https://www.rfc-editor.org/standards#IS

UDP标准协议文档-RFC 768

TCP标准协议文档-RFC 793

UDP协议详解

UDP协议的特点：

无连接、不可靠传输、面向数据报和全双工。

UDP协议报文结构：

关于端口号：

端口都是使用2个字节，16个bit位来表示，一个端口号的取值范围在0-65535之间。但是并不是所有的端口都可以被咱们程序猿所使用。我们自己写的程序绑定的端口一般是从1024开始的。0-1023这个范围的端口被称为“知名端口号”，即这些端口号是属于已经分配了一些知名的广泛使用的应用程序。1023以下的端口号一般是不建议使用。

关于UDP报文长度：

对于UDP来说，报头一共就是8个字节，分成四个部分（每个部分两个字节）。UDP报文长度也是用2个字节来表示的，2个字节的范围就是0-65535，换算成单位就是64kb，也就是说一个UDP数据报最大也就能够传输64kb的数据。

这个数值对于目前的传输要求来说显然是很小的，如果应用层数据报超过了64KB，对于UDP来说就需要在应用层通过代码的方式针对应用层数据报进行手动的分包，拆成多个包通过多个UDP数据报进行传输（本来需要send一次，现在需要send多次），或者换成TCP协议，因为TCP协议没有长度的限制。

关于校验和：

校验和的作用就是验证传输的数据是否是正确的。网络传输的本质就是光电信号，在传输过程中可能会受到一些干扰，就可能出现“比特翻转”的情况，即1->0 或 0 -> 1，就会造成数据改变。这样的现象是客观存在的，因此就引入了校验和来进行鉴别。

针对数据内容进行一系列的数学运算，得到一个比较短的结果（2个字节），当接收方收到这个数据之后，也会进行相同逻辑的数学运算，也会得到一个结果。如果两次校验和的结果是一样的，则证明传输的数据是正确的，反之，证明数据在传输过程中发生了改变。当然，在低端情况下，就算数据内容不一致，那么也会得到一个相同的校验和，那么这种是极小概率的，可以忽略不计。

TCP协议详解（10个核心机制）

TCP协议的特点：

有连接、可靠传输、面向字节流和全双工。

确认应答：

实现可靠传输的最核心机制。A给B发一个消息，B收到之后就会返回一个应答报文（ACK），此时A收到之后就知道刚才发送的信息已经顺利到达B了。

但是如果A给B发送了多条消息，网络传输中存在“先发后至”现象，那么B收到的信息的顺序也是错乱的，那么B返回A的应答报文到达的顺序也是可能发生变动的，这就有可能会因为顺序错乱而带来语义上的歧义。为了解决上述问题，给传输的数据和应答报文都进行编号。这样即使顺序错乱了，也可以根据序号来区分当前应答报文是针对哪个数据进行的了。

任何一条数据（包括应答报文）都是有序号的，确认序号是只有应答报文有，一条报文是否是应答报文，取决于ACK这个标志位是否是1。

TCP可靠传输能力，最主要就是通过确认应答机制来保证的。通过应答报文，就可以让发送方清楚的知道传输是否成功，进一步的引入了序号和确认序号，针对多组数据进行详细的区分。

超时重传

当发送的数据丢了或者返回的ack丢了，这种情况叫做丢包。但是对于发送方来说，就是没有收到ack，区分不了到底是哪一种情况造成的。因此，TCP就引入了重传机制，在丢包的时候重新再发一次同样的数据。TCP引入了一个时间阈值，发送方发了一个数据之后，就会等待ack，此时开始计时，如果超过了这个时间阈值还没有收到ack，就视为丢包，就重新传输。

但是会引入一个问题，由于重传，就会导致接受方同样的数据就会被收到多次，这是比较恐怖的，比如支付问题。但是，TCP对于这种情况是有处理的，TCP可以对重复数据去重。TCP存在一个“接受缓冲区”这样的存储空间（接收方操作系统内核里的一段内存），每个TCP的socket对象，都有一个接受缓冲区（其实也有一个发送缓冲区）。根据数据的序号，很容易识别当前接受缓冲区里面的重复数据，如果重复了，就丢弃后来的这份数据，保证了应用程序read读取到的数据一定是不重复的。

由于去重和重新排序机制的存在，发送方只要发现ACK没有按时到达，就会重传数据。即使重复了，即使顺序乱了，都没事，接收方都能很好的处理好(去重和排序都依赖TCP报头的序号)。

重传达到一定次数的时候，就不会再继续重传，会认为网路出现故障。接下来TCP会尝试重置连接(相当于断开重连一样)，如果重置还是失败，彻底断开连接了。

小结:可靠传输是TCP最核心的部分。TCP的可靠传输就是通过确认应答＋超时重传来进行体现的。其中确认应答描述的是传输顺利的情况。超时重传描述的是传输出现问题的情况。这两者相互配合,共同支撑整体的TCP可靠性。

连接管理

建立连接（三次握手）

建立连接就是通信双方各自要记录对方的信息，彼此之间要相互认同。

客户端主动给服务器发起的建立连接请求,称为"SYN"，同步报文段。

所谓的三次握手，本质上是四次交互，通信双方，各自要向对方发起一个“建立连接”的请求，同时,再各自向对方回应一个ack。但是,中间两次交互,是可以合并成一次交互的，因此就构成了“三次握手"过程。中间两次的交互是必须合并的，因为封装分用两次一定比封装分用一次的成本更高。

三次握手的重要作用就是建立彼此之间的认同，验证通信双方各自的发送能力和接收能力是否正常，在一定程序上保证了TCP传输的可靠性。

如果是只有两次握手，则验证不了双方通信都是正常的。举个例子：

如果只有两次握手，那么站在男生的角度，知道了女神同意我请她吃饭。但是站在女神的角度，她不知道男生是否同意她请她吃饭。

在建立连接阶段，主要有两个状态：

LISTEN(listen):为服务器的状态，表示服务器已经准备就绪，随时可以有客户端来连接。

ESTABLISHED(established):客户端和服务器都有这个状态，表示连接建立完成，接下来就可以正常通信了。

断开连接（四次挥手）

四次挥手，和三次握手非常类似，都是通信双方各自向对方发起一个断开连接的请求，再各自给对方一个回应。

四次挥手中间的两次交互是不能合并的，之所以三次握手中间两次能够合并是因为，三次握手的中间两次能够合并是因为他俩是同一时机（SYN 和 ACK），具体来说,三次握手这三次交互过程,是纯内核中完成的(应用程序感知不到，也干预不了)，服务器的系统内核收到syn之后,就会立即发送ack 也会立即发送syn。

对于四次挥手来说，FIN的发起，不是由内核控制的，而是由应用程序调用socket的close方法(或者进程退出)才会触发FIN。ACK则是由内核控制的，是收到FIN之后，立即返回ACK，而服务器的应用程序执行到对应的close方法,才会触发的FIN，这两者之间就会隔了一个时间差，具体时间差是多少取决于代码的写法。

所以，基于上述原因，FIN 和 ACK 并不完全是同一时机的，所以四次挥手中的中间两次是不能合并的。

四次挥手涉及到两个重要的状态：

CLOSE_WAIT: 出现在被动发起断开连接的一方（建立连接一定是客户端主动发起请求，断开连接可能是客户端主动发起，也可能是服务器主动发起），等待关闭（等待调用close方法关闭socket）。

TIME_WAIT: 出现在主动发起断开连接的一方，假设是客户端主动发起断开连接，那么当客户端进入TIME_WAIT状态的时候，相当于四次挥手在客户端这边已经结束了，但是此时这里的TIME_WAIT要保持当前的TCP连接状态不要立即释放。TIME_WAIT保留一段时间的连接是因为，此时最后一个ack刚刚发出去，还没有到呢，防止ack丢包。

在三次握手和四次挥手过程中都是存在超时重传的。如果是最后一个ACK 丢包了,站在服务器的视角来看，服务器是不知道是因为ACK丢了，还是自己发的FIN 丢了，所有统一视为FIN丢了，统一进行重传操作。

既然服务器可能要重传FIN，客户端就需要能够针对这个重传的FIN进行ACK响应，很明显,如果刚才彻底把连接释放了,这样的ACK就无法进行了。因此使用TIME_WAIT状态保留一定的时间,就是为了能够处理最后一个ACK 丢包的情况,能够在收到重传的FIN之后,进行ACK响应。

那TIME_WAIT具体保持多长时间,就真正释放呢?

按照一般的经验来说，定义MSL为A传输数据到B所花费的时间（经验值），那么就约定TIME_WAIT保持2 MSL。

滑动窗口

可靠性和传输效率本身来说是矛盾的，在保证可靠性的基础上，来尽可能的提高传输效率，就引入了滑动窗口。

对于基本确认应答的情况来说,每次发一个数据,都需要等，等 ack到了再发下一个。滑动窗口的本质就是不等待的批量发送一组数据，然后使用一份时间来等待着一组数据的多个ACK 。把不需要等待,就能直接发送的数据的最大的量,称为"窗口大小"。

如果出现丢包的情况，就分为两种情况了：

第一种就是ack丢了，这种情况是不需要做任何处理的，关键在于有确认序号的存在，表示从该序号往前的所有数据都已经确认到达了。

第二种就是数据丢了：

由于1001-2000丢包了，接下来2001-3000到达主机B之后,B给A返回的ACK确认序号仍然是1001(此时和你发来的这个数据序号是啥,关系不大了)，会一直索要1001开头的数据，直到1001开头的数据传输过来（“快速重传-超时重传在滑动窗口下的变形”），如果下面还有数据丢包的情况，那么还会继续索要下一个，直到没有数据丢包。