传输层_计算机网络

文章目录

运输层

运输层

网络层提供了主机之间的逻辑通信

运输层为运行在不同主机上的进程之间提供了逻辑通信

UDP(用户数据报协议 )提供一种不可靠 、无连接的服务，数据报

TCP(传输控制协议 )提供一种可靠的 、面向连接的服务，报文段

UDP和TCP的基本职责：将两个端系统间IP的交付服务扩展为运行在端系统上的两个进程之间的交付服务

UDP和TCP可通过在其报文段首部中包括差错检查字段而提供完整性检查

进程间的数据交付和差错检查是两种最低限度的运输层服务，也是UDP所能提供的

多路分解：将运输层报文段中的数据交付到正确的套接字
多路复用：在源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息从而生成报文段，然后将报文段传递到网络层

nmap：端口扫描器

shell 复制代码

sudo apt install nmap
umap hostName

Application	Application-Layer Protocol	Underlying Transport Protocol
Electronic mail	SMTP	TCP
Remote terminal access	Telnet	TCP
Secure remote terminal access	SSH	TCP
Web	HTTP，HTTP/3	TCP(for HTTP )，UDP(for HTTP3)
File transfer	FTP	TCP
Remote file server	NFS	Typically UDP
Streaming multimedia	DASH	TCP
Internet telephony	typically proprietary	UDP or TCP
Network management	SNMP	Typically UDP
Name translation	DNS	Typically UDP

UDP

UDP只是做了运输协议能够做的最少工作，多路复用/分解功能+少量差错检测。UDP优点：

无拥塞控制，关于发送什么数据以及何时发送的应用层控制更为精细
无需建立连接
无连接状态
分组首部开销小

长度：UDP报文段中的字节数=首部+数据

UDP检验和提供了差错检测功能，检验和用于确定当UDP报文段从源到达目的地移动时，其中的比特是否发生了变化，对差错恢复无能为力。丢弃受损的报文段、或将受损的报文段交给应用程序并给出警告。

TCP

TCP的"连接"是一条逻辑链接，其共同状态仅保留在两个通信端系统的TCP程序中，是全双工的

TCP可以从缓存中取出并放入报文段中的数据数量受限于最大报文段长度 (Maximum Segment Size，MSS )，MSS通常根据最初确定的由本地发送主机发送的最大链路层帧长度 (最大传输单元，Maximum Transmission Unit，MTU)来设置。MSS指在TCP报文段里应用层数据的最大长度，而不是指包括首部的TCP报文段的最大长度

TCP报文段：首部字段+数据字段

32比特的序号字段 和32比特的确认号字段 ：实现可靠数据传输服务
- 对数据流中的每一个字节编号，TCP把数据看成一个无结构的、有序的字节流
- TCP存在序号字段，报文段需要填入某个序号(即使该报文段里没有数据仍有序号)
- 累计确认，确认可被捎带在数据报文段中
- 一条TCP连接双方均可随机地选择初始序列(可减少将那些仍在网络中存在的来自两台主机之间先前已终止的连接的报文段，误认为是后来这两台主机之间新建连接所产生的有效报文段的可能性，新连接与旧连接碰巧使用了相同的端口号)
16比特的接收窗口字段：用于流量控制，指示接收方愿意接收的字节数量
4比特的首部长度字段：以32比特的字为单位的TCP首部长度
可选与变长的选项字段：用于发送方与接收方协商最大报文段长度MSS，或在高速网络环境下用作窗口调节因子时使用
6比特的标志字段 ：
- ACK：用于指示确认字段中的值是有效的，即该报文段包括一个对已被成功接收报文段的确认
- PSH：指示接收方应立即将数据交给上层
- URG：指示报文段里存在着被发送端的上层实体置为"紧急"的数据，紧急数据的最后一个字节由16比特的紧急数据指针字段指出。当紧急数据存在并给出指向紧急数据尾指针的时候，TCP必须通知接收端的上层实体
- RST：服务端向客户端发送RST报文段，告诉客户端不要再发送了，服务端没有客户端想要的端口
- RST，SYN，FIN：用于建立连接和拆除
- CWR，ECE：在明确拥塞通过中使用
16bit的紧急数据指针字段：指出紧急数据的最后一个字节

