传输层之UDP与TCP协议详解

1、UDP协议

<1>UDP协议端格式

• 16位UDP长度，表示整个数据报(UDP首部+UDP数据)的最大长度;
• 如果校验和出错，就会直接丢弃;

如何进行解包分用的呢？
报头定长8字节。

Linux是用C语言写的，那如何看待udp的报文？

struct udp_hdr
{
	uint32 src_port : 16;
	uint32 dst_port : 16;
	uint32 total : 16;
	uint32 check : 16;
}

<2>UDP特点

UDP传输的过程类似于寄信.

• 无连接: 知道对端的IP和端口号就直接进行传输，不需要建立连接;
• 不可靠: 没有确认机制，没有重传机制。如果因为网络故障该段无法发到对方，UDP协议层也不会给应用层返回任何错误信息;
• 面向数据报: 不能够灵活的控制读写数据的次数和数量;
• UDP协议首部中有一个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)。如果我们需要传输的数据超过64K，就需要在应用层手动的分包，多次发送，并在接收端手动拼装;

面向数据报
应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并;

如用UDP传输100个字节的数据:

如果发送端调用一次sendto，发送100个字节，那么接收端也必须调用对应的一次recvfrom，接收100个字节。 而不能循环调用10次recvfrom，每次接收10个字节(要读就读完，不能只读一半)。

<3>UDP的缓冲区

• UDP没有真正意义上的发送缓冲区，调用sendto会直接交给内核，由内核将数据传给网络层协议进行后续的传输动作;
• UDP具有接收缓冲区，但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致，如果缓冲区满了，再到达的UDP数据就会被丢弃;
• UDP的socket既能读，也能写，这个概念叫做 全双工。

2、TCP协议

TCP全称为 “传输控制协议(Transmission Control Protocol”). 人如其名，要对数据的传输进行一个详细的控制;

<1>TCP协议段格式

• 源/目的端口号: 表示数据是从哪个进程来，到哪个进程去;
• 32位序号: 携带发送的数据；
• 32位确认号: 对历史报文的确认；
• 4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节)，所以TCP头部最大长度是15 * 4 = 60；
• 6位标志位:
  URG: 紧急指针是否有效(如果想让一个数据尽快被读到，可以设置URG，表明该报文中携带了紧急数据，需要被优先处理,紧急数据在紧急指针中)；
  ACK: 确认号是否有效(应答)；
  PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走；
  RST: 对方要求重新建立连接，我们把携带RST标识的称为复位报文段；
  SYN: 请求建立连接，我们把携带SYN标识的称为同步报文段；
  FIN: 通知对方, 本端要关闭了。我们称携带FIN标识的为结束报文段；
• 16位窗口大小 : 接收能力(自己缓冲区剩余空间大小)流量控制；
• 16位紧急指针: 大小只有一字节；

如何进行解包分用的呢？
报头定长20字节。

<2>TCP的缓冲区

TCP协议是自带发送和接收缓冲区的(可以理解为malloc两段内存空间)。

在我们Socket套接字文章中，实现了TCP客户端和服务端。其中如何理解write/send等函数呢？

• write/send等与其叫做发送接口，不如理解成拷贝函数。应用层进行write/send时并不是把数据发送到网络上，而是把数据拷贝到TCP的发送缓冲区。
• 我们在应用层进行发送数据时本质就是把数据拷贝到发送缓冲区然后由操作系统发送到对端的接收缓冲区内，同样我们进行接收数据时本质就是把接收缓冲区中的内容拷贝到应用层。

TCP协议为什么要设有发送缓冲区和接收缓冲区呢？

• 提高应用层的效率；
• 因为只有OS中TCP可以知道网络状况乃至对方的状态明细，所以也只有TCP协议能处理如何发，什么时候发以及发多少出错了怎么办等细节问题。同时也更好体现出TCP传输控制的特性；
• 同时因为缓冲区的存在，故可用做到应用层和TCP进行解耦。也就是应用层拷贝完成后就直接返回，并不需要知道数据应该怎样发出去。而TCP也只需要把缓冲区中的数据收发出去就可了。

3、TCP如何保证可靠性

<1>面向链接机制

在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接。

三次握手过程
三次握手是双方的OS中TCP协议自动完成的，用户层完全不参与。

服务端状态转化:

