计算机网络-----第二章 传输层

第二章 传输层

---

1. 传输层概述

​ 传输层的功能是提供进程和进程之间的通信,实现复用和分用,对收到的报文进行差错检测.

​ 传输层会给消息加上发送端端口和接收端端口,根据下一层网络层提供的IP地址去寻找相应的目标机器(其中还会经历IP地址转换为MAC地址)

(1). 传输层协议

​ 传输层两个协议:TCP和UDP.

TCP	UDP
面向连接的传输控制	无连接用户数据报
传送数据前必须建立连接,传输后释放连接	传送数据不需要建立连接,收到数据页不需要确认
不提供广播,多播	支持广播
开销大	时延小
确认,流量控制,计时器以及连接管理	无
适用于大文件	适用于小文件

(2). 端口

​ 实现分用需要通过端口号分发从网络层获得的数据.

​ 端口号用于区分本地不同的网络进程,只有本地意义,不同计算机之间的端口号是没有联系的.

端口号:

• 服务端使用的端口号
  • 熟知端口号(1~1023):给TCP/IP最重要的一些应用程序,大多数被系统占用
    • FTP:21
    • TELNET:24
    • SMTP:25
    • DNS:53
    • TFTP:69
    • HTTP:80
    • SNMP:161
  • 等级端口号(1024~49151):服务端安装的应用程序使用的,如Tomcat的8080端口
• 客户端使用的端口号(49152~65535):在客户进程运行是动态分配

网络中使用套接字来标识网络中的一个主机和它上面的进程,套接字Socket=(主机IP地址,进程端口号)

2. UDP协议

(1). UDP协议概述

​ UDP只是在IP数据服务报之上增加了很少的功能,即复用分用和差错检测功能.

主要特点:

• UDP是无连接的
• UDP使用最大努力交付,即不保证可靠交付
• UDP是面向报文的,适合一次性传输少量数据的网络应用
• UDP无拥塞控制,适合实时应用(视频通话)
• UDP的首部开销比较小,8B,而TCP有20B
  • 16位源端口号
  • 16位目的端口号
  • 16位UDP长度
  • 16为UDP检验和

(2). UDP校验

在进行校验时会出现伪首部:

• 源IP地址
• 目的IP地址
• 0
• 17
• UDP长度:UDP首部加数据字段长度

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6Hz1emRN-1575943466044)(http://benjaminlee.cn:8989/hello/images/1574490572867.png)]

3. TCP协议

(1). TCP的特点

• TCP是面向连接的传输层协议
• 每条TCP连接只能有两个端点
• TCP提供可靠交付的服务,无差错,无丢失,不重复,按序到达
• TCP提供全双工通信
  • 发送缓存:准备发送的数据,和已经发送但是没被确认收到的数据
  • 接收缓存:按序到达但是没被读取的数据,不按序到达的数据
• TCP面向字节流:将应用程序交下来的数据看成是一连串的无结构的字节流

(2). TCP报文段首部格式

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DBMXQbgS-1575943466045)(http://benjaminlee.cn:8989/hello/images/1574491692732.png)]

序号:TCP连接传送的字节流中的每一个字节都按顺序编号,这里指本次传输的第一个字节的序号

确认号:期望收到对方下一个发送的下一个报文段中包含的序号,如果确认号为n,那么证明前n-1个字节全部都正确收到了

数据偏移:TCP报文中起始字节到第一个数据字节的长度,也就是首部的长度

URG:紧急位,当此位为1时,该报文具有较高的优先级,可以不在缓存中排队发送

ACK:确认位,当ACK为1时,报文段才有效.连接建立后所有的报文此位都为1

PSH:推送位,当PSH为1时,接收方不会等到缓存填满再向上交付,而是立即交付

RST:复位,当RST为1时,表明连接中出现了严重的差错,必须释放连接重新建立传输连接

SYN:同步位,当SYN为1时,表名当前报文是一个请求或接受连接报文

FIN:终止位,FIN为1时,表名次报文段将发送方所有的数据都发送完毕,请求释放连接

窗口:由接收方给出,是接收方允许发送方下一次发送数据的数量

检验和:加上12B的伪首部,进行校验,TCP中协议字段为6,TCP中是17

紧急指针:在紧急位URG为1时才有效,代表本报文段中紧急数据的字节数

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

(3). TCP连接管理

​ TCP连接传输的三个阶段:连接建立,数据传送,连接释放

​ TCP连接的建立采用客户服务器方式,主动发起连接的应用进程叫客户,被动等待连接建立的应用进程叫服务器

1). TCP连接的建立

