网络基础之运输层

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

运输层向它上面的应用层提供通信服务。真正通信的实体是主机的进程，是一台主机中进程和另一个主机进程交换数据

严格来说，ip协议虽然可以把分组按照首部中的目的地址，通过路由器转发送交到目标主机，这个是网络的核心，但也意味着分组依然停留在网络层而没有交付至主机的应用进程。

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、运输层协议概述

如图：运输层一个重要功能–复用与分用。

运输层提供的应用进程之间的逻辑通信是通过虚线方向的多个层次实现传递的，实际上并没有水平方向的方向的物理连接。

二、运输层的端口

1.复用与分用

因为当把进程作为最终终点时，进程是动态的，有时无法识别，需要一个额外的功能去识别（例如某一个服务器是邮件接收的功能不知道由目的主机的哪一个进程实现的），解决这个问题用的就是端口

硬件端口是不同硬件设备交互的接口，所以软件端口就是应用层进程与运输实体之间交互

16位端口 0-65535
熟知端口：0-1023

FTP	SMTP
21	25

SNMP	DNS
161	53

HTTP	HTTPS
80	443

客户端使用端口：49152-65535
短暂端口，进程运行时才存在，进程结束，端口可以提供其他进程

三、UDP

1.概述

• UDP无连接，尽最大努力交付，所以说运输层时可靠的这句话不对，因为只有tcp是可靠的
• UDP是面向报文的，意味着UDP不做合并拆分，应用层给多长，一次性就发多长，所以说如果太长，ip层就要做分片，太短效率又低浪费资源
• UDP没有拥塞控制，但是它支持重传

2.首部格式

UDP伪首部不用理解，重点看首部组成（8byte）与UDP的分用

请注意：如果发现目的端口号不正确，接下来会发生的事情
丢弃报文，icmp发送“端口不可达”差错报文，我们经常做测试的时候就是使用的UDP去发一个数据报给非法端口，然后用traceroute去追踪查看，发现icmp会返回“端口不可达”

3.差错检查

UDP检查与IP数据报首部检查相似，唯一区别是UDP检验和是把首部与数据部分一起验证（IP数据报验证回看即可）

四、TCP

1.概述

• TCP是面向连接的，意味着TCP协议在被应用程序使用前先建立连接，数据传输完毕后要释放
• TCP可靠，全双工
• TCP面向字节流，是一条虚连接，接收与发送双方都是通过字节流的形式处理数据，
• 除此之外最重要的是拥塞控制与根据对方窗口值发送数据

2.连接

TCP的端口拼接(concatenated with)到ip构成套接字socket
socket = ip地址：端口号
e.g. 192.3.4.5: 80 （五元）
socket存在意义：五元组数据打包降低了层与层之间的数据压力

请注意：此处的socket不是运输层与应用层之间的接口的含义，也不是socket数据报的含义，也不是socket函数的含义

3.可靠传输的原理

停止等待协议
每发送一个分组（segment或者packet）就停止等待对方确认，收到确认之后再发送下一组

• 无差错情况
  
• 出现差错：每一个分组都有一个超时计时器（计时器设定不能过长，影响效率；过短反复重传，比rtt长一些，根据时延决定），超过一段时间没有收到确认启动超时重传
• 确认丢失与迟到：这里是针对receiver主机的行为
  
  通常情况下，都是会收到确认的，因此确认迟到的情形其实很多，这种确认重传的机制叫做自动重传请求ARQ(automatic repeat reQuest)

信道利用率
停止等待协议会导致信道利用率过低

Total = Td + RTT + Ta
Td = 发送时间
U = Td/ Total

流水线传输有效提高信道利用率

连续的ARQ
这个协议其实包含了两点：

• 累计确认：确认多个数据报，但只发送一个确认表示目前到这个分组都是正确的，缺点是中间的分组错误没法体现，因此需要第二个点就是回退机制（回退N）
• 回退N(Go-back-N)：接着上述情形如果中间分组出错，必须回退至出错位置，然后全部重传，所以如果是线路信号质量不好，效率很低与停止等待相比。所以说最优解：SELECTICE REPEAT 选择重传

4.TCP首部

首部固定20字节长