• [CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态，等待客户端连接;
• [LISTEN -> SYN_RCVD] 一旦监听到连接请求(同步报文段)，就将该连接放入内核等待队列中，并向客户端发送SYN确认报文；
• [SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端的确认报文，就进入ESTABLISHED状态，可以进行读写数据了；

客户端状态转化:

• [CLOSED -> SYN_SENT] 客户端调用connect，发送同步报文段;
• [SYN_SENT -> ESTABLISHED] connect调用成功，则进入ESTABLISHED状态，开始读写数据;

为什么是三次握手? 1、2、4、…不行吗？

1.确定双方主机是否正常(SYN SYN+ACK)，一应一答；
2.验证全双工(网络)，(SYN、SYN + ACK)说明客户端收发正常(SYN+ACK、ACK)说明服务端收发正常。三次是能看到双方都有收发的最小次数，次数过多资源浪费；
若是1、2次会导致服务端安全性降低，若有人不断SYN则服务端崩溃(SYN)洪水；

建立链接的本质

三次握手成功，一定会在双方的OS内维护该链接创建的数据结构。(双方维护链接是有成本的 时间 + 空间 )

四次挥手过程

服务端状态转化:

• [ESTABLISHED -> CLOSE_WAIT] 当客户端主动关闭连接(调用close)，服务器会收到结束报文段，服务器返回确认报文段并进入CLOSE_WAIT;
• [CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据); 当服务器真正调用close关闭连接时，会向客户端发送FIN，此时服务器进入LAST_ACK状态，等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)；
• [LAST_ACK -> CLOSED] 服务器收到了对FIN的ACK，彻底关闭连接；
  客户端状态转化:
• [ESTABLISHED -> FIN_WAIT_1] 客户端主动调用close时，向服务器发送结束报文段，同时进入FIN_WAIT_1;
• [FIN_WAIT_1 -> FIN_WAIT_2] 客户端收到服务器对结束报文段的确认，则进入FIN_WAIT_2，开始等待服务器的结束报文段;
• [FIN_WAIT_2 -> TIME_WAIT] 客户端收到服务器发来的结束报文段，进入TIME_WAIT并发出LAST_ACK;
• [TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life, 报文最大生存时间)的时间，才会进入CLOSED状态；

为什么是四次挥手？

四次挥手是协商断开链接的最小次数。

断开链接的本质

双方都达成链接需要断开的共识，就是一个通知对方的机制。

理解TIME_WAIT状态

我们将server关闭后想重新运行server结果出现bind error，这是因为,虽然server的应用程序终止了，但TCP协议层的连接并没有完全断开,因此不能再次监 听同样的server端口。

我们可以用netstat命令查看一下如图：

• TCP协议规定主动关闭连接的一方要处于TIME_ WAIT状态，等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态。
• MSL在RFC1122中规定为两分钟，但是各操作系统的实现不同，在Centos7上默认配置的值是60s;

想一想, 为什么是TIME_WAIT的时间是2MSL?

• MSL是TCP报文的最大生存时间，因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启，可能会收到来自上一个进程的迟到的数据，但是这种数据很可能是错误的)。同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失，那么服务器会再重发一个FIN。这时虽然客户端的进程不在了，但是TCP连接还在，仍然可以重发LAST_ACK);

解决TIME_WAIT状态引起的bind失败的方法

在server的TCP连接没有完全断开之前不允许重新监听，某些情况下可能是不合理的。

• 服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短, 但是每秒都有很大数量的客户端来请求)。这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃，就需要被服务器端主动清理掉)，就会产生大量TIME_WAIT连接。由于我们的请求量很大，就可能导致TIME_WAIT的连接数很多，每个连接都会占用一个通信五元组(源ip，源端口，目的ip，目的端口，协议)。其中服务器的ip和端口和协议是固定的。如果新来的客户端连接的ip和端口号和TIME_WAIT占用的链接重复了，就会出现问题；

解决办法

使用setsockopt()设置socket描述符的 选项SO_REUSEADDR为1，表示允许创建端口号相同但IP地址不同的多个socket描述符。

int setsockopt(int sockfd, int level, int optname,const void *optval, socklen_t optlen);
参数：
sock：将要被设置或者获取选项的套接字。
level：选项所在的协议层。
optname：需要访问的选项名。
optval：对于getsockopt()，指向返回选项值的缓冲。对于setsockopt()，指向包含新选项值的缓冲。
optlen：对于getsockopt()，作为入口参数时，选项值的最大长度。作为出口参数时，选项值的实际长度。对于setsockopt()，现选项的长度。

