计算机网络之传输层

概述

注：10位k，20位兆，30位G，32b->4个G

功能：为运行于不同主机上的各个应用程序进程之间提供逻辑通信（logical communication），隐藏通信子网细节，是完全的端到端。

传输层协议运行在端系统（end systems）中
发送端: 将应用程序数据（messages）分割为段（segments）再递交给网络层
接收端: 重组各段为messages再提交给应用层
应用、传输及网络层逻辑关系（注意地址问题）

PDU(协议数据单元）的嵌套关系

（TPDU-传输层PDU）

为何需要传输层？
1.传输层提供的服务
面向连接： TCP（可靠）
面向非连接：UDP（不可靠）
网络层的服务？
为何需要一个重复的传输层？
网络层: 是在主机hosts之间的逻辑通信
传输层：是在主机的进程processes之间的逻辑通信，即可以让多个网络应用同时在host上运行
它使用并依靠网络层的服务，同时当通信子网出现问题时可以重新建立端到端的服务，即增强了网络层的服务

传输层服务原语

服务原语（service Primitives）可看作为一组事先定义好的，用于通信的例程（规范、程序或函数等）
开发人员通过调用传输层服务原语构建端到端的通信，而隐藏了各种不同的网络层服务原语的区别

传输层上的多路复用和解多路复用

1.多路复用（multiplexing）：指收集不同应用程序进程的数据，将这些数据封装上相应的头部形成段（segments），将这些段递交给网络层的过程。图示
2.解多路复用（demultiplexing）：指把收到的传输层段中的数据提交给相应的应用程序进程的过程

如何解多路复用

主机接收到IP包
每个包都有 source IP address,destination IP address
每个包都装载一个 transport-layer segment
每个segment都有source,destination port number；
传输层实体将用port numbers决定segment该发送给哪个进程（socket）

（头部16位：源端口号+目的端口号）
端口号说明

端口号说明
0～1023：保留端口号，一般给服务器端，由超级用户设置（可更改，但需要认可）
1024～49151：注册端口号，为避免冲突，分配给各组织或公司
49152～65535：私有端口号，任意使用
参考（RFC1700）：
http://www.iana.org/assignments/port-numbers
Windows下C:\WINDOWS\system32\drivers\etc\services
Linux/Unix下：/etc/services

说明：
同一台主机上可以有多个进程同时访问该服务端口（如迅雷等）

面向非连接协议: UDP

用户数据报协议
1.是最简单的一个 Internet transport protocol
2.它提供所谓的“best effort(尽力而为）” 服务, 没有流量控制和差错控制，UDP的segments有可能:
1)丢失
2)损坏
3)不按顺序提交给应用程序
3.它是面向非连接的:
在发送和接收方没有所谓的三次握手
每个UDP segment都将被独立处理 ，前后UDP segment互相没有关系

UDP头部格式

（总结：UDP：不可靠、简单、高效的用户数据报协议)

1.可用于流媒体（streaming multimedia）应用程序
1)允许丢失、时间敏感
2)如Internet电台、视频点播等。请参阅RTP
（实时传输协议）（Real-time Transport Protocol）
2.其他UDP应用（C/S模式）
1)DNS（UDP.cap）、DHCP等
2)SNMP
3)RPC（Remote Procedure Call）
3.建立在UDP上的可靠传输由应用层（应用程序）保证

可靠传输原理

建立连接-三次握手

释放连接（四次握手/挥手？）

传输层释放连接
1.方式
非对称释放：数据可能丢失，TCP不采用
对称释放：将连接看着两个单向连接，采用询问方式。是否一定能正确释放？

采用三次握手释放连接也不能完全保证正确释放，但一般情况下已经足够了

面向连接协议: TCP-传输控制协议

