计算机网络(4)--运输层协议--TCP与UDP

运输层位于五层协议的第四层，运输层向上面的应用层提供通用的服务，通用的是指多个应用进程可以使用同一个运输层协议。运输层负责的是为两台主机之间的通信提供通用的数据传输服务，运输层具有分用和复用的功能，复用是指多个应用使用同一个运输层服务，分用是指能够将网络层上来的信息分别交付给不同的应用

运输层主要有两个协议：

• TCP：传输控制协议，提供面向连接的、可靠的数据传输协议
• UDP：用户数据报协议，提供无连接的、尽最大努力提交的数据传输服务，但是不保证可靠性

本文重点介绍UDP和TCP这两种协议

一、UDP

UDP的全称是用户数据包协议(User Datagram Protocol)，UDP为应用程序提供了一种无须建立连接就可以发送封装的IP数据包的方法，UDP只在IP的数据报上增加了很少的功能，就是分用和复用以及差错检测的功能，虽然具有差错检测但是没有恢复能力和重传机制所以是不可靠的

1.1 UDP的特点

• UDP是无连接的，也就是在发送数据之前不需要建立连接，发送数据结束之后也没有连接释放，减少了建立连接和释放连接的开销
• UDP尽最大努力交付，是没有连接状态的，即不保证可靠交付，因此主机不需要维护复杂的状态
• UDP是面向报文的，UDP是面向报文的，即直接对应用层下来的报文进行封装，分组的首部开销小
• 速度快，基于以上几个特点，UDP的速度很快，目的保证的就是实时性

二、TCP

TCP作为传输层协议比UDP考虑得多，TCP是一种面向连接的，提供可靠传输的协议，而面向连接TCP需要三次握手、四次挥手进行连接的确认与释放，要提供可靠传输要有滑动窗口机制通过序号确认号保证、能够进行流量控制以及拥塞控制等等

2.1 TCP的特点

• TCP是面向连接的，也就是说在每次进行通信的时候都要进行连接的建立与释放
• TCP提供可靠传输，通过TCP传输的数据，无差错，不丢失，不重复
• TCP提供全双工通信，TCP允许通信双方的应用进程在任何时刻都能进行通信，TCP的接收方和发送方都设置有一个缓存用来临时存放接收或者发送的数据
• 面向字节流，虽然应用层下来的数据时一个一个数据块，但是TCP仅仅把这些数据当做是一连串的无结构的字节流

2.2 TCP的首部报文格式

TCP是面向字节的，但是具体发送的数据还是报文段，而报文段首部的各字段的作用体现了TCP的全部功能，下面介绍一些比较常用到得报文数据段

• 源端口与目的端口：源端口与目的端口各占2个字节，这两个字段是用于分用和复用的标记了进程的端口号，在接收或者发送时就能进行封包和解包

• 序号：序号占4个字节，总共是2^32个序号，当序号用完时可以从0接着编号，在每一个TCP连接中发送的字节流都必须按顺序编号，整个字节流的起始编号必须在建立连接时确定

• 确认号：确认号占4个字节，是期望收到对方下一个报文段的第一个数据字节的序号，也就是说如果确认号为N，则代表在N-1之前的数据都已经确认收到

• 确认ACK：仅当ACK=1时，字段才有效，TCP规定，在连接建立之后必须把ACK=1

• 同步SYN：在连接建立时用来同步需要，当SYN=1而ACK=0时，表明这是一个连接请求报文段，对方若同意建立连接，则在响应数据报里发送SYN=1和ACK=1

• 终止FIN：用来释放一个连接，当FIN=1时表明此连接需要被释放

• 窗口：占2个字节，是指接收方的接收窗口，窗口值告诉发送方：本次发送最多只能发送的数据量大小，因此窗口作为发送方的发送窗口的大小依据

2.3 可靠传输的原理-ARQ协议

自动重传请求(ARQ)是OSI模型中数据链路层和运输层的错误纠正协议，通过确认和超时这两个机制，可以实现在不可靠服务的基础上实现可靠的信息传输，ARQ包括停止等待ARQ和连续ARQ协议

停止等待ARQ协议

1)无差错情况

发送发发送数据包，接收方在规定时间内收到，并且回复确认，发送发再次发送下一次数据报文

2)出现差错

当B在接收M1时出现了差错，则B什么也不错不通知A收到有差错的报文，也有可能是在传输过程中M1被丢失了，B不会发送任何的消息。这是ARQ规定只要A在一定的时间内没有收到B发来的确认报文，就需要进行超时重传。

要实现超时重传，发送方需要设定一个超时重传计时器，并且超时重传计时器的时间应该比数据包一次往返的时间更长一些，发送方还需要对发送完的分组进行备份，以便进行重传，并且需要对每一个数据包进行编号，这样才能在确认是哪一个报文段没有正确发送

