传输层总结
为进程提供通用数据传输服务
TCP
(通俗的话来说,TCP相当于vip的快递服务,每次寄件前都会确认地址,发送后会询问是否收到,发送到时将所有发送内容进行重新编号,保证顺序,若发送中出现了丢失或者顺序混乱,马上检查,正是如此,TCP的报文头部至少有20位,发送也会比较慢)
双方保持在线
UDP
(而UDP相当于普通快递,若收件方的仓库无法容纳,则会造成数据丢失,头部只有8位,发送不保证按顺序到达)
1 TCP和UDP的区别(6)
TCP:Transimission control protocol
UDP: User Datagram protocol
- 连接
- TCP是面向连接,UDP是无连接的
- 注意理解、解释这个连接:使用tcp通信的双方必须先建立tcp连接
- TCP是面向连接,UDP是无连接的
- 可靠性
- TCP保证通信的可靠性
- UDP不保证,UDP尽最大努力交付
- 服务对象
- TCP面向字节流
- 在8bit组成的每一个字节中,TCP不向这8bit比特中插入记录标识符
- UDP面向报文,即用户数据报
- TCP面向字节流
- TCP支持拥塞控制,UDP没有
- 首部长度
- TCP首部长度20字节
- UDP首部长度8字节
- 速度
- TCP较慢
- UDP快
2 TCP三次握手
1:
client : SYN=1 + seq=j -> server
SYN_SENT
2:
server : SYN=1 + ACK=1 + acknum=j+1 + seq=k ->client
SYN_RECD
3:
client : ACK=1 + acknum=k+1, seq=j+1 ->server
ESTABLISHED
c:client客户端
s:server服务端
【c:我要和你建立链接 -- s:你真的要和我建立链接吗 -- c:我真的要和你建立链接】
具体过程:
第一次握手:
c 向s发送一个[seq=j,SYN=1]的SYN包,随后c进入SYN_SENT状态
第二次握手:
S收到c的SYN包;然后s向c发送一个SYN+ACK包[SYN=1,ACK=1,ack number=j+1, seq=k],随后s进入SYN_RECV状态
第三次握手:
c收到s的SYN+ACK包;然后c向s发送一个ACK包[ACK=1,seq=j+1,ack number=k+1]
----- 建立成功,进入ESTABLISHED状态
3 TCP为什么要三次握手而不是两次
可以从两个角度来解释
- 角度1:防止失效的链接请求再次传送到server而发生错误
- 对于失效的链接请求,client是知道的而server是不知道的
- 失效的链接请求再次传到server,server会回复一个ACK
- 如果只采用两次握手,那么此时server认为连接已经建立,此后开始等待client的通信和数据
- 而client接收到server的ACK则会将其忽视,不建立连接
- 从而,server白白浪费了资源
- 角度2:TCP可靠连接要求的应答机制以及全双工通信
- 确认通信双方的发送能力和接收能力
- 应答机制
4 客户端如果不断向服务端发起链接请求,会怎么样?(DDOS攻击)
–> server的反应:
为每一个链接请求(拟)创建一个连接(好像称为半连接?),并发送确认报文,等待来自客户端的确认
–> DDos攻击:利用漏洞
大概内容是:
攻击者利用漏洞,不断向服务端发起链接请求,但是并不给予连接确认;
一方面使得服务端忙于处理这些请求,消耗服务器资源,使得服务器不能处理正常请求;
另一方面,服务器因等待大量的这些请求的确认而空等,白白浪费资源。
预防方法:
(TCP三次握手所决定的,无法彻底解决)
(1)限制同时打开的SYN半连接数目
(2)缩短SYN半连接的TIME OUT时间
(3)关闭不必要的连接服务
5 TCP四次挥手
1:
client :FIN=1 + seq=j + acknum=k+1 -> server
FIN_WAIT_1
2:
server : ACK=1 + acknum=j+1 -> client
CLOSE_WAIT FIN_WAIT_2
3:
server : FIN=1 + seq=k+1 -> client
LAST_ACK
4:
client : ACK=1 + acknum=k+2 -> server
TIME_WAIT CLOSED
c:client客户端
s:server服务端
【c:我要和你断开连接--s:好,断吧--s:我也要和你断开连接--c:好,断吧||】
具体过程:
第一次挥手:
c向s发送一个FIN包[FIN=1,seq=j],随后c进入CLOSE_WAIT_1状态
第二次挥手:
s收到c的FIN包;然后s向c发送一个ACK包[ACK=1,ack number=j+1,],随后进入CLOSE_WAIT状态
第三次握手:
s向c发送FIN包[FIN=1,seq=k],随后s进入LAST_ACK状态
第四次握手:
c收到s的FIN包;然后c向s发送一个ACK包[ACK=1,seq=j+1,ack number=k+1],随后c进入TIME_WAIT状态
----- s收到c的ACK包后CLOSED,c的TIME_WAIT时间结束后进入CLOSED
6 TCP流量控制和拥塞控制
流量控制主要针对的是端到端传输中控制流量大小并保证传输可靠性(未收到ack就不滑动)。流量控制往往是指点对点通信量的控制,所要做的是抑制发送端发送数据的速率。
拥塞控制主要是一个全局性过程,涉及到所有主机,路由器,以及与降低网络传输性能有关的所有因素。防止过多的数据注入到网络中。如果有发生丢包则通过拥塞控制减小窗口,确定出合适(慢启动 拥塞避免 快重传 快恢复)的拥塞窗口(增性加乘性减)。
7 TCP拥塞控制
1). 慢启动:不要一开始就发送大量的数据,先探测一下网络的拥塞程度,也就是说由小到大逐渐增加拥塞窗口的大小;
2). 拥塞避免:拥塞避免算法让拥塞窗口缓慢增长,即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是加倍,这样拥塞窗口按线性规律缓慢增长。
3). 快重传:快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认(为的是使发送方及早知道有报文段没有到达对方)而不要等到自己发送数据时捎带确认。快重传算法规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期。
4). 快恢复:快重传配合使用的还有快恢复算法,当发送方连续收到三个重复确认时,就执行“乘法减小”算法,把ssthresh门限减半,但是接下去并不执行慢开始算法:因为如果网络出现拥塞的话就不会收到好几个重复的确认,所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法,而是将cwnd设置为ssthresh的大小,然后执行拥塞避免算法。
ssthresh: 慢开始门限
8 TCP可靠传输(6)
注:tcp协议如何保证传输的可靠性?
TCP可靠传输
使用机制:校验、序号、确认、重传
校验:TCP的校验机制和UDP相同;
序号:TCP首部的序号字段用来保证数据能有序提交到应用层(只保证有序发送,不保证有序到达);
确认:TCP采用累积确认,确认号是期望收到对方下一个报文段的数据的第一个字节的序号;
重传:导致TCP重传的两种事件:超时和冗余ACK
1). 失序重排:
TCP协议会对失序的数据报进行重新排序后再交给应用层;
失序原因:TCP协议报文段采用IP数据报进行传输,ip数据报会进行分组转发,因此会发生失序;
2). 差错检验
tcp协议检验传输过程中数据是否发生了错误,发生错误立即丢弃;
3). 丢弃重复数据
重复接收的数据会被丢弃
4). 应答机制
tcp通信的接收方在接收到来自发送方的数据后,需要回传一个确认报文(通常不是立即,稍微迟一点点❓❓❓)
5). 超时重传机制
发送端发送一个报文之后,会立即启动一个定时器;
当定时器的时间到达仍没有收到来自接收方的确认报文,将会立即重传这个报文段
6). 流量控制
接收端在确认报文中可以告知发送端来改变发送端的发送窗口大小,防止缓冲区移出
9 TCP和UDP分别对应 的常见应用层协议
- 与TCP对应:
- FTP:文件传输协议,端口21
- 下载、上传,都需要用到的FTP服务
- Telnet: 端口23
- 用于管理远程登录的服务协议
- SMTP 端口25
- 用于简单邮件传送的协议
- 目前很多邮件服务器都是用这个协议,因此客户端不需要打开网页就能传送邮件
- 用于简单邮件传送的协议
- POP3 端口110
- 与SMTP对应的邮件接收服务
- HTTP/HTTPs 端口 80/443
- 超文本传送协议
- FTP:文件传输协议,端口21
- 与UDP对应:
- TFTP: 端口 69
- 简单文件传输协议
- SNMP: 端口 161
- 简单网络管理协议,用于管理网络设备
- DNS: 端口 53
- 用于域名解析服务,将域名地址映射为IP地址
- TFTP: 端口 69