计算机网络_传输层详解

文章来源：我的个人技术博客

计算机网络-传输层/运输层详解

一. 传输层概述

1. 进程之间的通信

运输层向上层【应用层】提供端到端的逻辑通信服务，即应用到应用的通信服务。只有两个主机之间的协议栈才会有传输层，网络核心部分中只用到下面的三层【网络层，数据链路层，物理层】

上述中逻辑通信的意思是：

运输层之间的通信好像是沿着水平方向传送数据，但事实上两个运输层之间没有水平方向的物理连接，需要按照虚线的方向多次传送。

如下图所示。

2.因特网的传输层协议

2.1 分类

因特网（一般是TCP/IP网络）为上层提供两个不同的传输层协议。

1. 用户数据报协议（User Datagram Protocol UDP协议）

2. 传输控制协议(Transmission Control Protocol TCP协议)

2.2 区别

	TCP传输控制协议	UDP用户数据报协议
可靠性	可靠	不可靠
连接性	面向连接	无连接
传输单位	报文段	用户数据报
效率	满	快
双工性	全双工	一对一，一对多，多对多
流量控制	滑动窗口	无
拥塞控制	满开始，拥塞避免，快重传，快恢复	无
优点	保证传输质量可靠	灵活、轻量、传输速度快
缺点	传输速度慢	不保证传输质量
适用场景	用于在传输层有必要实现可靠传输的情况	用于那些对高速传输和实时性有较高要求的通信或广播通信

2.3 应用

使用UDP和TCP协议的各种网络应用如下所示

应用	应用层协议	运输层协议
域名解析	DNS	UDP
文件传输	TFTP	UDP
IP地址配置	DHCP	UDP
网络管理	SNMP	UDP
远程文件服务器	NFS	UDP
多播	IGMP	UDP
电子邮件	SMTP	TCP
远程终端接入	TELNET	TCP
万维网	HTTP	TCP
文件传输	FTP	TCP

注： HTTP1.0和HTTP2.0使用TCP协议 HTTP3.0使用UDP协议

３.复用分用

３.１复用

复用指同一个发送端主机中的多个应用层使用同一个运输层协议传输数据。

３.２分用

分用指在同一个接收端主机传输层剥去报文的首部之后将数据正确的交付给目的应用程序

３.３端口号

背景

复用和分用的前提是能够分辨同一个主机中不同的应用程序。在TCP/IP中，使用一种和操作系统无关的协议端口号。

概念

端口号用16位（2个字节）来表示，能表示的最大范围是0~65535.

二.用户数据报协议（UDP）

1.概述

提供无连接服务 发送数据之前不需要建立连接。因此减少了传输开销，降低了传输时延。
最大努力交付 不保证传输质量，即不保证可靠交付。
无拥塞控制机制 出现网络拥塞不会使源主机的发送速率降低，对某些实时应用很重要。比如IP电话，视频会议等。
面向报文 应用层交给一个报文，UDP就会将其发送出去。如果过大，底部的网络层会将其分片，会降低效果，如果过小，则降低了网络层的传输效率。
支持一对一，一对多，多对多。
首部8字节，比TCP协议的20个字节少。

2.首部格式

UDP的首部共8个字节

源端口，目标端口各2个字节。
长度：UDP用户数据报的长度
检验和：差错检测码，防止UDP用户数据报在传输中出错。如何计算检验和：１.　在UDP首部添加12个字节的伪首部，只是为了计算检验和，不向下传送也不向上递交。

关于伪首部

源IP与目标IP各占4字节
第三个字段固定0，占一个字节
第四个字段为协议号，当协议为TCP时，此字段是6.
第四个字段是UDP用户数据报的长度。这样的检验和，既检查了UDP用户数据报信息，又检查了IP地址。

三.传输控制协议（TCP）

1.TCP的特点

