网络原理-UDP/TCP详解

一. UDP协议

UDP协议端格式

由上图可以看出，一个UDP报文最大长度就是65535.

• 16位长度，表示整个数据报（UDP首部+UDP数据）的最大长度（注意，这里的16位UDP长度只是一个标识这个数据报长度的字段，并不是这个数据报传输的数据）

• 如果校验和出错，就会直接丢弃。

校验和：通过网线传输时，电信号使用高低电平来表示0和1.。但是，如果外部环境干扰，就有可能导致低电平->高电平，高电平->低电平，造成比特翻转=>数据就传输错了。校验和就是通过数据报中的数据内容通过计算得到的。值得注意的是：如果校验和不对，此时你的数据一定不对，如果校验和对，但是数据也有一定概率是错误的。

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

用UDP传输100个字节的数据报：

如果一次发送端发送100个字节，那么接收端也必须一次接收100个字节；而不能循环10次接收，每次接收10个字节。

缓冲区：UDP只有接收缓冲区，没有发送缓冲区

UDP没有真正意义上的发送缓冲区，发送的数据会直接交给内核，由内核将数据传给网络层协议进行后续的传输动作；

DUP具有接收缓冲区，但是这个接收缓冲区不能保证收到的DUP报的顺序和发送DUP报的顺序一致；如果缓冲区满了，再到达的DUP数据就会被丢弃；

二. TCP协议

TCP协议段格式：

2.1 TCP原理

2.1.1 确认应答机制

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

发送方的序号为最后一个字节的编号，确认序号为无意义的数据；

接收方的序号和发送方的序号无关，确认序号为接收数据的序号+1。

（在接收缓冲区中，优先级队列通过序号来确定数据的发送先后顺序）

接收方就可以通过ack的确认序号，告诉发送方哪些数据已经收到了。

2.1.2 超时重传机制

主机A发送数据给B之后,可能因为网络拥堵等原因,数据无法到达主机B;

如果主机A在一个特定时间间隔内没有收到B发来的确认应答,就会重发。

但是，主机A未收到B发来的确认应答，也可能是因为主机B收到了数据，但是ACK丢失了；

因此若ACK丢失了，主机B会收到很多重复数据。那么TCP协议需要能够识别哪些包是重复的包，并且把重复的丢弃掉。这时候我们就可以利用前面提到的序号来达到去重的效果。

超时重传后，重复发送的数据报仍可能会丢失，TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态的计算这个最大超时时间。

如果重发一次，仍得不到应答，TCP就会将这个超时时间延长后再重发，在不停的延长超时时间后，当累积到一定的重传次数后,TCP就会重置连接，如果重置连接失效，TCP就会关闭连接，放弃网络通信。

2.1.3 连接管理机制（三次握手，四次挥手）

建立连接：三次握手

握手指的是通信双发，进行一次网络交互，相当于客户端和服务器之间，通过三次交互，建立了连接关系。

syn称为同步报文段。意思就是一方要向另一方，申请连接。

在报文头部中有6个特殊的比特位，如果设为1，则表示特定含义。

其中第二位，是ACK，如果这一位为1，表示当前TCP数据报是一个应答报文；

其中第五位，是SYN，如果这一位为1，表示当前TCP数据报是一个同步报文；

如果一个TCP数据报，第二位和第五位都是1，则当前这个报文时SYN+ACK

三次握手这个过程，本质上时投石问路，验证了客户端和服务器，各自的发送能力和接收能力是否正常

断开连接：四次挥手

FIN：结束报文段

四次挥手中的ack和fin是否可以合并？

在三次握手中，ack和syn时同一时刻触发的（都是内核来完成的）

四次挥手，ack和fin则是在不同时机触发的。

ack是内核完成的，会在收到fin的时候第一时间返回

fin则是应用程序代码控制的。在调用到socket的close方法时候才会出发fin
finally{ 
    //thread.sleep(1000);
    socket.close();
}
这个close的执行时机，可能是立即，也可能是隔很久，却决于你的代码怎么写。

如果立即 close，趁着刚才ack还没发呢，这里就可以合并，如果是隔很久再close，此时fin就只能单独发了。

注：这里的close只是进程关闭了，但是连接（连接是内核维护的）还在，客户端发送的ack，服务器仍然可以收到。

2.1.4 滑动窗口(效率机制)

对于每一个发送的数据段,都要给一个ACK确认应答,收到ACK后再发送下一个数据段。.由于这样的一收一发的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能。（其实是将多个段的等待时间重叠在一起了。

• 窗口大小指的是无需等待应答而可以继续发送数据的最大值.上图的窗口大小就是4000个字节(4个段)。

• 发送前四个段的时候，不需要等待任何ACK，直接发送。

• 操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉。

• 窗口越大，则网络的吞吐率就越高。

如果出现了丢包的情况，如何重传？分两种情况：

情况一：数据包已经抵达，ACK被丢了。

这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认。如果1001的 ACK没有接收到，收到了2001的ACK，那么就说明已经接收到了2001以前的数据。

情况二：数据包直接丢了。

• 当某一段报文丢失之后，发送端会一直收到1001这样的ACK，就像是在提醒发送端“我想要的是"1001"一样；

• 当发送端主机连续收到三次同样的“1001”这样的应答，就会将对应的数据1001~2000重新发送

• 这个时候接收端收到了1001之后，再次返回的ACK就是7001了，因为2001~7000接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中。

2.1.5 流量控制（安全机制）

接收端处理数据的速度是有限的。如果发送端发送的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等一些列连锁反应。

因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制

• 接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK端通知发送端，此时发送端就可以根据这个窗口大小来批量发送这些数据了。

• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；