• 原端口目标端口：各占16位
• 序号：4字节 字节序号 发送时序号301，报文长100，序号400
• 确认号：4字节 接受时收到的序号401，报文长200，期待下次确认好600
• 数据偏移：4位 0000-1111 range为0-15 1532bit = 154字节=60字节 tcp首部最大长度
• 保留 6位
• 紧急(URG): 数据紧急优先传送，例如终止命令control+C 优先传送至应用进程
• 确认(ACK)：确认连接建立
• 推送(PSH)：尽快发送，不等缓存满了再交付
• 复位(RST)：释放异常连接，作用等同udp端口不可达时icmp发送的报文
• 同步(SYN)：请求连接
• 终止(FIN)：释放连接
• 窗口：窗口值作为接收方让发送方设置其发送窗口的依据，明确现在对方允许发送的数据量
• 检验和：和udp相似
• 紧急指针：配合紧急flag使用的
• 选项：最多40字节，当选项为0，首部长度20字节
  MSS(Maximum Segment Size) 每一个tcp报文段中数据的最大长度， 不能太短影响开销，不能太长不然ip层要分片
  时间戳（timestamp）计算rtt，防止序号绕回，类似一个标记的功能

5.TCP可靠传输的实现（与原理重复做补充）

滑动窗口
因为是全双工的，所以发送方与接收方都有自己的窗口，发送窗口不能大于接受；
对于已发送只有收到确认之后才视为完成，否则需要储存在缓存中；
通过三个指针控制已发送已确认，已发送未确认，允许发送未发送以及不允许发送部分数据；

重传时间的选择
之前提过原理通过超时重传实现可靠，时间的话稍微长过rtt，问题是如果是每次都是一样的重复确认报文，那么这个无效的rtt会影响判断

重传方法的选择

重传的方法有之前提及的回退N, 选择确认重传SACK，快速重传等

总结一下就是tcp的可靠来源于它的停止等待和超时重传，而滑窗更多的是利于控制流量的时候

6.TCP控制

重点是流量控制与拥塞控制是不一样的

1. 流量控制：通过滑窗可以很好的控制每次发送的数据量
   如果接收方感觉数据流量高了，就发信号给发送方进行流量控制，减小发送窗口甚至到0；如果感觉又好了，就发信息说可以了，但是这个报文如果刚好丢了，就不太妙，所以需要设置一个持续计时器来负责重传
2. 拥塞控制：拥塞congest与流量的区别是拥塞不是针对接受方控制，而是针对注入网络中的数据量做控制，防止过多数据存在于网络中，减少网络负担；
3. 拥塞控制的依据是网络负载量offered load与吞吐量throughput
   在负载越高那么吞吐越高，但是注入过多数据导致了拥塞影响吞吐，所以需要控制拥塞，否则一旦负载过高直接死锁；当然吞吐量也是有上限的

拥塞控制方法一共4种方法

拥塞判断的依据就是出现超时

慢开始：由小到大逐渐增加发送窗口，去探测拥塞情况

当慢开始使用使得窗口增加到一定地步时，到达临界值threshold，改用拥塞避免算法

除此之外，一个大家都熟知的快速重传法（3个重复的ack报文立刻开启重传）也在这里使用，所以我们应当理解，快速重传不是用于保证tcp可靠性的，因为tcp只要是超时重传ARQ就是可以保证可靠了而快速重传只是其中一个方法，但是在拥塞控制方面，快速重传意义非凡。

7.三次握手与四次挥手

通过图一我们分析握手：

首先客户端发送syn请求连接，然后服务器收到连接请求之后发送确认返还给客户端，然而这是两次握手，然而在此刻服务器为何还没建立连接？

服务器第一次接受到请求之后b知道客户端可以正常发送，a收到服务器的回复之后a知道服务器可以正常接受与发送，但是b始终不知道客户端是否能正常接受，所以最后一次证明给b看，客户端也是可以收到你的信息的，同时防止中途有异常情况两次确认可以避免错误连接

图二看出挥手比握手多了一次中间服务器处于半关闭时候的多一条线，为什么？

因为当客户端发出关闭的时候，第一次握手A->B的数据就已经关闭了，但是服务器刚收到这个关闭要求，它可以立刻回复你确认，但是有的数据可能刚好传到一半，你要让他传完那就需要一些时间，所以才有了多一次，那么当数据传完了，B->A的数据就也关闭了

关闭比建立连接还有一个麻烦的就是关闭更加害怕报文丢失，因为连接如果丢失了顶多就是不连或者再发一遍，但是关闭的话如果一边关了另外一遍还在等确认报文就会出现死锁情况，这也是为何客户端先不做关闭而是等2msl自己关闭的原因：

防止服务器收不到最后的ack，如果不关，异常出现了至少b重传fin confirm客户端可以收到，这样可以再发一遍最后的ack

2msl同样保证了A可以等至少一个报文来回的时间去给B重传的时间，同时可以清除已经失效的报文不要出现在网络中

保活计时器 keepaliver timer：这个适用于防止客户端在连接中突然异常关闭，此时服务器还不知道，用这个计时器去发送探测报文，如果没有回应，自己就可以关了

总结

提示：重点习题