面向连接 在传输数据之前，会先建立连接。具体来说，数据收发双方的内存中都建立一个用于维护数据传输状态的对象，比如双方 IP 和端口是多少？现在发送了多少数据了？状态健康吗？传输速度如何？等。所以，连接是网络行为状态的记录。
一对一 建立连接之后，连接被通信两端的端点确定。
全双工 TCP 是一个双工协议，数据任何时候都可以双向传输。
可靠交付 由于发送数据之前建立了连接，并且接收端接收到数据之后会返回一个确认，所以TCP传输的数据是可以保证无差错，不丢失，不充分，有序到达的。
面向字节流 应用程序交给TCP的是大小不等的数据块，但是TCP会认为是一串无结构的字节流，TCP会取出特定大小的数据陆续写入TCP发送缓存中。

为什么要这么处理呢？

为了稳定性，一次发送的数据越多，出错的概率越大。
为了效率，网络中有时候存在着并行的路径，拆分数据包就能更好地利用这些并行的路径。
大量的应用频繁地通过网卡收发数据，这个时候，网卡只能一个一个处理应用的请求。当网卡忙不过来的时候，数据就需要排队，也就是将数据放入缓冲区。如果每个应用都随意发送很大的数据，可能导致其他应用实时性遭到破坏。

因此，TCP会按照应用交给的数据块进行拆包和封包处理。

拆包数据经过拆分，然后传输，然后在目的地重组，俗称拆包。
封包如果发往一个目的地的多个数据太小了，为了防止多次发送占用资源，TCP 协议有可能将它们合并成一个 TCP 段发送，在目的地再还原成多个数据，这个过程俗称粘包。

2.TCP报文段格式

TCP报文段首部的前20个字节是固定的，后面有4N个字节是根据需要增加的选项。

各字段含义如下

源端口/目标端口各占2字节，用于传输层的复用和分用。
序号占4字节，在发送数据时，TCP会为每一个字节的数据都按顺序编号，该字段表示这个TCP报文段中数据部分的第一个字节的序号。
确认号占4字节，期望收到对方的下一个报文段的第一个字节的序号。
数据偏移占4位。单位是4字节。因此，最大值是2^4=15 TCP Header 部分的长度是可变的，因此需要一个数值来描述数据从哪个字节开始。也就是最大偏移为15*4=60个字节即TCP首部的最大长度为60个字节。
保留用于日后扩展能力。
标志位各占1位
- URG 代表这是一个紧急数据，比如远程操作的时候，用户按下了 Ctrl C，要求终止程序，这种请求需要紧急处理。
- 确认ACK 代表响应，所有的消息都必须有 ACK，这是 TCP 协议确保稳定性的一环。只有此字段为1时，首部的确认号才有意义。
- PSH 代表数据推送，也就是在传输数据的意思。出于效率的原因，TCP可能会延迟发送数据，这样可以一次处理多个数据。当此字段为1时，TCP不会等待，会立即发送。现在TCP会根据情况自动设置此字段的值。不会交给应用处理。
- RST 重置位，当连接中断时，将此置1，表示需要重新连接。
- SYN 同步请求，也就是申请握手。用来建立一个连接。当SYN=1，ACK=0时，表示是一个连接请求。当SYN=1，ACK=1时，表示是一个接收方同意连接的响应。
窗口占2字节。表示发送端的接收窗口的大小，用来控制对方发送的数据量。单位是字节。 计算机网络经常用接收方的窗口大小来控制自己的数据发送量。
检验和 2字节。和UDP一样，会加上伪首部然后计算。此时，伪首部中的协议字段应该是6.长度应该是TCP报文段的长度。
紧急指针指向最后一个紧急数据的序号（Sequence Number）。它存在的原因是：有时候紧急数据是连续的很多个段，所以需要提前告诉接收方进行准备。
选项 Options 中存储了一些可选字段，比如MSS。表示发送方的缓存能接受的报文段的最大长度是MSS个字节。它是一个协商字段（Negotiate）。协议是双方都要遵循的标准，因此配置往往不能由单方决定，需要双方协商。过大，接收方会拒绝，并且会占用网络资源。过小那头部的数据占比会上升，会浪费传输资源，降低吞吐量。因此，MSS设置为不超过IP层分片的最大长度即可。
填充因为 Options 的长度不固定，需要 Pading 进行对齐为整数字节。