TCP协议特性
1.面向连接
2.即使在不可靠的网络（Internet）上，都能提供可靠的、端到端的字节流通信
3.能够动态的适应各种网络（拓扑）、带宽、延迟、分组尺寸等
3.如果出错，应有足够的健壮性（Robustness）
4.TCP连接是建立在两个Socket（端口）之间的
5.一个TCP连接有且只能有两个端口，或者，两个端口之间只能有一个TCP连接,但一个端口（Socket）上可以有多个连接
7.TCP连接是面向字节流的，即，TCP将从上层得到的数据看作为无结构的字节流

如某进程交给TCP实体4个512B的报文，TCP发送实体可以组成如以下任意大小格式的段递交给IP层，由高层进行结构的区分（有助于提高传输效率）
4个512B的segments、2个1024B的segments、1个1448B和1个600B的segments

(每行4字节，固定的有5行，所以TCP头部至少20个字节）

TCP头部格式
1.端口号：16b，源和目的端口唯一定义一条TCP连接
2.顺序号（sequence numbe）：32b，表明本segment在字节流中的相对位置(开始位置)
3.确认号（Ack······）：32b，希望收到的下一字节序号
实验：在Wireshark中查看顺序号和确认号的变化
4.头部长度：4b，以32b（一行）为单位。TCP头部长度不固定，因此必须设置该字段，实际也指出了数据部分的开始位置

后两次间隔：捎带确认
6个标志位，一个比特

5.保留字段（Reserve，保留的，没有用）：6b，全部置0
1)URG紧急位：一般为0。当置1时，表示数据段中有紧急数据，位置从当前顺序号加上紧急指针（偏移量）开始。发送方传输层实体接到进程紧急指示后，后面收到的数据即为紧急数据，将立即发送已有的数据和紧急数据(不再继续累积数据)，且到达后接收方立刻中断，将紧急数据提前提交上层应用程序。
2)ACK确认号位：置1表示确认号有效；否则忽略确认号字段。用于连接请求时的第一次握手（第一次握手为0）
3)PSH推位：置1，表示数据段是被“推”过来的，即发送方正在等待一些字节以形成段时突然得到应用程序的Push指令，将立即把此时缓存中的数据形成段，马上递交给IP层（一般在连接好后的第一个请求包置PSH为1）（一般为0）
4)RST恢复位：置1，可用于表示数据段非法（如确认号不对），拒绝（Reject）不正确的连接请求确认等。一般而言，如你接收到了一个RST位为1的段，表明你这方出现了问题。（谁收到谁就有问题，拒绝连接）
5)SYN同步位：一般为0。置1时只用在连接建立时的3次握手中的前2次，即用于连接双方互相通知顺序号，初始化一个连接。如：（syn=1,seq=1234,ack=0）的段表示连接请求
（syn=1,seq=6789,ack=1235）的段表示连接请求确认
6)FIN结束位：置1时用于释放连接，发送方告知接收方已无数据要发送或请求方不再请求数据（现在基本都是4次握手释放）

如：

6.窗口尺寸：16b，接收方告诉发送方：
(确认号-1)之前的字节已经正确接收，还可最多发送这么多字节。
如果为0，表示(确认号-1)之前的字节已正确接收，但希望暂停发送；其后再发送一个有相同确认号但窗口尺寸非0的段告诉发送方恢复传输
7.选项：必须32b的整数倍，一般在连接建立时，如：
1)协商MTU(最大传输单元）。注意：传输层的MTU即MSS（Maximum Segment Size）仅为数据部分，多为1460B（为什么？1460=1500-20-20）
2)协商窗口尺寸因子：由于窗口尺寸为16b，因此最大为64KB。对于特定情况（如1000Mbps但线路延迟100ms且双方方有足够的缓存）应根据线路的状态和发送方及接收方的情况动态的改变窗口尺寸使得其可以大于64KB（左移因子，最大可将窗口尺寸从16b扩大为30b），以提高线路利用率
3)协商重发方式：选择性或全部。缺省为选择性重发（SACK）

TCP的一些策略