TCP连接管理

TCP三次握手

需要确定双方的发送和接收能力，SYN报文没有建立连接时，处理应用层数据耗时耗空间

客户端向服务端发送不包含应用层数据的SYN报文段(SYN=1 )，随机初始序号(client_isn)，TCP规定SYN=1时不能携带数据，但要消耗一个序号，确认客户端的发送能力
服务端为该TCP连接分配TCP缓存和变量，并向客户TCP发送不包含应用层数据的SYNACK报文段(SYN=1，ACK=1，确认号=client_isn+1 )，随机初始序号(server_isn)，确认服务端的接收和发送能力
客户端为该TCP连接分配TCP缓存和变量，并向服务TCP发送可包含应用层数据的ACK报文段(SYN=0，ACK=1，确认号=server_isn+1 )，确定客户端的接收能力。如果客户端不发送ACK，最终服务端将终止该半开连接并回收资源

不能两次握手原因：

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

如果只是两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的起始序列号则得不到确认

TCP四次挥手

客户端发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN_WAIT_1（终止等待1）状态
服务器端接收到连接释放报文后，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE_WAIT 关闭等待状态 ，此时TCP处于半关闭状态，客户端到服务器的连接释放
客户端接收到服务器端的确认请求后，客户端就会进入FIN_WAIT_2（终止等待2）状态 ，等待服务器发送连接释放报文，服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，seq=w，服务器就进入了LAST_ACK（最后确认）状态，等待客户端的确认
客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME_WAIT（时间等待）状态，但此时TCP连接还未终止，必须要经过2MSL后（最长报文寿命），当客户端撤销相应的TCP后，客户端才会进入CLOSED关闭状态，服务器端接收到确认报文后，会立即进入CLOSED关闭状态，到这里TCP连接就断开了，四次挥手完成

四次挥手的原因：TCP双向通道相互独立

半关闭：TCP提供了连接的一方在结束它的发送后还能接受来自另一端数据的能力。通俗来说，就是不能发送数据，但是还可以接收数据。

TCP不允许连接处于半打开状态时，就单向传输数据，因此完成三次握手后才可以传输数据(第三握手可以携带数据)。当连接处于半关闭状态时，TCP是允许单向传输数据的，也就是说服务器此时仍然可以向客户端发送数据，等服务器不再发送数据时，才会发送FIN报文段，同意现在关闭连接。

为什么中间的ACK和FIN不可以像三次握手那样合为一个报文段呢？

在socket网络编程中，执行close()方法会触发内核发送FIN报文。什么时候调用close()方法，这是由用户态决定的，假如服务器仍有大量数据等待处理，那么服务器会等数据处理完后，才调用close()方法，这个时间可能会很久，而ACK报文则是由系统内核来完成的，这个过程会很快。所以中间的ACK和FIN不能合为一个包。

2MSL：

MSL(Maximum Segment LifeTime)是报文最大生成时间，它是任何报文在网络上存在的最长时间，超过这个时间的报文将被丢弃。MSL（时间）>=TTL（跳数），确保报文已被丢弃。

TIME_WAIT等待的2MSL时间，可以理解为数据报一来一回所需要的最大时间。TIME_WAIT状态占用系统资源（端口号......），最好让客户端主动断开连接。

2MSL时间是从客户端接收到FIN后发送ACK开始计时的。如果在这个时间段内，服务器没有收到ACK应答报文段，会重发FIN报文段，如果客户端收到了FIN报文段，那么2MSL的时间将会被重置。如果在2MSL时间段内，没有收到任何数据报，客户端则会进入CLOSE状态。

保证客户端最后发送的ACK能够到达服务器，帮助其正常关闭。