​ 过程中SYN是同步位,代表本次是请求报文,ACK是确认位,代表已经建立了连接.seq是序号,ack是确认号,回应的ack应该是请求中seq+1

1. 客户端发送连接请求报文段
   1. SYN = 1, seq = x,其中seq是一个随机数,无效的
   2. 客户端:无状态(CLOSE) ===> 等待匹配请求(SYN-SENT)
2. 服务端为该TCP连接分配缓存和变量,并发送确认报文段
   1. SYN = 1, ACK = 1, seq = y, ack = x+1
   2. 服务端: 监听TCP建立请求(LISTEN) ===> 收到建立请求并且返回确认后等待确认的确认(SYN-RCVD)
3. 客户端为该TCP连接分配缓存和变量,并向服务端返回确认的确认,这时可以携带数据.
   1. SYN = 0, ACK = 1, seq = x+1, ack = y+1
   2. 客户端: 等待匹配请求(SYN-SENT) ===> 已经建立连接(ESTABLISHED)
   3. 服务端:收到建立请求并且返回确认后等待确认的确认(SYN-RCVD) ===> 已经建立连接(ESTABLISHED)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3JwzWD6C-1575943466046)(http://benjaminlee.cn:8989/hello/images/1574495842797.png)]

​ 以上的过程被称作为TCP建立连接的三次握手机制.之所以要进行最后一次握手,是因为在第二次握手进行完之后,客户端已经知道服务端同意建立连接了,但是服务端并不知道客户端得到了同意,这是可能发生很多状况,如消息的丢失,客户端已经挂机.只有客户端再发一次确认报文,才可以让双方都知道这个连接已经建立.

​ 还有一个状况就是,如果采用两次握手.服务端发出第一个请求报文后,没有到达服务端,有发送了一个请求.第二个请求顺利到达,建立连接完成通信后断开连接.这时第一个请求到达了服务端,那么服务端还是会给出一个确认报文,因为服务端并不能识别这两个请求报文是重复的,这时不需要客户端给出确认服务端就认为又建立了一个连接.明显是不符合逻辑的.

2). SYN洪泛攻击

​ 客户端不断向服务端发送建立请求报文段,服务端就直接分配了内存,但是客户端不进行下一步了,但是服务端会不断的发送确认报文段.客户端建立非常多的这种TCP连接,占用客户端的内存,直至死机

3). TCP连接的释放

1. 客户端发送连接释放报文段.
   1. FIN = 1, seq = u.
   2. 这时还是可以双向传输数据的
   3. 客户端:已经建立连接(ESTABLISHED) ===> 等待中断请求的确认(FIN-WAIT-1)
2. 服务端回送一个确认报文段.
   1. ACK = 1, seq = v, ack = u+1.
   2. 这时客户端不能向服务端发送数据了
   3. 服务端:已经建立连接(ESTABLISHED) ===> 等待服务器应用程序关闭连接(CLOSE-WAIT)
   4. 客户端:等待中断请求的确认(FIN-WAIT-1) ===> 等待服务端关闭连接(FIN-WAIT-2)
3. 服务端发送完当前正在发送的数据,会发出连接释放报文段,主动的释放连接.
   1. FIN = 1, ACK = 1, seq = w, ack = u+1
   2. 双方都不能发送数据了
   3. 服务端:等待服务器应用程序关闭连接(CLOSE-WAIT) ===> 等待请求的确认(LAST-ACK)