返回值：成功返回0，失败返回-1.

例：
int tw = 1;
setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &TW, sizeof(tw));

理解CLOSE_WAIT状态

对于服务器上出现大量的 CLOSE_WAIT 状态，原因就是服务器没有正确的关闭 socket，导致四次挥手没有正确完成。这是一个 BUG，只需要加上对应的 close 即可解决问题。
若我们代码中不加close如图：

此时服务器进入了 CLOSE_WAIT 状态，结合我们四次挥手的流程图，可以认为四次挥手没有正确完成。

<2>确认应答机制

TCP将每个字节的数据都进行了编号，即为序列号。

每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据。下一次你从哪里开始发。

<3>超时重传

在传输数据的过程中可能会因为某种原因导致丢包，TCP是如何解决的呢？

丢包有两种情况：
第一种

• 主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B;
• 如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发;

第二种

• 主机A发送数据给B之后，可能因为网络拥堵等原因，应答无法到达主机A;
• 此时主机B会收到大量重复的数据，根据确认序号便可做到去重效果;

那么, 如果超时的时间如何确定?

最理想的情况下，找到一个最小的时间，保证 “确认应答一定能在这个时间内返回”。但是这个时间的长短随着网络环境的不同是有差异的，如果超时时间设的太长会影响整体的重传效率，如果超时时间设的太短有可能会频繁发送重复的包。

TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间。

• Linux中(BSD Unix和Windows也是如此)，超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍；
• 如果重发一次之后，仍然得不到应答，等待 2*500ms 后再进行重传；
• 如果仍然得不到应答，等待 4*500ms 进行重传。 依次类推, 以指数形式递增；
• 累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接；

<5>流量控制

接收端处理数据的速度是有限的。如果发送端发的太快导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。 因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制(Flow Control);

• 接收端将自己可以接收的缓冲区大小放入TCP 首部中的 “窗口大小” 字段，通过ACK端通知发送端；
• 窗口大小字段越大，说明网络的吞吐量越高;
• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端;
• 发送端接受到这个窗口之后，就会减慢自己的发送速度;
• 如果接收端缓冲区满了，就会将窗口置为0。这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端;

窗口大小是16字节, 而16位数字最大表示65535, 那么TCP窗口最大就是65535字节么?
实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移 M 位;

<6>拥塞控制

TCP有了滑动窗口(下面会提到)这个大杀器，能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题。因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的。
TCP引入慢启动机制，先发少量的数据探探路，摸清当前的网络拥堵状态。再决定按照多大的速度传输数据;

• 此处引入一个概念为拥塞窗口;
• 发送开始的时候, 定义拥塞窗口大小为1;
• 每次收到一个ACK应答, 拥塞窗口加1;
• 每次发送数据包的时候，将拥塞窗口和接收端主机反馈的窗口大小做比较，取较小的值作为实际发送的窗口;

“慢启动” 只是指初使时慢, 但是增长速度非常快;

• 为了不增长的那么快，因此不能使拥塞窗口单纯的加倍;
• 此处引入一个叫做慢启动的阈值;
• 当拥塞窗口超过这个阈值的时候，不再按照指数方式增长，而是按照线性方式增长;
  
• 当TCP开始启动的时候，慢启动阈值等于窗口最大值;
• 在每次超时重发的时候，慢启动阈值会变成原来的一半，同时拥塞窗口置回1;
• 少量的丢包，我们仅仅是触发超时重传。大量的丢包, 我们就认为网络拥塞;

<4>TCP如何保证效率

<1>滑动窗口

若是每一个发送的数据段都要给一个ACK确认应答，收到ACK后再发送下一个数据段(如上图主机A和B传输过程)。这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候。

既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)。
如图：

• 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节(四个段);
• 发送前四个段的时候，不需要等待任何ACK，直接发送;
• 收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据。依次类推;
• 操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答。只有确认应答过的数据，才能从缓冲区删掉;
• 窗口越大，则网络的吞吐率就越高;

如何理解滑动窗口？

什么时候确定滑动窗口的大小呢？
三次握手交互期间，协商滑动窗口的大小(根据对方窗口的大小来设置自己的滑动窗口的初始值)。

