传输层概述

传输层向它上面的应用层提供通信服务,使用它下面的网络层的服务。

传输层的功能

  1. 传输层提供进程和进程之间的逻辑通信。网络层提供主机之间的逻辑通信。
  2. 复用和分用。
  3. 传输层对收到的报文进行差错检测(首部数据部分网络层只检查IP数据报的首部,不检验数据部分是否出错。
  4. 传输层的两种协议(UDPTCP)。

传输层的两个协议

首先,先来首打油诗熟悉一下!!

[start-plane type=”1″]传输层有两个好兄弟,大哥TCP和二弟UDP。大哥靠谱,二弟不靠谱。[/start-plane]

[title-plane title=” TCP协议”]

面向连接 的传输控制协议 TCP

传送数据之前 必须建立连接,数据传送结束后要释放连接。不提供广播或多播服务。由于TCP要提供可靠的面向连接的传输服务,因此不可避免增加了许多开销(确认、流量控制、计时器及连接管理等 )。

特点可靠,面向连接,时延大,适用于大文件

[/title-plane]

[title-plane title=”UDP协议”]

无连接 的用户数据报协议 UDP

传送数据之前 不需要建立连接 ,收到UDP报文后也不需要给出任何确认 。

特点不可靠,无连接,时延小。适用于小文件

[/title-plane]

传输层的寻址和端口

复用与分用

  • 复用:指发送方不同的应用进程都可以使用同一个传输层协议来发送数据。
  • 分用:指接收方的传输层在剥去报文的首部后能把这些数据正确的交付到目的应用进程。

端口号及其作用

端口能够让应用层的各种应用进程将其数据通过端口向下交付给传输层,以及让传输层知道应当将其报文段中的数据向上通过端口交付给应用层相应的进程。

端口是传输层服务访问点(TSAP),它在传输层的作用类似于IP地址在网络层的作用或MAC地址在数据链路层的作用,只不过P地址和MAC地址标识的是主机,而端口标识的是主机中的应用进程。 简单来说,端口是传输层的SAP,标识主机中的应用进程

[start-plane type=”1″]数据链路层的SAP是MAC地址      网络层的SAP是IP地址      传输层的SAP是端口[/start-plane]
[title-plane title=”软件端口“]在协议栈层间的抽象的协议端口是软件端口,它与路由器或交换机上的硬件端口是完全不同的概念。硬件端口是不同硬件设备进行交互的接口,而软件端口是应用层的各种协议进程与传输实体进行层间交互的一种地址。传输层使用的是软件端口。[/title-plane]

端口号只有本地意义,即标识本计算机应用层中的各进程。在因特网中不同计算机的相同端口是没有联系的。

端口号长度为16bit,能表示65536个不同的端口号。

https://www.whbwiki.com/wp-content/uploads/2021/05/图片-2.png
https://www.whbwiki.com/wp-content/uploads/2021/05/图片-3.png

在网络中采用发送方和接收方的套接字组合来识别端点。套接字,实际上是一个通信端点。

套接字唯一标识了网络中的一个主机和它上面的一个进程

[c-alert type=”success”]套接字 Socket = (主机IP地址:端口号)[/c-alert]

传输层和应用层协议的联系

https://z3.ax1x.com/2021/07/17/WQfmff.png

UDP( 用户数据报协议 )

UDP概述

UDP只在IP数据报(网络层)服务之上增加了很少功能,即复用分用差错检测功能

UDP的主要特点

  • UDP是无连接的,减少开销和发送数据之前的时延。
  • UDP使用最大努力交付,即不保证可靠交付
  • UDP是面向报文的,适合一次性传输少量数据的网络应用。
  • UDP无拥塞控制,适合很多实时应用。
  • UDP首部开销小,只有8B(TCP20B)。

UDP的应用:小文件传送协议(TFTP)、DNS、SNMP 和 实时传输协议(RTP)。

[start-plane type=”1″]应用层给UDP多长的报文,UDP就照样发送。即一次发一个完整报文。[/start-plane]
https://www.whbwiki.com/wp-content/uploads/2021/05/图片-4.png

UDP首部格式

UDP数据报包含两部分:UDP首部用户数据。UDP首部有8B,由4个字段组成,每个字段的长度都是2B。各字段意义如下:

  1. 源端口:源端口号。在需要对方回信时选用,不需要时可用全0。
  2. 目的端口:目的端口号。这在终点交付报文时必须使用到。
  3. 长度:UDP数据报的长度(包括首部和数据),其最小值是8(仅有首部)。
  4. 校验和:检测UDP数据报在传输中是否有错。有错就丢弃。该字段是可选的,当源主机不想计算校验和时,则直接令该字段为全0。
https://www.whbwiki.com/wp-content/uploads/2021/05/图片-5.png

当传输层从IP层收到UDP数据报时,就根据首部中的目的端口,把UDP数据报通过相应的端口上交给应用进程。

如果接收方UDP发现收到的报文中的目的端口号不正确(即不存在对应于端口号的应用进程),那么就丢弃该报文,并由ICMP发
送“端口不可达”差错报文给发送方。

UDP校验

  • 伪首部:只有在计算检验和时才出现,不向下传送也不向上递交。
  • 17:封装UDP报文的IP数据报首部协议字段是17。
  • UDP长度:UDP首部8B+数据部分长度(不包括伪首部)。
https://www.whbwiki.com/wp-content/uploads/2021/05/图片-6.png
https://www.whbwiki.com/wp-content/uploads/2021/05/图片-7.png

在发送端

  1. 填上伪首部
  2. 全0填充检验和字段
  3. 全0填充数据部分(UDP数据报要看成许多4B的字串接起来)
  4. 伪首部+首部+数据部分采用 二进制反码求和
  5. 和求反码 填入检验和字段
  6. 去掉伪首部,发送

在接收端

  1. 填上伪首部
  2. 伪首部+首部+数据部分采用二进制反码求和
  3. 结果全为1则无差错,否则丢弃数据报 or 交给应用层附上出差错的警告(不丢弃)。

TCP( 传输控制协议 )

TCP是在不可靠的IP层之上实现的可靠的数据传输协议,它主要解决传输的可靠、有序无丢失和不重复问题。TCP是TCP/IP体系中非常复杂的一个协议。

TCP协议特点

  1. TCP是面向连接(虚连接)的传输层协议。
  2. 每一条TCP连接只能有两个端点,每一条TCP连接只能是点对点的。
  3. TCP提供可靠交付的服务,无差错、不丢失、不重复、按序到达。可靠有序,不丢不重
  4. TCP提供全双工通信发送缓存:准备发送的数据 & 已发送但尚未收到确认的数据;接收缓存:按序到达但尚未被接受应用程序读取的数据 & 不按序到达的数据。
  5. TCP面向字节流。TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流
[start-plane type=”1″]:流入到进程或从进程流出的字节序列。[/start-plane]
https://www.whbwiki.com/wp-content/uploads/2021/05/图片-8.png

TCP报文段格式

序号:在一个TCP连接中传送的字节流中的每一个字节都按顺序编号,本字段表示本报文段所发送数据的第一个字节的序号

确认号期望收到对方下一个报文段的第一个数据字节的序号。若确认号为N,则证明到序号N-1为止的所有数据都己正确收到。

数据偏移(首部长度):TCP报文段的数据起始处距离TCP报文段的起始处有多远,以4B位单位,即1个数值是4B

[start-plane type=”1″]假设数据偏移字段的值为1111,即十进制的15,15*4=60B,首部长度为60B,减去20B固定首部,即填充了40B的选项和填充字段。[/start-plane]

6个控制位

  • 紧急位URG:URG=1时,标明此报文段中有紧急数据,是高优先级的数据,应尽快传送,不用在缓存里排队,配合紧急指针字段使用。
  • 确认位ACK:ACK=1时确认号有效,在连接建立后所有传送的报文段都必须把ACK置为1。
  • 推送位PSH:PSH=1时,接收方尽快交付接收应用进程,不再等到缓存填满再向上交付。
  • 复位RST:RST=1时,表明TCP连接中出现严重差错,必须释放连接,然后再重新建立传输链接。
  • 同步位SYN:SYN=1时,表明是一个连接请求/连接接受报文。
  • 终止位FIN:FIN=1时,表明此报文段发送方数据己发完,要求释放连接。

窗口:指的是发送本报文段的一方的接收窗口,即现在允许对方发送的数据量。

检验和:检验首部+数据,检验时要加上12B伪首部,第四个字段为6。

紧急指针:URG=1时才有意义,指出本报文段中紧急数据的字节数。

选项:最大报文段长度MSS、窗口扩大时间戳、选择确认。

填充:选项字段长度若不是4的倍数,需要在此字段补充成4的倍数。

https://www.whbwiki.com/wp-content/uploads/2021/05/图片-9.png

TCP连接管理

TCP连接传输的三个阶段:

https://www.whbwiki.com/wp-content/uploads/2021/05/图片-10.png

TCP连接的建立采用 客户服务器方式(C/S),主动发起连接建立的应用进程叫做客户,而被动等待连接建立的应用进程叫服务器

TCP的连接建立阶段

假设运行在一台主机(客户)上的一个进程想与另一台主机(服务器)上的一个进程建立一条连接,客户应用进程首先通知客户TCP,他想建立一个与服务器上某个进程之间的连接,客户中的TCP会用以下步骤与服务器中的TCP建立一条TCP连接

https://www.whbwiki.com/wp-content/uploads/2021/05/图片-11.png
https://www.whbwiki.com/wp-content/uploads/2021/05/图片-12-1024x643.png
[start-plane type=”1″]回顾:SYN :同步位; FIN: 终止位; ACK :确认位;seq:序号;ack:确认号。详细内容请看上文。[/start-plane]

ROUND 1:客户端发送连接请求报文段,无应用层数据。

SYN=1,seq=x(随机)

ROUND 2:服务器端为该TCP连接分配缓存和变量,并向客户端返回确认报文段,允许连接,无应用层数据

SYN=1,ACK=1,seq=y(随机),ack=x+1

ROUND 3:客户端为该TCP连接分配缓存和变量,并向服务器端返回确认的确认,可以携带数据

SYN=0,ACK=1,seq=x+1,ack=y+1

[title-plane title=”SYN洪泛攻击”]

SYN洪泛攻击 发生在OS第四层,这种方式利用TcP协议的特性,就是三次握手。攻击者发送TCP SYN,SYN是TCP三次握手中的第一个数据包,而当服务器返回ACK后,该攻击者就不对其进行再确认,那这个TCP连接就处于挂起状态,也就是所谓的半连接状态,服务器收不到再确认的话,还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接,由于每一个都没法完成三次握手,所以在服务器上,这些TCP连接会因为挂起状态而消耗CPU和内存,最后服务器可能死机,就无法为正常用户提供服务了。

解决办法:设置 SYN cookie

[/title-plane]

TCP的连接释放阶段

参与一条TCP连接的两个进程中的任何一个都能终止该连接,连接结束后,主机中的“资源”(缓存和变量)将被释放。

https://www.whbwiki.com/wp-content/uploads/2021/05/图片-13.png
https://www.whbwiki.com/wp-content/uploads/2021/05/图片-14.png

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

Wireshark分析

三次握手报文分析

https://z3.ax1x.com/2021/07/18/W3lt0A.png https://z3.ax1x.com/2021/07/18/W3lHB9.png https://z3.ax1x.com/2021/07/18/W31Sje.png

[title-plane title=”三次握手分析”]

客户机:172.16.16.128                    服务器:212.58.226.142

第一次握手:序号seq=3691127924,确认号ack=0,SYN=1

[start-plane type=”1″]序号是系统随机分配的一个数据,范围是0~2^32;由于第一次和服务器通信,不知道服务器的情况,ack确认号默认是0,并且此时 确认位ACK=0,故这个0其实也是无效的;由于是请求报文,故 同步位SYN位=1[/start-plane]

第二次握手:序号seq=233779340,确认号ack=3691127925,SYN=1,ACK=1

[start-plane type=”1″]此时服务器序号是仍是系统随机分配的一个数据,范围是0~2^32;此时服务器和主机已建立一次通信,确认号ack是上次主机请求报文序号+1,且 确认位ACK=1;由于是请求报文,故 同步位SYN位=1[/start-plane]

第三次握手:序号seq=3691127925,确认号ack=233779341,ACK=1

[start-plane type=”1″] 此时客户机序号为上次服务器报文的ack确认号,而ack确认号是上次服务器报文序号+1[/start-plane]

至此,客户机和服务器三次握手完成,可以开始数据传送了!!!

[/title-plane]

四次挥手报文分析

https://z3.ax1x.com/2021/07/18/W38fht.png https://z3.ax1x.com/2021/07/18/W38b7j.png

[title-plane title=”四次挥手分析”]

客户机:172.16.16.128                          服务器:67.228.110.120

[start-plane type=”1″]本例中服务器为主动断开连接方,客户机为被动断开方。客户机和服务器均可当作主动方或被动方。[/start-plane]

第一次握手:服务器请求断开连接报文,终止位FIN=1,确认位ACK=1

第二次握手:客户机回应确认报文,确认位ACK=1,但是客户机可能还有未传输完成的数据给服务器,故服务器此时处于 半关闭状态

第三次握手:当客户机的所有数据都传输给服务器后,再次发送一个断开连接确认报文,终止位FIN=1,确认位ACK=1

第四次握手:服务器收到客户机发送报文后,最后在发送一个确认断开连接的报文,确认位ACK=1

至此,客户机和服务器成功完全断开连接!!!

[/title-plane]

TCP可靠传输

[start-plane type=”1″]TCP发送的报文段是交给IP层(网络层)传送的。但是IP层(网络层)只能提供尽最大努力服务的不可靠传输。所以TCP必须采取适当的措施解决不可靠的问题。[/start-plane]

传输层 使用TCP实现可靠传输网络层 提供尽最大努力交付,不可靠传输

[c-alert type=”success”]可靠 :保证接收方进程从缓存区读岀的字节流与发送方发岀的字节流是完全一样的 。[/c-alert]

TCP实现可靠传输的机制

(1)校验: 与UDP校验一样,增加伪首部。

(2)序号: TCP连接传送的数据流中每个字节都编上一个序号。序号字段的值是指 本报文段所发送数据的第一个字节的序号

例如图中:蓝色报文段的序号是1橙色报文段的序号是4绿色报文段的序号是7红色报文段的序号是9

https://www.whbwiki.com/wp-content/uploads/2021/05/图片-15.png

(3)确认:TCP首部的确认号期望收到对方的下一个报文段的数据的第一个字节的序号

例:在图中,如果接收方已收到第一个蓝色报文段123,此时接收方希望收到的下一个报文段的数据是从第4个字节开始的,那么接收方发送给发送方的报文中的确认号字段应为4。发送方缓存区会继续存储那些已发送但未收到确认的报文段,以便在需要时重传。发送方再收到接收方的确认报文段后,清除缓存区中的蓝色报文段123 ,准备发送黄色报文段456。(注:左边是发送方,右边是接收方)。

https://www.whbwiki.com/wp-content/uploads/2021/05/图片-16.png

TCP默认使用累计确认,即TCP只确认数据流中至第一个丢失字节为止的字节

例:在图中,接收方收到了发送方发送的包含字节1~3及字节7~8的报文段。由于某种原因,接收方还未收到字节4~6的报文段,此时接收方仍在等待字节4(和其后面的字节),因此接收方给发送方的下一个报文段首部确认号字段仍为4。 (注:左边是发送方,右边是接收方)。

https://www.whbwiki.com/wp-content/uploads/2021/05/图片-17.png

(4)重传

超时重传 :确认重传不分家,TCP的发送方在规定的时间内(重传时间)没有收到确认就要重传已发送的报文段。

TCP采用自适应算法,动态改变重传时间RTTs(加权平均往返时间)。

冗余ACK(冗余确认)

  1. 每当比期望序号大的失序报文段到达时,发送一个冗余ACK,指明下一个期待字节的序号
  2. 发送方已发送1,2,3,4,5报文段
  3. 接收方收到1,返回给1的确认(确认号为2的第一个字节)
  4. 接收方收到3,仍返回给1的确认(确认号为2的第一个字节)
  5. 接收方收到4,仍返回给1的确认(确认号为2的第一个字节)
  6. 接收方收到5,仍返回给1的确认(确认号为2的第一个字节)
  7. 发送方收到3个对于报文段1的冗余ACK ===> 认为2报文段丢失,重传2号报文段 快速重传

https://z3.ax1x.com/2021/07/18/W8FytJ.png[title-plane title=”超时重传分析”]10.3.30.1发送给10.3.71.7一个数据包后,一直在等带10.3.71.7回复确认包,隔一段RTT时间后就发送一个超时重传包,图中一共超时重传了5次。[/title-plane]

TCP流量控制

流量控制:让发送方慢点,要让接收方来得及接收

TCP利用 滑动窗口机制 实现流量控制。

在通信过程中,接收方根据自己接收缓存的大小,动态地调整发送方的发送窗口大小。即接收窗口rwnd(接收方设置确认报文段的窗口字段来将rwnd通知给发送方),发送方的发送窗口取接收窗口rwnd和拥塞窗口cwnd的最小值。 发送窗口大小可以动态变化

https://www.whbwiki.com/wp-content/uploads/2021/05/图片-18.png

A向B发送数据,连接建立时,B告诉A:“我的rwnd=400(字节)”,设每一个报文段100B,报文段序号初始值为1。

https://www.whbwiki.com/wp-content/uploads/2021/05/图片-20.png

当rwnd=0时,A就无法发送数据了,就一直在等待B发送更改rwnd的报文段通知。若B发送的更改rwnd的报文段通知在发送过程中不幸丢失了,那么B就一直在等待A发送数据,而A在等待B发送更改rwnd的报文段通知,这时A和B就处于一种僵持状态。为了解决这种僵持状态,TCP有如下解决方案。

TCP为每一个连接设有一个持续计时器,只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器。若持续计时器设置的时间到期,就发送一个零窗口探测报文段接收方收到探测报文段时给出现在的窗口值。若窗口仍然是0,那么发送方就重新设置持续计时器。

TCP拥塞控制

拥塞控制:防止过多的数据注入到网络中,保证网络中的路由器或链路不过载。全局性

出现拥塞的条件:对资源需求的总和>可用资源

网络中有许多资源同时呈现供应不足 ==> 网络性能变坏 ==> 网络吞吐量将随输入负荷增大而下降

拥塞控制与流量控制的区别拥塞控制是让网络能够承受现有的网络负荷,是一个全局性的过程,涉及所有的主机、所有的路由器,以及与降低网络传输性能有关的所有因素。相反,流量控制往往是指点对点的通信量的控制,是个端到端的问题(接收端控制发送端),它所要做的是抑制发送端发送数据的速率,以便使接收端来得及接收。当然,拥塞控制和流量控制也有相似的地方,即它们都通过控制发送方发送数据的速率来达到控制效果。

https://www.whbwiki.com/wp-content/uploads/2021/05/图片-21.png

拥塞控制四种算法:慢开始、拥塞避免;快重传、快恢复。

[start-plane type=”1″]假定:

1. 数据单方向传送,而另一个方向只传送确认

2. 接收方总是有足够大的缓存空间,因而发送窗口大小取决于拥塞程度

发送窗口=Mn接收窗口rwnd,拥塞窗口cwnd}

