目录
5.0 章节层次
5.1.1 传输层概述
传输层
- 传输层是只有主机才有的层次
传输层的功能
- 传输层提供进程和进程之间的逻辑通信
- 复用和分用
- 传输层对收到的报文进行差错检测
- 传输层的两种协议
传输的两个协议
- 记忆打油诗:传 输层有两个好兄弟,大哥TCP和二弟UDP,大哥靠谱,二哥不靠谱
面向连接的传输控制协议TCP:专送数据之前必须建立连接,数据传送结束后要释放连接。不提供广播或多播服务。由于TCP要提供可靠的面向连接的传输服务,因此不可避免增加了许多开销:确认、流量控制、计时器及连接管理等。
可靠,面向连接,时延大,适用于大文件。- 特点:可靠、面向连接、时延大,适用于大文件
- 无连接的用户数据报协议UDP:传送数据之前不需要建立连接,收到UDP报文后也不需要给出任何确认。
- 特点:不可靠,无连接、时延小、适用于小文件
传输层的寻址与端口
- 复用:应用层所有的应用进程都可以通过传输层再传输到网络层
- 分用:传输层从网络层收到数据后交付指明的应用程序
逻辑端口/软件端口:端口是传输层的SAP,标识主机中的应用进程(交换机等设备的端口是硬件端口,不一样的)- 端口号只有本地意义,在因特网中不同计算机的相同端口是没有联系的
端口号的长度为16bit,能表示2的16次方,即65536个端口号
- 端口号的划分(按范围划)
- 一些熟知端口号:
套接字:在网络中采用发送方和接收方的套接字组合来识别端点,套接字唯一标识了网络中的一个主机和它上面的一个进程;- 套接字Socket = (主机IP地址,端口号)
5.2 UDP协议
用户数据报协议UDP概述
- UDP只在IP数据报服务之上增加了很少功能,即复用分用和差错检测功能。
UDP的主要特点:
UDP是无连接的,减少开销和发送数据之前的时延。
UDP使用最大努力交付,即不保证可靠交付
UDP是面向报文的,适合一次性传输少量数据的网络应用(应用层给UDP多长的报文,UDP就照样发送,即一次发一个完整报文)
UDP无拥塞控制,适合很多实时应用
UDP首部开销小,大小为8B(TCP首部大小20B)
UDP首部格式
UDP校验
- 伪首部:只有在计算校验和时才出现,不向下传送也不向上递交。
- 17:封装UDP报文的IP数据报首部协议字段是17(TCP的协议字段是6)
- UDP长度:UDP首部8B + 数据部分长度 (不包括伪首部)
UDP校验过程
- 在发送端:
- 填上伪首部
- 全0填充检验和字段
- 全0填充数据部分(UDP数据报要看成许多4B的字串接起来,后面计算校验和的时候需要16位,不到16位就要全0填充)
- .伪首部+首部+数据部分采用二进制反码求和
- 把和求反码填入检验和字段6.去掉伪首部,发送
- 在接收端:
- 填上伪首部
- 伪首部+首部+数据部分采用二进制反码求和
- 结果全为1则无差错,否则丢弃数据报/交给应用层附上出差错的警告。
- 二进制反码求和:对一个无符号的数,先求其反码,然后从低位到高位,按位相加,有益处则向高位进1(和一般的二进制法则一样),若最高位有进位,则向最低位进1.
5.3.1 TCP协议特点和TCP报文段
TCP协议特点
- TCP是面向连接(虚连接)的传输层协议。
- 每一条TCP连接只能有两个端点,每一条TCP连接只能是点对点的
- TCP提供可靠交付的服务,无差错、不丢失、不重复、按序到达。【可靠有序,不丢不重】
- TCP提供全双工通信。【 发送缓存:准备发送的数据&已发送但尚未收到确认的数据;接收缓存:按序到达但尚未被接受应用程序读取的数据&不按序到达的数据】
- TCP面向字节流:TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流【流:流入到进程或从进程流出的字节序列】
- 在传送TCP数据时,会将字节流的每一个字节按顺序编号(看下图)
TCP报文段首部格式
- 序号:在一个TCP连接中传送的字节流中的每一个字节都按顺序编号,本字段表示本报文段所发送数据的第一个字节的序号。
- 确认号:期望收到对方下一个报文段的第一个数据字节的序号。若确认号为N,则证明到序号N-1为止的所有数据都已正确收到。(ack)
- 数据偏移(首部长度):TCP报文段的数据起始处距离TCP报文段的起始处有多远以4B位单位,即1个数值是4B
- 6个控制位
- 紧急位URG:URG=1时,标明此报文段中有紧急数据,是高优先级的数据,应尽快传送,不用在缓存单排队,配合紧急指针字段使用。
- 确认位ACK:ACK=1时确认号有效,在连接建立后所有传送的报文段都必须ACK为1。
- 推送位PSH:PSH=1时,接收方尽快交付
- 接收应用进程,不再等到缓存填满再向上交付。
- 复位RST:RST=1时,表明TCP连接中出现严重差错,必须释放连接,然后再重新建立传输链接。
- 同步位SYN:SYN=1时,表明是一个连接请求/连接接受报文。
- 终止位FIN:FIN=1时,表明此报文段发送方数据已发完,要求释放连接。
- 窗口:指的是发送本报文段的一方的接收窗口,即现在允许对方发送的数据量。
- 检验和:检验首部+数据,检验时要加上12B伪首部,第四个字段为6。(和UTP类似,UTP的第四个字段是17)
- 紧急指针:URG=1时才有意义,指出本报文段中紧急数据的字节数。(比如,紧急指针现在是50,则从要发的数据报的第1个到第50个为紧急数据)
- 选项:最大报文段长度MSS、窗口扩大、时间截、选择确认.……
5.3.2 TCP连接管理
- TCP连接传输的三个阶段:连接建立——>数据传送——>连接释放
- TCP连接的建立采用客户服务器方式,主动发起连接建立的应用进程叫做客户,而被动等待连接建立的应用进程叫服务器。
TCP连接的建立
- ROUND 1:
客户端向服务端发送连接请求报文段,无应用层数据。
SYN=1,seq=x(随机)
- ROUND 2:
服务器端为该TCP请求分配缓存和变量,并向客户端返回确认报文段,允许连接,无应用层数据。
SYN=1,ACK=1,seq=y(随机),ack=x+1
- ROUND 3:
客户端为该TCP连接分配缓存和变量,并向服务器端返回确认的确认,可以携带数据。
ACK=1,seq=x+1,ack=y+1
- seq:发送的报文端的第一个字节的序号;ack:希望下一个收到的报文的序号,即确认号
SYN洪泛攻击
- SYN洪泛攻击发生在OSI第四层,这种方式利用TCP协议的特性,就是三次握手。攻击者发送TCPSYN,SYN是TCP三次握手中的第一个数据包,而当服务器返回ACK后,该攻击者就不对其进行再确认,那这个TCP连接就处于挂起状态,也就是所谓的半连接状态,服务器收不到再确认的话,还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接,由于每一个都没法完成三次握手,所以在服务器上,这些TCP连接会因为挂起状态而消耗CPU和内存,最后服务器可能死机,就无法为正常用户提供服务了。
- 解决方法:设置SYN cookie
TCP的连接释放
- 参与一条TCP连接的两个进程中的任何一个都能终止该连接,连接结束后,主机中的“资源”(缓存和变量)将被释放。
- ROUND 1:
客户端发送连接释放请求报文段,停止发送数据,主动关闭TCP连接
FIN=1,sqe=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
5.3.3 TCP可靠传输
- 可靠:保证接收方进程从缓存区读出的字节流与发送方发出的字节流不一样。
- TCP实现可靠传输的四种机制:
- 校验:与UDP校验一样,增加伪首部
- 序号:TCP传输是字节流传输,将每个字节按序编号。发送报文段时,以每个报文段的一位字节的序号为该报文段的序号字段。发送完后可以通过每个报文段的序号字段确认数据的完整正确
- 确认:TCP默认使用累计确认。假如在发送接收的过程中,此时接收方已经收到报文段"123",便返回一个确认报文段,该报文的首部确认字段为4,表示“我需要接收下一个首字段为4的报文段”。发送方收到后便继续发送“456”“78”报文段,当“456”的过程丢失,仅有“78”发送到。此时接收端便将”78”放入缓存区,但继续发送首部字段为4的确认报文段 。当发送方重新发送“456”并让接收反接收到后,由于缓存区已经有“78”了,就发首字段为9的确认报文段
- 重传:超时重传、快速重传【冗余ACK,一个确认报文段出现了3次,就认为该报文段丢失】
5.3.4 TCP流量控制
- 流量控制:让发送方慢点,要让接收方来得及接收。
- TCP利用滑动窗口机制实现流量控制。
- 在通信过程中,接收方根据自己接收缓存的大小,动态地调整发送方的发送窗口大小。即接收窗口rwnd (接收方设置确认报文段的窗口字段来将rwnd通知给发送方),发送方的发送窗口大小取决于接收窗口rwnd和拥塞窗口cwnd的最小值
- 理解看下图:
- 1.TCP为每一个连接设有一个持续计时器,只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器。2.若持续计时器设置的时间到期,就发送一个零窗口探测报文段。接收方收到探测报文段时给出现在的窗口值。3.若窗口仍然是零,那么发送方就重新设置持续计时器。
【防止接收方在重新发送非零窗口通知时该非零窗口通知丢失,导致发送方和接收方之间一直相互等待的情况】
5.3.5 TCP拥塞控制
TCP拥塞控制
- 出现拥塞的条件:对资源需求的总和>可用资源
网络中有许多资源同时呈现供应不足——>网络性能变坏——>网络吞吐量将随输入负荷增大而下降
- 拥塞控制:防止过多的数据注入到网络中。全局性
- 拥塞控制&流量控制(下图)【拥塞控制,全局性;流量控制,端到端】
拥塞控制的四种算法
- 慢开始
- 拥塞避免
- 快重传
- 快恢复
慢开始和拥塞避免
- 重点都在图里
快重传和快恢复
- 快重传:
- 快恢复:出现收到3个重复的确认,拥塞窗口马上减少,但不和拥塞避免算法一样减到1.而是直接减少到新的ssthresh值【开始减少时的拥塞窗口个数的一半】