4. 客户端回复确认报文段,再等到时间等待计时器设置的最长报文段寿命后,连接彻底关闭
   1. ACK = 1, seq = u+1, ack = w+1
   2. 客户端:等待服务端关闭连接(FIN-WAIT-2) ===> 等待足够长的时间确保服务器收到回复(TIME-WAIT) ===> 连接断开(CLOSED)
   3. 服务端:等待请求的确认(LAST-ACK) ===> 连接断开(CLOSED)
   4. 服务端如果没有收到这次的确认回复,那么会重新进行第三次挥手.直到得到回应

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5MFHP5VI-1575943466047)(http://benjaminlee.cn:8989/hello/images/1574499370153.png)]

​ 通常来说,让客户端和服务端两方都知情一件事情需要三次通信,但是在连接的释放过程中,还需要考虑当前正在发送的资源需要进行一个结尾.所以在服务端收到第一次断开连接的请求报文后,会先给客户端一个确认报文,表示服务端已经打算关闭连接,这时客户端已经明白自己不需要再发送数据了,但是可能还会有服务端正在处理的数据发来.等服务端处理完所有的数据,会给客户端发送断开连接的请求报文,表示服务端不再发送数据.同样的,客户端需要会送一个确认报文来让服务器知道客户端已经收到了服务端的通知完全断开连接,服务端也会完全断开连接.

​ 如果服务端没有收到客户端最后发送的确认报文,那么会重新发送服务端断开连接的请求报文.所以需要客户端等待一定时间确保可以收到这个再次发送的请求报文.如果客户端不进行等待,那么服务端会不停的重发.

(4). TCP可靠传输

​ 可靠传输是指数据的传输保证发出方发出的字节流和发送方发出的字节流是完全一样的.

​ 网络层是不保证可靠传输的.

TCP实现可靠传输的机制:

1. 校验:增加伪部首,二进制反码求和的反码.和UDP的校验一样
2. 序号:通过每次传输时发送序号,接收的回应中传输下一次的首序号保证发送的数据是连续的
3. 确认:接收方收到数据后,会往回发送一个确认报文,内容包含当前接受方应该得到的下一个报文段(中间空缺的话会对发送方进行提示),发送方缓存中的字节流不经确认是不会删除的.确认报文可以加在接收方发送的数据中发送,称为捎带确认.
4. 重传:放接收方发回来的确认号不符合当前字节流中的第一个字节的序号或在规定时间内没有收到确认时,发送方会重新传输这段数据.

(5). TCP流量控制

​ 滑动窗口机制

​ 窗口规定了一次性可以发送的包的数量,每次接收方送回一个确认号,窗口的开始会滑动到确认号对应的位置.没有收到确认的话,窗口不会进行滑动,就会重复的发送一样的几个包.

​ 接收方在返回的确认报文中设置了自己期望的下一次发送的数据量(一般都是期望充分使用缓冲池),也就是窗口.这样可以动态的调整数据发送的速度.

​ 当接收方发送的窗口大小为0时,发送方不再发送数据,接收方此时进行数据的上层提交等操作.当进行了一部分后如果想要让发送方重新开始发送数据,重新发送一个窗口大小不为0的确认报文即可.

​ 接收方的确认报文并不是每一次收到数据都会发送的,而是有一个累积的过程.

​ 为了防止窗口为0的确认报文丢失导致的两端相互等待,出现了这样的机制:TCP为每一个连接都设有一个计时器,发送方只要要收到接收方的零窗口通知,就启动计时器.如果计时器设置的时间到期,会向接收方发送一个零窗口探测报文段,接收方这时会重新发送此时的窗口大小.

(6). TCP拥塞控制

​ 拥塞是指对资源的需求超过了资源能提供的大小(交换机来不及转发数据等等),会有许多资源同时呈现资源供应不足,导致网络性能变坏.

​ 拥塞控制总体上就是防止过多的数据注入到网络中.这样听起来与流量控制很像,但流量控制面向的是单个连接中的两个端点,而拥塞控制面向的是有全局性正在连接某台设备的全部端点.

四种算法:

1. 慢开始
2. 拥塞避免
3. 快重传
4. 快恢复

​ 接受窗口是接收方根据接受缓存设置的值,并告知给发送方,反映接收方容量.

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

​ 发送窗口(实际发送的数据量) = Min(接收窗口, 拥塞窗口)

1). 慢开始和拥塞避免

​ 慢开始指数据传输时拥塞窗口很小,但是后面以质数进行增长(收到确认报文时二倍增长).

​ 当拥塞窗口达到ssthresh值时,通过加法进行增长,这是拥塞避免.

​ 当拥塞窗口达到一定值时,减小到1,重新开始这个过程,并根据网络拥塞的情况重新设置ssthresh值(网络拥塞是拥塞窗口的一半).

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pL9YNHg0-1575943466048)(http://benjaminlee.cn:8989/hello/images/1574510981964.png)]

2). 快重传和快恢复

​ 当收到3个重复的确认(中间的报文没有收到)后,执行快重传,迅速的将缺少的报文进行重传.此时被认为发生了网络拥塞.会重新计算ssthresh值为此时拥塞窗口的一半大小,并重新设置拥塞窗口大小为新的ssthresh值,也就是原来的一半.

​ 快恢复是指拥塞窗口变小后,直接以加法进行增大,较快的进行恢复.(快恢复的快主要指不需要重新从1开始)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aw26rNyh-1575943466049)(http://benjaminlee.cn:8989/hello/images/image-20191126223926961.png)]