接收窗口rwnd:接收方根据接收缓存设置的值,并告知给发送方,反映接收方容量。

拥塞窗口cwnd:发送方根据自己估算的网络拥塞程度而设置的窗口值,反映网络当前容量。

[/start-plane]

慢开始和拥塞避免

慢开始的“慢”并不是指拥塞窗口cwd的增长速率慢,而是指在TCP开始发送报文段时先设置cwnd=1,使得发送方在开始时只发送一个报文段(目的是试探一下网络的拥塞情况),然后再逐渐增大cwnd,这对防止网络出现拥塞是一个非常有力的措施。使用慢开始算法后,每经过个传输轮次(即往返时延RTT),cwnd就会加倍,即cwnd的大小指数式增长。这样,慢开始直把cwnd增大到一个规定的慢开始门限 ssthresh(阈值),然后改用拥塞避免算法。

在慢开始和拥塞避免算法中使用了“乘法减小”和“加法增大”方法。“乘法减小”是指不论是在慢开始阶段还是在拥塞避免阶段,只要岀现超时(即很可能岀现了网络拥塞)就把慢开始门限值 ssthresh设置为当前拥塞窗口的一半(并执行慢开始算法)。当网络频繁岀现拥塞时ssthresh值就下降得很快,以大大减少注入网络的分组数。而“加法增大”是指执行拥塞避免算法后,在收到对所有报文段的确认后(即经过一个RTT),就把拥塞窗口cwnd增加一个MSS大小,使拥塞窗口缓慢增大,以防止网络过早出现拥塞。