由于这个ACK报文段可能会丢失，使得处于LAST_ACK状态的服务器得不到对已发送FIN报文段的确认，从而会触发超时重传。服务器会重发FIN报文段，客户端能保证在2MSL时间内收到来自服务器的重传FIN报文段，从而客户端重新发送ACK应答报文段，并重置2MSL计数。

假如客户端不等待2MSL就之间进入CLOSE状态，那么服务器会一直处于LAST_ACK状态。

当客户端发起建立SYN报文段请求建立新的连接时，服务端会发送RST报文段给客户端，连接建立的过程就会被终止。

防止已失效的连接请求报文段出现在本连接中

TIME_WAIT等待的2MSL时间，确保本连接内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

可靠机制

回退N步(GBN)协议/滑动窗口协议 ：允许发送方发送多个分组而不需等待确认，接收方丢弃所有失序分组(不缓存)，一个定时器

选择重传(SR)协议 ：让发送方仅重传那些它怀疑在接收方出错(即丢失或受损)的分组而避免了不必要的重传，一个分组一个定时器

SR接收方窗口太大：是一个新分组or一次重传
窗口长度必须小于或等于序号空间大小的一半

可靠数据传输机制及其用途的总结：

机制	用途和说明
检验和	用于检测在一个传输分组中的比特错误
定时器	用于超时/重传一个分组，可能因为该分组(或其ACK)在通信中丢失了。由于当一个分组延时但未丢失(过早超时)，或当一个分组已被接收方收到但从接收方到发送方的ACK丢失时，可能产生超时时间，所以接收方可能会收到一个分组的多个冗余副本 ARQ(自动重传请求协议，Automatic Repeat reQuest)
序号	用于为从发送方流向接收方的数据分组按顺序编号。所接收分组的序号间的空隙可使接收方检测出丢失的分组。具有相同序号的分组可使接收方检测出一个分组的冗余副本
确认	接收方用于告诉发送方一个分组或一组分组已被正确地接收到了。确认报文通常携带着被确认的分组或多个分组的序号。确认可以是逐个的或累积的，这取决于协议
否定确认	接收方用于告诉发送方某个分组未被正确地接收。否定确认报文通常携带着未被正确接收的分组的序号
窗口、流水线	发送方也许被限制仅发送那些序号落在一个指定范围内的分组。通过一次允许发送多个分组但未被确认，发送方的利用率可在停等操作模式的基础上得到增加。窗口长度可根据接收方接收和缓存报文的能力、网络中的拥塞程度或两者情况来进行设置

往返时间：

在任意时刻，TCP仅为一个已发送的但目前尚未被确认的报文段估计SampleRTT。TCP绝不为已被重传的报文段计算SampleRTT，它仅为传输一次的报文段测量SampleRTT

重传超时间隔：

超时间隔在每次重传后会呈指数型增长
每当定时器收到上层应用的数据和收到ACK中的任意一个启动时，TimeoutInterval由最近的EstimatedRTT值与DevRTT值推算得到

使用单一的重传定时器，即使有多个已发送但还未被确认的报文段，定时器超时时重传，快速重传

产生TCP ACK的建议：

事件	TCP接收方操作
具有所期望序号的按序报文段到达。所有在期望序号及以前的数据都已经被确认	延迟的ACK。对另一个按序报文段的到达最多等待500ms。如果下一个按序报文段在这个时间间隔内没有到达，则发送一个ACK
具有所期望序号的按序报文段到达。另一个按序报文段等待ACK传输	立即发送单个累积ACK，以确认两个按序报文段
比期望序号大的失序报文段到达。检测出间隔	立即发送冗余ACK，指示下一个期待字节的序号(其为间隔的低端的序号)
能部分或完全填充接收数据间隔的报文段到达	倘若该报文段起始于间隔的低端，则立即发送ACK

一旦收到3个冗余ACK，TCP就执行快速重传，即在该报文段的定时器过期之前重传丢失的报文段

流量控制

消除发送方使接收方缓存溢出的可能性，匹配发送速率与接收速率

TCP 通过让发送方维护一个称为接收窗口（receive window）的变量来提供流量控制，接收窗口用于给发送方一个指示------该接收方还有多少可用的缓存空间。

