网络--TCP/IP（四）TCP 与 UDP 协议简介

从本节开始，我们开始学习最重要的传输层。传输层位于OSI七层模型的第四层（从下往上）。顾名思义，传输层的作用是实现应用程序间的通信。网络层的作用是保证数据在不同数据链路上传输的可达性，至于如何传输则是由传输层负责。

一、传输层协议简介

常见的传输层协议主要有TCP和UDP协议。

1. TCP，TCP是面向有连接的协议，也就是说在使用TCP协议传输数据之前，一定要在发送发和接收方建立连接。一般情况下建立连接需要三步，关闭连接需要四步。
   建立TCP连接后，由于有数据重传，流量控制等功能，TCP能够正确处理丢包问题，保证接收方能够收到数据，与此同时还能有效利用带宽。然而TCP中定义了很多复杂的规范，因此效率不如UDP，所以不适合实时的视频、音频传输。
2. UDP

• 无连接，UDP是面向无连接的协议。不需要建立连接。
• 尽最大努力交付，它只会把数据发送给接收端，但是不关心接收端是否收到数据。但是这种特性反而适合多播，实时的视频和音频传输，因为个别数据包的丢失并不会影响视频和音频的整体效果。
• 面向报文，对应用层的数据既不合并，也不拆分，而是直接在应用层数据基础上直接拼接udp首部，传给网络层（ip所在层）。

3. 关键要素
   IP协议中的两大关键要素是源IP地址和目标IP地址。而传输层我们刚刚说过，作用是实现应用程序间的通信。因此传输层的协议中新增三个要素：源端口号、目标端口号和协议号。通过这五个要素可以唯一识别一个通信。
   不同的端口号，用于区分同一主机上的不同应用程序。
   协议号用于区分使用的是TCP还是UDP。

用一句话概括，“源IP地址、目标IP地址、源端口号、目标端口号、协议号”这五个信息只要有一个不同，就被认为是不同的通信。

二、UDP首部

UDP协议最大的特点就是简单，UDP首部如图：

UDP首部

• 包长度，表示UDP首部和UDP数据长度之和。
• 检验和用于判断数据在传输过程中是否有损坏。计算这个校验和的时候，不仅要考虑源端口号、目标端口号，还要考虑IP首部中的源IP地址、目标IP地址、协议号（这些又称为UDP伪首部）。这是因为以上五个要素是识别通信时缺一不可，如果校验和只考虑端口号，那么另外三个要素在受到破坏时，应用就无法得知。这可能导致不该收到包的应用收到了包，该收到包的应用没有收到。
  这个概念同样适合于下面的TCP首部。

三、TCP首部

和UDP首部相比，TCP首部要复杂的多。解析这个首部的时间也会相应的增加，这也是TCP连接的效率低于UDP的原因之一。

TCP首部

• 序列号，它表示发送数据的位置，假设当前的序列号为s，发送的数据长度为l，则下次发送数据时的序列号为s+l。在建立连接时，通常由计算机随机生成个数作为序列号的初始值。
• 确认应答号，它等于下一次应该收到的数据的序列号。比如发送端的序列号为s，数据长度为l，则接收端返回的确认应答号也应为s+l。发送端接收到这个确认应答后，可以认为这个位置以前的所有数据已经被正常接收。
• 数据偏移，TCP首部的长度，单位为4字节。如果没有可选字段，那么这个值就是5，表示TCP首部的长度为20字节。
• 控制位，该字段有8比特，分别有8个控制标志。依次是 CWR，ECE，URG，ACK，PSH，RST，SYN 和 FIN。在后续的文章中会接触到其中的几个。
• 窗口大小，用于表示从应答号开始能够接受多少个8位字节。如果窗口大小为0，可以发送窗口探测。
• 紧急指针，仅在URG控制位是1时有效。表示紧急数据的末尾在TCP数据部分中的位置。通常在暂时中断通信时使用。

四、TCP握手

TCP是面向有连接的协议，连接在每次通信前被建立，通信结束后被关闭。了解连接建立和关闭的过程通常是考察的重点。连接的建立和关闭可以用一张图来表示：