3. TCP报文段的可靠传输

数据编号和确认 TCP是面向字节的，会将应用层传递下来的报文传递下来的报文切分为报文段，然后看成是一个字节一个字节的字节流，将其用递增的序号编号，在连接开始时，就会确定这个序号的初始值。发送时，TCP报文段首部的ack字段就是期望接收到的字节的序号，也就是在这个序号之前的全部已经确认接收完毕。
字节为单位的滑动窗口 TCP 作为一个传输层协议，最核心的能力是传输。传输需要保证可靠性，还需要控制流速，这两个核心能力均由滑动窗口提供。滑动窗口的单位为字节。下图为滑动窗口的概念

发送缓存中分为已经发送并收到确认的报文段，滑动窗口部分，不允许发送的报文段。 滑动窗口内的为允许发送的报文段。当收到报文的确认之后，滑动窗口向右滑动，直到滑动窗口的左侧正好包含确认序号的字节。然后发送缓存就会将已经发送并确认的字节从缓存中移除，让接下来的数据使用。在滑动窗口中，系统维护一个发送指针，每发送一个报文段，指针就向前移动一位。当移动到滑动窗口的最右部分，就无法继续发送，必须等待收到之前报文段的确认，滑动窗口向右滑动。 滑动窗口和发送缓存的关系

发送窗口只是发送缓存的一部分。已发送但未被确认数据大小<=发送窗口的大小。
发送缓存都应该是环形队列，并且是循环使用的。
当收到确认之后，滑动窗口左侧会按照确认号滑动到该字节，同时发送缓存也会将发送并成功收到确认的字节从缓存中删除。右侧会按照返回的确认首部中的窗口大小调整到对应的位置。
发送应用程序必须控制写入缓存的速率，不能太快，否则发送缓存会没有存放数据的空间。

滑动窗口和接收缓存的关系

滑动窗口只是接收缓存的一部分。
接收缓存都应该是环形队列，并且是循环使用的。
当收到按序到达的报文段时，滑动窗口左侧向右移动。右侧应该和接收缓存重合
当收到未按序到达时，会放入接收窗口中，等待接收正确序号，然后滑动窗口向右移动。
当收到的报文段根据首部的检验和计算出发送差错时，会丢弃。
当应用程序从接收缓存中读取到已经按序到达的数据之后，接收缓存会将这些数据删除，因为是一个环形队列，所以接收缓存和滑动窗口的右侧都会向右移动读取的字节数。
如果接收应用程序来不及读取收到的数据，接收缓存最终会被填满，使接收窗口减少到0
如果接收应用程序能够及时从接收缓存中读取收到的数据，接收窗口可以增大，但最大不能超过接收缓存的大小。

超时重传当TCP每发送一个报文段，就会在重传队列中缓存这个报文段的副本，并且设置一个计时器，当收到确认号后会将其从重传队列中移除。当计时器时间到了还没有收到确认，就会重新发送这个报文段。 超时重传的时间选择
- 时间过长：大量的丢失的报文段不会即使的重传，降低传输效率。
- 时间过短：很多报文还没来的及传输，就会被认为丢失，引起不必要的重传，加大网络负荷。
- 时间计算：超时重传的时间应该取决于当前报文段的往返时间(Round-trip Time RTT) 稍微长一些。 RTT的计算采用指数加权平均移动算法来计算，得出报文段的平均往返时间RTT(s) 新的RTT(s) = (1-α)*旧的RTT(s) α * 上一个RTT(s) （典型的α取1/8）超时重传时间(Retransmission Time-Out RTO )应当略大于上边的RTT(s)即可。
快速重传 快速重传是对超时重传的一种补充 当超时重传的时间设置过长的时候，发送方并不会马上知道需要重新发送，因此，接收方在接收到后续的报文段而没有收到之前的某个报文段的时候，会将之前没收到的报文段的开始需要放入后续报文段的确认号中，当发送方一连接收到3个同样的确认号时，认为这个报文段已经丢失，立即重新发送。
选择确认如上快速重传中所示，后续的报文段接收方已经收到了，但是发送方并不知道，他们的确认中填写的是之前没有收到的报文段的序号，所以，这些已经收到的报文段会等超时之后再次发送，选择确认可以解决这个问题。通过报文段中的选项字段添加SACK字段，存放已经收到的报文段的字节开始序号和结束序号。