如果丢包如何进行重传？

情况一： 数据包已经抵达，ACK被丢了。如上图中的ACK(应答)1001，1002，1003丢了并不影响，可以通过后序的ACK(应答)进行确认。
情况二： 数据包就直接丢了。

以上图中的1001~2000数据丢失为例。

• 当某一段报文段丢失之后，发送端会一直收到 1001 这样的ACK，就像是在提醒发送端 “我想要的是 1001” 一样;
• 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答，就会将对应的数据 1001 - 2000 重新发送;
• 这个时候接收端收到了 1001 之后，再次返回的ACK就是4001了(因为2001 - 4000)接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中;这种机制被称为 “高速重发控制”(也叫 "快重传）；

超时重传 VS 快重传

快重效率这么高为什么还要有超时重传呢？

TCP中两种都是存在的，因为快重传是有条件的，必须连续收到三次同样的确认应答，因为有可能存在收不到三次应答的情况(滑动窗口大小不够)，超时重传可以解决这一问题。

<2>延迟应答

如果接收数据的主机立刻返回ACK应答， 这时候返回的窗口可能比较小。

• 假设接收端缓冲区为1M。一次收到了500K的数据，如果立刻应答，返回的窗口就是500K;
• 但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了;
• 在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来;
• 如果接收端稍微等一会再应答，比如等待200ms再应答，那么这个时候返回的窗口大小就是1M;

窗口越大，网络吞吐量就越大，传输效率就越高。

延迟应答机制

• 数量限制: 每隔N个包就应答一次;
• 时间限制: 超过最大延迟时间就应答一次;

具体的数量和超时时间，依操作系统不同也有差异，一般N取2，超时时间取200ms;

<5>TCP面试常见问题

<1>什么是面向字节流

简单来说面向节流就是不关系数据的基本格式,只关心数据量，发送次数和接收次数没有任何关联性。

当我们创建一个TCP的socket时，会同时在内核中创建一个发送缓冲区和一个接收缓冲区;

• 调用write时，数据会先写入发送缓冲区中;
• 如果发送的字节数太长，会被拆分成多个TCP的数据包发出;
• 如果发送的字节数太短，就会先在缓冲区里等待，等到缓冲区长度差不多了，或者其他合适的时机发送出去;
• 接收数据的时候，数据也是从网卡驱动程序到达内核的接收缓冲区;
• 然后应用程序可以调用read从接收缓冲区拿数据;

由于缓冲区的存在, TCP程序的读和写不需要一一匹配, 例如:

• 写100个字节数据时，可以调用一次write写100个字节，也可以调用100次write，每次写一个字节;
• 读100个字节数据时，也完全不需要考虑写的时候是怎么写的，既可以一次read 100个字节，也可以一次read一个字节，重复100次;

<2>数据粘包问题

为什么会出现粘包问题呢？

• 在TCP的协议头中， 没有如同UDP一样的 “报文长度” 这样的字段，但是有一个序号这样的字段。
• 站在传输层的角度，TCP是一个一个报文过来按照序号排好序放在缓冲区中的。
• 站在应用层的角度，看到的只是一串连续的字节数据。
• 那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一个完整的应用层数据包。

怎样解决数据粘包问题呢？

一般有三种方式分包的方式：

• 固定长度的消息；
• 特殊字符作为边界；
• 自定义消息结构。

固定长度的消息

这种是最简单方法，即每个用户消息都是固定长度的，比如规定一个消息的长度是 64 个字节，当接收方接满 64 个字节，就认为这个内容是一个完整且有效的消息。

特殊字符作为边界

我们可以在两个用户消息之间插入一个特殊的字符串，这样接收方在接收数据时，读到了这个特殊字符，就把认为已经读完一个完整的消息。如HTTP 就是以空行来明确报头和数据的边界。

<3>连接异常问题

• 进程崩溃： 进程终止会释放文件描述符，仍然可以发送FIN，和正常关闭没有什么区别。
• 机器重启: 和进程终止的情况相同。
• 机器掉电/网线断开: 接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行reset。即使没有写入操作，TCP自己也内置了一个保活定时器(keepalive)，会定期询问对方是否还在。如果对方不在，也会把连接释放。

关于异常问题还以以参考下这篇文章，个人感觉还不错 TCP 连接异常的问题