• 发送端接收到了这个窗口之后，就会减慢自己的发送速度

• 如果接收端缓冲区满了，就会将窗口设置为0；这时发送方就不再发送数据，但是仍需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

上述过程是把返回的窗口大小，当作实际的窗口，实践中可能会有出入。

发送方的窗口大小=min(流量控制,拥塞控制)。

2.1.6 拥塞控制（安全机制）

虽然TCP有了滑动窗口这个大杀器,能够高效可靠的发送大量的数据.但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题.

因为网络上有很多的计算机,在传输的过程中,需要经历许多的节点,可能当前的网络状态就已经比较拥堵了,但是此时在不清楚当前网络状态下,贸然发送大量的数据,是很有可能引起雪上加霜的.于是,不管在客户端与服务器之间是经历怎样的路径,把这个路径当做黑盒一样的东西,每次发送不同数量的请求,来试验出最佳的发送窗口.

TCP引入 慢启动 机制,先发送少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度传输数据

• 发送开始的时候,定义拥塞窗口大小为1

• 每次收到一个ACK应答,拥塞窗口加1

• 每次发送数据包的时候,将拥塞窗口和接收端主机反馈的窗口大小作比较,取较小的值作为实际发送的窗口

为了让拥塞窗口不增长的那么快,变引入了一个叫做慢启动的阈值,当拥塞窗口超过这个阈值的时候,不再按照指数的方式增长,而是按照线性方式增长

• 当TCP开始启动的时候,慢启动阈值等于窗口最大值;

• 在每次超时重发的时候,慢启动阈值会变成原来的一般,同时拥塞窗口重置回1.

2.1.7 延迟应答

如果接受数据的主机立刻返回ACK应答,这时候返回的窗口肯能比较小.

• 假设接收缓冲区为1M,一次收到了500k的数据,如果立刻应答,返回的窗口就是500k

• 但实际上可能处理端处理的速度很快,10ms之内就把500k的数据从缓冲区消费掉了

• 在这种情况下,接收端处理还远没有达到自己的极限,即使窗口再放大一些,也能处理过来

• 如果接受端稍微等一会再应答,比如等待200ms再应答,那么这个时候返回的窗口大小就是1M

窗口越大,网络吞吐量就越大,传输效率就越高.我们的目标是在保证网络不拥塞的情况下尽量提高传输效率.

但是并不是所有的包都可以延迟应答

• 数量限制:每隔N个包就应答一次;

• 时间限制:超过最大延迟时间就应答一次

具体的数量和超时时间,操作系统不同也有差异;一般N取2,超时时间取200ms(根据业务需求可自定义)

2.1.8 捎带应答

在延迟应答的基础上,我们可以发现,很多情况下,客户端服务器在应用层也是一发一收的.意味着客户端给服务器说了"How are you" , 服务器中程序处理过请求后也会给客户端返回一个"Fine,thank you" , 那么这个时候ACK就可以搭顺风车,和服务器回应的"Fine, thank you" 一起返回给客户端

上述ACK是内核收到数据报后直接返回的,Fine....是应用程序,通过write写的数据,通过一系列代码执行到才返回,这俩时机本来是不同的.但是延时应答,使此时的ACK 就可能稍等一会再发送就很有可能和response 合并成一个数据报.四次挥手,有可能是三次挥手,就是捎带应答起到的效果.

2.2 粘包问题

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

如何解决粘包问题？归根结底就是一句话，明确两个包之间的边界。

• 对于定长的包，保证每次都按照固定大小读取即可；例如上面的Request结构，是固定大小的，那么就从缓冲区从头开始按sizeof(Request) 依次读取即可

• 对于变长的包，可以定义分隔符，来区分包（应用层协议，是程序员自己来定的，只要定义保证分隔符不和正文冲突即可）

• 对于变长的包，还可以在包头的位置，约定一个包总长读的字段，从而知道了包的结束位置

对于UDP协议来说，是否也存在“粘包问题”？

• 对于UDP，如果还没有上层交付数据，UDP的报文长度仍然在。同时，UDP是一个一个把数据交付给应用层。就有很明确的数据边界。

• 站在应用层的角度，使用DUP的时候，要么收到完整的UDP报文，要么不收，不会出现“半个”的情况。

2.3 TCP异常情况

2.3.1 进程关闭/进程崩溃

进程没了，socket 是文件，随之被关闭，虽然进程没了，但是连接还在，仍然可以继续四次挥手

2.3.2 主机关机（正常流程关机）

先杀死所有的用户进程，然后就和进程关闭一样。

虽然可以出发四次挥手，如果能够在关闭之前完成更好。

如果没有发完，比如，对方发的 fin 过来了，咱们没来得及ack就关机了，此时对端就会重传fin,重传几次之后，发现都没有ack,尝试重置连接，如果还不行，就直接释放连接。

2.3.3 主机掉电（把电源）

瞬间机器就关了，来不及进行任何挥手操作。此时分两种情况：

1）对端是发送端

对端就会收不到ack=>超时重传=>重置连接=>释放连接

2）对端是接收端

对端是没法立即知道，你这边是还没来得及发新的数据，还是直接没了。即使发送端没有写入操作，TCP自己也内置了一个保活机制“心跳包”。虽然是接收端，但是接收端会定期给发送端发送一个心跳包（ping),正常情况下就会返回一个(pong)，如果每个 ping 都有及时的 pong，这个时候就说明当前对端的状态良好，如果 ping 过去之后，没用 pong ，说明心跳没了，这边怕是打概率挂了（pong也有概率丢的，因此会连续几次都丢了才会判定连接断开）。

注：发送方也是有心跳包的，但是通过对方返回的ack来判定会更快一些。