TCP三次握手

通常情况下我们认为客户端首先发起连接请求。

1. 三次握手

1.发送端发送一个SYN=1，ACK=0标志的数据包给接收端，请求进行连接，这是第一次握手；
2.接收端收到请求并且允许连接的话，就会发送一个SYN=1，ACK=1标志的数据包给发送端，告诉它，可以通讯了，并且让发送端发送一个确认数据包，这是第二次握手；
3.最后，发送端发送一个SYN=0，ACK=1的数据包给接收端，告诉它连接已被确认，这就是第三次握手。之后，一个TCP连接建立，开始通讯。
*SYN：同步标志
同步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里，可以把TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。
*ACK：确认标志
确认编号(Acknowledgement Number)栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1，Figure-1)为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。
*RST：复位标志
复位标志有效。用于复位相应的TCP连接。
*URG：紧急标志
紧急(The urgent pointer) 标志有效。紧急标志置位，
*PSH：推标志
该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。在处理 telnet 或 rlogin 等交互模式的连接时，该标志总是置位的。
*FIN：结束标志
带有该标志置位的数据包用来结束一个TCP回话，但对应端口仍处于开放状态，准备接收后续数据

2.为什么是三次握手

根据一般思路，我们认为第三次是多余的，TCP协议为什么还要增加第三次的握手呢？
这是因为在网络请求的时候，我们应该时刻记住“网络是不安全的，数据包是可能丢失的”。假设没有第三次确认，客户端向服务端发送了SYN包，请求建立连接。由于网络原因，服务器没有及时收到这个包，于是客户端重新发送了SYN包。正常建立了连接。此时超时的那个确认包到达了服务端，如果是两次握手此连接就建立了，服务端就建立了一个空连接，白白浪费资源。如果是三次，客户端判断这个确认包是无效的，就丢弃了。

3. 第三次握手的ACK包丢失

三次握手实际其实解决了第二步丢包问题。那么第三步的ACK包丢失了，TCP协议是如何处理的呢？
按照TCP协议处理丢包问题的一般方法，服务器会重新向客户端发送确认包，知道ACK确认为止。但实际上这种做法有可能遭到SYN泛洪攻击。所谓的泛洪攻击，是指发送方伪造多个IP地址，模拟三次握手的过程。当服务器返回ACK后，攻击方故意不确认，从而使服务器不断重发ACK。由于服务器长时间处于半连接状态，最后消耗过多的CUP和内存资源导致死机。
所以服务端采用的是这种方法，发送RST数据包，进入close状态，这个RST数据包中的TCP首部中的控制位中的RST位被置为1。这表示连接信息全部被初始化，原有的TCP通信不能继续。客户端如果还想建立TCP连接，需要从第一步握手重新开始。

五、四次挥手关闭连接

TCP四次挥手关闭

（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送（报文段4）。
（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。
（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A（报文段6）。
（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。

1. 关闭连接的最后一个 ACK 丢失怎么办?
   实际上，在第三步中，客户端收到 FIN 包时，它会设置一个计时器，等待相当长的一段时间。如果客户端返回的 ACK 丢失，那么服务端还会重发 FIN 并重置计时器。假设在计时器失效前服务器重发的 FIN 包没有到达客户端，客户端就会进入 CLOSE 状态，从而导致服务端永远无法收到 ACK 确认，也就无法关闭连接。
2. 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
   这样能够保证第四次挥手不管在正常情况下还是丢包情况下都不会出现问题。
   正常情况下，客户端A把第四次挥手的ACK报文发送给客户端B，这个报文在一个MSL内能够成功到达。尽管A会多等一个MSL的时间也不会有什么问题。
   如果出现第四次丢包的情况，也就是A发送ACK包给B以后，正常情况下在一个MSL的时间内B是肯定能收到的，如果B没有收到，B会重新发送FIN包，这个重新发送的FIN包在MSL时间内也是能够到达的。
   所以2MLS时间之后，就确保了当前连接上没有任何报文了，可以正常关闭了。