计算机网络 传输层
传输层概述
传输层向它上面的应用层提供通信服务,使用它下面的网络层的服务。
传输层的功能
-
传输层 提供进程和进程 之间的端到端 逻辑通信。网络层 提供主机之间 的逻辑通信。
-
复用和分用。
-
传输层 对收到的报文进行差错检测 (首部 和数据部分 )。网络层 只检查IP数据报的首部 ,不检验数据部分 是否出错。
-
传输层的两种协议(UDP 和TCP )。
传输层的两个协议
-
面向连接 的传输控制协议 TCP :
-
传送数据之前 必须建立连接 ,数据传送结束后要释放连接。不提供广播或多播服务。由于TCP要提供可靠的面向连接的传输服务,因此不可避免增加了许多开销(确认、流量控制、计时器及连接管理等 )。
-
特点 :可靠,面向连接,时延大,适用于大文件 。
-
无连接 的用户数据报协议 UDP :
-
传送数据之前 不需要建立连接 ,收到UDP报文后也不需要给出任何确认 。
-
特点 : 不可靠,无连接,时延小。适用于小文件 。
传输层的寻址和端口
复用与分用 :
-
复用 :指发送方不同的应用进程都可以使用同一个传输层协议来发送数据。
-
分用 :指接收方的传输层在剥去报文的首部后能把这些数据正确的交付到目的应用进程。
端口号及其作用 :
端口能够让应用层的各种应用进程将其数据通过端口向下交付给传输层,以及让传输层知道应当将其报文段中的数据向上通过端口交付给应用层相应的进程。
端口是传输层服务访问点(TSAP),它在传输层的作用类似于IP地址在网络层的作用或MAC地址在数据链路层的作用,只不过IP地址和MAC地址标识的是主机 ,而端口标识的是主机中的应用进程 。 简单来说,端口是传输层的SAP,标识主机中的应用进程 。
数据链路层 的SAP是MAC地址 网络层 的SAP是IP地址 传输层 的SAP是端口
在协议栈层间的抽象的协议端口是软件端口 ,它与路由器或交换机上的硬件端口 是完全不同的概念。硬件端口是不同硬件设备进行交互的接口,而软件端口是应用层的各种协议进程与传输实体进行层间交互的一种地址。传输层使用的是软件端口 。
端口号只有本地意义 ,即标识本计算机应用层中的各进程。在因特网中不同计算机的相同端口是没有联系的。
端口号长度为16bit ,能表示65536 个不同的端口号。
在网络中采用发送方和接收方的套接字组合来识别端点。套接字,实际上是一个通信端点。
套接字唯一标识了网络中的一个主机和它上面的一个进程 。套接字 Socket = (主机IP地址:端口号)
传输层和应用层协议的联系
UDP( 用户数据报协议 )
UDP概述
UDP只在IP数据报(网络层)服务之上增加了很少功能,即复用分用 和差错检测 功能
UDP的主要特点 :
-
UDP只在IP数据包服务之上增加了很少的一点功能。
-
UDP是无连接 的,即发送数据包之前不需要建立会话连接,减少了开销和发送数据之前的时延。
-
UDP使用最大努力交付,即不保证可靠交付 ,也不使用拥塞控制。
-
UDP是面向报文 的,适合一次性传输少量数据的网络应用,例如多媒体通信等。
-
UDP无拥塞控制,适合很多实时应用,例如视频会议等。
-
UDP首部开销小 ,只有8B (TCP20B )。
UDP的应用 :小文件传送协议(TFTP)、DNS、SNMP 和 实时传输协议(RTP)。
应用层给UDP多长的报文,UDP就照样发送。即一次发一个完整报文 。
UDP首部格式
UDP数据报包含两部分:UDP首部 和用户数据 。UDP首部有8B,由4个字段组成,每个字段的长度都是2B。各字段意义如下:
-
源端口 :占16位 ,标识源主机 上使用的UDP端口。这个字段是可选的,仅当需要目标主机返回一个应答时才有意义。如果不使用它,则此字段值为0。
-
目的端口 :占16位,用来标识目的主机 上使用的UDP端口。如果目的主机应用层没有对应端口 的应用进程,则该UDP数据报会被丢弃 。
-
长度 :占16位 ,标识此UDP数据报的长度(包括首部和数据 ),其最小值是8(仅有首部 )。这个字段是可选的,仅当需要目标主机返回一个应答时才有意义。如果不使用它,则此字段值为0。
-
校验和 :检测UDP数据报在传输中是否有错。有错就丢弃。该字段是可选的,当源主机不想计算校验和时,则直接令该字段为全0。
当传输层从IP层收到UDP数据报时,就根据首部中的目的端口,把UDP数据报通过相应的端口上交给应用进程。如果接收方UDP发现收到的报文中的目的端口号不正确(即不存在对应于端口号的应用进程),那么就丢弃该报文,并由ICMP发送“端口不可达”差错报文给发送方。
UDP校验
-
伪首部 :只有在计算检验和时才出现,不向下传送也不向上递交。
-
17 :封装UDP报文的IP数据报首部协议字段是17。
-
UDP长度 :UDP首部8B+数据部分长度(不包括伪首部)。
在发送端 :
-
填上伪首部
-
全0填充检验和字段
-
全0填充数据部分(UDP数据报要看成许多4B的字串接起来)
-
伪首部+首部+数据部分采用 二进制反码求和
-
把 和求反码 填入检验和字段
-
去掉伪首部,发送
在接收端 :
-
填上伪首部
-
伪首部+首部+数据部分采用二进制反码求和
-
结果全为1 则无差错,否则丢弃数据报 or 交给应用层附上出差错的警告(不丢弃)。
TCP( 传输控制协议 )
-
TCP,是一种面向连接、可靠的、基于字节流 的传输层通信协议。TCP是TCP/IP体系结构中最主要的传输层协协议。
-
TCP是在不可靠的IP层之上实现的可靠的数据传输协议 ,它主要解决传输的可靠、有序无丢失和不重复问题。TCP是TCP/IP体系中非常复杂的一个协议。
TCP协议特点
-
TCP是面向连接 (虚连接)的传输层协议。
-
TCP仅支持单播 传输。每一条TCP连接只能有两个端点,每一条TCP连接只能是点对点的。
-
TCP提供可靠交付 的服务,无差错、不丢失、不重复、按序到达。可靠有序,不丢不重 。
-
TCP提供全双工通信 。发送缓存 :准备发送的数据 & 已发送但尚未收到确认的数据;接收缓存 :按序到达但尚未被接受应用程序读取的数据 & 不按序到达的数据。
-
TCP连接是基于字节流 。TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流 。
-
每次发送的TCP数据段大小和数据段数都是可变 的。
-
传输单位为数据段
流 :流入到进程或从进程流出的字节序列。
TCP协议主要特性
-
TCP协议连接管理
-
TCP协议可靠传输
-
TCP协议流量控制
-
TCP协议拥塞控制
TCP报文段格式
-
源端口和目的端口 :各占16位 ,TCP协议通过使用"端口”来标识源端口和目标端口的应用进程。在收到服务请求时,操作系统动态地为客户端的应用程序分配端口号;在服务器端,每种服务在Well-Know port为用户提供服务
-
序号 :占32位 ,在一个TCP连接中,传送的数据字节流中的每一个数据字节都要按顺序进行编号 。在"数据段头"中标识的只是毎个数据段的第—个数据字节的编号 。
- 例如:一个数据段的"序号”字段值是201,而该数字段中共有100字节,说明本数据段的最后一个字节的编号是300。因此,下一个数据段的"序号”字段值应该是301,而不是202
- 确认号 :占32位 ,指期望接收 到对方下一个数据段中“数据”部分的第一个字节序号 。注意:"确认号"不是代表已经正确接收到的最后一个字节的序号。若确认号=N,则表明到序号N-1为止的所有数据都已正确收到 。
- 假设B正确收到了A发送过来的一个报文段,其序号字段值是501,而数据长度是200字节(序号501~700),这表明B正确收到了A发送的到序号700为止的数据。因此B期望收到A的下一个数据序号是701
- 数据偏移 (首部长度 ):占4位 ,TCP报文段的数据起始处 距离TCP报文段的起始处 有多远,以4B位单位,即1个数值是4B 。
- 假设数据偏移字段的值为1111 ,即十进制的15 ,15*4=60B,首部长度为60B ,减去20B固定首部,即填充了40B的选项和填充字段 。
-
保留( Reserved) :占6位 ,保留为今后使用,目前应置为0
-
6个控制位 :
-
紧急位URG :占1位 ,URG=1时,标明此报文段中有紧急数据,是高优先级的数据,应尽快传送,不用在缓存里排队,配合紧急指针字段使用。
-
确认位ACK :占1位 ,ACK=1时确认号有效,在连接建立后所有传送的报文段都必须把ACK置为1。
-
推送位PSH :占1位 ,PSH=1时,接收方尽快交付接收应用进程,不再等到缓存填满再向上交付。
-
复位RST :占1位 ,RST=1时,表明TCP连接中出现严重差错,必须释放连接,然后再重新建立传输链接。
-
同步位SYN :占1位 ,SYN=1时,表明是一个连接请求/连接接受报文。
-
终止位FIN :占1位 ,FIN=1时,表明此报文段发送方数据己发完,要求释放连接。
-
窗口 :占16位 ,指的是发送本报文段的一方的接收窗口,即现在允许对方发送的数据量。
-
检验和 :占16位 ,检验首部+数据,检验时要加上12B伪首部,第四个字段为6。
-
紧急指针 :占16位 ,URG=1时才有意义,指出本报文段中紧急数据的字节数。
-
选项 :最大报文段长度MSS、窗口扩大时间戳、选择确认。
-
填充 :选项字段长度若不是4的倍数,需要在此字段补充成4的倍数。
TCP连接管理
TCP连接传输的三个阶段:
TCP连接的建立采用 客户服务器方式 (C/S),主动发起连接建立的应用进程叫做客户 ,而被动等待连接建立的应用进程叫服务器 。
三次握手过程
TCP的连接建立阶段 :
假设运行在一台主机(客户)上的一个进程想与另一台主机(服务器)上的一个进程建立一条连接,客户应用进程首先通知客户TCP,他想建立一个与服务器上某个进程之间的连接,客户中的TCP会用以下步骤与服务器中的TCP建立一条TCP连接
回顾:SYN :同步位; FIN : 终止位; ACK :确认位;seq :序号;ack :确认号。详细内容请看上文。
ROUND 1 :客户端发送连接请求报文段,无应用层数据。
同步位SYN=1 ,序号seq=x(随机) ,表明传输数据时的第一个数据子节序号为x+1。
ROUND 2 :服务器端收到连接请求报文段后,为该TCP连接分配缓存和变量 ,并向客户端返回确认报文段,允许连接,无应用层数据。确认报文段中,同步位SYN=1,确认位ACK=1,序号seq=y(随机),确认号ack=x+1 。
ROUND 3 :客户端收到此确认报文段后,为该TCP连接分配缓存和变量 ,并向服务器端返回确认,可以携带数据 。ACK=1,seq=x+1,ack=y+1 。客户端的TCP通知上层应用进程,连接已经建立。
ROUND 4 :服务器的TCP收到客户端的确认后,也通知其上层应用进程:TCP连接已经建立之后就可以传送数据了 。
SYN洪泛攻击 发生在OS第四层,这种方式利用TcP协议的特性,就是三次握手。攻击者发送TCP SYN,SYN是TCP三次握手中的第一个数据包,而当服务器返回ACK后,该攻击者就不对其进行再确认,那这个TCP连接就处于挂起状态,也就是所谓的半连接状态,服务器收不到再确认的话,还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接,由于每一个都没法完成三次握手,所以在服务器上,这些TCP连接会因为挂起状态而消耗CPU和内存,最后服务器可能死机,就无法为正常用户提供服务了。解决办法 :设置 SYN cookie
四次挥手过程
TCP的连接释放阶段 :
参与一条TCP连接的两个进程中的任何一个都能终止该连接,连接结束后,主机中的“资源”(缓存和变量)将被释放。
ROUND 1 :客户端发送连接释放报文段,停止发送数据,主动关闭TCP连接。
FIN=1,seq=u
ROUND 2 :服务器端回送一个确认报文段,客户到服务器这个方向的连接就释放了一一半关闭状态 。
ACK=1,seq=v,ack=u+1
ROUND 3 :服务器端发完数据。就发出连接释放报文段,主动关闭TCP连接。
FIN=1,ACK=1, seq=w,ack=u+1
ROUND 4 :客户端回送一个确认报文段,再等到时间等待计时器设置的2MSL(最长报文段寿命)后,连接彻底关闭 。
ACK=1, seq=u+1,ack=w+1
TCP数据包分析
三次握手分析
- 第一次握手 :主机172.16.16.128 向 服务器 212.58.226.142 发送连接请求报文,同步位SYN=1 ,主机分配随机端口2826连接服务器端口80,序号 seq = 3691127924 ,由于第一次请求确认号 ack = 0 。当前窗口为8192。
- 第二次握手 :服务器 212.58.226.142 向主机 172.16.16.128 向 发送确认报文,同步位SYN=1 ,确认位ACK = 1 ,序号 seq = 233779340 ,确认号 ack = 3691127925 (上次报文序号seq+1)。当前窗口为5840
- 第三次握手 :主机 172.16.16.128 向 服务器 212.58.226.142 发送确认报文,确认位ACK = 1 ,序号 seq = 3691127925 (上次报文序号seq+1),确认号 ack = 233779341 (上次报文序号seq+1)。当前窗口为4218。此时主机通知上层应用进程连接已经建立,可以开始数据传输了 。
四次挥手分析
第一次挥手 :数据传输结束后,服务器 67.228.110.120 向 客户机 172.16.16.128 发起 连接释放报文,并停止再发送数据,主动关闭TCP连接,此时, 终止位FIN=1,确认位ACK=1 ,序号seq = 822643295,确认号ack = 2079380537,当前窗口为71。
第二次挥手 :客户机 172.16.16.128 向服务器回应发起确认报文,此时, 确认位ACK=1 ,序号seq = 2079380537,确认号ack =822643296,当前窗口为4218。但是客户机可能还有未传输完成的数据给服务器,故服务器此时处于 半关闭状态 。
第三次挥手 :客户机 172.16.16.128 的数据已经完全发送完成,再次发起一个断开连接确认报文,此时, 确认位ACK=1 ,终止位FIN=1 ,序号seq = 2079380537,确认号ack =822643296,当前窗口为4218。
第四次挥手 :服务器 67.228.110.120 向 客户机回应发起确认报文,此时,确认位ACK=1 ,序号seq = 822643296,确认号ack = 2079380538,当前窗口为71。至此,客户机和服务器成功完全断开连接!!!
TCP可靠传输
TCP发送的报文段是交给IP层(网络层)传送的。但是IP层(网络层)只能提供尽最大努力服务的不可靠传输。所以TCP必须采取适当的措施解决不可靠的问题。
传输层 使用TCP实现可靠传输 。网络层 提供尽最大努力交付,不可靠传输 。
可靠 :保证接收方进程从缓存区读岀的字节流与发送方发岀的字节流是完全一样的 。
可靠传输原理
一个理想的传输条件
-
传输通道不产生差错
-
不管发送方以多快的速度发送数据,接收方总是来得及处理收到的数据
但是实际的网络都不具备上述两个条件。只能采取一些措施:
-
当出现差错时让发送方重传出现差错的数据
-
在接收方来不及处理收到的数据时,及时告诉发送方降低发送数据的速度
停止等待协议
第一种情况 :无差错情况
第二种情况 :超时重传
-
A发送完一个分组之后,必须暂时保存已发送的分组的副本
-
分组和确认分组必须编号
-
超时计时器设置的重传时间(RTO)应该比数据在分组传输的平均往返时间更长
第三种情况 :确认包丢失
-
丟弃这个重复的分组M1
-
向A发送确认
第四种情况 :确认包迟到
自动重传ARQ
-
使用上述的确认和重传机制,就可以在不可靠的传输网络上实现可靠的传输
-
这种可靠的传输协议常称为自动重传ARQ( Automatic Repeat reQuest)
-
ARQ表明重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组
缺点 :信道利用率太低
流水线传输
采用流水线传输 改进信道利用率,发送方可以连续发送多个分组,不必每发完一个分组就停顿下来等待对方确认,这样
可以使信道上不间断的在传送数据
滑动窗口
连续ARQ协议和滑动窗口协议 。采用累计确认
TCP流量控制
流量控制 :让发送方慢点,要让接收方来得及接收
TCP利用 滑动窗口机制 实现流量控制。
在通信过程中,接收方根据自己接收缓存的大小,动态地调整发送方的发送窗口大小。即接收窗口rwnd(接收方设置确认报文段的窗口字段来将rwnd通知给发送方),发送方的发送窗口取接收窗口rwnd和拥塞窗口cwnd的最小值。 发送窗口大小可以动态变化 。
A向B发送数据,连接建立时,B告诉A:“我的rwnd=400(字节)”,设每一个报文段100B,报文段序号初始值为1。
当rwnd=0时,A就无法发送数据了,就一直在等待B发送更改rwnd的报文段通知。若B发送的更改rwnd的报文段通知在发送过程中不幸丢失了,那么B就一直在等待A发送数据,而A在等待B发送更改rwnd的报文段通知,这时A和B就处于一种僵持状态 。为了解决这种僵持状态,TCP有如下解决方案。
TCP为每一个连接设有一个持续计时器,只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器。若持续计时器设置的时间到期,就发送一个零窗口探测报文段接收方收到探测报文段时给出现在的窗口值。若窗口仍然是0,那么发送方就重新设置持续计时器。
TCP拥塞控制
拥塞控制概述
拥塞控制 :防止过多的数据注入到网络中,保证网络中的路由器或链路不过载。全局性
出现拥塞的条件 :对资源需求的总和>可用资源
网络中有许多资源同时呈现供应不足 ==> 网络性能变坏 ==> 网络吞吐量将随输入负荷增大而下降
拥塞控制与流量控制的区别 :拥塞控制 是让网络能够承受现有的网络负荷,是一个全局性的过程 ,涉及所有的主机、所有的路由器,以及与降低网络传输性能有关的所有因素。相反,流量控制 往往是指点对点的通信量的控制 ,是个端到端的问题 (接收端控制发送端),它所要做的是抑制发送端发送数据的速率,以便使接收端来得及接收。当然,拥塞控制和流量控制也有相似的地方,即它们都通过控制发送方发送数据的速率来达到控制效果。
拥塞控制四种算法 :慢开始、拥塞避免;快重传、快恢复。
假定:
-
数据单方向传送,而另一个方向只传送确认
-
接收方总是有足够大的缓存空间,因而发送窗口大小取决于拥塞程度
发送窗口 =Mn接收窗口rwnd,拥塞窗口cwnd}
接收窗口 rwnd:接收方根据接收缓存设置的值,并告知给发送方,反映接收方容量。
拥塞窗口 cwnd:发送方根据自己估算的网络拥塞程度而设置的窗口值,反映网络当前容量。
慢开始和拥塞避免
慢开始的“慢”并不是指拥塞窗口cwd的增长速率慢,而是指在TCP开始发送报文段时先设置cwnd=1,使得发送方在开始时只发送一个报文段(目的是试探一下网络的拥塞情况),然后再逐渐增大cwnd,这对防止网络出现拥塞是一个非常有力的措施。使用慢开始算法后,每经过个传输轮次(即往返时延RTT),cwnd就会加倍 ,即cwnd的大小指数式增长。这样,慢开始直把cwnd增大到一个规定的慢开始门限 ssthresh(阈值) ,然后改用拥塞避免算法。
在慢开始和拥塞避免算法中使用了“乘法减小 ”和“加法增大 ”方法。“乘法减小”是指不论是在慢开始阶段还是在拥塞避免阶段,只要岀现超时(即很可能岀现了网络拥塞) ,就把慢开始门限值 ssthresh设置为当前拥塞窗口的一半(并执行慢开始算法) 。当网络频繁岀现拥塞时ssthresh值就下降得很快,以大大减少注入网络的分组数。而“加法增大”是指执行拥塞避免算法后,在收到对所有报文段的确认后(即经过一个RTT),就把拥塞窗口cwnd增加一个MSS大小,使拥塞窗口缓慢增大,以防止网络过早出现拥塞。
拥塞避免并不能完全避免拥塞 。利用以上措施要完全避免网络拥塞是不可能的。拥塞避免是指在拥塞避免阶段把拥塞窗口控制为按线性规律增长,使网络比较不容易出现拥塞。
快重传和快恢复
- 是对慢开始和拥塞避免算法的改进。
快重传 并非取消重传计时器,而是在某些情况下可更早地重传丢失的报文段。当发送方连续收到三个重复的ACK报文时,直接重传对方尚未收到的报文段,而不必等待那个报文段设置的重传计时器超时。
快恢复 算法的原理如下:当发送方连续收到三个冗余ACK(即重复确认)时,执行“乘法减小”算法,把慢开始门限ssthresh设置为此时发送方cwnd的一半 。这是为了预防网络发生拥塞。但发送方现在认为网络很可能没有发生(严重)拥塞,否则就不会有几个报文段连续到达接收方,也不会连续收到重复确认。因此与慢开始不同之处是它把cwnd值设置为慢开始门限ssthresh改变后的数值 ,然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性増大。
由于跳过了拥塞窗口cwnd从1起始的慢开始过程,所以被称为快恢复。
在流量控制 中,发送方发送数据的量由接收方 决定,而在拥塞控制 中,则由发送方自己 通过检测网络状况来决定。实际上,慢开始、拥塞避免、快重传和快恢复几种算法是同时应用在拥塞控制机制中。四种算法使用的总结 :在TCP连接建立和网络出现超时时,采用慢开始和拥塞避免算法;当发送方接收到冗余ACK时,采用快重传和快恢复算法。
TCP & UDP异同点
相同点
-
TCP和UDP都是传输层 协议,功能都属于保证网络层数据的传输
-
双方通信无论是使用TCP还是UDP,都是要开放端口 的