1.发送方收到接收方窗口大小为0的段时
一般不能再发送数据，除下列情况
1).当有紧急数据时可以发送
2)如在一定时间内，仍未收到恢复发送的段，可以发送1B的段，以此防止当到来的窗口声明包丢失时的死锁。
2.发送方一般不会当应用进程一提交数据就马上组段发送
1)当前多数TCP应用都采用：如应用进程提交了数据，先发送1B的段，其余的数据应等到累积到窗口尺寸的一半或MTU时再发送
2)或遇到紧急数据
3.接收方一般也不会连续发送ACK
一般都延迟500ms以希望能捎带
4.接收方的接收窗口已告知发送方为0后，其后空出了少量的空间如100B，一般不立即发送窗口尺寸修正信息给发送方
1)一般在空余了窗口尺寸的一半或MTU后才报告，尽可能避免小数据段在网络上的传输
5.如窗口尺寸需要大于64KB，则利用option中的Window Scale比例因子协商，可左移14b，达到1GB
最佳接收窗口尺寸
1)太小，瓶颈在主机；太大，网络和主机可能都是瓶颈
2)实际中，一般窗口尺寸将被设置为MTU（如1460B）的偶数倍

TCP的一些漏洞

1.Flag攻击
TCP报文标志位包括URG、ACK、PSH、RST、SYN、FIN。攻击者通过发送非法TCP flag组合的报文，受害主机收到后进行判断识别，消耗其性能，甚至会造成有些操作系统报文处理异常，主机崩溃。
2.Land攻击（环回攻击）
攻击者向受害者发送源IP/端口和目的IP/端口地址都为受害者的IP地址/端口的报文。这将导致受害者向它自己的地址发送SYN-ACK回应报文，结果这个地址又发回ACK消息并创建一个空连接。从而造成资源的消耗。
3.DDOS攻击
利用TCP的3次握手漏洞。Mitnick的攻击
如何防范？（p.168~169）

传输层上的拥塞控制

1.拥塞的产生
当加载到一个网络的负荷超过其处理能力时
2.传输层拥塞控制的重要性
1)尽管网络层也进行拥塞控制，但拥塞的产生的根本原因是由于端系统（资源子网）向通信子网加载了过量的负荷引起，因此仅由网络层（通信子网）的拥塞控制不能解决，必须由端到端传输的传输层来参与解决。
2)最直接的方法是降低数据传输率（谁？如何？）
3.如何判断拥塞发生
如果发生超时，一般有两种可能（除物理线路故障）
1)分组可能由于噪音丢失，很少出现（除无线网络）
2)发生了拥塞，滞留于子网或被子网丢弃

因此，当前的TCP算法都假设超时由拥塞引起

Internet拥塞控制算法
1.发送方需维护（知道）2个窗口
1)接收窗口：表明接收方容量
2)拥塞窗口：表明网络容量
2.选择两者的最小值作为可以最多发送的字节数
注意与MTU区分开
3.建立连接时，发送方可以
1)获知接收窗口尺寸
2)以MTU初始化拥塞窗口，典型的如1460B

随后，发送方发送一个尺寸为MTU的数据段
如果在Timeout前得到确认，将拥塞窗口更改为原来的2倍，接下来发送2个MTU尺寸的数据段（能超过MTU？）
如果在Timeout前获得确认，再将拥塞窗口尺寸更改为原来的两倍，接下来发送4个MTU尺寸的数据段
以此类推，直到达到接收窗口尺寸（肯定不能超过？这也是接收窗口一般为MTU偶数倍的一个原因）或出现了Timeout
如果此时没有出现Timeout，则维持该尺寸的拥塞窗口
如果出现了超时，则从头开始刚才的算法
以上称为慢启动（Slow Start）拥塞控制法

实例

在目前的Internet拥塞控制中还引入了一个参数：临界值（阈值，threshold），一般初始化为32KB

规定
当拥塞窗口增加到临界值后，不以指数而以线性方式增加

如发生Timeout，临界值更改为当前拥塞窗口的一半

进一步阅读*：
TCP的缺点（QUIC）
其它拥塞控制算法：RENO、CUBIC、BBR等