4.流量控制

**接收窗口的大小可以用来控制 TCP 协议的流速。**这样，就可以避免发送方发送太快而接收方的接收缓存溢出的问题。

具体实现：

发送端的发送窗口在连接建立时由双方商定。但在通信的过程中，接收端可根据自己的资源情况，随时动态地调整对方的发送窗口上限值(可增大或减小)。发送方收到的确认中的窗口大小是接收方的滑动窗口大小。发送方的滑动窗口必须小于等于这个值。接收方根据自己的接收能力控制发送方的发送速率。因此，流量控制是一个速度匹配服务，可以保证发送方的发送速率和接收方的程序的读取速率保持一致。

这种由接收方来控制发送方的做法，在计算机网路中经常使用。

窗口探测

当应用程序读取速度过慢，导致接收缓存中全部均为按序到达需要读取时，接收窗口大小被挤压为0，此时，返回给发送方的确认首部窗口大小为0，则发送方的滑动窗口的右侧会和左侧重叠，发送方的滑动窗口也变为0。发送方会一直等下去。为避免发生这种死锁状态，发送方会周期性（默认为60s）的发送一个字节数据的窗口探测报文段，以便强制接收方返回即时的窗口大小。当此时发送方的接收窗口依然为0，则接收方会丢弃这个字节并重复以前的数据进行确认。如果此时窗口大小不为0，则收到这个窗口探测的一个字节的数据并返回发送方确认消息。

综上所述，TCP的流量控制协议实现了发送应用程序的发送速率和接收应用程序的接受速率的匹配。

5.TCP的连接管理

三次握手

具体步骤、

第一次握手 客户端向服务端发送一个连接请求，在请求头中的SYN为1，表示这是一个连接请求。seq=x,x为一个随机数，表示接下来发送的数据从此序号开始递增。即下一个报文的序号应该是X 1。
第二次握手 服务器收到客户端的连接请求之后，如果同意，则发回一个连接请求确认。在这个报文段首部中，SYN=1，ACK=1。表示这是一个连接请求确认报文。,seq=y，y也是一个随机数，表示下一个返回数据的报文的序号应该是y 1。ack=x 1,表示希望下一次收到的数据是x 1。
第三次握手 客户端收到服务器的连接请求确认报文段之后，还需要向服务器发送一个确认，此时，SYN=0,ACK=1,序号seq=x 1。确认号ack=y 1,表示希望收到服务器的下一个数据序号为y 1。

此时，连接已经建立。 为什么要进行三次握手呢？ 为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

当采用两次握手 客户端发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。
当采用三次握手 采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。主要目的防止server端一直等待，浪费资源。

四次挥手

TCP的有限状态机

每一个方框表示一个状态，箭头表示状态变迁，箭头上的文字表示引起状态变迁的原因。绿色粗线表示客户端，红色虚线表示服务器，红色细线表示非正常。 CLOSED：无连接是活动的或正在进行 LISTEN：服务器在等待进入呼叫 SYN_RECV：一个连接请求已经到达，等待确认 SYN_SENT：应用已经开始，打开一个连接 ESTABLISHED：正常数据传输状态 FIN_WAIT1：应用说它已经完成 FIN_WAIT2：另一边已同意释放 ITMED_WAIT：等待所有分组死掉 CLOSING：两边同时尝试关闭 TIME_WAIT：另一边已初始化一个释放 LAST_ACK：等待所有分组死掉