接收窗口rwnd = 接收缓存RcvBuffer - [应用进程从缓存读出的数据流的最后一个字节的编号LastByteRead - 从网络中到达的并且存放在接收缓存中的数据流的最后一个字节的编号LastByteRcvd]。开始时，rwnd = RcvBuffer

发送方的未被确认的数据量LastByteSent - LastByteAcked <= rwnd

接收方将rwnd放入接收窗口字段中来告知发送方还有多少可用空间，通过将发送但未确认的数据量控制在值rwnd以内，就可保证发送方不会使接收方的接收缓存溢出。TCP仅当在它有数据或有确认要发出时才会发送报文段 ，当接收方的接收窗口为0时，发送方继续发送只有一个字节数据的报文段，这些报文段将会被接收方确认，最终缓存开始清空，并且确认报文里将包含一个非0的rwnd值

拥塞控制

防止过多的数据注入到网络导致网络崩溃和超负荷问题

拥塞控制方法：根据网络层是否为运输层拥塞控制提供了显式帮助分类

端到端拥塞控制，TCP采用，没有帮助，端系统通过对网络行为的观察判断
网络辅助的拥塞控制，有帮助，路由器向发送发提供关于网络中拥塞状态的显式反馈信息

TCP采用让发送方根据所感知到的网络拥塞程度来限制其发送速率。ACK------不拥塞信号；丢包时间(超时、冗余ACK)------拥塞信号。

通过调节拥塞窗口（congestion window，cwnd）的大小可以限制TCP发送方能向网络中发送流量的速率。发送方的未被确认的数据量LastByteSent - LastByteAcked <= {cwnd，rwnd}。

当发送方出现丢包事件就说明拥塞了，应当降低TCP发送速率，路由器缓存满了会引起一个数据报被丢弃。

TCP是自计时的，TCP使用确认来触发增大拥塞窗口长度，当对先前未确认报文段的确认到达时，应当增加发送速率。

TCP拥塞控制算法 (TCP congestion control algorithm)：慢启动和快速重传是TCP的强制部分，两者的差异在于对收到的ACK做出反应时增加cwnd长度的方式，慢启动比拥塞避免能更快地增加cwnd的长度；快速恢复是推荐部分，对TCP发送方并非必需的。

慢启动
TCP连接开始时，cwnd = MSS，cwnd以1个MSS开始并且每当传输的报文段首次被确认就增加1个MSS。

结束方式：
1. 超时：TCP发送方置cwnd=1并重新开启慢启动过程，并设置慢启动阈值 (ssthresh=cwnd/2)为拥塞窗口值的一半。
2. 当cwnd=ssthresh时：结束慢启动并且TCP转移到拥塞避免模式。
3. 3个冗余ACK：TCP快速重传，并进入快速恢复状态。
拥塞避免
每个RTT只将cwnd的值增加1个MSS，对于TCP发送方无论何时到达一个新的确认，就将cwnd增加一个 MSS*(MSS/cwnd) 字节。

结束方式：
1. 超时：cwnd = 1，ssthresh = cwnd / 2
2. 3个冗余ACK：cwnd /= 2，ssthresh = cwnd / 2，并进入快速恢复状态
快速恢复
对于引起TCP进入快速恢复状态的缺失报文段，每当收到冗余的ACK，cwnd的值增加一个MSS。当对丢失报文段的一个ACK到达时，TCP在降低cwnd后进入拥塞避免状态。

结束方式：
1. 超时：cwnd = 1，ssthresh = cwnd / 2，并进入慢启动状态
2. 丢包：cwnd=MSS，ssthresh = cwnd/ 2

QUIC

QUIC （快速UDP互联网连接）是应用层协议，旨在提高安全HTTP的运输层服务的性能，使用UDP，专门为简化的HTTP/2版本而设计的。主要特征：

面向连接和安全
数据流
可靠的、TCP友好的拥塞控制数据传输

参考：

计算机网络：自顶向下方法