拥塞避免并不能完全避免拥塞。利用以上措施要完全避免网络拥塞是不可能的。拥塞避免是指在拥塞避免阶段把拥塞窗口控制为按线性规律增长,使网络比较不容易出现拥塞。

https://www.whbwiki.com/wp-content/uploads/2021/05/图片-23.png

快重传和快恢复: 是对慢开始和拥塞避免算法的改进。

快重传 并非取消重传计时器,而是在某些情况下可更早地重传丢失的报文段。当发送方连续收到三个重复的ACK报文时,直接重传对方尚未收到的报文段,而不必等待那个报文段设置的重传计时器超时。

快恢复算法的原理如下:当发送方连续收到三个冗余ACK(即重复确认)时,执行“乘法减小”算法,把慢开始门限ssthresh设置为此时发送方cwnd的一半。这是为了预防网络发生拥塞。但发送方现在认为网络很可能没有发生(严重)拥塞,否则就不会有几个报文段连续到达接收方,也不会连续收到重复确认。因此与慢开始不同之处是它把cwnd值设置为慢开始门限ssthresh改变后的数值,然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性増大。

由于跳过了拥塞窗口cwnd从1起始的慢开始过程,所以被称为快恢复。

https://www.whbwiki.com/wp-content/uploads/2021/05/图片-24.png

流量控制中,发送方发送数据的量由接收方决定,而在拥塞控制中,则由发送方自己通过检测网络状况来决定。实际上,慢开始、拥塞避免、快重传和快恢复几种算法是同时应用在拥塞控制机制中。四种算法使用的总结在TCP连接建立和网络出现超时时,采用慢开始和拥塞避免算法;当发送方接收到冗余ACK时,采用快重传和快恢复算法。