3)确认丢失和确认迟到

• 确认丢失 ：确认消息在传输的过程中丢失了。当A向B发送M1时，B收到了M1并且发送确认消息，但是这个确认消息在传输的过程中丢失了，当超时重传计时器的时间到时，A重新发送M1，B收到时应该做：①收到但是丢弃M1，不向上层交付②重新发送确认消息，不会因为发过了M1的确认就不进行发送
• 确认迟到：确认消息在传输过程中被滞留了，同样当A没有在超时重传计时器时间允许的范围内收到B发来的确认消息，需要进行对M1重传，同样的B收到后需要对M1丢弃并且重新发送确认报文，而A可能此时收到了滞留的确认消息，则直接丢弃

连续ARQ协议

连续ARQ协议可以提供信道利用率，发送发维持一个发送窗口例如大小为5，那么也就是说发送方可以一次性发送5个连续的数据报而不需要等待对方的确认。接收方采取累积确认的方式，只需要发送最后一个序列的确认报文，那么发送方即认为接收方收到了该序号之前的所有报文，例如发送发发送了编号为1-5序号的报文，而接收方只需要发送序号为5的确认报文，发送方即认为接收方正确接收到了1-5这个报文段

采用上面方法的优点是信道利用率高容易实现，缺点是不能向发送方反映出接收方已经正确收到的所有分组信息，例如发送方发了5个分组，而接收方丢失了第三个分组，只能对前两个报文进行确认，而发送方只好将后面三个分组都进行重传这就叫做Go-Back-N(回退N)

2.4 流量控制与滑动窗口

要想传输的速度快，应该需要发送方和接收方的共同努力，但是如果发送方过快而接收方来不及接收的话，就需要进行流量控制，而流量控制是靠滑动窗口来实现的，其实也就是报文格式里面的窗口字段，接收方发送的确认报文中的窗口字段可以用来控制发送方窗口的大小，从而影响发送方的发送速率。

加入发送发向接收方发送了一个窗口为0的确认报文，这就告诉发送方不能再发送数据了，这里考虑一种情况，假如过了一段时间后接收方缓冲区可以接收新的数据向发送方发送一个窗口值rwnd=100的报文，但是这个报文丢失了，这就导致发送方一直在等待接收方，造成了一种死锁的现象，为了解决这个问题，TCP为每一个连接设置有持续计时器，只要发送方收到零窗口的通知就启动计时器，当计时器的时间到是就发送一个探测报文，然后接收方在进行确认给出当前的窗口值这就不会造成一直僵持的状态了

2.5 拥塞控制

拥塞控制是为了防止过多的数据注入到网络中，这样可以使网络中的路由器或者链路不至过载，拥塞控制是一个全局性的过程涉及到所有的主机、路由器等等。而相反流量控制需要做的是点对点的控制，流量控制需要做的是抑制发送方的发送速率，以便接收方来的及接受

为了进行拥塞控制，TCP发送方维持一个拥塞窗口(cwnd)的窗口变量，拥塞控制窗口的大小取决于网络的拥塞程度，并且在动态变化，发送方让自己的发送窗口取为拥塞窗口和接收方的接收窗口中较小的一个

TCP进行拥塞控制的算法有四种，慢开始、拥塞避免、快恢复和快重传，下面结合下图进行介绍

• 慢开始：当主机开始发送数据的时候，并不清楚网络中的拥塞程度，如果这时候将大量的数据注入到网络中可能会造成拥塞，所以采取类一种慢慢开始的算法，由小到大增加窗口值的大小。并且设置一个ssthresh慢开始门限，在慢开始阶段每经过一个传播轮次窗口值加倍
• 拥塞避免：当当前窗口值到达慢开始门限时，开始使用拥塞避免算法，拥塞避免算法的思路是让窗口值慢慢的增加，每经过一个RTT时间窗口值就加1，也就是按线性规律增长。根据图当窗口值到达24时出现了一个新情况，超时了，这时候发送方判断出现了拥塞，于是将当前窗口值cwnd=1，满开始门限ssthresh=24/2=12，重新进行慢开始算法以及拥塞控制算法
• 快重传与快恢复：快重传算法要求接收方不要进行捎带确认，而是要进行立即确认，当发送发一连收到三个确认报文时，发送方就知道某个报文端没有发送成功，于是立即使用快重传，重新发送丢失的数据包，同时进行快恢复算法将当前窗口cwnd改为之前的一半

上面的流程图如下：

2.6 连接管理-三次握手

上面多次提到TCP是面向连接的，所以需要连接的建立与释放，下面就来聊一聊TCP的连接建立的过程

