目录
5.2、为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?
一、传输层
在OSI七层结构的第四层,建立主机端到端连接
端到端,即主机到主机的层次。传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输。此外,传输层还要处理端到端的差错控制和流量控制问题。
定义传输数据的协议端口号,以及流控和差错校验。
传输层的任务是根据通信子网的特性,最佳的利用网络资源,为两个端系统的会话层之间,提供建立、维护和取消传输连接的功能,负责端到端的可靠数据传输。在这一层,信息传送的协议数据单元称为段或报文。
网络层只是根据网络地址将源结点发出的数据包传送到目的结点,而传输层则负责将数据可靠地传送到相应的端口。
二、传输层协议 TCP和UDP协议
- 面向连接网络协议,是指通信双方之间在进行通信之前要先建立连接。比如打电话,双方通话前需要先建立连接。等数据发送结束后,双方再断开连接。
- 无连接网络协议,是指通信双方不需要事先建立一条通信线路,而是把每个带有目的地址的包送到网络线路上,由系统自主选定路线进行传输。比如QQ发送信息。
2.1、UDP协议
User Data Protocol用户数据报协议
UDP协议是无连接、不保证可靠性的传输层协议。发送端不关心发送的数据是否到达目标主机、数据是否出错等,收到数据的主机也不会告诉发送方是否收到了数据,它的可靠性由上层协议来保障。传输数据速度更快,效率更高。
2.2、TCP协议
TCP是面向连接的、在传送数据之前必须先建立连接,数据传送结束后要释放连接,可靠的进程到进程通信的协议。TCP提供全双工服务,即数据可在同一时间双向传输,每一个TCP都有发送缓存和接收缓存,用来临时存储数据。
因为先建立连接所以三次握手和四次挥手是围绕传输层TCP协议来讲的。
2.3、总结下TCP与UDP的不同
TCP 是面向连接的传输控制协议;而UDP 提供了无连接的数据报服务。
TCP 具有高可靠性,确保传输数据的正确性,不出现丢失或乱序;
UDP 在传输数据前不建立连接,不对数据报进行检查与修改,无须等待对方的应答,所以会出现分组丢失、重复、乱序,应用程序需要负责传输可靠性方面的所有工作。
UDP 具有较好的实时性,工作效率较 TCP 协议高。UDP 段结构比 TCP 的段结构简单,因此网络开销也小。
TCP 协议可以保证接收端毫无差错地接收到发送端发出的字节流,为应用程序提供可靠的通信服务。对可靠性要求高的通信系统往往使用 TCP 传输数据。
TCP 协议传输更加稳定可靠,UDP 协议传输效率更高。
这两个协议各有特点,在实际应用 中,根据实际应用的需要,选择不同的传输层协议
三、TCP报文段格式
TCP全称传输控制协议,必须对数据的传输进行控制。
字段名称 | 长度(位) | 描述 |
---|---|---|
源端口号 | 16 | 表示数据从哪个进程来 |
目的端口号 | 16 | 表示数据要到哪个进程去 |
序号 | 32 | seq,发送端为每个字节进行编号,便于接收端正确重组, 序号可以保证传输信息的有效性 |
确认序号 | 32 | 每一个ACK对应这一个确认号,它指明下一个期待收到的字节序号,表明该序号之前的所有数据已经正确无误的收到。确认号只有当ACK标志为1时才有效。比如建立连接时,SYN报文的ACK标志位为0。如确认号是x,就是表示前X-1个数据段都已经收到。 |
4位首部长度(数据偏移) | 4 | 表示TCP头部有多少个32位bit(有多少个4字节) 根据该部分可以将TCP报头和有效载荷分离 |
6位标志位(控制位) | 6 | URG, ACK, PSH, RST, SYN, FIN |
URG | 1 | 紧急位,紧急指针是否有效 |
ACK | 1 | 确认位,确认号是否有效 |
PSH | 1 | 急迫位,提示接收端应用程序立即将数据拿走 |
RST | 1 | 重置位,处理异常连接,要求重新建立连接 |
SYN | 1 | 同步位,请求建立连接 |
FIN | 1 | 断开位,通知对方本端要关闭连接 |
16位窗口大小 | 16 | 接收方接收缓冲器剩余空间的大小, 流量控制,窗口大小:说明本地可接收数据段的数目。这个值的大小是可变的,当网络通畅时接收端响应消息会将这个窗口值变大以加快传输速度,当网络不稳定时减小这个值可保证网络数据的可靠传输,TCP中的流量控制机制就是依靠变化窗口的大小实现的。 |
16位校验和 | 16 | CRC校验,包含TCP首部和数据部分 |
16位的紧急指针 | 16 | 指向需要优先处理的报文,配合URG使用, 按序到达是TCP协议保证可靠性的一种机制 |
四、TCP三次握手
TCP是面向连接的,就是说每次发送数据之前都要和对方建立一条可靠的连接,这个建立连接的过程分为3个步骤,就叫做三次握手
① 当客户端向服务器发送请求连接的报文时
Seq序列号=x(x为随机)
SYN=1(表示发送连接请求)
② 服务器端收到客户端发来的请求报文后,同意建立连接,则向客户端发送确认报文:
Seq序列号=y(这时服务器也会产生一个序列号y,和客户端的序号不相关)
Ack确认号=x+1(Seq序列号x+1,表示确认收到了客户端的请求,表示肯定了i
ACK=1(表示这是条确认请求)
SYN=1(同时也发送一个建立连接的请求)
③ 客户端进程收到服务端进程的确认后,还要向服务端给出确认,然后连接成功建立:
Seq序列号=x+1(这时客户端的序号为1)
Ack确认号=y+1(表示确认收到了服务器的连接请求)
ACK=1(表示这是确认报文)
五、TCP四次挥手
客户端打算断开连接,向服务器发送FIN报文
服务器收到连接释放报文后,就向客户端发送ACK应答报文
服务器也打算断开连接,向客户端发送连接释放(FIN)报文
客户端收到来自服务器的连接释放后,会向服务器发送一个ACK应答报文。
在四次挥手中有一个半关闭的概念
5.1、谁可以中断连接?客户端还是服务端还是都可以?
都可以中断连接
其实在最后一步客户端收到服务端的ACK之后实际上是不会立马关闭连接的,它进入了TIME_WAIT状态,为什么不立即关闭?
这种情况: B向A发送 FIN = 1 的释放连接请求,但这个报文丢失了, A没有接到不会发送确认信息, B 超时会重传,这时A在 WAIT_TIME 还能够接收到这个请求,这时再回复一个确认就行了。(A收到 FIN = 1 的请求后 WAIT_TIME会重新记时)
另外服务器B存在一个保活状态,即如果A突然故障死机了,那B那边的连接资源什么时候能释放呢? 就是保活时间到了后,B会发送探测信息, 以决定是否释放连接。
5.2、为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?
答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假想网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
5.3、为什么是四次挥手不是三次挥手?
因为当服务端还有数据没有传完的情况
四次挥手确保了TCP连接的双向关闭,并且允许在关闭过程中继续发送剩余的数据。这种方式虽然比三次握手复杂,但它提供了更高的可靠性和灵活性,确保了数据在连接关闭前的完整传输。相比之下,如果只有三次挥手,就无法实现这种双向关闭和数据完整性保证。
5.4、2MSL(最大报文段生存时间)
MSL在RFC 1122上建议是2分钟,而源自berkeley的TCP实现传统上使用30秒,因而,TIME_WAIT状态一般维持在1-4分钟。
六、常见协议及其端口
常见的UDP协议和端口号
协议 | 描述 | UDP 端口号 |
---|---|---|
NTP | 网络时间协议 | 123 |
DHCP | 动态主机配置协议 | 67服务器 68客户端 |
SNMP | 简单网络管理协议 | 161代理162接收消息 |
TFTP | 简单文件传输协议 | 69 |
RPC | 远程调用协议 | 111 |
常见的TCP协议和端口号
协议 | 描述 | TCP 端口号 |
---|---|---|
FTP | 文件传输协议 | 20数据21远程: 用于传输指令 |
SSH | 安全 Shell 服务 | 22 |
Telnet | Telnet 服务 | 23 |
SMTP | 简单邮件传输协议 | 25 |
DNS | 域名主从服务,安全 | 53 |
HTTP | 超文本传输协议 | 80 |
POP3 | 邮局协议版本3 | 110 |
HTTPS | 安全超文本传输协议 | 443 |
MySQL | MySQL 数据库 | 3306 |