目录
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 |
4072
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