在一个TCP的连接建立的生命周期里，一共有以下几种状态：

• LISTEN：等待来自任何远程TCP的连接
• SYN-SEND：发送连接请求后等待匹配的连接请求
• SYN-RECEIVED：表示已接收并方连接请求后等待连接确认，也就是第二次握手的状态
• ESTAB-LISHED：表示连接已经创建成功可以进行数据的传输

如上图是三次握手的连接示意图，TCP规定在客户发起请求连接的时候，不能发送数据而是要消耗掉一个序号，下面来分析一下上面的过程：

1. 客户端主动向服务器端发送连接请求，请求中首部同部位SYN=1，同时选择一个初始序号seq，SYN报文段不允许携带数据，只消耗一个序号，此时客户端进入SYN-SEND状态

2. 服务器端收到客户端发起连接的请求后，需要确认客户端的报文，在确认报文段中需要把SYN和ACK都置一，同时发送一个确认号，也为自己选择一个初始序号，这个报文段也是不能携带数据的，需要消耗一个序号，同时服务器进入SYN-RECEIVED

3. 客户端在收到确认报文之后，还需要给出确认连接报文，确认连接报文找那个的ACK=1，序号为x+1，这个报文可以携带数据，同时客户端进入ESTAB-LISHED

4. 服务器收到确认报文后也进入ESTAB-LISHED

再次分析三次握手的过程，其实建立连接的请求的过程无非是先让对方都知道自己的状态，也就是要让确定对方发送和接收都正常：

• 第一次握手：客户端什么也确认不了，服务器端确认：对方发送正常，自己接收正常
• 第二次握手：客户端确认：自己接收，发送都正常，对方发送，接收也正常，服务器端确认：对方发送正常，自己接收正常
• 第三次握手：客户端确认：自己接收，发送都正常，对方发送，接收也正常，服务器端确认：自己接收，发送都正常，对方发送，接收也正常

所以需要三次握手，缺一不可

为什么要传回SYN与ACK?

传回SYN是在第二次握手中，目的是为了告诉客户端，我接收到的信息确实是你发的信息而不是别人。通信双方无误必须是两者互相发送消息都无误，所以后面还需要传回ACK目的也是要证明两者之间的通道是没有问题的

2.7 连接管理-四次挥手

在一个TCP的连接关闭生命周期里面有以下几种状态：

• FIN-WAIT-1：表示等待来自远程TCP的连接终止请求，或者等待先前发送的连接终止请求
• FIN-WAIT-2：表示等待来自远程TCP的连接终止请求
• CLOSE-WAIT：表示等待本地用户的连接终止请求
• CLOSING：表示等待来自远程TCP的连接终止请求确认
• LAST-ACK：表示等待先前发送给远程TCP的连接终止请求的确认
• TIME-WAIT：表示等待足够的时间以确保远程TCP收到其连接终止确认的请求
• CLOSE：表示连接已经关闭，无连接状态

1. 客户端应用程序发出释放连接的请求报文段，主动关闭连接，报文段首部的FIN=1，不包含数据其中seq=u，此时客户端进入FIN-WAIT-1
2. 服务器收到客户端发来的连接释放报文后，发出确认应答报文，其中ACK=1，生成自己的序列号，然后服务器主机就进入CLOSE-WAIT
3. 客户端收到服务器发来的确认报文后，进入FIN-WAIT-2状态，等待服务器发出连接释放的报文段，此时客户端到服务器端的连接已经释放
4. 当服务器主机没有数据发送的时候，服务器主机发出断开连接的请求报文段其中ACK=1，FIN=1，其中seq不一定是v因为中间可能还发送了数据，发送完请求之后，服务器就进入到LAST-ACK
5. 客户端收到服务器发出的连接断开请求后，客户端需要作出相应，然后进入到TIME-WAIT状态，此时连接还没有关闭，必须经过时间2MSL之后，客户端才会进入CLOSE

需要四次挥手的原因是任何一方都可以在传输数据结束之后发出释放连接的请求，当对方确认之后进入到半关闭状态，当另外一方也没有数据发送的时候则再次发出连接释放请求，因此需要四次

端需要作出相应，然后进入到TIME-WAIT状态，此时连接还没有关闭，必须经过时间2MSL之后，客户端才会进入CLOSE

需要四次挥手的原因是任何一方都可以在传输数据结束之后发出释放连接的请求，当对方确认之后进入到半关闭状态，当另外一方也没有数据发送的时候则再次发出连接释放请求，因此需要四次

上面客户端需要等待2MSL的原因是：①为了保证最后一个响应能够到达服务端，②防止失效的报文段，等待过2MSL时间之后可以确保本连接持续时间内的所有报文段都从网络上消失